Colin Devroe

Reverse Engineer. Blogger. Chills easily.

Follow: @c2dev2, RSS, JSON, Feedly,

PHP is pretty bad

Since I wrote “I’m perfectly happy using PHP” last week I figured I’d show the other side’s viewpoint as well. There are those out there that loathe the language. Evee goes off on PHP like no one else could:

PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

Her analogy to a toolbox full of tools that you can’t really use properly is apt. I do feel like I write a lot of workarounds for things. I’ve always thought it was due to the depth of my knowledge of the language. Perhaps it isn’t. Perhaps it is indicative of it.

Some of the things pointed out are rather baffling, such as why the functions names are inconsistently styled such as using underscores or not, etc. But those are a matter of taste really. A language can throw out a style-guide and still be very useful if those functions do things that are of value. As pointed out there, it just gets worse from there.

If you’re into programming you might as well read the entire post. It is good.

Use what works, play with the new

I had Unmark’d Kyle Slattery’s post on his company site (which I think is rather good looking; here is why) regarding why his company uses Ruby on Rails. It is a good post. Notice this bit:

It’s easy to get caught up in the newest trend, and there are lots of great technologies being developed, but at the end of the day, just because something’s new and shiny doesn’t mean it will move the needle for your business.

Bingo. By the time I finish editing this post seventeen more frameworks, libraries, or pseudo-languages will have been released. And honestly, that is fantastic. Because out of those a few will take off, be well supported, and become great utilities for future projects to benefit from.

However, this doesn’t mean we need to use them in live projects immediately. Or, that we should jump from one framework to the next because you like the way the method names use camelCase.

Kyle goes on:

When it comes down to it, I’m most productive when I’m writing Rails code. Sure, I could build out my next project in Node.js, or Go, or whatever else is out there, but I’m going to be able to crank out the best, most productive code in Rails. I know it best. I’ve been working with it for almost as long as it’s been out, so I know all of its ins and outs.

This piece, as he explains, is a big reason to decide to use one language or framework over another. Not just your own productivity, as he states, but also for those that may touch the code in the future. If the framework is widely known, actively maintained, and many people use it in live projects, chances are you can add more people to the project and not have to teach them much about your project. They can likely dive right in and be productive very early on.

Lastly, this bit:

A mature framework, while it may not be as exciting, has had thousands (maybe tens of thousands) of hours of developer time spent getting it to where it is, which generally results in a more stable and secure platform.

If the project your working on ever hits any type of scale, you will want to know that hundreds if not thousands of other projects that run on the same technology has done so too. Early on, many people pointed to Twitter as a project that helped Ruby on Rails mature. And also to Facebook as one that helped PHP get a lot faster. Do a bit of digging when selecting what to use in your project, if a “big boy” is using and supporting it then you will likely get more sleep.

The very same reasons Kyle uses Ruby on Rails is why I use PHP. I do like the way Ruby looks far better than PHP. (Insert GIF of DHH saying Ruby is gorgeous here) I also think that the Rails framework is well structured for web applications. I do think Go looks succinct and interesting. And Node is likely better for some of the things I’m trying to accomplish. However, I’m faster with PHP, a lot of people know it, it is very fast and stable, and has been used in large-scale projects. So I’m perfectly happy using PHP.

I try my very best to stay completely agnostic when it comes to choices like these. (Kyle and I still get along great even though he’s a Ruby fascist.) In fact, longtime readers of my little blog here have likely seen my opinion of Microsoft technologies change dramatically since 2012 or so. Recently I saw someone’s C# and was all o_0! It looked very, very nice.

I love playing around with new things in order to see what else is out there. I can’t tell you how many times I’ve built a new Ruby on Rails application or built something with React or this or that. You’ve gotta keep the juices flowing and one way is to push your abilities into new territory. I liken it to a guitar player that mainly plays rock music riffing with a classical pianist. Expand your horizons from time-to-time and it will only make you a better guitar player.

None of this is to say that you shouldn’t switch to something new when the time is right. In fact, one very good reason to play with new languages and frameworks from time-to-time is that when something you’re using needs to get the axe you’re likely better prepared than if you had your head in the sand. There may be a time to switch from PHP to something else and when that happens I hope I have an open mind and make a good decision. I’ll likely refer back to Kyle’s post to help me make that decision too.

Stripe’s API documentation

Stripe has had best-of-breed API documentation for the last several years. They’ve just made it even better with a “quickstart tour” that works wonderfully.

Anyone documenting an API should look very closely at what Stripe has done. Much of their success is very likely due to them caring about their docs.

/via John Collison on Twitter.

git from the inside out

Mary Rose Cook:

The essay focuses on the graph structure that underpins Git and the way the properties of this graph dictate Git’s behavior. Looking at fundamentals, you build your mental model on the truth rather than on hypotheses constructed from evidence gathered while experimenting with the API. This truer model gives you a better understanding of what Git has done, what it is doing, and what it will do.

I use git every day and I have read many pieces like Cook’s in the past. This was my favorite one to-date. I recommend giving it a read.

Side note: I prefer “git” over “Git”.

My Web: Yesterday and Today

This “Web 2.0” that we’re all so accustomed to lately is great. Semantic, accessible, open, and dripping with fantastic design. However, there are times I reminisce about the days of old, the days of well – Web 1.0.

There are several sites, some still in existence that I really do miss. I remember spending hours on the old Deviant Art just trying to find minimalist desktops and indy art. I also remember digging, refreshing (what is that anymore?) and bookmarking countless pages on The to find the latest and greatest information on release of the Star Wars Special Editions. I remember pulling my damned hair out trying to get ASP to do what I wanted by using Microsoft’s documentation.

It goes beyond sites though, since back then the web wasn’t about usage but rather building the foundation for what we have today. Using the Web in the 90s wasn’t, for me, about sharing photos and bookmarks, or creating and distributing content quickly and easily, it was about communication and expression of thoughts via hypertext. The more I think about Web 2.0, the clearer the picture becomes about the Web as a whole. We have an insanely far distance to travel before the Web becomes what it has the potential to be. Obviously services like Flickr,, and Newsvine are getting closer to what we’d all love to see replacing Deviant Art, e-mailing bookmarks, and CNN, but they are still only very simple concepts done in fairly complex ways.

I listened to a few of the Carson Workshop podcasts and, I must say, I realized how complex our jobs sound to the “average uninformed developer”. Combine the complexity of learning the “best practices” in Web development with how many developers out there that are still using tables for layout, Microsoft Access databases, and reading Lockergnome for HTML tips, and you can see that we’re not even close to where we could/should be.

What makes it even worse is that the people that could be advocating these changes in the new and ignorant developers, are resting on their laurels or even bad-mouthing efforts to help out. Perhaps such efforts as Naked CSS Day won’t make a large impact on Web Standards Awareness, but who cares, at least Dunstan Diaz is trying to do something about it!

“Back in the day” (according to Dane Cook this was indeed a Wednesday) I was always amazed when new specs were released, new technologies developed, or different ways of accomplishing tasks were mastered. Nowadays, I see a lot of copying going on. Sure, we have our elite few that are definitely leading the innovation pack, but in the old days everyone was an innovator. If you couldn’t get something to work, you figured out a way to do it regardless. You busted down walls, you hacked like a mad-man, until finally the result you were looking for was accomplished. Nowadays, you run to Google and do about four searches and copy what someone else has done right from their site. Sometimes this is good, but if you find yourself doing this every time, it isn’t.

I suppose I miss the speed at which innovation seemed to be moving on the Web. Even at 56kbps and under, it surely seemed that the Web was changing faster in 1996-1999 than it is now. I think we’ve hit a Web 2.0 plateau where 10 major services were released and everyone else is trying to catch up with them instead of trying to do better than them.

Take microformats for example. A great effort. Standardize the way specific chunks of content are marked up, this way it will make it much easier to move, distribute, and work with going forward. However, some of these standards are just atrocious. I look forward to trying my hand at making some updates to some of those specs in the near future, but instead of trying to simply use microformats, we need more than just five people thinking about how to improve them.

Recently we’ve seen a gathering for an RSS Advisory Board. Thank heavens, the last guy that was running the show was not only an asshat, but he made Communism look like Kazaa (if you don’t get this joke you probably have a life, which is cool – can I borrow it?). I’m looking forward to seeing what happens with RSS in the near, and distant, future.

AJAX. Oh god, do not get me started. A superb effort has been put into improving not only awareness but accessibility, implementation, and documentation of the HTTPRequest Object. Sure, we’ve had these types of abilities for ages, but I still think all this “excitement” will lead to one good thing – improvements. Ajax, while not revolutionary at all, has caused many newbies to open their eyes to, not only standards (due to the use of XML, etc), but also to the thinking a little bit beyond the separation of presentation and content – but also of functionality. I’d like to put a name on this particular movement, but I doubt the World could hold such an acronym.

I said we’re on a plateau right now, but I think that might be incorrect. Rather, I believe we are on the escalator. The down escalator. And, instead of actually going down with it, we’re trudging onward and upward – each foot landing on the next step only to find another one approaching right after it. This battle to make the Web better may never really “end” but I definitely think we need to pick up the pace a little. Like back in the old days when we said “Screw you” to tables for layout, WYSIWYG editors that wrote horrible HTML, and oh yeah – Windows servers.

[tags]internet, web 2.0, ajax, web development, programming, microformats[/tags]