22/07: @kirkk.com Moving
I've been using Nucleus as my blogging software. While it's met my basic needs, I haven't been totally satisfied with it. It has a few features I simply don't need, while leaving me wanting for different features. So I've decided that it's time to move on, and have chosen WordPress as my tool du jour. As such, this will be my last entry on this blog before moving on. The blog URL will be changing. I decided to change the URL so anyone who currently subscribes to this feed will see this entry and can update their bookmarks and feeds accordingly. Additionally, since I don't plan to move any of these blog entries to my new blog, maintaining the existence of this original blog allows you to access any of the entries anytime you desire.
The new blog URL is http://techdistrict.kirkk.com, and the feed URL is http://techdistrict.kirkk.com/feed. Be sure to update your bookmarks and rss feeds. See you at my new blogging home.
Of course, all updates to my home page, old blog, new blog, and other writings found on the 'net are aggregated into a single convenient feed on My Planet.
The new blog URL is http://techdistrict.kirkk.com, and the feed URL is http://techdistrict.kirkk.com/feed. Be sure to update your bookmarks and rss feeds. See you at my new blogging home.
Of course, all updates to my home page, old blog, new blog, and other writings found on the 'net are aggregated into a single convenient feed on My Planet.
11/04: The Silver Bullet
We really make software development much harder than necessary. In fact, if we listen carefully to industry visionaries, we'll learn the right way to develop software.
Booch says that "...All architecture is design, but not all design is architecture."
Now, Reeves says that "design is the source code listings."
So I conclude that if architecture is design, and design is the source, then it makes sense that architecture is the source.
But then Fowler really ties it all together by saying that we must "...remove architecture."
So if I'm to interpret this all correctly, it sounds like the best way to develop software is to avoid writing code. No wonder we're all so confused.
Booch says that "...All architecture is design, but not all design is architecture."
Now, Reeves says that "design is the source code listings."
So I conclude that if architecture is design, and design is the source, then it makes sense that architecture is the source.
But then Fowler really ties it all together by saying that we must "...remove architecture."
So if I'm to interpret this all correctly, it sounds like the best way to develop software is to avoid writing code. No wonder we're all so confused.
A while back, I wrote JarAnalyzer and have received many positive comments from developers who have found the ability to analyze dependencies among .jar files valuable. Recently, I began working on a .Net project, and I was quite surprised to see how few open source utilities are available for .Net development. Really nothing compared to the Java world. As I began search for .Net source code analyzers, I quickly found there weren't too many open source utilities that do for .Net what JarAnalyzer did for Java. That is, analyze a set of .Net assemblies and report on the dependencies. So I decided to roll my own, and have created AssAnalyzer.
19/03: SD Expo
Gosh. It's been a while since I've had time to post, and I've got quite a backlog of entries. I'm hoping to get them out here within the next month. In the meantime, I'll be at SD Expo late next week presenting Benefits of the Build - A Case Study in Continuous Integration, and From Code to Architecture. If you're at the conference, stop in to say "hi".
Recently, I wrote about the lack of a mature and de facto standard CI tool in the Ruby community. While not everyone will consider CruiseControl on their Ruby development efforts, for those that do, you now have an option. Late last week, CruiseControl 2.6 was released. In addition to some of the other useful features, RakeBuilder was included. It's now easy to invoke Rake build scripts from CruiseControl.
I decided it was time to explore more Ruby, so I decided to implement my standard programming kata using Ruby without Rails. My primary intent was to further familiarize myself with the Ruby platform and some of it's most useful gems. Given that much of my Ruby and Rails work has been with small projects, the secondary intent of this endeavor was to simulate the type of environment in Ruby that I have grown accustomed to working with in Java. That is, large teams and applications, and the environment necessary to support the development effort. I had planned to document my steps and share them on this blog. It was supposed to go something like this:
- Develop my standard loan payment calculator to show the monthly payment of a loan based on a rate, term and principle.
- Use Test::Unit and further explore ways to separate test code from application code, understand directory structures and loadpaths, other environmental issues.
- Add a test suite to aggregate multiple tests into a single test run.
- Introduce a Rake build file to run the test suite and perform any other build related tasks
- Deploy the application as a REST service along with an html front end
- Setup a continuous integration environment with scheduled builds and deploys.
I had a good start, encountering a few rather interesting challenges along the way. Eventually, I hope to compile my notes and share them. However, I got sidetracked. Above all else, there was one glaring deficiency I struggled with tremendously.
- Develop my standard loan payment calculator to show the monthly payment of a loan based on a rate, term and principle.
- Use Test::Unit and further explore ways to separate test code from application code, understand directory structures and loadpaths, other environmental issues.
- Add a test suite to aggregate multiple tests into a single test run.
- Introduce a Rake build file to run the test suite and perform any other build related tasks
- Deploy the application as a REST service along with an html front end
- Setup a continuous integration environment with scheduled builds and deploys.
I had a good start, encountering a few rather interesting challenges along the way. Eventually, I hope to compile my notes and share them. However, I got sidetracked. Above all else, there was one glaring deficiency I struggled with tremendously.
16/11: Source Code
It really is all about the source. Ken Schwaber, co-creator of Scrum, agrees, providing further proof that Agile processes and agile practices are only effective if the infrastructure and source code are adaptable, as well.
08/11: My Planet
Recently, I was looking for a way to combine all of my rss feeds into a single, aggregated feed. With blinders on, I started evaluating blogging software that would allow me to host my own blog, while also pulling in feeds from other sites to which I contribute. Turns out the solution was much simpler. Planet is an rss news feed aggregator that combines feeds from a variety of different sites, and displays them as a single feed. Planet, built using Python, has a very nice templating engine which makes it easy to modify the layout and presentation of the site. The amazing simplicity is that I simply setup a Cron job to run every so often to update the planet, and generate a single page from the template defintions. So if you're interested in receiving a combined feed of all my individual feeds from Artima, @kirkk.com, Agile Junction, and my home page, you can do so easily. For convenience, here's My Planet where you can subscribe to the feed.
20/10: Communication
If you've ever been part of a large project team, you understand the communication challenges present. Large project teams just have so much more of everything than do smaller teams. There is more code, more people, more requirements, more, more more. And all this extra stuff makes it difficult for anyone and everyone to understand things consistently. Hell, I've been on teams where I don't even know all the developer's names. And if I don't know their name, you can bet I don't know what they are doing nor how they are doing it. That's not ideal, but it's also real. And it's why we try to break teams up into smaller teams that each work together. Anyway, I've always wondered about the unique paths of communication that exist between members of a team. So I wrote a little Ruby script to help me figure it out.
09/10: All About the Source
My second blog entry over at Agile Junction is All About the Source. There's also an rss feed available. Subscribe to it, and get involved with the discussion. This is important stuff. If you aren't sure why, I'll explain why soon.
(RSS 2.0)