lesscode.org


01 Oct 06
14
14

Design Patterns as a statement of failure  3

By Aristotle Pagaltzis under Talk

Mark Jason Dominus:

If the Design Patterns movement had been popular in the 1980’s, we wouldn’t even have C++ or Java; we would still be implementing Object-Oriented Classes in C with structs, and the argument would go that since programmers were forced to use C anyway, we should at least help them as much as possible. But the way to provide as much help as possible was not to train people to habitually implement Object-Oriented Classes when necessary; it was to develop languages like C++ and Java that had this pattern built in, so that programmers could concentrate on using OOP style instead of on implementing it.

Update: and an excellent follow-up by Mark addressing a response by Ralph Johnson (one of the Gang of Four).

3 Comments...

14
09

Luke Plant on the pain of going back  0

By Aristotle Pagaltzis under Talk

I wanted to point out an article called Why learning Haskell/Python makes you a worse programmer.

When I found the link in my aggregator, I was expecting the worst, but the title is just gratuitously incendiary. The actual article is thoroughly reasonable. It asserts that learning better languages will make your day job an excercise in demoralization and then asks the question: if you’re a C#/Java developer in the trenches, how do you benefit from your broadened horizons?

There is lots of good discussion in the comments; don’t skip them. What there is not, unfortunately but unsurprisingly, is an easy solution.

Leave a comment...

15 Apr 06
08
53

Many Lives — Just One You  11

By Bill Burcham under First they ignore you.., Web as platform

You lead many lives. You’re a spouse and a parent. A soccer coach and a scout leader. A volunteer and an activist. You are an employee and an entrepreneur. Why do the systems you use not understand this? It’s like somebody out there just doesn’t care.

If you’re like me, and I know I am, you’ve got about a hundred accounts to keep track of on various systems — systems on the Internet, systems running in various corporate data-centers accessible only via VPN. You’ve got a slew of credentials to manage and no ability to leverage all that information at once. You spend your day duplicating and copying information between these systems, like some sort of freaking acolyte — serving The System — when The System should be serving you.

Meanwhile a million Web 2.0 startups are blooming. All DIY’ing for attention-equals-users-equals-dollars. Many of those startups are trying to tap both the consumer market and the corporate one too. It ain’t easy though since consumer buzz or even adoption does not always lead to access to fat corporate accounts.

What would it mean to you if you could use your favorite set of Web Apps all day and never have to log in twice regardless of which life you were leading moment-by-moment? How much more effective would you be if for each application, all your information in that application was available at once instead of walled off in separate accounts?

What would it mean to a Web Application provider if it was able to paint that picture for you? Would you be more loyal to that brand? Would you induce your employer, your client, your scout troop to use/purchase that brand?

I think there is a way and if you’ll lend me a few more minutes of your precious attention I’ll spin it out.

Imagine

The prevailing identity model in information systems arose around the enterprise system deployment model. In an enterprise system deployment, substantially all of the users of the system are employees of the enterprise. The enterprise itself is not represented at all in the model since each system serves only one enterprise.

This identity model has been carried forward to Internet-based applications. Just about all Internet-based applications offer accounts. An account represents a contract between the service provider and an individual. As such, most Internet-based applications are modeled like one big enterprise. Web Applications that offer corporate contracts offer separate identity systems for each corporate entity. At the end of the day, each of these identity systems — the “consumer” space ones and the “corporate” ones are separate.

Now let’s imagine a future where all applications are Internet-based. It’s easy if you try. Further, lets imagine that the market for some key Web Applications has settled down and consolidated a bit. So instead of a hundred wiki providers maybe there are three very popular ones. Kind of the way things were five years ago on the desktop with Word/Excel/Powerpoint/Outlook but this time, Internet-based.

Now let’s take a look at a knowledge worker, “Jessica” using say a wiki service, “WikiGood”. In the morning Jessica spends a few minutes in WikiGood writing out her plans for the day and reviewing progress against yesterday’s. Jessica has consulting engagements with two clients, “BigBoxCorp” and “NowYouSeeIt” but she’s in luck — both of her clients have standardized on the WikiGood service and use it heavily for day-to-day operations. As the day progresses she will interact with both of these corporate wikis as well.

In the first usage instance, Jessica is working on her own behalf, and wishes to keep the content private. What happens when she decides to do some work for BigBoxCorp? Well she logs out of WikiGood and logs back in with the identity assigned to her by BigBoxCorp. No problem. Other than the fact that she has two sets of credentials for WikiGood, oh snap, hang on — three sets of credentials because she’ll also be doing work for NowYouSeeIt.

There is a proliferation of accounts and credentials, but that’s not the worst of it. The deeper problem is that each WikiGood account is an island — even though all of the accounts are Jessica’s. Her preferences, her usage history, in short, everything associated with her in the system is divided, walled off, in three separate spaces. When Jessica is logged in under her NowYouSeeIt account and issues a search for instance, she will not find results for any of her personal wiki pages since the system knows her only (at the moment) as jessica@nowyouseeit. What if WikiGood is using Google AdWords to present Jessica with targeted advertisement? Is she a different Jessica when she’s logged in to her personal account than she is when she is logged in to her BigBoxCorp account? Google would like to think not.

Relate this scenario (personal account, and two corporate accounts) to other applications you use every day like email, contact list, calendaring, meeting scheduling, blogging, idea management, note taking, project management, personal task list, IM, VOIP, search. As these applications learn more about you, and you invest more time creating information in each application it rapidly becomes unacceptable to switch systems or even to switch accounts on the same system.

People increasingly expect and need the systems they use to learn more about them and to provide enhanced service based on that knowledge. Systems architected ignorant of the multiplicity of lives people lead force people to waste time repeating themselves (to systems) and copying information (between systems). More generally users of these systems fail to realize the full potential benefit of the knowledge they have shared. This is not a new problem, but it is certainly seems like a more pronounced missed opportunity in the age of Internet-based applications.

The situation is problematic. Users of systems would like to minimize the proliferation of credentials they must carry. Also they would benefit greatly from the ability to connect their accounts in a single system in such a way that they have visibility across all their content at once, and in such a way that they wouldn’t have to spend time re-entering profile, preference and other information into each account. Corporations seek these same benefits for their workers because it makes the workers, and hence the corporation, more efficient. On the other hand, corporations still have a desire to limit access to information (e.g. to employees only), and to monitor employees activities (shudder) if not for pure evil purposes, for regulatory ones.

But what of the service provider’s interests? WikiGood would like to continue to offer free or cheap service to individuals and premium service to corporations. The logic goes something like “we’ll attract consumers and that will lead to corporate customers”. But from the foregoing it should be clear that WikiGood is missing the opportunity to activate those very consumer-users, by failing to provide a vision for Jessica that looks substantially better than the walled-off nightmare. Users have little incentive to induce employers to switch to gmail for instance, if that would lead to each user having two gmail accounts instead of one. That situation is not appreciably better than the situation where the user has a gmail account and a corporate Exchange account. Contacts are still separate. Searches still fail to find results across accounts. The tags created for one account are completely separate (and return separate results) from the tags created in another account.

Many Lives — Just One You

The key missed opportunity is for WikiGood to acknowledge that users often act as agents for other legal entities. I’m using agency in the legal sense here. First from the American Heritage Dictionary:

One empowered to act for or represent another: an author’s agent; an insurance agent.

And now from the Agency (law) entry in Wikipedia:

The Agent’s primary fiduciary duty is to be loyal to the Principal. This involves duties:

  • not to accept any new obligations that are inconsistent with the duties owed to the Principal. Agents can represent the interests of more than one Principal, conflicting or potentially conflicting, only on the basis of full and timely disclosure or where the different agencies are based on a limited form of authority to prevent a situation where the Agent’s loyalty to any one of the Principals is compromised. For this purpose, express clauses in the agreement signed by each Principal with the Agent may identify specific types or categories of activities that will not breach the duty of loyalty and so long as these exceptions are not unreasonable, they will bind the Principals.
  • not to make a private profit or unjustly enrich himself from the agency relationship.

In return, the Principal must make a full disclosure of all information relevant to the transactions that the Agent is authorized to negotiate and pay the Agent either the commission or fee as agreed, or a reasonable fee if none was agreed.

If WikiGood introduced the concept of agency into its system, it would enable Jessica to have a consistent identity over time as she worked in her own interest, or in the interest BigBoxCorp or NowYouSeeIt, yet retain full visibility across all her content.

The core concept, is that within each application, a person has the ability to act as an “agent of” some identifiable “interest” or “principal” — think “employer” or “customer” or “client”. But the person retains her identity — the system always knows the person’s identity. There is one set of authentication credentials. Knowledge expressed to the system by the person is retained by the system and associated with that person — regardless of which “principal” they represent moment-to-moment.

In this way, principals can have (purchase) rights in the system, and those principals can assign their agents limited rights in the system too. The user switches between agencies as she operates. She expresses this switch through the user interface. If you’ve used a mail client that lets you select from multiple “from” addresses when sending mail you have the basic idea, only you’d make a “working for” selection each time you changed tasks. Perhaps you could “work for” more than one principal at a time — why not?

Instead of requiring the user to do this switching, perhaps smart systems could infer agency on-the-go based on time of day or content or physical location of the user. These smart systems could prominently display their guess and the user could change it if it was wrong.

In this way, no “closed system” like VPN is required to protect a principal’s interests. The principal contracts with various service providers the terms under which its agents can act. Principals then assign rights to their agents. But principals create no identities — they just assign rights/trust levels to identities. In this way one identity can serve many principals. There may be a notion of the “public domain” principal, so an individual has the ability to do work for the “public domain” or in the public domain.

What it Would Mean

The Agency-Aware Identity Model gives rise to a new business model where consumer accounts and consumer loyalty can be parlayed into corporate accounts. Each consumer-customer of a Web Service will now be highly motivated to induce each of the principals on whose behalf they work, to also become (corporate) customers of that same Web Service. Corporations (principals) would retain the important security and control capabilities they have today with their enterprise identity model: a) the right to assign and revoke privileges/trust to individuals (agents), b) the right to protect (privacy) information produced by their agents c) the right to eaves drop and monitor the activities of their agents for e.g. regulatory compliance, sexual harassment violations, EEOC etc. An individual, by agreeing to operate on behalf of an agency (for a period of time, or for a particular task) is potentially forfeiting some privacy or future access rights to her work product.

So what do you think? What would it be like to use WikiGood or your-favorite-web-app-here and never have to log out regardless of which client/principal you were working for moment by moment? How much more effective would you be if for each application, all your information in that application category was available at once? Would you be able to remember to click the drop down list of agencies as you switched between tasks during the day? Would you want that switching integrated with your web SSO system like OpenID? Do you believe that by adopting an Agency-Aware Identity Model, WikiGood could effectively turn its non-corporate customers into a rabid enterprise sales force? I do.

11 Comments...

27 Mar 06
05
02

The pragmatic’s guide to Web architectures  14

By Assaf Arkin under Then you win.

There’s a big battle of words raging on to define what the hell we’re doing and why we’re doing it all wrong.

Are Web services on the Web, or do they have to use SOAP? How is low REST different from high REST? Does XML/HTTP work better if we call it POX? When is AJAX not AJAX? Who owns the semantic landscape?

There are also a lot of people building applications, that don’t have time to argue how you call it or what it means, just as long as it works. We call them, “the pragmatics.” This post is for them.

When it comes to designing Web services, there’s a few choices of architecture style, and stacks of technologies to choose from. It’s still undecided which one will rule them all, the race if far from over. Most people who write about that stuff hope their horse is the winning one.

I’m no exception. So I’m going to play pundit and tell you which architecture style I think works best for the Web, which technology stack I prefer to use:

  • Architecture style: use the simplest most common solution to solve your problem.
  • Technology stack: see above.

XML over HTTP (can we please not use an acronym that means a disease?) is great for moving structured data around, and shines at encapsulation. Its loosely coupled document style has too many merits to mention. Except when you’re building a UI that needs to talk back to the server, where tight coupling is good enough, and too much abstraction means you’ll never deliver on time.

RSS is a wonderful way to stream data updates from server to client, not to mention the magical combination that are blogs and feed readers. It’s the ultimate query API. Except when your UI is trying to query the number of unread e-mails in your inbox, and you find out that RSS is anything but simple.

Microformats are amazing in their beauty and simplicity, and let you easily microchunk your content. Until you fall in the 80% of problems they were never intended to solve and… well, just don’t solve.

JSON (not to be confused with Jason, though they both love AJAX) is the simplest form of API you can think of, concise and easy to use. It’s a wonder it wasn’t invented earlier. Except that it’s tightly coupled and still envious of what XML can do for you.

AJAX is great even though almost everybody is using it for HTML. But let’s not get too tangled up in detail, acronyms are not for describing but for branding.

There’s nothing like REST, it powers the Web (can we get a logo for that?). You’ll just have to ignore all those big name Web sites we all like to mention that use cookies for the benefit of their users. And all the REST APIs that violate more constraints than a drunk driver speeding down the wrong side of the road.

RDF is semantic bliss, it gets semantics right and has a thoughtful model for representing and querying it. You can do amazing things with it. But most likely your semantic data is not RDF, and still happens to work, and you’re cursing every time you need to fix Firefox configuration files in all their semantic glory.

The Web thrives not because it uses a strict architectural style and a coherent technology stack. It thrives because so many sites pay little attention to REST and choose to focus on their users instead. It thrives because malformed HTML pages include GIFs and PNGs and Flash and badly written JavaScript that just works. It thrives because people go on the Web to send e-mail, IM, do VoIP and trade BitTorrent files.

The search for the holy grail, the one technology to rule them all, is as old as technology itself. I’m fine knowing we’ll never settle the score, never know whether vi is truely better than Emacs, or whether Eclipse shadows them both. But unless you’re a vendor making money on one horse, it doesn’t matter to you.

If you’re a pragmatic developer, you have one tool in your toolbelt that always wins the day. It’s the ability to think, ask questions and make choices. To choose solutions that are best for the problem you’re tackling right now. And to keep learning. Because there will always be some new technology that’s better at solving some use case or another.

The only architecture that matters is the simplest one you can get to solve the problem at hand.

This post: written in Vim, formatted as HTML, available over RSS.

14 Comments...

26 Mar 06
11
32

It’s Enterprisey!  6

By Bill de hÓra under Then they fight you...

Recently David Heinemeier-Hanson asked “How do we fork the word enterprise?”. This will do for now.

via Patrick Logan and Mark Baker

6 Comments...