Thursday, December 03, 2009

Simple Ruby Script for Source Code Reviews

Early today I wrote a simple script to help me get up and running quickly for source code reviews. You can check it out at http://github.com/medelibero/CodeReviewTools. It is nothing too special but it will save me a little bit of time. The only dependency for the script is the spreadsheet gem which can be found at http://rubyforge.org/projects/spreadsheet/. The nice thing about this is that it doesn't require OLE so you can run this on OSX and Windows and maybe even linux (I didn't try that OS).

Well I hope this is helpful for someone else, which is probably why I am posting it here :).

Tuesday, October 20, 2009

Weird Outlook 2007 Image Cropping

One of my clients recently added a third image to a newsletter they send out. This image like the other two was 120 pixels wide by 600 pixels high. Everything was all fine and dandy until one of them started to have issues with it displaying correctly in Outlook 2007. After a bit they called me into look at it, it was a fun little issue and during this time I found a rendering bug that is pretty annoying in Outlook 2007. This post hopes to explain the bug so other people can realize that it exists and work around it.

Background:
For Outlook 2007 Microsoft decided to switch from using Internet Explorer to render the display of the email to Word which was being used to compose the emails. I understand why they did this: removing dependencies, less security risk, blah blah blah. So, I don't think they are stupid for doing it but this bug is kind of an annoying corner case. Anyways, throughout this article remember that Word is being used to render the damn email.

So a setup for the email:
1) It was an HTML email
2) Like most HTML emails I was using tables for the layout because email clients are pretty far behind how browsers work
3) There was one column with three images that where all 120 x 600

Below is a rough layout of the email template -


As you can it should not be too hard, right? This is how Outlook 2007 renders it:

Wait why is there that huge ass gap?! The problem lies in the fact that Outlook messes up rendering when you have a table and a total of 1800+ pixels in image height. Remember how I said Outlook was using Word for rendering? How does Word work? It uses pages right? Which is actually the problem if you took an email setup like the one described above and put your cursor a little above the third image you would be able to drag around the page divider, sigh. How it works is that if all of the images can't fit into one page it will take the next image and move it to the next "page." Which screws up the layout of the email, nice....

During this whole process I thought of a few different hacks like what would happen if I put in a really large image like 1,900 pixels high could I force Outlook to expand the page? Nope! Here is a screen cap of an email with a large image in Mac Mail and in Outlook 2007.


Outlook 2007 is on the left and Mac Mail is on the right. I could have replaced Mac Mail with Outlook 2003, Mobile Me's web renderer, gmail, etc... If you look at the large image you will notice that Outlook 2007 has eaten the first 150 pixels of the image. You can even replicate this issue by creating a two column table inserting a large image (1900 pixels high) into one of the columns.

Well hopefully this explanation will prevent some head banging for other people. Now I need to get another cup of coffee.

Labels: ,

Wednesday, September 09, 2009

Lessons Learned From Going on My Own

I have been "on my own" as a freelancer for the last 2.5 months and I wanted to record some of the lessons and observations I have had in that time. My situation is a bit different (although I am sure I am not in an absolutely unique situation) than from what I have read in related articles. First off what makes mine a bit different? Two things:
1) I was moonlighting for the past 5 years so I had time to build up some recurring clients
2) I focus on development and application security (instead of one or the other)

So what have I learned?

1) Cash flow is king - very common saying but when you are on it really hits home. If you don't have enough money saved up to take on a longer-term project you can miss out opportunities (yep, I didn't have enough saved, sigh).

2) People don't give a crap how busy you are - People just want their stuff done and they don't care if you have been thriving on 4 hours of sleep and have 50,000 other projects going on you should have scheduled better. This is something I knew already but once again it really hit home when I went on my own. There is a bit of truth in both sides of the coin on this, scheduling your work load is important but clients can also be pretty demanding (if you let them be).

3) Plan for 4 to 5 hours of billable time a day - I heard this but I thought people were full of crap. I planned out my hourly rate for working 8 billable hours. This was stupid! Like head slamming against the desk stupid. I would even say plan your billable rate for 3-4 hours a day and be done with it. I work more than 3-4 hours a day but that cushion for crap days and other shit is just a good idea, imho. So, how long does it normally take me to work 8 true billable hours [note: composing an email, reading RSS feeds, facebooking or researching that one project is usually not billable]? Usually 10-12 hours depending on if I am on-site or off-site.

4) Working from home rocks and sucks all at the same time - I love working from home but sometimes it sucks. The dogs want attention, your significant other wants attention and then there is always that movie you have been meaning to watch :). Anyway, over all I enjoy it but taking a break and working at a coffee shop for a few hours or grabbing some lunch with a bud is a great way to break up the solitude.

5) Remember to take a break - For awhile I was just busting ass and feeling like I was never getting stuff done. I think taking a break to read a book, watch some TV, hang with humans, etc.. Whatever it is, is just a wise idea or else you get burnt out way too quickly. I mean really does that project need to get done right now? I highly doubt it, even if the client says it needs to most of them won't notice an hour difference from my experience.

6) People won't be immediately pounding on your door - It took about three weeks for me to get fully booked. Granted this was with business relationships already started and people knowing I was going on my own. I could only imagine that it would take a lot longer if business relationships had to be formed, etc...

I am sure I have tons more lessons learned but those are the ones I can think of and I need to get back to work :). Going on my own has been great but it isn't easy that is for sure. As I have said to people before I traded a job working from 7Am-4PM and having weekends off to working from 7AMish to 10PM with no time-off. The trade-off though is I get to help a lot more companies and learn a lot more which is what I enjoy.

Well off to refill my coffee cup and start slinging some code!

Labels:

Thursday, August 13, 2009

Creating a Splash Page in WordPress

Earlier this week one of my clients asked me for help on creating a splash page for a blog they where setting up. I of course said sure and figured it would only take like 2 minutes. Sadly, that wasn't the case there where a few issues that we ran into:
1) The way the blog was setup the urls looked like /?cat=16 instead of url-friendly
2) There was no way to specify a default blog page
3) The client didn't want to move the blog to a sub-folder (understandably)

The first solution I had was to set the default page but without modifying WordPress itself some of the links would just return you to the splash page. After a bit of messing around with .htaccess I finally came up with these two lines of code:


RewriteCond %{QUERY_STRING} !.
RewriteRule ^$ /splash.php


Basically what it says is if there is no querystring specified and the url is an empty string go to the splash screen. That is it and it worked!

Labels: ,

Saturday, August 01, 2009

What do you suck at when you develop code?

Everyone has a weak spot or a place they suck when doing any task, hence catch-all phrases like "no ones perfect". Since I am a developer I tend to look at development practices in general to see what could be improved or things that constantly happen to other developers. One thing I find interesting is how people cope with the thing they suck at the most. For instance I tend to rush things. Sure I get the code done quickly but usually it comes at the price of not fully testing the code I have written and bringing bugs into the system. If I remind myself to slow down then less bugs show up, shocking I know :). But what about other developers and the issues they have? I have seen all sorts of things like:
- Not seeing the forest from the trees
- Not taking the time to think of code maintenance down the road
- Not caring about usability

So, how have different people coped with the issues? I feel there are a few different ways you can cope with any short-coming you may have they are:
- Use a tool that helps you gain strength in a given weakness
- Find a buddy that is strong in your weak area
- Avoid the area like the plague
- Ignore that you have a weakness and think you are perfect :)
- Try to improve in that area

Use a tool that helps you gain strength in a given weakness:
This is a pretty good way to solve the problem if a tool actually exists and it works with your workflow. It is pretty rare to find such a tool for your given problem though but since we are a developers you can always just write a tool. For example if you tend to create lower quality code that is sloppy using a tool like FxCop could help increase your overall quality.

Find a buddy that is strong in your weak area:
What we can't just do stuff in a vacuum? Having this as a solution rocks but can also be difficult since you have to find someone that also meshes with your personality and has the time and want to help you. Hopefully their weakness is your strength so both of you can tradeoff in helping each other out. I have seen this work before but it seems fairly rare. Also, besides finding a buddy you can always hire someone to cover your weakness. For instance in my case it would be possible to hire a software tester to find issues on my code to minimize bugs that get sent to clients.

Avoid the area like the plague:
This is one of the simplest way to fix an issue you suck at. But it is also not always possible or it could be very self-limiting. For example if you create very poor UIs then maybe hand that off to the weird design dude that loves his mac and prefers doppios over that tall skinny soy latte.

Ignore that you have a weakness and think you are perfect:
This is like buying a mirror to make you look slim when you weigh 600+ pounds. Sure it makes you feel better but it can be annoying and disastrous. Sadly this seems to happen with a lot of people.

Try to improve in the area you suck at:
I personally believe this is the best solution but it is also the toughest. Trying to fix the issue you might have will take awhile and you have to remember to get back on the horse when you fall off. Some things I have read and done to fix pitfalls is by reading about the topic, consciously remembering the issue and catching yourself when you get into your old ways and having someone there remind you when you mess up.

I am sure there are other ways to fix being sucky at certain things so if you have a few ideas feel free to chime in :).

Labels:

Tuesday, July 14, 2009

Refactoring - Sometimes it gets messy before it gets clean

Recently I tweeted.
About to put my refactoring skillz to the test. The challenge a 27,000+ line "class" for a delphi CGI.


I am still working on this little side project and it has been pretty fun so far. One thing for sure is that just like many cleaning projects it always seems like it gets a bit dirtier as you throw stuff around before the project gets cleaner. Right now if I just checked in my code it would be bad, very bad. The code is brittle at best and the coupling between modules is so high it might reach into space. But hey it is just a first step and what does this first step look like?

It follows the general advice to look for similar functions and put them in their own code files. Note I did not say class. Since I have so much code to wade through I did not want to figure out on my first step all of the places I had to instantiate a new object and call it, plus I would have probably gotten the class wrongly designed in the first place. So, I mainly just referenced the different code files in the main class and made them static methods for the time being. Some of the code files turned into what would be expected like file utilities (deleting temporary files, writing to common locations, etc..), HTML utility methods, etc... I am not a huge fan of utility "classes" but wading through 800 lines of utility code and figuring out a design for common items is tons easier than wading through the gigantic mud-ball that currently exists.

Once I moved a few of these general functions around I started on something that would make a bigger impact and would be a little tougher. You have to understand one thing about Delphi is that it is a RAD language I don't mean it is cool I mean it is a Rapid Application Development language, what does that really mean? It means it turns into a huge event-driven mess that makes grown men cry when a button event, updates a field, which fires an update event, which updates a field which updates some dataset which then fires another event, you get the idea. All of these reports had events tied to them which meant a lot of code to move and a lot of interdependencies that would be "fun" to move, but hey I was up the challenge :). I did what any sane code-junky would do I copied the report objects into a new class and then leaned on the compiler like I had just finished a fifth of vodka on my own. To get the code to compile and be functional I had to pass in a reference to the monster class. This means there was now a recursive dependency between the two which is not prime but like said earlier it is a start and this was one of the messy parts of the code. To give you an idea on the interdependencies I tried to pass in the needed parameters for a method but I gave up after the parameter list grew to 15! Once I got this area to compile I then did some quick functional testing to make sure the program was you know still usable.

At this point I had shuffled around 4,000+ lines of code and things where looking slightly better and there was at least a glimmer of hope. What are my future steps? I plan to continue to look at the methods in the monster class and bucket them out to code files. After that I will start to move them into classes, implementing interfaces and hopefully writing some tests. I will write about my progress at each step of the way. If there are any questions on how I am doing something or advice from other people who have tackled similar monster classes that would be awesome.

Labels:

Sunday, June 28, 2009

Good times ahead

As many/all people who read this blog know I have been doing freelance work on the side for the past five years. Many of those years I would say stupid shit like "once it gets a little bit busier I will go on my own." Realizing that is a bit like saying "once I get XXX amount of money I will be fine" (which is never true, btw) I worked out a middle ground with my lovely fiancee and am going on my own as a freelance developer/hacker starting on Wednesday. It is pretty exciting and scary all at the same time.

What does this mean for whoever reads this blog? Not too much. I will still post here but I am also going to be creating a company blog in the next few weeks. I am not sure if I will cross-post or what but I would expect that this blog will have a bit more of a personal flavor to it. Well wish me luck because I will need it! :)

Labels: