Consider swapping out the standard “less” pager for one that has syntax highlighting.
Here’s one way to achieve this:
Back in 2012, Paul Irish tweeted a neat way to make “cat” colorized.
If you do this, and you like this, you can get a colorized less with no more work than a two line shell function.
If you’re looking for another way to get syntax highlighting with less, there’s something called lesspipe, but I haven’t looked into it yet.
So far I’m happy with cless.
Enabling the ability to magnify any part of your screen, at the level of your window manager (or operating system), is a key piece of functionality that you should figure out today.
Zooming into any part of your screen is something you can use every day:
And when you want to zoom, you’ll find yourself saying,
Oh, just one second– let me try to make this bigger.
And if you’ve got this figured out— it just takes a moment’s notice— less than a second— and you can make any text huge.
But if you don’t have it figured out, you’ll start thinking, “How do I increase the text in <whatever-application-I-am-in>?” It might be easy or it might not. You might have it fixed in a bit or you might have to give up and risk people tuning out. Either way— you’ll get off topic.
If you allow “zoom” to be done on an application-by-application basis, you are guaranteed to have inconsistent results. Your trusty browser might be just fine, but maybe your editor or a spreadsheet application will not be.
Perhaps the person you’re working with has left her glasses at her desk. Perhaps you’re giving a talk and you see people squinting in the back row.
Whatever the case, Zach Holman is right when he says,
I have yet to see a talk that made me think: ‘goddamn I can’t read
this because the text is too big’
In most cases, 15 minutes of research can provide a solution.
I first used this feature on Ubuntu, but now I use MacOS. If you’re using MacOS— you can easily make it so that pressing CONTROL and then using a two-finger gesture on the track pad magnifies content in the neighborhood of the mouse.
Here are the instructions from bkbeachlabs that I followed.
It takes 5 minutes to implement and you won’t look back.
I am happy to have finished the first draft of my emacs configuration! It is rudimentary, but I am proud of it all the same. The configuration, and a written description of what is included are available in PDF and HTML and elisp.
I had been looking for an excuse to wander around emacs, and the opportunity arose recently as part of moving my config to a new laptop. Rather than wholesale copy my old config, I was inspired to create a new one by this advice:
As an Emacs user, you’re going to have to get comfortable seeking out new pieces of elisp, bringing them in, configuring them, and eventually writing your own. The Starter Kit can help this process by giving hints as to where to start and what to look for, but constructing a solid configuration is ultimately a personal journey for which you must take the first steps.
– technomancy, Emacs Starter Kit, v3
Looking to take my “first steps,” and with my interest sparked in Knuth’s Literate Programming by Sacha Chua, I set off to write a coherent prose description of my elisp config. The end result is my emacs-setup, and the ability to generate a description of my config as well as just the pure elisp.
I set out to make a configuration that was:
Combining these two, my emphasis was on strong documentation and beautiful typesetting from the start and as a top priority. I suspect Beautiful and Well Documented would be the natural result of most Literate Programming attempts. However, additional goals were to make the configuration:
rm -rf
~/.emacs.d without flinching and reliably be back to where I was
before the rm just a few moments later. This is inspired by
working with vagrant and every-so-often testing
your configuration management setup by doing a vagrant destroy;
vagrant up./tmp/emacs-test, then I can be
confident in deleting ~/.emacs.d.Reproducible and Easily Tested are not difficult to achieve with
emacs. The hardest part was having the discipline, from an early
stage, to actively delete my ~/.emacs.d several times a day. I
admit, the first time I just did a mv ~/.emacs.d
~/.emacs.d-please-work, but it was pleasant to get to a point where I
could delete and re-create with ease.
This was the first literate program that I wrote, and I enjoyed doing it. I think I have a system that I understand, that I can maintain, and that I can extend. Having written this up, I’m off to go watch some emacsrocks.com or read up on some emacsredux.com or learn more about elisp via emacsbites.com.
Before I close the chapter on this post, I would be remiss if I didn’t at least point out that Babel and Org-mode, the parts of emacs that enable literate programming, are a real delight to work with! If you are thinking of treading this path, be sure to check out Schulte’s A Multi-Language Computing Environment for Literate Programming and Reproducible Research.
If you’re a web developer and have been asked to give a presentation and need accompanying slides, then check out reveal.js.
If you go this route, you will probably start by cloning the reveal.js repository, finding the index.html file, and then you’ll begin replacing the default content with your own.
If you’d like to have some help with fitting your content into reveal.js, then you should take a look at reveal-ck. reveal-ck is short for “reveal.js construction kit.”
It requires basic comfort with ruby and haml, and allows you to focus on putting your slide content into a single file which will become an input to a command line tool.
The reveal-ck gem comes with a command line
tool of the same name (reveal-ck) that transforms your content into
a reveal.js slide deck.
Open up a terminal, and make sure you have Ruby 1.9.3+ with ruby -v.
Then, install reveal-ck with gem install reveal-ck --no-rdoc --no-ri.
Verify that reveal-ck is present with reveal-ck --help.
As a first step toward creating a set of slides, put the following
into a file named slides.haml:
1 2 3 4 5 6 7 8 9 10 11 | |
Each %section above represents a new slide. There are four slides:
3, 2, 1, and Contact!
Once you’ve got that saved in a file name slides.haml, run
reveal-ck generate, and you’re done!
Your slides will be available at slides/index.html. If you are using
MacOS, you can preview them with open slides/index.html.
I’ve generated these slides and put the result online.
The example above is as simple as it gets. Here are a few more thoughts on getting the most out of reveal-ck and reveal.js.
The content that goes in slides.haml is haml.
The reason reveal-ck does not author slides only in Markdown is because most of the really neat and more advanced stuff that you can do with reveal.js requires the ability to get at the underlying HTML classes and attributes.
Haml has a slight learning curve, but it is pretty slick once you get going. If you’re new to haml, check out the haml reference or the haml tutorial.
You can also use slim with reveal-ck. The general idea is the same,
but create a file named slides.slim instead.
If you’re new to slim, check out the slim reference or the main slim site.
If you don’t need the more advanced features of reveal.js, or if you just like markdown, reveal-ck bundles redcarpet for markdown processing. This means that you can embed markdown in both slim and haml. For example, in haml:
1 2 3 4 | |
You can also author slides in Ruby. The benefit of doing this is that you can build out a presentation programmatically. Here are some instructions if you’d like to learn more.
By default, reveal-ck expects to find your slides in a file named
slides.haml, slides.slim, or slides.rb. However, you can pick a
different name that ends with haml, slim or rb and invoke
reveal-ck like so:
reveal-ck generate --file water-slides.haml
To get the most of out reveal.js you need to understand the classes,
markup, and data attributes that it expects. For example, if you want
something to be initially hidden and then fade in when you advance
slides, you need to add the fragment class. Here’s an example where
everything with fragment is hidden initially and then appears in
stages as you advance:
1 2 3 4 5 6 7 | |
And here is an example where vertical slides are used:
1 2 3 4 5 | |
The way to make progress here is to look at reveal.js proper and read through its documentation (and examine the markup for the default slides). reveal-ck has an embedded version of reveal.js. If things aren’t working as expected, drop me a line— reveal.js will get out of date over time. It only takes a moment to update, but the gem has to be republished: just let me know.
reveal-ck pays attention to a central configuration file. You can
create a file named config.yml in the same directory with your
slides files and put the following into it:
1 2 3 4 | |
This will change the <title> of the slides as you might expect, and
theme can be set to any of the available themes in reveal.js. Same
goes for transition. By adding this file and regenerating, you can
end up
with this result.
As with any HTML document, if you’ve got an <img/> you can make the
src absolute. However, if you don’t have (or don’t want) images
hosted anywhere, you can also bundle them up with reveal-ck.
If you’ve got a slides.haml, create an images/ directory as its
peer and put your images in there. When reveal-ck generate runs,
anything in images/ will be bundled up into the slides/ directory.
In short, this means that you can reference those images with the following:
1 2 | |
If you are connecting your computer up to a projector and displaying slides to an audience, you can simple open them in a browser.
If you want to make them accessible online, you get the benefits of presenter mode (hit “s” while presenting) as well as being able to view them from anywhere.
Because reveal.js slides are static content, you can generate the
slides/ directory and place the contents anywhere using whatever
tools you prefer.
If you’re already using Github, you should consider using Github Pages. In short:
master
branch initially.slides/master up to Github’s
master.master up to Github’s gh-pages branch.Because of how Github Pages works, if your username is jedcn and
your repository is my-talk, then the contents of your gh-pages
branch will be available at http://jedcn.github.io/my-talk/. Slides
are generated in the slides/ directory, so you will find your
content here: http://jedcn.github.io/my-talk/slides.
Here’s a quick overview to reveal-ck.
And here’s a Getting Started page.
If these aren’t enough, let me know what’s missing.
reveal.js is awesome.
Before I knew about it, I’d be coding along in Emacs (or whatever) and if I knew slides were in my future I’d boot up Keynote (or whatever).
Now, with reveal.js, you can author slides without ever leaving your favorite editor. They are plain text, so they can be easily managed in source control. On top of that, they look great, are mobile aware, and if you host them on the web, you can easily bring them anywhere.
Taking it one step further, I like using reveal-ck when dealing with reveal.js because:
reveal-ck allows me to isolate my content (the slides) from the 70+ files that come with reveal.js
reveal-ck allows me to focus right on my content (the
slides.haml).
In short, reveal-ck takes less work to make a better presentation.
At any rate, I hope this helps. Let me know what you think.
If you work with people that manipulate text for their livelihood then, sooner or later, you will hear about either Emacs or Vim.
Emacs is my editor of choice right now, but I also happen to be surrounded by people that often ask: “Why do you use Emacs?”
If you’re considering Emacs, or wondering why anyone would, this post details my emacs configuration, a few resources for further reading, and some videos about standout functionality that’s present in emacs: magit and org-mode.
One great way to see what Emacs is all about is to watch this video. The presenter, Magnar Sveen, is both adept at Emacs and entertaining. It’s a 20 minute whirlwind designed to show off some cool features.
I self-identify as an emacs beginner, and according to this post, I’m somewhere between a 2 and a 3 (out of a possible 6) in terms of mastery. That said- I’ve taken care to document my configuration using Literate Programming as described here by Sacha Chua.
This means that if you look at my configuration, you’ll see the main features of Emacs that I use. There’s nothing special: outside of plain old editing, I enjoy using magit and org-mode.
Both magit and org-mode merit further discussion.
If you use git (or are learning to use git), it’s hard to overstate
how sweet magit is. This is especially so for its support of git add
--interactive. Here’s a link to a screencast that
provides a good overview of what’s generally
possible.
Moving onto Org-mode, it describes itself as:
..for keeping notes, maintaining TODO lists, planning projects, and authoring documents with a fast and effective plain-text system.
There are a number of tutorials online, and back in 2008 I remember being somewhat slack jawed at Carsten Dominik’s talk about Org at Google.
I use it mainly for tracking tasks, embedding snippets of code or shell output, and taking notes through the day.
While we’re talking about videos, the the same crew behind this video mentioned above produce a series of videos at emacsrocks.com. Magnar’s approach is so light hearted, enthusiastic, and entertaining that I couldn’t help myself.
Aside from videos, there are a number of sites with pretty nice Emacs content, and the ones that I check out regularly are:
And I also like David Rothlis’ How to Learn Emacs for getting started.
I know that Emacs isn’t for everyone, and I know that there’s a rather large learning curve, but there’s a bunch to enjoy and discover in figuring this out.
If you read the following excerpt from The New Frontiers in Text Editing and find it intriguing, I suggest you give Emacs or Vim a try:
Overall, I think text editing is a solved problem. Text editors are like wine. The older the better. You do not want a shiny new text editor. You want the text editor that has been around long enough and used by enough geeks that every conceivable pattern of manipulating symbols on the screen has been thought of, and crystallized into a re-usable pack.
If you do go down that path and you’d like to chat about Emacs configuration stuff, shoot me an email.
These notes describe how I setup a Mac.
For now, they take the form of individual commands that I run and software that I install.
Hopefully, someday, they’ll be automated ala Boxen.
I am fortunate to find myself working at a company that provides me with a nice computer setup.
As of May 2013, this means I’m on MacOS, and I recently went through a re-install. As I was doing this, I was hoping to take a closer look at Github’s Boxen, but time was short and I missed out.
Instead of looking further into Boxen, I took notes as I got up and running, and these are those notes.
At a high level, here’s what I do:
This is accomplished via the AppStore. I log in with my personal id, and at the time of my most recent install the latest version of xcode was 4.6.2.
Next up is Homebrew.
I follow the instructions in the link above, which indicate that I should do this:
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
brew install git
Brew puts git into /usr/local/bin, which, for now, contains stuff
that I prefer over /usr/bin (ie: brew git vs. apple git), so I
modified my PATH appropriately:
#
# I added this to my .bash_profile
PATH=/usr/local/bin:$PATH
Once you’ve got git:
git config --global user.name "your name"
git config --global user.email "your@email.com"
While browsing through Github’s help on setting up git I became aware of this configuration possibility:
git config --global credential.helper osxkeychain
I set this up for short-term convenience, but I also generate a keypair and register the public key with github as well.
I make sure to setup colors:
git config --global color.ui true
And finally, I make it so that when I commit from the command line (this happens rarely because I’m normally using magit), I can supply the message via emacs:
git config --global core.editor /usr/local/bin/emacsclient
I get emacs from brew (described below, and so I get emacsclient
from /usr/local/bin).
As a side note, I find myself in a situation where I usually want 90% of my projects on my machine to use my main git config, but for the remaining 10% I’d like to use a different email address. I achieve that through mixing global and local config options, which work (as I understand) as follows:
If you’d like to have configuration options specified on a project-by-project basis, you can setup configuration local to a project by cd’ing into that project and running something like:
git config --local key value
For example, to change your user.email on a specific project, cd
into that project and run:
git config --local user.email "northridge@gmail.com"
These are a must for searching through code bases. I lean toward ack
right now, but I’ve been keeping an eye on ag.
brew install ack
brew install ag
brew install tree
My interest in a command line markdown is fueled by my editor. It provides preview capabilities that rely on a command line markdown processor.
brew install markdown
brew install node
brew install mysql
brew install wget
brew install emacs --cocoa
ln -s /usr/local/Cellar/emacs/24.3/Emacs.app /Applications
I really, really enjoy holding down control and zooming in or out
with my trackpad. This was made harder to enable with Mountain Lion,
but it’s handily setup in just a moment following
these instructions from bkbeachlabs.com here
To avoid the dreaded Emacs Pinky I re-map
CAPSLOCK to CONTROL each time I land on a new computer.
I’ve followed different instructions in the past, but here are the ones that pointed me in the right direction: random question/answer on stackoverflow.com.
Remember to do both your computer and your bluetooth keyboard. Look for the “Select Keyboard” combo box on the “Modifier Keys..” dialog.
Here’s how I get slate itself:
cd /Applications && curl http://www.ninjamonkeysoftware.com/slate/versions/slate-latest.tar.gz | tar -xz
And then how I setup the configuration:
mkdir -p ~/c/personal
cd ~/c/personal
git clone https://github.com/jedcn/getting-started-with-slate.git
cd ~
ln -s c/personal/getting-started-with-slate/.slate .slate
Then I started up Slate.
For additional notes about Slate, check out this post.
I’ve been sticking with the default Terminal recently, but I usually grab iTerm2 before too long. This time around I got it from here: iterm2 downloads list
And then, if I unzipped it and saw Downloads/iTerm.app I ran:
mv ~/Downloads/iTerm.app /Applications
I installed Pandoc for the first time recently, and it was.. exciting.
I pursued Pandoc (and BasicTeX) for the sole purpose of, within emacs,
being able to generate pdf documents ala org-export-as-pdf.
I’m not sure this is worth the effort (particularly the BasicTeX part), but, anyway..
I started here: pandoc install instructions.
Which directed me to this page for pandoc itself where I grabbed the .dmg: pandoc downloads list.
Here is where I found BasicTeX: the packages section, as recommended by the Pandoc install pages.
Things got complicated, quickly, with BasicTeX.
They tell you to read through the installation instructions in this document, and I found them worthwhile.
Here’s what I did:
Download the package for BasicTeX. There’s an installer. After you run
there’s a directory that’s been created at
/usr/local/textlive/2013basic
If you cd into it, and then run sudo ./install-tl, you’ll be
presented with a text based wizard. I ran the following cryptic
commands:
s, then a, then r
o, then r, then r
d, then 7, then ~/Library/texmf
Then I pressed i to run the installation. Whew. Time to figure out
boxen, because I’m not sure I’ll be able to get there again.
There’s more tweaking to Emacs to make it aware of where to find
pdflatex, but that’s for another time.
At any rate, I then ran the following commands to install various LaTeX styles:
1 2 3 4 | |
It’s not pretty, but it’s a start. Hopefully I’ll move on to automating this soon.
If you started with Ruby and you’re still around a month later, you
should spend a couple of hours and learn the basics of Rake. It’s a
venerable item in the Ruby toolkit, and if you haven’t used tools like
make before you’re in for a treat.
Rake describes itself as a A make-like build utility for Ruby, and you might think it’s limited to building “code,” but that’s not so. That’s just the beginning. So long as you keep your mind open, and remember that it’s Ruby under the covers, you can keep using it to “build” “things” that have nothing to do with code.
To get going, watch these two videos from Jim Weirich, the inventor of Rake:
These talks are well done, and a great investment of your time.
Once you’ve watched the videos, if you find yourself on a project using Rake, you’ll need to know about the tasks that are available to you and where to find the source code behind them.
rake -T shows all described rake tasks
rake -T whatever shows all described rake tasks beginning with
whatever
rake -P shows all rake tasks and their dependencies
rake -W whatever shows where the tasks beginning with whatever are
defined.
As a user of Rake, I am sometimes surprised by the notion that if a
task doesn’t have a description, then it doesn’t appear in the output
of rake -T or rake -W. One of these (-T) is intentional, while
the other (-W) is a bug, and will be fixed sooner or later.
The fastest way to get up to speed with Rake is to read Rake code.
If rake -W isn’t helping you find source, or you don’t have a
specific command to look for, you can generally find Rake tasks in the
following locations:
rakelib/ directory underneath
the root of your projectlib/tasks/ directory (if you’re
using Rails)Once you do manage to track down the definition of a rake task or two, the first time you read through Rakefiles there’s an element of mystery.
It can be a rather terse DSL, which you’ll probably come to appreciate over time, but initially, leaves you thinking “What just happened?”
Be sure to watch the videos above (with an eye for FileLists and the
file and directory tasks) and remember to hang in there.
One specific piece of Rake mystery has to do with two things named
CLEAN and CLOBBER. These are references to FileLists in Rakefiles.
FileLists allows you to describe a set of files, and new instances of
it are commonly created with [] rather than an explicit .new:
You can hold off on learning about FileLists until you want to clean stuff up or start writing tasks that operate on sets of files.
At any rate, don’t slug through this stuff: the path to happiness here is to watch the videos and then follow this link through to the documentation.
Many people have written oodles about Rake.
Rather than go down that path again, I’ll stop and say that sooner or later you you should check out:
How Rake handles accessing environment variables, specifically how
it simulates ENV['NAME'] if you write run this rake blah
NAME=value
How Rake handles global Rakefiles (tasks that live outside of any
given project) via rake -g
Rake has been around for a long time, and there’s a bunch to learn. However, you can get started initially with just a few hours and this investment will pay itself off within a week or two, and then only keep paying dividends.
Because it’s so well known, a number of tools claim that they are easier to understand because they follow a ‘rake like syntax.’ This means taking the time to understand Rake now has other, non-rake benefits as well.
Be Kind; Everyone You Meet is Fighting a Hard Battle.
Life is too short, and people carry around more than you know.
]]>Managing windows is an integral part of almost all computer sessions: you switch between them, change how large your windows are are, and (if you’re super lucky) move them between different displays.
Slate is a Window Management Application.
Slate provides configurable key bindings that give you control over your windows. With a single key press, you can switch between applications, make windows change to a certain size, or jump between displays.
If you’re not already using an application that provides these benefits, you should check out this write-up I created for getting started with Slate.
You might not. But..
If you’re not using an application like Slate, try counting up the amount of time you spend switching between, and managing, windows.
Switching between applications or changing the size of a window necessarily requires you to stop your train of thought and engage in a trivial and error prone task.
The total time isn’t bad: 2 seconds, maybe 5 seconds if you make a mistake, but you do this every day, dozens or maybe even hundreds of times.
No one benefits from this. Not the designer. Not the developer. Not the writer. Not the artist. Not the scientist.
What’s the alternative?
With a little work, you can make window management as second nature for you as typing is. Once you learn to type, you don’t think about typing: your fingers start going and words appear.
The same can be true for everything to do with windows: soon you’ll be in a situation where you start typing and windows start flying around.
If you’re still not sold,
When you are giving a presentation and your computer is displaying something on a big screen in front of a dozen or more people, you likely want to concentrate on your presentation and its content.
In particular, you don’t want to lose any of your focus cycling between applications, moving windows around, or manually adjusting their size so that everything fits on the screen. Especially not in front of 10 people. Or 20. Or 100.
If you’re willing to give Slate a try, I recommend starting with a write-up I made called Getting started with Slate. I’m suggesting this path because there are a bunch of configuration options and I initially found them overwhelming.
The idea of this write-up is that it should get you up and running in 15 minutes. If it doesn’t, send me an email on where I went wrong and I’ll see if I can help you out.
If Slate doesn’t seem right for you, but you are interested in window management, then start googling around for alternatives. There are a bunch of them and many have really slick user interfaces and videos showing exactly what you can accomplish.
Either way- hopefully you’ll check this out: I couldn’t go back to working without it.
You can search for ‘slate’ or ‘window manager’ on Hacker News.
Slate isn’t the only window manager in town. I’ve also heard good things about Size-Up and Divvy.
How to get a Jekyll generated site up on Nearly Free Speech with minimal hassle.
This site used to be created with Jekyll, and I wrote this to remind myself of what it took to “bootstrap” the site. That said, I’ve since switched to Octopress. I still generate locally, and I still rsync stuff up.
Nearly Free Speech is a popular hosting provider that’s good at hosting static content. It isn’t too expensive and gives you the ability to publish (or un-publish) whatever you want.
Jekyll is a static site generator.
There are many strategies for publishing a site that you’ve built with Jekyll.
Which strategy you pick will depend on your publishing platform / hosting provider.
However, if you’re using Nearly Free Speech, my suggestion is that you use straight-up rsync.
In particular, avoid the lure of using things like a git post-receive or post-update hook. If you’ve already got a local setup running the way you like with Jekyll and you don’t explicitly control the server-side environment that you’re publishing into, then it is:
a process where you upload your generated site.
/home/public with your local _siteBefore you begin, you should create a site with jekyll and then start tracking it in git.
You should be able to preview this site by running jekyll
--server and be ready to make this site available on the web.
You should have signed up with Nearly Free Speech so that you’ve got an account and ssh access to a box.
If you run jekyll --no-auto it’ll regenerate a fresh version of
your site in the _site directory.
Once you’ve got everything you want in _site you can rsync it
up to Nearly Free Speech.
Putting the two commands together:
$ jekyll --no-auto
$ rsync -crz --delete _site/ <NFSN_LOGIN>@ssh.phx.nearlyfreespeech.net:/home/publicIf you put this into a Rakefile you wouldn’t have to remember the specific command line options for rsync or to regenerate the site each time:
1 2 3 4 5 6 | |
And each time you wanted to deploy you’d type:
$ rake deploy--checksum