On May 13th, til.hashrocket.com (TIL) experienced an attack. This attack had the effect of overstating the relative amount of affection that the users of TIL felt towards the posts on the front page of TIL. While most of our developers will bask in the glow of any and all affection, either automated or not, the unanticipated scale of affection combined with the notifications that our slack channel receives on relatively small increments of "likes" both chafed at our sense of truth and also served as a Denial of Chat (DOC) attack in our main chat channel. The root cause of this attack was a script making requests from a computer in Dearborn, Michigan written by an author who had discovered that there is no limit to the amount of liking that can be expressed on TIL through clicking and post requests.
In software development, before any code can be written, you begin by gathering requirements. The clearer the requirements, the better the code reflecting those requirements will be. Writing quality user stories is an important first step towards setting development up for success. What is one way to make sure that the user stories are good? Make them small.
Why should you write small user stories?
1. They are easier to discuss and understand
Small stories are easier to talk about and get your head around. A large story has room for vagueness. You either risk making wrong assumptions or you spend time coming back for clarification again and again. A small story lets you have focused discussion around the specifics of a single behavior.
Just like good financial planning involves a strategy for paying off credit card debt or budgeting for home maintenance, good project planning involves setting a strategy to avoid and reduce technical debt. This post discusses methods to manage technical debt.
This is the second part of a two-part series. Visit the first part for an introduction to technical debt, its similarity to personal finance, and how it slows down development.
Why you should manage your technical debt load
Your bank isn’t going to give you a contract for a credit card or a home repair loan without some strict rules about how they will be paid back. To keep technical debt from piling up, slowing you down, and costing you precious time, you need to develop your own system of accountability to manage debt.
It’s that time of year again: time to think about what the next year of Ember should hold.
Personally, I feel really great about the community’s effort around the Octane edition. What’s great about Octane, and any future edition we do, is that it’s a focus on polishing and documenting the features, and providing a clear transitional path from where we were to where we’re going.
Octane includes a lot of stuff we’ve been working on for a long time. Some highlights:
jQuery is no longer included by default in new apps
Glimmer components are the default components in Octane, which includes a new, massively slimmed down base class and angle bracket invocation.
Element modifiers are a new, more composable way to interact with the DOM from components.
Tracked Properties are the default way of managing data flow in Octane, which eliminates the need for a special computed property feature.
One of the biggest challenges around technical debt in software development is how to communicate its true costs to stakeholders and decision-makers. The first part of this two-part series on technical debt explores some ways it can be helpful to think of technical debt like financial debt.
What is Technical Debt?
Technical debt is a term to describe the shortcomings of existing code that could be changed to perform better, and the ongoing consequences for failing to address it.
There are two ways to generate technical debt: actively and passively.
Technical debt is incurred actively when development has taken a shortcut. Maybe it was a hack solution or skipped a step to build a feature faster, but now the code is hard to extend or unsuitable for long-term performance. Sometimes, a shortcut is a conscious choice to get something done sooner. Other times it’s an unanticipated consequence of not having Continue reading “Technical Debt Part 1: Understanding Debt”
This is the description of a technical journey to better understand the labor market for computer programmers by using numbers from the Bureau of Labor Statistics. As a government agency, I expected the BLS to provide a readily available, significant amount of raw historical data, and while true, this data is provided in a number of ways each of which is unsatisfying in its own way. The BLS has an api, a large cache of public flat files, and a set of spreadsheets for each year dating back to 1997. In this blog post I explore each of these methods of extracting data from BLS.
The growth of the labor market for Computer Programmers
2000 TILs is a landmark but is just a small window into what we do at Hashrocket every day.
This week, we published the 2000th post to our daily learning site, Today I Learned. The statistics page gives a sense of the scope and scale of this ever-evolving project. It is the result of continual small contributions by the entire Hashrocket team.
Two thousand TILs began on April 13th, 2015. Springtime: a great time of year to begin something new. We've averaged a bit under two posts a day since starting to document these things in a digital, shareable way. Of course, before we had TIL as a platform there was a fair amount of non-shareable, non-documented learning. Okay, a "fair amount" is an understatement; Hashrocket's entire history has been about teaching and learning and craftsmanship and sharing. You can't be a great developer without obsessing over all Continue reading “2000 Today I Learned posts”
We learned about Invoke-RestMethod, the syntax for invoking commands, the concept of “pipelines”, and the fact that anything we type in a script that isn’t assigned to a variable or passed into a pipeline is printed out. We also learned about redirection and the special $null variable, which allows us to redirect output into nothingness.
If you’re just interesting in learning enough PowerShell to be useful, feel free to move on to the second post in the series (Fun With PowerShell: Deduplicating Records). But if you’re curious to dig deeper, let’s unpack a few of the concepts that we learned in more detail.
Like in other shells, you invoke a command in Powershell by mentioning it.
Title : The Avengers
Year : 2012
imdbID : tt0848228
Type : movie
Poster : https://m.media-amazon.com/images/M/MV5BNDYxNjQyMjAtNTdiOS00NGYwLWFmNTAtNThmYjU5ZGI2YTI1XkEyXkFqcGdeQXVyMTMxODk2OTU@._V1_SX300.jpg
Title : Avengers: Age of Ultron
Year : 2015
imdbID : tt2395427
Type : movie
Poster : https://m.media-amazon.com/images/M/MV5BMTM4OGJmNWMtOTM4Ni00NTE3LTg3MDItZmQxYjc4N2JhNmUxXkEyXkFqcGdeQXVyNTgzMDMzMTg@._V1_SX300.jpg
Title : Avengers: Infinity War
Year : 2018
imdbID : tt4154756
Type : movie
Poster : https://m.media-amazon.com/images/M/MV5BMjMxNjY2MDU1OV5BMl5BanBnXkFtZTgwNzY1MTUwNTM@._V1_SX300.jpg
Title : The Avengers
Year : 1998
imdbID : tt0118661
Type : movie
Poster : https://m.media-amazon.com/images/M/MV5BYWE1NTdjOWQtYTQ2Ny00Nzc5LWExYzMtNmRlOThmOTE2N2I4XkEyXkFqcGdeQXVyNjUwNzk3NDc@._V1_SX300.jpg
Title : The Avengers: Earth's Mightiest Heroes
Year : 2010–2012
imdbID : tt1626038
Type : series
Poster : https://m.media-amazon.com/images/M/MV5BYzA4ZjVhYzctZmI0NC00ZmIxLWFmYTgtOGIxMDYxODhmMGQ2XkEyXkFqcGdeQXVyNjExODE1MDc@._V1_SX300.jpg
Title : Ultimate Avengers
Year : 2006
imdbID : tt0491703
Continue reading "Fun with PowerShell, Deduplicating Records"
At Hashrocket, we begin new projects with an in-depth storycarding session. It's how we turn client vision into development-ready requirements. It allows us to immerse ourselves in the client’s business domain, define the overall interface and functionality of the application, walk through user work-flows, and discover edge cases. In this blog, I’ll talk about what storycarding is and what it takes to start a session off on the right foot.
Storycarding is a 2-3 day session where we work together with a client to define in detail the requirements of an application. We sit down together in person and talk through the client vision, capturing features in the form of story cards. If a designer
I’ve been having a lot of fun playing around with PowerShell recently, and wanted to write up some of my learnings.
If you’re thinking: “I don’t use Windows, so this post isn’t for me”, good news! Microsoft has released versions of PowerShell for OSX and Linux with easy installers, and I’ve tested the examples in this series on both Windows and Linux. I document the installation instructions in a separate post.
Let’s get started. We’ll interact with a REST API called the Open Movie Database. All of the APIs in OMDB require a (free) API key, so if you want to follow along, start by grabbing one.
Let’s create a new directory called powershell-explore and create a new file in that directory called omdb.ps1. The ps stands for “PowerShell” and the 1 stands for “maybe we’ll want a version 2 someday” (also .ps is taken by PostScript).
Aside from a brief excursion into MongoDB years ago, I have had no experience with NoSQL databases. This meant that when I was presented with a project that required me to convert a PostgreSQL-backed application to Neo4j, I knew I would have a lot of learning to do.
I don't profess to be a Neo4j master (YET!), but I found a way to think about the database that worked for me and helped me move forward on my project.
What Does My Data Look Like?
My journey started with trying to figure out how data is meant to be stored in a Neo4j database. In Postgres, I'm used to tables with rows and columns.
So how does that translate to Neo4j?
Data in a Neo4j database is stored as a node. You can think of a node like a row, with properties on it to store information, similar