What is the Fediverse?

Defining the Fediverse is, honestly, a little tricky. My understanding is that it is a series of interconnected apps, servers, and websites. There are lots of services for interacting with the Fediverse, including Mastodon, WordPress, Peertube, Pixelfed and even Threads. (This is definitely not an exhaustive list, so if I've left out an important one, let me know.)

When you have an account with one of the services listed above and share some content, other people on any of the other services can potentially see and interact with your posts, photos, etc. I personally mostly use Mastodon. You can check out my profile here.

How does it work?

The Fediverse is powered by an open protocol called ActivityPub. I'll not dig into exactly what that means, but behind the scenes, this is the specification that defines how one server communicates with another. The Fediverse doesn't run on any singular server, it is decentralized. Depending on the service, this means that if you don't like the server that your account is hosted on, you can move.

That might sound complicated, but it is a concept you are probably already familiar with. This is exactly how email works. You might have your email hosted with Gmail, but you can still email people who host their email with Outlook. If you don't like Gmail, you could move somewhere else. The Fediverse works the same way.

Why does it matter?

I think the Fediverse is one of the most important movements on the web in the last 10 or more years. Right now, most social media is a walled garden stuffed full of ads. If you post something on Twitter, your friends on Facebook won't see it. Worse than that, Twitter and Facebook are gathering huge amounts of data about you that they can then sell to advertisers. That might not matter to you, but I'd rather have the apps and services I use operated for my benefit.

As I mentioned, the Fediverse isn't one thing. You can find a service or server that works best for you and that matches your values. Most services are free to use and are operated by volunteers. I make a monthly donation to the server that hosts my account, but you don't need to do that.

On the Fediverse, I am in control of my data. My timeline isn't powered by an algorithm, and I only see content from people I follow. It's honestly kind of boring, which is exactly what I want. I spent 20 minutes or so per day catching up, then I put it down and don't think about it again.

How to get started

There are so many ways to create an account on the Fediverse. It can be a little overwhelming. My recommendation is to head to https://mastodon.social/ and sign up there. Spend a few days (or as long as you want) exploring, and then move to another server if you want.

Also, reach out to me if you want help or have questions. I'm not an expert in this stuff, but it is by far the most pleasant relationship I have ever had with social media, and I'd love to see you all there.

The more ads Google shows you, the more money they make. The longer you spend crawling through results unable to find what you are looking for, the more money they make. The ideal outcome for you and Google are different things. This doesn't even get into the privacy implications (of which there are many).

Kagi Search

For the last year, I have been a paying user of Kagi Search. It is a premium (as in paid-for) search engine that provides all the same functions as Google. You can search for whatever you like, get directions, read restaurant reviews etc.

You might be wondering why I would pay for a search engine if there are a bunch of other free ones. It all comes down to aligned incentives. Kagi makes money by charging end users for access to their service. If they want those users to keep paying for the service, they have to provide the best experience they can.

When I search for something on Kagi I'm not bombarded with ads. It is in Kagi's best interest to get me useful results as quickly as possible and stay out of my way. I don't have to scroll past a bunch of links that someone has paid for me to see. A side effect of this is that Kagi doesn't need to collect a bunch of personal data about me to make sure the ads are targeted.

If you are the kind of person who cares about your privacy and would rather spend your money than your attention, then check out Kagi. If the privacy issues don't bother you then there still might be a case for you to use Kagi.

Personalised Results

One of my favourite features of Kagi is the ability to tailor the kinds of results it shows me. If there is a particular domain that, if relevant, I always want to see in the results, I can pin it. Similarly, I block a domain if I never want to see it. I can also boost, and lower domains based on my preferences. Here is a screenshot of what my settings currently are.

There are a bunch more, but you get the idea.

Lenses

Another cool feature is Lenses. A lens is a filter you can view your search results. There are a bunch built in, like "Small Web" if you only want to see results from non-commercial websites, "Programming" if you only want to see links to official language websites and so on.

You can also create custom lenses. This is done by including and excluding certain keywords, boosting or lowering domains and various other parameters.

There are of course a load more features, but the Kagi website will do a better job of explaining them than I will.

What I don't like

While I love Kagi, it isn't perfect. Firstly, right now it seems to be focused on technical users like developers. This makes a lot of sense for them as tech-savvy folks are more likely to care about online privacy and to seek out an alternative.

Secondly, as Kagi is fairly niche, it is not an option to make it the default search engine in most browsers. This is easily resolved by installing an extension, but that experience on iOS is not great. As a result, your searches get sent to your default search engine before you get redirected to Kagi. I know there is nothing Kagi can do about this, but I wish there was a better way.

Finally, the shopping options on Kagi aren't great. I used to frequently put a product name into Google and see a list of places I could buy it, either online or locally. This isn't great on Kagi honestly. More often than not, I get results for the US Amazon instead of the UK one, and I rarely see any local results.

Conclusion

Paying for something you can get for free is not for everyone, but for me, Kagi is worth it. Search is often my doorway into the wider internet, and I'd far rather that experience was working for me rather than trying to sell my attention to the highest bidder.

Why I've shut it down

There are a number of factors that led to me deciding it was time to call it quits. The main one was that it was no longer as popular or profitable as it once was. It wasn't serving me or the community I built it for. There are a couple of reasons I think this happened.

Firstly, Twitter was purchased my a maniac and for whatever reason, they made API access extremely expensive. As a result, WeCode NI job postings were no longer shared automatically on Twitter.

In addition to Twitter, the other main source of both applicants and employers I had was a Slack channel for NI tech workers. A few years ago, the admins asked me to stop sharing links to new job posts. They did this out of fairness to other job boards, I think, as WeCode NI was technically a private company. I understand the decision, but ultimately it cut down on the number of eyeballs on the site.

Finally, there has been a general down turn in the number of tech jobs in Northern Ireland. I can't say for certain why this is, but I suspect it has to do with Brexit, Covid and the general lack of political stability here.

WeCode NI had been slowly declining for the past few years and I no longer felt comfortable accepting payments for job adverts, so I decided it was time.

Success

It's not all doom and gloom, though. WeCode NI was a success by any measure. In the ~5 years or so that it's been online it has brought in around £15k and the running costs were less than £500. That isn't a huge amount of money for 5 years, but it's not nothing. In that same, time I had a little under 500 jobs posted and dozens of people have reached out to tell me that they found their job on WeCode NI.

Aside from business success, it was also a great platform for me to experiment with and learn new technologies. Over the years, the tools used to build the site changed a few times. The first version was built with a Firebase backend. Eventually I got spooked by Google killing product after product and so moved to a more self-hosted platform and database. In all, I've used three different databases, multiple front end frameworks, and I used TypeScript for the first time on the project. Even if the WeCode NI had made no money, I'd have considered it a success.

What would I have done differently?

There are plenty of things that I did correctly, but if I could start again, I would find a partner to work with. Ideally I'd work with someone with more marketing skills than I have. I never minded reaching out to folks and pitching WeCode NI, but it's not where I'm most useful.

fFrom a tech point of view, the other thing I would focus on more if I got to start over is integrations. For smaller companies this wasn't an issue, but for larger companies, they usually had more than one recruiter and used some form of applicant tracking system. I think if I'd made it easier for larger companies to post to WeCode NI through tools they were already using, I'd have got more of their business.

What's next?

I'm currently in the process of moving the US to spend more time with my wife's family. Over the next few months I'll be using the time and energy I spent on WeCode NI with my family and friends instead. I'm also starting to do more contracting work, which will help ensure I have some income continuity during the move. I have no plans for a new side project just yet.

Conclusion

I worked on WeCode NI in my spare time. After the initial build, I spend less than a few hours each month doing updates and upgrades. I'm really happy with how it all worked out.

I've enjoyed building and sharing WeCode NI with my corner of the internet. Thank you to everyone who posted or applied for a job on the site. I would love to see someone build a successor, either with the code I shared or something completely original.

The code from the original site can be found on GitHub. I also have a full dump of the database available that I could share if anyone has any fun ideas for it. I'll have to scrub the user data first, of course.

When starting a software project I recommend the following approach - Make it work, make it right, then make it fast.

Make it work

The first step in any software project is coming up with a solution to a problem. It doesn't need to be perfect, it just needs to solve the problem. For example, if you have to build an admin panel for a website, don't worry about making sure the solution is pixel-perfect. It doesn't matter if it isn't responsive. It only matters that the end user can achieve what they need to. They'll likely have to jump through some hoops and it might only work under certain conditions, but that is fine.

At this stage, you might want to ship what you have. It depends on the culture of your company and the kind of project you are building. Personally, I tend to air on the side of caution here, but getting some user feedback at this stage can be very useful.

During this first phase, you'll learn more about the problem. You'll figure out what the difficult parts are and what doesn't work. If you have the time, I would actually recommend deleting all of the code you just wrote before moving into the next step, but I'll cover that in another article.

Make it right

You now know the problem can be solved and you even have a basic solution. Now is when we take that solution and make it more robust. Again we'll use the example of an admin dashboard. This is when you go back and make sure what you built actually matches the design, or, chat with the designer and find a better solution now that you know what is possible and what is not.

This is also when you can handle all of the edge cases. You probably didn't test on all of the major browsers. Or it might be relying on data that some old accounts on the system don't have. Fix these issues and sure your tests are as comprehensive as they need to be.

For many software projects, especially in the startup phase, this is where you stop. You have a solution to the problem that works and is robust. There are a million other features in the backlog, so ship it and move on. If however, you are at the stage where you expect this feature to get very heavy usage or you're building an e-commerce platform and every millisecond counts, then it's time to make it fast.

Make it fast

You've solved the problem and everything is working, but time is money. It is time to go the extra mile and optimise what you've built. If you're running your code and any kind of scale, then spending some time making sure you have taken advantage of caching etc can reduce the load on your servers and save you money. Faster e-commerce websites also tend to convert better than a slower equivalent.

A word of warning when it comes to optimisation. We waited until the end to optimise for a reason. Usually, when you spend time optimising some piece of software you make it harder to work with and harder to change. Premature optimisation can still be a problem at this stage. I recommend getting the feature in the hands of users before worrying too much about how fast it is. No one cares how fast your app doesn't do what they want.

Conclusion

Before you spend time and money building the perfect app or feature, build a cheap prototype to make sure it is possible and people actually want it. As developers, we love to come up with clever, optimised solutions. That is great, but do the dumb easy version first.

Heads up, this post is going to focus on how stoicism can make your life better. If that isn't your jam, feel free to check out now.

You might be familiar with the song Life is a Rollercoaster by Irish musician Ronan Keating. It's a banger, filled with terrible advice. In it, he says "Life is a rollercoaster, just gotta ride it." Unless you want to be a passenger in your own life, I suggest you ignore him.

Before we go any further, let's acknowledge a few universal truths. Firstly, life is hard. It's supposed to be that way. We're upright hairless apes, clinging on to a spinning rock that is hurtling through space. That is never going to be easy. Secondly, no matter what, there is going to be some amount of discomfort and pain in life. That goes hand in hand with life being hard.

Now, let's get back to decisions. We know that life is hard and that discomfort and pain are inevitable, so let's use that to our advantage. Most decisions in life have a pretty obvious "right" choice. Should you start going to the gym or should you stay at home and watch Netflix? Should you start that project you have been meaning to do or do you instead put on another Youtube video?

Generally speaking, you know what the "right" decision is. It's going to the gym and starting that project. But if you don't think too hard about it, it is also a difficult choice. Going to the gym will be uncomfortable. Starting the project? Hard work ahead! Yet, if you dig a bit deeper. Not hitting the gym is discomfort too, it just looms later in life. It's that unsettling feeling when you look back and ask yourself if you've truly achieved your aspirations. If pain is inevitable either way, why not opt for the discomfort that has a purpose?

If you take one thing away from this post, let it be this:

Pain and discomfort are part of life. Choose the pain that moves your life in the direction you want, don't trick yourself into accepting the pain of a mediocre life.

This article is heavily inspired by the YouTube video of the same name. I've thought about it regularly since I first watched it and wanted to interpret and share what I learned from it in my own words.

When I write, I challenge my understanding of my ideas. I am forced to distil them into clear sentences rather than loose thoughts and feelings. I can ask questions about my writing and when I don't get answers I instead get topics for further research. With my thoughts on paper (or a screen), I find it much easier to have discussions with myself about those ideas. It feels very similar to the idea of rubber duck debugging.

How I take notes

After reading Building a Second Brain by Tiago Forte I've started to organise my notes by actionability. I use what he calls the PARA method. I'll not be covering what that is in this article, but the most important part is that I have a list of projects/problems that I am actively working on. When I'm consuming content (articles, videos etc) I'm mindful of this list and if the content might be relevant to any of my projects. If it is, I'll make a new note linking to the content and I'll write a few words on my interpretation of it and why it is relevant to my work.

Later, when I'm working on a project, I have a bunch of notes linking to relevant content along with what I was thinking when I first watched/read it. From there I'll refine my notes, add to them, or delete them if I no longer think they are relevant.

I use Obsidian for writing and note-taking, but it doesn't matter what app you use. What matters is getting your ideas out of your head and challenging them. Find out what you're missing or if you have any contradictory thoughts or ideas.

If you'd like to see how effective writing is for leveling up your thinking then try the following:

Using whatever note-taking app you like, create a new note and write down a list of what you believe are your core values. Pick any one of those values and explore it. Write about why you hold that belief and what experiences led you to it. Do you have any other beliefs that are counter to it? When was the last time you modified your behaviour because of that belief and was it worth it? Next, try this again, but instead of writing about it, do it in your head. With the written example I'm certain you'll have gone deeper and have a better understanding of that part of your identity.

Conclusion

Writing is a tool for thinking. It forces you to slow down and make sense of your thoughts. It can be used for introspection and for exploring the world around you. Next time you come across something that piques your curiosity, try writing about it.

In a scenario like this you have a few options, you could dig into the node modules folder, find the (often minified) code and use console.log as you usually would. Or, you could use the built in JavaScript debugger.

Caveat: All of what I'll be talking about in this article is specific to JavaScript and TypeScript that runs in the browser. Backend frameworks almost always support this too but you'll need to look up the docs specific to whatever you are using.

How I usually debug

As mentioned above, until recently, my debugging strategy revolved around console.log. When a bug was reported, I'd figure out how to reproduce it, track down where the bug happens in the code and put console logs everywhere. Usually I'd log a label of some kind, for example the function name I was logging in and a list of any variables that were related to the issue. This is what I call cave man debugging. It is pretty rudimentary, but in my 10 years of working as a developer, it has yet to fail me.

With that said, there is a better approach. One I wish I'd embraced years ago.

What is the debugger?

The debugger is a tool that allows you to pause the executions of your code at runtime and inspect the values of any variables in that scope along with the call stack. It also allows you to step through the code line by line as the program runs and see those variables change over time. You could achieve a lot of this with a bunch of console logs too, but I've fund the debugger to be a lot less hassle.

To get started, fire up which ever project you're working on and head to the browser. In this article I'll be using a Chrome based browser but this'll work in any browser. Next open up your project in your editor and insert the debugger keyword where you want the app to pause for inspection. Remember, this will only work for code running in the browser by default. You'll have a few more steps for server code. Finally, head back to the browser and interact with your app in a way that will get the piece of code with the debugger statement in it to run.

You should see your app paused and the browser dev tools opening in the sources tab. This tab will have a bunch of information about the call stack, the values of relevant variables and controls to resume the execution of your code. You can skip the debugger and you code will carry on or you can step through the execution line by line and in and out of functions.

Conclusion

I'm not going to tell you how to use the debugger. It'll depend on your project and the browser you are using. However, I am going to tell you that you should be using the debugger. It is way easier to use than you might think. It involves no setup for code running in the browser and it'll make you look clever to your colleagues.

I've been using computers almost daily since I was 7 years old. Back then it was for playing games and chatting with my friends. These days it's for work (and still playing games). There is rarely a week goes by where I don't spent at least 40 hours a week in front of a keyboard. With those numbers you'd expect I'd know how to use one properly, but I don't. I've been a four finger typer for the last 20 odd years, but this week that changed.

Why I Learned to Type

There are a couple of reasons why I decided to learn how to type properly. Firstly, with how I make my living, it's border line embarrassing that I can't type properly. I'm a pretty good developer and I've often joked that my ideal editor would be one that I could control with my mind. They don't exist yet, so I'm stuck with a keyboard and while thats the case, I'd rather my fingers were able to keep up with my brain.

Secondly, with how much time I spend at a keyboard, it's only a matter of time before I develop RSI or something similar. I already get mild pain in my wrists after a long day of typing, so I'd rather nip that in the bud before it becomes a real problem.

How I Learned to Type

The first step to getting better at typing is actully learning where all the keys are and what fingers I should be using to press them. I found a great website called keybr that teaches you how to type. It starts off with the home row keys and then slowly introduces more keys as you get better. It shows you a keyboard on the screen so you can see where the key you're looking for is without actually looking down at the keyboard. This was a fairly brutal process. I went from typing at 60 words per minute to 10 words per minute. It was a real struggle to not look down at the keyboard and I found myself getting frustrated at how slow I was typing. This was especially true when working.

After 3 days of spending an hour or more in the evening on keybr, I'd finally "unlocked" all of the keys. I was still only typing around 25 wpm, but it was getting better. Next I moved over to monkeytype. It is a similar website to keybr, but it focuses on whole words rather than groups of letters. It has lots of different modes, from 30 second sprints to modes where you pick the number of words you want to type.

After around a week of working on these sites, I can now type at 50 wpm. This is nearly as fast as I could type before, but now I'm using all 10 fingers. I'm still not as fast as I'd like to be, but I'm making fewer mistakes and I'm still improving.

Whats Next?

I think this process may have opened an expensive can of worms for me. For the last few years I have used a standard Apple keyboard and never really had any issues, but once I started reading about ergo keyboards, I knew I had to have one. I've not made my mind up on what I want yet, but I have an eye on the Moonlander from ZSA. It's a split keyboard with a ton of customisation options.

While I'm mulling over what to buy, I'm experimenting with remapping my current keyboard to make it more comfortable. I use Karabiner Elements for this. I've moved the Caps Lock is now Esc and when I hold down the Space Bar, it acts as Shift. This does mean more dot files to manage/tinker with. I haven't decided if thats a good thing or not yet.

I'm pretty sure over the next few weeks I'll continue to get faster at typing and I'll probably end up buying a new keyboard. I'll be sure to write about it here when I do.

What is a Second Brain?

Simply, a second brain is a place to store and organise your notes. It's place to make your ideas concrete. A place that reveals new associations between your ideas. And a place to incubate your ideas over time to sharpen your unique perspective.

Ideally notes added to your second brain should be useful to your future self. The book explains a method that helps make this a reality.

The CODE Method

Taking notes that remain useful over time isn't simple. It is hard to predict what future you will need. Tiago uses a 4 step method when taking and working with his notes to make them as useful as possible. It's called the CODE method.

Capture

The first step is to capture notes. It doesn't really matter what app you use. Just pick one and stick with it for 6 months before worrying about if it's the perfect one or not. Notes should be taken with a curator mindset. If you capture every interesting thing you see, you may as well capture nothing. Instead take notes about things that resonate with you. Don't think too hard about it. This gets easier with practice.

Tiago recommends having a note inbox where unprocessed notes go. That way you can quickly capture notes when working without having to break your flow to figure out where to put it.

Organise

Step 2 is organising your notes by actionability using the PARA system. Start by creating 4 folders:

• Projects
• Areas
• Resources
• Archive

Projects should contain a folder for each project you are currently working on. A project is defined as some piece of work with an end date. Something that has a stopping point. For example, writing an article, recording a Youtube video or putting a slide deck together.

Areas are for ongoing projects; things that you need to work on or maintain that don't have an end date lined up. Maintaining your home, the relationship with your partner or fitness for example. Create a folder for each area in your life you want to take notes on.

Resources are similar areas, except there is no maintenance involved. This is where you would take notes on things you are interested in. This is where I store notes on reading, philosophy and money etc.

Finally, the archive folder is for what it sounds like. When you finish a project, move it to the archive. If an area is no longer something you are maintaining move to it the archive too. The archive gets these notes and folders out of your way, but the notes will always be there if you need them or if circumstances change.

By storing your notes this way you optimise for action. After all you're probably not taking notes for the sake of it. You do it to get things done. So when you're processing your notes inbox, start by checking your projects folder. If there is a pending project where the note is relevant place it there. If not, check your areas folder. If you haven't got a project or an area that the note would be useful for, put it in a folder in your resources. Don't worry too much about getting this right, search is your friend.

Your notes should now be in the folder where they are most likely to be useful to you when you need them.

Distill

Distilling your notes is the process of making them scannable. You want to have notes that a busy future you will find useful. Tiago uses a process called “Progressive Summarisation”. Your notes should be reasonably concise to begin with. However, you want to make sure that you can get the essence of a note in just a few seconds. Progressive summarisation starts with bolding the most important parts of a note. Then highlight the the most important bolded parts. Finally, for longer notes, you write a short summary.

The time to do this summarisation isn't when you capture or organise the note, but when you next use it in a project or for some other output. At the point you'll be in the best place to know what parts of the note are the most valuable.

Express

We have our notes, they're organised by actionability and it's easy to see what the most valuable part of each note is. It's time to put them to work. Modern work is more hectic and fragmented than ever before, so it's important to find a way to be productive despite this. An effective technique is to work on “Intermediate Packets”. These are small chunks of complete work that can be composed into larger projects. Here are a few examples of what an intermediate packet might be. A summary note combining and refining other notes, an outline of the article you want to write or your initial plan for a remodel you want to do in your kitchen.

An intermediate packet is something you can complete in ~20 mins or so. One of the benefits of working in small complete chunks is that you can share early and often. Feedback is a great way to improve the work we produce.

Creating intermediate packets provides an opportunity to use existing notes. Check the project folder for anything that might be relevant. Take a look in your other folders too and make use of search. If you find relevant notes, move them to the project folder. Use them as your reference material. This is also a good time to progressively summarise the notes you use.

A completed project is now just a case of combining and organising intermediate packets.

The Creative Process

The way we make and create is always changing but the creative process itself is ancient. We gather info, learn new things or look at them from a different perspective, then we combine those things into something new. We strip away the good to surface the great.

This is a process of divergence then convergence. First you explore all options to see what works and what doesn't. Make prototypes, first drafts, outlines etc. Then it's time to refine and focus in on the best parts. The CODE system builds on this process. Capturing and Organising notes is divergence. Distilling and Expressing is Convergence.

Techniques for Getting Work Done

Tiago mentions a few mentions a few techniques he uses when trying to complete a piece of work.

The Archipelago of ideas

When all of your research is complete and it's time to do the work it is useful to gather the most salient ideas into one document. This can include highlights from notes, images or anything else that will help produce the final piece of work. Reorder and add to these highlights until you end up with an outline of the final project. It is a lot easier to get started when you're not starting from a blank page.

Hemingway Bridges

When Ernest Hemingway was writing, he'd never finish a session until he knew what he'd write next. He would take notes about what he had planned and leave them for the next session. When he started his next session he'd know exactly where to begin. This is a great way to use yesterday's momentum today.

Reducing the Scope

This is a common technique in agile software development. You assign a time budget to a task and when the time is up, you ship what you've done. If you're running out of time on a project and there is risk you won't finish, reduce the scope of the project. The parts that don't make the cut can always be added later or be the basis of a new project. It is better to share a smaller completed project with the world than have an incomplete masterpiece that never sees the light of day.

Conclusion

I really enjoyed this book. If you're the kind of person that enjoys productivity systems, you probably will too. If you want to find out more, check out the Building a Second Brain Website I've implemented most of the recommendations this book makes and I'll report back in a few months with how I've faired.

At its core, the internet is a tool for human connection. It is a place where we can share what we have to say with the world. A place where we can connect with others and learn from each other. In a lot of ways though, social media has taken that from us. Social media has turned the web into a machine that generates rage and converts that rage into ad revenue. The web, along with social media is headed towards a place where we are just angry consumers.

This comic from The Oatmeal sums it up pretty well.

A personal website puts you back in control and empowers you to be a creator.

You're in control

One of the first steps to taking control of your online presence is to buy a domain. A domain name is the address of your website. For example, the domain name for this website is paulmcbride.com. You can get one for as little as $10 a year. I recommend Cloudflare for buying domains.

Owning your own domain and posting content there is a better alternative to exclusively using social media for a few key reasons.

First and foremost, owning your own domain and website gives you complete control over your online presence and content. When you post content on your own website, you have the freedom to post whatever you want, whenever you want, without worrying about it being taken down or disappearing. No one can sell your content or data without your permission, and you have the power to shape and control your online identity on your own terms.

On social media platforms, on the other hand, you are at the mercy of the platform's algorithms and policies. Your content can be suppressed or removed, and your online identity is shaped by the platform's curation and advertising policies. Also, social media platforms can change their terms of service or be sold to new owners (I'm looking at you Twitter), leading to potential changes in how your content is used or displayed.

In addition to the security and control that comes with owning your own domain, having your own website allows you to build a more professional and cohesive online presence (If that is what you want to do). You can design and customize your website to align with your personal brand and goals, and present a cohesive image to the world. With social media, you are limited by the platform's design and algorithms, and your content can easily get lost in the noise.

It's fun

In addition to the practical and personal benefits of having your own website, it is also a lot of fun to build and customize one. With a personal website, you have complete control over the design and content, and can build whatever you want. You can let your creativity and personality shine through and create a website that is uniquely yours.

Whether you want to create a polished website to showcase your skills and experience, or a weird and quirky website that reflects your interests and passions, the possibilities are endless. The only thing you're limited by is your own ability and imagination. Building and maintaining a personal website allows you to exercise your creativity and technical skills. It can be a fun and rewarding hobby.

It's a great way to learn

Building a website can be as simple or complicated as you want it to be. If you don't have the technical know how to build a site from scratch, you can start with something like Squarespace or Ghost. These platforms allow you to build a website without having to worry about the technical details. You can focus on the content and design.

If however you want to get your hands dirty and build a site yourself, then you have countless options! I use this website to play with and learn tools I wouldn't get the chance to ordinarily. I've used this website to learn React, Next.js, Tailwind CSS, and TypeScript. I've also used this website to learn about SEO. There are no rules when you build your own website, so you can use whatever your interested in.

Should you stop using social media?

No. Social media can be great for connecting with others and sharing your thoughts and creations. However, if you have something important to say, you should say it on your website first. That content should have a URL that you control. By all means share it on social media too, just make sure your website is the canonical home for your content.

Conclusion

In conclusion, having a personal website is a key tool for taking back control of your online presence and becoming a creator. It allows you to share your ideas, thoughts, and passions with the world on your own terms, and gives you the security and control over your content and data. Building and maintaining a personal website can also be a fun and rewarding hobby, allowing you to exercise your creativity and technical skills. Whether you're a professional looking to promote your career or an individual with something to say, a personal website can be a valuable and fulfilling project.

Hosting

When picking a hosting provider, I have a few requirements. Basically I want it to be affordable and convenient. I do not want to be managing a server or worrying about uptime. For most of the work I do these days, a serverless solution works best.

That's why for hosting, I use Vercel. Vercel is a serverless hosting platform with a generous free tier. I can push my code to Github and a few minutes later, it's live. My pull requests get deployed to staging urls for me to test and I can have multiple environments each with different configurations. The whole platform is backed by a smart CDN which helps static sites perform even better and ensures that my sites are always snappy and reliable.

Framework

When building a job board, server rendered HTML is very important for SEO. It puts you in control of how search engines see your pages.

My framework of choice is Next.js. Next.js is a fullstack JavaScript framework from the same folks that make Vercel. It can be used to build dynamic sites, static sites, APIs and projects that mix them all together.

One of the reasons I use Next.js is for its static regeneration feature. I can create a static page at build time but ensure it is always up-to-date by rebuilding in the background. Next.js makes this really easy to do. Check out the homepage or any job page on weCode Remote or WeCode NI to see it in action.

I use the Next.js API routes to power a GraphQL endpoint. This endpoint is what powers the admin interface and is consumed by all the job pages too.

Data

All data is stored in a MYSQL database running on PlanetScale. I don't need or use their geographic replication feature as the vast majority of users to the site are based in Northern Ireland. I chose PlanetScale because they have a generous free plan and it is serverless. I don't have to worry about scaling or managing a database.

Authentication

When I originally built the site I used Firebase for my backend and Auth. It worked well but there were several drawbacks. Firstly, at the time, the Firebase SDK was huge. Almost half of the JavaScript shipped with each page was just firebase auth code and when you consider most users never need to log in, it was a real waste. Secondly, I've never been a huge fan of Google and their privacy policies. I didn't want to be relying on them for my authentication.

So, when I rebuilt the site I decided to use NextAuth. It's a library that makes it easy to add authentication to your Next.js app. It supports a wide range of providers including email, GitHub, Twitter etc. The data is store in my own database so if I ever want to move away from NextAuth, I can.

Payments

You'll not be surprised to hear that my payments are handled by Stripe. I use Stripe Checkout. This is a prebuilt UI for taking card payments. When a user is ready to pay, I redirect them to a checkout page on Stripe where the transaction is handled. This way, a user never enters payment details on my site. Ensuring a website meets the legal requirements to process payments is hard, so I've left that liability in Stripe's capable hands. When Stripe successfully charges the user, they send me a webhook and the user's draft job goes live.

Content

I use Prismic to manage the content on the site. It's a headless CMS which means I can use it to manage the content on my site without having to build a custom admin interface. If I were to build the site again, I'd probably user Markdown files for the content. It rarely changes and I don't need a full blown CMS for it.

API Layer

I use Apollo Server to power my GraphQL API. This is by far my biggest pain point when working on the site. It's tricky to test, I have to write my types twice (TypeScript and GraphQL) and I have to write a lot of boilerplate code to get it working. I've worked with tRPC recently and I think I'd use that if I were to build the site again.

Email

I use PostMark to send emails. It's a transactional email service which means I can send emails to users when they sign up or login, when they pay and when their job goes live. It's a really simple service to use and it's very affordable. I also like that they are independently owned.

What I'd do differently

While I love all the tools I`ve used for building WeCode NI, there are some things that aren't perfect. As time has gone on I've replaced a lot of the parts I didn't like. I swapped Firebase for NextAuth and I'm planning to move away from Prismic. I'd also like to move away from Apollo Server and use tRPC instead.

That said, the site works and makes me money. As the saying goes "if it ain't broke, don't fix it". I'm happy with the site and I'm not going to spend time on it unless I have to. I'm sure I'll be back to update this article in the future though.

In this article I'll share what I want from life. By sharing these details, I hope I'm more likely to achieve the things I want and that I'm more likely to be held accountable for my goals.

I've spent a lot of time thinking about what makes me happy but I don't think I've ever really been able to put my finger on it. Like most people, the things I want have changed throughout my life. It wasn't until recently I decided that happiness shouldn't be my goal. Happiness comes and goes. That's a normal part of being human. If I set my sights on permanent happiness I'd be setting myself up to fail.

For me, finding purpose is more important.

As Steve Jobs famously said:

If you love what you do, you'll never work a day in your life

Steve was wrong. If you find a job you love, you'll work a hell of a lot, but you'll enjoy it. That's kind of where I'm at right now. I love writing code and more importantly I love solving problems. Before I was getting paid to build things on the web, I was doing it for fun.

I want the freedom to decide what I work on and when I work

Essentially, I want to be able to decide how I spend my time. I want to be able to take downtime when I need it and get stuck into the work I enjoy when I'm feeling motivated. I genuinely love the work I do and I want to make sure it stays that way. My wife Ellie and I are working hard towards this goal. Basically, we need to save a lot of money and we need to build up some level of passive income. That way, a full time job is not a requirement. That's not to say I won't have a full time job when we reach that point, it just means it'll be on my terms.

We still have some way to go before this becomes a reality but we're on track. We're currently saving to move to the US in early 2024 all being well.

The next goal of mine isn't related to money or work.

I want to build a life long habit of daily exercise

This is just as important as financial freedom. What would be the point of having all the money and time in the world if you didn't have the health to enjoy it. Throughout my life I've cycled through phases of training a lot, to months where the only exercise I would do is walking to and from the office. Recently that has been changing though. I've become more consistent by following the “two day rule”. Basically, I plan to work out everyday. I can skip a day whenever I like, but I can never miss two workouts in a row. My current work out plan is 30 mins of kettlebell training, 4 times a week. On days when I'm not doing kettlebells, I'll do a minimum of a 30 min walk.

When you want to make something a core part of your life, you need to do it everyday. At least at the start. When you do something every day, it becomes part of your routine. It's not the exception or something that gets in the way, it's just part of your day, everyday. To make sure I would stick with this plan, I decided on a workout that would take less than 30 minutes and could be done at home. That way I could never make the excuse that the weather was bad or I didn't have time. For me, the workout that fits my life best is kettlebell training.

I want to live in a way that is sustainable and positive for the planet

It is the responsibility of every person alive to leave the planet in a better state than it was when they arrived. I whole heartedly believe this. In practice this means I rarely eat meat at home, I avoid air travel when I can, and vote for political parties that support green initiatives. I also rarely buy new clothes. A lot of my clothes are years old and have been repaired several time. In a few years, when we move to Oregon (where my wife is from), we plan on building or buying a small house and growing as much of our own food as we can.

Some people might look at my lifestyle choices and see them as sacrifices, but I don't think of it like that. I like the slower pace of life that living like this encourages.

I want to do work that matters

This is a tricky one. What is work that matters? I think it is work that has a positive impact on the lives of other people. I'm not pretending I'm going to change the world, I just want to do work that moves the needle in the right direction. What I think this will mean for me is teaching.

I've been able to build a pretty comfortable life for myself through writing code. I want to help other people enjoy the same opportunities that I have. I'm already an egghead instructor so I'm heading in the right direction. That said, it has been a few years since I've published a course. I'm hoping to change that soon.

I want to enjoy the journey

When setting goals around what you want out of life I think it is easy to get tunnel vision. You can get so focused on the end goal that you forget to enjoy the journey. I've been guilty of this in the past. I've been so focused on the end goal that I've missed out on the fun of the journey. I'm trying to be more mindful of this now. I'm trying to enjoy the process of getting to where I want to be. There is more to life than work. Over the past few years I've been learning to fly (I know, that contradicts my previous point about trying to fly less.). I want to spend more of my time doing things like that.

Whats next?

Things are on track for me right now. I need to keep reminding myself to enjoy the journey. I have a bunch of goals I'm working on, but when I get there, I'll probably have new ones. Enjoying the day to day is what makes for a good life.

I know this post isn't at all tech related, but hopefully you found it interesting anyway. What about you? What do you want from life?

Note: My opinion on this as softened substantially since 2019. Mostly because there are now good options to opt out of the global nature of css when it makes sense ie. CSS modules and CSS Cascade Layers.

If you've been on the internet recently, you've probably heard of CSS-in-JS.

The technology has been growing in popularity recently but not everyone is a fan. Today, I'd like to shed some light on what it is and help you decide if it is right for your next project.

CSS-in-JS can mean a few things, but primarily it is used to describe the technique of authoring styling logic in JavaScript. In React this can be done in the form of inline styles attached to a react component or by leveraging a tool like Styled Components. Don't worry if you don't use React though, there are libraries out there for every framework. There are even libraries you can use without a framework.

Now, if you're anything like me, when you first heard the term CSS-in-JS you probably thought:

Oh great... something else I have to learn!

I have good news though! If you already know CSS, you don't have to learn anything new. But wait, if you already know CSS, then why bother writing CSS-in-JS, doesn't that just add complexity?

Why I Write CSS-in-JS 🎨

CSS stands for Cascading Style Sheets. Back when CSS was created, we were building websites which were simple by today's standards. At the time, the cascading part of CSS was super useful. Today, however, I think it ends up being a foot-gun more often that it is helpful. Think about it, can you remember every class name you used on your last project?

Now imagine working on a project with several other people. Writing CSS that conflicts with or overwrites someone else's styles is essentially inevitable. Techniques like BEM and SMCSS can help but you have to rely on all developers following the rules and as a project grows so do the chances that someone will slip up.

For me, CSS-in-JS help save me from myself. I'm protected from my own mistakes by an API instead of by convention. CSS-in-JS allows me to focus on styling my UI without having to be mindful of overwriting CSS somewhere else.

The cascade can still be useful, however. With CSS-in-JS, you can still take advantage of the cascade. The difference is that the scope of the cascade is limited and controlled by you. You can have your cake and eat it.

Performance 🚀

Okay, let's say you never make mistakes. Are there any benefits to CSS-in-JS besides controlling the cascade. As it turns out, there are. CSS-in-JS libraries are responsible for how styles are injected into the DOM. They can track which components are rendered and inline the appropriate styles for best performance.

This means the user ends up making fewer round trip to the server and even downloading fewer bytes of code. That means a quicker time to first paint. Great success.

Maintenance 🔧

Have you ever wanted to remove some CSS from a project but you had no way to be sure it wasn't being used somewhere. With CSS-in-JS, this usually isn't a problem as styles are typically co-located with the component that relies on them. You'll never have to go hunting for the CSS that is affecting the component your working on again.

Dynamic Styles

Another benefit of using CSS-in-JS is that you can take advantage of JavaScript. You can use functions to create mixins and reusable style modules, props can be used to create variations of components and variables can be used for theming.

Most CSS-in-JS tools give you all the benefits of traditional CSS preprocessors too, including nested rules and auto-vendor prefixing.

What are the disadvantages of CSS-in-JS

All tech choices involve compromise and using CSS-in-JS is no different. The primary drawback of using something like Styled Components is the added complexity. First of all, it needs to be installed from npm. Not a big deal, but it is one extra step.

If you are sever rendering your code, you're going to need to install and configure a babel plugin to make sure your styles work on the first load too. (This is how it know which styles in can inline etc.)

The other drawback of CSS-in-JS is that it just might not work for your particular application. If you're not using a front end framework like React or Vue, CSS-in-JS is probably not the right choice.

If you're in a situation where CSS-in-JS isn't a great fit, I highly recommend you check out Tailwind CSS. It is a utility first CSS framework that helps you build UI's rapidly. You don't get any of the benefits of CSS-in-JS but it may help you avoid some of the pitfalls of CSS.

Closing thoughts

As developers, our job is to solve problems using code. CSS-in-JS is a tool that can help us solve problems more efficiently and write code that should be easier to maintain.

If you've tried a CSS-in-JS solution and it didn't work out, that's cool too. Do what works best for you and your team.

Let me know if you have used CSS-in-JS and what problems it solved/caused for you!

After reading his article I took stock of what I know and where my blind spots are and thought I'd put together a list of my own.

For the record, this is a list of the things I know I don't know. There are so many things I don't know I don't know!

So, without further ado, here is my list.

• Typescript - Honestly, I've not even looked at Typescript. The language is taking off right now, but I've just not needed to use it yet.

• Big O Notation - I know it's a thing that can describe how complicated an algorithm is for a computer to process. At least, I'm pretty sure that's what it is. However, I don't know the notation or how to work it out.

• HTTPS - How do you even set up an SSL manually? If it weren't for Cloudflare and Let's Encrypt, I would be in trouble.

• Low-level languages - I've never worked with any low-level languages. Memory allocation and garbage collection sound complicated and I don't need to know it for the work I do right now.

• Java - It seems like most people when they are learning to code, learn Java. I didn't learn to code at university or college so I never learnt Java.

• Kubernetes - I would love to learn how to use Kubernetes, but every time I try, I get overwhelmed and give up.

• Linux - I know basic command line utilities, but setting up a Linux server would be way beyond my skill/comfort level.

• Dev-ops - Running a server scares me a little. There is so much that can go wrong. At my current place of work, I make deployments on a regular basis, but I hate touching the server, if something goes wrong, I wouldn't know where to start.

• Testing - It's a little shameful to admit, but I've barely written automated tests. It's like exercise. I know it's good for me, but I just can't get the motivation to do it.

• SQL - Another slightly embarrassing gap in my knowledge is that my understanding of SQL is very patchy. I work with it regularly, but I never feel like I 100% know what I'm doing. I check the docs a lot!

• SVG - SVGs are amazing! I've seen several of Sarah Drasner's creations and tutorials, but when I sit down and try and do something cool with SVGs it ends poorly.

• Canvas - Nope!

• Angular - I've played around with the first version of Angular, but I've not looked at it since.

• Service Workers - I have an irrational fear that adding a service worker to a website and making a mistake would lead to permanently breaking it.

• Web components - They may be the new standard for building reusable user interface components, but I know very little about how they work.

• AI / Machine Learning - I think machine learning is going to be so important over the coming years and I really need to spend some time learning how to use it.

• Animation - I work a lot on front-end development and I bit embarrassed to admit that animation is something I really suck at. I know when an animation looks good or bad, but I struggle to create them myself.

Knowing where your blind spots are is important. If I have to work on a project that needs these skills, I know I'll either need help or some time to study.

So much of being successful as a developer is knowing enough about a subject to know what to search for on google. I don't know everything and that's okay.

Conclusion

Developers are problem solvers and at the end of the day, that is the skill we get paid for. New tools and languages and be picked up pretty quickly so don't worry too much about what you don't know. Instead, focus on using what you do know to solve problems.

Before we dive too deeply into what’s new in Webpack 4, let’s quickly recap what Webpack actually is. Webpack is a module bundler. It takes care of care of compiling and transpiring code and assets into production-ready bundles. This includes transpiling JavaScript that uses modern ESNext features into a bundle that works in today’s browsers. Webpack can bundle basically anything if you use the correct loader.

What’s new in Webpack 4

So what has actually changed?

Webpack 4 is fast

A lot of work has been done under the hood in Webpack 4 and this has resulted in it being much faster. In some cases, build times have been reduced by up to 98%.

Mode Configuration

In an attempt to simplify Webpack config, a mode option has been introduced. This value can be set to production or development. In development mode Webpack does all the things you would expect; better tooling for debugging, useful error messaging and faster incremental builds. In production mode, the output bundle is minified and optimised for runtime performance. Development-only code is also omitted from the bundle to help reduce the overall size.

CommonsChunkPlugin has been deprecated

The plugin used for splitting the output bundle into multiple smaller bundles has been deprecated. Instead, this functionality is baked in and is configurable using the optimize.splitChunks option.

WebAssembly Support

As long as you have a loader which can handle the language the WebAssembly file is written in, you can now directly import WebAssembly files.

Zero Config Setup

One of the most exciting changes in Webpack 4 is that it can now be used without any setup. This is down to some new sensible defaults.

Getting started

Now that we know what has changed, let’s look at how we could use Webpack in a new project. By default, it will look for ./src/index.js as the entry point. Webpack will then bundle it up and emit it to ./dist/main.js. So, if you have an index.js in your src folder, all you need to do after installing Webpack is run webpack –mode development for development mode or webpack –mode production for production mode.

Simple, right? Obviously, there is a lot more to Webpack. It is super configurable and you can make it do pretty much anything you want. If you want to learn more about how you can configure it, check out the official documentation. https://webpack.js.org/

Conclusion

Webpack 4 has been released and it has a lot of benefits over previous versions. You should upgrade if you can!

You probably already use pure functions all the time and are unaware of what they are or what advantages they bring to your code base. Watch the Youtube below to find out why pure functions are better and much more.

Pure Functions - Functional Programming in JavaScript

Watch: Pure Functions - Functional Programming in JavaScript

Video Transcript

Hello, my name is Paul McBride and you're watching this series on functional programming in JavaScript. This is the fourth episode in this series so if you've not even any the previous ones, you'll be able to find a link to them up here.

In this episode, we're gonna be talking about pure functions what they are and how to use them. So what is a pure function? For a function to be considered pure it has to follow two simple rules.

The first one is that it has to be deterministic. That means that given the same inputs it will always return the same output. Let's take a look at an example of a few deterministic and a few non-deterministic functions.

Okay, so in this example, we have a deterministic function. No matter how many times we call the square function if we pass in the same value we'll get the same result. So if we pass in 3 we will get 9 every single time we call that function. Now let's take a look at a non-deterministic function. This is one I wrote earlier I'm gonna paste it in. This function, similar the last one takes a number is an argument and multiplies it by a random number between 1 and 10.

Now, every time we call this function we have no way to guarantee what the value is going to be. This is a non-deterministic function. This is obviously a very simple example of what one is and there are more complicated more real-life scenarios, for example, a function which connects to an API or speaks to a database is a non-deterministic function because we can't guarantee the results of what they're going to return. The database might fail or the server that you're connecting to might not be online.

The second rule that pure functions must follow is that they can't have side-effects. Now, what this means is that a pure function isn't allowed to alter variables outside of its own scope. If the variable isn't passed in, the function shouldn't know about it and shouldn't operate on it in any way. Let's have a look at an example of what that means.

So here we have an example of an impure function. We have an array of animals here cat, dog and fish. We have a function which pushes a new animal into an array and then on line 8 we're calling that function and we're going to print out the results. We print out the new animals first and then the original animals.

Alright, as I said, this is an impure function. It has a side effect and it's probably not immediately obvious. So let's run the code and see what we get. They're both the same. What!? Essentially what's happening here is that this push function has side effects. It affects the original array. It doesn't create a new one and return a new value.

Let's have a look instead of how we could do this in a way that is pure and doesn't have any side effects. In this example, I've altered the code very slightly on line four. Instead of using array.push to add the horse into the new array, we're using the spread syntax. We create a new array, we add the animal, in this case, a horse to the start of that and then, we use spread to pluck each item out of this animals array and place it into this new array that we're returning.

So if we run this code we should find that the original animals array is no longer changed and the new animals array has horse pushed in. So, let's run that and see what we get. Awesome! So, as we've seen there, original animals remains unchanged.

Now that we know what pure functions are let's discuss a little bit about why we would use them and what kind of benefits they bring to your code base.

The first benefit is that pure functions are incredibly easy to reason about. It's easy to understand what the function does and given a certain set of inputs you'll always get the same result. This means that those functions can be passed around your application, used in different parts for that every whirring that it doesn't have a particular bit of state in your app somewhere that it needs to work properly.

Another advantage of pure functions is that they're really easy to test because pure functions don't rely on external state variables it's easy to mock up every part of what that function does.

Javascript is a multi-paradigm programming language. What this means is that it can be used for different programming approaches including functional programming or object-oriented programming in several other different types. As a result, it's not perfect at any one. When you're writing functional JavaScript there are a few gotchas you have to be aware of such as the push on the array object. There are a lot more. They're pretty easy to find online. So, there are just things you need to be aware of if you're trying to write functional code in JavaScript.

That brings us to the end of this episode of functional programming in JavaScript. Hopefully, you understand a little bit better about what pure functions are and how they fit into functional programming. If you have any questions get in touch with me I'll do my best answer. If you've enjoyed this episode then please feel free to subscribe to my channel or sign up to my email list and I will see you in the next episode.

Bye!

How it's used

An example of how the reduce function can be used to total all values in an array of objects.

const array = [{ value: 1 }, { value: 3 }, { value: 2 }, { value: 1 }];

const total = array.reduce((total, object) => {
  return total + object.value;
}, 0);

console.log(total); // 7

Reduce - Functional Programming in JavaScript

Watch: Reduce - Functional Programming in JavaScript

Video Transcript

Hello and welcome back to this series of functional programming in JavaScript. If you've not seen any of the previous episodes I'll put a link up here and you can check those out. In today's episode, we're gonna have a look at the reduce function.

Before we get started looking at some code, let's talk about what reduce actually does. Now, if you've never used reduce before you're probably gonna have your mind blown. In a lot of ways reduce is just like map or filter. It's part of the array object and it's used for transforming data in an array. There's one key difference though and that is that reduce doesn't have to return an array. It can return any kind of data structure.

One of the other cool things about reduce is that it can actually be used to implement the other functions used on the array. For example, you can use reduce to write a map and we're gonna have a look at that today in this example.

Now let's have a look at some code. In this example we're using exactly the same data we have for the past two. We're going to use reduce to transform this array of users into an object of users where the key for each item in that object is the users ID and the value will be the user. Let's see how we would do that using reduce.

We'll get started by creating a new variable to hold this users object. Now, reduce is a little bit like map and filter in that it takes a callback function as its first argument. That callback function then takes two arguments and this is where it differs a little bit from map and filter.

The first argument is the accumulator so we'll just call it accumulator for now, and the second argument is the actual item that we're iterating over so we'll call that user in this case. Reduce actually takes a second argument which is required and that argument will be what is passed into the accumulator on the first loop over.

So, in this case, we want it to be an empty object literal. Because the data ultimately we're gonna be returning is an object so it makes sense to start there. Now that we've got the boilerplate written let's get started on actually creating this users object.

So, the first thing we're going to do is use this accumulator, which to begin with is an empty object and we're going to create a new value and the key will be the current users ID. The value is going to be an object which contains the user so we'll pass in name, age, which will be user dot age. Now, let's fix our indentation here. Then finally we've got to return the accumulator as well.

The reason we do that is because the accumulator then becomes the first argument on the next iteration of this function. Now what I'm going to do is log out the result of this user object and see what we get. Alright, let's run that through node and see what we get.

That's exactly what we want so here we've got an object with four keys each one of those keys is a user ID and the value of that would then be the user. This can be a really useful exercise in real-life programming because it's far quicker to access data out of an object than it is out of an array. Instead of having to loop over and find them, if you know the ID you can go straight to it.

At the start of this video I mentioned that you can use reduce to write functionality which is very similar to map or filter, so let's look at how we can do that. What we'll do is use reduce to filter the users array and we're going to remove any user if their name doesn't contain the letter e.

Okay, to get started then we're going to create a variable to hold these filtered users in. This will look very similar to the function we have above the one difference being that the second argument to reduce will be an empty array. The reason we do that is because this whole function is going to be working with array data and we want it to return an array.

So next thing we want to do then is check if the user's name contains the letter e. We're going to use the includes function. So if the the users name does include the letter e. What we're going to do is push them into this accumulator array like so. Then we also need to return the accumulator.

Okay, let's log that out and see what happens. Okay, if we run that we should see that Andy has been removed from the array and he has. So as you can see we've used reduce to recreate the functionality of filter. This isn't something you typically do but it gives you an idea of how you could use reduce to create any of that kind of functionality if it doesn't already exist on the array object.

So that wraps up this episode hopefully you've enjoyed what you've seen and you've learned a little bit more about reduce. If you have, please consider subscribing to the channel and you can also check out my website to learn a little bit more, which can be found at paulmcbride.com I'll see you in the next episode!

The filter function is part of the array object. It is used for filtering elements out of an array. Like map, filter is a pure function. Below is an example of how it is used.

How it's used

An example of how filter can be used to remove elements from an array.

const array = [1, 2, 3, 4, 5, 6, 7, 8];

const newArray = array.map((value) => value % 2 == 0); // 2, 4, 6, 8

The Filter function - Functional Programming in JavaScript

Watch: The Filter function - Functional Programming in JavaScript

Video Transcript

Hello and welcome to the second episode in this series of functional programming in JavaScript. Today we're going to take a look at the filter function.

Just like the map function we looked at in the last episode, the filter function is part of the array object and it's used for filtering elements out of an array. Now let's take a look at some code.

In this example, we're going to be using the same data we did in the previous example. We have an array of users I'm going to use filter to remove any user that's under the age of 23. Before we look at filter though let's look at how we can achieve this using a for-loop.

We start by creating an array to hold the older users in. We then use a for-loop to loop over each item in the original users array and if the user's age is greater than 22, we push that user into this new array. There's nothing very exciting here but it gets the job done.

Now let's look at how we could do this using the filter method. Let's start by removing the for-loop. Next, we'll call filter on the original users array. Filter takes a few arguments but the first one and the most important one is a callback function.

The way filter works is that it loops over each item in the array and passes each element in that array to this callback function. So let's do that now. In this case, we'll call it user, and whatever this callback function returns decides whether or not that element is pushed into the new array. If the callback function returns true the element is pushed in. If it doesn't it isn't pushed in. So, in this case, we want to keep every user if the age is greater than 22. So let's do that.

If we run this code, we should see only two elements remain. Perfect! Because functions like filter and map just return another array it allows us to chain these methods together. Let's look at an example of how this works.

Here we're calling filter on the users array but let's take it one step further and we'll call map as well. So here we filter out any user whose age isn't greater than twenty-two and then we're replacing that user object with the strings stating that the user is older than twenty-two. Let's run this code and see what happens. Yep, that's exactly what we expect. Hopefully, this is a good example for you as to how these functional programming methods can help you write really clean succinct code.

So that wraps up this episode of functional programming in JavaScript. Today, we've had a look at the filter method and how we can use it to remove elements from an array. We also had a look at how we can chain these methods along with methods like map to create clean succinct code. In the next episode, we're gonna take a look at the reduce method. Bye-bye!

The map function is part of the array object. It is used for transforming elements in an array. Map is also a pure function meaning that it does not change the original array, instead, it returns a new array.

How it's used

An example of how map might be used is to double every number in an array.

const array = [1, 2, 3];

const newArray = array.map((value) => value * 2); // 2, 4, 6

The Map function - Functional Programming in JavaScript

Watch: The Map function - Functional Programming in JavaScript

Video Transcript

Hello and welcome to my first episode of functional programming in JavaScript. Today we're gonna have a look at the map function, which is a function on the array object.

Okay, let's get started. In this example we're gonna have a look at how the map function can be used to transform this users array into an array that just contains the user's name in a string.

Before we start using the map function we're going to do exactly the same thing except we'll use a "for loop" so that we can compare how they differ.

I've written this for-loop earlier, I'll just paste it and now. This is what it looks like. So first of all, we define a names array. We loop over each of the items in the users array and we push the name into it.

So if we run this code it should do exactly what we want it to. It does. As you can see, it creates a new array with each of the user's names in it.

Now let's have a look at how we can do this with the map function. I'm going to comment this out. We'll create a new variable to hold the names in and we will call in users.

Now, the map function is a function on the on the array object, which means that anything that's an array you can call map on. Map itself, is a higher-order function and what that means is that it expects a function as an argument. So let's do that.

This is an ES6 error function. The way map works is that it will call this secondary function for each item that there is in the array. The secondary function will receive a single argument which is the item in the array that it's currently looking at.

So in this case, we'll call the user because each item in the users array is a user.

Whatever this function returns will be what is placed in the new names variable that we just created. Let's start by returning the user's name.

Now, if I have not made any typos this should work. Let's try that again. Perfect. Okay. So, there's nothing particularly crazy happening here and in fact, we can make it a little bit simpler with ES6 arrow function.

If the body of your function fits on a single line then we can shorten this up a little bit. Let's have a look at how that's done.

Okay, because of the fact that it does fit on one line we can omit the curly braces and the return statement. Whatever's on the right-hand side of this arrow is implicitly returned.

In this case, this does exactly the same thing as it used to. Let's run that just to prove. Cool, okay. If you compare these two functions, you can see that the second function on line 13 using map is a hell of a lot shorter.

This function is actually 89 characters, whereas the same thing using map is 43. So that is half as long as the original function.

Less code means less bugs.

That wraps up this short tutorial on how to use the map function. In the next episode, we're going to take a look at the filter function, which is fairly similar except instead of transforming elements in the array, it allows us to filter them out. I'll see you next time.

This video is also available on YouTube

However, when you look past this you'll find the biggest cloud provider in the world. A cloud provider who has all the tools you could ever need host your application.

Today we are going to look at AWS Lambda.

Cloud Computing

Before we look at AWS Lambda, it's important to understand what AWS is. Amazon Web Services is described as a cloud computing platform which delivers on-demand compute power, database storage and other IT resources.

What does that actually mean though? Amazon owns data centres all over the world. They sell you access to this computing power on a pay as you go basis. On a very basic level, it can be likened to any other web hosting service. The main differences being, it can be scaled globally and has a bunch of extra features.

AWS Lambda, Functions as a Service

Now we're up to speed on what AWS actually is, let's have a look at AWS Lambda. So what is Lambda? According to Amazon, Lambda can be described as follows.

AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you.

In layman's terms, Lamda is a service that will execute a function in response to an event. This can be described as Functions As A Service (FAAS).

The interesting thing about using AWS Lambda is that you don't need to manage the server yourself. AWS handles all the scaling issues. You provide a function, tell it when it should run and you're finished.

Why should you use AWS Lambda?

As we've already discussed, a Lambda function is triggered by an event. These triggers can be pretty much anything from an HTTP request to a new row being added to a database table. It can even watch Amazon S3, their file store service, for an image being uploaded. This could trigger a function which crops and resizes the image as required.

As a lambda can be triggered by an HTTP request, it is possible to run an application using only Lambda functions. This means you never have to worry about managing or scaling servers. This is made even easier by frameworks like Serverless

You don't have to completely rewrite your app to take advantage of the service though. A great way to use AWS Lambda is to offload computationally expensive pieces of code. That way, your server can focus on handling requests and putting pages in front of your users. An example of this would be converting a video from one format to another. The video would be converted by a function running on AWS Lambda, triggered by an HTTP request from your server.

Cost

One of the most compelling reasons to move to AWS Lambda is the cost. Amazon has a very generous free allowance. In fact, if you execute less than 1,000,000 functions per month it could cost your nothing at all.

This free allowance doesn't expire. Beyond the free tier, extra functions and more compute time is inexpensive.

Conclusion

Serverless infrastructure is becoming very popular right now. It's inexpensive, and simple to set up when compared to a VM or similar and it has scalability built in. AWS Lambda is definitely worth checking out and with the free tier, you have no excuses.

1. Performance

React is lightning fast. React works by taking advantage of the Virtual DOM. The Virtual DOM is a lightweight, simplified version of the DOM.

When rendering a component, React does two things. First, it compares the DOM to the Virtual DOM in a process known as "DOM diffing". Then, it only updates the Elements in the DOM that have actually changed.

2. Small API

The React API is small. If you are in any way familiar with JavaScript, learning React won't take long. It is possible to build in React without touching on any advanced techniques.

Knowing React inside out is not necessary when getting started. If you want to be a React master though, it won't take long at all!

3. Documentation

React's documentation make learning it even easier. They are well structured and easy to follow. With the release of React v16, the documentation has been overhauled. Not only is it easy to follow, it's also easy on the eye.

Check the documentation out at reactjs.org.

4. React Native

Once you know how to user React, you also know how to use React Native. This alone should be reason enough to learn React.

React Native allows you to build iOS and Android apps using JavaScript. "Learn Once, Write Anywhere" is how the React team phrase it.

React Native makes it trivial to write native apps. It only requires a single codebase for both iOS and Android!

5. The React Community

Finally, one of the most compelling reasons to learn React is the community. The React community is vibrant and welcoming. The official community page is located at reactjs.org/community/support.html. Here you will find links to discussion forums, tutorials and the GitHub repo etc.

The large React community have already come up against any issue you are likely to run into. As a result, there are tens of thousands of 3rd party components available for use on GitHub.

Conclusion

Facebook built and maintains React. It sees widespread usage on Facebook's own website, so React isn't going away anytime soon. React skills are in demand right now and it's likely to stay that way for the foreseeable future.

Start learning React today and you'll be building scalable front-end apps in no time.

CommonJS

CommonJS is the pattern used in Node.js to share functionality from on file to others. A typical Node module might look something like this.

// maths-helpers.js

exports.add = (x, y) => x + y;

exports.subtract = (x, y) => x - y;

To use the code defined in maths-helpers.js we would use the require keyword.

const helpers = require("./maths-helpers.js");

const total = helpers.add(5, 10);

console.log(total); // 15

Simple enough, right?

Module Caching in Node.js

Let's look at another example which isn't as simple.

// counter.js

let count = 0;

exports.increment = () => {
  count++;
};

exports.total = () => {
  return count;
};

Here we have another simple module that counts the number of times the increment method has been called. Let's use it.

const counter1 = require('./counter.js');
const counter2 = require('./counter.js');

const counter1.imcrement();
const counter1.increment();

console.log(counter1.total()); // 2
console.log(counter2.total()); // 2

Pretty weird right? We create two counters and increment counter1 twice. This gives it a total of 2. When we check the value of counter2 it's also 2! So what's happening here?

In Node.js, the first time you require a module it gets cached. Each subsequent time the module is required you are actually accessing the cached instance.

Exceptions

There are a few exceptions to this caching rule. The first exception is if import path used for each module is different. This may seem obvious, but it can catch you out if you are using a case-insensitive operating system (MacOS or Windows).

The second main exception can only occur when using npm version 2 or below. Let's say your project requires moduleA and moduleB from your node packages. If moduleA and moduleB both require moduleC they will both end up with different instances of moduleC. This is due to the way older versions of npm work. Each module would get its own copy of its dependencies. In more recent versions, dependencies are flattened.

Conclusion

Now you know a little more about how require works in Node.js. There are a few quirks that you need to be aware of but they are simple enough to understand. Module caching can be very useful if used correctly, and now you know more about it, you can use it to your advantage. Go build something cool!

What is the Node.js cluster module?

The cluster module is a Node.js core module that, among other things, allows you to create child processes (workers). These child processes run on separate CPU cores allowing you to distribute the work across available resources.

Let's look at an example of how to use it. In this example, assume that app is an express.js app.

const cluster = require("cluster");
const os = require("os");
const app = require("./app");

const cpuCount = os.cpus().length;

if (cluster.isMaster) {
  for (var i = 0; i < cpuCount; i++) {
    cluster.fork();
  }
}
if (cluster.isWorker) {
  app.listen(8000, () => {
    console.log("Server listening on port 8000");
  });
}

In the above example, when our app is started, we use the os module to determine the number of CPU cores available to us. Next, we check if the current process is the master process. In this case, it is as the first process started is always the master process.

The master process then calls cluster.fork() once for each CPU core. This, in turn, starts several more node processes in "worker mode". This means cluser.isMaster is false and cluster.isWorker is true.

Each worker process then spins up an instance of our app. Requests coming into out app are handled by the master process which immediately hands them off to an available worker process.

Advantages of Using a Clustered App

Running an app like this has several advantages. Let's talk about the main reasons to use clustering.

1. Better use of system resources

With just a few extra lines of code, we can greatly increase the performance of a Node.js application.

2. Fault tolerance

As there are now several instances of the app running, if for whatever reason one of them crashes, the others are still available to handle requests.

3. Zero downtime deployments

One of the cool things about using clustering is that during a deployment, you can upgrade your code without interrupting your service. This is achieved by stopping and upgrading one process at a time.

The example above does not handle this case, but it's not hard to implement.

4. Increased performance

This is obvious. Several instances of your app should be able to handle more requests than a single app. I tested this on an app I was working on recently. I hit my app with 100 requests per second for one minute. Here are the results.

Running on a single CPU:

• 72 req/sec
• 1.12 secs average response time
• 4313 responses handled
• 0.4 MB/sec data throughput

Running on 8 CPU cores

• 261 req/sec
• 0.13 secs average response time
• 15654 responses handled
• 1.5 MB/sec data throughput

As you can see, the results are pretty crazy. With the cluster module, the app was able to handle requests over 8 times faster. Your results will differ depending on what your app does. In this case, it was rendering an HTML template.

Conclusion

The Node.js Cluster module is a simple way to add a massive performance boost to your app. With less than 20 lines of code, you can run your app on multiple CPU cores, reduce the chances of an error bringing your app down and with a little more work, set up zero downtime deployments. Try running your app using the cluster module and let me know what kind of performance gains you achieve.

Let's look at an example of each. We'll make a request to an API and parse the JSON response.

XMLHttpRequest

const myRequest = new XMLHttpRequest();
myRequest.onload = () => {
  const response = JSON.parse(myRequest.response);
  console.log(response);
};
myRequest.onerror = function (err) {
  console.log("Fetch Error:", err);
};
myRequest.open("get", "https://jsonplaceholder.typicode.com/posts/1");
myRequest.send();

As you can see we have to define a callback for both the error and success responses. Let's make the same request with fetch.

Fetch

fetch("https://jsonplaceholder.typicode.com/posts/1")
  .then((res) => {
    if (!res.ok) {
      throw new Error("Whoops!");
    }
    return res;
  })
  .then((res) => res.json())
  .then((res) => console.log(res))
  .catch((e) => console.log("Fetch Error:", err));

Isn't that better? Fetch returns a promise that when resolves containes the response. From here we can access the headers of the response etc.

To get access to the JSON in the body though, we have to call .json on the body. This again returns a promise which will resolve the parsed data.

At the end of the promise chain, we call catch, which will handle any errors.

Response Data

As I mentioned, fetch resolves to a response which contains the response headers. Let's see what other useful information we can get.

fetch("https://jsonplaceholder.typicode.com/posts/1").then((res) => {
  res.ok; // Returns true if response status code is 200 - 299
  res.headers.get("Content-Type"); // Returns the content type header
  res.status; // Response status code
  response.statusText; // Returns the status text - eg. "Not Found"
  response.type; // Response type - eg "cors"
  response.url; // The url the request was made to
});

Request Configuration

The fetch function takes an options second parameter, a configuration object. Let's take a look at how we might use this.

fetch('https://jsonplaceholder.typicode.com/posts/1' {
  method: 'POST',
  headers: {
    'Accept': 'application/json',
  }
})

This is a post request with will be sent with the 'Accept' header. There are a lot more configuration options. You can read about them all on the MDN fetch documents.

Concerns

One of the major drawbacks with the fetch API is that once a request is initiated, it cannot be cancelled. For a lot of people, this is a deal breaker. However, there are discussions happening in the JavaScript community around making this happen.

Another possible issue with the fetch API is that is reasonably new, so although it is supported by all modern browsers, if you have to support older browsers, it won't work without a polyfill.

Conclusion

Fetch is a welcome new API for making requests. It is easier to read and serves the purpose that XMLHttpRequest always tried to. If you are not using it yet, you are missing out on a simple, concise way of making HTTP requests from the browser. If you are interested in learning about how to use the fetch with Async/Await, check out my previous article. - Asycn/Await Javascript Functions.

Let's start by using the Fetch API to make a request to an imaginary end point which returns a response, then we'll then log the response to the console.

const getData = () => {
  fetch("http://example.com/data").then((response) => {
    console.log(response);
  });
};

getData();

That's not so bad. Let's take a look at how we would write the same code using Async/Await.

const getData = async () => {
  console.log(await fetch("http://example.com/data"));
};

getData();

So much better, right? Notice the async keyword in the function declaration and the await keyword used before fetch and response.json()?

When we use the async keyword in a function declaration it gives us access to the await keyword in the function body. Await when used before a promise pauses the code execution until the promise resolves. If await is placed before a value which is not a Promise, it converts the value to a resolved Promise and waits for it.

Okay, so Async/Await allows us to write asynchronous code in a way that looks synchronous, but are there any other benefits? You bet there are.

Why Async/Await functions are better than promises

1. Code is easier to read

With async/await, your asynchronous code reads just like synchronous code. It allows you to avoid nesting callbacks or chaining promises together and this leads to code that is easier to follow and debug.

2. Nested Requests

Imagine a function which makes three network requests, requestA, requestB and requestC. The value returned from requestA is used and requestB and then both return values are used in requestC.

With a promise based approach this would look something like the code below.

const myFunction = async () => {
  return requestA().then((valueA) => {
    return requestB(valueA).then((valueB) => {
      return requestC(valueA, valueB);
    });
  });
};

When we rewrite this using async/await it becomes beautifully simple.

const myFunction = async () => {
  const valueA = await requestA();
  const valueB = await requestB(valueA);
  return requestC(valueA, valueB);
};

3. Error Handling

With async/await functions, we can now use try catch blocks to handle errors. With promises, this is not possible. Error handling is now a little easier and more consistent.

Conclusion

Async/await is a great way to make your JavaScript easier to read and maintain. Support is baked into the latest LTS version of Node and with Babel, async/await can be used in the browser too. If you write asynchronous code in JavaScript, check out Async/Await now.

In today's article, I'm going to talk about some of the tools often used by front-end developers to make life easier.

Code Editor or IDE for Front End Development

The most important tool for writing code is probably your editor. For front-end development, which mostly involves HTML, CSS and JavaScript, there are plenty of options. I'll mention three of the more popular choices.

Sublime Text

Sublime text has been around for nearly 10 years. It is incredibly popular and has a huge ecosystem of plugins and themes etc. Sublime Text requires a licence which costs $70, however, it can be evaluated for free. The free trial has no expiry time.

Atom

Atom is a free and open source editor built by GitHub. It is built using web technologies like Node.js. This means it's easy to hack and customise. As Atom is so easy to customise, it also has a large number of available plugins to extend its functionality.

Check out my article on Atom Plugins.

Visual Studio Code

VS Code is built by Microsoft and is available for free. Again, there are plenty of plugins available. Visual Studio Code is a great choice if you plan on working with Microsoft Technologies such as the .NET framework.

Task Runners

Task runners have been around for ages, but have become more popular with the release of JavaScript task runners. They are used to automate repetitive tasks like compiling Sass to CSS or minifying your JavaScript. They can also be used for much more complicated work.

If you're just getting started learning to code, you probably don't need to worry too much about task runners. Instead, focusing on understanding the languages you use. When you find yourself doing the same thing over and over, think about setting up one of the following...

Grunt

Grunt is the first task runner I ever used. All configuration of you grunt tasks would be done in a Gruntfile.js, usually in the root directory of your project.

Grunt, like the other task runners I'll mention runs on a plugin based setup. Each plugin gives grunt new abilities, such as image compression.

To get started with Grunt, visit gruntjs.com

Gulp

Gulp was released sometime after Grunt with the promise of being code over configuration. The idea was that your gulpfile.js would contain actual JavaScript instead of a harder to read configuration block used by Grunt.

Gulp is almost always faster than Grunt when performing the same task as it is built using Node's streaming API. The drawback of this is that you will need to a little more familiar with JavaScript and Node to get the most out of Gulp.

Check it out at gulpjs.com

Webpack

Webpack is the new kid on the block. It is described as a "module bundler". What this means is that it can take multiple JavaScript files and bundle them together using the CommonJS pattern. Webpack also supports plugins known as loaders.

Webpack is probably the most difficult to learn than the other task runners. In fact, Webpack isn't really a task runner. It's a more specific tool that can be used, with a few plugins, to transpile JavaScript using cutting-edge features into JavaScript that will work in all modern browsers.

Webpack may not be the best task runner for getting started, but if you plan on building modern JavaScript apps, it may be the tool for you.

Learn more at webpack.js.org

Chrome Developer Tools

The chrome developer tools are amazing. If you work as a front-end developer and don't use Google Chrome as your main browser, you might be crazy!

The list of useful features is pretty much endless. To read more about them, visit developer.chrome.com/devtools.

Front end Frameworks

Why write code when you don't have to? It may be worth checking out some of the main front-end frameworks. These frameworks usually come with a CSS framework which can give you a basic layout grid, have default styles for things like buttons and forms and also include responsive styles.

Most of them come with JavaScript helpers too. These can include features like hiding and showing modals etc.

My two favourite frameworks are BootStrap and Foundation

Codepen

Codepen is a great tool for testing out new ideas. It allows you to write code in the browser and see how it updates in real time. Even if you don't plan on using it yourself, you should sign up for their newsletter to see what other amazing things people are building.

Conclusion

There are more tools for front-end developers than you can possibly imagine. These tools can help make your day to day work easier and more efficient. If you use a tool regularly and I've not mentioned it, get in touch with me and I'll update this article.

Let's take a step back for a second. Programming is hard. If you're reading this you know that. You're also human, probably. Humans make mistakes. Writing bugs is just part of being a programmer and when you get stuck on a bug, sometimes all you need is a rubber duck.

Debugging with your duck

So how do we debug code with a duck? Well, it's pretty simple. First, you get yourself a rubber duck. Next, you set your rubber duck next to your computer and finally, you verbally explain to your duck what each line of your code does.

I find this process incredibly helpful. Almost always, when I describe what my code does using plain language, it becomes very clear what is going wrong.

Why it works

It's a well documented fact that explaining a problem or challenge with spoken words forces you to slow down and be more analytical with your description. It might sound crazy, but you don't always know what you're going to say, you might surprise yourself.

This technique can be applied to all kinds of problems but works particularly well when you are explaining code. By talking about each line of code, you challenge your own assumptions of what it does. I'm sure you've heard that the best way to learn something is to teach it to someone else. Well, this is essentially the same thing.

Conclusion

Next time you get stuck on a bug, instead of calling over your colleague, start talking to your rubber duck. Your colleague will be thankful! By using the rubber duck technique, I've learned to take my time when writing code. I've become better at debugging and I've become better and explaining myself and my code.

So what is the spread operator and how is it used? Lets see what the MDN has to say.

Spread syntax allows an iterable such as an array expression to be expanded in places where zero or more arguments (for function calls) or elements (for array literals) are expected, or an object expression to be expanded in places where zero or more key-value pairs (for object literals) are expected.

Let's take a look at an example of how it's used.

const numbers = [1, 2, 3];

const myNewArray = [...numbers]; // [1, 2, 3]

You see those three dots (...)? They have taken a copy of the values in the numbers array and placed them into myNewArray. This is a simple example, but those three dots allow us to do some very powerful things with very little code. Take a look at a few of these real-world use cases.

Concatenating Arrays

const a = [1, 2, 3];
const b = [7, 8, 9];

const c = [...a, 4, 5, 6, ...b];

As you can see, not only can we concatenate arrays, but we also get a really nice way to decide the order of the elements.

Copying Objects and Arrays

This is a very powerful use case for the spread operator. First, we need to understand a little bit more about how JavaScript works. Let's take a look at some code.

let apartmentA = {
  available: true,
  bedrooms: 1,
};

let apartmentB = apartmentA;

apartmentB["bedrooms"] = 3;

console.log(apartmentA["bedrooms"]); // 3

When we create apartmentB and set its value to apartmentA, we aren't really copying its values, we're creating a reference. Any thing we do to apartmentB will also affect apartmentA. This could easily lead to hard to find bugs in your code.

Using the spread operator, we can avoid this problem entirely.

let apartmentA = {
  available: true,
  bedrooms: 1,
};

let apartmentB = { ...apartmentA };

apartmentB["bedrooms"] = 3;

console.log(apartmentA["bedrooms"]); // 1

As you can see, instead of creating a new object reference, we take a full copy of apartmentA and assign it to apartmentB.

Passing arguments to a function

In order to pass an array as arguments to a function, we have to use Function.prototype.apply.

function myAwesomeFunction(a, b, c) {
  // do awesome JavaScript stuff
}

const args = [0, 1, 2];

// Call the function, passing args
myAwesomeFunction.apply(null, args);

With the spread syntax, this can be written as follows...

myAwesomeFunction(...args);

Can I use it in modern browsers yet?

At the time of writing, the spread operator is supported by the newest version of all major browsers with a few caveats. Check current support at https://kangax.github.io/compat-table/es6/

Conclusion

The spread operator is a powerful tool with wide support among browsers. It can help you write better code and less code. Start using it today!

There are some important differences between them and in this article, we'll discuss the differences and when you would use one of the others. First, we'll look at var.

The var keyword

With var the variables you create are globally scoped.

This means that the variable is available inside the function where it is defined, and all functions nested within.

Let's look at an example.

var myVariable = 10;

function mutateVariable() {
  myVariable = 20;
}

mutateVariable();
console.log(myVariable); // 20;

As you can see, myVariable is available inside the mutateVariable function. myVariable can also be mutated/changed because that's how var works.

Globally scoped variables might seem harmless but if you're not careful, they can lead to bugs that are very difficult to track down.

Another interesting quirk that can be quite confusing is hoisting.

Hoisting is hard to explain, so let's look at an example.

console.log(typeof myFunction); // "function"

function myFunction() {
  for (var i = 0; i < 3; i++) {
    var myVariable = 123;
  }
}

This is fairly normal looking code except for one thing. Notice on the first line, the typeof myFunction is actually function before it is ever defined.

This happens due to hoisting. When the JavaScript interpreter parses the above code, it looks more like this...

function myFunction() {
  var i;
  var myFunctionScopedVariable;

  for (i = 0; i < 3; i++) {
    myVariable = 123;
  }
}

console.log(typeof test); // "function"

As you can imagine, this can be pretty unpleasant to debug.

The let keyword

The let keyword works in the say way as the var keyword with a few exceptions.

The main difference between var and let is that let is block scoped. This means a variable created with let is only available inside the block it was created.

That means the madness seen with the var keyword is not longer a problem.

Let's take a look at the another example.

function myFunction() {
  let myVariable = 10;

  myVariable = 20;
}

myFunction();
console.log(myVariable); // undefined;

As you can see, myVariable is only accessible from within myFunction. It is block scoped.

The other major difference is that let acts as though it is not hoisted.

letVariable = "hello"; // Error
varVariable = "world"; // This works

let letVariable;
var varVariable;

The const keyword

The const keyword is almost exactly the same as the let keyword. It is block scoped and acts as though it is not hoisted. The one major difference is that variables defined with const are... you guessed it, constants.

This means that the value has to be assigned when the const is initialized and cannot be changed later.

One thing to be aware of is that objects defined using the const keyword are not immutable. This means you can add, remove or change any of the key value pairs on the object.

For example...

const pet = {
  type: "Dog",
  age: 5,
};

pet.age = 6;
console.log(pet.age); // 6

Conclusion

Now that we have a better understanding of how to define variables it is important to understand when we would use one keyword over the other.

When to use var

Almost never. In fact, if you are writing some code where you have to use var instead of let or const it's a good indicator that you've written some bad code that could be refactored.

When you use let and const

Now that we have access to let and const, we should use them instead of var. If you know the variable isn't going to change, use const, otherwise, use let. This will help keep your code bug free and easy to understand.

What is an arrow function?

Before ES6, when we had a function that required another function passed in as a parameter (a callback), it would look like this.

$(".button").click(function () {
  console.log("Hello World");
});

In this example, the jQuery function click requires one argument, a callback function. This callback function takes no arguments and logs "Hello World" to the console.

With arrow functions that same example would look like this.

$(".button").click(() => console.log("hello"));

That's much nicer, right? The whole expression is on one line and is still easy to read. We've also gotten rid of the function keyword along with a handful for parentheses and curly braces.

So what is so good about arrow functions? Other than slightly shorter functions, what benefits are there to using them?

Advantages of Using Arrow Functions

There are two very good reasons for using arrow functions they as follows:

1. Shorter, more succinct syntax
2. Lexical binding of the this keyword.

First, we'll look at the great new syntax.

JavaScript Arrow Function Syntax

As you saw in the above example, the syntax is a little shorter, but there is more to it than that. Let's look at another example. Here is a simple function declaration using some pre ES6 Javascript.

var sum = function (num1, num2) {
  return num1 + num2;
};

Now let's look at how we'd do this an arrow function.

var sum = (num1, num2) => num1 + num2;

With arrow functions, the return keyword is unnecessary. In a single line arrow function, the return is implicit. It is important to note that the return key word is only implicit when the expression is a single line. It is also not implicit if {} are used to declare the function.

Lexical Binding of this keyword

One of the most confusing parts of JavaScript is the this keyword. Before ES6 and arrow functions, every function defined its own value for this. When using arrow functions, it is greatly simplified. Arrow functions inherit this from their containing context. Let's look at an example using a regular function first.

function Timer() {
  // The Timer() constructor defines `this` as an instance of itself.
  this.seconds = 0;

  setInterval(function tick() {
    // In non-strict mode, the tick() function defines `this`
    // as the global object, which is different from the `this`
    // defined by the Timer() constructor.
    this.seconds++;
  }, 1000);
}

var timer = new Timer();

We could work around this by binding the value this to a variable.

function Timer() {
  var self = this;
  self.seconds = 0;

  setInterval(function tick() {
    // The callback refers to the `that` variable of which
    // the value is the expected object.
    self.seconds++;
  }, 1000);
}

In the above example, when we execute self.seconds++, the tick function will check its parent's scope to find out what self is.

As I mentioned, arrow functions inherit the value of this from their parent/containing scope. Let see how the above Timer would work with arrow functions.

function Timer() {
  this.age = 0;

  setInterval(() => {
    this.age++; // |this| properly refers to the timer object
  }, 1000);
}

var timer = new Timer();

In Conclusion

Arrow functions may appear confusing at first and their syntax may not be very beginner friendly, but once you know how to use them they are very powerful. The succinct syntax coupled with the way the this keyword works means it's hard to find a reason not to start using them right away.

Getting Started

Which programming language you decide to learn first will depend largely on what you want to do. Do you want to build iOS apps? Or maybe you would rather build web applications that run in the browser? You might even decide that you want to write code for the IOT, so you can chat with your fridge over instant messenger.

The other thing to consider when picking a language is what job market is like. You wouldn't want to spend months of your time learning Flash only to realise its in decline and there are next to no jobs available.

With a little bit of research, you can narrow down your options and ensure that you invest your time wisely.

Programming Fundamentals

The internet is filled with detailed overviews of every programming language you can think of - The good things, the bad things, things you don't understand and reasons why you should and should use that particular language. So why is it so difficult to pick your first language?

The truth is that most modern languages are very similar. Yes, they might have different syntax, they might even have different features, but under the surface, they all have similar concepts. They include:

1. Some way of iterating over data (Loops)
2. Grouping chunk of related code (Classes)
3. A method for storing reusable code (Functions)
4. A way to store data (Variables)

Obviously, each language will handle these concepts in different ways, but almost every language has at least one or more of these features.

The first language you learn is going to be the hardest because you are being introduced to so many new things. You have to learn the language itself along with all of its syntax, but arguably, thats the easy part. Learning the fundamentals of programming is the tricky part.

Once you understand how a computer reads and interoperates code and how to solve problems in a programmatic way, learning up another language is trivial.

So what programming language should you learn first?

Now that we've discussed that the language is only a small part of learning to code, we really should pick a language.

A safe bet is to pick a language that has an active community and a large user base. If you stick to one of the well-known languages, its much easer to get help and find user documentation.

Below is a simplified description of each of the main languages as well as what they are most commonly used for.

HTML & CSS

HTML and CSS are used to build web pages. HTML provides the structure and CSS handles the style. While they are not technically programming languages, they are a very popular choice for first-time languages. They are the "Front End" of a website and are a good choice if you want to pursue a career of building web applications websites.

JavaScript

JavaScript is also a popular choice and is often learned in conjunction with HTML & CSS. It is the only programming language that runs in a web browser. JavaScript adds interactivity to a web page. It can be used to hide or show elements on a page. In the past 5 years, with the birth of Node.js, JavaScript has become a popular choice for server-side processing too.

JavaScript has the concept of asynchronous programming which can be quite challenging for beginners.

Ruby

Ruby is a language designed with developer happiness in mind. It has clean succinct syntax and is a lot of fun to use. Ruby is a general purpose language and can be used for anything from building web servers to crunching data.

It would be wrong to mention Ruby without also mentioning Ruby on Rails (or Rails for short). Rails is a framework for Ruby for building web applications.

Python

Python is another general purpose language and is used extensively by YouTube. Python is whitespace dependant, meaning that your code has to follow certain rules on indention etc. Some people like it, other don't. Python is a great language for beginners because of it's easy to understand syntax.

PHP

PHP is a language created for the web. It was created in 1995 and was originally called Personal Home Page. Approximately 70% of the web is powered by PHP. Its an easy language to get up and running and has great documentation.

WordPress, the popular Content Management System is built using PHP. Many programmers start with PHP and move on after a few years.

Swift

Swift if a programming language created by Apple. If you want to build apps that run on Apple devices, Swift is the way to go. It is the successor to Objective C and has great documentation. Apple recently open-sourced the language, meaning anyone can offer improvements and bug fixes.

Java

Java is a language used in a lot of large, enterprise applications. It is also used to build Android applications. Java is a compiled language, meaning it is converted to machine code before being interpreted by the computer. This makes it very fast indeed.

C#

C# is a general-purpose, object-oriented programming language. It was built by Microsoft and is designed to run in a .NET environment. It is a great option if you want to build apps for a Windows PC.

In Conclusion

The truth is it really doesn't matter what language you decide to learn first. The reality is that you will likely learn several programming languages throughout your career. The most import thing you will learn from your first language is the fundamentals of programming and how to think like a developer. Once you have developed these skills, you'll be able to pick up other languages fairly quickly.

Pick any language and focus on it until you become comfortable with general programming concepts. Only then should you consider learning another language.