Feed aggregator

Measurement of the half-life of Technetium-99m.

I build a variant of Roger G3XBM's latest experimental transceiver, the XBM80-2.

Adventures in measuring the selectivity of MCU-controlled super-regenerative quartz crystal controlled receivers. Resulting in a very useful selective log power meter.

A RF power measuring head using the AD8307.

A low-speed data link implemented using Pierce quartz crystal oscillators controlled by a microcontroller.

Arcing fault destroys the Rope Light controller.

A web-based emulator for the 240 LED Christmas Tree project.

I put together a USB ISP programmer for use with my Win32 laptop.

A simple 4 channel, PMW-controlled, 240 LED Christmas Tree.

A large Christmas Star for my balcony made using a length of rope light and some timber dowelling.

Spock, the smarter testing and specification framework, is approaching its 0.4 release. This is the first part in a mini-series about upcoming new features in Spock 0.4.

I have ported minilzo.c (2.03) to pure java. Initial version is at http://code.google.com/p/java-compress. Yet to do final level regression/etc. Compression & decompression of zero-filled-data and random-data is working properly.

The article offers in depth analysis of 10 Maven myths, a thorough debunking of each one, and constructive ways to take action if you still disagree.

Building modules and components is not that hard. You "only" have to encapsulate the internal component implementation and expose a clean and easy to use interface. ...at least on paper. In practice you will be confronted with the following challenges in the early iterations:

1. The external interface is too coarse and far less interesting for internal reuse, than you had thought.
2. The interesting things are residing inside the component. They are, however, well encapsulated and not accessible from the outside.

Example: you have two independent components; customermgmt and address / geo-location service. The module customermgmt exposes CRUD services and the address component extensive search capabilities. So far the world is perfect.
Now: a customer has an address - how to model that? The external, customer contract will have to reference the address somehow. That is often modeled as a direct relation between DTOs (just a getter). The external view of the customer component is now dependent on the address component. The implementation is still independent.

The relation between the customer and the address has to be persisted somehow. And now the trouble starts. Now the implementation of the customer component is dependent on the address component - because of direct (JPA) link between both modules. Now the internal implementation *and* the component contract are dependent on each other.

You are using JPA 1.0 - and your database experts just don't want to introduce an additional mapping table between the customer and the address. So you have to model a bi-directional relation between the customer entity and the address (introducing a back-link with a mappedBy attribute). Now you get a bidirectional dependency between the implementation of your component - the external dependency of the customer can remain unidirectionally dependent on the address. This is only true if you are using DTOs.

So you get two components which should be independent of each others, but are actually tightly coupled. Your modules have to expose everything - if you are using Java EE 6 - the DTOs and JPA-entities are dependent of each other - probably only the very thin boundary may remain independent. In practice you will get e.g. an invoice module in addition, which will be dependent on both the customer and the address....

You can do the following to "improve" the situation:

1. Factor out all entities into a common package. Often called "domain", "model" or even "common". Such a common package is not cohesive (it contains multiple business concepts) and also not very good to maintain (the generic names have nothing to do with the actual business). This approach looks great ...on paper.
2. Drop JPA-relations and introduce proxy-objects, which contain the ID and can be resolved on demand. This will significantly increase the amount of code and will hit your performance. You will be not able to use joins...
3. Allow bidirectional friend-dependencies between modules. In that case it will be hard to introduce a framework like OSGi, jigsaw or something else. But you can still put all "business components" into few modules. Then the real benefit of OSGi, Jigsaw etc is questionable.
4. Remove OR-mappers and go with "plain" JDBC. Let the DB handle the dependencies for you. In most cases this is not really a maintainable option.

Dependencies between persistent objects from different modules are practically not existing in other domains like IDEs, servers or plugins, but are the standard case in enterprise projects.
So, you shouldn't kill any OSGi project - you should implement some typical use cases (PoCs) with modularity solution of your choice before the project really starts. This is actually independent of any framework like OSGi, jigsaw or EMS (esoteric module system) :-).

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 267, (Monolithic or Loosely Coupled?) for more in-depth discussion]

Many applications use hibernate as OR-Mapper. This article shows an easy and fast way how to unit test your DAOs and domain model.

You developed a web-service and your consumer asks for a client? Here are some arguments why it's a bad idea to deliver clients for web-services.

In a day-to-day life the emails are occupied our life.If we can send our mails by using our java code without help of browser how we feel?This article do this.By using the Java Mail API send our mail with attachment without help of browser.This code need a mail.jar file.You can download this at http://www.java2s.com/Code/Jar/JKL/Downloadmailjar.htm

Top 5 Reasons to Attend the New Ehcache Webinar: 1. You want to watch Greg walk through the Spring Pet Clinic as an application example and show us how to tune it for maximum performance, both when using Hibernate and when caching result sets directly. 2. You want to do so by simply swapping out a .jar, changing a few lines of config and starting a server 3. You want to see Greg's benchmarking tests the comparative application performance of Ehcache EX 1.8 versus MySQL, Memcachedand a leading In-Memory Data Grid, including the impressive performance increases from the latest Terracotta 3.2 Server Array. 4. You want to learn more about distributed caching options from Greg Luck, founder of Ehcache, a standards-based cache used in a wide array of applications to boost performance, offload the database and simplify scalability. Ehcache is robust, proven and full-features and this has made it the most widely used Java-based cache. 5. You get the opportunity to ask Greg questions directly in a live Q&A session. https://terracotta.webex.com/terracotta/onstage/g.php?t=a&d=663572888 Please register for the WebEx even if you are unable to attend and you will get an email with a link to the recording.

Recently, I work on a warehouse optimization project. On interesting problem is to select an optimal pick tour for the pick agent, which is very much like a simplified path planning problem in a game world. I used the popular A`*` search algorithm and like to share with you about my Java implementation of the A* algorithm.

The .NET Framework has scored many points with developers over its eight years of existence, but it also has created confusion and angst in the community as Microsoft’s sovereign decisions have come into question.