The rules have changed. In order to get a good article to appear on the front page you have to put it into a new BlogEngine theme. Then people will kick it. :)

I agree. There needs to be a dedicated themes site.

http://www.blogenginethemes.net/

Looks like someone beat me to it. :(

I think it is a combination of the fact that most developers now have so much to learn and are more interested in the practical things they can use today like AJAX and LINQ. And I have seen polls that show most developers are waiting for Silverlight 2.0. I know both reasons are the case for me. Once developers have geared up on the initial technologies they can use immediately and Silverlight 2.0 is out and widely installed with web browsers, they will start to get into it. Before developers can really take Silverlight seriously there needs to be at least 80% usage. Having 95% would allow it to go mainstream like Flash is now. Perhaps MS can ink some more content deals like they did with ESPN.com to get more sites using Silverlight. A deal with Disney would go a long way to getting onto lots of home computers.

It means the event is not ready for registration yet. Check back often to make sure you get in.

I have been using VisualSVN for almost a year now and it has been great. It is a major time saver. One feature I noticed that was just amazing was that it tracks file renaming and moving as SVN changes so that when you commit the changes it is all tracked with history on the server. That is very useful when refactoring your projects. I set up my SVN server before there was a VisualSVN server but I soon hope to upgrade.

How easy is it to change back to the default diff tool in case a problem comes up?

It is a pointless debate. I only use Vista because I need to run Visual Studio and WinXP became overrun with malware. If I have to pay a measly $15 for an FTP client just because I choose to work on a platform free of malware then that is my choice. And once the full .NET environment and VS is released to the Mac I will move instantly. Everyone knows Vista has been a huge mistake and it will take MS a while to get passed it. They have not released SP1 yet and most people think they will likely wait for SP2 or whatever is the next version of Windows to upgrade. I do not see why you feel the need to tear down MacOS X which has had a great track record over the last several years and has grown in market share.

Spend 3 months on a Mac and then come back and post your thoughts. A single week is hardly enough to really learn to leverage the platform. I first used the Mac in college and it took me 2 weeks to understand the UI and once I did I really liked it. Now I can move between the Mac and Windows very easily, as well as the occasionally Linux/FreeBSD desktop.

Simo,

Here is my response.

FTP client - Transmit (http://www.panic.com/transmit/)

This is an excellent application created by a company that produces several great Mac applications.

Text Editor - BBEdit (http://www.barebones.com/products/bbedit/)

I used this editor for years but eventually started using jEdit because it was more geared towards a developer's needs.

As for WLW, I have only started using it recently. Normally I just use the editor that is built into the web interface. Perhaps a WLW equivalent could be .Mac, but I have no experience with it. A quick search shows that iBlog seems to match WLW pretty well.

http://www.lifli.com/iBlog/index.html

I agree. Posts like this that bash the Mac without really spending enough time to get to know the Mac are really not helpful. It does not counter the reality of Vista. I have used Macs and Windows as well as Linux/FreeBSD systems for years. I like them all for different purposes. His bash on Objective-C simply shows his immaturity. Many developers feel that Objective-C is really very good. Apparently it has had dynamic typing abilities that we are just now getting in C# 3.0, but I doubt this writer knew that or bothered to spend any time working through a tutorial on development on the Mac. The development tools on the Mac are amazing. Just Google for Interface Builder and you will see what I mean.

And one premise he writes about... the greater # of apps ensures that you will find one you like. Well, I have been looking for years for a decent CD writing/burning application and I am still looking. Each has big problems and limitations. I generally try to get by with the software the comes with the hardware but key features are missing. What I found on the Mac was that only the best survive while the half-baked shareware applications never really make it at all. The level of quality expected by Mac users is much higher. You can browse for all of these applications here...

http://www.apple.com/downloads/macosx/

You can see there are plenty.

His comment system is broken (I tried IE and FF) so I will ask my question here...

Why this...

LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

and not this...

LogManager.GetLogger(GetType());

???

I assume you would get the same type either way. No?

Ad spam.

Even better you could use the provider model which handles all of the assembly activation details for you. There is good video on doing this here...

http://dnrtv.com/default.aspx?showID=89

True enough. In my experience the exceptions typically happen when there is a problem with a system outside of the application, such as the remote database. Either the connection string is not valid or a stored procedure was not deployed. In that case if you simply thow the exception (throw;) it will be easy to realize the cause of the problem. Now if you have a null reference, that is another matter that is harder to track down sometimes. For WCF communications, which throw fault exceptions, you could translated the exceptions on the client and turn them into something that makes sense like a NullReferenceException when an object is not found. I recall something along these lines related to SQL or SubSonic where the exceptions related to foreign key constraints were translated into C# terms with exceptions. An example would be making a constraint violation into a invalid state exception. But in the end there is not single way to do it. Context matters.

Seriously, does this really matter? As long as you can somehow determine the source of the error you can log it and later set a breakpoint to debug it later. How the message and the stack trace is formatted hardly matters. The important thing is to allow the exception to be raised to where it is handled instead of eating it and ignoring the problem. In ASP.NET that means handling the Application_Error event in Global.asax which is a good place to log the details and redirect to a proper error page that does not insecurely tell the user about the internals of your application. At the end of the day exceptions should be rare and if they are thrown it will be done during development where you clear them up before the software is published.

Next can we discuss what is better, using StringBuilder versus adding strings with the plus operator?

Keep in mind that a 56k modem will take 1 second to load a 2KB document and 10 seconds to load a 34KB document. (Many people still use modems or share broadband with many users which effectively acts like a 56k connection) By doing the compression for TinyMCE on these two scripts I save roughly 100KB which will have an impact on users with slow connections as well as the used bandwidth for a high traffic website. And if you are concerned with risk of modifying your source in this way, you should have a test suite. There is a great test suite for jQuery that you can find at the bottom of the following page. You can launch it in multiple browsers yourself to see how well it works and to discover cross-browser problems.

http://docs.jquery.com/Browser_Compatibility

And by pre-compressing and carefully testing your scripts you can then leverage HTTP-Gzip support for additional bandwidth savings. Every little bit helps.

What I try to do is write as little JavaScript as possible by leveraging a library like jQuery which is compressed and tested for me. My LinkMindr website uses a single script for custom behavior and comes in at 0.5KB.

http://www.linkmindr.com/LinkMindr.js

So what you are saying is to never compress your JavaScript unless it is helpful and you can minimize the risk. That is always my assumption and I only consider compression when the script is over 20KB. Recently I put together a sample website to use Tidy and I used TinyMCE as an example editor which is an editor run completely with JavaScript. The main script is 208 KB but when passed through Packer it is 87 KB. I can verify that the application works after the compression and if I do have a problem with Packer, which is usually due to not using the semicolons that are optional, I just use JSMin which has a much better chance of working. Note that Prototype does not compress well with Packer because the developers on that project like to leave off the semicolons. The following link explains that in detail.

http://www.andrewdupont.net/2007/02/26/packing-prototype/

Having an easy way to compress my sources I can edit my customizations, like the custom theme that I created for TinyMCE, and compress it during the build. The MSBuild script is here...

http://svn.offwhite.net/svn/SmallSharpTools.Tidy/trunk/build.proj

My custom theme is here...

http://svn.offwhite.net/svn/SmallSharpTools.Tidy/trunk/Website/tiny_mce/themes/custom/

The raw versus compressed is 56KB to 27KB.