Atom Text Snippets

Text editors are powerful tools to increase your efficiency.  I’ve finally gotten around to learning about customizing Atom’s text snippets, and I have a few tips to share here.

In all the time I’ve been learning to code, I have tried to avoid optimizing my text editor or even learning too much about its functionality.  I believe in muscle memory.  Typing code, over and over, helps me to internalize the syntax and structure of a programming language.  This is not entirely scientific on my part, but I come from a background of first learning to play guitar, and then practicing martial arts for many years.  Both of these disciplines require hours of repetition, day after day.

When I started learning to code, I found that Zed Shaw’s Learn Ruby the Hard Way gave me the most bang for my buck (yes, I know it’s free) because he requires you to type out the code, and then reread it, instead of just reading about the concepts.

But at some point, learning becomes doing, and now I find myself getting paid to reskin an app.  This requires entering the same code in multiple places across many files.  Providing value to my client requires speed.

Ag is a useful tool for finding the code I want to change (if you aren’t using it, stop reading this and start reading this).  But knowing is only half the battle.  I also have to go into each file, delete the old code, and type in the new.

Snippets allow you to type a short abbreviation, and expand that to whatever you want.  As an example, I have the following code in my snippets.cson file:


This allows me to open a new file, save it as an html file, and then type ‘html5sk’ and hit enter.  An tabbed-in html page appears in a puff of smoke!

The atom/snippets page really has all the information you’ll need to get things set up, and there are several tutorials out there as well.  But setup can be a little finicky.  One of the most useful bits of information is figuring out what context your snippets need – especially with Rails.  I struggled with this for a while, because ‘.text.html’ seems to work in some cases but not others, ‘.text.erb’ works in a different set of cases, and so on.

The easy way to determine this is to open a file that you want to use a snippet in.  Then hit ctrl-shift-p.  A box will open up at the top.  Type “Editor: Log” and you’ll see “Editor: Log Cursor Scope”.  Click on that or hit enter if it’s highlighted, and you’ll see the scope for that file.

Also, don’t forget to put a dot before the scope in your cson file, eg ‘.text.html.ruby’.

With a little experimentation you should be well on your way!

From Failure at Life to Coding Jedi in One Day

Recently I had one of the rare days where I was able to spend the entire day coding. Since I had such a big chunk of time, I decided to add a big hairy feature to the rails app I’m working on. And I failed.


After spending the morning on that feature, around noon I tackled another big problem, a different feature that was also hard to implement. And after 3 hours or so of struggling with it, I was getting discouraged. My whole day was almost gone, with nothing to show for it. I began to worry. Maybe I’m not actually cut out for this line of work. Maybe I’m not good enough to get paid to do this. I’m too old to learn how to do this stuff. Before long, my entire life trajectory of the past 2 years began to feel like a waste.

This is actually not an unusual feeling for me. And I’ve been building rails apps now for more than a year. I can build things that do stuff. But I keep running into these walls.

Learning to code is really just about running into the wall, over and over again, until you figure out that there’s a way over it, or around it, or that you’re running the wrong direction entirely. And after you run into that wall enough times, eventually you’ll start to slow down, stop and think before you smack into it again.

When I first started, the wall was figuring out that I had to assign a variable so my for loop would know where to start counting. A year ago, it was trying to understand how rails views and controllers and models all worked together. Today, it was creating custom routes to pass in multiple parameters to a controller.

I kept on working today, trying different things, reading and rereading the documentation. I talked to a buddy on slack. And finally I got it working!

Right now I feel like a true Rails Jedi Ninja Badass. Truly. It’s hard to beat the feeling of working through a problem, and seeing the results in your web app.

But tomorrow, or next week, I’m going to hit another wall. In a perfect world, you’d learn to code and then you’d just code. But the truth is, you never stop learning and you never stop running into problems. You just gain enough confidence to know that you will be able to solve the problem, given enough time. And you gain experience that helps you know where to look for answers, and understanding that helps you narrow down your search for those answers.

If you’re just starting out to learn to code, you’ll hit the wall a lot sooner. As you gain experience, you’ll get better and better at more things, hit fewer walls, and get better at fixing bugs because you’ve seen them so many times. But there will still be wtf moments.

Erik Trautman, who created the Odin Project, published this excellent blog post about the process of learning to code. He’s right, and getting stuck in the desert of despair is one reason why the Odin Project is so great. But his upswing of awesome I think is missing some details. It’s not a straight curve. There’s lots of little downswings in there.

Problem Solving Rails and React

I’ve decided to add React to a Rails app I built.  Right now I am trying to create a select box in a form.  The form creates new Transactions.  Each Transaction belongs_to one Program and one Account.

Currently I have the Transactions showing up, along with a form and delete actions.  But I am having some trouble.

The first bit of trouble is that I’m using CoffeeScript, which is new to me.  React uses JSX and vanilla JavaScript.  So translating to CoffeScript is confusing, although not impossible.

The next layer of trouble is how to create a select box in React.  React has no form_for or options_for_select helpers.   I have figured out how to create a select box, but I need it to be populated by the database table Programs.

The third layer of difficulty is how to deal with associations.  I can’t type in the view like I can in Rails, and I can’t use a raw SQL query in the JavaScript.

To help wrap my head around the problem, I decided to follow Justin Weiss’s fabulous advice, and build a mini-app.  This simplified the problem for me, by taking it down to the simplest level that I was having trouble with – how to access associations in a rails app, using React.  Thanks to this excellent tutorial, and with a bit of muddling around, I’ve figured out how to access associations.  Now I have to figure out how to put this into a select box with coffeescript.

Linter to the Rescue

I’m currently using the Atom text editor.  I’ve been trying to stay text-editor agnostic, figuring that I will have plenty of time to optimize later.  But lately I’ve been hearing that Vim is worth learning.  This thoughtbot post pushed me over the edge, and so this weekend I gave it a shot.  I’m still nowhere near ready to use it all the time but working on it.

So tonight I started working on learning to use React with a Rails app.  I decided to start building in Atom at first, since that’s what I’m used to.  After a while though I figured I’d try Vim.

Of course, I jacked up the spacing on the file I was working on, and gave up (for tonight).  I went back into Atom and started working.   I edited the component I was working on, refreshed the browser, and:

ExecJS::RuntimeError  SyntaxError: [stdin]:5:10: unexpected . (ExecJS::RuntimeError)

The error was coming from layouts/application.html.erb, which was all auto generated code.  Wth?  I looked back over all my code, looking carefully at the indentations of the coffeescript.  Everything, line by line, was correct.

Luckily, Atom has a package manager and so it was easy to install coffee-lint. Sure enough:  I had added a line that somehow got pushed down below the code I was looking at.   Since the whole file was only a few lines long, I didn’t think to scroll down.  But the linter found the error immediately.

So… Atom 1, Vim 0.  I see that Vim has some linters available though so I’ll be giving it another shot.

Everything looks like a nail

I finished the code kata I blogged about yesterday.  I won’t share the solution since others might want to try it.  But it’s interesting how my thought process was shaped by the challenge to try not to use a nested loop.  Because of this, I didn’t think about the simplest solution, or the most efficient solution.  I thought about how I could do it without using a nested loop.  I approached it as a coding challenge rather than a math challenge, which is what it actually was.

And once I solved it as a math problem, rather than as a coding problem, the complexity dropped from exponential to linear.  So the code was improved by stepping outside of the coding domain.

The Janki Method for Faster Learning

anki card

I have been using Anki flashcards for a while now, mainly to help memorize Ruby syntax, rails commands, and other things where rote memorization is helpful. I recently came across the Janki method, which relies heavily on Anki.

I will be giving this method a spin.  I have been reluctant to spend too much time optimizing.  Surely, the best way to learn to code is to study the concepts and practice writing code.  Optimizing seems like a distraction, especially if you have limited time.  But now that I am starting to learn a new language (JavaScript) which brings a different paradigm, taking some time to optimize might be helpful.

I will also be keeping some things in mind:

Twenty rules of formulating Knowledge:  Lays out hints and tactics for note taking and creating flash cards to maximize retention

Janki Method Refined

Oxbridge Notes on Note-Taking

A couple of other things to remember:  muscle memory is important – thus, practice coding as often as possible.

Visual memory is also important:

Visual cortex is that part of the brain in which visual stimuli are interpreted. It has been very well developed in the course of evolution and that is why we say one picture is worth a thousand words. Indeed if you look at the number of details kept in a picture and the easiness with which your memory can retain them, you will notice that our verbal processing power is greatly inferior as compared with the visual processing power. The same refers to memory. A graphic representation of information is usually far less volatile.

Anki allows images to be inserted into flashcards, so I’ll be playing with that.  Putting screenshots of code snippets on flashcards is one technique recommended by the creator of Janki.

Also, I usually find videos to be annoying and too slow.  I can read much faster than someone can talk.  But the visuals in a good video can be helpful, so I will be trying out more videos as I go along.

Progress update

I’m currently reading Agile Web Development with Rails 4.  I’ve also signed up for Pat Maddox’s 21 day Challenge, which starts April 13th.  I’m interested to see how that works.  It will be a busy week for me so there might be some challenges to keeping up with the challenge but I hope I can get ‘er done.  I’ve bought Pat’s book, Ruby Steps and skimmed through but haven’t devoted much time to it.

My plan when I wrote my last post was to do some other tutorials, as I was having trouble with the Odin Project’s sample projects.  I was feeling like I was taking too long to figure out things like error messages and how I should structure and implement pretty basic stuff.  Instead of working through the projects on Odin, I completed the Rails Tutorial (except for chapter 10, which was skipped in the Odin Project’s sequence).  I then moved on to Jumpstart Lab’s Merchant tutorial.

Unfortunately,  this tutorial was written a few years ago and hasn’t been maintained, so some of the methods no longer work in rails 4.  I spent some time trying to update the methods, and learned a bit in the process, but I decided to work through the Agile Web Development book.  I hope to return to the Merchant Tutorial, because it was an interesting challenge and I was learning a lot about reading error messages and server logs.  It was just taking too damn long.

I feel like I keep running into roadblocks, but I’m learning some things about how I learn best.  The Odin Project would be much easier if there was an active community of folks to bounce things off of and ask questions.  There are some gaps in how things are presented.  Of course, those gaps are the things that a learner is expected to figure out on their own.  The problem for me is feeling like I’m falling into those gaps instead of figuring out how to jump across them.  Given my available time to code (an hour or two a day), I can easily spend a week trying to figure out why a single method won’t work for me.

Thus, the tutorials.  I can keep learning, have concepts reinforced and spelled out for me, and have the same things presented to me in different ways.  This feels much more productive than hours spent googling, changing a line of code, googling some more, changing the line of code again, etc.


Learning Web Development for Grown Ups: How I Maximized My Study Time

I was about halfway through The Odin Project when I read this excellent post by Peter Hurford.  It got me thinking about the number of hours I have invested in  learning web development, and how I could get more time in.

I had been working through the Odin Project for about 6 months at this point.  I wasn’t tracking my time, but my rough estimate was that I was spending on average an hour a day on programming.  My time spent was probably more than that, but I didn’t think about it too much.  An hour a day seemed like a reasonable amount of time to spend studying something.  After all, I have a full time job, family responsibilities, a house to take care of, etc.

I started the Odin project at the beginning of July.  If my rough hour per day estimate was true, by December I had put in 1 hour per day for 180 days.  Peter estimates it took him 700 hours to learn enough web development to get a job.  After six months, at 180 hours I was barely a third of the way there.  At that rate, it would be another year before I finished!

Now there’s a lot of wiggle room here.  It’s likely that I spent more than an hour a day.  I don’t know because I didn’t track.  And different people have different learning speeds, so 700 hours for Peter might not be enough time for me or someone else.

The point is, it got me thinking about how I could maximize my learning time and be job-ready sooner.

One big problem is that programming is hard!  You can’t just memorize syntax and be good to go. Sometimes a single line of code can be extremely challenging to figure out.

I have been waking up early in the morning every day before work and getting in at least an hour.  At this point in the day I can tackle challenging concepts and knotty problems and do ok.  But then I drive to work, work for 8 hours, drive back home, fix dinner and take care of whatever needs to be done around the house, and by the time I sit back down my brain is mostly fried.

So the challenge is how to structure my learning time.  I can meet different challenges at different times in the day.  In order to maximize my learning time, I needed to have different things ready to do at the level my brain is ready for.  Maybe an example will best explain what I mean.

In the morning when I’m fresh, I start work on whatever project I’m on.  I try to make this my coding time.

At some point I stop studying, get ready for work and then drive.  I have a pretty long commute, so I have made it a point to fill my tablet up with podcasts beforehand.  Listening to podcasts on my commute gives me another hour of study time each work day.  The challenge here is finding podcasts that are actually conducive to learning, but I have found a few so far:

  • Learning Rails
  • MIT CS 600 – this is video lectures, not podcasts, but it explains simple concepts well enough that I can grasp them without doing the coding exercises.

Then when I get home, I am tired. I might still try to take on the more challenging stuff. Maybe during the day I’ve figured out how to get something working.  Maybe I’m still fresh enough to tackle the challenging problem I was working on in the morning.  Or maybe not.

If I’m feeling tired and dumb at this point, I read.  Usually this is reading ahead in the Odin Project or whatever tutorials.  Sometimes it’s just reading tutorials and not doing the code examples.  Or maybe I can just type in the code to build muscle memory.

Another tool is Anki.  This is a flashcard program that syncs across all devices.  While I’m studying, I fill out flashcards, and whenever I have 5 minutes of downtime I can pull out my phone or tablet and run through a deck of flashcards.

Finally comes videos.  These are good for when I’m at home doing housework.  There’s really no shortage of these and usually with a quick google search I find something that I’m interested in.

Structuring my day in this way has made it easier for me to get in 3 hours of learning time a day.   That’s about 90 hours a month.  At this rate, it would take someone 8 months to reach Peter’s 700 hours.