Home > The Offive


The Official Blog of the Web Tech Group


The Flagship Sets Sail!

February 2nd, 2010 by Kenley Cheung

Flagship 2 has set sail!

At the first Student Senate meeting of the year, the Web Technologies Group launched version two of Flagship Docs.  For years, student government at RPI lacked an easy to use and effective system of managing documents, whether it be press releases, meeting minutes, or even parking rules.

The WTG understands how the lack of organization, clarity, and branding hinders student government’s ability to communicate to the student body, so we decided to tackle the problem by creating our very own system from the ground up.  The first version of Flagship, written by Haris Khan, was released in February of last year.  It was an effective solution to solving this problem, but we felt that effective wasn’t enough.

Full-text search in Flagship 2 deserves a Spotlight of its own.

Full-text search in Flagship 2 deserves a Spotlight *cough* of its own.

Over the course of 2 months, the WTG has worked on making Flagship one of the best document management systems in existence. The entire codebase was rewritten to refine features such as categorization and the user interface, and to include new features such as the built-in full-text search engine (shown on left).

In our commitment towards developing solutions to tackle issues affecting student government and the student body, we have published the entire code on our GitHub repository, meaning that anyone can take Flagship, deploy it on his or her own system, and even modify it to suit their needs and share his or her contribution to the community.


Posted in Cool Stuff, Other Projects, RPI Happenings, Student Government, Web Design | No Comments »

Introducing Scavnet… again

January 25th, 2010 by Brian Michalski

Scavnet has been re-released here at RPI, completely rewritten in Ruby on Rails 2.3.4. If you are interested, you can check it out at RPI here: http://scavnet.myrpi.org.

We initially launched this application as part of the MyRPI suite of applications back around 2007-2008. During its initial launch, the code still had a few bugs that needed addressing and it never really took off on campus. As we work to redesign the current incarnation of MyRPI we decided Scavnet, like a few of our other applications, should live on as a stand alone application. Hopefully this separation will make it much easier for future administrators to manage and update as needed.

Additionally, we’ve open sourced Scavnet under the GNU GPL v2. You can grab a copy of the source code from Github at http://github.com/wtg/scavnet/.

Tags: ,
Posted in Other Projects | 1 Comment »

Culling the Seeds

January 20th, 2010 by Mike DiTore

Rails 2.3.4 brought with it a simple addition to the platform: seeds. These are the records you want to deploy with your application – you know, not test data, not user data, but the rows that you’ll always need to get the app up and rolling.

The implementation is not particularly exciting, some people have even suggested that it is substantially lacking.  But it makes me happy because it gives us a standardized place to keep seed data. No more squirreling data away in migrations, no custom rake tasks, and no plugins (which sound okay, but I haven’t tried).

But, as with many apps, I’ve been developing with data in a table for some time. Having to copy-paste all that stuff into ‘create’ statements would be something of a pain. So, I present to you the complement to db:seed: db_cull. It’s a rake task that, given a particular table, grabs each entry from the database and creates a corresponding line in the seeds file. Simple!

There are two good ways to install this task (sadly, using gems is not possible for rake tasks).

  1. Install as a plugin: script/plugin install git://github.com/mikldt/db_cull.git
  2. Or just copy the rake task into your tasks directory (one-liner):
    wget http://github.com/mikldt/db_cull/raw/master/tasks/db_cull_tasks.rake -O lib/tasks/db_cull_tasks.rake

Now, if you have the task, and you have the data in your table (say, ‘Person’) looking the way you want to preserve it in seeds, just run rake db:cull[person]. Repeat for any tables with seed data, and of course you can edit db/seeds.rb as you see fit.

Once you’ve culled the data, you’re all set to make use of the seeds. If you’re new to seeds, you can take a look at db/seeds.rb. It’s really just a script with a bunch of create statements. Running them is simple:

  • For a new deployment, the magical command rake db:setup will create your database, run all of your migrations, and pull in the seeds.
  • To simply add the seeds to your already migrated database, run rake db:seed.

As with any  Rails rake command, just stick RAILS_ENV=production on the end of your rake db:seed or rake db:cull[] to change the environment.

Buyer beware: this task copies over all data besides the primary key. If your seed data includes lots of referential situations, well, the foreign key references will be copied over as-is. In a perfect world, this might be alright (e.g., referencing only one entry), but if referential integrity is important you may want to go with another solution or manually beef up of db/seeds.rb.

Code and documentation are on the github page.

Posted in Web Design | No Comments »

New Concerto One-Page Handout

November 19th, 2009 by Brian Zaik

Michael Zwack, Grand Marshal of the Student Senate at RPI, just met with Dr. Jackson this morning to discuss student business.  He had asked me to provide a one-page handout to Dr. Jackson that would explain Concerto to her in a nice visually pleasing manner.  I looked over the past documents we have released for general handouts, and realized that the handout has been long overdue for an update.  So last night I updated this document:

New Handout for November 19, 2009

You can download the full PDF here. I used some existing text and images to introduce readers to Concerto and its benefits, but I specifically added information regarding interest we have received from visitors all over the world at Concerto-Signage.com, as well as statistics regarding the use of Concerto at RPI to date (which is up quite a bit from our first year of service).

I will be distributing these handouts tomorrow at a talk I’ll be giving for Dr. Chris Mackie from the Mellon Foundation. I’ll be giving the talk with Brian Michalski about the impetus for Concerto, the growth of the Web Tech Group, and the Concerto Project’s past and future.

Tags: , , ,
Posted in Concerto, Cool Stuff | No Comments »

Caching in Rails

November 9th, 2009 by Brian Michalski

Our Shuttle Tracking project has really taken off this year.  Our sites’ traffic is up 300% from this time last year and its been slowly growing as the cold weather sets in around the Troy, NY campus.  I suspect that the increase in students living further away from campus, either at Blitman Residence Commons or the Polytech Residence Commons, may be the source for a substantial part of this traffic jump.  That said, I haven’t taken the time to verify if the traffic is indeed coming from those locations, its purely conjecture at this point.

With the increase traffic to the site, several people reported pages (and associated AJAX requests) were taking longer and longer to load.  Most of the data you see on the map doesn’t change often.  Things like routes and stops might be adjusted once or twice a semester, hardly requiring a query to the database each time someone requests them.  Initially, I set out to do some simple caching in rails using caches_page.  It seemed like a pretty simple way to cache static pages, but unfortunately it was too buggy for what I needed it to do.  The controllers for stops & routes use respond_to to serve different formats of the same data, and caches_page didn’t cooperate nicely with this.  Firefox was smart enough to know that it wanted the HTML version of a route when it visited http://site/routes/1, but Safari and Chrome (its a WebKit thing) preferred the XML format of the request over the HTML version.  I believe this has something to do with the accept headers.

Also, I forgot about our JSONP callbacks enabling other sites to pull in our JSON feeds.  caches_page doesn’t look at the the URL param[]s when serving a request, so everyone would get the same output regardless of their specified callback.  I found that Rails has another caching component that can be used to cache views, but it logically comes into play after the controller has already done the database requesting.  I guess if my view referenced a render :partial or did some computationally intense work using that caching technique alone would make sense, but the slowdown here was on the database end of things.

The solution I came up with (currently in production), involves caching in the view and testing for that cache in the controller.  If the cache doesn’t exist, the database query is executed.  It if does, then no db work at all.  He’s’ some sample code:

Originally, my index method in the routes controller looked something like this:

   def index
    @routes = Route.find(:all, :conditions => {:enabled => true})
    respond_to do |format|
      format.html # index.html.erb
      format.xml
      format.js
      format.kml
    end
   end

I added code to check if a cache existed (we’ll define the cache in a little later view), resulting in the following:

  def index
    if !request.format.js? || !fragment_exist?(:action => :index, :action_suffix => 'js')
      @routes = Route.find(:all, :conditions => {:enabled => true})
    end
    respond_to do |format|
      format.html # index.html.erb
      format.xml
      format.js
      format.kml
    end
  end

You’ll note this code only caches javascript requests.  With some work it could probably be modified to cache more formats, but in my case the javascript JSON pages are getting hit the most.  The view caching is pretty straightforward, here’s the final result in index.js.erb:

<%= "#{params[:callback]}(" if params[:callback] %><% cache(:action =>; :index, :action_suffix =>; 'js') do %><%= @routes.to_json(
                       :only => [:name, :description, :id, :start_time, :end_time],
                       :methods =>; [:kml_url]
                       ) %><% end %><%= ")" if params[:callback] %>

The only difference in the view is the addition of the <% cache…%> and associated <% end %> tags.  Placement  is important.  Placing the tags outside the callback code (wrapping all the code there) would have broken the whole thing, incorrectly caching the first callback used or no callback at all if that was the case.

Tags: , ,
Posted in Shuttle Tracking | No Comments »

HTML/CSS Tutorial Notes from Nov 1

November 3rd, 2009 by Brian Zaik

Cascading Properties SlideI recently gave a lecture about HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) for members of the Web Tech Group at RPI.  But Brian Michalski recommended that I share my notes from the lecture with the world on the Web Tech Blog, so I’m doing that now.  This is the first in what will likely become a series of tutorials to help members of the team grow in their skills and appreciation for web application design.  Next time, I’ll likely employ some ZaikMagic (TM) in order to create an entire web app from start to finish, with an effective user interface to boot.

The notes from my talk are now online.  Please let me know if you have any questions.  This tutorial covered the basics of HTML and CSS, including the general structure for HTML pages, the block model in CSS, basic CSS syntax, cascading effects, and using floated divs for layout.

Download PDF (1.3 MB)

Tags: , , ,
Posted in Cool Stuff, Group Life | 2 Comments »

Clarification Regarding August 2009 Blog Post

October 29th, 2009 by Brian Zaik

A WTG blog entry “The Right Messages for the Right Places” posted in August, 2009, described a hypothetical deployment of a digital signage system based on Concerto. The article used the Los Angeles County Metropolitan Transit Authority, the LA MTA, as a fictional backdrop. It has come to our attention that some readers may have misinterpreted the article as a factual account of a real use of Concerto. This was never our intent. Concerto is not used by the LA MTA in any way, and we apologize for anyone who found our blog misleading in this regard.

Posted in Concerto | No Comments »

Imagine the Possibilities: Concerto and Mass Transit

October 29th, 2009 by Brian Zaik

I’d like you to take a flying leap with me for ten minutes. Concerto in its current form can’t make the vision I’m about to describe happen. But we can build the software. So come on, let’s sit back together and imagine the possibilities.  Think of this as a case study for the future: a hypothetical scenario of how a future version of the Concerto software could be used to add value to a space that is far removed from a college campus.

Enter the Subway Station.

It’s a busy Friday afternoon in a heavily populated city.  People are walking down the main thoroughfares, entering shops, tipping street performers, and talking on mobile phones.  But beneath the busy street is the City Subway, a public mode of transit that has become increasingly popular as the streets became more congested with cars and pedestrians.  The high-speed subway goes from one end of the city to the other.  And at every single station, there are bright digital signs.  Flat panel enclosures hang from above the tracks announcing train arrivals.  Digital signage is pervasive and greatly improved by the city’s recent switch from a closed proprietary system to Concerto.  Concerto – or at least a future branch of the codebase – is the ultimate communications tool, connecting consumers with products and services while generating impressive profits for the city.

The Right Messages for the Right Places

Concerto, by design, allows people and organizations with messages to either reach the entire area serviced by the City Subway system or target messages to specific Subway stations.  Concerto gives the Subway Authority (SA) the ability to customize the look and feel of Concerto displays to give each station a unique and memorable style of its own. But more importantly, Concerto integrates advertising messages with important Subway bulletins in a way that is both intelligent and flexible. For the screens hanging above each train track, the station information (train arrivals, schedules, and important alerts about delays and downtime) is always present in a right sidebar. Yet most of the screen is taken up by graphic ads that promote businesses, services, and organizations in the area surrounding the station.

Suddenly, a train arrives, and the graphics area is replaced by a large, graphic message that announces the train’s arrival for all Subway passengers looking to board. Within twenty seconds, the train is gone and the advertisements are back on all of the screens. And what types of ads are displayed on the hanging screens while passengers are waiting for trains to arrive? Well, let’s jump to the Grand Boulevard station in Downtown.  During the eight minutes he waited for his train to arrive, passenger Daniel was able to see 40 different ads from restaurants and boutiques in a nearby shopping center, a distant commercial plaza, and the other streets in the Downtown district. Each message was up on the screens for about 12 seconds. He discovered a new Japanese noodle bar that just opened up down the street from his work at America Bank, and he was also reminded to follow through with that donation to the Boys and Girls Club.

A Simple Gateway for Advertisers

Lynda works for a well-known ad agency in the city. When it comes to promoting a popular chain of coffee shops to the city populace, the Concerto Ad Panel (CAP) is her best friend. CAP really does it all: it collects flyers from Lynda’s computer in just a few clicks, tracks the number of appearances of her coffee shop ads across the city, and helps her manage her ad campaigns to get the most bang for her client’s buck. And yes, she pays for time on Concerto through CAP. All she needs to do is log into the Panel with her vendor account (given to her by the city), pick out a couple Subway stations where her message should go, select times of the day when the messages should be displayed, and upload a flyer to a category that best matches her intent (“Casual Eateries” works just fine). From there, a person working in the Subway Authority’s Ads office looks over the ad and approves it for Concerto right away.

There’s a new Christmas cookies sale that Lynda wants to announce to the entire city. So she decides to spend a little more of her client’s ad budget to pay for a citywide ad that will run for two weeks. She just fills out a simple form, uploads the message, and sends it off for verification. Within the hour, her message is ready to be shown thousands of times each day on every screen in every Subway station.

She can view daily, weekly, and monthly analytics to track how often her new message is being displayed across the network and in specific stations. CAP gives her a bunch of detailed yet easy-to-read charts that remind her of Google Analytics (software she uses for Internet advertising already).

The Subway Authority also recently added eye tracking cameras (connected to Concerto’s Hardware Devices Layer, which enables integration with web cams, button panels, and lots of other interesting hardware devices) to all of the hanging screens. These eye trackers reveal how often people’s eyes are actually looking at Lynda’s advertisements when they play. So she can get accurate statistics to give her an even greater amount of proof that her advertisements are being seen by the public.

Everyone Gets Involved

Commercial concerns aren’t alone in their use of Concerto. The city uses it to keep passengers aware of street cleaning hours, while local not-for-profits put messages up at reduced rates. Plus, Concerto’s Dynamic Text engine automatically searches the City Tribune (the only major print newspaper left in the city) and Google News for noteworthy national and city news tidbits, which are run on certain screens every once in a while to keep passengers informed. The Subway Authority’s small yet capable Ads office maintains the system and sets policies for using Concerto.

A Robust Management Interface

CAP also includes powerful controls for the Subway Authority to manage the network each day. Power settings can be remotely controlled from SA HQ, meaning that if a station needs to close for a period of time, all the screens within a particular station may be powered off at the same time with a couple mouse clicks in the Panel. CAP allows them to manage the entire system from a mile-high view and hone in on specific locations and screens, which can be customized in design in many different ways. Screens may be grouped together and managed together for simplicity’s sake. Concerto’s unique and powerful method of balancing feeds with different weights also works well here – the SA’s screen moderators can rank different feeds according to the interests of their passengers. If those interests change, a couple weight changes can quickly change Concerto’s behavior.

Convergent Cohesion

The City Subway Concerto network transcends devices to become truly pervasive. Because Concerto software is on the Web, it can easily appear on every device with a display and a connection to the Internet. In the Concerto world, the size, shape, resolution, operating system, and aspect ratio are all just screen parameters, useful for pumping the best possible picture out to the public. But they aren’t barriers.

In addition to the hanging monitors beside each train track, larger wallscreens run full-screen Concerto messages (along with useful, interactive web applications, such as a multi-touch enabled Subway map). Whereas the hanging screens can be run off of one single multiplexed computer, these wall screens are controlled by inexpensive machines that allow them to have layouts and mixes of content completely independent of what’s on those hanging displays. Yet they all access the same pool of messages, meaning that an advertising agency in a nearby suburb only needs to upload each one of their messages just once for it to potentially be shown all across the greater metropolitan area.

Furthermore, Concerto can also be integrated with websites and mobile applications for iPhone, Blackberry, and other platforms. So the SA’s cross-platform SubwayTravel app can also draw from this same database to direct riders to places of interest they may wish to include in their fun day of activities around the metropolitan area. There are many other web applications and social networks useful in getting the word out there – Facebook, Yelp!, and others. But Concerto fits into this ecosystem as the in-person broadcast medium for everything important on the Web.

Low Switching Costs, Large Rewards

Since moving from a supremely expensive commercial solution, the city has realized enormous gains from Concerto. The costs associated with switching over the 32 City Subway stations were relatively low, since the stations already had digital displays hanging over the train tracks. Metro Rail was already nearly equipped for Concerto. Over the course of several weeks, inexpensive display computers were added to each station. The Subway Authority purchased a powerful Concerto Content Server to power the whole network over the Internet.

And now, due to Concerto, the City Subway is generating impressive advertising revenues. These revenues come from local businesses and organizations, and they help to offset the costs associated with station upgrades and other municipal programs. Now, instead of fare or tax increases, the city is equipped with an extremely potent form of revenue generation that greatly improves citywide communications. Concerto has become a true asset for them.

NOTE: A WTG blog entry “The Right Messages for the Right Places” posted in August, 2009, described a hypothetical deployment of a digital signage system based on Concerto. The article used the Los Angeles County Metropolitan Transit Authority, the LA MTA, as a fictional backdrop. It has come to our attention that some readers may have misinterpreted the article as a factual account of a real use of Concerto. This was never our intent. Concerto is not used by the LA MTA in any way, and we apologize for anyone who found our blog misleading in this regard.

Tags: , , , , ,
Posted in Concerto, Cool Stuff, Tech Rants | No Comments »

Human-Computer Interaction Best Hits! (More Fun Than You Think!)

October 21st, 2009 by Brian Zaik

This semester I’ve been having fun with my Theory & Research in Human-Computer Interaction course with Professor Nathan Freier.  The class has been pretty awesome, with a lot of meaningful discussions about the past and potential future of computing.  I wanted to put out a couple links to the class blog to the essays I’ve written for the course, which I think have come out pretty well, but I’ll also suggest that you visit the class blog yourself to see all the goodies.  I think the other people in the course – grad students, mostly, but also some M.S. student like myself – do a great job introducing lots of meaningful topics in the HCI arena.  Think about it: computing and the windowed GUI haven’t changed much since the first Macintosh (OS X and Windows 95 have arguably brought the biggest sets of changes) in 1984.  Ubiquitous computing is still unrealized, and emotional computing is being explored but far from being anything but a pipe dream.  Where’s our augmented reality?  Here are the topics I’ve covered so far on the class blog:

  1. Jef Raskin: The Black Sheep Hero of the Humane Interface:  The father of the first Macintosh developed many new and noteworthy ideas about how computers should work for people.  He believed that we should drop the windowed GUI in favor of a more “humane” interface intended to work for human users, not the other way around.  And though he passed away in 2005 before realizing his ultimate vision for computing, his son Aza now has the opportunity to incorporate many of his old ideas into the coming generation of browser-based operating systems.  Oh, they’re coming.
  2. The Rise of Truly Emotional Computing:  We like to say that we can develop computers which act as social agents.  Sure, we all get pissed off at our laptops and throw them around, punch them a bit, and yell at them, but truly emotional computing – machines that can sense our emotions and adapt their behavior to accommodate to what they notice – haven’t yet been designed.  But there’s a lot of work under way in the EU.  I can’t do that for you, Dave.
  3. Back to the Drawing Board:  Our laws of old that are supposed to help us as designers to build computer interfaces that are well within the physical limitations of the human body are old and outdated.  They no longer work for new and exciting interfaces like direct manipulation, eye gaze tracking, or 3D.  We need to change our ways (and incorporate existing knowledge sets, with some updates) to fit the new “frontier” contexts of the future.
  4. Contact at the Expense of Privacy or: How Google Asked Me to Stop Worrying and Ride the Wave:  Google Wave is the super, whiz-bang communications medium of the future.  Or so Google claims.  But the privacy implications of this new technology must be incorporated into every stage of Google’s design for the system.  Wave promises to do away with all the old defects of email, but is that really for the best for all of us?  Do we really want our online friends to be able to see when we type and sign online?  Is removing the “barriers to communication” actually a completely good thing?

I hope you enjoy these other blog posts.  As I move forward with designing the future of computing, I’d like to hear your thoughts.  And definitely check out the rest of the posts from the course; I’m sure you’ll find days of excellent reading material.

Tags: , , , ,
Posted in Concerto, Cool Stuff, Other Projects, Tech Rants | No Comments »

Windows Sidebar Widget

October 13th, 2009 by Brian Michalski

I spent a few days last week re-acquainting myself with Windows Sidebar, a widget engine introduced in Windows Vista and carried over into Windows 7.  My goal was to create a Concerto widget similar in functionality to the screensaver so people who don’t use a screensaver as much could still get some Concerto content delivered locally.  While Windows Sidebar doesn’t support Windows XP natively,  having native support for Vista & 7 should be sufficient for now.

Luckily, there is no secret sauce behind widgets… not on Windows, not on OS X… they’re all just HTML which is really convenient for a web-based system like Concerto.  I started with a really simple design, copying almost all of the code to rotate content from Concerto mini-screen we introduced in our 1.9 update.  I had to tweak the javascript slightly to pull the XML/JSON from a different domain.  For some reason, jQuery’s AJAX methods couldn’t handle the cross-domain request so I had to switch to the manual method: Internet Explorer’s XMLHttpRequest.  It wasn’t very painful to substitute in for the .ajax call, and I was still able to use jQuery for all my selectors and iterators.

I got the widget working, but it kept freezing up on me in very strange ways.  The text in a div that displayed the content name would keep rotating, but the image above would freeze.  For the life of me I couldn’t figure out why this was happening, especially since the text rotation was setup to be handled when the image rotation had completed.  I decided to pull out my watch and see if the widget kept freezing at the same time, surprisingly it did.  I adjusted the time each image was to be displayed and tested again, measuring the same number of image rotations.  It seemed that after X image rotations the image’s ability to fadeOut, fadeIn, or have it’s src changed were getting stopped by some unknown process.  Time to fire up taskmgr where I could get a slightly better look at what was going on.

The memory used for the widgets (I had multiple open at a time) kept growing and growing which seemed to correlate with the sudden freezing of the image rotation.  I wasn’t totally surprised by the memory issues, the internal workings of jQuery’s chaining and binding have never been very clear to me.  While I don’t know the details, it looks like jQuery was attaching a completely new set of functions to each image when it was loaded.  Since there were functions attached to the image maybe it didn’t get garbage collected out of memory like it should… or maybe the duplicate functions activated some sort of nasty recursion chaining… I really don’t know.  I was a bit surprised we didn’t notice this earlier, since the same code was used on the Concerto mini-screen which was pretty much copy and pasted from the actual javascript used on our screens.  Internet Explorer, Firefox, and Chrome all showed a steady growth in memory when left on the mini-screen for a period of time.  We hadn’t noticed the leak before because all those big web browsers have much higher memory limits per tab, its not nearly as low as the allocation for 1 widget.  I also suspect we didn’t spend time running the mini-screen for a very long time.  The average person stays on that page for only a few seconds before clicking off to login, visit the wall, or download the screensaver, so stability over time wasn’t critical during the design phase.  Upon further inspection. it looks like we left out the line in the JavaScript from our screen code that destroys everything in the field….

Now the widget is ready to be passed off to someone with a bit more graphical design & CSS skill than I.  I suspect my background-color: red; will get stripped away in favor or something that flows better with Concerto.

You can check out the code here: http://dev.studentsenate.rpi.edu/svn/svn-senate/extras/concerto.gadget/

Tags: , , ,
Posted in Concerto | No Comments »
« Older Entries