Install Chrome under WSL

Even though WSL on Windows 10 is great at giving engineers a 'Nix-like environment on a Windows machine to develop, build and test; I ran into an issue where my Karma tests were failing due to the inability to find a suitable browser to execute the test suite one. I found some help online to help with installing a Chrome directly under the WSL. Below are the steps i used:

Debugging on WSL: Breakpoint ignored because generated code not found(source map problem?)

VSCode's support for debugging Typescript-based projects is really second to none in my opinion,  so much so that i made the switch from Atom.  Atom, though, is still is my goto editor for all my Terraform & other configuration-related projects.  Back to the topic at hand, debugging a React app on my Windows 10 machine with WSL enabled, my breakpoints were not triggered due to  'missing' source maps, even though the tsconfig.json had source maps generation enabled during transpilation.  I had followed the debug configuration setup described here.

Solution:
It turns out that running the application/debugging under the WSL,  this extra property is needed to be added to launch.json in order for the source maps to be found: sourceMapPathOverrides.

 

Infrastructure As Code - Terraform

Web first! Cloud first! That's the mantra at work, where the goal is to eventually move all existing apps to the cloud. Woohoo! Toss in the need for the apps to be platform-agnostic after years of being wedded to Microsoft stack and it makes for exciting times. After a quick comparison of the major cloud vendors out there in terms of richness of  offerings for what we intended, it's no surprise AWS won hands down. Prototyping by hand and running commands from the AWS CLI is okay for the trivial stuff like launching an EC2 instance or updating security groups. However, for things like CloudFormation where there was the need to launch and deal with multiple instances, the dependencies amongst themselves, correctly configured security groups based on generated IPs and manage all this within some source control; Terraform was the answer.  It's incredible that it's open source meaning we have the ability to fork the code (which I have :) ) and tweak things as we see fit without waiting for the community to address them.

Optimized Builds with Docker

Toying with Docker in the past, it's true power wasn't really revealed until it became a necessity on a API project due to the need to ensure that installed dependencies were the same regardless of which machine - dev or the build server itself was used. Essentially, the process was to define two Dockerfiles - one for building the .Net Core app and another for hosting only the necessary "build bits" from the earlier build. The former reduced the need for the Jenkins server to have all the required packages installed on it, and the latter was as an immutable tiny but fast image one could run locally or in prod.   Here's a more detailed instruction on how to do the same: Building Optimized Docker Images with ASP.Net Core. Hats off to the guys in Redmond!

These aren't the droids you're looking for!

For the past few days, i've spent time dipping my feet in the Android SDK and generally building baby apps to get a feel and understanding of them. This is in preparation for a larger app i'm building as part of my side projects at work so its fun all around. In the past, i've dabbled with Symbian S60 and pre- BB OS 7 but when it comes to app development the ease with which one can just get a working app installed and tested is astounding. Definitely loving it so far! 

Spring cleaning or sorts...

Finally got round to rebuilding my musty mouldy repo a couple of days back and began to check in some patches albeit easy ones just to get back in the groove. Next stop for me will be upgrading to VS2013. As usual, i need to have the best tool out there to play around with although emacs & Eclipse will continue to be my main preference for development. What can i say? A dork gotta have his toy.

Catching up...

Well it's been quite a while. Okay, a year since my last post. I could have used the recent “polar vortex” as a reason for the incredible delay but no - it's not even a remotely plausible excuse. Briefly, a recap of that undocumented year. Beginning with the most major, i finally ditched using Windows as my main OS for both coding and “recreational” activities and switched entirely everything to Linux; long overdue, on my part. The reasons being multiple. Right off the bat, as there was no suitable Win-based open source alternative for ccache, mind you, my build times ranged anywhere from 55-71 mins for full clobber builds and about 30mins for incremental builds. Again the latter time was fully dependent on which parts for the tree i had made local changes to. Honestly, fiddling my thumbs during those periods, especially early mornings when i had to pull new commits and update my local repo just got more and more frustrating. Toss in the lack of full Intellisense support even while using Visual Studio made my code edits even slower. A refactoring attempt was the final straw. With brilliant work done by Eclipse CDT developer, Andrew Gvozdev, which in turn allowed an easier time setting up and using the IDE for Mozilla C++ development, it was time to jump ship. Of course, emacs or vim could've been handy but hey it's a new millennium and in my case only a memory hungry editor with all the bells and whistles will do. With the switch, it's refreshing to see build times cut down to ~25mins for full clobber and ~4mins - max i've seen so far- for the incremental ones on my core i5 6GB RAM machine. Obviously,  with *nix's less overhead in process creation compared to Win, it fits nicely with the build system Mozilla has. It's mouthwatering to think what it'll be under a machine with a greater processing speed, RAM and of course SSD type disk. Stupefying, one could say.

Overall, i did get some nice things done such as the LLVMpipe fallback WebGL renderer option for Win and *nix users with a somewhat obsolete hardware who attempt to access and play around with cool things such as the interactive demos seen at the Chrome Experiments. By default Firefox, will use whatever software renderer is available, that is, the existing native GL driver. To explicitly use it, the user must manually change the gfx.prefer-mesa-llvmpipe configuration to true, assuming there's such a pre-built library located on the system to begin with. For those interested in the nitty gritty on how to build one locally, see: https://sites.google.com/site/buildllvmpipe/. Currently, i've thrown in my lot with the implementation of the WebVTT format. A fellow contributor, Rick Eyre, has an excellent blog post on what's been done and aim to achieve in the long term so i wont go into details here but with Apple and few others already stealing a march on us, it'll be most welcome to have more contributors to get it all polished and ready for the public. All hands to the pump, i say! Again for the curious to test out what's been implemented so far, turn this config option: media.webvtt.enabled on and sample a few demos online or even better create your own!

Enough of the techie stuff!

The fun part was hiking some of the popular trails again -for the umpteenth time - of the wonderful Long Trail and attempting my best impression of a daredevil Lance Armstrong during the summer; just the cycling part and not the other unsavory bits....As a rabid Liverpool fan, one can only expect me to be equally passionate when i play football(fussball? futbol?)- loathe to call it soccer. A man of the match performance as a defensive midfield terrier with two assists and a highly rare goal was the summer highlight personally. There's nothing like hobbling off the field of play feeling like a Marco Materazzi-cum-Vinnie Jones rolled into one. Secretly, i think if opposing teams knew the reason for my admiration of players like Nigel “The Lawnmower” De Jong, i very much doubt they'd dribble in my direction. [Cue: insidious laughter]