Sunday, January 7, 2018

Easily staying afloat on High Sierra

Whenever I use Mac I always miss "Always On Top" functionality for my windows. Don't ask me why up until today MacOS stubbornly refuses to add this functionality. Afloat is the closest I have found to make this work on Mac (though not all windows works)

The last time I tried installing Afloat, I had to slaughter a chicken and dance with it's blood smeared all over my body in the cold moonlight ... to make it work so this time when I my mini could not boot up anymore, I had to look find the way to install it again and I was filled with dread.  There are a few guides on getting it to work and a lot of them did not work or worked for earlier versions not the latest High Sierra. Finally I found this:

It's the easier to do, though you still probably have to reboot and disable System Integrity Protection on Mac. So finally it's working again ...

 Yayy ! Back to pretending to do something productive. 

Monday, October 3, 2016

Ansible experiment aka a review of my time using Ansible for building our deployment pipeline (part 1)

I have been playing around with Ansible and using it as a foray for Continuous Deployment. Few things I have read about Ansible is true:
  1. It's easy to read and get started on. Within minutes you can get a playbook started and someone else picking up on your work can definitely understand what you were trying to achieve.
  2. There is a minimum of requirements that you need, just a Ansible and whatever that it needs.
These are the few reasons why I like Ansible. After scratching my head for one or two days I pretty much wrote from scratch what I needed to perform my deployment script for our Django project. It was all very fast and painless.  You can say easy Ansible things are always easy to do. Some of these things are package installation, config management via templates etc.  These operations are a breeze and if your deployment only consists of these kinds of operations you will be thinking that Ansible is the best thing since sliced bread.

However hard things to do in Ansible turn out to be exceedingly hard to do, for example getting "psql" commands to idempotent turns out to be something really unwieldy such as this:

It can work, I have tried the answer, but then it still looks pretty much like a workaround to me.  Another thing that bugged me to no end is the fact that Ansible's test suites are so damn weak. I can appreciate the loftier goals of Ansible integration testing and would really appreciate if they can shoe implementation examples of these goals,  I am using Docker to build the test part of my playbook and at the end of the build I use a very simple selenium test using phantomjs to run a few tests like logging in and verifying that certain elements of our Django site is there and that will in the end give an assurance that the deployment is successful and the script is usable. Serverspec is there to ensure that services are configured correctly for example services are enabled during boot and configuration files are treated correctly.

Also, something practical that we do everyday like getting the deployment script to support two distributions (RedHat and Ubuntu in our case) can very much make your hitherto simple playbook grow and become this unwieldy monster. Our scripts for deployment is here:


This approach's weakness is however painfully obvious:

  • A huge toolchain. Everything needs to be installed and running by the numbers to achieve a green build. I really would rather just have an Ansible based integration test or a task that runs at the end to ensure that the site has been installed and running correctly. 
  • The build just takes too long, and more often than not strange problems occur which we are at a loss to explain. Debugging problems remotely on Travis sucks big time.
  • The command to run our playbook is overly complex now. 
 I have been thinking of a better way to do this and to make our script more dependable and run in half the time. I  know at this stage what I am saying sounds more like venting and ranty but then that is where the "Part 1" of this entry is all about. I will formalize what I say in concrete examples in the next few parts. While I might not like everything single thing I see about Ansible now, there are more positives than negatives that makes me still sitting in their camp.

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: