Barkeep is very simply code review system.
Your first steps should be to watched video on the project page, next you can simple try barkeep demo page.
What amazed me was usage of vagrant. Vagrant is great tool you should have in your toolbox. Vagrant is tool to simplify environment setup. You can build your development setup, or project setup or whatever you need.
The Barkeep example is great. To run barkeep, we simply do following steps:
and that’s it. At http://localhost:8080/ we can access Barkeep and start using it. For me this is the way we should prepare our stuff.
Note: For Mac user you must have 64bit MySql, otherwise installation will fail.
- bundle exec vagrant halt will shut down the Vagrant
- bundle exec vagrant destroy will destroy it.
Of course for production use you have to install it, but for playing Vagrant is enough.
The good thing about it is that Barkeep has REST API and nice and simple barkeep client.
Of course Barkeep is not only one code review tool. What is said is that “Comparing barkeep to other code review tools” page is a … bullshit.
- Crucible has post review
- Crucible and Gerrit has notification schemas, even Crucible has streams – from my point of view it is great feature.
- Crucible, and Gerrit has nice UI, and it is more we used to something.
- and last but not least, Reitveld has small codebase, so you can hack it without any problems (I would prefer to hack Barkeep – Ruby), and for sure as Java Developer I can hack in both Gerrit and Crucible.
I don’t defend others as I don’t use them, but I think Barkeep guys are not fair.
Despite of that it is very good tool, so for sure you should give a try.
We started with Keynote by John A. Stankovic from Universtity of Virginia, it was really cool keynote. He talk about defense system The dynamics aspects where use to implement mechanism “right defense at the right time”. He describe real life problems with messages encryption, power management and sensor localization. The localization problem comes from that GPS do works only on open space. Thanks to aspects they provide sensor communication protocol. Also power management was treated as crosscutting issue and John describe protocols they develop for this propose. The final John thought is : “Flexibility offered by Dynamic AOP has great potential”.
I went to demo sessions, there was two demos, the first one is out of my interests, the second was quite interesting and open my eyes. I thought that JDK classes and aspect are not woven because of security reasons (this is what AspectJ team claims). Now I know that this issue is due to bootstrap classloader. It makes impossible to wave aspect to for example String class. The demo was about the tool which can do it. There are tools for that purpose called MAJOR and CARAJillo, one limitation of this tools is that JVM classes can only be woven statically. Great stuff.
Industry Panel was about “Challenges and Roadmap for Using AOSD in Industry”. The panel was rather boring. It was very slow and some trash talking: “it not easy to adopt new things to industry”, “risk management”, “academic solution doesn’t scale”, “no trust for aspect”, “company policies ” and so on. Finally one of the panelist said that “Why we should use aspects if OOP currently works well”.There was few examples of industry usage from Accenture and Siemens.
Another demo session, two quite nice demos. First Lavash quite interesting probably not so aspect oriented framework of tools to automatic requirements processing. The second is in early stage and was about suggestion pointcut modification as we write new code. This may be very interesting tool in the future to keep programmers from silly mistakes. I will keep eye on it.
Industry session was more likely as panel. One good tough was that academic researcher should provide tools to make aspects fully testable. There was another aspect language proposal called “e” which mainly differs from AspectJ that AspectJ is focus on classes and “e” language on units. The session was improved by Uwe Hohenstein from Siemes. Uwe shows real project usage of aspects. Despite obvious examples such as connection pool monitoring, performance monitoring. Siemens use aspect to address challenges of integrating 3rd party software in a maintainable manner keeping 3rd party software untouched. Most of the examples comes from Siemens Soarian project.
The last day came so quickly. AOSD is high level rather academic conference, but we should learn from the best.
The conference was started by Keynote. Paul Daugherty from Accenture talk about cost, and how they try to reduce it. 91 from top 100 companies are Accenture’s clients. They have consultants on every place in The Earth. He told that about 60% of cost goes to maintenance and keep live system. The solution is to use many different techniques as SOA architecture and Aspect Oriented Programming. Quite interesting and based on real example speech.
Next three papers was presented: Dependent Advice, Generic and Reflective Debugging Architecture and Expressive Scoping of Distributed AOP. From my point of view the best of them was Generic and Reflective Debugging Architecture. Wouter has showed us problems when we must debugging system with aspect and where is the gap between program model and JVM TI. They write common aspect abstraction and it nearly ready for use. Great job.
After Lunch I went to Demo sessions. First demo was quite interesting made by Siemens. Product Lines – features as aspects was about deliver features as crosscutting concerns implemented as aspects. Often our product is deliver to different client, and must get special features. Implementing this features as aspects can help us to keep product dependencies low and to deliver high quality software.
Next demo “Building a next generation digital news publishing” shows how introducing aspect helps to refactor and simplify code base. The problem was that news are deliver to different consumers (RSS, WWW, subscribers etc.) By using aspect they keep one source of news and many different consumers.
After break I saw demo “Druid – unexpected interaction detection”, it mangos the problem when introducing aspects can break other module tests. They make topological sort of modules and than executing junit tests, checking if something break if so, they provide special metadata. This metadata build graph about dependencies and unexpected interaction. It may be used also to detects if every feature in module has it’s own test. The work is workable plugin for eclipse. The better integration between TDD and AOP. I talk with Andre Restivo and if you want to provide version for NetBeans or InteliJ feel free to contact with Andre. There is some kind of console magic so the plugin actually work only on Linux but should be no problem to port for OSX. There are some problems but you can download and try it now. I think that I will try to write port for InteliJ.
The next day begin. Stay tuned.