Tuesday, March 14 2006

The meme sites were abuzz yesterday about Zooomr - believed by some to be a Flickr killer, and purportedly written by a 17-year old in three months. Two of its killer features, apparently, are the ability to add audio to pictures, and to geocode pictures.

Aside from the shameless rip of Flickr's name and appearance (don't people feel a little ashamed when they do this? While it works for parady and satire, when used for a legitimate company it makes the foundations appear dishonest and shady, especially when the product is targeting at exactly the same market and use), superficially ripping off an existing site is easy. We subcontract some work through several of the code-farming sites, and every day we see low-cost jobs completed for tasks like "make a clone of MySpace" or "make a clone of Ebay". Hysterics about how amazing it is that a superficial Flickr clone + marginal features (such as a mash-up with Google maps, one of the cheapest techniques to liven up a website) was written in three months betrays a basic lack of understanding about where the difficulties of software development lie.

My daughter trying out her new boots

Of course, like the widely hyped Riya, I haven't actually been able to look at Zooomr -- it appears that their servers fell over and died under the onslaught (one of those non-superficial features you have to design in is scalability, and appearances are that it wasn't a primary concern).

As an aside, I read TechCrunch, but take everything Mr. Arrington and crew say with a monster-sized grain of salt: He seems far too incestuously embedded into the Web 2.0 hype community to offer any sort of critical analysis, and occasionally offers up some highly suspect infromation (such as yesterday's recommendation that everyone sign up for TrustedID to take advantage of already existing, usually free services for $8 US per month).

Speaking of geocoding and ideas, years back -- early in Google's ascent -- I emailed them advocating that they pioneer and evangelize geocoding standards for webpages: A standard that would allow web authors to indicate where, if appropriate, a particular webpage applied. For example Burlington, Ontario, Canada, perhaps even a particular street corner for a fish shop (possibly longitude and latitude). This thought came to mind because of the difficulty searching locally, which naturally led to a diminished value for small, localized businesses to take advantage of the web -- while we were gaining the ability to search a world of information, it was becoming, and remains, enormously difficult to zero in on locally relevant data.

At the same time I advocated that they should pioneer web client geocoding -- a proposed feature that with the user's authorization would enable an HTTP header, much like the language header, that would indicate what geographical location or proximity that they are most interested in, automatically incorporated throughout the web. Obviously there are some privacy concerns with this that would need to be evaluated. As it is this sort of feature has somewhat been accommodated via reverse-DNS and geographical records correlating with IP.

Google has added some hit-and-miss, high false-negative code to try to detect and extract addresses on websites, but it only partly achieves the goal. It would have been very advantageous for both users and businesses if geocoding were a principal element of page markup at the outset.

While commenting on a grab-bag of thoughts, here in Canada we've watched our dollar climb about 30% against the American dollar over the past two years. While a part of this can be attributed to the monstrous reserves of the oil sands we harbour, with a world oil price that finally makes it cost-effective to perform the costly oil extraction,  the principal reason our dollar has ascended has simply been the decline of the US dollar on world markets (e.g. we're largely spectators along for the ride). Several important Asian currencies are tied to the US dollar, and thus have also dropped against the Canadian dollar.

The impact this has on Canada is that anything sourced in the US, or in Asian countries whose currencies are tied to the US $, is that much cheaper in Canada. While our exports are more expensive to some countries, and thus less competitive, for organizations that rely upon substantial foreign inputs for their products or even operations, this can be a great advantage.

Given that I'm in the IT industry, of course I'm talking about computer hardware.

From LCD displays to laptops to servers, the prices across the board are amazingly low, and if a shop held off upgrading a server, there are some fantastic currency advantages to doing so now. You can get more computer hardware for less, far beyond the power/$ advances of the computer market.

 IT 
   
Monday, March 13 2006

A recurring argument on software development boards, often with a backstory involving a developer teaming up with an idea-man and then having second-thoughts about the equity split, debates the relative value of ideas versus implementation. Who is worth more to the team: The one who did the hard work of coding, or the guy who thought up the web app in the first place?

The predominate opinion is usually that the implementation is extraordinarily valuable, while the idea is close to worthless. "Ideas are cheap" the posters often claim. "There are an endless number of good ideas out there."

"Anyone can think up good ideas. Few can put them into practice."

So I ask you: What value are ideas? If you were a developer that teamed up with someone who had a clever idea for a web app, even perhaps just a couple of interesting twists that give it a potential competitive edge, how much value would you give their contribution?

This is a very contentious issue in the software development community, and it's one I plan on addressing in an upcoming entry.

P.S. This entry uses an inline IFRAME for a survey, and it may not appear in some aggregators or RSS readers. If that's the case, visit the entry directly.

   
Monday, March 13 2006

For evaluation purposes -- to see what it brings to rich web apps -- I've added Internet Explorer 7 beta 2 to the daily browser mix, using it aside Firefox 1.5.0.1 and Opera 8.5 in my daily activities.

It's a competent browser, hosting a number of great improvements, however thus far I've seen nothing about it that makes me believe it will replace my feature-rich Firefox browser, nor does it look like it'll replace the lightweight, ultra-fast Opera browser. It really seems to be more about playing catch-up, bringing some of the functionality that the rest of us have been enjoying to the IE hold-outs.

Will definitely keep an eye on it.

 IT 
   
Friday, March 10 2006

If you believe the Alexa graph, Digg is a significantly more popular site than Reddit, with the gap growing larger every day.

I find these results surprizing. I've had half-a-dozen entries on the front page of Reddit, with each yielding from 2500-5600 distinct referrals per day. In comparison, I've had a front page entry on Digg for a day, only bringing in ~750 referrals.

Of course, a single entry isn't a very good sample, and it's entirely possible that most people just weren't interested in the link -- that it was a fluke that it got on the front page in the first place -- but I've seen several other stat watchers mention very similar stats (that a front-page of Digg yielded them 800 or so visitors per day), so I'm not basing this comment simply on my own observation. I've looked for exceptions to this, and found one individual who had a broad-interest link atop Digg's front page for 24 hours straight, and they claim that for that day they received a total of 7200 distinct referrals, and then it rapidly tailed off, disappearing in two days. That case seems to be the exception.

One possibility is that Digg offers more link diversity and thus the much greater traffic is dispersed, significantly reducing the impact on any one link. Alternately, perhaps Digg users spend more of their time within the Digg community, rather than following the links (in the same way that many Slashdot readers just make assumptions about the linked article, responding accordingly, rather than RTFA).

Another possibility is that Digg caters to a crowd that is more likely to have the Alexa/A9 toolbars installed, both of which feed back the stats that are used to drive the Alexa popularity metrics. Given that they're somewhat infrequently used toolbars, and are much more likely among certain crowds (and seems to appear in clusters), the traffic rankings are a bit of a crapshoot outside of the top sites -- Here on yafla I've had days with 6000 visitors where my Alexa ranking doesn't budge, whereas other days 2000 visitors cause it to quintuple.

   
Tuesday, March 07 2006

Summary: Fake job listings, or real jobs backed by a selection process that filters out everyone, can earn your firm adversaries and detractors. They need to be identified for what they are -- a cheap, transparent gimmick.

A Typical Model

Following a fairly typical business model in this niche, yafla is a small consulting and contract development shop in a mid-sized market, using that business income to support the development of derivative products and businesses (such as the soon-to-come www.360notes.com), along with licensed ISV technologies.

We love the consulting/development market. We're extremely good at it, we enjoy the diversity and challenge, and we have no plans of ever abandoning it (at least until the world's software and IT needs have been completely satisfied once and for all). Yet of course we'd also love to build the next great shrinkwrap or web app hit, and are working towards that goal as well.

One thing we haven't done, however, is to pretend that we're bigger, more important, or more exclusive than we really are through the cheap but common technique of bogus or never-ending job listings -- We haven't built a pompous careers section bulked up with imaginary roles. We haven't provided descriptions of how extraordinary yafla talent is that only walk-on-water technical magicians with PhDs should consider joining the ranks of Extraordinary Gentlepeople.

The Lofty Requirements and Imaginary Jobs

under_skyway

What I'm talking about, of course, is the sadly prevalent practice of many organizations, from tiny to huge, to endlessly list artificial positions that don't actually exist, or to advertise theoretical positions that no one short of a deity could actually fill. This is a technique utilized by a diverse range of companies, from the tiny start-up that immediately has a prominent "careers" section comprising one third of their web property, to the huge organization like Microsoft's Canada division that lists the same positions for a year on end.

In this case I was spurred to write after seeing yet another micro-web firm -- one which I know has less than half a dozen employees and hasn't grown in years -- with a comprehensive job listing section including endless exhortations for only the most extraordinarily gifted and rare to join this exclusive crew. I imagine the endless ranks of prospects wasting their time jockeying for positions that will never be filled and it saddens me a bit.

Advertising false or theoretical positions is a cheap way of conveying the illusion that the perpetrator is an elite company on the go, so in demand that human resources needs outweigh the need to acquire clients (sort of a social proof), providing lofty requirements in hopes that you'll believe that all of the existing staff achieves the same. It attempts to cow competitors into thinking that they're so successful that they're chomping at the bit for new employees, but are thwarted by a workforce that is incapable of meeting their amazing skill requirements.

In response to these ads, countless prospective applicants carefully craft cover letters and customized resumes. They eagerly apply, imagining their future with this fabulous organization.

Many times their application either times out and yield an automated rejection letter, or immediately gets rejected by a human resources department that is filtering applications by a wide range of criteria unstated in the job posting (the classic being the secret compensation cutoff -- ask for less and you'll get through and underpaid, but waste your time submitting for a job that doesn't fulfill your financial requirements and you'll get instantly rejected).

Not named Smith. Not named Singh. Too much corporate experience. Too little corporate experience. Too presumptuous in its use of the greeting "A very good day to you". The arbitrary and often ridiculous filtering criteria can effectively eliminate anyone.

Cheap and easy for HR, so everyone wins. Right?

The Negative Repercussions

Of course they don't.

On the other end of the equation is a real person that wasted their time and effort creating a submission for jobs that often don't even exist, or which they don't meet due to hidden requirements -- people who often already have jobs and are sacrificing their limited free time -- only for their efforts to sit stagnating in an inbox or database for years. If they're lucky they might get rashly rejected despite fulfilling all of the requirements, and then some, when some arbitrary time-out mechanism fires off a form rejection letter, or a haphazard HR rep blanket rejects all pending resumes.

The resentment builds. The goodwill of the organization suffers.

These rejectees often have decision making authority in their organization, and over the years they grow into more powerful roles. For years they nurse the wound that their perfect application for the big XZZ corp position was rejected out of hand, without as much as a phone call or personal contact allowing them to demonstrate their worth. Often it subconsciously colours their choices, be it as simple as supporting and advocating open source products in defiance of the careless Microsoft rep that canned their submission, or second guessing whether the firm should automatically move to .NET, or whether there should be a competitive showdown between it and J2EE. Even a minor antagonism can substantially change internal advocacy.

Of course choices should be made based upon empirical facts and unbiased analysis, but as human beings we are consciously and subconsciously affected by emotions and biasSmaller firms of course have less ramifications for partaking in this abuse.

Smaller firms often have no downside to printing such fake ads -- apart from killing a bit of your soul abusing people like that -- given that spurned suitors often have no business relationship with them outside of vying for a job. These firms use such ads in the theory that "no publicity is bad publicity". Compare this to Microsoft that relies upon the decisions of millions of people, and suffers from a million tiny wounds when an HR department gets sloppy.

My Personal Experience

I can personally relate to this problem to a degree.

Many years back, when I first moved to the greater Toronto area, I applied to a Microsoft Canada position that was pretty much a perfect match for my skills -- the ad seemed like it was written specifically with me in mind: I had what seemed to be a perfect mix of skills, experience, education and certification.

I had watched this job listing sit on the job site for many months, and figured I'd finally give it a try, so I wasted an hour of my time putting together a perfect resume, and then reformatting it for their absolutely terrible, archaic online resume building tool. I looked forward to the inevitable telephone interview when I would wow them more with my incredible communication skills and demonstrated intelligence.

A week later I got a form rejection letter informing me that I wasn't suitable for the position.

No phone call. No email questions. No follow-ups at all. Just a blanket, uncontestable (from a no-return bogus email address, which is a classy touch) rejection by the machine of HR at Microsoft.

The job listing stayed up for as long as I bothered watching. Every day that it sat there unfilled I stewed over the fact that I wasn't given even the courtesy of a brief phone interview.

I've never been a Microsoft zealot, and nor did that organization represent my dream job, but it admittingly did burn getting rejected in such a fashion (I'd much rather have bombed an interview and had myself to blame). My choices of Microsoft technology have always been driven by facts and pragmatism, so it wasn't like I was going to stomp my feet and embrace Linux to spite the Microsoft machine, but it did make me give alternatives a second look.

In all honesty it's probably made me a little more antagonistic towards Microsoft Canada employees, making me question "so what's so special about this guy? I don't get a phone call yet this idiot works there?"

For someone more emotionally invested, though, it probably could have made them an enemy. I have to wonder how many avowed Microsoft enemies, spreading the anti-Microsoft word far and wide, were molded when the human resources machine rashly stomped on their dreams.

The same question could be raised for other organizations with the same hiring practices, and for startups that build a facade of size by listing numerous positions that don't actually exist.

Not Everyone Is Employee Material

Of course many applicants aren't appropriate or optimal for the position they're seeking, so job seekers have to accept the fact that even getting past the initial filter is a remote possibility (especially given the one-click applications possible at many of the job sites: A single listing can yield tens of thousands of mechanically submitted applications, so even the best prospect can get lost in the noise, not to mention that listed positions are often internally filled, and listed only as a matter of process), and as always getting considered is often best achieved by network contacts and organizational insiders rather than cold resume submissions.

Nonetheless, fake job listings are quickly transparent to all, and unfilled roles that waste the applicant's time can earn an organization lifetime enemies.

On top of that, the practice of keeping some requirements secret wastes everyone's time. Apart from often unstated diversity staffing requirements, organizations often fail to publish the compensation band for a job. For prospects with financial needs beyond the position, it is an enormous waste of time and effort, and it fills HR inboxes with prospects that will never accept the position.

   
Tuesday, March 07 2006

ASP.NET has improved dramatically with v2.0, to the point of making ASP.NET v1.x look like a bit of a hack job. One of the great improvements covered in this entry is the addition of Master Pages.

Master Pages allows you to define a template layer (and coupled back-end code) to be used on content pages using that master page. For instance a master page might define all linked scripts, CSS, and script blocks, along with a navigation header and footer that exist on all pages on the site (or at least those pages using the master page). An ugly example sits a subdirectory away -- at the root pages for yafla, where the navigation header and footer exist in a master page.

ex. MasterPage.Master

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>My Master Page - This Title Will Be Overridden
       By the Title Element
In Content Pages</title>
    <link rel=stylesheet type="text/css" href="stylesheet_in_all_pages.css" />
</head>
<body>
    <h3>This is my universal header!</h3>
    <form id="form1" runat="server">
    <div>
        <asp:contentplaceholder id="ContentPlaceHolder1" runat="server">
        </asp:contentplaceholder>
    </div>
    </form>
    <h3>&copy; 2015 Robot Inc.</h3>
</body>
</html>

You can also define code for the various events in the master page, which will run on the pertinent content pages.

Content pages then define what will fill the content block (or multiple content blocks as the case may be), and of course implement their own back-end code.

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"
AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2"
Title="This is my overridden title" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
This is my content for this content page
</asp:Content>

Very trivial.

Of course this isn't the only way that this result could be achieved -- I could derive from a page object that imperatively creates all of the common elements, or I could use multiple user controls that defined the basics, but neither of those solutions, or similar workarounds, seem as elegant as master pages to me. There are equal or superior solutions in other platforms, however I'm sticking to the topic of ASP.NET in this entry so they are irrelevant.

The one hiccup I faced in the use of master pages was my desire to have meta keywords (which exist in the header) vary by page, despite the fact that the meta keyword is basically dead. I want the keywords to vary, similar to the way I can declaratively override the title in content pages. Unfortunately this required some code workarounds, which in my case included adding a public property on the master page, MetaKeywords, with a default keyword list, which I then added to the header in the PreRender stage of the master page (the following example is simplified for demonstrations sake, however a real implementation would scan the headers to ensure that the pertinent header doesn't already exist before adding it).

    public string MetaKeywords = "default keywords";

    protected void Page_PreRender(object sender, EventArgs e)
    { 
      SetMetaValues(this.Page.Header, "keywords", MetaKeywords);
    }

    public static void SetMetaValues(System.Web.UI.HtmlControls.HtmlHead head, string name, string content)
    {
      HtmlMeta metaValue = null;

      metaValue = new HtmlMeta();
      metaValue.Attributes.Add("name", name);
      metaValue.Attributes.Add("content", content);
      head.Controls.Add(metaValue);

      return true;
    }

Any content page could access its Master property to set the property, and the meta keywords would be appropriately set when the page was rendered. By using the MasterType directive the Master property of the page automatically resolves to the proper type.

Unfortunate that a declarative mechanism wasn't added for arbitrary header elements in the content pages.

The goal of master pages, of course, is to avoid the scourge of copy/paste coding: Unnecessarily having a single line of code in multiple places is an evil in software development, yet it's often the easy, thoughtless solution, yielding volumes of redundant code that invariably diverges and causes maintenance problems for years to come, reducing the quality and agility of the codebase.

I despise copy/pasted code. It truly is a peeve of mine.

When analyzing the quality of code bases, one of the first checks I usually perform is to use one of the automated code duplication checkers (available for most languages). There is a remarkable correlation between code duplication rates and code quality.

The benefit of master pages isn't limited to a single master template, however, but instead you can actually layer multiple master pages. For instance on the yafla site the services category pages use the Services master page, adding additional service specific back-end code and layout, while it uses the web site wide master page. It mirrors the templated way in which many websites are developed.

The downside of layered master pages is that the GUI team apparently didn't have time to build multiple level parsing into the web designer -- wherever you're working on content pages that have more than one level of master pages above them, you are limited to the source view. To attempt otherwise yields a "Design view does not support creating or editing nested master pages. To create or edit nested master pages, use the Source view." Unfortunate, but not deadly.

As an aside, one of the big improvements with ASP.NET v2 is better support of per-page development, similar to classic ASP and competitors such as PHP. This solves one of the primary problems many had with ASP.NET, which is that they didn't prefer to work within the "web site as a monolithic application" model that ASP.NET v1 pretty much enforced. Strangely the improvements bringing these benefits has been met with little fanfare, and few are even aware of it. I do plan on doing a feature on it shortly.

Tagged: [], [], []

 .NET 
   
Tuesday, March 07 2006

While I remain committed to SQL Server, after a lengthy evaluation and feature analysis process, we will start advocating MySQL 5 to some clients under a set number of conditions, both on the Windows and the Linux platforms. While MySQL was previously lacking some critical foundational features, v5 ups the ante considerably, filling a particular niche in the solution spectrum. This is a part of a wider trend at yafla of embracing some of the "alternative" platforms, outside of our normal Microsoft-enabled comfort zone, where it benefits our customers and the solution.

Due to licensing conditions we still won't be targeting our applications at MySQL.

We still advocate PostgreSQL, another excellent open source RDBMS, for some scenarios.

 SQL 
   


About the Author
Dennis Forbes Dennis Forbes is a Toronto-based software architect. While focused primarily on the .NET and SQL Server worlds, Dennis frequently ventures outside of this comfort zone into game development and image processing. He has been published in several industry magazines, has been quoted in the Wall Street Journal and has been interviewed by NPR.

He is a vice president and lead software architect at an innovative New York City hedge fund back-office services firm.

Dennis has been working on solutions for the financial, telecommunications, and power generation markets for over 15 years.





 
Earlier EntriesLater Entries

Dennis Forbes