Gwadanina Rss » JRoller » March 14, 2008

JRoller (8 unread)

EclipseCon starts next Monday

Posted: March 14, 2008, 7:03pm CET by Andres Almiray

EclipseCon 2008 is almost upon us, starting next Monday. If you are in the Bay Area already it is recommended to pick up your badge on Sunday to avoid long lines and also to be ready for those early tutorials that start at 8 AM. If you are attending and consider yourself a Groovy enthusiast or just want to know what the deal is behind the language-with-a-cool-name please come by Room 206 on Tuesday, 16:30, for a brief Introduction to Groovy or just to say hi. See you there!

Keep on Groovying!
See you Monday at EclipseCON

Posted: March 14, 2008, 6:15pm CET by Carlos Sanchez

Monday 8:00 Maven, Eclipse and OSGi working together tutorial

Wednesday 16:50 Q4E, Maven integration for Eclipse short talk
Show up or find me at the bar
Design for Feature Rotation

Posted: March 14, 2008, 3:24pm CET by Rob Williams

Every site ends up having features. On a news site, it‘s top stories, most discussed, highest rated. In a store, it‘s the things that are new, best selling, etc.

A while back I made some feature classes that were generic. There were two big ideas in the approach: 1. the feature manager just held on to keys, which is generally anathema, especially in the anti-anemic age of ORM, but there is a reason for it: the feature manager is not a cache, it is just a list, and when it is asked for a feature or a bunch of them, it loops through its keys calling read on the injected Repository. Since we have a Decorator(should be a hyphen here, but the Textism parser is so stupid, it interpreted it as a strikethrough)based set of CachedRepository classes, that's an easy thing to arrange. (Of course, the person on the team who first tried to use the classes I wrote thought they were stupid for reading the item each time (I would prescribe some revisions to the JD to prevent this in the future, but the likelihood of that being read by implementors is a single ticket in a multi-state powerball). Of course, the other design pattern in this initial buildout was Strategy: we can just rotate through a list, order them, etc. (this is done through a selector).

So now I am cracking open the features again to look at how to address the question of topicality, in other words, what are the top-selling items in books v. music, etc. The idea of defining each of these things with some little filter key in the Spring files seems inane and useless. Thinking about the problem, a few things pop out:

Creational Dimension In my present case there are two dimensions: a type field (what type of post are we fetching), and categories. I started to imagine a kind of agent model where nodes could literally be spawned at runtime on combinations of type and category that the system didn't even know about at startup. In a scenario like this, there would have to be some interface-based wiring of the sources (Repositories), and each fill operation would be Interpretered into a request for items from a Repo. This would support the idea that an admin could configure a new topic by creating a new category, and then drop the feature rotation portlet onto the page, and bingo, it would work.

Countering this is the realization that this is simple, multi-dimensional data. One could imagine getting everything in one query, and then just divvying it up by dimension. The advantage of this approach is that there are fewer trips to the db, but that probably doesn‘t mean much, as we are going to cache these things once they are loaded. Which brings up the last issue: when rotating features, you cannot have blanks: if the rotator fits 10 products, there have to be 10 products, and if you are going to do topical filtering, you can‘t mix those topics. So the issue comes up how do we guarantee that we will get something? Well, that brings up the last thing: there is another hidden dimension here: time. For things like most viewed or highest rated, it makes sense to see things as receding on the time dimension.

One approach that seems to be easy to rule out is to fetch a whole ton of things and then just skip over what you don‘t want, based on the prevailing filter. One of the reasons for this is that the dimensional data must be inspected each time, furthermore, if you use a distributed cache, you will end up shuttling things around that are not being used.
OOP and Algorithms

Posted: March 14, 2008, 1:47am CET by Bob Foster

Some OOP practitioners seem to have painted themselves into a corner from which they can hardly admit the existence of algorithms. If all objects are domain objects and all states hidden in domain classes, there can arise an almost puritanical resistance to discussing classes that are applicable across domains, much less behaviors applicable across classes. For example, some Java developers will not allow a collection class as a method argument or result because a collection is not a domain object. This cuts them adrift from the mainstream of computer science, in which algorithms and data structures are most interesting when they are most generally applicable. This is not a straw man I dreamed up just to knock. I have heard developers say they see no benefit to computer science, as it has so little to do with their daily lives.
How cool is JMX?

Posted: March 14, 2008, 1:03am CET by Jess Balint

I've been a fan of JMX for quite a long time. I find it very convenient how it exposes a fairly comprehensive set of capabilities in such a generic way.
I was helping a friend out with a JMS issue and wanted to reproduce it locally. I grabbed the latest copy of ActiveMQ and booted it up. After queuing a few messages, I wanted to check the status and discovered the handy web interface (accessed at http://localhost:8161/admin). This shows the different queues and how many messages are currently in each one.
I started to dig further and saw the page about ActiveMQ's JMX support. After changing two lines in the config file to enable JMX and rebooting, I was able to connect with jconsole. Greeted with a simple interface that allowed me to check the queue sizes and even send text messages was quite pleasing.
I think this a truly unique capability of the Java platform and would love to see more applications take advantage of it.
UCDetector: Unnecessary Code Detector

Posted: March 14, 2008, 12:37am CET by raveman

http://www.ucdetector.org/
Consumer JRE needs tester

Posted: March 14, 2008, 12:28am CET by Anthony Goubard

This last month I‘ve been tested what will be the upcoming Java.
This consumer JRE will be installed on millions of computers so it‘s our jobs as Java
developers to make sure it works properly.
The feedback goes in the Java.net forums and I was surprised that so few people tested it.
I tested it, found some bugs, reported them and the dedicated team fixed them.
You too can help improve the next Java release!

[https:]
Checkstyle fast facts

Posted: March 14, 2008, 12:14am CET by Oliver Burn

From [www.ohloh.net].

Fast Facts:

← March 13 (7 items) March 15 (11 items) →

Gwadanina Rss » JRoller » March 14, 2008

Feeds

JRoller (8 unread)

Posted: March 14, 2008, 7:03pm CET by Andres Almiray

Posted: March 14, 2008, 6:15pm CET by Carlos Sanchez

Posted: March 14, 2008, 3:24pm CET by Rob Williams

Posted: March 14, 2008, 1:47am CET by Bob Foster

Posted: March 14, 2008, 1:03am CET by Jess Balint

Posted: March 14, 2008, 12:37am CET by raveman

Posted: March 14, 2008, 12:28am CET by Anthony Goubard

Posted: March 14, 2008, 12:14am CET by Oliver Burn

JRoller (8 unread)