Group items tagged

"This article looks at the new Jobs API available as part of Eclipse 3.0. It describes the main portions of the Jobs API and the use of scheduling rules. It also describes some changes to Eclipse resource management including how the Resources plug-in integrates with the new API. Finally, it describes some new UI functionality that has been added to provide feedback to users about jobs that are run in the background. "

"Background processes in Eclipse RCP and Eclipse Plugins This article describes how to use the Job API in Eclipse RCP and Eclipse plugins to perform asynchronous tasks. It also discuss how to update the UI thread. This article is based on Eclipse 3.6 (Helios). "

Last weekend while pondering the question "Is Scala ready for the enterprise?" I decided to write a simple Java EE 6 app entirely in Scala, without using any Java. I had three main reasons for doing this: one was just to see how easy/difficult it would be to write everything in Scala (it was easy).  Another was to document the process for others journeying down the same road (the entire project is on github).  Finally, I wanted to identify advantages of using Scala instead of Java that are specific to Java EE apps (I found several). Background The specific app I created was an adaptation of the Books example from Chapter 10 of Beginning Java™ EE 6 Platform with GlassFish™ 3. It's a simple web app that displays a list of books in a database and lets you add new books. Although it's a pretty trivial app, it does touch on several important Java EE 6 technologies: JPA 2.0, EJB 3.1 and JSF 2.0.

There was a recent outburst in blogs on the topic of Groovy and how it compares to Java. Although I respect the youthfull entusiasim of Groovy and Co. working on this little exercise I'm just perplexed by the "WHY?" in this whole discussion. Let me just say again: W H Y ?!?! 1. Practically no one cares about Groovy (let alone Groovy++ strap-on) beyond Grails community. So this language just as "widely accepted" as Ruby (at least for enterprise software development) 2. If you know Java it's equally "challenging" to pick up either Groovy or Scala. Don't let anyone insult your intelligence by claiming that Scala syntax is somehow more complex than Groovy. In both languages you will need to adapt to functional thinking - and that's where you will have to spend a couple of weekends… 3. If you know Groovy - you already know 90% of Scala (different syntax and few extra features can be picked up in the evening) 4. Scala is designed by people who have proper academic background, experience and talent in the area of language design - Groovy has never been that way (and anyone who dares to look inside of Groovy runtime or history of changes in it will attest to that). NOTE: it did come out rather strong - but that's how I feel about it and after some thinking I'll leave as is. Nothing personal to anyone reading it… 5. Scala as a post-functional language is years ahead of Groovy (static typing with best-in-business type inference, highly tuned mix of imperative and functional styles, powerful and done-right generics, etc.) 6. Groovy will ALWAYS be slower than Scala or Java (latest benchmarks put even Groovy++ about 50 times slower than Java) just by its nature unless someone changes the language and rebuilds the runtime from the ground up. 7. Once we get decent integration with Eclipse, NetBeans and IDEA for Scala, the Groovy will lose its only serious advantage

Last week I decided to challenge Scala's downscalability by trying to replace a Groovy script with a Scala pendant. In this article you will read about this little experiment and a comparision of the Scala result with the Groovy predecessor. But first some background about the script: Some time ago my company introduced a new spam notification system.  When it thinks that a mail contains spam, it keeps it in quarantine and once or twice a day sends an email to the recipient (me) reporting all the kept mails, together with an intranet web link for each  to release it. Here you see an example of such a mail (note: I have my mails displayed in plain text format):

"The Pencil Project's unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use. Top features: * Built-in stencils for diagraming and prototyping * Multi-page document with background page * Inter-page linkings! * On-screen text editing with rich-text supports * Exporting to HTML, PNG, Openoffice.org document, Word document and PDF. * Undo/redo supports * Installing user-defined stencils and templates * Standard drawing operations: aligning, z-ordering, scaling, rotating... * Cross-platforms * Adding external objects * Personal Collection * Clipart Browser * Object snapping * Sketchy Stencil * And much more..."

There are many approaches available to scale PostgreSQL beyond running on a single server. An outline of the terminology and basic technologies involved is at High Availability and Load Balancing. There is a presentation covering some of these solutions. There is no one-size fits all replication software. You have to understand your requirements and how various approaches fit into that. For example, here are two extremes in the replication problem space: You have a few servers connected to a local network you want to always keep current for failover and load-balancing purposes. Here you would be considering solutions that are synchronous, eager, and therefore conflict-free. Your users take a local copy of the database with them on laptops when they leave the office, make changes while they are away, and need to merge those with the main database when they return. Here you'd want an asynchronous, lazy replication approach, and will be forced to consider how to handle conflicts in cases where the same record has been modified both on the master server and on a local copy. These are both database replication problems, but the best way to solve them is very different. And as you can see from these examples, replication has a lot of specific terminology that you'll have to understand to figure out what class of solution makes sense for your requirements. A great source for this background is in the Postgres-R Terms and Definitions for Database Replication. The main theoretical topic it doesn't mention is how to resolve conflict resolution in lazy replication cases like the laptop situation, which involves voting and similar schemes.

"Developers usually have their programs write log and debug information to the standard output during coding and testing. This results in a lot of text being printed to Eclipse's console view, often more than can be easily surveyed. Since at any given time, only a small part of this information is of primary interest to the developer, a tool which highlights specific lines or words can significantly increase the readability of this output. Grep Console allows you to define a series of regular expressions which will be tested against the console output. Each expression matching a line will affect the style of either the entire line or parts of it. For example, error messages could be set to show up with a red background, or integer values showing the state of a certain variable could be rendered in bold font. "

As we have learned in the cucumber testing, feature files are created with the executable test scripts. The language, in which these executable test scripts are written, is known as Gherkin language.