We've come a long 12-15 years since then. Now you can likely get an HTML spec lead at even less than those rates -- never mind a regular consultant -- Java application servers are now 'free' -- with more than one to choose from -- and domain registration has dropped to around $10 a year with companies like GoDaddy.

It seems the world has pretty much adjusted from the craziness of those days. At least I thought so, until I ventured into trying to buy a domain through a re-seller, then it seemed like 1999 all over again, when I received a counter-offer for the paltry sum of $8,000 U.S dollars. Doing the math, that's an 80,000% return on investment at today's current registrarion fees, for a 9 letter .com domain, that currently gets close to 30 hits a month being parked (yes, THREE-ZERO plain, not thousands mind you ).Here's the story and a tech business that still appears to be stuck in 1999!

After a few word combinations excersises, I settled on 5 different domain variations, ranging from 9 letters to 12 letters, all from words in the following list: fun, video, happy, great, media, top, 10, easy, clip, cd . Sure enough, all the .com variations were taken, there were a few .net variations left, a lot more .cc variations available and all variations from top-level domains like .tv were available.

Beyond the .com domains being taken, what interested me even more was the potential competition! Surely there would be related products/services on those sites with a greater head start than mine. So I pointed my browser to all the sites and it turned out they were all parked domains.

Oh well, no competition at least. But on one of those sites it said 'This domain is for sale'. I really liked the domain which was a combination of three words, so I went ahead and clicked. It sent me to one of the largest re-seller services on the net so I could submit a bid.

Prior to submitting a bid, it presented me with the following information about the domain: Visitors to this domain’s website: 30 (previous 31 days) Previous offers for this domain:0. So 30 times 12 = 360 hits a year. I considered the averages I knew from Adsense -- which the parked domain appeared to be using -- in the 1 to 10 dollars for 1000 impressions. This domain wasn't even getting 1000 visits a year, so what could this parked domain be making $3 to $5 dollars a year ? Or perhaps $30 , if all 30 monthly visitors clicked through ( an unlikely possibility) ?

I went ahead and made a $50 dollar bid for it. However, then it turned out I had to send in a signed sheet to submit a bid. Well I was already into the process, so I went ahead and sent in the special form. In the mean time, I chatted with a friend about what I was doing and he actually laughed at me -- perhaps rightfuly so -- he said 'domain resellers are vultures, they won't make a deal if they don't make 1000%-2000% percent".

I received confirmation I could submit a bid. Taking my friend's advice I went ahead and browsed through the current auctions on the site. Sure enough, most of them ranged in the $100-$500 Dlls, which was in fact a 1000% to 5000% margin on regular domain registration.

I went to the bid page and it turned out the seller was british, so the offer would need to be in pounds, I typed in 100 pounds as the initial offer -- which was equivalent to $160 Dlls. Damn I thought, I sure wouldn't want to pay $500 Dlls for a domain, but I may just be crazy enough and consider it a 'design' expense.

Next day I get a counter-offer: 4,977 GBP, an equivalent to $8,000 Dlls! My goodness and I had feared considering paying up to $500 Dlls for a domain. I'm still having trouble understanding the sellers rationalization for this counter-offer, considering it's a domain made up of three words and gets about 30 hits a month being parked.

Oh well, I had to settle for another variation with a .net extension. But don't think for a minute the heady 90's are over, there are still some people in 2011 trying to make a cool 80,000% return on investment on their technology investments. If your locked out of this business like me, I guess you'll just have to make with the following song to remembre those heady days.

If you've worked with Python and processed any non-english language characters, there's a high probability you've seen the error: "'ascii' codec can't decode byte", in this post I'll explain why this is a common error and how to solve it.

This means that whenever an attempt is made to manipulate something that includes things like a British pound sign £, a French word with a cedilla ç or a Spanish word with accents á, é, í, ó, ú, you're likely to get the error "'ascii' codec can't decode byte".

After all, ASCII doesn't have enough space to represent such characters, so it doesn't know what to do with them, so you get this nice and informative(*gasp*) error: "'ascii' codec can't decode byte". ( The post Why you benefit from using UTF-8 Unicode everywhere in your web applications contains more details on these limitations and ASCII).

Just so you can confirm this for yourself, open up a Python interpreter and type in the following commands:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getdefaultencoding()
'ascii'

Now that you've confirmed this, I'll explain where you can change this so you can avoid all those pesky "'ascii' codec can't decode byte", but also why you shouldn't change this default encoding.

The default encoding configuration in Python is defined in the site.py file located inside the Python interpreter. On Linux/Unix systems this would be under a directory like /usr/lib/python<version>/ and on Windows systems under a directory like C:\Python<version>\Lib\. Inside this file you'll find a method called setencoding and a property defined as encoding="ascii".

Great, so all you need to do is call this method every time you're about to process some special characters, go ahead and try it:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.setdefaultencoding('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'setdefaultencoding'

So what happened here ? It turns out you can't set a default encoding at run-time in Python . This means you're left with two choices. The quick choice is to modify the encoding value inside site.py to 'utf-8' or whatever other encoding you expect to process. The lengthier choice is to address this ASCII encoding issue head on.

There are many explanations on why setdefaultencoding is not available in Python and why Python uses ascii as its default encoding .

You can enjoy reading the technical merits and criticisms for these default choices if you like, but frankly with someone like Guido van Rossum and the core people developing Python having over 200+ years of combined experience developing programming languages, you can likely assume there is a very good reason for these defaults and it's also no oversight.

So how do you solve this ' "'ascii' codec can't decode byte" error without modifying site.py ? You'll need to manually convert characters which can't be handled in ASCII. Here's a walk through of this conversion process.

Lets assume you have some content in a file or database encoded with Unicode/UTF-8 and you want to do some processing with it in a Python environment:

Art. 1º.  En los Estados Unidos Mexicanos todo individuo gozará de las garantías que otorga
 esta Constitución, las cuales no podrán restringirse, ni suspenderse, sino en los casos y con
 las condiciones que ella misma establece.

So you read the content into Python and place it in a variable called content which you then use in a Python third party library like BeautifulSoup or a framework like Django, both of which work by default with Unicode. We can replicate this behaviour by using Python's unicode method as illustrated next.

>>>unicode(content)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 6: ordinal not in range(128)
# Lets see what the variable is actually holding
>>>content
'Art. 1\xc2\xba.  En los Estados Unidos Mexicanos todo individuo gozar\xc3\xa1 de las
 garant\xc3\xadas que otorga esta Constituci\xc3\xb3n, las cuales no podr\xc3\xa1n 
restringirse, ni suspenderse, sino en los casos y con las condiciones que ella misma 
establece.\n'
# And lets confirm the print output  
>>>print content
Art. 1º.  En los Estados Unidos Mexicanos todo individuo gozará de las garantías que otorga 
esta Constitución, las cuales no podrán restringirse, ni suspenderse, sino en los casos y con 
las condiciones que ella misma establece.

So what's happening here ? For one thing the special characters are still there, as you can see by executing print on the content variable. But the most important aspect is the actual characters stored by the variable. Look at how º is mapped to \xc2\xba and á to \xc3\xa1, as well as how the error has a symbol "0xc2" which is used to represent º. In addition, the last part of the message "ordinal not in range(128)" is indicative of the 128 character mapping limit in ASCII ( See Why you benefit from using UTF-8 Unicode everywhere in your web applications for more details on this limit).

Here it doesn't matter if your input was Unicode/UTF-8, since Python defaults to an ASCII encoding, what you get are ASCII encoded Unicode/UTF-8 characters. So any attempt at performing a unicode operation on them and the interpreter balks, since ASCII doesn't recognize such characters.

Of course if you change the site.py parameters in Python to 'utf-8', you would get rid of the issue. Since Python would expect UTF-8 and you would only need to provide it with UTF-8 input.

But how would you make it work with Python's default configuration ? It's simple, since you already know what type of encoding the content is in you would just need to decode it, as shown in the next snippet

# Decode the content using the encoding you know beforehand
>>>hasslefreecontent = content.decode('utf-8')
>>>hasslefreecontent
# NOTE u' to indicate a unicode string and changes to the special character representations
u'Art. 1\xba.  En los Estados Unidos Mexicanos todo individuo gozar\xe1 de las garant\xedas que otorga 
esta Constituci\xf3n, las cuales no podr\xe1n restringirse, ni suspenderse, sino en los casos y con 
las condiciones que ella misma establece.\n'
unicode(hasslefreecontent)
# And lets confirm the print output  
>>>print hasslefreecontent
Art. 1º.  En los Estados Unidos Mexicanos todo individuo gozará de las garantías que otorga 
esta Constitución, las cuales no podrán restringirse, ni suspenderse, sino en los casos y con 
las condiciones que ella misma establece.
type(hasslefreecontent)
<type 'unicode'>

Here you can see a call made to unicode() on the new variable -- which has the decoded content -- works! No more "'ascii' codec can't decode byte". In addition, note that a call to print works as expected and the new variable is of the type unicode.

If for some reason you wanted to switch back to an ASCII representation you could do it just as easily by encoding -- which is the opposite of the process you just did of decoding. Since the process of encoding can be prone to the same difficulties of not being able to interpret special characters, there are a series of options you can use which are illustrated in the following example

>>>hasslefreecontent.encode('ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xba' in position 6: ordinal not in range(128)
# Ups, now ascii didn't know what to do with those special unicode characters!
# Lets try some options 
>>> hasslefreecontent.encode('ascii','ignore')
'Art. 1.  En los Estados Unidos Mexicanos todo individuo gozar de las garantas que otorga 
esta Constitucin, las cuales no podrn restringirse, ni suspenderse, sino en los casos y con 
las condiciones que ella misma establece.\n'
>>> hasslefreecontent.encode('ascii','replace')
'Art. 1?.  En los Estados Unidos Mexicanos todo individuo gozar? de las garant?as que otorga
 esta Constituci?n, las cuales no podr?n restringirse, ni suspenderse, sino en los casos y con 
las condiciones que ella misma establece.\n'
>>> hasslefreecontent.encode('ascii','xmlcharrefreplace')
'Art. 1º.  En los Estados Unidos Mexicanos todo individuo gozar&#225; de las garant&#237;as que otorga 
esta Constituci&#243;n, las cuales no podr&#225;n restringirse, ni suspenderse, sino en los casos y con 
las condiciones que ella misma establece.\n'
>>> 

As you can observe, if you try to encode Unicode to ASCII, Python also doesn't know what to do with those special characters not supported in ASCII. As alternatives, you can opt to ignore these special characters -- in which case the output is blank -- replace these special characters -- in which case the output appears with a question mark -- or use the XML entity representation of each character -- in which case you'll see the representations as &# marks which would make the content perfectly functional on browsers and XML parsers.

So there you have it, two alteratives to solving "'ascii' codec can't decode byte" insanity in Python.

You may also want to read Why you benefit from using UTF-8 Unicode everywhere in your web applications for more on encoding issues in general.

So many definitions and meanings depending on who you ask. But speaking of software consulting and clients. After over a decade of doing consulting work, here's a set of common characteristics or red flags you should be on the look out for when engaging with a potential client. They may or may not apply to your past experiences, but in my case, with over 100 clients and counting these are red flags you should be weary of.

It's one thing for a client to outline a budget -- which helps him limit the pool of candidates/companies to do the work or you the consultant/contractor to determine if you bid for the work -- it's quite another to gauge what someone has to take to complete a task. Such clients generally fall into the "I know how to do this, I just don't have the time" mentality.

So lets get this straight, they know how much it will take -- which implicitly means they know how to do it -- yet don't have the time do it themselves, but are spending time looking and interviewing someone else to do it for them.

Be weary of such busy-bees, they're spending time either way. And there's a high-probability they'll end up wasting your time too, once you dive-in and they start correcting you on every single thing you do or keep you committed to their time slots even though the project may have turned into a time-pit due to the complexity level or changing requirements.

So next time this situation presents itself, act like your friendly doctor or tailor would if you walked in making time demands or deadlines. Walk away or show them the door. If you're an employee, this is a question of office politics and social maneuvering, if you're a consultant this is question of losing time on something you're likely to invest more time than what you get out of it.

The tech company/developer/guy/gal who did this, no longer...: People come and go in every business, so while this may not necessarily be a red flag in many other businesses, in my experience if there isn't a technical liaison to run you through the project details, your predecessor is no longer there or 'they speak I'll of the dead', there's a high-probability you're walking into a snake pit.

For some consultants, having no other technical personnel on a project -- particularly from the client side -- can often seem like a great opportunity, being the only go-to tech advisor. If you're a medium to large consulting company this can often be the case, but if you're a small group of consultants or a solo consultant, you should be extremely cautious.

Businesses that appreciate the value/edge offered by technology, will more often than not have a set of stable in-house technical people and regular contractors to fulfill their work. These will be the people that will walk you through the ropes when you start work on a short or long term contract.

Being the technical lone wolf as a consultant or contractor means the client burns through technical people faster than a knife through butter. Something which often manifests itself in one of several things: a client who can't manage, a client who doesn't have reasonable expectations for technical projects or a client who believes 'tech stuff' just costs a lot of money. Whichever the case, neither is a nice situation to be working from.

I know what you may be thinking: "Hey, even good clients fire people! You don't have to know your predecessor" Yes, indeed good and bad clients fire people all the time or people just come and go. However, in my experience, it's only bad clients who fire or make people quit on whim.

I've had good clients assign me contracts, with some technical people bringing me up to speed who are 'canned' or quit in the following days or weeks. This may sound cold and it's a knife that can cut both ways, but it's savvy management compared to 'off with their heads' on whim style management. And you shouldn't take this personally, you're a consultant which costs money and comes in to do the work someone else hasn't or can't do, so it shouldn't surprise you if your budget comes from someone else.

What should surprise you is if there's absolutely no one to guide you through the technical ropes if you're coming in for a software consulting contract. It's one thing for a client who only requires an 'IT guy' to keep their email and networking ticking to have people come and go. But if it's a client looking for a more specialized kind of software consulting, who already has something in place but 'had to let go' of the previous person, these type of contracts rarely if ever end up being good clients for repeat business.

I'll have more ongoing work for you, once you do this ...: This is probably the grand-daddy of red flags you should be on the lookout for, since it plays into a consultant's/contractor's biggest fear -- permanent work -- and the ones doing the hiring can play you like a fiddle with this tune.

None of the best clients I've had ever led me with this one liner, while on the contrary, some of the worst clients or talks with would-be clients have included this one liner. This shouldn't be a problem for someone who's embraced the consulting mindset, but for someone who isn't totally convinced or is just starting out, the promise of 'stable work' is as alluring as offering a 'prize' to a child if he just does what he should already be doing.

A consultant's job is to solve problems (i.e. do work), if you do this, more work will follow whether from the same client or other clients. Initial consulting work shouldn't be a 'carrot and stick' game, as appealing as the thought of securing carrots for the future may be, don't fall for it.

My experience with clients offering 'more work if you solve this', is that it's either a 'sellers gimmick' -- understanding the primal fear of consultants/contractors of securing ongoing work -- or it's a 'save my burning building' case, from which most savvy consultants have stayed away from, so there's no other way to lure anyone except offering 'ongoing work' in which case additional funds are of course out of the question.

Whichever way I've seen it, clients promising more work as an incentive prior to doing anything is a red flag in my book, especially when the majority of my bad clients have used it. Again, good clients will call you back if you did great work, there's no need for them to use this tactic as a selling point.

I don't have any specs yet, can you call me to discuss it...: Unless you manage and bank-roll an entire team of consultants, you're IBM Global Services or are legally represented by Morgan, Lewis & Bockius, I would advise you against picking up the phone and talking willy-nilly to clients who have yet to define what it's they need.

These situations may present a good opportunity if you're trying to build a medium to large consultancy firm, since they can open the door to larger projects. But if you're just a small group of consultants or a solo consultant, holding a client's hand to arrive at what it's they want can be a very time consuming process, with generally no type of payment commitment.

Even the smallest successful businesses invest time defining what it's they need to overcome their problems. If they don't, no matter their size and using a favorite phrase from one of my consulting buddies, such type of clients generally "don't have a pot to pee in" and they're looking for 'free' advisers to help them figure it all out or as you might imagine 'offer more work' so long as you help them outline their objectives.

So unless you're IBM Global Services -- which does charge for helping clients figure out what they need -- or plan on establishing a medium to large business -- in which case it's the cost of doing business -- helping a client figure out what it's they need, will likely lead you back to looking for a permanent job sooner than you think, due to the amount of non billable time you spend with such would-be clients.

Just sign this non-disclosure agreement and then we can talk...: Though it can be understandable for clients to be weary of sharing delicate information with consultants/contractors, the issue of non-disclosure agreements has made me weary with clients who either don't have a stock ticker symbol (e.g. Fortune 500 companies ) or ones asking for very short-term work (e.g. a few hours or days).

I don't know if it's my own personal experience, but of the last five non-disclosure agreements I've signed, three of them have led nowhere. In other words, talk led to more talk, which led to no type of real work. So thanks for sharing your 'trade-secrets', which I can't sell now, but now I'm also out multiple non billable hours.

Though I wouldn't discard all clients asking for such a requirement, especially given that most large organizations use this as a default practice. I've become weary of this requirement for short-term contracts in non Fortune 500 companies. My reasoning is, if the information involved in the work is so 'delicate' and even talking appears to be so 'lawyered-up' why can't you hire someone permanent ? For a month-to-month contract it may be reasonable, but for hourly-basis or day-basis work ?

In my experience -- and that's a 60% rate of getting nowhere signing non-disclosures -- this is a way to demonstrate an organization's grandeur , no matter if they're working out of their parent's basement, which is a sly way of getting you to fall for the "I don't have any specs yet, can you call me to discuss it..." or "we're a large company and can offer you ongoing work".

I can't help but roll my eyes when I hear statements like "Wow, this is a fantastic app and it's FREE". Newsflash: If you're not paying for a product/app online, then you are the product for the product/app stakeholders.

If you enjoy using 'free' products/apps in the social space (e.g.Facebook, Twitter) chances are good you make up their product as a single individual of a demographic group, which is then rolled up into their product for advertisers.

I once heard it put succinctly "Web 2.0: You create all the content, we keep all the revenue". You think I'm cynical ? Gnip and Twitter have partnered to make Twitter data commercially available . Who is the product again ?

But what about all those free online technical goodies that aren't social apps ? I'll tell you from first hand experience -- since I've been both 'a product' myself and used it for things I've launched online. It's called establishing a market, getting people to 'kick the tires', getting test pilots to get into the cockpit before anyone in their sane mind would use them.

In Crossing the Chasm Geoffrey Moore calls them -- or us in the cases I've been a product -- the technology enthusiasts: they will forgive ghastly documentation, horrendously slow performance, ludicrous omission in functionality and bizarrely obtuse methods...all in the name of moving technology forward.

Any emerging technology product/app starts this way, because there's no established market. In this case technology enthusiasts serve the 'product', as much as they're the product themselves. It's a way to iron out the rough spots, establish a market segment for the product.

I've used and I'm all for things like Amazon 'free' server instances , but I don't kid myself. Amazon is a company -- where altruism plays no role -- free yes, so long as it helps them iron out the bugs, establish a market and determine what are the most desired features so they can get paying customers, in the form of pragmatists and conservatives as Moore calls them.

So free online products/apps ? Yes indeed, but you're the product as well. Money for nothing and your apps for free.

If you've ever downloaded some type of open-source software, you might have noticed there are multiple locations from where to download the software. In most cases you're automatically re-directed to the location nearest to you, so you can download the software faster. This is the principle of CDNs, having multiple copies of the same content in different data centers to increase throughput. The term mirroring is also often used to describe CDNs, given that nodes in a CDN mirror copies of one another's content.

Being that CDNs involve deploying nodes across several data centers, the routing policy between nodes cannot be done by a regular load-balancer that works across local nodes, it requires a higher-level approach involving DNS. This technique used by CDNs is often called global server load-balancing. Figure 1 illustrates this architecture in a CDN.

[ Click on figure to enlarge ] Figure 1 - Architecture for a Content Delivery Network (CDN).

As you can see in figure 1, initial requests from anywhere in the world first consult the DNS server of a domain zone to get a resolution to an I.P address (i.e. the actual server from where to get content). I should point out that by design DNS information is often replicated across multiple world locations to speed-up the resolution process, but this is another issue.

The primary issue with the domain zones used by DNS servers is that most resolve to a single location. This means that when a request is made from anywhere in the world, the authoritative DNS server always returns the same result (e.g. For static.domain.com go to I.P address 210.125.111.1). The problem with this set-up is that all users whether they're in North America, Europe or Asia are sent to the same I.P address. While you could have a massive horizontally scaled web server farm behind this single I.P address, this doesn't change the fact that content has to travel half way around the world to reach its destination.

For web applications consisting of video clips, audio clips or other large payloads, this is an extremely critical performance issue, given user perceived latency. The solution is to dynamically perform DNS resolution on the basis of where requests are made, returning an I.P address to the data center closest to the request. This requires a DNS server to provide different sets of domain zones and respond in accordance with a request's origin. This technique is called split horizon DNS and is the process illustrated in figure 1.

For CDNs this can be done on a worldwide scale, with the same content replicated across data centers in North America, Europe and Asia. Or for more sensitive web applications, on a regional scale replicating content across data centers in different countries (e.g. France, Germany, U.K and Spain) or on a national scale replicating content across data centers in different cities (e.g. Los Angeles, Chicago, New York and Miami).

It's possible to create your own CDN using a DNS name server configured with split horizon, working with a geolocation database like the ones provided by MaxMind or WIP mania to resolve a request's origin and return the I.P address of the closest data center in your CDN. There are several resources on the web for doing this with BIND -- one of the most popular DNS name servers -- which include Split horizon DNS in BIND and Geolocation aware DNS with Bind .

However, considering that setting up a CDN in addition to requiring this type of DNS configuration, also requires you to establish a master/slave architecture and a replication & synchronization process between multiple data centers for all your content -- a process explained in horizontally scaling the static content tier of a web application -- it can require a substantial effort. For this reason, you may find it easier to choose from among the many third-party CDN providers.

One of the leading providers in this space is Akamai , which runs CDNs for organizations like Adobe and MTV networks. In addition, another large CDN provider is Limelight networks which works with clients like Microsoft and DreamWorks movie studios.

There are also other CDN providers targeting small to medium-sized web applications, which inclusively run on-top of these last provider's technology. Distribution Cloud runs on Akamai technology, where as Cloud Files by Rackspace operates with Limelight network's technology. In addition, there is also Amazon's CloudFront which is a CDN operated on top of Amazon's cloud computing services.

This is an excerpt from a book I'm writing on web application performance and scalability. You can find the entire book's contents at http://www.webforefront.com/performance/

• Performance tuning.- This step would consist of refactoring a web application's source code, analyzing a web application's configuration settings, attempting to further parallelize a web application's logic, implementing caching strategies, detecting hot spots and another series of often invasive -- code wise that is -- procedures throughout a web application's tiers.
• Vertical scaling.- This step would consist of migrating a web application or individual tiers to nodes with greater resources.
• Horizontal scaling.- This step would consist of decoupling a tier from a web application or decoupling a tier in itself to run on multiple nodes. In this scenario, instead of adding more resources which is the case of vertical scaling, a web application or its tiers are decoupled so that demand is spread out among multiple nodes.

[ Click on figure to enlarge ] Figure 1 - Decision tree for performance tuning, horizontal and vertical scaling.

As this last figure illustrates, if a development team has very little experience making performance tuning changes, it can be easier to simply skip to the next step of vertically scaling an application or vertically scaling its different tiers. By the same token, if your service provider or data center has difficulties provisioning vertical scaling, it can be easier to simply skip to the next step of horizontally scaling an application's tiers or horizontally scaling tiers in themselves. If neither scaling scenario is plausible and you have an experienced development team, sticking to performance tuning may be the best alternative.

What is 'too expensive' for either of these phases depends on your circumstances. In addition, as a web application matures you will notice that it becomes more and more difficult to achieve any order of performance and scalability in the phases you invest more time in.

The hard part: Horizontally scaling individual tiers

Horizontally scaling a web application's individual tiers can become complex on account of both the technology and design choices made at the outset. However, there are two particular design choices that increase complexity when attempting to horizontally scale each tier: Decoupling and sessions.

Decoupling parts of a web application is critical to facilitating horizontal scaling. For certain cases, applying horizontal scaling to a web application can be simple on account of the clearly defined tier structure. A web application's permanent storage system can easily be transferred to its own node, allowing the remainder of an application to live on a separate node. However, decoupling a web application's individual tier is difficult if it has a monolithic design.

For example, take the permanent storage tier which may consist of a RDBMS. If the data managed by a RDBMS grows large enough, there will be a pressing need to do horizontal scaling once you exhaust both performance and scalability techniques, as well as reach the limits of vertical scaling (e.g. limits of an operating system). Since the tables in a RDBMS have relationships among one another, problems can arise because their data is tightly coupled. In other words, it's not possible to move tables arbitrarily between nodes or split one large table into several nodes to accommodate horizontal scaling, since it could break executing CRUD operations (e.g. On what node is 'table x' ? Is record 999999 located on node 1 which has part of 'table y' or node 2 containing the other part of 'table y' ?).

The same can occur in the business logic tier. If the demands increase exponentially -- due to increased users or elaborate business logic processing -- there will be a pressing need to do horizontal scaling. Problems can arise if business logic is tightly coupled, since you can't arbitrarily place part of your application's business logic in one node, that might be required by business logic present in a another node. Therefore it also becomes necessary to devise strategies to split up business logic to work across various nodes.

In addition to decoupling, sessions are another factor that will weigh heavily on executing horizontal scaling. Sessions hold data for users, with the business logic tier holding short-term data (e.g. for minutes or hours) and the permanent storage tier holding longer term data (e.g. for days or years). Expanding each tier into various nodes creates an affinity problem. Which node holds session data for a particular user ? Figure 2 illustrates this problem.

[ Click on figure to enlarge ] Figure 2 - Node affinity problem – Which node holds a user's session data ?

The scenario presented in this last figure can occur in both an application's business logic tier -- where data is processed temporarily -- as well as an application's permanent storage tier -- where data is stored for posterity.Under such circumstances, it's necessary to ensure consistency by either replicating & synchronizing data across nodes or using 'server affinity'. Figure 3 illustrates both approaches.

[ Click on figure to enlarge ] Figure 3 - Node affinity solution – Replication & synchronization or server affinity

Both approaches in this last figure constitute the most common techniques used to horizontally scale each tier of an application. In addition, they also represent the most common approaches used in clusters and distributed computing applications. Clusters or the more general purpose distributed computing model, allow resource pooling beyond that of the largest individual systems or nodes to achieve a common goal. And it's in this pooling process, clusters and distributed computing applications also achieve consistency among its member nodes, through a software layer that either replicates & synchronizes data among nodes or enforces 'server affinity'.

This fundamental premise of a consistent (i.e.'single and unified') view for each of an application's tiers is key to horizontal scaling. Though a consistent view of a tier made up of several nodes can vary in complexity depending on the tier and nature of an application, as an application designer, this is what will allow you to concentrate on a tier's specific requirements. It won't matter if a particular tier is two or dozens of nodes, a horizontal scaling strategy for an individual tier has to take care of this consistency problem for you.

In fact, one of the biggest advantages of relying on cloud computing services is their built-in ability to scale. This built-in ability is so advanced in some providers that you'll often not even realize if its vertical scaling being done (i.e. adding more resources to a node) or horizontal scaling (i.e. replication & synchronization of data among nodes or 'server affinity' enforcement).

This is an excerpt from a book I'm writing on web application performance and scalability. You can find the entire book's contents at http://www.webforefront.com/performance/

When you write character data in a text editor or IDE for a web application, it's encoded using a series of numbers. When a user's browser receives a web application's content, these numbers are decoded and placed on a screen. When data is saved to a web application's permanent storage system (e.g. RDBMS), it's encoded using a series of numbers. When a web application's business logic code reads data from a permanent storage system, it's decoded to execute the appropriate logic. This same encoding and decoding process can take place at several other parts of a web application that require reading and writing character data.

This encoding and decoding process in character data operates on the basis of character encodings, also called character sets, charsets, character maps or charmaps. But with over 50 character encodings to choose from in web applications, which one should you choose ?

This entry addresses why you should select UTF-8 Unicode for every part of your web applications and how you benefit from doing so.

Most web applications rely on a small set of character encodings that include: ASCII, ISO-8859-1, Windows-1252 and UTF-8. But even with this small set, there can be several differences in choosing one character set over another.

In terms of performance, character encodings are important because they influence the space needed to represent characters. Some character encodings are known as single-byte encodings, while others are multi-byte encodings. Of the multi-byte kind, variable-width encodings are the more versatile, since they can represent characters using 1-byte, 2-bytes or more bytes depending on the character they're trying to represent.

Choosing a web application's character encoding solely on the basis of performance (i.e. the amount of space it uses to represent characters) is generally a bad idea, since it can seriously impact a web application's usability. With variable-width encodings, you can choose a character encoding that's versatile to single or multiple bytes, which is often a better tradeoff -- favoring usability -- than one of strictly following byte efficiency by using single-byte encodings. To understand this, it's necessary to describe the consequences of using single-byte character encodings in a web application.

If you write web applications targeting a particular region in the world, single-byte character encodings like ISO-8859-1, Windows-1252 and even ASCII, can represent the most efficient character encodings. However, even though you're getting performance efficiency by using a single byte to represent each character, you're limiting a web application's usability because single-byte encodings are only capable of representing up to 256 characters (1 byte = 8 bits = 2^8 positions = 256 characters).

ASCII which was one of the earliest character encodings, in fact only uses 7 bits out of the possible 8 bits in a byte to represent characters. The reasoning behind this logic in ASCII -- made around the 1960's -- was that when you counted all the possible alphanumeric characters used by computers, the letters A to Z upper and lower case, the numbers 0 to 9 and special characters like %, *, ? among others things, the sum came to less than 100 characters. Given that 7 bits or 2^7 positions equals 128, 7-bits for character representations was enough, leaving the remaining 8th bit as a parity bit to detect transmission errors -- this again was the 1960's when network transmissions were in their infancy and not very reliable.

ASCII served its purpose until computers required to represent more characters. This brought the need to either make use of the 8th bit in ASCII to increment the total number of character representations in a byte to 256 or use multi-byte character encodings to break the 256 limit on single-byte character encodings.

The first change came with single-byte/8-bit character encodings. Among these single-byte/8-bit character encodings came ISO-8859-1 and Windows-1252. With 256 positions available to represent characters -- double the amount available in ASCII -- many new characters could be supported. The British were now able to represent their pound sign £ on their applications, the French their cedilla ç on their applications and the Spanish their vocals with accents á, é, í, ó, ú on their own applications.

Everyone happy, right ? Not exactly, even though 256 characters were enough to accommodate web applications targeting British, French and Spanish citizens, web applications requiring to represent characters in Arab, Hebrew or Nordic languages (e.g. Swedish, Danish, Norwegian), got squeezed out of this 256 character space. This led to multiple ISO-8859 regional character encodings. ISO-8859-6 supporting characters from the Arab alphabet, ISO-8859-8 supporting Hebrew letters and ISO-8859-10 supporting Nordic languages. As well as the equivalent Windows character encoding variations, like Windows-1256 supporting Arabic characters and Windows-1255 supporting Hebrew characters.

This need to encode characters in a single byte leads to usability problems. For example, the 232nd position in the ISO-8859-1 character encoding represents the è character (Latin small letter e with grave accent). But since other languages need space for their own characters and can do without this particular character, the 232nd position in the ISO-8859-6 character encoding represents the و character (Arabic Letter waw), where as the 232nd position in the ISO-8859-8 character encoding represents the ט character (Hebrew letter tet) and the 232nd position in the ISO-8859-10 represents the č character (Grapheme or latin c with háček).

Care to guess what happens if a web application's permanent storage system uses the ISO-8859-1 character encoding to store data and the business logic code attempts to read it as Windows-1256 ? Or a web application's HTML content is written with the ISO-8859-6 character encoding but accessed with a browser incapable of detecting this encoding ? You'll see character data as either squiggles (e.g. ), question marks (e.g. �,�,�) or characters with different meaning (e.g. instead of an expected è character, you could see ט, و or č). Yes, you gain performance using a single-byte to represent each character, but this is the potential usability penalty you pay for doing so.

Meanwhile, while this single-byte character encoding fragmentation process took place, users in other parts of the world like China, Japan and Korea found the idea of using a single byte to encode characters laughable. Languages like Chinese, Japanese and Korean rely heavily on ideographs -- symbols representing the meaning of a word, not the sounds of a language -- so with single-byte character encodings limited to representing 256 characters they prove inadequate for these languages that can have thousands of characters. These special symbols used in Chinese, Japanese and Korean are often called CJK characters, with CJK being an acronym made up from each language's initial. To address such needs web applications targeting Chinese, Japanese and Korean speakers require to use multi-byte character encodings.

This brought about a series of multi-byte character encodings, such as IEC-2022-JP and Shift-JIS to support Japanese, IEC-2022-KR and KSX1001 to support Korean, as well as GB-2312 and GBK to support Chinese. By using multiple-bytes, an enormous amount of positions are made available for character representations (e.g. 2 bytes with 8 bits each has a potential for 2^16=65,536 character representations and 3 bytes with 8 bits each has a potential for 2^24=16,777,216 character representations), more than enough to satisfy thousands of ideographs in Chinese, Japanese and Korean.

But would you dare guess what happens if a web application's permanent storage system uses the IEC-2022-JP character encoding to store data and you use a run-time (e.g. Java, Python, Ruby) built using ISO-8859-1 to read this data and do a business process ? Or a web application's HTML content is written with the GBK character encoding but accessed with a browser in Europe incapable of detecting this encoding ? You'll be back to seeing squiggles, question marks or characters with different meaning. This is because, multi-byte character encodings also define meanings for each position in their bytes (e.g. the 232nd position in a multi-byte character encoding is used to represent a meaningful character to that particular encoding, like a kanji, hiragana or katakana character, similar to how the 232nd position in an Arabic focused character encoding is used to represent an Arab letter or the 232nd position in a Hebrew focused character encoding is used to represent Hebrew letters).

So is there a solution to all this character encoding madness ? Yes, it's called Unicode, and it's one of the leading variable-width encodings used in software. There are actually several types of Unicode, but for web applications UTF-8 is the dominant choice. UTF-16 and UTF-32 are the other types of Unicode, but UTF-16 is primarily used in run-time platforms like Java and Windows OS, where as UTF-32 is used in several Unix OS. The differences consist of UTF-8 using one to four 8-bit bytes to represent characters, UTF-16 one or two 16-bit code units to represent characters and UTF-32 using a single 32-bit code unit to represent characters.

Getting back to UTF-8 which is the preferred Unicode choice for web applications. How is it that UTF-8 solves the problem of multiple character encodings not getting in the way of each other ? The answer is simple, in UTF-8 there's only a single character for every byte position that is equally interpreted on every system in the world supporting UTF-8. This means that in UTF-8, the 232nd position in its first byte will always represent the è character (Latin small letter e with grave accent), whether it's accesed on a system in Saudi Arabia, Israel or Norway.

So what happens if a web application requires using characters like و (Arabic Letter waw), ט (Hebrew letter tet) or č (Grapheme or latin c with háček) ? UTF-8 also assigns each of these characters an exclusive byte position to unequivocally represent such characters on any system in the world. UTF-8 can do this because it's designed to use up to 4-bytes to represent characters.

UTF-8 defines these exclusive byte positions for characters used in languages with Latin letters (e.g. English, Spanish, Italian Portuguese, German,etc), as well as Arabic, Hebrew, Nordic languages, Chinese, Japanese, Korean, in addition to other characters used in Ethiopic, Cherokee, Mongolian, Thai and Tibetan, to name a few. UTF-8 also defines exclusive byte positions for special characters like currency symbols, emoticons and even music symbols, also to name a few. In essence, UTF-8 provides software representations for practically every character imaginable that's used in computers. You can take a look at the entire set of UTF-8 characters by consulting references like the Unicode charts or this Unicode character chart with named and HTML entities .

The first issue than can come to mind about supporting this amount of characters in UTF-8 is the average number of bytes needed to represent characters. If encoding a basic character like the letter A requires using 4-bytes, this can translate into exponential byte growth requiring more bandwidth, memory and storage for each character, all this overhead just to support characters in Ethiopic, Cherokee or Mongolian a web application will never use.

You can relax on this particular issue. UTF-8 is a variable-width encoding character set, which means even though it can use up to 4-bytes to represent characters, it doesn't mean it requires using all 4-bytes to do so, certain characters are represented using just 1-byte, which makes the overhead concerns of exponential byte growth unwarranted.

UTF-8 designers took a very clever approach to the way characters are assigned among this possible 4-byte representation. The 1st byte in UTF-8 supports 7 bits for character representations (2^7= 128 characters or code points). Can you guess which characters got the privilege of being represented as a single-byte ? The most common set used in computers of course, the same sub-100 character set defined in ASCII in the 1960's. What this means is that the most prevalent set of characters used in software, even encoded using UTF-8, need just 1 byte per character representation, just like single-byte encoding characters sets like ASCII, ISO-8859-1 and Windows-1252.

So why doesn't UTF-8 use all 8-bits in the 1st byte to represent characters ? Since UTF-8 is a variable-width encoding character set, it needs a way to indicate if a character is made up of a single-byte or multiple-bytes. Therefore one bit of the 1st byte in UTF-8 character representations is reserved for this purpose. Following this same rational, 2 bytes in UTF-8 support 11 bits for character representations (2^11 = 2048 characters or code points), 3 bytes in UTF-8 support 16 bits for character representations (2^16 = 65,536 characters or code points) and 4 bytes support 21 bits for character representations (2^21 = 2,097,152 characters or code points). Here again, the reason UTF-8 doesn't use the entire 8-bit spectrum across the 4 available bytes, is due to UTF-8 reserving bits in each byte to determine if it's a single-byte code point, a multi-byte code point or a continuation of a multi-byte code point.

But wait, does this mean UTF-8 requires 2-bytes to represent characters that in character encodings like ISO-8859 and Windows-1252 could be represented with 1-byte ? Yes, since one bit in the 1st byte of UTF-8 characters is reserved. But don't get hung-up on small details. How many web applications have you written made up entirely of characters in the upper boundary -- above ASCII characters -- of single-byte character sets ? Characters like £, ç, á, é, í, ó, ú ? Not many I would think. Since such characters are used sparingly, the tradeoff between using 2-bytes instead of 1-byte for such characters, is well worth it when you consider the usability benefits of UTF-8.

But wait, what about CJK characters, won't UTF-8 need 3-bytes or even 4-bytes to represent them ? Yes, but again this shouldn't be an issue considering the usability benefits of UTF-8. Web applications that require CJK characters one way or another need multi-byte character encodings, so it's not like UTF-8 adds extra overhead for representing characters that would still need multiple-bytes to be represented.

Even though the maximum character definitions permitted in UTF-8 is 2,097,152, the most recent Unicode standard version 6.0 released in late 2010 defines a little over 100,000 characters or code points -- 109,449 to be exact. Among these 100,000 characters you'll find definitions for the barrage of characters already described earlier like Cherokee and Mongolian, all the way up to Vedic Sanskrit. Considering there's still room to add characters to the tune of nearly 2,000,000 character representations, UTF-8/Unicode is likely to accommodate characters for some civilizations to come.

Use UTF-8 in your web applications and ensure their usability without any performance or storage penalties.

This is an excerpt from a book I'm writing on web application performance and scalability. You can find the entire book's contents at http://www.webforefront.com/performance/

You can read the headlines enticing both sides. 'How to hire and retain the top 1% of developers', 'Be a ninja or rock-start with our team', 'How to crack the interview questions at X','Interview the right way', 'Avoid saying the wrong....'

There are blog posts, articles, even entire books dedicated to the right and wrong way to both conduct interviews and being interviewed.

After more than 10 years doing software, as a contractor, employee, interviewer and interviewee, trust me there is no right or wrong way to do an interview. There are just types of interviews that you can ace or bomb depending on your skills and attitudes.

As a contractor, you get the chance to live in the dynamics of interviews, without getting pinned down to the same approach. Either constantly looking for new gigs or interviewing the permanent employee who will take your place once your contract ends

I'm not advocating any approach or saying one is better than the other, this is just what I've seen with a few tips on how to get through.

The Navel gazer - We hire 1 out of every 1,000,000 applicants

Navel gazing - Excessive introspection, self-absorption, or concentration on a single issue. You probably know them from the thousands of recent CS graduates beating down their door to get the chance of even getting an unpaid internship. Their technology is so cool and used by billions, that navel gazing interviews questions are a must to see if you fit in.

The issue with these organizations is that they're so succesful in their market and have so many possibilities for their products, that they're not looking for any specific skills, just talent that can be found in 1 out of 1,000,000 applicants. If you are one of those rare pearls will depend on how you answer a series of navel gazing questions.

So what do I mean by navel gazing questions ? Here are two examples I've been put to the test with.

             What do you see ?

   A    < Network boundary>    B 
    
                  AND 

      What happens when this is called ?  
       
              <img>

         

So what do you see ? Uh ? Two systems called A & B ? An HTML <img> tag ? So let the grilling and navel gazing begin. So 'How would you connect systems A and B, would you use an interface?' Ah yes, interfaces they'll allow you to make future changes easier and....'Yes go on' 'Mmm a facade design pattern can also help ensure.....' SILENCE 'Yes what else?'. So 'What does that tag do?' Get an image from the server and...'Is it an HTTP GET ?' 'Yes and it also depends... ' SILENCE 'Yes what else?'

The thing that can be so distraughtful about these type of open-ended questions is they're not designed to see if you can solve real or actual problems, as most companies do. Remember, you plan on working with the leader in X field who only accepts 1 in 1,000,000 applicants. You need to be able to think outside the box for all the future and unknown problems you'll have to solve.

The problem is that if you can't get inside the head of your interviewer, going down the right path to such open-ended questions can fee like crossing a mine-field. Every pause or silence can feel like hearing a buzzer - 'BZZ-Wrong'.

The best thing you can do is relax, these are open-ended questions. So just go with the flow as best you can, as if you're talking to a buddy over a new technology or application you wrote. If you can latch onto a topic mentioned in the interview and talk about it for 15-20 minutes non-stop like the last time you went on vacation or something you read, you should be in good shape.

But then again, there are no promises. These interviews are crapshoots since they only hire 0.000001% of all applicants, they can't even possibly give you feedback on where you went wrong. You'll unfortunately become a false negative (not hiring the right person) as the other 999,999 people before you.

The new night club  - We hire 1 out of every 1,000,000 applicants, though we're still less than 50

Start-ups in an attempt to create the allure and image of a large succesful tech company, employ the same tactics as the navel gazer interview process.

Such organizations have a long way to become household names in the tech sector, which makes them operate a lot like night clubs. They create a lot of buzz and go to great lengths to make it appear as if there are long lines of people outside wanting to get in. Of course, like night clubs you might be in for a great time or hell of a time.

They will try to mimic the navel gazer interview down to the last detail to show how cool they are. But telling signs you're dealing with a new night club interview are: head counts lower than 50, 'fuzzy' product roadmaps or still to be released products, signing of non-disclosure agreements or 'stealth' operations.

Not all start-ups or small organizations use this interview process, in fact I would say the majority don't even expend this much energy trying to mimic navel gazing interviews, since they have actual work to do and take a more practical approach to interviewing, but still there are some out there. I would frankly be weary of anyone trying to pull the new night club interview process, but proceed at your own expense.

Buzzword compliant - We don't care if you can't walk, just talk the talk

10 points: "A cloud based CRM written in Ruby on Rails using Varnish Cache, HTML 5 compliant, that supports REST APIs that don't even exist yet that can connect to CouchDB and Cassandra".

ZERO points: " A distributed multithreaded application that can run on any browser and can use many data sources"

This is a favorite interview process for technical recruiters that have never worked on any type of software project. The irony in these interviews is that since the person conducting them is not technical, yet they're trying to gauge your technical abilities, they're loaded to the brim with jargon.

They range from the ridiculous to the funny. With questions jumping from project management technology, to mobile applications, to server-side technology, to storage technology, all in the span of 5 minutes. Buzzword compliant interviews are often buffers for follow-up interviews of the navel gazing type or more problem solver types.

Depending on the organization doing the actual hiring, the person doing the interview may not disclose many details or even act mysterious, but unlike the night club type process, an interviewer conducting a buzzword compliant interview actually doesn't do it to create an aura of coolness, it may actually be he has no idea about the work you'll do, not to mention he may not even know who is the hiring company! It's likely it's a third-party for a third-party.

Personally I find this to be one of the most wasteful interview processes, since it's a filter to get you into another type of interview. However, I have found it to be endemic in both small and large organizations alike, so you'll need to develop some dexterity in buzzword manipulation to get through these interviews.

Business problem solver - Consulting Big 5 - Fortune 500 style

These technical interviews focus on judging your skills from a business perspective.

• What they don't want to hear : Designed a Java EE application using BPEL to process HR applications
• What they really want to hear : Designed an app that handled 1,000,000 HR applications using Java EE and BPEL.

Though still technical, these types of interviews are designed for you to show off how you can solve business problems using technology. If you can express number of users, transactions, sizes, costs savings and mix-up it up with some technology jargon, you should do well in these interviews.

Code ? Why ? You have tools. These interviews tend to a focus a lot on tools if anything when discussing technology. You're more likely to be questioned on tools you've used, than on raw programming language questions, or god forbid writing code.

It always surprises me to see the lack of interest in coding skills on these interviews. But I guess when you can use the latest and greatest tool for automating BPEL process for a CRM backed Oracle database using Java EE, writing actual code comes cheap or can be outsourced to another organization.

Technical problem solver - Start-up style

Unlike the business problem solver interviews, technical problem solver interviews focus intensely on design and code, code and more code.

Unlike the navel gazer or night club interview, technical problem solver interviews are based on specific platforms or APIs. If you're interviewing for an OSGi position, you can expect questions like "How have you used OSGi in "X" scenario ?" or "How would you use OSGi in "Y" scenario ? In other words, questions designed to gauge your personal experience.

Though showing off your business problem solving abilities can also help in these types of interviews, remember that most organizations in this space either don't have the budgets or require custom software that isn't available as a tool ( or are actually attempting to write a tool in itself).

For this reason, interviewers in this space are more concerned with your abilities on writing code, than on using "X" tool. They will probably be more impressed with your work on GitHub or Stack Overflow, than what you tell them you did with your past employers.

If you're the kind of person that thrives on writing code and can do amazing things with it -- better yet show it of on a public forum or open-source project -- you're sure to do well on these types of interviews.

In the wild - Multiple interviews

You're likely to be interviewed by many people in an organization during the course of applying for a single position. Though interviewers tend to morph into a particular kind depending on the time they've been with a company, given the mobility or churn rate in the tech sector you're likely to face a variety of interviewing types.

If it's an ex-tech navel gazing type that recently joined a start-up, it's likely you'll face a more grounded technical problem solving interview or it could be the 'new night club' interview process which attempts to make a small start-up seem like it's already the next big thing. Your mileage will vary depending on the funding and how grounded the people doing the interview process are.

On the other hand you could also be dealing with a small consulting company -- technically speaking a start-up of 5 to 10 people -- that focuses more on the business problem solving interview. No surprise you would be dealing with interviewers that have a background working in Big 5 or Fortune 500 companies, where code and programming language expertise have little weight.

And depending on how upper management or the founders set up recruiting practices, you may face a barrage of buzzword compliant interviews or none at all.

In case you're also starting to use OSGI or Spring-DM in your Java projects, here are some things to consider when choosing an OSGi distribution.

For most Java projects looking to leverage OSGi -- I would venture to say 75% or more -- versioning is the primary purpose. Run-time versioning is a feature missing in Java since its inception. Though there have been attempts to create an alternate approach to OSGi (e.g.Project Jigsaw) with Oracle acquiring Sun and what appears to be the release date and feature set of Java 7 being held in limbo, OSGi is still the only thing that already works for this purpose.

Using OSGi on this front, simply requires that all your application JARs be equipped with a MANIFEST.MF file containing the dependencies and versions it offers and requires. You could create these JAR files yourself, get them from a specific OSGi distributor, download them from SpringSource's OSGi repository or use some other alternative.

In fact, these same OSGi bundles or JARs can just as easily run on any Java run-time whether you use an OSGi distribution (e.g. Felix, Equinox) or not, this is one of the benefits to using OSGi, its non-invasive nature. Of course, if you do you use an OSGi distribution, you'll be alerted of missing dependencies or versions for each bundle/JAR you install (a.k.a. run-time versioning)

So which OSGi distribution is best for this purpose ? Pretty much anyone, so long as they're said to be OSGi compliant. This would be like asking, which Java JDK to use for a Java application ? Oracle's JDK ? OpenJDK ? IBM's JDK ? They're all JDK's, so standard Java applications should run just the same. The same case applies for selecting OSGi distributions for projects requiring OSGi versioning functionality.

The other thing OSGi supports are services. Forget about web services, REST, SOAP and all the other things you associate with the term services. These are OSGi based services. Upon installing a bundle/JAR, a service is registered through OSGi that can be used by other bundles/JARs. In true form to OSGi, you can also require certain bundles/JARs to have the presence of a certain service to run, just like requiring certain versions.

These OSGi services can range from calculating a tax rate to running a web server, they're just services backed by logic coded inside Java classes. However, the process of registering, discovering and removing such services can be a complicated matter, since it needs to be done using application APIs, not just a basic MANIFEST.MF text file placed in JARs.

To reduce the work needed to run OSGi services, Spring-DM came onto the scene. Instead of having to deal with OSGi APIs for this purpose, Spring-DM brought the same approach as its big-brother Spring framework. OSGi services could be registered, discovered and removed through dependency injection and deployment descriptors written in XML, while the services themselves based entirely on POJOs ("Plain Old Java Objects").

The approach set forth by Spring-DM set of a series of events within OSGi, which actually got its start in the embedded/mobile technology market. Realizing OSGi was of use in enterprise scenarios like those solved by the Spring framework, OSGi defined an enterprise specification group designed to work with issues like transactions, database access, JMX integration, JNDI integration. among other things.

You can think of this development as the relation between Java SE and Java EE. There are the standard OSGi distributions that can work with the basic versioning and programmatic service model of OSGi (Equinox, Felix, Knopflerfish). And there are the OSGi enterprise distributions that can work with OSGi services operated with dependency injection (Spring-DM) and Java web container (dm Server), which require to run on top of a standard OSGi distribution.

One important fact about OSGi's enterprise initiative is there wasn't an explosion of implementations, unlike Java EE. In fact, to date there is only one implementation which is composed of the several parts that make up the specification.

The enterprise OSGi reference implementation has now been grouped into Project Gemini under the guidance of Eclipse, creators of the standard OSGi implementation Equinox. With Spring-DM now being named Blueprint services, albeit offering the exact functionality and code as Spring-DM (i.e. dependency injection for OSGi services) now evolving alongside the remaining parts of the OSGi enterprise specification.

So given that the OSGi enterprise reference implementation is now under the guidance of Eclipse, is it better to use Eclipse's Equinox standard OSGi distribution ? If you think you'll be requiring some of these enterprise OSGi features it could be a good idea, just like using a IBM's JDK with one of IBM's enterprise Java products is a good idea, though this shouldn't stop you from using any other JDK if you like.

If you'll just be using OSGi's run-time versioning functionality you should have no problems using any standard OSGi distribution (Equinox, Felix, Knopflerfish), they're after all based on the same OSGi standard, which inclusively shouldn't preclude them from working with OSGi's enterprise parts (Gemini) in case you require it.

As a user, I find this feature very helpful because it tells me on what site I will end up when clicking on a link, not to mention a URL can be sufficiently descriptive to give me added context about what I'll read next.

Which is why I find URL shortners disruptive. Up until a few years ago, there were just a few URL shortening services, but now that Google has made its URL shortening service public -- http://goo.gl/ -- it appears the inevitable is upon us.

Are URL shortners really warranted on the web ? Here are some technical and usability facts.

One of the few situations I've seen URL shorteners being a must is on services like Twitter. Here is a service that allows users to publish messages with a maximum of 140 characters. So what happens if a user wants to share a link to http://www.webforefront.com/archives/2010/09/java_the_king_i.html . Ouch, a link like this is almost half the allowed character length. Instead, a URL shortener could be used, to provide a link in the form http://t.co/Dsdc13A that would take the user to the same destination.

Ok, this is fine for Twitter because it has this type of restrictions. But why use it on the web ? Look at all the context that's lost. For starters, user's won't know where the link is pointing to, this alone can make many users weary of clicking on such a link. In addition, you loose other facts that can be taken from a URL. 2010/09 can be interpreted as a publication date and a document's name java_the_king_i. can give further details about the destination content.

Now that I've mentioned Twitter's character limits, let me put in a word about standard URL limits (i.e. On the wider Internet). URL limits on the web depend on two key components, a browser's maximum URL character limit and a web-server's maximum URL character limit.

The maximum URL character limit supported on the lowest-end browser is 2083 characters, where as the maximum URL character limit supported on the lowest-end web-server is 4,000 characters. You can find the entire list on What is the maximum length of a URL ?.

2083 characters is a lot for most web links. So are there exceptions ? Similar to Twitter, I would classify these exceptions for very particular scenarios, specifically where URL's have no-human meaning.

One case is for analytics, where links are used to track clicks among thousands of users, in which case URLs are also short-lived (i.e. intended for a single user or position). Another case would be related to geographical applications, which can require dozens of parameters to take a user to a particular location, a URL shortener provides a less-error prone URL than one with multiple parameters that shed little information to an end-user.

In fact, if you read Goo.gl url shortener is now open to everyone! by Matt Cutts, it explains Google's URL shortener was used for these and other similar internal and controlled scenarios inside Google.

So what's my problem with URL shortener's being used to create links on the wider Internet, beyond these specific cases ? They deny users a sense of meaning of where they're are going to be taken next.

But hey, don't take my word for it, take it from one of the primary authorities on web usability: Jakob Nielsen.

In URL as UI Nielsen advises to use URLs that visualize the site structure and URLs that are "hackable" to allow users to move to higher levels of the information architecture by trimming off the end of the URL. Unfortunately for my case, Mr Nielsen also advises to use short URLs and easy-to-type URLs.

It would be interesting to know what Jakob Nielsen thinks about URL shorteners in particular. But I for one don't believe the web will benefit from having such links spread out on the wider Internet.

The problem though is that Java is a huge platform, so saying its 'dead' or 'its the greatest technology in the world' is likely to be skewed. What part of Java exactly ? Mobile devices running J2ME ? Server-side web applications using JSP's/Servlets ? Game development ? Desktop applications ?

I wont focus on the negative aspects, since you can easily search the web for these often fruitless discussions. I will focus on what I've personally experienced and read are very productive and successful Java projects.

Projects can take months to develop, yes. It can take 1,000 lines of code to do what other languages would take 100, yes. There can appear to be millions of libraries and APIs that do the same thing, yes. But you know what , projects get done by some of the largest organizations and these aren't even issues many managers care about.

At the other end of the spectrum we find start-ups. For many of these one or five person teams, waiting months and writing thousands of lines of code is a no-no, in fact these terms probably don't even register. Everything has to be fast-fast-fast. If you look at 'Java' through the same lens as large organizations, Java is a dinosaur.

Most start-ups go by default with Ruby-Rails or Python-Django, because they're fast-fast-fast to develop with. I can personally attest these languages and frameworks are faster to develop with than Java, but that doesn't mean that Java is that shabby in this space.

Java can also be fast-fast-fast to develop with if you look in the right direction. Projects like Grails and Roo in fact grew by adopting techniques in the Ruby-Rails and Python-Django playbook. So for many start-ups Java is far from 'dead', it can be a viable option using some of these Java-compatible frameworks.

And for what I will make the 'poster boy' of this entry, I come to game development. What would you say of an independent game developer making $350,000 Dlls (U.S) a day for a game developed in 2010 of all things on : Java.

I don't know about you, but Java can't be that 'dead' when it can compete in a 2010 game market and generate this type of income for a single application. In case you want to take a shot for yourself, I believe this very successful game -- called Minecraft -- is built using the Lightweight Java Gaming library . Yep, another one of those million libraries available for Java.

So calm down Java demisers. Some parts of Java may be rotting away, but there are other parts -- even in 2010 -- that are clearly thriving. One bad apple doesn't mean the whole crate is bad.

You might ask 'leap of faith ? , why ?' Well because that 'secret sauce' that makes your provider's services so appealing (e.g. fault-tolerance, automated scalability. etc), is of course: secret. This means you can't just walk away and take your application to another cloud computing provider.

If you're an extremist like Richard Stallman , you might even say cloud computing is trap because it operates like this. The OpenStack initiative is aimed at easing these fears of cloud provider lock-in.

OpenStack compute is designed for provisioning and managing large-scale server instances. Which means if you rely on it, your applications won't be at the mercy of a particular cloud computing provider, given that OpenStack is an open standard.

OpenStack compute is built on Python, the Tornado web server , the Twisted framework for distributed applications, the AMQP messaging protocol and the Redis distributed key-value database . Everything in the open, so moving from one provider supporting OpenStack to another is transparent. Or in case you want absolute control, you can install OpenStack on your own hardware. You're application would work the same.

OpenStack object storage is designed to provide reliable, redundant, and large-scale storage of static objects. So here again, if you're weary of using a cloud computing provider's storage services, for fear your applications will be locked into a technology you have little control over, OpenStack object storage offers an open alternative.

Though OpenStack is still in its infancy --with only a 'developer preview' release -- it has over 30 organizations backing its efforts, which include: Citrix, Dell, NASA, Intel and AMD.

Here is Richard Stallman who has done so much for open source software, coming out and declaring that cloud computing is a trap .

Stallman declares "If you use a proprietary program or somebody else's web server, you're defenseless. You're putty in the hands of whoever developed that software."

Again, there is no reason to see this in just black or white. Yes, if you start using the Google App engine and they suddenly jack-up the prices, you will be defenseless. As you would be defenseless if you relied on Amazon's SimpleDB service and the service went down or got attacked.

But look at what you're getting in return. Applications that scale without having to worry about the internal details once demand picks up. Not to mention all the other goodies like not having to worry about backing-up your data, a hard-drive suddenly failing or ensuring server uptime.

It appears Stallman suggests that everyone should run their own data center so they can have absolute control over their data and software. I hate to break it to Mr Stallman, considering all he's done to advance the cause of open source software, but the majority of people and organizations are willing to get into this trap because its a convenience, one that offers more benefits than touting to have this radical definition of freedom.

Slowly but surely, the results are starting to materialize. Which include the departure and inclusion of heavyweight IT names, as well as the reassurance and cancellation of certain product lines.

Reading between the lines, it initially appears Gosling's departure was due to money issues, as he gripes: "For the privilege of working for Oracle, they wanted me to take a big pay cut,". We all care about money of course, but considering Gosling's stature and station in life, I doubt this meant taking him off a CEO-like gravy train salary. But then he goes on "My ability to decide anything at Oracle was minimized...myself and my peers in the Java area were not allowed to decide anything. All of our authority to decide anything evaporated.”. Ah, so it was something besides money.

And then he goes all out saying what he really thinks about Oracle culture. Talking about an abruptly canceled event he says: “The word came down that Oracle does not do employee appreciation events...On the other hand, Oracle sponsors this sailboat for about $200 million.” Ouch.

In another interview, related to his first non-show at Java's iconic JavaOne conference Oracle and Java Its Business Not Personal, he sums up the situation best with the following: "“Oracle is driven by the spreadsheet. And there are things I admire about that. The problem is when you’re doing everything with spreadsheets and you’re trying to do innovation you end up with things you can’t really quantify"

And speaking of spreadsheets, another key figure -- but this one coming into the Oracle/Sun mix -- is Mark Hurd, HP's ex-CEO. Here is someone that during his tenure at HP was notorious for cost-cutting measures -- Mark Hurd's management style -- never mind the salacious nature of his departure from the helm at HP . All the better reason with his cost-cutting nature, to now be an Oracle co-president, director and board member.

Though it would be unfair to compare Gosling to Hurd, you can't help but think what type of people/culture now prevails in this post Oracle/Sun merger.

Changing to the topic of product lines. In the Java product line there already appears to be some important changes, with the upcoming Java 7 release being scaled back and a new roadmap for JavaFX , the last of which is Java's offering to compete with Microsoft's Silverlight and Adobe's Flash.

And as you might have known, prior to Sun's involvement with Java, it was mostly known as a hardware company. So what's going on with their high-end hardware offerings after the post Oracle merger ? Another interesting series of events.

It appears Ellison does believe in the importance of performance and scalability , since he's declared full-speed ahead on Sun's SPARC processor line. SPARC's newest offering is after all one of the first 16-core processors on the market. It's offered as a single socket 16-core blade server up to a 4-socket 64-core server capable of executing 512 threads. Without a doubt, providing extreme performance and scalability. However, Ellison being the hard-nosed businessman he is, there are now strong rumors Oracle will kill AMD on Sun Servers.

Update: Another key departure I just read about is Jeff Bonwick's departure . Jeff is the creator of the ZFS filesystem, which as you might imagine was a Sun sponsored project.

The obvious answer would be to consult the security documentation of the software you installed, DUH!. But I digress, would-be exploiters would know this like the back of their hand. However, there also aren't many broad security standards o guidelines to follow. So here are some tips and resources I've given to clients, many of which don't just pop-up on Google when you search "secure system" or something along those lines.

But how does the CIA or Mossad secure their systems anyway ? They're unlikely to publish their techniques, but I often follow the closest possible public documentation to what a high-profile government agency does to secure their systems. I'm talking about the NSA or U.S National Security Agency.

The NSA has a dedicated Security Enhanced Linux project. But among the many resources they publish, I've found their operating system security guides to be invaluable. They include guides for securing Mac OS, Linux and Windows.

Once you've hardened an operating system, which is really all you can do initially, we get back to our cat and mouse game. What happens if after a few months a security vulnerability is discovered and a 'script kiddie' comes knocking at your door ? Well, you need a really good full-time system administrator to constantly monitor and apply patches to your systems.

If you don't have a budget for a full-time systems administrator, the next best thing you can do is at least run a monitoring system on your network to detect security risks. In this area one of the best tools I've seen is Nessus . In price, it's by far one of the most accessible tools of its kind, free to try out and around $1,000 Dlls (U.S) for annual updates. The updates function as PC anti-virus software, as soon as a vulnerability is discovered, you get updates so you can check for them on your systems. Nessus can check for security vulnerabilities ranging from Windows and Linux operating systems, to application software like Oracle, Java and Cisco routers.

And finally, speaking of applications. If Oracle, Microsoft or Cisco discover security vulnerabilities they'll likely be quick to emit a fix,as well as using a tool such as Nessus is likely to help you discover them in a timely fashion. But what happens if one of those in-house applications has a security hole ? For in-house applications, there isn't much you can do except educate your own software development teams.

The security vulnerabilities a development team can unknowingly introduce into a web application are many. Some are programming language specific, web framework specific or inclusively of a more general web application nature. Here I would point you to the Open Web Application Security Project (OWASP) which publishes a great number of resources for educating development teams on web application security.