debuggable

Update: The plot for the using git windows screencast is now available.

Hey folks,

it has only been a very short time since I wrote about Debuggable's Screencasting business venture.

Since then I have been very busy working like crazy to improve the underlaying architecture and producing a new screencast.

Let's start with the Screencast first, it is called "Using Git on Windows". In ~18 minutes you can learn how to install and use git on Windows including setting up a local repository and making a bunch of commits.

What else is new? There are two new sites. The git screencasts site has been completely redone. Initially it was really just a bunch of HTML files with 1 PHP file handling the payment processing. In fact you might get a kick out of what a terrible copy & paste job I pulled off for that : ).

But hey, I'm really playing this by the "Make it work" and then "Make it work better" rules, and it's tons of fun. Anyway, the new site is now finally a CakePHP app which will make it easy to add tons of new screencasts in future.

The next new site is the Debuggable Store. This is the payment gateway and the most interesting change. I will write more about this in future but the new setup is kind of fancy. You go to git.debuggable.com, choose a screencast and hit the buy button. You are the redirected to the store where you can actually buy the item. The store then sends you to PayPal. PayPal ping's the store when the payment has cleared and the store sends out an email with a download link. The download link is leading you back to the store which then redirects you to a Amazon S3 download url that is signed for 15 seconds. This way I can keep track of every download, ip and browser. This saves me from having to serve my files through a PHP script (slow!) which is awesome.

Anyway, what I was actually going to focus on here is: The store is independent from the git screencasts site. I'm already talking to a bunch of people who are interested in selling videos, ebooks and other downloadable files and who are looking for a payment solution that doesn't suck and can possibly be customized in future. If you are interested in a venture like this yourself, please don't hesitate to contact me.

So, go ahead and download the free using git on windows screencast - Feedback would be much appreciated!

-- Felix Geisendörfer aka the_undefined

Howdy folks,

Sorry for not getting back to you sooner. Between speaking engagements, framework releases and hard drive crashes, blog posting just gets lost in all the chaos sometimes. You know how it is.

So, today's code was randomly selected from the entries I've received since the introductory post. The entire submission is actually two files, which together comprise a console script for interacting with a web service (the names of the entrants have been withheld to protect the identities of the guilty). Rather than examine the full entry, we're going to take a look at one part which I find comes up fairly often: switch block overkill.

Don't get me wrong, switch blocks are great, especially for flow control (which makes the title of this post slightly misleading and sensationalist), but they're often overused in ways that make your code less maintainable. Let's take a look at the example:

This code takes a list of arguments from the command line, and uses them to set the state of the shell object. In other words, it is creating a mapping between the parameter flags and the shell object's properties.

A key to writing flexible, maintainable code is realizing that your applications are basically comprised of two things: algorithms and data. Algorithms are the code, the logic. Data is what the algorithms operate on, though in many cases (like this one), data is showing up as part of the algorithm: it's too tightly bound up in logic, and unnecessarily so.

Finding where data is tied up in your business logic can sometimes be subtle and hard to spot. It might help to think about the distinction in these terms. Logic (or algorithm) code does something: it causes a transition to the next state of execution within your application. Conditionals (if/switch blocks) branch, loops iterate, etc. Conversely, data code is declarative, it takes no direct action; i.e. setting a variable or object property. (Unless __set() is involved, in which case you're invoking a method anyway, so it doesn't count. Cheater.)

Now, setting a variable does cause a change of state within the machine of your application, but in and of itself, this change has no value. It requires some form of processing via logic code. With that in mind, let's take a look at the re-written example:

First of all, notice how the code formatting has been changed: things are now spaced out in a more consistent format that's easier to read, and an explaining variable ($value) has been added alongside $option, to make it more clear from the code which options support parameters, and which are stand-alone flags. When you're writing code, even if you're in a hurry, it always helps to think of the next guy. That next guy might be you in a couple months (or days) when you come back to the code and wonder what the heck you were doing there.

Moving on: as we can see, the data mapping has been abstracted out of the logic and put at the top of the code block. This means that (a) our data can expand infinitely with no logic duplication, and (b) the data can be moved around, manipulated, re-used, or loaded from an external source. This highlights another property of logic vs. data: logic is fixed and immutable, while data is infinitely flexible.

Okay... any questions/comments/snide remarks?

No? Good.

Now get outta here and refactor your code!

It's almost 5am now but I am finally done. Our new secret business idea is life.

What is it all about? Well maybe it is best if you see for yourself.

The basic problem is that I have fallen in love with git. To deal with this addiction and to put it to good use, I decided to make screencasts about git.

However, I am not talking about the stuff you see everywhere else, but real quality material. It took me probably 3-4 days to produce the first screencast about resolving merge conflicts. Lots of it was because I explored technologies and techniques for production, but I think most of the future screencasts will still take a solid day of work.

But ... I also want to make some money with this : ). So here is the deal. Some material on the site (I will write quite some text in future) will be free. I'll also publish some shorter behind the scenes videos that show some of the things I have to cut out or interesting observations I make about git.

The real screencasts themselves however cost money. I set the price to $5.99 right now for the first 13 minute long screencast. I don't know if that is too high for most people, but it I think its a good value for what you are getting. After all looking over somebody's shoulder for ~$30 / hour is pretty cheap when learning a new technology : ).

Anyway, the site needs work & touches all over the place, but I really am forcing myself into "make it work" and then "make it work better" mode here. Too many small side projects of mine died because I got caught up in details. Won't happen with this one.

Alright, let me know what you think folks - I'm looking forward to some feedback, hopefully from some people who bought the screencast as well : ).

-- Felix Geisendörfer aka the_undefined

So we are using Git here at debuggable now. It takes all the pain out of deployment:

ssh <server>
cd /var/www/<project>
git pull

Done.

Not easy enough? Create a deploy.sh file:

ssh <server> "cd /var/www/<project> && git pull"

And once you get super lazy you'll find yourself doing:

git pull && git push && ./deploy.sh

Don't forget to get setup with ssh keys so, entering passwords all the time is a major PITA.

If you are just starting out with all this web craziness and still depend on ftp & shared hosting, try to get a VPS somewhere. I can recommend LiquidWeb (~$60 month). If there is anything I wish I had done 3 years earlier, it is to get a server with root access - it is so worth it.

How do you deploy these days?

-- Felix Geisendörfer aka the_undefined

The new MacBooks look nice. But the 17" has not been updated, bummer. I'm also surprised there is no new 30" cinema display. That thing has been out since June 2004 now.

Oh well! I guess that's really good news. I'm not tempted to buy new mac hardware for a while and can invest in a new lens for the camera ; ).

-- Felix Geisendörfer aka the_undefined