The iota enumerator in Golang is elegant and unique. Writing idiomatic Golang code is so implicit in the language itself that I've been able to easily read almost any Go code I find.
Slashdot videos: Now with more Slashdot!
If you're building services that still require "regular maintenance windows" in 2014, you're doing it wrong.
This is a really nice sentiment but is in fact somewhat disconnected from reality.
In the web world, building zero downtime services that don't require maintenance is doable. In many enterprise IT environments with legacy or bloated software (hospitals, education, government) it's a non-starter. The staff do not have the skill, the applications don't have the support, and the political will within the organization is not there. Database migrations alone can be a major source of downtime, and that's largely true even for web services.
Puppet is a great tool for automation but does not solve problems like patching and rebooting systems without downtime.
Yup. Very dependent on the business, the application, the usage patterns, etc.
The right answer to this is to have redundant systems so you can do the work during the day without impacting business operations.
Many of the newer phones from T-Mobile (the US version, anyway) are configured out of the box to use native IPv6. A third of their data traffic is now terminating on IPv6. They're using NAT64 for reaching hosts that don't have a native IPv6 address.
IPv6 rollout is happening, just not in the places some of us are looking.
Yep, pretty much this. For me it was a bit later - 1980 - but we had a C64 in the house and my Dad was in a club that talked about them. He showed me some simple BASIC and set me on the track at an early age.
You're referencing a character who first appeared on the Simpsons in the 90s... before SAP software as a class even existed.
What? ERP systems have been around since the 70s... SAP released R/2 in '79. If you're talking about R/3 (when they introduced server-client architecture), it was released in 1992.
Today, you usually know who's calling before you answer. It may be appropriate to take a call if it's more important than the meeting. If you're in sales, a call from a major customer is probably more important than a meeting.
Sure, but not in the meeting. Excuse yourself, and explain it's an extremely important customer call that absolutely cannot wait.
And even if this is the case, you're still being rude... just with an excuse. The call may be more important to you, but the other people in the meeting? You're wasting their time.
If you've blocked out time for a meeting, don't take calls during that time. It's rude and unprofessional.
Note: This is for orgs that have effective meetings. If your meetings are generally unproductive, it may be a different story...
Come up with a few simple programming projects that students can run through. There's something magical about writing code and seeing the computer execute exactly what you told it to do. Write a Ruby Sinatra or Python Flask app and show how to access it from the command line. This will teach them what a web server is and how to write simple code at the same time.
Sure they are, but that doesn't stop 90% of people from filing on time, or at least filing for the automatic extension. For that matter, nearly every church in the country manages to do the same.
Actually, churches are an exception. Churches that have been granted 501(c)3 status as a church under 170(b)(1)(A)(i) are not required to file information returns with the IRS. They get special treatment.
Taking a two-decade-old trend is not cherry-picking.
It can be cherrypicking when there are cyclical trends whose period is longer than 20 years.
It was a feeble attempt at a joke, playing on the multiple meanings of "pass". I guess it wasn't obvious enough.