I've been working on a software project at home for the past several weeks. Until now, I haven't had the project under source code control. A few days ago, I installed open source Subversion and I'm very happy with the results.
I installed the Windows version of CollabNet Subversion from openCollabNet. The current version is 1.4.2. Installation is painless. You just have to answer a few questions including whether to install Subversion as an add-on to an Apache server or as a standalone server (svnserve). I chose the standalone option and my server was up and running in a matter of minutes.
One tip: You will want to check out the instructions for running svnserve as a Windows service. This lets you can automatically start your Subversion server when you start Windows. You can also use the services UI to stop your server, for example, when you back up your repository.
Although CollabNet Subversion includes a command line client, you can pick from a handful of GUI clients too. I chose Subclipse, an Eclipse Team Provider plug-in. If you've experienced the way Eclipse integrates with CVS, Subclipse will be very familiar. The preceding link brings you to a page with information on Eclipse update sites where you can get the version of Subclipse that's right for your version of Eclipse. And How to Use Subversion with Eclipse is a good tutorial for Subclipse beginners.
Showing posts with label eclipse. Show all posts
Showing posts with label eclipse. Show all posts
Sunday, April 15, 2007
Tuesday, October 31, 2006
Eclipse Rules
Eclipse must be doing very well. I can tell because there is now at least one blog entirely dedicated to listing all of the problems with Eclipse. By comparison, I can't find any blog or website dedicated to NetBeans complaints.
It may seem counter-intuitive that one's vocal critics are a measure of one's success, but consider the case of author Dan Brown. In an interview on NHPR, Brown talked about the uproar over The DaVinci Code. He was initially surprised by the volume of criticism. After all, his earlier book, Angels and Demons, was just as controversial, but it didn't generate anywhere near the same number of objections from readers. Brown's mathematician father explained all by pointing out a simple fact: The audience for the earlier book was a tiny fraction of those that read The DaVinci Code. You can't please everyone, so statistically speaking, lots of complaints might just be a sign you are a smash hit.
Taking the Eclipse vs. NetBeans comparison a step further, try comparing the number of Google hits for these two phrases: "eclipse sucks" and "netbeans sucks". Using Googlefight to do the comparison, I recorded 1840 hits for the Eclipse phrase vs. 421 hits for the NetBeans phrase. Knowing what I know about Eclipse, I'm sure this doesn't mean Eclipse is four times worse than NetBeans. More likely, it's an indication that Eclipse is four times more popular.
It may seem counter-intuitive that one's vocal critics are a measure of one's success, but consider the case of author Dan Brown. In an interview on NHPR, Brown talked about the uproar over The DaVinci Code. He was initially surprised by the volume of criticism. After all, his earlier book, Angels and Demons, was just as controversial, but it didn't generate anywhere near the same number of objections from readers. Brown's mathematician father explained all by pointing out a simple fact: The audience for the earlier book was a tiny fraction of those that read The DaVinci Code. You can't please everyone, so statistically speaking, lots of complaints might just be a sign you are a smash hit.
Taking the Eclipse vs. NetBeans comparison a step further, try comparing the number of Google hits for these two phrases: "eclipse sucks" and "netbeans sucks". Using Googlefight to do the comparison, I recorded 1840 hits for the Eclipse phrase vs. 421 hits for the NetBeans phrase. Knowing what I know about Eclipse, I'm sure this doesn't mean Eclipse is four times worse than NetBeans. More likely, it's an indication that Eclipse is four times more popular.
Monday, September 11, 2006
EclipseWorld Wrap Up
Friday, September 8 was the last day of the EclipseWorld technical conference. I won't go into all the gory details of the sessions I attended. If you read my Day Two report, it was more of the same: Some sessions missed the mark, at least for me. These sessions just weren't technical enough. In fact, in an informal poll, the consensus among people who have attended both conferences is that EclipseCon is the better conference for experienced Eclipse developers.
Of course, the conference did have some good sessions. The best session I attended on Friday was called Contributing Code to Eclipse. How to. Why to. It was conducted by Bjorn Freeman-Benson, Director of the Open Source Process at the Eclipse Foundation. Bjorn described the organization of the Eclipse Foundation, the motives of it's member companies *, and the details of development process.
As Bjorn puts it, one measure of the Eclipse project's success is they have released a version of Eclipse every year, on schedule, for the past seven summers. This is a record of which most commercial software companies would be proud, but Eclipse is an open source project. You might have expected it to disintegrate into anarchy by now.
How has the project managed to be so successful? Bjorn highlighted three points:
* Eclipse Foundation members commit resources to Eclipse projects not out of altruism. They expect to make money on the Eclipse framework.
Of course, the conference did have some good sessions. The best session I attended on Friday was called Contributing Code to Eclipse. How to. Why to. It was conducted by Bjorn Freeman-Benson, Director of the Open Source Process at the Eclipse Foundation. Bjorn described the organization of the Eclipse Foundation, the motives of it's member companies *, and the details of development process.
As Bjorn puts it, one measure of the Eclipse project's success is they have released a version of Eclipse every year, on schedule, for the past seven summers. This is a record of which most commercial software companies would be proud, but Eclipse is an open source project. You might have expected it to disintegrate into anarchy by now.
How has the project managed to be so successful? Bjorn highlighted three points:
- It's a meritocracy. Only the best developers become Eclipse committers. Even a paying foundation member company cannot install one of their developers on a project without approval from the current committers. Generally, you become a committer by contributing patches first.
- The process is completely transparent. Everything from project planning, to staffing, to the actual source code is recorded on the Eclipse web site. This ensures that both committers and the eventual consumers know what is happening with the project.
- Communication is key. This is related to the point about transparency, but Bjorn highlighted it a few times. He said even a great developer will not succeed in an Eclipse project unless he is also a good communicator.
* Eclipse Foundation members commit resources to Eclipse projects not out of altruism. They expect to make money on the Eclipse framework.
Thursday, September 07, 2006
EclipseWorld, Day Two
For me, today was Rich Client Platform (RCP) day at EclipseWorld. I planned on attending four separate sessions on RCP. As it was, I took a small detour to learn about the Java profiling tools in the Test & Performance Tools Platform (TPTP).
The first RCP course was First Steps for Building Eclipse RCP Applications. It was mostly review for me, but I thought it would be good preparation for some of the more advanced courses. The instructor, Dwight Deugo, did a good job describing the basics.
I also attended Fundamentals of RCP UI Programming. This session was a little disappointing. The instructor is a good speaker, but he spent the entire two hours talking about JFace -- and from a very high level. Although he occasionally showed some sample code, it was difficult to follow along. The sample code wasn't reproduced in the presentation materials. Even though I was near the front, I couldn't see the details. Pity the poor folks in the back.
To complete "RCP day", I planned on attending a two part session called Successful Architecture Design for RCP Applications. I expected this to be about factoring your RCP application into features, plugins and fragments; interactions between views and editors; extension points; the job manager; and other hard-core Eclipse concepts. Ten minutes through the first part, I realized I was mistaken. The session was all about migrating three-tier business applications from the web to RCP. Although the instructor has good "Eclipse credentials", this topic didn't really fit with the other sessions in the RCP track. It certainly doesn't interest me personally.
Rather than sit through the second part of Successful Architecture, I decided to switch to Profiling Java Application Behavior with Eclipse TPTP. This was a revelation. The instructor demonstrated the features of the Profiling and Logging perspective which is contributed to Eclipse by TPTP. The profiling views let you track execution flow, execution statistics, memory statistics and object references in a running JVM. You can quickly sort these views to find hot spots like methods that consume lots of CPU cycles. I use Eclipse everyday but I didn't realize the free profiling tools have gotten this good. For a good introduction of the Profiling and Logging perspective, see this tutorial at eclipse.org.
The first RCP course was First Steps for Building Eclipse RCP Applications. It was mostly review for me, but I thought it would be good preparation for some of the more advanced courses. The instructor, Dwight Deugo, did a good job describing the basics.
I also attended Fundamentals of RCP UI Programming. This session was a little disappointing. The instructor is a good speaker, but he spent the entire two hours talking about JFace -- and from a very high level. Although he occasionally showed some sample code, it was difficult to follow along. The sample code wasn't reproduced in the presentation materials. Even though I was near the front, I couldn't see the details. Pity the poor folks in the back.
To complete "RCP day", I planned on attending a two part session called Successful Architecture Design for RCP Applications. I expected this to be about factoring your RCP application into features, plugins and fragments; interactions between views and editors; extension points; the job manager; and other hard-core Eclipse concepts. Ten minutes through the first part, I realized I was mistaken. The session was all about migrating three-tier business applications from the web to RCP. Although the instructor has good "Eclipse credentials", this topic didn't really fit with the other sessions in the RCP track. It certainly doesn't interest me personally.
Rather than sit through the second part of Successful Architecture, I decided to switch to Profiling Java Application Behavior with Eclipse TPTP. This was a revelation. The instructor demonstrated the features of the Profiling and Logging perspective which is contributed to Eclipse by TPTP. The profiling views let you track execution flow, execution statistics, memory statistics and object references in a running JVM. You can quickly sort these views to find hot spots like methods that consume lots of CPU cycles. I use Eclipse everyday but I didn't realize the free profiling tools have gotten this good. For a good introduction of the Profiling and Logging perspective, see this tutorial at eclipse.org.
Wednesday, September 06, 2006
EclipseWorld, Day One
I'm at the EclipseWorld technical conference in Cambridge this week. I was hoping to blog from the conference, but there were technical problems with the conference's wireless network today. There are only a few hundred attendees, but the organizers apparently didn't plan for a large volume of network traffic. This doesn't reflect well on the conference.
Today, we each had to choose one of seven all-day tutorials to attend. I attended the Callisto Boot Camp:
Today, we each had to choose one of seven all-day tutorials to attend. I attended the Callisto Boot Camp:
This tutorial, for experienced Eclipse developers who are currently using Eclipse 3.1, will deep-dive on the new features and innovations in each of the 10 projects that make up the Callisto Simultaneous Release. By attending this class, you'’ll gain a unique perspective on these projects, not only about the individual new functions that they offer, but how they integrate together to advance the entire Eclipse ecosystem. Everything you want to know about Callisto--—you'’ll find it here.The instructor -- Eclipse Evangelist, Wayne Beaton -- acknowleged from the start it is difficult to do a deep-dive on everything. For my taste, he spent a little too much time on the Web Tools Platform (WTP) and not enough on the C/C++ Development Tools (CDT) or Data Tools Platform (DTP). However, I'm not really criticizing. Mr. Beaton struggled mightily to describe the whole elephant. He didn't quite pull it off, but he demonstrated a solid understanding of a broad set of technologies. It was a worthwhile overview.
Tuesday, November 22, 2005
Erich Gamma on Shipping Software
In part five of a series of interviews at Artima Developer, Erich Gamma talks about Eclipse's culture of shipping software. He talks about six week milestones, transparent planning, constantly "eating your own dog food", and the controlled end game. This is all very familiar. It is almost identical to the Notes development culture at Iris Associates.
There are at least two important differences. Notes release cycles were historically much longer than those of Eclipse. And Notes never was an open source project. However, these differences just highlight the importance of the common themes. If I had to pick one, I'd say the most important is "eat your own dog food". There are lots of different strategies for quality assurance. Nothing compares with running your business on the product you are building.
(via Jeff Atwood, at Coding Horror)
There are at least two important differences. Notes release cycles were historically much longer than those of Eclipse. And Notes never was an open source project. However, these differences just highlight the importance of the common themes. If I had to pick one, I'd say the most important is "eat your own dog food". There are lots of different strategies for quality assurance. Nothing compares with running your business on the product you are building.
(via Jeff Atwood, at Coding Horror)
Subscribe to:
Posts (Atom)