Monday, October 24, 2005

So is code really model? And what is the mysterious word "code"

Sometimes, it seems so odd to call code a model. Why? Well, true it has the characteristics of a model, but I once thought, it is also more appropriate to say that code is at a higher level than machine code, but it is still "code".

Then the question arises what is "code" and it does it have to be textual? For the most part, yes. Once upon a time, code meant humans writing instructions that a machine can understand. There could be layers of transformers and compilers in between, but eventually it was for the machine to process and execute. And generally humans are more precise in wrting in text than drawing pictorial models, so computer scientists always resorted to a textual form for "code". Not that graphical models wouldn't work. I can imagine having machine level instructions generated from squares and circles and arrows between them. But as you can imagine this is not productive. Also, historically computer scientists were always very technical and had a math or physics mindset. And hence graphical models again never enticed them.

So, it always came to understanding in the computing industry that when someone says "code", alarms ring in the brain shouting, some textual representation understood by a computer by either consuming directly or by transforming it in layers in different intermediate languages. But even these intermediate languages are always perceived as to be textual.

So the next obvious question arises is "Whether all that is said above is true ? - Was it right to always perceive code as of some textual form".

Or whether code is nothing but a model representation of a programming language which eventually is a model of an intermediate language which in turn is a model of machine code? Are they all truly "models"? Just taking the avatar of textual representation? In theory, this statement seems right. But in practice, when the "how" comes into play, suddenly we are confused again. So is thinking in "how" really evil, and the textual form thinking, we have adopted "code" is a just a fallacy? Maybe, maybe not. Or maybe it is just one of the many buzzwords our industry is known to create. Or maybe "model" is just a word, that has a vague meaning in our industry.

Harry Pierson's this blog entry inspired me to write this entry. After reading it, for the most part, he convinced me to think of code in terms of model. And I also agree with the "tenets" he mentioned in his weblog. Also, I personally cannot imagine working on an enterprise level project without modeling the design and architecture level artifacts using some diagram like UML. And I also agree that models are of little value, if they are not used to transform and generate into code.

So yes, I think it is accurate to say, that code is model. It is theoretically sound and can be proved easily using Mathematical induction. Although I personally think that this distinction isn't as important as it seems. But I agree, it is good to get the vocabulary straightened out. So when someone speaks of a model, our brain tells us that he/she is just speaking of a high level abstraction to some low level abstraction, be it in text form or graphical or 3-dimensional - although that would be interesting - having each co-ords represent some special artifact :)

Before, I had always thought of UML diagrams as models, just because they were graphical. And there was a correction needed in my comprehension.

You can share your opinions in the comment section of Harry's weblog.

Wednesday, October 19, 2005

From Shrinkwrap to Custom Development

I was reading Joel Spolsky’s article - Set Your Priorities and found out that he has some interesting points on shrinkwrap software, consultingware and custom development.

But what is even more interesting is that, his writing is based on his own product, FogBugz, which is important to note, because the domain of the product is a general purpose one. The product does not encapsulate logic any of the logic of the business sector, the product will be used in, other than some configuration settings.

On the other hand, there are some products that specific to a particular domain and has assumptions of it made in the software. I have found that for products with these needs, consultingware and custom development is often more profitable than shrinkware, because you can give the customer that extra level of domain expertise, like a special web app for insurance companies.

Now, I am not saying the core architecture of the product is solely based on that model, but what I am trying to say is the core product architecture can be general level one, with all the common logic and abstractions modelled. But all the custom and special domain logic and functionality are designed to extend this model like plugins or modules and run on top of this.

This way you can have a very successful and fulfilling business model for software products that are intended for specific business domains.

Monday, October 17, 2005

Loose coupling between layers of an application

I was listening to Mario Cardinal's podcast discussion with George Hohpe, where they discuss the layering pattern and issues surrounding it.

Mario asks George, how can we loosen the coupling between layers, and George replies among other things, one can:

* Wrap lower layer exceptions in the upper layer's exception type and not expose them to the layer above. George thinks, this is almost always a good idea.
* Use the all mighty - Program to interfaces - even though the interface which is in the current layer, but has some or all of its implementations in the lower layer or even on layers at the same level, it is OK to depend on the interface. And use dependency injection to plug and play implementations at run-time, without actually being dependent on any one of them. This is also very useful for testing and mocking objects
* Use events - asynchronous or not (something I am adding) - so the upper layer can subscribe to some events of interest happening in the lower layers and can and get notified when they occur - aka Observer pattern - but applied to objects that could be potentially in different layers. Events are great to communicate messages and notifications without being coupled to the implementations that generate those events. The good part here is that the lower layer does not which objects in the layer above are listening to the events emittted.

Above all this, George says, no matter what, it takes only one bad coupling to break the entire loose coupling between layers, that's why this is sometimes so hard to get it right, especially in deployment scenarios.

You can listen to the podcast on Mario's website. This is his show # 7. He plans to do this oftenly and like his style of thinking and his questions are interesting. I plan to catch up with his podcasts, since I have used the Observer design pattern and asynchronously subsribed to his podcast notifications :)

Monday, October 10, 2005

Ruby is an interesting language

Ruby Programming Language: It's got iteration methods do: select, collect, inject:into from Smalltalk and many of the global variables from Perl.

Yet it mashes them in a nice piece that is easy to digest, and one that wants you come again for more.

It's interesting I am reading and learning more Smalltalk stuff, just because I am learning more about Ruby. Neverthought I would encounter Smalltalk docs, as I am relatively new - I started my computer science education in 2000.

I sometimes wondered what made Dave Thomas so zealous about Ruby. What did he saw in it, that he decided to dedicate months of his time mastering it. After reading his PickAxe book, and I now exactly why. What I found about Ruby is that, if you learn or study it with a positive attitude, reading to learn but not criticize or how it compares with your favorite language, it gets on you. It takes you over. You are like, what the heck - dynamic, closures, mixins, all the tasty globals, gems and libraries and the community - life is finally more fun.

But if you already took the time to learn, master, program in other oftenly compared languages like Python, you will appreciate some of its beauty and easily find some of its dents and issues. You are like, huh? Ok. Now, back to work. Although some of these guys are forcefully learning to learn the current phenomenon - RoR (ruby on rails), but what many of them don't get is - RoR's heart and soul is Ruby. It exploits its power and dynamic elegance and adds architectural patterns and framework models to it, giving it a nice rich personality. But Ruby is what inspired it. Without appreciating Ruby, learning and working with RoR is just like chasing the hype.

Ruby - It's the community, stupid!

Wednesday, October 05, 2005

An example where engineers came up with a solution to a problem when the language designers didn't

Constructors in modern OO programming languages have 2 main defects, that often cause annoyances, debates, discussions and often confusions

1. They handle the job of both constructing and initializing and besides they always have to create a new object, they can't return or initialize a previously allocated object

2. They can only return objects of their type and not of their subclasses

But software engineers and designers have happily come up with solutions that bypass these issues and now we are in a situation, that it would be OK if the next gen. OO language does not improve upon the current behavior. We are fine with it, we have found ways around and are now used to it, added in our code generators and our books.

This also proves that, the uses of a language is more powerful than the language itself.

Monday, October 03, 2005

When one pattern makes you think of others and reminds you of some refactorings!

When you use a Strategy pattern, you are now able to switch different implementations depending on the runtime environment or other domain logic.

But immediately you now have to worry - how to create the right strategy? Who will decide, who will create, where will the logic placed, what kind of configuration settings we will use, if any, or whether we will inject the strategy into the caller using dependency injection.

Hence, some of the following design patterns often come in mind, which when used along with the Strategy pattern makes a more complete solution:

Thinking of other patterns, in the light of a pattern is ofen lead by personal instincts, experience among other factors, but clearly having that ability seems extrememly valuable. These are different what GoF uses in their book, sort of related patterns. These are patterns that work in conjunction with the "base" pattern in question and are intended to serve as replacement of the base pattern.

Not only patterns, but it also makes you think of related refactorings that come in handy and preventing you from common pitfalls. Fowler and many others have made an impression of refactoring as applicable primarily to improve the design of "existing" code.

I, on the other hand them even in the design phase and often keep refactorings in the same toolbox as patterns, principles and practices. It makes me avoid making mistakes early on, that might need refactoring in the future. Hence, I think the term refactoring is sometimes, misleading. A more appropriate name would be just "Factoring".

Saturday, October 01, 2005

Search using the most common and popular resources on the net using rollyo

Using Rollyo, I created a personal search (Searchroll), that search common sites for software design patterns and architecture related resources.

Search Design Patterns Resources

Similarly I created a searchroll for the Ruby programming language and including sources from rails websites.

Search Ruby & Rails Resources

I have one created for Video Games too

Search Video Game Resources

© 2008 Vishal V. Shah. All rights reserved. Contents of this web site reflect my personal work and is not representative of my employer.