DEV Community: Nevulo

Learning how to unblock yourself in projects

Nevulo — Thu, 16 Jun 2022 13:33:23 +0000

Being blocked (a phrase used in project management, especially software development in agile teams) typically means there’s something external, outside your control, that is preventing you from making progress in a particular task or project. When this is the case, it can be frustrating, but some blockers are almost impossible to get around.

Think about bringing a new person on the team and bringing them up to speed with the codebase (which will inevitably take some time), or contacting a third party who has long reply times.

There’s all different types of blockers. Some blockers can’t be solved for. However, some can be. Think about technical blockers, which typically happen when developing or planning a solution in software, and you’re having trouble progressing. Unlike dealing with an external entity that is largely out of our control, we’re really only dealing with ourselves here.

Don’t get me wrong, not all blockers are like this. Regarding technical blockers, you might be faced with technical debt or architectural problems that really do need your attention and take time away from deadlines because that’s ultimately what’s best for the project. There’s a fine balance between quality and producing what you require as fast as possible.

Let’s break this all down. What does being blocked actually look like, and what are some actionable tips for ensuring good flow in a project?

What does being blocked or impeded look like?

A quick note, what I’m mentioning isn’t necessarily industry standard or anything, but a practical approach to the way I, personally, see blockers. Some can potentially be solved quickly, some probably can’t. Ultimately, to stay productive, we want to try to identify when we’re blocked but also what type of block we’re experiencing.

A lot of my experiences are project management in the eyes of a software engineer, but I’m hoping they apply broadly to other roles.

External blockers

I see external blockers as true blockers. At the end of the day, if you’re relying on a third party to complete something, and it’s a must-have, there’s probably not much you can do in a practical sense.

A good example of this is a SaaS (software-as-a-service) provider that you’ve made an agreement with, but doesn’t offer exactly what you need.

With some blockers that last a few hours or days, or when you have obligations, it’s not really sensible to entirely change around your approach just to get around one thing.

External blockers give you a good opportunity to pick up new work though to keep up the general flow of the project, ideally work with a turn-around rate that is within the timeframe you’re roughly expecting to be unblocked in.

In a complete worst-case scenario, you can try a few other pragmatic actions:

reducing the scope of the project to avoid particular requirements leading to the blocker
increasing the scope/time-frame of the project, and looking into developing your own solutions to avoid an external entity

Internal blockers

Internal blockers occur internally within an organisation or team. Common internal blockers include:

new people coming on the team
dependencies, such as approval from teams that take longer than planned
communication break-downs or misunderstandings
technical problems, like needing to address a severe problem in a different area of the project, taking time away from what you’re working on

A lot of these blockers boil down to the need for more planning. Playing devil’s advocate, there’s also a downside to over-planning if you have a strict deadline. If you’re trying to get something done in 3 months, you typically don’t want to spend 2 months planning.

It also comes down to resource and priority management within your team; making sure you’re not spending too much time doing things that don’t bring value to the final results of the project.

Personal blockers

This is where you can often put power in your hands and take action towards blockers.

There’s the argument that a personal blocker isn’t really worth noting down as a blocker, but the truth is, we’re all human, and occasionally, we unintentionally go down a rabbit hole, get stuck, or have many priorities.

Some examples that come to my mind for personal blockers include:

up-skilling yourself for a task, like navigating around a new service or diving into areas that you’re not super knowledgable in
getting stuck on a certain problem to solve some requirement for the project
focusing attention in areas which aren’t directly contributing to the end goals for the overall project
time-management and task-management

It’s true that even some personal blockers take longer than we might expect to get around. But often, I find with personal blockers, there are a few key things I ask myself:

Is there a different, sensible approach to get to the same solution?

Sometimes, we need to settle with a solution for the sake of time that works now, but we might want to change down the line. This can lead to technical debt – and though you don’t want too much, a little isn’t bad. Don’t overshoot for perfection, especially with a strict deadline.
Is there a quicker way to do this?

Instead of doing something manually, could I automate it? If it’s practical, could I get the help from somebody else to solve this faster (through pairing or reviews, for example)?
What resources are available to me to get around this blocker?

Such as asking team members for help, getting in touch with a support person, looking online for documentation to get clarification, etc.

Actionable tips to unblock you and your team to keep moving forward

Identify if you’re blocking yourself

Often, the first thing I’ll do if I’m blocked is try to see if I’m actually blocking myself, as mentioned earlier. If you are, set out to follow a series of logical steps to find a way to unblock yourself.

Ensure you’re not spending too much time in a certain area, and keep track of your personal flow to find room for improvements. Remember – it’s always okay to ask for help!

Allocate strict time/effort resources, like a budget

You want to avoid spending too much time in the wrong areas. Use tools like time boxing to ensure you’re allocating a specific amount of time to certain tasks, or a system like story points to know ahead of time the amount of effort, risk, or complexity involved with a certain task.

As a last resort: work through a different problem

There are a few benefits to picking up new work to get around a blocker in existing work. There’s some research around the fact that taking a break can help you find the solution to problems quicker, and I’ve personally found this to be true when working through a different problem. Usually, I’ll be able to come back to the original work that was blocked and see with “clearer eyes” 👁

The main thing to watch out for is team bandwidth, which tracks how much time team members actually have to complete tasks given other priorities they’re already working through. In other words – you want to avoid overloading anyone.

Top tools to help you stay productive as a developer

Nevulo — Thu, 16 Jun 2022 12:59:51 +0000

I’m obsessed with squeezing out productivity wherever possible. Over the years, I’ve developed a workflow that helps me get work done effectively and efficiently. I’m a massive fan of having lots of information available at my disposal, while also remaining organised and clean (sometimes, at least 😅).

I’m also a big believer in tools and apps. In some cases, I think finding the right tool for the job (or in my case, a well-made application) can help you optimise your workflow to help you be more efficient and productive.

Everybody’s got a different definition of what it means to be productive. I’ll be mentioning 7 different types of applications I use daily as a software engineer to help me stay productive, why it helps me personally, as well as alternative applications to try to fit your needs!

Terminal — iTerm

iTerm is a terminal for macOS which has all the features you could ever want. It describes itself as a “replacement” for the terminal, but I think it’s more of a re-imagination of the terminal and what’s possible to squeeze the most functionality out of a terminal for your productivity.

Here’s just some of my favourite features iTerm offers out of hundreds:

Splitting panes horizontally and vertically for maximum space-to-productivity ratio
Powerful search (with regex support)
Instant replay (travel back in time to recover lost text, super cool!)
Auto-completion with a suggestion window

As for auto-completion and suggestions, an honourable mention goes to Fig, a tool that integrates with your existing terminal to display smart suggestions and information when you’re stuck in the command line. Forgot certain commands or the structure of arguments? Fig is there to help.

Some fine alternatives to iTerm include Warp, a terminal built for the 21st century that looks and feels buttery-smooth. Very aesthetic.

Both of these are unfortunately only available for macOS currently (Warp is planning for a Windows/Linux release, however).
If you’re on Windows, the next best thing is probably the Windows Terminal, in my opinion. Not your standard “Command Prompt”; this is redesigned from the ground up to give you major customisation options with features similar to iTerm, while remaining performant with GPU acceleration.

IDE — Visual Studio Code

Visual Studio Code is an integrated development environment (IDE) from Microsoft that focuses on simplicity while opening the door for extreme customisation, extension support and other advanced features to help you stay productive.

You can try out VS Code without downloading anything, right in your browser!

Not interested in using software from a big corporation or buying into the hype? Lapce is an adequate alternative focused on great performance. Full disclosure—in my testing, things weren’t working so great, such as TypeScript syntax highlighting or opening certain files, and it is still under heavy development.

A more robust, battle-tested solution is Sublime Text. Initially released in 2008 and designed by ex-Google engineer Jon Skinner, who had the goal of making a better text editor, Sublime Text has many similar features to VS Code, focused on speed and extensibility.

Note-taking — Notion

I like to consider Notion to be a digital, opinionated piece of paper. You’re free to do whatever you want in whatever format you’d like, whether that’s note-taking, tracking expenses, formal specifications/documentation for a project, and so much more.

At its core, Notion has different types of “blocks” that build up pages that can be arranged in countless unique ways. Notion integrates with lots of different services which allows you to create rich documents with embeds, maps, drawings, whatever your heart desires.

Another great alternative is going back to basics; pen and paper! There’s absolutely nothing wrong with taking notes in your notebook or on a loose piece of paper. I like the digital aspect, so I can search through old notes, link my thinking, and organise things when necessary.

Calendar — Cron

It’s about time. According to Cron, at least.
Cron is a “next-generation calendar for professionals and teams”. I’ve been using Cron for about 3 months, and there’s a lot of little, nice things that help you juice that extra bit of productivity in your life.

Some notable things I, personally, love about Cron:

Quick access to join meetings attached to an event with one click
Integrates with the menu bar on macOS for easy access to see your next event
See all the information you could ever need when planning new events/meetings, including the availability of invitees
Automatically create Zoom links when creating meetings

I love the simplicity of Cron while remaining extremely functional. Cron is great at what it does; being a calendar. It’s great for time-management, blocking out time and giving me great access to information to make informed decisions around booking time with others.

As of writing, Cron is currently in early access, but with its recent acquisition by none other than Notion mentioned earlier, it won’t be long before you can have access too!

In the meantime, there are two alternatives which also might help you be more productive and save time. If you find yourself spending more time organising your calendar than getting stuff done, why not let artificial intelligence take the wheel?

Reclaim and Motion use the power of AI to automate your planning and create a more efficient, effective workflow to help you get around to everything you want to do.

To-do tracker — Todoist

Life is basically one big to-do list. I’ve dedicated a lot of my time to finding a good to-do tracking application. Probably too much time.

In the end, for now, I’ve settled with Todoist. It simply has everything I need and more:

The ability to track multiple projects (such as work, personal tasks, etc.)
Setting deadlines and due dates, with the ability to set reminders
Attach priority levels to tasks, so you know what’s important at a glance
Works great with teams, allowing you to assign people to tasks as well as add labels

The most important thing for me personally, however, is the speed at which I can add new tasks and check off existing items. I’ve noticed as a software engineer, my day moves around a lot, and I’ve got many priorities.

I’ve also often got a lot of “sub-tasks” to complete before I can call something truly done. Todoist provides a simple interface to give rich detail where necessary, while also allowing me to jot down new tasks when things change quickly.

There are so many alternatives to any to-do tracking app that I couldn’t possibly list them here. In the past, I’ve also made good use of Trello, which has a lot of the same features, showing your tasks as cards in columns (known as a kanban board).

Design — Figma

A lot of the applications listed so far are focused on simplicity with power under the hood to allow you to move quickly when needed, but also get the same value when it’s time to switch gears.

Figma is a wonderful example of this philosophy. It’s lightweight and gets out of your way, so you can draft up wireframes or sketches quickly, while giving you the power to create incredible, modern, and professional-looking designs.

Even though I’ve got practically no design skills, I was able to quickly create designs for my newsletter, Nevuletter, in less than an hour. It’s intuitive, and with all the functionality also accessible through their web-app, it’s a collaboration power-house.

I’ve used Adobe XD in the past, and it’s an absolute headache. I feel like Creative Cloud is an ever-growing virus – even if I wiped my computer, it’d probably still somehow launch at startup 😆

Jokes aside, Figma is outstanding for amateur and professional designers alike. If you’re a big fan of quickly getting ideas down into drawings or creating quick diagrams without worrying about your design skills, Excalidraw is another great tool I can recommend.

I use Excalidraw for some images in my blog posts. It’s a great tool for creating quick diagrams and drawings to get your point across visually.

I’ve found it’s also helpful for planning, or just representing an idea to somebody in a really fast, dirty way, while remaining legible and pretty. Each drawing feels like it had effort put in behind it, thanks to the hand-drawn look Excalidraw provides.

API Tooling — Insomnia

This one goes out to those working with APIs. Insomnia is a dedicated API client, the main benefit being you’re able to hit any endpoint, supplying any data you need in requests to test that everything works properly and getting detailed information around the response for that request.

One thing I’ll admit around Insomnia (and why I sometimes prefer Postman) is the fact that it doesn’t support path parameter variables. It might be a bit niche, and Insomnia does have a good community and extension support, but I think Postman nails this down better.

Another alternative you might want to look into is Paw – it’s a paid tool, and only available for macOS, but it has everything most people would need. The design is simplistic and modern, my only gripe is that it is so feature rich that it has a bit of a learning curve, and some basic actions felt a bit buried in the UI.

Conclusion

As of today, most of the tools listed here are my go-to’s. They’re the tools I keep reaching back for, to get the job done, and documenting them here feels like solidifying my “developer toolkit”.

I encourage everyone to create a short list of what you’re using today, for many reasons:

You don’t forget what you’re using and why you’re using it
To look back in the future to find improvements in your workflow (and celebrate that!)
To help others find tools or workflows that you might be using in unique ways

At the end of the day, one thing I love is that everybody does work differently, and I learn a lot when watching how other people work. I don’t use Vim or Emacs personally, but that’s just because that’s what works best for me. I know that plenty of people work faster than me using those tools and many other things I probably have no idea about.

What’s important to help you stay productive isn’t necessarily the tools, but rather your workflow, how you use the tools to get you closer to your goals. At the start of this post, I mentioned that I’m a big “apps” guy. I love digital things and applications to improve my life, but it’s possible that might change, and that it’s different for you.

Keeping track of the tools you’re using, and broader goals, helps you stay productive as a developer, so you can find ways to improve your workflow.

Why learning basic programming is important

Nevulo — Thu, 02 Jun 2022 17:02:17 +0000

I’ve written about how having fundamental knowledge on the command line can help you outside of landing an engineering role. It can help give you better visibility around what’s happening on your computer, on top of automating common, mundane tasks.

What about programming in general, though? What benefits do non-engineers gain from learning how to give instructions to a computer through code, and how can it help you in your day-to-day life, regardless of who you are or what you do?

With the rise of “no-code” tools, on the surface it seems like engineers might even be obsolete. Unfortunately, I can assure you that while these tools seem attractive, they’re all powered by one thing under the hood despite the name: code.

Learning basic computer programming fundamentals (not anything crazy, like how to invert a binary tree 🤓) is super important in this growing digital age. Even if the benefits aren’t clear now, in just the few years I’ve spent programming and building up my knowledge over time, it’s thoroughly changed the way I think and approach the real world.

Abstract & logical thinking

Programming promotes logical and creative thinking. There’s always more than one way to solve a particular problem and satisfy requirements.

Like many software solutions, something as benign as creating a basic quiz can be broken down into many smaller problems, building up to bigger functionality:

Showing the question to be answered by the user
Prompting the user for their answer & storing their input
Comparing the user's answer to the correct answer etc…

Each project you build or plan will have different requirements, but fundamentally you need to think on a microscopic scale around the problems to be solved to get to the final result. Think of it like explaining what you want done to a 5-year-old.

Productivity & the power of automation

They say great programmers are lazy, and I’m no exception. The word “lazy” might have a negative connotation, but being lazy can be a good thing. You’ll rarely catch me spending 5 hours manually inputting data into an Excel sheet because surely, there’s a better way.

I’m obsessed with efficiency. My mind is constantly looking for small optimizations to increase throughput.

Let’s say you’re working on an app with 50 thousand users. Your boss wants you to send through an Excel sheet containing information on how many of those 50 thousand users have signed up for a specific feature. All the data you need is available in the database, but there’s just one problem. There’s 50 thousand users.

Even if you’re in a good rhythm, and it takes you ~2 seconds to get one user’s data and document it in the spreadsheet, it would take you just over a full day of work to complete that one report.

It’s possible some companies would just bear the cost of hiring a few extra employees with some overtime to expedite those results. But, even when you split the work across multiple people, it’s hours of time that could be spent elsewhere. Why settle with “good enough”?

Give me six hours to chop down a tree, and I will spend the first four sharpening the axe.

A creative solution through programming can save you incredible amounts of time, allowing you to “buy back” time you would’ve spent doing the task had you not developed an automated solution. Essentially, offloading time you would’ve spent doing this dull task to a computer, so you can be more productive.

Or, if you’re like me, automating tasks to get back precious time for games or YouTube. Need to manage that a bit better…

A more in-depth understanding of technology

Technology is becoming an increasingly important part of our lives. We’re surrounded by technology everywhere we look, and the rate of technological developments and breakthroughs has no sign of slowing down.

I think there’s benefit in having at least a surface-level, superficial understanding of how the services and tools we use work under the hood, for many reasons, including:

being able to troubleshoot issues independently, saving time and potentially money
not being left in the dark when others are using certain technical terminology
incorporating technology in your interests

Okay, I get the idea. Where do I get started?

Learning basic programming is indispensable, but it’s definitely daunting if you’ve got no idea where to start. Even if you’re actively learning, but searching for some extra tips to supercharge your path to being a great developer, take a look at my piece on Earlywork around 5 secrets to teach yourself how to code!

It goes into detail around why setting tangible goals is essential, planning & breaking down problems, but most importantly, getting your hands dirty and digging deep to solve puzzles.

I’m on a personal mission to make programming more accessible and understandable for people all around the world through my newsletter, Nevuletter. Check it out, and subscribe if you’re looking for more content like this and other valuable information to hit the ground running, with a vast repository of programming knowledge around all kinds of topics.

Why do I code?

Nevulo — Thu, 02 Jun 2022 16:54:06 +0000

Learning how to read and write code is a versatile skill. I recently wrote about why I believe learning how to program is a vital skill that everybody should look to achieve.

This is for those who are looking to start out, or those who are in the space but struggling to find the motivation to continue. I want to share some inspiration around reasons why I code, why I love it, and how you can shift your mindset to stop programming from becoming a chore.

Why I started coding

I’ve been interested in computers since before the age of 10, but I can attribute one of my earliest experiences with programming with Visual Basic .NET (also known as VB.NET).

Somewhere around the age of 13, Visual Basic .NET was my first exposure to object-oriented programming. No need to go into my backstory, all I was excited about was being able to create Windows applications that could do certain things when clicking on buttons.

For the first time, I had the power to create essentially anything I wanted to. This, combined with my constantly evolving curiosity and desire to get better, I was always asking myself “how can this be better”? What else could I create if I used the knowledge I gained since the last thing I created?

Why I love coding today

There are many reasons I love coding, some of which I’ve listed later in this post. One that stands out is the fact that I’m obsessed with self-improvement, for my own sake and to give a better experience for everybody involved.

Going back to the VB.NET story, below is an example of what the syntax looks like:

Private Sub Button1_Click(sender As object, e As EventArgs) Handles Button1.Click
    Dim message as String = "Hello World!"
    System.Console.WriteLine(message)
End Sub

Here’s what my VB.NET code looked like roughly 7 years ago:

I probably don’t need to tell you that, surely, there’s a better way.
For context, this is just one snippet of a ~1500 line file for a security manager application. When a certain button gets clicked in the app, it changes the visibility of over 30 different labels, buttons, and other “elements” in the app screen, since everything was in the same view.

It was a start. Years ago, this was revolutionary to me and though I was aware it was cumbersome, I was likely under the impression this is just “how things are” in programming.

The truth is, well-designed programs can achieve the same result in less lines of code, while remaining scalable.

It’s not about necessarily getting things done in less lines of code. It’s about understanding architecture; specifically why the implementation above could be improved, ultimately delivering the best experience for those reading the code, and those using it.

If I added a new button to the view with the implementation above, I’d have to add a new line to that method handling when “button 2” is clicked – and all the other buttons necessary. 😬

Why coding tickles my brain in just the right way

The thrill of hard work paying off

There’s no doubt about it, programming is difficult, and can be draining. At the end of the day, we’re just giving instructions to a computer through a terse syntax, most of which rarely resembles basic English. It often throws up new surprises, especially when you’re just starting out.

Bringing art to life

I’m a strong believer that, like many things, programming is a form of art. You can think of a programmer like any content creator, whether it’d be a musician, painter, or a writer. Programmers start with a blank slate and bring something into the world that didn’t previously exist.

I draw many parallels as a programmer to an artist. Most artists don’t just think about getting strokes on a paper or the screen. They think about the larger composition of the work, generally tying all parts of an artwork together to create an enjoyable experience for a wide array of viewers.

When all of these things come together and are done well…

the developer experience (code design, readability, maintainability & testability)
the user experience (in terms of intuitiveness, functionality, and overall happiness)
the management experience (analytics, including tracking what’s working and what isn’t for continual improvement, as well as scalability for future state)

This is when I get the true feeling of having created a masterpiece. Similar to an artist stepping away from their work to admire the hours of dedication and thought behind it for a moment, I feel the same way when everybody has a good, consistent experience with a solution I’ve developed.

Full creative freedom

I love the fact that programming gives anybody the ability to create whatever they desire. Think of it like having an infinite set of tools in your belt, giving you (and others) the opportunity to create astonishing, sometimes ridiculous things.

We often spend more time than necessary trying to get existing technology to work the way we want. There are plenty of tools that already exist, but if you’re looking to supercharge your productivity and find a workflow that performs the way you expect with results tailored for your experience, it can be sometimes better to start from scratch and develop your own solution.

More than anything, though, I love how creative some programmers can be. Here are some examples of just how creative you can be with programming and automation:

A Ruby program that generates 128 different programs in various languages, circling back to the original Ruby implementation (quine-relay)
You’ve heard of base 2, base 10, base 16… but what about base 131,072?
A programming language where the entire syntax consists of just emoji, aptly named Emojicode.

Why do these projects exist?
Why not? 🤠

Making people happy

Forget users, I want to make real people happy through software. With great power comes great responsibility. Your code has consequences in the real world, and that’s a privilege not to be taken lightly.

At some point, somebody besides you will use the programs you write.
Real people use the programs developers make. Similar to how real people use the buildings that construction workers build up. We expect those building to stand the test of time, no matter the demand.

Now more than ever, I’m inspired to create programs that make the world a happier, better place. It’s a bold mission, but it starts simple: thinking broadly about how a wide audience might interact with your logic.

There’s been too many times when I’ve used software, and it just hasn’t lived up to standards. You’ve likely had the same thing.

Imagine a food ordering app where you can’t submit your payment, the inability to progress in a learning management system, poor user design in your banking app causing a 20-second task to take 2 minutes; the list goes on and on.

These all lead to the same thing: a frustrating user experience. Beyond analytics and metrics leading to worse conversion rates for your product, put yourself in just one potential user’s shoes who might experience frustration. Multiply that feeling by however many users you’re serving, and suddenly the scale of the issue magnifies.

It’s not about being a good or bad developer, or implementing best practices. While these things matter, there’s fundamental design decisions you can think about; small wins you can implement and incorporate in your development workflow to increase user happiness, such as:

thinking about success/loading/error states for network requests
adding deterministic, automated test cases – testing your logic to ensure confidence when making fixes or shipping new changes
considering scale and performance when making changes, so things work great now, and continue to work well into the future

There’s no silver bullet to making users happy. However, I think putting real product users at the forefront of your mind when developing features or fixes to grasp sensibility and intuitiveness goes a long way to achieving that goal.

CSS layout & how to position elements on your webpage

Nevulo — Fri, 20 May 2022 01:54:01 +0000

One of the most fundamental requirements to creating a great website is being able to move elements around on the page, instead of having everything appear in one big blob in a corner.

Layout modes

If you’ve styled elements with CSS, you know that it’s essentially putting a bunch of properties and values on a selected element in just the right way to make things look the way you want. Add some color: red here, a dash of background: black there.

So, we know how to visually differentiate elements, including size, colour, etc., but how do we actually move an element to where we want, for the resolutions we want?

CSS comes baked with a bunch of different layout modes for adjusting the behaviour of elements so you can lay out your page the way you want.

Whether you need a grid pattern, a table, columns, and much more, you’ll just need to find the right layout mode for what you need.

It’s important to understand that different layout modes will affect the way elements display differently, and not all CSS properties will work across all layout modes.

The default layout mode is called “flow”, where elements flow down the page.

The `display` property

The display CSS property is used to set whether or not an element uses “block” or “inline” layout, and controls what layout child elements use, such as flow layout, or flexbox.

Different types of layout modes

Normal flow (default)

Normal flow is the default way webpages lay themselves out when you haven’t applied any CSS to change how elements appear. Elements will appear at the top of the document and stack downwards, each one appearing on a new line below the last, as space is needed.

Flexbox

The flexible box layout model is a one-dimensional box where content can be positioned and distributed across an axis (horizontal or vertical).

This is helpful if you want to display a collection of elements in one dimension, like all on the same row for a navigation bar for example, or in a list.

Grid

Whereas Flexbox works in only one dimension, CSS Grid layout, which you can consider a successor to Flexbox, works with two dimensions, and you can align elements into columns and rows.

The main advantage of Grid over Flexbox is that it’s much more suited for creating responsive, collapsible layouts that work in a more predictable way.

Positioning with the `position` property

If we want to shift elements without affecting other elements on the page heavily, such as shifting a button a little bit to the left, positioning is perfect. Use the top, left, right and bottom properties on an element with units as values to move the element.

Relative positioning
- Used for moving elements relative to themselves, where they’d normally be
Absolute positioning
- Used for displaying an element in an exact location on the page, a certain distance from the edge of the page
- Other elements won’t be affected by absolutely positioned elements
Fixed positioning
- Similar to absolute positioning, but anchors or fixes an element in place relative to the closest positioned ancestor
Sticky positioning
- A hybrid between relative and fixed positioning. Element will act as if it were relatively positioned until it is scrolled to a certain threshold (e.g., 10px from the top of the container), after which it becomes fixed

Floats

The float layout will pretty much “pull” an element to either the left or right side of the screen, using float: left or float: right.

On a technical level, it’ll take the respective element out of the “normal flow” of the document, shifting it to the left, or right, until it touches the edge of its containing box, or another floated element.

Elements and text can still wrap around floated elements, unlike absolutely positioned elements.

Table layout

Specifically designed for creating tables with rows and columns, like what you’d find in Excel. Great for rendering table data and makes it easy to customise tables such as spacing between cells, alignment of elements in the cells, etc.

Table layout is also a desirable fallback for older clients trying to replicate something like Flexbox or Grid where it’s not supported (ie. email clients… 😡).

Diving deep into CSS for beginners

Nevulo — Thu, 19 May 2022 14:51:51 +0000

When designing and creating your own website, you’ll find yourself using CSS, a language for creating style sheets. Style sheets are used to describe the presentation of HTML documents and how elements get displayed.

CSS and styling elements really is the backbone for a lot of user experiences visually speaking; raw HTML will only get you so far.

This guide is top-to-bottom (mostly) explanation about what CSS really is, how it’s used, and common concepts and properties to understand, so you can make your own beautiful webpages.

What is CSS, and what is it used for?

CSS stands for “Cascading Style Sheets”, which is a mechanism for adding style to web documents, such as adjusting fonts, colours, spacing, layout, and much more. (We’ll get back to that “cascading” part soon!)

CSS is built up on “rulesets” which target elements in a HTML document through selectors. Selecting an element to be styled looks like this:

body {
  background: black;
}

This snippet would select the body element, and turn the background to “black”. body can be replaced with any element you want to select, and then you can add declarations through properties and values inside the curly braces.

This is what your average HTML element looks like under the hood:

This is known as the “box model”. Abstractly speaking, when making a website, you’re essentially structuring and styling numerous boxes.

You’ve got the actual size of your element (in this case, 750 pixels wide by 150 pixels tall), then padding on the outer edge of the element to increase its internal size.

The border wraps around the padding (the space inside the element), and on the very outside is the margin (the space outside the element).

Adding CSS to a HTML document

There are a few ways to include CSS styling in a HTML document, but the two most common methods are:

creating a .css file with all of your rulesets, then referencing that CSS file as a stylesheet in the <head> of your document

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

including CSS rulesets directly in the HTML document in the <style> tag, also in the <head> of your document

  <style>
    .class {
      color: pink;
    }
  </style>

Creating & building up rulesets

When styling any element through CSS, the foundation is built up of “rulesets”, which include a selector to access an element (or multiple that meet the requirements of the selector) to be styled.

After the selector, everything between the curly braces is known as a “declaration block”, which can contain one or more declarations. Declarations are a key/value pair, consisting of the CSS property as the key, and a value for the property.

Selecting an element

There are a few ways to “select” an element to be styled in CSS, depending on your requirements. You can find a full list of selectors here.

Element type selector (element)
- Selects all elements that have the specified node name
- input { background: red; } will match any <input> elements on the page, making the background red
Class selector (.class)
- Selects all elements that have a class matching the selector
- HTML elements can have a class attribute, including a list of “classes” delimited by spaces
- An element in the document like <h1 class='bold'></h1> could be selected in CSS through .bold
ID selector (#id)
- Selects all elements that have an id attribute matching the selector value
- HTML elements can have an id attribute
- An element in the document like <div id='article'></div> could be selected in CSS through #article

Once you’ve selected an element, you can start adding declarations to change its styling. Note that if you don’t select a valid element, there will be no effect. You can use “Inspect Element” to see what styling is applied on an element to troubleshoot these issues.

Common properties for declarations

Some inspiration for understanding what you can style through these “declarations”. You can see an entire list of CSS properties here.

Colours

color: adjusts the foreground colour of an element. The colour of text elements will depend on the color value.
background: adjusts the background colour of an element

Fonts

font-size: changes the size of font for text, specified in pixels or other units
font-family: defines the type of font used for the text in the element (e.g., Arial, monospace font, etc)

Structure

display: used for adjusting the layout mode elements use, for positioning and structure
padding: adds internal space to an element, making it appear bigger
margin: adds external space around an element, pushing other elements away
border: applies a customisable border around an element

Sizing

height: adjusts the height of an element, specified in pixels or relative units
width: adjusts the width of an element, specified in pixels or relative units

Digging deeper in core concepts

Cascading

They don’t call it “Cascading Style Sheets” for nothin’!

The cascade describes how CSS declarations and rulesets are applied to a HTML document, including how conflicts between two declarations on the same element get handled (i.e., one ruleset sets margin-left to 0, but another sets it to 12px), and which gets priority.

It controls the order in which CSS declarations are applied, which is dictated by three other concepts:

Importance
- Where is the declaration applied? Browsers have default styling which is applied by default, but has the lowest importance, meaning they’ll be overridden.
Specificity
- How “detailed” is the selector that the declaration is in? Less specific selectors will take lower priority in being applied.
Source order
- Last resort, when two declarations affect the same element in the same way: which was declared first within the file?

Inheritance

Inheritance controls what happens if there’s no value for a specific property on an element. Essentially, if you set a CSS property like color on an element, any child elements will inherit the colour from the parent unless child elements have explicitly defined a colour.

There’s a distinction between inherited and non-inherited properties; non-inherited properties (such as border) will use the initial value for that property, not to be confused with the browsers default style sheet. All properties specify an initial value.

If you want to explicitly define that an element should inherit a property from its parent, almost all CSS properties include an inherit value (e.g., color: inherit), which will set the value of the property to the computed value of that property in the parent. This works for both inherited and non-inherited properties.

Specificity

The more specific a selector is, the more precedence it has over other declarations. Specificity is a weight given to all declarations, determined by 3 factors:

the number of element types in the selector
the number of classes in the selector
the number of IDs in the selector

If multiple declarations have equal specificity, the last declaration found in the CSS gets applied to the element.

Improve your code through code reviews

Nevulo — Thu, 05 May 2022 19:01:13 +0000

Getting a second opinion matters.
When you’re shipping new features to production, it’s important that all the requirements get implemented and everything works properly under lots of different situations. Otherwise, users are going to have a poor experience.

I can personally say it’s too easy for one person to miss simple problems that lead to bugs. It’s helpful to have more sets of eyes looking at the solution and seeing if it’s optimal and what comments/suggestions could be applied to improve it for everyone.

Code reviews have helped a lot in my career to catch mistakes, typos or other major/minor bugs when writing code to be used by thousands.
But, what is a code review, why is it helpful, and how can we incorporate code reviews in a project?

What is a code review?

A code review is where engineers in your team can inspect the code you’ve submitted to be shipped to production, and collaborate on comments and suggestions, before it goes live.

When you’re making any change to a codebase, typically you’ll publish those changes remotely to a repository, like on GitHub.

You can commit changes directly to the main branch, which represents the most up-to-date copy of the code, and usually, whatever is on the main branch eventually gets sent to production, meaning real users see that change.

Instead of committing directly to the main branch, we can create a new branch off the main branch and just push the changes relevant for one piece of work.

When your changes are ready to go to production, you’ll create a “pull request”, which is literally a request to pull your changes into the main branch.

In this request to introduce changes to the repository, others in the organisation get the chance to view the changes you’ve made, write comments on the changes, or provide suggestions for alternative solutions.

Reviewers can also:

Approve a pull request, meaning the changes to the code look good and this is ready for production!
Request changes on a pull request, meaning the changes to the code aren’t working as expected/correctly, and things need work
Comment without explicit approval, meaning the reviewer hasn’t approved or denied the pull request but has left comments

Why do code reviews?

The more eyes, the better

Giving other engineers the ability to review your code gives them the opportunity to:

spot potential problems or bugs before they ship to users
suggest improvements on performance so features scale properly
maintain project quality and makes sure everybody agrees the code is readable and acceptable
test changes before they go live, catching issues early

No matter the size of the change, developers in a code review should look to review the quality of the changes coming in and think about potential improvements.

Code reviews help you and your team grow

Exposing yourself to code as much as possible is a surefire way to expand your vocabulary, identify anti-patterns, and ultimately help you and your team write better code.

Offloading the review process to other developers, who can offer different perspectives, helps teams remain agile and keep releasing new high-quality features quickly.

It’s also a great opportunity for others to learn new techniques or get suggestions to improve code quality over time.

Giving others opportunity to comment

Other engineers can comment on readability, syntax, and other aspects of the code to improve the quality. These might be small changes like flipping an if statement to improve the logic flow, or adding an early return.

Beyond reviewing just code and its literal syntax, code reviews also offer the opportunity for others to voice feedback on other aspects of changes like styling or functionality if something doesn’t seem right.

Best practices for code reviews

Develop guidelines and standards for reviews

Atlassian and Google have written about what reviewers actually look for in a code review; things like architecture, functionality, readability, security, and much more.

Ask questions like:

Does this pull request do what it says it does?
Does it meet all the requirements laid out for this work?
Given this code change, how will this affect users?

Make sure changes are adequately tested

For particularly complex changes, automated tests help assert that all the requirements are being met under certain conditions. It will provide more confidence to teammates being able to see that all tests are passing in the CI/CD pipeline. This is known as “test coverage”.

To learn more, read about how testing your software is just as important as writing it.

Keep changes short, simple and readable

Cisco has reported that performance is likely to drop in developers reviewing more than 300-400 lines of code, and it’s well documented that reviewing for long periods of time leads to worse performance.

Testing your software is just as important as writing it

Nevulo — Thu, 05 May 2022 18:52:55 +0000

What do we mean by “testing” software?

Testing software involves examining the behaviour of software, and ensuring that the output is what you’re expecting.

This can be done manually, where a real person tests specific cases searching for defects, or automatically, through the use of testing tools and writing code for test cases.

Each method involves creating some expectation that is widely accepted on what should happen, and then executing a series of steps to get to the desired state and ensure that the software is working correctly after the steps are complete.

Different types of tests

Unit tests

Unit tests involve assessing the behaviour and asserting the output of individual “units” or sections in source code. Units are small components, functions, or modules in the code. Importantly, they are isolated bits of code to be tested and verified to build up to testing bigger functionality.

As an example, you might have a relatively simple function that just adds two numbers:

function add(a, b) {
  if (!a || !b) throw new Error("Error!");
  return a + b;
}

Unit tests may look something like this (with the help of a testing library):

it("should add two numbers", () => {
  const result = add(1, 0);
  expect(result).toEqual(1); // should pass
});

If we ran the test above, it would be failing at the moment. Why is that? Adding 1 + 0 should equal 1, right? Unfortunately, the code above has a bug. Have you spotted it?

By checking using the logical “not” operator to check if either number is valid at the start of the function, JavaScript is checking if a or b are “falsy” values, and 0 counts as a “falsy” value, making the function throw an error.

Asserting each unit is working as expected under different conditions or edge cases means we gain confidence whenever using it anywhere in our project.

Over time, you’ll have hundreds of units tested in your code, building up confidence in each little part of your code, ensuring changes won’t affect functionality in any of the other units.

Integration tests

Integration tests are where different units, modules, or components in software get tested together and ensuring they work as intended when connected to each other.

For example, a website that involves shopping will require the user to add an item to their cart and sign in. You could add an integration test to ensure that the user can both add an item to their cart and sign in, in sequence, as expected.

End-to-end tests

End-to-end tests ensure that the entire user journey; their experience from the beginning to the end in the application behaves as expected. It’s meant to simulate a real user scenario and validating the software works consistently when provided certain inputs.

If you had to verify the functionality of user account creation and deletion, and everything in between, you could program a test runner to run your application and perform the individual actions you’ve defined in code, asserting each step got executed correctly.

Why is testing important?

Writing code is crucial, but we also care about making sure end users get a good experience. Manual and automated testing can be very useful in catching bugs early in the development process, saving time and money for your team and making sure users have a lower chance of a poor experience.

Confidence, now and for the future

Through continuous integration, you can create a pipeline that ensure builds cannot be published to production if tests are failing.

One or more tests failing often indicate something is wrong with a proposed change. If all tests pass, it gives confidence to you and teammates that the changes implemented will work as expected and not break other areas of the experience.

Get alerted before potential bugs go out to users

Tests allow us to assert the behaviour of software and functions: we tell the tester what should happen, and it compares the expected and actual output. If users don’t get what they’re expecting, they have a worse experience.

Writing test cases allows developers to run software with mocked, fake values to test how they’ll behave under different conditions.

If tests are failing or returning unexpected values, it’s a good indication that there’s a problem somewhere that could potentially affect real users, leading to a bad experience.

Improves code quality

Testing is important for keeping code quality and maintainability high. Having high test coverage ensures developers don’t need to spend time resolving issues with existing code, and gives confidence around the impact of changes when creating new features or fixes.

Not having tests is a ticking time-bomb

I want to throw in a personal anecdote here. I can tell you personally that often, not having tests will kick you up the arse later down the road.

The number of times I’ve said “I wish this had tests on it, and we would’ve caught this bug” is higher than I’d like to admit.

The truth is, software is unpredictable, and even though you might have a simple operation, or you are 100% sure everything works as it should; there’s no telling how external factors might change how your software behaves. Having automated tests surfaces more information to you quicker.

As an example, let’s say you’re using an external dependency for calculating time differences. The maintainers might make a breaking change, and if your project updates the dependency, your software isn’t working correctly, and you’ve got no indication of it.

How to write optimal tests

Create a strategy around testing

Documenting a plan around what type of testing you need and what components are priority to test is helpful for you and others to get a sense on how test coverage works in your project. Some people might be aiming for 100%, but for some projects that may not be feasible.

Determine which types of tests are right for your software. If you’re making an application used by many people, it might be worth adding end-to-end tests to assess the core experience automatically and pick up potential issues.

Automating tests where possible

Manually testing can chew into resources and time, and it’s easy to forget things or still have things go wrong. Automating tests in code and setting up tools to interact with your application programatically can save a lot of time and allows you to catch problems early without much effort.

Depending on what language or framework you’re using, you might be able to use an external dependency to assist in asserting your code programatically.

Avoid “flaky” tests

A flaky test is an assertion on code that fails to produce the same result each time the test gets run. This leads to false positives (or sometimes false negatives) where code that is not problematic may cause a test to fail, or code that is problematic may not be caught due to a flaky test failing often.

Flaky tests may take a long time to eventually surface and can block the continuous deployment, making feature delivery more complicated and slower than it needs to be and causing headaches for the development team.

They’re typically caused by false assumptions in data being returned, race conditions, or insufficient mocking of calls to external systems to ensure they’re not influencing tests.

Test-driven development: red, green, refactor

The idea behind test-driven development is that you actually write the tests first based on requirements, making assertions in different scenarios, and then add the code to make the tests pass.

The tests will fail at the start (red) because there’s no logic. You begin to add the logic pertaining to the requirements until all tests are passing (green). The last part involves refactoring the code, so it is optimised for production and readable for others.

Different ways to copy an object in JavaScript

Nevulo — Thu, 21 Apr 2022 15:28:26 +0000

Copying any data, like an object, is a problem every developer encounters at one point or another.

Here’s an example of the problem: you have an object stored in a variable called user which contains information related to a user in your application.

let user = { name: "Blake", age: 20 };

Let’s say the user wants to update their first name, but you also need to keep the data for what their previous name was, perhaps for an audit log.

How can you retain the contents of the “old” user but make the changes required for the “new” user?

You could store the users “old” name in a variable, but it becomes cumbersome when there are many changes you need to keep track of.

This is one example where copying objects comes in handy – when copying data to a new variable, we don’t need to mutate the original value directly and potentially lose data. We can safely store a separate copy of the object contents in another place, and work on that object.

There are a few ways in JavaScript to create a new object using the exact data from the original value. Keep reading to learn about any “gotchas” between these different methods.

Using object spread syntax or `Object.assign`

One of the simplest ways to copy an object in JavaScript is using Object.assign, which copies all properties from one or more source objects to a single target object.

In our case, we don’t really have a target object, as we want to create a new object as a clone.

So, we can pass in an empty object for the first argument (the target object), and pass in the object we would like to clone in the second argument (the source object(s))

let obj = { a: 1, b: "hi" };
let clonedObj = Object.assign({}, obj);
console.log(clonedObj); // { a: 1, b: "hi" }

A shorter way to do this is using spread syntax, which allows for object expressions to be “expanded”. One implication of this is that we can expand the key/value pairs from our original object into a new object, effectively making a clone.

const obj = { a: 1, b: "hi" };
const objClone = { ...obj }; // pass all key/value pairs from an object
console.log(objClone); // { a: 1, b: "hi" }

Essentially, the ...obj gets replaced with all the keys and values from obj.

Both methods are functionally identical, the only difference being that Object.assign sets the properties on the target object, whereas using spread syntax creates a new object – meaning that Object.assign would also trigger any setter functions on the object. This isn’t essential for many people, but an interesting thing to note.

Another interesting thing to note is that both methods only perform a shallow copy. What exactly does that mean?

const user = {
  id: "abc123",
  // an object inside of an object
  name: {
    first: "John",
    last: "Doe",
  },
};

const userClone = { ...user };
userClone.id = "newId";
// Note that the original object is not mutated when modifying primitive values like a string
console.log(userClone); // { id: "newId", name: { first: "John", last: "Doe" } }
console.log(user); // { id: "abc123", name: { first: "John", last: "Doe" } }

// When modifying an object inside of a shallow copy...
userClone.name.first = "Johnny";
// ...the original object will also be mutated
console.log(userClone); // { id: "abc123", name: { first: "Johnny", last: "Doe" } }
console.log(user); // { id: "abc123", name: { first: "Johnny", last: "Doe" } }

A shallow copy of an object means that when you mutate non-primitive values (like the name object), it will mutate the clone as expected, but also the original object.

This is because any values stored as an object are reference values, meaning that there’s a reference to that object stored. So, when you copy an object with other objects inside, you’re really copying an object with references to those other objects.

This doesn’t apply with primitive (simple) values like numbers and strings. When making a shallow copy of an object with other objects inside, you need to be wary of making sure you’re not mutating the original object unintentionally when mutating the clone.

Converting an object to a JSON string and parsing it back

This method leverages JSON (JavaScript Object Notation) which can hold information about key/value pairs and has support for most basic data types you’d need.

The JSON.stringify method allows us to pass an object in the first argument, which is the object to convert to string format. Once we have converted our object to a string, we can take that string and parse it back to an actual object using the JSON.parse method.

let obj = { a: 1, b: "hi" };
// create a JSON representation of an object in the form of a string, convert back to object
let objClone = JSON.parse(JSON.stringify(obj));
console.log(objClone); // { a: 1, b: "hi" }

Unlike the previous method, this method of cloning does support nested objects better, creating a “deep copy”, meaning all values get dereferenced from the original object. With a deep copy, there’s no worry about mutating the original object.

However, because JSON only supports a limited subset of data types in JavaScript such as booleans, strings, arrays, etc. but not things like Date objects or Maps, these will not be converted properly when creating the clone unless you take additional steps to transform the incompatible values in the object first to something JSON can understand, and then transform them back to the desired data type you want in JavaScript.

On top of this, JSON.stringify won’t be able to convert a value to a string if the value references itself. This is known as a circular reference, and trying to convert an object that references itself would result in an infinite loop.

Using `structuredClone` global method

structuredClone is a fairly new, global method, meaning access it from anywhere in our code. The benefit of structuredClone is that it was made for this purpose; “cloning” or copying an object.

As of the writing of this post, the structuredClone method has been implemented by major browsers in recent versions (including Node 17+).

// Create an object with a value and a circular reference to itself
let original = { name: "test" };
original.self = original;

// Clone it
let clone = structuredClone(original);

console.assert(clone !== original); // the objects are don't have the same identity
console.assert(clone.name === "test"); // they do have the same values
console.assert(clone.self === clone); // and the circular reference is preserved

Unlike the JSON.parse/stringify method, this does support circular references, and it preserves most values and data types.

Of note, structuredClone will throw an error when cloning Error types or DOM nodes. If your object contains functions, these will be quietly discarded from the result. Read more about features and limitations of structuredClone.

For most cases, though, this will create a deep copy of whatever objects you throw at it.

How to use the command line

Nevulo — Thu, 21 Apr 2022 15:22:14 +0000

Whether it’d be in movies or over the shoulder of your “hacker” friend, it’s likely you’ve seen the mysterious command-line interface at one point or another. A window on the computer purely used for typing commands and getting back results in text.

Being able to use the command line with confidence opens some interesting doors and allows you to navigate your computer and automate tasks more effectively and efficiently.

But, if you’re starting out, it can feel like a steep learning curve coming from purely graphical interfaces. After all, when opened, all you’re left with is a blank screen and a blinking cursor. What are you supposed to write? What does it help us accomplish?

First, what is the command line?

The command line, also known as the command prompt or terminal, is ultimately a window that lets us enter text to input commands, and can display the output of commands back to us in the same window.

It’s like having a text message conversation directly with your computer, where you can give more explicit instructions to the computer than you could through a normal graphical interface, or using a mouse. It’s essentially a different “mode” of interacting with your computer; anything you could typically do through a graphical interface, you can likely do on the command line as well.

The command line is also at the heart of a lot of automation. This allows us to write programs through scripts, a set of instructions to be carried out by the computer in a logical order.

Why use the command line?

The main benefit from using the command line is providing a consistent means of performing actions on your computer and the ability to automate tasks. This is how your computer does a lot of the tasks it needs to do “in the background”.

Your software may use the command line to perform certain tasks such as reading/writing files, changing system preferences, or running other programs.

Imagine if we wanted to do a simple task like creating a folder, but we had to specify exactly where the mouse should be, and when to press the left or right mouse button. Considering the fact that everybody has different screen resolutions, different operating systems, and potentially different themes across systems, it’s pretty difficult to get it working for everybody in a simple way.

To create a folder through the command line, we can just write:
mkdir [folder name]
(m a k e a directory, a folder, where the name is [folder name])

Simply put, utilising the command line can often provide more efficiency when performing complex tasks. Even though it can seem scary, it typically provides an easier and quicker way for us to do things like run applications that we make, test our software, and much more.

Many servers run operating systems with a foundation called “Unix”. These systems are characterised around modular design (known as the Unix philosophy).

The idea is that the operating system provides a set of simple tools/programs, each with a well-defined function or purpose. You can construct a pipeline which feeds the output from one command to another, which can be combined into complex workflows using a shell like Bash.

How do you use the command line?

The best way to start learning to use the command line is just using it.
To start using the command line, follow the instructions, depending on which system you’re using:

Windows

The “command prompt” is equivalent to the command line, and it can be launched just like any other program on your system. To start the Command Prompt:

Tap on the Windows logo in the taskbar
Start typing “cmd” (executable name for command prompt), click the first result. You can also search directly for “Command Prompt”. Optionally, right click and select “Run as administrator” to run with administrator privileges (take caution!)

macOS

Launch the Terminal just like any other program on your system:

Open Spotlight search (Command + Space)
Type “Terminal” and click the first result.

Linux

There are a few ways to open a terminal in Linux, but the quickest way is typically through a direct keyboard shortcut: Ctrl + Alt + T.
If the keyboard shortcut doesn’t work or is hard to remember, you can also launch the Terminal just like any other app on your system:

Press the Super key (acts as the “Windows” key on most keyboards)
Start typing “Terminal” in the search box at the top.

Anatomy of the command line

Prompt `>`

The very first thing you’ll see when booting up the command line/terminal is often an arrow, or some sequence of characters behind the text you’ll be entering. This is known as the “prompt”.

It literally prompts the user to act and type a command. It indicates the fact the system is ready to take commands. Don’t be alarmed if yours looks different, or if you’re not sure what everything means.

Executables and commands

An executable file, command, or program is usually the first step in performing any kind of action on the command line. Your system has hundreds, probably thousands of executables installed by default for performing common tasks, such as modifying files, running scripts, etc.

In the image above, echo is a command entered after the prompt. The purpose of the echo command is to literally echo back what you write; whatever you insert as arguments after the echo command will be printed back in the command line.

“echo Hello world!” would display “Hello world!” in the command line after you press ENTER.

Arguments

Executables can accept “arguments” or “parameters” – these are essentially inputs provided by the user, so we can get the result we want.

If we want to remove a specific file on our system, we can perform the action through an executable (in this case, rm which removes files), and we can specify the file to be removed in the arguments:
rm hello.txt

The command above would remove a file called “hello.txt”, if it exists.

Options

Commands can also take what are known as “flags” or “options”, which are intended to modify the behaviour of the program in some way.

For example, the echo command mentioned earlier has one option you can choose to pass in: -n. The purpose of this option is to change the behaviour of echo, so it doesn’t print a new line after printing the user input to the command line.

Getting help with commands

As you’ve probably noticed, the command line is a lot more focused on functionality over user experience, and it’s not super apparent what some executables/commands do on the surface, such as rm or mkdir. Thousands of commands are out there, and it’s challenging to remember what most of them do.

If you need to get further details on what a certain command does, the easiest way to do this is often by typing man [command] in the command line. man is an executable used for displaying the online manual pages for system commands and other definitions.

Some executables also include a -h or --help option to give more information about what’s available to you or what certain arguments do.

git is a great example of this; if you type in git --help, you’ll get a list of common commands you can use within the git executable. If you type git branch --help, you’ll get even more detailed instructions about how to use the git branch command specifically, and what arguments/options are available.

The methods listed above may be a bit verbose in some cases, and might not help you if you want a certain command explained in a simple way. You can often use search engines to help find better definitions for commands, or if you’re trying to find out what command you need to use for a certain operation.

As a rule of thumb (won’t apply to everything), the names of commands are typically just shortened versions or acronyms of the function they perform. If you want to m o ve a file, the command is mv, c o pying a file can be achieved through cp, etc.

A tool I’ve used lately is shell.how, where you type in a command, and it’ll try to break down what each “part” of the command means.

⚠️ A word of warning

As I’ve talked about before, computers are very literal-minded. They really have no distinction between “good” or “malicious” instructions – they just do what we tell them to do.

Thus, it’s important to be cautious when entering commands directly in the command line. Unlike graphical interfaces, executing commands often comes with no warning or ability to undo, so you should avoid executing commands if you’re unsure of what they do.

The command line comes with a lot of power. It exposes low-level access to different parts of the system, so even innocuous, short commands can completely break your system or cause data loss if not used carefully.

I encourage you to do research if you’re unsure about what a command is supposed to do or why you’d need to run it. Stay safe!

What’s so great about performance?

Nevulo — Fri, 08 Apr 2022 01:07:51 +0000

Performance can make or break great software. If you’ve got a great app, but it runs at snail’s pace on my device, rendering it unusable, I may as well not even have it installed.

I don’t like to wait around for no reason. Most users don’t like to wait. It’s well documented that users will drop off quickly if your site or application loads slowly because “users” are actually real people with real lives, wanting to get stuff done.

As a developer, performance can be difficult to maintain, especially when there are other priorities. The speed of your application probably doesn’t rank as one of your highest priorities.

Usually, I’ve found it’s beneficial to prototype a solution in code, even if it’s “sloppy” or not as performant as it could be. It’s hard for us to get the grasp of exactly what the “cost” of running all of these instructions for the computer is.

So, why does it matter that we optimise for performance?

Why does performance matter?

Having a speedy app or website isn’t just a fancy badge to show off. Better performance leads to happier results for everybody involved, whether you’re making open-source software, working in a business aimed at helping people, or working on personal projects!

Performance for success

One of the funny things about performance is the fact that we take it for granted. We don’t want fast apps, we expect fast apps, and when we don’t get what we expect, the user experience degrades.

HubSpot has written about how page load times impact conversion rates for businesses, and it makes sense, as there’s a lot to fight for. Users are more than happy to go elsewhere if their experience is not satisfied, and speed matters a lot in user retention and user engagement.

Performance matters at scale. Imagine you’ve got 50 thousand users who have your app installed, relying on it to work properly, every time, and importantly, fast. If you’ve got an algorithm which takes 1 second to process something, and it has to run multiple times every second, you’ll quickly drain your resources, and upwards of 50 thousand real people will be having a bad time.

In a business environment, better performance can translate to higher profits and conversions, and ultimately benefit employees and users.

Performance for the users

It all comes back to the main people running the show; the users. Everything crumbles down if your core user experience is limited by performance issues, especially when things take a substantially long time. You’ll be lucky to have a user on board longer than a few seconds if you leave them waiting.

When your software is fast, you’re helping users get through their tasks and their day faster. It gives users incentive to come back as well. If they know your software is reliable and highly available, there’s no need to actively search for alternatives.

Improved performance means increased retention and engagement. But users are not statistics – at the end of the day, these are real people wanting to use your software for whatever they need.

Performance for the developers

As developers, we make code to offload work, not create more of it. So, by teaching yourself to create elegant, performant software through planning and testing, it ensures you won’t have to go back and fix it later if something goes wrong.

Sometimes, improved performance comes at the cost of readability. There are things you can do to ensure you keep your code quality high, like abstracting code or comparing and contrasting multiple alternatives.

Improving your performance

Find out if you’ve got a performance problem

Technically, every app could be faster, but you need to identify whether it should be faster. There’s only so much benefit in squeezing as much performance as possible out of a system, and there’s no point resolving a problem if you’re not sure whether you have it.

Identify whether performance is a pain point for users or yourself through testing and feedback. If you’re aware it is time for change in the speed department, make a plan of attack for places of priority for where you want to improve performance in your software, usually based on areas of high or crucial usage.

Common testing techniques for identifying slow points in your software include:

High load/stress tests
Testing on different devices and workflows
Getting user feedback if possible

Document/record areas of “slowness”

Documenting and recording areas of perceived slowness or dropped performance is an important step in knowing what you need to fix, and allows you to map out different areas or features in your software that are slow so you can identify common patterns or correlations. This will help guide you to fix the problem faster.

Let’s say currently in your app, when you tap on the “sign in” button, it takes 1.5 seconds to register that press. That’s pretty slow for a lot of users.

Document the amount of time it takes now (problem state), as well as goals and requirements to getting to the solution (final state). Find out what is acceptable. Is 0.5 seconds good enough for you or your users? If not, keep iterating through until you think of an end state that meets your requirements.

Reproduce the problem & implement a fix

Once you’ve identified and documented the performance issue, at some point you can try and reproduce the problem, to help you fix it and give your users the best experience possible.

If you can reproduce the issue in a consistent series of steps, you can almost walk through your code base as the user progresses through your software. If there’s a bug that always only happens after pressing a button, it’s worth looking into the logic for that touchpoint as an example.

Fixing the issue can either be the easiest part of the process, or take you the rest of your days. Regardless of what solution you use to fix the problem, it must meet the requirements you set out when documenting the issue, otherwise, just focus on providing a smooth experience for the user.

Conclusion

To answer the question; what is so great about performance?

Users feel performance.

Your users are the foundation to success and keeping them happy will keep you happy. If your software works fast, users work fast. Moving business objectives aside, helping users is what we care about.
Performance helps businesses be more successful.

It’s not just a headline, more performant applications (user-facing or internal) lead to better performance in metrics like conversion rates.
Helping developers for now and later

Not only do developers get the benefit of feeling reassured that things won’t break now, they’ll be able to rely on the scalability of their algorithms for the future. Less time is spent maintaining existing systems and more time is spent being productive.

Analyse the cost of your algorithms

Nevulo — Fri, 08 Apr 2022 01:06:06 +0000

When developing software, you get to know that some things take longer than other things. Like, reading a file taking longer than adding a few numbers. Or, getting 10 thousand users in a database over reading from memory.

These are helpful things to know, but we’re also aware that most of the time, it doesn’t matter. Read a file here or there, get those users from the database, it’ll take under a few seconds usually and that’s all we care about.

When developing software for a production environment, we need to think about scale and future state.

If you have 10 thousand users now, what if you have 1 million users in 2 years? An operation with 10 thousand users might take 2 minutes, but with a million, it’d take a couple of hours. What are the implications of this?

Time and space complexity

In computer science, “complexity” is defined as the number of resources the computer needs to run an algorithm. It’s difficult to get an exact estimate on how long an algorithm will take, or how much space it’ll use, typically we’re just interested in how the function grows over time as the input grows.

As a reminder, an algorithm is a set of instructions for the computer that you write in code, used to solve a problem or perform a computation.

“Time” complexity relates to the amount of time it takes to run an algorithm to completion. “Space” complexity relates to the amount of memory an algorithm uses to complete its tasks.

As always with any inputs, it’s important to consider how different values could affect your algorithm. There are three different types of notation for describing the limiting behaviour of a function as the input grows:

𝑂-notation (pronounced “big oh”): describes the asymptotic upper bound of execution time, the most amount of time required for the function to run (a worse case scenario)
Ω-notation (pronounced “big omega”): describes the asymptotic lower bound of execution time, the least amount of time required for the function to run
Θ-notation (pronounced “big theta”): describes the asymptotic tight bound for execution time, essentially, the intersection of O(f(n)) and Omega(f(n)) (datapoint is in both 𝑂 set and Ω set)

The most significant notation we’re here for is big-O notation – good for measuring the worst-case execution time as input grows for a function.

Big-O notation

Big O notation is a mathematical notation used in computer science for analysing algorithms for efficiency and describes the complexity of an algorithm/function.

Big O notation looks like this: O(n).
O represents Big-O notation, and the n inside the brackets is a variable that represents the size of the input given to the function.

An algorithm with a Big-O of O(1) means the function will take the same amount of time to complete, no matter the size of the input. One element, 1 billion elements; the time is constant.

An algorithm with a Big-O of O(n) means the time it takes the function to complete grows linearly with the size of the input. Typically, this is an operation like iterating through a list; if you have 1 item in the list, it’ll take less time than 1 billion items and the time taken grows as the items in the list grows.

A worst-case scenario Big-O is O(n²) (Big-O of n to the power of 2). These are the worst performing algorithms and typically involve repetition, such as looping through 100 users, and for each user, doing 100 more operations. 100 users * 100 operations equals 10,000 total operations.

What is Big-O notation used for?

Some functions are more complex regarding time or space than others, and we can use Big-O notation to represent how the resources an algorithm use change as the input changes.

Imagine you have a function which goes through all users, and sends a notification every week.

In your function to solve for requirements, you need to read each user’s document in the database.

Each user’s document takes a fraction of a second to read.
But, if you’ve got 50,000 users, 0.1 seconds * 50,000 users equals 8 minutes in total just to read each users document!

If you are running on infrastructure that has runtime limits, or simply don’t have enough resources, your function will stop.

To prevent problems like these from happening early, you can use Big-O notation to get information about how the resources your algorithm uses grows, as the size of the input given to the algorithm grows.

When to aim for lower execution time

If you have an algorithm or process that you run manually, or only runs once every so often (say, once every few days) and doesn’t involve many operations – worrying about execution time is probably not a top priority.

Typically, unless you’re having issues, or you want to future-proof your algorithms to work as input expands (users, documents in a database, etc), optimising for execution time in cases where the algorithm runs infrequently can be considered a bit of a waste.

If your algorithm needs to run multiple times per second, or even more frequently, it must run efficiently or things might get blocked, leading to a bad experience for users. If your algorithm involves a large number of operations, this means it might take longer to complete.

Where possible and sensible, anywhere you have a user interface, even internally for employees, after getting things functional, it’s wise to prioritise performance and maintainability.

How to design algorithms with lower execution time

I don’t personally design functions or algorithms with time/space complexity in mind (although it’s not a bad idea).

Instead, there are some common practices you can implement while planning in your head and writing code to prevent things from scaling up too fast.

Think about how you’re going to solve the problem

Before starting to implement a solution, try to build a mental model of the steps the computer would need to take to achieve the result you want. There are plenty of ways to solve a problem, usually, and it’s helpful to think through multiple ideas and compare complexity between how you implement an algorithm.

Typically, nested loops or repetition will add complexity to an algorithm.

const test = Array.from({ length: 10 }).fill(1);
for (let i = 0; i < 10; i++) {
  test.map((a) => test.map((b) => a + b));
}

In the example above, we first define an array with 10 elements, all as the number 1. There’s a for loop that runs the code inside 10 times.

The code in the for loop says, for each element in test, replace it with whatever is returned in the anonymous function. The return value is another map to go through each element in test.

In the end, in one iteration of the for loop out of 10, we did 20 operations. In 10 iterations, that’s 200 operations.

Try to think through each individual step the computer takes, even through internal methods like map as it will branch off more operations to run.

Optimisations

Usually, you don’t need to worry about making serious low-down optimisations, like picking between forEach or a for loop, or stressing over down-to-the-millisecond differences in speed. If you’re not sure if you need to optimise, think about maintainability first.

If you’re working in a critical environment where every fraction of a second matters, you’ll likely look towards squeezing every last bit of juice you can out of the language you’re using.

For example, in JavaScript, with the case of forEach vs for loops, for loops win out by a little making them preferable to use in cases of high performance. Usually, though, differences are negligible.

You’ll want to look towards third-party libraries and your solution in a bigger picture, and if there are small optimisations to be made to reduce computation time.

DEV Community: Nevulo

Learning how to unblock yourself in projects

What does being blocked or impeded look like?

External blockers

Internal blockers

Personal blockers

Actionable tips to unblock you and your team to keep moving forward

Identify if you’re blocking yourself

Allocate strict time/effort resources, like a budget

As a last resort: work through a different problem

Top tools to help you stay productive as a developer

Terminal — iTerm

IDE — Visual Studio Code

Note-taking — Notion

Calendar — Cron

To-do tracker — Todoist

Design — Figma

API Tooling — Insomnia

Conclusion

Why learning basic programming is important

Abstract & logical thinking

Productivity & the power of automation

A more in-depth understanding of technology

Okay, I get the idea. Where do I get started?

Why do I code?

Why I started coding

Why I love coding today

Why coding tickles my brain in just the right way

The thrill of hard work paying off

Bringing art to life

Full creative freedom

Making people happy

CSS layout & how to position elements on your webpage

Layout modes

The display property

Different types of layout modes

Normal flow (default)

Flexbox

Grid

Positioning with the position property

Floats

Table layout

Diving deep into CSS for beginners

What is CSS, and what is it used for?

Adding CSS to a HTML document

Creating & building up rulesets

Selecting an element

Common properties for declarations

Colours

Fonts

Structure

Sizing

Digging deeper in core concepts

Cascading

Inheritance

Specificity

Improve your code through code reviews

What is a code review?

Why do code reviews?

The more eyes, the better

Code reviews help you and your team grow

Giving others opportunity to comment

Best practices for code reviews

Develop guidelines and standards for reviews

Make sure changes are adequately tested

Keep changes short, simple and readable

Testing your software is just as important as writing it

What do we mean by “testing” software?

Different types of tests

Unit tests

Integration tests

End-to-end tests

Why is testing important?

Confidence, now and for the future

Get alerted before potential bugs go out to users

Improves code quality

Not having tests is a ticking time-bomb

How to write optimal tests

Create a strategy around testing

Automating tests where possible

The `display` property

Positioning with the `position` property

Using object spread syntax or `Object.assign`

Using `structuredClone` global method

Prompt `>`