OmbuLabs Blog

Previously, I outlined the new hotness that is Hotwire. New features are nice, but what can you build with it? Let’s build a little project, and let’s make it something different from the usual Twitter clone that’s being used to demonstrate this new feature. Instead, I’ll show how to build a basic scrolling price ticker like you’d see on any stock site that updates in real time. We’ll learn a few interesting things along the way.

One of the most visible and controversial new developments with the release of Rails 6.0 is Hotwire. Like anything in web development, the growing popularity of single page applications using JS frameworks has sparked some resistance. Arguably, the duplication of logic that single page applications often require violates the DRY principle. There are also many developers who would like the responsiveness of single page applications without all of the client side JavaScript and it’s associated headaches. There are a considerable number of developers who’d like the pendulum to swing back towards the server, but maybe keep some of the more desirable aspects of the SPA pattern. Hotwire is a fresh take on how to do this the Rails way.

With the constant pressure to both find and then execute on client projects, agencies often lose sight of the possibility of working on internal projects. While the initial reaction is often to dismiss them as a distraction from the important client facing work, carefully chosen interal projects can be very valuable. Aside from the obvious benefit of solving internal problems that might not have a readily available solution, they also provide training opportunities for developers. They give you a chance to try new ways of doing things with relatively low risk, or perhaps preview new languages and frameworks you’ve been considering.

One of the most fundamental tasks when writing or refactoring software of any kind is breaking the problem down into smaller parts. When you’re first starting out - and even as you continue to gain experience - figuring out what those parts should be, and where they should live within a codebase can be a daunting task. Design patterns and principles can help, but trying to keep them in mind as you design and implement solutions can be overwhelming.

Thankfully, there’s a pair of principles that can cut many of these gordian knots, and render decision making much clearer, simpler, and easier to articulate to others. Understanding and using the concepts of coupling and cohesion to guide my design and refactoring decisions yielded immediate results for me.

Tough Love

One of the first things that a journeyperson programmer will have to learn when they transition from full time student to working developer is that things in the real world are never as cut and dry as their classes may have made it seem. At the end of the day, software is not written because we love building castles of logic in the sky, it’s written to solve a real problem. That might seem like a trite observation, but it explains almost everything you observe as a working developer.

Here at OmbuLabs, we do a lot of work with older versions of Ruby and Rails. Recently, I’ve been taking a look at Docker, the virtual container platform, to see how it might help us manage the often idiosyncratic setup that applications we work with might require.

The last time we looked at Docker, we looked at the most basic and easy version of using it - building an image from a base image, a parent, and then layering additions and changes on top of it. With a carefully chosen base image, this can be an extremely flexible and relatively straightforward way of getting an image up and running in a container.

In my last article, I gave a brief tour of what Docker is, and basic usage. Once you’ve got your feet under you with basic usage, you’ll reach the point where you want to start making your own containers. You’ll certainly need to know how to roll your own if you want to use Docker in your own infrastructure.

If you’re like I was not too long ago, the DevOps world gives you a chance to experience what most non-developers probably feel like when they read about what we do on a day to day basis - confused, and maybe a little bored and frustrated, with an utter lack of even basic knowledge. It doesn’t help that DevOps is rapidly becoming a field of expertise unto itself, or that most of the relevant players seem determined to hide behind vague descriptions like “enterprise platform” and “containerization solution.” As a day to day working developer, adding an entire new skillset can be a daunting and intimidating prospect.

Everyone has had the experience of working on a gnarly, difficult to understand code-base. The sort of code base that makes you hate your job. Often it comes down to poor design, but code conventions also play a large part in whether you wake up dreading your job in the morning. The overall design (choice of design patterns and how modules and classes are organized and factored) is the long range, big picture strategy of how an application will be made. Code conventions, by contrast, come down to the choices you make about which constructs of a language you use, which you don’t, and when.

Out of all the problems an agency might face, “we have more opportunities than we can handle” is not something you’ll typically hear anyone complaining about. For those who are lucky enough to be in that position, it’s always thought of as being “a good problem to have.” But make no mistake, having more opportunities than you can handle can be a real problem. Aside from the obvious opportunity costs of all the work not taken, there are often good reasons why you may not be able to expand your permanent headcount just yet.

One of the first complications that most webapps of any complexity will run into is the need for privileged users who can do things that normal users can’t or shouldn’t be able to do. Before too long, you’re headed towards writing your very own administrative interface. This is not only extra work, but can be tricky to do without compromising the security of the application you’re administering. Most Rails developers will be familiar with this story, and Rails being Rails, it turns out that there are a couple of good options for extending your existing applications with a pre-generated, customizable admin console.

If you’ve been a web developer for any length of time at all these days, you’ve no doubt used at least a few web based APIs here and there. It’s possible that you’ve even written one (or more!) yourself. API design is a rich topic with a lot of deep roots, but some cursory research will show a number of best practices that public facing APIs should implement. Understanding these practices will give you a firm basis for judging the quality of APIs as a user and consumer, and allow you to design more useful APIs when it’s your turn.