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.
As I've said before, I'm constantly working in the shell and have
found many ways to improve my flow since I began working
this way. I also like to keep in contact on IRC to give out
help on Ruby, JS or Rails (and constantly learn in the process), chat
with friends, or discuss open-source projects. I use irssi to
connect to Freenode, a shell client, and I wondered if it would be
possible to get Notifications Center to listen in on my chats and let me
know when I get new messages. Thanks to alloy's powerful
terminal-notifier, I can!
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.
This began as a response on Facebook to a friend of mine and I
felt like more people should know my thoughts on why UK Garage is more
respected now as a genre than it ever was before. I'm not an expert
on UKG, but I've been listening to it for the past 3-4 years (and before
that even, I just didn't know it yet..) and been noticing some exciting
changes in its projected legitimacy and adoption.
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.
We hear a lot of talk by musicians and other "insiders" (who are mostly
either aficionados or amateur musicians who aren't doing this kind of
thing full-time. I would be included in this list) about entropy in our
musical lexicon. We hear talk about DJs not spinning vinyl anymore,
thereby making DJing even easier than it once was (and more reliable).
We hear about DJs not constructing their set in the same way as they
used to, with less variation and care taken to the actual sound levels.
The fact that there are people who are paid more money in an hour than
most of us are paid in a day, and they aren't even really making sure
they don't redline the mixer (which actually can cause damage, I've
seen it in real life!) or take care to not ruin their fans' ears, is
both sad and hilarious at the same time. After all, your fans aren't
going to buy your music anymore if they can't hear it...
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.
I feel like I've been posting a lot about code on this blog. It's mostly what I find myself writing about inside my text editor, but today I feel like I should change the subject a bit. I've been feverishly working on both The Wonder Bars' debut album as well as side projects with some of my friends here in the Philadelphia electronic music scene (in its various forms). One of the most fruitful collaborations has been with The Architech, a DJ I've known about for quite a while but which Philly is just beginning to get introduced to. He was one of the core guys behind the early raves at The Vaudeville Theater, where influential rave DJs like Brak (now Udachi) and Jen Mas performed in what seemed like uninhabitable conditions. This was all before my time as a raver, though, so if you really want to hear the full story you'll just have to come out to one of his shows and ask him yourself. He's a resident at Propaganda and the Bangarang! 4th Fridays monthly parties at The HeadHouse, and frequently plays the legendary PEX parties, including the most recent Heartburn at the Electric Factory.
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.
So here we go, another new layout and another re-hash of this blog's content. I threw away the last two iterations (still have the data, though) of this blog, because I was unsatisfied with the poor content on it. So let's start again.
Thanks to The Architech coming over and showing me some of the more interesting features of Ultrabeat, my drum composition has changed tremendously. I used to use ReDrum, a noble and wonderful little drum machine packaged into Reason, because of its familiar look-and-feel (its UI is modeled after the TR-909) and dead-simple feature set that was not only easy to comprehend, but easy to manipulate in a live setting. But composing in ReDrum has its drawbacks, and composing in Ultrabeat works better with the way I think drums ought to be composed in electronic music. However, this presents an interesting problem: since my live setup relies on Reason for drum beats, how am I going to get Ultrabeat patterns and sounds in Reason?
So now you have Reason set up to read MIDI from Ableton, and to pump drum audio back into the sequencer through 3 separate tracks. This is the way I do things live and at home, and I hope it helps your workflow because it's certainly helped mine!
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...