Wednesday, January 5, 2011

Truly Rapid Development

Ran across an old, but interesting article on how to save time and costs on developing software. Found it pretty interesting:

The interesting point here was the recommendation to skip estimates. I've never dealt with a customer who didn't want, or demand, time estimates on everything, but I agree with this article's assessment -- at the end of the day, the customer is either going to pay for the work, or not pay for it.

To-the-hour estimates, I agree, are painstaking and probably a waste of time, considering that more than likely, the estimate will be inaccurate anyway, or something may happen during the course of the project (change order?) that makes that original estimate wrong. However, in order to plan a project and create proper milestones and deliverables, there has to be some sort of estimate of time it will take to complete a task. Maybe weeks, not hours, would be better suited here.

Just thinking out-loud here, but wanted to share the article. Hope someone finds it as useful as I did.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Monday, September 21, 2009

Yay or Nay: URL Shortening

Coincidence or not, it seems in this new and brave Twitter-powered world (which deserves its own yay or nay blog but I'll save it for later), the prevalence of minimalist ... well, everything, have become popular. Half-size soda cans and water bottles, miniature laptops, and these tinyurl, (and URLs. Of course, the question is...

Yay or nay?

You may have already sniffed out which way I'm leaning, but I'll start with an objective look at the positives. A number of services (including Google Groups) don't take too kindly to very long URLs. With websites becoming more powerful by the day with amazing technologies backing them, more and more information is being handled by web services, and ultimately passed via URL. Additionally, shorter URLs are "cute" and they can also be more easily read aloud. Finally, some of the more advanced shortening services offer cool tracking features, which are nice when you are into those sort of stats.

So, negatives. Aside from the fact that the last time I typed in a URL or read a URL to someone to type in was April 1997 (as an April Fool's joke), I find myself incredibly suspicious and uncomfortable with clicking a link with an obfuscated mystery destination. And unfortunately (or fortunately, depending how you look at it), I (like so many others) am not on a Mac, so viruses are a concern. To me, URL shortening is essentially a rod and bait for phishing techniques. Yahoo and Myspace apparently agree, as they have banned URL shortening from some of their services.

So, the verdict...

Despite the features and "cute" factor that URL shortening provide, they also open doors to spam, phishing, and other dimly lit alleys that I don't want to venture down. Outside of services like Twitter that just don't allow enough characters to have a full URL and descriptive text, I find URL shortening to be useless. 98% of websites I visit are via a search or a clicked hyperlink ... and if I'm clicking a link, who cares if it's 20 characters or 200 characters?

Mind you, I have a clear bias as I am working with professional services most of the time and am used to seeing complete URLs (and do not click otherwise); however, in general, I think it's undesirable to be magically transported from one URL domain to another, just for the sake of cuteness.

Now, if there was a means of shortening a URL from something like to, that is more acceptable. Having a shortened URL within a domain is fine and useful given the same positives that you find with URL shortening, but without the obvious negatives as listed.

All in all, though, I like to know where I'm going before I get there. So, URL shortening get the Nay.

Thoughts are welcome, as always.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Friday, July 17, 2009

The Google Takeover?

First came Chrome, Google's web browser built from the bottom-up based on some well-thought out and fresh ideas (which I happen to be using now as I type this!).

But that just wasn't enough. Now, they want the whole operating system:

Good luck. We at Solertium are excited.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Thursday, July 2, 2009

Does Open Source Software Suck?

Hi All,

Just came across an interesting blog that I thought I'd share. It discusses the pitfalls of Open-Source Software.

My thoughts? Well, first, I think the article makes a number of valid points. However, many of them do not only apply to open-source. There's a lot of "sucky" software out there! But the fact that any Tom, Dick, or Harry with a machine can create open-source software means you have to be wary about where you get software from.

The article was directed at the higher-level OSS, so to focus on that, again, I agree with a lot of what was said. The main mistake this article makes, in my eyes, is limiting the remarks to the world of open-source. That said, as a happy Windows user, the value of well-polished financially-backed software is undeniable.

However, the draw to open-source is the gain received from using the latest trends and tools available. Much "industrial" software fails to stay current and shys away from new ideas, clutching ever-so-tightly to that which worked. By and large, open-source projects tend to feel much fresher, breeding ideas that 5-10 years later could likely wind up in a big-ticket, closed-source product.

Again, I won't deny the facts presented in the article. But there's always two sides to a coin. :)

Carl Scott
Open-Source Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Wednesday, May 20, 2009

Google Charts Via Charts4J 1.2!

Progress is a great thing...

After announcing my work on Google Charts for GWT, I was able to work with the Charts4J team, who'd also implemented a Google Charts Java API that worked server-side, and made a branch that was compatible with GWT.

charts4j 1.1 was released as an initial port of existing behavior of the original charts4j. Today, 1.2 was released containing loads of fun features as well as integration of some features I was using in Google Charts for GWT:

If you're looking for a means of providing lightweight charts in your GWT application, give it a whirl. If you need lightweight charts in a non-GWT client application, you should try it out as well!

Here's hoping you find this as useful as I have!

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Monday, April 13, 2009

Google Charts for GWT

For anyone interested, I have begun developing a GWT implementation of the latest Google Charts API.

While there are a number of useful GWT-based chart implementations, many of them are based in Flash or are otherwise a bit heavyweight. Although there are some that work really well and are very nice (there's a really cool-looking one for Ext GWT), sometimes you just want a simple chart without any external dependencies.

The Google Charts API allows you to create charts on the fly via a URL-based API. It returns a static generated image of your chart. This makes for a powerful, yet extremely lightweight tool. While this API is clearly exposed on their site, there does not seem to exist, essentially, a standardized wrapper for this that caters to GWT.

My implementation of Google Charts for GWT simply provides that wrapper. Certainly, if you want something flashy and dynamic, this tool is not for you, you want the heavier tools I alluded to earlier.  But for a quick, lightweight tool with a number of customizable features, give this a whirl.

It is currently in the alpha stages, meaning that it is functional but is not completely documented and may contain some weird behavior. I would like to test the implementation more aggressively and finish off the full API feature set. Right now, though, you can create Bar, Line, Pie, and Scatter Charts, complete with features for Chart Legends, Shape Markers, custom colors and chart axes, multiple data sets, and more.

Check out my Google Charts for GWT samples here (with example source code):

Download the source code and samples from:

The project you're looking for is located in trunk/modules/com.solertium.util.gwt.charts

Hopefully this is useful. I'm very open to criticism and suggestions going into further development of this project.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Wednesday, April 8, 2009

OSGi and Eclipse Make Me Smile

So, I finally did it.  After some preliminary research and a bit of procrastinating, I went all in and began to adopt the newfangled OSGi approach.  Er, maybe not so new, but new to me.

Surprisingly, everything now seems to just ... work.  After months of toiling with Eclipse trying to ensure that my classpath settings were right, and dreading every completely updating as I knew my classpath would be shredded to bits by a co-worker, the combination of some built-in plug-in development tools from Eclipse and some knowledge of OSGi have brought me to tears ... of joy.  

Anyway, a while back, somewhere between the research and procrastination, I came across a very helpful presentation that got my feet wet, and I'd recommend as a nice starting point for newcomers:

The conversion of my projects from the traditional monolithic project to the multiple modules approach was not initially fun.  I'd actually compare it to the transition from creating verb-based Web Services to RESTful Web Services, to a degree.  The presenation below goes into more detail on things related to that.

So, tying this all into Eclipse: if you've got a fresh version, a lot of the work is done for you via the Plug-in Development Tools!  Simply take the time to appropriately fill out your Manifest information for your bundles (er, plug-in projects), create an Application using said bundles (again, it's built-in), and you're off to the races!  And one thing you've got to appreciate is work already done for you!


Anyway, you can of course find Eclipse-related resources on their site, which has treated me pretty well in regard to finding information I'm looking for.  But the links above were particularly helpful for me to start from scratch and sink my teeth into OSGi.  Hope you find them useful, and feel free to submit your own references!

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile

Tuesday, July 29, 2008

Eclipse Tools You Should Be Using

I've written enough Java code in Emacs, Notepad, and Nano to know a good thing when I see it -- and Eclipse is a good thing! Pretty colors, line numbering, and CTRL+Space!! But seriously, there are a lot of cool things you can use with the software to make it even better.

Saving Tactics
It may seem a bit tedious, but I've got my Eclipse set up to do a bit of formatting every time I tap CTRL+S (which is a lot). It organizes my imports, formats my if statements, cleans up my whitespace, and, of course, saves the file. There are a number of options that differ version-to-version so I won't go into specifics but this is a nice way to keep your code clean and readable, especially working in a team environment.

Write buggy code? Fall into silly bug traps? Too lazy for JUnit? Or just like to try new plug-ins? Try out FindBugs! You can run it fairly quickly over your project and let it discover common ocde flaws, bad paterns, code smells, and code that's just on the fritz. Trust me.

Code Templates
Whether its method signature templates, comment defaults, or javadoc headers, using project-specific class templates are a great way to give your code formatting consistency. For example, I am working on an open-source project and need to include appropriate licensing headers atop each class. So instead of using copy-and-paste each time I make a class, all classes I create in my project automatically start with this text.

Of course, there's tons of things I haven't touched on here but these have greatly impacted my coding and make the process not only quicker and easier for me, but gives me better quality code as well. Maybe some of you can benefit as well! I also left some references you may find useful. Feel free to add others in the comments. 'Til next time!

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile


Friday, July 25, 2008

RESTful Client-Side tools for GWT

I guess this is more of an announcement than a blog, but I just wanted to do a quick follow up to my last blog to mention some new developments pertaining to using a RESTful approach to GWT.

In my last blog, I spoke of RestLet, a server-side Java framework for REST. When I first learned of this technology, my cronies at Solertium Corporation and I fully embraced the concept, even doing some development on the open-source tool. Between then and now, I have been experimenting with client-side tools that provide reliable API through GWT to a RESTful server.

I first found GWT-REST, which if you saw my comments, I found to be pretty usable. Like the original developers of RestLet, though, I found it to have almost too much going on to make it work for me at the time. In addition, since, at the time, I have a strong code pattern that worked, it didn't make me want to go through the trouble of refactoring. After speaking with their development team, though, it looks to be strong in the future.

Since then, the RestLet guys have announced the release of a Restlet-GWT module, a port of RestLet to GWT, supported by the release of GWT 1.5. You can check out the official announcement here:

I am interested in seeing the differences between this and GWT-REST, but from my initial reading it seems that the RestLet version is an attempt at a direct port as opposed to something customized to have client-side conveniences implemented -- which I feel has strong and weak points, but the good should outweigh the bad here. I'm excited to see the implementation details, though! If you want a quick overview, the RestLet wiki provides pretty pictures and diagrams:

Again, I want to express that the RESTful method is more of an alternative to RPC than a replacement, both having benefits and drawbacks. The main drawback to RPC that has turned me to this approach is the tight client-server coupling issues and the limitations it enforces on your back-end server technologies.

My suggestion -- give Restlet's GWT module a shot. Like I said, it's an alternative, and it works right alongside RPC so it's not an either-or situation. We all have our own ways of getting the job done, but I'm always excited to hear of new developments and try them out, especially ones like these which make my job that much easier!

Thanks for your time in reading this. Feel free to comment with opinions for or against REST in GWT as I'd love to hear both sides. Also, if you'd recommend any technologies, again, feel free.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile


Monday, April 28, 2008

The Internet: An Alternative to GWT's RPC

This blog is aimed at software developers currently or considering using Google Web Toolkit (GWT), and assumes you have some prior knowledge/background. I do not aim to be technical in this blog, but rather, simply expose the idea and provide insight to those loathing particular programming paradigms.

Google's Google Web Toolkit (GWT) has make remarkable breakthroughs in allowing Java developers to easily create websites and web-based applications with little concern about cross-browser issues. As a software developer fitting this niche, I must say I am more than happy with what GWT provides.

That said, one of the biggest complaints about GWT is it's Remote Procedure Calls (RPC). In a nutshell, your client calls a function through an interface which the server interprets, executes, and returns a Java representation of results. The actual process is somewhat annoying to implement, can be somewhat clunky, and can have the speed of the DMV lines at the end of the month. Ok, so I'm exaggerating a bit, but it's nuiances were enough to me to choose to never go back to RPC. In addition, I don't think my server should be returning me a Java Object. If I wanted to access this outside the context of my GWT application (hey, these "crazy" things may happen), I know Internet Explorer probably can't render it too well -- it has a hard enough time with HTML (zing!).

Allow me to re-introduce the concept of REST.

Representational State Transfer (REST) is an architecture style that, well, kinda does what it says. In the context of Web Apps, it defines how we define, locate, and access resources. If you want the whole scoop, I've got reference links at the bottom. For this exercise, you just need to understand resources and representations.

A resource is the conceptual target of a reference (the reference being, generally, a URL). A file, for example, could be considered a resource. The file's representation can be a number of things, but examples are HTML, XML, GIF image, basically what the user sees. In short, it represents a resource in some meaningful way. For this exercise, let's go with XML as our default representation (it will become painfully apparent why soon).

With RPC, using a method to retrieve some data (a Representation, perhaps) is the standard means. There is a RESTful way to do this a well, and here's the kicker: it's a basic building block of the Internet! The standard CRUD (Create, Read, Update, Delete) operations are already represented as HTTP PUT, GET, POST, and DELETE, respectively. I'd argue that just about anything you'll need to do with a web application can be covered by one or a combination of these functions. I'm not going to get technical today but take my word for it.

Enter RestLet. A lightweight, open-source Java API that acts as a catalyst in developing Web Services in Java to handle ANY general HTTP request. A request from, say, our Web-based GWT application! RestLet employs the principles of REST, transferring representations from the server to the client upon request. Assuming we use XML Represenations, we already have a means of parsing and interpreting these representations client-side ... AJAX, which is at it's core, GWT.

Now, we have a generalized API to program to and access data from. We can use GWT to make requests, but now JSNI, JSP, PHP, even standard HTTP requests are respected. We have a portable server to interpret our requests and the responses (XML representations) are immediately parsable, even by IE (zing!).

In short, employing the principles of REST to ANY web app is incredibly beneficial for a number of reasons that I'll leave to the avid reader to convince themselves of. Roy Fielding has spent plently of time stating things and I don't need to use more. RestLet, an open-source project provides a well-thought out means of utilizing this architecture. And with this, you can finally give that RPC code a REST.

I wanted to use this blog to simply introduce the concept of REST within the context of GWT, how it can be leveraged by AJAX, and how it can be used as an alternative to RPC. If there's any interest, I'll do a follow-up blog or blogs that will delve into the following topics:

  • Current Open-Source Applications using REST/RestLet and GWT.
  • Open-Source Solutions made to speed up XML processing and leverage REST.
  • Creating a RESTful Web Server
  • RESTful References and Why They're Essential

This is all information you can dig up yourself, but I'm happy to share. REST and RestLet, of course, aren't the only way to get outside the RPC box, but, from my experience, it works efficiently, encourages robust code, and, most importantly for me, let me say bye-bye to RPC.

To close, I want to say that I don't profess to be a definitive authority on this, and I'm still learning new things everyday. I look forward to any feedback on this you may have, and any other out-the-box ideas.

Carl Scott
Software Developer, Solertium Corporation
View Carl Scott's profile on LinkedIn View Carl Scott's ohloh profile