Eclipse is turning 10 years – and we have been in a mood to celebrate it. We have been involved in a lot of Eclipse related events in the past, but wanted to do something special this year.

If you are in Boston, come join us next week. We will be having free pizza, beer and even a birthday cake. We will have a bunch of people who really know Eclipse inside-out and will be showcasing a bunch of the cool technology being built these days.

Time and Location: We have planned to have the event on 17 November 2011 at 6:30PM, at Constant Contact, (Reservoir Place, 1601 Trapelo Road, Waltham, MA 02451 – see on map).

Here’s what you’ll get to see in this month’s Eclipse Demo Day:

CodeMaps.org – by Architexa

Architexa will demonstrate CodeMaps, a site built to help developers to easily understand Open Source projects from their web browsers, and the result of the exploration can be documented and shared online.

Code Sight Code Search – by Black Duck

Black Duck will demonstrate Code Sight, a free code search tool developers can use for their everyday search needs. This short demonstration will include searching and filtering capabilities that make finding code easier.

Open Source Jenkins CI – by CloudBees

CloudBees will show you how to use open source Jenkins CI to leverage agile development. Additionally, you can manage your development work and projects – all from within the Eclipse IDE, using the free plugin provided by CloudBees!

Orion Demonstration – by Eclipse

Eclipse will give a short demonstration of Orion, an online editor that runs in the web browser using javascript. Unlike other attempts at creating browser-based development tools, this is not an IDE running in a single tab. Links work and can be shared.

Eclipse Apricot Project – byNuxeo

Nuxeo will present the Eclipse Apricot project and introduce how to develop content-centric applications with Apricot project and with the Nuxeo IDE Eclipse plugin.

If you want to hear more information, you can visit Eclipse Demo Day or contact Sarah at sgerrol@blackducksoftware.com.

You can register for the event at Eclipse DemoCamps November 2011/ Boston.

When development teams are in the same room, it is not surprising to see diagrams being used – if only being shared via sketches made on pads, or through the use of whiteboards. Interestingly, despite the fact that OSS teams are distributed geographically, diagrams also play an important role in OSS development.

There was a helpful research done by Koji Yatani et al. at University of Toronto and Oregon State University. They studied developers on the Ubuntu project and found that developers create and distribute digitalized diagrams as opposed to physical sketches. While the uses of diagrams are specific to the Ubuntu projects, there are definitely lessons that we can learn to apply in other OSS projects to ensure successful development.

read more »

“Diagrams?”

Yes, diagrams. All of us use diagrams in one way or another. Mostly, diagrams are used to enhance communication and to illustrate what exactly one is talking about.

“But that’s it. Diagrams are sketches which are meant to be thrown away without deserving a second look.”

Now that’s where you’re wrong. In fact, diagrams are more useful than they appear to be. Yes, diagrams often become outdated fast in the software development industry and that tends to lead to people having a biased view against them. They often quickly assume diagrams are useless.
read more »

What exactly makes a codebase easy to understand; the documentation or the tools that you use? In our effort to help developers who are working with large codebases, we conducted a survey (see details and highlights) to find out what techniques developers use to better understand code.
read more »

Let’s face it; code can be hard to understand. We have all encountered a piece of code that took longer than expected to figure out or was easy to misunderstand. It could be a new library, a coworker’s code, or your own code from 6 month’s ago.

read more »

Every developer cares about code quality. But how do you maintain code quality throughout the software development cycle? Readability, modularity, and efficiency all are important factors of writing good code but there isn’t much agreement on the best way to maintain a high level of code quality.

One factor which is often missed in discussions is code visibility, or making sure your code has a clear structure so that others can easily understand it. (Take a look at the diagram above for some of the difficulties encountered when there is a lack of code visibility).
read more »

It is easy to find numerous negative sentiments about UML. The main complaints seem to revolve around UML being of little practical use and inconvenient to draw and update.

I have been looking into the practicality of UML and find this answer on stackoverflow very interesting:

Using UML is like looking at your feet as you walk. It’s making conscious and explicit something that you can usually do unconsciously. Beginners need to think carefully about what they’re doing, but a professional programmer already knows what they’re doing. Most of the time, writing the code itself is quicker and more effective than writing about the code, because their programming intuition is tuned to the task.

My question is: Is it all that bad to walk while looking at your feet? It is often said that learning to walk is one of the hardest skills a person has to learn. However, in time walking doesn’t seem like a “learned skill” anymore because we do it so much that it seems natural. But what happens when we are walking along a tricky path strewn with pebbles, banana-peels and the like; wouldn’t we feel safer to look at our feet as we walk? read more »

Managing software developers can be a difficult task, especially when working with an agile team. Changing requirements and priorities combined with a learning and growing team can make even the most experienced managers sweat.

Similar complex interactions have been studied in a number of fields. Game Theory, Cybernetics, and Chaos Theory all provide inspiration to managers looking to ease communication and improve the performance of a team. These theories along with many others fall into the category of Complex Systems. But as developers we need to be careful when utilizing concepts from other domains or managing developers may become an exercise in herding cats.
read more »

Today Architexa’s “Working With Large Codebases” blog has posted it’s 50th post. While not a huge number, we are excited to see the response to so many of our articles for helping developers work with Eclipse, with agile teams, use design patterns, and document and communicate ideas  with developer tools and diagrams.

Architexa has been working on the performance of our diagramming tools, and conducting user studies to find more about what it takes for a developer to understand code. We have also been improving our Open Source documentation site codemaps.org.

With all the articles out there helping developers understand code, we were wondering what type of information you would like to see more of?

photo credit: Imagery by Pete

We are looking forward to providing much more interesting content in the coming months. Please let us know what you would like to see. Send us your favorite articles from our site or across the web.

I came across two blog posts which agree that large code bases are a hassle to programmers. The first post, “Code’s worst enemy” written by Steve Yegge, basically loathes large code bases and Jeff Atwok shares the same opinion in “Size is the enemy”. The problem with large code bases is that their physical size is indication for the large amount of effort, cost and time to be invested for that project, as stated in Steve McConnell books.

read more »