Branch and Bound, Structured Grids, and Graphical Models

It is nice to see some discussion of graphical processing, and it makes sense then that what we would see is a whole-picture processing by effect on the image. Also, what's with that particular image being some sort of academic standard. It seems... sleazy.

Anyway. I find it strange that the Structural Grid pattern (perfect for that sort of application as is indicated in the paper) starts out presenting itself as though it is going to be a discussion of a multidimensional version of the multicore array we discussed earlier and then begins to try to phrase itself as some sort of master conductor unit when it is clearly exactly a tool to help apply basic operations over multiple dimensions quickly. Multiple threads are of course going to be needed for that to work, and the data structure should be the one to dispatch but I kept reading the phrasing as though it was overstating what was actually being accomplished. The discussion on the ghost nodes would have benefited from a little more depth and a few more examples. Other than that a good description of what was necessary.

I liked the amount of coverage of the different approach styles in the Branch & Bound paper and the description of the pros and cons of each. I also appreciated a concrete example of when the multiqueue structure would be used to gain efficiency, and the fact that the queue technique in the previous paper was used directly. It seems to me that using the branch and bound technique to drive statistical models (like the problems Monte-Carlo is being used for in most examples) would be a viable route as we can limit the total number of runs using this structure and then collapse the results to find the actual best and the conditions under which it occurs.

Shared Queue, Speculation, Digital Circuits

Shared Queue:
I suppose this is a sign that I haven't really been thinking things through, because we've had several patterns discussed already that talked about using a queue to create multiple tasks or threads with the option to use task stealing. And the idea of concurrency problems happening at the dequeue and enqueue operations scares me to death. Multiple counts of the same tasks being created, multiples getting added to the queue, and the list goes on. That we have waited until now to discuss this issue is worrisome, but what's scarier is that those papers we read before seemed to be willing to sweep these possibilities under the rug. And the deep problems at the task generation and retrieval stage can cause such extreme problems with data and process integrity.

Speculation:
It's a strange but interesting idea. I'm much more used to stages of programs flowing into each other in a way of tight dependency. I can see the possible uses for this showing up as a part of setup of methods and difficulty during other stages of execution. Additionally, decomposing the various tasks of interest into the FSMs for easy charting is going to be complex. The parsing example is a very good one, one where multiple stages can be broken cleanly into non-dependent parts, but getting another example showing where it could be useful would help easy my mind. Also, and this is probably just my lack of understanding, but I'm still not clear on the recovery process when a decomposed thing doesn't execute correctly. It's nice that this has been considered and covered I'm still confused as to how it's actually going to do its job.

Circuits:
Strange that this paper is almost 90% examples with very little definition. While I understand that there are only so many bitwise operations, seeing the examples of each with a clear explanation would be nice because I've only got a vague understanding of this stuff because it has been a while since I've last looked at it. Other than that, it seems sensible, though I personally haven't really worked with bitmasks there are very few tools to do so easily, and so doing CRCs on large disc images cannot be an easy task.

PRES

I think the funniest moment in this entire paper was the accurate yet obvious statement that if it takes a large amount of time to locate a bug in a program it will take a longer time to fix the bug. I understand the direction that this statement is heading towards: that concurrency bugs can be maddening to locate, and if it takes years to find them, it may take years just to correctly reproduce the conditions they occur under, and therefore it will take even more time to figure out how to protect against that condition. It is a very important point, as these concurrency issues are extremely important to solve before concurrency becomes standard.

What I find interesting is the approach of a lite-data retention in the first passes to build an outline of where the problems lie. I remember a previous paper where we were using technical abilities to predict areas of conflict in concurrency. This seems like a great possibility for combination of tools in order to better produce techniques for correct development. Again it seems that we have a great idea, with good technical setup and a good tool base, but since it succeeds at its own aims the authors haven't looked beyond to create a stronger technique for us to use to solve these complex problems with greater efficacy.

Task Queue, Graph Partitioning Etc.

Task Queue confuses me. It seems that all it is attempting to do is build a list of executable units, and then, as space opens, distribute those units amongst the available resources. But this seems like something the Operating System is supposed to as part of its normal operation. And since the queue system needs a system like Fork Join in order to distribute the tasks and do things like task stealing I'm not sure I understand what this is trying to accomplish that standard system doesn't already accomplish during its standard work. It also doesn't seem like there is much difference in intent than the pipes and filters pattern of dealing with multiple tasks of varying lengths and deciding how to move between them and begin those steps.

The Loop Parallelism paper reminds me of the discussions in the computer architecture courses that go over how to unroll loops and the complexities involved in that. It seems like this paper wants to use those same techniques whenever possible and assign the unrolled portions to different processors. Unfortunately I think this would severely limit the kinds of loops that this can be applied to, especially since many loops involve cumulative work on the components. When we read about the various multicore data structures like the parallel array there was a realization that scans of it would be easy to parallelize, but some alterations would be too difficult to do and maintain data integrity. Additionally, the architecture classes point out the amount of additional work that must be done to make the answers from the various stages of the loop pipeline available elsewhere. Combine these two ideas, of the necessary hardware additions for efficiency, and the restrictions of the way to use the structures in the code itself and I'm not sure I'm grasping why this would be more useful than either the techinques in wide use today or some of the tools and techniques we've already examined.

Armstrong Thesis Chapter 6

It was nice to finally see what an application using this structure would look like, and to get an idea how one would actually use the supervisor idea presented in the last chapter to create an effective hierarchy. I'll admit I'm fuzzy on why the finite state machine was constructed in that way and built into the structure the way it was.

To answer the point about why would you construct a separate event handler from the server, I would assume it's because by splitting the two into independent modules we can allow for the full purpose of the structure to work for us. If both modules were combined into a single asset then any modules we built to deal with an error would need to be able to handle server and event errors, which may be being caused by such different conditions and solved in such different ways that we would be better off splitting them into two separate error handlers. And since we would need two totally separate error handlers that should be a huge clue that what we're trying to capture errors from is too complicated. Just because they seem like they serve similar functions doesn't mean we can lump them together without considering all possibilities and repercussions.

Pipeline, Geometric Decomposition, Data Parallelism

What's interesting about the pipeline pattern is that, when properly constructed it works as a wonderful platform to use of further patterns. The paper mentions that we can use things like the discrete events pattern from earlier this week to pass messages between the stages of the pipeline, which of course also allows us to use the Fork-Join framework to ease the overhead as pointed in the earlier paper. This idea could also be used, depending on the resource requirements, to have multiple full pipelines running in multiple processors, though without investigation I would assume that it is actually more efficient to have multiple instances of the individual stages working in concert. Perhaps it is just my misunderstanding, but I'm not sure what the differences are between pipes and filters and pipeline. It seems to me that one implements non-hardware pipelines through the use of pipes and filters, by using that groundwork to lay out the connections and the data handling between the linkages.

The Geometric Decomposition is interesting, and I would have loved to have a different example than one with pictures, as the 2D format makes them an obvious application. I would hope that in applications that need the additional efficiency is actually a complicated data set which would allow this, and although the example restricted itself to just the 2D data set I feel it is obvious that expansion into higher dimensional data sets would be a matter of defining cuts more closely and could be accomplished with a minimum of thought.

Armstrong chapter 5: Fault Tolerance

The first thing that jumped out at me during reading of this was the idea of decomposing tasks into simpler and simpler pieces so that correct, or at least safe, execution could be achieved in all cases. I originally misinterpreted this to have to do with trying to perform only subtasks of the original task in order to complete as much as possible before exiting. This of course would be very dangerous, for example, if at an online store the money is subtracted from the account but the items aren't credited to the user or even the other way around. As I read on it seems that the system being proposed is actually focusing in two related areas: recovery and dependence. Firstly, it sounds that if a task fails to execute we either restart that task hoping it returns correctly on a new run, or run an alternative task to ensure that the system is restored to the correct state from before the failed task was run. This would ensure that there are no instabilities in the system, since we are able to explicitely design the heirarchy to be able to recover from any set of errors with the input or the execution.

Reading further it seems that the greatest use, thanks to this And/Or Supervisor technique is to create a heirarchy that guarantees the proper execution of tasks in a specified order (done through careful construction of the supervisor tree). This still helps wtih the overall chapter goal of designing fault-tolerant software as we can build using the correct Ands and Ors a tree that will prevent the program from getting into a state that causes problems because of unfulfilled preconditions. Building to use this structure will take careful management and a mindful hand, but in systems where the ability to correctly handle all adverse conditions of execution and input designing for safety needs to already be something in the forefront of the designer's mind. It is much easier to design a system to use this approach from the ground up rather than trying to go back and reconfigure everything to work in this format. There is even a chance to design some parallelism into the system, if the subtasks are all dependence related rather than fault-recovery, we can create new threads or processes to execute them in an efficient manner.

Recursive Splitting, Task Parallelism, and Discrete Event

The title of the Task Parallelism brought to mind many of the similar papers and patterns we have already discussed in the class, ones that talked about how to correctly leverage the splitting of large complicated tasks into ones able to take advantage of multiple processors. The paper did indeed end up discussing this, not to my surprise, but seemed to function more as an overview or index of other patterns, and a discussion of what is necessary to get them to work efficiently. It makes sense then that we have held off on reading this until now, as discussions of things like the Monte Carlo Simulation do require enough of a working knowledge to gain the full impact. Because this level of parallelism has to be kept in mind from the beginning in order to ensure that proper utilization occurs this pattern is firmly placed in the structural category. I don't think hardware is the issue here, the bigger hurdle seems to be that we engineers and developers are not properly creating the software to take full advantage of the hardware available, and as I've mentioned in earlier posts I'm not expecting this to change anytime soon without a concentration of effort to provide some tools.

The Recursive splitting paper made me question why we were assigned this paper. As it seems like yet another paper that discusses using a Fork Join framework to make computation faster, and I could swear we had already had at least one paper that discussed using recursive calls as the basis for producing new threads. Or maybe it's just that the frequent extolling of Fork-Join's low overhead, good switching, and safety have made it so that I automatically associate its use with any paper that begins discussing taking advantage of parallelism. I also question the use of insisting that this paper utilizes the Divide and Conquer pattern when the paper clearly says that it is that same class of problem that it is intending to solve.

For the Discrete Events paper, I would initially say that I have yet to work in a memory sharing environment, but have clocked a decent amount of time working with message passing systems, typically over networks. Since deadlocks can occur for many reasons, especially when we're waiting for tasks that can occur in different orders every time most systems would prefer to analyze expected runtimes for the various components that will allow for a sensible timout to be set. With the technologies that underlay most networks, busses, and similar message passing structures we should be able to trust that lack of returns in this reasonable amount of time is the result of failure and not inefficiency. Of course, this assumption won't work in all cases, such as ones where modules exist on multiple platforms and those platforms experience unexpectedly heavy loads. But in those cases the tasks may never finish, or may arrive too late anyway, so discarding and attempting again may alleviate these problems. Since an in-depth knowledge of the problem space and the solution possibilities exist already in the mind of the designer they should be able to recognize those few cases where the formal deadlock condition is preferred and plan accordingly, but I don't expect this to be a frequent thing.

Armstrong Thesis Chapter 2

This introductory chapter accomplished two things: it did an excellent job of laying the foundation that will be expanded upon in later chapters and it whet my appetite. Since both of these things were accomplished I would consider that a resounding success.

At first while reading I was concerned as to why the author insisted that current Object Oriented languages would not be enough to complete the level of concurrency aimed at since it seemed that all that was occurring was the layering of additional interfaces and basic constraints over a current thread like architecture. It wasn't until the listings near the end of the chapter that stressed things like run-time code and library alteration that I began seeing why it was necessary to go beyond Java or C/++/#. It would have been nice to see the requirements listing for the OS, Language, Libraries, and other parts near the front of the chapter so that readers like me aren't spending the brain power asking "Why can't we just..." when the author has clearly already thought that through. There was one comment in the Operating System requirements section that I disagreed with greatly, namely that if the OS can create and destroy threads quickly then this is good enough to assume that this approach will scale well to systems with a large number of threads. I find this to be dangerous and short-sighted, to think that only at creation and destruction do threads add computational overhead to CPU work. Perhaps later sections will delve further into this. I can only hope.

The Next thing that really caught my eye was the introduction to security. The idea that a process or program needs the PID for access is an obvious one and the author correctly identifies that it will be the flow of this information that will expose security risks (assuming of course that choosing a PID is a sufficiently obfuscated process). When I got to those bullet points it raised a few questions about how they were actually going to tackle these issues, but unfortunately that sounds as though it will have to wait for later. Also somewhere in there is a concern about all messages passed are going to be atomic and how they exactly propose to pull this off.

Finally, it will be interesting to see if programming in such an environment is really going to be as easy and intuitive as the author claims it will be. Again though, this sounds like it will have to wait until later chapters are read.

All in all, it was an interesting start. I haven't found any horrible flaws yet which is always encouraging in a paper of this size, and the authors have done a good job of laying the foundation for what is to come.

Event Based Notification and Map Reduce

To begin, I felt that the Event Based Notification added very little to the generally known observer pattern. The only real differences I was able to spot was that there was a discussion of choosing the correct medium to transmit messages, such as a bus, and then briefly mentions that it may be necessary to consider notifying listeners on other threads. The specialization of this system seems to be in that all objects on the medium will receive and check the message sent to see if they are concerned about its content and act appropriately as opposed to a system where objects must register with some central authority about the type of event they wish to be notified of. The method outlined in the paper does have the advantage of not needing to maintain a listing of objects that must be broadcasted to which is nice when the system gains many objects that want notification. However, if there are a large number of objects then this tactic looses some of its luster, as many messages must be sent to objects that have no interest in the contents and time must be spent checking which state this object falls in. So, it is best to determine not only the projected growth of the system's objects but also how many objects are expected to actually need to listen for events. If there are many objects but only a few that need contacting then an explicit list will add overhead at creation but will reduce it during normal operation. As for error handling, a given component needs to know how critical the proper reception and execution of a message is. So, while it will probably fall to the medium to detect if all notifications have all occurred (and rectify any misses in the same way most internet packets do find their way) it should be up to the component to determine what it should do with faulty input. No blanket approach is going to satisfy all conditions but my intuition is that the central authority should only be contacted in cases of dire failures.

For the Map Reduce paper I was sad to see such little attention paid to the important steps of actually constructing the summary. Since the application of threads to collect data and use it to derive some basic further information should not be difficult at this stage the trick seems to be in constructing a way to intelligently combine the results in a way that does not sacrifice the efficiencies of the mapping. Unfortunately this paper seemed to be more focused on the general idea of Map-Reduce rather than on the actual application of it, seeming to leave the majority of the work to those Parallel Computing Gurus mentioned in the paper. Nor is there much discussion of creating a way for domain specialists to interact with a system that could ease their use of a Map-Reduce framework. The idea of an extendable framework that allows for both the easy identification of data sets, the mathematical analyses that wish to be performed and the expected output format would be an intriguing system to help construct.

Heisenbugs in Concurrent Programs

Overall, this is my favorite paper so far this semester. It focuses on a tool that is released and being used in actual projects and not just as part of an academic environment which I quite like to see. The level of detail presented could have been better for some of the sections though. Their brief mention of how long it took to hook CHESS into an existing program was nice (and at one hour didn't sound too horrible) though it could have used with a more concrete discussion of what that involved. Running the tool against Singularity's boot sequence was an interesting touch, and that it found a bug is fantastic (how horrifying would it be to find your computer freeze or at least lose resources to a spinning thread.

The thing I liked the most about this product was definitely the robustness of the test platform. Its ability to semi-intelligently identify possible concurrency issues was cool, but by far the stand up features were the comprehensive test reports (enough to allow the engineer to target the condition that causes the error directly) and the ability to skip through the test set CHESS generates to a specific run is a great idea. I hate having to wait through several tests that I know will pass when all I'm looking for is to see if the changes I've just made actually fix what was intended. Allowing users to jump immediately to that broken test case is going to save quite a bit of time and aggravation. And 30 seconds for several thousand test case runs is not a bad trade off in that instance.

I suppose the only drawback right now is the effort that is required to extend this tool into new environments, and while I certainly appreciate the ability for this tool to work in the Windows environment I can already hear the calls to liberate this code so the *NIX can have its chance.

Pipes, Layers, and Iterative pattern

We read three brief papers, two on patterns we have covered earlier and one on a new "pattern".

The first was a review of the pipes and filters pattern, wherein a system is engineered to allow reusable modules to tackle sequential inputs. The idea in this paper of likening this process to the way a graph flows is an interesting idea and could help with the constructing of shared modules as common breaking points can be identified. The very brief mentions of how to parallelize programs using this pattern if welcome, but for a wiki it is awfully short on links to the appropriate pattern details. Considering how brief this whole section is it should not have been difficult to build a similar page for the mentioned patterns or link to their main wiki counterparts. More care could have been taken to discuss how to identify and construct the modules and their interfaces, including leveraging existing technologies like XML for these specifications. Overall this was a decent introduction to the pattern, but like the next two entries lacked the meat really needed to make this anything other than a guidepost.

The Layered Pattern follows much the same format, being a decent guidepost but lacking the detail necessary to use this as a guide for constructing programs according to this pattern. It keeps talking about making sure to get to the "minimum" number of layers with absolutely no direction other than you may want a layer to talk to hardware. I was convinced until I reached the example that you can just as easily have called this paper "Model View Controller" and changed nothing. Since this pattern is impossible to apply correctly without rigorous effort identifying the correct splitting points between layers I'm surprised there was no actual discussion on how one would accomplish this. Other than some vague references to TCPIP and a poorly described robot-controlling piece of software there was little actual content to this. A disappointment, even for the length of this paper.

The Iterative Refinement pattern is an interesting case. It seems from the discussion that it is applying parallelization to the standard recursive model of problem solving. This reminds me very much of what was discussed in the ReLooper paper where it was talking about building array loop parallelizers, only instead of iteratively going over specially designed datatypes we are applying the same thought to independent, recursive problems. It seems to me that making these calls parallel is not where the difficulty in this pattern lies. Indeed, the ForkJoin Framework paper even discussed applying itself to problems like this one. The focus of a paper like this should be on guiding an engineer through identifying when this can be applied and possible steps to take to modify current solutions to apply to this approach.

Rereading the classics

Like a few others in this class I have just taken special topics 598 over the summer which focused on Smalltalk and its strict use of object oriented programming. As a result much of this chapter was a review of materials for me so I wasn't as engaged as I could have been. I will say though that this paper was very much a rambling mass of concepts that seemed to be related but it could have been made much more explicit. To begin by breifly talking about how often Noam Chomsky is quoted, compare that the the Gang of Four in Software, then discuss Smalltalk's architecture is a strange flow without a much more explicit attempt to clarify the links.

Overall, as I believe I've mentioned before that I had a bit of experience in Smalltalk, I can say that it is a powerful and flexible language that allows for a lot of interesting tricks. With its strong focus on small, modular classes and methods breaking down a problem into manageable pieces is pretty straightforward, and with Squeaks built in code refactoring tools its easy to accomplish. However, much like the comments on Functional programming, such small modular pieces can make keeping track of large enterprise sized system a pain. With it's focus on typing, inheritance, and other object oriented focuses (and the handy package organization techniques) it will be easier to logically organize systems to allow for the handling of large programs, but in the class project I can remember a few times still getting lost in what was going on because of all the methods and submethods.

Refactoring for Reentrancy

I was spectacularly unimpressed by this paper and the Reentrancy tool. There are three strikes against it by my count. First is it's poor applicability, second is its poor performance gain, and third is its ability to damage exceptions.

Several times throughout the paper it is mentioned that this tool does not correctly handle programs that interact with their environment, including the use of the standard system output, accessing files, and accessing databases (not explicitly mentioned but heavily implied by its inability to handle other environmental data sources). Too many programs, especially ones that put enough strain on a system to justify multiprocessing rely on access to these outside data sources as a necessity, and having to completely re-work your program to handle and remove these things is going to be too much of a headache in any major application. While it makes perfect sense that this is necessary it removes too many programs from having this applied right out of the gate (without significant work on accessing libraries to better handle these accesses).

Secondly, the performance gain, in only 3 out of 5 test benchmarks does not give this refactoring program a passing grade. While that is a harsh assessment the authors even admit point blank that the performance gain in these 3 points is small. Big enough to notice but not large enough to have a big impact on the overall program efficiency. Given the amount of rework that will be necessary to get most modern programs to a point where you can apply the reentrancy tool I'm unconvinced that the meager performance gains are worth the trouble.

Which brings me to the last major issue. On page 7 the authors make note that their program cannot guarantee that certain structures remain coherent concerning exceptions. They also make the rediculous claim that "typically this does not pose problems". While I would agree that many exception statements are added in order to conform to coding standards or library usage and thus aren't added directly by choice of the programmer anything that makes a program less stable and helpful during debugging is something to generally avoid. I keep thinking of trying to find the root cause of some memory issue, going through the stack trace then being stopped when the reentrancy tool has broken the trace. That would make for some gloriously frustrating time.

So, with its performance gains small, its ability to break debugging when we only have the authors' assurances that this is an edge case, and with its inability to handle data accesses of any sort this tool clearly needs a lot of work to demonstrate true usefulness for the industry.

ReLooper

The first major comment I have on this tool is that I am confused as to why this is a separate tool from the one in the previous paper. Both are heavily focused on the refactoring of your program for enhanced parallelization with the first focusing on recursive functions and this paper focusing on array operations. Both tools seem to be very helpful on their own, and both do show a marked improvement in performance on a system, and both use the ForkJoinTask framework as their basis so it seems that a melding of the two projects into a single refactoring tool would be a grand idea to push performance even higher. I would love to see your group crunch the numbers on the combined performance of the two tools presented so far.

Another issue is the choice of hosts. While a site specifically aimed at refactoring is a logical place to put this tool I am afraid that the tool (and the tool presented previously) are not going to get the exposure they need. As we've discussed in class parallelization is not going to go away and companies and individuals are all going to be looking for the tools to help them get this done in a cost-effective way. So there is already and will be an increasing demand for these tools. And the chioce of working directly inside the Eclipse environment is a great one since that is a widespread IDE. But why not host this inside Eclipse's own addon network? A tool like this needs exposure to get the use it should have, and tucked away in a site away from the first place all developers will look for their addons is not the best approach.

Finally, the fact that the two tools were separated makes perfect sense in the world of academia. Afterall, part of the goal there is to publish as much as possible. In a perfect world the author team or a group closely associated with them would be bundling these advances into a single master tool suite for automated parallelization refactoring. Perhaps a corporate partnership or an appeal to the Open Source community to assist in packaging and refining of the tool itself. I am afraid that by placing the tool in an out-of-the-way location and making multiple publishings on what could easily be the same tool will lead to the death of the project. If after all these papers have been produced the authors move on to new refactoring paths or other areas of interest then this will whither on the vine and programmers will not only be denied a handy tool to make their development easier it will also force at least one other group (though most likely more) to reinvent the wheel. And isn't one of the big things in Software Engineering to build your modules for continued reuse, improvement, and maintenance with an understanding that it will probably not (with any success) be only you working on it in the future?

Object Oriented vs Functional

I'll start this off with the caveat that I have not had much personal experience with functional languages, so take what I say with a grain or so of salt.

One of the things that I liked about this paper was that they clearly laid out everything that could immediately be considered wrong with it at the beginning. That they would acknowledge the small sample size, author bias, and other factors like that is very nice to see because it allows me the ability to immediately start adjusting my expectations to compensate. Seeking another source to help offset that is also a welcome touch.

The main advantage, which was talked about in the Emacs paper, and from what I've seen from systems built using functional languages is that because everything has been deconstructed to small modules and functions extending the functionality is a very quick process. Everything you need is typically there in that function call, so it is up to you to do what you'd like to the output to get at your own needs. This seemed to be the strength of the Emacs construction, which demonstrated the power and flexibility of that approach. But the issue for me is that this same power and flexibility can make maintaining a hierarchy much more difficult since developers get the access they want to the functions they want where ever they want them. With and object-oriented system you can set up interfaces, scopes, and inheritance patterns so that extending functionality can be done relatively painlessly, but still maintain the control over component access. Of course, as we spent the whole first portion of this course saying that if you're going that route you better have a good architect so the system doesn't become prohibitively complex or pointlessly over-layered.

When it comes to designing and your languages impact it seems that the purpose of the language drives the focus of your efforts. Functional languages naturally build from small problems into larger ones, so the breakdown of problems into small tasks is going to be the guiding force behind your construction architecture. Care will have to spent (as this article discussed) in making sure that the tasks can work in such a way that the problem you're abstracting still gets solved with enough generality that it is useful and reusable. Whereas the way we're taught to approach object-oriented software design is to breakdown the problem space into nouns and model those first, then their interactions. So we arrive in roughly the same location, it's just a matter of if we're concentrating on "bake pudding" or "bake pudding".

One nice feature of functional languages is that since the concentration is on breaking a problem down into small methods that each solve an individual part of the problem it should not be too difficult to start separating independant sections of the problems into tasks that can be shipped off to different processors.

@Randy Blamo: Fruit Salad

Yummy yummy

Refactoring Sequential Java Code for Concurrency via Concurrent Libraries

Firstly, it was very nice to see a paper build directly off the work of a recent, previous paper, and the use of the ForkJoinFramework here was a great idea.

Q1) The biggest advantage to retrofitting these techniques into your project is the cost. Designing and implementing a project to be multicore ready is a wonderful idea to get the best performance you can, but often in the business world the create recreation of your project may simply be impossible. A tool that can go in and automatically produce performance gain in a controlled and trusted manner is a boon to developers and users alike. The only reason I can come up with to build an application from scratch is, as I have stated in other postings, if the project's performance is its key metric. In these cases designing from the ground up is the only way to ensure that performance is the best you can make it. The other advantage besides cost in using a refactoring tool is that the retraining of the developers is much less, as they only need to understand how to use the new tool rather than totally relearn their craft to accommodate this new skill.

Q3) My biggest issue with using a totally automated tool, and the nice thing about having to select what to apply the refactoring to is that it may not be necessary to fully parallelize all aspects of a program. Things like application login, some perference control and other relatively simple tasks would gain nothing from the additional effort behind doing these transformations. The code would simply be hid behind this strange exterior.

Q4) One of the things I was wondering about when reading the code was if there was thought given to simply overloading some of the traditional operators to work the way we expect them to while looking the way we are used to. It would be impossible in all cases but about 10 of the entries in Table 1 should be able to have this done to them. This would certainly reduce a lot of developer strain on the basic operations for the first two transformations styles (which the paper cites as being the most frequent by far). This would also reduce effort on the part of developers trying to program using these data structures on their own.

Q6) The biggest issue I had while reading this paper was the mention early on and several other times that this may not be a totally thread safe solution. Given the habit of many professionals to trust their tools this worries me greatly. Gathering clear metrics on the failings of the system would be nice, and a discussion of why they occur (beyond simply "code complexity") would be genuinely interesting. This also seems to be a place that the development team for this tool will need to be focused for a long time, as a faster program that is not correct is going to only be mostly useful.

Still, this is a great tool and I can't wait to start seeing it and others like it adopted in a widespread manner until we as developers are used to parallelization smells.

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."

Boxology

The Boxology paper seems to represent an wonderfully complete reference sheet in case an architect needs to make their design decisions based on the expected flow of data and control. The tables presented in the latter portions of the paper are precisely the sort of resource I would expect to see printed out and tacked up on a cubicle wall to act as a simple reminder for what needs to be done, or perhaps published in a "pocket guide to Architecture". The problem is that the author has done a wonderful job of laying out way to differentiate theoretical systems based on key groupings, but it seems to exist in a sort of bubble that ignores the fact that a reader may be looking for ways to directly apply this to a project. I found myself looking this document over for the architectural equivalent of a code snippet just to see if I was following him correctly. As there doesn't seem to be that, just those charts and a guiding checklist at the end, I feel the author has left the task incomplete. He has provided us a wonderful rubric but no real instruction on how to go and apply it in our real world.

The second biggest complaint I have is that, like many theoretical papers, they seem to assume that all systems are designed both correctly and coherently, with one major way to handle flow of information or control. While I would love if that were the case my time in the professional world has taught me that due to various business concerns: release dates, promotions, loss, various other HR shuffles, and the sheer power of business cases and market segments means that in all likelihood the system we would use these tables to classify may only fall "mostly", or even only "somewhat" into one of these categories.

A Tale of Two Systems

From the discussions about the two systems there seem to be two major differences that filtered down to create the rest of the issues with the messy project and the successes of the more elegant one. The first and foremost in the author's mind seems to be that the first project failed because it lacked any sort of uniform design philosophy or goal, which he takes great pains to point out the second project had again and again.

I find two things odd about his presentation in this matter, however. Not once does he talk about the business pressures that were put on the second development story, just that "enough time" was given to the team to get the project done. Which strikes me as odd considering how often he seems to attack the first project for the constant efforts involved in meeting its unrealistic business deadlines. The other thing that tickles my mind about this is how much his experiences might have changed had he been with the messy product from the beginning. As he notes he came it later in its life cycle, and had to deal with all the issues listed, when he talks then about the wonderful experiences of the other project. If he'd been in those first initial meetings when the first project wasn't designed I think his attitude would change significantly.

The other main difference he highlights is the difference between standardization of the two projects, with the first project not experiencing any conformity, not even to the language and environments being used, to the supposedly total harmony he helped design in the wonderful project. Standardization of tools, naming conventions, and the rest is an extremely important step, not to mention standardization around a goal, and the first project definitely suffered for it heavily.

In the end though, his point that the first project was constructed for various business reasons on the shakiest of all foundations should not be lost. The issues of coupling, data storage, control, maintenance and everything else could have been much alleviated had the company not simply had the team stitch their various prototypes together.

What is Architecture?

The main point of this chapter seems to simply drive home the point that when you’re designing a system it’s not all about what technology stack you’ll be using, or how you’re going to split up responsibilities into modules on the client side, but also to make absolutely sure you and your team have a firm grasp on why you’re building something the way you are. Without this information it’s too easy for the architect or the engineers to build something that violates the intended design and solution, and to make checking for this sort of thing simpler, documentation should be made available and be kept up to date.

@Randy: I can’t think of a single concrete example, but I took that section more to mean that the Architect should have a good understanding of which components can be decoupled the easiest. I mean, in a magical world of infinite budgets and staffing you would be able to assign a single person to each of these modules. Or maybe they’re just using a different staffing model where what could (and, you’re right, probably should) be two different jobs are unified under the heading of “Architect”.

Software Architecture in Practice Chapter 4

The three most important qualities are, without a doubt, Availability Modifiability, and Reliability. While all the qualities discussed are very important these three represent a solid foundation from which more expansive software can be grown. If a user installs a new piece of software they expect it to work they launch the program and quickly become irritated if that basic operation doesn’t succeed. If the program is plagued by constant errors, crashes, and other interruptions of service the complaints will begin to pour in, just as would be expected. Lastly modifiability is extremely important as this can be a way to measure the lifespan for a piece of software. Businesses or other software creating entities that do not make modifiability a concern early on will have more trouble as time goes on and new technologies or practices are introduced. By nailing these three qualities we ensure that the user’s expectations of a functioning program are met, and that as time goes on the software will change to keep pace with new technologies or simply with the necessary repairs to ensure solid use.

However, the quality I have found to be the most difficult in practice is Usability. Each quality listed in the chapter carries its own unique challenges, but many of them are relatively easy to overcome, in that hard documentation exists or many opportunities in school and in the workplace exist to practice overcoming these challenges. With Usability, however, so many small adjustments can have such a wide ranging effect on the user’s flow that capturing even a few major helpful practices is difficult. I know that in my own experience some of the longest discussions I have concerning features I am working on have to do with how things will be presented to the user and how that impact's their workflow. Another big issue that separates Usability from the others is that a single program may have to be used by people with a wide range of abilities, and making the program complex gives the power users the control they desire but may render the system unusable for those without the skills. I once heard about a system that used an auto-hiding taskbar to hide the menu options from the user. An elderly operator was so unfamiliar with this convention that in order to close the program he would actually hold down the computer’s power button and force a restart! And this doesn’t even begin to cover other usability concerns such as simple icon placement, color choices, and a host of other things that have added many minutes to many meetings.

Purpose

This blog has been created as a part of CS527, being offered through UIUC.