Category: PHP

Stuff about PHP (Personal Home Page or PHP Hypertext Processor), an open-source language for developing websites and web applications. And one of the few things out there with more market share than a Microsoft product.

I first heard about it in 2007, when I started using Scrivener, but dismissed it because the requirement that a novel be fiction. I only just found about NaNo Rebels, which allows you to customize the “50,000 words” into nearly any other creative exercise, including non-fiction. So yesterday, this was born:

I don’t know if I can finish since it’s about a good sized blog article each and every day. We’ll see how it goes. So far it’s been a bit strange writing a book. For instance, I can’t use my WordPress shortcode macros lest I ruin the word count.

Are sure it’s just Python programmers? I think that relatively speaking Ruby developers and Java developers hate on PHP more (and Perl and Javascript developers less).

From a software language design perspective, the PHP language is an ugly hack. One of the creators of Java said that when he thinks of PHP his heart goes dark (showing a complete black slide in his presentation for emphasis). The more structured the language (and Java and Python certainly are), the more offensive this ugliness is. (Ruby gets this view not from the language but for being the home of a lot of programmers who were trained in Java in school and for Ruby on Rails being a popular framework in the webspace already crowded out by PHP.)

However, there are t-shirts out there of me saying back in 2006, “PHP is a ball of nails, but when you throw it at a wall, it sticks” and that still applies today—it’s ugly, true; but it works. If anything, the language is far more ubiquitous on the web now than then, though that’s mostly due to the popularity of applications written in PHP such as WordPress and Facebook rather than any success in the language itself. The language has proved remarkably successful due to its adaptability and limited focus on what problems it tries to solve.

I imagine that this popularity-in-spite-of-aesthetic-beauty is offensive to those working in the web who think themselves above the direct, simple, and crass. That reality may sit so ill with some people that they feel the need to disparage PHP which becomes an object of their derision and the villain in their story. It’s only natural for a cohort in the minority to feel that way toward a market leader: Apple Macintosh users used to act like that toward Windows PCs, Windows Phone users act this way toward iOS and Android, etc.

The irony is that PHP is a market leader in only one tiny aspect of the programming market: the server-side, non-event-driven web. It has no footprint in the client-side web, none in application space or even the mobile app space, no recognized products in non-web tools and applications; and is just a rounding error in the DevOps space (to pick just one area where Python seems dominant/ascendant). It even makes no pretension to be a programming language to facilitate learning programming (another area Python is better suited to). Since all these areas are growing as the niche PHP represents is static, I find it ironic people still wage language-religious jihad against PHP.

That’s like hating on a horseshoe monopoly after the automobile has been invented.

And I say this as someone who has programmed PHP for 16 years and gives keynote speeches in the language.

On the non-programming side, I’ve been messing with Ansible because I just got tired of doing things by hand—and I never needed to learn this because I’ve always had operations engineers working with me.

The ripping on Rails thing is over with me because there’s no point in arguing over how to solve a solved problem—today, the web problem is the easy part. What I find strange is people still feel the need to defend Ruby on Rails. I mean who the fuck cares what your middle layer code is written in when everything is an API to something written in Javascript?

“I don’t like that everything is an API to something in Javascript. As a user, the Web feels slower and flakier than it used to.”

I don’t like that everything on the front-end is pushed toward a single-page application. The reason for this is that the DOM-based model of front-end javascript (e.g. jQuery) gets so taxing when the application gets big because you’re bolting feature-on-feature, library-on-library to get it to work as smoothly as you envision. At a certain point, a true MV(VM) javascript framework (e.g. AngularJS) gives you much more because it abstracts all that in a consistent manner.

As soon as you buy into one of these, you’re invested into a huge initial javascript payload which causes you to not want the user to leave the page to unload anything, which then forces you into an API-based model with HTML partials and a client-side route/sitemap and more crap in the payload until you have a single-page application.

And then pretty soon your website is like Flickr where I swear every tenth click I’ve got to reload the page because the UI became non-responsive and I’m deciding to open the app in my iPhone just to do something without that frustration. How fucked up is that?

But then I look at Bootstrap and I figure, I’d rather have a SPA than everything looking like it was designed by some Apple-loving hipster (and this coming from a person who has used and loved Apple products longer than they’ve been alive).

“I’ve always enjoyed your talks and lamented that you didn’t remain on the PHP speaking circuit.”

Maybe I’ll start speaking when I have something to say. Like I’ve said before, PHP solves the “web problem” very well, but the web-problem is not a hard problem anymore.

Remember, it’s been four years since I’ve done any UI programming so everything is new to me. Basically, I’m a newbie, and I don’t think anyone wants to hear from someone who doesn’t know what they’re talking about.

But I did notice this from managing engineers: the worst problem a coder can get into is fear of having to start over. You get good at what you’re good at and when things pass you by, you feel the need to protect what you have because its what you know.

That’s how I feel about Ruby on Rails and that’s how I feel about me and PHP.

It occurs to me that wpautop() is the register_globals of WordPress—a feature that was instrumental for its growth and popularity, but really needs to DIAF. They should rename the function wppeepee() because it finds a way to pee pee on your content at the most inopportune moments, causing unending headaches in your code.

For those of you who don’t know, wpautop can be seen as nl2br() on steriods, or (as I prefer to call it) a poor man’s Markdown. It’s been in WordPress for almost forever, and it’s hard to imagine writing a blog post without it, even if it’s a Really Bad Idea™.

After a couple year hiatus, I thought it’d be nice to start speaking again — the disconnect of basically stopping speaking at open source conferences when I started working at two companies producing some of the world’s largest open-source products ([WordPress][] and [Wikipedia][]) was becoming too much.

I decided to apply this year. Luckily, [Northeast PHP Conference][nephp] forgot to check the The Great Offensive PHP Speaker Blacklist™, and accepted my talk!

The talk will be: [Ten Evil Things: Features Engineering at Wikipedia][10 evil things]. Now with 30% less swear words, but don’t worry, it’ll still be fun. 😀

When registering, belatedly, I noticed they had an interesting preferences page, I thought I’d share my answers with you

> Hi Terrence,
>
> I am following up on previous emails and calls. I am doing some research on PHP. I understand that you are focused on [canonical model](http://en.wikipedia.org/wiki/Canonical_Model) management, [SOA](http://en.wikipedia.org/wiki/Service-oriented_architecture) or [ESB](http://en.wikipedia.org/wiki/Enterprise_service_bus) initiatives. Do you have 10 minutes for a quick call tomorrow afternoon?
>
> The [redacted] platform enables rapid service design, construction, and management all from a Canonical Model. This enables the following:
> 1) Your services are managed in our repository aligned to all of your business capabilities
> 2) Impact analysis on how a change from a provider system ([Logical Model](http://en.wikipedia.org/wiki/Logical_data_model)) can impact the Canonical and other services
> 3) Rapidly propagate the changes to the impacted services
> 3) Rules based [version management control](http://en.wikipedia.org/wiki/Version_control)
> 4) Mapping provider systems to the canonical model reduces the number of mappings required by over 99% for a complex integration projects.
>
> I know this is a busy time of year. If someone else is better suited for this discussion, can you please refer me to them?

I understood every third word.

The other day, I sat through a presentation from from an enterprise consultant, they had an 8 category scrum chart just for feature choice and a 10 category one for development. The former had categories like: “paths to insight” -> “validation” -> “harvesting”, so I spent most of my time imagining what would happen if people were story cards that ended up dying due to being harvested at the end of validation due to improper paths to insight.

Maybe if they spent less time throwing verbiage and more time doing, [Enterprise](http://terrychay.com/article/php-enterprise-scalability.shtml) [wouldn’t](http://terrychay.com/article/php-pro-con.shtml) [be such](http://terrychay.com/article/php-enterprise-myths.shtml) [a joke](http://terrychay.com/article/enterprise-scalability.shtml).

22 categories? **This** is agile?

My theory is that someone with [Wernicke’s aphasia](https://en.wikipedia.org/wiki/Wernicke%27s_encephalopathy) would make [a killing in Enterprise software development](http://www.youtube.com/results?search_query=wernicke%27s+aphasia).

37Signals & Ruby? Thank his noodly appendage PHP’s support isn’t as terrible as that company on that language.

You lost me there, bub.

When it comes to engineering choice, programming language is not even in the top 10 of important choices a software architect has to make. If you’re worried about the language, you’re worried about the wrong thing. (I’m also a little amused that the author holds Python as a language with great unicode support.)