Category: Software Engineering

Coding, Python, web development, architecture, and deployment

  • Slot Machines

    For the last couple of evenings I have been learning about slot machines and how they work.  There is actually quite a bit more to them than first meets the eye.

    I have a side project going to build a slot machine server application that can simulate many kinds of slot machine games.  Given the set of rules and reels it will build a playable demo, as well as produce all of the mathematical model statistics for the particular game such as how much money it will return to the player over time and what the volatility is.

    Designing a game engine that can handle all of the possible variations in slot machine gameplay is not easy.

    Ultimately this game simulator will be used to push different games down to a mobile app, which itself will need to dynamically render the reels, graphics, and animations that were set on the server.

    The complexity of this side project has kind of ballooned a bit.

  • 1 Thing Programmers Should Do More Often

    This past week I found myself with a task of creating pages on this site for all the Mobile Apps that have been developed by Halotis Inc. At the same time I wanted to get the marketing material organized for all of those apps in a consistent directory structure.

    Which lead me to something I believe more programmers should do more often. Write Automation Scripts. Rather than manually create the directory structure for 23 different Apps and find all those apps in the App Store to get their descriptions and screenshots. I was able to write a script to create the directory structure, search iTunes, pull out relevant information, and download all the screenshots.

    It’s what I love most about Python. It becomes so easy to find a decent library for any public API, and quickly whip up a command line utility to automate what would otherwise be a tedious task.

    Getting good at writing these sorts of automated scripts is a differentiator. After a while of writing them, you build up a library of neat scripts that can help you day to day to get more done in less time.

    A script, once written, becomes an asset to be possibly used again and again in the future.

  • White Shoe Syndrome

    You know what you need to do to launch your business, you have the skills, you have the idea, and yet progress is slow. Maybe you have White Shoe Syndrome.

    The problem with white shoes is that they are always dirty and need to be cleaned. When it is time to sit down at your desk to do some work that pair of white tennis shoes is in the corner of your office just screaming at you to clean them. Even in the dead of winter when you are months away from lacing up those white shoes for some reason now is the right time to clean your shoes.

    Of course it doesn’t have to be white shoes. If you are sitting down to do some work and minutes later you find yourself tidying your office, or mowing the lawn, or re-organizing your stamp collection then you are a victim of white shoes syndrome.

    The tricks to overcome this is:

    • Isolation – close the office door, put on some headphones or anything else you can do to physically isolate yourself from visual noise and disruption
    • Minimize clutter – clear your desk, minimize your office, move files off your desktop, run your software full screen
    • Turn off notifications – turn off auto-email checking, disconnect from chat, turn off calendar alerts
    • Turn off the lights – working in the dark can help you focus on what’s on your computer screen
    • Before or after hours – try working early in the morning, or late in the evening when other people are not around.
    • Go somewhere to work – you won’t be inclined to clean the counters at the coffeeshop

    White Shoes can be a real roadblock to your success.  Try to do what you can to avoid it.

  • Free Coding

    Getting into the flow or zone as a coder is when you are your most productive and code spews from your fingers into your favourite text editor as fast as you can type. When in the zone you can seemingly pour out 100’s of lines of code in no time.

    But how do you get into the zone other than by pure happenstance?

    Authors have a technique called free writing which was popularized in Julia Cameron’s The Artist’s Wayfor which the rules are simple:

    • Select an amount of time: 5, 10, 20 minutes for example
    • Write continuosly and quickly for that amount of time ignoring spelling, grammar, formatting
    • If you can’t think of things to write, write about that or simply scribble. just keep things going from your brain to the page.
    • When your time is up, review what was written and mark anything interesting to explore further in a future free writing session

    The goal of free writing is to build up enough momentum to blast through mental blocks and quickly transition to a state of flow for the real writing process. It is meant to be done daily as part of a morning routine before real work starts.

    I’m curious if a similar technique could be used to get into the zone for coding. A quick Google search revealed no information about anyone exploring this idea so I thought I would.

    Here are the rules I’m using for freecoding:

    1. Pick an amount of time before hand 5, 10, or 20 minutes for example
    2. Use a text editor where I can turn off syntax highlighting (to avoid the impulse to go back and fix typos)
    3. Code in a language that I know well enough to code without referring to documentation
    4. start coding and don’t stop typing. If you can’t think of something to code just code about that. it doesn’t have to run, it doesn’t have to make sense or be correct syntax. Try not to go back to code out of order.
    5. Don’t try to accomplish anything that will require you to stop to think. ie. don’t try to implement your favourite sorting algorithm.
    6. If you code yourself into a spot where you don’t know the API well enough, just fake it out with a call to a magical function that does what you want.

    When time is up, turn on syntax highlighting and read what you wrote. Make notes about anything interesting that you’d like to explore again in the future. Note things that you were hung up on with syntax or APIs that you should brush up on.

    The purpose of freecoding is to limber up your mind before starting real code. The secondary benefit is to identify gaps in your knowledge of a language or library where you might have to stop to look up the documentation.

    Use the momentum built up in the freecoding session to launch into a real project. Try to keep the transition freecoding and real code somewhat smooth

    As an example here’s part of what I did in my first 5 minute freecoding session:

    a = 'hi there'
    
    b = a.replace('hi', 'bye')
    
    a. reverse()
    
    c = fun(a)
    
    def requestA(a):
        return GoogleThis(a)
    
    if requstA(a) == 'no results':
        println("there's nothing in the google machine")
        return tryBingInstead(a)
    
    requestA('matt warren')
    
    b = b.capitalize()
    b = b.reverse()
    b = b.capitalize()
    println(b)
    
    not_sure_what_to_type = b
    
    def star_trek_is_better_than_star_wars():
        return true
    
    if star_trek_is_better_than_star_wars:
        print "hell yeah"
    

    There’s nothing interesting going on here, it’s not complete thoughts and doesn’t accomplish anything nor does it run. the point is to simply start getting a flow of code coming by reducing any blocks that might prevent it (in this case by removing the need to create something that runs or even makes sense).

    Upon reviewing this particular session I might decide that the concept of using bing as a backup for google is interesting, and that I need to increase my vocabulary of string functions to call upon.

    In my limited trials so far it’s clear that there is a bit of a skill to freecoding successfully. For all other coding you do there is a goal to reach, something specific you want to implement. I suspect that after a couple weeks of regularly freecoding the code will start to get more complex, better structured, and longer thought streams of cohesive code segments.

    I am still early on in my experimenting with this concept. However, if it is as effective as free writing is for authors, then perhaps free coding can be a daily ritual more of us can use to boost our productivity. I’d like to encourage every software developer to give it a try and report back (if they like) with how it worked or didn’t work for you.

  • Tele 10 Finished

    One more thing to knock off the bucket list.  Yesterday Heather and I finished the Tele 10 race in St. John’s.  My time was good considering zero training runs over the last few months.  I was counting on the adaptation to Calgary altitude to help me power through the race.  That seemed to work.  At no point in the race was I straining for breath and I was able to do the race without stopping to walk.

    The Tele 10 was one of the best runs I’ve done. Having a mostly downhill course was nice and the crowds are huge with cheers coming all along the route.  One thing I wasn’t quite prepared for was the level of humidity. The sweat never seemed to evaporate and as a result it was easy to overheat. At one point near the end some salty sweat dripped into my eye and was quite a distraction until I got a bottle of water to wash it out.

    Final time was 1:47. which could have been improved on with some training but I’m happy with because it didn’t feel difficult.  When I woke up in the morning I was still feeling jet lagged and wasn’t sure I’d be able to finish.

  • Manager Who Codes vs Developer Team Lead

    Personal branding is deceptively effective in many cases.

    The difference is skills between a manager who codes and a developer team lead is negligible.  In many cases you could say they are job titles that describe the same role in a company and yet from a HR and status point of view they are very different.

    If you’re getting hired into a position having presented yourself as management material with the bonus of having technical skills then you get lobbed easy questions in a relaxed setting (usually).  The hiring decision is based more on fuzzy “I liked her” type of gut reactions than any type of objective assessment of skills.  With this initial staging you are more likely to be treated as an equal with other “higher status” management employees.  And any technical skills you have will be treated as a bonus.

    Brand yourself as a developer with team lead experience and you will get a barrage of technical questions.  A high stress examination of how well you know obscure algorithms, or specific programming language APIs. In this case any holes in your knowledge will be assessed as negatives.

    The difference in hiring practices between these two roles is night and day.

    With this admittedly specific and anecdotal comparison it would be interesting to see just how real and widespread this effect can be.

    In my experience there seems to be a causal relation between what you internally believe your self worth to be, and the employment positions you get.  A strong personal brand comes out naturally when you have the confidence to tackle a “higher status” role.

    If there’s a lesson here it’s this:

    Position yourself for the future you want to have and there’s a better chance you’ll get it.

  • Reading Fewer Blogs

    For years I have had an extensive reading list of blogs that I read through everyday.  Scanning through 200+ blog posts per day was a way for me to keep up with the latest things happening.  However, the time it takes to read through everything was significant. I’ve decided to greatly reduce my subscribed blogs and have cut it from 200+ posts/day  down to 20 per day.

    The intention isn’t to cut down on my time for reading but to finish reading more books.  Books as opposed to blogs are higher quality writing. Published authors go through multiple stages of review; ideas have been curated and much more thought out and the words edited many times over before making it to print. As a result, books seem to offer more value.

    I have a stack of books that have been taking a very long time to whittle away at and I want to get through them.  Hopefully this change will help.

  • Ada Walking

    On Tuesday, Ada took her first un-assisted steps.  It’ll be a while until she develops the confidence to really get around the house on her own, but clearly that time is coming.

    I was convinced that she would be walking much earlier than this.  She was putting weight on her legs since she was 1 week old and I have been walking her around the house holding her hands for the past 4 months.  During those past 4 months I have been slowly providing less support.  She’s had the strength to walk on her own for a while, but the coordination, balance and confidence needed to catch up.

    We’re starting to see the difficulty that will happen when she run around the house.  Ada’s mobility skills are outstripping her english so we are having to close doors and baby proof the house a bit.  She doesn’t yet understand that rolling off the bed is a bad idea.  There’s no way to explain it to someone with zero vocabulary.

  • Microservices

    The term Service Oriented Architecture has been twisted by so many people now that it has lost some of it’s meaning. Microservices is a software architecture for web apps that aims to define a more specific way of doing SOA that isn’t so fuzzy and hand wavy.

    Web applications have long been developed in a SOA way.  Especially with the advent of PaaSes like Heroku which make it easy to bolt on services.  But even when building an app to run on Heroku it’s easy to create a monolithic application which may better be segmented into separate services.

    By dividing your application into micro services you can focus on clear contracts and well defined APIs. If you have an application that can be divided between people to work on then micro services allow you to reduce the cognitive burden of understanding the entire application.  It makes regression errors less likely, and gives you the focus to produce a high quality service.

    You can go pretty far with micro services.

    Exactly how micro you go can depend on your goals and the size/requirements of your project.

    A project I’m working on now will be creating a separate analytics service.  By pulling this API into a distinct application we were able to choose a different technology stack that  was better suited to the requirements.  For uptime and performance it made sense to write the analytics API in Go, this provides nearly 10x the performance of our usual Rails stack.  Given that we expect the reporting app (in Rails) to be updated far more often than the analytics gathering API it’s valuable to isolate it.

    This separation is just the start. In a micro service architected system you can go so far as to pull out user accounts, generating reports, sending reports, processing various things etc. all into their own stand alone service.  Then tie everything together with asynchronous message bus so that if a service goes down messages are queued and nothing gets lost.

    There are some performance issues to be aware of.  A request going through a message bus adds significantly more overhead compared to a function call.  As a result some thought should be made on how to design the API with some performance considerations. Perhaps adding a bulk update operation as an example.

    The benefits to pulling off a successful micro service architecture can be huge for managing the scalability of a big system.  If you have a project that is going to be big enough to require 4-5+ full time developers then consider micro services so that you can divide the work into multiple stand alone micro services.

  • Rhinoceros

    1024px-Waterberg_Nashorn2

    In a recent meeting with my boss he asked everyone to be more like a rhinoceros.  You can’t stop a rhino when it’s moving forward and you definitely can’t push it backwards.  It’s a situation that many of us find ourselves in.  A project or task runs into a small obstacle so we stop to reassess things or figure out how to get around the obstacle.  Whereas a rhino would have bulldozed right through the obstacle and perhaps made a mess but would have got to the other side without stopping.

    It’s not easy to be like a rhino and just power through the hiccups but sometimes its necessary to just get ‘er done.  Waiting for everything to be perfect is a sure way to not finish anything.

    Be unstoppable.