Aside from all the new APIs supported (and there are a LOT – some only previously available through extensions. Notable among them: Java APIs for Bluetooth ( JSR 82), Wireless Messaging API (WMA, JSR 226), and J2ME Web Services Specification (JSR 172), and of course we can’t forget.. argh... just check out Sun's page for the full scoop), the coolest thing for me has to be the standard support for the Location API’s. These APIs, of course have helped propel J2ME into orbit via Google’s "Google Mobile Maps" application (and the plethora of other maps / GPS applications out there helped, too, I suppose :-) )
This is an impressive release and long-awaited. One gripe: where’s my Linux SDK? I’ll have to use the windows version for now, I suppose. I should count my blessings: there doesn’t seem to be any mention of a Mac version!
Monday, February 12, 2007
Sunday, January 28, 2007
Salesforce.com's new language/platform pack: "Apex"
I just noticed Salesforce.com’s latest step towards platform domination: Apex.
I like the name. Cool. Sounds like Apress, and Ajax. Half buzz, half hard-hitting tech done cheap, with just a twist of that je ne sais quoi, that “this could be a Windows codename” quality. Yeah!
I like the possibilities. The market for middle ware integration is astonishing. The application that’s readily customized is the application that more readily adapts, and is adapted. This should go a long way towards removing all the edge cases defying Salesforce.com’s proliferation. Apparently, they have a little less than 30,000 customers. I don’t know if that’s individual users or entities, or what. It’s not nothing. Interesting: the inclusion of LINQ-style sql objects:
It’s a typed SQL query, embedded inline with your java. Not like those opaque String queries I keep hearing about…
I got the hint on all of this from eWeek magazine, in a small blurb about Apex of the January 22 issue. To my chagrin I get to the salesforce.com site, and start looking around right there, not too deeply linked, is Peter Coffee, formerly a columnist of 18 years at eWeek. He’s just switched jobs! Good luck, Peter!
I like the name. Cool. Sounds like Apress, and Ajax. Half buzz, half hard-hitting tech done cheap, with just a twist of that je ne sais quoi, that “this could be a Windows codename” quality. Yeah!
I like the possibilities. The market for middle ware integration is astonishing. The application that’s readily customized is the application that more readily adapts, and is adapted. This should go a long way towards removing all the edge cases defying Salesforce.com’s proliferation. Apparently, they have a little less than 30,000 customers. I don’t know if that’s individual users or entities, or what. It’s not nothing. Interesting: the inclusion of LINQ-style sql objects:
Account acc = [select Id from account where name = 'xxx'];
Account[] accs = new Account[]{acc};
System.assert(accs[acc.id] != null);
It’s a typed SQL query, embedded inline with your java. Not like those opaque String queries I keep hearing about…
I got the hint on all of this from eWeek magazine, in a small blurb about Apex of the January 22 issue. To my chagrin I get to the salesforce.com site, and start looking around right there, not too deeply linked, is Peter Coffee, formerly a columnist of 18 years at eWeek. He’s just switched jobs! Good luck, Peter!
Thursday, January 25, 2007
How common is the use of the “active” objects pattern in Java?
Before Spring/Hibernate/that whole wave came along, I don’t remember being particularly inspired to have persistence and business logic attached to the entities on which that logic acted… In fact, I rather disliked EJB’s entity beans pattern specifically because everything was on the bean itself. Often times it’d be on a SessionBean, and that’s good. But even there, entity beans have basic persistence, removal and lifecycle operations built into it. A Car doesn’t car how it’s persisted, does it?
Then along came Rails (the most infamous example of this pattern) and suddenly everything is built into the object itself. And, honestly, I like the pattern there. Everything is static if its an operation that would be done by a DAO in Java. It’s a property if its to be persisted. Simple. You know where you stand. I also like the DAO/domain objects mechanism in modern day Java.
That said, I’m astonished at how ugly having the DAO functionality built into the domain object can get in Java.
I ran across some code that has factory methods for returning the entity! Then, as you modify the properties in the entity (mutator by mutator), it writes them to the database! Ugh! Modify 10 properties on the object, and lo 10 update statements fly by your console.
Furthermore, I’ve gotten used to the idea that you can have an interface defining a contract and then an implementation of that DAO’s interface. You can hide that implementation (especially with Spring) behind its contract through any number of remoting technologies, simple base casts and more in a local call, and more. You don’t have to include the accessor / mutators in the interface, too. That’s pretty remarkable.
Then along came Rails (the most infamous example of this pattern) and suddenly everything is built into the object itself. And, honestly, I like the pattern there. Everything is static if its an operation that would be done by a DAO in Java. It’s a property if its to be persisted. Simple. You know where you stand. I also like the DAO/domain objects mechanism in modern day Java.
That said, I’m astonished at how ugly having the DAO functionality built into the domain object can get in Java.
I ran across some code that has factory methods for returning the entity! Then, as you modify the properties in the entity (mutator by mutator), it writes them to the database! Ugh! Modify 10 properties on the object, and lo 10 update statements fly by your console.
Furthermore, I’ve gotten used to the idea that you can have an interface defining a contract and then an implementation of that DAO’s interface. You can hide that implementation (especially with Spring) behind its contract through any number of remoting technologies, simple base casts and more in a local call, and more. You don’t have to include the accessor / mutators in the interface, too. That’s pretty remarkable.
Wednesday, January 24, 2007
Archy - a maven archetype aggregator, and the 10 minute test your project so richly deserves
I just found a tool called "archy"!
I have archetype-fever. I’m not ashamed of it. Long have I lusted over toolset x but not had the inner strength or resolve to spend the night setting up an ant build that MIGHT one day be integrated into my workflow, let alone quick enough for a 5 minute test. Maven archetypes make the agile “10 minute test” a possibility. Java’s robbed open source projects of their 10 minute tests by being so complicated to bootstrap. With installation and compilation the norm, configuration is par for the course. Who has time? Who has more than 10 minutes, anyway?
A really polished project will have some sort of installation mechanism. But often times, it’s non standard, or half-assed. Download Tomcat for Windows and be received with a windows installer with all the bells and whistles. Download it for linux and…look forward to configuring a few things..
If you’ve got a project that’s a webapplication and you’ve got an installation process, then that’s impressive! Tigris.org’s Scarab, for example, has an installer. That’s not to say that there’s no configuration at all, What’s more, in Scarab’s case, I definitely would have preferred some documentation and a few bug fixes in lieu of that installer!
Archetypes give the project the spotlight and take care of the minutiae. This is why, unless it’s very exotic (J2ME and Jini spring to mind! A proposito: has any one found a useful maven 2 plugin for J2ME or GWT?), I wait for the archetype. Simply add the archetype’s repository to ~/.m2/settings.xml and run that familiar invocation, “mvn archetype:create …”. Voilà, out pops a working project. You invoke mvn idea:idea at the root and off you go building a new application!
So fine, maven archetypes are amazing. Though, now you’re where you started, in a sense, aren’t you? Not quite as bad, but bad. You have to know where the archetypes are for them to be of any use to you! You could easily spend the time just looking for a way to avoid getting invested too much into some technology without a result.
That’s where archy comes in. It has a centralized listing of archetypes and their corresponding repositories and a command line interface to guide you through using any of them. It reads from this Wiki page, and it reads from archetypes.xml, on the local classpath. There doesn’t seem to be an easy to use way to expand that, though. I suppose you could just author your own archetypes.xml and put that on the root of classpath and it would resolve that, instead. I haven’t perused the source itself, so I don’t know. I’ll certainly get into it as I add more archetypes to my arsenal. Here are a few of note: Matt Raible's Appfuse, and a JBoss Seam archetype.
I have archetype-fever. I’m not ashamed of it. Long have I lusted over toolset x but not had the inner strength or resolve to spend the night setting up an ant build that MIGHT one day be integrated into my workflow, let alone quick enough for a 5 minute test. Maven archetypes make the agile “10 minute test” a possibility. Java’s robbed open source projects of their 10 minute tests by being so complicated to bootstrap. With installation and compilation the norm, configuration is par for the course. Who has time? Who has more than 10 minutes, anyway?
A really polished project will have some sort of installation mechanism. But often times, it’s non standard, or half-assed. Download Tomcat for Windows and be received with a windows installer with all the bells and whistles. Download it for linux and…look forward to configuring a few things..
If you’ve got a project that’s a webapplication and you’ve got an installation process, then that’s impressive! Tigris.org’s Scarab, for example, has an installer. That’s not to say that there’s no configuration at all, What’s more, in Scarab’s case, I definitely would have preferred some documentation and a few bug fixes in lieu of that installer!
Archetypes give the project the spotlight and take care of the minutiae. This is why, unless it’s very exotic (J2ME and Jini spring to mind! A proposito: has any one found a useful maven 2 plugin for J2ME or GWT?), I wait for the archetype. Simply add the archetype’s repository to ~/.m2/settings.xml and run that familiar invocation, “mvn archetype:create …”. Voilà, out pops a working project. You invoke mvn idea:idea at the root and off you go building a new application!
So fine, maven archetypes are amazing. Though, now you’re where you started, in a sense, aren’t you? Not quite as bad, but bad. You have to know where the archetypes are for them to be of any use to you! You could easily spend the time just looking for a way to avoid getting invested too much into some technology without a result.
That’s where archy comes in. It has a centralized listing of archetypes and their corresponding repositories and a command line interface to guide you through using any of them. It reads from this Wiki page, and it reads from archetypes.xml, on the local classpath. There doesn’t seem to be an easy to use way to expand that, though. I suppose you could just author your own archetypes.xml and put that on the root of classpath and it would resolve that, instead. I haven’t perused the source itself, so I don’t know. I’ll certainly get into it as I add more archetypes to my arsenal. Here are a few of note: Matt Raible's Appfuse, and a JBoss Seam archetype.
Sunday, January 14, 2007
I just got married!
I just got married!
It’s the morning after, 2:54 AM, Sunday, January 14, 2007. I was married yesterday, Saturday, January 13, 2007, at 10 AM, to my friend and console and… words fail me… to Richelle.
Few things make me arch my head in utter stupor… Few things stun me. I work in computer science, after all. Technology is science, and science is constantly learning that unknown. It’s learning that je-ne-sais-quoi that keeps our curiosity working, nagging us into the early mornings.
Richelle stuns me.
I love you, Richelle. Here’s to whatever’s next. I’m curious.
It’s the morning after, 2:54 AM, Sunday, January 14, 2007. I was married yesterday, Saturday, January 13, 2007, at 10 AM, to my friend and console and… words fail me… to Richelle.
Few things make me arch my head in utter stupor… Few things stun me. I work in computer science, after all. Technology is science, and science is constantly learning that unknown. It’s learning that je-ne-sais-quoi that keeps our curiosity working, nagging us into the early mornings.
Richelle stuns me.
I love you, Richelle. Here’s to whatever’s next. I’m curious.
Subscribe to:
Posts (Atom)