Hello 2018! A couple of weeks back we at LDC Via had our first board meeting of the year, and we’re thinking about what we’re going to do in 2018, what we’re going to concentrate on, and how we’re going to deliver our work.
The platform, together with our consulting base, had a pretty decent year in 2017 and as a result we are due some timely upgrades, both for LDC Via itself, and for the MongoDB layer that underpins it. Busy busy busy!
The consultancy side of our work is growing far more than expected: to the point where we’re having to turn away work, which as any freelancer knows, is anathema. This growth in our consultancy practice has given us a couple of advantages:
- Every migration we run increases our knowledge and gives us new ideas to improve the LDC platform and associated migration utility.
- We get to see all the different stresses and strains that every company out there works with.
You might think that after a few migrations we would have seen them all, but no, every organisation brings its own story (and motivation) to the table. What is more, whilst we have a platform and a migration “story” to sell, a considerable amount of our work is focussed on bringing Domino-based data and knowledge into other platforms entirely: G Suite, Office 365, custom CMS and more… it’s never dull.
All work and no play make for a dull Via. Whilst of course it’s a conference, and it’s “work”, we do love to attend Engage every year. Come May, we shall be there in Rotterdam, as you will have seen from previous posts and tweets, and we look forward to seeing you!
Here we are, almost at the end of another year, crikey. As is pretty much the norm, we’ve all been heads-down working frantically, and thus neglecting this poor blog. What’s new?
Well, we’re finishing up a large project using our platform to deliver a spanking new version of a multi-tenant web application. We’re also working on projects making use of Google apps script, node, Kubernetes, and more, with Domino migration work underway too!
In other news, Engage 2018 is a go for LDC Via: we’ll be in Rotterdam, how about you?
It’s been quiet on this site for a couple of months, and that’s because as usual we’re all heads-down working. So many things to do, so many things. Sometimes however, one has to take a step back and look around, see what’s happening, see what’s around the corner, and see what others are doing.
A few years ago, all of us attended MongoDB “days” in London which were interesting, niche-ish geek-fests. That has really changed now. MongoDB is over a decade old, and at the MongoDB Europe conference today, they officially announced version 3.6, and its impressive feature-set.
Our intrepid loon Ben attended said conference which was well-organised, well-attended, and pretty well-populated with useful content. Particular sessions of note included those on the forthcoming developer-focused product MongoDB Stitch, along with MongoDB Atlas which has been in beta for some time. These satellite offerings look great (oh my: query-able back-ups in Atlas!), but what of the core product?
Well, version 3.6 of MongoDB offers a number of intriguing features, which can be summarised as follows:
- Change streams: invoked with a simple
coll.watch() these are Observers for MongoDB. Fab!
- “Retryable” writes in the event of failures.
- Oodles of document updates including hugely increased “expressibility” in queries, aggregations, pipelining, array processing and updating. These look to be very powerful, and I think Matt will be cock-a-hoop with them.
- R driver to support advanced analytics and business intelligence.
- Support for JSON schema.
- Tunable consistency: customise your app’s balance between read-write consistency needs and overall availability.
You can read more about 3.6 and the future of MongoDB on the official web site.
LDC Via is, in my experience, a unique company: it started out as a group of consultants gathered together to help each other and share skills and experience, and then the Via product grew out of the realisation that so many of the things that we’re asked to deliver did not exist in the market.
That still holds to this day: we don’t have a default answer to every question of “NO” like many fixed products do, but nor do we default to “YES” like the sales teams for every cloud vendor ever (and then bite you later on). What we do is take a platform that we built with care that provides 90% of what we think people will need, and then we mould the rest to match exact requirements. We don’t presume to tell you what you need.
We built LDC Via from various components, not just the current internet darlings and not necessarily the libraries that are most popular and safe at corporations. We built Via with an eye to a solid foundation that will serve both you and us for years to come.
That is what makes the difference: we are all consultants used to dealing with other people’s platforms, and trying to get around the hard “YES” and “NO” of other’s limitations. Now we don’t have to do that; we can change things if it makes sense to do so, and this is a breath of fresh air, something to be proud of as we see the platform grow.
We do not default to “Yes”, we do not default to “No”. Our default is “What do you need?”
But there are strategies, best practices if you will, which can make the transition easier. One I thought worth mentioning is ESLint. This is a process whereby you statically validate your code to make sure it adheres to a set of rules you define. These rules can be as lax or strict as you like, but, applied properly they make your code more supportable, more readable and less error-prone.
So, how to get started I hear you ask? A lot depends on your working environment. If you use a modern editor like VS Code, Atom or Sublime Text then there will be a plugin you can install to help you along. In your project, you add a
.eslintrc file which defines the rules you want to apply and then you look, with horror, at the hundreds of errors that have suddenly appeared in your code.
But fear not, things aren’t as bad as they appear. Your ESLint plugin will probably have a command to automatically fix “easily fixable issues” such as using single quotes rather than double quotes for strings, or indentation of your code. Once these are all addressed you can fix the rest of the issues manually, and relatively quickly.
I’ve recently completed this exercise with a large code base primarily because we want to put some focus on performance: if I have code that is predictably organised, then this makes the process a lot easier.
A great side effect is that the rest of the developers on the team can pick up the code I’ve been butchering and immediately have some familiarity with the style.
The most popular eslint configuration is published by AirBnB as an open source project. It’s a great starting point, but the beauty of these configurations is that if you don’t like a rule then you can simply turn it off. Or, on a case by case basis you can also turn off the rule in your code. As an example, here is the LDC Via
Linting your code is not, in itself going to make it great code, but it will be a big help to you and, at the end of the day you can go home with a slightly smug feeling that you’ve gone that extra step to be a good programmer. And who doesn’t like to feel a bit smug sometimes?