Posted on

Cleaning up UTF-8 character entities when exporting from WordPress to Jekyll

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

I’ve been experimenting with converting this blog to Jekyll or another static blog generator. I’m sticking with Jekyll at the moment due to its ease of use and its plugin environment. The main idea behind this is to reduce the resource consumption and hopefully also speed up the delivery of the blog. In fact, there is a static version of the blog available right now, even though it’s kinda pre-alpha and not always up to date. The Jekyll version also doesn’t have the comments set up yet nor does it have a theme I like, so it’s still very much work in slow progress.

To export the contents from WordPress to Jekyll I use the surprisingly named WordPress to Jekyll exporter plugin. This plugin dumps the whole WordPress data including pictures into a zip file in a format that is mostly markdown grokked by Jekyll. It doesn’t convert all the links to markdown, so the generated files need some manual cleanup. One problem I keep running into is that the exporter dumps out certain UTF-8 character entities as their numerical code. Unfortunately when processing the data with Jekyll afterwards, those UTF-8 entities get turned into strings that are displayed as is. Please note I’m not complaining about this functionality, I’d rather have this information preserved so I can rework it later on. So I wrote a script to help with this task.

Posted on

How much will my software cost?

Paul Grenyer from Paul Grenyer


The question we get asked the second most when speaking to clients and potential clients is “how much will my bespoke software cost to build?” This is extremely difficult to answer without lots of detail and even then the complexities of software development, the complexity of client requirements and clients changing needs over the course of a project make an accurate estimate challenging.

For this reason, most software development companies shy away from including prices on their website. In fact we checked the websites of a number of our competitors and the closest we found was one who offers a range of fee options from fixed price to a daily rate and a couple who ask for your budget when contacting them for more information. As a client, until you get that first email response, phone call or face-to-face meeting you’re no closer to understanding how much your software will cost. Even then it may be some time before you are any the wiser.

We can’t help you understand how much your project will cost until we speak to you. What we can tell you is how much projects have cost our existing clients. We’ve broken the figures down into the types of services we provide, the minimum project cost, the maximum project cost, the average project costs and where in the range most of the projects sit:

* All values are approximate, exclude VAT and are correct as of August 2017

To start investigating how your business problem could be solved with a bespoke application, please contact us for a chat
Posted on

My Fantasy Gig: Polish Death Metal

Paul Grenyer from Paul Grenyer



It’s no secret that I like death metal. Three of my favorite death metal bands are all from Poland. I’ve been lucky enough to see all of them at least twice individually, but never together. I’ve often wondered why they haven’t all toured together. I’ve never been to Poland either so I’d settle for seeing them all together in their home country.

Decapitated

Opening the show I’d have Decapitated a technical death metal band. Their style, as you would expect, is heavy and progressive. While currently the smaller and less well know of the three bands on this bill, Decapitated are growing in popularity and are poised to step into the shoes of metal titans such as Lamb of God.

After getting into Vader and Behemoth I was really excited to read about another Polish death metal band and I wasn’t disappointed, especially as I also have a soft spot for progressive metal. Often with metal bands who have been around a while, their back catalogue is noisy and unpalatable. Not the case with Decapitated. They’re tight, aggressive and heavy from the first album through to the more recent ones. I’ve seen them play three times now (once even in Norwich) and their live performance demonstrates their skill as musicians.

Behemoth

I’d have Behemoth second on the bill. By far the biggest of the three bands, Behemoth are one of the best metal bands around at the moment. Currently (summer 2017) they are touring the US with Lamb of God and Slayer. I’ve seen them play three times. Once to about 10 people at a club in Bradford and twice to thousands at Bloodstock.

Their singer is often in the press, in Poland and around the world. He famously burned a bible on stage in Poland and was promptly arrested. Later he was diagnosed with and beat cancer.

In the early days Behemoth’s style of ‘blackened death metal’ was heavily influenced by US death metal giants Morbid Angel, but much more palatable. That said they’ve improved on almost every album. Their 2013 album the Satanist is a masterpiece of modern metal. Probably their least heavy album to date, but still crushing.

Vader

Headlining I’d have Vader. I’d describe them as the godfathers of Polish death metal. While not as popular or well selling as Behemoth, they belong at the top. Vader play more traditional death metal, sometimes with trashy tinges. I really struggled to get into their back catalogue. I just wasn’t ready, but every album is superb.

I’ve seen them twice, both times in small clubs. Their sound wasn’t the best, but being a huge fan I put that down to the PA in the clubs. I am sure that atop such a fine bill, they would shine and show what they can really do.

Of course the final encore would comprise of all three bands playing a metal classic together.

Posted on

Share And Share Alike – baron m.

baron m. from thus spake a.k.

Sir R----- my fine fellow! Come join me in quenching this summer eve's thirst with a tankard of cold ale! Might I presume that your thirst for wager is as pressing as that for refreshment?

I am gladdened to hear it Sir! Gladdened to hear it indeed!

This day's sweltering heat has put me in mind of the time that I found myself temporarily misplaced in the great Caloris rainforest on Mercury. I had been escorting the Velikovsky expedition, which had secured the patronage of the Russian Imperial court for its mission to locate the source of the Amazon, and on one particularly close evening our encampment was attacked by a band of Salamanders which, unlike their diminutive Earthly cousins, stood some eight feet tall and wielded vicious looking barbed spears.
Posted on

A Review: Express in Action

Paul Grenyer from Paul Grenyer

Express in Action: Node applications with Express and its companion tools

By Evan Hahn
ISBN: 978-1617292422

This is another excellent JavaScript book from Manning. It contains a great introduction to Express.js and I wish I’d read it sooner as it explains a lot of things about Express.js and how to use it, as well as the tools surrounding it and Node.js, which I had previously worked out for myself. If you’re thinking of writing a web application, especially one in JavaScript, I recommend you read this book first.

The book is far from perfect. It could have been a lot shorter. There is a fair amount of repetition and the chatty style makes it overly verbose and irritating in many places.  The author tries to cover too much and goes beyond Express.js unnecessarily in a few places. However, given that, it’s still not a huge book and quite easy to read.

Posted on

A review: JavaScript the Good Parts

Paul Grenyer from Paul Grenyer

By Douglas Crockford
ISBN: 978-0596517748

Every JavaScript developer with a pre-existing working knowledge of JavaScript should read this book. JavaScript is a powerful and varied language, but it was developed in a hurry and there’s plenty wrong with it. This book outlines the good bits of the language and highlights the bad bits and the bits you should just avoid. There’s also a fair amount about the author’s JSLint project in the appendices.

This book was written in 2008 and probably needs updating. It’s hard going in places and the diagrams did little to nothing to help my understanding. I’ve come away still wondering about new and constructors, but I know I just need to review them again when I need them and it’ll get clearer.  I’m still not sure which function declaration syntax is best, but I’m not sure it matters too much.


Posted on

Getting to the route of the problem

Paul Grenyer from Paul Grenyer

In 2016, Venkat Subramaniam wrote an incredible book called ‘Test-Driving JavaScript Applications’ which, along with JavaScript tools such as Mocha, Istanbul, Prettier and Eslint, have made me fall in love with JavaScript and Node.js (well for UI development anyway). JavaScript isn’t a proper language, right? For a long time I argued not, because the tools weren’t available to develop software with unit tests, static analysis and code coverage. This has changed and now I’m starting to take JavaScript seriously, even beyond jazzing up a web based UI. I’m almost over the lack of static typing.

I’m currently using Express.js, a web framework for Node.js, a lot and Venkat includes a section on testing Express.js routes in his book. They’re a bit like controllers in the Modal View Controllers pattern:

router.get('/', function(req, res, next) {
task.all(function(err, tasks) {
res.send(tasks);
});
});

Venkat’s example test looks like this:

it('should register uri / for get', function(done) {
    // ...        

    var registeredCallback = router.get.firstCall.args[1];
    registeredCallback(req, res);
});

I’ve left out some mocking and other boilerplate for brevity and so that we can concentrate on the one bit I don’t like. Venkat describes the test in full detail in his book.  Take another look at this line:

    var registeredCallback = router.get.firstCall.args[1];

What it does is get the second argument for the first get route declared with the router. That’s what is returned by firstCall, the first declared route. So if there is more than one get route declared with the router and at some point you change the order in which they are declared or you declare another get route in-between, the test will break. It’s brittle.

In fact it’s worse. To get the second get route you’d use secondCall and so on. So although it’s probably a very large number, there are a finite number of get routes you can get from the router with this method. For me this rang alarm bells.
Google suggested this is the way that everyone is doing it. It appears to be the standard practice. It doesn’t sit at all well with me. I’d much rather be able to look up route in the router by its path. After a while printing all sorts of things to the console to find out the data structures, I was able to develop this:

var rh = {
    findGet: function(router, path) {
        for (var i = 0; i < router.get.args.length; i++)
            if (router.get.args[i][0] === path)
                return router.get.args[i];

        return null;
    },

   // ..
};

module.exports = {
    execGet: function(router, path, req, res) {
        var get = rh.findGet(router, path);
        if (get != null) get[1](req, res);
    },

    // ..
};

The findGet function takes a router and the path to test and returns all of the arguments declared for that route or null if it’s not found.  The execGet function uses those arguments to execute the route, meaning that the test now becomes:

it('should register uri / for get', function(done) {
        // ...

        execGet(router, '/', req, res);
    });

Which is not only far more expressive, but less brittle and less code per test. It means that the declaration order of the routes for the router no longer matters. Of course similar functions can be added to facilitate testing post, put and delete.

I wanted to write this up as I couldn’t find any other solution with Google. Hopefully it will encourage developers to write more tests for Express routes as they become easier and less brittle.


Posted on

NorDev: JavaScript Starter Kit – Beginners Full Day Workshop

Rain Crowson from Paul Grenyer


Date: 9:00 am to 4:45 pm, Thursday 5th October 2017

Location: The King’s Centre, King Street, Norwich, NR1 1PH

Price: £50.00 per person

Level: Beginner

Prerequisites: Laptop with wifi, modern browser, text editor

RSVP: https://www.meetup.com/Norfolk-Developers-NorDev/events/242461849/

JavaScript is amazing.

It is a powerful, simple, infuriating, elegant and sometimes irrational programming language which was born in a hurry and can now do almost anything you can imagine. It can make whizzy websites, speak to databases, and draw maps, it can fly drones, make games, and build apps. You can run it on your watch or on your phone, on any web page or on hundreds of virtual servers.

And if you’re reading this you’re probably contemplating learning it.

This day-long workshop aims to cover enough ground to give you a broad base from which to start your quest. We’ll use plenty of practical exercises to explore the language. We’ll cover some of the tricky parts which often mystify people – especially handling asynchronous code, which is one of the language’s great strengths. We’ll spend most of our time in the browser, but we’ll also play around with node.js, JavaScript’s foremost server-side environment. There’ll be time to survey some of the different tools and frameworks which are popular with JavaScripters at the moment. As well as all this we’ll explore JavaScript’s history, its culture and community, and the factors behind its explosive growth. Perhaps most importantly we’ll introduce a set of resources which’ll help you continue your learning independently.

You’ll need to come equipped with a laptop, and you should have a modern browser installed, along with a text editor you’re comfortable using. You don’t need to have a lot of knowledge or experience to join in, though any familiarity with another programming language will help a lot.

There’s a lot to get into one day, so please bring lunch and Neontribe will be buying the first round in the pub straight after the workshop.

Rupert Redington

Rupert ran away from the theatre to become a web developer at the turn of the century. Since then he’s been making mistakes at Neontribe as fast as he can, learning from a reasonable percentage of them. Recently he’s been using Javascript to help teenagers talk to doctors, Americans to buy airline tickets and everybody to find their way to the loo.

“Rupert did a fine job of making this an entertaining subject and his enthusiasm for js was infectious.” – Matthew Shorten

“Thoroughly enjoyed it! Presenter was excellent. Would be interested in any other JS courses that he runs.” -Stephen Pengilley

“I’d certainly sign up for other courses Rupert hosts in a flash. This was an introduction and as such it was perfectly positioned (in my humble…), but if ever there’s an “intermediate” course which goes into more depth with core principles & real-world use of loops, arrays, functions & objects that would be great.” – Steve Harman

Posted on

Writing a Good Tech Cover Letter

Simon Brand from Simon Brand

I review a lot of job applications at Codeplay and most of them make me sad.

For every application I look at, I make a list of plus points and minus points as I read through the candidate’s documents and code. Invariably the first thing I look at is the cover letter, and I would estimate that 90% of them get an instant minus point in my review feedback. As an alternative to ranting about this on the internet, I’ve written some advice on writing a cover letter for a tech job. All advice is from the viewpoint of a small-medium sized tech company and all, well, you know, just like, my opinion, man.

A good job application answers two questions: why the candidate is right for the company and why the company is right for the candidate. The best place to answer these questions is in your cover letter. In fact, with the best cover letters, I even forget to read the CV. If you can’t answer both of these questions on a single side of A4, you probably don’t know the answers.

Step 1 to writing a good cover letter is to actually write a cover letter. If the job advertisement asks for a cover letter, write a cover letter. If it doesn’t ask for a cover letter, write one anyway! Without a concise, targeted description of why you should be considered for a job, your CV needs to work five times as hard for you, as the reviewer needs to try and extract the necessary information from a list of competencies and experience rather than an explicit argument for why the candidate fits the position.

Do not copy-paste a generic cover letter which you send everywhere. Anyone who has reviewed a bunch can spot them instantly, and they make it look like you don’t care about the job enough to actually write something targeted to the company and position.

If the job advert lists criteria for applicants, reference it. Show why you fulfil (or, even better, exceed) the expectations and provide evidence. The best cover letters I’ve seen have gone through all of the required and desired skills and provided short descriptions of experience in the area with links to proof of this experience. And, yes, you can do this on one sheet of paper and still have space for a how-do-you-do.

Don’t spout vague buzzwords. Every time I read about a “team player who is eager to learn” my eyes roll back in my head so hard I lose them. If things like being a team player or eager to learn are in the criteria, fine, but (again) provide evidence.

Let your character and enthusiasm show. These don’t come across in a CV, so show me who you are and why I should want to work with you. Of course, this is much more apparent when it actually comes to interviews, but being enthusiastic about the position and giving some colour to your writing can make the difference between actually getting that interview or not.

If the advert asks for links to your work, provide good ones. Of course, if most of your work is confidential and you don’t work on hobby projects then you may not have any; that’s fine, just justify it. But many applicants link to a Stack Overflow profile with two closed questions on std::vector and send a code sample they wrote ten years ago with using namespace std; in all the headers. Don’t.

Spell-check your letter. English might not be your first language, and whoever is reviewing your application should be sensitive to that, but maeking shoor ur letter doesnt look lyk this can be done by your word processor. This advice should be obvious, but you’d be surprised how many applications I review are riddled with typos. Bad spelling looks lazy. You should put effort into your cover letter, and it should show.

Finally, and most importantly, don’t assume you’re not good enough. An understanding of the gaps in your knowledge, an honest desire to learn the field and evidence that you’re trying goes a really long way.