WattDepot 3: It just got real

[Philip Johnson]

It is looking very likely that we have will significant commercial deployment/sponsorship of WattDepot 3 in 2014, and so I would like to start a discussion on how to improve the "development scalability" of the codebase.  So far, Cam has done a fantastic job developing an essentially one-person, spike solution. I think we're now at the point where the project will benefit from: (a) automated quality assurance, and (b) some additional eyes and time on the codebase. 

Here are some things I'd like to see:

(a) Continuous and/or daily integration:  Checkstyle, JUnit, Jacoco, JavaDoc

(b) Continuous and/or daily deployment: Heroku?  CloudBees?

(c) Documentation: More organized and centralized.   HTTP APIs, user guides, and javadocs all available from a single location. 

(d) Commits from more developers than just cmoore.  I am willing to start putting in a few hours a week as soon as the semester ends, at least for a few months.  Robert, where are you at? Can you help?  Are there other Aarhus folks that might want to get involved? 

(e) Google Summer of Code.  If we can do the above, we have a shot at becoming a sponsored project this summer.

(f) try-with-resources.   I really think we should investigate this Java 7 feature as a way to manage thread-session-transaction pool exhaustion. Note that without it, it is difficult to reliably close all sessions/threads/etc when exceptions occur. 

I don't think Cam can do all of this on his own (or, rather, I am sure he can do this all on his own, I'm just not sure he can do all this on his own without becoming grumpy.)

Philip

[Yongwen Xu]

I am very interested in helping out with wattdepot 3.

I could work on the following initially:
1. cloud deployment  (preferably heroku)
2. Google visualization support

I think i could allocate 1 day per week on this project, at least at the begining.

--
You received this message because you are subscribed to the Google Groups "wattdepot-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wattdepot-use...@googlegroups.com.
To post to this group, send email to wattdep...@googlegroups.com.
Visit this group at http://groups.google.com/group/wattdepot-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Philip Johnson]

Another to-do: architecture-level description.

Here's an interesting post: are we using an onion architecture?

http://www.planetgeek.ch/2013/11/26/chop-onions-instead-of-layers/

Philip

[Carleton Moore]

(f) try-with-resources is a good idea, but the resources in the try block must implement java.lang.AutoCloseable and the Hibernate Session doesn't implement the interface. We might be able to subclass the Hibernate Session and implement the interface. I haven't looked into how hard with would be.

[Robert S Brewer]

On Thu, Nov 28, 2013 at 8:13 PM, Carleton Moore <carleto...@gmail.com> wrote:

(f) try-with-resources is a good idea, but the resources in the try block must implement java.lang.AutoCloseable and the Hibernate Session doesn't implement the interface. We might be able to subclass the Hibernate Session and implement the interface. I haven't looked into how hard with would be.

It also makes WattDepot require Java 7, but I guess that's acceptable at this point. I assume all the OS X folks have switched to Oracle's JDK 7?

[Philip Johnson]

A little more googling seems to indicate that Hibernate already has an autoclose feature.  

Here's a stackoverflow question/answer with some interesting details:

http://stackoverflow.com/questions/4040761/control-the-hibernate-sessionwhen-to-close-it-manually

Philip