david @ flux
8 PostsBy default, Flux stores its information in an HSQL in-memory database. Flux is preconfigured with HSQL by default so that people can download Flux and get started with running simple examples within a few minutes. No need to configure your Oracle, DB2, or MySQL instance.
Over the years, a few problems have arisen from this approach:
1) HSQL's database transaction isolation level is READ_UNCOMMITTED (instead of the usual READ_COMMITTED), which places severe limitations on Flux's ability to run multiple jobs and workflows concurrently. In short, when using HSQL as its database, Flux can run at most one job or workflow at a time.
2) Flux requires up to three database connections for its internal use. Due to this requirement, not all of Flux's features are available when using HSQL. For one, Flux messaging doesn't work when using HSQL.
3) It would be useful if HSQL could store its information persistently. It can, actually, but it performs so poorly with sizable databases that Flux explicitly prevents HSQL from running in a persistent mode. For a Flux user to get a persistent database working with Flux, it would be nice if Flux's built-in database supported it. Not everyone wants to go to a full-fledged database such as Oracle, DB2, or MySQL.
Moving from HSQL to Derby would solve these problems.
Derby is well supported, would allow many jobs and workflows to run concurrently from the get-go, and would allow for an option to persistently store Flux data.
The plan for Flux 8.0 is to move from HSQL to Derby. For nearly all those using HSQL with Flux, the transition will be transparent and seamless.
Flux 8.0 development begins imminently. Flux 7.7 is very nearly ready to be released. Flux 8.0 starts afterwards.
I've already coded a proof-of-concept transition from HSQL to Derby in the Flux 7.7 code base. It was straightforward. I ran Derby-based Flux jobs and workflows.
It was cool. 
We're hiring.
Java developers, we have two openings here at Flux. Flux is a very exciting place to work where the fruits of your efforts are used at many, many financial institutions worldwide and have a positive impact on thousands of people. For me, that's truly both inspiring and sobering.
What's special about the Flux working environment?
Besides the truly casual atmosphere, weekly massages, daily ping pong, and shoe-optional dress code (I'm not wearing shoes as I type this), we have all the usual benefits (healthcare savings accounts, 401(k) with company paid matching, paid time off, holidays, dental, vision, etc).
But here is perhaps the most exciting benefit:
All Expense Paid, 7 Day Vacation for Two, Anywhere in the World
On previous trips, Fluxies have visited Ireland, Mexico, Japan, and, of course, the United States. One ambitious Fluxie hit France, Luxembourg, Belgium, The Netherlands, Germany, and the Czech Republic all in a single trip.
To apply, send your info to careers@fluxcorp.com telling us about your Java development skills.
Read more about our Java developer openings on our Careers page.
UPDATE: TheServerSide.com picked up this blog post and wrote an item on the "all-expenses-paid, seven day trip for two to anywhere in the world" benefit at Flux. TheServerSide.com is pretty much the place to go for enterprise Java news and spirited discussions among fellow practitioners in the enterprise Java community.
What benefit or perquisite excites you about your employer?
Here at Flux, we have a lot of resources that are new or updated as of late. They could be useful to you or your team to help you flatten your Flux learning curve or to help you use Flux better.
Here are seven helpful resources updated as of late.
- New website: We reworked the content on our website and the visual design to provide more information than before. It's organized better. The goal is to help you find what you need to learn Flux and to use Flux better.
- Blogs: We blog. We do it to give you insight into what we're thinking and how we're planning to help our customers succeed. There are truly useful things in our blogs.
- New customer portal: We updated the Flux Portal to better organize the info that is available. This includes discussion forums with other Flux users. It all helps you learn and use Flux.
- New technical specs page: It lists Flux's technical specifications and is updated regularly.
- New performance metrics: Flux engine performance data is online. The link to the performance metrics is near the bottom of the technical specs page.
- Comparison to Quartz: This comparison document gives a straightforward, unbiased viewpoint of when it's appropriate to use each.
- Technical articles: Short, to-the-point knowledge base articles that present solutions to common Flux situations.
How else can we help you? What else would you like to see?
First impressions are important. When a Java developer starts coding to the Flux API, the very design of the API itself is beyond important. It must be well designed, consistent, easy-to-use, highly functional, and aesthetic. Yes, aesthetic. APIs have aesthetics, as any Java developer knows. Some APIs are good, great, or even beautiful. Some are not. We've all used great and not-so-great Java APIs.
Which brings me to the heart of this blog post: graphic designers and graphic artists at Flux.
First impressions are important. Flux's graphical user interfaces must be aesthetic. They must be, first of all, beautiful to look upon, be very easy to use (usable), and highly functional (do what the users need).
We have staff members who have backgrounds in art and graphic design. Their contributions to Flux's web application as well as our website have been indispensable. They are instrumental in not only the beautiful aspect of your Flux experience but the usability and functional aspects as well.
So when you hit our website or use our web app, remember that there are experienced graphic designers and artists behind them. Your productivity is our only goal. If you have critiques, let us know. Be a tough critic. Your criticisms only make us better. Ultimately, your criticisms will only make you more productive with Flux.
How important is it to insert (that is, embed) enterprise Web applications within enterprise Web applications?
I'm not talking about special-purpose "widgets", like pop-up calendars and what not, which you embed in Web pages. And I'm not talking about enterprise back-end APIs, which have no visual aspect.
I'm talking about embedding a visual enterprise Web application inside a visual enterprise Web application.
For Flux's OEM customers, the answer to the above question is, Very important.
(An OEM is simply a software company that builds and sells their software application with Flux embedded in it.)
Many of our OEM customers are financial software companies selling their software products to their corporate customers. Other times, our OEMs are different kinds of software companies whose target market is financial institutions.
Financial companies want enterprise functionality, such as payments, accounts, and receivables management. As part of that enterprise functionality, our OEMs want to provide Web-based job, workflow, and business process editing and near-real-time monitoring capabilities. Flux 7.5 and the upcoming Flux 7.6 (available 12 Nov 2007) provide those capabilities.
Take the case of our fictitious friend, Gotham Financial.
Gotham Financial wants its enterprise Web application to be "branded" with their "look" -- their colors, their logo, their style. Hence the Gotham Financial style that you see in the image above.
Gotham Financial also wants its software vendor (a Flux OEM) to embed visual job scheduling, workflow, and business process editing and near-real-time monitoring capabilities in its enterprise Web application. Gotham Financial wants to enable its own staff to design workflows customized to their needs.
All of this is a capsule of why Web Embeddable is so important.
I've blogged before about how I've found it difficult to hire Java quality assurance engineers. Because our Flux and Flux BPM software products are targeted at Java software development teams, we need Java QA engineers to do lots of programming to the Flux APIs in order to properly test them. We can't hire someone with the standard set of IT skills.
With this experience in mind, this is what I've done.
1. I've folded our existing QA team into the development team.
2. The development team will perform all QA work, from unit testing all the way through to integration testing, load testing, system testing, and so forth.
3. Performance benchmarks will be posted online with the Flux and Flux BPM technical specifications as well as in the Flux software manuals. These benchmarks will be updated with each major and minor software release. In conjunction with this
effort, Eric and the development team have been improving Flux's performance significantly in the last two weeks. Eric will blog about what the development team has done.
4. Known bugs are posted online in the Flux bug list and the Flux BPM bug list. As I write this blog entry today, there are 20 bugs on the Flux bug list and one bug on the Flux BPM list.
###
I take our customers' success very, very seriously. Their success is the only reason I have a job today. I like my job; I want to keep it.
I have never intended for our users to be our QA team. We are our own QA team. Logic bugs, performance bugs, and excessive database deadlocks are unacceptable. They lead to bad feelings all around, starting with our customers' own users. And that's very, very bad.
With these changes, we are redoubling our efforts to find and fix all of these bugs, both with the current Flux and Flux BPM releases and all future releases.
David serves as the president of Flux. He wrote the first few versions of Flux before it was selling well enough that he could hire Java developers smarter than himself.