Well it's been a little over two years since I last completely reconfigured this blog, and now that it actually (mostly) works I felt like it would be fun to take a little tour of the more interesting features of this blog. The current iteration of the blog is written in Ember.js, and the entire blog application lives on your browser, hosted via Amazon's CDN. This post explains how I built a pseudo-static web site with Ember and Ember Data.
If you've ever browsed the source code of this blog, you might have noticed a directory called lib/active_copy. Opening up that directory is somewhat interesting, as you'll be able to see exactly how I take Markdown files with YAML front matter and render them through ActionView. But unfortunately, unless you fork this repo and hack it to bits, you were unable to use ActiveCopy in your own Rails projects.
Recently, I've been very interested in the development of the Ember.js framework, which has grown rapidly in the 3 years or so that I've known it. We've seen great apps being made with (most of) it, and it's gone from something that left me truly puzzled into an understandable and almost indispensable tool in my web development arsenal. While developing a Backbone app, I took a second look at Ember after they released their new routing API, and fell in love with how little code I wrote while developing a simple application. But the way that Ember worked flies in the face with one of my other favorite tools...
At eLocal, we use the lovely Pivotal Tracker to track our work progress. It has a really great interface for viewing stories, and some additional features like tasks, rich text comments, and the ability to "predict" future iterations by using the velocity and "points" system (which is totally arbitrary). Another great feature is the story states, which are also arbitrary, but we use them for very specific purposes...for example, Delivered means the story has been placed on the stage server and is ready for testing, while Finished just means that I've pushed the code to master branch and it can be deployed at any time.
At the job, we're constantly trying to improve the UX of eLocal.com by making the site behave harder, better, faster, stronger. For some reason, recently we've had a surge in these kind of feature requests from the "peanut gallery" of sales and operations staff who are the primary source of feedback for the application. Most of what I do every day is solving bugs or adding new features to this big monolithic app, which powers the vast majority of our business. It is used by the staff on a daily basis to accomplish all sorts of tasks, from an in-house CRM to an advanced billing system (complete with recurring charges and invoicing), as well as basic control of our paying customers' ZIP code ads and lead dissemination.
There has been a lot of hate towards scopes recently. I'm here to tell you that scopes aren't all bad, and they can be used to create some astonishingly elegant model definitions.
install bundler-1.3 before installing Ruby 2.0! That should downgrade RubyGems to a point that you can just do a gem install bundler to obtain 1.3. Once you begin installing gems with 1.3, everything in Ruby 2.0 will work out again.
So after posting my article on how to use assertions in rspec, I was involved in a discussion with @cheapRoc over the discovery that indeed assertions do work within the context of RSpec. To my surprise, it seemed @seattlerb was following at least one of us and overheard our conversation, mistaking my quite hyperbolic statement for a diss on Minitest.
Did you just upgrade Ruby on Rails and now all of your assert_response() tests are failing? Simply add the following code to test/test_helper.rb and everything will work again!
In the Ruby programming language, there exists two characters you are only permitted to use when naming a method: ? and !. These special permissions are designed to allow you to establish a certain level of convention in your method naming, for example, a method ending in "?" in Ruby is mosty likely always going to return a Boolean response of true or false. Not only is this convention not questioned much, but there seems to be very little sensible use out of making a "?" method not return a boolean response. At eLocal, we use "!" as a generalized YOLO convention. It means we're about to execute some actions which may fail, or are connecting to an outside resource (such as an API or our mothership site) In either case, the "!" dictates that our app's control flow should stop.
tl;dr -- you can do MiniTest::Assertions inside RSpec examples.
Ever since I watched Aaron Patterson's Peepcode Play-by-Play, I've been absolutely fascinated with the use of CTags to jump around the various codebases you have installed (if you use Ruby, you know how much of a maze it can be to figure out exactly where an error is coming from!). As the name would imply, CTags were created for C programmers dealing with massive codebases that typically had minimal to no documentation. Developed during the first boon of open source distribution, and created by some of the people on the BSD UNIX project (it was originally released with BSD UNIX), it was championed as a quick, easy and light-weight way of moving around a codebase.
In case you haven't already figured this out, I am a Ruby programmer. It took me a while before I was really comfortable with calling myself a "programmer" when dealing with Ruby, because I did something most people advise against. I learned Ruby by learning Ruby on Rails. So I learned the framework before I learned the language. Generally, this is frowned upon and causes some very bad habits to develop eearly on. However, learning Ruby this way turned out to not be so bad (even though it took me a bit longer to dive in to Ruby itself), and I continue to make the argument that having quick, tangible results and an emphasis on rapid prototyping allowed me to quickly and easily pick up some of the more advanced concepts of not only Ruby, but HTTP and web development in general. As it is my day job, I do enjoy working in Rails, but sometimes its paradigm just doesn't fit in (well) with what I'm trying to do. So I wanted to use something different.
So it's a well-known Rubyism that you can actually circumvent private and protected restrictions on instance methods if you simply use the send() method to access them. I wanted to see if it was possible to rewrite send() on a particular class to throw an exception if the method attempting to be accessed was a private method on the class.
Ruby is all about simplicity. Make simple things simple, right? So how come we have to deal with all this complexity when we run Ruby? This is how I made my life slightly easier and got some really sweet benefits as a result.
Most of my time at my current job has been spent refactoring our affiliates API. When I started, it was a series of disorganized Rails apps in a single Git repo, one solely for the backend and meant to push sales leads to our main web application, and the other solely as a frontend "dashboard" to that API, where the affiliates and the folks working in operations can see statistics on and make changes to affiliate accounts. In order to accomplish this, the past programmer had the genius idea of separating out the entire model structure into a gem, which further complicated the matter, leading to strange errors, security flaws, and flat-out unimplemented garbage code.
It's certainly been a while, hasn't it? I've been busy with gigs and vacation, so there's been little time to blog. I have been working on stuff...including the foundation of a record label (which I'll talk about in a future post) and maintaining the Wonder Bars' official website.
Well, I finally broke down and integrated Twitter Bootstrap with the existing UI of my blog. To be fair, it DEFINITELY needed some work, and I just didn't have the time to get into the existing Sass SCSS framework and figure everything out. But as Bootstrap turned 2.0, I found myself longing for a responsive UI (so I wouldn't have to "deal with" mobile), a standard reset, great typography defaults, and nice buttons/form elements to play with should I need them. The answer was simple. I needed Bootstrap.
Since December 2011, I've been working with ZSH, an alternate shell for *nix-based operating systems which has conventions similar to BASH, ZSH adds a number of more modern features to the standard shell fare, such as more customization options for your prompt and extendable autocompletion. To get started on it, I've employed the lovely Oh My ZSH framework which helps to organize your ZSH settings (.zshrc) and use functionality developed by others so you can explore the wonderful possibilities of this awesome shell.
Well I'm stuck in a bind. I can't seem to decide which operating system I want to run my all-powerful file server. A few days ago, my wonderful sister gifted me two computers, the Dell OptiPlex GX270 and GX280. The basic difference between these two tried-and-true workhorses is the graphics card interface-the GX280 includes a PCI Express x16 slot whereas the GX270 is still using AGP-and of course the model number. Other than that, they use the same motherboard, same case design, and same basic layout. PERFECT for general hackery purposes...and running a Boxee...