Tag: development

RESTExpress Overview and Tutorial

In my last post, Intro to REST (Revisited), as well as discussing the six constraints of the REST architectural style, the video discussed the background for the Java Rest Service Framework, RESTExpress and introduces a sample project.  The video below is part two of the presentation, where we dive in and create a real, working service suite using RESTExpress around a blogging system that uses MongoDB for its back-end store.  The reference implementation demo’d during the presentation is available on GitHub and supports linking, pagination, filtering and sorting of collection results returned (for blogs, entries, and comments).

This video goes into a bit of depth on how all that gets accomplished in your service suites with a minimum of coding.

[youtube http://youtu.be/hHDO6soGehc]

 

If you haven’t heard, RESTExpress is a lightweight micro-framework (along with some other micro-frameworks) that support rapid development of highly scalable, high performance REST services supporting JSON and XML payloads.  It is an active open source project that is gaining momentum.  You can get more information at the resources below:

Can Software Improve Over Time Through Refactoring?

As you know, the practice of refactoring is to account for software changing over time–presumably improving. Is that a myth? To some degree, I wager yes. Here’s why… and it’s not what you think.

Over the last few weeks, I’ve been involved in a fire drill to improve the reliability of enterprise messaging (via JMS) for a set of messages that transmit financial-related data within the organization I currently work. Said enterprise messaging library is approximately six years old and has had many features (as you can imagine) added to it over the years.

Upon initial inspection, it is quite clear that there is a significant amount of “Copy-n-Paste” coding involved in creating the additional features. Clue 1: Copy, paste, mutate does not constitute refactoring! Where’s the craftsmanship in that? Software quality, reliability, and readability degrades over time because software developers often just don’t give a damn. They lack pride, care, and craftsmanship. It’s as hard to find a good software person as it is to find a good doctor, mechanic, etc. Is that the company’s fault?

OK venting aside, I maintain software truly can improve over time. But as with anything (e.g. relationships, gardens, food, coffee), software requires tending. Software is never done so we need to be dilligent and deliberate with our changes. Companies need to account for total cost of ownership and allow time for refactoring to occur during the introduction of new features. Of course, that implies software developers have the inclination and skills to improve the software over time.