A Link to the Past remixed with experimental beat and hip-hop

April 04, 2013

Do I detect notes of Nujabes?

Either way, buy this album NOW.

    Yesterday's computing of the future.

    March 15, 2013

    Check out this prophetic video from 22 years ago

    Apple consistently hangs on the edge of innovation. That’s their niche- just ahead of the curve. It’ a good strategy but their was a time when Apple really pushed the pedal to the medal, speeding through the curve before losing control, crashing through the guard rail and flying over a cliff. Frox is a relic from that time, the Newton also springs to mind. Both of these products are interestingy predictive. What is a Newton but a proto-iPhone? And Frox contains traces of other modern technologies like the Wii and Apple TV. Speaking of Nintendo, you see the legacy of the Virtual Boy in the Gameboy 3DS and the Powerglove’s notion controls in the Wii. These ideas were all simply ahead of their time, good ideas who’s time had not yet arrived.

    But also note how much Apple has changed over the years. Notice the collision between programability and skeuomorphism. Everything is a “panel” or a “button” but nothing is bolted down. You even write programs with skeuomorphic icons. Scripts are first class citizens. A customizable interface is rather quaint compared to the current Apple TV’s stark and simple grid. Between expressiveness and simplicity, Apple came down hard on one side of the fence- Simplicity, ease of use and consumption. The Apple TV has a amazingly simple UI- each screen is a 2D arrangement of tiles and each screen is pushed and popped onto a stack. This is a structure in many Apple products, going all the way back to the original iPod. You’d think the future would bring more powerful interfaces, not simpler ones. Or at least, I’d like to think so. Then again, I’m a programmer and it’s hard for me to get in headspace of average users. I’m not afraid of customization or taking time to learn a new language. Programmers know that the “best” way to communicate with a machine is with a language, not buttons, knobs, windows and folders. Apparently, most people don’t feel that way. They just want it to work. Why and wherefore comes this resistance to more powerful interfaces?

    I believe back in the old days, we imagined that there was no such distinction between Programers and Users. Programmers seem to naturally right deep and elegant software. We want to give our Users freedom and control. This is the core of FOSS software. It’s a great idea but it doesn’t work. Why? Users don’t want freedom. They never did. Users will contribute only minimal amounts of time and patience to working with your software. And Users make up the vast majority of all users of computing devices. Users use Interfaces. Programmers use Languages. That is the dichotomy that Frox fails to recognize. It’s too simple for Programmers and too complicated for Users. It’s the difference between eMacs and Microsoft Word.

    This depresses me a bit. I want everyone to appreciate computers in a deep way, like a sculptor knows his clay and the gardener knows his garden. That’s how I’ve felt about every linux machine I’ve ever owner. Each was it’s own unique creature, with it’s own personality and needs. But my Macbook Pro is just that- a Macbook Pro. With iPads, the distinction is shaved to nil. These devices are made to be identical, passive conduits of content. And that’s why I like writing software for Programmers. I understand the needs and wants of Programmers.

      Some nice background noise

      March 15, 2013

        From my tumblr: abemasters:Princess Mononoke graffiti, Mar 14, 12:19 AM

        March 14, 2013


        Princess Mononoke graffiti

        From my tumblr: Photo, Mar 13, 11:55 PM

        March 13, 2013

        From my tumblr: Photo, Mar 13, 11:45 PM

        March 13, 2013

        From my tumblr: Photo, Mar 13, 11:43 PM

        March 13, 2013

        My first (and only surviving) radio show

        March 12, 2013

          Space Lion

          March 11, 2013

          Space Lion by Cowboy Bebop on Grooveshark

            Importing data using a RSS feed and rails_admin

            March 08, 2013

            It’s no secret that I love the rails_admin gem. You get so much for so little and by adding plugins, you can quickly tack on common functions, all in a nice clean interface. I like to keep in mind that I’m not the only one who’ll use my software- Rails_admin provides a relatively easy way to give non-programmers really powerful but standardized access to your data. By default, rails_admin is bit like ActiveScaffold, but easier. You get all the basic CRUD actions, searching, and exporting of records for free. It’s insanely easy to get started- it just works.

            But writing extending rails_adminitself is a bit of an adventure. Not only must you carefully navigate the infrastructure of the engine itself, you’re code must be very, very general. You might be tempted to simply write the code you need, immediately and without concern for the future because developing within rails_admin entails a certain amount of overhead in time and labor. But the rewards are also pretty high. You get consistent, robust, reusable code. Your plugin will work, out of the box, for any model and indeed, any project.

            Let’s take a look at a plugin I’m working on. I needed a nice way of syncing my tumblr blog with ifailedtheturingtest. Why? Heroku doesn’t give you much space for images, and a blog without images is just dull. So why not let tumblr host your images? Other blogs allow you to import posts via an RSS feed and that’s exactly what I need! So now I have a plan: parse the RSS feed and create or updating records in our rails database. Insert the html from the tumblr post into the body of a Post records and Voila! You’ve got pretty pictures, hosted for free.

            I tend to start by cannibalizing a similar project. Enter rails_admin_import- it’s the converse of the export functionality. The export plugin turns a selection of records into a csv, json or xml file. The import plugin does just the opposite: It turns a csv file into records in my database. This plugin is still a work in progress- as if right now, it can’t do json or xml. But that just means that there is room for improvement, of which I see a couple of points

            - Rails_import doesn’t allow one to import json or xml.
            - Rails_import doesn’t allow you to import data from a url, only an uploaded file
            - Rails_import doesn’t all you to import data from an RSS feed… until now!

            As you can see, there’s overlap between these issues.

            The first step is modifying the view to give the user the option of importing from a url. Well that’s simple- add the form you need. I took this chance to pretty up import.html.erb as well.

            Take a gander here

            Next stop is the controller. Rails_admin_plugins are not like regular rails apps. The controller is not it’s own file, but a Proc. You get a single path per plugin and you must handle the http verbs yourself. The changes I made are perhaps not perfect. I feel that some of this belongs in the model. Remember: thin controllers are almost always better! But it will suffice for now.

            register_instance_option :controller do
                        @response = {}
                        text = ""
                        # @abstract_model -> Post
                        # @abstract_model.model -> Post(id: integer, title: string, slug: string, body: text, body_html: text, active: boolean, approved_comments_count: integer, cached_tag_list: string, published_at: datetime, created_at: datetime, updated_at: datetime, edited_at: datetime)
                        # make sure class has import-related methods
                        @abstract_model.model.send :include, ::RailsAdminImport::Import
                          if !params.has_key?(:file)
                            return results = { :success => [], :error => ["You must select a file."] }
                          elsif params[:file].is_a? String
                            # text = open(params[:file]).read()
                            results = @abstract_model.model.rss_import(params, _attr_accessible_role, _current_user)
                          elsif params[:file].is_a? ActionDispatch::Http::UploadedFile
                            # text =[:file].tempfile)
                            if params[:file].content_type == "text/csv"
                              results = @abstract_model.model.csv_import(params, _attr_accessible_role, _current_user)
                          # results             = @abstract_model.model.run_import(params, _attr_accessible_role, _current_user)
                          @response[:notice]  = results[:success].join("<br />").html_safe  if results[:success].any?
                          @response[:error]   = results[:error].join("<br />").html_safe    if results[:error].any?
                        render :action => @action.template_name

            We must handle the http verb, then 2 cases: one for an uploaded file and another case where a string was returned. If a string was returned, then we will be pulling from a remote URL. For the time being, let’s assume that when pulling from a URL, you mean a RSS feed. Of course, this isn’t as robust as we’d like- it might be a json file or what have you- but let’s start with baby steps.

            Next, let’s take a look at csv_import().

            One of the things that differentiates RSS from xml, json and csv is that you can’t store arbitrary data in an RSS feed. RSS feeds have a certain structure, so we’re going to need to map the fields of each item in the RSS file to a field in your class, in this case, the Post class. This complicates matters- we need to establish this mapping in the configuration of rails_admin.

                rss_mapping do
                    :title =>{ |item| "From my tumblr: " + item.title + ", " + item.published.strftime('%b %e, %l:%M %p') },
                    # Inserts a link to the original content in the body of the html
                    :body =>{ |item| item.summary + "<p><a href=\"#{item.url}\">#{item.url}</a></p>"},
                    :published_at =>{ |item| item.published },
                    # This mapping is also usefull for setting defaults.
                    # Insures that imported posts are reviewed first
                    :active =>{|item| false },
                    # TODO: rewrite overload rss mapping to allow non-Procs data types
                    # :active => false
                    :tag_list =>{|item| "from tumblr"}

            Now, each item can be processed into a true Post record.

            There’s another thing that my particular branch of rails_import brings to the table: You can decide upon a update_lookup_field. If the record you are attempting to import has the same update_lookup_field and value, it updates the record, as opposed to simply creating the record. Now you can import data over and over, without populating your database with duplicate records.

                update_lookup_field do

            Put this all together and you’ve got an RSS importer! I’ll leave the configuration possibilities up to the user.