It never fails that Murphy will make an appearance right when I am getting close to wrapping things up. We have bandwidth limitations on internet usage in Australia. Do you remember using dial-up modems? That's about what it feels like when you use all of your allocated bandwidth for the month. Unfortunately, it made it nearly impossible to access the UIUC wiki page to get the papers for the final reading assignment. Here is my lackluster, yet final, submission for this reading blog...
Branch-and-Bound
The branch & bound pattern is fairly well written. Although the use of the data flow diagram did assist in explaining the pattern, it is unfortunate there were no actual code examples to demonstrate the branch and bound operations of branching, evaluation, bounding, and pruning. It was beneficial we had previously discussed the task parallelism, data parallelism, shared queue, and data distribution as they were used to demonstrate the parallelization approaches. I do appreciate the authors not getting to deep into the noise of the technical aspects and kept the pattern fairly high level for a well-rounded audience.
Graphical Models
Does this pattern have anything to do with parallelism? Ok, I understand the idea of modeling the probability distribution, but I do comprehend how this is applied to everyday use. What is the true benefit here? The example, if you call it an example, provided no real insight into what the pattern was about. I wanted to read and comment on the pattern before listening to the recorded discussion. Now, I am interested to hear the follow-on discussion after reading my classmates' comments.
Structured Grid Computational Pattern
This pattern was co-authored by an UIUC undergrad alum who went on to UC-Berkely to complete her PhD. The idea of representing a multi-dimension problem in the form of structured grid implemented as an n-dimensional array is very interesting. I do not have any background or experience in this area. As the array is broken into chunks for parallel processing, the tasks cannot be too fine-grained resulting in additional overhead and reducing efficiency of parallelism. The Geometric Decomposition pattern is handy in this situation.
I am interested in looking at additional information related to "Ghost" nodes, double-buffering, and adaptive mesh refinement.
Monday, November 16, 2009
PRES: Probabilistic Replay with Execution Sketching on Multiprocessors
PRES is a technique or system used for detecting, diagnosing, and reproducing a concurrency bug on multi-processors. I thought it was an interesting reading and was able to recognize similarities and differences between PRES and one our previous readings, CHESS.
In an ideal world, a programmer would love to reproduce a concurrency bug in a single replay and with no runtime overhead. PRES combines three ideas or techniques: (1) record only partial information to keep the replay close to the production run, (2) diagnose, process, and reconstruct unrecorded information to reproduce the bug, and (3) use feedback from unsuccessful replay runs to determine which paths do or do not produce the bug in question.
The various schemes of PRES are quite intriguing. I am not sure how thorough PRES is compared to CHESS. Even though CHESS is Microsoft-based, I would be interested in see a side-by-side comparison with identifying concurrency issues. Each system may be well on their way in building their own niche in the market. Considering the usefulness, efficiency, and feedback received from the concurrency debugging applications, I would definitely want to revisit this topic in a few years to see which approach reigns supreme.
In an ideal world, a programmer would love to reproduce a concurrency bug in a single replay and with no runtime overhead. PRES combines three ideas or techniques: (1) record only partial information to keep the replay close to the production run, (2) diagnose, process, and reconstruct unrecorded information to reproduce the bug, and (3) use feedback from unsuccessful replay runs to determine which paths do or do not produce the bug in question.
The various schemes of PRES are quite intriguing. I am not sure how thorough PRES is compared to CHESS. Even though CHESS is Microsoft-based, I would be interested in see a side-by-side comparison with identifying concurrency issues. Each system may be well on their way in building their own niche in the market. Considering the usefulness, efficiency, and feedback received from the concurrency debugging applications, I would definitely want to revisit this topic in a few years to see which approach reigns supreme.
Thursday, November 12, 2009
Shared Queue, Speculation, Circuits
Shared Queue Pattern
The shared queue pattern is found quite often in software applications involving the processing of multiple tasks. A centralized share queue is definitely one of the easier implementations. A common use of shared queue is with a thread pool. One concept is to allow the individual threads pull tasks directly from the queue. Another option is for a master thread to take responsibility for distributing the tasks to the threads for load balancing.
Although the examples in the paper used separate locks for put and take, I believe it is more common to use a single lock for the entire queue. Two locks might be overkill depending on the number threads working off the queue and the max size of the queue itself.
Speculation
I do wish the HTML lexer example was earlier in the paper. After getting through most of the paper, I recalled learning about speculation with branch prediction in a previous class. With branch prediction one path is speculatively chosen based on the past behavior of the program. This can be extended to speculatively execute both branches and terminate one of them when the result of the branch predicate is available.
I do want to go back and review this pattern again after the class discussion. I suspect there will be informative information discussed to help me gain a better understanding of this pattern.
Circuits Pattern
I can honestly say I had no idea what the Circuits Pattern entailed when reading the title. Even though this is not a Physics class, I thought it might have something to do with electronic circuits.
It is unfortunate I have not been professionally exposed to bit shifting as I might have had a more genuine appreciation for the examples of limited information presented in this paper. The md5 example was familiar and somewhat intriguing to see how it is really implemented. Looks like this might be another pattern I will revisit after the class discussion.
The shared queue pattern is found quite often in software applications involving the processing of multiple tasks. A centralized share queue is definitely one of the easier implementations. A common use of shared queue is with a thread pool. One concept is to allow the individual threads pull tasks directly from the queue. Another option is for a master thread to take responsibility for distributing the tasks to the threads for load balancing.
Although the examples in the paper used separate locks for put and take, I believe it is more common to use a single lock for the entire queue. Two locks might be overkill depending on the number threads working off the queue and the max size of the queue itself.
Speculation
I do wish the HTML lexer example was earlier in the paper. After getting through most of the paper, I recalled learning about speculation with branch prediction in a previous class. With branch prediction one path is speculatively chosen based on the past behavior of the program. This can be extended to speculatively execute both branches and terminate one of them when the result of the branch predicate is available.
I do want to go back and review this pattern again after the class discussion. I suspect there will be informative information discussed to help me gain a better understanding of this pattern.
Circuits Pattern
I can honestly say I had no idea what the Circuits Pattern entailed when reading the title. Even though this is not a Physics class, I thought it might have something to do with electronic circuits.
It is unfortunate I have not been professionally exposed to bit shifting as I might have had a more genuine appreciation for the examples of limited information presented in this paper. The md5 example was familiar and somewhat intriguing to see how it is really implemented. Looks like this might be another pattern I will revisit after the class discussion.
Wednesday, November 4, 2009
Armstrong Thesis (Chapter 6)
Chapter six of Joe Armstrong's thesis demonstrates the implementation of supervisors in the OTP system.
Believe it or not, hierarchies are used once again. I am not sure if it is an inferred concept of using Erlang or if it is a design decision by the developer. If you think about it, hierarchies are everywhere. There is always someone higher up the management ladder as you sit in your cubicle staring at the TPS cover sheets (eg. supervisors manage workers).
As with any language where I have not had a lot of hands-on use, I am still not very comfortable with the Erlang syntax. I am sure there are benefits of using Erlang that have not been expressed in the thesis. I think it is unfortunate the class will not be reading a few more chapters or appendix of the thesis. I do not have any real direct interest in learning about programming in Erlang, but the theories behind design choices can be applied to other system designs.
When looking at functionality, the supervisor and worker concept is similar to a thread manager being the parent of spawned child threads. The manager just sits in his office while the real workers do all the labor and satisfy any incomplete tasks. The child threads report back to the manager with status and the manager can re-spawn child threads if a thread happens to die.
Being one of the few thesis I have actually read voluntarily or involuntarily, it was an experience that may drive me to read more technical papers in order to stay knowledgeable on theories of design and development.
Believe it or not, hierarchies are used once again. I am not sure if it is an inferred concept of using Erlang or if it is a design decision by the developer. If you think about it, hierarchies are everywhere. There is always someone higher up the management ladder as you sit in your cubicle staring at the TPS cover sheets (eg. supervisors manage workers).
As with any language where I have not had a lot of hands-on use, I am still not very comfortable with the Erlang syntax. I am sure there are benefits of using Erlang that have not been expressed in the thesis. I think it is unfortunate the class will not be reading a few more chapters or appendix of the thesis. I do not have any real direct interest in learning about programming in Erlang, but the theories behind design choices can be applied to other system designs.
When looking at functionality, the supervisor and worker concept is similar to a thread manager being the parent of spawned child threads. The manager just sits in his office while the real workers do all the labor and satisfy any incomplete tasks. The child threads report back to the manager with status and the manager can re-spawn child threads if a thread happens to die.
Being one of the few thesis I have actually read voluntarily or involuntarily, it was an experience that may drive me to read more technical papers in order to stay knowledgeable on theories of design and development.
Pipeline, Geometric Decomposition, Data Parallelism
Pipeline is probably one of the more popular patterns used by a wide range of people most likely not recognizing they are actually using a synchronous pattern. One of the basic common methods of pipeline is in Unix scripting when users are "grepping" for certain characters in a file or filtering processes running on a server.
In addition to shell scripting, I have experience using pipelines in vector processing and signal processing. Various programs have used a message-passing environment if timeliness was a requirement. Otherwise, network file systems were very common as the concept was more dependable in case a stage of the pipeline failed.
The geometric decomposition pattern involves decomposing a data structure into chunks and processing the chunks in parallel. Designs for this apttern fall into four key elements: data decomposition, data exchange, update operation, and data distribution and task schedule. I would be interested in seeing more of this pattern to get a better understanding of how it can be applied to benefit my work.
Regarding the data parallelism pattern, I would tell you more if there was actual content worthy of commenting on. This pattern is very much in the early stages.
In addition to shell scripting, I have experience using pipelines in vector processing and signal processing. Various programs have used a message-passing environment if timeliness was a requirement. Otherwise, network file systems were very common as the concept was more dependable in case a stage of the pipeline failed.
The geometric decomposition pattern involves decomposing a data structure into chunks and processing the chunks in parallel. Designs for this apttern fall into four key elements: data decomposition, data exchange, update operation, and data distribution and task schedule. I would be interested in seeing more of this pattern to get a better understanding of how it can be applied to benefit my work.
Regarding the data parallelism pattern, I would tell you more if there was actual content worthy of commenting on. This pattern is very much in the early stages.
Tuesday, November 3, 2009
Task Parallelism, Recursive Splitting, Discrete Event
I thought had an inkling of an idea of what the Task Parallelism pattern. Boy, was I wrong. After reading the context a couple of times, it was the forces section that helped shed some light on what was actually being presented. Unfortunately, the examples of Monte Carlo simulations on a cluster of computers did not help solidify the pattern being presented. Perhaps a more concrete code example would have been more beneficial. I will be interested in hearing the discussion on this topic.
The Recursive Splitting pattern felt a bit like revisiting the fork/join pattern with a little twist. I am not sure how many other patterns take load balancing into account when determining the number of recursive splits to use. Too many or too few splits are of little benefit to the overall speed of the algorithm.
The Discrete Event pattern presents a method for trying to provide some form of order when dealing with independent tasks. Pessimistic approaches ensure the events are always executed in order at the expense of increased latency and communication overhead. I agree with the author in believing a deadlock timeout is more successful than deadlock detection. I also prefer message passing as a means for communication in systems.
The Recursive Splitting pattern felt a bit like revisiting the fork/join pattern with a little twist. I am not sure how many other patterns take load balancing into account when determining the number of recursive splits to use. Too many or too few splits are of little benefit to the overall speed of the algorithm.
The Discrete Event pattern presents a method for trying to provide some form of order when dealing with independent tasks. Pessimistic approaches ensure the events are always executed in order at the expense of increased latency and communication overhead. I agree with the author in believing a deadlock timeout is more successful than deadlock detection. I also prefer message passing as a means for communication in systems.
Monday, November 2, 2009
Armstrong Thesis (Chapter 5)
This chapter highlights fault-tolerant systems and how to achieve such success. It is difficult to be able to identify every possible circumstance the system will experience and how to handle the various circumstances.
The philosophy behind fault-tolerant systems is "if we cannot do what we want to do, then try to do something simpler." The thought involves creating a hierarchy of tasks being overseen by supervisors. If the highest level task cannot be performed by a worker process, then the supervisor process initiates a an error recovery procedure and will likely move down the ladder to a lower level task. The system will fail if you get to the ground with the simplest task of all.
The concept of AND and OR nodes reminds me of logic instituted on one of my past development programs. There was a parent or system executive process which monitored all other children processes. If the child process exited with a zero, then it was shutdown on purpose by a user. If the child process exited a value less than zero, the system executive had the ability to restart the child process if the configuration file deemed that action necessary. The concept came in handy when a process would get in a certain state and create a core file. The process is restarted with little interruption and developers could review the stack trace and core file for specific evidence.
I have not been exposed to the term "well-behaved function". Armstrong defines the WBF as a function which should not normally generate an exception. If an exception occurs which cannot be handled and corrected, the function should terminate with an exit statement. Notice the previous statement does not say the application should exit, just the function. Based on the four rules presented for WBFs, I must not fully understand how this approach is different than any other thoroughly thought out function in C++ or Java with try/catch blocks and throwing exceptions.
The philosophy behind fault-tolerant systems is "if we cannot do what we want to do, then try to do something simpler." The thought involves creating a hierarchy of tasks being overseen by supervisors. If the highest level task cannot be performed by a worker process, then the supervisor process initiates a an error recovery procedure and will likely move down the ladder to a lower level task. The system will fail if you get to the ground with the simplest task of all.
The concept of AND and OR nodes reminds me of logic instituted on one of my past development programs. There was a parent or system executive process which monitored all other children processes. If the child process exited with a zero, then it was shutdown on purpose by a user. If the child process exited a value less than zero, the system executive had the ability to restart the child process if the configuration file deemed that action necessary. The concept came in handy when a process would get in a certain state and create a core file. The process is restarted with little interruption and developers could review the stack trace and core file for specific evidence.
I have not been exposed to the term "well-behaved function". Armstrong defines the WBF as a function which should not normally generate an exception. If an exception occurs which cannot be handled and corrected, the function should terminate with an exit statement. Notice the previous statement does not say the application should exit, just the function. Based on the four rules presented for WBFs, I must not fully understand how this approach is different than any other thoroughly thought out function in C++ or Java with try/catch blocks and throwing exceptions.
Thursday, October 22, 2009
Armstrong Thesis (Chapter 4)
This chapter takes us in deeper into Erlang programming language and the various techniques of abstracting out concurrency, error handling, and intentional programming.
Armstrong makes an interesting statement by having the expert programmers write the difficult modules and the less experienced programmers write the easy modules. This would be a prime opportunity for applying pair programming in order to take junior developers under your wing and guide them to greatness.
He does go on to discuss how the generic component should hide the details of concurrency and fault-tolerance from the plugins, and the plugins should be written using only sequential code with well-defined types. One of the main points is the plugin can contain errors and not crash the server along with allowing the plugin to be modified dynamically.
I am glad I do not depend on publishing Erlang code in order to put food on the table for myself and the family. The syntax is not terrible or complicated, but it is different from your regular iterative programming language. In the examples I have seen, there are no data types or declaring of variables required. Yes, you can do a lot of exciting things with little code but at what expense.
Armstrong identifies the Erlang philosophy for handling errors:
Armstrong makes an interesting statement by having the expert programmers write the difficult modules and the less experienced programmers write the easy modules. This would be a prime opportunity for applying pair programming in order to take junior developers under your wing and guide them to greatness.
He does go on to discuss how the generic component should hide the details of concurrency and fault-tolerance from the plugins, and the plugins should be written using only sequential code with well-defined types. One of the main points is the plugin can contain errors and not crash the server along with allowing the plugin to be modified dynamically.
I am glad I do not depend on publishing Erlang code in order to put food on the table for myself and the family. The syntax is not terrible or complicated, but it is different from your regular iterative programming language. In the examples I have seen, there are no data types or declaring of variables required. Yes, you can do a lot of exciting things with little code but at what expense.
Armstrong identifies the Erlang philosophy for handling errors:
- Let some other process do the error recovery.
- If you can't do what you want to do, die.
- Let it crash.
- Do not program defensively.
Tuesday, October 20, 2009
Event-Based and Map Reduce Patterns
The event-based, implicit invocation, pattern implements a central event medium (i.e. manager) for handling the registration of and dispatching notification to listeners of events posted by the announcer. This concept seems logical so each announcer does not have duplicate similar code for handling registrations from listeners. By utilizing a central multi-threaded medium, many announcers of various events can take advantage of load balancing the notifications to the listeners.
It seems the event-based pattern use of the medium allows greater decoupling over the observer pattern. The announcer is not responsible for knowing which listeners are subscribed to the events as this is handled by the "third-party" medium. I think it actually simplifies the interface and modularizes the processes more. For greater number of listeners and guarantee of message delivery, systems may utilize middleware API like the Java Messaging Service (JMS) or commercialized products like JBoss or SonicMQ.
The map reduce pattern resembles the divide-and-conquer or fork/join framework. The idea is to split up the computations or various data retrieval tasks into smaller pieces and allow multiple threads or processor cores to independently obtain a result and then aggregate the results into a single response.
Errors in the map reduce pattern should be handled by the application developer as different errors require different actions. Depending on the data, an error may not be critical enough to cause the whole computation to be null and void.
It seems the event-based pattern use of the medium allows greater decoupling over the observer pattern. The announcer is not responsible for knowing which listeners are subscribed to the events as this is handled by the "third-party" medium. I think it actually simplifies the interface and modularizes the processes more. For greater number of listeners and guarantee of message delivery, systems may utilize middleware API like the Java Messaging Service (JMS) or commercialized products like JBoss or SonicMQ.
The map reduce pattern resembles the divide-and-conquer or fork/join framework. The idea is to split up the computations or various data retrieval tasks into smaller pieces and allow multiple threads or processor cores to independently obtain a result and then aggregate the results into a single response.
Errors in the map reduce pattern should be handled by the application developer as different errors require different actions. Depending on the data, an error may not be critical enough to cause the whole computation to be null and void.
Armstrong Thesis (Chapter 2)
The next couple of weeks will involve reading Joe Armstrong's thesis, Making reliable distributed systems in the presence of software errors, presented to the Royal Institute of Technology in Stockholm, Sweden in December 2003. The topics and issues described will be intriguing as we read each chapter.
This chapter describes an architecture for building fault-tolerant systems required for telecommunications switching networks. If you think about it, you expect your aging rotary dial phone to always get a dial tone when you pick up the receiver and be able to complete a phone call with no interrupts.
Telecommunications systems have some of the most stringent technical requirements. Due to the vast number of customers, switching systems are inherently concurrent and distributed across multiple locations of varying distances. These same systems are designed for many years of continuous operation requiring the performance of software or hardware updates without stopping the system.
The thesis advocates fault-isolation and forbids the use of shared data to deprecate the need for locks or mutexes. A software error in a concurrent process should not influence processing in the other processes in the system. The isolation is developed further by only allowing processes to communicate by message passing. This concept is intriguing as I have worked on systems implementing this type of isolation and how well it has worked when one process has an error. Unfortunately, if certain processes error out or crash, the rest of the system may not receive any message traffic to continue processing.
Armstrong suggests the use of the Erlang programming language to satisfy the requirements set forth in the thesis. Erlang was designed by Ericsson to support distributed, fault-tolerant, soft real-time, non-stop applications. The first version was actually developed by Joe Armstrong 17 years earlier.
I look forward to reading the remaining chapters to see what insight Armstrong can provide about telecommunications systems and the implementation of the architectural model.
This chapter describes an architecture for building fault-tolerant systems required for telecommunications switching networks. If you think about it, you expect your aging rotary dial phone to always get a dial tone when you pick up the receiver and be able to complete a phone call with no interrupts.
Telecommunications systems have some of the most stringent technical requirements. Due to the vast number of customers, switching systems are inherently concurrent and distributed across multiple locations of varying distances. These same systems are designed for many years of continuous operation requiring the performance of software or hardware updates without stopping the system.
The thesis advocates fault-isolation and forbids the use of shared data to deprecate the need for locks or mutexes. A software error in a concurrent process should not influence processing in the other processes in the system. The isolation is developed further by only allowing processes to communicate by message passing. This concept is intriguing as I have worked on systems implementing this type of isolation and how well it has worked when one process has an error. Unfortunately, if certain processes error out or crash, the rest of the system may not receive any message traffic to continue processing.
Armstrong suggests the use of the Erlang programming language to satisfy the requirements set forth in the thesis. Erlang was designed by Ericsson to support distributed, fault-tolerant, soft real-time, non-stop applications. The first version was actually developed by Joe Armstrong 17 years earlier.
I look forward to reading the remaining chapters to see what insight Armstrong can provide about telecommunications systems and the implementation of the architectural model.
Thursday, October 15, 2009
Pipes & Filter, Layered Systems, Iterative Refinement
We had previously read whitepapers on pipes & filters and layered systems. This time we also add an unfamiliar pattern called Iterative Refinement. The information presented in the whitepapers was much more intuitive and self-explanatory than the pattern information presented by the Parallel Computing Laboratory at Berkeley.
I really wish there was more information on each one of the patterns. Maybe I have been spoiled by the Gang of Four and Head First, but I receive so much more detail from these texts than what the online OPL has provided. Not to mention the numerous code examples in the texts compared the non-existent examples online. I am a visual type of person and appreciate when the examples are provided for my benefit. Since this is a website, the patterns could be under constant update or have plans to be expanded. The published papers (or scanned pages from a book) read previously satisfied my knack for examples.
As mentioned earlier, the Iterative Refinement was unfamiliar to me. Even after reading the pattern a couple of times, I am not confident as to what this pattern is used for. I realize I am not the only one with a quizzical look on my face after reading comments from other classmates. This almost sounds like it could be applied to the divide and conquer concept or an algorithm that requires multiple recursive calls in order to complete a calculation. I would like to request a more thorough explanation or example of the Iterative Refinement pattern.
I really wish there was more information on each one of the patterns. Maybe I have been spoiled by the Gang of Four and Head First, but I receive so much more detail from these texts than what the online OPL has provided. Not to mention the numerous code examples in the texts compared the non-existent examples online. I am a visual type of person and appreciate when the examples are provided for my benefit. Since this is a website, the patterns could be under constant update or have plans to be expanded. The published papers (or scanned pages from a book) read previously satisfied my knack for examples.
As mentioned earlier, the Iterative Refinement was unfamiliar to me. Even after reading the pattern a couple of times, I am not confident as to what this pattern is used for. I realize I am not the only one with a quizzical look on my face after reading comments from other classmates. This almost sounds like it could be applied to the divide and conquer concept or an algorithm that requires multiple recursive calls in order to complete a calculation. I would like to request a more thorough explanation or example of the Iterative Refinement pattern.
Wednesday, October 14, 2009
CHESS
CHESS is an automated concurrency testing tool for finding and reproducing Heisenbugs in your concurrent programs.
You might ask yourself, "What is a Heisenbug?" It is a bug in a computer program that goes away or radically changes its behavior when attempts are made to investigate it. If you have ever programmed with threads, you have likely come across a Heisenbug. Do you remember that time when a thread was deadlocking or returning the wrong value and the error no longer occurred after adding a debug statement around the suspected area of code? The case of the error no longer occurring is the Heisenbug.
It is unfortunate CHESS is so limited as to which languages and platforms are supported. As a product developed by Microsoft Research, CHESS is only available for the Windows platform requiring Windows 2003 or later, 32-bit, x86, and Visual Studio 2008. Looks like I won't be able to use CHESS for quite some time until there is a Linux or Mac version available. With all of the useful features and possible exposure, I would expect an open-source team to devise a CHESS version that is compatible with other platforms. Even developing a version for Java or C++ would be a step in the right direction.
I am impressed by the number of iterations, permutations, and interleavings the tool can go through in such a short amount of time. There would have been many hours saved troubleshooting various issues in the past. The fact CHESS can learn and reproduce a failed execution over and over again. Repetition of the error is key to troubleshooting a problem. CHESS definitely corners the market on being able to capture and explore all interleaving determinism for large or small systems.
You might ask yourself, "What is a Heisenbug?" It is a bug in a computer program that goes away or radically changes its behavior when attempts are made to investigate it. If you have ever programmed with threads, you have likely come across a Heisenbug. Do you remember that time when a thread was deadlocking or returning the wrong value and the error no longer occurred after adding a debug statement around the suspected area of code? The case of the error no longer occurring is the Heisenbug.
It is unfortunate CHESS is so limited as to which languages and platforms are supported. As a product developed by Microsoft Research, CHESS is only available for the Windows platform requiring Windows 2003 or later, 32-bit, x86, and Visual Studio 2008. Looks like I won't be able to use CHESS for quite some time until there is a Linux or Mac version available. With all of the useful features and possible exposure, I would expect an open-source team to devise a CHESS version that is compatible with other platforms. Even developing a version for Java or C++ would be a step in the right direction.
I am impressed by the number of iterations, permutations, and interleavings the tool can go through in such a short amount of time. There would have been many hours saved troubleshooting various issues in the past. The fact CHESS can learn and reproduce a failed execution over and over again. Repetition of the error is key to troubleshooting a problem. CHESS definitely corners the market on being able to capture and explore all interleaving determinism for large or small systems.
Tuesday, October 13, 2009
Rereading the Classics (Beautiful Architecture - Chapter 14)
We have finally blasted our way through the Beautiful Architecture book with the final chapter on Smalltalk and architecture. Like some of my classmates, I learned about and had hands-on experience with Smalltalk in Ralph Johnson's CS598RJ class at UIUC. I highly recommend the class to anyone wanting to experience a fully object-oriented language (and needing another 500-level credit).
As with any new language, using Smalltalk for the first time is a bit overwhelming. You have new syntax, new commands, and a new GUI (if using Squeak). "Modern-day" programming languages such as Java, Python, and Ruby have been influenced by concepts from Smalltalk. It is unfortunate Smalltalk is not more popular among developers. I would be interested in seeing a mainstream software application developed in Smalltalk. I am not aware of a significant software package written solely in Smalltalk.
I would like to give a kudos to @JLSjr for his latest blog entry. Well stated!
You always want to jump to the end of a book to see how it ends. Even though it is not a suspense novel, the last line of the book sums it up nicely:
As with any new language, using Smalltalk for the first time is a bit overwhelming. You have new syntax, new commands, and a new GUI (if using Squeak). "Modern-day" programming languages such as Java, Python, and Ruby have been influenced by concepts from Smalltalk. It is unfortunate Smalltalk is not more popular among developers. I would be interested in seeing a mainstream software application developed in Smalltalk. I am not aware of a significant software package written solely in Smalltalk.
I would like to give a kudos to @JLSjr for his latest blog entry. Well stated!
You always want to jump to the end of a book to see how it ends. Even though it is not a suspense novel, the last line of the book sums it up nicely:
Architecture is a chaotic adventure because beautiful architecture alone is not enough; not only beauty, but also usefulness, is the law for architecture and programming alike.
Refactoring for Reentrancy
Prior to reading this paper, I had no significant understanding of the term 'reentrant'. The idea is a program can be reentrant is distinct executions of that program on distinct inputs cannot affect each other. Many existing Java programs are not reentrant because they rely on mutable global state.
The developers implemented the refactoring for reentrancy in a tool called Reentrancer as an extension to the the Eclipse Java development tools (JDT). The refactoring for making programs reentrant are:
The developers implemented the refactoring for reentrancy in a tool called Reentrancer as an extension to the the Eclipse Java development tools (JDT). The refactoring for making programs reentrant are:
- Removal of non-reentrant accesses to library global state.
- Encapsulation of static fields in the application in getter/setter methods.
- Replacing static initializers with explicit lazy initialization.
- Replacing global state with thread-local state.
- Transforming the application to use a fresh thread for each execution.
Sunday, October 11, 2009
ReLooper: Refactoring for Loop Parallelism
I had no idea this paper co-authored by Dig, Radoi, Tarce, Minea, and Johnson had not been published yet. With all of the potential benefits from ReLooper, I expected to find a slew of information on the internet about it. Much to my demise, there was more blog entries from my classmates than more insight into this Eclipse plugin.
As I am a hands-on person and have to experience the benefits first-hand, I was really hoping to find the plugin available in the community. Again, my search returned no results. Even the Eclipse and Eclipse plugin website do not mention ReLooper. I have not had much exposure or opportunity to investigate parallel development. As with any automated tool, I am always a little hesitant to accept it for face value based on a technical paper.
Danny Dig is presenting/demonstrating ReLooper at OOPSLA 2009 on 28 October. It will be interesting to see how the plugin is received and what topics of discussion are spawned from the presentation. In addition to OOPSLA, there appears to be plans to formally present the paper at the 32nd International Conference on Software Engineering in Cape Town, South Africa in May 2010.
As I am a hands-on person and have to experience the benefits first-hand, I was really hoping to find the plugin available in the community. Again, my search returned no results. Even the Eclipse and Eclipse plugin website do not mention ReLooper. I have not had much exposure or opportunity to investigate parallel development. As with any automated tool, I am always a little hesitant to accept it for face value based on a technical paper.
Danny Dig is presenting/demonstrating ReLooper at OOPSLA 2009 on 28 October. It will be interesting to see how the plugin is received and what topics of discussion are spawned from the presentation. In addition to OOPSLA, there appears to be plans to formally present the paper at the 32nd International Conference on Software Engineering in Cape Town, South Africa in May 2010.
Saturday, October 10, 2009
Object-Oriented vs. Functional Programming (Beautiful Architecture - Chapter 13)
For those not familiar with the term, you might ask what is functional programming? Functional programming is a style of programming that emphasizes the evaluation of expressions rather than the execution of commands.
UIUC students (undergraduate and graduate) will learn about functional programming and OCaml if they take CS 421, Programming Languages & Compilers, as part of their degree. Students will be exposed to and receive hands-on experience as to how a functional programming language eases the pain of writing the various components of a common code compiler. It does take some time getting used to the syntax and break out of the shell of imperative programming.
Functional programming has its place, but that place is not in everyday software development. Maybe I am biased since the industry of my employment relies on modular, reliable, extensible, and maintainable software. That does not mean C++ or Java is the answer to all software development projects. Object-oriented concepts applied through common development languages allows the majority of software engineers to understand and maintain the code.
We all know the keys to good software architecture. Make sure code is extensible so modifications affect as few modules as possible. A one-module solution does not support reusability. Modularity is the key to successful software design.
I, personally, found it more difficult to troubleshoot or debug functional program code. It was uncomfortable to comprehend the logic and try to apply patterns or refactor your code. The same ideas or concepts that have been ingrained in our brains are not easily interchangeable between object-oriented and functional programming.
UIUC students (undergraduate and graduate) will learn about functional programming and OCaml if they take CS 421, Programming Languages & Compilers, as part of their degree. Students will be exposed to and receive hands-on experience as to how a functional programming language eases the pain of writing the various components of a common code compiler. It does take some time getting used to the syntax and break out of the shell of imperative programming.
Functional programming has its place, but that place is not in everyday software development. Maybe I am biased since the industry of my employment relies on modular, reliable, extensible, and maintainable software. That does not mean C++ or Java is the answer to all software development projects. Object-oriented concepts applied through common development languages allows the majority of software engineers to understand and maintain the code.
We all know the keys to good software architecture. Make sure code is extensible so modifications affect as few modules as possible. A one-module solution does not support reusability. Modularity is the key to successful software design.
I, personally, found it more difficult to troubleshoot or debug functional program code. It was uncomfortable to comprehend the logic and try to apply patterns or refactor your code. The same ideas or concepts that have been ingrained in our brains are not easily interchangeable between object-oriented and functional programming.
Wednesday, October 7, 2009
Refactoring Sequential Java Code for Concurreny via Concurrent Libraries
With all of the talk about locks, threads, forks, and atomicity, the lessons being taught this semester in CS423, Operating System Design, with Dr. Sam King provide a reasonable understanding of the concepts discussed in this paper.
Atomicity is key when dealing with parallelism. In case you are not aware of the concept, atomicity can be thought of as a transaction on a database -- it either happens in its entirety without interruption or does not happen at all. No events from other threads can happen in between the start and stop of an atomic event.
As I was reading the paper, the first question to come to mind was how does a call to ConcurrentHashMap's putIfAbsent perform an update without locking the entire map? It is ideal for no updates to occur on an object, especially a queue or map, when being read or updated. The theory later came to light when it was identified only the part of the map being read or updated would be locked. The concept is fairly intriguing as I am not aware of it ever being done before quite that way. It means other threads could ideally continue to operate on other parts of the hash without interfering with other operations.
Why are there no atomic APIs in AtomicInteger for multiplication and division operators? Unfortunately, this answer was never explained. I wonder if it is because you may not end up with an integer as the result.
I greatly appreciate the consideration of not changing the original interface of a recursive method when converting to ForkJoinTask. Interfaces should not change and any change to the logic should be hidden from external clients. This is very critical when other systems depending on your system for a service expect that interface to always be there. Depending on the type system being impacted, a change to the interface could be very costly.
Concurrencer is more efficient and more accurate than refactoring by hand. Concurrencer produces the correct code in about 10 seconds and identified more opportunities for using the new, scalable APIs. Manual conversion is always error-prone. Having used refactoring tools in Eclipse, I am always hesitant about fully automating some manual actions. It would be wise to backup the current code into CVS or subversion before applying any automatic changes. After the changes are complete, you can do a diff to visually verify the changes are accurate. There will likely always that odd case where the automated tool did not know how to handle your code properly.
Atomicity is key when dealing with parallelism. In case you are not aware of the concept, atomicity can be thought of as a transaction on a database -- it either happens in its entirety without interruption or does not happen at all. No events from other threads can happen in between the start and stop of an atomic event.
As I was reading the paper, the first question to come to mind was how does a call to ConcurrentHashMap's putIfAbsent perform an update without locking the entire map? It is ideal for no updates to occur on an object, especially a queue or map, when being read or updated. The theory later came to light when it was identified only the part of the map being read or updated would be locked. The concept is fairly intriguing as I am not aware of it ever being done before quite that way. It means other threads could ideally continue to operate on other parts of the hash without interfering with other operations.
Why are there no atomic APIs in AtomicInteger for multiplication and division operators? Unfortunately, this answer was never explained. I wonder if it is because you may not end up with an integer as the result.
I greatly appreciate the consideration of not changing the original interface of a recursive method when converting to ForkJoinTask. Interfaces should not change and any change to the logic should be hidden from external clients. This is very critical when other systems depending on your system for a service expect that interface to always be there. Depending on the type system being impacted, a change to the interface could be very costly.
Concurrencer is more efficient and more accurate than refactoring by hand. Concurrencer produces the correct code in about 10 seconds and identified more opportunities for using the new, scalable APIs. Manual conversion is always error-prone. Having used refactoring tools in Eclipse, I am always hesitant about fully automating some manual actions. It would be wise to backup the current code into CVS or subversion before applying any automatic changes. After the changes are complete, you can do a diff to visually verify the changes are accurate. There will likely always that odd case where the automated tool did not know how to handle your code properly.
Tuesday, October 6, 2009
Building Cathedrals (Beautiful Architecture - Chapter 12)
Having a particular interest in the many successes of Linux and KDE, this was a great chapter for highlighting some of the growing pains experienced on Open-Source projects.
Whether it be Free Software or commercially-developed, all software face technical challenges. Data is always growing and is becoming more complex. Users want easier-to-use interfaces; responsive and not overly complex interactions with software and high reliability, stability, and safety. Developers expect well-maintained APIs, clean migration paths, and functionality at the level of their day jobs.
With the Free Software development teams being so disparate and spread across the world, it is a wonder how anything was agreed upon. Communication is still key. It was recognized where most decisions made in 15-minute stand-up meetings , it may take days for each person in other hemispheres to provide their feedback or opinions.
One of the interesting aspects of the KDE community is the lack of commercial governance. Developers did not want to be influenced or pressured by executives providing funding in order to take control of the project. There are no dictators cracking whips and shouting orders to the minions in the dungeon.
It was a pleasure to read a chapter where the author does not delve too deep into the architecture and confuse the reader. The sections on the Akonadi framework and KDEPIM were very enlightening as to the various approaches considered in the software integration and architecture. A decision is never going to be perfect or the "one size fits all" choice for everyone involved. It is a guarantee applications are going to be decommissioned when something better comes along, libraries will be replaced, and interfaces will change. Software and system development is not stale. Climb aboard and be part of the innovation.
Whether it be Free Software or commercially-developed, all software face technical challenges. Data is always growing and is becoming more complex. Users want easier-to-use interfaces; responsive and not overly complex interactions with software and high reliability, stability, and safety. Developers expect well-maintained APIs, clean migration paths, and functionality at the level of their day jobs.
With the Free Software development teams being so disparate and spread across the world, it is a wonder how anything was agreed upon. Communication is still key. It was recognized where most decisions made in 15-minute stand-up meetings , it may take days for each person in other hemispheres to provide their feedback or opinions.
One of the interesting aspects of the KDE community is the lack of commercial governance. Developers did not want to be influenced or pressured by executives providing funding in order to take control of the project. There are no dictators cracking whips and shouting orders to the minions in the dungeon.
It was a pleasure to read a chapter where the author does not delve too deep into the architecture and confuse the reader. The sections on the Akonadi framework and KDEPIM were very enlightening as to the various approaches considered in the software integration and architecture. A decision is never going to be perfect or the "one size fits all" choice for everyone involved. It is a guarantee applications are going to be decommissioned when something better comes along, libraries will be replaced, and interfaces will change. Software and system development is not stale. Climb aboard and be part of the innovation.
Wednesday, September 30, 2009
GNU Emacs (Beautiful Architecture - Chapter 11)
Emacs has been described as antiquated, unimpressive, and down right repulsive. And those were just the comments overheard in a small group of software engineers working in the same common area. Yes, I am guilty of being one of many of those critics. The majority of the complaints from coworkers who did not want to devote the necessary time to learn keystrokes features of another editor. The vi editor and nedit were sufficient applications that were commonly installed across most of our platforms and adequately known by most of the developers.
As far as I can recall, there was mainly one software engineer out of approximately twenty-five that used Emacs religiously and proclaimed it as gospel. Maybe it had something to do with being from Oklahoma and living in Texas. Whatever the case, he did know how to use the features very well and created a class navigation macro or primitive very similar to drilling down into classes and subclasses in the Eclipse IDE.
Emac's architecture follows the widely used Model-View-Controller pattern for interactive applications and is written almost entirely in Lisp. Before reading this chapter, I can honestly say have never looked at Lisp code. Now I know why. Maybe it is the way Pascal, C++, and Java have been spoon fed to me over the years, writing applications for Emacs does not appear to be the most exciting task to complete.
Emacs developed a hierarchy of update strategies ranging from the quick-but-limited to the more-work-but-exhaustive. Emacs determined which algorithms to use based on the speed of the terminal and the communication connection. I will give Emacs the benefit of the doubt and say that was a pretty impressive idea. I doubt you will find many of today's modern systems willing to gamble and take that much consideration into their logic. Most systems today submit a minimum CPU or memory requirement that will not provide a bottleneck and degrade usability.
Unlike wine, I am convinced Emacs does not get better with age. There are so many other options available in the community. I think Emacs will always get the bad wrap of just being an over-hyped, bloated text editor. Maybe I am pessimistic, but I do not see Emacs becoming the tool of choice even if has been around for 20+ years.
As far as I can recall, there was mainly one software engineer out of approximately twenty-five that used Emacs religiously and proclaimed it as gospel. Maybe it had something to do with being from Oklahoma and living in Texas. Whatever the case, he did know how to use the features very well and created a class navigation macro or primitive very similar to drilling down into classes and subclasses in the Eclipse IDE.
Emac's architecture follows the widely used Model-View-Controller pattern for interactive applications and is written almost entirely in Lisp. Before reading this chapter, I can honestly say have never looked at Lisp code. Now I know why. Maybe it is the way Pascal, C++, and Java have been spoon fed to me over the years, writing applications for Emacs does not appear to be the most exciting task to complete.
Emacs developed a hierarchy of update strategies ranging from the quick-but-limited to the more-work-but-exhaustive. Emacs determined which algorithms to use based on the speed of the terminal and the communication connection. I will give Emacs the benefit of the doubt and say that was a pretty impressive idea. I doubt you will find many of today's modern systems willing to gamble and take that much consideration into their logic. Most systems today submit a minimum CPU or memory requirement that will not provide a bottleneck and degrade usability.
Unlike wine, I am convinced Emacs does not get better with age. There are so many other options available in the community. I think Emacs will always get the bad wrap of just being an over-hyped, bloated text editor. Maybe I am pessimistic, but I do not see Emacs becoming the tool of choice even if has been around for 20+ years.
Sunday, September 27, 2009
Metacircular Virtual Machines: Jikes RVM (Beautiful Architecture - Chapter 10)
Jikes RVM is a Java Virtual Machine written in Java for Java applications. Is that a good thing or a bad thing? The author claims "being written in the language supported by the runtime allows close integration and reuse of components." I am not positive on all of the benefits but one that did catch my attention had to do with how a C VM does not track what methods are currently running on a stack like Jikes RVM.
It is likely I would comprehend the last 20+ pages I just read if I went back and read it two or three more times. Perhaps if I had more experience with virtual machines this chapter would not have been so "Greek" to me.
Some of the information did appear to be reasonably thought out and make sense in context of the whole. Having completed my undergraduate education over 10 years ago, it is possible I have lost the context of advancements in system architecture and how beneficial virtual machines are to development community. I do believe virtual machines have the ability to become the de facto standard for software development programs that are looking for secure environments without impacting other development efforts and might be strapped for hardware financial backing.
It is likely I would comprehend the last 20+ pages I just read if I went back and read it two or three more times. Perhaps if I had more experience with virtual machines this chapter would not have been so "Greek" to me.
Some of the information did appear to be reasonably thought out and make sense in context of the whole. Having completed my undergraduate education over 10 years ago, it is possible I have lost the context of advancements in system architecture and how beneficial virtual machines are to development community. I do believe virtual machines have the ability to become the de facto standard for software development programs that are looking for secure environments without impacting other development efforts and might be strapped for hardware financial backing.
Our Pattern Language
Having read the Gang of Four software patterns and the Head First version on the same topic, I can say I was not overly impressed with the content of this paper. There is very little sustenance to the paper of which there is significant interest to tell the software development community.
The author organized the patterns into a stacked, layered system. The categories in which the patterns are organized are:
Obviously an incomplete work and work in progress, this paper on OPL is more of a teaser. The author says "experienced parallel programmers will most likely understand the intent of the patterns just from these brief descriptions." The descriptions presented to the reader are brief. Unfortunately for me, I do not fall in this category. The more detailed descriptions are on the wiki.
With the remaining limited advancement and imminent stalemate of hardware design, parallel programming is going to be the key to utilizing available resources and increasing the processing capabilities in software applications. This paper and accompanying information on the wiki could become the guidance needed to push software over the top.
The author organized the patterns into a stacked, layered system. The categories in which the patterns are organized are:
- Architectural patterns
- Computational patterns
- Parallel algorithm strategy patterns
- Implementation strategy patterns
- Concurrent execution patterns
Obviously an incomplete work and work in progress, this paper on OPL is more of a teaser. The author says "experienced parallel programmers will most likely understand the intent of the patterns just from these brief descriptions." The descriptions presented to the reader are brief. Unfortunately for me, I do not fall in this category. The more detailed descriptions are on the wiki.
With the remaining limited advancement and imminent stalemate of hardware design, parallel programming is going to be the key to utilizing available resources and increasing the processing capabilities in software applications. This paper and accompanying information on the wiki could become the guidance needed to push software over the top.
Thursday, September 24, 2009
Adaptive Object-Model Architectural Style
Trying to make a system dynamic and easily configurable can be hard, but the payoff can be large. The Adaptive Object-Model is an architectural style that relies on storing the business or domain model separately from the code. Implementation of the model can lead to system that allows users to "program without programming".
It is interesting to see how each example system implemented the concept differently based on their domain. The Illinois Department of Health is a good example of how a system needs to be able to adapt quickly when additional data is required to be collected. Your customer does not want to be delayed and have to wait for the next software version to be released in order to capture the necessary data.
Thinking about how complicated our tax code is in the United States, you have to wonder how all the various rules and data are stored for online software programs like eTax. The tax code changes regularly and the tax software developers need to implement the changes quickly. Do you add a new table in the database for each tax form with every "blank line" as a database field?
I would be curious to know how much more upfront design might be required for implementing the AOM into a system. The architect may not immediately recognize or notice the system design has greater flexibility when adopting this model. A paper detailing the growing pains or benefits of a system that has converted from a "traditional" relational-database design to an AOM design might spark some additional interest.
Even though the concept of using the AOM is to make it possible to develop and to change software quickly, are there any noticeable side-effects or performance degradations on the database when being used this way? How does the number of reads and writes on a normalized table schema differ from the number of reads and writes on tables using the AOM schema?
I should note the co-author of this paper, Joseph Yoder, is hosting a half-day tutorial on the AOM at OOPSLA in October 2009. It is unfortunate I will not get a chance to attend.
It is interesting to see how each example system implemented the concept differently based on their domain. The Illinois Department of Health is a good example of how a system needs to be able to adapt quickly when additional data is required to be collected. Your customer does not want to be delayed and have to wait for the next software version to be released in order to capture the necessary data.
Thinking about how complicated our tax code is in the United States, you have to wonder how all the various rules and data are stored for online software programs like eTax. The tax code changes regularly and the tax software developers need to implement the changes quickly. Do you add a new table in the database for each tax form with every "blank line" as a database field?
I would be curious to know how much more upfront design might be required for implementing the AOM into a system. The architect may not immediately recognize or notice the system design has greater flexibility when adopting this model. A paper detailing the growing pains or benefits of a system that has converted from a "traditional" relational-database design to an AOM design might spark some additional interest.
Even though the concept of using the AOM is to make it possible to develop and to change software quickly, are there any noticeable side-effects or performance degradations on the database when being used this way? How does the number of reads and writes on a normalized table schema differ from the number of reads and writes on tables using the AOM schema?
I should note the co-author of this paper, Joseph Yoder, is hosting a half-day tutorial on the AOM at OOPSLA in October 2009. It is unfortunate I will not get a chance to attend.
Tuesday, September 22, 2009
JPC (Beautiful Architecture - Chapter 9)
"Emulation is better than pure virtualization. An emulator will always be the most stable and secure means to virtualization." Who knew there was so much security in using JPC? You have to ask yourself why the concept is not widely distributed for common everyday use if it really is that secure. I wonder if you could build an infrastructure strong enough to support a university system on either emulators or pure virtual machines.
I happen to be using the QEMU (C++ based) emulator in CS 423 with Sam King this semester. The emulator was used to verify the results of adding a new system call in the Linux kernel in MP1. One advantage QEMU has over e.g. VMWare (used in previous semesters) is the ability to easily run a linux kernel image that was compiled outside of the Virtual Machine. This means the linux source code will reside in the host; this means compilation is also done on the host (which saves us a lot of time). On the other hand, because the source code is not in the VM, installation of modules and headers takes a little bit more work.
I can honestly say that no one has ever explained the difference between exception and error to me. This chapter defines an exception as a rare or exceptional condition, but not necessarily a fatal one. Error is used for fatal or certainly seriously undesirable situations. There have many, many times when I have used exception for catching errors and vice-versa.
Similar to Beta vs. VHS and HD-DVD vs. Blue-Ray, it will be interesting to see if emulator or virtualization comes out on top. Will it be performance or security that reigns supreme?
I happen to be using the QEMU (C++ based) emulator in CS 423 with Sam King this semester. The emulator was used to verify the results of adding a new system call in the Linux kernel in MP1. One advantage QEMU has over e.g. VMWare (used in previous semesters) is the ability to easily run a linux kernel image that was compiled outside of the Virtual Machine. This means the linux source code will reside in the host; this means compilation is also done on the host (which saves us a lot of time). On the other hand, because the source code is not in the VM, installation of modules and headers takes a little bit more work.
I can honestly say that no one has ever explained the difference between exception and error to me. This chapter defines an exception as a rare or exceptional condition, but not necessarily a fatal one. Error is used for fatal or certainly seriously undesirable situations. There have many, many times when I have used exception for catching errors and vice-versa.
Similar to Beta vs. VHS and HD-DVD vs. Blue-Ray, it will be interesting to see if emulator or virtualization comes out on top. Will it be performance or security that reigns supreme?
Sunday, September 20, 2009
Big Ball of Mud
"If you think good architecture is expensive, try bad architecture." Yes, the initial cost may be cheaper, but the price is going to skyrocket when the constant maintenance headaches creep into reality. Maybe cutting corners wasn't such a good idea. You start getting upset customers due to lack of stability and usability followed by upset developers attempting to maintain the system. The customer is losing profit and developers are losing their minds. It is a win-win situation if you are trying bring a system to its demise, but not so good if trying to be successful.
Have you ever noticed the worse the looking the code the longer the shelf-life? Think about it. No one wants to touch the dingy spaghetti code because you will go in with a nice, clean white shirt and come out with sauce all over your body. You could possibly "sweep it under the rug" for the time being, but, eventually, you are going to have to get your hands dirty by either doing some major refactoring, isolation, or reconstruction.
After a system has failed to meet a deadline or fallen flat on its face during a demonstration to the customer, upper management takes the lack of architecture guidance to the extreme other enf o the spectrum. Do not try to correct failed design by doing a 180-degree turn to the rigid, totalitarian, top-down design with architects requiring every hair to be in its place before moving on to implementation. That could be a very costly and detrimental choice.
It is funny how a simple prototype can easily become the productized version of the software being delivered to the customer. There is a reason it is called throwaway code. It is ideal to completely toss the code away. This is especially true when the requirements of the customer change. Management believes the software can be modified with no penalty to future design even though the current architecture cannot fully support the customer's requirements. Too many developers start trying to "patch" the code in order to satisfy the need of the customer. The longer the patching goes, the harder it is going to be to refactor or reconstruct the architecture in the long run.
Have you ever noticed the worse the looking the code the longer the shelf-life? Think about it. No one wants to touch the dingy spaghetti code because you will go in with a nice, clean white shirt and come out with sauce all over your body. You could possibly "sweep it under the rug" for the time being, but, eventually, you are going to have to get your hands dirty by either doing some major refactoring, isolation, or reconstruction.
After a system has failed to meet a deadline or fallen flat on its face during a demonstration to the customer, upper management takes the lack of architecture guidance to the extreme other enf o the spectrum. Do not try to correct failed design by doing a 180-degree turn to the rigid, totalitarian, top-down design with architects requiring every hair to be in its place before moving on to implementation. That could be a very costly and detrimental choice.
It is funny how a simple prototype can easily become the productized version of the software being delivered to the customer. There is a reason it is called throwaway code. It is ideal to completely toss the code away. This is especially true when the requirements of the customer change. Management believes the software can be modified with no penalty to future design even though the current architecture cannot fully support the customer's requirements. Too many developers start trying to "patch" the code in order to satisfy the need of the customer. The longer the patching goes, the harder it is going to be to refactor or reconstruct the architecture in the long run.
Guardian (Beautiful Architecture - Chapter 8)
Prior to reading this paper, I had no knowledge of the so-called accomplishments related to the Tandem Corporation or the Guardian operating system.
The Tandem/16 naming convention appears to be complex compared to what we are used to with the likes of Linux, Solaris, Mac OS, and Windows. I think the only possible advantage of the naming convention might be knowing whether or not the process belongs to the system or user and if the process is local or external. The use of $, #, \ is a bit overkill. Give me a PID and an ASCII name, and I am ready to go.
I can't say I have had the pleasure of working on fault-tolerant systems as described in this chapter. My experience is primarily in that of redundant systems and clusters which is a slightly different approach. If a CPU or disk failed causing the server to be non-responsive, the processes failover to other nodes to take over the load with minimal to nil downtime. The failed server could then be repaired and brought back online with no noticeable impacts.
It is interesting how the ownership of Tandem came full circle. Engineers had left HP to form their own company only to get saved by Compaq and eventually bought by HP. It was a nice run while it lasted. Some of the "benefits" of working for Tandem have carried over into some companies when trying to lure innovative personnel. Unfortunately, for some companies, benefits are usually the first things to get cut when budget reduction comes into play.
The Tandem/16 naming convention appears to be complex compared to what we are used to with the likes of Linux, Solaris, Mac OS, and Windows. I think the only possible advantage of the naming convention might be knowing whether or not the process belongs to the system or user and if the process is local or external. The use of $, #, \ is a bit overkill. Give me a PID and an ASCII name, and I am ready to go.
I can't say I have had the pleasure of working on fault-tolerant systems as described in this chapter. My experience is primarily in that of redundant systems and clusters which is a slightly different approach. If a CPU or disk failed causing the server to be non-responsive, the processes failover to other nodes to take over the load with minimal to nil downtime. The failed server could then be repaired and brought back online with no noticeable impacts.
It is interesting how the ownership of Tandem came full circle. Engineers had left HP to form their own company only to get saved by Compaq and eventually bought by HP. It was a nice run while it lasted. Some of the "benefits" of working for Tandem have carried over into some companies when trying to lure innovative personnel. Unfortunately, for some companies, benefits are usually the first things to get cut when budget reduction comes into play.
Thursday, September 17, 2009
Xen and the Beauty of Virtualization (Beautiful Architecture - Chapter 7)
I am intrigued by the progress made in virtualization and the publicized benefits of such. The 20 or so pages presented in this chapter was somewhat informative since I have never really been exposed to the technology. The reading is getting my interest in pursuing some options with virtualization. As I have other questions concerning virtualization, I am going to divert away from the actual content of the reading.
Is virtualization really as good as it is made out to be? The hype is definitely taking the industry by storm as one way to be more energy efficient and give an opportunity for applications play in their own "sandbox" without disturbing the other kids. I really do not have any experience with virtual machines except with the web hosting company who hosts websites for me. I have heard about sluggishness on laptops and desktops running VMWare. Does Xen experience the same issues?
Where is the cost savings that is being promoted when switching to virtualization? Yes, you can possibly reduce the hardware footprint of 10 HP DL380 servers down to 1 virtual host manager with 10 virtual machines. What is the minimum hardware requirement in order to virtualize 10 Linux servers on one host? How many CPUs and amount of memory will you need to maintain acceptable operating environments? Poor performance and latency is not ideal or an acceptable situation.
Would virtualization be an ideal situation for setting up a "development farm" for 10 developers all running Eclipse with a few virtual nodes running Oracle or MySQL? Can you create a database cluster across virtual nodes?
Just some thoughts, ideas, and questions to ponder...
Is virtualization really as good as it is made out to be? The hype is definitely taking the industry by storm as one way to be more energy efficient and give an opportunity for applications play in their own "sandbox" without disturbing the other kids. I really do not have any experience with virtual machines except with the web hosting company who hosts websites for me. I have heard about sluggishness on laptops and desktops running VMWare. Does Xen experience the same issues?
Where is the cost savings that is being promoted when switching to virtualization? Yes, you can possibly reduce the hardware footprint of 10 HP DL380 servers down to 1 virtual host manager with 10 virtual machines. What is the minimum hardware requirement in order to virtualize 10 Linux servers on one host? How many CPUs and amount of memory will you need to maintain acceptable operating environments? Poor performance and latency is not ideal or an acceptable situation.
Would virtualization be an ideal situation for setting up a "development farm" for 10 developers all running Eclipse with a few virtual nodes running Oracle or MySQL? Can you create a database cluster across virtual nodes?
Just some thoughts, ideas, and questions to ponder...
Wednesday, September 16, 2009
Layers Pattern
The Layers pattern helps structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
Maybe I look at it differently, but layers is another way of saying hierarchical modules with loose coupling. I may not have tasted the 7-layer dip of the network, but I have dabbled in n-tier client/server systems. One development had decided to bubble up trapped error messages with a full stack in order to provide the most suitable amount of information to the users and developer.
Developing in layers provides an advantage for allowing incremental coding and testing to occur without disturbing other protocols. When thinking about layering, you should consider the following forces (as you battle Darth Vader):
Maybe I look at it differently, but layers is another way of saying hierarchical modules with loose coupling. I may not have tasted the 7-layer dip of the network, but I have dabbled in n-tier client/server systems. One development had decided to bubble up trapped error messages with a full stack in order to provide the most suitable amount of information to the users and developer.
Developing in layers provides an advantage for allowing incremental coding and testing to occur without disturbing other protocols. When thinking about layering, you should consider the following forces (as you battle Darth Vader):
- Late source code changes should not ripple through the system.
- Interfaces should be stable.
- Parts of the system should be exchangeable.
- Possibility of building other systems at a later date with the same low-level issues as the system currently being designed.
- Similar responsibilities should be grouped to help understandability and maintainability.
- The system will be built by a team of programmers, and work has to be subdivided along clear boundaries.
Tuesday, September 15, 2009
Pipes and Filters
"Pipes and filters" was an interesting read, but I think the example of using a compiler was not best suited for someone exposed the pattern.
There two types of filters: passive and active. Passive filters can either have data pushed to them or have data pulled from them. Most commonly, active filters are in a loop pulling its data from and pushing it down the pipeline. An active filter will begin processing on its own as a separate program or thread.
Pipes are synchronized and operate on a first-in-first-out buffer paradigm. Trying to confuse the reader, this example of a pipe resembles a common queue to push and pop items off the stack. Is this an incorrect assumption or understanding?
Not sure what the author means when "you have to change your code whenever you want to recombine or reuse filter components." I thought the idea of having multiple filters was to support multiple formats.
The Pipes and Filters pattern presented is recognizable, and it is likely you have been using the pattern all along. Dr. Johnson identified other sources to gaining a better understanding of the pattern. Bill Walker's Master's thesis is a wonderful example of applying the Pipes and Filters pattern. The fact it was about music was an interesting topic and one that I can associate with fairly easily. I am considering the idea of bringing Dagos Manolescu's "A DataFlow Pattern language" to fruition for a writing assignment or class project.
There two types of filters: passive and active. Passive filters can either have data pushed to them or have data pulled from them. Most commonly, active filters are in a loop pulling its data from and pushing it down the pipeline. An active filter will begin processing on its own as a separate program or thread.
Pipes are synchronized and operate on a first-in-first-out buffer paradigm. Trying to confuse the reader, this example of a pipe resembles a common queue to push and pop items off the stack. Is this an incorrect assumption or understanding?
Not sure what the author means when "you have to change your code whenever you want to recombine or reuse filter components." I thought the idea of having multiple filters was to support multiple formats.
The Pipes and Filters pattern presented is recognizable, and it is likely you have been using the pattern all along. Dr. Johnson identified other sources to gaining a better understanding of the pattern. Bill Walker's Master's thesis is a wonderful example of applying the Pipes and Filters pattern. The fact it was about music was an interesting topic and one that I can associate with fairly easily. I am considering the idea of bringing Dagos Manolescu's "A DataFlow Pattern language" to fruition for a writing assignment or class project.
Monday, September 14, 2009
Data Grows Up (Beautiful Architecture - Chapter 6)
Being an avid user of Facebook, I had a keen interest in how a system is able to support a subscription of over 230 million users. Facebook has become a great ally in communicating with former classmates from high school and college in addition to friends and family members while living overseas.
Facebook was created around the vast amount of social data available. Everything on the site is driven by the data each user has entered. The business logic closely depends on this social data, such as the flow and access patterns of various pages, implementation of search, surfacing of News Feed content, and application of visibility rules to content.
Facebook initially started out a standard n-tier web site, but there was so much more potential. To allow third-party developers to participate, the platform was then developed into an array of web services (Facebook API), a query language, and a data-driven markup language.
Previously, web sites were primarily static or database-driven with data generated by companies. Web 2.0 has turned the tide where websites are still being data-driven but the benefits are being realized as the source of that data is from the users themselves. The larger the network of users, the more information readily available to everyone involved.
Third-party or external applications have access to user data through authentication granted by the user. Once the application has been granted authority, the application utilizes the Facebook API and Facebook Query Language (FQL) in the Web Services. User privacy preferences does limit the amount information available to external applications. The data is only as safe as the preferences determined by the user. Some privacy information is divulged by users willing to give away credit card information and social security numbers to complete strangers. Sorry, software cannot prevent stupidity.
At times, I do think the reading was a tad lower level than required and causing the reading to extend to 40 pages. It is not that information was not interesting, but it might have been a little overkill. Considering the amount of personal time spent on Facebook, it was a nice exposure to how technology has transformed the way data is gathered, distributed, and reused across multiple applications.
Facebook was created around the vast amount of social data available. Everything on the site is driven by the data each user has entered. The business logic closely depends on this social data, such as the flow and access patterns of various pages, implementation of search, surfacing of News Feed content, and application of visibility rules to content.
Facebook initially started out a standard n-tier web site, but there was so much more potential. To allow third-party developers to participate, the platform was then developed into an array of web services (Facebook API), a query language, and a data-driven markup language.
Previously, web sites were primarily static or database-driven with data generated by companies. Web 2.0 has turned the tide where websites are still being data-driven but the benefits are being realized as the source of that data is from the users themselves. The larger the network of users, the more information readily available to everyone involved.
Third-party or external applications have access to user data through authentication granted by the user. Once the application has been granted authority, the application utilizes the Facebook API and Facebook Query Language (FQL) in the Web Services. User privacy preferences does limit the amount information available to external applications. The data is only as safe as the preferences determined by the user. Some privacy information is divulged by users willing to give away credit card information and social security numbers to complete strangers. Sorry, software cannot prevent stupidity.
At times, I do think the reading was a tad lower level than required and causing the reading to extend to 40 pages. It is not that information was not interesting, but it might have been a little overkill. Considering the amount of personal time spent on Facebook, it was a nice exposure to how technology has transformed the way data is gathered, distributed, and reused across multiple applications.
Thursday, September 10, 2009
Resource-oriented architectures (Beautiful Architecture - Chapter 5)
Perhaps it is due to not having an overly abundant amount of experience with modern web query concepts, but some of the information either bored me to tears or caused me to doze off. Well, some of that could be from lack of sleep this week...The paper seems like a nice scapegoat.
Even though it wasn't stressed succinctly, part of the information presented has been passed down over generations to computer scientists -- don't break the interface. When interfaces change, you need to be able to support previous versions of the interface in order to keep communication flowing and not break other external systems. Changes to logic "behind-the-scenes" should be transparent to users once the interface is established.
I do respect the idea of being able to have different formats of the data returned for a request. Technology is evolving and the respective layout of data will vary on whether or not you are using a computer, PDA, iPhone, or Commodore 64 emulator. The user appreciates the multiple options and not being tied to a specific presentation device.
REST utilizes four verbs: GET, POST, PUT, and DELETE. The messages types present a simple interface for developers. Simple is good. As one of my classmates recognized, I also appreciate the similarities to using SQL for select, insert, update, and delete.
Even though it wasn't stressed succinctly, part of the information presented has been passed down over generations to computer scientists -- don't break the interface. When interfaces change, you need to be able to support previous versions of the interface in order to keep communication flowing and not break other external systems. Changes to logic "behind-the-scenes" should be transparent to users once the interface is established.
I do respect the idea of being able to have different formats of the data returned for a request. Technology is evolving and the respective layout of data will vary on whether or not you are using a computer, PDA, iPhone, or Commodore 64 emulator. The user appreciates the multiple options and not being tied to a specific presentation device.
REST utilizes four verbs: GET, POST, PUT, and DELETE. The messages types present a simple interface for developers. Simple is good. As one of my classmates recognized, I also appreciate the similarities to using SQL for select, insert, update, and delete.
Tuesday, September 8, 2009
ArchJava
ArchJava is described as a small, backwards-compatible extension to Java that integrates software architecture specifications smoothly into Java implementation code. For demonstration purposes the authors applied ArchJava to Aphyds, a moderate-size circuit design application with ~12,000 lines of code.
There appears a common theme among the existing tools and languages -- failure to ensure or enforce communication integrity. This include architecture design languages (ADLs), module interconnection languages (MILs), CASE tools, and component infrastructures such as COM, CORBA, and Java Beans all fail to be satisfactory according to the authors.
If a development team is not applying the concepts and guidelines of agile development, I could see where ArchJava might provide a benefit. The time spent time on adapting and integrating with ArchJava could have been spent on the design decisions. Development teams could do a little upfront design to hash out some of the architecture and the rest would be resolved through the use of pair programming. Could peer code reviews provide the inherent benefit of "ensuring communication integrity" instead of additional complexities presented in ArchJava?
I have to question whether or not ArchJava has been put on the back burner as the little no verifiable activity or maintenance releases since version 1.3.2 in June 2005. It is hard to win over an audience when there is little progress being made.
As a newbie to ArchJava or anything similar, I would be hesitant to use Java extensions for this purpose. This is just my opinion without and actually reaping the benefit myself. There have been many successful development projects that did not use ArchJava. However, it is unknown if those same successful projects ensured communication integrity throughout the source code.
There appears a common theme among the existing tools and languages -- failure to ensure or enforce communication integrity. This include architecture design languages (ADLs), module interconnection languages (MILs), CASE tools, and component infrastructures such as COM, CORBA, and Java Beans all fail to be satisfactory according to the authors.
If a development team is not applying the concepts and guidelines of agile development, I could see where ArchJava might provide a benefit. The time spent time on adapting and integrating with ArchJava could have been spent on the design decisions. Development teams could do a little upfront design to hash out some of the architecture and the rest would be resolved through the use of pair programming. Could peer code reviews provide the inherent benefit of "ensuring communication integrity" instead of additional complexities presented in ArchJava?
I have to question whether or not ArchJava has been put on the back burner as the little no verifiable activity or maintenance releases since version 1.3.2 in June 2005. It is hard to win over an audience when there is little progress being made.
As a newbie to ArchJava or anything similar, I would be hesitant to use Java extensions for this purpose. This is just my opinion without and actually reaping the benefit myself. There have been many successful development projects that did not use ArchJava. However, it is unknown if those same successful projects ensured communication integrity throughout the source code.
Christopher Alexander Excerpts
The excerpts from published works of Christopher Alexander include "The Timeless Way of Building" (1979) and "A Pattern Language" (1977). Provided a very small subset of the books, it is an interesting to see construction from an architect's perspective. Many of the thoughts or concepts presented can easily be adapted for computer science and software engineering.
The entire text of "The Timeless Way of Building" contains a mere 552 pages. Alexander presents an abstract view of building a system and how each team member applies a unique spin on development. Here he describes how the language can live, like a genetic code - picked up and modified by people over time so that multiple languages can evolve. He also describes how to put the pattern into action. Agile development or extreme programming was not even an inkling in anyone's mind back in the late 1970's. Yet, Alexander was able to describe some of primary characteristics and benefits of applying the concepts in a software development environment.
The author does not bluntly come out and say it, but systems are not cookie cutters like you see in some neighborhood developments where every house looks exactly the same. Yes, they may all have four walls, a roof, and a garage. However, the inside content or decoration of the house is unique to each owner (i.e. developer). You can plant a seed and water it as much as you want, but there is no guarantee the tree will turn out perfectly or be healthy. Even the best arborist cannot provide that guarantee. Same goes for your system architect.
Part of the series, "A Pattern Language" applies some of the concepts discussed previously. Weighing in a whopping 1171 pages, there are a total of 253 patterns available for your reading enjoyment. A similarity between architecture patterns and software patterns is they both are representative of common approaches or solutions that have been demonstrated in the field.
One pattern that sticks in my mind is about "Site Repair". It is common for housing developers to select the best looking part of the land on which to build the structure. Rather than taking the worst section of the land and improving upon it, the construction eliminates the healthiest soil and leaves you with the worst for your so-called great view across the prairie.
The same concept can be applied to software development when doing code reviews or refactoring. There are areas of the code that require attention due to "code smells". It is not prudent to leave the trash sitting out where you may get a bug infestation that will end up being more expensive to eliminate the longer you wait. Concentrate your efforts on the sections that will give the most bang for the bug and will likely cause more issues in the long run. Bring all the code up to par with the rest of the system development...Don't be the weakest link.
The entire text of "The Timeless Way of Building" contains a mere 552 pages. Alexander presents an abstract view of building a system and how each team member applies a unique spin on development. Here he describes how the language can live, like a genetic code - picked up and modified by people over time so that multiple languages can evolve. He also describes how to put the pattern into action. Agile development or extreme programming was not even an inkling in anyone's mind back in the late 1970's. Yet, Alexander was able to describe some of primary characteristics and benefits of applying the concepts in a software development environment.
The author does not bluntly come out and say it, but systems are not cookie cutters like you see in some neighborhood developments where every house looks exactly the same. Yes, they may all have four walls, a roof, and a garage. However, the inside content or decoration of the house is unique to each owner (i.e. developer). You can plant a seed and water it as much as you want, but there is no guarantee the tree will turn out perfectly or be healthy. Even the best arborist cannot provide that guarantee. Same goes for your system architect.
Part of the series, "A Pattern Language" applies some of the concepts discussed previously. Weighing in a whopping 1171 pages, there are a total of 253 patterns available for your reading enjoyment. A similarity between architecture patterns and software patterns is they both are representative of common approaches or solutions that have been demonstrated in the field.
One pattern that sticks in my mind is about "Site Repair". It is common for housing developers to select the best looking part of the land on which to build the structure. Rather than taking the worst section of the land and improving upon it, the construction eliminates the healthiest soil and leaves you with the worst for your so-called great view across the prairie.
The same concept can be applied to software development when doing code reviews or refactoring. There are areas of the code that require attention due to "code smells". It is not prudent to leave the trash sitting out where you may get a bug infestation that will end up being more expensive to eliminate the longer you wait. Concentrate your efforts on the sections that will give the most bang for the bug and will likely cause more issues in the long run. Bring all the code up to par with the rest of the system development...Don't be the weakest link.
Architectural Blueprints - The "4+1" View
It is unfortunate this paper was written by a single person. He could have really used an editor to proofread his paper and look for missing or misspelled words. There were multiple I had to break the flow of reading in order go back and figure out what point he was attempting to express.
The author presents the theory of not being able to clearly and efficiently present all necessary information about a system in a single diagram. Duh! Unless the "system" has two classes and less than 500 SLOC, you might be referring to a script in this case.
In order to describe a software architecture, a model composed of views or perspectives is presented:
Perhaps it is the case of SEI-CMM and DODAF being spoon fed to me over the last 10+ years, but I see nothing overly exciting about the author's presentation of creating views to describe the architecture. Any right-minded development program should have at least some documentation laying out decisions that have been regarding the system development and design. Even agile development produces some amount of design documentation.
Since this paper was written by an associate of Rational, I am not sure if the intended audience included your 2-man development teams running out a garage. A little upfront design should be done by all.
The author presents the theory of not being able to clearly and efficiently present all necessary information about a system in a single diagram. Duh! Unless the "system" has two classes and less than 500 SLOC, you might be referring to a script in this case.
In order to describe a software architecture, a model composed of views or perspectives is presented:
- logical view, object model of the design
- process view, captures the concurrency and synchronization aspects of the design
- physical view, describes mapping(s) of software onto hardware and distributed aspect
- development view, describes organization of the software in the development environment
- scenarios (use cases)
Perhaps it is the case of SEI-CMM and DODAF being spoon fed to me over the last 10+ years, but I see nothing overly exciting about the author's presentation of creating views to describe the architecture. Any right-minded development program should have at least some documentation laying out decisions that have been regarding the system development and design. Even agile development produces some amount of design documentation.
Since this paper was written by an associate of Rational, I am not sure if the intended audience included your 2-man development teams running out a garage. A little upfront design should be done by all.
Making Memories (Beautiful Architecture - Chapter 4)
Making Memories was a fairly simple read (for the most part) describing the process used by a professional portrait studio from initial photo shoot to the product being delivered to the customer. Due to the disparate locations of these studios, many locations do not have adequate space or staff to handle the process of developing and/or printing the various sizes of photos. The idea is to let the photographers (associates) do what they do best -- create beautiful images.
The author mentions a couple of different of patterns from the Gang of Four's book, Design Patterns: Elements of Reusable Object-Oriented Software.
Chain of Responsibility
Facade
Visitor
Since I do not get daily exposure to the patterns, I had to go back and review in order to refresh this degrading brain of mine. An unknown pattern to me, leader-follower, was also utilized in the design. Other patterns can also be inferred based on some the concepts applied and approaches taken by the development team.
The contributor mentions the StudioServer walks through the orders collecting GUIDs using the controversial Visitor pattern. What makes this specific pattern controversial?
I may be publicly announcing some of my shortcomings, but I have not had any exposure to Hibernate and Spring. Maybe it is due to the size and age of some of the software projects in which I am involved that prevents me from applying these concepts in my daily job. What are some of the benefits of using these frameworks?
It is interesting how the development managed to develop methods for providing database updates remotely without requiring the associate to perform the upgrade. The last thing you want to do is have a non-techie hopping around in your database with the root account.
At the photo studios, the team threw around the idea of a peer-to-peer network but ultimately decided on a multi-threaded client-server model with a RAID set and additional storage device for the customers' images (ie. image repository). This helped in making the workstations interchangeable.
There were numerous concepts for design, development, testing, delivery, and maintenance discussed in this 25-page chapter. I recommend the read for anyone interested in relating to different issues the development team ran into and how they worked around the obstacles while devising some intelligent design choices.
The author mentions a couple of different of patterns from the Gang of Four's book, Design Patterns: Elements of Reusable Object-Oriented Software.
Chain of Responsibility
Facade
Visitor
Since I do not get daily exposure to the patterns, I had to go back and review in order to refresh this degrading brain of mine. An unknown pattern to me, leader-follower, was also utilized in the design. Other patterns can also be inferred based on some the concepts applied and approaches taken by the development team.
The contributor mentions the StudioServer walks through the orders collecting GUIDs using the controversial Visitor pattern. What makes this specific pattern controversial?
I may be publicly announcing some of my shortcomings, but I have not had any exposure to Hibernate and Spring. Maybe it is due to the size and age of some of the software projects in which I am involved that prevents me from applying these concepts in my daily job. What are some of the benefits of using these frameworks?
It is interesting how the development managed to develop methods for providing database updates remotely without requiring the associate to perform the upgrade. The last thing you want to do is have a non-techie hopping around in your database with the root account.
At the photo studios, the team threw around the idea of a peer-to-peer network but ultimately decided on a multi-threaded client-server model with a RAID set and additional storage device for the customers' images (ie. image repository). This helped in making the workstations interchangeable.
There were numerous concepts for design, development, testing, delivery, and maintenance discussed in this 25-page chapter. I recommend the read for anyone interested in relating to different issues the development team ran into and how they worked around the obstacles while devising some intelligent design choices.
Thursday, September 3, 2009
Architecting for Scale (Beautiful Architecture - Chapter 3)
Are you telling me there are other experiences out there in the world besides Pong and the Atari gaming system? *sigh* The last MMO adventure I participated in was around Feb. 2006 playing Diablo II in a multi-player battle with other co-workers. It is unknown whether or not some of our so called latency problems were bandwidth related or infrastructure problems with Blizzard Entertainment.
Created by Sun Microsystems, Project Darkstar is designed to help developers and operators avoid a range of serious problems associated with online games today such as zone overloading, data corruption, and server under-utilization. No reason to make everyone re-invent the wheel...Take advantage of the programming already completed by someone else.
Project Darkstar presented a fairly novel scaling approach. Any action from a game server can be processed anywhere on the server-side network. Actions working on the same data can be grouped and executed together on the same machine. Grouped actions can also be distributed across multiple servers, and, on each server, individual actions are further distributed across all available threads for parallel execution. Dynamic scaling is easily accommodated where workloads can be balanced across any number of servers, and scaling up or down becomes a simple matter of adding or removing servers.
Since minimizing latency was not the only goal, Project Darkstar maintains game state in a globally shared and persistent Data Store. The Data Store is updated with the results of each action, therefore minimizing data loss in the event of a server failure. All data access requests are wrapped in a transaction to insure that game state remains consistent in the face of conflicting player actions or system failures. The ability to cheat is limited, or at least more difficult, because all shared data are maintained on the server, rather than on players' machines.
With the advancements in architecture and technology, I am somewhat excited to get back into gaming. Unfortunately, that will not be happening until after graduation. Who knows what next gaming adventure will be on the horizon in 2011?
Created by Sun Microsystems, Project Darkstar is designed to help developers and operators avoid a range of serious problems associated with online games today such as zone overloading, data corruption, and server under-utilization. No reason to make everyone re-invent the wheel...Take advantage of the programming already completed by someone else.
Project Darkstar presented a fairly novel scaling approach. Any action from a game server can be processed anywhere on the server-side network. Actions working on the same data can be grouped and executed together on the same machine. Grouped actions can also be distributed across multiple servers, and, on each server, individual actions are further distributed across all available threads for parallel execution. Dynamic scaling is easily accommodated where workloads can be balanced across any number of servers, and scaling up or down becomes a simple matter of adding or removing servers.
Since minimizing latency was not the only goal, Project Darkstar maintains game state in a globally shared and persistent Data Store. The Data Store is updated with the results of each action, therefore minimizing data loss in the event of a server failure. All data access requests are wrapped in a transaction to insure that game state remains consistent in the face of conflicting player actions or system failures. The ability to cheat is limited, or at least more difficult, because all shared data are maintained on the server, rather than on players' machines.
With the advancements in architecture and technology, I am somewhat excited to get back into gaming. Unfortunately, that will not be happening until after graduation. Who knows what next gaming adventure will be on the horizon in 2011?
Tuesday, September 1, 2009
A Tale of Two Systems (Beautiful Architecture - Chapter 2)
What a difference one chapter makes! The second chapter sparked my attention as the topic kind of hit home and reminded me of some development pains I have had with previous employers. Ugh, the horror!!!
Working on a poorly-designed system is like driving a 1978 Chevy Nova that is being kept together by kite string and duct tape. Sure, you can add a new radio or buy new tires, but the car is still being held together by duct tape and is not roadworthy. You could even add an alarm system if that would make you feel better. Eventually, the vehicle is going to succumb to reality and fall apart while driving 65 mph on the interstate. You (and management) really need to take a step back and evaluate if the "car" should be stripped down to the chassis and rebuilt due to a previous poor design. The financial, morale, and personal benefits will be realized immediately.
In this day and age, you are rarely ever going to be the sole architect, developer, tester, and maintenance person. You will always be part of team. The team could be comprised of 4 people or 70 people. The quality of the product is a direct result of how well the team works together. Believe it or not, the buzzword "synergy" plays a strong role in determining the success or failure of the project. A rogue developer, or a group of developers, claiming mutiny could bring a development program to its knees and potentially destroy future business.
It appears this author is a proponent of the extreme programming methodology. There are definite advantages to this approach when there is no definitive path for development. XP forces the architect or developers to work closely with the stakeholder which allows the stakeholder to stay-in-the-loop on progress and help drive the next phase of development. From a developer point of view, pair programming can be very beneficial in spreading the knowledge of the code and functionality to various teams as they each work together on various parts of the project.
If you have not done it before, you would be amazed at how the simple steps of refactoring and unit testing will greatly improve the quality (and inherently the design) of the code. It is quite scary to see what some so-called developers determine as valid or clean code. Maybe it is acceptable if you are going to be the only person updating the code for the next 50 years. Now that would be job security. Maybe I should write Fortran and get a cushy job.
Working on a poorly-designed system is like driving a 1978 Chevy Nova that is being kept together by kite string and duct tape. Sure, you can add a new radio or buy new tires, but the car is still being held together by duct tape and is not roadworthy. You could even add an alarm system if that would make you feel better. Eventually, the vehicle is going to succumb to reality and fall apart while driving 65 mph on the interstate. You (and management) really need to take a step back and evaluate if the "car" should be stripped down to the chassis and rebuilt due to a previous poor design. The financial, morale, and personal benefits will be realized immediately.
In this day and age, you are rarely ever going to be the sole architect, developer, tester, and maintenance person. You will always be part of team. The team could be comprised of 4 people or 70 people. The quality of the product is a direct result of how well the team works together. Believe it or not, the buzzword "synergy" plays a strong role in determining the success or failure of the project. A rogue developer, or a group of developers, claiming mutiny could bring a development program to its knees and potentially destroy future business.
It appears this author is a proponent of the extreme programming methodology. There are definite advantages to this approach when there is no definitive path for development. XP forces the architect or developers to work closely with the stakeholder which allows the stakeholder to stay-in-the-loop on progress and help drive the next phase of development. From a developer point of view, pair programming can be very beneficial in spreading the knowledge of the code and functionality to various teams as they each work together on various parts of the project.
If you have not done it before, you would be amazed at how the simple steps of refactoring and unit testing will greatly improve the quality (and inherently the design) of the code. It is quite scary to see what some so-called developers determine as valid or clean code. Maybe it is acceptable if you are going to be the only person updating the code for the next 50 years. Now that would be job security. Maybe I should write Fortran and get a cushy job.
Sunday, August 30, 2009
What is Architecture? (Beautiful Architecture - Chapter 1)
I begin to wonder how much work the authors, Spinellis & Gousios, actually had to do since the book is a compilation of papers written by other authors. I have no personal experience in this philosophy of having subject matter experts do the work and allow me to take the credit for their work.
The approach in which the contributors took in personalizing the architect as female was surprising (even if the contributors were both male). Personally, I urge more women to take the helm in leading projects and starting companies. It had been so common or stereotypical to use 'he' or 'he/she' when referencing a person or role, this could be a new approach that we will see more often.
It is much appreciated how the authors of this chapter stated there is no single correct architecture and no single "right answer." Evaluation of architectures or initial trial and error will allow architects, designers, and developers to determine if a certain approach will satisfy the needs of the customer. If you try and fail, at least you tried. Get up and try again.
The text of this first chapter was pretty dry and not the easiest to follow. Maybe I have been spoiled by other technical books such as "Peopleware" and "Extreme Software Engineering". It really is possible to make a topic enjoyable with a little sarcasm and humor. Unfortunately, I had to keep myself motivated to get through this first chapter.
The approach in which the contributors took in personalizing the architect as female was surprising (even if the contributors were both male). Personally, I urge more women to take the helm in leading projects and starting companies. It had been so common or stereotypical to use 'he' or 'he/she' when referencing a person or role, this could be a new approach that we will see more often.
It is much appreciated how the authors of this chapter stated there is no single correct architecture and no single "right answer." Evaluation of architectures or initial trial and error will allow architects, designers, and developers to determine if a certain approach will satisfy the needs of the customer. If you try and fail, at least you tried. Get up and try again.
The text of this first chapter was pretty dry and not the easiest to follow. Maybe I have been spoiled by other technical books such as "Peopleware" and "Extreme Software Engineering". It really is possible to make a topic enjoyable with a little sarcasm and humor. Unfortunately, I had to keep myself motivated to get through this first chapter.
Tuesday, August 25, 2009
Subscribe to:
Posts (Atom)