I make apps for other people


Another job at work

Posted by Chris Jones
On August 25th, 2007 at 18:33

Permalink | Trackback | Links In |

Comments Off on Another job at work
Posted in Games, Work

I’ve been saddled with another task at work: helping to write game reviews. Sometimes, one of my sentences makes it through the editorial process intact, although often my notes, ideas, and comments are discarded.

It turns out that the video game editors have been busy with other things (like the GWEN pre-order key roll-out, which still got screwed up with only one key per account for any number of pre-orders) and apparently haven’t had a lot of time to write reviews. Since I play the most games of anyone in my group (a scary thought, considering how little gaming time I think have), it’s fallen onto me to look at videos, read websites, and help to come up with convincing looking previews of games that I’ve never had the chance to play. It looks like with this latest batch that the Sony PSP group wanted previews to help generate interest in pre-holiday releases. I feel like the blog at work was put up for sale . . .

If you send me a game, chances are I’ll be able to put a review on the blog. If you’re a publisher, you’d wonder why you’d send the games to me when I’m not in the video games group, or even why someone who doesn’t get to see the review copies would be writing reviews about the games. You’ll be just as confused as I am. 🙂

Debugging and missed my bus

Posted by Chris Jones
On August 22nd, 2007 at 15:59

Permalink | Trackback | Links In |

Comments Off on Debugging and missed my bus
Posted in Tech, Work

Too much debugging leads to missed buses.

Edit: It turns out that my bus broke down anyway, so being a little late didn’t matter. It was standing room only, overfull bus (one of the passengers was riding in the front entrance) but I eventually made it home.

Plogs redesign

Posted by Chris Jones
On August 22nd, 2007 at 14:17

Permalink | Trackback | Links In |

Comments Off on Plogs redesign
Posted in Work

Plogs V3 – The End of the Plog

==Plogs Use Cases to Support==
* Daily display
* Post discussions
* Author Central and Entity Blogs
* Post permalinks
** The Daily encrypted PLNK
** New SEO / directory pattern permalink
* Blog links
** Customer ID to entity mapping (for Author Central blogs)
** Customer ID to directory pattern (for non-entity blogs)
* Tag blogs
** Tag Customer ID to directory pattern
* Blog email subscriptions
** Rewrite Mason handlers to either remote hook Santana renderer or invoke blog service
** Email subscriptions are a subcase of multiple tag blogs
* Syndication
** RSS 2.0
** Atom
** Overload each blog view (daily, entity, tag)

===Plogs Use Cases to Deprecate===
* RNA – moves to Tag Communities
* Reminders – moved to Tag Communities
* Taba – dropped, no migration
* Enumclaw blogs – a special case of hooking a Santana renderer
* Blog subscriptions – notifications of blog content, if we believe is still of value to the customer, can be sent to Tag Communtiies

==High level data flow==
# An XML document containing syndicated content
# Ingested as a syndicated object
# Processed as a syndicated feed

===Syndicated Feed===
* feed metadata (URL, feed name, feed author, and other display information)
* a checksum of the feed content (to identify unchanged feeds)
* posts

For each post in a feed, create a checksum and filter the content.

* post metadata (permalink, datetime, update time)
* a checksum of post content
* description (plaintext)
* cleaned and filtered rich content (or the plaintext description)
* the original rich content (if included)

A checksum is the filtered alpha-numeric content passed through an MD5 hash.

content < = filter( [A-Za-z0-9], original_content )
checksum <= MD5( content )

===Post Entry Checksum===
If the full content is available (through Purl.org extensions or as an Atom feed):

checksum < = MD5( filter( [A-Za-z0-9], post_title + full_content ) )

Else, if only the plaintext description is available:

checksum < = MD5( filter( [A-Za-z0-9], post_title + description ) )

Checksums are calculated before filtering.

Posts without a title and without a description are discarded. Posts with no post title are renamed to a localized "Untitled".

===Feed Checksum===
The set of post entry checksums are joined as a single string and passed through the MD5 filter to calculate a feed checksum.

feed_checksum < = MD5 ( join( [ post0_checksum, post1_checksum, . . .  ] ) )

==Blog Links==
Blog links provide a way to access blogs via:
* the default view (a blog)
* an archive view (blog by month or day)
* a single post (a permalink)

Old Plogs links took the form of:
* /gp/blog/ACUSTOMERID
* /gp/blog/post/PLNKAPERMALINK

The customer ID and permalink are encoded versions of Amazon internal database identifiers. They have no special meaning and provide no SEO value.

/gp/blog is valuable real estate (as is /blog) and should point to either Amazon Daily or our top or most popular blogs instead of the customer’s personal blog.

===New Blog Links===
To improve the search engine value of links, blog links should now take the form of:
* /gp/blog/SEOName
* /gp/blog/SEOName/YYYY/MM/DD/Post-Title

The second form is the post permalink, which in the new blog system is the post ID. A more concrete example follows:


This is broken into several parts and acts as a filter:
* The blog or feed name part is unique in the blog system, case insensitive, safe UTF-8 for maximum SEO benefit, and is the entity or topic SEO name.
* The Year allows for paging through a year’s worth of content
* The Month allows for paging through a month’s worth of postings
* The Day allows for display of all the blog posts on the given day
* The Post Title differentiates between multiple posts on the same day. This won’t change, even if the post is updated multiple times during the day as long as the post’s original permalink is unchanged. Where the title from the original post is absent, we’ll use the original permalink title part as our post titile part. The post title is generated through an SEO filter.

Blog names may collide, especially where two authors have the same name. The order of resolution may be:
* The older title wins. This preserves current SEO value.
* If both are created at once, the higher glance view should get the preferred name.
* If a new blog is created that has a higher glance view, part of the highest glance view work, ASIN, or title should be appended to the blog name, such that a blog, “Stephen-King” would be renamed “Stephen-King-Dark-Tower”.
* If the offsite blog (through the feed metadata) has a unique SEO name for blogs, that can be used in the case of a name collision (where the offsite blog name isn’t the same as the artist name).
* Finally, the artist’s year of birth or death could be used to differentiate between two otherwise identical authors.

==Indexing Blog Content==
The new permalink provides a natural index to blog content. In addition to providing SEO friendly permalinks, blogs must support older permalinks to continue generating link authority.

* /gp/blog/post/PLNKAPERMALINK => post ID
* /gp/blog/ACUSTOMERID => feed name (including tag blogs)
* entity ASINs should point to the feed name

The feed name is a unique identifier for the individual feed in the blog system (as described above). The post permalink is the same as an individual post ID and is designed to not only provide high SEO value but also to allow intuitive prefix searches of blog content in a DBM or S3 DB:

Neil-Gaiman -- top level blog (get the most recent 10 posts)
Neil-Gaiman/2009 - get first ten posts of 2009
Neil-Gaiman/2009/04 - get first ten posts of April 2009
Neil-Gaiman/2009/04/09 - get first ten posts of 09 April 2009
Neil-Gaiman/2009/04/09/unsorted-mailbag - get the individual post

The front end and service are responsible for filtering traversal requests and limiting access to particular keys or bags of data. As an aid to users, 2009/04/09 should be treated the same as 2009/4/9, 2009/04/9, and 2009/4/09.

The post permalink is key to retrieving post metadata and content:


It’s the responsibility of the service to assemble the various bags into a coherent post or entry object to return to callers.

Finally, feeds may need to be renamed or removed:

Neil-Gaiman:metadata = { active = [ true | false ] , deleted = [ true | false ] , renamed = [ None | 'new-name' ] }

The front end should rewrite URLs as necessary to account for renamed feeds.

Finally pertinent data needs to be stored, but not necessarily retrieved on each call:

Neil-Gaiman:history = { create-date = 'YYYY-MM-DD MM:HH:SS' , created-by = 'some-id' , activate-date = 'YYYY-MM-DD', activated-by = 'some-id', delete-date = 'YYYY-MM-DD' , deleted-by = 'some-id' }
Neil-Gaiman:feeds = { { feed-url = 'some-url' , active = [ true | false ] , deleted = [ true | false ] , last-read = 'YYYY-MM-DD' , status = 'some-code' , last-error = 'some-error' , checksum = 'some-MD5' } , . . . }

Accomplishments and Goals 2008

Posted by Chris Jones
On August 22nd, 2007 at 13:50

Permalink | Trackback | Links In |

Comments Off on Accomplishments and Goals 2008
Posted in Work
    My highest business value activity of 2008: Reftag Heatmap

  • Developed initial version in a few hours, which inspired Sean Scott with lots of feature requests
  • Established early coding and development standards
  • Shared progress and results with team
  • Coordinated changes with the rest of the team – made sure members like Sushma got a chance to be involved, even though her time to devote was very small; or Amanda, who didn’t have a large role
  • Reconciled features
  • Adapted to changes introduced by the team
  • Worked within those changes to implement new features
  • Worked with Sean Scott to understand new feature requests and implement his vision for those features
  • Developed some techniques to make heatmap faster, more responsive, more reliable; especially the pulling of tags through multiple requests
  • Provided expert advice and continued debugging/feature requests as needed
    Plogs Ticket Reduction

  • Out of memory
    • Asked the team for advice, even where the advice didn’t pan out
    • Monitored the logs and memory status for a month to determine causes and evaluate possible solutions
    • Implemented the least costly fix for ticket reduction: don’t ticket when out of heap–the JVM and OS recover the memory at that point, and this doesn’t (in practice) indicate any serious problem with the host
    • Recommended a long-term solution (move PlogsFeedReader to a separate host)
    • Still have to resolve PlogsTargeterWorker out of memory tickets
  • Syndicated feed recovery
    • Implemented backlog item during end of and between sprint period
    • Side-effect: used more memory because of how Hibernate deserializes object trees; I have a solution but it involves rearchitecting the Plogs Repository layer such that objects are managed in a fixed pool and doesn’t allow us to take full advantage of the Hibernate library
    • Prevents embarrassing problems like having high profile blogs (Leaky Cauldron, other authors) from being disabled for months at a time
    • Zero administration solution: doesn’t require more time from CS or SDEs — notification takes place in existing post-flow-prod@ email alias channel
    • Could be run less often, but that only slows memory consumption, not removes it (c.f., Java caching of bytecode, objects; won’t GC until needed)
  • Escaped & entity in entry titles in syndicated feeds — fixed problem for Kindle and syndicated feed customers
  • Past efforts
    • Automatic syndicated feed expiration
    • Reduce logging errors in feed code, redirect feed error messages to separate log
    • Modify and update monitoring configuration for Plogs services
    • Automated recovery of major type of failed posting (Happenstance recovery job)
    • Auditing and review of key failure points in PlogsService (some changes implemented)
  • Ongoing
    • Identify low-hanging fruit — easy fixes for occasional tickets
    • Identify ongoing problems or trends — review Remedy tickets to find regular problems, develop solution to resolve or work around problem

  • Set up Plogs Reporting database, automated jobs — need to evaluate current business value with cbrucia@ (may be limited)
  • Developed automated reports — when their value dropped, they were removed (along with the maintenance needed to keep them up to date)
  • See also Reftag Heatmap
  • Use various monitoring reports to keep track of systems, identify trends, and verify warnings from patrol systems
  • Added or run reports as needed for cbrucia@ — June 2008 created syndicated feed report as part of ARMS metrics report page
  • Major reporting effort (four days or more) in July 2008. Created custom queries, month-by-month queries, and scripts to grab artist biographies and images for cbrucia@, sscott@, mchien@, and jyotsna@. Gigabytes of data were queried sifted to create raw reports which were later used by the business.
    Mentoring and Teamwork

  • Answer networking and systems questions for team members
  • Answer Java questions (some of our team members aren’t clear on fundamental or essential JVM concepts, such as how Strings work within a JVM)
  • Act as a sounding board for team members
  • Provide code reviews: I prefer to sit with the team member to do those
  • Participate in team activities: although my after work time is limited, I can contribute what I can within my limitations
  • Work with Will, answering questions, providing background, and asking the right questions to help him find the answers he needs. This ended up being informal, and took up at least a couple hours per week.
  • Participate in team meetings, asking appropriate questions and providing my opinion when appropriate
  • Begin to assume some of chne@’s duties and work:
    • May 2008 and ongoing: document RCX/QA Preflight and work with version sets for Mason code
    • July 2008 and ongoing: document Endless preflight changes
    • More Mason development effort (so far, this has been chne@ and sushuma@)
    Completed Sprint and some backlog activities (not comprehensive)

  • Beginning to contribute to auth content team goals
    • Lightbox CSS fixes: made IE and Firefox look more similar
    • Minor tweaks and page layout work as needed
    • Mason integration for TV series Lightbox (based on chne@’s work and advice for music lightbox)
    • Removed secret Plogs post editor
    • Added targeting debugging information to ARMS on syndicated feeds
    • Fixed overrides for flash player CSS classes
    • Migrated Plogs to HttpClient-3.0 (January/February 2008)
  • Email digest: still not done, but I’m gratified that Toby got stuck at the same point I got stuck at
  • Plogs activities and maintenance: these tasks are still something that are primarily my job and responsibility — it’s hard for the rest of the team to switch gears, and at this point I have to own Plogs from the database through the front end
  • The team is still significantly ahead of me in understanding these systems, the business rules, and the data
  • I still spend a significant amount of time each week (4-10 hours) on Plogs support, tickets, reports, etc.
  • On-Call support: constantly for Plogs, will be adding auth content. In June 2008, Auth Content began supporting Plogs in addition to me, although I still was called in for most every ticket. I also supported and resolved individual trouble tickets (such as fixing the display of biography text on artist blogs).
  • Amazon Daily editorial support: when jyotsna@ or cbrucia@ identify a problem, I’m the person who must solve it–there’s no other choice. Quite simply, I’m the sole remaining Plogs resource.
  • Ongoing maintenance of Plogs/development-1 version set (updates, syncing to live, etc.)
  • Integrated unbox-episode-widget.mi into TV series lightbox. Worked with Geetika Singla (geetika@) to integrate this code. Prior to that, integrated with the unbox-episode-new-buybox.mi and through that process learned a lot about Inca/Mason integration, dynamic handlers in JSF/Mason, and how AJAX works in this mixed platform environment. Continued to shepherd the process through testing and working with Geetika and the Unbox team to resolve bugs.

  • Provided Plogs review and participation in early June 2008 DDOS attacks (Plogs was indirectly impacted; blog on Video Downloads page was fetched over 260,000 times in a five minute period, over 2 million times in an hour-long attack on that URL)
  • Participated in 2008 Lease Migration — this is a significant investment in time and testing for service and host owners
  • Support during power failures and data center outages/networking problems (May and June 2008) — monitoring and recovery of Plogs services
  • (Starting June 2008) Support and documentation provided to Auth Content team on-call for Plogs content/services. Auth Content really doesn’t want to have to deal with it, though (Plogs is complicated and take a lot of time to perform root cause analysis when unfamiliar with the code base and business rules).
    Remaining 2008 Goals

  • I want time to design and implement a replacement for Plogs, an event streaming service.
    • Reduce infrastructure costs – no Oracle DB, minimal fleet (four to eight virts)
    • Meet future SLAs – LS2 widgets need to be ready to load content in less than 0.5 seconds; Plogs may take five seconds or more to render a page — LS2 content may take longer to render, but will meet SLAs
    • Reduce administrative burden – non-durable events, distributed/partitioned data store, take advantage of other Amazon services such as personalization/preferences
    • Provide alternative to teams that publish to Plogs today – as a simple tracker of events, those other teams would need to provide durable storage for their event data
    • Take advantage of trends in aggregation, display, user configurability, collaboration – Plogs is very Web 1.0, while LS2 would be a simple service that fits into Web 2.0 paradigms
    • Make this replacement essentially invisible to Plogs users – this won’t be 100% possible, but by being clever in the display of content and how LS2 is used, Plogs users will still have the Amazon Daily/Plogs experience, with more customizability and a faster infrastructure (albeit with slower content loading)
    • Make the service usable by other teams, and ready to hand over to Platform or another group on completion
    • Built an initial, production ready version of LS2 within a five week period
    • Toby won’t be happy, but I don’t believe LS2 is, in itself, a good candidate for a REST interfave
    • Fulfill any existing contracts we have with publishers, celebrity authors, etc., regarding Plogs content and availability
    • Ongoing design during Q2 and Q3 for LS2: high level design, working out some of the knotty issues, and figuring out how the service will be called, used, and monitored.
  • Get more on-track with catalog, product aggregator, and other key Amazon infrastructure components and services — some of this will develop naturally
  • Participate in more Amazon SDE activities: Plogs was very insular and we didn’t do things outside the team very often. Participating in the AWS Hack Attack, like the Builder Battle Royale, is key to getting me more involved in life as an Amazon SDE. Brownbags, POA talks, etc., while considered important were almost never attended by teammates, so I didn’t turn those into a habit.
  • Participated in July 2008 AWS Hack Attack.
  • I’d like to take the Networking at Amazon KNET course to better understand the Amazon networking infrastructure
  • I want to see time allocated to either complete work on the Plogs artist browse directory or to migrate that data into another system (title authority?) so that we can plan to retire ARMS
  • Migrate Remedy community-plogs-primary and secondary to rcx-auth-content; move CTIs
  • If we’re going to continue using Oracle as a repository for Plogs, I need to plan on partitioning some tables in the database. I need time to collect queries and analyze usage of the Plogs database to identify natural partitions, additional key columns that may need to be added, and update the Plogs software to work correctly within the newly partitioned schema
  • Plogs services, unless retired within the next year or so, will need to be changed to WSDL from ASDL as part of the Codigo-2.0 migration
  • Either develop or provide support for an Associates Widget for Amazon Daily — it looks like much of the administrative or management portion of this task is being done by Jyo, and development is (properly) occurring in Romania.
    Pain Points

  • Email: even with aggressive filtering, I get a lot of mail related to auth content, especially poorly directed Remedy tickets. Between Plogs and Auth Content, I’m spending nearly an hour each day handling email–when I don’t I fall behind and miss important notifications.
  • No comprehensive plan or documentation for handling auth content Remedy tickets
  • Auth content team relies very heavily on tribal knowledge and practices, even during sprints where URLs and documentation get passed around on a person-to-person basis. I feel that we fail to point to a single knowledge base, transfer individual knowledge into team knowledge (especially when building systems), and don’t get full advantage of the daily SCRUM — we report on time used. For example, our demos and testing are for TV series entity pages rely on multiple boxes to work: Alex runs the Java/Manaus/Inca portion, Chris N. runs the Mason/Gurupa, and integration on another desktop isn’t possible until after the sprint is complete.
  • I think I would have been more efficient on the auth content team if we had an ethic of pair programming while bringing in new developers. My experiences with code and development at Amazon are clearly, at least to me at this time, 180-degrees off the standard that is in place with auth content. This is great in that it exposes me to how the rest of the half lives, but it also makes me feel as if there’s a knowledge or practice gap.
  • Environments: auth content development overloads a typical desktop. Second or third desktops, or dedicated virts for debugging and development should be standard on this team.
  • I’m trying to keep up in two separate development worlds at once. Since I can’t work 12 hour days, I’m falling behind in both Plogs and auth content, especially when I perform administrative work (like maintaining this list).
    Examples of resilience and overcoming difficulties

  • Support for Plogs after the technical team left/was fired. I simply had to assume all the duties, including part of the codebase (most of the Mason code) that I had never had to maintain or work with. It really improved my Mason skills. Unfortunately, my ticket load and development work didn’t leave a lot of room for more time to support Plogs outside of scheduled time in each sprint.
  • I had to learn how to modify, support, and implement Mason-Inca lightboxes in order to integrate the Unbox episode widget. My findings were documented in the Authoritative Content Entity wiki and provides a high-level architectural overview and implementation hints to create and enhance lightboxes.
    Demonstrates architectural thinking

  • I always emphasize the architecture in discussions with Will Leslie, the intern.
  • When discussing features (including UI features), I try to find current architectural, usage, or design patterns and base my opinion of those on the existing patterns (such that our customers will find the UI consistent and exemplifying the Principle of Least Surprise).
  • I’m carefully (over the course of months) considering the architecture of LS2 and how to replace Plogs
    An opinion leader

  • I can primarily and most productively express my opinion (most of the time) when discussing UI issues. I feel vindicated when I share Chip’s opinion. On occasion, and when Chip hasn’t been there, I’ve been able to influence my other developers when discussing UI.

Sprint 7 ending 27 June 2008


  • Reftag modifications — full reftag report link
  • CSS updates for music entity pages
  • Integrate unbox episode widget into TV series entity pages
    Challenges Overcome

  • As a developer, I had an out-of-date idea of how and which unbox episode widget would be included. I discovered, after spending a significant amount of time integrating the wrong widget, that the new widget would be available before I had planned and that it would be called differently.
  • I had trouble getting my development environment/stack working properly. I ended up calling my co-worker’s CDWRenderJava and CDWDispatcher environments from my RetailWebsite installation. I had received a new desktop, but never got it fully configured during Sprint 7, so it wasn’t a solution (yet) to get around these testing problems.
  • Working with Geetika Singla of the USDigitalVideo team had its own challenges: the DV team has assumptions about how catalog, display, Mason, CSS, and Javascript work. Not knowing much about the digital catalog slowed my work velocity, and I eventually requested Geetika do some of the work that was closest to the digital catalog, recognizing her expertise and the best use of my time (working on other tasks).
  • I documented my work done so that other team developers will have an easier time working with lightbox development in a mixed Mason/Inca environment.
    Core Competencies Used

  • Broad and deep technical knowledge – The lightbox was an excellent opportunity to challenge and stretch my knowledge of not only Mason-Inca integration, but also Javascript, CSS, AJAX, as well as working with Amazon Mason components and performing remote calls to other services (such as Mason to Inca).
  • Business and infrastructure knowledge demonstrated – This was an opportunity to improve my business knowledge of Digital Video rather than demonstrate it. My gained knowledge was valuable to co-workers in the next Sprint (8). Linking Reftag Reporting to the Heatmap demonstrated my knowledge of Reftag reporting (in addition to Greasemonkey) and provided immediate business value to the users of the tool.
  • Leading role in development of enterprise system – My lightbox work was ancillary to the greater (team) goal of getting TV series pages ready for launch in July.
  • Knowledge of work done by other teams – This was my first chance to work this closely with another team (DV). Later, my knowledge of the team was valuable to my co-workers in the next Sprint (8).
  • Think architecturally – I documented the architecture used to develop and implement Mason-Inca lightboxes. I internalized this architecture, and was later able to answer questions my team members about how lightboxes work in this mixed-environment and help them with their own development and enhancements.
  • Drive software engineering best practices – I made sure my code was code reviewed and tested. I chose to take longer to develop and thus found additional bugs and problems that wouldn’t have been apparent if I had said, “Good enough!” when the code was first demonstrated to work well in early integration testing. I identified the sections of the code that I checked in which were intentionally badly engineered (because of how I had to call the Unbox episode widget) and made sure that my code reviewer and colleagues knew about them and what we could do to fix them.
  • Insightful contributions to team priorities and approach – My work leads me to develop new opinions based on my experience. This is communicated to the rest of the team: in task estimation and sprint planning, during daily scrums, and when helping the team prioritize work. In particular, my “black hole” tasks are helpful in identifying future roadblocks and either reducing their impact or warning about them.
  • Work efficiently and deliver the right things – We don’t have an open approach to tasks: we estimate the time needed and try to work within that limit. The majority of the tasks I complete are done on time and correctly. However, the most notorious tasks (about one quarter or less of the tasks I complete in any Sprint) are black holes and suck away time and development effort and hurt my overall contribution to the team’s effort. I always strive to correctly complete those tasks, even if they go beyond the arbitrary end of the Sprint.
  • Harmonize discordant views and find the best way forward – The team doesn’t generally have a lot of discord. Where we do, it tends to be in UI design. I always emphasize what is best for the customer.
  • Demonstrate reslience – Working with DV was a challenge. being flexible in my work to quickly adopt the DV widget and provide feedback (and receive feedback) about how to use their component was key to making my work in this sprint successful.
  • Mentor more junior members – Spent a lot of time answering questions for Will Leslie, the intern, assisting him with services, implementation, and architectural details. Prepared documentation for lightbox development for other team members.

Sprint 8 ending 18 July 2008


  • Reporting support
  • Artist profile, biography, image, and ARMS data extract
  • On call support: fixed biography widget display error (UNICODE not displaying properly; changed to HTML entities), working with Auth Content oncall to resolve Plogs tickets
  • TV Series Lightbox completion and assistance with Sushuma’s work on it (she integrated it with EMS)
  • Started split environment work — clustered Manaus and Gurupa on different hosts
    Challenges Overcome

  • Reporting took a huge chunk of time (about a week) out of my development effort. I interleaved my work as best as I could, but still lost significant time which hurt the burn-down on the project. Likewise, AWS Hack Attack hurt my effort on this Sprint. I had the rectify my feelings about lost development time versus the business value derived from my reporting work and efforts.
  • I had to dive into parts of Plogs and Community code I had never before touched in order to retrieve artist biography, profile, and image data. I reused some of my PI Standalone code to do this, but discovered my reports were inadequate for what the business needed to work with the data, so I took a second, then third pass over the report content to make it as portable and well-formed as possible.
    Core Competencies Used

  • Broad and deep technical knowledge – Significant work was done in Mason and Perl, reusing existing services, making a batch program that balanced execution time against system load, and creating useful output. Extensive SQL reporting was done during this Sprint, which requires skills not typically used by members of this team.
  • Business and infrastructure knowledge demonstrated – I expanded my knowledge of Community services, and demonstrated that I can work with those services to get business data. I worked with cbrucia@ and mchien@ to produce reports which generated real business value.
  • Leading role in development of enterprise system
  • Knowledge of work done by other teams
  • Think architecturally – I considered how to reuse the data extracted from Community and ARMS for Entity pages, and also considered if the best way to get this data and keep it up to date is to not store it in EMS. ARMS and Community may have latencies low enough for speedy entity pages.
  • Drive software engineering best practices – I particularly strongly emphasized good software engineering practices with Will Leslie in this Sprint. I kept aluthy@ apprised of check-ins and updates to preflight documentation.
  • Insightful contributions to team priorities and approach
  • Work efficiently and deliver the right things – Wow, it took a lot of time to generate Oracle reports. It’s sad to say that I was busy the entire week, typically seven or eight hours a day, writing reporting queries, reviewing results, formatting and preparing the output, and answering questions or discussing reports.
  • Harmonize discordant views and find the best way forward – Where Sushuma and I disagreed on development work I had done on the lightbox, I discussed my reasoning, explained my motives, and let her discover on her own why things has been done the way they were.
  • Demonstrate reslience – I had to abandon much of my development work during this Sprint for reporting tasks and AWS Hack Attack. I had to recognize that the higher business value may be in letting other people do development work while I work on metrics and improving my value and worth to Amazon as a whole.
  • Mentor more junior members – As always, answered a lot of questions and gave a few (short) lectures to Will Leslie, especially in the context of code reviews.

Sprint 9 ending 20 August 2008


  • Reporting support
  • On Call. Changed resolving group of Plogs ticket to one that AuthContent team members can resolve. Got numbers needed to acquire a USB dongle for AT&T 3G wireless SIM.
  • Development of tag library for reusable lightboxes. Discussed lightbox design with Alex Zhao.
  • Began investigating Plogs targeting problems (during downtime, on-call). Reset stalled targeting jobs.
  • TV lightbox CSS and layout fixes
  • Worked with Toby on Plogs configuration changes — gave him some leash to try to implement all the configuration changes on his own (while I was busy with coding) — unfortunately, this broke parts of PlogsTargeterWorker and PlogsService, but the services mostly continued working, if not perfectly
  • Added missing reftags and reftag indexes for elements in Music, TV, and Author lightboxes.
  • Finished getting Manaus working on second desktop, with development process in place
    Challenges Overcome

  • Problems with the Manaus framework for taglibs and pagelets meant that my taglib work went through four iterations before arriving at a working version. However, after the sprint, Alex and I discovered that the taglibs (as they evolved) were not going to work with all lightboxes.
  • I had to overcome some of my lack of familiarity with Ruby to assist the intern Will Leslie to get his jruby environment working for his service. There were significant problems, but my experience with building the BrowseBatchPI environment helped me to direct him to a working solution and resolve some of his path issues.
  • CIU/CVU firedrill: CIU/CVU libraries were changed such that form indexes started at 0 instead of 1. I implemented the changes and prepared a WIRQ, but the CIU/CVU team rolled back their changes.
  • Completed configuration of split CDWRenderJava and CDWDispatcher / RetailWebsite deployment, where CDWRenderJava and CDWDispatcher run on a separate workstation which syncs to my desktop (which runs Gurupa).
    Core Competencies Used

  • Broad and deep technical knowledge – I tried to apply my knowledge of J2EE and Java tag library development to making a reusable lightbox tag library. Unfortunately, I was stymied by the Manaus platform in this work, but (with appropriate code forking) I was able to get it working in Sprint 10.
  • Business and infrastructure knowledge demonstrated – For the CIU/CVU script change firedrill, I quickly identified where the changes needed to be made in the Plogs code, made the changes, and prepared the WIRQ (with some assistance in the steps required to file the WIRQ). This represented a chance to demonstrate my knowledge about the Plogs platform infrastructure and how it interacts with other Amazon products.
  • Leading role in development of enterprise system – This again demonstrated that I am usually the on-call, architectural, and development lead for Plogs.
  • Knowledge of work done by other teams – I had a big failing here because of the CIU/CVU process. If Chad Desjardins had not recently moved into Mark’s office, we wouldn’t have known the real cause and would instead have been blaming the recent JSF push, not the recent library change to CIU/CVU. In part, this demonstrated my lack of knowledge as to where we used other teams code, and what code belonged to each time, but it also demonstrated that I had poor contact with teams from which we consume code. This represents the impact of lost tribal knowledge.
  • Think architecturally – The lightbox tag libraries are an excellent example of thinking architecturally. The task was added by Toby while he was sick, but the implementation was left up to me. I sought, through collaboration with other team mates, consensus on a tag library design and made my best effort to propose a design that worked well within the Manaus/Inca platform. That the original design failed in this sprint is due to a technical limitation of the platform and the short-sightedness of the original developers of Manaus rather than a failing in the goal or approach of using industry standard libraries to develop a reusable lightbox tag library.
  • Drive software engineering best practices – Again, some work with Will Leslie in this sprint to review, suggest how to design or architect some parts of his process (especially how his service and updater jobs work together), and how to fit within Amazon’s development and deployment platforms. With the Lightbox tag, engineering best practices were brought to life through code, from how the code was written and documented, through the way it was deployed and made use of static resources.
  • Insightful contributions to team priorities and approach – I had primary influence on the lightbox tag design and development process. I was, as always and when appropriate, willing to ask questions and suggest actions that could be taken with tasks during the daily scrum. I rescheduled or deferred work when higher priority tasks were needed (such as the CIU/CVU fix) and limited work that could go on forever (such as tweaking the lightbox tags–they got to the “good enough to be deployed” stage instead of “such perfect code that the sight of it makes you cry” stage).
  • Work efficiently and deliver the right things – I approached my tasks with the goal of producing a deliverable. Where my efficiency suffered, it was either from environmental work (tweaking Manaus on my second desktop to provide a rapid development environment), library/platform problems (Taglib development bugs), process (waiting for a CR), or that this was new ground.
  • Harmonize discordant views and find the best way forward – Tag library design and use was definitely a chance to practice working with Alex and harmonizing our views. He knew how he wanted to use the tags, while I had ideas about how they should be used within a page. In the end, I was able to convince him that there weren’t many viable alternatives to my architecture, and that how he proposed invoking them wouldn’t work in all cases, while Alex was able to inform my architecture and provided some excellent ideas.
  • Demonstrate reslience – CIU/CVU and rearranging my schedule for a day (or two) to get that fixed, tested, then rolled back. Likewise, abandoning Lightbox at a “good enough” stage because there are other tasks I need to complete in this sprint.
  • Mentor more junior members – I worked a lot with Will, accompanying him with Mark to meet Chris V. Jones and learn about Ruby, as well as providing advice and showing him a couple things or places at Amazon he didn’t know about or know how to do (US1, US2, conference room projector use). I wrote evaluations for Toby and Sushuma.

Sprint 10 ending 8 September 2008


  • Reporting support – ETL query to determine if entities are artists or authors, reporting on ETL query results
  • On Call
  • TV lightbox fixes and debugging
  • Completed lightbox tags — stymied by Manaus taglib and pagelets under Tomcat
  • Met with author services and tried to get them to take ARMS. They need internationalized ARMS, while we could move this service to another team and treat it as a platform element. Victoria Griffith, Josh Canfield, Daniel Leng, Pavlo Korohod, Chris Brucia.
  • Completed EMWA widget implementation, changes to EntityDataService
  • Fixed TV episode lightbox: when series episodes aren’t available, don’t show the series header
  • Continued investigating Plogs targeting problems. Fixed configuration problems from Toby’s work on PlogsTargeterWorker. Got two workers started so that large backlog of posts could be processed.
  • Identified code that needed to be changed to support Jeff Bezos’ request to remove Plogs Lozenge Popover. Helped test, CR, verify change implemented by Chris Newell.
  • Secure cookie site-wide changes: support for Plogs; determined which packages contained changes that may need to be made, advised Chris Newell, performed CR for Chris Newell, assisted Amandy Luthy in QA testing Plogs and ARMS
  • Reporting: backfill of missing days in preparation for Jeff B. meeting. Support with queries against PLOG1NA. Ran queries and suggested problems with missing Amazon Daily readers.
  • Wrote ETL query to get artist/product group relationships. Developed script to associate the artist with the appropriate product group relationships in EMS. Deployed script to a build box and connected to HAM.
  • Began to mentor Ryan Berckmans from Waterloo.
    Challenges Overcome

  • Problems with the Manaus framework for taglibs and pagelets meant that my taglib work went through four iterations before arriving at a working version. However, after the sprint, Alex and I discovered that the taglibs (as they evolved) were not going to work with all lightboxes.
  • I had to overcome some of my lack of familiarity with Ruby to assist the intern Will Leslie to get his jruby environment working for his service. There were significant problems, but my experience with building the BrowseBatchPI environment helped me to direct him to a working solution and resolve some of his path issues.
    Core Competencies Used

  • Broad and deep technical knowledge
  • Business and infrastructure knowledge demonstrated
  • Leading role in development of enterprise system
  • Knowledge of work done by other teams
  • Think architecturally
  • Drive software engineering best practices
  • Insightful contributions to team priorities and approach
  • Work efficiently and deliver the right things
  • Harmonize discordant views and find the best way forward
  • Demonstrate reslience
  • Mentor more junior members – Began mentoring Ryan Breckman.

Sprint 11 ending 6 October 2008


  • Reporting support – ARMS/CAMS report rerun
  • On Call
  • Checked in ARMS/CAMS extract
  • Fixed automated import of Musician, Author, TV legacy contributor ID type from Data Warehouse into EMS. Worked with chne@ to integrate this into byline
  • Modified by-line: refactored entity-name utility, changed retail pages to point to entity name utility, worked with MA code review
  • Added division IDs to entity pages generated by Santana so that aluthy@ can better automated QA test those pages.
  • Many, many code reviews
  • Checked-in fatal logging API changes in Plogs code; tested and verified
  • Tried to work closely with team members on my changes, goals, and process
  • Fixed Plogs posting in Devo
  • Updated Plogs/development-1 version set
  • Didn’t succeed in getting PPD deployed to desktop; used Gamma for testing instead
  • Fixed EMWA text (widget change; world server string addition)
  • Met with jthimsen@, ahmedw@ to discuss Plogs architecture and applicability to providing similar to all Amazon customers
  • Verified PLOGS hostclasses and version sets were up-to-date for OpenSSL library change
    Challenges Overcome
    Core Competencies Used

  • Broad and deep technical knowledge
  • Business and infrastructure knowledge demonstrated
  • Leading role in development of enterprise system
  • Knowledge of work done by other teams
  • Think architecturally
  • Drive software engineering best practices
  • Insightful contributions to team priorities and approach
  • Work efficiently and deliver the right things
  • Harmonize discordant views and find the best way forward
  • Demonstrate reslience
  • Mentor more junior members – Began mentoring Ryan Breckman.

Sprint 12 ending 3 November 2008


  • Reporting support – ARMS/CAMS author ingestion
  • On Call
  • Completed ARMS/CAMS author ingestion except for one small piece (automating getArtists PI Standalone script). This ingestion process turned into a huge project.
  • Increasing Plogs maintenance. In addition to advising Sushuma on parts of Plogs for her email subscriptions, and meeting with the Artist Central team to discuss replacing ARMS, Plogs required more maintenance work.
  • Many code reviews
    Challenges Overcome
    Core Competencies Used

  • Broad and deep technical knowledge
  • Business and infrastructure knowledge demonstrated
  • Leading role in development of enterprise system
  • Knowledge of work done by other teams
  • Think architecturally
  • Drive software engineering best practices – Documented and improved author ingestion process. Cajoled teammates into documenting processes for script ingestion, restarting services, etc.
  • Insightful contributions to team priorities and approach
  • Work efficiently and deliver the right things
  • Harmonize discordant views and find the best way forward
  • Demonstrate reslience
  • Mentor more junior members – Continued mentoring Ryan Breckman.

Finished testing

Posted by Chris Jones
On August 21st, 2007 at 14:47

Permalink | Trackback | Links In |

Comments Off on Finished testing
Posted in Games, Work

I’ve finished using my blog as a guinea pig for testing features on Amazon Daily, at least for now.

My wife reports Chicken Play was a bust: she didn’t get to peck anything to death. I suggested she try the troll next time so she can smash things to flinders, but she went back to City of Villains where she slowly grew bored with that as well.

Poor analogy: data mining like working with dangerous substances

Posted by Chris Jones
On June 8th, 2007 at 12:25

Permalink | Trackback | Links In |

Comments Off on Poor analogy: data mining like working with dangerous substances
Posted in Work

Considering the size of my data set for my Plogs (Amazon Daily) reporting database, I can really only approach and make sense of it from a very macro view. I have to create views to summarize data to the point where they’re useful. Any individual customer’s interactions with the system are only used to identify criteria from which aggregate data can be selected.


The analogy that came to mind was that of the nuclear, biological, or chemical worker who has to work through surrogates, such as waldoes or telerobotics. The raw materials are so dangerous that the work must have an intermediary that isn’t susceptible to the poisons and dangers. In a similar way, my database is so large that it can only be worked with effectively through intermediaries.

Amazon Daily has better encoding support

Posted by Chris Jones
On June 5th, 2007 at 13:01

Permalink | Trackback | Links In |

Comments Off on Amazon Daily has better encoding support
Posted in Work

I deployed the latest version of the Amazon Daily feed reader with better support for Unicode characters. Although Java was perfectly happy passing around 16- and 24-bit characters, our in-house transport layers weren’t immediately ready for us to use them naively. Additionally, in a few cases I was using the wrong character encoding which caused nastiness like mangled foreign characters and fancy quotations turned into question marks.

Yow . . . overnight shipping -$5?

Posted by Chris Jones
On May 31st, 2007 at 15:22

Permalink | Trackback | Links In |

Comments (2) |
Posted in General, Work

As a stockholder, I shouldn’t be even mentioning this. I certainly don’t shop at this on-line store either (it’s not exactly my kind of store), but when I saw this promotion, my jaw hit the floor.
Endless free shipping plus
I haven’t seen a deal that good since PayPal gave me $5 to sign up. Plus, Endless will do free returns if what you buy doesn’t fit and always does free overnight shipping. There’s a strategy people use to make sure their purchases do fit, but it’s pretty obvious so I won’t mention it here, plus it hurts margins and my (partially vested) RSUs.

Still, free overnight shipping and five bucks off an order. Am I sure I don’t need new shoes? And Becky was looking at purses over the weekend . . .

Log4J lesson learned: working around a greedy logger

Posted by Chris Jones
On May 14th, 2007 at 15:13

Permalink | Trackback | Links In |

Comments Off on Log4J lesson learned: working around a greedy logger
Posted in Java, Work

Use Case: divert specific log messages while capturing all other log messages. Errors that happen because of a bad RSS feed or connection problem should go to a specific log, while program errors should continue to go to the existing log files.

Simple Solution: create a new logger and write feed errors to that logger.

Other Solution: when you can’t create a new logger, create a wrapper around Log4J to log messages to a specific log file, with changes to the log4j.properties file.

In the hierarchy of com.company.reader.feed, a logger is defined as com.company.reader.feed.FeedLog which lightly wraps Log4J logging methods. This FeedLog will need to be excluded from the parent logger(s) that already log its hierarchy, and will need to point to a different logging destination (file or database table).

Amazon Daily

Posted by Chris Jones
On April 17th, 2007 at 14:41

Permalink | Trackback | Links In |

Comments Off on Amazon Daily
Posted in Work

Amazon Daily was just released by my team at work. It’s been a labor of love, and some of my teammates have put in plenty of long hours (and late nights) over the past week to make sure that it worked as well as possible.