If you liked the Project Lifecycle cartoon, you are going to love this.
While entertaining myself by reviewing the list of referrers to my blog, I happened to find this, which has lots ot work related cartoons. I found one which looks like an older version of the Project Life Cycle cartoon I posted earlier.
Enjoy!
Add comment April 29th, 2005
Are Carpools designed by sadists? I think so. Carpools are just plain evil!
I
live in the SF
bay area. Today I was driving from Palo Alto to Milpitas and after I got
on to Highway 237, I began crawling in the middle lane with traffic barely moving
for almost 8 miles. And then on my left, I see this wide open car pool lane,
with just an occassional car or two whizzing by. What the ding?!! 25–30% of
the lanes are reserved during peak time for who now? This makes no
sense. I see countless cars in my lane and the lane to my right all barely moving
and the lane on the left is empty! So I think carpools are evil and a waste
of thousands of hours, because:
Bottomline, Carpools are an unjustifiable failure that waste lots of gas and
lots of productive worker hours.
There is only one way to like carpool lanes. If you are driving in it. Or if
the car is in the pool!
Add comment April 29th, 2005
Is Apple being silly or what ? I had not heard of this upcoming book, and even if I did I probably would not have paid much attention to it.
Until I saw this and this today. Apple pulled Wiley books off their shelf despite the author and publisher saying that there is nothing negative about Steve Jobs or Apple in this book. I think this silly move by Apple is going to make this book a best-seller. This book is now on my list to buy now. There is probably more to this story. I am intrigued. What gives?
Add comment April 28th, 2005
I thought it would be fun to design a logo for ROME. So I could not resist participating in this
all roads lead to Rome… er, I mean, All Feeds Lead To ROME logo contest. My entry got accepted!
My design builds on the idea of All Feeds Lead to ROME tag line on ROME Website. The arrow heads represent Feeds and the bullseye represents the target in ROME. I tried to keep it as simple and minimalistic as possible. It is designed so that it can be used for a variety of purposes (website, docs, clothing, etc.)
Do you like my design?
[View other submissions here]
Add comment April 27th, 2005
What does the term "micro-architecture" mean to you? You probably
have heard it somewhere. But, its meaning can vary depending on the domain/context
most relevant to you: hardware or software (in broad terms). Micro-Architecture
is not a new term. In the area of microprocessor design, the term micro-architecture
has been used for a long time to describe processor design. A web
search for micro-architecture yields almost all references to microprocessor
design. There is even an IEEE committee
on micro-architecture.
So, here is one definition of the term from Wikipedia:
Microarchitecture consists of a set of microprocessor design techniques
used to implement the instruction set (including microcode, pipelining, cache
systems, etc.).
And, here is another from The
Anatomy of a High Performance Microprocessor:A Systems Perspective by Bruce
Shriver and Bennett Smith:
Microarchitecture is the term used to describe the resources and methods
used to achieve architecture specification. The term typically includes the
way in which these resources are organized as well as the design techniques
used in the processor to reach the target cost and performance goals. The
microarchitecture essentially forms a specification for the logical implementation.
What I want to talk about is the usage of the term micro-architecture
in software architecture. Here
is one such perspective titled Micro-Architecture
of Software Components (circa 1995), which tries to connect micro
(object/component) level concerns to macro (application) level concerns.
But that paper while filled with good intentions, I get lost quickly because
I find it too confusing to link the two levels of abstraction. I feel the difference
in abstraction levels make it hard to link those two levels. But, most references
to micro-architecture take this approach to connect the high-level software
architecture with low-level coding/implementation. Here
is another paper with an interesting title One
Architecture Does Not Fit All: Micro-Architecture Is As Important As Macro-Architecture.
In this paper, micro-architecture is treated as software component engineering
focussed on composition, compatibility and interoperability of componenets.
And this too quickly gets into a discussion of low-level component design issues.
In the micro-architecture definition by Shriver & Smith above, if we replace
"processor" with "system", the definition becomes pretty
generic and can apply for hardware or software or anything in between. That
leads to our definition of the same term as applied in software architecture.
Now I want to discuss how we
started using the term in the area of enterprise software architecture. In the
second edition of Core J2EE Patterns,
we said this about
micro-architecture:
We define micro-architecture as a set of patterns used together to realize
parts of a system or subsystem. We view a micro-architecture as a building
block for piecing together well-known, cohesive portions of an overall architecture.
A micro-architecture is used to solve a coarser-grained, higher-level problem
that cannot be solved by a single pattern. Thus, a micro-architecture represents
a higher level of abstraction than the individual patterns.
Our
goal was, and still is, to document reusable combinations of patterns, where
each combination (micro-Architecture) solves a problem that is too large for
any one pattern to solve.
In the diagram I have attempted to show the conceptual decomposition of a overall
Architecture into micro-Architectures, patterns, components and their relationships.
However, there are some missing parts that I should mention that are not shown
in the diagram. It is not always possible to describe an architecture entirely
as a set of micro-Architectures. Partly because much work needs to be done in
the area of documenting reusable micro-Architectures. The missing parts are
contextual in nature and are gaps in the architecture that are not addressed
by micro-Architectures alone. These gaps (which I tentatively want to call bridges
& connectors) are filled by individual patterns and/or custom implementations
to make the architecture complete. Thus you can view an overall architecture
as a union of these 2 sets:
Architecture = {µArch1, µArch2, … , µArchN} + {bridges
& connectors}
Next, I will try to describe more about the relationship between µ-Architectures,
Patterns, and Frameworks.
What do you think?
Architecture Pattern Software Design
Add comment April 25th, 2005
First,
Cookie Monster went vegan!
What next? Count Von Count counting
Big Bird‘s calorie intake? No. It‘s only that
PBS is going commercial. They are launching
a new channel called PBS Kids Sprout on Comcast. While the On-Demand feature
looks interesting (access any show anytime), it seems to be more mainstream
commercial than the regular PBS Kids channels we are used to. Atleast according
to the media reports.
According to this
column:
…public television executives say the advertising will all be very
low-key. Commercials will run only between programs.
Huh?? Does that mean we won‘t get to see Cookie Monster gulping down a Diet
Coke during the show.
And this
article from Washington Post says:
PBS programming would not have commercials “in the traditional sense”;
it will, however, include about the same dose of sponsorship spots as other
PBS fare. They will be targeted at parents and caregivers, not children, and
will appear only between programs, said PBS spokeswoman Stephanie Aaronson.
Note to self: Time to join Campaign
for Commercial-Free Childhood.
Add comment April 22nd, 2005
Service granularity is a recurring hot discussion in design teams. So, I am
glad that my amigo John Crupi started this discussion
on SOA Granularity. The issue of granularity is a never ending discussion, and
as John mentions is an easy way to start a debate. The issue of granularity
is not just an issue in SOA. We have always had to deal with object/procedure/service
granularity in designing a system. I think
SOA magnifies the granularity issue by bringing it to the forefront of the design
discussion.
IMO, granularity is a subjective matter. What is coarse-grained for one is
not coarse-grained for another. I think this subjectivity is one of the reasons
that granularity becomes a hot topic debate amongst designers. While granularity
is one aspect that must be paid close attention to, I think it is better not
to issue edicts around it. Because the moment you define a law of granularity,
someone is going to break it! Trust me.
Pragmatically speaking, a (composite) SOA application will contain services
of varying levels of granularity as shown in the diagram. I think what John
is pointing out is that you want to ensure that the services that are exposed
externally are the ones that are on the top (i.e. relatively coarse-grained).
Anyway, I do agree with John that when talking about SOA services, we should
be talking about business services. But, that does not really
imply that we should always make a service coarse-grained. So, can
a business service be fine-grained? It depends, on the business it serves.
For instance, let's say you are a famous online auction company and
many successful small business partners use/depend on your auction platform.
Let‘s say that these users require a service to be exposed that returns the
latest bid price for a given item number. Is this too fine-grained? It sure
feels like it when compared to other services like Create Auction,
End Auction, etc. But what if this is indeed business speak. That is,
your business managers want to provide a Latest Bid Price service.
And what if your partners using this service are willing to pay for
it. Will you not expose this service because it is fine-grained? Hell, no! You
are going to expose that service. Why? Because it is going to make
money! Whether that be a Dime, a Rupee, a Yen or a Yuan. (OK, it is not always about money, but surely about generating some business value.)
So while we lean towards making SOA services as coarse-grained as necessary,
remember that whether a service is coarse-grained or fine-grained or
in between, if it makes business sense, it must be a good service to
expose to the world.
SOA Architecture WebServices Technology
Add comment April 21st, 2005
It shouldn‘t be this wicked. Ok, I admit it has been a while since I implemented
a Java RMI based
client/server. But, it shouldn‘t be this wicked. So, I was trying to get some
RMI client/server code running on my machine. And I kept getting was this friggin
exception:
Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.lang.ClassNotFoundException: com.sun.salsa.PatternModelImpl_Stub
The RMI docs said that anytime you get a ClassNotFoundException, it
is most likely caused by an improperly set codebase[J] So I checked
the value of my java.rmi.server.CodeBase property. It was set as follows:
java.rmi.server.CodeBase=file://dev/salsa/classes
I checked to make sure that the directory was there and that all the stubs
and other classes were in there. They were. So, I ran the RMI server program
again. But, again I got the same exception. What the heck is going on? And then
it hit me. Isn‘t that supposed to be codebase and not CodeBase?
So I change "CodeBase" to "codebase" and reset the property
as follows:
java.rmi.server.codebase=file://dev/salsa/classes
And give the program another try. This time, I got a different exception.
Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission //dev/salsa/classes read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) …
Hmm…this looks like we need some permissions granted. That‘s easy, let me go
the $JRE/lib/security directory and change the java.policy file
and add a new grant permission and it should all be fine. So I edit the
java.policy file and add the grant permission:
grant codeBase "file://dev/salsa/classes" {
permission java.io.FilePermission ">", "read";
};
I run the program thinking I fixed the problem for good. But not so fast! I
see the same exception again. Then it hit me again. I had committed another
silly error. It appears that I gave 2 slashes (file://…) to the codebase
to separate the protocol and the url.
So I quickly undo the changes I made to the java.policy file.
I go back to the codebase property and this time I set it as follows:
java.rmi.server.codebase=file:/dev/salsa/classes
I restart my RMI server and voila! Everything works fine this time!
Thought this record of my silly errors might help someone else sometime.
[J] Thanks to Jeremy Pitten
for reminding me the codebase settings.
Add comment April 20th, 2005
Let's say you have used a pattern many times in your implementations. And then
one day something new comes along and you no longer need to implement that old
pattern anymore. So what happens to that pattern? Does it get deprecated? I
have come across this question many times while talking to other developers.
For instance, this question of pattern deprecation is associated with some
patterns we documented in Core J2EE
Patterns. We first released these patterns in the 1st edition. And when
newer version of J2EE/EJB/Servlet specifications became available, these patterns
gained direct support in the underlying platform. The questions related to a
few of the J2EE patterns are:
IMO, patterns do not get deprecated. In these cases above, the patterns were absorbed and supported into the relevant specifications. This makes the platform better because it is providing built-in support for well known patterns. So as platforms mature, some platform patterns can get assimilated into the platform as a process of improvement.
This process however does not diminish the value of those patterns. Instead the forces around the patterns can change a bit leading to new solutions and strategies for implementing the pattern in the new platform. This is what happened to some patterns in Core J2EE Patterns. As J2EE evolved, the strategies we describe for these patterns also evolved. I look at this as a process of symbiosis and maturation between patterns and platforms.
YouRIt: Patterns Architecture J2EE Programming
Add comment April 18th, 2005
Don‘t you hate being stereotyped? I do, anywhere anytime.
This time, I think the restaurant chefs are out to get me! They want to find out how spicy I can
eat, because they hear Indians can eat very spicy food with ease and delight. So
this is exactly what happens to me in some restaurants and especially in ethnic
restaurants. And especially if I am new to that restaurant.
When I find a new restaurant, I really really want to check it out. So, when
I get my food, I find that they made it the spiciest they can, without checking
with me first! And then hand it to me with a big smile and say what I have now
heard many times in many places:
"I made it extra spicy for you!"
And I am like:
"What the…Oh no! I hate friggin extra spicy! Spicy is ok,
but extra spicy? Darn!"
Of course, I do not say that aloud to them, because I might want to come back there again.
So nowadays while ordering my food, I ask them upfront to go easy on the extra spicy.
On the plus side, spicy food does have potential benefits. Check out Kormatherapy!
Korma
Hmm…Maybe I am shouldn‘t be complaining after all!
Todd
Fast points out Gernot Katzer's Spice
Pages, which provides a detailed look at each of over a hundred spices.
Programmer's Kormatherapy
Now, let me draw a parallel lesson in software development from the afore mentioned experience. If in the above anecdote, I substitute as follows:
Now i wonder how often programmers produce code with extra/excessive
features than what the customer really asked for in the first place.
For instance, if customer asks for a feature set {A, B, C} and the programmer
churns out {A, B, C, D, E}, would the customer be delighted? Probably, if {A,
B, C} were implemented to meet the requirements. However, a more likely scenario
is that the programmer churns out {A, X, Y} because {X, Y} is what the programmer
thinks the customer asked for when they described {B, C}. But a more interesting
reason might turn out to be the wanderlust programmer implementing {X,
Y}, which seem a lot more fun than implementing boring old {B, C} !
YouRIt: Programming Life
Add comment April 15th, 2005
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Mar | May » | |||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | |