Sun, 11 Feb 07
Posted in Java, BJUG at 1:19 am by moore
Ah, the perils of reading Bloglines before going to sleep. (I’ll just catch up on one more blog…)
I gave a BJUG talk 18 months ago about large websites and internationalization (i18n). (Links and powerpoint here.) The talk was based on my experiences of a smooth operation, created and executed by Zia Consulting.
A crucial part of this i18n process was creating and moving around Excel files containing keys and translations. In addition, there was an Access database and a VB script that converted the keys and translations to properties files. The reason to do this is that the typical Java developer wants to use ResourceBundles for i18n, which typically involves properties files. And the typical translator is much more comfortable with Excel. So, Zia built a process which bridged that gap.
It looks like someone else solved the same problem with translators and Excel files, and open sourced the solution.
Via Rickard.
Updated 2/16, fixed typo and a small formatting change.
Technorati Tags: i18n, excelbundle
Permalink
Sun, 23 Apr 06
Posted in Java, BJUG at 1:42 pm by moore
I went to BJUG last week to see a presentation about Jini by someone from GigaSpaces. It was an intensely interesting presentation for a number of reasons. First off, I knew the presenter, Owen Taylor. About 6 years ago, I took a class from him, along with a few other people. The class covered BEA Weblogic and EJBs. I’ve attended (and given a couple) technical presentations in my time including some conferences. I don’t think I’ve ever met someone who was more energetic and practiced at conveying hard concepts than Owen Taylor. Owen! Start blogging!
Another reason it was interesting is that Brian Pontarelli, an old friend, really likes Jini and has told me about some of his experiences. I actually looked into it when Bill DeHora published his entry two classic hardbacks. I downloaded Jini and JavaSpaces (Jini is the framework, JavaSpaces is the tuple space repository.) and started playing with it. The final reason that it was an interesting presentation is that JavaSpaces is something that I have never had a chance to use, and didn’t foresee using in the future. By the end of the presentation, I was convinced that this concept deserved more research, if nothing else.
What follows are my scribbled notes from that meeting, along with a smattering of other comments and thoughts regarding these technologies. More information is here, however no presentation artifacts are available, unfortunately.
The problem with distributed systems is that they move data around a lot. What you really want is for the processing and the data to be at most one step apart. Stored procedures do this, but you can’t change the logic easily.
Jini was originally developed for pervasive computing, but the focus of the presentation was on the enterprise applications that can be built based on that spec. This class of applications has some amazing features, including low latency, extremely high throughput and ‘100%’ uptime capability.
For that reason, many large institutions are looking at replacing or augmenting JEE (nee J2EE) applications with JavaSpace applications. He mentioned that GigaSpaces recruited him with the notion that a laptop could run 3 million events an hour. This kind of blew his mind.
JavaSpaces is the command pattern–code and data are distributed, based on Linda. Orbitz uses the technology and talks about 100% uptime. Anyplace where you are batching, you can now do it in real time. The key is to keep everytihing in memory and use replication for persistance, rather than disk. (Eventually you want to push it to disk, for reporting and auditing purposes, but you can do that asynchronously.) Databases tend to be used as a bus between in memory processes right now, and you can replace that with a JavaSpace.
Jini is composed of discrete objects that can run anywhere; more to the point, they don’t care where they run. It also expects failure, as opposed to many other technologies that simply assume that things will run correctly. Jini is a LAN based technology, though Owen mentioned that there are ways to turn it into a WAN technology and cited several examples. I am not competent to give a general overview of Jini–please check out this tutorial for more information.
One thing that really struck me is that all of the complexity that EJB and other JEE technologies hide (clustering, transaction management, thread management, lifecycle), JavaSpaces revels in. Owen actually mentioned that JavaSpaces brings skills that JEE developers currently rarely need to use, like threading and classloading, back into the toolbox, rather than depending on a vendor. That can be a plus and a minus, right? The whole point of not trusting servlet threading to a business developer is that it allows them to focus on the business logic. The problem with much of JEE is that it hasn’t done a very good job of doing this. Do you remember the ‘deployer’ role?
Jini has only interfaces; the named implementations are shipped around transparently. Ha ha, just like EJB remote calls are transparent. However, one very nice aspect of Jini is that when you register an implementation of an interface, you say how long the implementation is going to be available (the lease length). As a service provider, you can keep track of that lease and re-register yourself when it is near to up. Of course, if the service is no longer available, for whatever reason, it is not provided to clients–there’s no need for the JVM to garbage collect. The clients do need to be a bit smart about things though.
As for licensing, version 2.0 has been released under an apache license, as opposed to the Sun Community Source License, which was the previous license. This should grow the jini.org community significantly.
Configuration of Jini takes place with a java syntax, which can be a bit confusing, since you don’t compile and execute it. The names of the services (reggie, webster) are a bit cutesy. Webster is the web server which serves implementation classes, but shouldn’t be used in a production environment. Use Tomcat.
Spring and JavaSpaces are complementary; work is in progress to integrate them and completion is expected in the next few months. GigaSpaces has scaled implementations (linearly!) to 2000 cpus on 500 machines….
At this point Owen began talking about various architectural patterns that could be used with Jini; he also covered some war stories. However, I didn’t take any notes–you’ll have to see him talk sometime.
Issues include (so my friend says) versioning. Owen mentioned that debugging isn’t a strong suit. And I did some parallel computing for my senior thesis so I know that splitting up problems so they can be parallelized is not always as easy as you’d like. However, the web paradigm is actually rather suited to parallelization, since you do have the request/response model. The problem is, as it so often is, state.
Permalink
Fri, 10 Jun 05
Posted in Java, BJUG at 8:19 am by moore
OK, here’s a grabbag of links and info regarding my talk last night (links and powerpoint available here). I was interested to know how many folks had actually worked on an internationalized application. (I18n is one of those APIs that you ignore until you need it, and then you absolutely have to have it.) Here are some rough numbers, based on a quick survey of hands. Out of a crowd of 25, about 5 people had used i18n. Of those, 3 had used it with web applications, and one with a J2SE application (I think the last person had used i18n with C). 3 of them had supported European languages and three had supported Asian languages.
I was emphasizing how important it was to pull out all the strings to be displayed to properties files, so they could be localized. A few folks in the audience mentioned that eclipse has support for this–out of the box for java classes, and with a plugin for jsps. (If you are reading this and know the name of the plugin, please comment; I did some googling and couldn’t find any jsp plugins that claimed an ‘Extract Strings’ capability.)
One person asked if we encountered issues with translating plurals, like house/houses. I hadn’t seen that problem with the application I worked upon, but was pretty sure that the java class libraries supported a solution. That solution is ChoiceFormat.
When I mentioned that we used Excel spreadsheets as our transfer format for slinging around translated strings, one of the other folks, who spent five years supporting a java application that was internationalized (he had some war stories), mentioned the XLIFF, an XML variant that is used in several translation editors. If you’re planning to do a lot of translation, you might want to take a look.
The talk after mine was an interesting discussion of SOA by Glen Coward. It was a rather discombobulating mix of an extremely high level look at the SOA landscape, complete with TLAs galore, and an extremely low level example of a rich client in Flex talking to two web services, one built with Axis on JBoss, and the other built with MS.NET deployed on Mono. The demo went poorly, as demos tend to do, but it was enough to whet my appetite to look a bit more closely at SOA.
In addition, as you’d expect from an employee of Novell, he was interested in delineating the differences between open source software and commercial software in a corporate environment, and where each made sense. His point was that in quickly changing areas, corporate software made sense, because of productivity gains that commercial IDE support makes available. In addition, deep integration (read, anything to do with backend legacy systems) is probably going to require commercial software. He didn’t specify why, but I’d guess that specialized backend integration is primarily going to continue to be commercial software for a number of reasons: it’s not sexy, it requires the backend system to test (not often available for the average hacker), and there are intellectual property issues. What Glen didn’t make explicit, but I will, is where that leaves open source–smack dab in the middle, gluing together all the applications. You know, like Apache and JBoss and Tomcat (among many others) already do.
As usual, I learned something at BJUG. And you can’t beat free pizza.
Permalink
Wed, 08 Jun 05
Posted in Java, BJUG at 9:33 am by moore
I’m giving a talk tomorrow (Thursday) in Boulder at BJUG at 6:00. The topic will be “Internationalization and Localization in the Real World”:
This is not another rehash of the Internationalization Trail fromthe Java Tutorial website. Rather, Dan examines one website that is supporting a large number of locales in the real world and looks at how i18n and l10n were implemented in the real world. This includes the nuts and bolts of loading multi character data, framework tools that helped, how users were associated with locales, what parts of the i18n API were not used, and issues to be aware of.
Afterwards, there will be pizza and pop, then a talk about Services Oriented Architecture. Hope to see you there.
Permalink
Mon, 14 Feb 05
Posted in Java, BJUG at 11:07 am by moore
I went to BJUG last Thursday, and enjoyed the informative talk about JMS by Chris Huston. It started out as a bit of a tutorial, with the typical “here’s a messaging system, here are the six types of messages, etc.” When he was doing the tutorial bit, I thought it was a bit simple for a main talk, but it got better as the the speaker continued. It was clear from the speaker’s comments that he was deeply knowledgeable in the subject, or, if not that, at least has been enmeshed in JMS for a while. This wasn’t just a “I downloaded an open source JMS server and ran through the Sun tutorial talk” and I appreciated that.
I had a couple of take aways. One is that managing messaging with transactions is something that you’re always going to want to do, but this is fraught with difficulty, since you’ll then have two transactional systems. And we all know what that means; you’ll have to buy this book. It also means that, in a real system, you’ll never want to use local transactions, as you’ll want the transactions to be managed by a global transaction service, typically your application server.
Recovery of such a transactional messaging service was touched upon. If you have two different transactional systems, and failure occurs, recovering can be a real issue. Chris recommended, if at all possible, having the JMS provider and your data layer live in the same database, as then you can use the backup tools and ensure the two systems are in a consistent state.
One of the most interesting parts of the evening was a question asked by the audience. A fellow asked what scenarios JMS was useful for, and Chris said it was typically used in two ways:
1. Clustering/failover. You can set up a large number of machines and since all they are getting is messages with no context, it’s much easier to fail over to another machine. There’s no state to transfer.
I’ve seen this in the Jetspeed 1.5 project, where messaging is used to allow clustering.
2. Handling a large amount of data while increasing the responsiveness of the system. Since messages can be placed into queues, with no need for immediate response, it’s possible for a message source to create a tremendous number of messages very quickly. These messages may take quite a bit of time to process, and this rules out a synchronous solution. JMS (and messaging solutions in general) allow hysteresis.
I’ve seen this in a client’s system, where they send out a tremendous number of emails and want to ensure they can track the status of each one. It’s too slow to write the status to the database for each email, but sending a message to a queue is quick enough. On the receiving end, there’s some processing and status is written to the database. The performance is acceptable and as long as the JMS provider doesn’t crash or run out of memory, no messages are lost.
The only scenario that I thought of that Chris didn’t mention is one that I haven’t seen. But I’ve heard that many legacy systems have some kind of messaging interface, and so JMS might be an easy way (again, no context required) to integrate such a system.
It was an interesting talk, and reminded me why I need to go to more BJUGs.
Permalink
Mon, 19 Apr 04
Posted in Java, BJUG at 11:03 am by moore
Kris Thompson attended my BJUG kick start talk on J2ME development. I wanted to comment on his post.
1. I wouldn’t say that J2ME development has scarred me. But J2ME is definitely a technology (well, a set of technologies, really) that is still being defined. This leads to pain points and opportunities, just like any other new technology. Lots of ground to be broken.
2. Caching–you can do it, but just like in any other situation, caching in J2ME introduces additional complexities. Can it be worth it, if it saves the user time and effort? Yes. Is it worth it for the application I was working on? Not yet.
3. PNG–it’s easy to convert images from GIF/JPEG format to PNG. Check out the extremely obtuse JAI.create() method, and make sure you check out the archives of the jai-interest mailing list as well.
4. Re: Shared actions between MIDP and web portions of the application, I guess I wasn’t very clear on this–the prime reason that we don’t have shared action classes between these two portions was because, other than in one place (authentication) they don’t have any feature overlap. What you can do on the web is entirely separate from what you can do with the phone (though they can influence each other, to be sure).
Anyway, thanks Kris for the kind words.
As a last note, I would reiterate what Kris mentions: “Find out which phones have the features you want/need” and perhaps add “and make sure your service provider supports those features as well.” Unlike in the server side world, where everyone pretty much targets IE, J2ME clients really do have different capabilities and scouting those out is a fundamental part of J2ME development.
Permalink
Fri, 16 Apr 04
Posted in Java, Programming, BJUG at 12:19 am by moore
I presented this evening on J2ME for the kickstart meeting at BJUG, where Grady Booch was the featured speaker. After unknowingly knocking UML in his presence, I enjoyed a fine talk on software archeology. This discipline involves looking at larger, historical patterns of software development. Essentially, when we build software, we are building artifacts. And, just as the plans and meetings of the the slave foremen who built the pyramids used are not recorded, so there are aspects of present day software development that are simply lost when the project ends or the programmers die. One of Booch’s projects is to capture as much of that data as possible, because these architectures are full of valuable knowledge that many folks have sweated for. It needs to happen soon, because, in his words, “time is not on our side” when it comes to collecting this kind of data. Man, I could handle that kind of job.
Speaking of architecture, I stumbled on “Effective Enterprise Java” which looks to be a set of rules for enterprise java development. I really enjoy “Effective Java”, by Joshua Bloch, so I hope that Ted Neward’s book lives up to its name. And I certainly hope this project doesn’t get stranded like “Interface Design” apparently did.
Permalink
Thu, 11 Dec 03
Posted in Programming, BJUG at 10:28 pm by moore
I went to BJUG meeting tonight, and the topic was automatic code standardization tools. Tom Marrs gave a good presentation which covered 4 open source tools that integrate with ant:
Checkstyle checks that code fits existing guidelines. It comes configured to check against Code Conventions for the Java Programming Language. pmd is lint for java; it actually has a page where you can see it run against itself. It also finds generic exceptions and complains. Both of these tool show you where problems exist in your code, usually by generating a nice HTML report, but don’t modify the source.
The next two tools actually modify your .java files. cleanImports fixes erroneous import statements, and cleans up com.foo.* imports. It’s smart enough, supposedly, to only import the actual classes that are used in a particular file. Jalopy is a bit more ambitious, and attempts to fix missing javadoc, whitespace problems, brace placement and some other problems.
Now, you need a combination of these tools. The style checkers can be very strict, since they don’t have to be smart enough to fix the problems they find. The code beautifiers, on the other hand, actually fix the problems that they find. Tom made some good points that these programs can generate a lot of output, and it makes sense to prioritize in deciding which problems to fix. Especially when you aren’t starting with a blank slate, it makes a lot of sense to ignore some of the lesser evils (who cares about whitespace when you have a constant that isn’t static final).
A member of the audience brought up a good point, which is that using these kind of tools is at least as much a political problem as it is a software problem. Few folks are going to argue that having a consistent coding standard makes maintenance easier, but I think that few folks are going to argue that it’s the most important factor. But, as I see it, there are a couple of different things you can do to enforce coding standards. I list these below in increasing order of intrusiveness.
1. Make the tools available
If you make the tools available on the project, folks will probably use it. After all, who likes writing crappy code? All these tools integrate with ant, and some integrate with popular IDEs. Make developers aware of the tools and add the targets to your standard build files, and encourage folks to use it.
2. Get buy in from the team
If you’re on a team, it may make sense to have ‘tools meeting’ at the beginning of a project (or in the middle, for that matter). Decide on basic standards (and remember, the location of braces isn’t really that important), after explaining how it makes folks’ lives easier. Build a consensus that using one or two of these tools is a good thing to do, and should be done before code is checked in.
3. Have senior staff dictate usage: ‘thou shalt use pmd’
If the senior members of a team feel strongly about this, they can make a preemptive decision that the tools must be used. I’ve been on a few projects where this happened, and I can’t say that it was a huge issue. After all, the senior staff make lots of arbitrary decisions (well, they look arbitrary) about architecture, team membership, etc. One more won’t hurt too much.
4. Make running the tools required before check in
You can put wrapper scripts around CVS. I’ve seen it done it on the client side, but this can be circumvented by just running the cvs command. You can also do it on the server side. I’m not sure what the best option is, but this is a large hammer to wield: it ensures that the code meets a standard, but also displays distrust that the coder can and will do the right thing on their own. Not exactly the kind of attitude you want to convey to folks you’re paying to think for you.
I think that these automatic tools are great. Code inspection, especially of a large number of classes, is something that programs are well suited for–there’s a clear set of rules, it’s a repetitive, boring task. But make sure that you don’t forget the human element. What happens to the reported problems? No matter how much the code is automagically fixed, you need and want the programmer to look at the output of the tools, and strive to improve his or her code.
Permalink
