Software-Engineering

Introduction I’ve seen a lot of clamor over trying to “ace” interviews for software engineering positions. While interviews can definitely go well and poorly, there generally isn’t a prescribed “right way” to do something. In this article, we’ll cover how interviews are put together, and what they target. We’ll identify objectively “bad” interviews, and we’ll describe how good interviews work. Who Puts Together Interviews Interviews are generally put together by a team lead. Higher-ups want to give teams the agency for teams to do the filtering they want, so they stay out of that process. I’ve seen some interview processes where higher-ups get involved in a “meet and greet” fashion, so in a sense they retain some kind of veto power. “Boss is an institution of mistrust”. It makes them feel better. Let them have it. ...

Introduction When writing any kind of real world applications, “edge cases” arise - wrinkles placed into your beautiful applications which start off as simple if statements and later lead to great sources of confusion and kind of a dumping ground for all of the organization’s wacky needs. This later takes on the form of crushing technical debt and you’re wondering how your pristine application got here, and how you might avoid it on your next one. Fortunately it is avoidable through a simple technique called data modeling. ...

Function Composition Function composition is the act of treating functions like small lego bricks that you tie together. Composing simple, well known functions to achieve complex behavior is like having and advanced vocabulary used to discuss a complex topic. If you want to try some of this out, I recommend Ramda’s REPL for experimenting with different JavaScript features such as this. Bespoke: Average Here’s some code for writing an average function. It computes an average value from a list of numbers. For reference, an average is all of the numbers added together and divided by the number of values. ...

1 Introduction I’ve always heard the software engineering industry is a rapidly changing industry. One of the things that contributes to it (and not the other way around) is the frequency at which we abandon a pile of work and just start anew. I have not had good experience with this, and this post will go into why. At a very high level, here’s there’s one really big point I want to drive home: Rewrites won’t unburden a project from technical debt. ...

Typically when we think of map we think of lists, but we can widen our thinking of map and through it get a simpler understanding of how the elusive JavaScript Promise works. the type signature of map Let’s take the ML notation for map of a list: ((a -> b) -> List a -> List b) With ML notation, the best way to read this is that the last arrow is the return type. The reason the notation exists this way is because functions in a functional language can be modeled as unary, or meaning they only have one argument. One can imagine multiple argument functions as sytactic sugar. ...

In this episode, our hero (that’s you!) will be learning a tool that is helpful in virtually any kind of development you will wind up working in: Version control. Version control is rarely taught in school. It can be somewhat a deep topic, but we’ll go over some basics of how you see it in the open source world, which can carry over significantly to the commercial world. what’s version control? Version control is like the double-entry bookkeeping technique of saving all of your hard work. If you recall on the last lesson, there was an off-the-cuff statement about how your computer is just a fancy interface for working with files. Version control typically excels at handling text files. This blog post is a text file. HTML is text files. The original file that the blog post is generated from is a text file. SVG images are also text files. There’s also non-text files. Generally we call these binary files, but really we could also call them shit-files. That’s a completely objective industry term and not me showing any bias at all. Honest. ...

This is the third installment of this Starter Web App series I’m doing. In part 2 we made our app server respond with different formats based on headers the client sends. Now we’re going to use dynamic data! If you’re still on lesson 2, this will be cheating to continue. Spoiler alert! This is about what we should have had from lesson 2. const express = require('express') const app = express() app.get('/', (req, res) => { if(req.accepts('text/html')) { res.set('Content-Type', 'text/html') res.send('\ <html>\ <body>\ Welcome to the official site for <em>justified</em>\ <strong>cat hatred</strong>.\ </body>\ </html>') } else { res.set('Content-Type', 'text/plain') res.send('ohai') } }) app.listen(3000, () => console.log('Example app listening on port 3000!')) providing data Let’s add an endpoint (request handler) that gets us a list of cats. We’re going to model our endpoints after REST. I have a post that gives a very high level overview of REST, which you can read but isn’t required to move forward. The real basic gist is that with REST, our endpoints are modeled as noun-like things, and we have a very small number of fixed verb-like things we can do with the noun-like things. ...

As a continuation of Starter Web App, we’ll be making our server respond with some well formatted HTML. We want this so we can also test our web server with a real web browser. why? If your server is already running, you can visit it in your browser by navigating to http://localhost:3000. You will see the “ohai” we added earlier in a very flat, ugly “page”. It’s not actually a page, but instead how the browser displays plain text content. We want to give back some actual HTML so we can make a pretty page with meaningful content. ...

Hi there! I believe questions are wonderful opportunities to enhance documentation. In this case I’ve put together a series of posts for putting together your first web application using this buzzword list: HTML, CSS, Node.js, Express.js, bash (or just a shell), yarn, git, Homebrew, and maybe some other stuff I forgot to include. part 1 - getting set up with your local environment, and a tiny server part 2 - using curl, mime types, and fulfilling an automated test part 3 - working with data part 4 - backing it all up with git While this isn’t complete, I’ll expand upon it anytime I get a chance to help someone pick up the trade. Don’t worry if it seems like a lot! Fairly consistent exposure will keep you moving along the never-ending fractal that is learning about software engineering.

The purpose here is to go over some basic web stuff and get a server up and running, with maybe a web interface. legend terminal commands A source block with a $ in front generally means this is a command you should run as your normal user from within a terminal or shell. Commands on your system are programs, and you should either only run commands you understand and/or originate from a trusted (by you) source. If the command is prefixed with a # it means to run the command with elevated permissions, such as the root user or as a sudoer using sudo. Generally commands that want elevated permissions should be treated with greater scrutiny. ...