We added a twist to our Hackathon (which we'll get to shortly), but traditionally Hackathons are engineering-centric events: 24 sleep-deprived hours in which coders bang out the ones and zeros, and in the end some small glorious innovation transpires.

We hacked on lots of things, but a couple to note:

We Hacked Mobile

We have a reputation for our industry-leading mobile apps, and during the Hackathon we took the opportunity to expand into push notifications and position our platform to better support HTML5. This of course made our mobile initiative more buzzword compliant, but more important, it made our tools more accessible to a wider audience.

We Hacked Maps

Perhaps the highlight of the day was the maps hack. As we've grown, it's been difficult to keep up with all the new employees and where they sit. We'd been managing this with an (albeit impressive) shared spreadsheet. But at our Hackathon, some engineers bested the spreadsheet by integrating Google Maps with our employee Wiki. (Click on the screenshot to get an idea of why we're so excited about it!)

We Hacked Rooms

Yup, the twist was we incorporated the entire company, from accountants to executives—everyone hacked on something, and some hacked rooms. We've got nearly as many conference rooms as there are countries, and if we have an employee contingent from a country, it earns a room name. (Make sense?) Anyway, "Norway" got hacked with minimalistic Scandinavian furniture, painted landscapes and silhouettes of skiers, and, most important, an electric fireplace to make all the other conference rooms jealous.

A Great Success

The whole event was a blast. And although you can't superficially create innovation, Hackathons allow a unique opportunity to celebrate it. Getting the whole company on board was a huge success, and we're looking forward to our next Hackathon soon.

Functional Testing is a key component in any development process. Its main objective is to identify potential issues before they reach production and negatively impact eventual users. These tests tend to be time consuming, and are often described as the ‘bottleneck’ in the development cycle.

At this point, Automated Functional Tests kick in. Several tools are available to generate these UI tests (here at Medallia we use Selenium and HtmlUnit), but in general the test suites based on these frameworks rely entirely on the UI, making them unnecessarily time consuming and flaky. A particular suite that is aimed at testing a specific functionality requires a number of preconditions that are usually fulfilled by creating the various necessary components through the UI. As a result, a test that has the goal of verifying some small case ends up having a lot of boiling code that takes quite some time to execute, and also might fail due to inherent flakiness of the UI test.

One solution might be to have a common data set that all tests can access: a common starting point for all the suites. But that has another inherent problem that one prefers not to face: data dependency. Now you have a system where one test might interfere with others, and trust me, if there is one key feature that has to be maintained for the success of any testing framework -both at unit and functional level- it’s the independence of tests.

Our Solution at Medallia

As I explained before, we wanted a system that was reliable and fast, where we apply UI testing only to the portions of the test that we WANT to actually verify. Also, we wanted test independence so developers could focus on testing their feature and not worry about the rest. What’s more, with test independence it is possible to run all the tests in parallel, reducing the length of each test cycle. Additionally, we wanted our framework to be easily extendable, where all the components are reusable, in order to minimize the time needed to create a new test.

In order to achieve these objectives, we came up with an automated framework that is based on three main modules:

• Components: A "bean" that represents any entity of the application. For example, the component User that contains a name and a password.


• Commands: A method that performs an action using the components. For example, createUser(User) or deleteUser(User)


• Facades: An interface that groups the commands by functionality. Following the same example, a UserFacade should contain the commands createUser and deleteUser(User)

Then we provided different “implementations” of those facades and finally we created a system that picks the right implementation of the specific functionality for each test. In addition, we built a basic QA Api that is able to receive different commands and create data in the backend (in our case it is mainly calling the create method of the different components we have in the production system, but it could be done by opening a DB connection, or even better, you could use the production API if your system has one).

Simple Example

Let’s illustrate the basic behavior with an example:

We have our “User” interface that defines two methods:

Then we have two different implementations of that facade:

In the actual framework, each ImplementationFacade does not directly implements the Facade, so there is no need to implement on each ImplementationFacade all the commands defined in the Facade.

Now there is a mechanism that runs an algorithm every time a test calls a method of the interface, to check which implementations have that method available, and will then execute the implementation that has the highest priority (lowest number). You can also force a command to run under a specific implementation.

For example:

These two tests end up doing the same thing: they both create one user and then deletes it. The difference is that the first one is going to create the user through the UI and then delete the user through the QA API, while the second test does the opposite.

This approach gives us several advantages:

• We only do the UI testing of the particular logic component that we want to test (in this example all the assertions that the component was successfully created are missing, but it is quite simple to code those assertions with Selenium).


• Our tests are not tightly coupled with a specific implementation. This offers us two main advantages:
  
  • In the future, if we decide to use another tool (rather than Selenium), we can simply create a new implementation using that tool and almost no change has to be made to the tests)
  
  
  • If at some point we have, for example, a production API that allows us to handle the creation of the components, we simply have to create a new implementation of a facade, assign it a higher priority and then all of our tests will begin using that implementation with no change at all!


• We have a fast and reliable way of creating all the components needed in the preconditions without going through the UI. If a test needs to have five different users, simply call those ‘create methods’, then enable UI testing, and you can test your functionality from there.


• The commands are completely reusable, once a method is created, it is automatically available for any other test.


• You can have one command that will create a basic entity from scratch (for example a company with X number of users, Y locations around the globe, etc.), so that all the tests can call that command at the beginning and have a fresh new entity, that no other test uses, achieving data independence.

We are still working in the final details and we hope that at one point we will be able to open the code of the framework in order to share it with the community.

About 3 years ago we switched from Subversion to Mercurial which allows us to improve our workflow by keeping all features on separate branches until they are ready to be merged. Each release gets its own integration branch, and these are numbered sequentially; our current release branch is called e55 and the next will be e56. Once a feature has been developed and tested, it is merged to the next release branch.

At the top, the two latest release branches are listed, followed by the unmerged branches for each release branch. It also shows the case number in our bug tracker, who made the last commit on the branch, how long ago and how many tests failed. Clicking on the changeset link shows which tests actually failed:

This screen shows the last few commits on the branch, which tests failed and the execution time of each test. Notice that each test is actually run four times for each changeset; they are run in different order to allow us to detect code which depends on static variables being initialized by other tests.

Finally there is a tree view which makes it easier to visualize branches and how they are merged:

Clicking on a node in the graph moves the viewpoint to that node, thus making it easy to navigate around in the tree. By default one level of children and 5 levels of parent are shown, and these can be adjusted as necessary.

Together these tools make it reasonably easy to keep track of our repository and manage all the branches. So how is all of this implemented? The web interface is pretty simple: the output from 'hg log' is parsed and used to build a representation of the tree. We use dot to draw the graphical tree view.

Actually running the tests is a bit more interesting. We have a stand-alone program which executes 'hg pull' every few seconds to grab any new revisions pushed to the repository; once it finds a new revision it hands it off to a separate thread which then compiles the code and starts a separate Java process which actually runs the test cases. This process writes the test results to an XML file every few seconds so we don't have to wait until all the tests have completed before seeing any results (quick feedback is very important).

Since the tests require a lot of resources to run, we actually use several servers to run them; ssh is used to execute commands and start the tests on remote servers, and they write the test results to a shared NFS mount. This way we can test as many changesets concurrently as we want (just limited by how many servers we want to dedicate).

The system is completely automated and thus requires little maintenance. A big advantage of a home-grown system such as this is that it is simple and integrates everything we need in just a few screens. It also makes it easy to add other useful features, such as integration with our bug tracker, so that it shows which features have actually been merged to the release branch.

At Medallia, a key component of our system currently works with an open source relational db. Since this component mainly queries the db entries by key, we want to try to switch to a key-value storage system and take advantage of several benefits provided by such a system, including distributed replication, load balancing, and failover. One of our objectives is to re-architect this component in a way that will allow us to achieve horizontal scalability, that among other things will help us alleviate the high disk storage requirements we currently have.

Recently we took the time to look into this (and other technological improvements too, exciting times at Medallia right now!), and we reviewed several options. To make a long story short, we ended up with two finalists, Apache Cassandra and Project Voldemort.

These two projects seem to be the most mature open source options in their class, and both provide a native decentralized clustering support including partitioning, fault tolerance, and high availability. Both are based on Amazon's Dynamo paper, but the main difference is that Voldemort follows a simple key/value model, while Cassandra uses a persistency model based on BigTable‘s column oriented model. Both provide support for read-consistency where read operations always return latest data, which was a requirement for us.

Project Voldemort

While not an exhaustive list, these are the most relevant pros and cons we identified when reviewing both stores:

• Pros
  • Simpler API
  • Persistency based on Berkley DB, a mature and well-known key/value db
  • Uses Vector Clocks instead of simple timestamps. It doesn't need the nodes (or clients) clocks to be synchronized
• Cons
  • No built-in support for "multiple data center"-aware routing (meaning there must be 1 copy of each key in at least one data center)

Apache Cassandra

• Pros
  • Broader range of systems in production (Facebook, Twitter, Digg, Rackspace)
  • Richer API which supports values with a dynamic column structure. The columns can evolve independently, meaning that you can update one column without reading the whole structure.
  • Optimized for writes (by design)
  • Configurable consistency level (specified on each request)
• Cons
  • File format is still in development, changes to the internal structure are likely to happen. Due to the flexibility it provides, the file format is more complex and harder to reason with, especially in terms of performance
  • Requires Clock Synch (NTP) (for nodes and clients)
  • Reads are more disk-intensive than competitors
  • Doesn't support client conflict resolution, so the latest update always wins

Performance Tests

To our surprise this was the only link we’ve found that compares the performance for both projects – thus we decided to write this post to share our research. We used the vpork test framework, which we modified to suit our needs by upgrading the client code to the latest versions, adding a warm-up phase, and adding rewrite capabilities. These are the results of our tests:

Setup:

• Versions
  • Voldemort v0.80.1
  • Cassandra 0.6.0-beta3
• Boxes: 3 similar nodes with the following spec:
  • 4GB maximum heap size
  • Replication parameters: N=3 (replicas for each entry), R=2 (nodes to wait for on each read), W=2 (nodes to block for on each write)
  • 8 processors on each server (Intel(R) Xeon(R) CPU E5504 @ 2.00GHz)
  • 1TB disk space (Seagate ST31000340NS, 7200 RPM, 32MB cache)
• Persistence parameters
  • Voldemort (default values)
    • key-serializer: string
    • value-serializer: identity (byte array)
    • persistence engine=bdb (Berkley DB)
    • bdb.cache.size=1536MB
  • Cassandra
    • ColumnFamily definition: CompareWith="BytesType" RowsCached="10000"
    • ReplicationFactor=3
    • Partitioner=org.apache.cassandra.dht.RandomPartitioner
    • ConcurrentReads=16
    • ConcurrenWrites=32
• Tests
  • Client Threads: 40
  • Initial load: 5 million records - records present before starting each test
  • WarmUp: 20K records - initial writes before measuring time for each test
  • Number of operations per test: 500K

We ran tests for 4 different write-rewrite-read configurations. A write is equivalent to a put operation with a new record (non-existing key). A rewrite is a put operation with an existing key. A read is a get operation on an existing key. These are the configurations we tested:

• 50% Write 50% Read
• 10% Write 40% Rewrite 50% Read
• 50% Rewrite 50% Read
• 90% Rewrite 10% Read

We ran all the tests for two different value sizes, 15 and 1.5 KB. Even though we evaluated different options, for our current needs, the last one with a 15 KB data entry was the most representative scenario.

The first pair of charts shows the latency, or average time it takes a read or write operation to complete in each case. Lower values are better. As expected, Cassandra write (and rewrite) times were consistently faster than Voldemort, while read times varied a bit depending on the scenario but were more or less the same in general.

The second pair of charts shows the maximum time in the best 99% of cases; again lower values are better:

On the front-end, we have a write-back cache which means that write operations don't affect the user experience. On the other hand, read operations are directly related to page loads. That's why we were concerned about the peak for Cassandra read in the last scenario for 15KB. We ran some further tests to measure the 99.9% and 99.99% percentiles and the difference was even greater: 5050 ms for Cassandra and 748 ms for Voldemort in the first case, and 9176 ms against 1129 ms in the second case. This huge difference was a key decision factor for us.

Finally, these two charts show the general throughput in terms of operations (read or write) per second. In this case higher values are better:

Notes:

• Cassandra commit log and data folder are supposed to be placed at different disks to improve performance, we tested with both on the same disk.

Issues found while testing:

• Voldemort client.put(K key, V value) (not the one that takes a Version object) throws ObsoleteVersionException if called with the same key from different threads. The javadoc states "Associated (sic) the given value to the key, clobbering any existing values stored for the key. ", so this was not expected.

And the winner is ...

I think there is no clear winner, in general terms. The best option depends on many factors that each company has to evaluate. My preference changed a few times during the review and tests.

Having said that, we had to choose one, and we decided to go with Project Voldemort. The main reasons were the simplicity, better versioning control, persistency layer maturity, and latency predictability.

We are currently developing the new solution, and it will take some time before we can put it in production, but we wanted to share our preliminary results with everyone who is considering one of these two options, so they’ll have one more tool at the time of the decision.

We'll keep you posted on how it goes.

Diego Erdody
Lead Software Engineer

Other useful articles comparing different key-value stores:

• http://blog.endpoint.com/2010/03/nosql-live-dynamo-derivatives-cassandra.html
• http://www.vineetgupta.com/2010/01/nosql-databases-part-1-landscape.html
• http://arstechnica.com/business/data-centers/2010/02/-since-the-rise-of.ars/2
• http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/
• http://bhavin.directi.com/tag/memcached/
• http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/

Medallia is a fast-growing, profitable, privately held technology company located in the heart of Silicon Valley, in Menlo Park, CA. We build great Software-as-a-Service (SaaS) based solutions for Global 2000 companies, and we have a 100% client recommendation rate. More than 50,000 businesses and business units use our products to gather, analyze, and act on feedback from customers, partners, and employees, including Fidelity, Four Seasons, Sephora, Hyatt, Gap, and Lego. Our customers delivered more than 400 million survey pages using Medallia in 2009 alone. By adopting Medallia’s products, companies can better understand and adapt to customer needs. More satisfied and loyal customers, in turn, help generate better business results. In fact, measured in terms of market capitalization, publicly-traded Medallia customers have outperformed the S&P 500 10X since 2003 and 4X since 2008.

Medallia is also a great place to work, with an unconventional, creative, collaborative, intellectual, and positive environment. We have an unusually low turnover rate, with less than 10% of employees voluntarily leaving the company, and most of those for reasons unrelated to Medallia — like to join a spouse relocating to Europe. Of the few employees who have left, 30% have actually returned! We are also finalists for the SF Times best workplace award, which will be awarded in the coming weeks. We hire inspiring people you will like working with. To find out more about our company culture, please visit http://medallia.com/careers/opportunity

We actively seek talented people for the following positions:

1) Software Engineers
We are hiring java experts at all levels - entry-level, senior, and lead positions. If you are a passionate programmer who lives and breathes to develop innovative algorithms, please check out our full job descriptions below:
http://www.medallia.com/careers/position/software-engineer/
http://www.medallia.com/careers/position/senior-software-engineer/

2) Summer Software Engineering Interns
We invite student java experts to spend the summer working on innovative projects with us, including data mining, visualization, and more. We welcome students who are looking for an opportunity to apply their research work to practical problem solving that we can incorporate into our application. Preference is given to students within one year of graduation, but exceptional java developers will be considered at any point in their education. Apply soon, as these positions are filling up quickly!
http://www.medallia.com/careers/position/2010-summer-engineering-internships/

3) Operations Engineers
We are looking for both Operations Engineers and IT/Systems Administrators who will enjoy working with our talented software engineers and client services team to keep our application running smoothly.
http://www.medallia.com/careers/position/operations-engineer1/
http://www.medallia.com/careers/position/it-systems-administrator/

4) Web/Graphic Designers
We seek someone with an impressive online portfolio to play a key role in designing our web and print presence through new web site initiatives, as well as the development of marketing materials (both
print and online).
http://www.medallia.com/careers/position/web-graphic-designer/

5) Office Assistant/Admin (30 - 40 hours per week)
We seek a smart, friendly office assistant who multi-tasks well and is able to work with minimal guidance. The ideal candidate will have a car available for running errands, and will be available to work 30 or more hours per week, including weekday afternoons until 6:30 pm.
http://www.medallia.com/careers/position/office-assistant/

6) Client Service Managers and Senior Managers
We are seeking Client Service Managers and Senior Managers who can take ownership of specific Fortune 500 accounts from the first day. Medallia’s Client Services Managers build deep relationships with top management at client companies, leverage those relationships to understand underlying client needs, then channel Medallia’s engineering and management resources to address those needs – often through innovative software solutions.
http://www.medallia.com/careers/position/client-services-manager-senior-manager/

7) Analyst and senior analysts
We seek quick-learning, articulate, and analytical members of our client services team, where responsibilities include a blend of account management, project management, data analysis, product
development, and business consulting.
http://www.medallia.com/careers/position/analyst-and-senior-analyst/

8) Product Marketing Manager
Medallia is looking for an enthusiastic and talented product marketer to partner with our product and marketing teams and develop compelling collateral and provide key strategic contributions. The ideal candidate for this position will have demonstrated cross-functional leadership.
http://www.medallia.com/careers/position/product-marketing-manager/

9) Staff Accountant
We are seeking a Staff Accountant with working knowledge of the general ledger function and US GAAP for internal corporate accounting. This position will support much of the general ledger
activity in our US parent company as well as for two foreign subsidiaries.
http://www.medallia.com/careers/position/staff-accountant/

To apply, please review our hiring process at http://www.medallia.com/careers/hiring-process, and then send your resume and cover letter to jobs@medallia.com, with the job title in the subject of your email.

This project started as I explored ways to view lyrics while listening to my music library on the iPod Touch. Ideas kept coming and I added some concepts (and code) from iMovieMash.com plus great content from the multitude of public video, music and search APIs.

The result was iMusicMash.com, an iPhone and Android G1 social web application that takes your music experience to a whole new level of enjoyment and discovery. You can start with the friends' playlists we already have or load your own iTunes music library. The interface is familiar as it mimics the iPhone's iPod. For each artist, we bring photos from Yahoo Boss Image Search, concert dates from Eventful, and live Twitter discussions. Then, for each song, we bring great YouTube videos, lyrics from LyricWiki, similar songs from Last.fm, and friends' songs for the same artist.

I recently added lyrics search and artist/title search.

iMusicMash was a winner in the Yahoo Developer Mashup contest at the recent Mashup Camp in Mt. View, California.

We don't access the mobile device's music library directly, rather, we have a utility with which you can upload your iTunes XML file to iMusicMash from your desktop or laptop. We provide you a personal URL so that you can bookmark your library to appear on the mobile site's home page. (iPhone icon is available if you click "+").

These are some of the API's I used:

YouTube
(for music videos)
http://code.google.com/apis/youtube/2.0/reference.html

Yahoo BOSS Search & Image Search API
(for artist images and lyrics search)
http://developer.yahoo.com/search/boss/boss_guide/

Last.fm
(for similar songs)
http://www.last.fm/api

Seeqpod API
(for MP3s)
http://www.seeqpod.com/api.php

Eventful API
(for concert events)
http://api.eventful.com/

Twitter API
(for discussions on each artist)
http://apiwiki.twitter.com/

Al Nevarez
Product Manager

• Make it trivially easy to write good test cases
• Reduce boilerplate code to a minimum
• Avoid static state through dependency injection
• Strict M-V-C separation
• Prefer convention over configuration

One of the most important feature of a framework is to facilitate testing; Spiderweb includes a testing framework that makes it trivial to write comprehensive test cases; a complete test, excluding the class and method declarations, can be written as:

assertHasContent(action(), "foo", "bar");

This will actually test the whole stack; HttpServletRequest and HttpServletResponse objects are instantiated and passed in to a servlet instance, and the data written to the response object is what is actually checked. The above checks that rendering a page without any request parameters returns a page that includes the strings "foo" and "bar".

Request parameter parsing

The HTTP protocol is text based, which means that any web application needs to parse request parameters into proper data types; this includes integers, enums and any custom data types defined by each application. This code tends to either be duplicated or at the very least need a method call for each request parameter to convert it into the right data type. Spiderweb handles this via a proxy interface which is dependency injected. Custom parsers can also be added easily.

Dependency injection

A web application often has several services and / or background tasks that are configured and instantiated when the servlet starts, typically in the Servlet.init() method. Since each module of the application typically needs to use a different set of these services a way to get references to the objects is needed. Often this is done by putting the references into static variables or having an object that has references to all the services and pass this object to all modules of the app. Both approaches make it difficult to determine which services a given module needs.

Spiderweb solves this problem by dependency injecting the needed services; the dependencies are thus documented simply as a list of arguments.

M-V-C separation

M-V-C is the preferred approach for an application that presents a UI, however, it turns out that, for a number of reasons, it is hard to keep this separation in practice. Spiderweb attempts to solve this problem by using StringTemplate as its templating language. StringTemplate was developed specifically to make a templating language with enough expressive power to make it useful, but no more. The author of StringTemplate wrote a paper going into detail on the motivation for StringTemplate.

Spiderweb goes a step further requiring all attributes used in the template be listed using TypeTags; these tags serve both as documentation for the template as well as a type safe way to set attributes.

Convention over configuration

Paradoxically having no choice can often be liberating; if there is only one way to do something the focus can simply be on actually getting it done.

Configuration for a web application tends to be very repetitive since most teams, if they are well organized, will adopt conventions to avoid having to check configuration files all the time. The configuration is thus copied and pasted each time a new module is added. In addition to being extra work this duplication also increases the maintenance burden.

Spiderweb solves this by having no mandatory configuration (beyond the minimum required for a Java Servlet). A URI maps to a name of a class and the URI is valid if that class exists. Various parameters can be changed, however, but this is typically done by method overriding instead of external configuration files (which cannot be automatically refactored and are not checked at compile time).

A tutorial that goes through writing a simple application can be found here.

Never rent a bad movie again. I created iMoveMash.com after renting one bad movie too many at the local supermarket's DVD rental kiosk. The free-wifi sign near that kiosk and my long time interest in mobile applications sparked an idea to help movie lovers make better rental decisions.

The resulting mobile web application integrates 7 data sources, including DVDPlay's kiosk content, Blockbuster's latest movies, IMDB movie ratings, Kids-In-Mind movie ratings, YouTube, Yahoo Movies, and Google Maps.

iMovieMash lists the kiosk's or Blockbuster's new movies in descending IMDB movie rating order (best movie first). Each movie I list is also a link to Yahoo Movies and search results from YouTube's API. The YouTube search query is biased in a way that is likely to return trailers or videos related to the movie itself. When clicked, the YouTube results launch the native YouTube application in the iPhone or iTouch.

iMovieMash took 2nd place at Mashup Camp 6, where I demo-ed the application dozens of times in 5 minute "speed geeking" sessions. That was a good bit of fun, and re-enforced the concept that successful products have a simple message, solve a real problem, and look good.

The application was developed with Perl for the backend and the IUI iPhone framework for the front end. It looks best on the iPhone or iTouch, but runs fine on a Blackberry or any web browser. Just goto http://imoviemash.com.

    

It's the day after I decided to join, and it's time to get motivated. I was a bit worried about my recent injury in my back and that my knee had been bad for a couple of years, so I figured I could ask my physiotherapist on my scheduled meeting that day. When I told her I was going to run marathon.. in 4 weeks.. first, she looks at me with a you-gotta-be-kidding look, and somewhat kindly explaining that running marathon was NOT the smartest thing I could do in my situation.. My back would probably survive, but my knee is most likely to get a lot worse! But after a while she, after realizing I was already at the point of no return, was indeed helpful and gave me some advice to help me along the way. I proudly told her I at least had a really good pair of shoes to run with, although a couple years old they weren't really used much yet and as good as new! "And how are you supposed to be able to finish a marathon if you haven't used your shoes the last couple of years" was her reply! Hmm, she had a point there - it's was time to get started!!

When it comes to motivation, Max definitely played his part by sending me some of his "research".. Hmm.. did anyone mention knee injuries?! So, in conclusion; life won't be much fun if we always stick to what's smartest, now, would it?! Sometimes it now always about getting to the end of the road, it's HOW you get there!:)

:: The training ::

Max had already been training for two weeks, that's like 50% of my total training time, so I would have to work pretty hard to catch up! And Max was very well prepared indeed; maybe a bit too prepared someone might have said! With his brand new GPS running computer, new shoes and a lot of research of how to actually do this think in one month!

We both had the same goal, to finish without major injuries! We used, however, two pretty different strategies to get there. I was most concerned about the last part of the goal; "without major injuries". On the other hand, Max was most concerned about the first part; finishing. Meaning he stopped running as soon as he felt the pain come sneaking in order to be sure he didn't get injured before the marathon. Mine was, however, to constantly push it to prepare myself for what was about to hit me. So, here's what my plan was: the 3 first weeks I trained fairly hard. When it started hurting and became very uncomfortable running, but before it became directly painful, that's when I stopped running. After resting 1-2 days or whatever number of days it took for the pain the completely disappear I was ready for a new session. The remaining week I took it easy, giving my poor knees a chance to catch up and get ready for the big run! But at that point my knees didn't really hurt that much anymore.. I've also, after advise from my friend, practicing to run more softly, to minimize the "pressure" on my knees.

We were ready, both in undoubtably(?) good shape. It was a bit concerning that most of our trips was between 8-10 km only.. I had one run that lasted 18km before the knee started killing me, but still pretty far from 42km. That's when I made myself an ultimatum. If my knee started hurting badly during the marathon I would drop out, no discussion!

:: The race ::

After a long day of sightseeing the day before; getting up at 5:30 in the morning was a challenge itself. Eating plain wheat flakes with milk for breakfast didn't help much either. Especially without a spoon. But two hours later we were at the starting point in Marathons, almost ready to start. We felt pretty clueless how to prepare though. Do you warm up for a marathon? I mean, you'll be running slowly for 6 hours, what's the point of warming up!? But before we even figured out, I realized my starting number was gone, 20 minutes before the race began. Remembering reading that "you will not be able to start without your starting number" I kinda freaked out and ran back and forth looking for it. A few minutes after Max came towards me with my start number with a lot of footprints and dirt on it.. *puh*.. I have to admit my pulse rise quite a lot those few minutes.. so there I go, my warmup was complete!

10 minutes remaining, and we were preparing the gear! Max had of course his GPS with him, and I had my cellphone! We've promised people back home to give live updates during the race, so a cellphone was a requirement. How I was supposed to write text messages with the cellphone literally taped to my arm was another question. But more importantly; on my cellphone I had 4 hours of music - The Ultimate Marathon Mix! Legends say that faith can move mountains, but so can music!! Not literally, but music is the best motivation you can ever find! There are certain songs that just gets the rhythm and fill you with excitement! That's my 4 hours of marathon mix! That's what was going to keep me going! We were now ready for what was about to begin!

So, when it comes to the race itself.. what can I say?! It was 5 hours and 21 minutes of running! YES, I did complete the marathon! All the way! Was it hard, yes indeed it was, but I made it!

The biggest surprise; my stamina (or lack of it) wasn't an issue at all, I wasn't really breathing very heavily at all during the race. The pain, however, was just indescribable. In the beginning I kinda struggled to not run too fast as I knew that would probably kill my knees after a while if I did. So the first 25 kilometers went very smoothly, but the last 17, nah, not so smooth. The pain, sweet pain! Especially the last kilometers; I can remember how every step I made felt like my legs were going to fall anytime. Exhaustion, cramps, blisters, you name it! But my knees were OK! I actually had to stop and feel carefully because my muscles and feet hurt so much I had to be sure the muscle-pain didn't suppress any knee-pain! After 35 kilometers I just couldn't take it any more and had to start walking, which I did for the remainder of the race. At that point, though, I didn't really run much faster than I walked anyway, so I guess I didn't matter! I think I even walked passed a couple of guys still running.

But during the race you have a lot of spare time, and you start noticing the small things around you, the things that keeps you motivated. To me, seeing young children and entire families along the road cheering and shouting "bravo bravo bravo" was really inspiring. For quite some kilometers I ran together with an old man, he must have been 60-70 years or something. He was running steady as a rock up the hills. Amazing, who wouldn't get motivated by watching him. And when the going got touch, the text messages from Ngoc helped a lot, and not to talk about good old Roxette and Boney M singing loudly through my headphones. All together, it kept me going, one step at the time!

Coming into the stadium was just an amazing feeling, seeing Ngoc at the finish line cheering me forward was a priceless moment. The stadium wasn't really that crowed anymore, but it really felt like it was, people were screaming and cheering! At that precise moment all pain was forgotten and we all started running again. Though, 10 seconds later I was brutally reminded of the pain again. But it didn't matter! I was there! It was done! I was just about to finish the run of a lifetime!!

:: Final thoughts ::

The next day, going shopping in Athens, oh how I regret not bringing crutches!. And even worse, how I regret harassing Max for bringing crutches! I though it sounded like a bad idea when we left, kinda like jumping into the lifeboat in case the skip should start sinking.. but believe me it sounded like a good idea the day after! At that point it felt like all of my tendons was ripped halfway apart, which might not be far from the truth either.. But three days later, I was feeling a lot better. I was nearly able to walk normally and only one tendon is still hurting, but doesn't seem like something seriously. And today, one week later, I'm doing very fine and happy as ever!

So, I somewhat surprisingly reached my goals, and was I lucky it turned out this way, yes indeed I was! But one question still remains: WHY!? Pretty much all my friends asked me; why going through so much pain and lonely hours, running a high risk getting long-term injured?! I've never really been able to answer that question yet, it was definitely not for the money! Although there was a prize money the race cost me 80 euros.. and to put it that way; I wasn't running the best odds of winning. So, was it to be able to brag about it afterwards and impress people? Nah, not really. It's of course a nice story to tell, and.. hmm, maybe a little, but that wasn't my motivation when I joined it. What about pushing my limits and prove I could to it? Nope. I already know long-distance running is not my area, if I wanted to push my limits I'd chosen something I'm good at. Besides, I'm a programmer and computer engineer, if I were to prove something I'd use my brains, not my legs!

So, I still don't have a good answer! I shall admit I had a hard time finishing the marathon and that some parts of it wasn't much fun at all. But I guess it's all about the feeling I'm left with in the end! The satisfaction of achieving something great is one thing, but when I now, one week later, look back at the race, it wasn't that bad after all. The pain is gone, all I can remember now is exactly what I want to remember; the good times! Because that's what it really was all about, a great experience!

Pain is temporary, pride is forever!

Long story short, I made a simple one from a plastic bag, some dye and a camera:

Fast forward a few weeks later: I'm on a plane heading to our headquarters in Menlo Park. Eclipse (and a bunch of other technologies) are serving me our app via localhost--nice! ...that is, until I needed to reference those pesky $.ajax parameters!

With that in mind, and the remainder of the flight, I threw together a jQuery reference widget. It's been of value to us front-end developers at Medallia, and now we're returning some love to the jQuery community with this public release.

The widget provides simple, searchable, offline access to the API. More, we've provided the ability to search older APIs, as well as a few quick-links to online resources.

Per Resig's suggestion (and thanks John for all your help), we're releasing this with an MIT license and have made it available under version control.

We hope you find it of value!

Download the widget, v1.0 (View screenshots)

I've updated the widget to the latest documentation 1.1.3.1.