DevMavens Feed

Static vs. Dynamic languages: What I really want

Jeffrey Palermo — Wed, 11 Nov 2009 21:21:00 GMT

“I want static behavior between assemblies/libraries/packages but dynamic abilities within.” – JeffreyPalermo.com

With C# 4.0, code within method can be dynamic because of the new dynamic keyword. This is a short post expressing what I want out of C#.

I recently listened to a great debate about the advantages and shortcomings of both dynamic and static languages, and the biggest pain of 100% dynamic languages is that when using a library, you really don’t know what is supports except if the documentation is liberal and flawless. There are no interface types to describe what properties and methods will be called once you pass the object in. If the documentation doesn’t cover every API, you are forced to write characterization tests.

The other big challenge is that when working with a dynamic language, you have to keep more of the system in your head in order to program. You have to remember which object is overriding which method, and what objects have new functionality attached to them.

Both of these points are only an issue between package boundaries. Within a package, everything is fine because you own all that code. All the conventions are yours. This dovetails with the main strength of a static language: All the APIs are self-describing. Every method declares types on the arguments. Objects explicitly implement interfaces.

The problem with static languages is that this rigor is extended within the package as well forcing the programmer to write every method body using the same compiler strictness of typing.

If we can have a dynamic keyword in C# so that code within a method body is dynamic, then some of this might already be achieved. We’ll have to see. Public interfaces that are at package boundaries need to be self-describing, from my point of view. After that, writing dynamic code within controlled boundaries can make things go smoother.

ASP.NET MVC wins with simplicity, not features

Jeffrey Palermo — Wed, 11 Nov 2009 21:09:06 GMT

Hot on the heals of DevConnections appearing to downplay ASP.NET MVC and folks like Dino Esposito taking notice, I want to provide my commentary on why the grassroots of the .Net developer community is so in love with ASP.NET MVC, even though Microsoft marketing isn’t really seeming to push it. It’s odd, too, because with Entity Framework, the message from Microsoft is clear: DataSets and Linq2Sql will still be supported. . . but . . . er. . .um, we recommend you start moving to Entity Framework.

Car vs. Motorcycle? Irrelevant analogy, I say

Because of the way the http://asp.net/mvc and other folks present a car vs. motorcycle analogy, the message is loud and clear: 9 of of 10 of you should be using Web Forms/car. The remaining 1 psycho with a death wish can ride the motorcycle/MVC. The problem is that reality is the following: Web Forms is the 1985 Lincoln TownCar (or even modern cars) where every single function is a physical electric toggle switch, plush comfortable seats and a sunroof. ASP.NET MVC is a 1950s Chevy. Every Chevy owner could understand how that car worked because of its simplicity. With the decked-out Lincoln, you needed to call in expert help if your electronic left mirror adjustment switch stopped working.

Whether Microsoft says it or not, ASP.NET MVC is a much superior IHttpHandler than Web Forms. I say it in this way because both use the ASP.NET runtime, which has proven very solid over the years. Because they are both linked to this core interface, they play nicely together. (In fact, stay tuned for an article about how to utilize MvcContrib’s Portable Areas feature by dropping in a DLL into a Web Forms app to instantly give that site a new section of urls and pages.)

Why is ASP.NET MVC superior? How can I say this when Web Forms has so many more controls, so many more features? I say this because it is a framework, not a product. I build products. I use frameworks to build products. I want my platform vendor to provide me with a simple and powerful framework so that I can build killer products for my clients. Crowding the framework with features actually hurts my ability to achieve my goal.

Web Forms will always have more features than ASP.NET MVC. ASP.NET MVC will never provide as many features as Web Forms. Chart control? Nope. How about the most basic grid? I certainly hope not. In fact, as one of the early and strongest community champions of ASP.NET MVC, I hope a grid never ships with it. ASP.NET MVC has such grassroots excitement in the developer community because of the raw simplicity of it.

Simplicity will cause ASP.NET MVC to de facto replace Web Forms. I’ve said before that Web Forms will continue to power interesting web sites for decades to come. I am glad for that. It is a great framework, and I have delivered business critical applications with it. ASP.NET MVC is the way into the future for ASP.NET, though. After having a framework with tons of features and many strong control vendors who provide almost any functionality you can think of in a control, we (as in the average joe developer) long for a simpler way. ASP.NET MVC latches onto some of the strength of Rails and PHP. It is very easy to understand what is going on. Very simple. It doesn’t take an expert to decipher the flow of logic in the pages. This is simpler to the exercise equipment craze of the 1990s giving way to the rise in popularity of simple running and bicycling that we have seen in the U.S this decade.

Conclusion

Microsoft is not jumping up and down saying: “You should be using ASP.NET MVC for all your new web applications!” It’s just the folks who have given the framework a chance who are saying it.

Dino: ASP.NET MVC is MUCH better than MS seems to think

Jeffrey Palermo — Wed, 11 Nov 2009 20:24:58 GMT

Dino Esposito, from whom many of us have read and learned a great deal over the years, has recently expressed his love for ASP.NET MVC. Moreover, he has also notice that the message from Microsoft is very tentative about the framework. Because of the large market share of Web Forms, Microsoft seems hesitant to push ASP.NET MVC as THE NEW VERSION OF ASP.NET for fear that existing customers will worry about being left behind.

I have previously predicted that with Visual Studio 2010, the majority of new ASP.NET projects would use the MVC flavor over the Web Forms flavor. I stand by that because the IHttpHandler that is MVC is simpler to use and maintain than the System.Web.UI.Page (which is just an IHttpHandler).

Chasing the SQL Injection that never was

Oren Eini — Wed, 11 Nov 2009 15:00:00 GMT

So, I am sitting there quietly trying to get EF Prof to work in a way that I actually like, when all of a sudden I realize that I am missing something very important, I can’t see the generated queries parameters in the profiler.

Looking closely, I started investigating what appear to be a possible SQL injection issue with EF. My issue was that this query:

entities.Posts.Where(x=>x.Title == “hello”)

Generated the following SQL:

SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title],
[Extent1].[Text] AS [Text],
[Extent1].[PostedAt] AS [PostedAt],
[Extent1].[BlogId] AS [BlogId],
[Extent1].[UserId] AS [UserId]
FROM [dbo].[Posts] AS [Extent1]
WHERE N'hello' = [Extent1].[Title]

It literally drove me crazy. Eventually I tried this query:

var hello = "hello";
entities.Posts.Where(x=>x.Title==hello);

Which generated:

SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title],
[Extent1].[Text] AS [Text],
[Extent1].[PostedAt] AS [PostedAt],
[Extent1].[BlogId] AS [BlogId],
[Extent1].[UserId] AS [UserId]
FROM [dbo].[Posts] AS [Extent1]
WHERE [Extent1].[Title] = @p__linq__1

This was more like it.

It seems (and Julie Lerman confirmed it) that EF is sticking constant expressions directly into the SQL, and treating parameters differently.

I am not quite sure why, but from security standpoint, it is obviously not a problem if it does so for constants. It have a lot less hair now, though.

Configuring the PasswordRecovery To Send Email to an SSL-Enabled SMTP Client

Scott Mitchell — Tue, 10 Nov 2009 17:54:00 GMT

ASP.NET's PasswordRecovery provides a mechanism for users to recover their forgotten passwords. Depending on how user passwords are saved, the PasswordRecovery control will either email a user their password or it will reset the user's password to a new, auto-generated one and email them this new password. In either case, the PasswordRecovery control sends an email message. To accommodate this, your web application should have the SMTP settings defined in Web.config's section as described in this article: Sending Email in ASP.NET.

Certain SMTP servers (such as GMail's) only accept connections over SSL. Unfortunately, you cannot specify whether to send emails via SSL from the section; rather, you have to do it when you instantiate the SmtpClient object, via its EnableSsl property. This is problematic if you need to have the PasswordRecovery control send the user her password via an SMTP server that requires SSL. The workaround is to create an event handler for the PasswordRecovery control's SendingMail event, where you create your own SmtpClient object, set its EnableSsl property, and use it to send the MailMessage object the PasswordRecovery control is getting ready to send.

Protected Sub prResetPwd_SendingMail(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.MailMessageEventArgs) Handles prResetPwd.SendingMail
    Dim smtp As New SmtpClient
    smtp.EnableSsl = True

    Try
        smtp.Send(e.Message)
    Catch ex As Exception
        'Decide how to handle SMTP errors
    End Try

    'Instruct the control to cancel sending the email itself, since we just sent it
    e.Cancel = True
End Sub

Two things to note:

The MailMessage object that the PasswordRecovery control is about to send is available via e.Message, and
It is important to set e.Cancel to True. This tells the PasswordRecovery control to not send the email, which is what we want because we have already sent it with the SmtpClient object created in this event handler.

This concept can be extended to other ASP.NET Web controls that can automatically send emails (such as the CreateUserWizard control).

Happy Programming!

Select N+1 is also applicable for user interface

Oren Eini — Tue, 10 Nov 2009 15:00:00 GMT

I just opened Messenger for the first time in maybe a year, here is what it end up looking like (and this is the truncated list):

And it doesn’t seems to end…

Download Podcasts with Powershell

Scott Hanselman — Tue, 10 Nov 2009 04:38:18 GMT

A number of people have mentioned to me that they didn't realize that Powershell is included by default in Windows 7. If you haven't yet jumped on the Powershell bandwagon, this is a good time. Powershell 2 includes a bunch of cool features like

Über Prof goes live

Oren Eini — Tue, 10 Nov 2009 03:03:00 GMT

Über Prof is the codename for the multi-OR/M profiler that I have been working on for the last several weeks.

Today is a good milestone, because it marks the shift from treating it as an experimental to production ready.

Über Prof also brings with it several changes to the way I mange the profiler profiles. Each profile (NHProf, HProf, L2SProf and EFProf, currently) is built on top of the same codebase, but contains slightly different functionality to fits it target audience. I might talk about exactly how we are doing that in a later post.

That required making a small number of breaking changes:

The executable filename was changed to NHProf.exe (or HProf.exe, or L2SProf.exe, etc)
The appender filename was changed to HibernatingRhinos.Profiler.Appender.dll
The appender type name was changed to HibernatingRhinos.Profiler.Appender.[profile].[profile]Profiler.Initialize();

In practice, those changes are annoying, but should be very easy to fix.

Something important to note, however, is that NHibernate profiling and Hibernate profiling has been split.

For NHibernate, we have NHProf, and for Hibernate, we have HProf.

I hope to have L2sProf out in public beta this week. And EFProf is currently in private beta for this week and hopefully poke its nose out as public beta next week.

Read more: Über Prof goes live | Subscribe

Party with Palermo: PDC ‘09 edition – 6 days and counting

Jeffrey Palermo — Tue, 10 Nov 2009 01:55:55 GMT

That’s right, folks! For those of your coming to Microsoft’s Professional Developers’ Conference (PDC), Party with Palermo is going to kick the week off right. The conference starts on Tuesday, so Monday night, we are going to get down and party to the turntables of DJ Craig. If you were at the Party with Palermo at Tech Ed, you remember this DJ and how he had the uncanny ability to get folks like Ted Neward and Sara Ford dancing like it was 199. . . 2009!

Here is the skinny: Monday night – 7pm-10pm before PDC. Come to The Mayan, 6 blocks from the convention center in downtown L.A. Party with Palermo. RSVP now!

November 16, 2009 - Los Angeles, CA - 7:00PM - 10:00PM

The Mayan (map, website)
1038 South Hill St., Los Angeles, CA 90015
Ph: (213) 746-4287 - (six blocks from the convention center)
Cover charge is 1 business card. This will get you in the door and register you for the grand prize drawings.

Entertainment provided by:

DJ Craig

Free to attend
Free drinks
Free swag
Eat before you come

Sponsors: (find out how to become a sponsor)

KEEP TABS ON HTTP://www.PartyWithPalermo.com --- THIS IS WHERE THE INFORMATION WILL BE POSTED.

Subscribe to the Party with Palermo newsletter

Feel free to blog and link back to this site.

Answering YAGNI commentary

Oren Eini — Mon, 09 Nov 2009 23:49:00 GMT

My post about applying YAGNI in Impleo has gotten a lot of comments, and instead of answering them one at a time, I think it would be useful to just have a post answering all of them together.

Ryan Riley: I suppose I'm still wondering, how did WebForms appear as a result of YAGNI? I realize that's the original ASP.NET platform, but MVC seems simpler to me, and even simpler would be starting with HTML, CSS, and JavaScript (or, heaven forbid, classic ASP) with some AJAX.

Ryan, it is quite simple. It is all about friction, using HTML, CSS & Javascript would have added more friction initially than the webforms solution.

Torkel: Any plans to open source it?

Highly unlikely.

Andrew: I know we all hate Web Forms, yada yada yada, but if you need to just setup a few pages, it's dead easy and much faster than MVC, a WCF service or any other method to deliver content. Hence why it makes perfect sense in this "I'm using YAGNI to the letter of the law" experiment.
But the reality is, you rarely have a project where you can work in this pure YAGNI way, since there almost always is requirements such as make it testible, make it easy to maintain, make it SOE friendly, etc. so working in ASP.NET Webforms a poor choice for the job. But there does come a time where a project is "All we need is one page that shows data in a grid", it can be done in literally 10 minutes with a WebForm.

I agree, except that there is an additional thing that I want to bring to the table. The most important thing for me in most of my apps is the first customer demo. That is important for a host of reasons, but most importantly, because it make a product real. Building fancy architecture and buzzward compliant development is usually in the way of that. The first customer demo is simple, stupid and should be out as soon as possible.

Dmitriy Nagirnyak:

Your own website framework?
Hmm.
What are the reason for starting it from scratch if there are some of them already available?
- Exercise?
- Lack of extensibility?
- Wrong architecture?
- "Just want my own" thing?
- others?

Quite simple, I wanted something that would work the way I need it to work. Anything that adds friction to the process is not acceptable. I am willing to build my own thing to get a friction free process.

Richard Dingwall: Article starts with YAGNI and ends up writing a whole new CMS from scratch! Ayende!!

See previous reply.