*warning: plot spoilers below*. Imagine yourself in the trenches of WWI. The next chapter you're in Ancient Egypt, then in Troy. A little while later you've gone through the land of the bugs, dark/twisted versions of the Worlds of Oz and Wonderland, and many more. Of course this is before you arrive at the heart of the universe itself, where the basic rules of reality no longer apply.
The nice thing about Tad William's Otherland series, which takes place in the Otherland virtual reality network, is that he takes great liberties in his artistic vision. Otherland doesn't conform to the rules of many other artificial realities portrayed in fiction that try to preserve a consistency in their environments, rather is was built by a secret cabal of the most powerful people in the world to serve their nefarious purposes, each of which has a completely different vision of their utopia.
At first I was a little apprehensive about the last bit, in general I'm not a big fan of stories with a huge super-secret organization that runs the show, but progressing through the series it began to grow on me. Most of the main protagonists in the story start off as simple peons in the big picture, stuck in the simulation network, unable to leave, narrating the chaotic events unfolding around them. As the story progresses, the roles of the protagonists and antagonists become more apparent, but these mostly arise as artifacts of their characters, it is just who they are and often the random luck of their circumstances that results in their impact on the story.
There are exceptions to this, one of the most interesting characters is the dark serial killer knows as Dread, who is employed by the leader of the Grail Brotherhood (those that built and are running the network) to act as an assassin in both the real and virtual worlds to meet their goals. Of course things aren't as simple as they seem as Dread has perverse ambitions of his own, and seeks to control the very thing which his masters built to rule the world. Furthermore Felix Jongleur, the worlds richest man and leader of the grail brotherhood, proves to be quite interesting as well. While a bit on the cliché side his ruthless quest for immortality at any cost sets up and drives the events of the series and as they unfold around him, whether to his liking or not, and serve as many of the focal points of the epic. If you do start the series, make sure to commit yourself to reading to the end (it consists of four rather lengthy novels) as while it starts off slow, the ultimate fate of these two characters alone are so vivid that I suspect they will linger in memory for a while.
At the heart of the series, the network, and namesake of the books is the Other itself, the semi-sentient AI serving as the Operating System driving the virtual reality. The story of the Other when fully revealed is a very sad one, and there is no happy conclusion for this being, though there is some vindication with the fate of Nemesis, an ALife entity which the Other creates to quash anomalies in the network. I feel that in itself is enough reason to read the series, while many of the protagonists manage to escape the network and achieve their goals, it's no happy-hollywood ending. Rather there are many deaths and fates far-far worse, and as events unfold no character manages to escape the network unscathed, having to bear their experiences for the rest of their life. For some characters its worse than others, those with abilities which permit them some control over the network quickly find those abilities turn on them and they become more of a curse than a blessing. It is a bit of a tale in irony as nothing is ever what it seems, and while Williams often reveals the basic facts that setup for the awesome conclusion as the reader goes along, it isn't until the very end that all the pieces fall into place and the final puzzle is solved.
The series is an epic in every sense of the word, and in some senses it can be seen as a meta-epic, as other previously established epics such as the Odyssey and the Lord of the Rings are folded into the mix as characters go through those worlds, though often with a dark twist. I very much recommend the series to any sci-fi fan, the last book is so compelling I could not put it down (read the 900 page novel in a little under a week!) and I consider it to be one of my top three favourites of all time.
Until next time, happy dreams!
As a follow up to the GSOC, I've been mentoring several talented high school students from around the world who have been adding many cool new features and functionality to the isitfedoraruby webapp as part of the GCI contest. They have been doing a phenominal job on the site and an update sharing their work is long over due!
- Nico (from Argentina) has deployed the site to openshift, wrote scripts to syncronize the db on a daily basis, automated the production push process (whenever we merge our commits into the 'stable' branch on github, the site automatically gets updated), is working on i18n internationalization support, and much more
- Kendhia (from Algeria) has been working on features involving 'gamification', eg importing the contributors that maintain fedora packages, and displaying that data in visually appealing manners (including badges!)
- Mark (from Honolulu, Hawaii) has been working on adding more visualizations to the site, most notably graphically representing the packages a contributor maintains using d3.js here. Mark also designed a logo for the fedora-ruby sig, which can be seen above.
- Animesh (from New Delhi, India) implemented a timeline of contributions, so we can see a summary of all updates, both on the rubygems side and those in Fedora. He also wrote up and made a screencast of a great guide on how to get a simple hello world rails app up and running on the Fedora/Ruby stack.
We aim to keep driving the site forward, now that we've automated the push and syncronization process, getting new features into production should be very trivial. I'd like to thank the talented students for all their hard work and really look forward to continuing to work with them in the future!
Friday I flew out to Mountain View, CA to attend the Google Summer of Code Mentors Summit hosted at the Googleplex, Google's worldwide headquarters. Every year, two mentors from every organization are sponsored by google to attend the summit and I was offered the extra slot by Buddhike, the Fedora summer of code admin.
After the inevitable hubub w/ delayed flights and such (surprisingly my stow-away bag actually made it!), I arrived at the hotel on Friday night intime for the pre-summit dinner. On Saturday shuttles were available to transport us from the hotel to the Googleplex which I have to say in quite impressive. From architecture of the buildings, to the modern artwork scattered around the complex, to the meals/beverages/snacks, and even random bicyles available for any employee to just pickup and use, the complex lives up to the legend! (hover over images for descriptions, click for full sizes)
The summit was very much developer centric which I very much enjoyed, as most of the other conferences I attended included a mix of sys-admin and developer tracks. Obviously the driving event was a summer of _code_, so many of the attendees were software engineers themselves, mentoring students doing the development. Some projects were bigger than others, some well established, some not, but it was a great mix of contributors from across the industry working on many cool things.
Among the best of the presentations I attended included roundtable discussions on the latest languages and language features being used in the industry, different collaboration tools that the projects are using and their thoughts on them, and one on developing tools to quantify and measure community metrics and individual contributions. During the lightning talks (one minute a piece), I showed off Zuhao's isitfedoraruby project, and extensively promoted his work, as well as Sammy's and Nitesh's contributions to Aeolus throughout the entire conference.
I also held an impromptu session on the JSON-RPC protocol during the afternoon which was a last minute thing, but was able to leverage my presentation and demo of rjr in Brno from a few months back. This led to an good discussion with some interesting ideas emerging from it and even a couple adopters!
Saturday night was the Summit Dinner Party at the hotel, italian food, good mingling, and even a dip in the pool and hottub! This morning I checked out of the hotel and attended more sessions before wrapping up the trip (I am currently blogging this from SFO prior to catching my red-eye home).
I have to say this might just be the best conference I've been to so far. The talks and presenters were phenomenal. Even the attendees were constituted of some of the brightest of the industry, so many conversations lead to insightful perspectives and different conclusions than I hadn't come upon so far. I hope to be able to participate in the GSoC and maybe attend the summit again next year. Until next time, happy coding!
RJR uses eventmachine on the backend to process incoming messages over tcp/amqp/http/websockets/etc and dispatch json-rpc requests to registered handlers. It also employs a built in thread pool to hand off requests to the dispatcher so that the reactor isn't blocked. What results from combining the reactor pattern with a thread pool is a highly reliable concurrent event processing system.
The reactor central to eventmachine and the design pattern itself processes events one after another in a serial manner. Events are executed in the order that they arrive and no event executes until the one before it completes. Events can come from multiple sources and the reactor will take care of the serialization necessary to ensure data integrity.
A developer initializes the necessary connections and receives events by registering callbacks to be triggered on their invocation. Since the reactor blocks on any operation, the developer needs to ensure that his/her callbacks execute quickly and return control back to the reactor to continue processing events. Threads can be used to accomplish this, but spinning up a thread is an intensive operation, so a managed thread pool can be used as a nice solution that allows the developer to execute callbacks quickly and asyncronously without blocking the reactor.
Of course any resources leveraged by the callbacks will need to be protected from concurrent access but the nice thing is that if care is taken, the reactor itself can be used to handle this. In the callbacks launched by the thread pool, the developer can leverage the event machine reactor to schedule additional work that will be executed serially with the rest of the work already there. What results is an elegant / simple solution to schedule and process work concurrently with a built in mechanism to protect shared resources. Optimally the thread pool will incorporate a timeout mechanism that is able to kill jobs that exceed the timeout and restart their worker threads to keep things moving smoothly (as RJR does).
I would give this combined design pattern a name (perhaps Reactor Pool?) but I'm sure someone out there probably has already thought about this... and blogged about it... and uploaded an article to wikipedia... etc...
Be sure to see the first three parts in this series which contains the complete overview of my demo for the conference. I also have a minimal set of slides which I've uploaded here (original showoff source and commands).
And thats about it! I head out in a short bit for my 7hr drive there (stopping in Buffalo) and back on Sunday. On Friday, I'm scheduled to present in the first slot at the 'Build A Cloud' Day, and then on saturday my OLF talk is at 3pm in room C110-112. Everyone who can make it is welcome to attend, and I'll try to take some photos and post from the conference but there is always a million things going on so no promises! :-)