I recently had an interesting problem which served as a great learning experience. It involves hair-pulling levels of frustration, vicious finger-pointing, and an unexpected ending — not a TV Soap opera episode, just a day in the life of a developer.
It all started with a REST API I had built for a customer proof of concept that started refusing requests after an arbitrary period of time. Nothing was unusual in the codebase of the REST API — it was two simple CRUDL endpoints on equally simple objects.
I’d built similar many times before, and probably will many times again – but yet still, this process kept hanging, refusing requests. The time it took to fail was arbitrary — sometimes immediate, sometimes hours, sometimes days.
Eventually, through some SSH foo we discovered that the count of open file descriptors was growing inside the app’s container. I wrote a simple endpoint to query the number of open file descriptors, and it looked like this:
Indeed, after restarting the process, it was clear that the file descriptor count would grow every few minutes, without stopping. An empty Node.js application didn’t exhibit the same problems, only this app.
Continue reading “A Lesson in Debugging: Big Projects Have Critical Bugs Too”
Test-Driven-Development (TDD) is an increasingly popular, and practical, development methodology in today’s software industry, and it is easy to apply in Node.js – as we’ll see in this article. TDD forces much greater code test coverage, and if you aren’t already using it, I’d strongly encourage trying.
The process is: define a test that expects the output we want from our library, API, or whatever it is we’re testing to produce; ensure that the test fails – because we have not yet implemented any functionality; then write the implementation code required to make that test pass.
Continue reading “Test-Driven-Development for building APIs in Node.js and Express”
In part one of this post, we discussed building a hybrid client application which scans a barcode, and sends this code to the server side of our application. Now, we’re going to build the server code to take this barcode number, and look it up on an external service.
The example we’ll see today uses the SOAP protocol, with an interesting twist. We’ll show how easy Node.js & some community plugins make integrating with this SOAP service.
The language of APIs: , SOAP, XML, CSV, JSON?
We’ve mentioned some acronyms already, let’s talk a little bit about what all this means. If these terms are already familiar to you, feel free to skip this section.
Continue reading “Apps 101: An Absolute Beginners Guide to Integrating With a Node.js Backend”
Building applications can be a laborious process. Sourcing work to bespoke app development studios is expensive, and there’s often a large backlog of applications built up within a business needing development. While there’s no magic bullet solution to clearing this backlog, there are tools that can help.
In today’s post, we’re going to look at building a mobile application on the Red Hat Mobile Application Platform as a complete beginner. Since mobile developers are an increasingly rare commodity, this post serves as an introduction to the concepts developers might need to re-skill as mobile developers. Hopefully, we’ll also de-mystify the process of building a simple app.
Continue reading “Apps 101: An Absolute Beginner’s Guide to building a Mobile App”
A huge problem facing modern enterprises is managing the large software systems and applications they deal with on a daily basis.
Be it the CRM system purchased by a predecessor, a bundled HRM product thrown in to sweeten a deal, or the CMS that marketing could not live without, silos of information exist in the modern enterprise, and it can often be difficult to utilize the data that these systems contain. When an enterprise decides to buy a proprietary system, often little consideration is given to future interoperability of that product. Many of these decisions were made before the mobile era of computing began, and these products share many common characteristics which are ill-suited to the changing face of computing.
Designed for the Desktop Era
These applications are typically delivered through a desktop browser. The limited screen real estate of modern smartphones and tablets makes interacting cumbersome. Mobile experiences are often retro-fitted to these products as an afterthought. Sometimes vendors release a mobile application to the app store, but these can be limited in functionality.