I am experimenting with OpenDolphin after a while of being interested in it's concept,
I am at the defining requirements phase with some friends for a project we want to make with hopes of earning some money from it this project's concept will be based on a server/multiple-client model where we want the server to have most of the logic, we have average to little experience couple of years each doing java projects but not anything big or exactly with the latests tools, so we struggled a little bit understanding the building process of the gradle setup, and after running this project, we are now faced with tons of groovy projects demos.
And I am struggling to keep my friends interested in the library as they think using what we know best is a better option than trying to understand a library that would mean to learn asap a new language
(we are not that lazy but there is some people that is helping us as consultants/associates and we are afraid that if we dont start producing something we are gonna lose their support [we are not earning anything from this yet but without them as "productowners", we wouldnt know what are exactly the market needs]).
I have watched multiple videos and videos like this: http://www.youtube.com/watch?v=z54hEJvpZys
are amazing , I think that is exactly what we need.
I would like to know if maybe there is an example/tutorial in java maybe a screencast,blog or recorded webinar of how to make a simple application where the server binds to a port and multiple java clients update the value and sends a pair of commands.
I dont know something like server starts, puts a default value in a variable, client connects and sees value, second client connects sees value, and a command is sent to server "erase", and both clients see that the server erased it and another command is sent "default" and server sets variable to default.
I am not asking for that exact example but something that I can read to make it like that.
I tried making something like that using the .8 release and I was utterly lost, but i think that an easy example like that could help me to make them see how good of a tool this is,
"Install this in your laptop, that's the server run it and see how my client and yours are synched automagically".
Ok, you made a good choice of technologies :-)
It appears that the Dolphin JumpStart project (https://github.com/canoo/DolphinJumpStart) covers exactly that combination: OpenDolphin with Java, view in JavaFX, built with Gradle (use dist/jumpstart-gradle.zip) and jetty as the minimal server implementation.
The Jumpstart project is also explained in a step-by-step fashion as part of the OpenDolphin user guide (http://open-dolphin.org/download/guide/guide/howto.html).
Concerning your question about the shared tacho demo: this demo is using only one server that all clients connect to. The "clients" update each other over the server-side event bus. To that end, we do not open any specific sockets. It is all plain HTTP POST that goes trough all proxies and firewalls and needs no special infrastructure.
your concerns are very understandable.
First let me clarify that you can use Java, Groovy, JavaScript or any other language that runs on the JVM with OpenDolphin. What would be your preferred language for a demo?
For a demo that shows many clients that share a common value, I would recommend the SharedTachoDemo.
As for making the build setup easier, we do have to make choices in the demos since there are so many combinations of build system (ant, maven, gradle), structure (all-in-one, multi-project), implementation language, IDE integration (intellij, netbeans, eclipse), server infrastructure (jetty, tomcat, grails, glassfish, jboss, weblogic, webshpere, ...), and last not least the intended UI toolkit (Swing, JavaFX, HTML5, others). If you tell me your preferred combination, I can point you to the respective resource or create one for you.
cheers, Dierk
I have been developing a static program analyzer (a kind of tool that attempts to detect program errors at compile-time), and it is almost finished. I would like to put a demo version to the web so that the few people who may be interested into the tool can test out its functionalities.
Context:
1. I have a personal computer to be used as a server if necessary. Otherwise, I am not sure if it is technically possible to put the demo to the computers of my institute because their computers do not have the required library used to launch the demo.
I am using Eclipse and Maven to develop this analyzer. The analyzer is written in Java.
The analyzer is somewhat time-consuming. It takes, for example, 5 seconds and 500 Mo JVM virtual memory to do an interesting work. So I need to limit the number of accessors.
I do not plan to send the .jar files to the clients, because I don't know who they will be.
I know nothing about the web application.
Under this context, what is, in your opinion, the easiest way to demonstrate my analyzer on the web?
This may be a different question from most questions about how to convert a desktop program to a Java web application, such as this
Thank you.
[EDITED] What would be the best solution if the constraint 3 above is to be taken into account?
You may be looking for Java Web Start, a deployment option used by the popular analyzer, FindBugs. This example illustrates few key concepts and leverages minimal-cost hosting.
Addendum: #Capn Sparrow helpfully comments that Java Web Start downloads copies of the program's JARs from the server to the client, violating requirement three in the question. This entails several risk/benefit tradeoffs:
Pro: The server can be easily updated to ensure that the client always has the latest version. JARs are cached on the client, minimizing latency on update.
Con: The cached JARs may be decompiled or tampered with. The user must accept whatever <security> setting is chosen or reject the application. Using jarsigner can mitigate some risks.
I'm trying to find some java code with it's test suites, which includes all changes happen to test cases overtime(adding updating and deleting) after updating the code. Where do you think I could find this kind of repository that track changes to the source code and it's test cases over time.
Thanks in advance folks.
It is best to divide your needs into separate categories, and then find tools that cover the category.
I'm trying to find some java code with it's test suites, which includes all changes happen
to test cases overtime(adding updating and deleting) after updating the code.
A source code control system tracks changes to all revisioned files over time. There are many different source code control systems, but if you are starting out in source code control the documentation is more important than the specific system. I suggest subversion, which has excellent documentation here.
Under such a system, source code is checked in, which allows tracking of changes over time. Typically test cases are also checked in (usually in a different directory) and changes in test cases are also tracked over time.
Subversion is not the only solution, almost any source code control system will do this task. I recommend subversion because you are likely to see it again, it has excellent documentation, and some of the most advertised features of other systems are not understood until some mastery of source code control is obtained.
The actual source code is another matter. I think you want to write your own, but if you are looking for someone else's source code, there are many projects at apache.org or sourceforge which give some examples of how other people solved their problems using a source code control system.
Where do you think I could find this kind of repository that track changes to the source
code and it's test cases over time.
You can find subversion at http://subversion.apache.org/, and if you don't want to install your own private subversion server, you can find hosting providers which will install and run your subversion server (for a fee). I recommend you install your own server at least once, and to start I would also recommend the svnserve version of the server. After you get a feel for how source code control works under subversion, you might consider a https installation.
We have some service running on 'n' number of hosts behind a VIP. When there is some fault that occurs with specific request call, we might be interested to know the reason by looking at the logs on the respected host where the fault occurred. since the request could go to any host, when it comes to tracking logs, we need to know from which host the fault originated.
One solution is to store the host name in the database of our service along with other information.
The alternative is, pushing the logs onto a common store and tracing it there.
I personally feel that if we go with the first approach, we might end up in adding many such debugging related attributes in the application database thereby polluting it. However the second option is also not that easy to implement and incurs some overhead. Moreover on which host the fault occurred does not help much except in case the fault occurred due to some hardware specific issue.
What do you guys suggest?
Without knowing more about your infrastructure, it's hard to be precise, but here are some general points of view.
I don't like using databases for storing application logs - if the database falls over, you wouldn't be able to log it! It's also not really relational data, and you can't get the monitoring tools that are available for other solutions.
My recommendation is to use your operating system's built in event logging solution; most logging frameworks support this out of the box. On Windows, that's the event log; on *nix there's the syslog system. Logging should be quick, cheap, and bullet proof - that's what you get from the OS tools.
The second question is then how you use those logs for trouble shooting and monitoring. There are lots of tools for doing this, though mostly aimed at system administrators rather than developers. Microsoft have MoM, there's Tivoli and Big Brother - as well as a whole bunch of open source tools. I'd use those, rather than build your own solution.
The key point is - logging should be fast, cheap and robust; the analysis and monitoring stuff should be entirel separate from your application logic, so you can reuse the tools and processes acros multiple projects.
storing the hostname should be quite cheap I guess. I understand you are appending logs to a db?
you could also store the pid for each process, that can help you in case you have multiple processes running on same hostname. The combination hostname/pid/timestamp will ensure you identify uniquely a process.
I'm setting up a Java development shop, currently just for myself as the only developer, but with hopes of needing to hire others as the business grows. Obviously I'm hoping to set it up right so that as more people come in, they can be productive right away. Please help suggest things I want to do, and tools to do them.
Here's what I think I need:
Distributed source code/revision control (Subversion?)
Bug tracking (does Trac do this?)
documentation (both internal and customer facing)
team communication
frequent automated building
maybe something to make sure automatic tests pass as part of the check-in process?
I like Hudson for Continuous Integration builds, and I like JIRA for issue tracking. Eclipse has plugins for both.
Hudson can watch software repositories and rebuild those projects that use the changed resources.
If you need more documentation than javadoc can cover (which is quite a lot) then consider a Wiki. Easy to use, and with a bit of structure you can massage it into a PDF.
Source control is a bugger. Too many to choose from. For a small development team start with either subversion or CVS (which is old but has supreme IDE support) and when you outgrow that and know your needs, then migrate to a better one. Most have migration tools from svn or cvs. It is harder to move from e.g. git to Mercurial, and you defintively want one with more than one implementation. Remember to have good backups of the source control repository - it IS your business. Frequent rsyncs, often tapes.
EDIT: You also want decent hardware. For the Continuous Integration server, the fastest build machine you can afford. For yourself the largest monitor you can afford (not in size, in resolution) for your primary monitor and as many extra monitors as you can afford to have (including adapters to your computer). I have found that Mac's use the pixels better than Windows, so that might also be a point.
My primary monitor is pivoted 90 degrees. This allows me to see many lines at once instead of a few long lines. (For some reason tradition says that editing areas should be wide and short, which may work in word but not in code where lines should not be wider than 72 characters)
Note on Eclipse: Use the source repository to have a single workspace per project! Use the Java Editor Save Function to reformat your code everytime you save - this makes it more readable up front, and goes better with the source repository as changes are marked in the correct version.
Edit: The reason for the CI server needing to be better than your development machine is because it will run all your tests every time you check stuff into your source repository. After a while, that WILL take time.
Personally I have found tests working well for library routines. They specify what works and what doesn't. It is harder to write good tests for whole applications, but you may want to look into that from the beginning, as it allows you to ensure that everything works for every check in. Write a comment if you are not familiar with the concept.
Whatever you choose for the individual parts, you will be glad if they can work together. Hudson knows how to talk to JIRA for instance. JIRA knows how to look in CVS.
To see what a big amount of people thinks to make a good software development environment read this article on the 12 points of joels test
This list does not include the things more important for you. Getting clients getting them to pay and manage legal stuff and taxes.
Most important, the right staff:
get great people who find work and handle customers (aka sales)
get software engineers who are smart and get things done (http://www.joelonsoftware.com/items/2007/06/05.html)
get someone who knows about accounting and the local legal and tax regulations, so you don't get any surprises
Tools / Processes:
use a distributed version control system like git or mercurial
jira or the like for bug/issue tracking
continuous integration with hudson or cruisecontrol
wiki system to share the teams tangible knowledge
unit tests, clover, checkstyle, findbugs, ...
From a managerial point of view i would try
daily standup meetings (checkout scrum) to keep the team updated members to commit by saying what the did, do, and will do
timeboxed meetings, everything else sucks.
plan iterations/sprints
let team do task time estimations
pair programming (gets you better code)
code reviews (builds trust)
weekly in house "techtalks" to build a strong sense for the team
twitter like communication tool to keep all insync and informed with minimal distraction
develop team towards dynamic languages (groovy, scala, ...)
yourself, listen to what the guys at http://manager-tools.com/ have to say...
good luck!
We have been using:
version control:
subversion - Its not distributed but it is accessible over a few different protocols if firewalls are an issue. I'm not sure if distributed version control is necessary for us and reading Eric Sink's take is entertaining at least
issue tracking :
Fogbugz - You get some team discussion and communication for free with it because of the built-in wiki and discussion boards.
continuous integration:
CruiseControl - we had been talking about switching to Hudson, but Cruise is working really well right now - it runs our unit tests.
dev environment:
Netbeans and Eclipse - There is really no reason to pay for a Java IDE. An import point for getting going fast is that Netbeans and Eclipse both store all of their project data as text files which version control nicely. See this question. We had giant headaches when using an IDE which used binary project files.
profiler:
JDK VisualVM - Its free and it works. I used to really like YourKit, but VisualVM does so much now.
documention:
Combination of javadoc and fogbugz wiki pages plus the cruise dashboard for internal. For external we are using RoboHelp and we dislike it.
other tools:
Findbugs - huge help in catching things that are sometimes really stupid and sometimes amazing quirks that you'd have never realized. PMD is good for some of this as well.
We find chat tools to be really helpful for communication. We used to have access to Sametime and it had a giant conferencing feature that was really great. That was taken away for an unknown reason by the overlords though.
Here is what development stack our team of five developers is using over a year now:
Eclipse IDE (worked better for us than NetBeans)
Maven as a project comprehension and build tool -- simply a must tool!
Nexus: The Maven Repository Manager -- serves as a local Maven repo for proxying, and for managing internal and 3rd party libs; simple in use and is really necessary if you're going to use Maven
Subversion for source versioning -- was chosen mainly due to very good IDE support (Subclipse for Eclipse IDE)
Trac as a bug tracking and requirement management tool -- it nicely integrates with Subversion, has very useful plugins including blog and discussion plugins; also it can be integrated with Eclipse Mylyn.
Hudson as continuous integration, which nicely integrates with Subversion, Maven and Trac -- very valuable even for a small team.
Sonar code quality management platform -- a tool which integrates a large number of code quality matrix with intuitive web interface supporting code review and drill-down facility for analysis of the problems; integrates with Maven.
In our case this development stack is running under Ubuntu (workstation components: Eclipse IDE, Maven) and CentOS (server components: Maven, Nexus, Subversion, Trac, Hudson, Sonar).
As for the documentation, LaTeX (TexLive and Kile under Ubuntu) works just great supporting high quality PDF generation. The documentation source can be managed by Subversion the same way as the application source. Allows making of simple several page document and large multi-chapter books.
Hope this helps.
Distributed source code/revision control (Subversion?)
Subversion is good enough unless you want to use this as an opportunity to learn Git or Mercurial.
Bug tracking (does Trac do this?)
Trac works fine if you don't mind CamelCaseTurningIntoWikiWords. JIRA is fancier but (as noted) not free, and I find its data-ink ratio annoyingly low. Good once you learn which parts of the UI to ignore, though.
documentation (both internal and customer facing)
Internally, I would prefer communication over documentation unless you're really willing to commit to spending time keeping internal documentation updated. Javadoc your integration points (internal/external APIs), but try to keep your code and build scripts as self-documenting as you can.
That said, requirements docs are useful. I'd suggest using one tracking system for bugs and requirements. JIRA lets you create hierarchical issues, but I wouldn't bother with that till you need it.
Trac includes a Wiki, which can be handy although too much content will get stale.
Customer-facing docs are all over the map -- depends a lot on what you're doing. If you need big fat manuals (either printed or HTML or on-line help) FrameMaker + the DITA Open Toolkit is a nice combo, but a FrameMaker license is going to set you back $1000.
At a certain point this shades into corporate communications (marcom and PR), which are kind of a different animal.
team communication
Google Talk (or the instant messaging framework of your choice), email, and the occasional Skype teleconference are probably all you need.
An internal wiki and/or internal blogs might be nice but you probably don't need them right away, even once you've added a few more developers. Trac includes a wiki.
frequent automated building
Switching from CruiseControl to Hudson has made everyone here much happier -- two teams made the same decision independently and both are pleased with it. Hudson's flexible, easy to configure, and shiny.
I have yet to be convinced by Maven. I suspect its value depends on how much you want automated downloads of the latest versions of all your open-source libraries.
Edited (Feb. 2010) to add: Several months of Maven 2 experience now and I'm still not convinced. I think (like many frameworks, e.g. Rails) it may work well if you're starting from scratch and structuring your project according to its conventions, but if you already have your own structure in place it's a lot less advantageous.
maybe something to make sure automatic tests pass as part of the check-in process?
I'd advise against it. Most of the time the tests will be passing (or should be, anyway) As long as continuous integration notifies you quickly of failures, and you also have stable automated builds (a couple of days' worth of nightly builds, tagged iteration builds, etc.), you want more and faster checkins, not fewer and slower.
Subversion is not a distributed approach -- go for Mercurial, Bazaar or git instead!
Yes, Trac does do bug tracking (among other things -- check it out!).
Documentation is indeed a must but I'm not sure what you're asking -- tools for it? Why not just javadoc?
For communication you can have many tools, such as skype, email, IM of many kinds, and so forth -- you need to express your specific issues better to get specific advice, I think. Google Wave once it matures may be just great, but it's not production-ready yet.
For continuous build check out CruiseControl -- of course it also run tests &c.
You can write "triggers" for any of the build systems I've mentioned (and even good old svn;-) to run some test suite and reject the commit if it fails.
A few more items:
IDE
Billing Software - will you be charging by the
hour? If so you might want to track
what your time is going towards.
offsite backup of some kind.
Each one of your bullet points is probably worthy of a community wiki by themselves. Though in the end you might not care so much about best of breed in each area, but care more about how well they all integrate with your IDE or with each other.
Also, if you really want to get new teammates up and running quickly, consider putting as much of your dev environment into source control as you can, so you can just checkout your "dev-env" project onto a new computer and be up and running instantly!
One of your specs (in your question) says:
maybe something to make sure automatic
tests pass as part of the check-in
process?
I would suggest this is essential. Check out this matrix of continuous integration servers to see which one fits your requirements.
If you're starting off with just yourself as the only developer but scaling up at some point, depending on what it is you're developing, it might be worth to check out a Platform as a Service (PaaS) offering, like https://www.openshift.com or https://www.heroku.com/, both which offer developer accounts, but you can scale up to paid accounts as and when needed.
OpenShift have CI cartridges for Jenkins so you can spin up DVCS (git), CI using Jenkins, and an app server like JBoss AS or WildFly all in one go in a matter of minutes... depending on your needs and how much time you want to dedicate to setting this up yourself locally, I'd be more inclined to look at using a PaaS.
Rather than use Trac, consider Redmine. It allows you to have multiple projects stored in the one issue tracking system. You can then use the same setup for each project, rather than having to have N instances of Trac.
For starters, SVN will be enough for you. Definitely get a bugtracker. JIRA is good but isn't free. Enforce a rule "No commits without a bugtrecker ticket". This way you will be able to track the development. Do a cruise control and run a build + unit tests after every checkin into the main branch. Bigger changes should be made on a separate branch and then merged into the main branch.
Invest in a good IDE (I recommend intelliJ IDEA) and a good profiler (I recommend JProfiler). They're not free, but they are definitely worth their price.