INDIAN ENGINEERING DESIGN FORUM

Connect. Collaborate. Innovate.

Articles tagged with: Tips and Tricks

6
July
2017

Building My Own Development PC

Achieving Meteor 2-second rebuild time for £830

Building My Own Development PC

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.

27
March
2017

Are There Race Conditions in a Web App?

Analysis of a chat app and resolving the problem

Are There Race Conditions in a Web App?

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.

28
January
2017

Famous Software Failures and Why They Happened

Bugs that turned out to be expensive

Famous Software Failures and Why They Happened

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.

13
October
2016

Essential Techniques for Reading Other Developers' Code

Getting up to speed quickly

Essential Techniques for Reading Other Developers' Code

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?

7
September
2016

The Art of Designing Embedded Systems

Book Review

The Art of Designing Embedded Systems

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.

14
August
2016

Storytelling with Data

Book Review

Storytelling with Data

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.

28
May
2016

How to be Productive at Work

When you are your own boss and working from home

How to be Productive at Work

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.

23
May
2016

IoT Project Day: What We Learnt

Droids, cloud platforms, APIs and more

IoT Project Day: What We Learnt

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.

VIEW MORE