October 2002 Archives

I love CiteSeer, but I need some help. I need something, maybe a bookmarklet, that can help me organize my various findings while browsing CiteSeer. Accumulating bookmarks in mozilla isn't useful and makes it difficult to share my findings. I basically want to be able to have a blog that's centered around a research topic.

In addition to possibly adding to a bloglike recently added page, I'd want to be able to index the page multiple ways (ie, by topic, by project, by date, etc...). Ultimately, it could scrape the CiteSeer page and download a .pdf or .ps to a local cache.

Surely there's a MovableType Perl hacker out there who has Copious Amounts of Free Time to hack something up. I think MT has most everything we'd need. Just need to sort of repurpose it.

Bonus points if it's WikiEnabled.

Well, I'm 29 today. Life is good. I have a wonderful wife and son, a house full of pets who I think appreciate me and extremely enjoyable work. Though, I could always use more books if anyone, ahem, wants to help me celebrate.

JSR 121, the Application Isolation API specification looks kinda cool. Unlike many JSRs, this one at least has a fair number of public documents at this stage in the game (scroll down).

This API provides a uniform mechanism for managing Java application life cycles that are isolated from each other, at least with respect to object reachability, but that can potentially share underlying implementation resources. It provides a means of deploying new Java implementation features that enable and enhance scalability while providing an alternative to ad hoc control schemes.

The Avalon Project over at Jakarta has blown my socks off over the past 48 hours. It is a server-side hacker's wet dream.

I've always enjoyed the idea of component-oriented architectures. Unfortunately, most component frameworks decided to assume network-accessible distributed components. So, I always ended up avoiding them, using normal JavaBeans and hacking in my own lifecycle and broker patterns. Never the same way twice.

Jason van Zyl kept promoting Avalon to me (plus, I'm going to have to use it on the Day Job(tm) anyhow), so I finally dug in. I decided to make werkflow be Avalon-enabled. Having Avalon force me to think about components has definitely helped the design and extensibility. The configuration mechanism, while a little wacky, is certainly nice. And I'm finally understanding the true benefit of inversion of control.

So, if you want flexibility and life-cycle management in a component architecture framework that doesn't assume you want distributed object, definitely check out avalon.

As many of you guys know, The Werken Company as a hopefully-viable commercial venture, is pretty new. You may also be familiar with our various open-source projects.

We've had the extremely good luck to have some of our development sponsored by Zenplex, a company that uses, supports and produces open-source software.

So, I'm wondering how many of you guys know you have a need for a rules engine, or a workflow engine, or whatever else we're churning out here at Werken. How many of you have done any sort of cost/benefit analysis comparing building in-house, licensing a commercial offering, or supporting an open-source project?

Ideally, I'd like to have our open-source projects treated as sort of a venture fund. Many organizations with a need for rules, workflow, or whatnot could contribute dollars towards the development. Sure, development continues without sponsors, but sponsors get their use-cases considered quicker, their bugs fixed faster, and their voices heard more often in general.

I know the now-defunct SourceXchange attempted something similar, but lacked the coherent organization of developers by instead simply hooking random developers with random sponsors. I think we're different as we have a history, code you can inspect, projects that are already underway, and a developer headcount greater than one (there's three of us werkers, now).

Would your organization be interested in sharing the costs of development of these infrastructure pieces with others and support the open-source community at the same time?

Notes on Postmodern Programming is a nice paper to make you think about what it is we're doing.

These notes have the status of letters written to ourselves: we wrote them down because, without doing so, we found ourselves making up new arguments over and over again. When reading what we had written, we were always too satisfied. For one thing, we felt they suffered from a marked silence as to what postmoderism actually is. Yet, we will not try to define postmodernism, first because a complete description of postmodernism in general would be too large for the paper, but secondly (and more importantly) because an understanding of postmodern programming is precisely what we are working towards. Very few programmers tend to see their (sometimes rather general) difficulties as the core of the subject and as a result there is a widely held consensus as to what programming is really about. If these notes prove to be a source of recognition or to give you the appreciation that we have simply written down what you already know about the programmer's trade, some of our goals will have been reached.

via slashdot.

Brett Morgan mentioned ny beep4j project but complained about the broken domain-name. The problem is that SourceForge is almost complete crap and can't handle more than a single vhost entry, apparently. This has been a probelm for a long time and has yet to be fixed. Hence, my slow migration of my projects away from SourceForge.

Brett.... You don't allow comments on your blog?

Mike hits the nail on the head with this one, while thinking about mock objects.

Rule 2 is especially interesting, because mock testing forces you to think of your code as an API - as you now have two 'clients' (your other code, and your tests). I think in the end it will lead to a much nicer architecture.

I think this is the absolutely #1 reason there is so much crappy code in the world. Folks, for some reason, view APIs as being in the realm of frameworks, libraries and other infrastructure, where it's not something to consider while writing an application. Though, we must not forget that the public, protected, private and in java's case, the wacky no keyword, but package protected all force us to think of several different APIs.

private The API used only within your class. It can be a very informal API, as as wicked as it may be, absolutely no one else has to suffer it. Feel free to live in your own filth.

package protected You're opening yourself up and telling your close friends some of your darkest secrets. These are things you don't necessarily want to whole world to know, but you should at least make them presentable to others.

protected This one is a bit weird. You're still sharing with your friends, but now, any moron who walks up and decides that you are his god has certain access to you.

public Most of the world cares about this, and you don't want to frighten, confuse or scare them. Simplicity is good. Interfaces, interfaces, interfaces.

Anyhow, yes, I agree, Mike. People who don't really consider their classes to be ultra-small APIs even to be used by other classes in the same package, they are basically just writing (possibly poor) procedural code glommed onto an object.

Ick.

James Strachan continues the JCP discussion, regarding his experience with JCACHE.

I totally agree with Cameron on this. JSRs should be developed in the open. Anyone should be able to comment on JSRs, while they are still under development and see the discussions that their comments cause. Right now any comments you send to a JSR from your perspective typically just go into a black hole.

I'm on quite a few JSRs, including the JCache JSR (and developed the first non-Oracle JCache implementation at my employer, SpiritSoft). I think its very sad that JSRs don't operate in the public.

Sun's reasoning behind this is that typically various companies on the expert group need to give away details of their intellectual property and so only want to do this in private amonst other people who have also signed NDAs. This NDA issue is a real problem in big business, but then maybe this highlights that standards should mostly be created by individuals, in a totally open manner (like most open source projects) rather than being vehicles for big business to gain competitive advantage.

I've often wondered if a new standards body could form, following the Apache style guidelines to running open source projects, where standards are created in an open manner using a meritocracy.

My only two direct experiences with the JCP were...

1. The JDOM JSR (102, I think). Pretty much developed around the refence implementation (JDOM) and in the open on the jdom-interest list. But, I'm annoyed that it isn't very clear to most people that JCP is merely a process and not necessarilyi some form of blessing form Sun. And as far as processes go, I think the JCP is a pretty bad one for all the reasons Strachan and others have outlined. With JDOM having a JSR, I've seen many folks assume that JDOM will become the officilal or sanctioned object model for XML. This is not the case, and if you read through the jdom-interest archives, you'll hear the founding members say as much.

   I was, for a while, a member of the JDOM expert group due to my contributions through the Jaxen XPath engine. Aside from adding some comments via jdom-interest, which anyone could do, I didn't really feel that special. The JDOM JSR is also probably one of the slowest moving on the JSR track.
   



2. As implementor of drools, I have an interest is JSR-94, the Java Rule Engine API. I had many many folks ask if drools would support JSR-94 even before it was publically available. It's a question that everyone asks and that no implementor can answer until actually able to judge the appropriateness of the JSR.

   I deemed JSR-94 to be inappropriate in its public-review form to give any effort towards making drools compliant.

   As requested during the public-review period, I compiled my comments and sent them to the comments address. I've heard absolutely nothing in response. I have no idea (and absolutely no faith) that JSR-94 will in any way be affected by my comments.
   

With a few exceptions, the JCP is most definitely a Cathedral and not a Bazaar. It's a cathedral behind a very tall, very thick hedge. Surrounded by a moat. With alligators and snakes.

As you might know, I've recently been working on a workflow/process engine known as werkflow. Some folks want to use it for large-scale business processes, some think it could drive UIs, and others think it might make a suitable EAI component.

I personally come from a resource planninng and scheduling background, of sorts. Workflow involves a lot of resource planning and scheduling but potentially on a different scale than I am used to. So, this is a call to all the readers out there...

I'm currently thinking that the workflow itself handles the planning aspects of activities to be performed. So, mostly it's a resource scheduling problem. Resource scheduling is NP-hard, but there are a ton of different heuristics that can be used. With werkflow, I'll at least have a pluggable scheduling framework, to allow for specialized scheduling algorithms. But, I'd really also like a general-purpose, tending towards real-time, scheduling engine to ship by default.

When dealing with longer scheduling horizons and activity execution times, we are afforded more time for complex scheduling. It's the short time horizon case that I'm unfamiliar with. Anyone out there have a favorite real-time algorithm? Ideally, it'd introduce very low overhead in a mostly contention-free environment. I'm thinking along the lines of werkflow being use to drive your typical web-app, where you have almost enough database connections, etc. Once we start scheduling trucks for cross-country hauls, I'm back on familiar ground.
So, anyone with any useful ideas or algorithm names I should plug into CiteSeer?

(Sorry folks, but I find problems like this infinitely more interesting that the RSS-Dialect-Of-The-Day or My-MVC-Framework-Is-Better-Than-Yours topics...)

For the longest time, the people who qualified as net legends was pretty small, and pretty much universally agreed upon. Sure, each group had their own legends, as the open-source community has ESR, RMS, or Bruce Perens The Original Author of The Open-Source Definition (yes, I think that's his full name). Others, like Knuth seem to rise above any particular community.

Now, with blogs and maturity of open-source organizations, it seems that communities are getting smaller and therefore it takes less to become a luminary within any particular community. Strangely, it seems that luminary status is somewhat transitive. Joe might be the luminary in the Froboz community, which only has 5 members, but he's respected by luminaries of other, much larger, communities. Sorta like the Senators from Rhode Island.

I recently found the java.blog community and pretty quickly established that Brett Morgan and Russel Beattie are people to listen to. I'm not a part of the RSS community, but I seem to understand that Sam Ruby and Dave Winer are at least making a lot of noise.

Over in jakarta, even that small community is fragmented. The maven community listens to Jason van Zyl (jvz) while, once again, the gump community looks to Sam I think. James Strachan (jstrachan) crosses several communities both in and out of jakarta.

One thing to note, is most luminaries tend to be known by their logins, initials, or some handle. A few are known by their whole names. I'm certain that RMS knows he's a net legend, but do all net legends recognize their status? Do they realize the power they throw around, necessarily, whenever they make an idle comment?

Sorry, no links, excerpts or references. Just random thoughts.

Maven ties together tools for better code management is an article by Jeff Linwood talking about some of the highlights of maven.

The Application of Petri Nets to Workflow Management - van der Aalst (ResearchIndex) is probably what I'd call the starting-point in your journey through CiteSeer to accumulate knowledge of Petri nets.

Brett Morgan had asked that I produce references to the papers I read to go from zero to Petri in 2 days.

Overall, W.M.P. van der Aalst seems to be the shinig light in the world of Petri nets for workflow systems.

For what it's worth, petridish supports coloured petrinets, but werkflow does not take advantage of them. Werkflow has exactly one colour of token flowing through the network: bare java.lang.Objects.

Anyhow, Brett and others, start with that paper and explore CiteSeer. Aalst is The Man.

(One of his papers was also recommended by a commentor).

Capability Maturity Model for Software, also known as SW-CMM is an assessment tool to measure a given methodology. I'm sure many of you guys know this. But, lots of folks writing for software development journals and HR staff writing help-wanted adverts apparently do not realize this.

I'm just tired of reading articles that describe the extremes of metholodies ranging from XP to CMM. XP is a process. CMM is a way to assess your implementation of your selected process. All processes, and even not-using-a-process can be considered 'CMM', though just CMM Level 0.

At my current gig, we're doing a pretty consistent SCRUM process. While it's a light-weight method that has produced very little paperwork, I think we could be assessed higher than level-0.

The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

Gartner grades the Web services standards really isn't all that insightful. But then again, the companies I've worked for who were Gartner clients were wasting money as far as I could tell. Buy a couple of your neighborhood gurus a few espressos and they'll give you an opinion as worthy as Gartner's.

Somewhat funny quote though...

Higher up the Web services stack, Perlstein gave BPEL4WS a Promising rating, and called it the "worst-named specification."

petridish: the petri net framework is yet-another BobProject(tm).

I'd originally planned on building werkflow using blissed, which is a finite-state-machine framework. But, then, a few folks chatted with me about Petri nets, and I did a lot of reading from CiteSeer. I have decided that yes, Petri nets are indeed the way to go.

Hence, the new project.

No release yet, but just trying to raise awareness, since workflow seems to be a somewhat hot meme these days.

I've seriously reduced the number of blogs I read in the past weeks, as the main topic of conversation has turned towards RSS and aggregation. While that's all well-and-good, it's really not something I want to read about in 12 places every day. I know there's a (r)evolution going on in the RSS world, but all of these blogs about blogging and aggregation just seem a tad masturabatory. When I pick up a newspaper, I'm pretty much hoping that it'll contain information aside from that about the printing industry. Likewise, I read blogs to learn about non-blog ideas. Sure, there's a certain sense in dog-fooding the experimental RSS technologies, but I'll stick to Russell, Strachan and other folks who don't feel the need to make RSS/Blogging 98% of the content on their blog.