While I’m not thrilled about what was said and how the topic of diversity was delivered, I can’t really deny that the statement and slides retain a lot of truth. Why are there few black people in the web developer space and attending functions? Personally I think its a cultural issue.

Lets face it. Black people just aren’t very excited about web development. Few of them ever pursue a career in technology unless it has to do with music or some form of entertainment. As a black web designer of almost 10 years, I have not once worked with other black web developers. I just don’t know why that is. I have a vibrant career as a web designer without having a degree, why aren’t other black people doing the same?

In Rails there are different ways to do anything. The approaches can become easily unlimited depending on your skill level. For a developer like myself who is primarily a designer, it seemed less appealing that I had to spend 60% of my time learning how to do it right. Don’t get me wrong, I want to do it right. Nevertheless Rails documentation and the elitist community didn’t shine light on anything. I realized then and there, Rails is not for newbies.

I’m almost positive there are plenty who disagree, but the fact of the matter is your disagreement is irrelevant cause you’re not me. Moving on. I’ve bought all the “important” books for Ruby and Rails and have come to the conclusion that Rails isn’t as productive as it claims to be. Surely its more productive than what we’ve had over the years in the shadow of Java, PHP and others. But I’m speaking mainly about building production ready web applications and web sites.

This is where I came back to Django. Previously, Rails gave me good fuzzy feelings and the only reason I took to it was because it had a larger influence and everybody else was doing it. Now that reality has set in, I needed something that was less hassle. So I’ve switched to Django.

Why Django over Rails?

• Deployability – Rails is not easy to deploy on shared host environments. When I say easy, I mean I should have the proper control to start and stop my application layers whether they be servers or just applications. Rails needed at least Mongrel to work smoothly. And if you really wanted your projects to sing, you’d had to incorporate more stacks. Django leaves this to be optional. Django runs well no matter how many stacks you have.
• Portability – Django was built to run on any hardware anywhere. It runs well with older versions of MySQL and Apache, so on and so forth. So moving my projects from one server to another was simple. Rails on the other hand leaves all the heavy lifting to the developer. Quietly, Rails in a nutshell is a luxury framework.
• CRUD and the Admin – Often I like to test and validate my model structures before adding end-user centric functionality on top. To do this in rails I have to build “non-scaffoldish” admin intefaces and relate my data manually. Django doesn’t make me do this. It does it all for me and it looks hot at that. It makes CRUD and the admin UI enjoyable.
• Views and Templates – They just make sense. I hate recreating the same layouts over and over again, luckily both Rails and Django create paths of least resistance in this area, however Django does a better job.

Those are just a few things Django has proved itself in and as time moves on, I will post more about how Django does documentation. Stay tuned.

As it stands the iPhone is a fringe platform meaning that its relevance is almost nil for most web developers. For one thing, the iPhone can view full websites with exception of Flash and Java. So why are we masking already existing standards and putting the same ones in their place? It just makes no sense at all. The only difference in developing for the iPhone compared to the usual is screen resolution and thats about it. Everything else is fairly minuscule.

Until the iPhone starts getting in the hands of at least 5+ million people I’ll hold my breath and so will my web development practices. However, I will go out on a limb and say that if you’re a web developer building iPhone-centric web applications and websites, you’re wasting your time and resources on a dangerously low-pentration platform.

People buy passionate products. Comparing two software giants, Microsoft and Apple you can certainly tell whose products are built on passion and not just bottom-line. Build passion into your company and products and your bottom-line will fall right behind. However don’t think for a minute all passion and no ingenuity will work, cause it will crash and burn just like most web 2.0 companies have done so far.

Do like 37signals and create passion and simple ingenuity for your customers and the world could be yours. Well maybe not completely yours. (chuckles).

Lets face it guys, Mozilla will never fix firefox’s memory consumption. The End.

The Best of Best Practices

In web development it is sometimes difficult to commit to a structured process when working on a website. Thanks to the agile methodologies floating around lately, its become even harder. EE has unintentionally brought sexy back to structured development processes. EE helps me to really think about how I will organize and implement my website. This is especially important when building websites for large departmental universities.

Unlike most systems, EE has a very simple template engine and organizational structure. Instead of mashing everything together with your public presentation (like Drupal) it actually separates the admin interface. So when content managers and contributers login they are allowed to focus only on content. In my opinion this is preferred.

URL Structure and Template Groups

One joy I find in using EE is clean urls are built in and ready for production. Unlike Drupal I don’t have to sit and figure out why “clean urls” aren’t working with my server configuration. EE just works. For example in EE, lets say I create a new template group called admissions. In that group contains several templates such as index (homepage), apply and contact. EE takes that information and builds a url.

The end result is this: http://www.univ.edu/admissions/apply/.

In my opinion, that is the smartest feature in EE aside from custom fields which I will talk about in later posts. But the real genius isn’t building simple urls, its in the extraction.

Any Content, Anywhere

EE extracts everything. In some cases one aspect is not dependent on another. So if you create many template groups and templates without any content, they will still show up in your browser. Most systems are very dependent on the existence of content. This is not the case in EE and its mainly due to the fact that every template is a full web page.

EE has a content publishing structure known as weblogs. I know what you’re thinking, EE is a blog engine on steroids. While that is an easy assumption its not the case. If you look at any website, its content is generally created, updated and displayed chronologically. Even before the rise of blogs this is how frequently updated content worked aside from static content.

Using the weblog structure, EE allows you to model your content any way you’d like. Its not just for blogs. So you want to display upcoming events? Create a custom field group just for events then create a weblog based on that group.  Its really that simple. A perfect example of this flexibility can be found at jobsandgigs.com. That project is running fully on ExpressionEngine (with a few customizations and glue here and there).

Summary

All in all EE is great for organizing your website the way you want. The best part is that it requires no extensions or additional modules to do this kind of organization and extraction. For university websites, grouping your templates and content is the most important stratagy and EE gets me 90% of the way there by making it simple.

In the next installment I will be discussing implementations of templates, custom fields and modeling your content. I hope to be posting screenshots and making available the live mock university website. Stay tuned!!