Pages

    Tuesday, October 28, 2008

    I'm Pushing this on You

    So, one of the requirements we have is to be able to alter the content of a page given a users input, where that user is either another user entirely or the main user of the given session. The aim is to impart a collaborative aspect on a given page so that anyone on the page can view the collective changes that have been made to that page.

    This has brought me around to thinking about AJAX in a different manner. Normally, AJAX is used to pull info from the server. The page (or component on the page) makes a request of the server, and the server sends the response to the page/component. However, what do you do when you need to reflect changes to your model in near real time?

    Well, the thought that comes to my mind is that you move to a push model. In the push model, whenever the data model changes it pushes those changes out to the view. Now, this is totally doable with AJAX, it's just a different way of thinking about things. I think it's been termed reverse AJAX.

    Of course, the poor man's way of doing a push model is to actually do a pull model with automated (instead of user-requested) pulls on a short interval. The downside to this is that it can result in a ton of network traffic at the very least. Another downside is that you don't have true data coherence. You're basically taking a guess as to when the data model has changed.

    So, I'm now investigating ways in which I can use a push model. I've found two promising leads: CometD and Pushlets. I might still opt for the poor man's approach, at least for now, but both of these bear investigation. When I know more, I'll post it here.

    If you're interested in a good article which outlines some of the ways of going about this, check out this article here.

    Monday, October 27, 2008

    J2EE Survey Software: Opinio

    A requirement came up recently wherein we need to be able to conduct online surveys. Thinking that this was an area where I'd best be served leveraging existing software, I started searching for Java based survey tools.

    I quickly found that there is a severe dearth of Java survey tools in the open source community. Most projects haven't been updated since 2005 and all of them seem cumbersome. If I am going to use something, I'm going to make sure it is easy to use and also looks good.

    So, abandoning open source for the moment, I started looking at what was available in the closed source world. I quickly found a piece of software that fit my needs perfectly. Called Opinio, it is a very nicely built J2EE application that can be deployed on anything from Tomcat to JBoss (even IIS, or so they claim).

    It has 3 versions: Lite, Corporate and Enterprise. The Lite version is free for use, but has a much reduced feature set. However, the reduction is in the analysis side and since we're going to be building our own analysis tools, this application fit perfectly!

    My only gripe so far is that it doesn't have a great community or a good set of docs. I'm currently trying to set it up so that it will write the surveys to our SQL Server database. There are directions on the site for setting up MySql and Oracle, but no SQL Server. Once I get the issue solved, though, I may post how to do it, here.

    Wednesday, October 22, 2008

    And the Winner Is...

    JBoss.

    1. First and foremost, JBoss has the best community. Documentation exists for all facets of using JBoss, from developing on it to deploying it to a production environment. Most of these docs exist in Wiki form on the JBoss.org website, but a Google search of any term prefixed by JBoss (ie: JBoss Administration) will return many, many relevant links. This in and of itself is the primary factor for using JBoss.
    2. While GlassFish provides the latest in JEE 5, JBoss is not far behind (actually having a release candidate with JEE 5 support available). Further, we will most likely not be harnessing a lot of the JEE 5 specification. What we will be using of the JEE 5 specification, mainly JSP and Servlet are provided, along with a JAX-WS compliant stack in the form of JBossWS.
    3. JBoss has an Eclipse plugin (as does GlassFish).
    4. JBoss’s system requirements are lower than GlassFish’s.
    5. While GlassFish’s admin console is very nice and very polished (specifically it’s log viewer), the lack of being able to run in a console window is constrictive to development. From a developer productivity standpoint, having to open up a web page and refresh the view to get the latest log files would be detrimental.
    6. Hibernate, the ORM solution we will be using, is a JBoss project, and is built directly into JBoss.

    The choice came down to JBoss vs. GlassFish. I never really considered Tomcat with Metro.

    While I really liked GlassFish, it didn't seem as suitable for a development environment. Both of them seemed completely competent in a production environment, with each having its best features. So, it came down to which would be better to develop on.

    The answer to that question is that JBoss is easier to develop on and it has the most widely available community. Those two factors weighted things to JBoss.

    Thursday, October 16, 2008

    The Purpose

    So, this is my developer's blog. It's the "in vogue" thing for developers to do. I see them all over the place, so why shouldn't I have one, too?

    I've recently changed jobs and am working on a project now that is starting from the ground. I'm also the lone developer on the project. That kind of makes it my show, to a certain degree. I'm responsible to the Customer (who shall remain nameless) and to the Company (who shall also remain nameless) I work for.

    Being in on a project from the ground up is a pretty cool thing. You get to make a lot of decisions that will have a huge impact on the project months, if not years, down the line. Some of the decisions I've already made have been which language I will use: Java; what type of application it will be: a web app.

    A few decisions were made for me, including which database I'll be using, which is Microsoft SQL Server. That suits me fine, as I'm going to try to take a database agnostic approach by using Hibernate. We'll see how true to that desire I can stay later on down the road.

    It does have the up-side, or so I've heard, in that SQL Server is supposedly easy to administer. It certainly seems easier to administer than Oracle, the only other database I've worked with. The tools seem to be a lot more developed and "user-friendly". That's good in my book, as I don't want to spend all my time adminstering the database.

    The big decision I'm working on right now is what application server I'm going to be using. I've basically narrowed it down to three choices. The first is to use Tomcat augmented with the Metro web stack that is available from the GlassFish project. The second is to use the actual GlassFish server itself (or whatever lame name Sun gives it once it's released officially). The third is to use JBoss.

    I'm researching all three right now and I plan on posting here what I find and my ultimate decision.

    So, back to the purpose of this blog. I'd like to document the steps that I take as I build this application. I'd like to make note of the pitfalls I fall into and how I got out of them. I'd like for this to be part history, part road-map to how to do it better in the future.

    We'll see how it goes from here.