Working with Dates and Times as a developer can be a tricky business. Recently I ran into an interesting time format which consisted of day of week, abbreviation of month, and the ordinalized day of the month. If you’re unfamiliar with ordinalized dates what it refers to are day of the month followed by a suffix. So 1st, 2nd, 3rd… I found a super cool trick to making this happen built into ActiveSupport::Inflector.
Upgrading to a new version of Rails is always an adventure. There are gems to update, deprecations to fix, and pitfalls to dodge. Recently, I’ve upgraded Rails from 5 to 6 and have come away with lessons I’ve learned and a general process to follow.
Active record has a multitude of features and niceties. From merging scopes to performing complex joins. However, sometimes it falls short. One shortcoming is a Union query.
When I’ve got a roadblock with active record, I reach for either raw SQL or Arel Tables. Both of these work well but tend to produce verbose code. That’s why it’s nice to to stay in Active record for readability. Ok, so let’s actually look at how to accomplish this.
Request specs have a lot of benefits over traditional controller specs. They allow for full stack testing at the controller level. One thing I recently ran into was how to write this for AJAX requests.
When working with multiple databases, code can become intertangled with records spanning across the systems. Seperating database domain reponsibilities away from each other is challenging but a good end goal. Sometimes this isn’t possible which in the case of testing clean-up can make for some tricky configuration details.
Recently, I’ve really dug into the Hanami framework. Coming from a Rails background it is really fascinating to see what a Ruby framework looks like in a post-Rails world. One of the first things I setup with new Rails projects is a process by which I can test mailers in development. The letter_opener gem is perfect for this purpose and luckily has a non-Rails setup guide.
A common theme I’ve noticed throughout my career is that every product, every feature, and every company eventually hits a threshold in their application of what was designed to support. Once this magic threshold is reached, the application starts to fall down the technical debt cliff. Now, I’m not saying that this is due to bad design or bad decisions, really it is just that technical debt is difficult to identify and more difficult to prioritize. It isn’t building new features or fixing existing bugs, but rather building better architecture for the future. That’s tough to sell as something worth investing in. In this article, we’ll discuss several metrics for identifying technical debt in your application.
In addition to request params being sent with malicious characters, a user’s session
can also contain them. If your website relies on session data (and most do) to determine
if a user is logged in, then you may experience the pain of seeing ArgumentError: string contains null byte appear in your logs. Luckily, building on the previous two posts we can quickly craft a mechanism to
check a users session and invalidate the request if necessary.
In this article, we’re going to learn how to build a React Drawer component from start-to-finish. We’ll work through several iterations of the component. Finally, we’ll end with something that could be reusable anywhere throughout your application.
When working with asynchronous requests and setting state in React, you can encounter some interesting side-effects. What happens if the request succeeds before the state is set? The reverse? With situations like this it’s hard to be confident in what the logic flow will look like. setState solves for this via allowing callback functions to be defined.