Tag Archives: Programming

The 5 Best Things About Being A Developer

Posted on by John Rockefeller

I was at work today and had a few of these happen. Because of that, I was inspired to write this post. These things happen to programmers young and old, novice or expert. Here’s the list.

1. Writing code that works the first time

Oh sure. All of us write flawless code, right? There’s just something that feels great about writing a sizeable portion of code and then having it do exactly what you wanted straight away. Especially if you’re newer with a certain language. Confidence++.

2. Finishing a Project

Starting a project is exciting. Finishing is ethereal. My typical work method is based on doing all of the hard work first, thereby eliminating any unintended delays before launch. Unfortunately this means that the last 10% of any project is the most tedious and dreary as it’s filled with things like pixel-hunting or resizing images. Once the last few lines of code are written and tested, life is bliss.

3. Optimization / Refactoring / Reducing # of Lines of Code

Few things in development are as good as the feeling you get when you took that 4x nested for-loop with its switches and if blocks and converted it into a simple, 5-line function. It’s why I get up in the morning. OK maybe not that exciting, but still.

Optimization may not be the best description for this, but in a way it is a sort of optimization of how efficiently your code works.

4. Seeing Marketing For a Product You Worked On

I smile every time I visit my parents as there is a very large billboard advertising a site that I had a part in developing. I know that nowhere on the sign it says my name and that no one even knows I worked on it, but inside I feel good that someone, somewhere is finding something I helped to create useful.

Another example of this would be seeing people play a videogame you created or hearing your song on the radio (if you were a musician).

And, finally:

5. Learning Something New and Useful

I try to make it a point that every day I learn something new and useful to make my work better, faster, and more efficient. I say “new and useful” since new isn’t always better than old. Especially with computers and software.

Whether it’s some new Linux commands (split and cat for me a few weeks ago) or a big jump like using source control, making yourself and your team better at what you do is what it’s all about.

Leaving for Michigan… Excited about Yahoo! BOSS.

Posted on by John Rockefeller

Every year during the second week of July our family has a reunion in Michigan, USA. I’ll be gone for three days but I’ll have the laptop and wireless. While it’s unlikely there will be a blog post during that time it’s possible! (who can stay away from blogging when it’s so addictive, huh? Didn’t think so!).

In the mean time I’ve been given (along with the rest of the programmers around the world) a new nugget to chew on and that is Yahoo! BOSS. In a nutshell, their new API will allow you to retrieve their search results and practically let you do anything you want with them. Re-order them, put ads next to them and generate revenue, mix them with your own results, you name it. It’s really intriguing and it’s definitely ballsy.

I’ve been thinking about Yahoo!’s potential return on this investment… Why would they give away the one thing that’s made them who they are? Well first, by taking the lead they are doing a few things such as increasing their standing with developers around the world as a partner to have and to stick with, they might also be looking for Google to follow suit or come up with a comparable system (gotta love competition), and finally they might also be looking for startups and unique talent to pluck from when all us developers start really using this thing in unique and interesting ways.

Just think: Yahoo! has basically said “Here’s our search results. Show us what you think you can do with them.”

Pretty cool!!

DemoCampGuelph6 was a lot of fun!

Posted on by John Rockefeller

I got back from the 6th Guelph DemoCamp around 9:00pm last night. Free beer, free food, a group of 50 or more programmers, and one block away from my apartment. Guelph rules :)

If you live in the Guelph area and you’re interested in going to the next one, there will be another DemoCamp on the 17th of September 2008. You should be there. Presenting stuff is easy: You get 5 minutes to set up, 5 minutes to talk, and 5 minutes to answer questions from the crowd. If you just want to come listen and mingle that’s cool, too.

I presented Jack of All Links to the crowd and it went really well. There were a couple of guys from WeGoWeGo, which is a startup that’s gearing up in Toronto as well as a few other people presenting technology or software they wrote. I really enjoyed it.

I was really surprised at the size of the crowd! I figured there might be at maximum 10 people (I mean, how many programmers *are* there around here anyway) but there were over 50. Exciting!

Source Control – svn + ssh (subversion to the rescue!)

Posted on by John Rockefeller

There comes a point in any developer’s life where he/she must work with one or more people on the same project. What’s the correct procedure? How is this done? There are a number of different ways. Some good, some bad.

The Bad: You may have a method in place where only one person can be working on a file at one time. You have to notify the other developers that the file is free when you’re done with it. They download the latest copy every time and so do you so as to not overwrite the work that was just completed.

Some of you may say “Well, why is this bad? We’ve done this for months! It’s worked out pretty well so far!” There are a number of different answers to this question, which I’m going to deal with right now.

This is a bad method because time is money and this method is much, much slower. What is a programmer to do while he or she is waiting for the file to be free for editing? Read blogs?

Time is money.

If the company had source control, both programmers could essentially be working on the same file at the same time. I say essentially because technically they both have their own versions of it and the source control program (Subversion is the one I would like to write about today) will merge their changes together intelligently. Oh wait, this isn’t good. Now you won’t have time to read my blog because you’ll be working!

The second reason the “one person, one file, one time” method is bad is because it’s extremely risky for accidentally deleting work and wasting hours of productivity. As a developer, you should be constantly using and building work methods that prevent failure at any level you are involved with.

How would you feel if you worked on a function for two hours, then because someone overwrote the file with their copy all your work was lost? The reverse is also true: How would you feel if when you saved your work you accidentally overwrote a day’s worth of work and changes?

Time is money. Again.

“But before you save your file you can make a backup of the original file!” I hear you saying, way in the back. Of course you could, but how far do you want to take that methodology? Will you remember every time? Will everyone who works on the project remember, every time? What if it’s a one-line fix? “Oh, I’ll just log in quickly and fix that typo.” and the like are sentences that run shivers down my spine when thinking about using this method.

So the person logs in and fixes the typo. Because it was a small fix, they never checked to see if anyone was working on the file. So now we’ve got two changes that need to be merged somehow. I’m sure that person will be wondering the next day why the typo has reappeared after you save your file!

Okay. So what’s the solution then, smarty-pants?

The good: The solution is source control. It’s not new. It’s been tested and proven multiple times in the computing industry and there are some big players that use it. There are a multitude of different kinds that do some different things, but to the layman the simplest way to look at it is to use a common source control program called Subversion. Everyone’s heard of it, a ton of people use it. Nerds of different flavors will tell you there are better ones out there, and that may be true, but Subversion works. For a lot of folks.

The concept is simple: A project is set up in the Subversion software. Two programmers “check out” (think of checking out at a grocery store) a copy of the project on their computer or development server and work completely independently.

Programmer “Jane” and “Jack” are both working on the same project. Jane is building a module not related to Jack but in a few cases they may modify the same files. That’s no cause for concern, deliberation, or communication. They happily keep on working until their particular task is complete.

Jane finishes first and “checks in” her work by “committing” her work to the Subversion server. Everything goes as planned and her work is then “committed” to the main project files. Jack finishes his work a few minutes later and attempts to check in his work. Uh-oh! Jack’s copy of the project is slightly out-of-date! No big deal, he issues the “svn update” command and all of the files Jane edited are updated on Jack’s computer. Any changes to the files that they both worked on are merged automatically.

After he has updated his copy of the project he commits his files and goes home for the day.

Wow! Sounds great. But what happens if Jack deletes parts of the source code that Jane edited?

This sort of thing is called a conflict. They’re pretty rare and in most cases you can resolve the conflict in a few minutes. When you edit a file that is marked “in conflict” by Subversion, it shows the added and removed portions. You can make adjustments based on which is correct and issue the “svn resolve” command to consider the issue resolved then commit the correct version.

Cool beans. How do I start?

First, you install Subversion on your server. Programmers will connect to this machine, “check out” a copy of the project, and begin work. In most cases, installing Subversion takes less than 10 minutes. You should check with your particular Operating System documentation to see how to install Subversion, but in Mandriva Linux you can do it through the command-line with this command (logged in as root):

# urpmi subversion

After installing Subversion, you will need to pick a spot on your hard drive where you want your project files to be located. For me, that’s almost always /home/svn. Change directory to your project directory and type:

# svnadmin create <projectname>

This will create a directory and place the important Subversion bits inside it for this all to function. Make sure the directory (and all subdirectories) are writeable by the group of users that will be working on the project by first first changing the ownership to a particular user and group with this command (run as root):

# chown -R user:devgroup <projectname>

This command makes the project directory and any directory inside of it owned by user and associated with the devgroup group. After this you will need to set the permissions on the directory so that the devgroup has read, write, and execute access to this directory. We do that by executing this command (run as root):

# chmod -R 775 <projectname>

Great! Our project is ready to roll. Note that this assumes you have ssh enabled on this server (very likely by in Linux, FreeBSD, and in fact most others *nix variants).

Next, we’ll need to check out a copy of our project. Stay tuned for that tutorial, coming soon!

PHP Tricks: How To Handle Multiple Domains

Posted on by John Rockefeller

This is really handy for those of us who have the same code handling multiple sites or multiple sub-domains.

A case in point: When I coded NetBoardz (my free forum hosting service now defunct), I had one codebase handling all 250 forums. How? Simple. When the code runs, it determines which site the user is loading and does different things (like using different databases) dynamically.

How to determine the domain the user is using to view your site:

$domain = $_SERVER['HTTP_HOST'];
if ($domain == "xyz") {
...
} else if ($domain == "uvw") {
...
}

In the example above you can see that we have put the domain that the user has used to view your site into the $domain variable, loading the value from the PHP global variable, $_SERVER. The $_SERVER variable is global, which means you can access it anytime and anywhere in your code.

For more information on PHP’s predefined global variables to see what’s available to you, click here.

How to determine the sub-domain the user is using to view your site:

Sample code is from NetBoardz, which is based off of phpBB 2:

$subdomain = strpos($_SERVER['HTTP_HOST'], ".");
$subdomain = substr($_SERVER['HTTP_HOST'], 0, $subdomain);
$dbname = "nb_".$subdomain;
mysql_select_db($dbname, $sql_link);

Here you can see that we retreived the whole hostname, including the top-level domain and subdomain, then used the PHP functions strpos and substr to take anything before the first dot. For example, the whole hostname “testforum.netboardz.com” passed through this code would end up as “testforum”.

After, we use that subdomain name to calculate which forum database to load. Of course, once you have the domain or subdomain in a variable, you are able to handle your code as you wish!

I hope this small tid-bit of code helps you out in some way. I know that there are tons of these snippets and tips littered across the internet and while I was learning PHP they were really handy. I’ll post more over time, always in this same category.