It's not about programming: engineering reliable computer systems is about how you work with the organisation and people around you to deliver, to prove you've delivered, and to keep alive your system.
If you don't understand your code well enough to teach it to anyone -- especially those less technical, educated or experienced than you -- you don't pass review.
If you don't practise for critical incidents -- which firefighters and emergency-response teams do -- you'll make that unexpected bad day a whole lot. Be ready, spend time to be calm, prepared and (above all) practised.
If you're fire-fighting -- and people love to praise a hero -- then get yourselves enough time to reflect and learn from what's going on. Trust your colleagues, because almost nobody shows up to intending do a bad job, to find out and prevent re-occurring mistakes.
It's great that your planning, design, implementation, testing, deployment and monitoring can react in an agile way to changes in your business needs, but doing that with sporadic and ad-hoc meetings is extra strain on your team. Make the meetings routine and clockwork so that it can be low-exertion in contrast to the creative work of documenting the failure modes (in test cases) or designing the interaction, moving parts of the system.
Learn from history:
The team that brought us everything-is-a-file paradigm of Unix got together later to think of the next iteration for networked computers. The pattern of small services responding to inter-process communication passed through message buses, so your containerised services can be daisy-chained together to provide your software-as-a-service, is an echo of the microkernel of Bell Labs' Plan 9 From Outer Space with its paradigm of every-app-is-a-server.
Mainframes had time-sharing and many programs running for a wide range of users back when there was 'maybe a market for six computers worldwide' (IBM's Thomas Watson), which enterprise virtualisation and cloud service providers are reprising today.
'Your shipping software is your org chart' is a paraphrase of a 1967 piece of wisdom my Melvin Conway; Conway's law reads: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Amdahl's Law for the limits of parallelism and how organising work to get speed ups from the embarrassingly-parallel bits has echoes in team structures where organising the work can dominate time spent in place of completing the tasks ahead of you.
No real comparable thing exists, and to expect it is to think in the MS single-microcomputer-on-every-desk mindset. We're networked and clouded these days, so every program is a server which can interact with any other program (or should be) and a single-lump tool is limited to its black box. In the Free/Open Source world, you can get full SQL DB's or NoSQL storage engines free-at-point-of-use, so why would you grab a single solution when you can pick the components which best fit your needs?
I think you've condemned your many clients to no scalability and little flexibility. When it comes to cope with larger numbers of records, more complicated business logic or increased concurrent access, there's nothing like Access in the Free/Open Source world because the big-boy DB's are free-at-point-of-use. You then have the freedom to implement a web UI or a GTK+ UI or a QT UI talking a standard protocol and standard DB query language, and with that comes the architectural freedom to divorce the back-end from the business logic from the user interface -- which makes maintenance and ongoing improvements easy.
Another one runs NT Server, because porting 100,000+ part numbers to a new database isn't worth the upgrade.
Can you name and shame your customer*, so I don't get delayed by parts from that DB when it goes pear-shaped? Data should be transferrable; migration -- like backups and disaster recovery -- should be a thing we expect as normal for digital information.
*: well, no you won't, this request is hyperbole on Slashdot.
But... if I were going to try and confound the system which can correlate almost all of your electronic records, you'd need to have a rolling list of sock-puppets who supply proxy identifying information to the cell towers. You'd need to have a bundle of SIM cards in the handset to do this, or to have electronics which fake the same data. Then, to make sure you can actually be contacted, you need to have a call redirection system sending you SIP calls (though if you're designing the hardware for this, you can encrypt the data streams carrying your voice over the existing cell transports - note that Skype may be encrypted but we don't know how well or who has a back door key). To avoid that being a single point of obfuscation failure, it probably needs to be a distributed network of TOR-like relays across hardware and cloud providers, and even then, it will probably need to be steganographically hidden in ordinary-looking traffic.
Not impossible, but still a pipe-dream since 1993.
Rob Pike's setup on a Macbook Air with Plan 9 From Userspace is nearly there. See rob.pike.usesthis.com/, and there's no way that a full 9p system shouldn't be usable on a phone or tablet.
How extensive is the undiagnosed population, and how fast is that population growing, and how much will they cost to treat?
You have a 1 in 100,000 of a 20+year ailment giving you symptoms which cause its diagnosis and treatment. Most carriers are asymptomatic, and the article states that no-one knows how many people are carriers or how many more infections they cause.
I'll suggest that the undiagnosed population is a few million, but it's not growing fast because most people wash their hands after pooping and before preparing food. Your fiscal choice is to wait until it becomes a problem (cost:billions, using your number above) or to pay for preventative work which studies the problem and works to diagnose and lower the asymptomatic-yet-parasitised population (cost:millions). Your call.
May I add my contribution to the many elucidatory and finely-expressed commentary as is usual here at Slashdot?
I've not seen anyone ask which Linux platform Steam is going to arrive on. There's desktop Linux, which may make a fine foundation for a 'Punk' or 'Boiler' Steam box*, or there's Android, which will help Steam sell to casual, mobile and hand-held users. Steam games on either would be quite welcome.
*: Steam Punk variety has ornamental gears and intricate woodwork (I'm sure you could see that one coming).
"Being intellectually sound, however, is not sufficient to affect change"
Can we have the argument about affect and effect here? I would have used 'effect change' here, unless OP means that change, in some way, is to be altered.
Also, there an enormous issue about how invested we all are in the existing system, with jobs and housing provided by it. That makes it very costly to change - but it's quite costly to stay paying a mortgage which supports the lifestyles of the people who sold created and sold CDOs and which is also rescuing the present situation.
I'm a software tester in an organisation which has clear delineation between manual testers, software test engineers who build automated tests and developers (I gotta say that I speak for me and not them here - that's the policy out of the way). The first two of that list need to have a 'question everything' testers' mentality; the last two need to have a technical grasp of how the whole thing works, from the core OS, servers and transports to the libraries used and the UI.
A manual tester is concerned with the human experience of your software. Typically there will be a script of the exact actions or the class of actions the manual tester is expected to cover. Some firms roll regression testing and new feature testing into the manual tester's role, others have a separate user-acceptance testing team who stand between released software and deployment.
The automation tester's role is to make the computer test the software, by building a framework around the program and its installed environment to check the system as-a-whole does the intended job. Some automation testers also write unit tests in the core program code; mostly this is left to the developers, who are increasingly being asked to show that their code works - and doesn't break the existing code - before check-in. Some places operate a Behavior-Driven Development (BDD) process where client needs are expressed in testable ways - so that the evidence that your software does what a client wants is written down clearly for the client to see, the tester to test and the developer to build. Some BDD systems even build tests which show that these goals are met, and are known as Test-Driven because the proof of rightness is shown by the tests.
Preparing for an telephone screening or interview about software test engineer, you will need to show that you're technically-minded, that you've worked engineered a test system before, that you understand the benefits and shortcomings of building such a system (such as knowing when to build tests and when to leave low-hanging test fruit to manual testers), and that you're concerned for the quality of the product more than for building a new toy test rig.
I disagree with nearly every point made above, but I know this as a tester: there are a lot of people who shuffle into testing because it's the gateway to working in software. That's no bad thing. But mix it with the lack of confidence to apply for and get developer roles, and you will probably harm your sanity and your career. In every job, you need to be competent and confident. On top of that, you need to be personable so, for example, you don't make bug reports critical of the developers who made them (and know how to calm down a dev who's got that idea).
To be a good tester is genuine hard work requiring the best of your technical insight, pedantry and commitment to high standards, but to be a great tester will call for charisma, kindness, honesty, good working relationships, and the skills to help make a dysfunctional team work right.
If you're only a tester for a short while and move on to a developer role, you can either blame the economy for not having enough dev jobs (so you compromised in order to fulfill your passion for making software), or you can say that you wanted to improve your developer skills by learning what it's like to be on the other side of the fence as a tester. It's not a black mark if working as a tester makes it a benefit to you and a prospective employer.
Content too? I think that you could easily co-opt this by supplying a farm of content-producing people for Y-Combinator to invest in, making them subject to the same market forces -- or putting them in the same boat -- that the movie studios and record companies are.
The fix requires more and better entertainment, more and better news reporting, more better-aware citizens and more and better political engagement. Make reading up on news get you points in some kind of alternate-reality game (ARG), discussing news and being politically active gets you points, too. Perhaps points to make your shopping or recreation cheaper (but there's probably other incentives).
Can I ask someone in the US to get the Feds on to this? News International's staff are alleged to have bribed UK Police, which is a federal crime under your Foreign Corrupt Practices Act. Please get it investigated, and get New International prosecuted for perverting justice.
We would definitely herald 2012 as the Year Of Linux On The Desktop if we had a UI which used a 20-dimensional hypercube. Redmond's Photocopiers couldn't keep up with that kind of innovation!
Can I bring my laptop to you and you install a hypervisor and partition it up with some virtual machines so I have one partition for your work environment and one for my stuff? You can pick the hypervisor...
Nice dream, but this can never be a win because, soon as I have access to the hardware and run my instrumenting hypervisor, your disk encryption is compromised and any secrets you might want to keep -- and that's no matter how obscure the notion of a secret: logins, handshakes, keyfiles, and onward to company confidential or technical know-how -- those secrets are now theirs to leak.
They're racking their brains as to what to do next.
I would aim for kernel threads running directly through CUDA and the Scheduler knowing the performance profile of suitable work for the GPU and the message-passing cost of moving work to the GPU^H^H^H parallelism co-processor. Make the interface right and you should be able to shift tasks across heterogeneous processing units. Do it perfectly and you can have a Linux Virtual Processor model which allows you to start running a task on your desktop, shuffle it to a laptop for transit, pare it down to use on your mobile phone, buy some CPU time from an internet cluster to grind through some calculations before transferring it home. Choose x86: there's already enough x86 junk in other trees, and it might fix up the ARM shenanigans too!
Expensify's got 7 people total in their huddle but they want more. They've trolled successfully to get your and my attention -- and got worldwide press for this. For a company at 7 seats, everyone has to pitch in at everything: 'not my job' and 'not my skillset' are unacceptable and only 'what can I do to help us get the win?' is the only thing that will get this company to success.
Maybe you didn't like the style and wouldn't work there. It reminded me that I enjoy being the sort of person who uses any skill and the best tool to do what I've chosen to get into. And it's good to know that there are other people out there who will celebrate and encourage that.
(But still, I've been trolled and this is a post in a troll thread.)
You aren't a mainstream Christian if you think that*. Penal Atonement is a minority view of what the Cross does for mankind's relationship with God. It makes sense to a human but it can't be the true explanation because it requires God to make humanity susceptible to fail God's rules, then have God step in and sacrifice God to God to break those rules and 'satisfy' God of something when most of it is breaking God's rules.
Any idea how unfair it seems of God has to hold you or me to God's rules? Or that we must 'adore' or 'worship' such a deity in such a setup?
*: Penal atonement, that Jesus on the cross is a sacrifice which satisfies God's need to have someone pay for the sins of the world.
Perhaps we need to add steganographic noise to the other elements on your photo-sharing sites, just so that your messages don't stick out like a sore thumb.
This is a really terrible review. You could have said that Business Process Management (BPM) and Business Process Execution Language (BPEL) are important to know for this book. Or it's so esoteric that, if you need to know what BPM is, you already know BPM.
I don't know if there are domain experts or a client-base whose desires a traditional engineering effort can be aimed at. So the internal crowd get to be the client-base and to provide feature requests or feature enhancements themselves.
I can't work out if that's a good thing. Perhaps they'll be doomed like Sun to have a closed culture (as Valerie Aurora pointed out http://blog.valerieaurora.org/2010/02/13/sleeping-with-the-enemy/) which will only scratch the itches that people within Facebook need for Facebook. On the other hand, they've built a substantial internal culture which mimics a successful free software culture.
Slashdot Mirror
It's not about programming: engineering reliable computer systems is about how you work with the organisation and people around you to deliver, to prove you've delivered, and to keep alive your system.
If you don't understand your code well enough to teach it to anyone -- especially those less technical, educated or experienced than you -- you don't pass review.
If you don't practise for critical incidents -- which firefighters and emergency-response teams do -- you'll make that unexpected bad day a whole lot. Be ready, spend time to be calm, prepared and (above all) practised.
If you're fire-fighting -- and people love to praise a hero -- then get yourselves enough time to reflect and learn from what's going on. Trust your colleagues, because almost nobody shows up to intending do a bad job, to find out and prevent re-occurring mistakes.
It's great that your planning, design, implementation, testing, deployment and monitoring can react in an agile way to changes in your business needs, but doing that with sporadic and ad-hoc meetings is extra strain on your team. Make the meetings routine and clockwork so that it can be low-exertion in contrast to the creative work of documenting the failure modes (in test cases) or designing the interaction, moving parts of the system.
Learn from history:
Short for "We Don't hire over 40's."
Get off my lawn, kid.
No real comparable thing exists, and to expect it is to think in the MS single-microcomputer-on-every-desk mindset. We're networked and clouded these days, so every program is a server which can interact with any other program (or should be) and a single-lump tool is limited to its black box. In the Free/Open Source world, you can get full SQL DB's or NoSQL storage engines free-at-point-of-use, so why would you grab a single solution when you can pick the components which best fit your needs?
I think you've condemned your many clients to no scalability and little flexibility. When it comes to cope with larger numbers of records, more complicated business logic or increased concurrent access, there's nothing like Access in the Free/Open Source world because the big-boy DB's are free-at-point-of-use. You then have the freedom to implement a web UI or a GTK+ UI or a QT UI talking a standard protocol and standard DB query language, and with that comes the architectural freedom to divorce the back-end from the business logic from the user interface -- which makes maintenance and ongoing improvements easy.
Another one runs NT Server, because porting 100,000+ part numbers to a new database isn't worth the upgrade.
Can you name and shame your customer*, so I don't get delayed by parts from that DB when it goes pear-shaped? Data should be transferrable; migration -- like backups and disaster recovery -- should be a thing we expect as normal for digital information.
*: well, no you won't, this request is hyperbole on Slashdot.
http://www.schneier.com/blog/archives/2013/03/our_internet_su.html
But... if I were going to try and confound the system which can correlate almost all of your electronic records, you'd need to have a rolling list of sock-puppets who supply proxy identifying information to the cell towers. You'd need to have a bundle of SIM cards in the handset to do this, or to have electronics which fake the same data. Then, to make sure you can actually be contacted, you need to have a call redirection system sending you SIP calls (though if you're designing the hardware for this, you can encrypt the data streams carrying your voice over the existing cell transports - note that Skype may be encrypted but we don't know how well or who has a back door key). To avoid that being a single point of obfuscation failure, it probably needs to be a distributed network of TOR-like relays across hardware and cloud providers, and even then, it will probably need to be steganographically hidden in ordinary-looking traffic.
Not impossible, but still a pipe-dream since 1993.
Rob Pike's setup on a Macbook Air with Plan 9 From Userspace is nearly there. See rob.pike.usesthis.com/, and there's no way that a full 9p system shouldn't be usable on a phone or tablet.
How extensive is the undiagnosed population, and how fast is that population growing, and how much will they cost to treat?
You have a 1 in 100,000 of a 20+year ailment giving you symptoms which cause its diagnosis and treatment. Most carriers are asymptomatic, and the article states that no-one knows how many people are carriers or how many more infections they cause.
I'll suggest that the undiagnosed population is a few million, but it's not growing fast because most people wash their hands after pooping and before preparing food. Your fiscal choice is to wait until it becomes a problem (cost:billions, using your number above) or to pay for preventative work which studies the problem and works to diagnose and lower the asymptomatic-yet-parasitised population (cost:millions). Your call.
I took is as grand satire, merciless in ridiculing its targets, and I laughed most of the way through it.
May I add my contribution to the many elucidatory and finely-expressed commentary as is usual here at Slashdot?
I've not seen anyone ask which Linux platform Steam is going to arrive on. There's desktop Linux, which may make a fine foundation for a 'Punk' or 'Boiler' Steam box*, or there's Android, which will help Steam sell to casual, mobile and hand-held users. Steam games on either would be quite welcome.
*: Steam Punk variety has ornamental gears and intricate woodwork (I'm sure you could see that one coming).
"Being intellectually sound, however, is not sufficient to affect change"
Can we have the argument about affect and effect here? I would have used 'effect change' here, unless OP means that change, in some way, is to be altered.
Also, there an enormous issue about how invested we all are in the existing system, with jobs and housing provided by it. That makes it very costly to change - but it's quite costly to stay paying a mortgage which supports the lifestyles of the people who sold created and sold CDOs and which is also rescuing the present situation.
I'm a software tester in an organisation which has clear delineation between manual testers, software test engineers who build automated tests and developers (I gotta say that I speak for me and not them here - that's the policy out of the way). The first two of that list need to have a 'question everything' testers' mentality; the last two need to have a technical grasp of how the whole thing works, from the core OS, servers and transports to the libraries used and the UI.
A manual tester is concerned with the human experience of your software. Typically there will be a script of the exact actions or the class of actions the manual tester is expected to cover. Some firms roll regression testing and new feature testing into the manual tester's role, others have a separate user-acceptance testing team who stand between released software and deployment.
The automation tester's role is to make the computer test the software, by building a framework around the program and its installed environment to check the system as-a-whole does the intended job. Some automation testers also write unit tests in the core program code; mostly this is left to the developers, who are increasingly being asked to show that their code works - and doesn't break the existing code - before check-in. Some places operate a Behavior-Driven Development (BDD) process where client needs are expressed in testable ways - so that the evidence that your software does what a client wants is written down clearly for the client to see, the tester to test and the developer to build. Some BDD systems even build tests which show that these goals are met, and are known as Test-Driven because the proof of rightness is shown by the tests.
Preparing for an telephone screening or interview about software test engineer, you will need to show that you're technically-minded, that you've worked engineered a test system before, that you understand the benefits and shortcomings of building such a system (such as knowing when to build tests and when to leave low-hanging test fruit to manual testers), and that you're concerned for the quality of the product more than for building a new toy test rig.
I disagree with nearly every point made above, but I know this as a tester: there are a lot of people who shuffle into testing because it's the gateway to working in software. That's no bad thing. But mix it with the lack of confidence to apply for and get developer roles, and you will probably harm your sanity and your career. In every job, you need to be competent and confident. On top of that, you need to be personable so, for example, you don't make bug reports critical of the developers who made them (and know how to calm down a dev who's got that idea).
To be a good tester is genuine hard work requiring the best of your technical insight, pedantry and commitment to high standards, but to be a great tester will call for charisma, kindness, honesty, good working relationships, and the skills to help make a dysfunctional team work right.
If you're only a tester for a short while and move on to a developer role, you can either blame the economy for not having enough dev jobs (so you compromised in order to fulfill your passion for making software), or you can say that you wanted to improve your developer skills by learning what it's like to be on the other side of the fence as a tester. It's not a black mark if working as a tester makes it a benefit to you and a prospective employer.
Content too? I think that you could easily co-opt this by supplying a farm of content-producing people for Y-Combinator to invest in, making them subject to the same market forces -- or putting them in the same boat -- that the movie studios and record companies are.
The fix requires more and better entertainment, more and better news reporting, more better-aware citizens and more and better political engagement. Make reading up on news get you points in some kind of alternate-reality game (ARG), discussing news and being politically active gets you points, too. Perhaps points to make your shopping or recreation cheaper (but there's probably other incentives).
You like your OLED display? That's inkjet-printed. I figure that Cambridge University has tamed the Inkjet -- the OLED was discovered there, too.
Can I ask someone in the US to get the Feds on to this? News International's staff are alleged to have bribed UK Police, which is a federal crime under your Foreign Corrupt Practices Act. Please get it investigated, and get New International prosecuted for perverting justice.
Linux IMA at LWN: https://lwn.net/Articles/227937/, https://lwn.net/Articles/326747/
IBM (involved in Trusted Computing Group) link: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html
Bullet-point summary of EVM:
EVM Mailing-list announce: https://lwn.net/Articles/393673/
We would definitely herald 2012 as the Year Of Linux On The Desktop if we had a UI which used a 20-dimensional hypercube. Redmond's Photocopiers couldn't keep up with that kind of innovation!
Can I bring my laptop to you and you install a hypervisor and partition it up with some virtual machines so I have one partition for your work environment and one for my stuff? You can pick the hypervisor...
Nice dream, but this can never be a win because, soon as I have access to the hardware and run my instrumenting hypervisor, your disk encryption is compromised and any secrets you might want to keep -- and that's no matter how obscure the notion of a secret: logins, handshakes, keyfiles, and onward to company confidential or technical know-how -- those secrets are now theirs to leak.
They're racking their brains as to what to do next.
I would aim for kernel threads running directly through CUDA and the Scheduler knowing the performance profile of suitable work for the GPU and the message-passing cost of moving work to the GPU^H^H^H parallelism co-processor. Make the interface right and you should be able to shift tasks across heterogeneous processing units. Do it perfectly and you can have a Linux Virtual Processor model which allows you to start running a task on your desktop, shuffle it to a laptop for transit, pare it down to use on your mobile phone, buy some CPU time from an internet cluster to grind through some calculations before transferring it home. Choose x86: there's already enough x86 junk in other trees, and it might fix up the ARM shenanigans too!
Expensify's got 7 people total in their huddle but they want more. They've trolled successfully to get your and my attention -- and got worldwide press for this. For a company at 7 seats, everyone has to pitch in at everything: 'not my job' and 'not my skillset' are unacceptable and only 'what can I do to help us get the win?' is the only thing that will get this company to success.
Maybe you didn't like the style and wouldn't work there. It reminded me that I enjoy being the sort of person who uses any skill and the best tool to do what I've chosen to get into. And it's good to know that there are other people out there who will celebrate and encourage that.
(But still, I've been trolled and this is a post in a troll thread.)
You aren't a mainstream Christian if you think that*. Penal Atonement is a minority view of what the Cross does for mankind's relationship with God. It makes sense to a human but it can't be the true explanation because it requires God to make humanity susceptible to fail God's rules, then have God step in and sacrifice God to God to break those rules and 'satisfy' God of something when most of it is breaking God's rules.
Any idea how unfair it seems of God has to hold you or me to God's rules? Or that we must 'adore' or 'worship' such a deity in such a setup?
*: Penal atonement, that Jesus on the cross is a sacrifice which satisfies God's need to have someone pay for the sins of the world.
Perhaps we need to add steganographic noise to the other elements on your photo-sharing sites, just so that your messages don't stick out like a sore thumb.
That was added after (in response to?) my comment post. The mods can do that, and thumbs up to them for improving this content-free front-page post.
This is a really terrible review. You could have said that Business Process Management (BPM) and Business Process Execution Language (BPEL) are important to know for this book. Or it's so esoteric that, if you need to know what BPM is, you already know BPM.
I think it just sums up the situation succinctly:
"Nokia got trapped by that win32.elop.trojan."
Actually, the word in the botnet IRC channels is that it's a dotNETclr.elop.trojan.
I don't know if there are domain experts or a client-base whose desires a traditional engineering effort can be aimed at. So the internal crowd get to be the client-base and to provide feature requests or feature enhancements themselves.
I can't work out if that's a good thing. Perhaps they'll be doomed like Sun to have a closed culture (as Valerie Aurora pointed out http://blog.valerieaurora.org/2010/02/13/sleeping-with-the-enemy/) which will only scratch the itches that people within Facebook need for Facebook. On the other hand, they've built a substantial internal culture which mimics a successful free software culture.