A Java Fork / Join Framework

Overall, this paper seems like a good approach to allowing programmers more access to tools for better multicore performance. As has been discussed several times already with hardware advances focusing more and more on additional cores for performance gain rather than clock speed it will become even more important for developers to work to make their software compatible with this architecture. Essentially extending a current library is a wonderful, non-disruptive way of accomplishing this since it allows those developers to better leverage the existing hardware without damaging their current code-base and practices.

But is this worthwhile? After all, we've read several papers already that discuss writing their own thread library, so clearly an interest exists for this. My intuition is that the addition of a new, better working threading library will not overwrite the reasons that many projects decide to construct their own. Projects that are highly concerned with efficiency will still be interested in getting every last tick of performance out of their machines and so will be looking at all levels of their architecture and technology stack for places they can improve, and if they feel the generic thread library (however advanced) is not enough, then they will construct their own much as they would now. And projects that are less concerned with efficiency will be glad that they have something that runs threads more efficiently, and move on to the next big advance (which we all hope is not Clippy 2.0). So it seems to me that much as now, writing your own thread library is a task that is highly dependent on the program itself and so would receive little benefit from this new technique, but as a general rule I would never turn down a more efficient library for general use.

I've worked a little bit with threads in Java before, and found them to be pretty easy to write (write well may be another story). And it seems from the code snippet and description that the author's framework maintains the same structure with the addition of isDone and join, which are both two sensible operations. So I can definitely see using this for large sequence number crunching or for set exploration, possibly even some image manipulation. But I feel that the greatest use of this sort of extension may never be visible even to most application programmers as this can be used to help increase the efficiency on a lot of backend systems and other libraries. I suppose I am also concerned about the possibility of developers attempting to "parallelize" their software for just the sake of saying it was done and attempt to apply this solution to anything they see as slowing them down even if the problem cannot be easily deconstructed into smaller subsets of itself.

On the plus side, it was nice to read a paper that actually had performance information analysis.

GNU Emacs: Creeping Feautrism is a Strength

I have very little experience with Emacs myself. I've seen a couple of power users at work with it though and I was impressed with the speed they were able to use to produce some pretty interesting results. Unfortunately that same power comes with an expectantly steep learning curve, and that is one reason I never really spent much time with it.

Emacs, judging by this author, seems to exist as some sort of ideal as far as open source community programming goes. It's apparently very easy to make simple extensions to the command structure and to combine those extensions into larger features. The extensions are easy to share and easy to setup for a user's calling preference. All of this is great, but I wonder what cost the people in charge of maintaining the releases have to put in to make sure that they are growing in a meaningful way. I mean, with everyone passing around their packages how do the people in charge hear about them, and how do they make sure they aren't taking in multiples of a given script set when they decide to adopt a package. The amount of overhead to stay on top of these things cannot be small. Additionally, the authors continual decrying of plug-ins for making plug-ins puzzles me. After all, if more recent systems have more complex data models why wouldn't they need this, and other than making freelance additions easy what is gained from a simple data model? And what if developers want to make large changes to the current setup? These plug-ins would be a great tool in helping to start that process.

The discussion about Firefox at the end of the paper is interesting, and I can see the possibility of an Emacs or Emacs like extension to Firefox in the near future (after all, if they can integrate a word processor into a web-page to work as smoothly as this blog publishing software why couldn't someone create a more complex but similar extension). But I see two fundamental issues with this path. One, Firefox is developing in a way to make itself a more efficient and powerful browser, and it will better spend its efforts along this line leaving it to third parties to develop this Emacs like tool. And Two, why would those people seek to build Emacs again? Most Emacs users I have known are rabid, cultish fans of the application and if they already have their perfectly suitable Emacs why waste the effort to build another without a major reason? And I do not see a major reason like that appearing any time soon.

Our Pattern Language

I don't have that much experience with parallel programming, but I think this paper does a decent job of laying out one approach to codifying the process that will need to occur to help maximize this hardware architecture going forward. I like the discussion at the beginning of the paper where there was a discussion of the "ideal" layout of developers across the overall hierarchy of a given set of problem spaces and I would love to see a model like that actually in place and working. I know the company I'm currently working at seems to be putting more and more effort into going into something like this, but we keep running into real world issues where the various products are so used to their own specialized stack that they are untrusting of moving to this new unified service package. The other issue also seems to be that no-one is entirely sure whose job it is supposed to be to actually port products over to the system. In a new company, some startup, this would be an excellent plan to follow to make sure that effort is getting spent where it needs to be and work to move technology changes to the stack is simplified.

The biggest issue I have with this paper is the granularity of the patterns they present. It seems like they are almost arbitrarily grouping problem solutions into large patterns, and at the same time focusing in on smaller patterns at the same level. For instance, in the Architecture section they have an entry for MVC, which is indeed a way to approach designing the overall project flow, and another entry for Event Based invocation which seems to be a slightly more complex version of the Observer pattern. Either my inexperience is showing, or I'm not sure that one can justify placing those two patterns in the same grouping, as they seem to solve entirely different issues of organization and activation. And others like "Bulk Iterative" seem to be even more simplistic. With these drastic differences in approach all being captured by patterns at the same level I am more than prepared to state that this team needs to seriously examine their current dissection of the parallel programming architecture space and make sure that the patterns they have here are all full patterns and not simply a macro-equivalent of a "code trick" or "handy thing". With so much variance in scope I have a hard time understanding how they can consider this a unified design tool.

Although, any advantages in this area that will help more programs actually take advantage of multiprocessors is a welcome thing. With multicore processors becoming standard equipment I'm too used to seeing one of my cores getting much more heavily taxed than the other depending on where the programs I'm running got assigned by the OS. It makes much more sense to balance the load out as much as efficiently possible, but many developers simply do not have the training to do this effectively. And much like UI has been codified and recodified into more flexible and easier to understand and use libraries the ability to effectively use cores must extend in a similar way. I do not want to end up needing one core for every new program I need to run, especially since today's exploding hardware capabilities are making lazier and lazier developers and thus bigger and more bloated software.

Metacircular Virtual Machines

The biggest strength that metacircular VMs offer is that they are created in the same language they are built to run. This allows for many techniques to increase performance and functionality, such as with the way they were using several construction tricks and java calls to construct stack traces during exceptions. While there may be more classically efficient languages to construct a VM in, the flexibility that building your VM in a mature language gives goes far beyond the negatives of performance loss. Squeak, as mentioned in the chapter, is a wonderful example of this. The ability to use Smalltalk's own methods to perform explorations of any and all objects at any time was of great assistance during the time I spent working in that environment. And as mentioned in the chapter we can overcome much of the performance deficit that is incurred by performing many small tweaks at all levels.

The biggest fear I had when reading that they had implemented their own threading library was that the team did not think ahead and make it easy for them to replace it with something should a more efficient library be created. However, in the chapter they make specific reference to making an API for their thread usage supposedly allowing for the easy substitution of other threading techniques. Unfortunately the article doesn't go into depth on how effective this API is possibly because they have not yet had the chance to test it out. The decision to build their own thread library certainly made sense at the time, as this allowed them to greatly customize the performance and behavior of their system, and thus kept with their overall design aesthetic and made great gains for their project. Only time and further work will tell how good their thread API actually performs as multiprocessors and OS behavior continue to advance.

Adaptive-Model Architecture

The adaptive model system seems to be a great way to go if you're worried that the business logic of how objects interact will change frequently, but that the overall structure of the relations changes less quickly. This would allow the system to be updated frequently with new or revised rules on how objects interact without needing to take the system offline and without worrying that something has been missed (since the system is using rule objects we can alter those and know that they will be referenced). It seems both possible and necessary, then, that this model of software would allow its objects to dynamically change type. Since type is little more than a collection of properties and all of these properties have been abstracted out to a different object then reconfiguring to look at a new set or to slightly alter them should be a relatively simple process. It also makes sense to add this because if you're using a phone billing system like the one presented in the paper a misfiling that causes a landline account to be created instead of a cellphone account will have a lot of the same information: owner, number, billing address, etc. and so it should be simple for the user to go in and make the necessary adjustments without having to create a whole new entry in the system.

Calls become a bit more complicated, and for once I would have loved for the paper to delve further into the mechanics of the actual operation. However, we can say that since there is some base object type that decides at runtime what sort of object it is supposed to represent through the acquisition of meta-data direct method calls would only work if the architecture is strictly following the strategy pattern (which it should) so that we can be assured that the method calls are all consistently and appropriately named. Other options are also possible to ease the burden and allow for more flexibility, including storing the needed methods in the metadata itself.

The biggest concern for a system like this though, is the size of its object pool. After all, if you're allowing users of the system to generate their own objects it could very easily get into a situation where users are creating objects with only very small differences that should be handled in properties. The cure for this is two-fold: 1) limit the ability of the users to create new objects. By carefully constructing the UI for modifying the object set it should be possible to make it so that small differences naturally guide the user into simple creating a new instance of an already defined object, rather than a whole new object. 2) By ensuring training and having a maintenance staff. While not exciting, making sure that users are trained and are able to recognize when new objects are needed will go a long way to help contain the number naturally. And it should be not all that difficult as they are domain experts and so should have a solid grasp on what they are doing. A maintenance person may also be needed to ensure the continual and smooth operation of the system, and may be able to prune down some of the excess items.

JPC: x86 Java Emulator

The authors of this chapter present an interesting technique, using emulation rather than VMs in order to allow for an increase in code portability. My concern is that the gain in portability does not outweigh the negatives of this approach. Since you're emulating the system itself it is unnecessary to run the system on customized hardware, removing a lot of the negatives we discussed in the chapter on Xen, such as having to customize the OS, or write special processing stacks to handle the computations as needed. Unfortunately, since you're running a simulation, it is necessary to expend processing power to run the simulation, then additional power to actually run the contents. This performance hit is severe, and it makes the idea of general purpose environmental emulation questionable, since, as was mentioned in the Xen chapter, hardware companies are making it easier to run VMs instead.

One place the idea of emulation may take hold is not necessarily the emulation of x86, but full emulations of more complex hardware packages, like smartphones. This would allow for quick deployment testing of software on multiple platforms and I'm sure this is already a standard use of emulation. Emulating the x86 hardware space seems less interesting beyond the reasons listed above because there is a lot of platform development making laptops lighter, faster, and longer lasting. If you can bring the entire physical system with you without a performance cost then other approaches that provide the same portability but have performance hits will be of less interest to users.

The only thing that this emulation has going for it is that since everything is being run inside a safely contained box there is minimal risk to security. As the article points out you're going to need three failures: the program in use, the emulator, and then the OS itself in order to actually cause damage to the system underneath the emulator. And having all three of these failures correctly interact to allow the transmission of damaging or malicious code is going to be difficult to orchestrate.

Also, why are the Tips not in order? Did that bother anyone else?

Big Ball of Mud

The main focus on this article seems to be on the thing that a high energy electrical engineer once told me during my first internship: "Temporary fixes become permanent solutions".
In today's business climate with it's customer satisfaction focus means that there is often a large backlog of bug fixes and enhancement requests for a product team to deal with. And as soon as one batch is finished, not only is there the rest of the backlog that you have to worry about getting done, expect whatever it is you just made to generate even more work for you.

Since this cycle of business pressure -> code -> release -> business pressure is constantly pushing the code base managers need to plan in time every iteration (or some other static time splice) to allow their teams to go over and refactor the current code base. If this isn't built directly into the company's product timeline then the crush of that cycle will not allow for the time to do this to simply appear. And what is making this more difficult is that the business must weight this time against other development activities that could be going on, and proving to your business leads that this time is well spent may be very challenging.

The assumption that it costs more to build a system with a good, growable, maintainable architecture upfront is going to take a lot of time is absolutlely correct. If experience has taught me anything it's that getting architecture right the first time is almost impossible. And worse, a team may spend all its time trying to find the "perfect" architecture without ever actually moving on to building the product, which is worse than not even getting a product to market. This is also partially true because the Ball of Mud can arise out of many scenarios, so the product may have started out with a good, solid architecture, but maybe it was simply neglected, and an architecture cannot be better than a team's commitment to ensuring its continued appropriate use and application.

When I first read the quote "Make it work, make it right, make it fast" I interpreted "make it fast" to mean build the application quickly. In that case my response was the ever popular: "Choose any two". But since this quote is more about the goals of your development efforts, from the initial code, through the next refactors (focusing on performance last) I'm more of the feeling that more companies should take the time to allow the second of these steps to take place. I'm not sure I've ever seen or heard of an instance where a product was allowed to pass through all three of these steps.

"Sweeping it under the rug" is an unfortunate consequence of brain drain as people leave your products and you eventually lose all knowledge of what a specific subsystem and/or technology is actually doing in your product. As an engineer these black holes are dangerous, you only have the guarantee of your co-developers to go on that this section of code is producing the correct results, let alone that it isn't actually broken somewhere inside. This is a scary position for any business/product/developer to be in. Unfortunately, without a large expenditure of effort you are never going to recover that section of the code, and if your business hasn't put forth the effort to stop this drain from reaching this point I doubt they'll do much of anything at this point.

Guardian: A Fault-tolerant Operating System Environment

This article, a definite break from other papers, focused almost exclusively on hardware layouts. The Tandem system, with it's complete backups of everything would allow for good parallel processing, because each CPU and memory unit can do their own processing. Of course, with the overhead concerned with moving the data and processing around this would not be an efficient system.

All of this seems to combine into the eventual decline of the system. As the author indicates towards the end of the paper, the biggest downfall of the system seems to be its inability to cope with the change to 32bit systems, and the cost of double (or more) hardware also seems to have put a dent into their ability to last. The fact that the performance was already below average didn't help the system to stay active as time pressed on.

I find it pretty ironic that this was used in many ATMs at one point, yet the author gleefully points out that they saw many opportunities to successfully attack a Tandem system's processes and files during the creation of the system itself. I'm assuming they made sure the system was secure once it was in place, but it still doesn't help to think about how wrong it all could have gone.

Layers: A System of Patterns

I found this article to be, for the most part, too focused on their example of TCPIP and not worrying about more common (to a software engineer) layers typically used in programs. Perhaps this is because network traffic has been the subject of so much work and such wonderful design that it's difficult not to talk about it.

However, what this paper made me think about, especially when it started talking about how to address applying layers to programs that already exist are the sorts of programs I deal with at work. Most of them are fairly standard sorts of large applications. There's a front-end with some processing power sitting on the user's computer, and a connection to a database sitting somewhere in the network. What gets me thinking is some of the development effort that's going on right now that's trying to replace the front end of the system, which is a strange combination of technologies form various time periods, and how much pain that process seems to be bringing. A lot of discussion these days at the business is focusing on the expanding mobility options that our users are getting, whether it's netbooks, iPhones (or other smartphones), touch tablets, or some other system it seems like our users' demands for greater coverage is running into the fact that our front-end simply isn't designed to handle these things. And I haven't heard a single word that the redesigning we're currently doing on our frontend is focusing at all on making expansion into other platforms easier. I bring this up also because there was an earlier chapter from the Beautiful Architecture book "Making Memories" that talked about how the team put a lot of effort into separating their business logic away from their front-ends as much as possible, and unfortunately, in the products I work on I'm not seeing much of that. This seems like an especially good idea because of the mobility I've pointed out before. Sure you give your teams massive headaches initially in making sure you've split everything out of the frontend, but when it comes time to move your system over to a smaller app, or to work in a totally different environment the engineers will probably be happy not to have to reproduce all of those workflow specific things. To answer my question about where I see the most changes (as though it were not already obvious), I'd like to see more changes on the front-end as I've described (it would also make fixing bugs much easier since workflow issues should cascade automatically). Unfortunately I see more work being done on backends and network efficiencies, like most of the Facebook paper from earlier this week concerned itself with the handling of user data and then talked about the necessity of adding another scripting technology to further impact frontend performance.

In one of my classes recently my group chose to design an simple interactive game. We sat down and went through the initial design steps, and did a good job of getting our major pieces in place and interfaces setup. Unfortunately, as time went on, I kept finding myself having to poke into the calls produced on the other sides of some of the interfaces because the transparency of the data wasn't what I wanted or I didn't know I was going to need something like that again. Thankfully my piece of code was mostly on the backend logic side of things, because the number of relayerings and other reorganizings I saw on the level above me made me glad that my code area remained relatively stable. Perhaps some of the steps from their guide, specifically number 8, Specify Communications between adjacent layers, would have been useful for my segment, whereas the levels above me saw that code shuffling from a lot of issues with decoupling and an unclear understanding of what service they were precisely supposed to be providing (numbers 9 and 6 respectively). From what I can remember, and this is also unfortunately true of some of the code I've seen in other places, we almost totally ignored creating a unified response to the issue of error-handling, and simple discovered them and handled them as we went. It made the system workable, but there was little in the way of a codified approach.

Xen and the Art of Paravirtualization

The idea to actually go in and re-write the base code of the OS itself to work on your virtual machine is a pretty fascinating one. I'm glad the footnote mentioned that the practice traces the roots back to the 1960's, otherwise I was going to wonder why it hadn't been tried before this system (perhaps it was going to be one of those blindingly good ideas that you can't recognize until someone else points them out). But by going in and customizing the OS you're running there should be little surprise that there is a large performance gain over the original method of adding another whole stack of calls that need to constantly examining input for possible tricky commands.
The only issue with this approach (until the chapter later talks about stub domains) is that if there are major changes to the OS then you'll have to go through and discover where those changes may impact your hypercalls. In this case, focusing on new uses of the dreaded commands, or ones where past changes of your own have been overwritten by kernel upgrades.

As far as Domain 0 goes, splitting the interface to the actual hardware away from the tasks of creating, destroying, and some of the running of the VMs was a good choice to split the functions into two modules. This also minimized the amount of flow through the Hypervisor as can be seen in figure 7-6. This also, I imagine, allows the IOMMU to fit in easier, as there are fewer paths that are truly necessary to worry about. Giving each VM an abstracted representation of the hardware so that they could only, by design, look into memory space that they were allowed into seems like a great way to decrease the risk of ruining someone else's data. I'm just not sure I agree with or appreciate that the authors' response to adding in all these layers possibly defeating the efficiency gain from paravirtualization or similar methods is effectively "Don't worry, not only will hardware get faster, the hardware companies are now making our jobs easier by writing these things for us." It just seems like too much of a cop out to me. If this whole system was designed to bring speed instead of just flexibility shouldn't they still make that speed their number one priority?

Pipes and Filters

One system that I had a hand in building and designing (based in no small part on work done by another member of this class actually) used the same basic concept to perform automated remote backups based on some simple user inputs. The users could go in, setup when they wanted the system to run the task and how often, and then go through and select the various files or databases they needed backed up, as well as a destination site (typically a separate server). Since we were dealing with potentially any number of data sets to be backed up, and three different database styles to deal with, and since we had no idea what order they'd be done in, we built independent modules capable of processing one kind of data each and then a datafile to contain the listing for repeated lookups. So the pipeline built by this was actually dynamically creating the ordering, but was also referencing a static listing at each stage.

For multiprocessing concerns the best configuration would be one where the pipeline used the Active styling, so performance isn't hurt by having to start the process/thread each time it's needed, and the length of time it's going to work outweighs the time it takes to push data to it and pull the data back out of it.

If the process of the pipeline as a whole should be started as a user triggered action. Since we cannot predict the start of task, leaving the thread spinning and eating up resources is not the best plan. This means we will have to make sure that starting this process is relatively inexpensive.

Data Grows Up: Facebook Platform

The biggest boost from Social Networking Sites to other sites and services is in providing rich sources of user-specific data. This can allow sites to try to tailor more content directly to certain types of users (based on some sort of predetermined status) such as sending announcements to users that have specific bands in their Favorite Music section. This data set also allows for the sending of messages through the network of a person: if they like something, their friends may like it as well. As a result, as more and more sites link data through Facebook or Facebook like services I expect to see a rise in targeted marketing as more and more sites scrape the visible parts of Facebook based on my login to try and get more money out of me.

FQL is an interesting and seems to be a pretty well thought out idea. Afterall, if I'm creating a program to work with Facebook I want some way to get at their delicious data (it may make my life easier, allow my program to do interesting tricks, or to make money), but you obviously cannot expose all that data without ensuring security. And FQL seems like a very logical thing to do to allow programmers easy and controlled access to your data. And then marrying that with the FBML to force the use and acquisition of session IDs is the icing on the cake to stable and safe accesses, while also allowing the Facebook data backend the tight expected inputs that should allow them to monitor and improve their latency issues.

The most interesting part of the discussion I found was the section on the acquisition of the session ID, not because of the process itself, but rather what seems to be an unexpected piece of fallout from it. I have several friends who do Facebook games in their spare time and I am getting a large number of notifications from them or the programs asking me to join in with them. And for some reason, that I probably could have looked up but seems to have been answered for me thanks to this discussion, I would have to actually login to the game and activate my Facebook account with it in order to ban it from sending me notifications. Seems that when Facebook built it so that a 3rd party application needs you to register your user ID with the game's application ID they weren't considering that a user may want to ban access to and notifications from that game without first handing the game access to their personal information. Strangely enough though, it should be pretty simple to make those bannings a thing attached to Facebook itself, especially since each game has a known application ID.

From Christopher Alexander

The first two sections deal heavily with the application of Patterns as the successful strategy behind creating an organic solution that not only grows up naturally to conquer the present problem, but can also grow to conquer future issues with ease (analogous to cities growing to take in more residents, businesses, etc.)
The first part bothered me the most of the three. Not because of what it was or wasn't saying, but because of it's heavy approach. Maybe I'm just too much the engineer but his phrasing just came over as pretentious and overlong.
The second section I found the most interesting because it seems to be suggesting that Patterns (architectural, software, etc.) are the tools we use to transform Platonic ideals into Aristotelian examples. His extensive discussion on Swiss builders all understanding "Barn" because they understand the patterns used to create does seem to account neatly for the differences in implementation but similar usage and appearance that seem to take place in each construction. I do not, however, agree with a comment he made about builders not trying techniques that do not fit their preconceived notion of barn to be disingenuous. After all, how can we build new things, new types of structures, without a willingness to cast off the shackles of our preconceived designs? I was struck upon reading his comment of the images of the various pyramids that are still standing in Egypt, and how a number of them show that clearly the idea of the pyramid was there, but the patterns for building it were not yet present. And it is this willingness to depart the current path to chart new designs and create new problems to be solved that we need in order to find these new patterns.

His comparison of Patterns to language is an interesting idea, but I'm not sure how much I believe that, if only because language, even in the hyper-evolutionary ring known as the internet, is still relatively slow to develop and accept new meanings, whereas engineering solutions can be disseminated relatively quickly assuming actionable evidence of correct function exists. Because my high school friends and I are still the only ones using "sw00t" as an exclamation of joy.

Part 3 seemed to me to be a rather straight forward discussion of user-permission based security and/or data access and storage procedures. Wherein the most important data (and the most sensitive data) should be accessed only by a few and contained at the "back" of your design.

Resource Oriented Architectures: Being "In the Web"

REST seems like an interesting approach to simplifying getting the needed data from a particular web service. It's main benefit comes from reducing it self to the four verbs, GET, POST, PUT, and DELETE, which allows for the builders and maintainers of sites to simplify their outfacing structure. As long as these four know how to handle themselves it doesn't much matter what's going on behind the scenes or how it is getting done: the user is pulling the data they need and making updates as necessary.

The issue, however, is that the author seems to believe that this should be a universally adopted format, that all the information connected to the web should be accessible in this way. But there are some serious problems with this. Firstly, the author seems supremely confident that by relying on any already in-place security measures will prevent the leakage of data. Fine, but what about instances of data trading that happen entirely with the consent of those who are controlling the data sources, but not the "owner" of the data? What if my credit card company decides to announce to a few corporate partners that they aren't blocking GETs to customer usage data? Also, I find the claim that this system will be more secure because you can understand it easier spurious at best. I will grant that easier-to-understand systems give a better chance to secure obvious holes in the system, I cannot fathom that this will seemingly act as a panacea to security woes, which, given how much time the author spends talking about those concerns seems to be his idea. I suppose we will simply have to have faith that SSL is going to be used a lot more in accessing these things (as well as almost all PUT and PUSH commands to prevent a duped context from spamming the servers and data backend into oblivion).

Finally, the last point about putting data at the forefront: I'm not sure I really see the benefit of this system as a user. Perhaps tying some of the metadata captured in the RDF will help with applications of the semantic web, but when I use web services I am rarely going to these locations for static data, but rather for processes I can do with data I have or data located there. And not a lot of what I am after is basic reporting or pinpoint updating. In these cases, the caching advantage disappears (since I'm running specific-to-me GETs), and the simplification to 4 verbs increases the number of middle steps that must be taken, either by adding an additional call between what I am trying to do and the backend processes, or breaking it down into many smaller component calls.

I find it odd that the author also insists that this technique will help with load balancing problems because the entirety of the context is passed in as an argument, which makes switching to a less-burdened server "easier". I'll grant that this would make switching simple (after all, we've got all the information of what we need to do passed in), but what about the underlying data needed to make this happen? Unless I was lucky enough to force a call to the cache I will still have to hit the underlying data at some point, and unless that data is being stored in this other location as well I am simply passing the buck down to the back-end rather than keeping it at the middle-tier.

I suppose the summary of my thoughts here would be this: other than as a way to help enforce correct interfaces between page requests and the underlying mechanics, allowing for easy changing of the underlying mechanics, I'm not really seeing a point to going through the effort of changing your system to use this. Especially since most users wouldn't see a single change, since constructing the system to be easy to use would reduce all these calls to the same links and buttons they already use.

ArchJava

The biggest advantage to using a language extension to plot out and enforce an architectural vision is that relies on tools you are already familiar with, namely, the language you're already using to create the product. This has the two main advantages of reducing the learning curve (as the extension should match the language conventions) and reducing overall complexity. During the introduction the authors mention several stand-alone tools that can be used to enforce the architecture, but every new and distinct tool you add into your code construction product gives you one more chance to slip out of date, one more chance to make stupid code errors, and one more headache when compiling or publishing your product.

As far as using this tool (or a later version) for the product found in the Memories paper I am of mixed feelings. While the description shows how it could easily encapsulate the various concerns that were talked about in the sections on refactoring in the Memories paper, it seems that it would require at least the same amount of effort, if not slightly more. So, it seems that the only real bonus to refactoring that could happen would be for future iterations where developers could clearly see the labeled connection points without necessarily referring to an external chart. You would have to balance this against the additional training necessary to work with ArchJava obviously.
Perhaps the biggest issue is that it doesn't seem like it would do much for the biggest hurdle facing the Memories product, that of making the system stable and user agnostic to reduce the workload on the people operating it. The architecture designed should help achieve this, but it would not do so on its own.
So the ArchJava extension seems only to partially assist with the needs presented in Memories, and, when it comes to adding new components, tools, or what have you, unless a clear benefit can be seen from its implementation I would hesitate in adding it to the product if only because it would be one more possible source of failure for such little gain.

I will say in its defense that ArchJava may be the sort of strict framework you would want to use for the Memory product's strict separation of Business and UI logic. Since ArchJava does to checking to make sure all communications are being channeled correctly it should be fairly simple to lock the business on one end and the display(s) on the other. This would have the benefit of enforcing the split that will come in handy preventing the repetition of code through the various view styles.

Making Memories

Overall this was an bland but informative look into the evolution of a piece of commercial software in the face of its business needs.

The most interesting tidbit for me, however, was the brief sidebar concerning Architecture in Agile development, and the idea of "Architecture Smells" rather than just code smells. A quick trip over to Google indicates a general lack of work in this area, beyond an entry in the book "Agile Adoption Patterns" by Amr Elssamadisy, but a quick read through the relevant section shows a conceptual groundwork, but even without directly pointing them out, shows some of the difficulties of turning some of them into full blown automated structures used in the same way that many code smells are.

Makes me wonder how much research is going on in this area, especially as more and more large businesses move over to Agile.

Architecting for Scale

The focus of this newly designed architecture seemed to focus on two key aspects of gaming across networks: make it playable, and make it buildable.

The author spends most of his time discussing the various and ingenious methods used to decrease the latency in the system, such as the use of the Data Store to store cross-task data and most of the other persistent facts as well. The most impressive part of the scheme though is the way the whole architecture is split to allow the easy addition of new servers and the automatic load balancing that takes place to move tasks to less utilized environments to maintain service speed and power. I remember hearing from friends who joined WoW early on about the horrible server issues that would plague the game and add so much lag as to make it almost unusable during peak hours. Though what really makes this load balancing scheme impressive is that it is built into the fundamentals of the system so that this is all hidden from the programming team.

Which leads to the second important part of this article: making the system easy for the company/group to create. Every year we see game after game being created for every system that use the Unreal, Source, Quake, or other engine. Many companies have recognized that it is typically faster and cheaper to simply acquire the tools for creating the underlying mechanics of your game and focus instead on the things that make your game unique, which, much like DNA, is overall a small percentage.

Also, embarrassingly? "You keep using that word. I do not think it means what you think it means."