Taking The Big Leap To Achieving Web Business Freedom


Picture in your mind a high, windswept cliff overlooking a deep canyon. From the top, it’s impossible to see into the seemingly bottomless abyss below.
At the top of the cliff, a small crowd has gathered. Minutes before, a solitary, simply dressed man had approached and gotten their attention. He is curiously carrying a large, red toolbox.
“In just a few minutes, I’ll be jumping off the edge of the cliff,” the man said.
A loud gasp rippled through the crowd. A voice shouted, “Are you crazy? You’ll get yourself killed!” Others chimed in:“Don’t do it!”“Hey, mister, whatever the problem is, there’s got to be another solution!”“You’re throwing your life away!”
The man raised a hand to speak, and the crowd grew silent.
“I know you think I am insane, and what I’m about to do probably is, to a degree,” he began. “But they’re a couple things you need to know.
“First, I’m not the first to jump off this cliff,” he continued. “In fact, it happens many, many times every day.” The crowd murmured, with some pressing a little closer and some taking a step back.
“Sometimes there are groups like this watching, and sometimes not,” the man said. “Some watching want and even hope the person will plunge and not make it. Yet others pray the person will somehow avoid certain disaster, and offer what encouragement they can.
“Second, whatever the reason that brings them to the edge, the people who take this leap share a few things in common,” he said. “They’re at a point in their lives when they feel they have no choice but to jump into the void. Life has driven them to the precipice, and they are eventually willing, despite all fear and doubt and despair, to take the plunge.
“Finally, each person stands at the edge with a toolbox, much like this,” the man said. He held up the shiny, red toolbox. “Inside each person’s box is a unique set of tools. No two sets are alike. But each literally holds the keys to their future—whether their leap ends dashed on the rocks, or whether they are able to build wings and fly.”
A woman from the crowd interrupted. “That is ridiculous!” she said. “Once you take a leap like that, no one can possibly use ‘tools’ to save themselves, much less ‘fly!’”
The man looked at the woman, and then around at the others, and smiled.
“Fortunately, this is not just any ordinary toolbox,” he said. “For the ‘tools’ represent all the talents and qualities that make up each person’s life—their attitude about success and failure, their willingness to let go, their belief in themselves, and so on. And even for people who seemingly lack any special knowledge or skills, often there is real magic that takes place, enabling them to save themselves and even others!”
The man was silent, and let his words sink in. Then, he picked up the box and turned to face the edge. Suddenly, and without looking back, he went over and was gone in a flash.
The people rushed to the edge, waiting and listening and wondering what fate would bring the crazy man with the red toolbox.

Ads, comments & social bookmarking, these are all things that website owners hope & wish that the visitors to their sites will click on.


There are some questions that seem to have no definitive answers bouncing around in my head. Ads, comments & social bookmarking, these are all things that website owners hope & wish that the visitors to their sites will click on or participate in. Lets discuss each of these three items and see if you can help answer some questions I & perhaps yourself have.
Ads
Do you click on ads when you like someone’s website? Is it inappropriate to click on an ad if you enjoy a site knowing it will just send two cents or a dollar into the owners ad account(s)? Are we as visitors adverse to doing this or do people just not know that it helps contribute to the designer of said site?
I know that there are many sites I have enjoyed over the years and on some I have never clicked on an ad. As I look back I wonder would it have been so bad to click an ad or two to show my appreciation. Lately I have been clicking on an ad if I actually enjoy someone’s site. In some cases I will even click an ad if the article I am reading just captures my attention so that I read it to the end.
Think of clicking on ad as paying for a newspaper or local news rag. The small amount that the owner receives should entice them to create more & more enjoyable content. Maybe in this way we can reward those who deserve it for their contribution. Perhaps by clicking on a skyscraper ad versus a smaller ad depending upon our enjoyment of the site or content would make us a true connoisseur of the content.
Comments
While I have less thoughts on this subject, more of a piece of advice really, here’s one question. Is it proper etiquette to leave a comment about an article if you enjoyed it? Have we as visitors really gotten to the point where we move too fast that this one minute would slow us down? I am myself also guilty of not leaving comments but am really putting forth an effort to do so lately.
My piece of advice is actually common sense but there are still some people out there, blog owners mostly, that do not have captcha or do not moderate the comments posted on their sites/blogs. This allows spam of the highest proportion to flood their blogs. Have you that moderate your sites comments seen some of the stuff that spammers try to get thru? I have seen comments that are like whole entire miniature websites of links try to get posted on this site.
Moderate your comments!
Social Bookmarking
With the advent of social bookmarking like Digg, StumbleUpon, Buzz & Technorati among others a whole new way of grading or reviewing websites & articles has opened up. Websites and blogs can now be graded by visitors Digging or Stumbling your content, this can either bring you yet more visitors if your content appeals to the masses or just leave you stuck on the sidelines if graded poorly.
My question is do you actually take the few seconds to socially bookmark a site or article? Clicking an ad would be more my style as it just seems quicker to me, I am lazy, but I am getting in the habit of socially bookmarking more & more. When an article of mine gets Dugg or Stumbled it brings in more & more traffic making me feel liking writing more often.
There is nothing more rewarding than going from 50 -60 visitors a day to 200-300 for a webmaster. To reach the front page of Digg or any of the other social bookmarking front runners out there is the pinnacle of achievement for a writer. While I have yet to obtain this lofty status I can aspire to one day climb that summit.
Afterword
I hope to receive some answers to my questions knowing that some of you out there have answers of your own. Clicking on an ad, making a comment or socially bookmarking will not hurt you in any way, shape or form. In fact it might make you start to reward those who do well in their endeavors. Some of you can explain if you feel that my opinions could be considered proper website or blog visitor etiquette.

Mule has the ability to notify you when certain key internal events occur.

Mule has the ability to notify you when certain key internal events occur. It can, for example, raise a notification when a transaction is successfully committed or when it has successfully completed loading. This facility is not very well known and I thought I would create a series of blog posts to talk about it and show how it can be used.
Let me first point out that these notifications are NOT Mule messages. The notification is NOT sent to an endpoint. It is NOT sent via a router. It has nothing to do with the messages that would be sent through a normal Mule application.
The only way you can receive these notifications is if you create a POJO that is registered to listen for them. There are (currently) 12 different types of notifications that Mule can raise:

Manager notifications are raised while the state of your Mule application changes, such as when it is initialising, starting or even stopping.
Model notifications, on the other hand, are raised when the state within a single Mule model (identified by the XML elements) changes. You will also receive notifications when individual components are being registered or unregistered.
Component notifications are specific to state changes for individual components. Whenever a component is started or stopped (or paused and resumed), a component notification is raised.
Connection notifications are related to transports and can tell you whether it was un/successful in connecting to the underlying resource or whether the resource was released.
Message notifications are fired when a MuleMessage is sent or received by the Mule application. While ideal for tracing, the performance impact when using these is tremendous and it is disabled by default for this reason alone. It is the only notification to be disabled by default.
Exception notifications indicate that an exception was thrown.
Transaction notifications show a change in the life cycle of a transaction and therefore shows whether a transaction was started, committed or rolled back.
Security notifications indicate that a request is denied security access.
Space Monitor notifications are related to space implementations such as JavaSpaces, when messages are sent into, or received from, a space.
Admin notifications are fired when requests are received by the Mule Admin agent, usually from the MuleClient through the RemoteDispatcher, which proxies calls to a remote server.
Custom notifications - can be used to raise notifications of your own.
Management notifications show that monitored resources are low ( but this has yet to be implemented)
By being able to monitor certain key events within a Mule application, you can react to changes by performing different tasks. For example, you could stop a service from processing any more messages from its inbound endpoint given certain criteria.
Over the next few blog posts, I am going to do the following:
Show how to create Java classes that can listen for these notifications and act upon them.
Show how to register these Java classes with Mule both through configuration and programmatically.
Demonstrate a typical use-case where system notifications can be used.

Google Chrome: A developer's perspective

I was as blindsided by Google Chrome as everyone else, but there's no denying that its release was a momentous occasion. Chrome is more than just a browser; it represents Google's latest entry in the ongoing discussion of standards and best practices for the Web as an application platform. As such, it may be the company's most important offering since Gears.

"From my perspective, Google Chrome and Gears are entering the Web from two directions," says Google's Adam Goodman in Scott McCloud's comic-strip introduction to Chrome. "The [Chrome] browser project is an effort to make the Web better for users. The Gears team wants to make the Web better for developers."

[ Check out InfoWorld's Special Report for all the news, reviews, and commentary on Google's open source Chrome browser. ]

Lucky for us, Google Chrome ships with all of the functionality of the Gears plug-in for Firefox and Internet Explorer already baked in. But I don't agree that users are the only beneficiaries of the other effort that's gone into Chrome. There's a lot going on beneath the hood of the new browser that should interest developers, too.

Roaring engines
For starters, Google's decision to use the WebKit HTML rendering engine may not be surprising, but it's still significant. WebKit, an improved version of the open source KHTML project, is the rendering engine used by Apple for its Safari browser. It's also the engine found in both Apple's iPhone and Google Android, arguably the two most important mobile Web platforms today.

That means Google Chrome isn't yet another browser to support, as my pal Paul Venezia suggests. Rather, it's one more vote in favor of making WebKit a primary target for new Web development projects. It only makes sense to test against the engine that's available on the widest range of platforms and devices.

And popularity isn't the only reason why WebKit was a good choice. Current WebKit builds are very fast. As a result, pages generally pop up more quickly in Chrome than in Firefox 3. More importantly, WebKit leads the pack in Web standards compliance (with Opera a close second). The more developers get on board with writing fully standards-compliant code, free of undocumented tricks and browser-specific hacks, the better it will be for everyone.

Chrome raises the bar in other ways, as well. Its V8 code execution engine beats Firefox's forthcoming TraceMonkey to the punch by offering a just-in-time native compilation engine for JavaScript. That means it runs Web applications at blazing speeds. But V8 is also a proper virtual machine environment; it's designed to handle multiple execution threads and memory management better than any other JavaScript implementation to date. For developers, these efforts further cement JavaScript's position as a legitimate application development platform, rather than a toy language for one-off scripting.

From specs to prototype
I wholeheartedly recommend reading the introductory comic strip for more insight into how Google rebuilt the browser from the ground up. Everything, from the browser security model to how plug-ins are managed, has been crafted with the utmost care. Google Chrome really is the next step in the ongoing project to create the ultimate client for the Web application platform.

To understand what I mean by that, think of the drafting of Web standards as the requirements-gathering phase of Web browser development. The various specifications describe the type of documents that the browser will be expected to parse and how it should deal with them when it receives them. With Chrome, Google has taken the next step. It has offered us its own vision of what a reference implementation of the browser should look like -- not just how it should render pages, but how each module of the application should operate and interoperate.

Mind you, we don't have to just take Google's word for it. For example, I still think this fixation on JavaScript might be a little bit unhealthy. But that's fine. Because Chrome is open source, we're free to take the ideas -- and even the code -- that we want, and leave the rest. Or we can add the parts that are missing: an ad blocker, for example.

Google doesn't need Chrome to be a "Firefox-killer," or to become the dominant browser on the market. The important thing is that Chrome will keep us talking -- and in so doing, as Google is so fond of saying, it will help to push the Web forward. It's high time that we developed new standards and practices for today's Web. In that discussion, Google now clearly sits at the head of the table.

Google Chrome and Lightstreamer

Chrome, the new Google browser, was released a couple of days ago as a beta version for Windows Vista/XP and officially entered the browser war, currently dominated by Microsoft Internet Explorer and Mozilla Firefox. Chrome offers many interesting features, aimed at making the browsing experience more robust, more secure, and faster. I was especially interested in the new V8 JavaScript engine, with its just-in-time compiler and a full-fledged garbage collector.

We tested Lightstreamer on Chrome soon after its release, and the results were amazing, as all the Comet demos worked seamlessly out of the box. I posted a quick

Some of the Lightstreamer online demos are shown in the video. I noticed a couple of Chrome features that should be particularly interesting to the Comet community:

Chrome offers a Task manager, under the Developer menu, which reports the memory footprint and the used bandwidth for each process (one of the most appealing features of Chrome is that it runs independent Web applications as different native processes, to increase the level of sandboxing; see below). This native bandwidth meter is probably gonna be an important tool for Comet developers.
Chrome decides whether to create a new tab as part of an existing process or in a new process based on the navigation path. I have noticed that if you open a new tab from an existing tab’s link, the new tab will live in the same process of the previous, instead of creating a new sandbox (the heuristic could probably be a bit more complex, but I won’t investigate this here). Opening multiple instances of a Comet application in the same tab space (process) or in different tab spaces affects the possibility of sharing resources. For example, Lightstreamer is able to share the Comet connection among different web applications (and different instances of the same applications) to minimize the HTTP connection pool exploitation. This happens if the applications share the same process, though based on different tabs. On the other hand, if the tabs live in different processes, they will create their own Comet connections. I consider this a wonderful trade-off. In other words, based on the level of affinity of applications, the Comet connection will be automatically shared or not.

Keyword Stuffing: Google vs. Yahoo’s Treatment of Keywords


Everyone on the internet this morning seems to be doing one of two things: googling for Sarah Palin or blogging about the new Google web browser, Chrome. So like any good SEO I start thinking about how I can capture a piece of this search engine traffic. My bright idea? Why not capture both markets by titling a blog post What Sarah Palin could do with the Chrome on a Trailer Hitch?

Of course, I won’t do that, because I’m all about ethical SEO, and that’s what my blog post will be about today - how to not engage in keyword stuffing. Not Sarah Palin, or the Republican National Convention, or the Google Chrome Browser. Seriously. No keyword stuffing here.


The term keyword stuffing is an old one which was probably first invented to describe the excessive use of the Meta Keywords Tag. But it has evolved to mean any site which either puts way too many keywords on a web page, or tries to hide the use of excessive keywords. I would hope most SEOs and web designers today realize that Google will penalize for it, but I still get plenty of requests from clients to either add lots of keywords in nonsensical places in their content, or to hide keywords in invisible sections of their code. Why?

One reason may be the fine line we do have to walk between keyword-stuffing, and simple keyword placement. Google has a number of factors which it takes into account for ranking pages, and believe it or not keywords in actual page body content are not really that high on the list — Google depends more on keywords in backlink anchor text. But other search engines, most notably, Yahoo, do place more importance on keywords in content. Whereas with Google you could probably get away with just placing your primary keywords in the page title and an H1 tag, Yahoo will look at keyword density, proximity, and page location of keywords (putting more prominent keywords in the beginning of the page’s content).

So how and when are keywords overused? You may have noticed I have probably already used the term “keywords” way too often in this post. Even I’m getting sick of it. If you read your website’s content to yourself and you get tired of reading the same word over and over again, then you’ve overused it. It’s pretty much that simple; write your site content for humans, not for search engines. As long as you’ve done a reasonably good job writing content for humans Google’s not going to penalize you. And if you hired someone to work on SEO for your site and they repeat your target keyword 100 times on a page, get out of that contract fast.

But wait, what about plural versions, misspellings, different verb conjugations, etc. - all those variations on keywords for which you want to capture the search traffic? It’s not really stuffing if you pepper in just a couple of those, but really, do not focus on it. Especially misspellings - you might capture the top search engine rank for a misspelled word, but everyone reading your content is going to think you can’t afford a good copy editor.

And before you criticize my blog for that, I’m not mispelling on purpose, it’s because I literally can’t afford a good copy editor. My copy editor is a middle-aged guy named Sal who splits his time between the men’s room and waxing nostalgic over the days of typewriters and white-out. But I digress.

I already mentioned the importance of anchor text in backlinks for Google, and it is true - that is arguably the most important determining factor in how Google ranks you. But you can overuse keywords there also. You don’t need 1,000 backlinks all with the exact same keyword (unless, of course, it is a highly competitive market you’re going after, in which case I’d suggest you look into long tail marketing). Instead, try varying popular keywords in the anchor text of links which point to your site, if you have control over them.

This will allow you to rank for a more varied number of queries, and will also allow you to get some better metrics on which keywords are working better for you by comparison. If you have 10 links with term “A” and 10 links with term “B”, but visitors coming to your site with term “B” are converting more (be it pages/visit or sales), than obviously you want to shift your linkbuilding efforts to focus on term “B”. Simple, I know, but a lot of people still don’t get it.

Google App Engine: Getting Data Out Ain't Simple. Yet.

Developers who adopt the Google App Engine for their cloud computing platform today may fear data lock-in, since the only way to import or export data is using a Python-based API. Google is working on a tool to improve data exchange to improve data portability.
The Google App Engine is intended to help developers build and scale applications to run on Google's infrastructure, says Peter Koomen, Google's product manager for App Engine. "It's still difficult to build Web apps," he notes.
Here's why in a nutshell: a Web developer who has a bright idea has a steep ramp to climb before she can really get underway. She has to set up an infrastructure stack—renting or buying servers, setting up a Web server, configuring a database engine—burning up both time and money. That's before a single line of code is written. Then, when her website gets popular (see, it was a bright idea), it can't handle the load. The site needs to scale, and to do it quickly. So the developer has to burn even more time and money (under pressure) to rent or provision more infrastructure, while figuring out how to split access across multiple Web servers. It isn't an easy job.
It's also a common issue. "You see this a lot with the newer social apps coming out," says Koomen. Certainly we can point to several such examples, including Twitter's scalability problems, but the need is similar for any cloud-based enterprise application. Business developers, too, need to worry about getting the right infrastructure in place and making it secure and scalable.
Google App Engine, says Koomen, fixes these problems. The application developer can focus on the application, because the App Engine takes care of the infrastructure. To quote Web technologist Niall Kennedy's blog post last April explaining the then just-announced runtime environment: "Google App Engine lets any Python developer execute CGI-driven Web applications, store its results and serve static content from a fault-tolerant geo-distributed computing grid built exclusively for modern Web applications."
Sounds cool. So what's the problem?
Data Lock-In—or Nervous Nellie?
The Google App Engine uses a data store that is... different. It's not precisely SQL, says Koomen, because the data store is built to run across multiple servers. While most developers who are familiar with SQL databases (from Microsoft SQL Server to MySQL) won't have a problem using the data store, some things aren't technically possible. "These restrictions aren't as terrible as you'd think," adds Koomen.
Using Google App Engine today also requires Python, which might present a problem to developers who are more familiar with other languages—whether dynamic languages like PHP and Perl, or traditional languages like Java or C#. (Personally, I don't think Python is a significant turn-off to most Web developers, but programming language preferences are passionate.)
For more on Python, see You Used Python to Write What?! by Martin Aspelli, and Python Upgrades Readied for 2008.
The bigger question—a real one from a developer friend, which is what inspired me to call Google—is whether that data store creates a lock-in, preventing data-based applications from being portable. Start-ups might worry whether their companies are less attractive to investors if they've tied themselves to a single vendor's data store. Enterprise computing professionals would worry that, on top of their concerns about any corporate data living in the cloud, they'd have information they could not easily retrieve or would have trouble migrating to another database. Or, probably more important over the long term, they might worry whether database interactions involving Google App Engine would require fancy custom programming to interoperate with in-house applications, Web services components, a service-oriented architecture or other situations in which the leg bone data must connect to the thigh bone data.
In its current "preview" state, the Google App Engine requires that data be stored and retrieved using a Python API called GQL, which Koomen says is as similar as possible to SQL. You can get data out of your data store only programmatically, not by copying a SQL file from one server to another.
However, Koomen says Google sees this limitation, and the company has actively been soliciting input on how best to address it. In fact, that's one of the reasons Google makes preview versions available, says Koomen. "We wanted to get it out early and see what developers thought."
As a result, Koomen says, Google will be releasing a tool that makes it easy to get data out of the data store without writing code. They aren't ready to go into specifics, other than it'll be available "within the next two quarters," but Koomen said the intent is to make it easy to get data out of App Engine. The new tool promises to address the data portability issue, to provide a "home brew backup" and to be "completely open," according to Koomen.
This isn't the first time user input has affected the development of Google App Engine. For example, for security reasons they had to remove the Python image library from Google App Engine. (Google App Engine supports 100% of the Python language, Koomen says, and 90% of the Python libraries.) However, developers made it clear that they needed to manipulate images in the data store, such as to scale or rotate images or to create thumbnails. "So that ability is in there, now," says Koomen.
In the short term, developers who use App Engine don't have their data locked in. Getting data out of the App Engine data store may be awkward, or at least you should build "Darnit, I have to write that from scratch" time into the project schedule, but these limitations are temporary. That's worth knowing, certainly, because every developer adopting a new-to-her technology wants to know where the bodies are buried and where her assumptions are incorrect.
Within six months, however, the data lock-in concerns—and the need to write a hack—in Google App Engine should go away. "We still have some ways to go," says Koomen.