Super Simple Hacks While You’re Figuring Out Your Workflow

There are a lot of really great reasons to use TypeScript, but we’ve occasionally encountered some hesitancy from programmers not sure how much of an adjustment it will be. Learning Typescript is not as complicated as say learning Elm and I’d argue it’s more enjoyable to use than Flow. But the hesitancy is understandable. Many front-end developers have learned JavaScript and Ruby or Python, but have not had to dig into typed languages. Learning to program with types and think about your type system in advance can elevate your programming style and eventually be easier than not using types. However, there are many different ways to be good at programming, and I have seen a range of programming styles that might make the learning curve of TypeScript steeper. Everyone eventually adjusts to TypeScript on their own and most come to love it. From those of us who have already made the change, here are some super simple tips and hacks while you’re getting your sea legs in TypeScript.

Part of our approach to software development at Carbon Five is to ensure everyone is playing with the same dictionary. The start-of-project questions we all ask are common: What are the success metrics for our stakeholders? Will our customers dislike our product? But words like “success” and “dislike,” “good” and “bad” are all personal words. What they mean will change project-to-project, and even person-to-person.

It’s a common assumption that users and stakeholders know their needs, and can easily voice them. But if a stakeholder has gone through the daunting process of signing with a new team, they may well be looking to that team to define those needs for them. How do we do that?

While it’s not a match for every project, consider adding a demo to the end of your iterations — a scary proposition, but that’s the point. When done right, the benefits of regular demos are massive.

You, fellow software engineer, have probably felt the same as I have: while coding some big feature, you find a thing that is inefficient, unreadable, deprecated, confusing, or just buggy. Maybe it’s not bad code at all — you just realize that several packages are out of date, or your framework needs to be upgraded. You roll your eyes, you sigh, and you think, “Ugh, this has got to be fixed.” It’s technical debt.

You may also have experienced this: you go to your manager, or your project manager, and complain about the Technical Debt. “We really need to upgrade to Rails 5!”  Yet you can’t seem to get the go-ahead to fix it. “We have a hard deadline!” “We don’t have time for that!” they say.

Those in charge insist you have more important things to do. How do we convince them otherwise?

Recently we’ve noticed a number of our clients maintain a backlog of small tasks that are handled separately from their main backlog. These are tasks that should be finished at some point, but will rarely take priority over business-critical features and bugfixes. Often they are bite-sized pieces of work that can be finished in a couple of hours or less: addressing engineering chores, paying off tech debt, and addressing minor bugs. Internally, this separate backlog has earned a catchy name: the snacklog.

I recently gave a talk at Empex LA in which I talked about my desire to see simplifications and enhancements to using some of the OTP behaviors offered in Elixir. In this post I’m going to explore a simple improvement to the GenServer API that would make it a little easier to work with.

GenServers are processes that have state that can be transformed when the GenServer receives a message. This state is represented in a single value that is passed into the handle_call or handle_cast function.

This is easy to manage if your GenServer only needs to manage a single piece of information. But as soon as you find that your GenServer needs multiple pieces of information in state, you need to substantially refactor it.

Back at my first job in tech, we paired 95% of the time. Many people were new to pairing. As it was my first job, I was relatively one of the more junior people on the team, which is an especially difficult position to be in for pairing. It was an incredibly intense experience for the whole team with many growing pains. There was a lot to navigate and no set-aside time or structure to do that, so I started having “pairing retros” with my teammates. It made pairing a lot more manageable and I started having better experiences with my pairs. It’s now something I’ve continued to do throughout my career.

The concept is fairly simple. Set aside a time when you’re not pairing, to talk about pairing.

It remains a common practice in database systems today to refer to configurations where one database is a source of truth, and another database is a replica that follows the state of the source of truth database as a “master/slave” configuration.

Use of this term is problematic. It references slavery to convey meaning about the relationship between two entities. The term “slave” is used because one system is controlling the state of the other system.

Using these terms like this is cavalier. It downplays slavery and the massive human suffering it causes. By having an everyday use for the term “slave” we normalize the concept of having things called “slaves” and it desensitizes us to the seriousness of slavery. More importantly, the casual use of the term may be an unwelcome daily presence in the life of a person of color, for whom slavery has great personal significance. Continue reading …

Moving your code towards a more functional style can have a lot of benefits – it can be easier to reason about, easier to test, more declarative, and more. One thing that sometimes comes out worse in the move to FP, though, is organization. By comparison, Object Oriented Programming classes are a pretty useful unit of organization – methods have to be in the same class as the data they work on, so your code is pushed towards being organized in pretty logical ways.

Continue reading …

Active Storage was introduced into Rails version 5.2. It is a highly anticipated addition to handle integrations with asset management such as AWS S3. For a long time, the field has been dominated by outside gems, including Paperclip, which has been around longer than many people have been Rails developers. Now that Active Storage has been released, Paperclip is being deprecated, creating even more incentive to migrate if you weren’t already considering it.

I recently performed the migration from Paperclip to Active Storage on production. It felt a bit like transferring trains without stopping at a station. You’re setting up Active Storage, replacing the code, and performing a data migration that relies on the code you’re refactoring out from under you. Continue reading …

In our last Elixir blog post, “Functional Mocks with Mox in Elixir”, we discussed how testing across module boundaries could be made easier by creating a Behaviour for a collaborating module, then utilizing the wonderful framework Mox to substitute a lightweight mock module in tests.

This approach is well and good when you have very concrete module boundaries that are well-defined and coarse enough to warrant the ceremony of wiring up a behavior for a module boundary. But what if we aren’t necessarily interested in all the work in creating a mock, and we need something simpler and more lightweight?

Join us as we discuss some alternative ways to write lightweight tests across function or module boundaries.

Continue reading …