January 2011 Blog Posts
Over the past couple of years, I’ve written several blog posts on ASP.NET Routing where I provided various extensions to routing. Typically such blog posts included a zip download of the binaries and source code to allow readers to easily try out the code.
But that’s always been a real pain and most people don’t bother. But now, there’s a better way to share such code. Moving forward, I’ll be using NuGet packages as a means of sharing my code samples.
In the case of my routing extensions, I’ve compiled them into a solution I call RouteMagic (source is available on GitHub). This solution includes two packages, RouteMagic.Mvc (extensions specific to ASP.NET MVC Routing) and RouteMagic (more general ASP.NET Routing extensions). The RouteMagic.Mvc package depends on the RouteMagic package.
These packages are available in the NuGet feed!
After installing the RouteMagic.Mvc package, you’ll have the following features available to you.
The source code for the solution contains the following projects:
- RouteMagic
- RouteMagic.Mvc
- RouteMagic.Demo.Web (ASP.NET MVC Web application used to demo these features)
- UnitTests
This is just a pet project I put together based on various blog posts I’ve written. I’d love to see some of these ideas eventually make it into the Framework. But until then, you’ll probably see these things make it into Subtext for sure!
Ni hao ma!
Hot on the heels of the RTM release of ASP.NET MVC 3, we now have localized versions of ASP.NET MVC in 9 languages! The installation links within the Web Platform Installer was updated. If you want to download the installer yourself, you can go to the English download page and select your language or click on one of the nine languages below:
If you speak one of these nine languages, you can now develop with ASP.NET MVC in your native language. Salud!
Last night I got a little treat in the mail from the kind folks at StickerMule. I really appreciate how they support open source projects with such great stickers.
Look at all those little NuGets!
Just in time as I have a few events I’ll be going to where I can hand some out such as Web Camps Argentina/Brazil, the MVP Summit, and if I’m selected, Mix 2011.
After that, I need to figure out the best way to give the rest out since I won’t be travelling a whole lot this year. We’ll need to have a Nerd Dinner or something. I’ll give some to Scott Hanselman since he travels a lot too.
For those of you who enjoy learning about a technology via screencast, I’ve recorded a video to accompany and complement this blog post. The screencast shows you what this package does, and the blog post covers more of the implementation details.
A key feature of any package manager is the ability to let you know when there’s an update available for a package and let you easily install that update.
For example, when we deployed the release candidate for NuGet, the Visual Studio Extension Manager displayed the release in the Updates section.
Likewise, NuGet lets you easily see updates for installed packages. You can either run the List-Package –Updates command:
Or you can click on the Updates node of the Add Package dialog:
This feature is very handy when using Visual Studio to develop software such as Subtext, an open source blog engine I run in my spare time. But I started thinking about the users of Subtext and the hoops they jump through to upgrade Subtext itself.
Wouldn’t it be nice if Subtext could notify users when a new version is available and let them install it directly from the admin section of the running website completely outside of Visual Studio? Why yes, that would be nice.
NuGet to the Rescue!
Well my friends, that’s where NuGet comes into play. While most people know NuGet as a Visual Studio extension for pulling in and referencing libraries in your project, there’s a core API that’s completely agnostic of the hosting environment whether it be Visual Studio, PowerShell, or other. That core API is implemented in the assemly, NuGet.Core.dll.
This assembly allows us to take advantage of many of the features of NuGet outside of Visual Studio such as within a running web site!
The basic concept is this:
- Package up the first version of a website as a NuGet package.
- Install this package in the website itself. I know, crazy talk, right?
- Add a custom NuGet client that runs inside the website and checks for updates to the one package that’s installed.
- When the next version of the website is ready, package it up and deploy it to the package feed for the website. Now, the users of the website can be notified that an update is available.s
I should point out a brief note about step #2, because this is going to be confusing. When I say install the package in the website, I mean to contrast that with installing a package into your Web Application Project for the website.
When you install a package into your Web Application Project, you use the standard NuGet client within Visual Studio. But when you deploy your website, the custom NuGet client within the live website will install the website package into a different location. In the example I’ll show you, that location is within the App_Data\packages folder.
The AutoUpdate Package
Earlier this week, I gave an online presentation to the Community For MVC (C4MVC) user’s group on NuGet. During that talk I demonstrated a prototype package I wrote called AutoUpdate. This package adds a new area to the target website named “Installation”. It also adds a nuspec file to the root of the application to make it easy to package up the website as a NuGet Package.
The steps to use the package are very easy.
Install-Package AutoUpdate. - In Web.config, modify the appSetting
PackageSource to point to your package source. In my demo, I just pointed it to a folder on my machine for demonstration purposes. But this source is where you would publish updates for your package. - In the Package Console, run the
New-Package script (This creates packages up the website in a NuPkg file). - Copy the package into the App_Data\Packages folder of the site.
- When you are ready to publish the next version as an update, increment the version number in the nuspec file and run the
New-Package script again. - Deploy the updated package to the package source.
- Now, when your users visit /installation/updates/check within the web site, they’ll be notified that an update is available and will be able to install the update.
The Results
Lets see the results of installing the AutoUpdate package and I’ll highlight some of the code that makes the package work. The following screenshot shows a very basic sample application I wrote.
The homepage here has a link to check for updates which links to an action within the area installed by the AutoUpdate package. That action contains the logic to check for updates for this application’s package.
Clicking on that link requires me to login first and then I get to this page:
As I mentioned in the steps before, I packaged up the first version of the application as a package and “installed” it into the App_Data folder.
That yellow bar above is the result of an asynchronous JSON request to see if an update is available. It’s a little redundant on this page, but I could have it show up on every page within the admin as a notification.
Under the Hood
Let’s take a look at the controller that responds to that asynchronous request.
public ActionResult Check(string packageId) {
var projectManager = GetProjectManager();
var installed = GetInstalledPackage(projectManager, packageId);
var update = projectManager.GetUpdate(installed);
var installationState = new InstallationState {
Installed = installed,
Update = update
};
if (Request.IsAjaxRequest()) {
var result = new {
Version = (update != null ? update.Version.ToString() : null),
UpdateAvailable = (update != null)
};
return Json(result, JsonRequestBehavior.AllowGet);
}
return View(installationState);
}
The logic here is pretty straightforward. We grab a project manager. We then grab a reference to the current installed package representing this application. And then we check to see if there’s an update available. If there isn’t an update, the GetUpdate method returns false. There’s a couple of methods here that I wrote we need to look at.
The first method very simply retrieves a project manager. I encapsulated it into a method since I call it in a couple different places.
private WebProjectManager GetProjectManager() {
string feedUrl = @"D:\dev\hg\AutoUpdateDemo\test-package-source";
string siteRoot = Request.MapPath("~/");
return new WebProjectManager(feedUrl, siteRoot);
}
There’s a couple things to note here. I hard coded the feedUrl for demonstration purposes to point to a directory on my machine. This is a nice demonstrations that NuGet can simply treat a directory containing packages as a package source.
For your auto-updating web application, that should point to a custom feed you host specifically for your website. Or, point it to the official NuGet feed and put your website up there. It’s up to you.
This method returns an instance of WebProjectManager. This is a class that I had to copy from the System.Web.WebPages.Administration.dll assembly because it’s marked internal. I don’t know why it’s internal, so I’ll see if we can fix that. It’s not my fault so please direct your hate mail elsewhere. 
What is the web project manager? Well the WebMatrix product which includes the ASP.NET Web Pages framework includes a web-based NuGet client for simple web sites. This allows packages to be installed into a running website. I’m just stealing that code and re-purposing it for my own needs.
Now, we just need to use the project manager to query the package source to see if there’s an update available. This is really easy.
private IPackage GetInstalledPackage(WebProjectManager projectManager,
string packageId) {
var installed = projectManager.GetInstalledPackages("AutoUpdate.Web")
.Where(p => p.Id == packageId);
var installedPackages = installed.ToList();
return installedPackages.First();
}
What’s really cool is that we can just send a LINQ query to the server because we’re running OData on the server, it’ll run that query on the server and send us back the packages that fulfill the query.
That’s all the code necessary to check for updates. The next step is to write an action method to handle the upgrade. That’s pretty easy too.
public ActionResult Upgrade(string packageId) {
var projectManager = GetProjectManager();
var installed = GetInstalledPackage(projectManager, packageId);
var update = projectManager.GetUpdate(installed);
projectManager.UpdatePackage(update);
if (Request.IsAjaxRequest()) {
return Json(new {
Success = true,
Version = update.Version.ToString()
}, JsonRequestBehavior.AllowGet);
}
return View(update);
}
This code starts off the same way that our code to check for the update does, but instead of simply returning the update, we call projectManager.UpdatePackage on the update. That method call updates the website to the latest version.
The rest of the method is simply concerned with returning the result of the upgrade.
Try it Yourself
If you would like to try it yourself, please keep a one big caveat in mind. This is rough proof of concept quality code. I hope to shape it into something more robust over time and publish it in the main package feed. Until then, I’ll post it here for people to try out. If there’s a lot of interest, I’ll post the source on CodePlex.com.
So with that in mind, give the AutoUpdate package a try
install-package AutoUpdate
and give me some feedback!
The changing of the year is a time of celebration as people reflect thoughtfully on the past year and grow excited with anticipation for what’s to come in the year ahead.
Today, there’s one less thing to anticipate as we announce the final release of ASP.NET MVC 3 and NuGet 1.0!
Oh yeah, this never gets old.
Install it via Web Platform Installer or download the installer directly to run it yourself.
Here are a few helpful resources for learning more about this release:
Those links will provide more details about what’s new in ASP.NET MVC 3, but I’ll give a quick bullet list of some of the deliciousness you have to look forward to. Again, visit the links above for full details.
For those of you wishing to upgrade an ASP.NET MVC 2 application to ASP.NET MVC 3, check out Marcin Dobosz’s post about our ASP.NET MVC 3 Projct upgrader tool. The tool itself can be found on our CodePlex website.
NuGet 1.0 RTM
Also included in this release is the 1.0 release of NuGet. I’ll let you in on a little secret though, if you upgraded NuGet via the Visual Studio Extension Gallery, then you’ve been running the 1.0 release for a little while now.
If you already have an older version of NuGet installed, the ASP.NET MVC 3 installer cannot upgrade it. Instead launch the VS Extension manager (within Visual Studio go to the Tools menu and select Extension Manager) and click on the Updates tab.
Just recently we announced the Beta release of our NuGet Gallery. Opening the door to the gallery will make it very easy to publish packages, so what are you waiting for!?
At this point I’m obligated to point out that everything about NuGet is open source and we’re always looking for contributors. If you’re interested in contributing, but are finding impediments to it, let us know what we can improve to make it easier to get involved. Here’s the full list of OSS projects that make up the NuGet client and the server piece:
Show Me The Open Source Code!
As we did with ASP.NET MVC 1.0 and ASP.NET MVC 2, the source for the ASP.NET MVC 3 assembly is being released under the OSI certified Ms-PL license. The Ms-PL licensed source code is available as a zip file at the download center.
If you’d like to see the source code for ASP.NET Web Pages and our MVC Futures project, we posted that on CodePlex.com too.
What’s Next?
So what’s next? Well you can probably count as well as I can, so it’s time to start getting planning for ASP.NET MVC 4 and NuGet 2.0 in full gear. Though this time around, with NuGet now available, we have the means to easily distribute a lot of smaller releases throughout the year as packages, with the idea that many of these may make their way back into the core product. I’m sure you’ll see a lot of experimentation in that regard.
As David Ebbo blogged today, the NuGet Gallery is now open to the public. The goal of the NuGet Gallery is to be the hub for NuGet users and package authors alike. Users should be able to search and discover packages with detailed information on each one and eventually rate them. Package authors can register for an API key and upload packages.
We’re not quite where we want to be with the gallery, but we’re moving in the right direction. If you want to see us get there more quickly, feel free to lend a hand. The gallery is running on fully open source code!
In this blog post, I wanted to cover step by step what it takes to create and upload a package.
Create Your Package
Well the first step is to create a package so you have something to upload. If you’re well acquainted with creating packages, feel free to skip this section, but you may learn a few tips if you stick with it.
I’ll start with a simple example that I did recently. The XML-RPC.NET library by Charles Cook is very useful for implementing XML-RPC Services and clients. It powers the MetaWeblog API support in Subtext. As a courtesy, I recently asked Charles if he would mind if I created a NuGet package for his library for him, to which he said yes!
So on my machine, I created a folder named after the latest 2.5 release, xmlrpcnet.2.5.0. Here’s the directory structure I ended up with.
By convention, the lib folder is where you place assemblies that will get added as referenced assemblies to the target project when installing this package. Since this assembly only supports .NET 2.0 and above, I put it in the net20 subfolder of the lib folder.
The other required file is the .nuspec file, which contains the metadata used to build the package. Let’s take a look at the contents of that file.
<?xml version="1.0" encoding="utf-8"?>
<package>
<metadata>
<id>xmlrpcnet</id>
<version>2.5.0</version>
<authors>Charles Cook</authors>
<owners>Phil Haack</owners>
<description>A client and server XML-RPC library for .Net.</description>
<projectUrl>http://www.xml-rpc.net/</projectUrl>
<licenseUrl>http://www.opensource.org/licenses/mit-license.php</licenseUrl>
<tags>xml-rpc xml rpc .net20 .net35 .net40</tags>
<language>en-US</language>
</metadata>
</package>
There’s a couple of things I want to call out here. Notice that I specified Charles Cook in the authors element, but put my own name in the owners element. Authors represent the authors of the library within the package, while the owner typically represents the person who created the package itself. This allows people to know who to contact if there’s a problem with the package vs a problem with the library within the package.
In general, we hope that most of the time, the authors and the owners are one and the same. For example, someday I’d love to help Charles take ownership of his packages. Until that day, I’m happy to create and upload them myself.
If somebody creates a package for a library that you authored and uploads it to NuGet, assume it’s a favor they did to get your library out there. If you wish to take ownership, feel free to contact them and they can assign the packages over to you. This is the type of thing we’d like to see resolved by the community and not via some policy rules on the gallery site. This is a case where the gallery could do a lot to make this sort of interaction easier, but does not have such features in place yet.
With this in place, it’s time to create the package. To do that, we’ll need the NuGet.exe console application. Copy it to a utility directory and add it to your path, or copy it to the parent folder of the package folder.
Now, open a command prompt and navigate to the directory and run the nuget pack command.
nuget pack path-to-nuspec-file
Here’s a screenshot of what I did:
Pro tip: What I really did was add a batch file I call build.cmd in the same directory that I put the NuGet.exe file. The contents of the batch file is a single line:
for /r %%x in (*.nuspec) do nuget pack "%%x" -o d:\packages\
What that does is run the nuget pack command on every subdirectory of the current directory. I have a folder that contains multiple packages that I’m working on and I can easily rebuild them all with this batch file.
Ok, so now we have the package, let’s publish it! But first, we have to create an account on the NuGet Gallery website.
Register and Upload
The first step is to register for an account at http://nuget.org/Users/Account/Register. Once you have an account, click on the Contribute tab. This page gives you several options for managing packages (click to enlarge).
To upload your package, click on the Add New Package link.
Notice there’s two options. At this point, you can simply browse for the package you created and upload it and you’re done. In a matter of a few minutes, it should appear in the public feed.
The second option allows you to host your package file in a location other than the NuGet gallery such as CodePlex.com, Google Code, etc. Simply enter the the direct URL to the package and when someone tries to install your package, the NuGet client will redirect the download request to the external package URL.
Submit From The Command Line
Ok, that’s pretty easy. But you’re a command line junky, right? Or perhaps you’re automating package submission.
Well you’re in luck, it’s pretty easy to submit your package directly from the command line. But first, you’re going to need an API key.
Visit the My Account page (http://nuget.org/Contribute/MyAccount) and make a note of your API key (click image below to enlarge it).
Be sure to keep that API key secret! Don’t give it out like I just did. If you do happen to accidentally leak your API key, you can click the Generate New Key button, again like I just did. You didn’t really think I’d let you know my API key, did you?
Now, using the same NuGet.exe command line tool we downloaded earlier, we can push the package to the gallery using the nuget push command.
nuget push path-to-nupkg api-key –source http://packages.nuget.org/v1/
Here’s a screenshot of the exact command I ran.
Shoot! There I go showing off my secret API key again! I better regenerate that.
As you can see, this command uploaded my package and published it to the feed. I can login and visit the Manage My Contributions page to see this package and even make changes to it if necessary.
Moving Forward
We’re still working out the kinks in the site and hopefully, by the time you read this blog post, this particular issue will be fixed. Also, we’re planning to update the NuGet.exe client and make the NuGet gallery be the default source so that the –source flag is not required.
As David mentioned, the site was primarily developed as a CodePlex.com project by the Nimble Pros in a very short amount of time. There’s two major components to the site. There’s the front-end Orchard Gallery built as an Orchard module. This powers the gallery website that you see when you visit http://nuget.org/. There’s also the back-end gallery server which hosts the OData feed used to browse and search for packages as well as the WCF service endpoint for publishing packages.
Each of these components are open source projects which means if you really wanted to, you could take the code and host your own gallery website. Orchard will be using the same code to host its own gallery of Orchard modules.
Also, these projects accept contributions! I personally haven’t spent much time in the code, but I hope to find some free time to chip in myself.
In part 1 of this series, we looked at the scenario for grouping routes and how we can implement matching incoming requests with a grouped set of routes.
In this blog post, I’ll flesh out the implementation of URL Generation.
Url Generation Implementation
URL generation for a group route is tricky, especially when using named routes because the individual routes that make up the group aren’t in the main route collection.
As I noted before, the only route that’s actually added to the route table is the GroupRoute. Thus if you supply a route name for one of the child routes (such as “r1”) during URL generation, you’ll get a null URL.
Interestingly enough, in this case, if you don’t use named routes when using URL generation, everything works just fine. However, since I heartily recommend using named routes all the time, I should cover that situation.
So what we need to do here is supply two route names during URL generation. One for the group route, and one for the child route. How do we supply the child route name? We’re going to have to supply it in the route values. Here’s an example of generating an URL in this manner:
@Html.RouteLink("Hello World Child", "group",
new { __RouteName = "hello-world3" })
Note that the second parameter, “group”, refers to the route name for the GroupRoute that we registered. The route value __RouteName is passed into the GroupRoute so that it can look in its own collection of routes for the matching child route.
In the following code sample, I’ve highlighted the essential part of the URL generation logic within the GroupRoute class.
public override VirtualPathData GetVirtualPath(RequestContext
requestContext, RouteValueDictionary values) {
string routeName = values.GetRouteName();
var virtualPath = ChildRoutes.GetVirtualPath(requestContext,
routeName as string, values.WithoutRouteName());
if (virtualPath != null) {
string rewrittenVirtualPath =
virtualPath.VirtualPath.WithoutApplicationPath(requestContext);
string directoryPath = VirtualPath.WithoutTildePrefix(); // remove tilde
rewrittenVirtualPath = rewrittenVirtualPath.Insert(0,
directoryPath.WithoutTrailingSlash());
virtualPath.VirtualPath = rewrittenVirtualPath.Remove(0, 1);
}
return virtualPath;
}
The code grabs the route name for the child route from the supplied route values. Notice that I’m using an extension method I wrote in my last blog post.
The block of code after the highlighted portion rewrites the virtual path back to the full virtual path for the parent GroupRoute. This ensures that the virtual path that’s eventually returned to the caller will actually work, since the individual routes within the group don’t have a clue that they’re within a group.
In a follow-up blog post, I’ll wrap up this series and provide access to the full source code.
I gave a presentation to another team at Microsoft yesterday on ASP.NET MVC and the Razor view engine and someone asked if there was a reference for the Razor syntax.
It turns out, there is a pretty good guide about Razor available, but it’s focused on covering the basics of web programming using Razor and inline pages and not just the Razor syntax.
So I thought it might be handy to write up a a really concise quick reference about the Razor syntax.
| Syntax/Sample | Razor | Web Forms Equivalent (or remarks) |
| Code Block | @{
int x = 123;
string y = "because.";
}
|
<%
int x = 123;
string y = "because.";
%>
|
| Expression (Html Encoded) |
<span>@model.Message</span>
|
<span><%: model.Message %></span>
|
| Expression (Unencoded) |
<span>
@Html.Raw(model.Message)
</span>
|
<span><%= model.Message %></span>
|
| Combining Text and markup |
@foreach(var item in items) {
<span>@item.Prop</span>
}
|
<% foreach(var item in items) { %>
<span><%: item.Prop %></span>
<% } %>
|
| Mixing code and Plain text |
@if (foo) {
<text>Plain Text</text>
}
|
<% if (foo) { %>
Plain Text
<% } %>
|
| Mixing code and plain text (alternate) |
@if (foo) {
@:Plain Text is @bar
}
|
Same as above |
| Email Addresses |
Hi philha@example.com
|
Razor recognizes basic email format and is smart enough not to treat the @ as a code delimiter |
| Explicit Expression |
<span>ISBN@(isbnNumber)</span>
|
In this case, we need to be explicit about the expression by using parentheses. |
| Escaping the @ sign |
<span>In Razor, you use the
@@foo to display the value
of foo</span>
|
@@ renders a single @ in the response. |
| Server side Comment |
@*
This is a server side
multiline comment
*@
|
<%--
This is a server side
multiline comment
--%>
|
| Calling generic method |
@(MyClass.MyMethod<AType>())
|
Use parentheses to be explicit about what the expression is. |
| Creating a Razor Delegate |
@{
Func<dynamic, object> b =
@<strong>@item</strong>;
}
@b("Bold this")
|
Generates a Func<T, HelperResult> that you can call from within Razor. See this blog post for more details. |
| Mixing expressions and text |
Hello @title. @name.
|
Hello <%: title %>. <%: name %>.
|
| NEW IN RAZOR v2.0/ASP.NET MVC 4 |
| Conditional attributes |
<div class="@className"></div>
|
When className = null<div></div>
When className = ""
<div class=""></div>
When className = "my-class"
<div class="my-class"></div>
|
| Conditional attributes with other literal values |
<div class="@className foo bar">
</div>
|
When className = null<div class="foo bar"></div>
Notice the leading space in front of foo is removed.
When className = "my-class"
<div class="my-class foo bar">
</div>
|
Conditional data-* attributes.
data-* attributes are always rendered. |
<div data-x="@xpos"></div>
|
When xpos = null or ""<div data-x=""></div>
When xpos = "42"
<div data-x="42"></div>
|
| Boolean attributes |
<input type="checkbox"
checked="@isChecked" />
|
When isChecked = true
<input type="checkbox"
checked="checked" />
When isChecked = false
<input type="checkbox" />
|
| URL Resolution with tilde |
<script src="~/myscript.js">
</script>
|
When the app is at /
<script src="/myscript.js">
</script>
When running in a virtual application named MyApp
<script src="/MyApp/myscript.js">
</script>
|
Notice in the “mixing expressions and text” example that Razor is smart enough to know that the ending period is a literal text punctuation and not meant to indicate that it’s trying to call a method or property of the expression.
Let me know if there are other examples you think should be placed in this guide. I hope you find this helpful.
UPDATE 12/30/2012: I’ve added a few new examples to the table of new additions to Razor v2/ASP.NET MVC 4 syntax. Razor got a lot better in that release!
Dear Reader, I apologize for not blogging much lately. I know, total #fail, but I’ve been so f***ing busy lately. I thought I would start off this new year right with a top ten list FTW!
Without further ado, I present my list of the top 10 blogging clichés of 2010. These are things yours truly would never ever do, right?
- The random photo: Starting off the list is a very common one that even gets the very best bloggers, including a random photo in the blog post completely irrelevant to the topic at hand as if trying to meet a stock photography quota for the month. Perhaps you own stock in the stock xchng (or perhaps I should!). At least try to make the photo slightly relevant so it adds something to the post.
- “Dear Reader”: Is there a more patronizingly boorish phrase to use to refer to those reading your blog than “Dear Reader”. Do you know if the person reading your blog is dear? Seriously, he or she could be a total prick who’s only redeeming quality is that he or she clicks on your AdSense link so you can buy a cup of coffee in two years. Do you realize that the person reading the blog might be me? I’m a total jerk and I don’t click on your ad links, but you just complimented me. Ha! When I read a blog post that uses the phrase “Dear Reader” what I see in my head is “Dear random person that I hope clicks on my ads”. I’ve used it at least five times. Don’t be like me.
- Apologizing for not posting regularly: I have a dirty little secret, nobody gives a flying f*** whether or not you’re posting regularly (unless you’re Randall Munroe, then we absolutely do care), so stop apologizing for it. They’re all using some sort of RSS aggregator in the first place so they didn’t even have a clue to how lame you are up until the point that just reminded them. Great job Sport!
- Using f*** when you really meant to say “fuck”: It’s just a fucking word! If you really mean to use it for emphasis, just fucking use it! Nobody, in the history of humanity, ever lost his sight, hearing, or sanity from reading the word fuck. Not to mention that you’re not fooling anyone when you type f***. Do you really have such a low opinion of your readers that you think they’re sitting there thinking “Gee, I wonder wonder what word that could be? Good thing he asterisked the fuck out of that word because I might go blind if he had spelled it out.”
- Overusing the word “fuck”: Whoa nelly! Just because it’s ok to unmask those asterisks from time to time doesn’t mean we should go overboard here. Slowly back away from the “F” key. The word is meant to be very lightly sprinkled to pack a powerful punch when you need it. It’s not meant to be poured liberally like salt in a futile attempt to salvage taste from your awful cooking.
- “Wah wah, I’m so busy.”: You know what, we’re all fucking busy, so shut your pie hole about it already.
- “Hinting at a super secret project you can’t reveal just yet.”: Yeah yeah, we get it. You know something we don’t know so you’re going to rub our faces in it like a bad little doggy who just did a no-no. Bad doggy! This may even be the reason you’re “so busy”. Well I have news for you…wait for it. Wait for it. Nobody cares! Maybe your project really is the next big thing since that little plastic triangle thingy that holds the pizza box up away from the cheese. Really, that thing is awesome! Maybe your project is better than that, but if you can’t talk about it yet, you’re just wasting bandwidth. Once again, shut your pie hole until you can talk about it.
- Top ten lists, for all values of “ten”: Top ten (or eight, or eleven, or any number) lists are a cop out. You know it, I know it, and your readers know it. Top ten lists are what happens when a blogger is in the middle of writing a blog post apologizing for not posting regularly and thinks, “What the f*** am I apologizing for?! I know, I’ll write a top ten list of the varieties of lint I found in my belly button.” Yeah, you’ll make the front page of Reddit, but at what cost of your soul, dear reader? What cost?
- Name Dropping: So just last year I was chatting with my friends Jeff Atwood (aka CodingHorror), George Clooney, and Miguel De Icaza (aka Mr. Mono) about how lame it is to name drop. There’s nothing lamer than that except for name dropping about fictitious events that never happened. Seriously, nobody is going to change their opinion of how lame you are just because you happened to have seen the neighbor of the third cousin of Bruce Schneier from across the conference hall floor (but if you did, high five right atcha!).
- “FTW!” Yes, we all know you’re so hard core and like to express your enthusiasm while simultaneously tweaking your nose at the powers that be, but seriously now. You’re all growed up and it’s time to lay this one to rest, in the same way you no longer play with your GI Joes except when the wife has the kids at her mother’s. One exception to this rule, it’s perfectly fine to use it on Twitter, but only because of its brevity and only until we come up with something better.
Yes, some of these clichés were also noted back in 2007 as reported in CodingHorror, but apparently nobody got the memo as they were still going strong in 2010. Now it is 2011 and I’ve made a new years resolution to avoid such blogging clichés. How am I doing so far?
Probably about as well as my resolution to stop procrastinating, which I made after the new year, so I’m not off to a good start on that one either. 