5 Project Management Lessons I Re-Learned

by Buddy Lindsey on May 28, 2013

For the last few weeks I have spent a lot of my free time rebuilding the GoDjango site. GoDjango has been a lot of fun, and I have felt bad putting it on a hiatus to get a new job and get married. So I decided i’m going to relaunch the site and really do things more intentionally over the haphazard way I did them before.

In order to relaunch, and make sure I don’t burnout and overstress I decided to lay out a plan, a long one. I stepped back and setup a timeline of things to do from coding to video production. With the relaunch of GoDjango.com coming tomorrow, and a long and fruitful future coming. I wanted to recollect on the 5 biggest things I re-learned doing this project.

If You Don’t Define Scope Your Sunk

Once I decided to go full steam ahead reworking GoDjango to make sure it was a success I wrote down 10 steps and gave my self 3 weeks to do it in. My biggest problem is three of the steps are things I had never done before, so I set about breaking down two of those. My steps ballooned to roughly 40 steps. I learned that I should have broken it down before I set a deadline so I wouldn’t have had to push it back to make sure I got it all done.

However, the question is would I have pushed as hard with 40 steps as I did with 10?

Minimum Viable Product is Smaller than You Think

I set out to have three key things done by launch. Only one of them will be fully ready with the others getting turned on in the coming couple of weeks. As I got closer to the deadline I really started thinking what do I really need vs. what would be nice to have. It turns out I didn’t need as much as I thought. So on launch tomorrow two features I really wanted wont be available, but they will be soon.

To mitigate this problem in the future I think I really need to take to heart “Launch and Iterate”. To be honest though it is hard you want everyone to have everything from day one, even knowing you will have more users later and they wont know the difference.

Proper Deployments Take Time

I haven’t done a full deploy in a long time. I have used heroku a lot, but I have felt like I lost some of the control I really wanted. Therefore, I setup a VPS just for the new GoDjango, and decided to do a best practices deployment. Unfortunately because I haven’t deployed in so long it took a lot longer to setup than I though it would. I should have better planned my deployment and built in longer than a couple of hours into my schedule for it.

Write Down Everything

As part of the planning process you should write down everything you think about. I went through and planned a large portion of what I was going to code, and how I was going structure things. Unfortunately, I did a portion of it in my head thinking “Oh I wont forget”. Well I forgot, and had to spend time re-planning out portions of the rewrite of GoDjango. So going forward if nothing else I need to write down on my whiteboard whatever I plan out, and take a picture of it.

Don’t Put off What You Don’t Know

Finally, don’t put off things you don’t know about. I have never purchased and SSL certificate, or setup a server to use one. I have never had the need before. As part of keeping GoDjango alive for a long time I am going to add a premium subscription model to the site. In order to take payments I need SSL, I don’t want to use paypal. Unfortunately I put this off, and off, and off again. Now I wont be launching tomorrow with the ability for people to subscribe because I am having to argue with the State of Oklahoma as to why my business isn’t showing up for my certificate authority to verify.

If I had taken care of this sooner I could have had this all wrapped up by now. Now I have a bit of egg on my face, and a valuable lesson learned.

Conclusion

Being the sole developer, designer, architect and project manager of a site has a lot of challenges, and falling down in one area can have adverse consequences in other area. In the future I need to be more diligent in all areas. Maybe even make some checklists for everything to make sure all is covered.

Related Posts:

{ 0 comments }

Adding Git Data to Your Bash Prompt

by Buddy Lindsey on May 14, 2013

Git Logo

A well setup bash prompt can save you a lot of time, and be amazingly useful giving you all the information you need, quickly. Unfortunately, you need to set it up properly which is a bit tricky. We will walk you through setting up your prompt with git data.

Bash 4+

First thing you need to make sure of is you have bash 4.0 or higher.

Linux

This should be default.

Mac OS X

Mac OSX is a bit more complicated, but not by much, please follow a previous blog post: Upgrade Bash to 4+ on OS X.

Download git-prompt and Activate

Next you will need the bash functions for your environment to use. Easiest thing to do is download the file and source it in your `~/.bash_profile` or `~/.bashrc` file.

Download git-prompt.sh

Similar to setting up git-autocomplete you need to download the git-prompt.sh file, and source it in your `~/.bashrc` or `~/.bash_profile`.

cd ~/
wget https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh
mv git-prompt.sh .git-prompt.sh

Activate

Then you need to source the file by adding the following to your `~/.bashrc` or `~/.bash_profile`:

source ~/.git-prompt.sh

Adding Git Data to Your Prompt

One of the tricks to setting your prompt is setting the PS1 environment variable, will cover it in more detail in another post. Since you will be setting the PS1 in your `~/.bashrc` or `~/.bash_profile` you can actually do some fun things with bash scripting to have some very dynamic prompts. Most noticeably the __git_ps1() function was designed to get the current branch, plus more information, and bring back that data for your bash prompt.

The easiest thing to do is add the following line to your `~/.bashrc` or `~/.bash_profile`:

export PS1='$(__git_ps1 "(%s)") \W $'

This will produce a prompt similar to:

(master) Programming $ 

What you are seeing is the __git_ps1 function adds the (master) segment to the prompt if you are in the folder of a git repository. The \W shows only the current folder you are in, not the path. This is convenient when you are super deep in folders.

What About Staged and Non-Staged Changes?

One of the good things about this is you can easily tell if you have staged and non-staged changes. In order to use this feature you need to add the following line to your `~/.bash_profile` or `~/.bashrc` file.

GIT_PS1_SHOWDIRTYSTATE=1

This is a flag for your prompt to show a * and + after the branch name. * means unstaged changes and + is for staged changes. Having neither means you have no uncommitted changes.

Conclusion

Adding this to your prompt is extremely useful to have. There have been a number of times I have forgotten which branch I am in and push the wrong one to a remote. I have also tried to rebase and not realized I have uncommitted changes. Now my prompt easily ‘prompts’ me to know what I am doing. This saves me time everyday.

Related Posts:

{ 0 comments }

Quick Intro to Python Requests Library

May 7, 2013

Calling 3rd party services is an essential part of web development these days. I did a quick little python article on Basic urllib GET and POST With and Without Data. It was a good look into how python natively handles doing GET and POST HTTP actions. However, there is a better way, and that is [...]

Read the full article →

Upgrade Bash to 4+ on OS X

April 30, 2013

Unfortunately, Apple has decided to ship an old version of bash shell. When I go back and forth between linux and OSX sometimes I hit minor inconsistencies because of this. One big one is the git-prompt scripts. As such I finally decided to upgrade to version 4 of bash. It is a very easy process, [...]

Read the full article →

Adding Git Autocomplete to Bash on OS X

April 23, 2013

If you use git on the command line a lot then git bash autocomplete is an amazing tool to have in your toolbelt. Unfortunately, just by installing git you don’t get to use it. You need to add command line functionality to your environment. The easiest way to add autocomplete is by downloading a file [...]

Read the full article →

Jenkins and Github Pull Requests

April 16, 2013

One of the things people love about travis-ci is it will build pull requests, but most people don’t realize Jenkins can do pull requests as well. It is also very simple to configure Jenkins to do pull requests using the correct plugin. Install the Plugin Install this plugin through the manage Jenkins admin section. Github [...]

Read the full article →

Python Date and Datetime Objects – Getting to Know Them

April 9, 2013

Properly dealing with dates can be hard, but they don’t have to be as long as you understand the basics. I have had to deal a lot with dates lately with a few Django applications, and life got a whole lot easier once I figured out the basics with python. In this post we are [...]

Read the full article →

Minimum Grep You Need to Know

April 2, 2013

You need to find a phrase in over 200 files worth of code. Manual searching is not a feasible option. If you are like me you know about grep, but it has always made you nervous. It is so powerful reading the man page was like a tech manual for an engine. Fortunately, getting the [...]

Read the full article →

Interview With Founder of Picirus

November 21, 2012

I got to sit down, shortly, with Tim Morgan the founder of Picirus a backup solution where you backup your cloud data, not to the cloud. This is a fun device that was created during, and since, Startup Weekend Tulsa has a very bright future ahead of it. So without further ado here is the [...]

Read the full article →

Working With Unix Processes – Book Reivew

October 29, 2012

This book alone proves why books are still relevant. It is a fairly short read, but the quality of the content is one of the best, with regards to a technology book. The material covered is very important if you want to do anything beyond basic websites, which I do. In short it is an [...]

Read the full article →