“Higher-order function” is one of those phrases people throw around a lot. But it's rare for anyone to stop to explain what that means. Perhaps you already know what a higher-order function is. But how do we use them in the real world? What are some practical examples of when and how they're useful? Can we use them for manipulating the DOM? Or, are people who use higher-order functions showing off? Are they over-complicating code for no good reason?
Trees come up a lot in web development. As in, more than you would expect. They pop up all over the place. But trees can be tricky. If you're like me, you know that there ought to be a way to process them neatly. You might want to change all the values, or make some calculation on the tree. But the way to do it isn't always obvious. And utility libraries like Ramda or Lodash don't come with tree-traversing functions. So, what do we do?
Transducers are very cool. They give us a lot of power. But they are also a bit abstract. And that makes them hard to explain. But they also embody the dream of functional programming. We write tiny, simple functions. Then we piece them together with flexible tools that work for lots of different data structures. And we end up with powerful, performant programs.
The JavaScript array reduce method seems to give people trouble. Part of the reason is that many tutorials start out using reduce only with numbers. So I wrote a previous article about the many other things you can do with reduce that don’t involve arithmetic. But what if you do need to work with numbers? How do you use reduce for real-world arithmetic problems?
The array reduce method is really powerful. But people often run into trouble as soon as they step beyond the basic examples. Simple things like addition and multiplication are fine. But as soon as you try it with something more complicated, it breaks. Using it with anything other than numbers starts to get really confusing. I think this is because the examples in most tutorials mask some of what's going on. This article looks at some of the more interesting things you can do with .reduce() that better show how it works.
JavaScript gives us a built-in language feature for handling exceptions: try…catch statements. And they're better than littering our code with if-statements. But they can be problematic. And they are not the only way to handle errors. In this article, we’ll take a look at using the ‘Either monad’ as an alternative to try…catch.
The async and await keywords are a great addition to Javascript. They make it easier to read (and write) code that runs asynchronously. But they can still be confusing. Asynchronous programming is hard. Anyone who tells you differently is either lying or selling something. But there are some simple patterns you can learn that will make life easier.
As functional programmers, we like to piece our programs together out of small pieces. Our main tool for this is composition. We take an input, process it through a function, then pass it on to another function. And this all works great so long as all our functions take exactly one argument. Which never happens. So what do we do? In general, we turn to a set of tools called combinators. This article focusses on a particular combinator called lift.
Currying is one of the most formidable weapons in our functional programming arsenal. Combined with composition, it’s extremely powerful. But is currying useful if you’re doing object destructuring with your function parameters?
If you start learning about functional programming, it won't be long before you come across the idea of pure functions. And as you go on, you will discover functional programmers appear to be obsessed with them. “Pure functions let you reason about your code,” they say. “Pure functions are less likely to start a thermonuclear war.” “Pure functions give you referential transparency”. On and on it goes. And they have a point. Pure functions are a good thing. But what do you do with the impure bits of your code?
Getting your JavaScript to run well on a CMS can be difficult at the best of times. But the difficulty grows exponentially when you add something like React and Redux. And this isn't the fault of the CMS. Unfortunately most React tutorials assume you're writing a Single Page web Application (SPA). And that's great if you are actually building an SPA. But what about when you're not? What about those of us who have a CMS imposed on us by our employer? What about those situations where a CMS is the best tool for the job?
What is art for? What is the point of it? It’s not like food, clothing and shelter. We don’t die without art. At least, not straight away. Take away air, or water, or food, and we die. But we seem to be able to last much longer without art. Art doesn’t appear to be essential for life. In fact, it even seems frivolous at times. Its utility is not obvious. Yet, we humans keep making it. And the better our physical needs are met, the more art we seem to make.
Whether you use them or not, React and Redux are important. They have changed the way we think about structuring front-end web applications. They can be very powerful. But they are not magic. JavaScript code does not automatically become better just because it uses React. It is easy to write horrible React code, just like it's easy to write horrible vanilla JavaScript. So, why is React important then? The thing is, understanding how to write React and Redux code is one thing. Understanding why you'd want to use React and Redux is another matter entirely. Once you understand the why of React, then modern JavaScript starts to make more sense. This is true whatever framework you're using. Whether it's React, Vue, Ember, Angular, Web Components, or something else entirely. React and Redux have had a huge impact on how we organise front-end code.
Have you ever visited different types of churches and listened to how they pray? Growing up, I had the privilege of visiting several churches. They were all different. And the people in them prayed with different styles.
Nobody wants to deliver late, over-budget software. I don’t know a single software developer who wakes up in the morning and thinks “I’d like to do a rubbish job today. How can I cost my employer more money?” And yet, so many software projects don’t go well. And with every new project, there seems to be more and more pressure to go faster. So, if we’re in the business of making software, what do we do? How do we go faster without compromising quality?
Have you ever started writing some code that seemed so simple? But then you had to validate the input? And handle an edge case? Oh yeah, and that weird thing the server sometimes does? And somehow this oh-so-simple piece of code turned into a mess? This article looks at how we can reduce the complexity introduced by conditionals.
We've been talking about writing less complex JavaScript. We do this by choosing the right abstraction to solve a problem. But how do you know which abstraction to use? So far, we haven't looked at any concrete examples of how to do this. In this article we look at how to deal with JavaScript arrays, without using any loops. The end result is less complex code.
I’ve been working a lot with a legacy code-base lately. And this one is particularly troublesome. It has all the hallmarks of a rush job. The code is brittle. There are no tests. Things often seem to break at random. And to my embarrassment, I wrote most of it. So, I've been thinking about how I ended up here. How did the code get so intertwined and brittle? And how do I prevent it in future?
Is it OK for a Christian to write fantasy stories? The bible is pretty clear that people should not use magic. Why would it be OK to write about magic? And isn't the whole idea of writing fantasy stories frivolous anyway? Wouldn't our time be better spent serving the poor and telling people about Jesus, or even reading the bible? I would argue that not only is it OK, but if you are a Christian with the inclination to write fantasy stories, it’s helpful if you do.
Monads have a bad reputation in the JavaScript community. Douglas Crockford even said that monads are cursed: Once you reach enlightenment and finally understand monads, you immediately lose the ability to explain them to others. Even amongst experienced functional programmers, monads are treated with respect. But, if you can understand Promises then you can understand monads.
How to you make yourself do things that you don’t feel like doing? When it’s a cold winter morning and you have to get up in the dark to go to work, how do you make yourself leave the warm bed? If you’ve just started a diet, how do you resist the doughnuts your work colleague decided to share? How do you make yourself strap on the running shoes and go jogging? Doing things you don’t feel like doing is hard work---it takes willpower. But where do you get the motivation?
‘One weird trick’ is a cheesy title, I know. Originally I was using it as a draft placeholder title for a joke. But the more I thought about it, the more it seemed appropriate because it's true. Test Driven Development is one weird trick that will change the way you code forever. It will make you a more badass developer.
Sometimes TDD can seem like a drag. Are you writing mocks that are several times more complicated than the code you will test? Does your test suite take minutes (or hours) to run? Does refactoring your code fill you with dread because of all the tests to rewrite? If any of this sounds familiar then it may be time to try a new strategy.
This is part three of a three-part series outlining my personal approach to JavaScript TDD. Testing code that creates HTML and manipulates the DOM can be tricky—especially when testing without a browser. In this article I outline one approach to this, and finish off the sample application we have been building through the series.
Working with JavaScript network calls can be tricky when practicing Test Driven Development. This article gives an example of how to use stubs and Promises to make testing network calls easier. This is part two of a three-part series outlining my personal approach to JavaScript TDD.
Getting started with test driven development (TDD) can be daunting. It sounds tedious, boring and hard. There’s also a confusing array of frameworks and libraries out there. Some work on the server; some work in the browser; some do both... it can be hard to know where to start. This is part one of a three-part series outlining my personal approach to JavaScript TDD.
I really like Star Wars, and I enjoyed The Force Awakens. I think that when you dig below the surface, the ways in which it agrees and disagrees with Christianity are different from what you might expect. In the end, the Star Wars movies are just that: a bunch of movies. But, as I've said before, if we watch in the right way, movies can point us to something deeper and more meaningful—a new and better hope.
In the last article of our four-part introduction to functional programming in JavaScript, we looked at higher-order functions. In this article we discuss how to use these new tools with style.
In the last article, we saw how functional programming can be used with arrays. In this article we examine higher-order functions—functions for making functions.
In the previous article, we saw how functions can be used to make certain code abstractions easier. In this article we apply these techniques to arrays and lists.
What is all the hype about Functional JavaScript? And why is it called functional? It’s not as though anyone sets out to write dysfunctional Javascript. What is it good for? Why would you bother?
Over Easter, our pastor challenged us to live like Jesus is actually risen. Someone I know (quite rightly) asked the question “but what does that look like?” My response is that part of the answer is righteousness, but that might need some explaining.
First of all, I write this to myself as much as anybody. Now, with that said…
I am concerned about how Christianity is perceived by those who don’t call themselves ‘Christian.’ It’s not that Christians are ridiculed in the media (we’ve always been ridiculed), but rather, what people assume I mean when I call myself a Christian is so very different from what I actually mean that I’m almost hesitant to use the word.
For a recent project I needed to process some code in parallel. A colleague pointed me to the pcntl_fork() function, and it turns out it’s not quite as scary and complicated as I thought. So I turned the simple use case into a generic function.
These are some notes to myself on how I would like to approach my work, at least, an ideal for who I would like to be as a Christian web developer. I write this mostly to organise my own thoughts, but I am publishing it just in case there are others who might find it helpful.
You can find a reasonably sensible example of how to perform parallel processing with PHP using the `popen()` function at wellho.net. Sometimes though, the requirement to pass all the parameters to your function via command line arguments can be limiting.
Why would Christians watch movies at all? They are full of violence and bad language and plenty of other things we try to avoid. They are made by people who have completely different world views than our own, and disagree with most of the beliefs we hold most dear. Why would we fill our heads with all this simply for the sake of entertainment?
Sometimes I will talk to somebody, and think that I’m expressing
myself really clearly when I’m not. I seem to make perfect sense. Yet
when I hear what the other person says in response, it is obvious that
they heard something quite different from what I thought I said.