Just created a Ruby Gem

2017-09-30 01:31:00 +0000

I had this old Ruby script lying around which I was using to upload my sites to s3 whenever I wanted to deploy something new. However, as you can imagine, copying this script around was not the best solution as in time, I added bits here and there, updated to use new aws-sdk etc, and keeping them all in sync was getting tedious ...

Sooo, finally I nudged myself and put it in a gem. Ladies and Gentlemen, here is Emblaze ! It's basically a rake task to minify & gzip & and upload a static site to S3.

Some of you may wonder, "What does Emblaze have to do with uploading a site to cloud ?"

Well, rest assured, the name has nothing to do with what it does. Initially I had a mind to call it aws-s3-deploy. But it turns out, that name was already taken. Along with a whole sloth of similar candidates, like s3Deploy, s3Deployer, etc ... So I took the liberty to get creative .... So here you are with Emblaze !

What does it provide against the competition ? Well it's compatible with the latest aws-sdk. And just requires s3-sdk so I tried to keep the deps to a minimum. It's dotenv & travis compatible, so you can integrate it with your CI pipeline with minimum issues. I already use it to deploy all my sites.

Currently the site folder is fixed to _site. So it's geared towards Jekyll sites. But you can deploy anything with it. I can add customised upload dirs without much trouble. But I am kind of waiting for someone to come and ask for it :) it will be more fun !

Stellar Battery on Oxygen OS

2016-03-15 01:31:00 +0000

I have been getting stability issues with Cyanogen on my OPO lately, so I decided to give OnePlus's native OxygenOS a whirl. First I installed the initial version 1.0.0, which was kind of dated. I thought I could make my way into a newer version via OTA updates, alas, no there is no OTA available for OPO it seems, which is kind of baffling.

So I flashed the newest version, which was 2.1.4. It's still a 5.1.1 Lollypop based build, but it was much more better polished. And the battery life I get with this ROM is simply amazing :

OxygenOS Rulez

With the Cyanogen, I could make one day, but that's it. If I forget to charge at night, it would definitely be off by morning. Cyanogen was good, but it went pretty straight downhill after they soldout to microsoft. I would never consider using them for any of my devices, ever.

Golang Gotchas

2016-02-26 14:11:00 +0000

I've been playing around with golang lately, and got to know its intricacies better. At first, I have to admit I was not very enthusiastic playing with it, but the more I got to know about it, the more I warmed to to its concepts. And I observed it has matured pretty well from version 1.1 when I first started to play with it to version 1.4 and 1.5 when I first got do to something useful using Go. Here I will summarise my Gotchas.

  1. Non versioned dependency management

    I'm not sure I even spelled this right. Golang has it's own package acquisition tool which you can invoke with go get This will install the specified dependency in your go path, and you can start using it in your project by importing it.

    The problem with this is that it doesn't allow for version management. You can't ask for a specific version, you have to do with whatever version the author provided.

    There are some tools out there which alleviate this issue, like go dep. It seems this registers a revision hash with the dependency, so when fetching it you get the specific version you want to get.

    I haven't used go dep myself, I circumvent the issue by forking the dependency to my own github account and use my forked repo as dependency. A nuisance, but not something that I tore my hair out for.

  2. No cyclic imports

    I ran into this a couple of times. I come from the ruby land, so it was rather strange why the import manage couldn't figure import order. It seems in ruby, since you can require all packages in some init file you don't run into this issue. You can't do this in Go, since it doesn't allow you to import something and leave it unused.

  3. No iterating over struct fields

    I'm not sure if I'm comparing apples and oranges here, but when you need to iterate over the variables of an plain ruby object, or attributes of an active model, the answer is usually only a method away. Go doesn't support much meta magic though, so when you need to do something like that you need to use reflection

        // returns a string representation of a struct.
        func GetStructStr(lead string, strct interface{}) string {
            str := lead
            tempintslice := []int{0}
            ielements := reflect.TypeOf(strct).Elem().NumField()
            for i := 0; i < ielements; i++ {
                tempintslice[0] = i
                f := reflect.TypeOf(strct).Elem().FieldByIndex(tempintslice)
                value := reflect.Indirect(reflect.ValueOf(strct)).FieldByName(f.Name)
                str += fmt.Sprintf(" %v: %v\n", f.Name, getStringVal(value))
            return str
  4. Lack of Generics aka. the interface{} Black Hole

    As you might have heard, Go doesn't support Generics. Which leads to much pain and copy-paste. Once you descend into interface{} hell, there is no turning back. But later I found out it supports alias types. Which takes most of the pain away. Ok it's poor mans generics, but gets the job done 90% of the time.

  5. Lack of Polymorphism

    This one is also little bit thorny issue. Go does not support polymorphism, so it's not an OOP in the sense you know. What it does have is interfaces, which are like function signatures which you can attach to Go types. Polymorphism in Go is kind of a controversial subject, but I think the golang team has chosen wisely to adopt a minimal polymorphic policy. It makes it clear what you need to do and guides the programmer to do the right thang (YMMV of course).

  6. Use capitalised names for managing visibility

    This is something I've really grown to love. Anything you want to export from your package, you can just capitalise the field name. And anything you want to hide, you can just lower case its name, and bam! it's gone. Simple, elegant, clean.

  7. Awesome Concurrency

    Unless you have been hiding in a cave for the last 5 years, Go has awesome support for concurrency. The official motto for concurrency in Go is Share Memory By Communicating which is actually an old concept inspired by a paper by C.A.R. Hoare. Concurrency in Go is simply amazing. It is very simple, elegant and easy to understand and debug, especially compared to alternatives in other languages. And it works and SCALES very well (unlike ahem some oter languages). Concurrency is something that Go really shines in, so you should really consider giving Go a go if you intend to write a heavily concurrent program.

  8. Pretty Good Cross Platform Support

    If you ever needed to write a program which needs to run in multiple platforms (ie, MacOs and Linux) and which will need to hit the Os directly in some cases, you know what a head ache and spaghetti it can be. Fortunately Go supports build constraints which can help you organize your code and build process nicely. Build constraints also work in file suffixes, so say if you have a package in report.go, you can have MacOs specific stuff in report_darwin.go and linux specific stuff in report_linux.go. And they will be package accordingly. Once again a simple solution which works really great.

Overall as you might have imagined, I'm pretty impressed by the language, and really looking forward to being able to do more with it. In the mean time, I'm also checking Elixir, which is another exiting new language. I am checking a new project which I hope I will be able to use it so I hope to be able to blog about it in some near future. Another interesting new language is Crystal, but I think it is little bit too young at the moment. They need to go little bit more and mature.

Switching Carriers

2015-12-29 14:11:00 +0000

Lately wifey's cellphone was acting up, so I got her a brand new One Plus X as a christmas present. Unfortunately, the SIM that was installed in her YMobile provided Huawei P7 didn't like the One Plus X. I'm not sure what was the problem, but we were not able to enter the Ymobile APN for some reason, and the default APN installed in the SIM didn't work in One Plus, and YMobile customer service were not able to help. So I decided to jump ship to Docomo based IIJmio which had a great family plan.

Before I jumped ship though, I took some benchmarks.

Phone Network Download Upload
One Plus One YMobile 4G 24.4 Mbps 2.2 Mbps
One Plus One Home Wifi (5G) 20.5 Mbps 14.1 Mbps
One Plus One Work Wifi 17.9 Mbps 9.7 Mbps
One Plus One Docomo 3G 3 Mbps 314 Kbps
One Plus X YMobile 4G 9 Mbps 8.2 Mbps
One Plus X Home Wifi (2G) 13.4 Mps 8.3 Mbps

Some notes :

  • I'm not sure why I was not able to use LTE on Docomo. Will check in different locations and contact mio support if this persists.
  • 4G on OPX seems slower than OPO. May have to do with restricted 4G bands on OPX. Though I'm not sure it has higher upload speed ?
  • OPX doesn't support 5G Wifi. Which is the biggest bummer on this otherwise fantastic phone.

Eddystone vs iBeacon

2015-10-30 09:49:00 +0000

If you are interested in IoT, you've probably heard of Estimote. They are probably the leading beacon provider in the IoT field and that's for a good reason. We've had their dev kit for a while, and had since been using them happily ever since. Their beacons quality is top notch, software frequently updated, and customer service usually responsive.

As of recently, Estimote annouced support for Google's Eddystone protocol, a beacon broadcast protocol which is a competitor to iBeacon from Apple. I will admit that I am a pretty much hopeless Google fanboy, since their products tend to give end users more freedom. But this time, we had a much better, concrete reason to jump ship from iBeacon to Eddystone, fleet management.

When iBeacon was launched, fleet management was probably not a very big concern, and Apple probably left it totally to the app developers, out of the protocols scope. Because of this, iBeacon supports only a simple UUID broadcast scheme. To get more specific info about the beacon, you need to poll this from the beacon directly. This is where things get ugly though, because polling information from the beacon also brings security concerns to the table. While Estimote has a key based security protocol, it was shown that it could be hacked and while Estimote have since updated their security protocol, beacon polling is still a pretty big security concern. And it is currently the only way to get other information (battery level, temperature, sensor readings etc) from your beacon, if you're using iBeacon as the broadcast protocol.

And that is where Eddystone steps in. Eddystone supports three packet types, UID, URL, and TLM (which stands for telemetry). UID packet is a iBeacon type packet which transmits a UID, for providing context information to your app. URL transmits a URL (no surprises there) and its use case is quite different, please check Physical Web if you are interested. An eddystone beacon is meant to be configured to broadcast either one of these two schemes, and in addition to these, it will also transmit a TLM packet, which will contain its battery level information and any other sensory data. This mitigates the need to poll the beacon, and obviously, the less you connect to it, more secure it is. Which prompted us to step in and jump ship to Eddystone.

Configuration on Estimote side was a breeze. With just a couple of taps on the official app, our beacons were transmitting Eddystone UIDs. Configuration on our backend was not so straightforward though. Since Eddystone is relatively new, I couldn't find any decoding libraries for Go. That's why I had to write Goodystone. I also prepared this bash script to play around and confirm my results. (While I was at it, I also refactored my iBeacon decoding logic to its own repo as well, which became I Be Gone haha, see what I did there ?)

In the end, this TLM packet really saved the day for us, because it was obvious polling the beacons for this would bring lots of issues. Another day to thank the big G I guess !

subscribe via RSS