So traditional Sheet Music and hence, notation is akin to C or Perl's verbose and/or messy syntax...the problem is, it's not just about the Notes with Music: there's a lot more in terms of dynamics and the like going on which notation has evolved over thousands of years to support.
Interesting read though. For something not so 'serious' (e.g. not a Concert piece), it could definitely make the correlation easier.
Re: '...Rather than do all this work with Puppet, Chef, or even Ansible, I can just declare what the systems ought to be and cluster them within code branches...'
It sounds like the poster is doing something similar to a 'Gold System Image' though with Container technologies.
Configuration Management is great, but I'm with the view that you should start with a combination of gold images/system builds and then stack on Cfg Mgmt on top of that.
Theory is you will have a known base and identical builds etc, otherwise you would get subtle drift in your configurations, especially for things which are not explicitly under control of Config Mgmt (shared library versions, packages).
Of course, this is not always feasible but if I were to start from scratch, I would probably try to do it this way.
You want to have your "Gold system image" available and this is most certainly what you should be deploying from; however your configuration management - whether it's Chef, Puppet, whatever - should be able to take a base operating system and get it setup completely from scratch.
This then solves the problem of ensure that you can completely reproduce your application from scratch; but also removes the possibly horrendous slow scale up time by using a "Gold image" that has already done this.
My current process is: Jenkins runs puppet/chef, verifies that the application is healthy after the run and everything is happy, calls AWS and images the machine, then it iterates over all instances in my load balancer 33% at a time and replaces them with the new image resulting in zero-downtime. Of course another solution is to pull out those instances and apply the update, and then put them back in.
And I'm sure someone else will have their $0.02 on their own process, which actually I'd love to hear :-)
Here's mine, with the preface that we're still iterating our deployment procedure as things are quite early.
I have an Ansible repo with an init task, which configures new boxen (makes sure proper files, dependencies etc. exist). Then to deploy, I have another task that ships a Dockerfile to the target boxen group (dev, staging, or prod) and has them build the new image, then restart. This happens more-or-less in lockstep across the whole group, and scaling up is relatively easy - just provision more boxen from AWS and add the IPs to the Ansible inventory file. Config is loaded from a secrets server, each deploy uses a unique lease token that's good for 5 minutes and exactly one use.
I'd love to hear how to improve this process, since I'm dev before ops. My next TODO is to move Docker image building locally and deploy the resulting tarball instead (though that complicates the interaction with the secrets server).
I've personally seen other 'tactics' used, most notably a former company's CFO told my Manager that I was being paid 20k more in Salary than I actually was.
This 20k was then subtracted from the IT Budget presumably on a yearly basis. Any other stories from readers?
I wear earplugs on a regular basis and they are great for drowning out excessive noise. I do remove them off and on, especially if I'm in a meeting with someone or if I have to hop on a call.
If I don't wear them, I tend to get distracted and irritated by various sounds. Now, you can still hear things, but they are dampened which is soothing for me at least.
Agree with Johnythree. I used to be an electronics technician over 12 years ago. What happened is that it became cheaper to replace a board than to pay a skilled technician to debug components on a board.
You also had to pretty much learn whatever setup a company's products had on the job, as typically this was proprietary information.
There are great boards/kits out today but yes, it's mostly a hobbyist thing unless you decide to go embedded, then boards such as the MSP-430 from Texas Instruments can be a good choice (especially in the Medical Devices field).
Another explanation could be attributed to the food supply: in America, the lower standard of living you have, the more likely you consume a nutritionally poor diet and consume water from the tap which in some areas has been shown to contain trace amounts of medications, spores, lead, fluoride, etc. In other words, medical conditioning.
This is great news for Administrators and IT Staff as in the Enterprise, Microsoft is still very relevant and this will only ease Management.
I am of course referring to the still existent non-startup style companies which might have non-technical users/staff such as Project Managers or Business Analysts etc. In my experience, once a company gets past 50 users or so, Windows is still the way to go.
Sincerely hope they will donate to the OpenSSH project to support its ongoing development going forward and not just mooch off it as many other companies do.
Linux is increasingly become more 'appliance-like' and I think the steps taken here are actually positive. Too many shops flat-out ignore the OS compoment of the stack. This will at least force integrators to think about the OS more.
For what it's worth, this is just SmartOS re-implemented in Linux (though lacking certain features of SmartOS), and funded by Google with apparently more flexibility on where you can run this.
I personally cannot wait for the day when I am able to treat Linux like a dumb appliance everywhere, running atop more purpose-built systems.
I think the PostgreSQL Development Group does a great job overall. If they indeed have a reputation of being hard to work with, all the better in my opinion if it means guarding the integrity of the Project.
> if it means guarding the integrity of the Project
That's a big "if." There are many projects that have been controlled by "hard to work with" developers, and it's not always a good thing. Even if the project doesn't suffer significantly from it, that doesn't mean it's helping the project either.
That may not be the case here, but just as a general statement, you can't chalk up "hard to work with" as equating to "focused on quality" and/or "good for the project."
It's open source with a very liberal license. If someone is too difficult to work with, the rest will just fork and move on with life. Do you think the fact that people stick around, and have a respectful discussions means that the guys are not too hard to work with, and the values they provide outweigh the challenges of working with them?
Interesting read though. For something not so 'serious' (e.g. not a Concert piece), it could definitely make the correlation easier.