Chippewa Valley Code Camp 2009

Posted by Brian in News (November 15th, 2009)

I had the honor of presenting two talks this year at the second annual Chippewa Valley Code Camp. Code camps are free events where programmers of any skill level come together for a day of sessions and talks that are centered around code. I’ve only recently become involved with these events and am extremely happy I have. The opportunity to learn from so many experienced developers is incredible.

We held the event at UW-Stout this year, and had a great turnout. I gave two talks, the first on Ruby, and the second on Cucumber. I had wonderful audiences both times, and met some great people that I hope I get to work with in the future. Here are the slides for my talks.

See the end of the slide decks for links to the demo source code.

“Introduction to Ruby” talk from Twin Cities Code Camp 7

Posted by Brian in News, Projects (October 25th, 2009)

On Saturday, I had the honor of giving a talk on the Ruby programming language to an exceptional audience. I talked about the simple syntax and powerful libraries available, and then showed how we can use Ruby to maintain static web sites, build web applications, and test web sites.

During the talk, I showed how to use Sinatra to create a very simple wiki. I wrote two versions. During the talk, I used SQLite3 and ActiveRecord, but I wrote a version that uses MongoDB. You can grab the source for those at Github.

Here are the slides from my talk. You can view the notes too by viewing the slides on Slideshare.

Participating at code camps is something I really enjoy. It gives me a chance to talk about what I love, but it also gives me a chance to learn from other speakers. These events are usually free, and an awful lot of fun.

Twin Cities Code Camp VI: Shoes!

Posted by Brian in News, Projects (April 11th, 2009)

I had a great time talking about building applications with Shoes, which is an amazing Ruby-based GUI framework originally aimed at kids but awesome for grownups too. The source code for the examples covered in the talk is available at

Slides coming very soon.

“Meet Rails” presentation materials from Chippewa Valley Code Camp

Posted by Brian in Howto, Rails, tips, web (November 24th, 2008)

I gave a talk at the Chippewa Valley Code Camp earlier this month where I built a Rails pastebin application using test-first development principles. Since there were no slides for this, I’ve prepared a small PDF that will walk you through the installation instructions and the coding of the application I built.

Download Meet Rails to get started.

You can grab the source code for the finished project at Github.

Watch this site, as this project may get turned into a full-scale book.

Slides from “Becoming a Documentation Ninja” from Twin Cities Code Camp V

Posted by Brian in docbook, News (October 13th, 2008)

Here’s the slide deck from the talk Chris Johnson and I gave at this year’s Twin Cities Code Camp. I had a great time talking about this and I wanted to make sure that all of the resources people need are easily available. The slide deck includes notes for each slide with links to relevant information.

Slides from “Becoming a Documentation Ninja” from Twin Cities Code Camp V in PDF format.

Enjoy, and if you’re missing important stuff from this or just want to learn more, leave a comment.

How to Survive a Live Coding Demo Without a Projector

Posted by Brian in Accessibility, Howto, Public Speaking, tips (October 10th, 2010)

I love to turn bad situations into opportunities to help others learn. This morning I gave a talk at Twin Cities Code Camp on “Building Mobile Apps with HTML5 and Web Standards”. The talk had a slide deck, but was mostly designed to be a follow-along live demo. When I went in to give the talk, the projector system was locked down. According to my feedback, the talk still worked very well, thanks to the preparation I did beforehand to accommodate for things like this. Hopefully this advice will help you if you’re preparing for a talk in the future.

My slides for the talk are online here. The code is on Github.

Practice Writing and Drawing

I have horrible handwriting when I write fast, and when I’m nervous. I teach a lot though and have learned to slow down and think carefully as I write. Having clear handwriting on a whiteboard is really important because you’re going to have to give people URLs to your content. They need to be able to read it at the back of the room, too, so be sure to write big.

Learn to carefully draw simple shapes that resemble things you’d show on-screen. In my talk, I drew the interface elements we’d be creating and was able to show how they’d look.

Have a live copy people can see

Make the finished product available on your website so people can play with it. If you’re building a web site, provide the URL to the demo version. If you’re demoing an iPhone or Android app, have a link to a video that people can watch that shows the app in action if you can’t get access to put the app on the App store. This helps people see what’s in your head (and on your screen.)

Make a PDF of your slide deck!

If you use Keynote or PowerPoint, or even SlideDown, convert your slides to PDFs. Include presenter notes in your export so that people will have more context as they’re reading along. If you don’t make use of presenter notes, you should start. They can help you when you present, but they can also help jog memories later when people look at your slides at work.

Protip: Presentation Remote for iPhone will let you see the presentation notes in your hand. You can control the slideshow with it as well.

Use Git and Github for your examples

Lately I’ve been using Git branches to stage my code examples. For my talk on HTML5 mobile apps, I started out with a new branch like this:

git init
git checkout -b 01_simple_form

Then I’ll do all the work for the first stage, commit it, and make a new branch for the second stage. In this talk, the first branch was just the HTML for the user interface. The second branch then covered the JavaScript we used to create the database on the client machine.

git add .  
git commit -m "Web form"
git checkout -b 02_create_database

By the time I’m done, I have several branches in the repository that I can use to track the stages of my live demo. At the end, I merge my last branch into the Master branch.

git checkout master
git merge 09_offline

Protip: If I realize that I made a mistake, I can check out the earlier branch, fix the code, commit the code, and merge that fixed branch forward into the branches that followed.

git stash      # puts your in-progress work aside
git checkout 01_simple_form
# fix changes
git commit -am "fixed the form"
git checkout 02_create_database
git merge 01_simple_form
git checkout 03_add_note
git merge 01_simple_form 
git stash apply # put your stuff back

Once I’m ready, I create the new Git repository and push my code. I have to push the master branch and the other branches too.

git remote add origin
git push origin master
git push origin 01_simple_form
git push origin 02_create_database
git push origin 03_add_note

So how does this help me during a talk? I can direct people to the Github page and they can use the Select branch section to see each branch. The Github web interface lets them follow along as I talk about the code. That’s what I did here.

Git advantages
Uploaded with Skitch!

Be ready offline

As a last resort, take this git repository and your PDF presentation and make it available on a thumb drive, or fire up a local wifi hotspot and run a server. An iPad, iPhone, or iPod Touch with Air Sharing can help with this.

Wrapping Up

So, that’s how I’ve done preparation for my talks and managed to make it through a code-centric talk with just a whiteboard. Do you have any suggestions on what you would do?

Slides from “Learning To Walk In Shoes” presentation

Posted by Brian in Howto, News (May 14th, 2009)

As promised, here’s the slide deck from my talk “Learning To Walk In Shoes” from April’s Twin Cities Code Camp. After the slides, we went over some demo applications, and you can get those from Github so you can play around with them yourself.

Learning To Walk In Shoes

On The Desired Complexity of Rails

Posted by Brian in Rails (August 21st, 2011)

I attended Madison Ruby this weekend and got a healthy dose of knowledge from some very talented presenters. Some of the talks focused heavily on improving our practices, especially in Rails applications.

Jeff Casimir talked about making views nicer by introducing decorators. These are relatively simple to implement in a language like Ruby, but Jeff created a nice gem to make it even easier, called Draper.

Several talks mentioned using decent_exposure, a gem by Stephen Caudill, to keep instance variables out of views, as Rails does a somewhat nasty hack to get instance variables from controllers.

Then today, I saw another article talking about how Rails code could be made even more easy to maintain by leveraging Dependency Injection, a well-known, and very very useful technique.

On a few applications, I could have used a couple of these techniques to make the code easier to maintain later. And on one I did use a proxy instead of helpers in a complex view. But in the last six years of working on projects for clients, other consultancies, and even when I’ve mentored others, using these patterns would have been a huge jump in complexity for the majority of the projects.

When I decided to use Rails, it was because it was a productivity boost. When compared to Struts, Spring MVC, or other similar frameworks, Rails cuts a lot of corners in exchange for this productivity.

But seeing a number of respected thought leaders looking to bring this complexity to Rails makes me wonder…. is Rails (the community) growing up? Are we out of the “teenage kid that knows it all” phase? Are we done telling Java and C# programmers that they’re not “with it”?

Since it came on the scene, Rails, through decisions made by developers and the core committers, has evolved from something a PHP developer or Java developer would find easy to pick up to something that is much, much more complex. It’s no longer a framework for beginners, but rather a solid foundation and collection of “best practices” to build modern web applications. Rails is now being used to build bigger and more complex applications, and that complexity calls on us to revisit concepts like decorators, proxies, service objects, and dependency injection, the very “high ceremony” things that Rails developers were proud to avoid a few years ago.

While I don’t expect these kinds of things to make it into Rails itself, I do expect these concepts to gain traction. But I hope they only gain traction for the 5% of the situations where they’re needed, rather than for the sake of “well, so-and-so said it was good, so I’m doing it.” Using these tools to mediate complexity in applications adds a different kind of complexity, and that’s worth some thought, especially since, as I was told several times this weekend, there’s apparently a shortage of talented Rails developers these days.

Proper use of these object-oriented concepts in the right place will make our projects better. But it’s vital that we truly understand when we should apply these patterns so we can decide when the additional complexity is warranted, and where it’s overkill. As I was reminded this weekend, there is no “golden path” in Rails.

I encourage you to explore these things. And read Design Patterns in Ruby
while you’re at it, especially if these concepts are new to you.

Why Rails?

Posted by Brian in News, Rails (February 16th, 2010)

NAPCS was a proud sponsor of the first Chippewa Valley Ruby Camp, a day-long Ruby training camp where 23 students learned how to build and deploy their first Rails application. I taught two of the three sessions and had a great time helping other developers get their hands on what I believe to be the best way to develop scalable, maintainable, and stable web applications today. That’s a pretty bold statement, but I believe in it, and it’s why NAPCS uses Rails on all new client projects. (In fact, every project since 2006 has been a Rails project.)

Rails projects are quick to launch

With Rails, we can build and launch a prototype application in an extremely short time. On average, we can have something simple in front of the client in less than a couple of days, which is much faster than our previous projects where we used ASP or PHP. And that project isn’t usually a throwaway project; we can tweak it and move forward, from prototype to production.

Rails applications are easily testable

Professionals write tests that prove the code works as it should, and since testing is built right in to the Rails framework. testing is an easy natural part of the process. Testing has always been possible regardless of the language used, but with Rails, it’s so easy to produce well-tested code that you’d be foolish not to test. For my customers, that means much better products, and less support calls.

It’s a standard framework

I occasionally pick up projects from other developers, and while I can’t always ensure that the quality of the code will be good, I at least already know my way around the project because, in a Rails application, conventions dictate where things go. This means the learning curve is lower when we transition an application, and the customer doesn’t get billed extra time for me to figure out what’s going on.

The community is incredible

We rely heavily on open-source projects to get stuff done, and Rails has an amazing community that is always pushing the limits of what Rails applications can do. There is a new solution to a new problem almost every day, and that keeps us all on our toes. Plus, we’re very proud to be sponsoring the Rails Mentors project, which helps other developers get better at Rails development. We’re always giving back to open source, too.

It gets out of the way.

This is the most important point of all; Rails lets me deliver features. Instead of spending hours wiring up database tables to web pages, I can do that in five minutes and spend more time focusing on user experience and new features. And since it isn’t difficult to build things incrementally, I don’t get boxed in. I can make changes without feeling that I’ll lose days of work. It allows me to respond flexibly to new feature requests.

Rails gives us a competitive advantage. We cannot always compete on price alone, but we can provide better-quality solutions than others because we embrace an open, agile framework that lets us deliver stable, scalable, well-tested, and maintainable web applications.

Want to learn how you can take advantage of Ruby on Rails?

Contact us for information on customized training and mentoring services. We offer affordable hourly rates for remote mentoring, as well as custom training classes upon request.

Why I’m using a Mac

Posted by Brian in News, Rails, Usability, web (May 9th, 2007)

I’m a Windows user. Anyone who reads this blog can pretty much figure that much out. I started this company in 1995, fixing computers and trying to put the “personal” in computer service.
Over the years, I’ve removed countless viruses, uninstalled lots of spyware, formatted hard drives, recovered files, and occasionally had to send a computer back to a customer as “unfixable” because
of some unknown hardware or software glitch. Windows is popular and well-known, and people who know it well can have some pretty good job security.

Shortly after I started this company, I shifted focus towards the Internet, developing web sites. I bucked the trend of my Mac-using
counterparts back then and did all of my design work on Windows. I even did video editing there. I embraced ASP, and when that got old, I started using PHP, but deployed on Windows.

When Ruby on Rails came along and I got involved in that community, I was determined more than ever to bring Rails to the Windows platform. I’m speaking about Rails on Windows at RailsConf 2007 this year, and I’ve just finished a book on
Rails for Windows users which will be published by O’Reilly.

But I started using a Mac for development this Spring and couldn’t be happier. Here’s why.

  1. Ruby runs faster.

    Ruby runs at least ten times faster on a Mac, which means my unit tests, Rake tasks, and anything else I do with Ruby take no time to run. On Windows, I pay at least a 15 second penalty just to start a task or a test. That basically means I either sit and wait for things to happen, or I just start neglecting my tests to save time. Not a good place to be if you’re trying to write good code.

  2. It’s Linux that runs Photoshop

    Many web-based languages like PHP, Python, and Ruby run extremely well on Linux. However, you can’t use industry-standard tools like Photoshop on Linux without a few glitches and a lot of work. I’ve done Photoshop on Wine and I am not impressed. On my Mac, I can use Flash, Photoshop, Illustrator, Dreamweaver, and anything else, because there are native supported ports of those programs for my system.

  3. I can run Windows apps too!

    I need Office, and I need to run IIS so I can support ASP, .Net, and other Microsoft-based technologies. My Macbook Pro has Windows XP installed as a second boot option, but I also run Windows XP on Parallels, a virtual machine that lets me use my Windows apps side-by-side with my Mac programs. Parallels can run pretty much any other operating system, so I also have Windows Server 2003 installed for testing.

    When I go to conferences, I only have to bring one computer.

  4. I can surf in peace

    No IE means no spyware. I typically use Firefox on Windows anyway, but the complete absense of IE on this machine makes me feel much safer.

  5. More time working, less time tweaking

    I don’t have to stop working in order to make something do what I want. The Mac’s OS gets out of your way and lets you work. It’s a little difficult to transistion from a PC to a Mac at first, but some of the built-in features are great. The Dashboard gives me quick access to GMail, my WordPress blog, the weather, my Backpack account, and even a color-picker.

    When I got my Macbook, I was using it and actually being productive with it in only a few hours. I haven’t used a Mac since I was a kid.

  6. Textmate

    Windows users have e, but I have TextMate, and I don’t need anything else. TextMate is more than just a text-editor; it’s an IDE. I can integrate with Subversion, I can run Rails generator commands, I can run unit tests, and I can have Prototype and methods auto-complete while I type. I can validate HTML, preview in a browser, and then upload it back to my repository.

  7. I can use more advanced tools

    I do most of my deployment on shared hosts with Mongrel and mongrel_cluster. I can run these on my Mac without incident. I also use the excellent load-testing program httper, which does not run on Windows. There are countless other tools out there too.

    I also get to use QuickSilver, which means I can chain commands and navigate through my files and programs much faster.

  8. Apple has awesome support

    I used my new Macbook Pro for gaming one night just to try it out. My games ran flawlessly when I boot into Windows XP via Bootcamp. While I was playing, one of my keys came dislodged. I called up Apple, and within 10 minutes I had them sending me a new keyboard. That’s cool. Try getting that from another company. I’ve worked with tech support offices for the last 13 years, and I rarely get service like that. Good luck getting that from some of the larger PC manufacturers unless you have an enterprise support contract.

  9. I can zoom.

    OS X has a built-in zoom feature that I use to not only enlarge the screen when I need it, but also to inspect images for artifacts and imperfections.

So there you have it, a long-time Windows user who is using a Mac for software development. If you’re going to preach to others about “using the right tool for the job” then you owe it to yourself to see what a Mac can do for you.

If you have switched, I’d love to hear your story. If you’re thinking about getting one, let’s hear what’s holding you back from taking the plunge.