Saturday, April 11, 2015

Reviewing the code review

Lots of software development based companies do code reviews, yet for the most part I find that code reviews more of a laugh than anything, well at least how it's done in the formal company setting. 

What I have observed is:
  • People who submit code reviews are just doing it because it's part of the process, that unnecessary evil that you have to endure to get your code merged into the repository ?
  • Unnecessary ? How many people who do software development daily really keeps an open mind when their code is sent for review and suggestions are made ? What I find is these developers already find their code working perfectly and does not need a change. If that is the case, why not just send me an email telling me that you will be checking so and so code into the repo and just give me a heads up. I know where you stand and you are not really asking me for a code review just letting me know that you will be checking stuff into the main repository. 

A code style document guideline

Code styles are like belly buttons .... any programmer who has written more than 10 lines of code using a language has one. Let's face it, everybody has an opinion on why 80 column rules matter or how stupid indentation rules are. Everybody has preferences and trying to cater for everybody's taste preferences is just stupid. Make it clear. This is the code style we prefer here. All major projects OS have it.

Tell me this, if we can have guidelines on code style, standards on testing and others, why don't we have a team agreed standards on reviews guidelines or more aptly called a code style document. Essentially what should be reviewed and what is considered superfluous. What is is considered good style and what is not. I for one would find it extremely useful if there was a guide that told me what is considered useful review and what is considered Nazism before I do a review instead of being beat down by a snide retort in a code review.

Each team too has their own "unwritten rule" about what is deemed important and what is not as part of code style and reviews. Why not make the unwritten rule a written one, giving an easier time the newbie or the outside joining the group. The bulk of the time should be spent feeling around the nuances of the code not for feeling around where the invisible lines and rules are.

You know what, if a standard is not going to be obeyed within a code base, it's really okay, just frigging document it down somewhere so that every single person who work on the code from day one knows it if they read the documentation. If they don't then beat them into pulp in the code review.  I would rather spend a few minutes bitching about how I feel a style is stupid but knowing not to bring it up in the review rather than spending time on a to and fro session in the review process trying to prove or defend how smart I am.

The goblin here does not lie in a bad style rather inconsistencies. Reading and understanding code, traversing the code logic is already hard enough, why add another layer of style inconsistencies to make matter worse ?

Make the unwritten erm ... written ?

If there are too many "unwritten rules" in your team, usually one of these things exist:
  1. A few senior coders or developers who have a certain idea of what constitutes good style which deviates from the standard recommendation but is unwilling to put into written rules.
  2. Learning the rules is thought of as learning process and part of the induction of a new member to the team. 
  3. There are a few opinionated team members who have unofficially beaten others to a pulp in a prior review, but still again did not document or went the step of formalizing what they think into a style document or rule. Refer to #1.
Both in my opinion results in waste of time. Why all the unwritten rules ? Just write it down, document it if the team feels that this is important enough to make into an "unwritten rule". #2 should not be used as a learning process. If this is part of the learning process, think of the countless hours and saved effort in to and fro of reviews you can achieve by just writing and documenting what the team or company considers as their internal code style practices.

Rules to enforcement

Collect all of the agreed style practices and using something like editorconfig, enforce it!  If a junior member feels strongly enough to change a standard practice, then use something along the lines of writing a Python PEP process to filter their conviction behind their reason for change. You want something changed, write a proposal on why the team should adopt it. Vote on it, deliberate over it but above all else document it! I know everybody wants to be a liberal, hear out everybody's idea but at the end of the day I think a lot of frustration and hassle could be avoided if everybody was clear right from the get go what is open for discussion and what is not.

Saturday, December 6, 2014

Links and app finds of the week

Links of the week

After having a child, I joined the scores of parents around the world grimacing when checking out the rising prices of children books, so this link was a god send:

Easy way to share a file and set up a chat session ? aka. "Why didn't I think of this first ?!"


Insightful article of the week :

Spiritual Project Management

This one will be another one of those sites, which I will go to from time to time for a pick me up from a spiritual perspective. What is unique about this site is that he, the author tackles some of life hardest questions with easy to understand writing with great illustrations to boot.  Wish I had this resource during my awkward growing up phase. Well, guess it's never too late since I am just in the middle of that phase now!

Oliver Emberton

Watch anime online ! Nuff said!


Currently watching Ghost Hunt and Parasyte. Tokyo Ghouls was great but then the ending a bit too abrupt and dangling for my taste.

Apps of the week

Another one of those apps so simple to use and made so much sense, I am still beating my head wondering why I did not think of it first ...

Cheat Sheet

Fancy a great gui tool for tangling with github on a Mac, then you can't do worse than use their own tool ! There is however me thinks a missing link in my workflow when working with this app however which is the ability to fork the project from the app itself. For that you are better off using hub for github.

Github for Mac

I have always wanted to create a childrens' book and lately the urge just got stronger, yet searching for a self publishing tool for children book brings you through the seedier part of the Interwebs. Ironic if you ask me. Anyway, I found a somewhat usable tool for this from, please note this is a heavy install.

Amazon's Kindle Book Creator

Yes you guessed it, YET ANOTHER EDITOR ... this time written (partly) in Scala, presenting, claim to fame ? Welll, it's a lot like Emacs ?


Wednesday, December 3, 2014

Re-look at circleci part duex a review ?

One great comment from part 1 of this post is the fact that circleci does not really support parallelism like they promised for Open Source projects.

Finding no information on any searches on how to enabled it, I finally contacted their support team on their "hip chat" app and got response immediately. Turns out it's a bug on circleci itself and they have since enabled it.

I can now have 4 parallel cores or instances or whatever you want to call it for my project which is good. As supports go, I feel ... uh supported well by circleci group of support folks. They are responsive and they get back to you quickly.

After parallelism, I want to try deployment for my project next to see how that performs.  However, as my project itself is so simple with just one test, would be rather big of a stretch trying to parallelism to work on it. Perhaps should try parallelism on some other project that I have. 

Checkout the screen below for what the parallelism screen should look like for an open source project:

Saturday, November 29, 2014

Re-look at circleci

Recently got an email from announcing that they were changing some of their pricing models effectively making OpenSource projects free to run on circleci. Well let me just directly quote them:

While on the free plan you can run 1 build for private repositories and 3 builds for public repositories simultaneously. All other builds will queue and run once the earlier ones finish. You can always add additional containers to run more builds simultaneously or take advantage of parallelism and get your test suite running faster.

For the full link to their announcement fly on here

On the band wagon I was in less than 2 seconds. I had to scratch that niggling itch I had initially of not being able to get it to work with Radpath, my Elixir baby.

I am glad I did. There are some things I really like about it:

  1. The main thing. Cache folders period. The ability for me to set cache folders greatly cuts down on the time it takes to run tests. For Radpath, it completed first way ahead of Travis and Drone. This to me is the main reason I started paying attention again.
  2. Ability to let you open up a ssh session to check on running test by just the flick on an option. It's slightly rough and induced a few minutes of head scratching, but I am glad this is there.
  3. Parallelism sounds just great to me, and I am itching to try this feature next. 
  4. The configuration file does not require you to understand rocket science and is pretty much self explanatory. See below
  5. Great support. I got personal emails from some of their devels even though I was still pretty much a freeloader up until now. 
Check out the sample configuration file below:

For those running Elixir projects, you can use my ci scripts as a sample:

They do support quite a wide range of languages out of the gate:
  1. Ruby/Rails
  2. Python
  3. Node.js
  4. PHP
  5. Java and even
  6. Haskell
Other languages you can still get at it using custom installations
So, yes second time around testing with CircleCI, they have got my attention. I am curious to see what they are up to next. Try it, who knows you might just be pleasantly surprised. Happy CI-ing!

Friday, March 28, 2014

Elixir and breakage on Travis

Development on Elixir is still moving at break neck speed and currently they have bumped up their Erlang version to support RB17-r1 for the map support.

There is a lot of delicious goodness that will eventually come but this also causes a lot of fun breakage on Travis and if you test your projects there.

Currently while Travis supports RB17-r1 in their otp_release, you might want to choose not to test your apps against that. If that is the case, you can change your .travis.yml from using trunk to using a release by changing the steps a little bit:

     - R16B03-1
     - git clone git://
     - cd elixir && make && cd ..
    - "export PATH=`pwd`/elixir/bin:$PATH"
    - export PATH=`pwd`/elixir/bin:$PATH
     - MIX_ENV=test mix do deps.get
     - MIX_ENV=test mix test
    - R16B02
    - wget -c
    - tar -xvzf v0.12.5.tar.gz
    - cd elixir-0.12.5 && make && cd ..
    - export PATH=`pwd`/elixir-0.12.5/bin:$PATH
    - MIX_ENV=test mix do deps.get
    - MIX_ENV=test mix do deps.compile
    - MIX_ENV=test mix amrita --trace 

The settings should be something similar. 
Found a better way of doing this which is you don't really have to use the manual wget method but you can just clone the repo then check out a branch within it. That way you don't have to tangle with all the version string messiness. Check out my final version:

Monday, March 17, 2014

Eixir: Radpath -> A library inspired by Python's

Have not been spending a lot of quality time with Python these days, rather have been trying my hand at being a polyglot and trying out a few of them new languages over the horizon like:

I tried these languages mostly through the exercises in which was really a refreshing time away from my beloved Python who I have used for years. Taking a holiday away from the true and tried sometimes and going on the path of least traveled can provide refreshing view on what you are doing and bring you back charged up with ideas. 

Out of all of them, Elixir with it's famous "|>" pipe-lining stuck with me and seemed to map with the noggin' the most with it's root mostly planted on the Ruby sphere with some Erlang love sprinkled here and there.

While using it's File and Path library, though I missed a lot of the OO style Python libraries, and seeing as how there didn't seem to be any good ones out there, I decided to go home one weekend and roll my own! There and behold, Radpath was born! I have only implemented some very basic functions like file listing with filtering, directory listing, and tempfiles.

While this is not really a Python post per-say, but I would say that the main inspiration for this library is the multitudes of great OO path libraries I have had the pleasure of using for all my time in Python, so enjoy the library and don't forget to leave a suggestion or two.

Monday, January 13, 2014

hsandbox: REPL-ing where there is none!

Yesterday while tinkering around with the go language and in the process of finding a nice REPL shell for it, I found this delightful little project called hsandbox. It's written in Python and employs a screen session with some clever engineering in the back end to provide you a nice REPL screen without installing anything extra on your machine. Just what I needed. Currently, hsandbox supports:

  •     C (hsandbox c)
  •     C++ (hsandbox cc)
  •     Clojure (hsandbox clj)
  •     C# (mono) (hsandbox cs)
  •     Erlang (hsandbox erl)
  •     Go (hsandbox go)
  •     Haskell (ghc) (hsandbox hs)
  •     Java (hsandbox java)
  •     Javascript (Node) (hsandbox js)
  •     Lua (hsandbox lua)
  •     Objective C (hsandbox m)
  •     Pascal (gpc) (hsandbox pas)
  •     PHP (hsandbox php)
  •     Perl (hsandbox pl)
  •     Python (hsandbox py)
  •     Ruby (hsandbox rb)
  •     Shell (sh) (hsandbox sh)
A screenshot of hsandbox running lua is shown below. The one thing that would be nice which I have asked for is the ability to clear the screen with a switch.

Ingenuity with the available tools always gets my respect! Bravo! Try it and see what you think.