Using Firefox with create-react-app

If you are using create-react-app to build your ReactJS applications (who isn't anyways?!), you may be wondering how to change the default browser when inside your development environment. As you might have noticed, by default, create-react-app is opinionated and tries to first launch the default browser or else Chrome, in that order.

But what if, you're like me, and prefer Firefox Developer Edition (or any other browser that is not as evil as Chrome)? Luckily, the core developers behind create-react-app have recently added support through the use of the environmental variable BROWSER.

My personal preference is to use a .env.development file in the root of the ReactJS project and embed the variable as follows:


Fixing random restarts on my late 2011 MacBook Pro


My constant love-hate relationship with Apple products has been going on since the last decade. My first Apple product was the (back then) ubiquitous 2006 white MacBook "Core Duo" 2.0. Man, that was a sweet machine. The first time I used it, it felt I was hacking on a cold marble slate with thoughtful design and an impeccable BSD operating system. Little I knew I was going to get addicted to that line of products, ranging from iPhones, to iPad and to more and more MacBooks.

The problem is that there is a price to pay. The extrinsic price which everyone knows - paying more than a grand. The intrinsic price being the constant turmoil with design flaws and stability issues.

I always likened a MacBook with a Fender Made in Mexico - if you manage to get a sweet tone loving MiM, good luck! Chances are, however, that you are not lucky at all, and end up with an instrument that needs continuous maintenance and attention due to poor QA processes.

Random Restarts

My latest battle was with a beautiful MacBook Pro 8,2 - for its time, as it was manufactured during late 2011, beginning 2012, (and I admit that this applies for nowadays as well), this was a heck and a beast of a machine. Donning the Sandy Bridge 2.4GHz quad core i7 processor, a 15.4" TFT screen and 8GB 1333 MHz DD3 RAM, it is a pleasure giving workhorse.

It had one serious design defect though, one that has led to the infamous RadeonGate - a class-action lawsuit which forced Apple to extend its repair extension program by two years. Suffice to say, Mr Murphy postulated a law for people like me, and this program is not available anymore.

So what is this serious design defect?

All MacBook Pros from 2011 have a design flaw whereby the thermal management and the generated heat together with the robustness of the discrete AMD graphics chips do not match up very well. Of course, Apple knew this and acted like a typical Soapy Smith, only reacting after the aforementioned class-action lawsuit.

So what?

This MacBook Pro has two graphics chips - an integrated  Intel and a discrete AMD Radeon X3000, the latter being defective. This AMD chip will heat up and cause the MacBook to restart randomly. If this chip goes bust, it makes the whole logic board unusable. With recent OSX updates, Apple wanted to keep the AMD chip alive by forcing more reboots to avoid TLC (total laptop combustion - ok sorry, I invented this acronym myself).

Now, get this, and please bear with me.

When I got this MacBook a couple of months ago, barely I knew what these random restarts where. I did everything, a systems engineer could possibly do - fsck the disk, re-installed O/S, kept the fans clean, checked all logic board solder joints, measure voltages at critical points in the logic board, etc. Until I started seeing something strange on the chip, which led me to this discovery.

Determining the problem actually took a month - due to my hectic schedule, I outsourced this process to two technicians, who are deemed to be the best in my country. I forked out EUR50 to get jack-shit fixed. One of them even had the audacity to tell me that his 'secret' magic sauce was installing a new firmware (a 1 minute job) and wanted to charge me EUR30 for that. Of course, I had already taken a stock information report before handing him my MacBook, and showed him that the latest firmware was already installed.

So with the bullshit being cut and diced, I decided to go head-first by myself, all alone.

The Solution(-ish)

Suffice to say - once you know the problem, you're half way to find the solution. To my disappointment, I found that the only real way to fix this problem was to replace the AMD chip alone. Not the logic board. Not "re-balling", not "reflowing". Apple replaced a failed chip with a failing chip. Time and time again. Only replacing the graphics chip is stilll a costly hardware procedure for such a vintage laptop. I am talking in the range of EUR500. FFS, with that amount of money, I would buy an entry level GPU to mine bitcoins!

So I decided to vest off from my electrical engineering mentality and start thinking from a software point of view. Can I fool BSD to ignore the graphic card? I know it can be done, back in my Linux hardcore days when I used to build my own custom kernel, I used to strip the kernel from all the bells and whistles that my hardware didn't need. So this was the approach I was determined to take.

Now let me make it clear - this blog / guide, assumes you are comfortable hacking the firmware and executing basic Linux commands. I will also assume that you kernel modules (kexts) are all in their default location (/System/Library/Extensions).

To get some display acceleration back it will be necessary to force the machine to not boot in discrete graphics (dGPU) but directly into integrated graphics (iGPU) and stay in this mode.

Booting into dGPU mode is the default on Macs with two switchable graphics cards. The procedure below will set an NVRAM variable that disables the dGPU and forces the system to only use the integrated Intel graphics even when booting.

The NVRAM variable is undocumented but appears to be universally applicable to all Macs with two switchable graphics cards. That means it should work on iMacs and MacBook Pros. Whether they have AMD or NVIDIA chips. The specifics about the drivers that might be necessary to move only cover AMD in this guide. But the NVRAM variable will bypass the discrete graphics chip in any case.

This will give you back your machine – but you will lose some features: e.g. the ability to drive an external display from the DisplayPort, a bit of 3D performance. Thunderbolt data connections should work.

In case this guide fails or is not wanted anymore: this procedure is pure software configuration and therefore fully reversible at any time with simple NVRAM reset.

Part 1: Bypassing the (failed) AMD Chip by disabling dGPU and move offending Kernel module

  1. To start from a clean slate: reset SMC and NVRAM: shutdown, unplug everything except power, now hold leftShift+Ctrl+Opt+Power and release all at the same time
  2. Now power on again and hold Cmd+Opt+p+r at the same time until you hear the startup chime two times
  3. Boot into Single User Recovery by holding Cmd+r+s 
  4. Disable SIP: enter: csrutil disable 
  5. Disable dGPU on boot with setting the following variable: nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01 
  6. Enable verbose boot mode: nvram boot-args="-v" 
  7. Reboot into Single User-mode by holding Cmd+s on boot 
  8. Mount root partition writeable /sbin/mount -uw / 
  9. Make a kext-backup directory mkdir -p /System/Library/Extensions-off 
  10. Only move ONE offending kext out of the way: mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/ 
  11. Inform the system to update its kextcache: touch /System/Library/Extensions/ 
  12. Reboot normally
You should now have an iGPU accelerated display, but the system doesn't know how to power-management the failed AMD-chip. (In this state the GPU is always idling with relatively high power, consuming quite a bit of battery when unplugged and leading to GPU temperatures from 60°C upwards [on average 60-85°C], despite not being used for anything by system.)

Part 2: Improve Thermal and Power Management

For improved power management of the disabled GPU you have to either manually load the one crucial kext after boot by:

sudo kextload /System/Library/Extensions-off/AMDRadeonX3000.kext 

If you have a temperature sensor application you might want to have it open before issuing the above command and watch the temps drop…

Automate this with the following LoginHook that will get executed after the next reboot:

sudo mkdir -p /Library/LoginHook 
sudo vim /Library/LoginHook/ 

with the following content:

kextload /System/Library/Extensions-off/AMDRadeonX3000.kext 
pmset -a force gpuswitch 0 # undocumented/experimental 
exit 0

then make it executable and active:

sudo chmod a+x /Library/LoginHook/ 
sudo defaults write LoginHook /Library/LoginHook/

For proper power management the minimal set of loaded kexts are on boot (versions for 10.12.6, check with kextstat | grep AMD): (1.5.1) (1.5.1) (1.5.1) (1.5.1) 

And if the above method of loading succeeded this should appear added to the list: (1.5.1)

Is that all?

If you managed to read this far, holy cow!

I tested this solution by looking at the OSX preferences and making sure that the MacBook was always using the integrated Intel graphics card (and not switching to other the AMD discreet card).

I also made use of a free software called Mac Fans Control. This has given me the ability to measure the temperature of the logic board at various places - each CPU core, the memory slots, and most importantly, the graphic chips.

The temperature was now cooler, dropped by at least 20 degrees!

However, the inevitable happened. The restarts happened again after a few less than an hour. I was pissed off at this stage. Then I remembered about Murphy's Law again - If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. But that doesn't exclude that other things are also going wrong in the background.

So I started looking at Kernel logs, trying to eliminate various variables and postulated that there must be something at the disk level as well which is triggering restarts. Lo and behold, I did a disk check and found out that all these restarts that have been caused by the AMD chipset, have also screwed up my filesystem. Nothing that an fsck -iy didn't fix (make sure you are in single-user mode).

My MacBook hasn't restarted in the last 72 hours, and to be sure, I did all sorts of activities to work out its Intel graphic chip, disk and memory - and making it sweat to the point of no return. I downloaded about 30GB of data, played 3D accelerated games, and abused the disk by bucketing random disk sectors to the null device using dd.

Downloaded and playing Dungeons & Dragons Online

How to get an External display working now?

The million dollar question. Those Apple engineers of course decided to do a direct connection bus from the AMD chip to the external display port, making the latter completely unusable now!

After some research I discovered a nifty USB-to-VGA adapter that works successfully with this range of MacBook that are equipped with only USB 2.0 ports (ergo no USB-C or USB 3.0).  The Diamond Multimedia USB 2.0 to VGA adapter supports high resolutions and have had very good reviews. In fact, I just ordered mine a couple of days ago!

With that said, I hope this guide relieves you from my same ordeal!

Refactor a React action creator using AsyncAwait syntax

As soon as I learned about the AsyncAwait syntax in ES6 and ES7, I soon realized that this is going to be the end of Javascript promises as we know it. There are tons of articles explaining how they work and why they are great.

This little blogpost is solely to demonstrate how I refactored a standard action creator that uses an async call through Axios, using async/await.

This is the vanilla action creator:
... and this is the end result:
... and of course, goes without saying, if I want to further abuse this new syntax I can further compact it as follows!!!
The rules I follow to refactor are as follows:
  1. Refactor the arrow functions and remove any noise. In this case I removed the function keyword, the extra braces and the brackets from the dispatch argument.
  2. Identify the function that contains the async function and prefix it with 'async' keyword. In this case, the async function (axios) is contained in the dispatch arrow function.
  3. Identify the async function and prefix it with 'await' keyword. In this case, it is the axios function.
  4. Store any intermediary responses from promises and such, in a constant, in order to get rid of the 'then' keyword.

Programmatic navigation from action creator using React Router V4

React Router 4 has made tremendous updates not only in terms of features and syntax but also in terms of coding design patterns and philosophies.

I created this post because I know a number of developers who give on React Router v4 when they try to accomplish things, such as programmatic navigation, which seemed much easier in v3. I will not go into the merits of the decisions by the react router core developers, however this post will attempt to explain one of the best ways to achieve programmatic navigation from an action creator.

This use case is quite common, especially in the context of signing in users - typically we want our React app to redirect the users to a protected route once they have successfully logged in. In V3 this was very simple through the use of the BrowserHistory method to push the new route. This is not supported anymore in V4, and developers are encouraged to use the history object inherited (via props) by the Router component.

So the next big question is - "How can I use the history object from inside an action creator?"Let's say we have an action creator that uses an async request to an API server to login the user. This action creator has no access to this history prop (since it is not a Router component).

Therefore, for an action creator to manipulate the navigation, we have to use some callback logic. I know, I know - you're already shivering by just mentioning callback, but trust me it is quite succinct and intuitive.

The idea is to hook the helper function from, say, an html form's submit button (we will call it conveniently handleFormSubmit()) and call the action creator with a callback as a second argument as follows:

This means that once the action is fired and we get a response back from our API server, React will then push the new route (/feature in our case) to the browser. For this to work we must make sure we have two things in place:

  1. The Signin component is being rendered by the Router (otherwise we cannot access the this.props.history), and
  2. The action creator (this.props.signinUser in this case), accepts a callback as a second argument and executes it when the http request is successful.
A typical action creator will look like this:

Connecting Redux states and actions to a React component

Connecting states and actions from a Redux store to a React component is quite straightforward. While many developers use shortcut techniques to do it, I prefer to use the following format:

What this is saying basically is that somewhere we have a component called ProductList, and I would like to expose an action creator, called fetchProducts, and a state (possibly a state altered by this action creator), called products.

Note that I made use of an ES6 technique called object destructuring to shorten state.products into products, as I am only interested in that particular state. This technique is so common in this context that it is perfectly conventional to map states like this.

Installing Python Quantlib 1.9 on Ubuntu 64 bit

I compiled QuantLib for Python using SWIG and packaged it for public consumption. Installation is easy for those who want to get started quickly. Just follow this link.

Python decorators explained in 2 minutes

Python decorators seem to confuse most newbies. But in reality they are just a fancy way of wrapping functions and modifying their behaviour as a consequence. They are functionally similar to Java annotations.

The code below describes a decorator in its simplest form.

It can be rewritten as per below, using the pie syntax:

My philosophy about technology architectures

I get asked this question often: how would I build an effective IT strategy in a way that will deliver both short- and long-term business value? I believe that it always boils down to these three mantras:

A. Learn once, write anywhere
This is rule number one. Very similar to the KISS (Keep It Simple Stupid) mantra. Don't spruce up a high variance tech all over the place to sound hip. Go for technology frameworks that do not need isolated niche skills. Instead go for technologies that talent can be easily transferrable elsewhere.

B. Fast deployment and Immutable Infrastructure

You want to scale up (or down!) quickly and cost-effectively? Then you have to build your stack in a way that is easy to adapt to changes and features while catering for growth. Do not grow vertically. Grow horizontally, ideally using commodity hardware. What am I saying here? Look into DevOps philosophies, continuous integration and deployment pipelines.

C. Loose Coupling Technology (don't put all your eggs in same basket)

This is perhaps one of those concepts that if misunderstood, will pave the way to long-term failure. We have all heard about vendor locking, and you already probably know that this can lead to a growing technical debt in the future. One can also transpose this concept to the choice of technology - whether how host your infrastructure, or which tech to use to power and code your application. Bottomline is to avoid technologies that are tightly coupled with specific systems (example: does your current stack work only on NOSQL systems? Can your application be transferred to the cloud?)

If you are like me, you have probably worked on a multitude of different technology stacks, way before they were called "stacks". From Linux to Windows, from open-source to proprietary systems, from monolith to service oriented architectures, etc. One needs to take into consideration other business processes when starting to think what architecture suits you best - consider HR processes, operation processes, marketing processes, etc.

Remember, there is no such as thing as 'best practice' in the real world, but more of a 'best fit'.

Simple effective way to take Docker backups

The title might seem contradictory for Docker noobs - backup Docker? What the..? While most people use Docker to achieve an immutable infrastructure there are many reasons why you would still need to backup your docker containers.

Let's say you are running MySQL on a docker container for instance. And let's also say that you are running a custom docker image and you are not using any docker repository to store this image. Furthermore, I will presume that your data volume is not ephemeral and you want to back it up as well.

The following code will backup the docker container and save it as an image for later reuse:

If you want to restore this docker image you can follow these steps:

What about data volumes? To list data volume mounts of a running docker container:

This means that /mysql_data inside container is mounted on the host's /var/mysql and we can simply backup this directory from the host.

Best way for effective Postgresql database backups

Unfortunately the Internet is littered with ineffective methods of backing up your precious PostgreSQL database. Most methods use the pg_dumpall technique - this is inherently faulty for mission critical databases as it only creates plain text backups which would limit the restore options.

A better way is to use custom format backups coupled with global data backups (such as user accounts, permissions, etc):

Deploying Apps on Github Pages

While is a great way to simulate web applications while in development, I find it more convenient to eventually deploy the Free Code Camp challenges to Github Pages. Examples of web applications I have deployed so far:
  1. Wikipedia Viewer
  2. JS Calculator
  3. Tic Tac Toe Game
  4. Pomodoro Clock
It’s really simple. Once you create a github pages account and create a new repository, just follow these steps to deploy the app on github pages:

Traverse JSON trees

I believe that knowing how to traverse JSON trees is an important skill to master, particularly when designing applications that consume complex JSON structures through API requests.

When I recently started playing around the epynomous Wikipedia Viewer challenge on Free Code Camp, traversing the wikipedia API tree was an important first step. While there are many techniques, I decided to go for a recursive function approach. Pay attention however as Javascript creates a stack for each recursive call...

The way this works is straightforward:

  1. For each JSON object determine whether it is a defined (bang bang!!) object.
  2. If it is an object, recursively call the function to traverse it.
  3. If it is not an object (example: array, string, value), then it must be a leaf node!

Take the Wikipedia API JSON tree as an example which looks like this:

The traverse function will iterate through each object, but for the sake of this example, scanning through the first object of the Pages object will look like this:

How I fixed the OSX Sierra battery drain issue

tl;dr Boot to safe mode, restart after some minutes and you should be back to normal!

So a couple of days ago I decided to upgrade my flawless El Capital setup to Sierra OSX 10.12.3. You may say "Aren't you too late for the party?" and that is normally true if it were for other tech upgrades. However since I run on an old hardware (on a MBP 2010 with SSD drives and 4GB RAM) you would definitely emphatise with my conservative approach.

Direct upgrade was plain sailing and to be honest I thought Wow! I should have not been afraid of doing it earlier. But I soon realised that my battery was draining fast. Really fast. Usually I can squeeze between 2 - 3 hours on WiFi and document editing and browsing Safari, and perhaps a couple of days if on sleep mode. Now, after upgrading to Sierra, I was barely getting 45 minutes, and it was not sleeping well.

I tried the usual suspects, namely a PRAM and SMC restart to no avail. After hours of scouring all forums possible, I realised that I was not alone with this issue. Some suggested to go back to El Capitan while others even suggested to take a look at the Activity Monitor and turn off resource hungry apps. The latter did not make sense at all - I would imagine that native apps would be more optimised on a new OSX installation.

... That was until I came across a very unorthodox suggestion to boot into safe mode, use the system for a couple of minutes and then restart. I have an idea as to why, but it worked. I got my previous battery capacity back. These are some theories that I made that could have explained this resolution:

1. Orphan processes that were draining the battery were removed after booting to safe mode.
2. Orphan legacy drivers that were also draining the battery were either removed or fix following a safe boot.
3.  Pure coincidence and may have been a combination of resetting the PRAM/SMC and turning off transparency and the usual exotic display features.

What do you think?