Hi,

People ask me from time to time, what PHP framework is the best one to learn?

Well, I always look at technology choices with two things in mind:

1. How capable is the technology?
2. How accepted is the technology?

If you look around, it becomes pretty clear, that if you want to learn an effective web application framework, you want to learn the Zend Framework – indeed, the trend is with Zend.

Zend framework being used by companies large and small

I know from first-nerd experience that the Zend Framework is being widely adopted. Just recently for example, Intuit and the BBC have implemented new web apps that are Zend Framework based.

… I know because my good buddy Jon Lebensold of Zendcasts helped build one of them.

There are plenty of other examples out there I’m sure … and I am confident that the trend will continue towards the adoption of the Zend Framework. With the PHP company (Zend) and IBM behind it … it doesn’t take a brain surgeon to figure that one out.

Thanks for reading,

Stefan Mischook
www.killerphp.com

Recently we had to make an emergency move from our old servers (where we had been for 5-6 years) to our own dedicated server because of technical difficulties in the heads of the nerd’s who managed the servers killersites.com had been sitting on.

I will spare you the details of my server migration ordeal for now. What I want to point out, is that PHP (once again) has proven to be a great choice as the server side programming language.

PHP is consistent …

During this move, I had to deal with a bunch of web apps and scripts that included a nice buffet of technologies like:

- Perl
- PHP
- Java

.. Yes, the dreaded evil configuration hell that is J2EE!!

To make a long story short, migrating the PHP apps was a snap – copy over the files, set up the database and were off! On the other hand, I still have to get around to figuring out why the Perl and Java applications don’t want to run on the new server.

PHP continues to rock, saving me time, money and headaches.

Stefan Mischook
www.killerphp.com

In 2006 I created killerphp.com because I wanted to make it easy for web designers to learn PHP. I thought PHP was THE predominate web programming language and I felt every web designer should include PHP as one of their core coding skills:

- html
- css
- php
- javascript.

Then Ruby came along … for a short while.

What happened to Ruby and Ruby on Rails?

Once upon a time Ruby was the best thing since sliced bread … it was the language to replace all languages and everything else just sucked! Funny, that seems like ages ago.

Today though, the picture is different; Ruby’s shine has since lost its’ luster and the Rails train has practically fallen off the tracks – now there are other web frameworks in the Ruby world that have replaced Rails.

Addendum: Merb and Rails are merging … Rails hasn’t ‘gone off the tracks’. My bad.

So what the heck happened … what stopped the Ruby train ride?

What stopped Ruby from spreading beyond being a niche language is the EXACT same thing that stopped me from jumping on board back in 2006-2007: Ruby’s heart was broken.

- Yes, Ruby has a great syntax.
- Yes it is a lot of fun to program with.
- Yes it is pure object orientation, to the max!

But, there were a lot of holes in Ruby … crucial libraries and functionality that PHP’rs took for granted, the Ruby guys could only dream of … or they could patch it up with some C code. Ouch!

Beyond that, there is Ruby’s dirty little secret: crash-o-matic. Yep, Ruby based web apps used to crash a lot! Web server integration was not stable and was a pain in the ass.

Reference: Twitter Crashing

… To be fair though, I hear that aspect has improved.

What does this have to do with PHP?

As I stated years ago in a blog post about Ruby; PHP’s strengths are found in Ruby’s weaknesses. Yes some aspects of PHP are not as (shall we say) pretty as Ruby. But like good looking people who are jerks, who cares how beautiful they look if their personality sucks.

… OK, maybe you could hang with them for just a short time! But whatever you do, don’t marry them Rob!

Stefan Mischook
www.killerphp.com

Why not?

… Because building a content management system from scratch is (probably) a really dumb idea!! Now that I come to think about it, building any of the most commonly used software from scratch, is kinda stupid.

Things you should not build from scratch:

• Content Management Systems
• Blog Software
• Forums
• Directory scripts

The Top 3 Rules in Programming

The real estate business has a famous set of rules – the top three rules in fact:

1. Location
2. Location
3. Location

The idea behind this rule, is to stress how important location is to a piece of property. In software development (programming), we have a similar set of key rules:

1. Reuse
2. Reuse
3. Reuse

Yes, if you are a smart and experienced programmer, you know that the first thing you do when someone approaches you with a project, is to fire up Google to check if someone else has already built something that is at least similar to what you want to create.

… Simply stated, it is crazy to reinvent the wheel and build something that has already been created. Especially within the context of building a program to help support some business. What I mean by that is, that unless you are building a piece of software as the core of a business, where the software itself is the business, then you should not be starting from scratch. It’s just too expensive.

Lucky for us PHP nerds, there is a huge collection of open source, free and nearly free software out there created in PHP. Things like the above mentioned blogs, cms’, forums etc … have been created many times over by teams of adventurous nerds. Given that fact, it makes even less sense to build these things yourself, just because you need one for your website.

Don’t ask me how to build a CMS!
No, instead of trying to build these (typically) big and complicated programs from scratch, you should download a proven mature product where they have already worked out many of the bugs and spent the hundreds of hours refining them.

Suggestions:

A good blog software: http://wordpress.org/

Forums:

http://www.phpbb.com/
http://fluxbb.org/
http://punbb.informer.com/
http://www.vbulletin.com/
http://www.invisionpower.com/community/board/features.html

CMS

http://drupal.org/
http://expressionengine.com/
http://www.cmsmadesimple.org/

Believe me, there are many more out there.

Thanks for reading,

Stefan Mischook

www.killerphp.com
www.killersites.com

I was chatting with my Java buddies recently and they had just discovered an alternative lightweight framework for building Java based web applications – something called Spring. The Spring framework is equivalent to the Zend Framework or Code Igniter.

I first learned about Spring before it was called Spring, back in 2002 when the inventor of Spring wrote a book (Expert One-on-One J2EE Design and Development) criticizing how ridiculously heavy Java was becoming.

… I was right there with him! So much so in fact, that I moved into the ultra nimble PHP.

Anyway, since then, the Spring Framework has become one of the major players in the Java world. I’ve been out of the Java world for a while now, but I do check things out once and a while just out of curiosity. Besides, the PHP community can learn a lot from Java … both the good and the bad.

The point of this article:

I checked out the official site for the Spring framework … they use Drupal! For those of you that may not know, Drupal is a PHP based web application.

Nice!

Stefan Mischook

www.killersites.com
www.killerphp.com

I was researching things ‘nerd’ on the Web today, and I found myself at the CodeIgniter website.

For those of you who may not know, CodeIgniter is an MVC PHP framework.

What is an MVC framework?

I won’t go into details here since we’ve covered MVC basics elsewhere. Let me just say though, that an MVC framework is a bunch of PHP code organized into a reusable structure/system designed to make building web applications easier.

MVC is short for:

- Model
- View
- Controller

The general idea is to keep code separated by it’s function.

For example:

Code used to talk to the database is contained in the ‘Model’ part of the code base. And the ‘view’ is the code (typically mostly HTML with some small bits of PHP mixed in) are basically the pages/views that people actually see … your basic web page.

… Don’t worry, I’m going somewhere with this.

I’m wondering about CodeIgniter’s decision to place PHP looping code in their views.

I had a few minutes to spare and so I watched their ‘Hello World’ video tutorial.

What caught my attention in this video was how the author was using PHP looping code in his ‘view’ template! This may not seem like a big deal to you, but consider these two points:

1. The whole point of the ‘view’ in MVC is to keep as much PHP code out of the view templates as possible. For me, the main advantage of doing this is to keep your web designers from busting your PHP code.
2. Looping code is the messiest PHP code you can possibly have in your pages … get it out of there!

… I remember back in 1996 (in my classic ASP days) where the biggest problem was trying to cleanly loop through recordsets in such a way so that web designers wouldn’t break the ASP code.

My own simple solution was to build the table rows in a page-widget helper object and then shoot back a simple string variable to the view. The web designer would then simply wrap the one line of PHP in a table tag:

This way the web designer is free to style the table anyway they want, and it’s way harder for them to break the page.

-

I haven’t really looked much at CodeIgniter, but if this introduction video is representative of how they do things … I’m wondering: why?

Thanks,

Stefan Mischook

www.killerphp.com
www.killersites.com

I know I will probably get blasted/flamed for this post … but that’s the life of a nerd with an opinion.

So does WP 2.5.1 suck? I’m not sure!

UPDATE:

I have since discovered new information and have resolved the problem … kind of. You can find details in the comments below.

-

So what’s the problem with Wordpress 2.5.1?

I just recently installed the this latest version of Wordpress (2.5.1) and quickly found it hanging (while trying to load a page) for as long as 40-50 seconds!

I then proceeded to isolate the potential causes (database, custom fields, custom theme) and have since found out that something stinks in 2.5.1’s core.

The bug is not consistent across servers – that means, it could be hard to find.

After installing Wordpress 2.5.1 multiple times on one of my servers (the server where I always got the massive slowdown) I then installed 2.5.1 on another server of ours and so far, it seems to be working.

Some might think that the simple answer is that the first server is the problem. Well, the problem with that assumption is that all previous versions of Wordpress work fine … along with 5-6 other PHP applications.

… No, it’s a Wordpress 2.5.1 thing.

Update: I am having the same problem with Wordpress 2.3.3. Strange because Wordpress 2.3.1 works.

I’m not the only one.

A few minutes of Googling revealed, that I was not the only one having these problems.

Unfortunately for me, the solutions suggested don’t seem to solve my problem. Too bad, Wordpress 2.5.1 has some nice administrative features.

My suggestion:

Before you upgrade your old working installation of Wordpress, I would suggest that you test 2.5.1 in some other directory just to be sure it works with your server.

Stefan Mischook

www.killerphp.com

I was going to start this off with some analogy on how Ruby is like dating some ‘hottie’ that turns out to be crazy .. but I just couldn’t make it work …

-

When Ruby on Rails started to gain some momentum a year or so ago, I decided to take another look at the Ruby language itself along with the Rails web framework.

Before I get to the heart of this article, I have to tell you that I love the elegance of the language … it is fun to use.

But, being a nerd who’s has experienced disappointment in promising new technologies in the past, I decided to dig a little deeper into Ruby and Ruby on Rails before committing to use it in real projects. I did my research … and I’m glad I went with PHP instead.

… Let me just say that this Twitter news, only reinforces my own thinking from a year and a half ago.

Why did Twitter decide to move away from Ruby and Ruby on Rails?

Well according to TechCrunch, the boys at Twitter found that Ruby could not be made to scale.

Update:

Apparently this Techcrunch report was later refuted by the Twitter people. Nonetheless, the point of this article still holds true.

-

I’ve also found comments from a Twitter developer (Alex Payne) talking about how slow the Ruby language is:

“All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise.

Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. “

Even the creator of Ruby (Matz) has his beefs with Ruby

When I heard about the critical comments made by the creator of Ruby about the language … it made me think twice about jumping in.

Always look at what’s going on ‘under-the-hood’

So, when I decided to move forward with a new web application, my first decision to make was the technology stack I was going to use. I was considering:

• PHP
• Ruby
• Java with JSP and Servlets

… I had to at least consider Java since I’ve done a lot of my work in Java in the past.

Quickly though, it came down to PHP or Ruby with Ruby on Rails. Ruby was the hot new language and my little team really wanted to jump into it .. and I must admit, so did I.

But experience prevailed, and I decide to take a deeper look at Ruby (and Ruby on Rails) before I would commit myself.

… I found some major holes.

The problem with Ruby and Rails

I don’t want to get into to micro-nerd details, but at the time, I found that there were things missing in the core Ruby language, things that developers had to fall back to C solve! This was something I did not want to have to deal with.

Another major hole (and this was the deal breaker for me,) was that Ruby and web server integration sucked. It sucked hard. You had to jump through hoops to get Ruby web hosting working.

One reason I moved away from Java web application development, was because of the problems related to Java web hosting. Though I know Java server setup reasonably well, PHP is so freakin easy by comparison!

Anyway, Ruby web server integration makes the Java thing seem trivial.

Ruby reboot

Beyond all that, you’d here stories (with Ruby and Ruby on Rails) of the web server having to be rebooted several times a day! This is not at all acceptable in any situation. That alone should be enough for any self-respecting developer to want to stay away from a technology.

The above reboot problem is like buying a boat that continuously springs leaks. Who wants to have to bail water all day … especially when you’re out there on the water.

Anyway, I made the choice for PHP because it was fast, could do everything I wanted without having to write C code, and was proven.

As told one of my assistants:

I don’t want to spend months developing an application, and then find that the underlying core can’t support the load. Or … that we find that we have to reboot the web server ten times a day!

… If I wanted that, I would go back to classic ASP!

Conclusion

I haven’t looked at Ruby and Rails since that time, but I am sure things have progressed. That said, this Twitter news is just further evidence that the Ruby web stack stills needs work … work on the very heart of things Ruby.

It also shows that you should never jump into something until it is really well vetted.

Some related links:

The complete interview with the Twitter developer Alex Payne.

CNET on Twitter’s Ruby move.

Thanks,

Stefan Mischook

www.killerphp.com
www.killersites.com

Angry self righteous tech-nerds.

Who are the angry-nerds?

Angry-nerds are those programmers, network administrators or any other geeks that have a major chip on their shoulders.

Typically, they are in their twenties, with little experience, and are just out of school … full of academic dogma and ritual.

It takes little to set these guys off …

When confronted with a tech idea they don’t agree with, or they find that a concept (or way of doing things) is ‘below’ them intellectually .. they become arrogant, hostile and their not so inner nerd-child appears.

Generally these twits are useless to have around … besides being annoying.

Angry-nerds like to attack beginners

One behavior that is consistent in the angry-nerd population, is their collective disdain for those trying to learn a new technology. If that wasn’t strange enough, they are even critical of those who would try to help beginners get on their feet.

Why?

I think angry-nerds are just looking to bully people they feel they can bully. A little payback I suppose …?

-

The classic arguments that bring out the angry-nerds (frothing at the mouth), include:

• Java vs. PHP
• Mac vs. PC
• Apache vs IIS

… and the list goes on.

Funny thing about angry-nerds, is that they tend to get angry only on message boards and chats. For some reason, angry nerds tend to be quiet introverts in real life.

??

What makes a nerd so angry?

It’s hard to say, but I think nerds become angry-nerds because of two things:

1. Because the got picked on a lot in high school.
2. Because they go on dates once every 3.5 years.

I think #2 alone can turn a harmless nerd, into an angry-nerd. That said, I also think memories of childhood beatings probably goes a long way to help the process.

My advice to angry-nerds:

Try not to be so angry, and maybe you’ll actually get a real date.

Stefan Mischook

www.killerphp.com

I’ve been known to say: “I love everything about programming … except for the clients!”

This aspect of the web business (managing clients,) falls under the umbrella of project management – something every web developer, must learn at least a little bit about.

Who are the clients?

Clients can be the actual company for whom you are building the software, they could be the department next door or perhaps it is just your manager.

Whichever the case, you need to learn how to manage your clients, otherwise you will suffer a long and painful life – as a programmer.

A story all too common …

I was chatting with a nerd friend of mine recently and he describe a situation he was dealing with – a situation that made him consider leaving his job.

… He described his hair-pulling situation where his client was adding new functionality with each meeting. It was becoming such a regular event, that he was purposefully avoiding meetings.

These additions are commonly known as ‘change request’ and unfortunately, my old buddy was not handling them the way change request should be handled.

This is the scenario:

• Client request additional features/functionality NOT in the original quote.
• Client expects these additions at no additional cost.
• Client expects the project to be finished by the original deadline, even though they’ve requested a bunch of new stuff.
• … Client gets angry because you can’t meet the above expectations.
• You start hating your job because the rug keeps getting pulled out from under you and yet, all the fingers are pointed at you!

Programmers need to draw that line in the sand, and then stand their ground!

The frustration is really rooted in how YOU manage the client’s expectations. You (as the programmer) need to be clear at the start, on how things are going to go with regards to the project.

Put it down on paper.

You need to clearly define the parameters of the work (what you’re doing exactly) and then set that down on paper where everyone concerned signs on the dotted line and everyone gets a copy.

It should also be clearly stated in the document (and to their faces) that any changes will affect the price and the deadline.

… If they want to add features or change requested functionality, the price will change and the deadline will be pushed back – it only makes sense that it will take longer to finish.

The contract before the work.

This paperwork should all be hammered out before you write one line of code. Actually, this should be done before you do any real work on the project.

I’ve found that (most of the time) if you establish the working relationship at the beginning (defined by the contract), the vast majority of clients will respect you, and the process much more so.

… Rampant change request will simply not happen because the client understands.

That said, if your client still turns out to be a little dense, you need to pull out the paperwork and stand your ground.

You have been warned:

If you don’t do this, programming will be like the slow pull on your back molar … as the dentist extracts your tooth. And then, there will be blood.

Stefan Mischook

www.killerphp.com