A lot has been written about blogging and working on open source projects to improve your coding skills. They are great ideas. In addition, I like attending user groups.
But there is more. Becoming a great software developer also means making sure you are able to think as the situation demands, as opposed to being biased in the manner that your current project is developed. It means making sure you are comfortable building very different types of projects.
Working on a software project after it has shipped for 1 or 2 years can be fun. But sometimes you feel like you need to do something a little different – to get different ideas, different perspectives, and different types of challenges. I feel like I am in the midst of such a journey, one that has begun to have some results that were unexpected when I started. The big lesson has really been that I need to *talk* to more people about coding.
Diagramming tools can help you to quickly understand a new project, debug code, visualize and enforce usage patterns, and quickly generate high quality documentation. All good. However, not all tools are created equal and there are lots of legacy tools (UML has been around for a while). I wanted to take a look at what is out there to get a sense for how these tools are evolving.
Below is a slice if you will through what are some next generation offerings in software development, tools that are trying to do something different, and some well established old-guard tools that everyone has heard of and compares all comers too.
Debugger Canvas Debugger Canvas by Microsoft (see video) is based on Code Canvas which was developed at Microsoft Research in collaboration with the Code Bubbles folks from Brown. Debugger Canvas is available to premium Microsoft Visual Studio license holders. I love how you can view a GUI widget, its documentation, and implementation side by side in one clean view. The development metaphor is very different from a traditional IDE.
I am a big fan of open source. I use it every day, and recommend it often. But I do want to have a balanced perspective on it. I recently posted about the pleasures of using open source. This is the other side of the coin, the pains of using it.
My hidden agenda about talking about such problems with open source usage is so that we as a community can come up with solutions to some of these challenges. But first, I really want to hear and write down the main challenges, so that we fix the right problems.
I have previously written about how lack of decent software documentation can cause problems in doing what we developers love to do, deliver functioning software. Documentation, code comments and good variable naming are all key to understanding code. This applies to both code that we write and applications that we use through their API’s. We could just as easily be looking at C/C++/C#, Python, PHP or any language but for now let’s stay with Java (read more about advantages of Java over other languages at theappsolutions.com .
I want to illustrate how useful diagrams are in understanding an existing complex Java code base. Understanding code quickly is particularly important when inheriting a new project or trying to figure out how to use a third party package or open source project. As we all know we are typically faced with tight deadlines, limited resources, and herculean objectives. Sound familiar?
We’re happy with how this blog has become a resource for developers. We want this to grow, but are also excited with the new releases that are coming. Stay tuned to
www.architexa.com/blog for Architexa releases, events, and other things that the team is doing.
Software documentation is one of those things that is sorely missed when it isn’t there. Why is it the last thing that any of us developers wants to do? It seems that it is easy for us to ignore documenting in the heat of the situation, but we always get burned in one of many ways.
Now, I have used Spring in the past, and am really a big fan of what they have done. But, these days, I keep thinking of ‘bloated’ in association with them, and wonder if their best days are perhaps behind them.
I have been working on deploying a simple web app over the last 2-weeks. The experience has been one that has highlighted how Open Source is changing programming for all of us. First up: the pleasures of open source 🙂
The goal of the app was to get something very basic and quick out there. I was taking a very simple utility – one that had been built over a day and making it available to everyone. Doing this meant adding what is commonly expected of most apps these days: storing results in a database, adding support for accounts and authentication, and integrating with a couple of external systems to make the utility easier to use.
We got the early release of CodeMaps out yesterday. It has been great to hear all the feedback.
Over half the people that came to the site liked it – we are excited to hear that the site is meeting a need. About a third of the people felt like it needed work – we agree, and we are just starting the process (please keep on giving us the feedback). One-tenth of the people did not find the site helpful – we are hoping that as we improve the site and make it’s purpose more obvious that this will change.
For the curious, the above numbers are 53%, 35%, and 11% respectively (we used the the survey forms attached on the site).
The biggest question that we heard about was about the sites purpose. Our goal is big, as we mentioned earlier:
Our goal is to help you use an Open Source Project. We want to help you easily look at the API’s/Javadoc; Make it easy to get a code snippet for using a feature in a library; Simplify finding the right blog post; And even get you a high-level view of the project.
We are planning to start this simply:
First, we want to extend Javadoc – and let you see the source when you need it. Along with that, give you the niceties of your IDE. Being able to easily jump to the caller/callee of a method is often very helpful.
Next, we want to take this fancy code viewer and let you tag it with ‘concepts’. Concepts are the glue that our site uses to connect your code together. And possibly connect your code to things like blog posts, wiki pages, or questions on stack overflow. We want these ‘concepts’ to be used to describe any code concern and can range from a name for some code that you might care about to a high-level architectural principles in the project.
Oh yeah, as we do this, we are hoping that we will have a single site where you want to go to figure out how to use a project. Where for a library that you are using, you can easily find relevant blog posts voted up by the community or just find answers to questions (asked on sites like StackOverflow).
We have been improving the site – please try out CodeMaps, and let us know what you think. Let us know what you think? What should we do differently?