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.