Posted by rtholmes on March 5, 2012
Jordan Johns writes:
The second month of the UCOSP Winter 2012 Umple project has been quite a good experience for many involved. Everything from bug fixes, compiler enhancements and new features have been accomplished thus far.
It has been a really good experience. I’ll start off by mentioning what has been going on with the others students.
To begin with we’ve had James who has been diligent in working on enhancing the capabilities of the compiler, by enabling additional command line options. A particularly good use of the recent enhancements in this aspect are that you can specify the output language of the generated code on the command line; his objective is to enable the Umple compiler to compile the Java, so any Java error messages appear as Umple error messages.
Sonya has had a breakthrough with enabling a rather useful feature to Umple: class-evel immutability. With this new feature, those who wish to use Umple to build systems in, lets say, Java can create immutable classes with ease.
Another good addition, that is in progress at the current moment in time, is SQL code generation. Adam has been making some headway in this regard and soon we will have the ability to create usable SQL code from the Umple code we write.
With respect to primary enhancements this is where we’re at currently, however bug fixes have seen quite a bit of progress. Luna has been working on fixing deletion of 1-* associations at the many end in PHP and Ruby; this currently fails. Another fix being worked on by Song Bae is to fix a rather interesting problem in UmpleOnline where class names do not correspond to association names when the former is changed.
My tasks have been fixing issues mainly associated with the compiler and providing maintenance in relation to codebase documentation. I’ve made a decent amount of progress on this I think.
To start off with we’ve had a issue where you could write comments in your Umple code but when you generate code from it, such as Java code, not all the comments would appear. Although the generated code is not intended to be read by developers (e.g. it ought to be treated in the same manner as bytecode or machine code), there are two reasons why comments nonetheless need to appear: First is that tools such as JavaDoc or Eclipse ToolTips generate API documentation from the comments; second an objective of Umple is to demonstrate what good-quality generated code would look like. The lack of comments meant, for example, that those developing Umple itself couldn’t make good use of any internal documentation.
The initial learning curve a while back was essentially this, figure out how the codebase is working and look into fixing this problem. As it turned out this meant that I had to get really familiar with the compiler parser to ensure that comments follow out to the generated output. After learning the parser and getting acquainted with a few different areas of the project I was able to fix the problem, which now allows comments of consistent format to appear in generated code. This is quite good, because now internal documentation problems can be solved which is what I’m currently trying to do.
I really like the codebase and wish those who follow to have a solid base to work off of, and knowing the learning curve associated with a very large codebase I want to ensure they have good documentation to assist in that regard.
So everything from compiler enhancements and new features to bug fixes and internal documentation (maintenance), I would say good progress is being made. I personally really like the Umple project, the mentors are extremely knowledgeable and always willing to assist when there is a problem. The project itself has a good purpose and I think others should try it out and use it. It really does save time to create a system really quickly since you essentially write a little bit of Umple code and get a lot of consistent workable generated code in almost any language from Java, C++, Ruby or PHP. I definitely see Umple as a great project to work on, thus far I have enjoyed it, and I hope to see how it turns out later on.
Posted by rtholmes on February 27, 2012
Aimen Khan writes:
Recently I have been introduced to two new development tools; GitHub and ReviewBoard. In this blog I am going to talk a little bit about each and my experience with using these tools.
GitHub is one of the largest code hosting applications, which provides an ease of sharing codes online and allows other coders to contribute to different projects. GitHub has several advantages; it fuses the best features of a social networking site with a code-sharing forum. Just like a social networking site it has news feeds, followers and a network graph that shows details of how developers have been working on their version of repository. Individuals have options to work on a repository and other individuals can fork it and follow them.
For MarkUs we have placed our code on the MarkUs repository. All the other developers that would like to contribute to the project can fork it and download the code on their local drive and continue working on it. After working on their part of the code it is posted on the ReviewBoard. Other developers that are working on the project then review this code, discuss potential modifications and if satisfied with the results, they are then able to Ship It! Shipping basically means creating a pull request on Github so that the new code can be merged with the existing code on the repository.
ReviewBoard is a web based code review tool that provides simplicity of reviewing code online. It removes the extra effort and time that has been given in the past to reviewing code. It has the tools to identify or highlight, which line of code has been removed and which has been added or changed, making it easier for coders to track the changes. It also allows users to add comments on the screenshots and the changed code.
In my experience working with GitHub and ReviewBoard has been wonderful. It has made it easy for me to work on the code and also keep up to date with the current changes that have been made on the code. GitHub provides the option of keeping a wiki, posting issues, providing notifications and updates on newsfeed. ReviewBoard on the other hand provides the opportunity to post the diffs online and make it easy for discussing the different parts of the diff. These two tools facilitate the sharing of code and remove the barriers that developers face while sharing and reviewing code. Basically these two are great tools for software development and work great with open source projects.
Posted by rtholmes on February 15, 2012
Curtis Muller writes:
We all know Review Board is great for allowing a distributed team to effectively ensure only high quality, standards complaint code is integrated into the end product. But what else makes Review Board great?
From my experiences on the team I can safely say it gives new developers a leg up on the learning curve when starting. I was able to leverage Review Board to quickly learn exactly what I should, and should not be doing in my code. Through each new code review I was determined not to repeat the same mistakes that were made in my previous review. The intuitive review interface clearly communicates these mistakes back to the developer, allowing them to make the changes and learn from their mistakes.
Review Board also acts as an effective communication platform for any distributed team utilizing it, as it allows the entire team to see the progress of each component, and add their own input to how the end solution should look. This is very important, as communication is one of the toughest aspects when working with a team not based in one site.
I started off in the Code Sprint by getting my feet wet with a couple bugs and a small project. Due to the fact that I haven’t used Django recently, and that the Review Board code base itself is quite large and complex this meant I was in for quite a steep learning curve. I have now moved on to my second project, which itself comes in two parts. The code based part of the project is a rating extension which will allow users to leave anonymous feedback on the quality of the code reviews they receive, while also tracking their own aggregated results over a period of time. These results will allow users to reflect on their code reviewing habits, and make improvements if necessary. This project will be leveraging brand new scripts to simplify the extension building process, by templating out the base code required for an extension to exist in a Review Board instance.
The second half of this project will involve writing documentation to guide others using these scripts on how to take their extension stub and turn it into a functional and integrated part of their Review Board environment. A lot of developers get the idea that by adding this “one feature” to the project, it will vastly improve their experience using Review Board. This has many problems however, because if every one of these features are added they will start to bloat the code base, making Review Board run slower and harder to maintain. This also requires developer hours, which could be spent working on other features which would benefit more than just a handful of developers. Adding this “one feature” also runs the risk of alienating other developers with features or functionality they don’t need, want, or understand. The great thing about extensions is that they allow these developers requesting the feature to easily create and add the feature to their own instance of Review Board, without impacting everyone else’s experience.
It’s great to be able to work on such a far reaching project like Review Board, and know my improvements are being used all across the world. The project could not be nearly as successful without the big effort put in by each of the mentors. Their ability to offer prompt code reviews, technical guidance, and project ideas really makes working on Review Board a lot of fun. Due to their efforts, more time is spent in the learning or “eureka” phases of development than stuck in a frustrating roadblock.