I've been playing around with the Electron framework, formerly known as Atom Shell. It's a tool based on Chromium and io.js that allows you to build cross-platform desktop applications in JavaScript, and is most famously used as the framework for the [Atom][atom] text editor as well as the [Slack][slack] team messaging application. While Apple, Google and Microsoft all offer intriguing platforms and lots of cool features, there was something I needed to build quickly and didn't have the time or resources to find native OS X/Windows developers in which to help me complete it. So I turned to the tools I know best: JavaScript and, especially, Ember.js.
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.
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.
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!
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.
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...