Chess

i think finding bugs that are not caught by stress testing can be very valuable. stress testing doesn't guarantee to hit every scheduling scenario. hitting one particular scenario that breaks in a production environment can be extremely frustrating because there is not a good way to really track the problem down other then looking through the code by hand and hoping to find something. (this excludes programs like CHESS). one chance in thousands or millions is rare but could cause havoc in a system.

OPL paterns

with Pipes and Filters papers. the more recent paper seems to go strait for the heart of the pattern. it gives you the major details and lets the reader fill in the blanks. the earlier paper goes into detail of different variations of the pipe and filter pattern. i don't think this is missing something so much as just a different way to document a pattern. the more recent paper's style encourages creativity. with the first paper you see different varieties and may stop there and use them as is. with the paper this week, the developer needs to fill somethings in to make the pattern useful for a problem.

Reentrancy

i disagree with the author's statement that reentrancy implies thread safety. thread safety requires avoiding race conditions. given the definition thread A and thread B cannot share inputs that are changeable. race conditions require thread A putting a lock on resource X and thread B putting a lock on resource Y and each thread needing the others resource. i recall two threads reading the same location at the same time can lead to unexpected results. these resources are immutable but could cause issues. this is not going to a common case by any means. i can't think of a reason you would need two read locks open simultaneously on separate pieces of "static" data but it does break the author's statement.

BA 14

this chapter details an object oriented language smalltalk. the language has some interesting concepts to it. i think the biggest reason smalltalk never took hold is it has little structure. the lack of structure is one of smalltalks benefits and downfalls. as a programer i feel more comfortable with more structure. that being said too much structure is also a bad thing. strongly typed languages seem to have the idea balance. smalltalk can do everything that C++ or Java can do. the difference is Java or C++ hands you the constructs for loops and conditionals they are there is smalltalk but are built from smaller pieces of the language. this gives smalltalk a lot of power and some advantages but also makes programers shy away from using the language.

relopper

i think relopper could still be useful but not as much as it once was. the paper's motivating example shows a good use for the program. if there is existing code that is structured as a loop then it could be much easier to convert the code to a parallel loop then to a threading type solution. that being said. if i were designing the program to be parallel from the beginning i would probably not choose a parallel loop as the main design choice. so the idea seems good for converting exiting code to parallel if there is not time or money for a complete rewrite.

BA 13

problems that lend themselves to procedural solutions tend to problems that have linear set of steps to solve the problem. an example would be following a recipe from a cookbook. the same steps are followed in the same order.

object oriented solutions start to shine when the order of execution of the individual operations is determined at run time.

refactoring sequatial Java code for parallelism

one major advantage of having libraries built for parallelism is easy of programing. programers don't need to completely familiar with parallel programing to use the libraries. they will need some knowledge parallel programing still to know when to use the library. it also helps programers not reinvent the wheel every time they want to do something in parallel.

the only major disadvantage i can see is behind this type of idea is. that program will probably not be as efficient then it could be if the parallelism was built for that program

BA 12

i agree completely analyzing a problem before any work is done on design or programing is a very good idea. the problem is often times requirements or underlying software changes mid implementation. one sign of a good architecture is being able to adapt when requirements change during development. I'm no expert on KDE by any means but perhaps if KDE's architecture was more modular it may not have required a huge rewrite when QT 3 became QT 4. that's then easier statement to make then to actually accomplish. it's an example of a change that could never really be accounted for.

Fork Join

is trading performance tuning for easier to write code worthwhile. like all questions of this nature the answer is not a simple yes or no. i think most of the time this is worthwhile but there are exceptions. high end scientific applications would probably need performance tuning more then easily written code. i think these types of programs are a small part of the programing community . if the programer isn't dealing with parallel concepts he or she should be more able to focus on real problem at hand which should lead to better code.

BA 11

i don't think Emacs could be created in a closed source enviorment. or rather it never would and be widely used. one of the biggest features of the architecture is it's extendability. it can difficult to extend a system if the internal workings are unknown. i could see a software company buliding something similar for interenal use if tasks that were needed could vary from day to day but i see that as more of an internal tool then a marketable product.

BA 10

at the time Jikes was written the choice to implement its own threading method was a wise choice but as time has past i think this seems to make less sense then it once did. part of the operating system's job is schedule threads. doing the operating system's job seems to doing double the work. i think OSs have come a long way and can handle more threads now then they use to which undercuts a big reason to implement a separate threading algorithm.

Our pattern language

i think parallel programing offers a lot of challenges. we as programmers think of how to solve problems linearly. it takes me some effort to think of a problem in parallel. i don't think it's a lack of design skill. i think improvements in programing languages could help make parallel programing easier but i think the hardest part of programing in parallel is breaking the problem down into small parts that can be worked by separate CPUs. dealing with concurrency issues and shared data isn't easy and could possibly become easier with a better programing language.

BA 9

i can see advantages to using a JAVA based emulator over a C++ based emulator. the emulator would be more portable and less hardware dependent. it also appears more inherently secure due the the 3 layers of security built into the system by the emulator. i wonder if this type of emulator might be very dangerous as well. there has been talk in the past of VM's being used malicious purposes. an example being if an 'Evil' VM was slipped between the OS and the user the hacker would have complete control over user computer without the user being able to easily detect the hacker's presence. the difficult part of this hack is getting the VM installed on the host machine. JAVA doesn't really have anything to install the user just needs to start the Evil emulator and the user may never notice the difference.

big ball of ud

the current system i'm working display some signs of a big ball of mud. there are parts that are well done but there are others that do not work well.

one the big biggest forces that lead to the ball is the company attitude. the company doesn't really put a high value on documentation. its hard to tell sometimes what the intent of a class is. i've had to guess more then once and hope i was right.

time has been another big force in creating the ball. there were more then a few 15 hour days trying to get things done. once a developer becomes overworked bad choice start happening more and more.

the skill of the developers was also a force. i feel this could have been counter somewhat by having more code and peer reviews.

changing requirement was another driving force. major requirement have been changed a week or so before deadline. you try to build in flexibility into the architecture as you can but there is only so much that can be done some times.

BA 8

there were several reasons that Guardian.

the biggest reason and one of the most common reasons new systems fail is performance the system scaled well but overall performance wasn't very good when the system was created and systems have only become faster.

a 16 bit address space was another limitation. it was later changed but contributed some.

hardware has become more reliable. with more reliable hardware there is less need for these type of systems.

the author claimed that it also failed because it didn't handle all failure well. the system handled most failure well so while it wasn't prefect it was good. this might have been a small factor in it downfall but i don't feel it was a big one.

BA 7

most if not all operating systems assume they are the most privileged piece of software on a computer. virtual machines break this assumption by placing a layer of software between the hardware and guess operating system. one early approach to this problem was to catch exceptions thrown by the hardware. once the exception was caught the VM would then emulate the call the guess OS was trying to make. there are problems with this approach. if the hardware doesn't raise an exception then there is nothing to catch and therefore nothing to emulate. the cost of avoiding this issue is performance. early incarnations of Xen suggested changing the guest OS to account for not being the lowest running piece of software on a machine. this solved a lot of issues that earlier Vm's had but it take a lot of force to get big proprietary software companies to change their software. if you're working with open source software or have the next "big idea" then this approach works fine but i don't think this is the common case yet.

layer architecture

the steps listed in the paper several steps for constructing a layer architecture.

step 1 define abstraction criteria.

this can be an easy task or very difficult. a lot of it depends on the particular problem that is being solved. if the problem lends itself to layers then it becomes much simpler to define abstraction layers. the paper listed a chess AI program as an example that lends itself to layers nicely. this step tends to be an interative process. the first try is rarely going to the 100% right.

step 2. deterimene the number of abstraction layers

this step is more art then science. the more systems you work with the easier this step becomes.

step 3 name layers and assign tasks

this step is fairly simple compared to the first two tasks. the author feels this step takes a lot of experence to do correctly. i think the abstraction criteria is done correctly this step should be almost intuitive.

step 4 Specify Services

this is a refinement of step 3. step 3 determines the outline of the layer step 4 defines the inner works of the layer.

step 5 refine the layering process

repeat steps 1 through 4 till each layer is solid.

step 6 define the interface for each layer

once each layer is solidly defined it should be clear what each layer needs so defining an interface should be somewhat simple. the author state that doing this is black box fashion is best and i agree.

step 7 structure individual layers

this step would involve filling in more details of how each individual layer should work. this step can vary from simple to complex depending on how complex the individual layer is.

step 8 specify communications between adjacent layers

this is fairly simple step just a choice in which communication methodology to use. the author suggests 2 common ones. push pull method and callbacks

step 9 Decouple adjacent layers

this is very architecture dependent. it could be simple or very difficult to do

step 10 define an error handling strategy

this is another basic design choice that can vary from architecture to architecture

pipes and filters

for pipes and filter architecture to realize the full potential of parallelism requires a few things. at least the initial filter can't consume all the input right way. multiple CPU's either on the same machine or another will avoid context switching overhead. each filter would need to take roughly the same amount of time.

BA chapter 6

Facebook controls its privacy through a number of means. for external applications it only exposes certain information assuming the facebook user is allows it. the facebook user can associate his or her facebook account with an outside application so the application can pull information from facebook. applications running inside facebook have indirect access to more data then external applications. request for information flows through the facebook architecture allowing facebook to render some more private information internally. this allows more private information to be used without any external program having access to it. this is accomplished through a new language called FBML which is similar to HTML with new tags added in so the facebook platform can render private information.

Excerpts From Christopher Alexander

a pattern language is a defined way of how to communicate how patterns fit together. these patterns are typically design patterns.i would say a pattern language is the language of design. this idea seems to fit better with buildings then with software architecture. i find it is rare that a software pattern will fit prefectly into solving a problem. it will come close and with a little oil and a hammer and some duct tape will solve the problem nicely.

BA ch 5

this chapter descries a resource oriented architecture. the focus of the architecture is to hold data and searchable format and be able to return the data in many formats. i think this style of architecture can be very powerful when it's useful. there are times that having access to data in a multitude of formats is avery good thing in fact for some tasks its the best solution. the only downfall i see is there are not many tasks that require data in different formats. the concept is interesting but in it's raw form has limited use. i suppose that can be said about most architectures but this one seems more limited then most. sometimes having too much information can be as bad as too little information. it can be hard to sift through. that can be frustrating to users as not being able to find the information they need.

archjava

archjava combines design and function into one language. this is a very powerful idea. it forces the programer to follow the design laid out. the language forces the programmer to think more about design and architecture. extending a language already in common use is a great advantage as well because the learning curve to use the language is fairly small.

BA 4

i found the approach the author used to design the system interesting. laying out facts about the problem and then drawing forces from those facts and from there you can chose how to balance forces. knowing the forces can help lead toward what the author called facets. one of the problems that was solved by the architecture was building a system with a seemingly complex dependence chain. it also solved the common issue of usability. most users of a system are never going to be computer people. building a system that is both functional and user friendly is a tall order even in a simple system.

BA chapter 3

Darkstar seemed like a very interesting concept. i've done some work with parallel programing myself and it does take another dimension of thinking to program in that style. with multi-core CPU's becoming almost commonplace now someday parallel programing might become more common but i think that will still be quite a while still. Darkstar appears to take the extra dimension away from the programer's thought process. one of the main concerns with parallel programing is scalability. i think there is a limited set of program types that need to scale up and down on the fly. throughput of a system can vary over time but few things spike in traffic like an MMO. an MMO world can be very crowded for a few hours and the population can drop off as most people go to bed. Darkstar isn't explicitly tied to games or MMO's in particular. it happens to be a good tool for the task just like a hammer is a good tool for hanging a picture. it's not the only tool but one of the better ones out there.

A Beautiful Architecture Ch. 2 A Tale of Two System

in this chapter the authors describe two systems, "Messy Metropolis" and "Design City". by the names a person can tell one is a prime example of what to do and the other an example of what not to do. the chapter mentions some good advice that i don't think a lot of people new to design think about. to paraphrase people working well together = better design. i think a lot of programers will get so focused on coding part of the design. that is a big part of the design process but that is not everything there is to it. if enough small things are neglected the system will suffer or fail.

CS527

test post