Programming

The best and, honestly, the only usable SFTP and/or FTP plugin for Eclipse is Target Management. This plugin makes over-the-SSH development in Eclipse a practical possibility.

One of the greatest features of this plugin is that it allows working with files, without creating a project, something that vanilla Eclipse is insanely paranoid about. Out-of-the-box Eclipse forces you to first create a project. As a consequence, even if you map a remote server as a network drive, over SSH, you may still have problems working in Eclipse. Reason being - Eclipse constantly analyses project files and over SSH it is just too darn slow.

You can use Target Management for local development, too, if you hate creating projects. Actually, it makes sense for PHP development. Whilst Java developers always think in terms of projects and dependencies (guess why - they need to build the darn thing), PHP developers do not have to carry the same burden and may choose to avoid the overhead. By the way - if you are using Eclipse for PHP, you definitely need to install PDT plugin and the easiest way is to install a pre-built, "bundled" version that you can find on the PDT download page: [http://download.eclipse.org/tools/pdt/downloads/]

If you are serious about using Eclipse as your IDE, you definitely need this plugin.

Please note that you have to install CDT plugin, before you can install Target Management. Also, CDT is not part of standard Eclipse distribution so you need to add the update site, just "install required" will not help. The update URL for CDT is: http://download.eclipse.org/tools/cdt/releases/europa

When you are done installing TM, add its primary view to your perspective via:
Window -> Show View -> Remote Systems
and start enjoying.

Last week, the major news on the Web was the launch of OpenSocial. Google did an excellent job documenting APIs and publishing quick-start tutorials and videos, as well as signing-up an impressive group of early adopters. All that is left to us, the blogger by-standers, is to review, envy and criticize. That is exactly what we are going to do.

Since it's too early, I, personally have only a few, quick comments. These comments may be totally off, so I insist on the right to change my statement at-will. Nevertheless, the first impression of OpenSocial is highly positive. The API is clear, concise and pragmatic. Pragmatism and (at least an attempt of) parsimony are a necessary feature for such API. It seems like Google is on the right track on that front.

Some of our readership, coming from the Java/J2EE world, may draw parallels between OpenSocial and Java Portlets API (JSR-168). Java Portlets API was created about four years ago, intended to be a plugin infrastructure for Java-based web sites (a plan much less ambitious than that of OpenSocial) and - failed miserably. The main reason why it failed was that it was too restrictive in the areas that do not matter, and too general in the areas they should have described in detail. Areas like user profile management, user actions, user interactions. Basically, JSR-168 was page-centric, rather than user-centric and the demand is for a user-centric integration. Rendering is a job of a container.

OpenSocial has clearly avoided the trap that JSR-168 fell into. They concentrate on the right features: people, activities, persistence. The choice of the platform - Javascript, REST (bye-bye SOAP), Atom, RSS, HTML and CSS makes complete sense. The API is quite modular, reasonably high-level and what seems like flexible-enough to allow for all kinds of applications. We were shown some very different applications in the demos, created by different vendors.

Now that we have praised OpenSocial enough, and probably nobody had any doubt in its huge potential, anyway, let's mention some oddities, we've noticed:

Steve Jobs announced the availability of Safari 3.0 Public Beta during yesterday's WWDC Keynote. For audience at large the biggest news about the release was that it is now available on Windows, as well. However, apparently there is a "hidden" (well, unpublicized) new feature that is just as exciting for Mac geeks like moi - Web Inpsector.

Web Inspector is a context menu-activated DOM analyzer a-la FireBug for Firefox. This thing is sweet (!) and will make Safari troubleshooting much nicer, from now on.

Thanks, Apple! Well done.

SOA is probably the most overused/abused buzzword. I would say even more so than AJAX - which is scary, really. It's also funny how "SOA experts" can make the subject even blurrier.

That was the subject of the conversation between Doug and I, recently that I am quoting below. We were discussing a recent SOA article. Nothing too serious, just fun.

irakli: Got a minute?
dharris: sure
irakli: Trying to catch a blasphemy in this: http://www.theserverside.com/tt/articles/article.tss?l=ChurchandState

There are tons of wonderful Firefox add-ons. In fact, that is what makes this browser stand out among other browsers. However, be cautious to install every other extension you think may be cool. Firefox performance can significantly degrade when you install many/random extensions.

Anyway, for what it's worth, following is the list of Firefox extensions that I can not live without (alphabetically):

• Aardvark
• Add N Edit Cookies
• CookieSwap
• del.icio.us
• Extended Statusbar
• Fire Encrypter
• Fire Bug ( I bless the day Joe Hewitt started programming!)
• MeasureIt
• Server Spy
• Talkback (well, i can live without it but keep it installed as courtesy to Firefox)
• User Agent Switcher

P.S. I am not trying to be lazy or annoying when not linking these plugins. First, such links may soon get invalidated because URLs change all the time, second - if you google "firefox plugin <addon name>" you will find any of them, easily - promise!

As far as Enterprise Architects are concerned, there is no other, single characteristic of a software system more important than the performance and scalability. Or, at least - there should not be. Sadly, in reality, performance is often an afterthought. Inexperienced development teams look at it in disdain and refuse to "waste" time on performance tuning. They amuse themselves with "feature enhancements" and only remember performance when things start to fall apart. That moment in time is usually before the champagne glasses, in celebration of the "successful" launch, get a chance to dry.

Bjarne Stroustrup: "The purpose of a programming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast."

Let's see...

We will skip the "adequately fast" part since I have no idea what adequate would be for Mr. Stroustrup and besides fast/slow is determined by language compiler/interpreter implementation not by language syntax. We will assume Bjarne is just trying to off-handedly dismiss scripting and VM languages,

Moving on...

What does "correct" mean? In line with all those patterns and "best-practices" they try to teach you in all the "right" books? And, of course, maintainable goes hand-in-hand with that, too?

Even though I have some Assembly language under my belt and have worked with, what I like to see as, wide variety of programming languges, I am still from the spoiled generation that learnt object-oriented programming before calculus and got on Java bandwagon early on.

I was fortunate to have had privilege to work with a wonderful group of programmers. In my earlier days, one of them was kind enough to spend some time (and I imagine patience) to argue with me that Java is not panacea and \'"hard facts" that "best-practice" literature tries to feed us is just one side of the truth. An often-used example was dynamic vs static and strict vs lose typing. Lisp would come up in the discussions habitually.

Lisp is one of those languages that may be regarded as a dinosaur one but people with more insight know it is too important to simply disregard or ignore.

There is a wonderful review of Common Lisp by Peter Seibel, given at Google, that gives some insight in Lisp, but more importantly - in software architecture generally and how patterns in different programming languages relate.

Developers often compain about explicit Exceptions, especially in a strongly typed language like Java, and how much real estate handling those takes up in source code.

I have seen approaches when people try to avoid java.lang.Exception and fall back to java.lang.RuntimeException for most cases. Is that a good thing to do? RuntimeException is a valid choice for certain cases but overusing it beats the whole idea of exception-handling, really.

As part of my responsibilites as a software architect, I get to review code of many developers. I think the problem, in most cases, is incorrect usage of exception-handling. More specificly, developers overdo with catching exceptions at the lowest level - at the same spot they expect exception to be fired. Passing it up the class hierarchy is often needed but not done. It is especially true in the case of more junior developers (however, you quickly find out that many "senior" developers are vulnarable, as well).

There are several books about Subversion, some small some huge. Yet, none of them gives a 5 minute get-going guide. Most of the developers are seasoned CVS users, so we do not really need a tirade about version control - just get us going!

And (I can hardly stress this enough) we\'d really like Subversion to authenticate over SSH. Leave that "pasword db" (in essence - open text file) or Apache Module bullcrap, to somebody else. Neither do we need the WebDav for version control - thank you very  much, but no.

The last time I set up a SVN repository (accidentally - my first time, too) it took me looking through 4 different books and a week\'s work on and off. Today I needed to do it, again and I found out that I did not remember much of the last experience. Well, it did not take me a week, but still more than I would want to spend on it. Anyway, to save myself time, in the future and in hopes of this being useful for folks who don\'t want to read 4 books, here is how it is done, on Unix (Windows can get lost, as far as I care):