Cordova is a popular framework for building hybrid mobile applications. This post provides a complete guide on how to install it on a Mac running OS X or macOS, so you can deploy a Cordova-based app to your iOS or Android device.
Since Cordova is the technology that underpins other frameworks such as Ionic, this post also acts as an installation guide for these projects.
Running a node.js app in a low-memory environment requires some additional work to ensure that the v8 garbage collector is aware of the memory ceiling. This post outlines an approach to achieve this.
There are lots of options when it comes to choosing a message queue for your application. The guys at queues.io have a very comprehensive summary of the options.
There are some times, however, where you don’t need something as heavyweight as RabbitMQ or Amazon SQS. A popular alternative is to build a queue using Redis. A simple implementation will use
LPUSH to push messages onto the queue, and
BRPOP pull them off, respectively. Whilst this is useful for a basic FIFO queue, it does not support delayed messages – pushing a message to be pulled from the queue at a later date.
This post explores how a simple message queue can be built to support delayed messages, using Redis.
So, you’ve created a super-awesome npm module, and you want to share it with the world. You’ve seen other modules include handy demo sites, where you can play around with the functionality directly in your browser, before even downloading the module yourself. So, just how do you create a demo page?
In this post, I’ll walk through how to setup an automatic build toolchain to create and publish a static demo page for your super-awesome module.
A common problem for any developer is setting up your development environment for working on multiple projects. By nature, different projects will run different software stacks, and so each piece of the stack needs to be installed and managed. This can get messy when the number of projects increases, and especially when revisiting older projects that were coded against an older version of the stack.
For this reason, it’s a good idea to try and segregate your dev environment for each project. In this post, I’m going to outline how I setup a MEAN development environment using Docker, completely segregated from my host OS.
npm has recently unleashed private modules to world. This allows you to publish a node module to your own private registry, and install it via
npm install as normal. I think this is a good move from npm, and with a price of only $7/user/month, it doesn’t break the bank.
If you are already using GitHub to host your private module’s source code, you might however be wondering whether paying for another service is worth it. In some situations, using a private npm registry is the correct choice, such as if you need strict semver adherence, or need to separate your source code hosting from your production module hosting. In many cases, however, you can get away without using npm for hosting your private modules.
In this article, I’m going to show you how you can replicate npm private hosting using GitHub or Bitbucket, and access these modules from your deployment server and/or Heroku.
You’re working as a full-time employee, slaving away for 40 hours per week. The job is secure, your pay is pretty decent and the work is moderately interesting, but you don’t have much flexibility or freedom. All your friends are freelancers, regaling tales of £400 per day rates with the freedom to work when and where they please. Could you do it too? Could you forsake the good job, good pay and security for a life altogether more risky?
Life as a freelancer can seem very attractive, and in many aspects, it is. You are free to make your own decisions on when, where and who you work for. It’s not all sunshine and rainbows, though – you can fall into the trap of working long hours, and when you don’t find work, you aren’t getting paid – which can be tough.
How can you successfully make the transition from full-time work to full-time freelancing? This was the question I asked myself a year ago. 12 months on, and I’m coping pretty well, and here I’d like to share some of my experiences and advice on how to go about this daunting task.
A ‘short’ or ‘hash’ ID is a seemingly random sets of characters, popularised by services which need unique but readable (and typeable) URLs. For example, YouTube use short IDs for their video URLs:
I found myself needing to generate short IDs for URLs in a recent project. These were the requirements:
- Be short enough to type
- Be easy enough to speak (e.g. over the phone in support situations)
- Be unique (or close to unique as feasible)
- Not contain any rude words
I wasn’t looking at generating millions of IDs per day, all I needed was something simple.
Over the past few days I have had the pleasure of standing up and talking about RESTful APIs.
I followed this up with a similar talk on Monday as part of our latest SWmobile meetup, All About APIs in Bath. This time there was no coding – instead I discussed the design of a RESTful API and gave some examples.
The slides for both talks are available here, and the coding tutorial is available on GitHub. For those that enquired, the coding tutorial is split into git tags. Each tag represents a stage of the tutorial, and tags come in twos: a
fail tag and a
pass tag. The idea is to check out each
fail tag as you go, which will checkout a set of (failing) test specs, which you run with
npm test. Have a go at implementing the API and hence ensuring the specs pass (keep running the test suite with
npm test to check your progress). If you get stuck, checkout the corresponding
pass tag to see the answer.
So, for example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
It was great to open the discussion about API design and chat to others after the talks about their experiences designing and building APIs. It became apparent that more and more people are thinking about APIs – pragmatic RESTful principles will certainly help, so I was glad to share some of my own experiences in this area.
I’m looking forward to speaking again soon!