Category Archives: development

On this page:

Upgrading from Rails 3 to Rails 4; thank goodness for Emacs and rspec

I spent some time working on upgrading Quantified Awesome from Rails 3 to Rails 4. I was so glad that I had invested the time into writing enough RSpec and Cucumber tests to cover all the code, since that flushed out a lot of the differences between versions: deprecated methods, strong parameters, and so on.

rspec-mode was really helpful while testing upgrade-related changes. I quickly got into the habit of using C-c , m (rspec-verify-matching) to run the spec file related to the current file. If I needed to test specific things, I headed over to the spec file and used C-c , s (rspec-verify-single). Because RSpec had also changed a little bit, I needed to change the way rspec-verify-single worked.

(defun sacha/rspec-verify-single ()
  "Runs the specified example at the point of the current buffer."
  (interactive)
  (rspec-run-single-file
   (concat
     (rspec-spec-file-for (buffer-file-name))
     ":"
     (save-restriction
               (widen)
               (number-to-string (line-number-at-pos))))
   (rspec-core-options)))

(sacha/package-install 'rspec-mode)
(use-package rspec-mode
  :config
  (progn
    (setq rspec-command-options "--fail-fast --color")
    (fset 'rspec-verify-single 'sacha/rspec-verify-single)))

C-c , c (rspec-verify-continue) was also a handy function, especially with an .rspec containing the --color --fail-fast options. rspec-verify-continue starts from the current test and runs other tests following it, so you don’t have to re-run the tests that worked until you’re ready for everything.

I should probably get back to setting up Guard so that the tests are automatically re-run whenever I save files, but this is a good start. Also, yay, I’m back to all the tests working!

Test coverage didn’t mean I could avoid all the problems, though. I hadn’t properly frozen the versions in my Gemfile or checked the asset pipeline. When I deployed to my webserver, I ran into problems with incompatible changes between Rails 4.0 and 4.1, and Bootstrap 2 and Bootstrap 3. Whoops! Now I’m trying to figure out how to get formtastic-bootstrap to play nicely with Bootstrap 3 and Rails 4 and the latest Formtastic… There are some git repositories that claim to do this correctly, but they don’t seem to work.

Grr.

Fine, I’ll switch to simple_form, since that seems to be sort of okay with Bootstrap 3. I ended up using this simple_form_bootstrap3 initializer along with

# You can wrap a collection of radio/check boxes in a pre-defined tag, defaulting to none.
config.collection_wrapper_tag = :div

# You can define the class to use on all collection wrappers. Defaulting to none.
config.collection_wrapper_class = 'collection'

and this in my style.css.sass:

.form-horizontal
  .control-group
    @extend .form-group
  .control-label
    @extend .col-sm-2
  .control-group > .form-control, .form-group > .form-control, .form-group > .collection
    @extend .col-sm-10
  .help-block
    @extend .col-sm-offset-2
  .control-label.boolean
    text-align: left
    font-weight: normal
    @extend .col-sm-offset-2
  label.radio
    font-weight: normal

which is totally a hack, but it sort-of-semi-works for now.

More changes to come, since I’ve got to get it sorted out for Rails 4.1 too! Mrph.

Reflecting on my growth as a programmer

One of the things I realized from dealing with that programming issue is that I don’t have a mature development workflow for front-end work yet. On previous projects, I focused mostly on back-end development. I had somewhat gotten the hang of test-driven development and code coverage when using Rails before, and I set up an issue tracker for my previous teams. For my main consulting engagement, I shifted to working on mostly HTML, Javascript, and CSS. I’d handled a bit of that before, but we usually worked with designers who did most of the heavy lifting (and the cross-browser fiddliness). Over the past two years,  I picked up more JQuery and Angular, fought with Internet Explorer 7 and then 8, and explored Chrome’s developer tools a bit more.

I didn’t have things quite set up the way I think other people have. I felt mildly guilty about installing programs that were not available from the client’s internal software site, although Emacs was definitely worth the twinge of unease. Even the version control I used was ad-hoc, using Git on my computer to manage snippets for copying and pasting. I still haven’t mastered the Javascript debugger in Google Chrome, much less the tools available for other browsers. (Hence all the grief Internet Explorer gave me.) I didn’t have a test framework set up, so I often committed regression errors and other mistakes. I haven’t yet internalized all the cool development tools in Emacs, like Smartparens and Magit. (I’m slowly getting the hang of multiple-cursors-mode, though!) In terms of workflow maturity, I felt more like someone a few years out of university (or maybe even someone in their final year of classes!), and definitely like someone cobbling things together instead of picking up practices from a well-running team.

My main consulting engagement is coming to a close, but I’m looking forward to learning more about the craft of software development. I have a few personal projects to practise on, and it might be easier to Do The Right Thing when you’re less worried about potentially wasting the client’s time. I’m looking forward to familiarizing myself with more of the nifty features in Emacs. I’m also looking forward to immersing myself in the right ways to do things with popular frameworks, including testing and deployment.

I’d like to become a good programmer someday. What would that be like? For the particular way that I work–a generalist pulling together different things quickly–a good programmer might be one who has a neatly organized library of snippets, and who writes modular code with simple tests that exercise different functionality. Using a debugger, the good programmer would be able to dig into other people’s code, figuring out even things that aren’t documented. That programmer would also be able to quickly prototype and build well-designed interfaces. Things don’t have to win awards, but the interface shouldn’t get in the way. An even better programmer would have the ability to coordinate other programmers, improving people’s results by helping them work on both a tactical and strategic level.

Someday!

2014-09-15 Reflecting on my growth as a programmer

2014-09-15 Reflecting on my growth as a programmer

My path for learning AngularJS

I’d been meaning to learn AngularJS for a while, and rapidly prototyping a data-binding-heavy Javascript application was the perfect excuse. The phonecat tutorial on the AngularJS site was a little too heavy-weight for me, although it would probably have been useful for learning how to Do Things Right. Simpler, from-scratch tutorials like AngularJS in 30 minutes and ng-newsletter were a little more useful for me. After I got the hang of setting things up and using a controller, I browsed through the AngularJS documentation and looked for different modules as I needed them.

Here’s the rough order I learned things in:

  1. Binding data with {{}}
  2. Retrieving data with $http (since I already had JSON handy from the NodeJS site I created)
  3. Iterating over data with ng-repeat
  4. Adding ng-click events
  5. Using ng-class
  6. Dependency injection
  7. Figuring out routing with ui-router
  8. Dividing things into multiple routers
  9. $interval and $timeout
  10. State change functions
  11. Resources (although I didn’t end up really using these)
  12. Directives

I still have to learn about filters, nested views, testing, proper file organization, and all sorts of other goodness. But yeah, AngularJS feels pretty good for my brain… =) Yay!

Programming and creativity

My client had been bringing me a constant stream of little technical challenges to solve. I pulled together different tools to make things happen: AutoHotkey, NodeJS, shared files, optical mark recognition, and so on. He said it was fun watching me figuring things out. It got me thinking about how programming can involve many different types of creativity. If you can tell the different types apart, you might be able to focus on improving some of those aspects.

2014-09-10 Programming - What does it mean to be creative?

2014-09-10 Programming – What does it mean to be creative?

Here’s a rough first pass:

  • Design: Probably the most obvious form of creativity in development, whether we’re talking about interfaces or architecture.
  • Imagining or anticipating needs: When people don’t even know what they’re missing
  • Imagining practical applications: Starting from the solution or from an available tool
  • Seeing gaps and being curious about possibilities: Maybe related to anticipating needs? More like, “Hmm, what if?”
  • Collecting components/capabilities and combining them: API functions, tools, etc. Like collecting puzzle pieces and then being able to dig up the right combination later on.
  • Making adapters: Smooshing different systems together.
  • Generating variants and other ideas: Coming up with different approaches, or coming up with variations on a theme.
  • Incorporating feedback and iterating effectively: Probably related to generating variants or shaping requirements, but also related to getting beyond vague requirements or too-concrete requirements.
  • Breaking things down and building a plan: Seeing the components and figuring out a good order.
  • Shaping requirements: Translating vague requirements/feedback or seeing past what people think they want.

Hmm…

Planning my code/development learning

One of the best things about programming is that as you learn more, the possibilities increase dramatically. Each new thing you learn can be combined with so many other things for even more awesomeness. I’m getting ready for my idea-of-the-month experiment, and I’m thinking about the kinds of building blocks I’d like to learn more about and use.

Android development – I can build small apps for myself
Data visualization library like D3 – web-based graphs
Some kind of Javascript/CSS/Rails front-end toolkit that makes it easier for me to prototype rich user interfaces
Evernote API, so that I can improve my workflow
AutoHotkey – finely-tuned timesavers
Rails 4 – prototyping
WordPress backend – building things
WordPress theming – design
Twitter API, for analysis
Meetup API, for analysis
Google Contacts, Google Calendar, IMAP headers – for analysis
OCR, speech recognition – so I can convert, even at 80% accuracy
Arduino, sensors, and motors – for interfacing with the physical world
Emacs LISP – for personal productivity
PhoneGap – cross-platform mobile apps?
Dropbox API – tools, analysis
Twilio or some other text API – communication

For March, I’d love to dig into Emacs, D3, and maybe Evernote. That way, I can prepare for the Emacs conference, visualize my Quantified Self stuff, and dig into my new brain backup system. :)

Helping people learn more about programming

A number of people I know want to learn more about code. People see it as a useful skill, whether they’re dealing with functions and macros in Microsoft Excel, building tools in Ruby or PHP, or playing around with graphics in Processing. I had tea with a designer who’s learning how to code in the process of building a personal project. Since he was there and the code was there, I figured I’d help by answering any questions he had. By the time we wrapped up, he’d solved three of the things he was getting stuck on: limiting queries, working with inline PHP, and using AJAX to dynamically pull in data. Good stuff.

Helping people learn is so much fun. I loved teaching introductory computer science. Even though sometimes it was frustrating, it was such a thrill getting people to those "aha!" moments. I speed-read, so it’s easier for me to skim through Google results and documentation to spot just the right function. I’ve made lots of mistakes, so it’s easier for me to debug things than it is for people who are starting out. Sometimes all people need is a nudge in the right direction, a snippet of sample code, and then they’re off. I get such a kick out of it. It’s high-leverage – a little help can go a long way.

Problem decomposition is a key skill: breaking a challenge down into small, motivating steps, identifying the things you need to figure out first so that you can build on top of them. It’s hard when you’re new, and easier when you’ve solved lots of similar problems. I want to get super-good at this, which probably means doing this with more breadth and depth so that we have more building blocks to play with.

I’m figuring out what I like. I like one-on-one sessions and co-working chats more than group tutoring or teaching a class. I don’t mind looking at someone’s screen using Skype. I’m not an expert, but we can learn together, and I’ve been told that my enthusiasm is infectious.

What could this look like, if I folded this into my experimental life? Maybe it starts with informal coworking in a shared space, helping people while hanging out and doing my own work. (I might have a "Do Not Disturb" / "Open for Helping with …" sort of sign on my laptop.) I’m planning to join HackLab.to in March, after my current consulting gig winds up. (I hope the weather will be nicer by then!) More formally, people might book hour-long sessions in a cafe, coworking space, or library, like the way tutors meet with students. I’d get paid in cash (pay-what-you-can) and/or barter. I could offer virtual help, too – e-mail? Skype?

So there’s this idea of code coaching, for those questions that you can’t ask on Stack Overflow or on mailing lists, and for learning not just a specific thing but also the process of learning it. Shall we give it a try? I’m open to inquiries about Emacs Lisp, PHP, Ruby, Rails, JQuery, Excel functions and reporting tools, AutoHotkey, Bash scripting, and other things people might want to learn.

I’m a little anxious about the impostor syndrome, but I should just get over that. I confess up front: I’m not an expert in any of these frameworks, especially since most of them move faster than I can learn. <laugh> (You won’t believe the kinds of things people are building with Emacs Lisp these days!) I’m always going to be looking things up, because I switch between languages and don’t have all the syntax in my brain. I sometimes have to look up how to do basic control structures like a for loop. And I’ll tell you if I don’t have the foggiest idea how to solve something, but at least I can show you how I’d look for it.

This sort of mentoring is an expected part of teamwork. Who’s done this as an independent? Are there things I should watch out for? Will it hopelessly fragment my brain?

Who’s interested in exploring this with me? How would you value it, and how do we test whether it’s worth it for you and me? Jan/Feb’s busy with consulting, but maybe we’ll see what this looks like in March, or we’ll do low-key coaching for starters…

Related: http://news.ycombinator.com/item?id=4857854