It's that time again! I've been gathering links from far and wide (translation: twitter and my collection of RSS feeds), and I've chosen a few interesting ones to show you.
It's that time again! I've been gathering links from far and wide (translation: twitter and my collection of RSS feeds), and I've chosen a few interesting ones to show you.
Recently, I read an article called Making Virtual Teams Work: Ten Basic Principles. It was all about ways to improve team communication, but the 7th Principle gave me an idea for marketing my wtBoard project.
You've probably heard people talk about "legacy code". They're usually referring to systems that are no longer supported or updated. However, there are other types of legacy code out there. Code that was written years ago, but still runs your company's products every day. Often an unruly mess of hacks justified by shifting business requirements and the airy whims of management, it's your job to keep it maintained and working.
Since people seem to think it's easy to just go in and presto-change-o add a feature, I'd just like to point out a few things that complicate that process. These three threats conspire to make the Total Cost of Ownership of a codebase hard to predict, and they are why you should use best practices at all times to ensure that you aren't willfully strapping yourself into a straitjacket in the name of short-term savings.
Here are a few interesting articles I've come across lately:
Engelbart invented many of the concepts we take for granted today. While we may have transitioned away from one of his inventions, the computer mouse, we still heavily use many other concepts that he pioneered. You should also read this article about some of the hardships he faced later in his career.
And of course, you should watch "The Mother Of All Tech Demos" and be amazed at what he had accomplished in 1968.
This is a walkthrough of an advanced technique that Etsy uses to separate their opcode caches & enable deployment with no downtime. Essentially, they resolve the symbolic link to the current deployment prior to loading PHP, so when the opcode cache writes out its supporting information, it points to a physical disk location. Then, they can swap the symbolic link at any time without having to restart the web server or worry about cache issues resulting from the same HTTP request accessing old and new files at the same time.
This is an intro to Vagrant as written by the architect of PuPHPet (which I recently wrote a quick walkthrough for). The article is quite in-depth on topics such as the vagrantfile, Puppet integration, and of course PuPHPet.
Well, that's all for tonight. Thanks for checking in! :)