It's OK to be wrong...

Posted by Jim Jagielski on Tuesday, March 22. 2005

Ruby on Rails has completely changed by opinion regarding Ruby.
More...

How to choose

Posted by Jim Jagielski on Monday, March 21. 2005

I am occasionally asked "How do you pick which language to use for a partcular project?" Usually the question concerns various scripting languages, particularly PHP, Perl and Python. The sad fact is that there are no cut-and-dried rules; it depends greatly on the design requirements of the project in question. In general though, I find myself following the below general pattern:
Perl:
For short scripts or tools, Perl is the way to go. I hardly every use 'sh' anymore for basic admin things either. It also excels for basic proof-of-concept things. Anytime you can do stuff like $sp{'foo'}[$idex]->{'bar'} = $spamalot; and have everything pop into existence automagically, life is good.
PHP:
For any web-application, I tend to steer towards PHP. A full and robust suite of functions and capabilities tuned with web-apps in mind.
Python:
For any medium to large stand-alone application, Python is the best choice. Straddles the high-level/low-level language fence very well, just right as far as the amount of "basic" functionality provided, and an extensive array of library modules.
Of course, there is overlap... I find myself using mod_python more and more, eating a little bit into the PHP space... but then again, I haven't made the PHP5 jump yet, which may just turn that around. Also, if the project requires a lot of textual abstraction and manipulation, then it just screams out for Perl, no matter what the size or implementation.
More...

Google goodies

Posted by Jim Jagielski on Friday, March 18. 2005

Google has released a few of their tool and library packages as Open Source, as well as some useful APIs. The most useful Google code projects are the Core Dumper tool and the PyGoogle wrapper. Also interesting noting that all Python developers seem to develop the same support and enhancement functions; Google's is available as Goopy. It was fun comparing their's to mine. More incentive to make sure that Python is part of your toolbelt.
More...

Is Apache 1.3 Apache 2.0's worse enemy?

Posted by Jim Jagielski on Wednesday, March 2. 2005

Bill Rowe found some interesting news (here and here) comparing the adoption of Apache HTTPD 1.3.33 with 2.0.52. He notes: "What is notable is that the number of users adopting 1.3.33 in place of 2.0 far outweighs the number moving from 1.3 to 2.0." This has created quite a discussion on the dev@httpd.apache.org list regarding why this is the case, and what can be done (if anything) about this. This is a somewhat old discussion ("why are so few people migrating to Apache 2.0?") but with a slightly different PoV: Does the continued existence of Apache 1.3 cannibalize adoption of Apache 2.0? Previous discussions have revolved around the FUD that's associated with Apache 2.0, especially with regards to mod_perl or PHP and their stability and/or usefullness under 2.0. There is also the FUD about the reliability and stability of Apache 2.0 itself, compared to 1.3. This new discussion instead looks at comparing 1.3 and 2.0 and asks the question Why? Personally, I tend to use both, but, to be honest, I use 2.0 mostly when I require some of the new capability that it provides. Otherwise, I stay with 1.3. Of course, nowadays, especially in high-end, "enterprise-level" web infrastructures, those additional 2.0 features make it the solution of choice, but for smallish environments, 1.3 is just fine... At least for the time being. As a developer, there are loads of reasons to adopt 2.0, but as a user or administrator, there simply aren't as many. Under Linux, the advantages of worker aren't as significant as under Solaris or AIX. The "questionable" threading implementation on some OSs also preclude the possibility of using worker as well. Yes, there may be reasons why you can't move to 2.0 (mostly due to 3rd party module availability), but those are decreasing at an ever increasing rate. But I think the real change will happen with the release of 2.2... There are a lot of additional cool features in 2.2, compared to 2.0, that will make strong, compelling reasons to upgrade. Things like the advanced proxy, better authentication/authorization capability, robust caching, etc... Plus, as a developer, I like using what I develop, and the 2.1/2.2 tree has some good energy. Because 2.1 is the development tree, developers can easily scratch itches and add features, keeping that momentum going. Development with 2.0 is "sluggish" by comparison; even 1.3 development seems more "open" than 2.0 does. Since I don't find development of 2.0 as fun as 1.3 or 2.1/2.2, I tend not to use it as much as it deserves. But that's just me. But from a purely technical standpoint, there's no comparison: Apache 2.0 blows the doors off Apache 1.3. Even though I may bemoan the development energy within Apache 2.0 core, the energy with module developers is incredible. Quite simply, developing modules for 2.0 is much more fullfilling that developing 1.3 ones. The 2.0 API provides a lavish environment; it really is a module developer's dream. And since one of the great strengths of Apache has always been its modularity combined with a exhaustive suite of modules, getting more module developers to focus on 2.0 is key, I think, in seeing increased adoption. Some discussion on the dev@ list has mentioned doing "promotion" of Apache 2.0. I certainly agree with this, but we should focus just as much, if not more so, with promoting the 2.0 API and increasing the number of 2.0 modules. The 2.0 API isn't as easy to wrap your head around as the 1.3 API is, but it's well worth it. IMO, we should spend some effort extending and expanding knowledge of the 2.0 API.
1 Comment More...

Page 1 of 1, totaling 4 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!