With the wide adoption of robust front-end frameworks and CSS-in-JS, traditional methods of targeting xpath or CSS selectors for scraping data from web pages are becoming ineffective. However, this new paradigm of front-end development leaves a key opportunity to improve the web scraping experience.
I was recently having a conversation about Pull Request reviews with a colleague of mine and I mentioned that when I’m ready to look at code for a PR, I review one commit at a time in order. After a confused pause, she asked how I could get the full context by only looking at one commit at a time. I supposed to her that perhaps the full context is not what facilitates a better review. Instead, we should follow the journey the developer who opened the PR has set out for us through their commits.
After a while of using docker locally for development, you may notice that you have a lot of images and containers laying around on your disk that you no longer use. This post shows you an effective way to clean up 50 of GB or more of disk space. The first, best thing to do is clean up dangling images. These are docker images that are not referenced by a container.
The Golang web app framework, Buffalo, has a very good templating system called Plush. It adds some nice features to the standard library templating specific to web applications such as partials and local context. It’s pretty intuitive if you’re coming from Rails. While the default setup makes rendering a template as a response to a request super easy, using rendered template content elsewhere isn’t so obvious. Once you see it though, it’s pretty straightforward to render a template to a string within your action handler functions.
For many recent projects, I’ve been using the excellent Buffalo web development eco-system. It’s a great collection of tools and packages for building web applications without needing to reinvent the wheel for each app. In this post, I’ll be highlighting a technique I use based on the service object design pattern of abstracting business logic from your applicaton implementation to increase readability and reusability. But, why? Here’s a scenario I find myself in with increasing frequency.
Let’s examine a refactoring to move code to follow the open/closed principle. We’ll see how the resulting calling code becomes much easier to read locally, without having to open other files or classes to understand what’s going on. Open/closed principle First, let’s do a quick recap of the open/closed principle. Classes should be open to extension, but closed to modification. What does that mean? Let’s take it a half at a time.
Recently at Videofruit, we had a fun internal exercise of building an app in single workday. That app ended up being an Email Service Provider picker where you answer a series of questions and we recommend an email service provider to meet your needs. In this post, we’ll breakdown a simplified version of that app focusing in on how we built a routing mechanism that is simple but effective and uses no external dependencies.
I work on a lot of little side projects. Many of them are short-lived and small scale. I start them to learn a new technology, to learn a new concept, try an idea, or just to see if I can actually build something cool. I should also mention that my memory is terrible. I “remember” things by figuring them out again. Rote memorization is basically non-existent to me. I’ve recently come up with a new best practice for my side projects which has saved my butt several times now.
Everyone knows how to checkout a branch, git checkout master, or how to look at a specific commit, git show a1c8b6d. But few know that branches, tags, and commit SHAs are typically interchangeable in these and many other git commands. Plus there is a whole set of modifiers to reference commits near to specific commits. In this post, we’ll explore all these techniques to become expert git referencers. References Below we will explore the different ways we can express a commit in git.
Christopher R Marshall