This is AWESOME!!!

(•_•) <) )╯ UNIT / \ \(•_•) ( (> TEST / \ (•_•) <) )> PASSED / \" @twcrone does this same dance.

— Jamie Bisotti (@jbisotti) November 7, 2013

Todd's Helpful Hints #1

One college Spring Break I travelled to some popular beach in Florida with an evangelical group known as "Campus Crusade for Christ". I must admit, although I am a Christ follower, my main motivation here was going to the beach for Spring Break on the cheap (like $100 for a week!). On the trip down, I shared a van with a hulking linebacker from Georgetown College. Let's call him 'Jon' (I don't remember his name either). So Jon was a vision of physical power. He was not only large but he was cut to shreds and had a shelf under his pecs where someone could seek shelter in the rain.

During our 10+ hour van ride he noticed a scrawny guy weighing in at a massive 135lbs happily eating a large bag of powdered donuts. Yes, that scrawny guy was me (50 lbs ago) and as I noticed him eyeing my bag of donuts I smiled and said, "Powdered donuts contain muscle building nutrients." He quickly retrieved a notepad and began writing something very important. As he finished, he smiled and showed me what he had written.

Todd' Helpful Hints
---------------------------
1. Powdered donuts contain muscle building nutrients.

Throughout our week long trip, Jon, continued to make note of all my comments that he qualified as "wisdom" that he did not want to forget. I enjoyed the experience but something tells me he never followed any of my "Helpful Hints" and he was simply messing with me.

In that spirit, I want to mention a couple things that I hope are more educated with regards to "Agile Software Development" than my muscle building hints of the past.

To misquote an agile mantra I heard somewhere, "Agile development is more about filling up your Outbox than it is about emptying your Inbox." This means the more stuff we can "Get Done" the better. Even if those things are relatively small.

"Getting Things Done" (GTD) is a methodology or something for becoming a more effective and efficient "Doer". One thing it champions, is a To Do list. Even if you have already done something, write it down and cross it off. To do items should be short as possible because every time you check something off, there is a positive psychological effect to the Doer. Several 'large' tasks tend to stay on your list longer and can potentially have a negative psychological effect to the Doer.

In agile software development, large stories (or worse large tasks) tend to stick around a long time and either get wrapped up toward the end of the sprint, get carried over or get 'split' so that something can be logged as 'Completed' in one sprint and the rest can carry over to the next. If we start off with small stories, we can hopefully get some done early and towards the end of the sprint feel less pressure to 'finish' that large story that is still lingering. Obviously we still want stories that actually mean something but they don't necessarily need to mean 'everything' for a given feature. Perhaps it should be just the first part of a larger feature or the 'Simplest thing that can work' and then next story can be the next 'Simplest thing that can work more'.

Smaller stories also help with source control branching and merging if you are using Git Pull requests. Typically you want Git feature branches to be short lived and closely tied to a user story. If the stories are large, you will either have a feature branch that lasts too long and has merge issues or you will need to create multiple feature branches throughout the work on a particular story. This might be okay and feature branches can be mapped more closely to tasks if necessary but if feels a great deal better to complete a fully tested story as you are merging the feature branch and then subsequently deleting it.

Every team has to find their rhythm and find a comfortable way for defining features/stories so that they can be accomplished in isolation in a reasonable amount of time. My experience is that a larger number of smaller stories causes less stress and flows better than a smaller number of larger stories. One agile book (and there are a bajillion) I don't remember the name of, suggests that a user story should fit on a 3x5 index card with enough information to begin a deeper discussion but if you find you need pages upon pages in a tool like Rally to define a story, it might be too large. Once again, every team must figure out what works best for them.

So that's it! One of Todd's Helpful Hints. Do with it as you choose.

Hopefully it is more useful than, "Powdered donuts provide muscle building nutrients." or some of the other hints that I seem to remember but don't bear repeating.

Proud of myself - Smallest Multiple

In an effort to learn Ruby in a semi-fun way, I'm porting my Project Euler solutions that are in Groovy to Ruby.

Today I made myself proud...

Problem 5 - Smallest Multiple

2520 is the smallest number that can be divided by each of the numbers from 1 to 10 without any remainder.

What is the smallest positive number that is evenly divisible by all of the numbers from 1 to 20?

My Groovy solution:

class Test extends GroovyTestCase {
 
 def solveFor(upperBound) {
  def answer = 0
  def temp = upperBound * (upperBound + 1)
  while(true) {
   answer = temp
   (2..upperBound).each {
    if(temp % it != 0) {
     answer = 0
     return
    }
   }
   if(answer != 0) {
    return answer
   }
   temp += upperBound
  }
 }
 
 void test_base_case() {
  assertEquals 2520, solveFor(10)
 }
 
 void test_solution() {
  def start = System.currentTimeMillis()
  println solveFor(20)
  def end = System.currentTimeMillis()
  println "Elapsed time ${end - start} milliseconds"
 }
}  

To this Ruby solution:

require "test/unit"

def solve_for(upper)
  answer = upper
  until divisible_by_numbers_up_to?(answer, upper)  do
    answer += upper
  end
  answer
end

def divisible_by_numbers_up_to?(number, upper)
  (2..upper).all? { |i| number % i == 0 }
end

class SolveProblemXTests < Test::Unit::TestCase

  def test_simple_case
    solution = solve_for(2)
    assert_equal(2, solution, "Solution was #{solution} not 2520")  end


  def test_base_case
    solution = solve_for(10)
    assert_equal(2520, solution, "Solution was #{solution} not 2520")
  end

end

answer = solve_for(20)

puts "Answer is #{answer}"

After some thinking I felt it was still a little clunky and I actually wanted to try to make it more terse for fun. So I left the tests etc. but changed the implementation at top of file to this:

def solve_for(upper)
  (upper..Float::INFINITY).step(upper).find do |num|
    (2..upper).all? { |i| num % i == 0 }
  end
end

Not sure it got more confusing to read. Earlier code was not necessarily easiest to read but I learned some stuff about Ruby and coding in general. Honestly it was my exposure to Clojure that made me think I could use a lazy loaded list of numbers going to infinity.

Mission Accomplished!

Forget the old and learn the new-ish: Ruby on Rails

Recently switched jobs to one that uses Ruby on Rails as primary technology. Here is hoping that this will spark my interest in writing about technology stuff again!

Tagging Git projects with Ruby

It has been a while since I wrote any Ruby and I've never written much but today I needed to tag a bunch of projects in Git that I used to do through a Groovy script in Jenkins.  Since I might need to become a Rails dev in the near future I figured I would write this with Ruby.

1:  projects = [  
2:   'project1',  
3:   'project2'  
4:  ]  
5:    
6:  tag = ARGV[0]  
7:    
8:  puts "Tagging projects at #{tag}"  
9:    
10:  def tag_project(tag, project)  
11:   Dir.chdir(project) do  
12:   system "git pull"  
13:   system "git tag #{tag}"  
14:   system "git push --tags"  
15:   end  
16:  end  
17:    
18:  projects.each do |project|  
19:    
20:   if !File.exists? project  
21:   system "git clone git@github.com:fork/#{project}.git"  
22:   end  
23:   tag_project tag, project  
24:  end  

That's it!

Geb ain't just some country hick!

Started using Geb (http://www.gebish.org/) for some simple UI automations to run via Jenkins.  Basically, login to several instances of our app every half an hour and make sure something infrastructure-wise has not taken our app down.  Only issue is something with the network (proxy config etc.) makes it run REAL slow so far...

>>>
@Grapes([
    @Grab("org.codehaus.geb:geb-core:0.6.0"),
    @Grab("org.seleniumhq.selenium:selenium-firefox-driver:2.0rc3")
])
import geb.*
import org.openqa.selenium.firefox.FirefoxDriver

class LoginPage extends Page {
    static url = ""
   
    static content = {
        submitButton(to: MainPage) { $("input", type: "button", name: "signin") }
        usernameInput() { $("input", type: "text", name: "usernameInput") }
        passwordInput() { $("input", type: "password", name: "passwordInput") }
       
    }
}

class MainPage extends Page {
    static url = "main"
}

Browser.drive() {
    def username = config.rawConfig.username
    def password = config.rawConfig.password
    def loginTitle = config.rawConfig.loginTitle

    println "Opening login page..."
    to LoginPage
    at LoginPage
    assert $("title").text() == "Sign In"
   
    println "Setting username=$username"
    usernameInput << username
    println "Validating username..."
    assert usernameInput.value() == username
   
    println "Setting password=$password"
    passwordInput << password
    println "Validating password..."
    assert passwordInput.value() == password
   
    println "Submitting login form..."
    submitButton.click(MainPage)
    println "Waiting for main page..."
   
    at MainPage
   
    println "Checking for main title..."
    assert $("title").text() == "Main Title"
}.quit()

println "Done!"

<<<

If you can't beat em', join em'

I started out my little EclipsePhase RPG tracking web app using a Flex UI on top of Gaelyk services.  However, this last weekend I gave up on that and rebuilt my starting point plus some more features with Grails and HTML.

Using Grails instead of Gaelyk was an easy choice for now since I can get a free cloud deployment via CloudFoundry.  Nevermind the fact that I use Grails at my day job, I think I might generally like it better than Gaelyk.

However, the Flex vs. HTML/JavaScript thing is a little less logical.  I spent 4 years getting decent with the Flex framework which I think is a great RIA platform.  However these days with all the Flash FUD going around and the hype around HTML5, it seems highly unlikely that I will build many more Flex UIs professionally.  That's a shame but I'm growing tired of fighting it for now.

My project is a "no Flash" zone as my company's head management is convinced Steve Jobs "Flash is dead"eventhough we have several RIA front-end projects that have been success and no JavaScript/HTML ones yet to do anything significant. 

We actually pay for a JavaScript framework (ExtJs) when Adobe Flex is open source now.  Our UI constantly has browser issues.  It does very little.  In Flex it would be the equivalent of a couple data grids, a couple forms and file uploader.

I'm not digging on our UI guys, but they have alot more work to do dealing with what one guy referred to as "GarbageScript". 

I'm also not digging on JavaScript but browsers suck.  JavaScript devs that spend their time hating on Flash suck.  And eventhough I love my Mac and don't want to be insensitive, but Steve Jobs hateraid for Adobe Flash sucked also.

I'm tired and beaten, so I'm just doing HTML and GarbageScript for now.  The good thing is I am back to basically writing my UI on the server with Groovy/Grails and only slightly with HTML and JavaScript.