Notes on declarative programming techniques

I am reading some great stuff on Computational Models. It is via “Concepts, Techniques and Models of Computer Programming” book from MIT Press, Special thanks to Gaurav for pointing me this. I am dumping my notes here for my future reference

Computational operation: A program fragment with inputs and outputs.

Declarative operation: A computational operation is declarative if

1. is independent (does not depend on any execution state outside of itself),
2. stateless (has no internal execution state that is remembered between calls), and
3. deterministic (always gives the same results when given the same arguments).

A component can be thought of as a precisely delimited program fragment with well-defined inputs and outputs. A component can be defined in terms of a set of simpler components.

Why declarative programming?

• Declarative programs are easier to compose. A declarative program consists of components that can each be written, tested, and proved correct independently of other components and of its own past history (previous calls).
• Understanding declarative programs is simple. Why –  “Consider a program with a declarative component. This component can be understood on its own, without having to understand the rest of the program. The effort needed to understand the whole program is the sum of the efforts needed for the declarative component and for the rest. If there would be a more intimate interaction between the component and the rest of the program, then they could not be understood independently. They would have to be understood together, and the effort needed would be much bigger. For example, it might be (roughly) proportional to the product of the efforts needed for each part. For a program with many components that interact intimately, this very quickly explodes, making understanding difficult or impossible.”

Can we do away with non-declarative code? They cannot be “legislated away” by programming in a model that does not directly support them.  But  an  important  principle  is  that  they  should  only  be  used  when necessary and not otherwise. To support this principle, as many components as possible should be declarative.

Classification of declarative programming in 1000 words

Another interesting orthogonal taxonomy can found here. Alternative Computational Models by Martin Fowler.

Layers vs. Tiers

Most people often use the terms layers and tiers interchangeably. A layer is a logical means of separation of concerns. A tier is a physical separation. Even when we run all the layers of a layered application on a single machine, it will still be n-layered. Provided the resource requirements are met the application would still run without any major issues.

While you can collapse deployment to make all the layers run on the same node (provided the resource requirements are met) It will be hard to do the other way round. It will often be difficult to introduce a tier boundary between two layers when the tier boundaries were not designed for. Most applications today can handle introducing tier boundaries between the database and data access layer. To introduce a tier boundary other than this you have to design your application explicitly for it. Example: Tier boundary between presentation layer and the service layer / application layer is the most used one. But this has to be explicitly designed for. The remote interfaces should be coarse grained as opposed to fine grained to take into account the network latency / inter-process latency involved.

I have not seen a tier separation between the Business Layer / Domain Layer and the Data Access Layer though this might become more common with the cloud based data services looming over the horizon.

To those who had seen the client server era, another common trend in the recent past is the disappearance of the app server. The web server typically hosts the domain logic in its own process leading to the popularity of two tier application (if you do not consider the browser machine separately). This is a reasonable optimization considering that presentation related logic is already running on a central server (the web server). But once applications are written for this assumption it becomes really difficult to introduce a tier boundary.

A typical two tier web app will have the following layers.

Presentation –> Domain –> Data Access (all running on web server) => database.

-> Logical separation

=> Physical separation

Since the object-oriented domain layer interfaces are fine-grained it will be difficult to introduce the tier boundary later without rewriting the presentation layer. A different approach would be

Presentation –> Service –> Domain –> Data Access (all running on web server) => database.

The Service layer offers a coarse-grained interface to the presentation layer thus making the optional tier boundary possible when really needed.

Presentation ( Web Server ) => Service –> Domain –> Data Access (App server) => database.

I have introduced several terms Presentation, Service/Application, Business/Domain, Data Access. Most of them are self explanatory. In case there is any confusion please refer to Martin Fowler’s Patterns of Enterprise Application Architecture catalog for the vocabulary used. I will also discuss this layering scheme of Fowler along with that of Eric Evans’ scheme in the near future.

Answer to my question, Are Shelves anti-CI?

A while ago a posted a blog entry on are shelves anti-CI. Martin Fowler’s entry today on Feature branches is very much related to some of the questions I had in mind.

http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!1318.entry

http://martinfowler.com/bliki/FeatureBranch.html

Carrots, Eggs & Coffee

Stolen verbatim from Clarke Ching’s blog

 

A young woman went to her mother and told her about her life and how things were so hard for her. She did not know how she was going to make it and wanted to give up.  She was tired of fighting and struggling. It seemed as one problem was solved, a new one arose.

Her mother took her to the kitchen. She filled three pots with water and placed each on a high fire. Soon the pots came to boil. In the first she placed carrots, in the second she placed eggs, and in the last she placed ground coffee beans. She let them sit and boil; without saying a word. In about twenty minutes she turned off the burners. She fished the carrots out and placed them in a bowl. She pulled the eggs out and placed them in a bowl. Then she ladled the coffee out and placed it in a bowl.

Turning to her daughter, she asked, ‘ Tell me what you see.’

‘Carrots, eggs, and coffee,’ she replied.

Her mother brought her closer and asked her to feel the carrots. She did and noted that they were soft. The mother then asked the daughter to take an egg and break it. After pulling off the shell, she observed the hard boiled egg.

Finally, the mother asked the daughter to sip the coffee. The daughter smiled as she tasted its rich aroma. The daughter then asked, ‘What does it mean, mother?’

Her mother explained that each of these objects had faced the same adversity: boiling water.

Each reacted differently. The carrot went in strong, hard, and unrelenting. However, after being subjected to the boiling water, it softened and became weak. The egg had been fragile. Its thin outer shell had protected its liquid interior, but after sitting through the boiling water, its inside became hardened. The ground coffee beans were unique, however. After they were in the boiling water, they had changed the water.

‘Which are you?’ she asked her daughter. ‘When adversity knocks on your door, how do you respond? Are you a carrot, an egg or a coffee bean?

Think of this: Which am I?

Am I the carrot that seems strong, but with pain and adversity do I wilt and become soft and lose my strength?

Am I the egg that starts with a malleable heart, but changes with the heat? Did I have a fluid spirit, but after a death, a breakup, a financial hardship or some other trial, have I become hardened and stiff? Does my shell look the same, but on the inside am I bitter and tough with a stiff spirit and hardened heart?

Or am I like the coffee bean? The bean actually changes the hot water, the very circumstance that brings the pain. When the water gets hot, it releases the fragrance and flavor. If you are like the bean, when things are at their worst, you get better and change the situation around you.

When the hour is the darkest and trials are their greatest do you elevate yourself to another level? How do you handle adversity? Are you a carrot, an egg or a coffee bean?

May you have enough happiness to make you sweet, enough trials to make you strong, enough sorrow to keep you human and enough hope to make you happy.

The happiest of people don’t necessarily have the best of everything; they just make the most of everything that comes along their way. The brightest future will always be based on a forgotten past; you can’t go forward in life until you let go of your past failures and heartaches.

When you were born, you were crying and everyone around you was smiling.

Live your life so at the end, you’re the one who is smiling and everyone around you is crying.

Embedded Web Resources related Javascript errors

It is sort of a long rant, feel free to jump to the end if you want to read the findings alone.

We had been running into this issue for more than an year now. I have been postponing getting to the bottom of the issue because we found some solution which works. We did not know why. A healthy prod by my client forced me research on the issue further.

The problem: Javascripts from embedded resources within assemblies were not getting downloaded and we used to get errors like ‘YAHOO’ is undefined, ‘xyz..’ is undefined etc. Initially I was thinking that the assembly has gone corrupt during the file transfer and used to retransfer the assembly to the server. And it used to work. Sometimes even a retransfer of file doesn’t work. After that we tried using reflector on the so called ‘corrupt’ assembly, but it opened like a charm indicating the file hasn’t gone corrupt. We also used to zip the files and when we transfer the files without zipping things used to work.

We thought the problem was with the zipping tool used to create the zip file and tried different options but in vain. A uncompressed file transferred directly used to work where as a zipped file fails, even though it opens fine in reflector. After some frantic searching yesterday I found the real reason. Initially I was on a wild goose chase around the lines of “The not so mysterious problem around webresource.axd”. I also created a sample to simulate the issue, but it vain.

Today morning I ran into “Web Resources Troubleshooting” from the Telerik folks. After reading the article I realized I had seen the error earlier in one of the dev boxes due to the date being in the future. I created a small sample to reproduce the issue and bingo! But it did not answer the question how retransfer was fixing the issues. We always zip the files and transfer the website. When 1 or 2 odd dlls go missing we do not zip that during the transfer.

The source and destination machines were in different time zones / times. The following conditions had to be true to get a the exception.

• If the assembly build time happens to be within the time difference
• and you zip the assembly for transferring
• and for unzipping you use Windows Explorer Compressed folder feature 

the issue will occur

I did some more research and found the following facts.

Findings: Different applications use different philosophies when it comes to handling datetime stamps (Date Created & Date Modified). I tried the following applications

• Windows explorer copy & paste to destination folder (from an ftp site).
• Internet explorer saving the file from a web site
• Windows Explorer Compressed folder feature to extract files.
• 7Zip Extract files feature

The Windows Explorer Compressed folder extract files uses the timestamp of the source machine as is where as the other scenarios the local machine’s timestamp was used (I am overly simplifying it, you can try this on your own).

You can use Fiddler / firebug to see if any webresource / scriptresource are not getting downloaded. Here is the original error.

"Specified argument was out of the range of valid values. Parameter name: utcDate"
The assembly containing the embedded resources is probably built in the future (its last modified time is later than the current time). This can occur when deploying in a different time zone. In such case run the following command line statement (the commas and plus at the end are important!):
copy /b <path to assembly which is built in the future>+,,”

A little reflectoring lead me to AssemblyResourceLoader.GetAssemblyInfoWithAssertInternal which was using File.GetLastWriteTime rather than GetLastWriteTimeUtc. Is this the cause for the exception? I didn’t look deep enough to figure that.

Layering

Layering is one of the most common techniques that software designers use to break apart a complicated software system. It serves to help us in Separation of Concerns.

Advantages of Layering

• Reuse of Layers
• Standardization possibilities
• Dependencies are kept local
• Exchangeability
• Raise the level of Abstraction

Some of the Drawbacks

• Cascades of changing behavior (Ex: Adding a field to the database and its ripple effect in all the layers)
• Lower efficiency
• Layers lacks support for the easy recombination and reuse of components.

POSA Volume 1 and PoEAA are good places to read more stuff on this.

We’ll look into some of the popular schools of thought on layering.

POSA: Pattern Oriented Software Architecture

PoEAA: Patterns of Enterprise Application Architecture

Implementation based organization / decomposition

Layering is one of the most common techniques that software designers use to break apart a complicated software system. But it is not the only one.

The list that I know of includes

• Layering
  • Top-Down Communication – Request/Response Style
  • Bottom-up Communication – Notification Style
  • Two Stacks of N Layers communicating with each other – Yo Yo Style (The best known example is TCP/IP)
• Pipes and Filters (Ex: The Http Modules pipeline in ASP.NET)
• Ports and Adapters (Hexagonal Architecture – this can also be a thought of as a view of layering)

More on each of these soon…