Yup, I am (said by others) very good at architecture and the big picture, while I have never been great at details.
Some of the details oriented work is actually just habit, I can spot tiny issues in Ruby, but I need a diff to figure out Go code. Tools help a lot too.
I have a more general question for you: I am a senior developer who is starting to figure out devops because I need to deploy two different products we built. I have limited Chef and Ansible experience and pretty good Unix skills.
Should I start out with Docker or am I missing some crucial pieces I should go through first?
The use case is "media processing services" in one case, and a sports betting game in the other.
We Italians come up with unorthodox solutions all the time, because we grew up in an environment that only rewards two things: low profile, or being creative. And creativity is far more interesting.
My opinion is that the US should have "won" any kind of war they had in mind with the Arab world by putting the trillions spent on Iraq and Afghanistan into energy research.
That would have been far more damaging to their targets and immensely beneficial to the world at large.
I work in the telephony field, and Erlang comes up every other sentence. I have limited experience with that, but Elixir in my opinion makes it far easier to jump in.
I sort of agree with the common argument about OTP needing a rename, but in the end if a developer can't get past a name, he can't get past a lot of other things either.
This is more of an history lesson than anything else.
It just used to be that way, back when machines were slower and there was an actual cost involved in wasting cycles.
Of course I wonder which path you went through, it is the point of this discussion, and for all the rampant no-holds-barred religion bashing HN usually sees, this is still an above-average forum for this kind of discussion.
I would really like to hear about that, with the only rule that neither of us should try and convince anyone else, and all we say is to be taken strictly personally.
I will start by saying that I actually went through the realization that I had no evidence or need for the supernatural about 1 year ago, at 35 and counting, after reading The God Delusion and then starting my own research path across philosophy, theology and science. I feel like I have reached a conclusion, albeit just a personal one.
I have gone the exact opposite path, from a life pretty entrenched in Christianity, to skepticism, to a conclusion that led me towards hard atheism.
I feel like I am sure there is no supernatural creator, and the only love we receive is from people. I now thank people for their good, not God, and get angry at them for their bad, not at Satan.
Religion starts off by lifting your responsibilities, and that is the worst part in my opinion.
That said, it has improved my outlook on death too. I think there is no point worrying about an inevitable event that has no consequences other than the disappearance of a, maybe loved, person.
No one knows what you feel, and no one ever has come back from it. That makes death pretty unconsequential, as there is NOTHING you can do about it.
We are a pretty small team, and aside from one person most of us double as ops at some point. Not trying to generalize at all, but at our scale, it is far more productive to go to something GIL-less and possibly as self-managing as possible, such as BEAM VM languages.
Incidentally, Erlang/Elixir describe applications as a collection of "in process processes", essentially allowing you to reason much like you were doing single threaded processes but without the real system implications.
What I see as the most important thing here is that developers have a better pulse on resource needs of their own software, since we do a lot of load testing before pushing anything to production, and the ops team can take our baseline data and handle applications almost as a black box.
On the other hand, Docker essentially makes all my points nul by itself, so there is room for all approaches.
Based on our experience running large telephony applications, I would say that the threading approach, using JRuby as it provides a stable GIL-free interpreter, is vastly superior both in resource handling and developer/sysadmin productivity, also known as "less headaches".
I understand the importance of Rails in the Ruby ecosystem, but at the same time, I would really like it not being the only measure of Ruby's performance.
That is not necessarily an advantage, considering the same semi-technical people leave their websites available for any kind of security breach.
This is not 2001 any more, people should know what they are doing.
I left PHP about 3 years ago, and I have recently had to look into it again due to a new course I am preparing to teach.
The PHP I knew is no more, and it is leaps and bounds ahead of what it used to be.
But using Drupal as an example is really a bad choice.
Talk about Laravel, Composer, new language features, but not crappy giant codebases.