Related link: http://www.ondotnet.com/pub/a/dotnet/2004/06/28/liberty_whidbey.html

In my previous column, I showed how to add web form security to your ASP.NET 2.0 application, and how to add users. In this follow up, I’ll demonstrate how easy it is to create and manage roles.

To illustrate this, we’ll recreate the example program from the previous column, but build on it to add roles and role management.

Related link: http://www.near-time.com

I’ve got a text file called “TODO” on the desktop of every machine I’ve ever worked at for longer than 20 minutes. I have a combination of bookmarks in a combination of browsers, along with little notes about sites I’ve visited that didn’t rate a bookmark. I have folders filled with documents that I’ve written or been sent, some of which are related, but I just have to remember that. I have old .zip files sitting around that contain documents I sent out to colleagues, and .zip files they sent back with their edits. I’ve got three different RSS readers, and mayble nine different OPML/Blogroll files sitting around. In short, I’m like a lot of folks: I have a lot of information to track, and no good way to do it all.

Entire Near-Time’s new Flow application. This piece of software just blows me away. It has an excellent, lightweight but full-featured text editor, so I can create any of the documents I’m used to (barring specialty stuff like spreadsheets). It has an organizing principle that lets me combine those documents in a variety of ways. It has a built-in browser and RSS reader (my favorite so far), and every web page and feed is just another document to Flow. I can combine them with text documents. I can annotate web sites and RSS feeds using a commenting mechanism, and every time I visit those pages or feeds, my comments are right there.

It has auto-indexing and super-fast search. It has smart folders, like iTunes. It has configurable auto-refreshing rules for online content that you subscribe to.

In short, this application makes managing all my varied information a cinch. And the best part? Peer-to-peer collaboration with other users. Just add another Flow user to my list of contacts, and I can share any and all of it with them.

I’m hooked. Now, if only I had a Mac.

Related link: http://www.sys-con.com/story/?storyid=45077&DE=1

Hani Suleiman has written an article in this month’s JDJ rebutting those in the industry who have taken a position against the overuse of J2EE. As one of the pack howling at that particular moon, I thought I’d respond. I’m one of those people that believes that code without tests isn’t code, its hope. For me, testability is key. To be testable, my code has to be succinct, direct, and simple. Much (but not all) of the time, J2EE doesn’t meet those criteria.

First, and foremost, let me say that Hani’s assertion that most of the anti-J2EE opinion is “spread through rumor mongering and anecdotal stories with little to no effort made to validate them or place them in context” is a sweeping generalization about a wide variety of people, opinions and publications. I think the weight of his piece would have been greater without this needless swipe at the validity and professionalism of those who see things differently.

In our new book, “Better, Faster, Lighter Java”, Bruce Tate and I argue that J2EE has negatively impacted the software development by inserting often needless complexity into our code, and being hostile to the tools that really drive quality, like automated unit and integration testing, for example. And, for 250+ pages, we tackle those issues and look at alternatives.

Now, on to his “myths”:

1. JNDI is awkward.

Now, I don’t know about you, but if I’m trying to argue against some position, I usually tackle the big items up front. If your biggest reason to avoid J2EE is that JNDI is awkward, then you probably haven’t thought that much about your software. Essentially, your choices boil down to these:

a) couple directly to the binary image of your code at compile time
b) couple loosely to the binary through directory resolution
c) couple loosely to the binary through IoC frameworks

Frankly, as long as you avoid option a) as much as possible, then your other choices are just a matter of personal style. Given that, however, it is difficult to follow Hani’s logic when he argues that JNDI is more useful when you count all the free googaws that the different vendors include for clustering JNDI. Those tools might be useful, but they don’t make it any less “awkward”.

2. J2EE is difficult to develop in.

This is my favorite point in the article. Hani admits that J2EE is unit-test-resistant and not particularly agile. However, he says that the blame should be placed with the vendors, not with the spec. That’s like saying that hydrogen-filled airships are a decent idea, but its the guys who built the Hindenburg that are to blame. If all the tools available show the same resistence to TDD, then maybe the spec has something to do with it.

Hani later makes a point I totally agree with: J2EE isn’t for everybody or every project, but it IS ideal for some. The important thing is to let common sense rule the day: if you will get more benefit than pain from using J2EE, then do it! Otherwise, find another path.

3. EJBs must be avoided at all costs.

Hani rightly points out that the lighter-weight EJBs (stateless session beans, for instance) can offer a lot of benefit without nearly the same cost as, say, entity beans. They are still test-resistant, though, and therefore the cost is still greater than some other options. Again, though, the rule of thumb is to make a real cost/benefit decision. If it comes out in your favor, do it.

4. J2EE is dead!

I just don’t know where he got this. This sounds like a straw man to me. If J2EE was dead, why would there be so many of us out here beating the bushes for alternatives? There would be no need for a book like Better, Faster, Lighter Java if J2EE was gasping its last breath; we would just let it die. I mean, c’mon, have you seen the 3.0 spec?

5. J2EE is unportable.

Again, Hani blames the vendors for mandating their own custom deployment descriptors. I really don’t get the distinction between the spec and the implementations OF the spec. This makes me wonder what Hani’s motivation is. The spec is only as good as the implementations available. If they all make the same mistake, we, as developers, are stuck with the consequences, whether or not the spec mandates it. As it stands today, making an app portable between WebSphere, WebLogic and JBoss means spending a lot of time worrying about configuration and feature-creep that shouldn’t be necessary.

6. J2EE is expensive.

I’m just not sure where he’s going with the final line: “Do not neglect to factor in the cost of the time and effort you’d be wasting by going to a third-party library and spending hours reconfiguring it for every new application.” This implies, seemingly, that you don’t need to reconfigure J2EE for every new application, which is patently untrue (see his earlier point about deployment descriptor hell). If he didn’t mean to imply that, but rather, to imply that other libraries have as many configuration problems as J2EE, then he’s right. But they generally don’t have the further costs, like a super-heavy container, intrusive requirements for your code, etc.

J2EE is expensive, whether or not you go with a commercial, open source, or commercial open source vendor. That expense comes in money, time, resources, and complexity. Just remember that expense is only half of cost/benefit analysis.

7. API X is too complex/unclear; it’s easier to roll your own instead.

I don’t disagree with his underlying point, which is that all the different implementations of J2EE provide a ton of services, some of which are trivial to set up. What I disagree with is his conflation of “using an open source project” with “rolling your own”. Those are two entirely different concepts; if I choose to get my transactional management from a different framework, that doesn’t mean I wrote it myself.

8. Petstore is a reference implementation.

Anybody who still believes this needs to be smacked down. I think the Petstore application has been dissected enough that people don’t honestly use it as an example of anything, except maybe bad marketing.

9. J2EE is useless without extra frameworks.

Hani’s right to say that “naked” J2EE still provides services that you wouldn’t get with just plain POJOs and Tomcat, for instance. And, again, I say that if the cost is worth it (in money, time, and having a heavy container) then by all means, go with it. I’m just not sure where he’s going by invoking JSF. Is this supposed to prove that really good frameworks become part of the spec? He says himself that there are issues with JSF that the committee is feverishly trying to work out. How does the committee rushing out a half-finished addition to the spec rebut the “urban myth” that J2EE is useless withot extra frameworks? To me, the JSF issue shows that J2EE is deficient on the presentation tier, and needs extra help, but that the addition to the spec doesn’t yet solve the problem.

Conclusion

The opening paragraph of Hani’s conclusion is, I think, as clear a presentation of my viewpoint as possible, and demonstrates that we agree on a common principle: don’t blindly trust what some book author or CTO tells you. Be smart, use your brain, and figure out whether J2EE or Spring or Pico or POJOs or whatever solve your problems. And they use that solution. But be cognizant that J2EE often tries to solve problems you don’t have, and you can often wind up writing more code to support your container than to solve your customer’s problems.

Related link: http://www.ondotnet.com/pub/a/dotnet/2004/06/14/liberty_whidbey.html?page=1

Wow!” That is my honest opinion about the level of support built into ASP.NET 2.0 for forms-based security.

This is the first of two articles on adding security to your ASP.NET application in ASP.NET 2.0 (Whidbey)

In my last weblog, I wrote about a fascinating but disturbing new email service called DidTheyReadIt that lets you trace every piece of email you send, for $50 a year. It tells you if someone opened your mail, and even how long the recipient kept your email open.

I’ve used the service more since then, and done a bit of investigation, and what I’ve found is both disturbing and reassuring. Disturbing because DidTheyReadIt uses a technology commonly used by spammers to help harvest email addresses, and reassuring because it’s so easy to defeat.

DidTheyReadIt attaches an transparent, one-pixel .gif called a “Web bug” or “Web beacon” to emails you send out. When someone opens your email, your email server grabs the .gif from the DidTheyReadIt server, which then logs information about when you opened the message, and for how long you had it open. It then sends that information to you. Spammers commonly use this technology to confirm people’s email addresses, so that they can spam them more in the future, and sell the confirmed email addresses to other spammers.

The DidTheyReadIt service has more problems than that it invades people’s privacy, and uses a technology that spammers use. Ultimately, too much of the time it can’t actually tell you if someone has ready your message. If you send a message to someone who doesn’t use HTML email, you won’t be able to know whether he’s opened the message. Outlook 2003, and all future versions of Outlook, turn off HTML email by default. So send a message to someone who uses Outlook 2003, and you won’t know whether your mail got through. (The exception is if you’re on the Contact list of the person to whom you’re sending a message. In that case, Outlook 2003 turns on HTML.)

Because Web bugs are associated with spam, some anti-spam software blocks email that includes them. In the future, expect that all anti-spam software will do it. It even appears that some ISPs block email with Web bugs as well. I’ve sent several emails using DidTheyReadIt to my beta Google Gmail account, and not a single one has gotten through.

What’s the upshot? DidTheyReadIt is one of those bad ideas that probably won’t stick around long. Legislation won’t be needed to kill it (as some have proposed) — technology will handle that all by itself.

What do you think of DidTheyReadIt and similar technologies? Should the government intervene?

Related link: http://www.ondotnet.com/pub/a/dotnet/2004/06/07/liberty.html

Liberty On Whidbey has a new column on C# Iterators.

I look forward to your feedback.

Related link: http://radio.weblogs.com/0138856/

I’ve created a new web log for my non technical writing.

I will restrict this log to writing about technical issues and pointing to my other technical writing.

Thanks.

Related link: http://www.ondotnet.com/pub/a/dotnet/2004/05/17/liberty.html

The single most anticipated (and dreaded?) feature of Visual C# 2.0 is the addition of Generics. This new article will show you what problems generics solve, how to use them to improve your code, and why you need not fear them

Talk with me about Generics, Whidbey or anything else that is on your mind…

I’ve been beta testing a piece of email software that some people see as breaking the basic web of trust that holds the entire Internet together, and I hate to admit it, but using it gives me a bit of guilty pleasure.

The software, and associated service, is called DidTheyReadIt. Run the software, and then you can invisibly trace any piece of email you send, for the price of $50 a year. You’ll be able to know whether someone opened your email, and even how long the recipient kept your email open. You can even find out where the recipient is physically located.

The software runs in XP or Windows 2000, and it appends a bit of text onto the back end of the recipient’s email address. So if you’re sending email to preston.gralla@gmail.com, for example, it invisibly changes the address to preston.gralla@gmail.com.didtheyreadit.com. The recipient never sees the address change, and never knows that the email is being tracked. Presumably, the email is routed through didtheyreadit.com’s servers, which is how the service does its work.

You don’t have to use the software to track mail. Sign up for the service for $50 a year, and you can manually insert the .didtheyreadit.com to the end of any email address, and the tracking works as well.

DidTheyReadIt is not alone in doing this kind of thing. If you use AOL to send mail to another AOL user, you can do something like this. MessageTag has a similar service as well. But neither track you mail as comprehensively as DidTheyReadIt. And you can always use the return receipt feature of Outlook, but that at least alerts the recipient that you want a receipt, and he always has the option of not returning it.

So what do I think? I’m appalled and fascinated at the same time. Appalled because it breaks the trust inherent in Internet communications. Fascinated because like everyone who’s ever sent an important email, I want to know whether it’s been read, and whether it’s being taken seriously.

But although I’m fascinated, ultimately I think it’s a bad thing. There should be at least one part of our lives that remains private. Although email is used for business, it’s also used for personal communications, and when that intimate barrier is breached, we’re all the poorer for it.

What do you think of DidTheyReadIt? Is it a great new service or an invasion of people’s basic right to privacy? Let me know.