Yes it may seem like when you switch over to a new revision system, git perhaps? That your brain may explode.  Or that things might turn into a major catastrophe.  Be that as it may I'm going to let you in on how I get things done at my job using git in my daily workflow.  This is by no means the best way to get things done, or the end all solution... so comments and suggestions are very welcome.

So at my current place of employment we have 4 developers coding out of the same code base.  It would seem like it would be easy enough to not step on eachother's toes, but it happens.  Sometimes it happens a lot!  Some of the main reasons:

• Whitespace in code
• Large files/classes/controllers (multiple people working out of the same file)
• Unique workflows
• Different programming environments
• Improper merges

I could go on for at least another minute or two, but you get the gist of it.  The whole point of a revision control system is to not only be able to version your code, but to also let it allow you to work succinctly with all of your team members.  So before I get into a typical day at the office, let's take a look at the structure of how our git repository is setup.

Repo Basics

I'm not going to go into how to setup a repository, how git is a DVCS, or how I like git better than SVN; but if you'd like I can do that in another post.  We're going to nail down the basics of how our repo should function and some general terminology.

First off we have a generic repository for each project.  We then use that generic repository to share code between ourselves and the deployment system.  Each developer then forks that main repository and creates their own repository of the codebase as well.  For instance our main repo might be developers/projectName@github, and my personal repository would be aronstaves/projectName@github.  The great thing about github is they provide a few not-so-common features with their repository and also have the ability to setup private and public repositories.

For the most part, each developer in our team has access to 3 repositories.

1. Local - this is each developer's git repository that's located locally on their development machine.  This is what we develop in day to day.
2. Origin (aaron/projectName@github) - this refers to the personal developer repository that lives remotely (on github).  This is used for personal backups of branches, or for pushing branches remotely that that other developers do not need access to.
3. Upstream (developers/projectName@github) - this refers to the generic repository that everyone forked their developer repositories from.  Pushing branches to this repository allows you to share code with other developers as well as the deployment system.  If the branch isn't in upstream, it isn't a candidate for deployment.

So in short, I develop out of my local branch every day.  If I have a branch I want to save for later, or possibly an incomplete feature I want to delete locally and pull down later, I'll push it to origin.  This way I'm not cluttering up upstream with various branches that other developers know absolutely nothing about, and that they probably don't care about!  If I need to share code with other developers, or give the deployment system acess to code, I'll push it to upstream.

Branch Basics

Alright! Now that you see how the repos work, let's check out how branches work within a repository.  At any given time, I'll have a minimum of 3 branches available.   Master and Release typically are tracked against the upstream repository, and the development branch is pushed wherever it is needed.  Again, these aren't rules to follow, but how I personally use git.

Master Branch

Stable Tested code.  I cannot stress that enough, only stable and production tested code should be put into master.  Once we've had a successful deployment of release code, we will production test it.  Once tested, release code is merged into master and tagged.  This branch is mainly used for breakfixes or rolling back deployment.

Release Branch

This is all code that is staged for release, but not yet tested in a production environment.  Just to reiterate, if your code is not going to get released, it has no business being in this branch.  Once code from a development branch has been tested by a developer, it is merged into this branch and put through QA testing.

I also want to stress working out of this branch is typically a big no-no.  Not only could this lead to unwanted code getting committed to the next release, but it also has the potential to spread commits for a specific feature across non-linear commits.  I'll get into the problems this can cause later, but unless you're making a single commit change to the soon-to-be released, you should make a branch for your code change.

Development

This is code that is currently being developed and is typically branched from release.  So when you want to start a new feature, you'll checkout release (and make sure you have the latest code pulled down!), then create a development branch from that.  I'll also go over a typical development lifecycle later as well.

Anyways, that's a quick high level overview of how I typically get things done in git.  Look out in the next week or two on how I branch, rebase and merge in code with other devs on my team.

At any rate, this is just a quick update to hopefully kick myself into gear for getting some stuff done.  Some things that will be coming up:

A new project!

Not like I really actually finish any of my projects but I can dream right?  So far things have gotten off to a better start than most.  I've started using codeigniter, which is a pretty lightweight MVC framework.   Toss in a little ORM magic on there and I'm set!  Right now I've got just a login page, some sessions and some inheritance vodoo going on.  All things considered it's further than I've gotten most times.  I'll be sure to post more updates as they come.
 

Revision control!

At work we've been using git for the past few months and I'm becoming a huge git enthusiast.  Problem is, there's a ton of ways to do things!  So in the next few weeks I'll hopefully have a few posts on how *I* personally use git as well as how it could potentially be used in smaller to mid-size development teams.  This topic might have to be broken out into a few multiple ones.

So there you have it.  In the spirit of keeping me honest, please hound me to get at least one blog post a week.  Sunday nights seem like as good a time as any.  You know, until football season starts.

If you hadn't heard, my sister and brother in law just had (well, he's 1 now) a baby boy, congrats!.  Given how tech savvy they both are they take a ton of movies and photos and post them online for relatives from all around the country to watch.  This is an awesome way to keep up on how the little guy is doing.  However! Given that some of our relatives may be a bit more on the less tech savvy side I decided that making an interactive web based movie page would be a good way to help them view their new nephew, cousin, grandson or great grandson.  You can see a demo of it here.

For starters, I've already done a few projects using the JW FLV Player. I use this player for a few reasons.  First off, it's free to use for non-commercial purposes!  And even if you do use it commercially, it's pretty dirt cheap.  Second!  It's got an insanely awesome javascript interface.  You can pretty much completely control the player and hook into almost every event you can think of that the player may publish. This is great for web developers that know absolutely nothing about flash but still want the benefit of a flash based movie player.  Lastly, this player is great because it constantly getting updates and there's a huge community behind it; always good stuff.

What you'll need

I did try to spruce up this player slightly so you'll need a few things if you'd like this to work on your server.

• mod_perl, along with the CGI, File::stat and DateTime packages.  I imagine most come pretty standard with a vanilla install of PERL.
• ffmpeg, compiled with png support.  I imagine a pretty standard install of ffmpeg should be fine.
• movie files, yup! you'll need some movies to view.  Right now this is limited by the type of movie files that the player natively supports.  I may add some transcoding using ffmpeg later if anyone actually uses this and wants it.

And that should be it!  Pretty simple.  I'm also using the YUI javascript toolkit, but Yahoo! has been kind enough to host that on their CDN.  So no need to download all those crazy javascript files.

How to Install

Here are some quick install instructions:

1. Grab the zip file from here
2. Make a directory on your server (in my case aaronstaves.com/movietest) where you want the files to and unzip 'em there.
3. Make a directory (if you need to) where you're movies are going to be placed.  I put mine in aaronstaves.com/movietest/movies).  This directory will need to be writable as far as your webserver is concerned.  If you already have them you can forget this step!
4. Edit the movies.conf file.  You'll need to specify the absolute path of your movie director and the url that links to them.
5. Once that's done you should be able to just go to your url and watch some movies!

Features

Sorting and Dates

I've made it so the player automatically sorts the movies by date.  The newer movies are listed at the top and the older movies are listed at the bottom.  It also grabs the date one of two ways.  1) if the date is specified in the filename (yyyymmdd format), it will use that.  2) otherwise it will grab the timestamp on the actual file.  Neat huh?! The only downside to this is is that it has to touch each file(name) to do this.  But I wanted to make this without the hassle of a DB, kind of a necessary evil.  Hopefully with 100's of files, this won't be that much of a performance hit.

Native file support

As I said above, this natively supports mp4 (m4v, etc) files as well as flv files.  So hopefully if your files are in that format, you won't have to deal with transcoding files.  Awesome! As I said, transcoding wouldn't be that hard to do, but it would be pretty time consuming on the server side, pending on how large the files were, so I'm not sure how I'd go about that at the moment.

Downloads

See a movie you like? Well download it! You'll notice at the top of the screen when you play a movie, you'll get an awesome download link.  For anyone that wants to actively share or archive these movies, I figured it would be a necessity.

Feedback

Right now I've only tested this in FF3+, IE 7  and the latest version of Opera.  If anyone finds something wrong with it, let me know and I'll see if I can address those issues.  Otherwise feedback, suggestions, comments and criticism is welcome.  This is my first mini-project in a while that I've made to "distrubute" so somethings may be clear while others may not.  Hopefully with the addition of the conf file, you won't have to touch any of the code I wrote.  This small tutorial is written for them, but anyone is more than welcome to use it if they want their own personal video page to share with others.  Enjoy!

Initially when I was using it, I couldn't understand why my page was loading so slow. When I slow, I mean slow; enough to the point that the browser would give you the whole this page could be doing bad things, would you like to stop scripts on this page? slow. Yeah I have a few XHR's here and there, but nothing out of the ordinary. The only thing I could find was that commenting out Dojo requires for the actual Grid dijit improved performance immensely, but how am I supposed to use a grid if I can't include it! I didn't really remember Dojo's demo being slow at all, so I went to investigate on their site.

Copying their example line-for-line worked like a charm. It loaded up nice and quick, no problems, no lag and none of it was my code. So I began to tweak a few things to try and get my data in the grid. First off, I noticed that they were making their includes from the AOL CDN. I've heard about this but never really looked that much into it (as I probably should have). So I took it out, and replaced it with includes from our DreamHost server. Upon doing that, and reloading, this is where the slow down was from.

Don't get me wrong, DreamHost is a great hosting company, but lets face it - you get what you pay for. $90 for two years of hosting, you can't really expect to get lightning fast connections and/or a dedicated machine as your server. Their notorious slow load times had to be the bottleneck that was killing my code. For those not in the know: Dojo require statements essentially make requests to grab all the dojo files that they need. For a heavy duty dijit like the grid, this can add up to a lot of requests! And making these requests through the DH server was what was slowing me down.

So basically, using AOL's CDN to host all the Dojo includes make things insanely faster (load times below!). I guess fast javascript isn't enough, but when dealing with massive JS requests and includes, having a fast host is just as important. Lesson Learned!

DreamHost Hosted Example - Load Time: 27.86s

(link)

AOL CDN Hosted Example - Load Time: 2.96s

(link)

Wow.

From what I gather, a wireframe is just that a wire-frame. It should purely consist of a layout, with the possibility of some actual production CSS in the page. The articles suggested that there are two main ways to do this:

1. Create a page for each "flow" of your application.
2. Create one page with a "stacked flow" of your application.

Basically, a flow is the various screens/interfaces that the end-user will be presented with. They give a nice "login" example (one which I actually made one of my own as well) with a "stacked flow" wireframe. You can see my example of that here. Comments are welcome, but keep in mind:

1. I'm not a graphic designer
2. This is my first crack at this
3. It's 2am... and I'm making wireframes...

Needless to say, that's kind of how I feel at the moment. The actual prototype, which I plan on using YUI for will probably come out tomorrow or sometime next week.

The reason I actually went through and made a wireframe, is because I'm attempting to get some sort of side project going for myself (yet again...) so I can play around with some new things. These things being YUI; as mentioned above, Python; which I've been somewhat getting into and web frameworks - namely Pylons. So tonight at least I got some wireframes done for the login, the next step will be to learn some YUI and get some fake data going for the prototype.

Lastly, I (possibly re)learned some interesting things today regarding CSS. As you can see in the source for my wireframes, I'm actually using display: table. Insane! I've never actually used that, ever. I initially had a pretty descent layout, but when looking at it on my Nokia N800, it looked completely borked! So the only way was to make div's within my login box actually span set percentage widths.

Now you're probably saying, whoa! Just set a width on that puppy and your good to go. Wrong! Since I wanted somewhat "tabular" data, consisting of two rows, and two colums. Each row being 100% the width of the box and each column being 50% of the row, there was no way to do that using pure css and not using tables. This is for two reasons:

1. Div elements are initially set as display: block. This means there is a line break before and after the element. So there's no way to have two "columns" side by side.
2. Inline elements (or elements set to display:inline!) do line up side by side; however!, they will only take on as much width as they need, and don't respond to width: styles. They may use the width attribute in some browsers, but not what I was testing it in (FireFox 2).

So I came across an article talking about using display: table. And really, it couldn't be simpler. Parent element needs to be set as display: table. The children of that needs to be set as display: table-row. And the children of the rows need to be set to display: table-cell. The only downside, is there is absolutely no support for colspan or rowspan in css or the markup. Even if they did work, it looks like the CSS for those will be depricated in CSS 3 and replaced by some other multi-row/column attribute.

So all in all, a night of learning pylons, which I'm really starting to like. And hopefully I'll keep cranking out these wireframes/prototypes and get good enough at them so I can actually use them in my daily work. And although I'm posting more now... I hope I don't make a habit of posting at 2:30am : (. Next time I'll hopefully have some stuff on prototypes to discuss.

\

Awesome 90's cartoons aside, there are things that we can learn from the user! The past few weeks I've been re-desiging a lot of the web user interfaces here at work. I've found that when I'm given a chance to update an already designed UI, I can pretty much copy the old style and just give it a "web 2.0" boost and add in some new functionality - no biggie. But when given a completely new projectthat is done from scratch, I start to get a bit lost.

The reason I bring this up is because last sprint I was given a chance to make a new web tool for some of our in-house support staff to use. This tool replaces some minor SQL query's that I would do on a day to day basis, so I was already pretty familiar with the project. Initially I threw together what I thought to be an all-in-one awesome bone-crushing tool that did everything it had to... and more! However! Upon dropping this tool on our support staff, it became readily apparent that they were not terribly familiar with all aspects of this particular system, and had no idea how to use my brand new shiny tool. Oops! Looks like my user interface doesn't fit the job!

In all fairness it is completely my fault, because I was trying to make a tool that I would use, and not a tool that your average Joe User would use. So after going over my UI with some of the people that were actually using it, I got some input and tried to see if I could possibly improve upon my abomination of a webpage. Now here's where I get into my UI design. I assume everyone has pretty much heard all of these before, but this seemed to really hit home for me this past week - so I'm putting them up anyways!

Simplicity! You'll hear this time and time again about making things easier for the user. And most of the time, they're probably going to be right. My first iteration had a real classy whiz-bang multiple selection drag and drop interface, when this clearly was not even needed in the end-user interface. It was just going to be a new thing to learn, and a new widget full of potential bugs. So that got scrapped and replaced with a table layout using divs. This way the user can just focus on one element at a time, and it makes handling the data immensely easier on the programming side.

Dialogs are also an amazingly easy way to make things simpler. Everyone has seen them, everyone knows how to use them and it's no surprise when one pops up. Using dialogs completely changes how a page can be viewed. Instead of displaying all information all the time, just display a lot of very specific information when a user requests it. This not only makes your layout a lot cleaner, but also allows you to separate functionality from various sections of the page.

Consistency! Granted, with a lot of the new javascript libraries such as dojo an YUI, there are lots of awesome widgets at your disposal. The problem is - is that if the user doesn't know how they're supposed to work, how is that actually helping them? This was pretty apparent with my drag and drop widget that I mentioned above, but simple things like common layouts as well as how the data is presented also have a huge impact on how well the UI is received. So in keeping with the above comment, simple and consistent seemed to be the way to go.

Quick and Verbose! So obviously with the newly (re)discovered XMLHttpRequest techniques, this gives an opportunity to make people not have to navigate from page to page - like it was 1995. Using XHR's to speed up saving or loading data in the background makes pages appear to be loading faster as well as makes the user happy. Win-Win! The only problem is - is that you still need to let the user know what's going on. In most cases a simple throbber will do. So along with the verboseness, some helpful messages are always nice as well. If creating a pdf is going to take a few minutes on the server, maybe you should let the user know that. This way, hopefully, they'll think twice before actually calling in and complaining about how your site is slow.

So all in all, I cranked out my re-designed tool over the weekend and Monday morning it was getting put to use. Everyone that's using it seems to be a lot happier and more comfortable with the tool, which makes me a lot happier because now I no longer have to be diving through SQL to make minor changes. Obviously no UI is going to satisfy everyone, but following the above will at least get me started on the right track from now on. I also find myself drawing about 10 to 15 drafts of what I think the wire-frame should look like before I even start coding. This is a pretty big step from where I was 2 years ago and so far it seems to be working well.

I apologize for the lazyness in posting, but I have been somewhat busy between work, side projects and other things. So hopefully I can get back into the habit of posting.