Remedium was launched

The first beta version of Remedium was launched this week at http://reboot.pro/14801/

It has been a very long year moving this platform from my sketches onto a a real implementation as seen on the screenshot but I am happy with the current result.

Remedium opens the door to a new portofolio of projects based on the Java platform/language.

It is also an opportunity to move from an aging concept of applications restricted to work from a desktop onto applications that take advantage of web browsers and remote management.

So, when accounting the learning curve to program in Java proficiently, the effort to create a new platform from scratch and still account with the research work necessary to implement a new security concept, I would say that our development time required to make this possible since the past year was indeed put to good use.

Wouldn't have made it this far without the help of Professor Benoit Morel from CMU and my close friend José Feiteirinha. The professor helped me keep my feet to ground about the goals to reach and José brought really cool ideas to make this platform a reality.

Unless you had been involved since the start, it is difficult to have an idea of the effort required to implement this work. It required a bit too many rewrites until it resulted in a simple solution.

The first phase has been completed. The remedium client is indexing all files inside a given machine and placing the gathered data inside a set of databases.

Indexing files is not an amazing feature, creating a superb architecture was the real challenge. It provides enterprise functionality such as message queues, web server and component based modules that will allow us and other developers to expand remedium with more features.

The next two phases are equally challenging if not even more. We will start to work in a networked environment and aggregating data from multiple sources along with also feeding multiple points.

In the end, we should have a system capable of allowing users to exchange data and provide feedback on their own, using a perfectly decentralized structure.

A lot of work ahead, but it has been fun so far.

Old school programming

This weekend was intense.

While working on my current project, I've slowly reached the conclusion across the past week that many things were wrong on the adopted architecture and that a simpler solution could be adopted.

Reminding myself of the words from a wise software engineer about efficiency of the good enough I could have kept on moving, but it would pain my soul knowing that things were not optimal. If there was a time to make changes, the time was now.

Couldn't afford more schedule slips as seen for the month of the March. So I've decided to plunge myself into a coding marathon to rearrange the code and do things right.

Started of at Friday after work around 17:00 and stopped around 04:00 Saturday morning to grab a snack and some sleep. Saturday and Sunday followed similar hour addiction for code cranking the intended result. The outcome was fabulous!

Not only the new framework is simpler in terms of architecture, it also looks great. The web user interface provides a neat appearance and makes life a lot easier than creating a Swing based interface for each component of the system.

Many other nice-to-have features were also added this way. People can use browsers or third-party developers can create wrappers that make use of the provided web services.

I know that anything coded during a hackathon weekend will haunt me with defects across the next times. That is a risk. But it is still better than living with an architecture that that would only add layers of unnecessary complexity and my own (human) resources are too limited to cope with them.

As result, there is absolutely no need to adopt a Google web toolkit, hibernate, SEAM, JBoss or ActiveMQ COTS for the moment.

The current result can rightfully be called old school programming (compared to current trends of course). And I say this perfectly aware of all advantages and disadvantages that come from this design decision. But nevertheless all that, there is elegance in simplicity and this is the route that I prefer to follow whenever possible.

And speaking of small, the entire framework when including the database (HSQL), message queue, process manager, web interface and remaining components is still using some whooping 3Mb of disk space.

Below is demonstration screenshot of the current status. The page demonstrates two applications. The first one is a simple file browser and the second demonstrates a simple page with text. Each application can host child applications and these are automatically added on the page tabs.

Tough weekend but happy results.

:)