How can a tool that is indescernably wrong be anything more than a toy?
Here’s a super quick one-liner to copy the current branch’s PR URL to your clipboard (for posting into Slack, tickets, etc.) $ gh pr view --json url --jq .url | <pbcopy | xclip -sel c> Remember to replace the copy command with your platform’s specific command. This would also make a good shell alias. Also, also, I might try setting up Clipboard for multi-platform goodness. Happy PR-ing! – Chris
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.
I propose a case for writing all of your commit messages for a feature, bug, pull request before writing a single line of code and afterward not adding any additional commits to your branch. Plan and execute. Give clarity and focus to your reviewers. Here’s how.
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.
Christopher R Marshall