The Growing Self-Importance of Blogs

Posted by Jim Jagielski on Sunday, February 27. 2005

I find myself becoming increasingly despondent over the perceived importance of blogs and bloggers lately. It seems that those who don't blog are somehow marginalized and those who do are somehow more "respected" than others. This goes for companies as well as people. As much as I agree with a lot that Matthew Langham has to say, it appears to me that even he weights the existence (or non-existence) of blogs way too highly (at least with regards to companies). I know several incredibly important, noted and respected members of the OSS community who don't blog at all, in fact, who almost despise them. It would be a sad thing indeed if their lack of blogs diminished, even slightly, the honors and accolades that they so richly deserve. Conversely, it would be just as sad, imo, if the simple existence of a blog somehow bestowed more honor and note-worthyness to a person or company than they warrant as well. It's easy to stand on a soapbox and say "Hey, look at what I'm doing." It's much harder to actually do what it is you're talking about. I think the latter should carry more weight than the former.
More...

Hear ye, hear ye...

Posted by Jim Jagielski on Tuesday, February 8. 2005

Amazing what can be announced in just a bit over a week: The CFP for ApacheCon Europe, Apache HTTPD 2.0.53, Google Maps, Apache Tomcat 5.5.7, JOnAS J2EE 1.4 Certification... *whew* And on a different subject, I've been following Berin Loritsch's entries regarding Ruby with interest. Maybe I was a bit premature in writing off Ruby, and so I'm once again endeavoring to add Ruby to my preferred list of languages. Finally: *where* do people find the time to actively maintain and update their blogs?!? I see sooooo many which are finely crafted literary works. Mine are the blog equivalent of a short note on the back of an index card. Must... control... the... envy...
More...

Patents and Street Credit

Posted by Jim Jagielski on Thursday, January 27. 2005

Much is being made of Sun's recent announcement that it is "releasing" over 1600 patents to cover and help with the development of Open Solaris. Some of the discussion, as expected, sees this action as a simple reaction to IBMs similar pledge of free use of some 500 of its patents to aid in the development of open source, and nothing more. Others applaud the action, but bemoan the fact that Suns "release" is not as wide-ranging as IBMs. As for me, well, I'm very much against software patents of any kind for fundamental reasons; I think that they severly restrict the distribution and usage of the technology to the areas in which they are needed the most. Anyone recall the hurdles you had to go through with the RSA patents and SSL? But if you do have patents, then opening them up to the open source community is a very welcome thing to do. Patents are still hammers, but (if they must exist) they should be tools used to allow work to proceed, not as a weapon to bring down on someone's toes. Of course, some of the more suspicious among us see Suns efforts as a blatant attempt to obtain more open source street credit. Personally, I don't see that at all; it appears the logical and expected action to promote the development of Open Solaris. But it's not unexpected for companies to make attempts to align themselves as "contributing members" of the open source community, even when they don't have the slightless clue what that means. My favorite thing is when a company tries to buy street credit by taking a software project that they no longer have any use for, slap an OSI approved license on it and assume that that makes 'em automatic members in good standing. These people just don't get it. They see the code as if it was that old, musty sofa in the basement and we need to get rid of it so why not donate it to Goodwill or the Salvation Army or even just dump it on the side of the road? Somebody will take it. It's not that way at all. Instead, open sourcing a software project is like transplanting a tree, from a shady area with clay-like soil, to a warm, sunny spot with rich, fertilized ground. You transplant it to ensure its health and growth and development. Not because you don't have any more need of it. No street credit isn't bought. It isn't obtained by simple declarations of being "pro open source" or claims that "we will help open source" and certainly not by butting into the communities with the mindset that "you all have been doing pretty well up to now, but we're here to help take you to the next level." Street credit is obtained by taking the time to honestly understand what open source really is, what it means. It's being active members of that community, and not for the prime reason of being able to use that as marketing hype. It's understanding that one key aspect of open source is collaborative, healthy development; that corporate governance of the requirements and direction of development, with no regard for the inputs of the development community or even no real regard for an external development community at all, may be open source in letter, but certainly not in spirit. It's not a bandwagon to jump on; it's a world-view. And the open source community can smell poseurs a mile away.
More...

EyeTV 200

Posted by Jim Jagielski on Monday, January 24. 2005

I've had an Elgato Systems EyeTV 200 for a bit over 2 months now, and I'm finding it more and more indispensable. If you are unfamiliar with the EyeTV line, think of them as TiVo for the Mac. I spend a lot of time in my home office, and although I'd run a cable drop to it, I never really had the real estate to put in a TV. Even when I would use a small TV (which we would take on trips), I found it more of a distraction than a benefit, since I needed to turn this way to see the monitor and that way to see the TV... It just took too much time away. I needed to be able to watch TV on the monitor, just as I would have a DVD running in the background in a small window. It was that capability that first made the EyeTV look so attractive. The ability to also record with it was a nice "added extra." Still, it seemed quite an expensive solution, so I hesitated in buying one until last October, when I was able to buy one heavily discounted. The EyeTV 200 is a Firewire drive, so the throughput is quite fast, resulting in a very nice and clear picture. But even more importantly is the recording quality, which is fantastic. I find myself using the unit more and more as DVR, burning DVDs for trips and the like. That is the coolest feature of all. My youngest son loves the SpongeBob DVDs I've made for him, and I find myself creating my own Law and Order episode set. The drawback, of course, is that the Mac needs to be up and running for the recording to happen, and you chew up diskspace like a sonofagun. I bought a nice 160gig Firewire drive and use it exclusively as my EyeTV archive. Still, it's quite a nice little device. It does exactly what it claims to do, and exactly what I want it to do. Can't get much better than that.
More...

Growing as a programmer and developer

Posted by Jim Jagielski on Friday, January 14. 2005

Two separate events precipitated this posting. The first was my older son Jonathan, who's a sophomore in high school, saying that he was interested in maybe becoming a programmer, and what courses should he be looking into. The second was Gianugo Rabellino's excellent blog entry on Holub on Patterns. The former got me thinking about how I started to grow and develop as a programmer (and developer) and the latter got me thinking about how much more I want to learn. I'm a proceduralist at heart. This is, of course, due to my start in programming. In high school and college the main language was BASIC (BASIC-Plus) with (at Hopkins) a moderate amount of C. When I graduated and started software development at NASA GSFC, the only languages at my disposal were FORTRAN and Pascal, again, very procedure oriented. The 2 were different enough that it was relatively easy to switch between the 2, without a lot of shifting of mental gears. However, around the late 1980s, the computing infrastructure at Goddard (which had been VMS on VAX) started moving towards Unix on various platforms (At Hopkins, we were all Unix on PDP-11s). When that happened, C became the language of availability. The problem for me was that I found myself not programming in C, rather I would "think" in Pascal and then "translate" to C. Needless to say, that didn't work too well, and I would make stupid mistakes; mistakes I should have known better about (pointers are a good example). Eventually, of course, I learned the skill of being able to juggle a number of languages around in my head, without conflict (well, much conflict). So my first nugget of advice to my son was to never "translate" languages. Think it, and write it natively. He's taking Spanish in school and he understood immediately what I meant. He said that when he first started as a freshman, he would think of what he wanted to say in English, and then translate it in his head to Spanish. Now, he "thinks" in Spanish. But that's only the first step. The next one is to think "design" and "algorithm" in a mental, pseudo-code sort of way, and then "map" the language you're programming in to that. You see the problem, and work the solution, without any language in mind; instead, you let it exist as itself without being tainted by a potential language. This has the further advantage of letting you pick the right language for the task at hand (if you are lucky to do so). Of course, this brings me to the Holub on Patterns book, since it appears that this book helps you further refine and develop that mental image to remove (or at least, not require) a deep procedural frame of reference, which I still have. In fact, I almost think procedural and translate to OO. Almost. But I know I could be better. Anyway, it's worth a look, and for Christmas I got a Barnes and Noble gift card, so that's what I may be using it on. I also gave my son two other pieces of advice. One was that no matter how far along you are, you can always get better. You can always tweak and fine tune the code; you can always fine tune the programmer. The other was even more basic: Learn To Type. I sure wish I had.
More...

Page 3 of 55, totaling 273 entries

Quicksearch

Search for an entry in IMO:

Did not find what you were looking for? Post a comment for an entry or contact us via email!