BlowfishWorks.com

Organization:
Blowfish Works is a small, privately funded startup.

Title/Role:
VP of Mobile Applications: October 2006 — August 2007
The Mobile Applications group was to be expanded (at least a staff of 4 in 2007) but budget constraints limited the group to 1 person, me. This means the design, development, testing and deployment of the application server and the handset application (described below) were performed soley by me. A nice title, no staff, lots of work.

Technologies Utilized:
Java 1.5/1.6, J2ME, XML, JSP/HTML, JUnit, Ant/Antenna, Apache 2.2x, Servlets/Tomcat 5.5.x using clustering, Hibernate 3.2.x, MySQL 5.0.37 using clustering, Eclipse 3.2, Enterprise Architect 6.5, Subversion, PKI Security (openssl, https, keystores, code-signing, smartcards), Linux, Windows XP, Windows Mobile, ffmpeg and a variety of utilities for analysing/editing media encodings.
J2ME Specific: MIDP 1.0/2.0, CLDC 1.x, JSR-135 (Multi Media), JSR-75 (PIM/File), JSR-172 (Web Services), JSR-211 (Content Handler), EclipseME, Sun/Sony-Ericcson/Nokia/Motorola SDKs, J2ME Polish.

Project description:
Blowfish Works provides a system whearby users can receive advertisements/content, that they have an interested in, delivered to their cell phone (handset), and get compensated (paid) for watching it. The service has 3 primary components:

1. A website for advertisers. This interface provides a mechanism for advertisers to create advertising campaigns by selecting or uploading video content, specifying text (i.e., the advertising message) to overlay onto the video, and then selecting the demographic population of users that are to receive the campaign.
2. A website for subscribers/users. This interface provides a mechanism for users to subscribe to the system, complete comprehesive demographic information, designate how they would like to be compensated, and download the Blowfish Works Player to their cell phone.
3. The back-end content delivery system. This component actally has 3 parts: 1) the advertisement/content Player that runs on cell phones; 2) the application server that delivers campaigns to the Players; and, 3) the content generator.

The application server is responsible delivering content to specified populations of cell phones (i.e., users). The target population for a given campaign is decided at the time the campaign is created by complex scheduling algorithms that match user demographics with advertiser targeting information. From this is produced a kind-of delivery manifest consisting, in part, of users who are to receive the content of the campaign, generally a short video clip with an embedded advertising message. (See a conceptual example here.)

The content generator is loosely coupled to the application server. At the time the application server receives the delivery manifest the content has not yet been generated. For simple campaigns the content generation consists of taking video, audio, and text and blending them into a set of formats and encoding's that will match the capabilities of the cell phones known to the system. This results in a relatively small set of outputs. For more complicated campaigns the content is personalized to the receiver (e.g., the user's name). This results in a set of video files equal to the number of targeted users. The video can be generated dynamically or in batch.

The application server is also responsible for:

• Tracking the properties (e.g., phone number, cell phone model, model capabilities) of all the cell phones in the system and matching these with the user information.
• Managing all data conversations with the cell phones regarding content delivery and viewing statistics, as well as errors and model changes.
• Providing an auditable record of handset communication as it pertains to assigning compensation.
• Running 24/7

The Blowfish Works Player

The Player is the software that runs on the users' cell phone/handset. It is a J2ME application that communicates with the application server to download and play advertising content and reliably record whether the content was viewed. This last part is critical and a core feature of the Blowfish Works advertising system. Users get credit (i.e., some form of compensation, like $1 per ad) for viewing advertisements that are delivered to their phones. The Player must reliably detect that content is viewed or not and report that to the application server, and back to the advertiser. This is a primary and critical element in the company's value proposition and revenue model.

The Player also responsible for tracking content statistics like expired content (content never watched), how many views, when deleted, content failures (media players on cell phones aren't perfect), etc. Aditionally it provides features for saving content for viewing later, viewing saved content, dialing the vendor being advertised (an optional element of an ad), browsing to the vendor's website (an optional element of an ad), viewing account information. Debugging features include forcing uploads/downloads, sending log information to the server, viewing raw data stored on the handset, and resetting the handset to a just-installed state.

Things Learned/Issues Solved (not inclusive)

• Reduced the need for a great deal of fracturing. By analysing the various idiosyncracies across a variety of cell phones I was able to determine the smallest set of features/behaviors that needed to be specially handled -- like using flags to enable or disable a feature or action -- in order to maintain a common user experience using a single code base across the greatest number of handset models. With the population (families) of handsets I worked with this resulted in about 7 characteristics.
  
  
• Learned a great deal about the issues surrounding playing video on cell phones, including 'most compatable' audio/video encodings, approriate bit-rates and other encoding parameters.
  
  
• Identified certain performance characteristics regarding clustering Tomcat and MySQL which permitted expanding the cluster with predicatable performance results -- e.g., predicting how many additional cell phones can be handled by adding a new Tomcat server; does the additional server require an additional MySQL cluster server.
  
  
• Vastly increased my knowledge and understanding regarding all the idiosyncratic behaviors of J2ME on cell phones.
  
  
• Learned to design, develop and test J2ME code more reliably and efficiently.