DEV Community: Theo Harris

How I set up my Frontend Mentor projects with Tailwind CSS

Theo Harris — Wed, 15 Jan 2025 00:31:47 +0000

Recently at work there has been a shift in our workload that means I'm not in my usual happy place as a developer - that is to say, there are no front end features to be built. To remedy this, I've hopped back into the projects provided on Frontend Mentor, a platform that provides beautiful UI mockups that developers can turn into real projects. I started on their platform about a year ago, and I've been super impressed, not only by the quality of the projects, but also by the focus on community building and particularly on educating developers on accessibility best practices. It's a fantastic resource that I highly recommend for any developer looking to hone their frontend skills on realistic projects - there are varying degrees of difficulty, starting from very simple projects that only require HTML and CSS to build, so there's something for every skill level!

One of the great things about the platform is they simply provide a design along with some basic starter code, so you're free to choose whatever combination of technologies you'd like to complete the project with. For me personally, I'm on a bit of a journey of minimising framework usage¹ and focusing on writing semantic HTML, with plain JS sprinkled in for interactivity, so that's primarily what my solutions will look like moving forward.

Having said that, I do still far and away prefer Tailwind as my styling solution for side projects. I've been using it professionally for around three years now, and I find it strikes a nice balance between useful default utility classes and a pleasant developer experience when it comes to expanding its base capabilties (which we cover in detail below). I'm not suggesting that beginners should build with Tailwind straight away - definitely go learn CSS first! But as someone who is very comfortable with how CSS itself works, Tailwind is a productivity boon for me, personally, as I understand what its utility classes are doing under the hood.

Therefore, as I've worked through several of Frontend Mentor's challenges, I've had to add Tailwind to the provided project starter code quite a few times now. I figured it may be helpful to other developers who are newer to the platform, but who would also like to utilise Tailwind in their own projects, to document my workflow for installing and configuring Tailwind on a typical starter project. As is the way with many things in dependency management, there's about a million different ways to do this. This is simply my preferred method, so your mileage may vary.

Installing Tailwind

Package Installation

First, you'll want to navigate to the root directory of the starter code you've downloaded from Frontend Mentor, and run the following command to install Tailwind and its dependencies:

npm install -D tailwindcss postcss autoprefixer

Some notes on dependencies:

Tailwind CSS uses PostCSS to process your CSS. PostCSS is a tool for transforming CSS with JavaScript plugins, and Tailwind CSS itself is a PostCSS plugin².
Autoprefixer is a PostCSS plugin that adds vendor prefixes to your CSS rules using values from Can I Use. It ensures that your CSS works across different browsers.

These technically aren't required to install Tailwind in your project, but I've generally found things run smoother when using them.

Initialise TailwindCSS

Next, we want to generate the tailwind.config.js and postcss.config.js files using the following command:

npx tailwindcss init -p

Configure Source Paths

Next, navigate to tailwind.config.js and add index.html to the content array - this will ensure that unneccessary styles get purged. You can read a bit more about how this works in practice in Tailwind's Content Config docs.

Note that if you create multiple HTML files for your project that are going to be styled with Tailwind utility classes, you'll have to add their paths to this array as well.

module.exports = {
  content: ["index.html"],
  theme: {},
  plugins: [],
};

Include Tailwind in your CSS

Create a CSS file (I typically just name mine styles.css) in your project root and add the following to it:

@tailwind base;
@tailwind components;
@tailwind utilities;

Adding and Running a Build Script

In your package.json file, add a script to build your CSS. This will create an output.css files with the styles that are built. The --watch flag lets us observe CSS changes in realtime, meaning we don't have to restart our script every time we update our styles.

Note that you can name this command whatever you'd like - I'm just following convention here.

"scripts": {
  "build:css": "tailwindcss build styles.css -o output.css --watch"
}

Now you can compile your CSS by running the script like so:

npm run build:css

Linking the Stylesheet

Finally, you'll want to include a link tag inside the head of your index.html file (and any other HTML files you want your styles to apply to):

<link href="output.css" rel="stylesheet" />

You should now be able to test that Tailwind is working in this file. I typically add something like class="text-red-600" to the body tag inside index.html and confirm that the text does indeed turn red.

Installing Project Fonts

When you download the starter code for a project from Frontend Mentor, they include font files for the fonts used in the design you'll be building. This usually includes a combination of both variable and static font files. For our purposes, we'll be using the files provided in ./assets/fonts/static.

I'd recommend taking a look at these files as well as the style-guide.md file provided in the project root to get an idea of which fonts are used, and which font weights are required.

Adding `@font-face` Rules

Once you've gotten your bearings, you'll want to create another new CSS file in the root of the project (I typically call this file fonts.css), and then define @font-face rules for each of the font files provided in the starter code:

@font-face {
  font-family: "Inter";
  font-weight: 400;
  src: url("assets/fonts/static/Inter-Regular.ttf") format("ttf");
}

@font-face {
  font-family: "Inter";
  font-weight: 600;
  src: url("assets/fonts/static/Inter-SemiBold.ttf") format("ttf");
}

@font-face {
  font-family: "Inter";
  font-weight: 700;
  src: url("assets/fonts/static/Inter-Bold.ttf") format("ttf");
}

The example above is from my solution to the Social Links Profile Challenge, which uses the Inter font in 3 different weights.

Once you've defined your font faces, you'll want to link the stylesheet in your HTML document as we did with output.css earlier:

<link href="fonts.css" rel="stylesheet" />

Extending Tailwind Config

Now, we need to extend our theme inside tailwind.config.js to add some utility classes to apply our project fonts where we need them:

module.exports = {
  purge: ["./index.html"],
  theme: {
    extend: {
      fontFamily: {
        inter: ["Inter", "sans-serif"],
      },
    },
  },
  variants: {
    extend: {},
  },
  plugins: [],
};

Note that if your project has multiple custom fonts, you can define as many properties as you need inside the fontFamily object. You can name these properties whatever you like, but I typically just kebab-case the name of the font to align with how most Tailwind utilities are written out of the box, e.g. comic-sans.

Now, you should be able to add the font-inter class to your HTML and see your new font applied to your markup! You can also use the different font weights that we've set up, e.g. font-semibold to apply the font at a 600 weight.

<p class="font-inter font-semibold">Hello World</p>

Setting Up Project Colour Palette

Earlier, when you were taking a look at the style-guide.md file provided with the starter code, you may have noticed that the challenge creators have helpfully noted all of the different colours used to create the final design. Neat!

We can now use this information to set up some more theme extensions, this time to the color property, in our tailwind.config.js file. This will allow us to set up utility classes for the colours we'll need to build our project.

If we take a look at the colours provided in the starter code for the Recipe Page Challenge, we'll see the following:

## Colors

- White: hsl(0, 0%, 100%)

- Stone 100: hsl(30, 54%, 90%)
- Stone 150: hsl(30, 18%, 87%)
- Stone 600: hsl(30, 10%, 34%)
- Stone 900: hsl(24, 5%, 18%)

- Brown 800: hsl(14, 45%, 36%)

- Rose 800: hsl(332, 51%, 32%)
- Rose 50: hsl(330, 100%, 98%)

This is awesome - the colours are already named for us (naming is hard), and they've been given number values indicating how light or dark they are, just like the base colours that Tailwind provides us with!

We can now add these colours to our tailwind.config.js file like so:

module.exports = {
  content: ["index.html"],
  theme: {
    extend: {
      fontFamily: {
        inter: ["Inter", "sans-serif"],
      },
      colors: {
        stone: {
          100: "hsl(30, 54%, 90%)",
          150: "hsl(30, 18%, 87%)",
          600: "hsl(30, 10%, 34%)",
          900: "hsl(24, 5%, 18%)",
        },
        brown: {
          800: "hsl(14, 45%, 36%)",
        },
        rose: {
          50: "hsl(330, 100%, 98%)",
          800: "hsl(332, 51%, 32%)",
        },
      },
    },
  },
  plugins: [],
};

Now we can use these custom colours just as we would with the base colours provided by Tailwind!

<button class="bg-rose-800 text-stone-100">Click me!</button>

If you'd like to learn more about how you can customise colours in your Tailwind config, I'd recommend checking out Tailwind's docs on Customizing Colors.

Final Thoughts

That's about all you'll need to get up and running and ready to start coding your Frontend Mentor solution with Tailwind!

While initially I kind of felt like installing several packages in a small challenge project was overkill, in my case, I find the tradeoff worth it when considering the productivity benefits I get from using Tailwind. Ultimately, the purpose of these challenges is for learning, so using a framework I know well for styling is allowing me to focus on other areas, such as HTML semantics and trying out the occasional front end framework. I know this won't be the case for everyone, and that's okay! I'd encourage you to find a workflow that best addresses your needs and learning goals.

If you ever want to get some feedback on a challenge solution, feel free to hit me up on FEM!

If this is something you're interested in, I highly recommend checking out the Lean Web Club by Chris Ferdinandi ↩
Zev Averbach writes about Tailwind and PostCSS in more detail ↩

ElixirConf 2022 - That's a wrap!

Theo Harris — Mon, 12 Sep 2022 22:31:23 +0000

If you've been following my sporadic twitter posts as I continue building my skills as a developer, you'll know that I was incredibly fortunate to be accepted as a speaker at this year's ElixirConf in Aurora, Colorado. For the last week, I (along with fellow Alembians Josh Price and Zach Daniel) have had the privilege of hanging out in the United States with some of the most talented people I have ever met, all of whom are present and vocal members of the Elixir community.

If you know me personally, you'll also know that this was a super special trip for me, as it was not only my first time speaking at a conference, but also, my first trip outside my home country of Australia! Despite lots of travel-related hijinks that left me a little worse for wear, I'd do it all again if it meant meeting so many amazing, talented, wonderful programmers.

It was an incredibly jam-packed three days for myself and my colleagues, in between running our Alembic sponsor booth, sharing everything going on with the Ash framework, presenting my talk to the community and soaking up the knowledge of many, many incredible speakers. The community is continually innovating in the Elixir ecosystem, as displayed by some of the presentations shared at the conference:

Brooklin Myers from Dockyard has been hard at work building the curriculum for Dockyard Academy, a bootcamp designed to train developers to fill the increasing number of Elixir developer roles. The entire twelve-week curriculum is available on GitHub for early review - and the whole thing is created by utilising LiveBook to create an interactive learning experience that makes devs get their hands dirty. As discussed in his talk, Brooklin has utilised smart cells to ensure a friendlier and more accessible user experience for students taking the online course, providing widgets that allow for easier navigation through course materials.
Chris Grainger is making strides in the machine learning side of the Elixir community with his company, Amplified. By utilising machine learning and training a model to find specific patterns in text, Chris has created a platform that allows for incredibly complex queries to be run on Amplified's database of patents. By giving users incredibly granular control over queries to the database, Amplified allows for finding specific words and phrases in the text contained within patents to minimise the amount of manual reading needed when a patent applicant is researching potential conflicts.
Tyler Young took the floor to show the community how the team at Felt handled multiple people making edits simultaneously in their map editor. As Elixir’s ecosystem evolves, it will be fascinating to see more and more use cases for multiplayer editing, and how interfaces for such complex interactions will be handled.

These are just some of the highlights from the talks I was able to watch in-between discussions with fellow developers and hanging out at the Alembic booth giving out stickers. It was fantastic to see many speakers from different specialisations and at different levels of seniority and experience share their knowledge and learning with the rest of the community, and notably, it was fascinating to see the sheer variety of different use cases in which Elixir is being utilised by individuals and organisations alike.

Of course, no ElixirConf would be complete without its keynotes, and the core teams behind the ecosystem’s technologies and frameworks absolutely delivered.

Opening Keynote - José Valim

Apart from the updates announced for Elixir 1.14 released as part of the changelog, José spoke at length about the next steps for Elixir:

The core team is aiming to continue releasing updates every 6 to 9 months, focusing on smaller improvements and optimisations. He mentioned that this cycle allows the team enough breathing room to experiment with new ideas in preparation for larger updates to the language.
Three key areas of focus were pointed out for the future of Elixir - set-theoretic types (which he covered at length in his ElixirConf EU 2022 Keynote), developer and learning experience, and machine learning.
José is adamantly championing Livebook as a tool for learning the language and teaching aspiring alchemists. In particular, he spoke about the breadth of possibilities for visualising aspects of Livebook using Kino, such as charts, graphs, and mermaid diagrams. As mentioned previously, Dockyard Academy is taking this approach with their bootcamp curriculum, and is using this suite of visualisation tools alongside smart cells to lower the barrier to entry for new developers.
Machine learning is rapidly expanding within the Elixir ecosystem, with tools such as Nx, Axon, and Explorer being used both by individuals and companies such as Amplified, as mentioned above.

It’s fantastic to see the focus on developer and learning experience in particular, as more and more Elixir positions are opening and developers are joining the community.

Closing Keynote - Chris McCord

Despite some disruptive technical difficulties around laptops and screen sharing, Chris delivered some news that delighted users of Phoenix and LiveView across the board:

We’re getting a nifty new feature, Phoenix.VerifiedRoutes, as a replacement for the (currently very verbose) route helper methods. They’re a sigil-based string that, at compile time, is dispatched against the router and throws a warning if no match is found. This also works with nesting, turning this:
```
 resources "/posts", PostController do
        resources "/comments", CommentController
 end 
 > Routes.post_comment_path(@conn, :show, @post, @comment)  
```
Into this:
```
~p"/posts/#{@post.id}/comments/#{@comment.id}"
```
To paraphrase Chris, we now get to sprinkle strings everywhere, but in a way that “doesn’t suck”.
LiveView is getting declarative assigns and slots that help provide some quality of life improvements at compile time. Notably, we can now add docs in our declaration:
```
attr :row_id, :any, default: nil, doc: "the function compute each tr id"
attr :rest, :global, doc: "arbitrary HTML attrs to apply to the tbody"
```
This means that mix.docs can now pull these into the documentation in a human-readable way.

Previously, we had to use the assigns_to_attributes function to allow users to pass in arbitrary assigns, like so:

def icon(assigns) do
    assigns =
        assigns
        |> assign_new(:outlined, fn -> false end)
        |> assign_new(:class, fn -> "w-4 h-4 inline-block" end)

~H"""
<Hero.icon
    name={@name}
    outlined={@outlined}
    class={@class}
    {assigns_to_attributes(assigns)}
/>
"""

But now, with the use of a :global attribute, we can write the same component like so:

attr :name, :atom, required: true
attr :outlined, :boolean, default: false
attr :rest, :global, default: %{class: "w-4 h-4 inline-block"}

def icon(assigns) do
    ~H"""
    <Hero.icon
        name={@name}
        outlined={@outlined}
        {@rest}
    />
    """
end

A HEEx formatter is here in the form of a mix formatter plugin, thanks to Felipe Renan. This is a huge quality of life improvement and people were cheering at this announcement!
The authentication system in Phoenix has had live generation added with phx.gen.auth -live, thanks to Berenice Medel from the Phoenix core team. By creating auth flows with LiveView, we can create richer experiences for users when logging in or signing up, with niceties such as real time form feedback creating a better user experience. Additionally, all of the newly generated code with this flag is fully tested.
Phoenix 1.7 will include Tailwind by default when creating a new app - no flag needed. Chris was careful to point out that this can be removed with minimal effort if devs don’t want to use it in their app, but also pointed out how Tailwind pairs incredibly well with Phoenix’s component system. Additionally, the new landing page generated with a new app is designed by the team at Tailwind, and includes resources to help users who are new to using Tailwind in their apps.
LiveView 0.18 is very accessibility-focused, and is releasing with a new function component, <.focus_wrap>. This is useful for maintaining focus events to stay within a modal when the user has one open, rather than tabbing through fields and ending up somewhere outside of the modal while it is still open. This is included with the new out of the box components being brought to Phoenix, so that a certain level of accessibility is baked into the code generated with phx.gen.auth.

Chris wrapped up by sharing the Roadmap of future features, including:

Integration with Christian Blavier’s Phoenix Storybook project
Unified LiveView/LiveComponent messaging
Improved Phoenix.Form API
Function component template files
A <.layout> function component

A great time to be using Elixir

Ultimately, this year’s ElixirConf showed just how much developers and companies are benefitting from the “Elixir advantage” - teams are building things faster, cheaper and with less people than before. Elixir’s use cases are growing even broader, especially with renewed focus on the machine learning tools and libraries within the ecosystem and the business value that they can bring. With core project teams working hard to make Elixir and its frameworks even more robust and delightful to use, the future of this language and its community is looking brighter than ever.

Want to enjoy the Elixir advantage on your next project? Get in touch with us at Alembic.

How keeping a sketchbook can make you a better developer

Theo Harris — Wed, 07 Jul 2021 04:53:02 +0000

If you're not used to practicing visual art, the idea of keeping a sketchbook might seem pretty daunting. Even seasoned artists have a famed fear of the ever-intimidating blank page. So crisp and smooth - how could we possibly ruin it with our pencil marks and chicken-scratch handwriting? Getting over this fear is worth another blog post entirely, but once you push through, a sketchbook can be a useful everyday tool for recording everyday thoughts, feelings, and ideas.

I've been keeping sketchbooks since I was around eight years old (for those keeping count, that's roughly 14 years of sketching as of the time of writing). They've obviously evolved with me over the years as my art skills improved, however, one of the most valuable lessons I've learned in over a decade of working in sketchbooks is that sketchbooks are useful for so much more than just art. As I've gotten older, my sketchbooks have gotten messier, but so much more valuable. Recipes for eggplant lasagna and phone numbers of people I probably forgot to call back grace the pages in between renders of local birds and thumbnails for future large works. I also keep loose documents folded in my sketchbook such as business cards and medical prescriptions (since I always have my sketchbook with me). My sketchbooks are a beautiful, chaotic snapshot into my daily life.

When I started at Coder Academy last October, I brought my sketchbook with me on the first day. At the time, it was a small moleskine sketchbook filled with drawings and notes from my art degree. That first day, I think I made roughly three pages of notes, and by the end of the term, my sketchbook was completely full of coding knowledge and syntax snippets. My sketchbook was one of my most beneficial tools for getting through bootcamp, and I want to share some reasons why. I think that sketchbooks are an underutilised tool outside of visual arts settings, and could be key for some of my fellow developers to unlock another level of learning and productivity.

Without futher ado, here are some reasons why keeping a sketchbook could make you a better developer.

Handwritten notes can be beneficial for retaining knowledge

While it can be tempting to take notes on your laptop if you already have it out to work on code, studies have found that there are learning benefits to taking notes by hand. While this may sound paradoxical given how fast one can type in comparison to writing by hand, the research suggests that taking the time to write notes by hand requires that students are able to accurately summarise the material being presented in order to take concise notes, rather than copying a speaker verbatim without actually processing any of the information.

It's no secret that programmers are constantly learning and uptaking information. Additionally, this learning can be extremely fast-paced, especially for those enrolled in bootcamp programs like myself. To digest such a large amount of information, note-taking becomes essential, and many developers will keep their notes to refer back to when they reach a sticking point.

During my time at bootcamp, my sketchbook has become absolutely invaluable to me due to the handwritten notes it has amassed. Physically writing these notes by hand has undoubtedly helped me retain knowledge to a greater extent than typing my notes out (trust me, I tried), and has the additional benefit of freeing up my laptop to be used purely for programming along with my tutors during class. This, in turn, has limited distractions during class for me, as I can simply leave my IDE open and avoid flicking between tabs and potentially getting sidetracked by other windows.

One other thing worth mentioning is that physical, handwritten notes don't fall victim to file corruption and lack of internet connection. I had a classmate who, for a time, decided to take all of his class notes in Vim without being fully acquainted with how it works. One fateful day, several wrong commands later, he managed to lose all of the notes he had typed for the duration of our four hour morning class. Writing your notes by hand ensures this never happens! Just, you know, don't spill your coffee on your sketchbook.

Additionally, handwritten notes can still be shared with friends or backed up via the cloud. This can be done either by taking scans/photographs of your sketchbook pages, or by transcribing your notes into typed text. I found the latter option to be useful for two reasons - it meant that my friends no longer had to translate my messy handwriting when they asked for notes, and it also doubled as a chance for me to review what I had been learning.

Visualising your code can help you think through problems differently

By this point you might be wondering where the actual "sketch" part of the sketchbook comes in. Now, while you might not be the world's next Da Vinci, drawing out a visual representation of your code can help you approach your code from a different perspective.

An example of this I commonly use in my own coding projects is using physical sketches to plan and visualise the layout of my web pages. This is because I primarily use flexbox for my CSS layouts in order to easily keep things looking nice across multiple media breakpoints. Anyone who has worked with flexbox knows that working out exactly how to wrap your web page components in order to make them flow the way you want can be a massive headache. Add a div here, remove another one there, cry at your desk, rinse and repeat. However, physically diagramming out my page lets me explicitly draw in and mark how my page content needs to be divided up for flex to work appropriately. For example, here's a page from my sketchbook mocking up a web page design:

You can see that I've drawn out all of my components on the page in the way I would like them to be displayed, and then containerised them into their own flexboxes in a way that makes this layout possible in CSS. This gives me a visual reference to start coding from and minimises the amount of experimentation I will have to do during the build phase to get my components laid out correctly.

Now, this method isn't just for my front-end developer friends. Those of you working with data can also utilise your sketchbook for drawing out Entity Relationship Diagrams. Visualising the relationships between your entities when working with relational databases is crucial, and I'm yet to find a good online tool that lets me make an ERD quicker than drawing one by hand. Having the visual aid of an ERD with me in my sketchbook while I work has helped me avoid issues with my data that I might not have seen otherwise.

Sketching these kinds of solutions out in a physical book limits the need to fiddle with and learn online tools, allowing you to get your planning done quicker and get to coding sooner.

Drawing improves the ability to recall information

It's no secret to those in the tech community that creativity is a key skill for programmers. So why aren't we utilising learning methods that encourage creative thinking?

There is a phenomenon known as the "drawing effect", wherein illustrating the meaning of a word or concept increases one's ability to memorise it. The term was coined by Jeffrey D. Wammes during a 2016 study he conducted to analyse the effect that drawing has on the memory. In the initial two experiments, Wammes gave his participants a list of relatively simple words, for example, "kite", and "peanut". Half of the participants were asked to write the word to be remembered repeatedly, and the other half were asked to draw a visual representation. In both cases, the group who drew their words were able to recall the words more easily.

"But what if I'm no good at drawing?", I hear you ask? This method is still beneficial, as long as you are willing to try! Wammes later conducted an additional set of experiments where participants, once again, were given a list of simple words. This time, however, while one half were asked to draw, the other half were asked to hold a visual representation in their mind's eye, as well as shown photographs relating to the words to be remembered. The result? The half who drew their words were still able to recall them more accurately. This suggests that the actual quality of the image doesn't matter, but rather, the act of drawing itself is what catalyses the ability to retain information.

Your visual notes don't have to be elaborate, either - even if you are a talented artist. Wammes attempted to expose limitations in the drawing effect by reducing the time given for participants to draw their words from the initial 40 seconds down to only 4 seconds. Even with this massive reduction, participants from the drawing group still bested those from the other group. Wonky stick men will absolutely suffice here, my friends.

Now, imagine having that boost in recall ability during your next technical interview. Need to implement a tricky callback function? Good thing you drew that diagram showcasing how the information flows together!

The Verdict

I'm not saying that everyone is (or has to be) comfortable keeping a sketchbook. I've seen people anxious to mark a blank page because they're "bad" at drawing. My advice, though, is to give keeping a sketchbook a genuine go. Get a cheap one from the dollar store if you're worried about ruining it or wasting money. Maybe you'll just find that your sketchbook helps you become a better developer.

Full Stack Boot Camp: Leaving JS for Later

Theo Harris — Tue, 08 Dec 2020 05:16:20 +0000

As an active member of Dev Twitter, I'm more than familiar with the kinds of tweets circulating the tech community. Code snippets, portfolio highlights, and celebratory posts following successful job interviews are always a pleasure to see. However, a trend I've noticed among so-called "Code Influencers" (Codefluencers?) is the generic numbered list of "Steps to Become a Full Stack Developer", which usually go something like this tweet:

JavaScript Teacher

@js_tut

Stage 1 – HTML, DOM.
Stage 2 – CSS (Grid, Flex.)
Stage 3 – JavaScript.
Stage 4 – React.
Stage 5 – Node.js
Stage 6 – MySQL.
Stage 7 – MongoDB.
Stage 8 – The CRUD pattern.
Stage 9 – Back-end XP at your first job.
🏆 – Full Stack developer.

21:57 PM - 22 Oct 2020

While I'm a strong advocate for self-education when it comes to coding, and believe that you should follow whatever tech stack interests you, I feel as though there's a huge push for people to learn JavaScript IMMEDIATELY after HTML and CSS basics are mastered. It feels like it's almost required to continue web development.

While I can understand wanting to learn a technology that is both in-demand and has powerful capabilities, JavaScript is notoriously difficult to learn, even to slightly more experienced developers. No doubt I would have been struggling with it myself months ago (and would probably have cultivated a love/hate relationship akin to how most feel about CSS) if I had follow the dominant narrative of learning JS straight away.

However, I'm thankful that I learned Ruby first.

Being in a boot camp has both its pros and cons, and not learning JavaScript in the first few months could fall into either one of these categories depending on your perspective. However, being a student means following the curriculum, and one thing that our program does that seems to deviate from the norm is teaching its students to program in Ruby before any other programming language. At first I was skeptical of this approach; dev jobs online are all seeking JS and Python programmers. Learning Ruby was, at times, incredibly frustrating. But when I finally started teaching myself JavaScript, everything started to make sense.

For those that are unfamiliar with Ruby as a language, it's designed to be as readable to humans as possible. Ruby's creator, Yukihiro "Matz" Matsumoto, essentially took features of several languages that he found pleasant to use, and wrapped them all nicely in an Object-Oriented Programming Language that was pleasant to read and abstracted unnecessary complexities.

Thus, in 1995, Ruby was born. But why learn a relatively new and underutilised language over an in-demand technology?

Anyone who has learned to program can likely attest to the fact that learning your first programming language can be a frustrating endeavour. While I felt much the same way about Ruby in my first few weeks working with it, I am someone with no previous programming experience. I can say without a doubt that Ruby gave me the confidence with programming I really needed to start exploring other languages on my own, and it's all due to its simple syntax.

The reason I recommend Ruby prior to learning JavaScript is the similarities between the two languages. Basic JavaScript feels a lot like writing in Ruby with a little extra syntax (eg the keyword "lets" in front of variables, and console.log() instead of the keyword "puts"). Diving into JS after a month of coding in Ruby means I can already do everything in JS that I am capable of in Ruby, with next to no effort on my part.

I am, of course, speaking as a boot camp student, and I no doubt have the amazing educational staff at Coder Academy Sydney to thank for my rapid growth as a developer. However, I do firmly believe that Ruby is a fantastic stepping stone towards JavaScript, that can help prevent future frustrations and the potential of lost passion over a language that just won't seem to work.

My advice to those learning to program: Try Ruby. If you find that it isn't for you, then there's nothing lost, and there's a multitude of other tech waiting for you to play with. But don't let Ruby's relative obscurity fool you into passing by an enjoyable and powerful language.

A Tale of Bootcamp and Blogging

Theo Harris — Mon, 30 Nov 2020 06:29:28 +0000

In February of 2020, I lost my retail job.

It was a long time coming, of course - poor upper-management, low foot traffic and an encroaching threat of economic recession meant that we were due to close when the company owners failed to sell their brand into more capable hands. It's not like I didn't know it was going to happen. What I failed to anticipate, however, was a global pandemic.

You've probably heard plenty of sob stories from my fellow retail workers, lamenting over job searches and failed applications. I was in the same boat, sending out endless resumes to cricket noises in lieu of return emails. I landed a retail gig in June of this year, but then injured my back (which led to the discovery of long-term undiagnosed scoliosis) and was advised by my doctor to quit retail, as it was making my back deteriorate even faster.

So, I turned to the industry that was flourishing during the period of indoor isolation - web development.

I had some knowledge of Coder Academy's Bootcamps prior to my application, due to connections to staff that have taught there. In what felt like a rather brash decision, I signed up and started teaching myself how to build a website from scratch in the lead-up to my first class.

Two months later, I have built my first website with HTML and CSS, and can write programs in Ruby, as well as utilise version control through Git and Github.

I want to emphasise that I previously had only dabbled in code through hand-held tutorials and simple block-based programs. I had never run anything in my computer terminal. I had no idea what Github was, other than a place where I could download cool themes for RainMeter. Now, two months on, I can build websites and write programs from scratch.

The thing that changed was my mindset. I had this preconceived notion that programming and software development was reserved for "smart people" and that I wasn't a smart person. The key was changing my outlook on failure. Growing up, failure in any capacity was the end of the line for me. "That's it", I would think, "I'm doomed to be terrible at (insert activity here) and I'm never going to try again so I don't embarrass myself".

But how is programming different to my past failures?

Every failure, from week one of bootcamp, became an opportunity for growth. Because programming is presented as problem solving, I found it easier to take a step back when my code didn't run as expected, and look objectively at what was going wrong. Even though technically the errors in the code were my fault, every single mistake was a learning experience, something I could commit to memory once I had discovered a solution. That feeling became addictive - a constant desire to improve myself and hone my skillset. I suddenly had a whole new world of opportunities to explore, skills to learn, projects to build, and people to meet.

The tech community, especially on twitter, has also been an incredibly helpful and encouraging environment. Being able to follow people in various stages of their own journeys is motivating, and every member of the community I've interacted with feels real, authentic. I'm sure tech twitter does have its bad apples, of course, as any community does, but I'm incredibly grateful for the myriad of positivity that has come from joining such a great community.

That brings me to why I'm starting a blog.

My favourite experiences, the ones that have been the most engaging to follow, have been those from devs just starting their journeys, and growing little by little each day. Watching people learn new things, overcome challenges, and generally flourish is the boost of positivity we need in the dumpster fire of a year that is 2020. So I want to give back by making my own blog.

I want to try my best to talk about what I'm learning and how I'm learning it. I want to be as helpful as possible to new devs, and maybe even to people considering web development as their career. Eventually maybe I'll have the confidence to post tutorials and other content. For now, it's a learning journey.