I had to download my Octopress blog to a new machine today and the process of setting up didn’t go as smoothly as I expected. At the end of the day the setup turned out to be simple, and here are the steps:
git clone -b source https://github.com/username/username.github.io myblog cd myblog git clone https://github.com/username/username.github.io _deploy bundle install
In a nutshell, you have to manually add
_deploy folder set to track
branch of your Octopress repository. Otherwise
rake deploy command fails.
I’ve had increased interest in writing throughout this year. In addition to being a pleasant and fulfilling activity, it shown a number of benefits in my everyday life and career:
- Composing emails became faster and easier. When you have to reply to a couple of dozen emails a day, speed and attention to details matters. Writing more taught me to write more concise emails which are easy to read.
- Writing a lot isn’t a problem anymore. If I have to write documentation, comment code, or just put together a very long email - I’m not put off by the idea. I’m excited about it.
- Typing speed went up. I already touch type, and constant writing practice increases the acquired speed. Fast typing makes life easier, speeding up mundane tasks, freeing up brain power for more costly activities.
- It’s easy to keep a condensed work log to highlight the issues of the day. Tough programming issues, “Eureka!” moments, meeting notes - this historical data saved me hours or even days of repeating my mistakes.
A while ago, I’ve heard of a thing called “750 words”, a site built around a challenge to write 750 words a day in order to improve writing skills and unleash creativity. This looked like a great idea, and I decided to give it a shot. I prefer to keep my personal entries offline, and I decided not to use the provided service, but to keep a set of plain text files on my local machine. Which worked out just fine. It’s all just text after all.
I lasted for 10 days in a row, which I am proud of (filling up approximately 3 pages a day was no easy task for me). I started of with silly entries about not knowing what to write about, and finished with a piece of a fiction story. That’s a considerable improvement.
By the end of the challenge I was mentally exhausted. But it taught me a very important lesson: the more you write, the better you become. And that’s one of the main reasons I keep crafting new entries for this blog.
This happened half a year ago, I just never got around to writing about it. I will go ahead and start another 750 words spree today. Maybe this time I’ll be able to make it last for the whole month.
I search for things a lot, especially in my code. Or even worse - someone else’s
code. For years
grep served as an amazing tool for this: fast, simple, and
yet powerful. That was until I discovered
ack for myself. An incredibly easy
grep implementation built to work with large (or not really) code
A lot can be said to enforce superiority of
grep when it comes to
working with code, and it’s all said here: ack’s features.
Amazing thing is -
ack doesn’t even need a tutorial. Learning progression is
natural and “just happens” by researching necessary use cases as the need
ack has a great manual entry).
Here’s a typical use example for
ack --shell 'gr[ae]y'
Searches all shell script files in the current code tree for any occurrences of
“gray” or “grey”. It will search
.zsh, and just about dot-anything;
ack will even check shebang lines for you.
Ease of use, the fact that it’s ready to use out of the box, extensive file
types, native support for Perl’s regular expressions:
ack does really good
job at searching through code.
Download it from Beyond grep.
I generally don’t use Mutt for everyday emails - I find smooth non-monospace fonts to be more pleasant to the eye, and the visualization my browser offers is hard to beat. The main use-case for me is composing long emails: Mutt lets me use my favorite text editor, which speeds up the editing of long and carefully composed responses.
Recently I added a new use-case to my work flow: searching through emails. Mutt has a powerful built-in regular-expressions engine, which is something the web Gmail client is missing.
Mutt has two ways of finding things: search and limit. “Search” just jumps from
one matching letter to another, something along the lines what
/ command does
vim. “Limit” is something I am more used to with the
web client, and it’s what I use the most.
Limit works the way regular search works in Gmail: it limits the view to
conversations matching the query. Hit
l, and enter a search query.
By default, Mutt will only search through the subject lines, but this behaviour
can be changed by prefixing the command with a special identifier. For
instance, searching for
~b oranges will limit the view to all the messages
which mention “oranges” in the message body. Here are a couple I use the most:
~b– Search in the message body.
~B– Search in the whole message.
~f– Message originated from the user.
~Q– Messages which have been replied to.
You can find full list in the Mutt Advanced Usage Manual.
Patterns can be chained to produce narrower results:
~f joe ~B apples. This
will search for a message mentioning “apples” coming from an author whose name
Caching mail for faster search
You may find that searching whole messages is slow, especially if you have more
than a couple hundred messages to search through. That’s because by default
Mutt does not store messages for local use. This can be changed by specifying
message_cachedir variables in your
set header_cache = "$HOME/Mail" set message_cachedir = "$HOME/Mail"
Now, after you perform your first search, it will cache every message you open, making all the consecutive searches lightning fast.
Oh, and keep in mind, Mutt stores messages and headers in plain text, so make sure the cache directory is not shared with anyone but yourself.
Limiting code to 80 (or 100 or 120) characters per line. It’s a well-known topic, and there’s an overall consensus on the subject, not counting occasional questions by newbies and odd cases. Most established tech companies have their own line length guidelines. These are often dependent on a language, such as in the case of Google with their 80 character Python and 100 character Java limits.
In this article, I won’t be advocating all the usual arguments, such as easier diff with version control software, or the ability to stack windows side by side on wide screens. No, I believe that battle to be won quite a long time ago, the topic is now closed. But something I didn’t find mentioned in any of the discussions is an interesting point from the world of writers and designers.
Ever since I started being interested in improving my writing skills, I found article after article mention the importance of line length in reading. Interestingly enough, this issue was raised in a world of literature. It had been resolved long before programmers were fascinated with the desire to use up rapidly expanding screen real estate.
I am talking about something known as “measure” in typography. It seems to be the reason newspapers use narrow columns, or books leave such vast margins around the text on a page. Here’s an exempt from the Wikipedia article:
Measure (or sometimes “The Measure”) in typography is the length of a line of text. For a single-column design measure should ideally lie between 40 & 80 characters. Many typographers consider the perfect measure to be 65 characters. If the lines are too short then the text becomes disjointed, if they are too long the content loses rhythm as the reader searches for the start of each line. Punctuation should preferably hang outside the measure.
Most programming languages use special operators and keywords, which can be considered “punctuation”. Some languages are more verbose (use more punctuation), and some aren’t. If you remove punctuation, the 80/100/120 character limit perfectly fits the standard time-honed “measure”.
Maybe I can use this as an additional argument the next time I have to explain to a junior new hire why the character limits are so strictly enforced.