Posted by Eitan
Fri, 17 Feb 2006 13:59:00 GMT
It's no secret that I have for a while now been a great fan of the NakedObjects framework.
Here are a few blog entries where I express opinions on software and software development that are congruent with its philosophy:
All the while I was slowly thinking about, slowly developing a system of my own, one that would embody my shaped, personal opinions on software development. I have built myself a chainsaw. A system with a user interface that is consistent.
This system now has a name: jMatter. It has a url, with documentation, screenshots, and more.
Rather than flaunt all of the goodies and features I put into this chainsaw, I would instead like to invite you to take a look. Follow the above link, read Chapter 1 (a total of four pages), and let me know what you think.
Sincerely,
Eitan Suez
Posted in Java, jMatter | no comments
Posted by Eitan
Wed, 15 Feb 2006 21:22:00 GMT
I think these should make for a nice extension to the existing Java 5
Annotation API:
From an Annotation, one should be able to navigate back to the programming element that it annotates.
For example, a method annotation clearly marked with a Target
of ElementType.METHOD cannot say getAnnotatedElement().getName(),
There are two problems here. The first is the lack of the
getAnnotatedElement() method
The second is the fact that an AnnotatedElement is too primitive
of an interface. You cannot actually invoke getName() on an
annotated element. I feel that there should exist a basic
ProgrammingElement implemented by or extended by all annotated
elements.
The default value for an annotated element should not be restricted
to a constant expression. Instead, the value should be a code block.
For example, let's assume that I want to annotate methods to
give them a caption. By default, the caption should be some
kind of derivation from the method name it is bound to.
That is,
class MyClass
{
@MyMethodAt(caption="The X Method")
public void method x()
{
// ..
}
}
and
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface MyMethodAt
{
public String caption()
default
{
return getAnnotatedElement().name(); // see [1]
}
}
As far as I know, this is currently not possible.
no comments
Posted by Eitan
Wed, 15 Feb 2006 15:57:00 GMT
I just read the Pragmatic Friday on QtRuby: coding Qt client applications with Ruby.
On the good side:
I believe toolkits such as KDE to be much richer in terms of numbers and variety of widgets when compared to Swing. This could save a developer a terrific amount of time.
It's also terrific to see that one doesn't have to code in C++ to actually employ this library. So, a real Kudos for QtRuby.
Two observations:
the signal/slot mechanism really does not utilize the strengths of the ruby language.
in rails, you can say:
before_filter :method_name
and in ruby in general, one can do all kinds of neat things with code blocks besides.
in javascript, one connects a signal to a slot like this:
button.onclick = method_name
then why on earth should i choose to do this instead:
connect(button, SIGNAL("onclick()"),
some_other_obj_ref, SLOT("method_name()"))
???
on the other hand, i do really like the choice of metaphor
used in qt: the metaphor of a signal. maybe it's because
i have some kind of background in electrical engineering,
but probably not. anyhow, i like it.
my initial feeling about qtruby is that the divide between
the c++ world of qt and the ruby language is not transparent;
one notices it. i wonder to what extent this might be an
issue when developing a full-fledged system.
so what i'm trying to say is that i'm not certain if
qt and ruby are exactly a *marriage made in heaven).
i'm not sure what the "best" solution is.
I qualify these comments with 'initial feelings,' and what I mean to imply is that I could [very well indeed] be completely wrong about this.
full-featured, cross platform widget libraries are not
exactly a dime a dozen, i understand. so yes, there's gtk
and there's qt, and there's swing, and there's swt. but
one can't magically say tomorrow, there'll be a ruby-native
widget library. i know some swing, and now just a little
tiny bit of qt. i don't know swt or gtk/glade at the moment.
so far, my scale gives more weight to java + swing over
ruby + qt, even if ruby holds a few language gems that are
absent in the java language. it's also nice to see that
java has been narrowing the gap with its language improvements
in v5; specifically: annotations and enumerations. i still
believe that java needs:
- a stronger, richer, cleaner, simpler metamodel (reflection),
and
- facilities in its syntax for making the use of that metamodel
completely transparent, like it is in smalltalk
Posted in Programming | no comments
Posted by Eitan
Wed, 15 Feb 2006 13:37:00 GMT
Today we're beginning to smell the coming of Java se 1.6 (Mustang). Feels like Spring's upon us.
Don't ask me why. Although it's been about eight months since I've moved to Ubuntu Linux, the first thought that came to my mind mind was the question: is MacOSX doomed to remain 1 to 1.5 versions behind with respect to Java SE?
My understanding is that Java 5 on the mac at the moment is in some kind of pseudo-beta mode with no promises being made as to when a final, "blessed" release will appear. Years ago (in the late ninetees, I believe it was) I went through the experience of working on a web ecommerce project implemented using Apple's WebObjects framework. I recall too clearly this nauseating feeling of desperation one has when they know there's a problem or a bug in the framework that directly affects their project, combined with knowing that the resolution of the problem or bug is totally beyond their control.
To those of you out there who've chosen to run MacOSX, I'll say this once: I don't want to hear you complaining. If you want Java SE 6, and on time, it'll be there waiting for you on The People's OS.
no comments
Posted by Eitan
Wed, 08 Feb 2006 13:52:00 GMT
As I review and reference the Pragmatic Programmers' Agile Development with Rails book, I am increasingly convinced that any developer, group of developers, or publisher would be hard-pressed to produce a better book on the topic.
My wager is that the only book that will supplant Agile Development with Rails will be the second edition of Agile Development with Rails.
no comments
Posted by Eitan
Sat, 04 Feb 2006 17:16:00 GMT
Over the last year, here and there when I've had an idea or a little time I've
changed something or added a feature to ashkelon. Much time has passed and
I hadn't cut a release. For a while I really wanted to finish idea x or
feature y "before making another release."
That was a bad idea. Yesterday I decided that was enough. It'd been way
too long since I'd last published a release. I spent a few hours updating
the documentation, testing the release, updating the documentation again,
testing the release again until I was satisfied.
Finally, version 0.9 is out.
Sure, a number of features are only half
finished, but at least others can play with them. I mean they've been
in CVS for a while. But few bother to get that close to a project,
I admit.
Just because I'm not spending much time developing ashkelon does not mean
that I'm not using it. For my purposes, ashkelon has been feature complete
since 2001, since before I even considered open-sourcing it.
I use it on a regular basis when I code and have
been doing so for five years now. That's an awful long time. People
should know when to give up. I think this five-year mark is a sign that
if this tool has not gotten any traction by now, it probably never
will.
What saddens me the most is that even the idea itself has met failure.
As far as I know people are ignorant of the idea, the notion that a better
system for api documentation is a database application. In the ruby
world we've yet to see rdoc implemented as a rails app. Maybe some
day someone will write one.
no comments
Posted by Eitan
Sat, 04 Feb 2006 16:53:00 GMT
Who said Linux was too hard? My 3-yr old son, Arik,
has been running Ubuntu on his laptop since December.
He's a very happy user. Every once in a while he'll
ask me to help him figure out why something's not
working right, but most of the time, he works alone.
He sits at his ubuntu desktop, and can launch a
variety of games, including GCompris, SuperTux,
Tux Racer, Tux Kart, Slune, and many others.
I'm particularly
proud of these facts:
over a few weeks, he's gotten as good as me
(actually in some ways better than me) at
SuperTux. that's no mean feat.
he recently figured out Frozen-Bubble
he recently figured out SolarWolf, a most
addictive and wonderful games, though difficult
for really young people.
he's a whiz with the arrow keys
he doesn't know how to read but he's got the
entire SuperTux menu hierarchy figured out.
He can start a game, pick levels, pause a game,
exit out of one level and go to another, picking
out the correctly indexed option in the menu
hierarchy
he can launch and quit apps all on his own
he loves Tux!
All this he's achieved by himself, with no help from me,
and in a pretty short time.
Finally, when I ask him to practice his letters, he'll be
considerate of me and launch GCompris's letter-identification
game.
Posted in Computers | no comments
Posted by Eitan
Tue, 31 Jan 2006 13:43:00 GMT
One must applaud Bob Lee for saying what many of us never dared to: I don't get Spring. I think many of us for a long time did not grok Spring either but were afraid to say it. Everything has a reason to exist and Spring is no exception.
I believe today I grok Spring a little better than before, but I'm not sure. Below is a snapshot of my continously morphing hypothesis, as it stands today, on January 31 2006.
Spring solves a number of issues that derive from a not-as-natively-implemented feature of the Java language: closures. In smalltalk, ruby, and JavaScript, treating a method as an object is a much more common thing. And thus using a method as an object is much more commonplace. So things such as Spring's *Template classes are altogether unnecessary unless you're working in Java.
One of the end results of applying Spring to a project is a combination of Java and XML. You inevitably end up with two languages instead of one. Interestingly, this aspect of Spring is directly related to a blog I wrote recently (two weeks ago, to be exact): Skip the Compile.
There are concerns in Java that don't exist in other languages. One of them is the compile step. Removing that issue leads to Internal Domain Specific Languages, the very solution to the Java+XML conundrum.
So by attempting to grok Spring, I am coming to the conclusion that Spring is an artifact that attempts to make some of the pain of working with Java go away. It does a pretty good job in some respects (I consider the fact that we still have a bunch of XML a down-side). But when we look at other languages, specifically at Smalltalk, we see a much more elegant solution: these problems simply don't exist. Everything is written in-band. I advocate that it should be.
Posted in Programming, Java | no comments
Posted by Eitan
Mon, 30 Jan 2006 14:36:00 GMT
i think this would be cool:
<html xmlns="http://www.w3.org/1999/xhtml">
xmlns:md="somekindofmarkdownnamespace">
<body>
<div>
blah
</div>
<md:markdown-block>
markdown text here.
what firefox would do (assuming plugin is installed
, of course) is filter all text inside
md:markdown-block tags through a markdown
processor, producing html that would then be further
processed by the firefox rendering mechanism
to render the page.
</md:markdown-block>
</body></html>
A second point: define a .markdown mimetype that such a plugin could similarly process.
no comments
Posted by Eitan
Mon, 30 Jan 2006 14:20:00 GMT
- the quicktime player would be available for linux
- ditto for itunes
i believe apple has benefited much from open source. safari
for example is a derivative of konqueror. there are many
other examples.
of course, from a business perspective, apple leverages
these assets to draw people to the mac platform. and
there's nothing wrong with that. it makes perfect business
sense. if its jewel apps were available on linux, there'd
be less of a reason to give apple money..err i mean, to switch.
that's why itunes on windows makes perfect sense: apple had
a large market for ipods to gain in return. i suppose the
size of the linux market is too small to make a difference
in the case of itunes.
i guess my gripe is with this whole wolf in sheep's clothing thing:
saying "we're a friend of open source, we're the good guys" is pure
rubbish of course. the good guys are the people that forge open
source: gnu, linux, the people behind the projects on sourceforge.
anyhow, it'd be nice some day to run quicktime, itunes, and keynote
on gnome or kde. i'd pay $100 for a copy of keynote for linux...
assuming the copy was at par with its apple counterversion.
no comments
