Achieving Meteor 2-second rebuild time for £830
This was my purely hardware solution to the problem of slow Meteor build times.
When I decided to get into development I was adamant that I wasn’t going to run out and buy the latest and greatest in hardware until I actually knew how to code and knew what my requirements were in the long term.
So I went out and bought a used 15" Acer laptop for £150. It had the following spec:
- Memory: 6GB RAM
- Processor: Intel Pentium CPU 6200 @ 2.13GHz (Dual Core)
- OS: Ubuntu 16.04.1 LTS 32-bit
- Storage: 153.5GB HDD
With this setup, I saw rebuild times of 15-30 seconds (including the browser refresh) of a side project using Meteor 1.4, React and a Mongo-db instance with around 1500 records. I found these times to be excruciatingly slow when it came to making multiple changes to my code and waiting to see the results. You can see the initial version of the project I was working on here.
Analysis of a chat app and resolving the problem
A system in which concurrent events come in can affect behaviour depending on the relative timing of these events. Those working with embedded systems are probably familiar with this problem. Hardware interrupts come in at unpredictable times. One layer sends a message to trigger action from another layer. Data comes in via the wireless interface. A timer expires. How does one reliably handle all these events without taking the system to an unknown state? It would be worse if the system can't recover from such a state.
Real-time operating systems (RTOS) have some things to handle data synchronization, critical sections and race conditions. But can we have such problems in a web app? The answer is yes, as I found out recently when developing a "chat-like" app. The chat window of this app can be updated anytime by multiple users. When user A creates a new chat message, user B can also see it as long as the chat window is open. User B can then reply to user A's message.
Bugs that turned out to be expensive
Some of you may recognize the picture above, of a moth taped to a log book in September 1947. The moth was found in one of the relays of Harvard's Mark II. Although the word "bug" to describe a software fault had been in common use among engineers for some decades, this story is often mistakenly quoted as the origin of the word. If you're an engineer, you will agree that every system has software bugs. It's impossible to design and bring out a perfect software product. Fundamentally, the world itself is imprecise and unpredictable, and all software systems interface to the real world in one way or another. Some of these bugs may lie dormant and never see the light of day. Some others may occasionally arise and disappear without serious consequences. Some others, when they become active, cause catastrophes. It's the last of these that deserves our attention.
An anecdote is in order. India's Income Tax Department has a Excel file where you can enter your income details. The macros in the file will calculate the tax that you have to pay. Some years ago I used this software and submitted my tax returns. Many months later I got a notice to pay pending tax of ₹ 1! Clearly, a rounding-off error somewhere: macros in Excel did not agree with IT Department's enterprise software. Although this bug did not cause any serious damage either to me or to the government's coffers, history gives us far more spectacular failures due to software.
Getting up to speed quickly
Even if you are a narcissist, chances are that you will spend a lot of your time reading other people's code than admiring your own. The primary reason is that we have come to depend a lot on open source software. Technology is progressing so fast and in so many different directions that writing good software is really a collaborative effort. As individuals, we will make the parts that others can use. We will use parts that others have written. Even if we create an application from scratch, it will most likely depend on libraries and interfaces written by others.
A lot of times we may not need to look at other people's code because we will use their work through defined interfaces and APIs. But what happens if we wish to improve that code? What if we discover a bug and wish to fix it? What if the APIs are not adequately documented? There's also the case of mergers and acquisitions. It often happens these days that you're suddenly staring at code your employer has just acquired from another company. The original team may be unreachable or busy with higher priorities than help you out. Then there's the case of outsourcing work. If your team has just accepted a project to maintain legacy code, you have no choice but to understand it at source code level. So how does one go about deciphering code others have written?
Authors: Jack Ganssle
Publisher: Newnes, 2008 (Second Edition)
When I picked up this book, I half expected to read about a serious subject written in a serious textbook style. Within the first few paragraphs it was clear that this book surprises and interests, not least by its almost chatty informal style. It's a book written by an engineer for engineers. It's a book written by a practitioner with many years of solid experience. The author is not presenting here a theoretical framework or a wish list. He is rather condensing many years of experience from which readers can directly benefit. He gives loads of tips and tricks that engineers can start applying in their daily work.
The relevance of this book is of course obvious. Embedded systems are everywhere: in home electronics, in personal devices, in industrial automation and increasingly in tiny devices that are going to come in their billions as part of the Internet-of-Things. Now more than ever firmware developers need to learn from the experiences of others and adopt best practices. To learn from self-experience through mistakes and mishaps is something neither engineers nor their employers can afford.
Authors: Cole Nussbaumer Knaflic
Publisher: Wiley, 2015
I've been doing a little bit of data visualization for the last couple of months. The intent has been to get insights that could trigger decisions to add business value. While I've produced dozens of charts in the process, I've at times wondered if there's a better way. That's when I picked up this book written by an ex-Google employee who employed best practices in visualization to assist the HR department in their recruitment process.
If oil is considered as liquid gold, data is cyber gold. In the Information Age of today, data is perhaps becoming more important than ever before. Yet data remains just a bunch of numbers if we don't see past them to understand causes, patterns, trends, forecasts, dependencies, correlations and contexts. Yes, data can tell a lot about the systems and the world they represent. It's therefore important to analyze data. If data is cyber gold, it's not available in a glittering form. It has to be mined, processed and polished.
When you are your own boss and working from home
If you were to google it, I'm sure you'll get dozens of matches about productivity. In this post, I'm going to share what I've learnt in the last three years of being my own boss and working from home as an independent consultant. In fact, you can think of this as not so much about improving productivity as about preventing your normal productivity from dropping. The latter is really the more common scenario these days since distractions abound, our patience is withering and our capacity to concentrate on a task for decent periods is falling.
Historically, productivity at the workplace started with Adam Smith and his ideas on division of labour. Then in the 1880s, Frederick W. Taylor proposed his principles of scientific management where science and measurements could be used to objectively study processes and perform optimizations. In the early 1910s, Henry Ford introduced the assembly line that could churn out a Model T car in just 93 minutes.
Droids, cloud platforms, APIs and more
On Saturday we had our second edition of IoT Project Day, a quarterly half day session where our members get a chance to give demos on what they have done in the IoT space. Unlike other IoT meetups happening in Bangalore, the focus of this event is as always on the engineering aspects of IoT. In other words, we talk about technologies and tools, tips and tricks, optimization techniques, design and architecture, interfaces, mistakes and what we learnt from such mistakes ...
We had a good turnout of students and working professionals. It was good to see a couple of school students taking interest in electronics and IoT. There were seven demos. This article is a summary of the demos, which will be useful for those who were unable to attend the event. It was also a good networking session for us. I'm sure some of us will collaborate on a couple of projects that can be presented at the next IoT Project Day, which will happen in August. Thanks also to Microsoft for sponsoring the venue.