Sprint 1

I had my first "Sprint planning meeting" with myself.  It was actually harder than I thought as I really have no idea how much I can fit into a sprint since it is my first one.  This is good as it is all a learning experience and next time after seeing how much I accomplish during this sprint will help me better estimate next time.

Github is a really amazing tool which is helping me stay organized with my code, my backlog, and my sprints.  I created a milestone called sprint 1 and added all the tasks I believe I can finish during this sprint.

Sprint 1 is from 10/09/11-11/09/11

With all the labels, assignments and milestones, I feel so organized!  Trying to keep track of all this would be infinitely harder without this.

You can see there are comments on 3 of the issues, this was before I realized you could put multiple labels on issues, I was putting estimates within the comments.




For most of those I will put user stories, but for the infrastructure update, Update to rails 3.1, I will just do it.  There is an extra chapter on the E-book that goes through this process and I will be doing that, which is why its not actually that huge of a task.

If I do finish all of those before the Sprint is over I will just pull some other smaller items out of the back log.

I will keep posted with user stories and progress as the sprint goes on.  That will be sort of my scrum meeting since I don't have a team to report on the progress I can at least post on here a few times a week.

Again if you have any feedback, questions or any constructive criticism let me know!

Agile / Scrum

So since I always wanted to follow an agile software development process and use scrum, but it never really took off with my jobs, I am going to do it for this site.

For those of you not familiar with agile software development, it basically is a methodology for engineering software.  It is based on the idea that in the real world, requirements change, pieces of software are built on top of other software, and constant testing a working codebase is crucial.

To go a little deeper, it is fast iterations of software. So say a customer wants a web site with 100 different features.  Instead of documenting and writing all requirements and test plans, developing the entire site, and then delivering to the customer some long time later, you would write the essential requirements for each feature, with testing plans, and deliver a working site with those features so a customer could see it, or so you can see it, then in your next iteration implement more features, and so on and so forth.

This helps to always have a working product, rapid delivery and updates keeps a customer happy, and breaking down requirements helps for planning and testing.

Specifically I am going to be using the SCRUM framework of this process.  For the most part this assumes a product backlog (the requirements, user stories, features, etc) , and at the beginning of each sprint , or major iteration of the code, you plan which features etc, from the backlog can get into the sprint , do this and release for the end of the sprint.

Scrum

Usually you meet each morning for 15 mins to say what progress has been made, what you are working on, and if anything is getting in your way.  Since I am the entire team in this case, this will not be necessary.

This is built around a team, and hopefully one day if my site gets huge I can have one, but for now its just my way of organizing myself while learning.

My sprints will be 1 month long.  Obviously I will not have HUGE iterations each month as I am one person doing this in my spare time.

I am using the Github issues tab as my product backlog.  I have labeled each by priority and gave them a rough size estimate.

My priority labels are as follows:

• Critical functionality
• Cannot move on without this, 100% necessary for the site 
• Important functionality
• very important, site will work without it, but is key functionality needed pre-beta
• really want
• not 100% necessary but should be included
• these can come during beta release
• nice to have
• not really necessary but something that may slightly improve user experience

The critical functionality items will be done first regardless of size, then the important.  I have written user stories for each of the critical functionality items.

Users stories are the basic requirements I will be working from.  They consist of the 3 C's.  Card, Conversation, and Confirmation.

Card is a simple one sentence description of the feature stating who the stake holder is and why they need that feature, or what it may do.

Example:  As a USER I would like a welcome email when I register to remind me of my username.

This obviously leaves out a ton of stuff, but is the basic functionality of what it needs to do.

The Conversation part is more like the conversation with the developer and the person giving the requirements to really flush it out.  Mine will likely be just a rough mockup of the screen with the feature describing functionality.  For this one, it may just be the email itself with a link, and some text describing what the link would do.

The Confirmation piece is confirmation that the feature works as expected.  This is the test cases to ensure the feature works.  For the example above it may be something like:

• On successful registration an email is delivered
• On failed registration no email is delivered
• In the email there is a link back to the home page

I actually have only written the Card part of my current user stories. After my sprint planning, which I may do over this weekend, I will write the Conversation and Confirmation pieces of the items that I believe I can fit within this sprint.

On that note, you are probably asking yourself, "How do you know what you can fit into a sprint"?.  Long story short.. I don't.  However I can't just give up because I am not sure how many hours I will work on this this month, and how big each item on that list is. 

I looked up a bit of how to make these sorts of estimations.  Basically you don't want to estimate in terms of time, like hours weeks etc.  You want to estimate in terms of size.  Size you say? What unit would you measure that?  Well there is no real unit of a size of a software project, unless you were counting bytes or something, for this it is sort of size of the project and size of the time I think it would take me.  Some sites say people estimate time based on any unit so long as the team members are aware of what is bigger than the other. 

For example some teams use shirt sizes like S M L XL XXL XXXL.  While others may use Fibonacci  sequence like 1 2 3 5 8 12. 

Me, since I am my own team in a non-professional environment, and because it feels rewarding, I am going to use beer sizes for my estimates.

From small to large:

Sampler 4.75oz
Can 12oz

Pint 16 oz
Tall Boy 24 oz
Growler 40 oz
Pitcher 60 oz
Tower 100 oz
Quarter keg 496oz
Half keg 992oz

To see what my issues look like and how I am labeling them see below.

First 11 issues on my list with labels

You can also watch my repo, and look at my issues/code whenever you want here https://github.com/teylewr/PlayDate/issues

 If anyone thinks I said anything wrong above please let me know, so I don't continue thinking the wrong things.  I am always open to feedback and constructive criticism.

Finished Book/Sample App

After a few months, I have finally finished the book and sample app.  I have learned so much about test driven development, and ruby on rails.  I feel like a pro, although obviously working out of a book and doing it in real life are slightly different.  

I am way behind schedule of my original deadlines I made myself at the beginning of this, but I made it through and that is what is important.  From now on rather than setting myself up for failure by giving myself deadlines that are hard to meet, I am going to try and give my self goals and just hit them as milestones.  I am also going to split everything into small tasks.  

Here are some updates/screens of the final app, which you can view here. Feel free to create an account and make some posts, all the passwords are encrypted and not view-able in their normal form, not even by logs so you can feel secure.

I also updated my IDE from gedit, which was getting rather annoying, I am now using eclipse with aptana studio 3.  This is much nicer, and way easier to get up and working.

Now that this is done I am free to start working on my site.  This is going to take a bit longer as now I am not working out of a book and need to figure things out, design, and come up with the ideas on my own.

In order to do this, I will be following an Agile Software development process, particularly SCRUM.  In which I will have many iterations, break each piece down into user stories with priorities and estimates, and have monthly sprints where I work on only a few pieces at a time.  This will help me get a lot done without being overwhelmed.  I can do it piece by piece.  More specifics on this will follow as I document the process.

Thanks for reading!

Another Chapter Down : TDD Rubular and Users!

So another chapter down, and another concept learned.  TDD or Test Driven Development, is something I have heard of in the past, but never have done myself, or fully understood its awesomeness.  This book is all TDD and its really helping me understand it.

Basically anytime you want to add a new feature or element to your site first, create a test for the feature.  As a simple example, say you are adding an "about us" link in your navigation, before writing any code, first write a test that checks for the links existence then that the correct page renders.  So starting with a failed test, basically write as minimal amount of code to make the test pass.

What's the point?
So far I have thought of a few amazing reasons for this.

First, automated testing from the get go.  This can check to make sure you don't break anything when updating any features. Instead of clicking through the site constantly and still missing little things, the tests check these automatically, so long as you wrote them correctly.  

If it sounds like its a lot of work to write these tests, it is.  Its typically more than the actual code itself, and should be, but they are simpler to write, and save tons of time in the process.

Another thing, since you are basically writing code to make the tests pass, it really lets you focus on the one thing at hand and keeps you less distracted, and you end up writing a lot less unnecessary code.  You can always go back later and clean that up making sure the tests still work.

I can't wait to start using this more.

Also I have made my first users:

Also as always you can see my progress so far here http://severe-robot-761.heroku.com/

Oh and one last thing!

In order to validate email we did some regex, and the book linked to a really cool ruby regex tester, so I thought i'd share http://www.rubular.com/

Busy Busy...

I am trying to post at least twice a week, but I have been super busy these past 7 days, due to moving, and going to PA for the 4th of July... then not unpacking yet... Just got computer unpacked and set up.

Since I don't have any big updates, and haven't made much progress in my book, I did find an article that seems worth sharing on finishing a project.  It is written specifically for game developers trying to finish a game, however most if not all the hurdles seem the same as any coding project.

It goes through a lot of the things that have stopped me on many projects, such as wanting to go back and re-do all the code based on things I've learned, and hitting other walls.  It was really inspiring and I think will help me finish this project.

I highly recommend it.
http://makegames.tumblr.com/post/1136623767/finishing-a-game

Sorry that's all I have for now!  More later this week/weekend hopefully.

5 chapters down, filling in the layout, free online book, deployment and branching!

So as you can probably tell from the title I have done  a lot since my last post.

First, I am already 5 chapters down.  So far way ahead of schedule, which is great, because some of it was definitely pretty optimistic later on anyways.

Chapter 4 was a lot of ruby, and going through a lot of what it can do.  Chapter 5 was mostly layout, but it had a lot of new and important stuff such as url routing and creating a new controller for our user. I also went back to try and better understand some other concepts.  I looked more deeply into the automated testing built into rails, which is really great for finding issues on the spot, however I am not sure I fully understand this enough to know when I should create a test on my own.  Hopefully I'll have a better understanding by the end.

Also every chapter has us create a branch in our version control when we start.  This is something I have never done before, even though I have used many version control software programs before, none of my jobs had required this.  However after learning about it, there were definitely times when this would have been VERY useful, and also it makes a lot of sense.  Its something I always knew about, but since I never did it I always was like "meh i guess its not necessary".  Instead of explaining it myself, I found this really awesome article on branching.   Sahweeet.

I also was getting sick of my big thick book constantly closing on me, and me losing my space, and not being able to copy and paste from book to my code, and googled around a bit... and low and behold, the entire book is free online!  So if anyone wants to learn some Ruby on rails, and some of these other cool tools (linux, github, heroku, ruby, gedit) along with me, check it out!  Everything is free!! Wish i knew that before I bought the book, but whatever, at least i can take it on trains and stuff with me.

Last but not least, I went back and looked further into heroku, and its a free hosting service for small ruby apps.  This was in the book, but I sort of skipped over it at first because it required setup and such.  Then I rememberd I am doing this to learn as much as possible so I shouldn't skip anything.  Heroku is pretty great, and its allowing me to deploy my sample site live already, and get used to deploying the app from git to production, which is really cool.  So if you want to check out my progress on my app  check out this link http://severe-robot-761.heroku.com/  obviously there isn't much too it since I'm only on chapter 5, but still pretty cool.  Also severe-robot-761 is an auto-naming thing.  I can actually rename it whatever I want so long as it isnt taken, but for now I really don't care.  Also if I really grow to like this I might just buy some space at heroku and launch my main site from there when all is said and done. 

And since everyone loves picture heres a before and after so far of the main page of my app, just to show progress from last time.

Setting up environment and first few chapters

The first few chapters were an introduction to ruby, and setting up the environment.

The book goes through using Linux, so I burned a fedora cd and installed that. I  have not used Linux that much, so its a good opportunity to really dive into it.  I decided to install it on a usb external hard drive so that I can bring it around anywhere, and update on any machine I have.  It has been working out well so far.

My fedora desktop

One of the first things the book has us do is to set up github, and use that for version control. Github is very similar to other versioning software i have used, but the whole public aspect of it is very new to me.  You can view tons of open source software projects on there, and clone repositories etc.  If you want to check out my repositories go here https://github.com/teylewr you can follow my code there as well.

I have been trying out different text editors and IDE's, but haven't found anything I am loving yet.  I want to try something other than eclipse since thats basically all I have ever used since college, and I want to branch out a bit.

Editors I have tried:
Emacs - wtf is up with emacs... people seem like they love it, but it is so incredibly complicated and hard to find good training on.  I wanted to use it but was wayy too confusing and overly complex

Gedit - currently using best so far

Vim - Couldnt get it to work with rails coloring, didnt like it much all around

Eclipse

So far in the app I have created some tests, which are built right into rails, set up some views, and did a few more basic things.

Gedit and editing about page

New Update

So recently I've been dedicating a lot of time to getting kick ass at starcraft. I reached diamond league (top 20%) and have been stuck there for a while, basically around top 5%. I dediated a lot of time to keep improving, and watching pros.

I recently realized if I put all that energy into something productive, I could probably get a lot accomplished, however it is hard to find the motivation on my own. Basically I decided blogging about it will make me feel more commited to doing something.

Since I really grew to love the starcraft community I figured doing something starcraft related would be fun. So I plan on making a starcraft community website.
Since I currently use ruby on rails at my job and I love it, thats what I am going to use to build it.

My first step is going to be going through my rails 3 tutorial book. This will get me a template site to work from, including having user accounts, profiles, and posts. Also it will help me get most, if not all, the concpets I need to build the site.

Another thing to help motivate me is a timeline. If I dont try and get things done by a certain date, I probably wont do it. I have a hard time finishing things on my own.

1. Step 1 : Complete tutorial book (08/01/11)
2. Step 2 : Features for site and basic mockup (08/14/11)
3. Step 3:  Alpha version (9/01/11)

Hopefully I can finish the tutorial book sooner, but its pretty long and I want to make sure I understand everything I am reading.

I have linked the book below, and also starcraft if interested.