Lessons learned from a receptionist

Ok, this is probably the most obvious statement in the world (to anyone that knows me, at least) but I’m a huge fan of NBC’s The Office, and in particular, the story of the receptionist, Pam Beesley.

Since the start of the series, she’s been the sweet, downtroddden girl – the quiet wallflower of the office. Once you get to know her character, you can understand why. She’s had a very contained life – same boyfriend since high school, same job for years. If you’re in a situation like that, you get used to the flow of things and they start to become standard. It’s easy to ‘forget’ how to fight back, how being ‘alright’ with how life is going can be a blanket of security, and you hide behind it rather than pursue what it is you would really like.

This last season was a big ‘growing up’ time for Pam – she called off her 4 year engagement (and 10 year relationship) with that jerk of a fiancé, got her own place, started pursuing her hobbies, and in the last few episodes of the season, she learned how to stand up for herself and be fully honest – even if that honesty is scary and uncomfortable.

And much to our delight, her new honesty came with a big reward – the possibility of a new beginning with her best friend and confidant. While some will say that it’s silly, and it’s just a show, her character’s transition this season really got to me.

It’s all too easy to be that person who isn’t really happy with their situation, but too unsure to change things up, because change is risky. It’s easy to sit back and let others make decisions for you, and shape the life around you. What’s not easy is understanding yourself, what you want, and taking steps to get there.

All too often I find myself in the same footsteps. Knowing that there could be better things out there, but too stuck in the current to do anything about it. Seeing Pam step up (and succeed) has been a bit of motivation to me, a reminder that sometimes you need to step out of your comfort zone to get ahead. And although it’s scary at first, as I’m learning, the scariness soon fades and changes to a tone of excitement.

And that’s a wonderful feeling.

Programming standards, anyone?

So, the blog’s been pretty dead recently, which is the exact thing I didn’t want to happen. But what can you do. The ‘life’ has been a bit hectic as of recently, but things are moving in the right direction, so it’s a good thing.

Today I feel like ranting… but not just any kind of rant. Hopefully it’ll be a constructive rant. If that makes any sense.

So my rant is all about programming standards. Over half of my job consists of going into existing code and performing maintenance on it, and to be honest, it’s one of my least favorite parts of working in the web industry. Maybe I’m just slightly obsessive over the cleanliness and readability of my own programming, but I’ve always been a really strong believer that the code you write should have meaning; six months down the road you should be able to re-open your old code and know exactly how it works.

The thing is – this is where the rantiness comes in – the standards of programming needed to keep your code maintainable are so simple that anyone can incorporate them! Also, these techniques were taught to me in the most fundamental of programming classes I had, dating back to high school. It doesn’t take any more time or effort, and the benefits you gain from it far outweigh any possible headache.

So what are these techniques? Let me mention a few of them:

1. Use variables with meaning
   Seriously, why isn’t everyone doing this? I know typing $x might be slightly quicker to type out as you’re programming, but six months down the line are you really going to know what $x = $a*$b+$c is going to mean? Are other developers who come in to maintain the application going to know what it means? Chances are they won’t – and they’ll waste more time trying to figure it out than the time you saved by typing ten less characters.
2. Comments, comments, comments!
   I always comment my code – perhaps I get a little too verbal sometimes, but I like explaining my programming process as the code flows. For instance, if I’m creating a function, usually I will have a short description of the function before it opens, and then within the function I’ll have brief, one-sentence comments on ‘code milestones’. In addition to making the code more understandable by providing other developers (and even yourself) with explanations of what your code blocks are trying to achieve, it helps out during the programming process as well – often times I’ll ‘comment out’ my process before I even start to write any code.
3. Consistency is king
   This one, I’ll confess, actually does take some effort, but not as much as you might think. When making changes / additions to existing code, I’ve always found that it’s best to try to emulate the original programmers ‘style’, as to keep consistency through the life of the app. Now, I’ll stick to the standards mentioned above; just because the old developer was using $x for everything doesn’t mean I’ll keep that, but with things like the use of include files, functional vs procedural programming flow – sure I’ll try to copy that as best I can. That way, when the next developer comes in, they don’t have to wrap their brain around 2 (or 3 or 4) different programming methods.

Like I said before, these are fundamental things, and it’s just a short list. Part of me even feels weird making a blog entry about something so obvious, but this type of programming is (for some reason) not being picked up as it should. Hopefully one day I’ll live in a world where I don’t dread going into someone’s old script for some maintenance.

I Wish Drupal Could…

At work, I’ve been using the Drupal Content Management System more and more. Since we picked it up as our ‘de facto’ standard for CMSes last year, it’s been an interesting journey to get over the Drupal learning curve and start to become a Drupal expert.

For those who are not in the know, Drupal really is a powerful CMS with huge potential. It can be modified and tweaked till it’s almost impossible to identify as an out-of-the-box (and open-source to boot) CMS. There are hundreds of pre-built modules which you can install for custom functionality, and with the huge, supportive user-community behind it, Drupal looks to set the standard in open source CMS solutions.

I’m currently wrapping up my fourth Drupal site, and along the way I seem to keep running into the same issues – things I wish Drupal could do that they just fall short on. I figured I’d make a list and post it on here, because there’s still so much I need to learn about Drupal that perhaps these answers already exist! Half of the reasoning behind this blog is to get feedback from the developmental community. Go ahead, Drupal fans, help me out here:

1. CCK nodes in Drupal need better overall support for multiple file uploads. Right now to create file uploads on content you need to create a file upload box for every attachment – it can become quite ugly when you want to create a content type that can have multiple (like – 9) uploads.
2. While Drupal 5 did a great job at allowing you to have a separate admin template, there’s still issues with it – I would think that the content creation page would fall under the administrative section and thus be displayed with the administration template, but instead it uses the primary site template. Since everything I have created for clients has called for a custom template, it becomes extra work to style the add pages so they look good with all of the form fields.
3. When you create a custom view, it becomes difficult (read: impossble) to be able to create a custom display for it. Now, there is the Template Wizard, but that seems to require that you create your custom views using the list / table type, as when you do Full Nodes for your view type you don’t have options with the Template Wizard like you would otherwise.

I may have had my problems with Drupal at first, but the more I use it and learn the ins-and-outs, the more it’s growing on me. They’ve come a long way since release 4, and if they keep improving like they are, the future is looking bright.

Current Music Obsession: TV on the Radio

For about the last week, I’ve been growing more and more addicted to TV on the Radio. They’ve always been a band I’ve liked, but I really only knew them from their more well-known songs (like Staring at the Sun). Recently I got their discography, and decided to stick their newest release, Return to Cookie Mountain, into my car’s CD player. I had been feeling a bit bored with what I’d been listening to recently and wanted a change.

I wasn’t let down. This band is all about rhythms, and they’re masters at it. They can make even the most off-beat sounds flow smooth. It seemed the more I listened to them, the more addicted I became. I branched out and started listening to their other albums, and their evolution as a band is interesting.

Like many other bands, TV on the Radio’s first release – OK Calculator has a very different sound than the rest of their albums. It’s a rough release, but they had a really good offbeat sound – and they’re funny! Songs like Robots and Buffalo Girls really impressed me.

Their next album – Young Liars – sounds completely different, and in all the right ways. This EP blows me away – I actually would probably marry it. The introduction of Kyp Malone added a fuller tone to the sound, really evened everything out and created this very unique offbeat flow. Their newest release, Return to Cookie Mountain, which came out last fall, shows another step in the evolution – it feels like they’re being a bit more offbeat – experimenting with rhythms more. The album grows on you – and you’ll grow to love this band.

Frameworks: Light on the SQL, Please

Cake, the rapid development framework for PHP, makes life 10,000% easier for developers everywhere by providing us with an ActiveRecord pattern for performing the most used database interaction methods: Create, Read, Update, and Delete (CRUD). It’s modeled closely off of Ruby on Rails’s ActiveRecord, for those who are more familiar with that framework.

As a Rails developer I’ve seen the limits of ActiveRecord, and the performance issues it gets when dealing with large, complex database types. But to be honest, I’ve never been a big fan of the Ruby language, and part of me assumed that was just Ruby being slow. I was convinced that with a good framework, ActiveRecord could be used (efficiently) in complex database environments.

Yesterday that blind faith was taken to the test as I attempted to optimize a CSV generator. The problem was simple: the query which collected a table’s information, was producing an array which was way too large – the database table had close to 60,000 records and at 9.something MB, was throwing PHP memory allocation errors left and right.

Right now it stands at Heavyweight SQL: 1 / CakePHP: 0. However, I am determined to find a way to make complex databases work well with Cake – I still have a lot to learn about this framework, and I have belief in it.

Universal Font Sizes

I’ve always been a big supporter of hackless CSS. 99% of the CSS problems I’ve experienced have to do with rendering order and browser assumptions – for instance, when you set a float to something in Internet Explorer, by default it does not depreciate that element to inline; however that practice is followed in Firefox and Safari. It’s by learning these differences and putting catches in that you can successfully develop anything hack-free.

However, there’s one thing that I have never been able to get around without filters, and that’s font-sizes.

Font sizes can be called in three ways – using pixels, ems, or percentages. Setting your font-size in pixels is optimally ideal (although I could get into many fights with some of my college teachers about this) – we’re web developers, we live in pixels. We’re familiar with them, and we know how big a 10px font looks on the screen. Besides, ems and percentages are too relative to the browsers – 1em in Firefox is not the same as 1em in Safari.

So why not just use pixels? Well, technically you can, and it works cross-browser, cross-platform. However, there’s a catch – if you set a font size to a pixel amount in IE – it’s stuck at that size for life. Even if you adjust the font size in your browser settings. It’s a total accessibility crutch for close to 80% of the web viewing market.

So, if we want to develop accessible websites, what do we do? In college, I was taught to use ems, and it was all very defended: they’re fonts, after all. Set your font and get over the minor inconsistencies. It might have worked in Advanced Web, but in the Industry you have clients and designers breathing down your neck – they don’t understand why the font is slightly bigger in Safari, and they don’t like it.

So what do we do? The only real solution is in IE filters – sometimes they’re just a necessary evil. Luckily, the font-size problem is only in IE6 and below, so one simple star filter can allow you to set browser font-size in pixels, but in IE, use ems.

html { font-size: 10px; }
* html { font-size: .8em; }

For the rest of your font adjustments, feel free to use percentages or ems – everything will be relative to that base font-size setting.

Cheering for an American Idol

I must admit that before this season, I was never interested in American Idol. It seemed too pop culture; the kids could sing someone else’s lyrics, big deal. But this season I got into it early – having 2 channels narrows down what you can watch on a Tuesday night, and American Idol seemed as good as anything. I’d get some good conversations at work at the very least.

In the top 24 I noticed Jordin Sparks, a young kid with a big voice. I was immediately impressed, but it seemed like the masses tended to forget her, preferring early favorites Melinda and LaKisha. It wasn’t until the British Invasion week that people started giving her credit.

It’s great that they did, too! She’s got such a talent, and she’s so young – she has her whole career ahead of her and there’s no doubt she’ll be a success. I’m cheering her to make it to the finals, and even though Miss Doolittle will likely take the win, Jordin’s music career is going to be a great one.

The Power Behind Frameworks

Ever since discovering the Ruby on Rails craze last spring, I’ve been falling more and more interested in frameworks. It’s quite amazing how they help web developers not only develop applications faster, but create them with less code, cleaner code, and more maintainable code.

New frameworks are popping out all the time, and it’s really amazing that this is starting to catch on in the web industry. Ruby has Rails, PHP has Cake, Python has Django… and that’s just the top of the pile.

However, not all frameworks are created equal. In a world where everyone and their mother are getting on the framework bandwagon, one must be wary of what they put time into learning. All too often you find a framework which has become too bloated with features, backwards code, and crappy documentation. But when you can find a good framework and connect with it – well, it can be very empowering. A small development team can take on the world.

So this got me thinking – what makes a framework a great framework or a crap one? What are we, as developers, gaining from frameworks and how can we best utilize them without fattening them up like a Thanksgiving turkey?

The power behind a good framework is actually quite simple, and has been in process for eons. It’s really a method of standardization for programming. Back when we would judge distance by our hands and feet, everyones beds were different lengths. Just like now – we see a programmatical goal – we need to make a affect b. Without frameworks, chances are we’d all program it slightly different. What good frameworks do is set us up with conventions to program – a sub-language of sorts which unifies programmers.

But what kinds of conventions do we need? If we try to cover everything, we’ll end up with a big jumbled mess of 20 parameter functions and an API that scrolls for years. A framework which knows its limits is always going to win over a framework which tries to do everything for you. However, there are several standard conventions which greatly improve frameworks. At the most basic, some really important ones are:

• CRUD functionality
• MVC architecture
• Helpers, Components, and Partials
• Support of 3rd Party Libraries

Why these? Lets dig a bit deeper into the benefits of each:

CRUD FUNCTIONALITY
CRUD is one of the neatest things to come about in the in the web since the conception of standardization. If you’re not up on the buzzword, CRUD is an acronym for Create, Read, Update, Delete, and refers to the MySQL functions you find yourself using a hundred times a day. With a good framework, no longer will you have to connect to your database – it’s been done for you. Your table? Selected. How? Standardization of your code lets the framework do all the redundant work for you. CRUD functionality is now down to a one-line process, drastically boosting development speed and cleaning up code.

MVC ARCHITECTURE
The MVC Architecture, to me, is just beautiful. The ability to separate your database code from your processing code and presentation code is the best possible way to develop. Separating code always helps keep it maintainable – the less you have to echo out HTML statements with PHP, the better. Separating your code into database logic, the application layer, and presentation logic is a very well-organized and efficient logic when you get right down to it.

HELPERS, COMPONENTS, AND PARTIALS
In an MVC world, where code is separated by it’s software role, one might think that this isn’t very DRY. If every view requires a navigation bar, wouldn’t copying and pasting the bar through every view seem a bit redundant?

Well, this is where helpers, components, and partials come in.

These three types of files allow code to be reused through multiple areas of the project. Think of them like the guys at concerts with all-access passes – one partial can display code for every view file in your application. Helpers, components, and partials play a huge role in DRYing up your code, and all the while make it way more maintainable. That horrible nav with the overlays you programmed? It’s stored in it’s own partial – and calling it out on your view pages is reduced to a single line of code.

SUPPORT OF 3RD PARTY LIBRARIES
Since we’re not trying to have our framework do everything for us, there are times when we will need to do something that’s outside our framework’s scope. Cake, for instance, does not have built in support for RSS feeds, but does that mean that we could never tap into an RSS feed?

Not a chance. Just like frameworks, development libraries are popping up all around us. Javascript alone has dozens – from scriptaculous and prototype to jquery. Any good framework will allow you to be flexible with third party libraries – and a great framework will provide you the means to integrate these libraries into it. It shouldn’t be a surprise that most frameworks come with a Vendors folder, or something similar to place and hook up your third party applications.

The Future is Transparent

The last issue of Wired had an interesting set of articles about how being completely transparent in your business is the trend of the future. It’s a grassroots movement in a way – small companies would blog about both their successes and their failures, making public note of the lessons learned in their businesses. This is extremely common in web-based companies. In a world where everyone’s blogging on a daily basis, there won’t always be good news to talk about.

But as a business, do you allow your employees to be transparent, knowing your clients may read what they have to say?

Companies are starting to spill the beans, and people are listening with open ears. One of my favorite examples (of course) is PayPerPost.com – between the blog and the reality show, they’ve proven to be pretty transparent. It seems to be working – and rightly so. The web industry changes so fast, there’s no way we can always develop flawless cutting-edge web applications – we make mistakes, but we learn from them.

It’s why transparency works. Blogging about your mistakes as well as your successes builds authenticity. If your reader is relating to you as a person, they’ll be more forgiving when you slip up.

But if you get in this game you have to be honest. Completely honest, because in this world of Google you’re only as good as your ‘net rep’. Being caught in a lie is worse than not being transparent at all.

So is transparency the way to go? I suppose only you can decide for yourself and your company, but personally, I think it’s a great idea, both as a professional and a consumer. There’s a level of trust on the Internet, and it should be respected.

Introductions

I’m one of those people who think that all blogs should have an introductory post – one which summarizes what the blog will be about and gives a little information about the author.

So here we go. My name is Jade Rauenzahn and I’m a web developer. By day I work for MindComet, an interactive advertising agency in Maitland, FL, where I’m constantly challenged to come up with new concepts and web solutions. It’s fun, and it keeps me on my toes.

The tone of the site is both personal and professional – on most days I’ll be blogging about the dailies of being a web developer, but the occasional post about my interests or personal life might slip in.

Oh, and I’m not really one for formalities. I wouldn’t say I’m a vulgar person by nature, but if you’re the type to get upset from mild language and sarcasm, it’s best you find another blog.