Frederic Barachant's Blog: Programming Archives

Swash already had part of its code split to a seperate project, one with a pretty infamous name: preciseInternalDate.

Swash will see an other split: splines!

While i was finishing the splines part of swash, i said to myself that this could easily be extracted to an external package that could be useful to other projects than swash. In fact, i have other projects that would benefit from it, so even within my own projects that would be fine.
Then i thought of other parts that could be useful and could be extracted. But as i was thinking deeper on what could be externalized and reused i wondered about the burden of reuse.

How much does it burden to be smart and fancy? When is it wrong to do it right?

I mean, i -more than once- grumbled over the fact that i needed activation.jar to use javaMail. What if to use one API you suddenly need to add six or eight jars? Swash actually has two jars, soon three. We are all taught the wonderful advantages of object orientation like ease of reuse, but even if not pushed to an extreme, i see it as a burden. Is it acceptable? I don't know.

Next thing i could export to an external lib is interpolation, but as i will soon support java3D canvases within my rendering pipeline, its jars will become somewhat a dependency of swash. (but no, i certainly do not intend to see everyone forced to install java3D. Not having it will simply not render that part of the graph). Only those two things add at least 4 jars (and native libs for java3d)
Supporting inclusion of svg will also add its own pack of jars.

Sure, JSR-277 could solve the problem and make it transparent for developers to include anything but it's not there. And until it is really everywhere and used by everyone -which imho means years- there will be a "legacy mode" to support.

On an other hand, having no real central repository and no real way to handle dependencies makes it a harder decision to whether i should include the whole bang or handle their inexistence gracefully.
Solution number two might turn in a coding nightmare, while solution number one will certainly add unwanted burden to swash.

Bubonic plague or cholera?
What could be the jar count to choose between one or the other?

Does it have to be nice?

Posted by pepe on March 19, 2007 at 05:02 AM | Permalink | Comments (2)

As a programmer and somewhat graphist, i tend to make things nice, or at least i take time to work a bit on presentation.
But should i?

It is always better, in my opinion, to present even the slightest example with a little image but, when is that presentation distracting from the technological point of view, or in the opposite when is the presentation hiding flaws of an API?
Is it better to present something in a basic form, so that people can concentrate on what you say, or impress them with a shiny-blinking demo, then let them enter the technical part? How to be sure that they will not draw false conclusions from one or other kind of presentation?

Last week, i did read the petstore 2.0 article. Then, i went to the live demo to check the result.
To be honest, i first thought that there was a css problem, that it did not load and what i was watching was the 'pure' version of the website. So, i opened firebug (fabulous firefox extention, by the way) and checked for that. Unfortunatly, there was nothing wrong with the demo code.
Then, well, i thought that the demo was plain ugly and i really did not understand why they left such a thing online, that ought to be used as an example for people application. Examples ought to give people some kind of envy. Envy to do the same, envy to do better, envy to use. That example just gave me a weird sensation of a cheap amateur puzzle.

But, maybe i am wrong which is why i am questionning. I did read the article and did not even took care to look at the included screenshots, so it seems obvious that non technical part did not bother me.

Is shine needed? When does it blind, or when does it attract? Does no shine repel?

Powered by
Movable Type 3.01D

java.net RSS Feeds