archcoder

Taking Nerd Life balance one day at a time.

The Dark Side

| Comments

Here’s a book I pretty much keep in hand all the time: Continuous Delivery by Jez Humble and David Farley. Not that it’s a really super enjoyable read, but it helps me remember how doing this software thing we do can be awesome for both the dev and user.

This book is primarily focuses on Continuous Delivery and not Continuous Deployment per se, it etches into an architectural area (around pages 347-349) that I feel every software ecosystem should have.

Feature Dark

dark side rule #1: Releasing small, even unfinished bits into production is ok and will actually save you from head aches.

Delivering features into customers hands should be exciting not terrifying – how many of you have placed bets on the success or failure of a gargantuan release? Why do we have humongous deployments that are scary? Being big and scary didn’t really work out for the dinosaurs did it and it won’t work for your software either. Create a parallel page, work on the model first – do something other than stop to wonder how you’re going to eat the elephant (i.e. big things need to be eaten one bite at a time).

dark side rule #2: Putting software into production does not always mean that you are putting it into the hands of your users. Your software should have toggles that turn features (partial or otherwise) on for either some or all users

I believe that developers should be able to release code right to production, bottom line. If you disagree then you either need to get new developers or you need to start trusting the ones you have. I also believe that every commit after going through quality gates should go right to production once it hits master.

Write your code so that if the doomsday scenario of someone elbowing the keyboard won’t put your latest UX redesign in front of your customers. Histrionics aside make your software “releasable.” Don’t expect a magic bullet here either, this will take team maturity and some patterns for everyone to stick to (like the ones @chadmeyer and I created – pushing features dark). Best idea here is to come up with an easy to understand / use patten and make sure that the business is tooled to flip those switches.

dark side rule #3: Let your business worry about releasing the software to the customers and let your developers worry about writing and deploying said software

See – cd vs. cd. Look @ your keyboard, go ahead I’ll wait……

If the symbols <,>,{,},# are worn then you are a developer. Do what you’re good at – write and deploy code.

If the # key or the letters a,t,t,n,. are worn then you know who you are. Go put the software developed into the hands and minds of the customers

dark side rule #4: Your features might not always fit into or be able to be feature dark

You just won’t. There will be organizational challenges, changes, events and technical roadblocks that will take time to get past. The goal here is to incrementally get there. Be pragmatic.

dark side rule #5: Ruled by fear your competitors are… deploying software all the time you will be…

See amazon, flickr, so on.

Note: The dark side rules are my own creations and are only based on my experience with what works and does not work while I have been in dev shops trying to achieve CD, so take them with a grain of salt to season your own rules.

The Rub

| Comments

What is it about bit-rot that seems to drive us away from quality? Here’s the analogy:

Let’s say you just bought this massive steak that you’re going prep before the game. So you know you’re gonna create an awesome rub then toss it on the grill at a solid 600° and just go to town on the beautiful cow bouquet.

You get to the counter and it is covered in the remanence of last night’s game fest. Baring any cultures that the CDC might want to take for posterity do you really stop and think… “Hmmmmm, should I clean the counter before I do the rub throw-down on this $50 steak?” No you don’t… so why do we do it with the code we write?

You’re in some pretty rough code and you add a beautiful bit of code to it, do you leave the other bits around it trashed; lipstick on a pig. Word to the wise, be a boy scout, leave it in a better condition than you found it.

Just Some of Archcoder’s Favorite Ruby and Ruby on Rails Learning Resources…

| Comments

Docs:
apidock
railsapi
rails guides
envylabs rails cheatsheet

Teaching tools:
hackety-hack.com/
codeschool.com/courses/rails-for-zombies
codeschool.com/courses/try-ruby
rubylearning.org/
railscasts.com/
teachmetocode.com/
rubyrogues.com/
ruby.railstutorial.org/
guides.rubyonrails.org/
rubyflow.com/
refactormycode.com/
pry.github.com/

Screen / pod casts:
peepcode.com/screencasts/ruby-on-rails
rubyshow.com/
www.destroyallsoftware.com

irc:
#rubyonrails (irc.freenode.net)
#ruby (irc.freenode.net)

Books
Why’s (Poignant) Guide to Ruby
The Pickaxe
Beginning Rails 3
Beginning Ruby
Humble little ruby book
Exceptional Ruby

Kid Gamification - Day 3, the Finale

| Comments

As I sit here listening to the TRON soundtrack I recognize that the flashy code of movies like TRON, anit-trust, hackers and the like have changed the ideal picture of what coding something looks and feels like.

I have to admit, Hollywood makes slamming out bits look cool and easy – not nerd cool like node.js or mongodb but more like socially acceptable “teen” cool like eating Pringles, drinking mountain dew or jolt and getting away with “something.” Right now I am snacking on Pringles and drinking mountain dew – the propaganda worked!

Though my boys haven’t seen those movies they are familiar with the “hacker” architype of a guy mashing keys having code fly across the screen to save the world from total meltdown! So, as I expected we hit a productivity wall with the “code” part of this project.

Needless to say here is my 6 year old’s first lines of code:

    public Earth(){    
        super(750, 750, 1); 
        addObject(new Turtle(), 0,350);
        Greenfoot.playSound("mnhaon.mp3");
    }

and the 4 year old’s in the Turtle class:

public void act(){
    moveLeft();
}

It took us roughly 30 minutes of them typing (20 minutes) and going through the greenfoot API docs by themselves (10 minutes) to get that done. At this point and time they saw a turtle run left across a white screen and they were done, shutdoor. I expected this so I did have a back up plan….

Making media for the game: They spent the remainder of or time making trucks, turtles, backgrounds and recording sounds for the game. I wrote the remaining code and added some snips from Michael Kölling’s blog.

What we learned:

  • Making games together can be fun and we can actually get something enjoyable done in a short period of time.
  • Greenfoot is a great platform for new developers and there are others out there such as: Alice, Kudo, scratch and others, so there is really no excuse to not teach your kids if they are interested.
  • My boys were too young (6 and 5 years old) to code. Kind of obvious but I really wanted to see where they were at as far as logic thinkers - I was impressed with there ability to articulate what they wanted to do all I had to do was write the code

The bits:

If you have time please let my boys know what you think about their project, I know they’ed love to see your comments and thoughts, they worked really hard and I am super proud of them for doing all that they did and trying as hard as they did. Related posts: kid gamification – planning, kid gamification – day 1, kid gamification – day 2

Kid Gamification - Day 2

| Comments

The boys wanted to get stomping on the project code right away (I did too) but I knew this would be a great opportunity to distill some of the assumed magic of code and that it takes a lot more than copy-n-paste and a browser. I think a lot is gained and lost on the magic of the interwebs with the “it just works” mentality. Not that things have to be difficult or over baked but I believe that there is much to be gained for having a “big picture” perspective to software.

Today we focused on:

  • getting our project all planned out using sudo scrum (didn’t want to get wrapped up in teaching them the process in depth; just that there is a process and it can help)
  • a repo going on github
  • creating a greenfoot scenario
  • theme music - because every great game has cool theme music, and we were doing a lot of admin stuff for the project and I wanted the kids to have fun mixing music.

Project planning:

Using scrum, we generated cards and hijacked the grocery list whiteboard and began planning. I asked the kids questions like what do you want the game to do?, how do you think it should work?, how will you play the game? what do you want things to sound like? and so on. Their answers, to my surprise, were somewhat practical for a 5 and 6 year old. I assumed that they would say things like, “I want to control the turtle with my mind,” or “the turtle can fly and breathe fire to destroy the trucks.” The answered with we can use the “arrow keys” or “w:a:s:d” to move the turtle (apparently we need to lay off the games, their familiarity with default game controls and their ability to name them was frightening). Here are the resulting cards from their answers:

  • Make game sound effects(truck sounds, turtle sounds, turtle getting hit sounds)
  • Make code project
  • Make story about why the turtle is doing what he is doing
  • Make the turtle and truck graphics
  • Make place to put our code so we dont loose it
  • Make music
  • Make turtle move
  • Make trucks move
  • Make world for trucks and turtle

Getting a repo going:

I let them type the commands in terminal, they said it felt like they were super spies trying to save the world (I never really thought of it that way…)

We…

  • generated ssh key - just follow the instructions here
  • setup a github account - just follow the instructions here
  • created a local repo - - just follow the instructions here
  • pushed the code

Creating a greenfoot scenario:

If you are parent of really young kiddos with limited attention spans like me I would recommend going through the greenfoot tutorial before you begin your senario with your kids. The tutorial will get greenfoot setup and get you aquatinted with the greenfoot API

Creating the theme music:

This was pretty fun. The kids mixed samples using Aviary audio editor. You can listen to the sample mix here.

Once we did the mixdown on the samples we made into an mp3 using the same tool and added it to our github repo.

That was it for today. Tomorrow we should have some working code g2g. We will spend the next 3 days working on code, testing and content. Finishing the game at the end of the week.

Related posts: kid gamification – planning, kid gamification – day 1, kid gamification – day 3, the finale

Kid Gamification - Day 1

| Comments

Day one consisted of a bunch of idea gathering. My kiddos have vivid imaginations and most of the time when you talk about games they click right into minecraft mode and that’s about all they can talk about. While I am a big fan of Markus Persson and his work, I told the boys they should come up with their own unique story and game flavors.

I told them to begin drawing pictures and just talking out loud about what they were thinking they wanted from a game. As they talked I wrote down key words that they said that had to do with: game name, characters (antagonist, protagonist), environment, and story line.

One idea was… Game name: Lego Minecraft Characters: protagonist - Lego guy, antagonist - environment Environment: Total mutable world Cool idea but it has really already been done.



Another idea was… Game name: MnHAON (no idea where he got the game name) Characters: protagonist - trucks, antagonist - turtle Environment: A road with moving cars, etc.. much like a frogger clone



We ended the hour with a couple of really good ideas where we picked the one titled “MnHAON” and decided to move on it.

We also decided on using greenfoot (i.e. java) for the project based on the simple API and java being a pretty simple language to pick up quickly.

Tomorrow we are planning on:

  • Create our scrum board and cards
  • Creating a github repo for the project
  • Creating the “theme” music using aviary
  • Creating a greenfoot project and push it to github

Related posts: kid gamification – planning, kid gamification – day 2, kid gamification – day 3, the finale

Kid Gamification - Planning

| Comments

Being a homeschooling dad who is a self proclaimed nerd comes with a great deal of responsibility and it also tools my children in extremely unique ways. We just brought our newest baby girl home (yes, she is awesome!) and I am taking 2 weeks off to help my wife with the adjustments that come with having another baby at home. One way I am helping is taking over the homeschooling for a couple of weeks.

I know what your thinking: 4 boys and dad, mom is cuddling with the new baby girl – video games, junk food and movies, whoo hoo!! Well, almost…

My wonderful wife hooked me up with a lesson plan and the directive: “If you just get one or two things done that will be great.” Looking over the curriculum I saw math, reading, handwriting(who needs that?), science (cool we can blow stuff up), history (really that’s where that subject should stay), and so on. I mean my wife has this thing put together so well I felt like I might actually be able to pull off teaching my kids something other than the Konami code (a.k.a the Contra code) or how to beat Zelda (which we did).

Something felt like it was missing. So for two weeks we decided to ditch history and replace it with developing a game from 0 bits to shared. I will be teaching my 6 and 5 year olds with the following in mind:

The constraints:

  1. The source must be shared via github and in a compiled playable format with in two weeks.
  2. The focus will be on creating, experiencing and sharing code not the framework or deep syntax itself (so we will be using greenfoot, gosu or something like them).
  3. The two students will write all of the code using XP and scrum with an occasional booster script from me
  4. The two students provide all of the content: music, graphics, story and code
  5. We will have fun

I am really looking forward to taking on this challenge and will be chronicling it daily, so keep up with us and follow what we are doing. I know the boys and I hope that it will inspire other parents and kids to try it out and see how far a little creativity will take them.

subscribe to follow our progress

Related posts: kid gamification – day 1, kid gamification – day 2, kid gamification – day 3, the finale

Mowed Grass

| Comments

I like the smell of mowed grass. It reminds me of things like spring, new things and that something just got done.

Most of us have lists. I call mine the “grrr” list (pronounced grrr). This is a list of things that constantly irritate you about the software you write but for some reason you just cannot stop to address it.

My personal software grrr list has things on it such as: rip out old data model and replace it with the new shiny one I just built, change doc-type on all of my sites – so that I can-haz HTML 5 or move all of my domain names to one provider.

The things on your grrr list are important because they cause you grief and no one likes a constant stream of grief (re: Frasier). Do yourself a favor and create a grrr list – and in moments where you could watch re-runs of Frasier instead do something on that list.

You’ll feel accomplished and less frustrated with the software you write. Then you can go outside and do something you’ve been putting off, like mowing the grass.

Ticking Clock

| Comments

Ever stop to listen to a ticking clock? It’s one of those things you don’t hear unless you think about it, or someone asks you, ”ever stop to listen to a ticking clock?”

That seems to be much like some software deployments I been evolved with over the years. The software goes out into production and no one pays attention until the alarm goes off.

As devs pushing bits into the hands of our beloved customers, why don’t we take some time to listen to the tick of the clock. You can do this by checking the logs after a deployment, monitor cpu / memory usage or my personal favorite get a tool like newrelic and see what the impact of what you just pushed really is.

the take away: just because it was deployed to ”production” does not mean it’s done or you’re done – take time to look at what your software is doing after a release it WILL pay off.

The Lowdown and Star Trek

| Comments

Let’s be honest, we have a lot of code, right? According to guys like Michael Feathers: “code you wrote yesterday is legacy code” and Jez Humble: “if you’re working with that code only test what you impact – don’t try to generate coverage.”

So with all of the legacy out there who’s dealing with the underbelly of our software stacks, you know “the lowdown” where no one dares to go.

Seems to me we need to be a little like Captain Kirk. He wasn’t scared to go places where no one had been. A little unknown nerd history on the juggernaut legacy of Star Trek – Gene Roddenberry, the creator, wanted to build something that was an adventure while simultaneously conveying a moral point and political agenda. Kirk was one such character who could carry out that agenda.

Let’s pretend Captain Kirk was a night time hacker – what would that look like next to how the show played out:

The Plan

Captain: Crew set out to do something routine

Coder: Kirk decides, “Hey let’s do a twitter mashup in one of my existing apps. I want to be able to tell all of the ladies how cool I am in my yellow an black stretchy outfit.”

The Distraction

Captain: Somewhere along the way they get a call: “Planet O’ ladies are in trouble, only Kirk can save them, please hurry.”

Coder: “Crap,” says Kirk, “I have to create OAuth hooks, and it looks like all of the models in this app use .net SOAP web services and there are no flippin tests!!!” “efffffffffffffff!, The boss is gonna kill me!” Kirk exclaims.

The Moral Dilemma

Captain: The Captain must decide, should I follow orders and go or should I do the “right” thing and save the ladies, errr um, the planet.

Coder: Scratching his head he thinks: “do I give up on the app, this legacy code is gonna kill me. Or do I rewrite it so that it actually looks and works like software.”

The Decision (this is where a lot of us go off the reservation)

Captain: “Think of the lady planet, they need me! I choose yes! I choose refractor, regardless of the dangers i’ll face.”

Coder: “Think of the ladies, they need my fashion tips! I choose refractor, regardless of the dangers i’ll face.”

The Victory

Captain: He arrives, struggles with the bad guy aptly named SOAP (what, it’s my story) , looses his shirt (so that they can have a show that both the man and woman will watch), saves the planet, gets forgiven for getting off task, and there is much celebration.

Coder: He begins writing tests, refactor, test, refactor, kills the bad guy named SOAP, implements his twitter client, gets forgiven for a little scope bleed, builds a killer app, and all of the ladies rejoice because now they see that most of his fashion is based on a breakaway design.

As dangerous as it may seem we need to deal with the lowdown and be like Kirk.

the point: Go hunting occasionally – code smells are not hard to find and there will always be something to refactor.