Software

Nov
30
Posted by JB at 11:34 am

A very close friend of mine released a new type of pastebin that has some very fancy features that really make it shine over any other interpretation on this type of idea. The client, which is written in Ruby and open source, is quickly installed through the use of the standard Ruby Gem installation approach. At this point you can immediately echo any code that you wish into the haste command on the terminal and it will be pushed up to a node.js powered backend which stores it, syntax highlighted, and returns a URL back down to you.

The web interface is simplistic, yet beautifully crafted to allow for inline text editing right in your web browser. Shortcut commands exist to create a new piece of code, save one, and tweet it immediately. In a single day it has climbed among the top spot on Hacker News, and is already getting some very constructive feedback. The fact that both the server and the client are open source allow for internal implementations to be rolled out without any worry to proprietary code being leaked to the outside.

I know he’ll be reading this post so I’ll gripe a little, and give my wish list:

  • It’d be nice to allow for a quick shortcut for tab spacing. I work in C/C++ every day, and like to have a little bit more tab that you have there by default. More tab please!
  • In the future when the Gist API becomes public it’d be really awesome to allow for forking, and pushing back up to your Gist.
  • An emacs plugin would be nice, but since I know at the main site itself, and of course, go download the client and the server and deploy it at your nine-to-five today!

  • When I was younger I spent a year or so not-so-admirably trying to learn how to play the saxophone. Like many people at that ripe age there were many other things on our mind: playing with friends outside, video games, and basically anything other than the prescribed homework-esque music. I can’t remember actually ever understanding music, like most things in my life I think I probably guessed and slid through the class, but for some time I have always wanted to learn how to play music. I don’t want to study music, in fact, I hate looking at it. It hurts my brain much in the same way that mathematics does, but that does not mean that I lack respect for music (and mathematics, for that matter).

    When I first touched Guitar Hero I thought it was very fun. My roommate and I spent hours upon hours staying up, not doing our class work, and battling each other with the game rifts. But it wasn’t like playing a real guitar. I’ve strummed my digits, fumbled with the frets, but was never able to spend the time to actually learn how to play. This is where Rocksmith enters the picture.

    My axe.

    This past Thanksgiving I drove down to Virgina to spend it with an old friend. We headed out that night and checked out Best Buy in hopes to figure out if we wanted to spend our hard earned money on some Black Friday swag when we first ran across Rocksmith. If that store in Reston, VA wasn’t able to find an Xbox 360 controller I probably wouldn’t have taken the red pill. My buddy, Drew, has been a guitar player for years and he was quite impressed with the game. Rocksmith is what Guitar Hero should have been. You plug in your guitar to the console, and strum along to the song with the actual notes, thereby learning how to play the song on the guitar. It is genius. Futhermore, Rocksmith includes video tutorials, a digital amp, and downloadable content to keep you rocking along for perpetually.

    The game tracks your progress and will dynamically make the songs harder when your skill level increases (or easier when it decreases). This means that you will always be challenged, but not enough to get discouraged and put the instrument down when you can’t feel that you accomplished something. Additional game modes allow you to master individual verses of the song, replay them at a slower speed, and even rock out to a friend that has purchased the game. Unfortunately, as far as we were able to tell, it does not include Xbox 360 (or Playstation Network) support for multiplayer, so your buddy has to actually come over to jam.

    I’ve only been playing the game for a few days but I already know much, much more about playing the guitar than a did a few days ago. The obvious initial cost is a bit more steep than your normal video game if you don’t own a guitar, but there are two avenues you can go: the bundle that includes a guitar (PS3) [~$200]; just the game if you already have your axe (PS3).

    Since Drew and I stumbled upon an awesome Gamestop sale on the game, we were able to get it for about $25 dollars off the retail price, which allowed me to save about $40 off the price of the bundle when I went to Guitar Center to buy the instrument. But obviously if you already have a guitar, or are able to purchase one second hand, it would still be cheaper just to get the game in the box. It should work with any six string guitar, and future downloadable content to the game promise a setting for bass rifts. This was my late birthday present to myself, and I’ve been enjoying it for a few days now. I hope you’re able to enjoy it, too!

    When I started doing some serious programming about ten years ago this new buzzword started to get passed around. When I was browsing the isles at Barnes and Noble every other new-age programming book would pop up describing how a service oriented architecture would be the future of software development. How it would bridge the gaps between platform dependent code and allow us to use cheap hardware when necessary to serve enterprise clients (and other services). It promised a more modular approach to programming, encapsulating functionality in a bundled executable called a “service” which had a schema that it responded to, but it via XML, SOAP or some other protocol.

    Whenever I dream up a project I tend to use it as a driver for learning a new software library or language. When reading first about the service oriented architecture paradigm the Java programming stack was usually the king of the hill when it came to discussions. Even today, after Oracle purchased Sun and basically started to put nails in the proverbial Java coffin, it still reminds a leader in enterprise service oriented design. I am a C/C++ programming, self taught and currently by trade, but I would be a fool to ignore the advantages that this platform offered. So as any good project manager I read up a lot on Java (at the time) and learned as much as I could about SOA practices.

    A few years ago I started attending college for the computer science discipline and Java was the primary language that was being taught everywhere. Although, until some of my later entrepreneurial projects, I heard not a word about SOA practices in any of my programming or software engineering courses. A few years ago the topic of the “Cloud” became all the rage; people were making money off writing books, companies such as Microsoft (and even Sun) were working on Cloud projects to help developers and Amazon started selling specialized hosting geared towards metered bandwidth, CPU and memory usage. I began asking myself: what is different about software in the Cloud?

    Well, the truth is, software that is written to be able to take advantage of all the regularly toted features of the Cloud such as being able to elastically adjust your application’s presence on demand, is just the service oriented architecture approach of designing software taken to the limit. The actual truth of the matter is that any piece of software that is designed to be fully “cloud compliant” is most likely some kind of service, be it a web application using the HTTP protocol or a Glassfish Java application stack using XML or SOAP as communication protocol. When designed properly a service oriented platform stack should be able to scale horizontally much more efficiently than it does vertically.

    What the is the difference between scaling out vertically and horizontally? When an application scales out vertically this means adding more memory, CPU power, hard-drive space, etc, to an existing system that is servicing clients. Scaling out vertically is merely adding additional computing nodes. This means everything to a distributed architecture; as soon as the node touches the grid it should be servicing clients. But as I said earlier in this essay the idea of SOA practices have existed long before the marketing engine of Salesforce and Amazon have trademarked the word cloud.

    The principle of the cloud is the ability to scale out vertically on demand. If your application is about to get hit by a swarm of geeks from Slashdot any normal application running on cheap Linux metal in a data center would likely cripple under the additional CPU, bandwidth and memory requirements put in place by this surge of new clients. An application that is able to be scaled out can elastically grow and shrink on demand, servicing the needs of its client base at any single point in time.

    But what does that mean for business? You only pay a metered rate for bandwidth and CPU cycles on the amount that you’re using at any given point in time. Your traffic at 2AM in the morning on a Thursday likely is not anywhere near the traffic that you have at peak Internet browsing hours. Why should you be paying those massive hosting fees when you’re really only using your hardware to the limit about three to four hours a day?

    This is the principle behind “the cloud,” and if you couple this with a logical service oriented application design (see: distributed) your business will much more agile and cost effective in both the peak and downtime hours.

    I have been doing some hacking on Type Aloud and I was looking for an answer to a question that was bugging me: what is the best way to use link_to with a vanity URL setup? I asked my question over at Stack Overflow and I figured I would post the answer to the question here in case anyone was looking as I was.

    Inside of my application the route setup is quite simple.

    match '/:id', :to => "users#show"
    match '/:user_id/:id', :to => "stories#display"

    Now I want to be able to make a very simple call inside of my view logic which will print out a pretty URL. Since I am using resource definitions for several controllers I cannot use the normal Rails URL helpers. The answer to my question is actually quite simple, and I already have used it before, but what I wasn’t doing was correctly passing through the objects into the helper. Here are the changes that you need to make to those routes above.

    match '/:id', :to => "users#show", :as => "vanity_show_user"
    match '/:user_id/:id', :to => "stories#display", :as => "vanity_show_users_story"

    And finally inside of your view you would build both links like the following.

    <%= link_to @story.name, vanity_show_users_story_path(@user, @story) %>
    <%= link_to @user.name, vanity_show_user_path(@user) %>

    I hope that this helped you out as much as it helped me! Kudos to the amazing Ryan Bigg for the original answer.

    The past couple of weeks I have been doing some research because I am planning on working on a FastCGI Model-View-Controller framework for developing web application services in C++. I am a C++ engineer by day and have been working with the language for nigh on a decade. The brief research I was able to do has shown me that there are no DataMapper or Active Record open source libraries available.

    What Exactly Is The N+1 Query Problem?

    When using an abstract framework to build a data model for use with an SQL-esque language you generally need to build a set of classes to model the schema in said language. For Type Aloud, lets say that I want to display all of the stories in a set of categories after you get them back based upon two slugs taken from the site’s URL.

    SELECT id FROM categories WHERE slug='sci-fi' OR slug='fantasy'
    SELECT id, name FROM stories WHERE category_id = 0 OR category_id = 1

    How many queries will be run? At most there will be two queries, but what about if none of the categories match the two slugs provided? That first dangling select query will be executed each and every time even if there are no matches to search against. How can we fix this?

    SELECT * FROM stories 
    INNER JOIN categories ON stories.category_id = categories.id 
    AND (categories.slug = 'sci-fi' OR categories.slug = 'fantasy')

    This type of explicit join will allow you to execute a single SQL query and, in the long run, will save you thousands of CPU cycles with your web applications. This type of data mapper already exists in Ruby on Rails using the Data Mapper gem which is freely available. But as of right now there is no such framework available (unless I am mistaken) in C++ which gives you the power and flexibility to build your data models and eat your cake too. My first plan in developing an MVC framework is to work on architecting a proper data mapper library for C++.

    Anyone else game?

    For awhile now my pet project has been running on top of the “noSQL” document database technology, MongoDB, that the folks over at 10Gen have developed. After testing the tech and going to a couple of the New York City meetups, I immediately decided to push myself to utilize this in Type Aloud. But, along with the Rails 3.0 release and Mongoid 2 (the Active Record wrapper that I am using for Mongo) I have had a hard time finding accurate up-to-date information on some less used features. One particular problem has been referencial (foreign) associations and the use of composite keys.

    Because the user’s poems and stories in Type Aloud and only unique on the user level I have been unable to use a simple uniqueness validation on the document identifier which up until this point was just the default hash provided by the database. I need the composite, the user identifier and the story identifier, to be unique; I only want the user to only have one story named “Winnie the Pooh.” It may be easier to understand some code.

    A standard Story model in Rails (using Mongoid) might look something like this. Notice how I do not need to explicitly provide the key because it is assumed, by default, we will use the database standard hash provided as our primary key for the document. As you see I explicitly specify the slug field as being an index as this is what will most commonly be queried. In this case, the “id” field may contain something along the lines of 4c897698cd44a10f8b000006.

    class Story
      include Mongoid::Document
      include Mongoid::Timestamps
      include Mongoid::Paranoia
      include Mongoid::Versioning
     
      # Document fields
      field :title, :type => String
      field :slug, :type => String
      field :description, :type => String
      field :disabled, :type => Boolean, :default => true
     
      # Document associations
      embeds_many :chapters
      referenced_in :user
     
      # Document indicies and keys
      index :slug, :background => true, :unique => false
     
      # Document validators
      validates_presence_of :title, :description
    end

    The problem here, and the exact reason why I merely cannot validate uniqueness on the title, is because multiple users can have the same title for a story or poem. The submissions will be presented in a vanity URL format, e.g. http://typealoud.com/johnbellone/the-darwin-prospect/chapter/1, and thus will almost always be queried with the user’s name. My solution to making this unique is quite simple. So now the story identifier will be in the format of the-darwin-prospect-4c892963cd44a108a2000008 where that hash at the end is the user’s identifier.

    class Story
      include Mongoid::Document
      include Mongoid::Timestamps
      include Mongoid::Paranoia
      include Mongoid::Versioning
     
      # Document fields
      field :title, :type => String
      field :slug, :type => String
      field :description, :type => String
      field :disabled, :type => Boolean, :default => true
     
      # Document associations
      embeds_many :chapters
      referenced_in :user
     
      # Document indicies and keys
      key :title, :user_id
     
      # Document validators
      validates_presence_of :title, :description
    end

    This works as expected and I no longer get duplicate documents. The only issue that I am having right now is Mongoid does not seem to be correctly throwing for a second save which seemingly just creates another version with a timestamp in the future. Merely adding an explicit validator does not seem to help either. Other than that this solution seems to be up to snuff, but as always, I am sure there may be a more elegant way to handle this. Any thoughts?

    On my way home from work I started to put some mind power towards figuring out a solution to the issue of adequate class loading in C++. A quick Google search for “Classloading C++” brings up a few pages that are of quite an interest. You see for awhile now I have been trying to grasp why I have not found any model view controller frameworks written in C++ running on top of FastCGI, and one of the reasons that I have been stuck on is the fact that people do not want to modify, compile, start, execute in order to get through one series of tests for Internet projects. Of course, there are many ways to divide your project up appropriately to limit the compile time of certain small pieces, but in the end, there is still that dependency on the fact that we’re still shit slow compared to Ruby development.

    One of the features I love about Ruby on Rails is the fact that there are long periods of time that I really never need to restart Mongrel while developing. I have my Emacs buffer pointed to a couple of files, save out my changes and click the refresh button on Chrome. That’s how easy it is. Could we achieve that development speed with a C++ framework? My my rain soaked walk home I went through it all in my head, and I firmly believe that speedy Web development with a proper C++ framework is achievable. But something core to this, at least as I see it, would be a structured dynamic class loading architecture which would allow on-the-fly loading and unloading of linked objects. In “development” mode (which could merely be controlled by an environment variable) we could even execute g++ each and every time we have a web request as long as the dependencies for these plugins were small enough to minimize compile/link time. A class loader could be pointed to a directory similar to class path environment variables, setup to look for a specific string through a regular expression, and dynamically load object files based upon the timestamp of the file. The core framework would need to be a shared library – so your classes to handle the variety of software patterns you decide to use (Observer, Singleton, MVC, etc) would be something that you’d need to take down the whole server if updated. But once a framework is to a certain point you rarely make changes to the core.

    After I worked through these thoughts on the PATH ride into Harrison I got to thinking: because we have access to literally all the low level libraries for Ruby, Python, PHP, what is stopping us from building a framework that will allow simultaneous development in any language that we can plug in easily? Of course, I do not see why anyone would want to do this inside of a real development environment when you could just as quickly (and easily) stick to a single language, but the thought still piqued my interest.

    Just something on my mind.