alek blogs

Resign Patterns: Real Design Patterns?

This is look on dark side of Design Patterns: Resign Patterns [local copy]:
Ailments of Unsuitable Project-Disoriented Software by Michael Duell.

Here is a short excerpt:

(...)
3.1 Chain of Possibilities

The Chain of Possibilities Pattern is evident in big, poorly
documented modules. Nobody is sure of the full extent of its
functionality, but the possibilities seem endless. Also known as
Non-Deterministic.

3.2 Commando

The Commando Pattern is used to get in and out quick, and get the job
done. This pattern can break any encapsulation to accomplish its
mission. It takes no prisoners.

3.3 Intersperser

The Intersperser Pattern scatters pieces of functionality throughout a
system, making a function impossible to test, modify, or understand.
(...)

created Mon July 7, 2003 5:12 PM EST [2003/7/7 17:12 EST] permalink

Fire And Motion

So instead of writing code i read email and surf web not unlike Joel. He captured specifics and concerns about programmers productivity quite well in Fire And Motion.

However what really struck me was this piece of his experience:

(...) When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. (...)

When I had a summer internship in France lots of years ago there was this guy who was apparently very good. He was very good but he did not show up to work however as he did exactly what they wanted at the end of the internship so they really loved him...

My personal theory is that surfing web, emailing or in general reading and thinking is what really matters for programming. Writing code is just an end result, an artifact produced to capture what was created in days of hard work of thinking that may have looked like doing nothing but were required to accumulate into written code.

created Fri July 11, 2003 6:12 PM EST [2003/7/11 18:12 EST] permalink

Time is the scarcest resource

Time is the scariest resource and it should be treated as the most important factor when considering any task. From interview with Jim Gray:

(...) You see this today. Two groups start; one group uses an easy-to-use system, and another uses a not-so-easy-to-use system. The first group gets done first, and the competition is over. The winners move forward and the other guys go home.

That situation is now happening in the Web services space. People who have better tools win.(...)

However it is also important to not simplify the problem we try to solve or we have something very easy-to-use but useless ...

He also talks about phenomenon of scale when doing software development and I find this estimate quite interesting:

David Patterson: What do you think is happening with databases in terms of open source? What is the Linux of databases?

Jim Gray: I think it's exciting. Very small teams built the early database systems. A small team at Oracle built the original Oracle, and there were small teams at Informix, Ingress, Sybase, and IBM.

Twenty-five people can do a pretty full-blown system, and ship it, and support it, and get manuals written, and test it. (...)

Now the trick is to be where action is and to be part of such team :-)

created Sat July 12, 2003 5:43 PM EST [2003/7/12 17:43 EST] permalink

TRANSFORM-INTO-A-GEEK FORMULA

How to become a geek effectively? Sisi Liu has now a simple answer to question . No need even for the pill (and this pill was invented before Matrix was it?).

This works kind of opposite to ACME Nerd Suppressant [cached]

Now it doe snot work on men, does it?

created Tue July 15, 2003 4:25 PM EST [2003/7/15 16:25 EST] permalink

The Last Of the Great Indoorsmen?

Another species identified for extinction classifed and identified by Dave Johnson:

(...)This is all great and the only thing really causing any stress is the ProJSP book, but I don't think I'll have to miss a day at the beach to wrap up my changes to my two chapters. My Dad and I have our laptops setup in the kitchen and the only thing that really interferes with my works is the constant derision and calls of "hey nerd-boys" and "get a life" from our wives. This really doesn't bother me at all. I always arrange to bring a laptop along on vacation. I'm not like Raible. My idea of a vacation is tinkering with all things digital, which, coincidentally, is also my idea of work. I'm the last of the great indoorsmen.(...)

It can not be- I would consider myself another one - and I suspect there is more ...

created Tue July 15, 2003 6:25 PM EST [2003/7/15 18:25 EST] permalink

microBlog improved

microBlog improved: finally resolved generating and linking pages for multiple categories and fixed category specific RSS feeds.

created Tue July 15, 2003 7:25 PM EST [2003/7/15 19:25 EST] permalink

Space Invasion in Newport, RI

This was fantastic day and seeing current state-of-the art kites floating over Newport is not much different experience than seeing UFOs. This time we made amazing number wrong turns but overcam all stumbling including longer-than-expected cliff walk almost during night and arrived safely to be able to put photos online.

created Sun July 20, 2003 6:50 PM EST [2003/7/20 18:50 EST] permalink

Memex: futuristic device?

If idea has almost sixty years and it is till interesting then there must be something in it. That is certainly true about memex.

First motivation for memex from "As We May Think" by Vannevar Bush from July, 1945 (emphasize is mine):

(...) The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain. It has other characteristics, of course; trails that are not frequently followed are prone to fade, items are not fully permanent, memory is transitory. Yet the speed of action, the intricacy of trails, the detail of mental pictures, is awe-inspiring beyond all else in nature. (...)

So how such device would work? One organizing theme is about machine remembering and recalling anything that operator deems interesting:

(...) When the user is building a trail, he names it, inserts the name in his code book, and taps it out on his keyboard. Before him are the two items to be joined, projected onto adjacent viewing positions. At the bottom of each there are a number of blank code spaces, and a pointer is set to indicate one of these on each item. The user taps a single key, and the items are permanently joined. In each code space appears the code word. Out of view, but also in the code space, is inserted a set of dots for photocell viewing; and on each item these dots by their positions designate the index number of the other item. Thereafter, at any time, when one of these items is in view, the other can be instantly recalled merely by tapping a button below the corresponding code space. Moreover, when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly, by deflecting a lever like that used for turning the pages of a book. It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book. It is more than this, for any item can be joined into numerous trails. (...)

Finally what really matters is ability to organize, recall and share knowledge and that idea what was well captured in this example:

(...) The owner of the memex, let us say, is interested in the origin and properties of the bow and arrow. Specifically he is studying why the short Turkish bow was apparently superior to the English long bow in the skirmishes of the Crusades. He has dozens of possibly pertinent books and articles in his memex. First he runs through an encyclopedia, finds an interesting but sketchy article, leaves it projected. Next, in a history, he finds another pertinent item, and ties the two together. Thus he goes, building a trail of many items. Occasionally he inserts a comment of his own, either linking it into the main trail or joining it by a side trail to a particular item. When it becomes evident that the elastic properties of available materials had a great deal to do with the bow, he branches off on a side trail which takes him through textbooks on elasticity and tables of physical constants. He inserts a page of longhand analysis of his own. Thus he builds a trail of his interest through the maze of materials available to him.
(...) And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outraged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail. (...)

It seems that linking creates such trial and good search engine is tool to recall trails and now blogs are making easier to create trials but still this is long way to go ...

There are other tools that try to do this but so far I have not found yet one that works for me ... where is my Memex? so i start forgetting what i can easily recall:

(...) Presumably man's spirit should be elevated if he can better review his shady past and analyze more completely and objectively his present problems. He has built a civilization so complex that he needs to mechanize his records more fully if he is to push his experiment to its logical conclusion and not merely become bogged down part way there by overtaxing his limited memory. His excursions may be more enjoyable if he can reacquire the privilege of forgetting the manifold things he does not need to have immediately at hand, with some assurance that he can find them again if they prove important. (...)

created Sun July 20, 2003 7:08 PM EST [2003/7/20 19:8 EST] permalink

Xydra: easy way to add Web Services to your portal

Xydra is a library that uses servlet to provide XHTML based WSDL invoker. Xydra servlet takes WSDL with XML Schema complex types as input, generates XHTML form to allow user to fill content of input message, gathers submitted input values and converts form name-value pairs into XML message that is sent it to Web Service and then finally displays result message.

One could ask: there are other WSDL invokers so what makes Xydra unique? Here is couple reasons:

• Xydra has pluggable data model and currently two backend to represent form and XML message content One is traditional name-value pairs that are structured into tree (called TreePath) and second that is based on Protege engine to use ontology describing web service to allow more reach constraints and relationship validation (called OntoBrew).
• It is very easy to customize Xydra look and feel: just save auto-generated XHTML page, modify it to your needs and tell Xydra to use this XHTML page as template. What makes it really easy is that template is a regular XHTML page that is used by Xydra processing engine (unsurprisingly called Diesel) to annotate it with runtime information.
• Xydra support complex types and generate nice XHTML form UI for arbitrarily nested XHTML forms.
• You get source code so you can improve it :-)

Sample installation is available online to test drive Xydra. It is open source so anybody can play with it, improve it, and give us feedback, patches are gladly accepted, we may even fix some bugs when reported (good bug report that contains all information necessary to reproduce problem and/or unit test greatly increases chances of getting problem fixed ...)

created Sun July 27, 2003 11:55 PM EST [2003/7/27 23:55 EST] permalink

Comparing XB1 to JDOM ...

This is mini review of "A Design Review of JDOM (A Conversation with Elliotte Rusty Harold, Part III)".

Let see how Xml Pull Builder a.k.a. XB1 (for more details on XB1 see its home page) compares to JDOM based on points raised in article.

A Short History of JDOM

Before we do this few word about XB1. XmlPull Builder Version 1 a.k.a. XB1 is lightweight document object model to represent XML tree that is implemented on to Common API for XML Pull Parsing and alpha version is in XPP3/MXP1.

JDOM Offers Many Convenience Methods

XB1 is currently rather modest API and do not have lot of methods (except for obvious overloading of methods) and that makes API quite simple (at least for now).

JDOM Allows Malformed Documents

XB1 implementation also allows creation of malformed documents or let put it this way: the implementation does not do extensive checks but XB1 API allows implementations that will do those checks (XB1 API is composed of interfaces). BTW: example with control characters is not good as XML allows to have control characters but escaped as numerical entities AFAIR ...

JDOM Ignores Setter Method Conventions

I do not see problem here: JDOM is not Java Bean and chaining methods may be sometimes convenient (but should not be overused). This looks like rather weak complaint ...

JDOM Uses Java Collections

XB1 goes one step even further and it uses Generics for even more natural iterators than mentioned NodeList (currently moving to use future java.lang SimpleIterator interface so idiomatic for(XmlElement el: node.elements()) will work in JDK 1.5) .

JDOM Uses Too Many Checked Exceptions

XB1 has only one exception (at least for now) and it is runtime exception for all reasons mentioned in the article and i woould add one more reason: RuntimeException makes it easier to integrate XB1 into existing code.

Will JDOM Remain Class-Based?

I agree that interface based API is more versatile as it allows to abstract form implementation and allow creating XML tree models directly from other data sources that XML event stream from parser (like databases)

Conclusion

I was disappointed that XPath integration (and good performance of it) was not mentioned. Also I would like to see some tests that compared memory footprint and how easy is to build partial tree: this is very easy with XML pull parsing but quite difficult with push parsing (in SAX it requires provide way to overwrite endElement() callback and in general is as much fun as writing SOAP deserializer with SAX). And as far as future of XML Tree APIs: I would like to see how easy is to annotate XML infoset items with additional information (needs for it emerges with data bindings and PSVI)

But after all what makes and breaks APIs is how programmers feel about them, and I feel good about XB1 when I am using it (nothing to do with the fact that I am author of it of course ..)

created Wed July 30, 2003 8:06 PM EST [2003/7/30 20:6 EST] permalink

This blog is about:
XML, Java, and everything else (or nothing ..)

Find more about
blog author

Blogroll:
Sam Ruby
Russell Beattie
Diego Doval
Joel on Software
and some (almost) harmless entertainment: The BileBlog

Projects::
MicroLogger
Xydra
WSIF
XmlPull API
XPP3/MXP1
XSOAP
XMessages

RSS
0.92 [validate]
2.0 [validate]

Filter Entries:
Life
Java
XML
Computing
Web Services