I've spent the last few weeks in a new larval stage again. This time I've the been studying the alphabet soup that surrounds web portlets and the JSR168 spec. I'm not talking about learning to make portlets... that's easy... I'm talking about the best way to make portlets.
The fastest way to get working with portlets is to start by creating JSP pages and balling them up into portlets. You end up with function fast. But, if you plan on doing that, why not just go with a PHP based site? About all that JSP will get you in this case would be some props at cocktail parties where you can get an easy 'wow' by tossing around the word Java a few times.
We want MVC and we want to enforce it. So I've decided on velocity for page design. With velocity I can give page designers the ability to work with active page content and remove the possibility that some slack-jaw might muck up my code-base by slapping in some ill concieved SQL. It also means that view policy is utterly divorced from controller mechanisms.
2006-09-06
2006-08-17
Programs that write programs
A new generation of software has begun to emerge. These are tools that take UML diagrams and transform them into code. Humans have been creating software now for nearly a generation. This wisdom has begun to distill itself into "Design Patterns" and into a higher order of meta-thinking about systems design.
The idea behind UML to Code tools is simple enough and the progression follows a path something like this:
In the bad old days you had to toggle in programs one bit at a time. Then there were switch boards allowing bytes at a time to be toggled in. Programming involved all sorts of unrelated skills such as knowing how to toggle in code from 3x5 cards. There were no languages beyond binary.
Later the binary got covered over in a veneer of language that could be assembled into binary. Life was better. When higher order languages were introduced that could translate formulas into assembler and then binary there was some resistance. Surely, there was no way that these compilers could produce binary that was as good as the binary created by a talented human programmer? In time this argument was forgotten and the age of Programming Languages dawned on the planet.
After thrashing around for a while on how to best represent programmer thought in programmer language some defacto paradigms started to evolve as the ways that various classifications of human minds work began to be understood. In time we began to see common problem solving patterns. These patterns eventually began to see formalized expression in an implementation independent way.
Just as assembler was more expressive than binary, the programming language more expressive than assembler, wouldn't this meta formalization be even more expressive? And, shouldn't it be possible, once they were formalized, to transform these diagrams into programming language representations that would find their way all the way down to binary?
This is the early dawning of that next phase of software developments evolution. We have had some faltering starts at it. Several commercial products have tried to add a "visual" component to their development tools but these miss the power of the meta-language called UML. Just as it took time for the first compilers to get "good enough" to over come the argument that no "code generator" could do as well as a human programmer, these tools face that problem too.
In time they hold great promise of freeing the programmer from unnecessary minutiae allowing them to build bigger bolder castles in the air.
The idea behind UML to Code tools is simple enough and the progression follows a path something like this:
In the bad old days you had to toggle in programs one bit at a time. Then there were switch boards allowing bytes at a time to be toggled in. Programming involved all sorts of unrelated skills such as knowing how to toggle in code from 3x5 cards. There were no languages beyond binary.
Later the binary got covered over in a veneer of language that could be assembled into binary. Life was better. When higher order languages were introduced that could translate formulas into assembler and then binary there was some resistance. Surely, there was no way that these compilers could produce binary that was as good as the binary created by a talented human programmer? In time this argument was forgotten and the age of Programming Languages dawned on the planet.
After thrashing around for a while on how to best represent programmer thought in programmer language some defacto paradigms started to evolve as the ways that various classifications of human minds work began to be understood. In time we began to see common problem solving patterns. These patterns eventually began to see formalized expression in an implementation independent way.
Just as assembler was more expressive than binary, the programming language more expressive than assembler, wouldn't this meta formalization be even more expressive? And, shouldn't it be possible, once they were formalized, to transform these diagrams into programming language representations that would find their way all the way down to binary?
This is the early dawning of that next phase of software developments evolution. We have had some faltering starts at it. Several commercial products have tried to add a "visual" component to their development tools but these miss the power of the meta-language called UML. Just as it took time for the first compilers to get "good enough" to over come the argument that no "code generator" could do as well as a human programmer, these tools face that problem too.
In time they hold great promise of freeing the programmer from unnecessary minutiae allowing them to build bigger bolder castles in the air.
2006-08-14
Things you never want to hear...
... your doctor say:
What the heck is that?
I didn't even know that was possible.
oops.
Oh well.
I'm thinking Arby's!
2006-08-08
Castles in the Air
If the poet creates castles in the air then the programmer creates castles in the air made of air. The programmer works in a rarefied space where the interplay of thought and language are the only limitations.
2006-07-27
Too Abstract
Most days I get the feeling that nobody understands what I'm talking about.
This is the problem with being too abstract. Many people have difficulty with abstract models of behavior and being a person that spends nearly all my time working with abstract models I sometimes find myself in the position of speaking Greek to a Latin audience. The Greek is appreciated by the Latins but not really all that well understood.
When we as programmers communicate software designs or the impact of new technologies we often will get those blank stares. The way to help mitigate those blank stares is to use concrete stories. Stories with people's names that contain actions that people really need to perform. If you can say: "Now when Joe wants to check his mail he can do so from anywhere that has an internet connection." instead of "This is a web enabled mail client." That's more words but easier for lay-users to understand.
For example instead of "This Ajax mail client will allow our end users to use mash-ups of corporate data in email." you could say, "Now when you check your mail and hover over an order number with your mouse a little bubble will show the order details. You can click in the bubble to get other data on that order." The second example is wordy but hopefully easier to get people's minds around.
When we teach sales people we teach them to put emphasis on benefits not features. In our example the "Ajax Mash-up" is a feature but the "hover over an Order number for quicker access to details" is a benefit. Sometimes our jobs as technologists are more about sales than about technology. Instead of booking orders we are trying to buy mind-share for our thoughts and ideas.
This is the problem with being too abstract. Many people have difficulty with abstract models of behavior and being a person that spends nearly all my time working with abstract models I sometimes find myself in the position of speaking Greek to a Latin audience. The Greek is appreciated by the Latins but not really all that well understood.
When we as programmers communicate software designs or the impact of new technologies we often will get those blank stares. The way to help mitigate those blank stares is to use concrete stories. Stories with people's names that contain actions that people really need to perform. If you can say: "Now when Joe wants to check his mail he can do so from anywhere that has an internet connection." instead of "This is a web enabled mail client." That's more words but easier for lay-users to understand.
For example instead of "This Ajax mail client will allow our end users to use mash-ups of corporate data in email." you could say, "Now when you check your mail and hover over an order number with your mouse a little bubble will show the order details. You can click in the bubble to get other data on that order." The second example is wordy but hopefully easier to get people's minds around.
When we teach sales people we teach them to put emphasis on benefits not features. In our example the "Ajax Mash-up" is a feature but the "hover over an Order number for quicker access to details" is a benefit. Sometimes our jobs as technologists are more about sales than about technology. Instead of booking orders we are trying to buy mind-share for our thoughts and ideas.
Model Driven Architecture
When building software a software engineer or other system design expert creates a shared mental model of the problem space. Boxes and stick-figures or intricate flow diagrams detailing the space to be explored find their way into documentation. Descriptions made for implementation people to work out finer details.
What if the documentation was the software?
In theory the process of creating software is all design. Design progresses from large sketches to finer and finer detail. The finest of details yielding code that is finally compiled into machine language. Each refinement is fueled by human effort. Each finer detail of documentation yielding an artifact that exists merely to be consumed by the next stage in the chain.
Model Driven Architecture is an attempt to skip many of these steps and skip as closely as possible to the code that is ready to be transformed. UML diagrams drive a series of transformation engines to "compile" drawings into code. The resultant code may or may not be ready for use but it is a many great steps down the chain to complete. All of this hinging on the pretext that the programmer builds a mental model that is then transformed into code.
What if the documentation was the software?
In theory the process of creating software is all design. Design progresses from large sketches to finer and finer detail. The finest of details yielding code that is finally compiled into machine language. Each refinement is fueled by human effort. Each finer detail of documentation yielding an artifact that exists merely to be consumed by the next stage in the chain.
Model Driven Architecture is an attempt to skip many of these steps and skip as closely as possible to the code that is ready to be transformed. UML diagrams drive a series of transformation engines to "compile" drawings into code. The resultant code may or may not be ready for use but it is a many great steps down the chain to complete. All of this hinging on the pretext that the programmer builds a mental model that is then transformed into code.
2006-07-20
Who can program?
A there is a paper written at the School of Computing at Middlesex University in the UK that addresses the issue of programming aptitude. The authors of this paper (Dehnadi and Bornat) have devised a test that they claim can separate out who may learn to program well and who will not. This fits well with my earlier observation that: "Anyone can program, only some people will learn to program well."
The working title "The camel has two humps" refers to a phenomenon that even I have noticed when teaching programming. One group will do well, and the other will do poorly, each group will have their own bell producing a two humped grade curve. The break through for this paper is creating a test that separates out who is part of which group. You can then reliably plot two independent bell curves based on results.
The differentiating factor between our two populations of programmers? Mental models.
The tests devised by Dehnadi and Bornat determine who is creating mental models and using them. It turns out that it is not nearly so important that the student use a correct mental model as that they know how to create and use a mental model at all. So I have to ask, how does one learn to use mental models? Why do some people use them well and others do not?
The working title "The camel has two humps" refers to a phenomenon that even I have noticed when teaching programming. One group will do well, and the other will do poorly, each group will have their own bell producing a two humped grade curve. The break through for this paper is creating a test that separates out who is part of which group. You can then reliably plot two independent bell curves based on results.
The differentiating factor between our two populations of programmers? Mental models.
The tests devised by Dehnadi and Bornat determine who is creating mental models and using them. It turns out that it is not nearly so important that the student use a correct mental model as that they know how to create and use a mental model at all. So I have to ask, how does one learn to use mental models? Why do some people use them well and others do not?
Subscribe to:
Posts (Atom)