I've started playing with the Eclipse in general and the Eclipse dynamic languages toolkit (DTLK) specifically for it's Ruby support. The 1.0M3 version doesn't seem to be the update servers so I downloaded the full package version and unzipped it into my local eclipse install. The "Mx" numbers must be prerelease milestones.
So far the experience has been much better in general than past forays into using both Eclipse in general, CDT, and RDT (though that was quite a while ago for all of the above). I havent tried, but I don't think this version doesn't seem to have any particular support for rails, however I'm mostly doing quick algorithmic prototyping or utility scripts in Ruby.
One nice feature is the binding of build configurations to a specific ruby interpreter so, on my Mac, it's a nice way to develop and play around with an install of ruby 1.9. Also, I do like to support for unit tests and execution. It also automatically indexes and pulls up rdoc strings. Both nice touches, though I have yet to figure out if there's a way to configure a Ruby project to autorun the unit tests while you type or for every resource save.
The DTLK project in Eclipse is a smart project in that it seems to building a foundation of eclipse support for dynamic languages in general - and there has to be a lot of commonality there. So I'm looking forward to getting more comfortable in the DTLK Ruby environment.
I have some motiviation as I'm also trying out eclipse for embedded development using CDT configured with an embedded toolchain. Eclipse Ganymede is a much nicer enviroment for code browsing than many of the mini-embedded IDE's provided by the vendors.
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Tuesday, November 18, 2008
Saturday, August 30, 2008
History of Agile Software Principles
In an article inside Crosstalk, the Air Force Journal of Software Engineering, Alistar Cockburn reviews a 1968 NATO software engineering conference. He observes that many of the core beliefs and techniques of the modern Agile software development movement aren't such recent developments after all. Both the 1968 conference and the Agile movement focus on the central effect of people over processes.
I understand that there is a strong temptation to develop processes with a mindset that success will result when all that is needed is to capture the collective history of all past processes within the current one. Over time, I believe that approach is guaranteed to be ineffective.
It's not that you don't want to develop processes, but if one focuses on the development of process before people, your process will build up unwieldyness, and the people applying it will either lose confidence in the process, or worse, may not recognize why the steps they are taking are going wrong. To capture knowledge of past projects, you need to allow time to writeup retrospectives. To transfer the knowledge, you want to encourage time for less-experienced engineers to talk and read about past projects. Then going forward, people are better informed to create and apply approaches to the problem at hand.
It takes people to figure out if things are working. For example, I don't think that most aerospace software development can blindly follow the iterate smaller / continuous flow focus of the current Agile software development. They need to consider that they're not purely software systems, and that costs of design-reversals can be much higher when hardware and physical environments are in play.
p.s. if you new to the term Agile Software development see the Agile Manifesto or search on "Agile Software", or "Lean Software" or post a comment.
I understand that there is a strong temptation to develop processes with a mindset that success will result when all that is needed is to capture the collective history of all past processes within the current one. Over time, I believe that approach is guaranteed to be ineffective.
It's not that you don't want to develop processes, but if one focuses on the development of process before people, your process will build up unwieldyness, and the people applying it will either lose confidence in the process, or worse, may not recognize why the steps they are taking are going wrong. To capture knowledge of past projects, you need to allow time to writeup retrospectives. To transfer the knowledge, you want to encourage time for less-experienced engineers to talk and read about past projects. Then going forward, people are better informed to create and apply approaches to the problem at hand.
It takes people to figure out if things are working. For example, I don't think that most aerospace software development can blindly follow the iterate smaller / continuous flow focus of the current Agile software development. They need to consider that they're not purely software systems, and that costs of design-reversals can be much higher when hardware and physical environments are in play.
p.s. if you new to the term Agile Software development see the Agile Manifesto or search on "Agile Software", or "Lean Software" or post a comment.
Subscribe to:
Posts (Atom)