My Favourite Jon Skeet Facts

Jon Skeet is a programmer at Google, author of C# In Depth and Internet legend from his participation on Stack Overflow.  After his meteoric rise to fame, a question was posted to gather Chuck Norris style facts about Jon Skeet.  There are currently 291 answers, here are few that made me chuckle!

  • Jon Skeet is immutable. If something’s going to change, it’s going to have to be the rest of the universe.
  • Jon Skeet doesn’t have performance bottlenecks. He just makes the universe wait its turn.
  • Users don’t mark Jon Skeet’s answers as accepted. The universe accepts them out of a sense of truth and justice.
  • Anonymous methods and anonymous types are really all called Jon Skeet. They just don’t like to boast.
  • Jon Skeet does not use revision control software. None of his code has ever needed revision.
  • When Jon Skeet’s code fails to compile, the compiler apologises.
  • Jon Skeet is the traveling salesman. Only he knows the shortest route.
  • When Jon Skeet points to nullnull quakes in fear.
  • Jon Skeet coded his last project entirely in Microsoft Paint, just for the challenge.
  • Jon Skeet can believe it’s not butter.
  • Jon Skeet can code in Perl and make it look like Java
  • Jon Skeet codes only with final sealed methods. No one has ever needed to override any of Jon Skeet’s code.
  • Jon Skeet programs in binary, then compiles it into human-readable code.
  • Jon Skeet can make IE obey his CSS rules.
  • Jon Skeet can divide by zero.
  • Jon Skeet has already written a book about C# 5.0. It’s currently sealed up. In three years, Anders Hejlsberg is going to open the book to see if the language design team got it right.

and my personal favourite:

  • Jon Skeet can recite π. Backwards.

Do you have any programming related Chuck Norris facts? Share them with us in the comments!

If you liked this list then you’ll love our Classic Programming Quotes!

Scroll an element into view programmatically with JavaScript

I’ve just finished building an FAQ section for one of Storm‘s clients. The client requested that a list of questions be shown at the top of the page and the user be scrolled to the appropriate answer when they clicked the question. The site was using a URL re-writing scheme that meant using traditional #anchor links was impossible. We got around this by using a very simple piece of JavaScript.


Continue reading

How to take your startup from an idea to $170m

Aaraon Patzer, the founder of Mint.com, gave a really insightful talk at Carsonified’s Future of Web Apps conference in Miami this year.  The video of the talk is definitely worth watching (see bottom of the post) but I’ve pulled out 6 killer tips that you can use today if your thinking of starting a tech company.

1Tell everybody and anybody about your idea. Don’t worry about people stealing your idea, it’s the execution that’s important, not the idea.  Validate your idea before you do anything.  You don’t want to waste your time building something that isn’t wanted or needed.

2Make sure the problem will still be there 5 years from now. Don’t solve a transitional problem that fills in for a missing feature.

3 - Does your idea solve a problem that annoys you and do lots of other people have the same problem?  To be really successful you need a large market for your idea.

4You should have a tangible prototype before seeking funding. Don’t rely on slides.  People/investors will buy into your idea much more easily if they can play with a prototype and see the practical benefits of your product.

5 – To grow and become a large company you will need a sustainable advantage: patent, top tech guy, amazing interface.  You have to do something better that your competitors and that something shouldn’t be easily copied.

6 - Have a genuine revenue model (not advertising) and know how much money you’ll make per-user or per-transaction.  This is far more important than predicting annual revenue.

There were also a couple awesome annecdotes in Aaron’s talk with really inspired me.  These are two amazing pieces of marketing and show fantastic creativity and opportunism.

Too many users for your beta?
First, Mint.com launched a blog before their product to generate awareness.  They had 20,000 people sign up for the beta.  That was way more than they could initially handle, so they sent an email out asking people to put a link on their website or blog saying ‘I want Mint!’ to get priority access.  600 users did this giving Mint.com a great set of back links and authority in search engines as well as the marketing benefits of having their logo on a bunch of sites!  All of that benefit because you had too many users want to use your product, now that’s genius!

Want to win a People’s Choice award?
Second, Mint.com really hit the big time when they won the main prize at the TechCrunch40 conference – the People’s Choice award.  How did they do that?  Well, they noticed there were two small rooms next to the main conference venue that weren’t being rented – so they rented them and set up a couple of bars.  They then went around the conference offering free mint Mojitos to people that stopped by.  By doing this they had a permanent presence at the conference instead of a 7 minute slot, had huge numbers of people interacting with their brand and were able to do one-on-one demos with hundreds of people.  On the back of their victory they were able to go to people like BusinessWeek and CNet to get real, mainstream publicity.  Now that’s what I call a brilliant piece of opportunism!

Prevent a C# or VB.NET Console Application from closing when it finishes

I’m working on a little console application to run a scheduled data import task.  During the debugging of the application I wanted the console window to remain open after the program had finished executing – by default it closes when the application finishes.  There seem to be two common answers to this problem.

The first solution is to run the application without debugging by using Ctrl+F5 instead of just F5.  The console window will remain open when the program has finished.  The disadvantage of this is that you lose Visual Studio’s debug information.

The second solution is to add a couple lines of code to the end of your Main() method which halts the application until the user presses a key.  This allows you to run in Visual Studio’s Debug mode but requires a change to the code that you might not want in a production environment.

Console.WriteLine("Press any key to close");
Console.ReadKey();

Neither solution is perfect, but they both solve the problem well enough to let me get on with development.

URL Re-Writing in ASP.NET Requires Form Action to be Re-written

On a project I was working on recently we ran into a problem where the combination of URL re-writing and  postbacks caused the page to post back to the wrong URL.  When you create an ASP.NET page with a <form runat=”server”> tag, ASP.NET will automatically output the action attribute to be the URL of the current page.  However, the URL that is used is not the original URL of the request, but instead the real URL of the page.  For example, when you are on the page “/services/web-design” the real request might be to “/services.aspx?service=web-design”.  When you do a postback, you will be returned to the ugly URL.


Continue reading

Setup email alerts from ELMAH when exceptions are raised

This is part of a series of posts on using ELMAH to handle error logging for your ASP.NET web applications.  We’ve already looked at how to get started with ELMAH and how to allow remote access to your error logs.  In this post we are going to look at how to configure ELMAH to send you an email alert every time an exception occurs on your site.  This is a really handy feature if you want to catch bugs early and keep your site running smoothly.

ELMAH makes sending email alerts really quite simple.  Open up your web.config file and add an errorMail section definition and corresponding errorMail entry as follows:

<configSections>
	<sectionGroup name="elmah">
		<section name="errorLog"
                               requirePermission="false"
                               type="Elmah.ErrorLogSectionHandler, Elmah"/>
		<section name="errorMail"
                                requirePermission="false"
                                type="Elmah.ErrorMailSectionHandler, Elmah"/>
	</sectionGroup>
</configSections>

<elmah>
	<errorLog type="Elmah.SQLiteErrorLog, Elmah" connectionStringName="..."/>
	<errorMail from="error@mysite.co.uk" to="bug-report@developer.com"/>
</elmah>

You’ll also need to add a reference to the Elmah.ErrorMailModule in your httpModules section.

<system.web>
	<httpModules>
		<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
		<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
	</httpModules>
</system.web>

You will then need to configure an SMTP server for error@mysite.co.uk in your web.config.  You can do this in two ways: inline on the errorMail definition, or in a system.net mailSettings section. Examples of both are shown below. Personally, I prefer to use a mailSettings section as I use the SMTP details elsewhere in my applications.

<system.net>
    <mailSettings>
		<smtp deliveryMethod="network">
			<network host="..." port="25" userName="..." password="..." />
		</smtp>
    </mailSettings>
</system.net>

or

<errorMail from="..." to="..."  async="true" smtpServer="..." smtpPort="25" userName="..." password="..." />

If you want to send your error emails using GMail’s SMTP server you will have to change a couple of bits in your configuration. GMail requires SSL to be enabled. We cannot specify this through the system.net section so we need to add the useSsl parameter to the errorMail tag. We also need to specify port 587. If you don’t specify a port on your errorMail tag, ELMAH will use port 25 by defualt. To tell it to use the port we have defined in the system.net section, set smtpPort="0". [Thanks to Scott Mitchell for this tip]

<elmah>
	<errorMail from="..." to="..." async="true" smtpPort="0" useSsl="true" />
</elmah>

<system.net>
	<mailSettings>
		<smtp deliveryMethod="network">
			<network host="smtp.gmail.com"
				 port="587"
				 userName="..."
				 password="..." />
		</stmp>
	</mailSettings>
</system.net>

That’s all you need.  I suggest creating a page with a deliberate error on to check that everything is set up correctly.

What Next?  Well, if you have a team of developers working on a site then you probably have bug tracking software keeping track of problems that need working on.  Most popular bug tracking packages allow you to post issues by email – why not pipe your error report emails straight into your bug tracker, after all problems that are happening now should be top of your todo list (See Jeff Atwood’s Exception-Driven Development).

Caution: If you experience email issues (maybe a password changes, or an SMTP relay is misconfigured) then you will not receive emails alerting you to the problem (or any other problems).  This is a catch-22 that has caught me out a few times.   If this becomes a problem for you, ELMAH also provides an RSS feed of errors which you could subscribe to, it can also Tweet your errors to you!

Allowing secure, remote access to your ELMAH error log

This is part of a series of posts on using ELMAH to handle error logging for your ASP.NET web applications.  We’ve already looked at how to get started with ELMAH and how to send email alerts when errors occur.  Now we’re going to configure remote access to ELMAH’s error logs and add authentication so that only permitted users may read our exception details.

By default, ELMAH is configured to deny access to the error log it produces unless you are accessing it from the server the site is hosted on. To safely access our logs remotely we need to do two things. First, we need to enable remote access. Second, we need to add authentication so that random users and people of ill-intent cannot access our error reports and see sensitive details of the inner workings of our application.

Enabling Remote Access to ELMAH

To enable remote access we need to add the security section to ELMAH and set allowRemoteAccess="yes".

<configSections>
	<sectionGroup name="elmah">
		<section name="errorLog"
				 requirePermission="false"
				 type="Elmah.ErrorLogSectionHandler, Elmah"/>
		<section name="security"
				 requirePermission="false"
				 type="Elmah.SecuritySectionHandler, Elmah"/>
	</sectionGroup>
</configSections>

<elmah>
	<errorLog type="Elmah.SQLiteErrorLog, Elmah" connectionStringName="..." />
	<security allowRemoteAccess="yes" />
</elmah>

With those definitions added anybody can navigate to /elmah.axd and browse through the exceptions that have been logged.  This is clearly a Bad Thing™ as our error logs contain details of how our application works and may even expose usernames and passwords.  So, we need to prevent unauthorized access.

Add Authentication to ELMAH Error Logs

Using ASP.NET’s Membership Provider and in-built authorization system we can deny anonymous access by adding the following definition to our web.config file. It can go anywhere inside the root configuration element.

<location path="elmah.axd">
	<system.web>
		<authorization>
			<deny users="?" />
		</authorization>
	</system.web>
</location>

This will allow any authenticated user to view the error log. If you only want a select group of people to be able to view the log, you could put those users into a ‘Developers’ role and use something like:

<authorization>
	<allow roles="Developers" />
	<deny users="*" />
</authorization>

If you are unfamiliar with ASP.NET’s authentication and authorization features, you might find this Microsoft KB article helpful.

That’s all there is to it.  By now you should’ve set up automated error logging, secure access to the reports and configured email alerts which pipe straight into your bug tracking software and it’s probably taken less than an hour – how awesome is that!

Getting started with ELMAH: ASP.NET Error Logging and Reporting

This is the first part of a series of posts showing you how to use ELMAH to handle error logging for your ASP.NET web applications.

What is ELMAH?

From the official site: “ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.”

Why should I care?

Once you have dropped the ELMAH dll into your bin directory and added a couple of definitions to your web.config you get a bunch of seriously cool features  without changing a single line of code:

  • Logging of nearly all unhandled exceptions.
  • Remotely view the log of exceptions and full details of any one exception, including the ability to see the original YSoD.
  • Options to receive an e-mail notification of each error at the time it occurs, an RSS feed of the last 15 errors from the log or a Tweet of the error.

Sounds good!  How do I get started?

Head over to the ELMAH downloads page and grab the binaries.  Make sure you pick the right download, x86 v x64 depending on your platform.  Drop the Elmah.dll file into your web sites /bin directory.

At this point you have a choice to make.  You need to pick a storage medium to hold your error log and ELMAH has quite a selection to pick from: SQL Server, SQLite, MS Access, Oracle, Vista DB, MySQL.

I’m going to give an example of how to configure SQLite as it’s my preferred storage medium (I’ll explain why in a minute) – for details of how to configure many of the other databases I suggest you check out the Elmah WebBase.

So, why do I use SQLite?  Well,

  • It’s fast. Very fast.  The database is stored in memory and written to a local file in the App_Data directory.
  • There’s no client-server traffic to a database server clogging up my network.
  • It’s incredibly simple to set up.

To use SQLite we will need to drop the System.Data.SQLite.dll from the ELMAH zip file into the /bin directory.  Now we have everything we need, lets configure web.config.

Configuring web.config for ELMAH with SQLite

Below is a minimal web.config stripped of everything but the pieces you need to add to get ELMAH up and running.

<configuration>
	<configSections>
		<sectionGroup name="elmah">
			<section name="errorLog" requirePermission="false"
                                 type="Elmah.ErrorLogSectionHandler, Elmah"/>
		</sectionGroup>
	</configSections>

	<elmah>
		<errorLog type="Elmah.SQLiteErrorLog, Elmah" connectionStringName="ELMAH.SQLite"/>
	</elmah>

	<connectionStrings>
		<add name="ELMAH.SQLite"
                     connectionString="Data Source=|DataDirectory|errors.s3db"/>
	</connectionStrings>

	<system.web>
		<httpModules>
			<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
			<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah"/>
		</httpModules>

		<httpHandlers>
			<add verb="POST,GET,HEAD" path="elmah.axd"
                             type="Elmah.ErrorLogPageFactory, Elmah"/>
		</httpHandlers>
	</system.web>
</configuration>

Not a lot to it, eh?  Once you’ve added those bits to your config file you application will begin automatically logging your errors and provide you with an interface to view the logged errors via elmah.axd.  However, there is much, much more you can do with ELMAH to make your development and maintenance processes slick and efficient.

Getting the most from ELMAH