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.
Wednesday, September 30, 2009
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.
Subscribe to:
Posts (Atom)