Groovy Twilio SMS

Very simple Groovy script that sends a message via Twilio APIs...

@Grab(group='com.twilio.sdk', module='twilio-java-sdk', version='3.4.6')
import com.twilio.sdk.TwilioRestClient
import org.apache.http.message.BasicNameValuePair
// Find your Account Sid and Token at twilio.com/user/account
ACCOUNT_SID = 'ACbee9cae6cca2b82845e057571236378e'
AUTH_TOKEN = '811da513032f1f8866e9bcb127b167cd'
client = new TwilioRestClient(ACCOUNT_SID, AUTH_TOKEN)
// Build a filter for the MessageList
params = []
params << new BasicNameValuePair("Body", "Hey!")
params << new BasicNameValuePair("To", "+15005550006")
params << new BasicNameValuePair("From", "+15005550006")
message = client.getAccount().getMessageFactory().create(params)
println message.getSid()

Brownie App Development

Fred:  We'll NEVER keep up with those interfaces!

Todd:  Then we will have to merge them!

Fred:  That will take forever.  Besides, even if we implement them, they will change them, stick us with weird OR mappings, torture us (AKA make us use Maven) and FINALLY fire us!

Todd:  Are you suggesting we rewrite it? 

Fred:  Naa, this is more fun!

Sergeant Crone On Writing Code

Obviously I have plagiarized someone but I felt inspired by him.  The next time your project manager, product owner or some non-coder questions your professionalism as a developer due to some arbitrary deadline that you know you have to miss for code quality, just respond with this. 

Son, we live in a world that has code. And that code has to be written by people with editors. Who's gonna do it? You? You, Project Manager? I have a greater responsibility than you can possibly fathom. You weep for deadlines and you curse the developers. You have that luxury. You have the luxury of not knowing what I know: that deadlines missed, while tragic, probably prevented bugs. And my existence, while grotesque and incomprehensible to you, prevents bugs...You don't want the truth. Because deep down, in places you don't talk about at parties, you want me in the code.  You need me in the code. We use words like test, code, refactor...we use these words as the backbone to a life spent caring about something. You use 'em as a punchline. I have neither the time nor the inclination to explain myself to a person who rises and sleeps under the blanket of the very software I provide, then questions the manner in which I provide it! I'd rather you just said thank you and went on your way. Otherwise, I suggest you fire up an editor and write some code. Either way, I don't give a damn what you think you're entitled to!

Leading Change

My minister from Crossroads Christian Church in Lexington, KY posted this Monday.  It REALLY has a good perspective on the changes we are trying to drive currently.  I promise, minus the Bible reference at the end (Proverbs) there are no religious trappings.  I got permission to post here since it did not readily have a public link.

As for Proverbs reference, view it as a reference to a conventional book on wisdom.  ;-)

>>>

In his book, Deep & Wide, Andy Stanley points out how change is a complex issue.  James M. Kouzes and Barry Z. Posner write: “Any system will unconsciously conspire to maintain the status quo and prevent change.” While leaders are often quick to blame people for their stubborn unwillingness to change, Kouzes and Posner rightly point out that the problem is much deeper and more complex than inflexibility or stubbornness. It’s a systems problem. Every workplace is a complex collection of systems. Every business has its way of doing things. And for the most part, it works. Consequently, change is rarely perceived as a solution.  “We’ve never done it that way before” can become the unconscious response to change.

Stanley notes that in most cases, change feels like an interruption. An expensive interruption to something that’s fine the way it is. An interruption with no guarantee at the end. Only promises and wishful thinking. The way things are done at your business is so deeply ingrained that you may meet resistance at every turn. And in spite of what you might be tempted to think, Stanley thinks it’s not anyone’s fault…

He suggests that the best way to bring about desired change is to describe the future. Paint a word picture.  Stanley declares, “The most ineffective way to begin a conversation about change is to talk about what needs to change. You should never begin a conversation about change by addressing where you are now. You should always begin with where you want to be. When you begin a conversation about change by discussing what needs to change, you generally begin with something that someone is emotionally invested in. That’s a recipe for failure. Or termination.”

Reminding me of where I am and then telling me I need to change is neither compelling nor inspiring. But pointing me toward a preferred future and helping me discover what I need to do now in order to get there … that’s different.

So the best place to begin any conversation about change is the future. What could be. What should be. Perhaps what must be! As a leader, your responsibility is to make the people in your organization discontent with where they are by painting a compelling picture of where they could be.  

Proverbs 28:6 (New Living Translation) “Those who trust their own insight are foolish, but anyone who walks in wisdom is safe.”

Until next Monday, Glen

<<<

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!