Beautiful Architecture Ch11.

I did not really heavily used Emacs before I read this Chapter, but I would like to explore more after today.  The time that I uses Emacs limited to the condition that I worked on a Unix system or telnet to a linux system. But the only reason I used Emacs is for opening the file with several lines of code changes then closing it.  In this Chapter, the author shows me a more advanced use of Emacs, which reminds me about another powerful similar structrue, browsers in Squick. I love the universal browser in Squick, a very easy to use browser, and Emacs seems to have a lot of functions integrated into too.

Architecture wise, Emacs adopts the typical MVC pattern.  And it seems like the buffer management of Emacs is really strong that even "crash", user still can retrieve data from the buffer.  Emacs can be extended, but maybe because of this, it is turning into a "big ball of mud".  I'm not sure if another text editor with sililar architecture will be produced to replace Emacs, but it seems a haul is needed for it in near future.

OPL

The author introduces a design pattern for parallel-software engineering called "Our Pattern Language". I really do not appreciate the name of that pattern, since it is not intuitive enough to tell me what that Pattern Language is about and it can be used to any other pattern languages. Although it is said that OPL is not specific to any particular application domain, the author can add some more distinguishing words to it, such as Our Pattern Language for design of parallel software.

Then in the main body of this article, the author divided the tasks into several different buckets and threw some patterns in each bucket.  Well, I have to admit that this is far away than what I have expected when seeing the title and follow all the way down to the end. What I expect is a real language with the elements that are defined for describing a certain scenario of problems in parallel-software engineering instead of a set of patterns that can be used in parallel programming.

Maybe I should stop complaining about the ambiguity of the name.  I don't have experience on parallel programming so I guess I can not tell if those patterns that are listed in OPL really helps developers or not.  But one thing I think this project did is creating a manual for developers on design patterns.  Sometimes I do want some summary of available, so called best practice, for a certain job structured by layers and as a whole too.  So with that point of view, developers may benefit from this article.

Beautiful Architecture Ch 10.

I think it is the third or fourth paper for VMs, this one is mainly focused on implementations. I like the details in runtime environment and it answers some of my questions in such as class loader and I found Optimizing compilation interesting too.

There are no architectural specialty in this article, is a good reading for knowing more in compiling/runtime properties of this JVM.

The Adaptive Object-Model Architectural Style

Before AOM, people generate a lot of classes for different type of entity. Developers need to change the code whenever a business change happens. In AOM, entities are modeled by metadata, rules and constraints which can be changed quickly and affect the least of the system.  I think AOM is a flexible architecture that it can be combined with many other design patterns such as Builder and Interpreter, but it currently has no generic framework for building the model.   The author described three different systems that uses AOM, I can see they all share TypeObject and Property patterns, but the Strategy differs a lot. 

The project in this article as an example of AOM is building a Refugee application, the model takes time to build, but once built, other components are easy to add on. That is the power for the AOM.

Beautiful Architecture Ch 9.

I really like emulations over VMs when there are a rush task and I don't have to install a environment that I know I would not use often afterwards.  One of the most used for me is Cygwin, which contains a emulation of Linux on Windows.  It is easy to install, only contains essential components that is quick to boot up. I think the biggest convenience Cygwin brings to me is that I don't have to reboot my machine (I have another full version of Linux installed in my computer) to do a little bit of work in Linux while majority of the time I can get my jobs done using windows more quickly (I'm more familiar with windows environment).  But I have to admit that sometimes the speed penalty of emulation does kill me. My bottom line is, if I have dedicated time to work on, I will use the real system/VM, if I need to do some higher priority works in Windows, I'll just let the emulator run at the background.  Even though the emulator might just crash because of the bugs in my code, it will not affect me using Windows normally.

Normally I use exception to report errors, but there are some circumstances that I use exception to deal with absence of form field when assigning values in .NET.

Talking about the flexibility of emulators, there are another important factor that I can run multiple instances of emulators at the same time without worrying about interfering other instances. (Of course, I need to avoid working at same file directory among those instances.)

Big Ball Of Mud

I think I saw a lot of systems which are like a big ball of mud during my work as a software engineer. And I believe I created some too. Other than those were created at my early career as a freshman in software development with little knowledge of what a good system should look like, majority of them are created by a rush work.  Time was limited and we were kind of in a exhausted mode. Later on, there came the improvements and bug fixing. Not until we could not figure out some code error in a big chunck of function body that we realized we've defeated by this big junk of mud.  

I don't think a big ball of mud can be avoided without a careful design, which is basically impossible at the first version of the system, if not several. Especially when the system you are working on have not been implemented before.  I believe that user requirements are needed to be triggered, and the prototype system is needed at early stage of the system development. Since it is almost impossible for us to foresee what the future requirements would be, there are a big chance that after some time, the functions that are added on in a casual way will turn into balls of mud, until someday you get a huge one that forces you to rethink the structure.  At early days, people do not realize the importance of reflectoring and prefer to rebuild the system from zero when they find the old system is not working right any more.  I agree with the author that forming a nice architecture of the system takes time and I think customers are more happy when they see some real system running than seeing a carefully designed system diagram. Thus, "focus first on features and functionality, then focus on architecture and performance.

I think not all the throwaway codes are really throwaway since the code is still good in functional. It's because of the poorly organization of the code that cause the problem. Sweeping under the rug is an interesting idea and I believe that is good for relectoring too since you can put the ugly code under a facade but still keep the trivial functionality available using interfaces while you are focusing the reflectoring of main bone of the code.

I think the only reconstruction that I've ever experienced was because the functionality had changed a lot or some of the main functionality would not able to be created under the old roof.  The other possible reason for reconstruction was the underlying platform change. Not surprisingly that a lot of organizations, majorly not for profit organizations tend to change platforms when personnels get changed in IT department. A director that has more .NET background will reconstruct the software that was written in Java. I've been through a project the person in charge is from java background and tried to change all the core applications into java from coldfusion.

Beautiful Architecture Ch8.

Greg Lehey in this chapter described an architecture, Guardian, which is designed to provide efficient fault tolerence with the hardware support of Tandem

Tandam used the fault tolerent structure which is widely used now, the hot standby structure, for hardware components such as CPU, to back up the possible failure of one another.  The system used a special bit in one of the register to distinguish and protect the procedure calls. Then by checking the offset of the instruction based on procedure type, load instructions or generate protection trap.  There are two buses that are parallelly used and both functional and as back ups for each other.  IO controllers can be used by only one CPU at a given time to reduce confliction.  Each CPU owns a set of processes with PID. 

To manage such a system which works basically like several system colaboration, a advanced message system is requried.  The process pare is quite interesting to me since I know the checkpointing from DBMS.  I don't know which sytem adopt this idea first but we can see some similar architecture between the two here. There is a difference that in some of the DBMS, the checkpoints are set automatically when some system threshold is met whereas Tandam needs the programmer to set up the checkpoint and I can already see there might be chances of malfunction of that mechanism. 

As a fault tolerant system, the exploit of memory seems quite intolerant to me, opening the parameter check to the programmer is the main reason of this weakness.  File access control is too strict that users can only belong to a single group, but it still could not solve the device access control.

As it was said in the chapter that many mechanisms of that Tandem that you can find in today's system succeeded in later on machines.  I am as surprised as the author who found Tandem had made such a small impression in the industory.  Well, I guess that is not a new story in the history of computer systems that many techniques are not noticed when it's first launched.  But I do not agree with the saying that Tandem made a small impression on the design of modern machines, it might not be applied to individual machine, but the whole architecture and idea of fault tolerance can be seen in many places in today's systems.

Beautiful Architecture Ch7.

Before Xen, the biggest challenge of virtualization is the priviliged instructions that will cause malfunctioning of the operating system.  Xen extends the paravirtulization that change the code in operating system to make it compatible in the virtual machine environment.  By using mechanisms such as hypercall and virtual memory, Xen is able to share the the memory and run several virtual machines on one physical machine. 

Domain zero is a special domain the hypervisor lauches when machine boots up to allocate memory, manage admission. 

By applying emulated BIOS and hardware devices, Xen is able to support the hardware virtual machine.  And it is because of the open feature of Xen, engineers from AMD and Intel can help on this.  IOMMU is a new feature which helps developers to manage the IO devices. It also stops unauthorized memory access.

Pipes and Filters

As the first architectural pattern, Pipes and Filters is widely used in many systems, I think it is everywhere. But the concept is really big and abstract, I almost don't recognize it when I just read through the chapter without going online and search around for some examples.  The most direct use that I came across recently is the IEnumerable approach and a lot of workflow applications.  I think the liability is surely exists when you basically need everything in the process of the data flow. 

I think passive filters are good when the previous data sources are in a more priority position than the rest of flow, since other part of the system can still process it's own procedure until the data source gets the data ready and send command to them. While as the active mode, the previous sources are fully occupied, only will serve the following sources when needed.

Beautiful Architecture Ch 6.

The auther gives a detailed introduction of how facebook works out.  Facebook provides third party applications to integrate many web services such as SSO, privacy protection and most important to those applications, a network of users that might interested in their web services because the group of friends might share some common interests when they see their friend using some "cool" applications.  I think that is quite smart and take good advantage of the social network.

I think one of the reasons that facebook opens itself to other applications is because if depending on Facebook itself, it is really hard to develop such a full amount of variaties of applications and it's really a burden to maintain those applications by its own.  An open service interface can let Facebook be a cool place with so many applications without worrying about maintenance, it is a very smart business move. Yet to mention that the company still hold the most important business source, the customer information, actually, a customer network.

 FQL, similar to Microsoft .Net LINQ, is a wrapper around internal SQL statement, with this wrapper, the platform maintains its encapsulation and can realize the optimization of query with the minimum impacts on applications.

Facebook gets control on those third party applications by wraping the contents from other sites using iframe, like a sandbox.  Also Facebook provides specific markup to render the third party pages in its trusted server environment to let user data have the capability to leave the Facebook domain. And that is FBML.  Through FBML, Facebook enables third party pages without hurting the privacy constraint. 

I don't think the FBJS as the fair compromise to javascript, since Facebook uses it's own data manipulating language, own page rendering language, but there is weak support for client-side sciprt.  But Facebook surely want to put those scripts into a sandbox too, to set boundary and keep consistant in the use of scripting in consider of security and privacy.  That is a policy of "you can use the script, but you need to follow my instruction".

I think what Facebook has done makes a good example of proper handling the need for social networking and the issues arised in privacy and security.  It provides a comparatively safe and scalable environment for online computing.  I think Facebook is a successful example for other web service providers, technically and commercially.

Excerpts from Christopher Alexander

I think a pattern language, like every other languages, is a way to communicate, to describe a thing with abstraction. It has the elements that the pattern is about, most repeatly using elements or we want to identify from we will give a name. It has a rule to follow, a logic sometimes implicit or explicit. It has a understanding prerequisite to stand above, like the sentence "The tree stands on a hill", when we use it, we are having certain knowlege of it that it won't come out like "The hill stands on a tree".  The pattern languages are important to avoid those kind of misunderstanding to happen.

We have seen a lot of patterns in buildings, especially when you travel along in a vast piece of land, you can feel the dramatical changes in the buildings over different places, but they are somewhat related though.  As a matter of fact, some of the patterns are so famous that people use it to other areas, like Baroque style is used in other forms of arts like music.

As the "timeless" pattern, I think everything is changing, only the most classical ones will have a longer life span, but it does not mean they are timeless.  They can become a classic in the history and maybe are forgotten by people.  But some day, somebody will apply that or change that to fits the time,the patterns are back to life with or without the same name.  So I think there is not necessary for pattern to be timeless, it's been a great appreciation that they can fit the most requirement now. 

Beautiful Architecture Ch 5.

In this Chapter, the auther discussed a very interesting idea to cache the data using an resource-oriented approach.  And this structure that can be accumulatively built and transparent to the user could be really powerful as far as I see, once used rightly.  There are enough examples of the techniques turning into a mess because of misuse.  And I think the REST service naming convention/method can be one of the many in this techniques that are mistakenly used.  So restrict to only 4 verbs might mitigate that risk of misuse or confusions if users can create their own verbs like GET,RETRIEVE,FETCH.... I just think that could be a disaster. 

As the auther said in this Chapter, putting data in the forefront is ideally the most intuitive way to send a command, but it might hurts the security. Well, I believe there are some methods to protect the data, but since sometimes,  those small queries that contain the most important message are likely to be the attacking target and since their structure are much simpler and they are much shorter than the blob data and they are repeatly appears in the query, such as SSN=... they are in higher risks being sniffed and hacked.




 

Beautiful Architecture Ch 4.

In this chapter, the author describes a system that contains many components from different areas, web interface, database, workflow, other automation stations.  It used many common now rather standard solutions such as the three layer structure for web applications, repositories for historical image storage, unit testing, database migration.  I think they are pretty common in a middle sized web application we see today. 

It is interesting that they adapt the incremental architecture which is normally the way things work out for me, but I never think it as such a thing that should be kept doing. There was a colleague in my team who always had the best idea, best approach even sometimes, but turned out nothing at the end.  The problem was that he was too worried about some tiny little part of the system was not ready, not perfect yet while majority of the system should already be in the production line. I think the total think-through is important, but things, most of the time, troubles or bugs were not appeared at the first place would eventually be seen in the process. So fail early, fail loudly is good at the end.

Beautiful Architecture Ch 3.

I think one of the reason that Darkstar does not seem to tied to games closely is because there is lack of benchmarks for large scaled games, no as far as I know of. And that is one of the reasons that before those games are actually go to the shelf, they will provide some public test chances. Gamers get the games to play and the companies get the running data about how the size of the players can be, win win situation.  So to prepare for this non-prepared or less prepared situation, they need to find out a more of "having everything prepared" system, a balanced system for all kinds of "in case of", work loads, parallelism, latency, backup plans.   

I, myself is not a fan of those online games, but I guess that is a hot spot because I keep seeing all kinds of online games ads flying all over the internet. Sometimes I wondered how can they survive from such intense competitions and still make profit? But I guess they do, since although a lot of the games are vanished quickly, there are still tons of them emerge everyday.

Beautiful Architecture Ch 2.

It's a very interesting chapter to read through, vivid example about the Messy Metropolis. I was cracking up when I read "The code had grown organically over a period of years", it reminded me about those spaghetti codes that I wrote when I first started coding. Not saying they are perfectly elegent and neat now, but definitely going that way. 

I'm strongly agree that tight coupling leads to code that is not able to throughly test.  I remembered once I liked to encapsulate the data access code within each function call that need data exchange, well, like every mistake has an excuse, my excuse was that I was running out of time.  But year after year, I just let that code sitting there and more and more messy code gets dumped in, until one day, a little error caused me three days to debug that I found out that piece of code needs a overhaul.  The result was very good, at least I could run small test cases module by module.

I experienced both sides of the system, and what I have learned is keeping a good pace in development and refector in timely manner is important. You don't want the development to be too rushy that cause bugs or taking too long. It is a pain to working on millions of things parallelly but get nothing done. No output after a certain time can be a warning. Refectoring is another important thing to do to make sure the code are clean and still makes sense.

I hope I could always be in the nice side of the system, but being in bad side makes me aware all those ugly things and learn how to deal with them.

Beautiful Architecture Ch1.

I wondered why I did not ever link the software architecture to the buildings, well, I definitely used the terms such as hierarchy and of course, architecture.  But the similarity between building construction and software development did not seem to be so close to me before reading Chapter 1.

So, like buildings that some are wonderful, some are special, some are just so so, you can tell the quality differences between architectures of softwares.  Other than the concerns on aspects of software in Table 1-1 in the book, I think as a developer, there is an intuitive feeling about the architecture of a system. Simple, easy to understand, easy to use, clever and thoughtful designs, structured but flexible... I think this book will let me find other beautiful spot of a system.

ArchJava

It is a very interesting paper from a software architecture point of view, applying a structure to ensure the implementation conforms to communication integrity.  It adds constructs such as components, connections and ports to enforce the communication integrity.  In this paper, a middle-sized program that runs on a single JVM is converted into ArchJava architecture.

Actually, I found the evaluation process and analysis process effective.  It answers the questions in my mind when I read the section 1-3.  But it also make many assumptions/hypothesis during the evaluation process, which will be a case by case basis according to different applications that might not be reusable in other applications. 

As it is said in the paper that ArchJava is suitable for middle-sized applications that run on single machines, I think it can have some use in application development.

"4+1" view

I still remember the very first project that I did when I just graduated from college, my boss wanted a proposal on a big project for a university. I don't know why she would ever willing to put that kind of work to the hands of a just-graduated, maybe we were short of people at that moment. It was not a happy experience, suddenly I found what I learned in college was just text books, not enough for me to tackle questions like what is the proper capacity servers we should order, or things like what are the interfaces between applications we need to consider for possible future extensions. It will take an experienced system architecture some time to sort all that kind of things out, not to mention to the poor non-experienced me. Anyway, I wish I saw this article 7 years ago at that time. Because the chart that I made in that proposal was harshly criticized by the project committee. Well, I had to admit that putting all sorts of information on one tiny little diagram was not a smart choice, because I had to explain where the server means hardwares, where it means middlewares, where it means applications, for example DBMS. I could find excuses for myself that we could not have detailed design until we start the project. But my system "pre-design" diagrams could not find excuses by themselves that they are really mashed up with mixed concepts and very confusing. Everyone has their own interpretation, it might have caused turmoil when we started the project. Lucky for us that we PMed that project too, so as long as our team was on one page, everything was working out. So I really appreciate the "4+1" view concepts in this article and I think that is very realistic too.