Thursday, December 5, 2013

Software Crafty Articles That Inspired Me

Here's a set of random things that inspired me over the years. There is some other set of random things that have inspired me that are also things that didn't occur to me at this instant.

J.B. Rainsberger



Nat Pryce & Steve Freeman

  • Growing Object Oriented Software 

Uncle Bob


Gary Bernhardt


Michael Feathers


Jay Fields



Fowler

Joel Spolsky

Oh and The Pragmatic Programmer & Domain Driven Design.

Monday, October 14, 2013

Trampolining - An exercise in recursion and not blowing your stack!

This exercise was developed for the October 2013 Boston Software Craftsmanship Group Meeting

Discussion:

  1. Tail call optimization
  2. Tail calls vs tail recursion
    1. http://stackoverflow.com/questions/12045299/what-is-difference-between-tail-calls-and-tail-recursion
  3. Continuation Passing Style & Continuations
    1. http://en.wikipedia.org/wiki/Continuation_passing_style
    2. http://en.wikipedia.org/wiki/Continuation
  4. Trampoline
    1. Trampolining is a technique to implement tail-recursive optimization without consuming stack space (under the hood you're turning your recursive calls into a loop). It's commonly used in lisp compilers that compile down to C. If you implement your own trampoline you'll be able to make trampolined tail calls without blowing your stack.
    2. A trampoline is an outer function which iteratively calls an inner function. The inner function returns a thunk (or a continuation) of another function to call or the result. To turn a tail recursive function into one that can be trampolined all you need to do is return a thunk wrapping your recursive call. It's called a trampoline because it bounces from function to function. Boing, boing, boing, boing, omg I got a result.

THE EXERCISE

  • Pick a stack based language of your choice (I'd recommend something with functions as first class objects)
  • Write the following two recursive functions:
  • Blow your stack!
  • Re-write to be tail recursive (you may need an accumulator)
  • Blow your stack!
  • Write a trampoline, re-write your recursive functions to operate in that world
  • No more blowing your stack!

LEARNINGS

You should come away from this exercise with a better understanding for a good number of functional programming terminology. Experience thinking about recursion and how to rewrite recursive functions as tail recursive. And maybe after we run the exercise you'll help me update this section!

HANDY LINKS

Blogs:

http://volgarev.me/blog/62412678347
http://raganwald.com/2013/03/28/trampolines-in-javascript.html
http://pramode.net/clojure/2010/05/08/clojure-trampoline/
http://jakemccrary.com/blog/2010/12/06/trampolining-through-mutual-recursion/
http://kix.in/2007/12/30/the-trampoline/
http://blog.functionalfun.net/2008/04/bouncing-on-your-tail.html
"The one kind of message says, "I want to bounce: please call me again with these parameters"; the other kind says, "I've had enough bouncing: here's the final answer"."
http://programmers.stackexchange.com/questions/157684/what-limitations-does-the-jvm-impose-on-tail-call-optimization

Wikipedia:

http://en.wikipedia.org/wiki/Tail_call
https://en.wikipedia.org/wiki/Thunk_(functional_programming)

Academic:

"No assembly required : compiling Standard ML to C" http://repository.cmu.edu/cgi/viewcontent.cgi?article=3011&context=compsci
"CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A." http://home.pipeline.com/~hbaker1/CheneyMTA.html

NOTES

Depending on your language and chosen implementation, it may be helpful to be able to check if variable is a function. In clojure you can do that easily with fn? In javascript the following code should work:
function isFunction(functionToCheck) {

 var getType = {};

 return functionToCheck && getType.toString.call(functionToCheck) === '[object Function]';

}

If you need a little help see https://github.com/zdsbs/trampoline-exercise for some sample code.

Saturday, September 14, 2013

Reactive Programming Exercise With baconjs


For the September 2013 Boston Software Craftsmanship Group meeting I ran an exercise in Reactive Programming. Reactive programming is a programming paradigm that is all about data streams. It's getting a lot of attention these days, from people using it in iOS development to deep interest in the Scala community and even a coursera course on it https://www.coursera.org/course/reactive
The basic idea of Reactive Programming is stream processing. It allows for declarative programming about streams of events and calculations / transformations that are declared on a stream and triggered with events from that stream. Once you start thinking about it (or at least once I started thinking about it) you realize data streams are everywhere. Streams are so fundamental to programming it surprises me we don't model with them more often. Or maybe it doesn't surprise me, maybe this is yet another point in the history of software engineering that programmers of the 70s & 80s are head-desking that as an industry we're "discovering" a concept. But, better late than never!
In 2+ hours we took a room full of 8 programmers, gave them some hands on experience, and a taste of what modeling with streams might be all about. From what folks said after the meeting it was a success. I know it was one for me: Streams man, they're everywhere.

Thursday, April 26, 2012

Pair Programming Madness


Pair programming madness (or musical chairs for programmers)


I've been meaning to write about this game I developed at the Boston Software Craftsmanship Meetings for a long time and apparently the time for writing is now! It's a fun, silly, chaotic way to pair with friends and strangers. Without further ado here's the description:
Pair programming madness is a collaborative coding game similar to musical chairs.
Rules:
  1. Select a code kata. At Boston SC we've used: https://github.com/moss/messaging-exercise and found it well suited.
  2. Everyone brings a laptop with their favorite language setup with a testing framework
  3. Present a code kata and everyone pairs up
  4. We’ll work on the kata for 15 minutes, then rotate pairs. One person stays + one person goes
  5. Repeat step 4
What's this look like? Well, you'll only work on one code base max 2 times and pair with 3-4 different people. Additionally you'll both be in the position of explaining current (legacy) code to a new pair or coming up to speed with a code base / env you're not familiar with. (Basically controlled chaos, but fun)
Important note: Because it’s possible that two people will be working in a language + env that they’re not familiar with, you should make sure to have either an easy to use IDE, that’s kind of point and clicky or a vanilla text editor (no vim / emacs) and an easy way to run the tests.
Running 3 iterations will take ~90 minutes.
Enjoy!

Thursday, February 23, 2012

Certifications

The topic of programming / agile / IT certifications seems to make the rounds every few years. At least in the circles I hang out in we're in a lull, no one's complaining about certifications or coming up with alternative ideas. Which in my opinion makes it a perfect time for an alternative idea. tl;dr

As a programmer what might a meaningful certification of your skills look like? Is it something like http://www.scrumalliance.org/CSD becoming a certified scrum developer? Is it a social network of recommendations, Bob says Fred is a great programmer and you trust that Bob is a great programmer so the transitive property of programmer greatness goes into effect? Should we look to other industries like engineering or medicine? These are the kinds of arguments I remember hearing in the past.

Why do we care? Why does the topic keep coming around? The answer, demand. Companies have caused a demand in certifications, and other companies (e.g. scrum alliance) have looked to fill that demand.

The debate about certifications always seems to come down to: How can you certify that someone is a good programmer? That's a flawed question. There will never be some metric that you can say this person is a good programmer because of X,Y,Z (or maybe there will but we're no where close to that as an industry).

There is demand, there are certifications, they're of limited value and possibly misleading. Our job as an industry is to provide good alternatives. Meaningful certifications that have teeth behind them. My solution, domain specific programmer certifications.

Assume I'm a bank I have two very similar resumes in front of me, I only have time to phone screen one of the candidates. The difference one candidate worked their whole career in finance, the other bio informatics. I'm going to call the finance guy.

Different scenario, I'm a bank again, the two resumes in front of me are both pros who've been coding in finance. One of the guys has a the Financial Programming Certification with a focus in trading (it's the most difficult financial certification to get with a 75% failure rate for first time test takers), the other guy doesn't have it. I'm going to call the certified guy.

tl;dr

So what is a domain specific certification? It is a difficult to achieve certification focused on verifying knowledge in a domain as it pertains to writing software. One could imagine them in finance, bio-informatics, medicine, healthcare, education, etc. They are business focused, not technology focused. They validate that you know the important domain concepts and the subtleties of those domains. That you understand common client needs. That you know common design pitfalls.

What about CSD? The content looks great, the name is misleading. Because what does it certify? It certifies that you are familiar with the daily practices and language of a scrum team. It's a domain specific certification for being part of a scrum team. Which is useful, but does it really mean that you're a good developer? That you can abstract well?

Certifications are about filling a need for businesses, they're not going to go away. Businesses have made that clear, and we can't ignore them. We have a choice as an industry do we have certifications like CSD or do we certify that programmers know about certain domains and the pitfalls of programming in those domains. We can either shape the certifications towards something useful or allow them to be shaped for us.

Thursday, August 19, 2010

Starting an XP Team

Driving home on July 4th weekend I had the sudden realization, not only did I desperately want to work as a part of an XP team, I thought it might be possible. If I could get two other devs, they could move into my office, we could get one more computer and we could all practice XP. Do pair programming, become a tight knit team, everything a guy could ask for. The challenge was convincing management and getting the two other people. I had a feeling getting the resources was going to be the most difficult part.

I had a few prerequisites for forming an XP team that was going to make it hard:

  1. Everyone needed to be full-time on the team
  2. No remote devs
  3. I wanted particular devs to be on the team

Why these prerequisites?

  • "Everyone needed to be full-time on the team" - To me this was a no brainer. I wanted to build a team, and I couldn't see how to build a cohesive group when you had people popping on and off constantly.
  • "No remote devs" - I've never been on an XP team or any team for that matter, never mind starting one. Having the additional challenge of working with remote people I felt would have set me up for failure. No point in trying if it's going to fail.
  • "I wanted particular devs to be on the team" - First off, I like and enjoy working with all my co-workers (Hi all!). There were going to be plenty of issues to work out that come with starting a new team. I felt it was important that we didn't spend too much time arguing about XP practices (TDD, pairing, etc.). There were a few co-workers I had worked closely with and I felt confident we were on the same page. For this first attempt at an XP team I thought it was important to have them be a part of it.

Why were these challenges for my company?

  • "Everyone needed to be full-time on the team" - Traditionally people work on 2-3 projects at one time, this means getting full-time resources requires some serious shifting of work.
  • "No remote devs" - Every project leader at my company prefers on-site devs. Giving my project 2 full-time devs means other projects have to rely more on remote devs. I like the other project leaders, I didn't want to make them mad by "stealing" their resources (Nor did management).
  • "I wanted particular devs to be on the team" - The two developers had some other commitments to projects, so it was going to be difficult to free them from those commitments.

Anyway enough background. Monday morning I was still bubbling with excitement. I talked with our VP of Operations to see if she thought I was crazy or if it might be possible. She seemed to think the idea was interesting, but there was a wrinkle, a big wrinkle. I could get a smattering of part time in house devs or some full-time remote devs, but getting two full-time in house devs on one project was just impossible. The question I asked myself was, "Is there something that can be done to still make this team a reality?" The company didn't have the resources to have three people full-time on one project, but what if the team worked on two projects? Two projects, three people, two computers and one office. Two projects would be more challenging for the team, but it still seemed doable. Our VP also thought it was a possibility.

I floated the idea a little more, people seemed interested especially our new VP of Technology. He was fully on-board and championed the creation of the team. Everyone thought it was an experiment worth trying, and now I'm a member of a three person XP team. Last Friday we completed our first iteration and I couldn't be having more fun.

Monday, May 3, 2010

I hate looping / iterating / eaching

I really hate looping. I mean I really hate looping. Why is that you ask? Because most of the time our looping is not looping. You're filtering, you're transforming or you're calculating, you're not looping. Looping is a means to an end. You loop to perform those actions. But syntactically it's quite common in many languages to see something like: for (blah in blahs) do some filtering / transforming / what ever. Why does the statement "for (blah in blahs)" come first? why isn't it blahs.filter(some predicate) or filter(blahs predicate) or blahs.transform(some stuff) or really so many other options. Why isn't the intent of transforming / filtering / calculating brought to the forefront?

I love clojure's solutions to the issue: filter, map, reduce. You can get rid of 99% of all your looping and describe better what you're trying to do. I've been trying this in java (I know I know it's a mistake)... with google collections. I mean great they have filter, transform, this will look great. It really doesn't:

List filtered = new ArrayList( Collections2.filter(foos, new Predicate() { @Override public boolean apply(Foo foo) { return foo.isBar() && foo.isBaz(); } }));
vs
List filtered = new ArrayList(); for (Foo foo : foos) { if (foo.isBar() && foo.isBaz()) { filtered.add(foo); } }

Well fine I'm maintaining intent (I guess) by using a filter method and a predicate, but the whole filter mechanism gets completely lost in all the boiler plate java cruft. I love that I can just implement an apply method, highlighting the boolean expression, and the magic is done for me, but I need so much more code to get my work done. Sure I'm removing duplication of looping (which is nice) but at such a legibility cost. Maybe I'll get used to all the crazy syntax, and it will just fade into the background, but for the moment I'm really doubting it.

 
Web Statistics