Home > The Offive


The Official Blog of the Web Tech Group


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.

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.

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)

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.

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.

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 WaveGoogle 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.

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/

The Mint.com Story, with its latest chapter…

September 14th, 2009 by Brian Zaik

I diss TechCrunch a lot, because I really don’t think most of the “businesses” they hype up are actually promising businesses. But when a really killer product comes along, with a simple yet powerful idea and a strong team behind it, TechCrunch and the rest of Silicon Valley can really pave the wave to success. I want to share with you the newly updated story of Mint.com, as told by its CEO:

The Value of TechCrunch50: Mint Acquired by Intuit for $170m Two Years After Winning TC40

$170 million acquisition after 3 years. Not the biggest take-home prize ever, but still extremely impressive. And best of all, as a web application, Mint is so good because of its intense focus on usability and a phenomenal UI. If you haven’t used Mint yet, I wholeheartedly recommend trying it out – it’s free.

See, this is how Silicon Valley and Internet businesses should work. Mint has always concentrated on solving a problem (money management) in a way that also opens up actual means of making revenue (partnerships with banks and credit card companies to lead customers to personal savings AND newly opened accounts for those companies). They have ads, sure – their savings promotions are thinly veiled ads for their partners, but they also have a business plan and a great product. And they relied on free press, word-of-mouth marketing, and Internet presence to become successful.

I’ll be honest – we haven’t really had a quality ticketing/bug-tracking system of any kind since we began the Web Tech Group. We’ve moved from one product to the next, tried to build our own simple project management systems, and gone back and forth with different software packages. The road to massive win, as they say, is lined with fail. Among our considerations over the years were these systems:

  • Flagship Tasks. Flagship, our document management system that still looks like garbage from a UI standpoint, technically is a platform for a number of useful applications, including document management, project and task planning, and finances. But we’ve got a lot of work to do to build it up into a cohesive package. While we are going to re-release Flagship Docs with a brand new UI later this semester, it’s really been on the back burner for some time (Concerto generally takes most of our focus, for obvious and not-so-obvious reasons). In the meantime, Flagship just isn’t a compelling platform for our own project management. In a couple months, maybe the situation will be different…
  • ProjectPier actually wasn’t too bad when we tried it out two summers ago. While it’s free, open source software, it employs a method of organization that just proved too cumbersome for our interests. I had installed ProjectPier and sent the link to some of the other Web Tech people, and while we used it a little bit at the beginning, PP never really gained traction with others. It became obvious that the best tool is the one that people actually wanted to use regularly to keep our tasks and milestones up-to-date, but ProjectPier just wasn’t it, at least at the time.
  • Trac. Ah, Trac, our big elephant in the room. While Trac’s concepts of milestones and repository integration were both well regarded in our circle, it’s a big bloated piece of software that just didn’t really hold our interest for very long. We made a really strong attempt to use it, but I have to say that personally, I always viewed as a piece of software trying to be more than it deserved to be. It’s a case of being a Jack of All Trades and Master of None. Maybe we didn’t give it enough of a chance, but we mostly needed it for ticket and bug tracking. We didn’t need the wiki. We didn’t need pages. We just needed ticketing and milestone management. In the end, it just didn’t fit enough of us well, and we largely abandoned it.

Our latest ticketing suite is Lighthouse, built on Ruby on Rails by Rick Olsen and his other colleagues. Lighthouse has a good API that allows us to integrate our task management with our website, and it’s nice and pretty simple to use it to do what we need to do. So Lighthouse it is, at least until further notice. It’s free for open source projects. We’re now using it to track multiple open source projects, including Concerto and Concerto Screensaver, so check it out! Update 1.9.1 for Concerto is 50% complete, according to our Lighthouse dashboard.

Activities Fair 2009: Success

September 4th, 2009 by Brian Zaik

We just had the Activities Fair in the Houston Field House at RPI yesterday and a great showing for Concerto and Web Tech. We took up residence in a big corner right at the front entrance to the Field House. It was a good opportunity to introduce lots of people to Concerto Screensaver, but we also took the chance to tell people who we are in the Web Tech Group. And that was a pretty fun task, let me tell you…

I designed this big plotted poster to celebrate life through the eyes of a Web Tech Group member. If any of this sounds like you, I think it’s time you stopped by the third floor of the Rensselaer Union (the Student Government Suite, or SGS)! We want more people within our ranks – we can handle more people, and you DO NOT have to be a programmer to join. Graphic artists, electronics whizzes, marketers, carpenters, or just people who want to have fun and learn plenty about product development and help make a difference – you’ll all welcome. In fact, there’s not even a formal sign-up process! Just stop by the SGS and stay a while. If you don’t go crazy, maybe you’re crazy enough to stick around for longer as a full-fledged member of the team.

This was our big, crazy dedication to the life of the average Web Tech member...sound like you?

This was our big, crazy dedication to the life of the average Web Tech member...