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.
Development is more than just writing code
Technology is changing so fast that it's becoming hard to keep track of what's new or where it's going. It's typical for a developer to invest a few weeks learning a framework, a productivity tool or a new language, only to be told to her annoyance that there's something better and shinier that has came out just two days ago. Often there's no clear-cut comparison to suggest that one choice of technology stack is better than another. Developer skill-sets, community support, open libraries, documentation, cost, and application requirements are some factors that influence that choice. The problem has become so acute that some developers spend days or even weeks researching and get indecisive. Wouldn't it be nice to have a place that introduces technology to beginners?
When I say "beginner" I don't mean in the sense of someone in college or just starting his career. You could have years of experience in one technology and still be a beginner in Data Science, Big Data, Virtual Reality, IoT or any of dozens of new technologies that are coming up. I've found from personal experience that often initiations are in the form of Getting Started Guides, Setup & Installation Guides or Hello World examples. This fails because it's telling folks how to use something rather than explaining what it is or why it's relevant.
Ever watched the Ted talk by Simon Sinek, How great leaders inspire actions? Not yet? Then I encourage you watch this 20-minute talk. This video covers the most fundamental thing that most companies fail to address: connecting with customers! Often companies focus on their products, going into details about the technical features, price, engineering innovation, etc. However, they fail to address the basic thing that is needed for a successful sale: Why they are offering the product? Answering this question bridges the gap between product and market. Revenue is an outcome, not the sole purpose of a company’s existence.
Let us take an example of a conventional sales pitch for the embedded computing platform: System on Module (SoM).
“We offer SoM that has a SoC, memory, power circuitry, Operating System, and BSPs, all integrated on a small form-factor board that offers you a platform for building your next embedded product”.
Sounds exciting? Well, it depends. However, it does not generate a great interest. Now, how about the following as a sales pitch?
Image source: Kumar, M., 2013, ‘Digital Privacy, Internet Surveillance, and The PRISM – Enemies of the Internet’, The Hacker News; Security in a Serious Way.
The world we have built around us is due to human ingenuity as well as engineering skills. Tools play an important role in this. It's not an exaggeration to say that most engineers think about the tools at their disposal before starting to give form to their ideas. To sculpt something, you need first good chisel and hammer. To build a bridge, you need precision measuring instruments. To dig a tunnel, you need a boring machine. In today's digital economy, you need connected servers, software platforms and algorithms.
Tools improve both efficiency and effectiveness. The problem with the use of tools is the intent. A knife can be used to cut fruit or to kill your neighbour. A cook and an arsonist use fire in very different ways. Now imagine what will happen when a powerful tool is created with bad intent but the public is told that it is for their good. Aadhaar seems to be in this category.
An opinion on the diversity of cloud services
I've just returned from AWS Summit held at Taj Vivanta, Bangalore. It was a busy day of multiple back-to-back sessions interspersed with networking over tea, coffee and lunch. The venue was packed. The sessions were heavy, at least for someone like me who has never used AWS in any big way. I was familiar with some of the terms before coming to this event but I was surprised how much more there is to the AWS platform. They say that as a developer you can focus on developing your application while the cloud takes care of everything else: deployment, configuration, scaling, security, access control, monitoring, etc. While this is certainly true in the long term, as developers we need to put in upfront investment in terms of time and effort to understand the plethora of services that a particular cloud platform provides.
They say there are 90+ services in AWS. It's bad enough that developers need to aware of all these different services at their disposal. It's worse when you consider that making the choice of the right set of services for your application isn't trivial. This is particularly hard for folks used to only on-premise software built in monolithic fashion. We have to be really clear what we mean by the word "monolithic", which is usually not properly explained in such summits.
Payments made easy
It was in December 2016 that the BHIM app was launched by our Prime Minister. BHIM couldn't have asked for better timing. It came at the heels of demonetization when all of India was focusing on cashless payments. Cash was in short supply and alternative means of payments were in demand. About two months later, YourStory carried a story about 27-year old Nikhil Kumar who had apparently built the BHIM app in just three weeks. A few days ago Nikhil Kumar spoke at a small gathering of enthusiasts at Thought Factory, Bangalore. I attended mostly to know about UPI and BHIM but also partly out of curiosity to see the man behind the app.
I am yet to install the BHIM app on my smartphone. While I'm not a Luddite who stands against the advance and adoption of technology, I'm certainly not an early adopter. Since I know the engineering side of things, experience tells me that early releases are prone to contain bugs. Particularly in today's world of MVP releases and lean/agile processes, no one waits for a well-tested product. First releases will certainly contain problems when test-driven methodologies are not followed; or test automation has been sidelined due to more pressing delivery deadlines. So I haven't been using BHIM but I certainly wanted to know what it was.
Takeaways from Intel AI Developer Workshop @ Bangalore
Images in this article are copyright of Intel.
I just returned from a full-day developer workshop organized by Intel. The focus was on Artificial Intelligence (AI) and how Intel is contributing in mankind's best efforts to teach machines to sense, reason and decide. The event was a useful peek into what Intel is bringing to the table in terms of both hardware and software. Beyond that, it was not an event that I would call a developer workshop since there were no hands-on sessions, demos or even tips and tricks that developers can use. The event was structured as a line of talks in order to bring awareness of Intel's involvement in AI and where the market is headed.
AI originated in the 1950s but it was only in the 1980s when Machine Learning (ML) came about that people started to think it might be possible to realize AI. Machines can be trained and then asked to solve problems. Their algorithms could be tweaked as they learn and relearn with more sets of data. Deep Learning (DL) came about as a sub-branch of ML, where neural networks became the basis of learning. DL has brought us closer to the dream of realizing AI but DL alone did not achieve this.
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.