./databyte

In an earlier blog post entitled Heroku’s uptime numbers are off, Heroku claimed their uptime was 99.28% and I calculated it closer to 96.25%.

Status page a few days ago:

Now, they’re combining multiple months together to decrease the number.

Status page today:

The numbers are looking better and better eh?

Three questions:

1. Why are they listing July separate (which was a good month right?) and then the 3 previous months with July included again?
2. What happened to January through April?
3. Is this going to be a rolling previous three months? Or is next month going to drop May and June then list only July and August?

I wish their marketing department didn’t make these pages.

They should list percentages for the current month and the previous month with a link to a page listing all the months ever recorded.

Even better would be to mimic your parent company (Salesforce) or Amazon. The way they list history is much easier to digest.

Amazon:

Salesforce:

I recently bumped into someone who proclaimed PHP as the greatest language for web development and he had zero desire to learn another framework, especially not Ruby on Rails.

I, for one, couldn’t care less if you used Ruby or Rails, Python or Django, C# or ASP.NET. I do care that you would a) only stick with what you know and b) choose PHP.

For the former, it’s simple - you should assume you simply don’t know everything there is to know and continually try to better yourself. If you haven’t reached that conclusion yet, the book The Passionate Programmer will surely help.

For the latter, hmm, PHP eh?

I’ve done PHP development as recently as last year but to read into more of a PHP’ers point of view, I recently read a blog post named PHP is much better than what you think.

In it, the author, Fabien Potencier, sounds just like the person I mentioned earlier. The opening paragraphs calls PHP the easiest, most popular and quickest language. All great reasons to pick one language over another. So let’s break this down.

The Language

PHP is old but instead of a language that moves forward with its syntax, PHP chooses to build on top of the old cruft and never clears away the cobwebs. Its syntax coherence is below most other languages. A blog titled PHP: a fractal of bad design says it better than anyone else:

• PHP is full of surprises: mysql_real_escape_string, E_ALL
• PHP is inconsistent: strpos, str_rot13
• PHP requires boilerplate: error-checking around C API calls, ===
• PHP is flaky: ==, foreach ($foo as &$bar)
• PHP is opaque: no stack traces by default or for fatals, complex error reporting

Consistency is the key to discovering a new language, framework or API. One of the key arguments for PHP is that it’s easy. I don’t see how inconsistency is easy. From the same article:

• Underscore versus not: strpos/str_rot13, php_uname/phpversion, base64_encode/urlencode, gettype/get_class
• “to” versus 2: ascii2ebcdic, bin2hex, deg2rad, strtolower, strtotime
• Object+verb versus verb+object: base64_decode, str_shuffle, var_dump versus create_function, recode_string
• Argument order: array_filter($input, $callback) versus array_map($callback, $input), strpos($haystack, $needle) versus array_search($needle, $haystack)
• Prefix confusion: usleep versus microtime
• Case insensitive functions vary on where the i goes in the name.
• About half the array functions actually start with array_. The others do not.
• htmlentities and html_entity_decode are inverses of each other, with completely different naming conventions.

Seriously read through that entire article, it’s a great read.

The Ecosystem

The author mentions git but git is everywhere. Even Microsoft uses. it. now.

It’s great to see PHP has a dependency manager but so does everyone else. The fact that you have one and it works decently does not mean it’s better than another language or implementation. At this point, not having a dependency manager is a problem. All modern frameworks have them including RubyGems, Python PyPI, Node Package Manager (NPM), Microsoft NuGet, etc.

I’m not sure how the author judges that Composer is better than other package managers. Is it because it resolves dependencies or has over 2400 packages? I don’t know. The other managers do handle dependencies as well and the package counts as of today are:

• Composer at 2,454
• RubyGems at 42,278
• PyPI at 22,860
• NuGet at 7,792

Under the original article, the author calls this community collaboration but really he’s making a point about the number of packages available in PHP. Given the numbers, I expected a lot more from PHP given the number of sites online and the years its been in service.

The Community

To me, the community is not about sharing code but more about the people themselves. The developers make the community because they strive to make everything better. They don’t sit in their own echo chambers and pat each other on the back, talking about how great this is about their preferred language or that is about their favorite framework. They see the shortcomings and they strive to address them while acknowledging their strengths and weaknesses.

The main issue I see with PHP but also with some other communities is the lack of sharing. Not just code but technical advise, support and overall camaraderie. Some communities are getting better at it. Having spent years in the Microsoft and Java ecosystems, I’ve seen it shape up better in Microsoft but that’s because they have evangelists running around doing their job. Java’s “ok” but Oracle hasn’t helped at all, especially given recent lawsuits and Hudson vs Jenkins.

The JavaScript community is an interesting one and the developers within it range from copy/paste scripters to those that thrive on functional programming who have dived deep into CoffeeScript or Dart to know which OOP parts suck compared to, say, LiveScript.

That wide variety of developers makes it harder to polarize the community as a whole and makes it difficult for one great programmer to recognize another. It’s similar to PHP.

Conclusion

The language is not easy to learn if it’s inconsistent. The community around your language and framework really matters; it allows you to learn and grow to become a passionate programmer.

Ultimately, I suggest that all developers should learn more than one language and framework. Get out your bubble and expand your horizon.

You can then choose the right language and the right platform for the right problem. Just as long as it’s not PHP.

Meetups are always fun because you get to meet a wide range of developers. A great event in NYC is Hacker Hours by NYC on Rails which offers programming help for any developer regardless of the problem.

A developer I helped out there recently learned Rails and joined a new startup. He asked me an interesting question regarding working at the new startup:

The other dev is very productive. I feel very slow and unproductive. Is this what it’s like every time you join a project? Everything is just a friggin’ mess?

Ignorance or Incapable?

I think there’s a distinction between ignorance, which is not knowing something because you haven’t had the opportunity, and being incapable, meaning not being able to do it even though you know how. When I start new projects, it takes hours and days of reading to get past the ignorance stage. It takes even longer if they use external libraries or APIs that I’ve not used before.

Don’t expect to be productive within days or even weeks. In larger projects, it could take months.

Legacy Code

On some projects, the developers are disorganized and unskilled or even advanced developers who used so much meta programming that the code reverted itself into being even harder to read. I have to read through the mess and the confusion to determine the program’s purpose and the programmer’s intent.

A developer’s goal is to make the program meet the goals of the business and it’s just as important to make it readable to other developers.

I think we would all agree that Ruby and Python reads easier than Assembler though all languages are capable of meeting their business needs. So you have to look at your highly productive developer and ask, is she writing functioning code, readable code or both?

Falling behind

From the new developer:

I’m burning out because I stare at “magic” all day and produce at a snail’s pace. I don’t get the reward of finishing something frequently and it decreases my morale.

If pairing through large chunks of the application isn’t an option, I suggest focusing on something small that’s part of the whole and working on it until you grok it. You can also start on a new section of code based on technology you already know.

Starting on a new project with lots of existing code and developers can be a daunting proposition. Your first commit will probably be a bug fix or small tweak.

Personally, I always start in the tests. That’s an easy place to find the interesting business logic and the uninteresting CRUD code. Test code needs to be refactored and structured just as much as the code it tests which provides another opportunity to learn more about the codebase and remove more of that “magic”.

Doing FAST vs Doing it RIGHT

Make your code a shining example of how it should work. Don’t spend too much time polishing it. Any true craftsman will want to continue working on their craft and as they get better and learn more, you’ll look back at your old code and wonder what you were thinking.

Any code written more than an hour ago is crap and will eventually be revisited. One of the Ruby Rogues said that all code is experimental.

Therefore, take the time to do it right. Don’t try to play catch-up and throw away quality in favor of speed.

The difference between that highly productive developer that writes messy code and the code that you write starts to shift the culture from one of productive mess which inherently contains technical debt to quality code that’s easier to work with later.

It’s always better to know about the engineering culture before you sign the dotted line but if it’s truly a startup, then you can shape its future.

Readable code

Recently there was a popular gist from a contractor that was let go due to applying aggressive SRP to a simple PostComment class in Ruby. The thread is a good read but when I think of the new developer’s comments regarding “magic” code, I think of something a previous co-worker, Donald Ball, wrote:

… getting code to do what it’s supposed to do is the lowest threshold for acceptability in my book. Getting code to clearly communicate its intent and to be easy and safe to modify is a higher bar, but is the standard by which I judge any code that’s intended to work for longer than a day. We spend more time reading code than writing code.