How Git Checkout's Previous Branch Shortcut Works Under the Hood
One piece of Git shorthand I use all the time is git checkout -. Much like
cd -, it references the previous item in your history. In the case of cd,
it will change your current directory to the previous one you were in. So,
$ echo $PWD /home/aru $ cd code/git-req $ echo $PWD /home/aru/code/git-req $ cd - ~ $ echo $PWD /home/aru
Git has its own version of this:
$ git branch --show-current master $ git checkout my-new-feature Switched to branch 'my-new-feature' Your branch is up to date with 'origin/my-new-feature'. $ git checkout - Switched to branch 'master' Your branch is up to date with 'origin/master'.
Handy! But how does it work? I poked through the files in .git (and even
watched the filesystem for changes, but nothing jumped out).
Elixir Development with Vim
I love Vim (more specifically, the NeoVim fork). Modal editing as part of my Unix IDE brings an immense amount of productivity and enjoyment to my day-to-day development activities. As such, whenever I take up a new language or framework, I enjoy experimenting with how best to integrate it into my existing workflow.
Having started programming in Elixir, I've started the customization journey for the language. Much as with Maslow's Hierarchy of Needs, there's a hierarchy of editor support required for an fulfilling programming experience. Let's get there with Elixir!
Kicking the Tires with Elixir, Part 1 - Pipes
Lately I've been playing with Elixir, a functional language that sits over Erlang and the OTP framework. It's exciting because it handles embarrassingly scalable problems with aplomb, enabling a high level of parallelism and concurrency with a great developer experience. While I think Rust shines at the system programming level, Elixir seems like a perfect candidate for web services - balancing power with ergonomics.
There are plenty of well-written posts about the language and its associated libraries. I wanted to touch on what stood out to me as a Pythonista, web developer, and nerd. I don't know how many posts will comprise the series, but I have at least a few topics in mind.
First up: pipes.
Migrating from Gmail to Fastmail
In 2004, Google launched Gmail. This service changed everything. You didn't have to worry about running over your few megabytes of quota - your storage space was "unlimited" (with a ticker and everything)! Deletion was a thing of the past, you now archive! Folders were so ninety-ninety-late, there were labels! I got an invite within the first two weeks of it launching, and it was good.
A decade or so later, Google launched Inbox, which brought innovations like bundles, snoozing, highlights, pinning, sweeping, and smart filtering to the deluge of email that flooded your account each day. I switched from Gmail to Inbox, and it was better.
Then, in true Google fashion, it was sacrificed at the altar of project mismanagement (or whatever the lack of product strategy is called). And it was bad.
Since being forced back to Gmail, I've constantly lamented the death of a service that made dealing with email less painful for me. Gmail is not only without new innovation, but it's also slow; It regularly fails to load new messages, or seemingly loses track of what it should be showing, necessitating a hard refresh. Sure, Google has thrown a few bones at it, like smart replies, but I respond to so few emails that spending a few seconds to formulate a response has never been an issue.
Given these concerns, I realized that the "stickiness" of Gmail was gone. I have the means to pay for service, and nothing is keeping me on Gmail (other than the fact that everyone's been using my Gmail address for 16 years). Leaving Gmail sounded doable, and I owned a personal domain on that I'd love to use for email. The only question was: where do I go for hosting?
Elasticsearch Frustration: The Curious Query
Last year I was poking at an Elasticsearch cluster to review the indexed data and verify that things were healthy. It was all good until I stumbled upon this weird document:
{ "_version": 1, "_index": "events", "_type": "event", "_id": "_query", "_score": 1, "_source": { "query": { "bool": { "must": [ { "range": { "date_created": { "gte": "2016-01-01" } } } ] } } } }
It may not be immediately obvious what's going on in the above snippet.
Instead of a valid event document, there's a document with a query as
the contents. Additionally, the document ID appears to be _query
instead of the expected GUID. The combination of these two irregularities makes
it seem as if someone accidentally posted a query to the wrong endpoint. No
problem, just delete the document, right?
DELETE /events/event/_query ActionRequestValidationException[Validation Failed: 1: source is missing;]
Wat.
A DevOps Workflow, Part 3: Deployment
This series is a longform version of an internal talk I gave at a former company. It wasn't recorded. It has been mirrored here for posterity.
Congratulations, your code looks good! Now all you need to do is put your application in front of your users to discover all the creative ways they'll break it. In order to do this, we'll have to create our instances, configure them, and deploy our code.
A DevOps Workflow, Part 2: Continuous Integration
This series is a longform version of an internal talk I gave at a former company. It wasn't recorded. It has been mirrored here for posterity.
Look at you – all fancy with your consistent and easily-managed development environment. However, that's only half of the local development puzzle. Sure, now developers can no longer use "it works on my machine" as an excuse, but all that means is they know that something runs. Without validation, your artisanal ramen may be indistinguishable from burned spaghetti. This is where unit testing and continuous integration really prove their worth.
A DevOps Workflow, Part 1: Local Development
This series is a longform version of an internal talk I gave at a former company. It wasn't recorded. It has been mirrored here for posterity.
How many times have you heard: "That's weird - it works on my machine?"
How often has a new employee's first task turned into a days-long effort, roping in several developers and revealing a surprising number of undocumented requirements, broken links and nondeterministic operations?
How often has a release gone south due to stovepiped knowledge, missing dependencies, and poor documentation?
In my experience, if you put a dollar into a swear jar whenever one of the above happened, plenty of people would be retiring early to spend time on their private islands. The fact that this situation exists is a huge problem.
What would an ideal solution look like? It should ensure consistency of environments, capture external dependencies, manage configuration, be self-documenting, allow for rapid iteration, and be as automated as possible. These features - the intersection of development and operations - make up the practice of DevOps. The solution shouldn't suck for your team - you need to maximize buy-in, and that can't be done when people need to fight container daemons and provisioning scripts every time they rebase to master.
In this series, I'll be walking through how we do DevOps at HumanGeo. Our strategy consists of three phases - local development, continuous integration, and deployment.
Please note that, while I mention specific technologies, I'm not stating that this is The One True Way™. We encourage our teams to experiment with new tools and methods, so this series presents a model that several teams have implemented with success, not official developer guidelines.
Twitter for Blackberry®
Note: This is an old review that has been sitting in my draft folder. Rather than delete it, I decided to publish it. The content may be outdated as I was testing the first official release.
Recently, Twitter made waves in the tech world by buying Tweetie (renaming it Twitter for iPhone) and launching their own BlackBerry App World and Android [QR here] clients. I've been a long-time ÜberTwitter user, but decided to see what sort of experience the official Twitter app for BlackBerry could provide. Click past the jump for my review!