My first podcast was “published” last week on Dana Gardner’s blog. Doing a podcast was definitely an interesting experience. I’m not going to comment on the content here. Go listen to the podcast or read the transcript. 🙂 Instead, I want to describe the process about how the podcast content was created.
I’m sure a lot of podcasts are created with a simple “sit down, chat, all in one take” type process. This wasn’t that way. Part of that was because this was our (my employers) first podcast to be involved in. We kind of wanted a couple walk throughs and such so we could get a feel of what it would be like ahead of time. We had a couple meeting ahead of time to discuss what the podcast was going to be about, the types of questions that would be asked, the general outline, etc… A lot of that is important. With less than an hour or so of time, you need to make sure the podcast is focused on the important points. These discussions definitely helped narrow the discussion points and were very valuable in making the podcast a better production.
The next step in our process was a “practice” run. We kind of set up things like it would for a full production run. All the audio was taped and such. This did last a bit long, but that’s ok. Things can always be cut during editing. The raw audio from this was sent around to a few people for comment and suggestions. We got several good comments and ideas, but for the most part, everything was very good. We decided to then have the “final” taping.
After the final taping, the audio was then passed around and we kind of discovered that the first “practice” session was actually better. The second one sounded more scripted, more rehearsed. A lot of the “spontaneity” wasn’t there. Thus, we actually ended up using most of the stuff from the first taping.
Thus, the moral of the story is:
If at first you don’t succeed in making it perfect, don’t worry, most likely if you try again, it won’t be as good anyway. 🙂
This past week, my son’s website (http://www.ryankulp.com) hit a major milestone: it now consumes over 1GB of drive space on my server. Since it’s mostly uncompressible images/videos, that means it sucks up 1GB of my backup storage as well. It also went over 1000 items.
That started a bunch of discussions about what to do in the future. Should we pull old stuff off the site and archive it to CD’s? Should we archive to CD, but leave it there but configure the backups to not back it up? (my server has 4x the space as the backup area) Should we just purchase more backup space? (I use http://rsync.net which provides a good open source developer discount so another GB is less than $1/month) Personally, I prefer the last options, but I’m an engineer. (If there’s an issue, throw more hardware at it)
The more interesting discussions started when we thought about would Ryan WANT his baby pictures forever available on the web. Think about it. How many times have you been embarrassed when you brought a friend to meet your parents and they pull out the baby books? With his website, all the pictures are always available. I guess we’ll find out in the years to come. For now, it serves as a useful tool to make his pictures available to friends and familly that are scattered throughout the country.
Today reached a new milestone for me. After a bunch of work with the Maven team to define new release process, creating new plugins, filing a lot of patches to bugs, etc…., the Maven team voted me in as a committer for the Maven plugins.
This is kind of exciting to me as it validates a lot of the work I’ve done. It also is the first NON-INCUBATOR project that I’ve been granted commit rights to.
I’m looking forward to contributing yet more stuff to Maven. I think Maven is a great tool, but has a few rough edges that I’d like to help smooth out.
Last week, Maven 2.0.5 was finally released. It was long in coming (over nine months since 2.0.4), but well worth the wait. It fixes a TON of bugs, many of which I’ve hit my own builds and have had to do a lot of hacks and workarounds to deal with. (Now I have to go through and remove some of the hacks) 🙂
Maven 2.0.5 is pretty exciting in itself, but all the other “behind the scenes” stuff that was developed to support/produce this release is fantastic work and doesn’t get the attention it deserves in the announcement. The work they did on the release process should benifit any enterprise level Maven user as well other open source projects using Maven.
I’m talking about things like:
maven-gpg-plugin – digitally signs the artifacts. Requirement for apache projects and others.
maven-remote-resources-plugin – allows injection of common resources (like licenses, disclaimers, etc…) into all the jars.
For apache projects, created the apache-jar-resource-bundle and apache-incubator-disclaimer-resource-bundle for those common artifacts.
Updating the release procedures to support “staging” of releases for inspection before being promoted to the final repository.
repositorytools-maven-plugin (at mojo/codehaus) for doing that promotion.
I know that I learned a LOT following all the discussions around the efforts that went into all of the above.
Anyway, a “really big thanks” to all the Maven developers for their hard work.
Every once in a while, my employer (IONA) actually allows me to get out of my cube and do a presentation about what I’ve been working on. Last week, I got to give a presentation to a bunch of people about Apache CXF. Specifically, some of the internal architectural things and how they differ from IONA’s older commercial projects.
One of the things that was asked of me was “can you run a sample in a debugger so we can really see what is going on?” Sounds simple, doesn’t it? After all, we obviously use debuggers for our own development. Yes, we debug unit/system tests, not the demos, but how different can that be?
Boy was I wrong. Getting the samples up and running in eclipse was NOT fun. Our general builds use maven for building which has a nice “eclipse” plugin that generates eclipse plugins for all the projects/sub-projects. Thus, getting that up and running in eclipse is easy. The samples, however, use an ant based system, not maven. I tried the “New project from ant build.xml” thing from eclipse, but that didn’t work very well. It didn’t wire in the CXF jars properly (it doesn’t traverse the manifest/classpath jars) so the project didn’t work at all. I ended up doing a bunch of hacks to get it working.
I’ve now put on my “todo” list to investigate changing the samples over to something more eclipse friendly. I’d like to move to maven, but that might then require the user to be “online” to build/run the demos. I’m not sure if that’s OK. I’ll need to investigate some more.