As I get more responsibilities and things to remember, I really have fallen to my tools to help me keep going. Since my workflow was based upon one of my good friends and has only increased, I’d like to share what works for me and maybe some ideas that can help you no matter your place in life.

There are several methodologies on how to become more productive. One of the more popular ones is Getting Things Done (GTD). This, in particular, speaks to organizing tasks into non-overwhelming ways. For many of us, this is a task in and of itself. This is where computers can come to the rescue.

There are many task management systems that implement GTD. They tend to strive to help you to add tasks quickly and only view what is important to you. In general, they work to help you keep track of and continue to progress on your tasks. I’ll go more into this in the next section where I discuss something I use.

Other general productivity programs exist to help you focus by either removing distractions or sometimes creating them so that you can appropriately rest. Some distractions or simply interface ambiguities or inefficiencies can really take away from a workflow. Having a good workflow for you is really the target of being productive. Having to leave your workflow or otherwise be interrupted can be the death of a day’s productivity.

So what do I mean when I say workflow? This isn’t really a formalism or anything of the sort. I mean the actions that one has to go through to accomplish work. For the simple example of taking the trash out, this would involve getting shoes, getting the garbage, bringing it to the appropriate receptacle, and returning. This seems very simple, but it becomes even more apparent that a workflow can be interrupted if one had to stop in the middle, search for something (say a key), pause to ensure that all the garbage had already been properly collected, and finally evaluate one of many possible receptacles to ensure the correct one was chosen. Our target it to help one discover a pattern that helps to reduce or remove interruption from productivity and otherwise makes life less stressful.

Exceptions

Exceptions are a very common way in most programming languages to establish that something went wrong. They are unique in that they terminate the current context and move up a level. Depending on language, these may need to be dealt with at the level that receives the exception or it may simply raise the exception to the next higher level automatically.

Exceptions are a bad thing to occur. I bring this up since most languages makes them extremely easy to handle in most cases. This can lead to bad practices of using exceptions to convey different statuses or otherwise something other than an error that is unrecoverable at the level at which it will be raised.

In my experience, exceptions come up most (though not exclusively) in environments where there is an element of classes. This allows for the use of typed exceptions. One of the main advantages to this is the ability to handle different types of exceptions differently. This will become extremely important later.

The latest version (1.1.1) has a really nice interface and imported my library rather nicely. I was in the middle of listening to a podcast on iTunes on my Mac, so I didn’t play with it too much on my Windows install. So I installed Songbird on my Mac and asked it to grab my iTunes library (which is mostly podcasts I haven’t listened to and a little bit of music). It seemed ok with it though it didn’t grab my podcast subscriptions (which is annoying though not unexpected. So next step was to ask Songbird to subscribe to a podcast. It’s most definitively not the most intuitive thing in the world at this point as it only seems to support RSS or a single location (if I’m wrong, please correct me). It’s not that bad except it doesn’t seem to understand that a lot of podcasts are not something you want to keep. So podcast features could use to still improve.

What really struck me was the resources. So Songbird was just sitting idle now on my Intel Macbook and iTunes was currently playing back an mp3 podcast (mono but reasonable bitrate). Songbird was taking ~100MB of RAM just sitting there while iTunes used ~23MB to play back. Ouch. Even more surprising was that Songbird was taking between 8 and 10 percent of my cpu (again, doing nothing) while iTunes was taking about 4 percent while playing back. Again, ouch.

I don’t want to say Songbird is all bad by any means. It does seem to have a very nice installer and “assistant” for setting things up (like how Quicksilver does which I think is a very good system when done well). I’ll try to post a more detailed review after actually using it for music and maybe some music/web browsing after I do use it. It also is a good multiplatform mediaplayer. I just do believe at least the Mac client could use some more optimizations before I want it to take over for iTunes on my laptop that I like to try to optimize battery live anyway. If you want to play with a new media player, it’s definitely worth a look.

There are two major flavors of version control systems: the standard system with a single repository you check out and commit against (like Subversion) and distributed version control systems where a repository is copied, locally modified, and merged back to the original later (like Git). The former offers a simpler approach to the entire system. Though you can set up some very unique systems with further customization of subversion like taking advantage of externals, the general formula is to have people modify files from where they checked out (which can just be parts of the tree) and then check them back into the tree, resolving conflicts as they arise. In a lot of situations this works perfectly. It suffers from a large problem in my mind though: revisions on code that isn’t done. Because there is only a single repository in the traditional set up, you _should_ only commit code when it’s done and ready. This means that until that point, you should just keep your code on your machine. If it’s a personal repository, it doesn’t matter, but public projects should not have bad code in the public repository (knowingly).

This is where something like git can make everything better. By having a local copy of the repository, you are able to commit your changes, revert back, and so on without modifying the public facing repository. When your modifications are done, you simply push your repository back to the origin (or alternatively have someone who maintains everything clone your branch and merge both yours and the master branch). The result should be that you get to keep revertable changes locally without messing up the public repository. There are also many other features to version control systems, but these are the most important for my rant.

My rant is about Wordpress. I’m not going to call their code good, but I will say that their product works rather well and is very feature rich. I also (generally) run the subversion build. I’m not right now because as of the last revision I got (10786), someone checked in code that was syntactically wrong (like would not parse). I admit, it was just for ajax stuff, but I still find that rather unacceptable that essentially non-compiling code was pushed into a public facing repository. I reverted to the nightly build easily enough, but this could have been easily avoided. One can even use a subversion backend and git locally to have local revision that git then pushes back to subversion as needed.

What better way is there for actually comparing the frameworks than to actually build a project in it? The problem with this is finding the time to actually do it. I figure a good place to start is to actually lay out the plan.

The plan for testing frameworks is to build a small web app using several popular frameworks (though by no means exhaustive):

• Zend Framework (PHP)
• Pylons (Python)
• Django (Python)
• Ruby on Rails (Ruby)
• ASP.NET MVC (C#)

I don’t promise to actually use them in that order; that’s just part of what I was thinking. There’s also odd ones like Turbinado which is written in Haskell which is a purely functional language as well as having some pretty cool other features which I would like to look at even in its reasonably young state. If you have any others that you think should be looked at, I’m happy to consider them. (Notably not mentioned is anything written in java. That’s due to my not seeing a lot of people who are flocking to java web development. In general, people write java web apps either because they really only know java and do not want to have to learn another language before learning web development (which is very reasonable), they just really love java, or the group they are working with already have a java site which they are then contributing to. If you think it is worth investigating, I’m ok with it though not as a primary interest).

The actual project is supposed to help to show strengths and weaknesses to the frameworks. As such, I want a vaguely realistic project that is still small so I am not tied up in these for very long. That in and of itself creates a somewhat large problem that I want to talk to though won’t exactly demonstrate: how the frameworks work on large projects. Many webapps really are small overall. I’m not trying to say that’s a bad thing, but it is true. That said, many projects that might not be so public or conversely the ones that get very large can be seen as very large projects. I think both perspectives are important to observe though a large project is non trivial to devote my free time to for investigation so I will try to consider.

The project I want to propose will have an initial idea and then be updated twice. At every stage, I am going to try to develop it in generally the most naive and non-scaling way (that is still reasonable). This is to mainly evaluate how much effort will be needed to update and change the application.

The application is supposed to be a polling application (for whatever reason). We want to be able to make a poll that poses some question to uses and has a list of options. Users can select a single option and the results are displayed visually. No user accounts are needed and we’ll just use ip’s to stop multiple votes. We also want to have unit tests and validation on data.

We will then add the first update to add comments because obviously people have input that they want to give. We want simple threaded comments with a captcha and a bad-word filter (with unit tests and validation).

We now have too many users and comments for the admin to always be around to deal with everything. Our common users also are annoyed at having to enter a captcha all the time. In response, we will implement user accounts that need email validation and the concept of other administrators, moderators (just able to delete comments) and normal users who can vote and comment.

This is a fairly small application but not completely trivial. For each framework, I’m going to try to follow the “proper” way of making it. This means that I’m using the components that it ships with unless changing it would be relatively trivial and any installed updates/add ons are at most dropped in a directory rather than me having to modify too much generated code. That does mean that things such as PHP’s PEAR, Python’s easy_install, Ruby’s gems, and just adding dll’s for C# is all perfectly valid.

If you have any input about this project, please leave a comment. I would love to know if you think it’s a good idea, bad idea, is missing something or whatever your feed back is. Also, your own comments on any framework is very encouraged. I am not sure when this project will go through, but I hope to be generally done within the next month.

In my last post, we were looking at a large picture perspective of web applications. I first must apologize for a misuse of terminology. I used the terms “PM” and “Project Manager” when referring to the role being described in my last post. Strictly speaking that would be incorrect as just setting up premade software would not concern a PM in all likelihood. I should have just used the term “manager”.

As we continue, we are going to look at usability and maintainability. We are going to continue to approach these problems from the perspective of effort/time and decisions rather than technical aspects except where very useful.

2. Usability

Usability is arguably the most important part of the project for a manager. This is really what needs to be reasonably well defined before hand and what can make or break the final project.

The largest and most important part of this is a well defined list of features. After all, this product is providing the users with access to some features. If they are good enough, the users will continue to use the product. If the features are lacking, convoluted, difficult or time consuming, wrong, inappropriate for the target audience or anything else negative, this can spoil the project. Since even though all these descriptors are similar they are still extremely important, I want to look more specifically about what each can entail. More importantly, how features could be better defined to remove the problem and give a better product.

Lacking features references when a product lacks an element of completeness to the user. This comes from a couple of ways. The most direct is when a product helps the user toward a goal but fails to help from the start or until completion. Having to use external tools or do more work by hand is generally unacceptable unless there is good reason why the product cannot do more (licensing, technical limitations, etc.). Even if it might be more work to do it by hand, users may choose to do all the work without the product then simply because it involves less context switching.

The more subtle way that a set of features can be lacking is when all of the features from start to finish do exist, but they are not well done. Not well done can refer to both flawed in a different way (possibly one of the ways described below) or that the feature itself does not provide enough help to the user to really be seen as a full feature. For example, if something expects html formatted input but only provides a text area, this is not very useful or friendly to the user (unless the user is known to be very comfortable with writing html by hand and not much writing would be needed).

How do we avoid this though? Well, use-cases can help to actually identify all of the features that really need to be developed. These use-cases need to be detailed enough to also convey technical knowledge of the user and then tested with that level in mind. Features that are not well done tend to only be discovered by tested (and frequently more public of testing due to people associated with the project might know too much to be able to evaluate short comings).

Convoluted features can pose another large problem. The actual cause of a feature being convoluted is two-fold. The first comes from the feature being hard to find. If it is not presented to the user anywhere, how can one expect a user to take advantage of it? I could easily see this coming up when you have say a bookmarklet that you want people to use. If there is no real way to find a link to this without prior knowledge, the feature is convoluted to find and essentially does not exist to most of the user base. Presenting a feature only where it is not relevant has the same result. These can be evaluated by tracing paths to how to find each feature and determining if that is a logical set of steps for a common user or not.

Being convoluted can also refer to a poorly explained feature. Sometimes this is the result of a bug in rendering. If you cannot see the explanation of a field, it is much more difficult to use. If there are constraints on input, these also need to be explained to the user ahead of the user trying to use the feature. Also, error messages should be useful when seen rather than cryptic or exclusively for debugging purposes. Error messages should also exist for all errors so that the user is well aware when something has gone wrong (and whether it was a random fluke such as a race condition, server error, or user error).

Possibly one of the most difficult things to test when the system is understood is how difficult or time consuming the features are to use. That said, it is also extremely important. After all, the service being provided is here to help users. In order to do that, these features have to be intuitive to use and helpful whenever possible. The best way that this can be thought out is by considering the actual use case down to each input. If a user has to enter 40 different values before they get any feedback, there is a decent chance something will go wrong. Also, when actually testing the product, the tests should be timed especially between interactions with the system (or some feedback at the very least like notifications of auto-saving).

Difficulty is something usually hard to measure by people involved on a project due to their understanding of what is required. This poses two possible ways to evaluate the situation: the most authentic way to test this would be to have the system tested by outsiders before it goes live. Finding good and willing outside testers is difficult and also is harder to get fast and good feedback. Because of that limitation, some evaluation still can come internally. The biggest question is how much effort must the user put in outside of the actual function to cause it to work. Does the user need to already have certain figures calculated? Can the product be expanded to help with that? Can any prerequisites be helped by expanding the product some? Conversely, is the product forcing the user to accept its help when a user may be able to figure out the answer on his or her own without the need of assistance? Answers to these questions are important and should affect how the product exists when it is moved into production.

Possibly the easiest one to test is the validity of any output generated by the product. This is somewhat of a demand to really unit test and hand test each and every feature. If there are limitations, can they be either handled gracefully or is the user informed? This I won’t go into so much because this actually would come up mainly in development and can be handled to a large degree there.

Our final question that management should investigate is whether or not the features are appropriate for the target audience. Exactly who might be included in the target audience is very important. If there are several categories, each feature needs to be evaluated from the perspective of that category. Appropriateness is evaluated through many of the above methods. Is there appropriate information to allow the audience to use the feature in a timely manner without problems? More importantly, would this audience actually use the feature? Can you make the feature more useful? It’s possible that the fact that an audience would not use a feature is acceptable (like advanced users may not take advantage of a guided mode). This should explicitly be realized and probably documented. Also, if there are distinct groups of users, maybe the product should tailor itself to present the most appropriate features first.

4. Maintainability

When thinking about a product, how much work it will need in a years time or maybe several years. A common thought is that the set up is likely to be replaces. Experience will dictate otherwise in many situations though. Maintainability needs to be considered in a number of situations: work needed to update, expand, move between hardware, and tightness to dependancies. Again we’ll look at each individually.

Even after a product is done, it is very likely to need updates. No where is this more important than the web where the exposure to the world is huge. As such, the ability to roll out a new update successfully is key. Success in an ideal world means next to no work from the administrator and no noticed downtime from the users. The more complicated the system, the less likely this is. If the product is packaged, it is good to look at how updates are distributed ahead of time so that an idea of effort can be gaged. This gets more complicated also in distributed systems. Can an update be applied one server at a time and they all continue to cooperate in the mean time or does it need to be instantaneous? What happens to any users currently logged into the system? A large concern is data loss. If someone is working in the system as something is updated, will that work be lost? The web is in reality stateless though state is frequently hacked on top of it. Any changes to how state or caches are handled can cause problems for users. Can users be warned about an update that is coming up?

With answers to these questions, one still needs to look at what has to be done on the administrator’s side. Can the update be completed completely from the management interface? Is direct database access required? From a manager’s point of view, how many people will be needed to normally maintain as well as update the system? Needing a full team of IT people to stay late to do an update is costly to the company. Choosing a product that someone without technical ability can update with little effort is much cheaper in the long run.

Projects frequently start much smaller than they end up if they get popular. As such, a question of how to expand this project is very important. This can be important for clustering and redundancy. Does the product itself actually handle being distributed or is that something that has to be handled at the server or database level? Very database oriented applications frequently can be simply handled by using clustering and redundancy features built into the database. If, however, the program also uses local temp files, suddenly load balancing is much trickier. Also, does the product handle increases in hardware gracefully or not notice? If something has to be reconfigured to actually become aware of changes in say RAM, this is another sticking point in long term maintainability.

Hardware changes begs another question of just moving servers. Frequently it is useful to move software to different hardware for better reliability or performance, but some software is not as easy as others to move. Could one server be brought up and another taken down without any noticeable change to the outside world? Can any problems be reduced or removed by simply running the system in say a Xen or Hyper-V virtual machine? If that would work, can the organization support this?

A lot of the questions of moving between servers or hardware might actually be more related to the software’s reliance on the underlying system. It might be very beneficial to performance to take advantage of certain aspects of the operating system. This could create a dependancy on that operating system. Though there currently is a good administrator of AIX systems, is it a wise idea to require the software to run strictly on those systems? More commonly, there can be dependancies on libraries and the like. Most of the time the binding is loose enough that the library can be upgraded past the starting point without any problems. This is not always true. If, for instance, the program was built against a beta version of a library, the actual interface might change in the future. Because of this, an update may actually break the system. This can also exist in underlying languages. If the solution is java based, for instance, would it work well with different java runtime environments? I have personally seen software that would not work correctly with java versions later than a certain point. Sometimes this can happen with interpreted languages too. How much does the software depend on deprecated code? Is it documented so that future administrators can determine whether or not it can be upgraded?

I realize this has been a long post, but I hope it helps with planning projects. After all, better products come from better planning. As a developer though, I believe that it would be good to actually look at approaching how to implement some of this and the ease of development. In my next post we will start to look at advantages and disadvantages of various web languages and frameworks. If you have any comments on what I presented here or would like to contribute to that post, please feel free to email me or post a comment below.

I am by no means an expert on many topics including the ones I want to look at. I do argue that to be a feature in the regard that most of the world is not experts. Because of that, I can present a user’s perspective to a lot of topics.

I have wanted to see a wonderful and accessible web for a long time. From the client side, we have achieved that to a great degree. Browsers are actually overall acceptable products. I will not call them perfect by any means, but I do not think that a large concern of the web needs to be focused on the client. Instead I want to focus on the server side.

There are three major aspects to any application that are not foreign to the web: setup/development, usability, and maintainability. Now I usually play the role of developer on projects, but I am by no means foreign to the Project Manager role or big picture. For this post, we are going to stay with the big picture. To be very clear, we are going to start by defining each of the terms rather specifically:

Setup/development

Though these seem like two steps, they reference the same goal: what it takes to get the software running on the server. Setup here is referring to deploying premade software. These can differ greatly with a “from scratch” environment and something that exists. Development on the other hand references both man-hours needed to get the software created as well as the time based around the learning curve. This can differ for people of different backgrounds and should be approached from different perspectives.

Usability

From the web application’s stand point, there are two ways this must be usable: can the administrator easily achieve whatever task he wants (such as generating content) and can the users easily access and consume the results (such as reading the content). We are strictly looking at the amount of work needed for the day to day use of the product

Maintainability

Even when shipped, software is never really done. The web knows this to a great extent with regards to security. This also comes up with support from underlying technologies. For instance, does the software no longer work with future versions of the language interpreter/compiler? If so, now old software must be kept or new software needs to be located. This looks at from a required interactivity level, what needs to happen to keep the software in a safe and usable state.

I unfortunately have not tried everything I want to talk about. If at any time I misspeak or you have a different opinion, please bring it up. I would like more of a complete discussion than just my views. That said, I am going to generally only look at ASP.NET, PHP, Ruby, and Python and some applications and frameworks on those when talking. There are many more technologies that exist and I am happy to look into more if there is a compelling reason. For this post, however, we are going to stay above a lot of technological specifics and just look from a manager’s perspective.

0. Hosted solutions

The following discussion does not really apply to solutions hosted by others. This is because setup and maintenance is removed. Usability is important and out of box value is crucial. For hosted solutions, only configuring during start up and usability apply. It is assumed that the hosting provider will take care of the rest (which is a feature when what is provided is good enough, but tends to add cost as well as limits use besides sometimes causing legal problems for organizations).

1. To begin

All products need to get onto the server somehow before anything can really happen. This seems like a good place to start.

a) Set up

A very common situation is where some product is desired that already exists (mostly or completely). Even sometimes glorious ideas are really just different ways of expressing known problems. Some of the most common desires on the web are blogging, wikis, content management, and project/bug management. These flavors of problems can actually exist in many ways. For instance, a blog is very applicable if a small company has generally one source of news and some static pages or some site posting news. Wikis work well when trying to have collaborative document generation or simply a system for developing documents. Content management systems work for more general case web sites that tend to want to fill multiple roles at one time such as file/media management, forums, articles, and possibly more. The last category is generally set up for those working on projects (this includes non-technical ones) and/or developing software. There is many more categories of software available, but from the set up perspective, they all act about the same.

Finding appropriate software for a specific goal frequently is not trivial. This comes from the abundance of software that exists as well as constraints for the software itself (such as needed features, language/system requirements, etc.). The worst part is seeking a decent amount of features that are available with work from multiple sources. Generally, the concept that time is money is the best thing that I can suggest. When trying to start looking for software, try to limit the field as much as possible first. Less choices for whatever reason will allow you to either pick a product or choose to develop your own much faster than trying several.

Assuming software has been selected, installation actually occur starting with prerequisites. Package managers and installers really make this part easy is most cases. Installing databases, apache modules, and various other components frequently can be taken care of by either some other system or is described in the installation documents making this step the most predictable in general.

The final step of set up of premade software is configuration. This is frequently where many problems will occur and time will be lost. A concept briefly mentioned in point 0 is out of box value which is very important here. Products have a certain number of features contained in the default install. These features and the quality they provide can be described as the out of box value as no additional software was needed to achieve it. For many large projects though, there exist add-ons and plugins that will provide even more features. Sometimes that is the only way to actually get a desired feature. These frequently become a consideration for long term use though. This stems from compatibility between plugins and the main software versions as well as any required changed needed to make the plugins work. Many can simply be moved to the server and enabled through an administrative interface. Others may actually involve hacking part of the code of the product. The latter is much more prone to error and problems though the former is not without them either. Speaking from experience, something like Wordpress (which runs this blog) allows plugins to attach to methods. These methods may be called all the time and could render the entire product unavailable until it is reinstalled or the database is manually edited to revert changes (which is how I fixed one problem with plugins). To truly get a system working the way that is desired, a lot of time is likely to be invested in configuration.

b. Development

Again, we are approaching this from a PM’s perspective for now. Actually creating software from scratch is time consuming and costly in a lot of regards. That said, you get full control over what is created and can therefore get the maximum out of a system. You also can basically remove configuration as everything will be built to fit the situation.

The entire cycle has to start out in the planning stage. The actual objective needs to be defined along with constraints. Due to a lot of organization’s limitations, outside code might be somewhat limited (based on licenses amongst other potential problems). The amount of available outside help (speaking of code, not contractors) as well as time constraints can change a project from following the best or latest means to being something more within the developer’s skills. If at all possible though, the best tools for the job should always be chosen. We will look at this from the developer perspective in the next post where we actually try to find the best tools for the job.

Effective development will need to have the actual code-writing section overlapped with a testing section. If large enough, people could be tasked with strictly testing the code and setting up automated tests for more thorough coverage. The web is an interesting beast in that 100% code coverage is almost required by tests because the potential user base can easily find all the errors that were missed in development. Also, a bug released to the internet could give arbitrary outsiders access to central points of data that are very critical. As such, a good testing phase is very necessary. Also, documentation should be written for all of the code. For this code to live on past it’s current developer, how it was made absolutely must exist (and be written in more of a “what this does abstractly” rather than a “what this code exactly does” sort of way; this will also keep documentation valid for longer even when the code changes).

I am extremely well aware that how to do all of the above is very abstract, but I think it is all better addressed from a developer’s perspective. From the manager’s stand point, development may give you a better product for your needs, but it is very costly to do right.

[Due to the fact that this post is probably over 1700 words, the rest of this is posted in part 2 of this series. The developers perspective on actual development comes after that and soon!]

I’ve taken to running svn releases of Wordpress. I don’t exactly have a good reason, but it does seem to make themes not work right. (I tried to use two different themes because i’ve been doing a lot with dark backgrounds and light text recently. it went poorly). On the bright side, the new interfaces seem slick and the updates are easier using straight svn access.

For development, I’ve come to find that I’m either in vim or Visual Studio 2008. That’s pretty much the two ends of the spectrum of light and generic program to highly customized and heavy for development. I’ve been doing some development with C#.net and really have to say it’s fun. I love programming in it probably more than any other language. I’m enjoying the environment too. I admit, I kind of miss my vim key bindings and jumping into normal mode to move around, but it’s not all bad. The code completion and intellisense is great in VS2008. The debugger for applications in extremely nice to step through whatever has gone wrong. I really must say that I miss those capabilities when I’m writing something else.

Also, since I mentioned running light text on a dark background, I would suggest altering your theme (if your window manager supports that) to light-on-dark. It’s very nice on my eyes and you can find great places where only backgrounds or foregrounds were specified, making them unreadable! Well, at least it encourages you to think about what happens when someone does try to use high contrast light-on-dark settings with your program/web site. Accessibility forever.

I’m going to be honest. I enjoy writing web apps. I really enjoy the back end code and the product at the end. I have done pretty much everything of significance in PHP also. This shouldn’t offend anyone yet, but some people might see PHP and think less of me. And the real question becomes why?

Now I’ve asked a lot of my friends this question. The general answer usually comes down to PHP yielding bad code or being unmaintainable. Um… I don’t think that’s PHP’s fault that the last person who worked on this project kinda hacked it together into somewhat working but terrible shape. Most if not all programming languages allow you to write bad or unmaintainable code (purely functional languages might be the exception, but my experience with them is far too limited to be able to comment). To be quite honest, I don’t have a problem maintaining my php code. Larger projects always have a framework (one I made usually) to power them and small scripts can easily be navigated by using find in the file or scrolling.

Well Rails and Django are amazing frameworks. This may or may not be true. Rails does have a lot of cool features. It is even cooler when you start giving it extra gems. I’ll give it that, but even that isn’t good enough for me. If you actually want to start using more complicated conditions, you end up writing the SQL you were looking to avoid. Something like Symfony provides most if not all of the commonly requested features for php. There are many other frameworks available too. So if one isn’t good enough, you can always try another.

PHP is slow. To be honest, PHP is usually not where scripts end up being slow. I frequently see one of the following: 1) Are you having PHP do calculations that your database could easily do? Why would you do that? 2) Are you having PHP parse pages that are static or virtually static? Why not use server side includes and not even use the php parse? 3) Did you make a huge data structure that you are recreating on every call? Look into functional programming or restful programming (both are stateless) and consider revising your code.

And in the end, PHP has a lot of well known ways to speed it up. Why not try out a caching solution? memcache is nice and well supported. You could even implement your own.

Are there any reasons to use PHP, not just defend it? YES! Plenty. Integrating kerberos authentication is extremely easy. There is a wealth of information about any common task. the PEAR/PECL code is common and usually easy to use. The wealth of code already available makes it a simple choice.