I think you are jumping to conclusions about me. This is not about me.
You are right that it is not just about process. Process is part of it. The largest issue, IME, is knowledge: do people know about VMs? Containers? ATDD? DevOps? etc. - at all levels, from the developers through the various managers who set the rules (and therefore can change the rules).
One thing that I have found is that if you give developers Windows machines, they learn that - they don't learn about Linux. That's fine if the org deploys on Windows, but if it deploys on Linux, it is nice if the devs know about Linux; and if you want them to know about Linux, the best way to achieve that is to have them live in Linux most of the time.
There are always exceptions: people who will learn all of the envs. That's why I don't believe in forcing people to use one env over another. Most of my work is in large organizations where one has to think about the range of skills and personalities.
PS - Don't assume that because I am an Agile transformation coach that I am not technical - I am (I code).
Yes, and there is also the issue that if a test fails in a downstream production-like env, it is nice if the developers are familiar with that env so that they can diagnose the problem. If they work in Windows and the downstream test failure is in a Linux env, then the devs need to be comfortable in both Win and Linux. Did you have experiences with that situation?
Sorry you had that experience. In the organization I am working with, I have spearheaded the introduction of ATDD and the use of docker containers on laptops. To do that, I had to have lots of conversations with various stakeholders in the bureaucracy, to explain why we were doing things differently. IMO, a good Agile transformation coach needs to (1) know the technology, and (2) be able to explain it to managers who don't know it.
Indeed. One thought: it is nice if your native OS can run containers natively. Regarding Macbooks, everyone has their own reasons, but my personal reason is hardware quality: the hard aluminum case, the keys, the slimness. There are downsides of course - can't easily replace the battery, lack of ports on new ones. It is a tradeoff. I carry mine everywhere, so physical durability and lightness are important to me. But using OSX/MacOS means that to run true Linux containers, I have to run a VM. In practice, I do most of my own dev in AWS anyway, so it is not an issue.
Why run Windows in the first place? I am an Agile transformation coach, and I work in large organizations, and I always wonder, Why, if they are deploying on RHEL, are their developers writing code on Windows laptops? The problems that result are endless. And the solution is simple: either (1) run real Linux in an VM; or (2) run Linux natively. #1 will satisfy enterprise access to email, etc. The solutions are already here. Trying to cram Linux into the Windows kernel seems bizarre to me. What do others think?
Yes, although regarding "hotties", things have changed since I was in school. When I was a physics student at Cornell in the '70s, there were two women in my year in the department. Two. Across all colleges on campus, the ratio of men to women was about 70/30. Today I think it is about 45/55. Young college men today have it made, in that respect.
Yes, very true. The really hard things tend to require deep knowledge - not lots of shallow knowledge. I expect the most of the people who design rockets for Elon Musk at SpaceX have PhDs in aerospace engineering.
So there are more entrepreneurs, creating more IOT gizmos and more Googles and more plastic that ends up in landfills, pushing us faster towards the Singularity. Is that being a successful person? A successful society? I didn't go to college and grad school to get a job or create a network: I went to become educated. I learned things that I could not have learned on my own because formal education provides rigor and a support structure that forces you to continue through it. Today, at 60, my biggest regret is that I did not finish my PhD and I am thinking about going back to school to study what I love - physics. Besides family, knowledge is all that has meaning to me at this point.
It is very simple. If software providers were at least partially liable for damages caused by security breaches, the situation would rapidly change: we would see companies hiring programmers with "security training", etc., and programmers would start caring about software security - because that would be where the jobs are. The total lack of liability today is the core problem.
Until they have transponders, they are a menace to sport aircraft, which often fly at low altitude when landing or taking off from a field, for amphibian aircraft, a lake. Given that striking a drone will usually destroy an airplane and kill the passengers, it seems reckless that they can be allowed over public land above 100 ft. They have been declared to be aircraft: they should have transponders.
Just because wikileaks helps to expose illegal government activity does not mean that it is "aligned" with Russian interests. Perhaps we should focus on the activities that have been exposed, instead of focusing on the whistleblower and the whistleblower's tools.
It's kind of like, on the eve of the car, the government sponsoring camps for learning how to use the buggy whip. Here's how you know for _sure_ that coding's days are numbered: government officials are saying that everyone should learn how to do it.
Most definitely. Metadata is highly sensitive. Indeed, who you talk to is information in its own right - imagine an oppressive regime collecting a list of who the regime's opponents associate with: that list can be used to round up those who are opposed to the regime.
A warrant is supposed to provide independent (non-executive) oversight. No warrant - no data. That was the theory. Warrants exist to prevent abuse by the executive government, which would eventually tend to use unchecked surveillance powers to protect itself and to stay in power.
Indeed! Although to be honest, as a fairly loyal Mac user, I have not found Apple's software to be any more reliable than MS. The software is FAR, FAR more usable and intuitive. My iPhone sometimes has to be restarted (about once a week - I can't swipe, but restarting fixes it). The iTunes app is a horrible mess (unlike most Apple software, its usability is very poor, due to inconsistency in various parts of the app). The original Apple TV (version 1) was so bug-ridden that I actually started keeping a list of all of the things that went wrong - most had to do with race conditions. And the Mac's Mail program often crashes (say, once per week). Not a big deal. I think the problem is that application software is not very reliable in general - it is too expensive to make it reliable. But do we want to run our cars on that? I want my car's software to be rock solid, because when software fails, it fails completely (i.e., hangs). Most analog/physical systems in a car give some kind of warning and fail gracefully (not all). But in my Saab, sometimes the _entire_ dashboard will go dark unexpectedly, and the next day it works again. That's a Saab, but I have heard that Jeep's might have that problem, and it sounds to me (thought I don't know) like software bugs.
You must reboot your car to install updates. Click here to automatically pull over and do it now, or here to do it tonight. Sorry that you are driving and in the middle of something while I am pestering you with this. - Your car. PS - Last night, you were hacked.
"limited experience with a tool-poor scripting language..." - which are you referring to, Ruby? If so, Ruby is not tool-poor.
"...but in return, a lot of problems become quite a bit easier to solve." - Yes, I agree with you. Perhaps our disagreement is our perspective: I advise organizations, and so I tend to be on the side of maintainability - and that requires languages and tools that are naturally maintainable - not ones that require great effort to craft maintainability. I think that you advocate for the developer - and particularly the advanced developer. Yes, I agree that scripting languages enable you to code more quickly, although I have found the refactoring can introduce lots of bugs with scripting languages, unless you have a very high coverage unit test suite, which I try to avoid, and compilers help me to avoid that - saving me a huge amount of effort, and instead allowing me to focus on behavioral tests which are far more stable when one refactors.
I will note that I have seen very, very expert developers create mountains of unmaintainable code very rapidly, and not even know that their code was unmaintainable.
Aha. Now I know where the disconnect is in our discussion on this. I have been thinking in terms of updates, and you have been (it sounds like) been thinking in terms of fetching data. Yes, for fetching data, you are right, asynchronous is far more efficient, if one can get away with a best effort (eventual consistency) approach, which is usually the case for UIs.
For transactions that do updates, a synchronous approach is far easier to implement, because one does not have to keep track of application state, because (1) one handles failures immediately, and (2) the transaction is atomic (if it is not, then you have to manage state at the application level). E.g., consider a user who reserves an airline seat, but between the time the user received notice of the available seats, the selected seat is given away. The user does not now the seat was given away (and their UI has not refreshed yet), so they click Submit to reserve the seat. In a synchronous approach, the Submit will fair right then, and so their UI will immediately receive a failure response and can update it self accordingly. But in an async approach, the user will receive a success response, and might even close their browser before a failure message is received. Thus, the application then has to have additional logic to record that the user was not notified of the transaction failure, and will likely have to email the user to let them know that their seat reservation failed. Much more complicated.
I.e., message oriented is simpler for getting data, but synchronous is simpler for updates. Do you agree?
Go and C++ are so different, and C++'s type safety might be stricter, but the type safety of Go is pretty strict. Nuances aside, thus practically speaking, I have found that languages like Ruby lead to very unmaintainable code. That was my point. Dynamic type features (which Go has to some extent) don't change that, because one uses those to add dynamic features to one's application, such as adding a new component a runtime, or dispatching to a method based on dynamic information such as a command that has been input. Dynamic type features are not usually used throughout a program, but rather only in special circumstances. But I have found that Ruby's lack of type checking can lead to very fragile code when one refactors.
"The asynchronous approach is much, much more complex to implement on top of an RPC system." - can you please give an example? I have implemented message based programs - and you are right, that it is a programming construct independent of the network - but IME message based applications are very complex to design: one must identify all of the states. But I am willing to learn! Thanks!
Yes, C++ is probably not for most programmers. To use it well, you have to spend a-lot of time with it, and do a-lot of reflection (reflection in the sense of mentally thinking about it). And you are probably right about Google not changing its attitude on dynamic versus static. But doesn't that say something? They have to handle very large things - they have had to from the beginning. The fact that they stay away from dynamic languages - what does that say? I guess you can tell that I am not a fan of dynamic languages. I started my career writing compilers and so I feel strongly about the benefits of static analysis. I have spent a-lot of time writing vagrant and chef scripts (not anymore - vagrant and chef are obsoleted by docker and orchestration), and I remember the pain of that process - wishing that there were a statically compiled alternative, so that I did not have to run the scripts, wait for the VMs to boot, and then get through all the provisioning just to find that there is a syntax error somewhere in my Ruby. Another experience: I wrote a large application (a performance testing tool) in Ruby, over a period of about six months. I then ported it to Java, and in the process I discovered countless issues that could potentially be problems down the road - issues that I only discovered because the Java compiler found them - things that would have required a comprehensive unit test suite for the Ruby version to find them. A third experience: Over the last year I have been working mostly in Go, and while I don't like Go _at all_ it has some things going for it: one if them is that it is pretty strongly typed, and I have found that I can do massive refactoring of the Go codebase and introduce _zero_ new errors as a result - try that with a dynamic language!
"Not that I know of. And what would be the point? That would amount to a REST call with metadata attached in PB format, which is kind of like a bicycle for fish." - that would indeed be ridiculous, but I would expect the attached binary content to be unencoded, as it is in an HTTP binary encoded part. There is a major use case for that: queries that send binary data. E.g., I have been using the docker engine and docker registry REST APIs, and many of the methods include both query parameters and binary object parts (i.e., attached files) in the same request or response. I think we need to look at the gRPC specs to see if it handles this case.
"Asynchronous message passing refers to a style of programming similar to (but different from) OOP. It really has nothing to do with UDP other than a superficial similarity." - I disagree. The debate between synchronous calls and messaging is as old as the Internet. You are right that these do indeed distinguish different programming paradigms: in synchronous calls one handles the response inline, whereas an asynchronous approach requires and event-oriented design with compensating transactions at the application level. The asynchronous approach is much, much more complex for the programmer to implement, because of the large number of states that must all be handled, but it is warranted when requests have lots of latency or when there are lots of clients compared to the number of servers - so many that it would be difficult to maintain that many stateful connections. With an elastic back end, however, the latter concern goes away.
Slashdot Mirror
I think you are jumping to conclusions about me. This is not about me.
You are right that it is not just about process. Process is part of it. The largest issue, IME, is knowledge: do people know about VMs? Containers? ATDD? DevOps? etc. - at all levels, from the developers through the various managers who set the rules (and therefore can change the rules).
One thing that I have found is that if you give developers Windows machines, they learn that - they don't learn about Linux. That's fine if the org deploys on Windows, but if it deploys on Linux, it is nice if the devs know about Linux; and if you want them to know about Linux, the best way to achieve that is to have them live in Linux most of the time.
There are always exceptions: people who will learn all of the envs. That's why I don't believe in forcing people to use one env over another. Most of my work is in large organizations where one has to think about the range of skills and personalities.
PS - Don't assume that because I am an Agile transformation coach that I am not technical - I am (I code).
Yes, and there is also the issue that if a test fails in a downstream production-like env, it is nice if the developers are familiar with that env so that they can diagnose the problem. If they work in Windows and the downstream test failure is in a Linux env, then the devs need to be comfortable in both Win and Linux. Did you have experiences with that situation?
Sorry you had that experience. In the organization I am working with, I have spearheaded the introduction of ATDD and the use of docker containers on laptops. To do that, I had to have lots of conversations with various stakeholders in the bureaucracy, to explain why we were doing things differently. IMO, a good Agile transformation coach needs to (1) know the technology, and (2) be able to explain it to managers who don't know it.
Indeed. One thought: it is nice if your native OS can run containers natively. Regarding Macbooks, everyone has their own reasons, but my personal reason is hardware quality: the hard aluminum case, the keys, the slimness. There are downsides of course - can't easily replace the battery, lack of ports on new ones. It is a tradeoff. I carry mine everywhere, so physical durability and lightness are important to me. But using OSX/MacOS means that to run true Linux containers, I have to run a VM. In practice, I do most of my own dev in AWS anyway, so it is not an issue.
Why run Windows in the first place? I am an Agile transformation coach, and I work in large organizations, and I always wonder, Why, if they are deploying on RHEL, are their developers writing code on Windows laptops? The problems that result are endless. And the solution is simple: either (1) run real Linux in an VM; or (2) run Linux natively. #1 will satisfy enterprise access to email, etc. The solutions are already here. Trying to cram Linux into the Windows kernel seems bizarre to me. What do others think?
Yes, although regarding "hotties", things have changed since I was in school. When I was a physics student at Cornell in the '70s, there were two women in my year in the department. Two. Across all colleges on campus, the ratio of men to women was about 70/30. Today I think it is about 45/55. Young college men today have it made, in that respect.
Yes, very true. The really hard things tend to require deep knowledge - not lots of shallow knowledge. I expect the most of the people who design rockets for Elon Musk at SpaceX have PhDs in aerospace engineering.
So there are more entrepreneurs, creating more IOT gizmos and more Googles and more plastic that ends up in landfills, pushing us faster towards the Singularity. Is that being a successful person? A successful society? I didn't go to college and grad school to get a job or create a network: I went to become educated. I learned things that I could not have learned on my own because formal education provides rigor and a support structure that forces you to continue through it. Today, at 60, my biggest regret is that I did not finish my PhD and I am thinking about going back to school to study what I love - physics. Besides family, knowledge is all that has meaning to me at this point.
It is very simple. If software providers were at least partially liable for damages caused by security breaches, the situation would rapidly change: we would see companies hiring programmers with "security training", etc., and programmers would start caring about software security - because that would be where the jobs are. The total lack of liability today is the core problem.
Until they have transponders, they are a menace to sport aircraft, which often fly at low altitude when landing or taking off from a field, for amphibian aircraft, a lake. Given that striking a drone will usually destroy an airplane and kill the passengers, it seems reckless that they can be allowed over public land above 100 ft. They have been declared to be aircraft: they should have transponders.
It is also true that for centuries people did not go to the moon. And then, in 1969, they did.
History is not always a guide. In fact, due to technology, history never repeats - only human behavior patterns repeat.
What is different how is that it is very likely that AI will attain human level thinking ability within the next decade. And that _is_ a game changer.
Well said!
Just because wikileaks helps to expose illegal government activity does not mean that it is "aligned" with Russian interests. Perhaps we should focus on the activities that have been exposed, instead of focusing on the whistleblower and the whistleblower's tools.
It's kind of like, on the eve of the car, the government sponsoring camps for learning how to use the buggy whip. Here's how you know for _sure_ that coding's days are numbered: government officials are saying that everyone should learn how to do it.
Most definitely. Metadata is highly sensitive. Indeed, who you talk to is information in its own right - imagine an oppressive regime collecting a list of who the regime's opponents associate with: that list can be used to round up those who are opposed to the regime.
A warrant is supposed to provide independent (non-executive) oversight. No warrant - no data. That was the theory. Warrants exist to prevent abuse by the executive government, which would eventually tend to use unchecked surveillance powers to protect itself and to stay in power.
Yes, and by the way, one we (Apple) are allowed to fix or modify your car.
Indeed! Although to be honest, as a fairly loyal Mac user, I have not found Apple's software to be any more reliable than MS. The software is FAR, FAR more usable and intuitive. My iPhone sometimes has to be restarted (about once a week - I can't swipe, but restarting fixes it). The iTunes app is a horrible mess (unlike most Apple software, its usability is very poor, due to inconsistency in various parts of the app). The original Apple TV (version 1) was so bug-ridden that I actually started keeping a list of all of the things that went wrong - most had to do with race conditions. And the Mac's Mail program often crashes (say, once per week). Not a big deal. I think the problem is that application software is not very reliable in general - it is too expensive to make it reliable. But do we want to run our cars on that? I want my car's software to be rock solid, because when software fails, it fails completely (i.e., hangs). Most analog/physical systems in a car give some kind of warning and fail gracefully (not all). But in my Saab, sometimes the _entire_ dashboard will go dark unexpectedly, and the next day it works again. That's a Saab, but I have heard that Jeep's might have that problem, and it sounds to me (thought I don't know) like software bugs.
You must reboot your car to install updates. Click here to automatically pull over and do it now, or here to do it tonight. Sorry that you are driving and in the middle of something while I am pestering you with this. - Your car. PS - Last night, you were hacked.
"limited experience with a tool-poor scripting language..." - which are you referring to, Ruby? If so, Ruby is not tool-poor.
"...but in return, a lot of problems become quite a bit easier to solve." - Yes, I agree with you. Perhaps our disagreement is our perspective: I advise organizations, and so I tend to be on the side of maintainability - and that requires languages and tools that are naturally maintainable - not ones that require great effort to craft maintainability. I think that you advocate for the developer - and particularly the advanced developer. Yes, I agree that scripting languages enable you to code more quickly, although I have found the refactoring can introduce lots of bugs with scripting languages, unless you have a very high coverage unit test suite, which I try to avoid, and compilers help me to avoid that - saving me a huge amount of effort, and instead allowing me to focus on behavioral tests which are far more stable when one refactors.
I will note that I have seen very, very expert developers create mountains of unmaintainable code very rapidly, and not even know that their code was unmaintainable.
Aha. Now I know where the disconnect is in our discussion on this. I have been thinking in terms of updates, and you have been (it sounds like) been thinking in terms of fetching data. Yes, for fetching data, you are right, asynchronous is far more efficient, if one can get away with a best effort (eventual consistency) approach, which is usually the case for UIs.
For transactions that do updates, a synchronous approach is far easier to implement, because one does not have to keep track of application state, because (1) one handles failures immediately, and (2) the transaction is atomic (if it is not, then you have to manage state at the application level). E.g., consider a user who reserves an airline seat, but between the time the user received notice of the available seats, the selected seat is given away. The user does not now the seat was given away (and their UI has not refreshed yet), so they click Submit to reserve the seat. In a synchronous approach, the Submit will fair right then, and so their UI will immediately receive a failure response and can update it self accordingly. But in an async approach, the user will receive a success response, and might even close their browser before a failure message is received. Thus, the application then has to have additional logic to record that the user was not notified of the transaction failure, and will likely have to email the user to let them know that their seat reservation failed. Much more complicated.
I.e., message oriented is simpler for getting data, but synchronous is simpler for updates. Do you agree?
Go and C++ are so different, and C++'s type safety might be stricter, but the type safety of Go is pretty strict. Nuances aside, thus practically speaking, I have found that languages like Ruby lead to very unmaintainable code. That was my point. Dynamic type features (which Go has to some extent) don't change that, because one uses those to add dynamic features to one's application, such as adding a new component a runtime, or dispatching to a method based on dynamic information such as a command that has been input. Dynamic type features are not usually used throughout a program, but rather only in special circumstances. But I have found that Ruby's lack of type checking can lead to very fragile code when one refactors.
"The asynchronous approach is much, much more complex to implement on top of an RPC system." - can you please give an example? I have implemented message based programs - and you are right, that it is a programming construct independent of the network - but IME message based applications are very complex to design: one must identify all of the states. But I am willing to learn! Thanks!
Yes, C++ is probably not for most programmers. To use it well, you have to spend a-lot of time with it, and do a-lot of reflection (reflection in the sense of mentally thinking about it). And you are probably right about Google not changing its attitude on dynamic versus static. But doesn't that say something? They have to handle very large things - they have had to from the beginning. The fact that they stay away from dynamic languages - what does that say? I guess you can tell that I am not a fan of dynamic languages. I started my career writing compilers and so I feel strongly about the benefits of static analysis. I have spent a-lot of time writing vagrant and chef scripts (not anymore - vagrant and chef are obsoleted by docker and orchestration), and I remember the pain of that process - wishing that there were a statically compiled alternative, so that I did not have to run the scripts, wait for the VMs to boot, and then get through all the provisioning just to find that there is a syntax error somewhere in my Ruby. Another experience: I wrote a large application (a performance testing tool) in Ruby, over a period of about six months. I then ported it to Java, and in the process I discovered countless issues that could potentially be problems down the road - issues that I only discovered because the Java compiler found them - things that would have required a comprehensive unit test suite for the Ruby version to find them. A third experience: Over the last year I have been working mostly in Go, and while I don't like Go _at all_ it has some things going for it: one if them is that it is pretty strongly typed, and I have found that I can do massive refactoring of the Go codebase and introduce _zero_ new errors as a result - try that with a dynamic language!
"Not that I know of. And what would be the point? That would amount to a REST call with metadata attached in PB format, which is kind of like a bicycle for fish." - that would indeed be ridiculous, but I would expect the attached binary content to be unencoded, as it is in an HTTP binary encoded part. There is a major use case for that: queries that send binary data. E.g., I have been using the docker engine and docker registry REST APIs, and many of the methods include both query parameters and binary object parts (i.e., attached files) in the same request or response. I think we need to look at the gRPC specs to see if it handles this case.
"Asynchronous message passing refers to a style of programming similar to (but different from) OOP. It really has nothing to do with UDP other than a superficial similarity." - I disagree. The debate between synchronous calls and messaging is as old as the Internet. You are right that these do indeed distinguish different programming paradigms: in synchronous calls one handles the response inline, whereas an asynchronous approach requires and event-oriented design with compensating transactions at the application level. The asynchronous approach is much, much more complex for the programmer to implement, because of the large number of states that must all be handled, but it is warranted when requests have lots of latency or when there are lots of clients compared to the number of servers - so many that it would be difficult to maintain that many stateful connections. With an elastic back end, however, the latter concern goes away.