briankung

Rails Tutorial Quick Start Guide

Basically, this is a quick start guide for people who have some experience with Rails and Git already and just want to get to the meat of Michael Hartl's classic book, [the Rails Tutorial][railstutorial]. It boils everything down to what you'll need to start creating the sample app at Chapter 3, without any of the demo apps in the beginning, assuming you know version control with git and what you need to do to install rails.

Installing Development Environment

I'm assuming you already have a text editor or IDE.

1. Rails Installer (Windows)
2. Install Git

briankung

Notes from the Rails Tutorial spec suite

• Almost all of the model validations are should respond_to or should be_valid

• A few specs for relationships

• FactoryGirl vs Fabrication: After a bit of research, it seems like the general consensus is that Fabrication is better, even though FactoryGirl is used in the RailsTutorial.

• Request specs test each page.

• Composition:

  Controller Specs: 1 file, 4 examples, 2.7%

briankung

Tweaking MRI Ruby's Garbage Collector

I came across Fred Wu's post endorsing tweaking your MRI Ruby garbage collection settings for great justice. The results in the post and comments indicated ~33% speedup. Intrigued, I started looking into it more and found more in-depth explanations for the magic by Dennis Taylor and on [StackOverflow.][so]

After local testing that put our numbers in line with Fred Wu and readers', I tried it out on our test environment in Jenkins. Preliminary results are a 42.45% speedup on an M1 Large Amazon EC2 instance (7.5 GiB).

Awesome.

briankung

A Brief Investigation of DevOps

A week or so ago I took a brief dive into the world of DevOps, intending on finding the latest techniques for deploying apps. It was kind of like learning Yoga in order to become more flexible. It's not really the point. You'll have to excuse the lack of details, as I started (and summarily abandoned) this investigation a while ago, but what I found was actually something strikingly similar to the Agile Manifesto. There may, in fact, be a manifesto for DevOps. Truthfully, I'm not that interested in seeing yet another manifesto.

In short, DevOps is a blending of roles and an emphasis on communication between traditionally separate functionaries: the system administrators and the developers. DevOps seems to be more of a social revolution rather than a craft or set of procedures, which is cool. It seems like the most radical ideas in software are usually not software itself, but how we treat each other. As a social coder, I am okay with this.

That said, I still don't know wha

briankung

The devo.ps blog

I'm beginning to grok devops a bit more, which was greatly aided by the [devo.ps blog.][devops blog] I am a big fan of their writing. It meanders enough to have a certain vivacity to it, but remains a great technical resource as well. It also affirmed my belief that, like [Agile,][manifesto] it is primarily a social revelation in a technical sphere.

If I were to summarize what I've learned about devops, it would be to say that devops is about mutual respect and collaboration between developers and system administrators. I've always maintained that, in most cases, the hard part about coding is not the code itself, but the context in which it happens. Devops is about the context and the environment in which code runs, as well as acknowledging the complexities inherent in the job. Devops is about being disciplined [always or never.][always or never]

I'm also beginning to understand how ignorant I am about this. It's a bit overwhelming. I'm taking in a lot of information, but my practical ab

briankung

Devops Research

A few of the resources I read while looking into devops. The [devo.ps blog][devo.ps blog] also comes highly recommended.

Rackspace vs Amazon:

• http://www.quora.com/Rackspace-Cloud-vs-Amazon-Cloud-%E2%80%94-which-one-is-better-And-why
• https://plus.google.com/u/0/107359210528811368247/posts/dzjWGFrfPM9

TDD And Devops:

briankung

A Pragmatic Philosophy

I read the first two chapters of [The Pragmatic Programmer: From Journeyman to Master][pragprog], which are entitled "A Pragmatic Philosophy" and "A Pragmatic Approach," respectively. I'll go through and summarize my thoughts "A Pragmatic Philosophy" first:

The preface of The Pragmatic Programmer begins by explaining the meaning of the word 'pragmatic,' which comes from the greek word pragmaticus, or "skilled in business." I get the feeling that this is the central pivot point around which the rest of the book hinges. Skill and craftsmanship are emphasized from the get-go.

Business needs are also a key element, though I get the feeling that it has less in terms of doing whatever the "business person" says and more to do with contextualizing the job of programming within the context of the greater problem at hand.

The sections in the chapter were broken down as seen below. These are the guiding principles behind the rest of the book.

briankung

A Pragmatic Approach

"A Pragmatic Approach" focused on principles that are applicable to any and all software development. It was a bit more specific than the prior chapter. Unfortunately, it's been a while since I actually read the chapter, so we'll see. I may also be finding it difficult to summarize the chapter because it was a collection of tips rather than having an overarching theme.

Regardless; onward.

7. The Evils of Duplication

"The Evils of Duplication" explained why duplication was such a pain in the ass - basically, DRY, or "Don't Repeat Yourself." I loved this quote from this chapter:

briankung

The Basic Tools

As the chapter title implies, the authors went through the tools that they think should be employed in all software projects. There were a good deal of allusions to carpentry. I felt like this was an introduction to ubiquitous tools like the hammer and the phillips screwdriver.

14. The Power of Plain Text

Plain text is explained as being printable characters that can also be read and understood by a human. The authors mention the idea that data and code (you might argue that they are one and the same) are knowledge, and any knowledge that remains readable by humans will outlast any other data. Period. So use plain text when possible. Or, keeping in mind space and speed constraints, when pragmatic.

15. Shell Games

briankung

The Joel Test: 12 Steps to Better Code

I just wanted to make note of Joel Spolsky's "highly irresponsible, sloppy test to rate the quality of a software team." It seems like a pretty straightforward and comprehensive litmus test for overall quality of a software team. For your viewing pleasure: [The Joel Test.][joel test]

In short, the steps are:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?