Property-based tests give us more confidence in our code. They’re great at catching edge-cases we may not have thought of otherwise. But this confidence comes at a cost. Property tests take more effort to write. They force you to think hard about what the code is doing, and what its expected behaviour should be. It’s hard work. And on top of that, running 100+ tests, is always going to take longer than running 3-5 example-based tests. This cost is real, and it raises the question: How do we keep ourselves from over-specifying or writing unnecessary tests?
Property-based testing helps us write better tests, with less code, and greater coverage. This leads to more confidence in our code, and fewer bugs in our applications. But, as always, there's a price. Property tests take more effort to write, and they take longer to run. Still, I'm convinced that the trade-off is worth it. In this article, we'll run through an example of how to write property tests using fast-check.
Lots of people treat the ternary operator with suspicion. At first glance, ternaries appear unnecessary. Nothing more than a tool for the overly clever to trim some characters from their code. A favourite hack for coders who don’t care about readability. And sure, it’s all too easy to turn ternaries into an indecipherable mess. But what if we’re missing something? What if there's more to ternaries than meets the eye?
Javascript has its fair share of ‘wat’ moments. Even though most of them have a logical explanation once you dig in, they can still be surprising. But JavaScript doesn’t deserve all the indignant laughter. And now that BigInt is officially part of the TC39 ECMAScript standard, we have options. I'm going to show you how to take advantage of them.
Remote work is a mixed bag. Some aspects are wonderful. The lack of commute and extra flexibility is great. But there are drawbacks. Being remote comes with radical changes to how we communicate. Things that were effortless and unconscious in person become tiresome when we’re remote. And right now, so many of us are trying out this remote experiment together. But as time goes on, maybe the novelty is starting to wear off.
Did you know there’s an algebraic structure for functions? That may not surprise you at all. But it surprised me when I first found out about it. I knew we used functions to build algebraic structures. It never occurred to me that functions themselves might have an algebraic structure. The structure is fascinating, but functions can be rather abstract. So we'll look at some concrete things we can do with React functional components.
Staring at a blank screen can be scary. And writing is hard work. Don’t let anyone tell you different. It takes extended periods of concentration to write anything significant. And that's a rare commodity these days. And even if you manage to beat your attention into submission, the craft of writing is still complex. It can be tough to know where to start. What if my writing turns out to be boring? What if nobody reads it? What if people hate it? Or worse, they start reading and get so bored they quit?
Fantasy land is great. It opens up a whole world of interoperable functions and structures. And the title, though originally a joke, is quite fitting. But Fantasy land isn’t perfect. And it’s not the only way to do algebraic structures in JavaScript.
Algebraic data types and algebraic data structures sound similar. It’s like they ought to be the same thing. But they’re not. They both have ‘algebraic’ in the name, so it’s confusing. I got them mixed up at times. Others have too. But, they’re different concepts. Understanding the difference will help if you’re trying to learn functional programming.
Type classes are not the same thing as algebraic structures. But you'll find many people use the terms interchangably. And that can be confusing. It confused me for a long time. In this article we look at what type classes actually are. And we’ll also look at why programmers from other languages are so enthusiastic about them.
Algebraic Structures are something I wish I’d understood better, sooner. I had a hazy idea of what they were, but didn’t know the correct terminology. That was a massive barrier to finding out more. This article is my attempt to stop that happening to others. We'll look at: What are algebraic structures? How do we use them in JavaScript? Why would we bother? What's the big deal?
It's hard learning functional programming on your own. But it ought not to be. You don't need a PhD to understand functional programming. The concepts are abstract, yes. But that doesn't make them incomprehensible. It shouldn't be this difficult. This is the first in a four-part series on things I wish someone had explained to me about functional programming.
“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.