Buzzword Buster — Stylesheets, XSL and XSLT

Stylesheet

A Stylesheet lan­guage or style lan­guage, is a com­puter lan­guage used to describe the pre­sen­ta­tion of struc­tured doc­u­ments. A struc­tured doc­u­ment which doesn’t break the schema it is designed to con­form to is “well-formed”.

One mod­ern Stylesheet lan­guage with wide­spread use is Cas­cad­ing Style Sheets (CSS), which is used to style doc­u­ments writ­ten in HTML, XHTML, SVG, XUL, and other markup lan­guages. One of the most attrac­tive fea­tures of struc­tured doc­u­ments is that the con­tent can be reused in many con­texts and pre­sented in var­i­ous ways. Dif­fer­ent Stylesheets can be attached to the log­i­cal struc­ture to pro­duce dif­fer­ent presentations.

In order for con­tent in struc­tured doc­u­ments to be pre­sented, a set of styl­is­tic rules — e.g. colours, fonts, lay­out — must be applied. A col­lec­tion of styl­is­tic rules is called a Stylesheet.

XSL

XSL stands for EXten­si­ble Stylesheet Language.

CSS = Stylesheets for HTML — HTML uses pre­de­fined, well under­stood tags, you can use CSS to tell a browser to dis­play an ele­ment in a spe­cial font or colour, etc.

XSL = Stylesheets for XML — XML does not use pre­de­fined tags and there­fore the mean­ing of each tag is not well under­stood. XSL describes how the XML doc­u­ment should be displayed!

XSL con­sists of 3 parts:

  • XSLT — a lan­guage for trans­form­ing XML documents
  • XPath — a lan­guage for nav­i­gat­ing in XML documents
  • XSL-FO — a lan­guage for for­mat­ting XML documents

XSLT

XSLT stands for XSL Trans­for­ma­tions, it is a declar­a­tive, XML-based lan­guage used for the trans­for­ma­tion of XML doc­u­ments into other XML documents.

The orig­i­nal doc­u­ment is unchanged, after the trans­for­ma­tion the new doc­u­ment maybe seri­alised by the proces­sor in stan­dard XML syn­tax or in another for­mat such as HTML or plain text.

With XSLT you can add/remove ele­ments and attrib­utes to or from the out­put file. You can also rearrange and sort ele­ments, per­form tests and make deci­sions about which ele­ments to hide and dis­play, and a lot more.

A com­mon way to describe the trans­for­ma­tion process is to say that XSLT trans­forms an XML source-tree into an XML result-tree.

XSLT uses Xpath to find infor­ma­tion in an XML doc­u­ment. Xpath is used to nav­i­gate through ele­ments and attrib­utes in XML documents.

In the trans­for­ma­tion process, XSLT uses Xpath to define parts of the source doc­u­ment that should match one or more pre­de­fined tem­plates. When a match is found, XSLT trans­form the match­ing part of the source doc­u­ment into the result document.

Fur­ther reading:

W3C schools XSLT Tutorial

Share
February 12, 2010 | | Tags: | No Comments »

Buzzword Buster — DDD

Def­i­n­i­tion:

Domain Driven Design (DDD) is an approach to soft­ware design which puts the focus on the prob­lem domain and pro­vides a struc­ture for mak­ing design deci­sions to accel­er­ates soft­ware devel­op­ment for com­pli­cated domains. The key com­po­nents in DDD include:

Domain: the sub­ject area to which your pro­gram is applied

Model: abstrac­tions that describe aspects of a domain and can be used to solve prob­lems related to that domain

Domain Experts: peo­ple with the most com­plete knowl­edge about the world your sys­tem will live in

Ubiq­ui­tous lan­guage: a lan­guage around the domain model used by all team mem­bers, the lan­guage is ubiq­ui­tous because it is present everywhere

Pur­pose:

Tra­di­tion­ally .Net appli­ca­tions are devel­oped using a data-centric approach where you build your sys­tem around your under­stand­ing of the data – cre­at­ing all the tables and the rela­tion­ships in the Data­base and then mir­ror them in your .Net code. This approach is pop­u­lar because of the ease and speed with which you can cre­ate a fully func­tional sys­tem from the ground up.

DDD on the other hand, focuses on the prob­lem domain as a whole which cov­ers not only the data but also the behav­iour. DDD encour­ages greater involve­ment from domain experts, the idea is to build your sys­tem in a man­ner that’s reflec­tive of the actual prob­lem domain you are try­ing to solve and let the domain drive your design decisions.

One of the great­est chal­lenges in devel­op­ing a new sys­tem is to learn and under­stand the new busi­ness, which is why a sin­gle, shared lan­guage (the ubiq­ui­tous lan­guage) between the users and the devel­op­ers can go a long way to reduce mis­in­ter­pre­ta­tions and cre­ate a more con­cise and effec­tive com­mu­ni­ca­tion amongst all inter­ested parties.

Part­ing thoughts…

It is impor­tant to remem­ber that whilst DDD is bet­ter than the data-centric approach in some cases, the reverse is also true.

Also, DDD car­ries with it the over­head on the devel­op­ers’ part to become pro­fi­cient (or some­times experts!) in the prob­lem domain and being able to com­mu­ni­cate with the users in an com­mon language.

Mas­ter­ing both pro­gram­ming skills and busi­ness knowl­edge in the core prob­lem domain is dif­fi­cult and takes sig­nif­i­cantly longer than the course of devel­op­ing an appli­ca­tion — sea­soned devel­op­ers in the Finan­cial sec­tor would no doubt agree with this! This is one of the rea­sons why knowl­edge in a par­tic­u­lar area (equi­ties, deriv­a­tives, etc.) is such a valu­able asset and devel­op­ers who also qual­ify as domain experts in a busi­ness area are so highly sought after and compensated.

On the hand, it is also why so many find it hard to break into Finance despite boast­ing impres­sive devel­op­ment skills, and why many oth­ers become type­cast with a spe­cific industry/area and find oppor­tu­ni­ties out­side their famil­iar ter­ri­to­ries hard to come by.

Dur­ing my time with Credit Suisse I have come across many devel­op­ers who have spent their entire pro­fes­sional career in the same busi­ness area, becom­ing domain experts in their own right. Though per­son­ally it’s not what I’m look­ing to get out of my career I can def­i­nitely see the mer­its of doing so and appre­ci­ate the enthu­si­asm they have for their prob­lem domains.

Fur­ther reading:

Domain Dri­ven Design by Eric Evans

Share
February 7, 2010 | | Tags: , , , | No Comments »

Buzzword Buster — AOP

Def­i­n­i­tion:

Aspect Oriented Program­ming (AOP) is a pro­gram­ming par­a­digm where each appli­ca­tion can focus on its pri­mary func­tions and core con­cerns by encour­ag­ing greater mod­u­lar­ity and increas­ing sep­a­ra­tion of cross-cutting con­cerns (such as log­ging and authentication).

Pur­pose:

In any real-world appli­ca­tions, when you’re writ­ing code to address the prob­lem domain (say, book­ing an order) you might need to address other con­cerns such as:

  • per­sis­tence — writ­ing to the data­base for example
  • trans­ac­tion han­dling – defin­ing trans­ac­tion scope and set­ting roll­back strat­egy, etc.
  • secu­rity — user authen­ti­ca­tion for example
  • log­ging — for audit­ing and debugging

So effec­tively you’re mix­ing mul­ti­ple domains with fine-grained inter­sec­tions and likely to end up with:

  • tan­gled code — mak­ing it more dif­fi­cult to work out what the code is doing to address the core concern
  • boil­er­plate code at every inter­sec­tion point – intro­duc­ing dupli­cated code and increas­ing the size of the code base and the blast radius of any change that are not related to the prob­lem domain, e.g. chang­ing the per­sis­tence media..

AOP aims to address these prob­lems by sep­a­rat­ing cross-cutting con­cerns into sin­gle units called aspects, each aspect encap­su­lates behav­iours that affect mul­ti­ple classes into reusable modules.

Part­ing thoughts..

As far as I can think of, the only draw­back of AOP is that you no longer see all the behav­iours of your class when you open it and it requires knowl­edge of the whole sys­tem to know what else are hap­pen­ing under the cover. Which inter­est­ingly, is the flip side of the same coin because you employ AOP when you don’t want to deal with cross-cutting con­cerns all the time!

One of the ways to mit­i­gate this prob­lem is to build up a cul­ture in your team and stan­dard­ise how AOP is imple­mented so that every­one is on the same page and there are few surprises.

Frame­works:

Post­Sharp pro­vides a light­weight AOP frame­work for the .Net plat­form and is estab­lish­ing itself as the de facto stan­dard much like the way AspectJ has done for Java.

Share
January 10, 2010 | | Tags: , , , , | 1 Comment »

Buzzword Buster – Cross-Cutting Concern

Def­i­n­i­tion:

A Cross-Cutting Con­cern is a con­cern your appli­ca­tion needs to address that is unre­lated to your application’s prob­lem domain, and ‘cuts across’ other con­cerns. Typ­i­cal exam­ples include:

  • log­ging
  • per­sis­tence
  • secu­rity
  • error han­dling

They are usu­ally dif­fi­cult to decom­pose from the rest of the sys­tem and result in tan­gled code. Address­ing these cross-cutting con­cerns will add a lot of boil­er­plate code into your appli­ca­tion, increas­ing both the size and com­plex­ity of your code.

To ease the pain of deal­ing with cross-cutting con­cerns in our appli­ca­tions, Aspect Ori­ented Pro­gram­ming (AOP) was born and frame­works such as Post­Sharp (which I’ve blogged about already) pro­vides an effec­tive way of intro­duc­ing AOP into .Net applications.

Share
January 7, 2010 | | Tags: , , , , | No Comments »

Buzzword Buster — DSL

Def­i­n­i­tion:

A Domain Specific Language (DSL) is a pro­gram­ming lan­guage that’s ded­i­cated to a par­tic­u­lar prob­lem domain. DSLs are often used to sup­port domain-drive design and mod­el­ling. It’s the oppo­site of gen­eral pur­pose pro­gram­ming lan­guages such as C# or Java.

Advan­tages:

  • Code looks like domain prose.
  • Eas­ier to under­stand by everyone.
  • Eas­ier to align with requirements.
  • More suc­cinct (so less code is required!).

Dis­ad­van­tages:

  • Hard to design, test and debug.
  • Bad API design­ers make even worse DSL designers!
  • Dif­fer­ent peo­ple use dif­fer­ent ter­mi­nolo­gies (think mobile in the UK and ‘cell’ in the US) which reduces DSL’s abil­ity to bridge gaps in communication.

Part­ing thoughts..

  • Indus­try spe­cific, so from a career and per­sonal devel­op­ment point of view, it’s not attrac­tive to me to spe­cial­ize myself in DSLs and be locked into one industry.
  • Exist­ing exper­tise and tal­ent is hard to find (com­pared to gen­eral pur­pose languages).
  • Addi­tional train­ing required for peo­ple new to the industry.
Share
| | Tags: , , | No Comments »
« Older Entries
Newer Entries »