Tag archive for: fail

I’ll tell you a secret. I am a huge Perl fan. Always was, ever since I started my developer career in the early 90s. And even though I have programmed in, probably, dozen of other languages since then and Perl has, in all fairness, become the COBOL of the 21st century – it still holds a dear place in my heart. Frankly, not only I’d still lean to Perl for most quick and dirty projects, but I also maintain and somewhat actively develop perhaps some of the most trafficked existing Perl-based web systems. That is one of the reasons I was excited to speak at The Perl Conference (YAPC::NA), meet with esteemed members of Perl community and discuss the future of Perl (and especially Perl 6). And frankly, the future looks grim.Continue reading Perl is $schrödinger_state

I gave an Ignite talk at DevOpsDays DC in Washington D.C based on my rant. In this talk I covered some of the most frequently seen and heard fallacies and misuses of the term “DevOps”.

DevOps has been a hot topic in the industry for some time now. A lot of people been talking about it. Some have built business models around DevOps-related tools and themes. There are even conferences and trade shows dedicated to DevOps-oriented things. People have made career around talking about it. In light of all of that, I find it chuckle-worthy that very few people actually know what DevOps is. So instead of trying to create a buzzword-infested definition of DevOps to suit my particular agenda, I’d like to talk about what DevOps is not.

As the holiday rush is winding down, I sit here reflecting on all the companies that lost business/revenue over the past few days. Loss of business not because of technology failure, although this is always a manifestation of a problem, but because of process failure in order to remedy the failures of technology. I’ve offered some tips on preparing for the holiday traffic from the system architecture perspective, but perhaps I should’ve concentrated on preparing for the rush from the organizational perspective.Continue reading Reflecting on holidays

Everything happens for a reason. Sometimes that reason is you’re stupid and make bad choices.

A few months ago I attended Node Summit in San Francisco, dedicated to success stories around node.js implementations in large architectures. There were a couple of very educational war stories (particularly, the so-called, “boring” Walmart Black Friday case study, presented by Eran Hammer), but, this rant is not going to be about how awesome node.js is. This rant is going to be about bad decisions. Those that are still being made in the world of technology, driven by false premises, wrong reasons and buzzword bingo.

Every developer blames his or her predecessor. Whenever we get to work on, or maintain, a codebase that was developed by someone else, the first impression is always a negative one. Along with second, third, forth…up to nth. Someone else’s code is always worse than what we would’ve developed, given the opportunity. The design is wrong. The code is messy. There is insufficient documentation. The problem could’ve been solved in a more efficient way. Variable names too short. Variable names too long. Truth of the matter is – even when we look at our own code years later (and sometimes much sooner) we criticize it in exactly the same fashion. But after years of dealing with unrealistic deadlines, last minute changes in requirements, and “visionaries”, who cannot explain what they want, yet want it to work exactly the way they envision it, I’ve learned to make a distinction between “necessary evil” and complete incompetence.Continue reading How to make enemies

At $work we specialize in performance audits on systems of every size, from start-up sites hacked together overnight, to a ginormous applications built by world-recognized brand companies. I’ve seen a lot of interesting (and sometimes very unique) performance issues in every level of the stack: code (front-end and back-end), architecture, databases, (sometimes all of the above), but there is one particular, very “Performance 101”, issue that I see all the time. And frankly – it bugs the hell out of me. In fact, the problem is so common sense that writing about it seems a little embarrassing, yet the frequency of seeing the same issue is proving otherwise.Continue reading One query show

Recently I realized that I don’t hate PHP, as I thought for many years, I just hate people who code in PHP. And before lynch mob starts knocking on my door, let me elaborate.

PHP requires minimal learning curve to get in and whip together a small website (props where it’s due). Unfortunately, the ease-of-use has one major flaw that is a root cause of my frustration. Way too many people, who shouldn’t be allowed to use the computer for any other purpose than to play solitaire, start coding in PHP. Without any previous exposure to programming. Without any knowledge of basic theory. Without a clue. And they like it. And what’s worst of all, they often succeed in their first endeavor. And they crave for more.Continue reading global $issues