I noticed that I still had the journaling app Day One (macOS) on my computer. I haven’t touched it in ages. So I figured it’d be time to export to plain text and then shove all the goodness from 2004 and onward into my Emacs org-mode diary.org. Turns out there’s no Day One to org-mode exporter.
No matter if you use exec-path-from-shell or not, Emacs will not be able to know your RVM-managed Ruby information. This drove me crazy. Most Emacs shell commands are invoked in an “inferior” mode, aka a “dumb” shell. This includes M-!, M-x shell, and also the projectile compile commands. That’s when some of your user login scripts will not automatically load, like the entirety of rvm, the Ruby Version Manager.
Python has the with keyword that is analogous to using in C#. It is used to manage resource access and wrap a block of code with setup and cleanup stuff. I like it. Here’s an example adapted from the Python Enhancement Proposal (PEP) 343 that introduced the implementation in Python 2.6:
A little side-project of mine is a role-playing game written in Ruby that runs in the terminal and uses Unicode/ASCII characters instead of bitmap pixel graphics. In my personal tradition of these kinds of side projects, this is called TermQuickRPG. It’s a work-in progress, so there’s not a lot to do in the sample game at the moment.
Shopify published amazing/epic stats for their Ruby on Rails “app”:
1:1.3 code–test ratio
2300 model classes
most classes <10 methods
most methods way <10 lines
Makes you wonder:
can you live with more types?
can you shrink down existing types?
Swift changed the game a bit. Now it’s very convenient to create a new type. You don’t need to do the .h/.m file dance anymore but can start a new type declaration wherever you are. (Except when you’re inside a generic type.) That makes it more likely we devs stop to shy away from smaller types.
But it’s still a job for our community’s culture to unlearn coding huge classes (massive view controller syndrome, anyone?) and splitting stuff.
Ruby has a long tradition of super-focused methods and very small classes. Swift is just as terse and powerful in that regard. Now it’s your turn to experiment with writing types for very simple tasks. Like the Extract Parameter Object refactoring, where you lift things that go together into a new type.
Can be as easy as writing:
Et voilà, there you have a new explicit concept in your code base.
I use nanoc as my static site creator for this blog. It’s written in Ruby, my favorite scripting language. And so I use a Rakefile to automate most things, like generating a fresh copy of the site and deploying it to my server. Only last week did I find out how to make Rake not continue when a part of its tasks failed. Most of the stuff I use is wrappers around shell commands with a few system notifications sprinkled in. $? does capture the latest shell call’s return value (kudos dnsimple.com):
They didn’t use the ? because Ruby method names usually have a postfix question mark when they return a boolean; also, they will have a postfix bang when they mutate the receiver. This would’ve led to confusion.
Since Swift came out, I haven’t used Ruby a lot, really. I still use it for all my scripting needs, but coding real applications? Rarely. I really like strong typed languages for that: leaning onto the compiler for refactorings and such.
For about two years now I still use Brett Terpstra’s gitlogger to store my daily git activity in Day One. As of late, it ceased to run properly. Turns out some messages to log contain fancy characters like real apostrophes, ’. To fix this, add the following statement to the launchd configuration script:
I got fed up with having to start a Ruby project from scratch every other day. Thus I proudly present my Ruby BDD project boilerplate. This is an “opinionated” boilerplate. I say that because having an opinion seems to be de rigueur. What I really want to say is: I picked a setup which works for me and it might or might not work for you.
I use Brett Terpstra’s little Ruby script called “gitlogger” to write git commit messages from selected repositories into my Day One journal once a day. My commit messages tend to be a bit longer when I work on projects which really matter. Unfortunately, gitlogger wasn’t intended to handle multi-line commit messages. Every commit message resides in a list item. But if you know Markdown, you’ll know this markup won’t render as expected:
Nat Pryce released Code Guide, a tool to create interactive code documentation. See his blog post announcement. It’s written in Python and works for Python and Java code. But since Python and Ruby comments look the same, parsing Ruby code works, too.
I was trying to fix a non-issue with YAML by throwing Ruby gems at it. nanoc and Jekyll and the like provide YAML metadata for their content files: Google said this is called YAML Frontmatter. So I was looking at a way to parse YAML Frontmatter of plain text files, searching for gems – until I found the laconic answer on StackOverflow: what’s wrong with YAML’s standard features?