Aaronontheweb

Hacking .NET and Startups

Real-time Marketing Automation with Distributed Actor Systems and Akka.NET

I published a lengthy post on MarkedUp’s blog yesterday about the new product we recently released, MarkedUp In-app Marketing Automation for Windows Desktop (with support for Windows Store, Windows Phone, iOS, and Android planned) and how it uses Akka.NET’s distributed actor system to execute real-time marketing automation campaigns for our customers.

If you’re interested in learning how to use actors inside your application or want to know how they can help you build types of applications that are virtually impossible to build over simple HTTP APIs, then you should read it (click here!)

If you enjoyed this post, make sure you subscribe to my RSS feed!



Tradeoffs in High Performance Software

July 15, 2014 15:56 by Aaronontheweb in .NET, Open Source // Tags: , , // Comments (0)

I’ve spent down the past week tracking down an absolutely brutal bug inside Akka.NET. Sometimes the CPU utilization of the system will randomly jump from 10% to 100% and stay pegged like that until the process is recycled. No exceptions were thrown and memory / network / disk usage all remained constant (until I added monitoring.)

I couldn’t reproduce this CPU spike at all locally, nor could I determine the root cause. No one else had reported this issue on the Akka.NET issue list yet, probably because the product is still young and MarkedUp In-app Marketing is the only major commercial deployment of it that I know of (hopefully that will change!)

I had to hook up StatsD to MarkedUp’s production Akka.NET deployments to figure out what was going on ultimately1 – using that plus the combination of a DebugDiag dump I was able to isolate this down to a deadlock.

I didn’t have a meaningful stack trace for it because the deadlock occurred inside native CLR code, so I had to actually look at the public source for .NET 4.5 to realize that the issue was caused by an edge-case where a garbage collected Helios IFiber handle could accidentally make a BlockingCollection.CompleteAdding() call on the Fiber’s underlying TaskScheduler (possibly leaked to other Fibers) via the IFiber,Dispose() method which would gum up the works for any network connection using that Fiber to dispatch inbound or outbound requests.

Took a week to find that bug and a few hours to fix it. What a bitch.

Before I pushed any of those bits to master, however, I decided to run Visual Studio’s performance analysis toolset and test the impact of my changes – a mix of CPU performance and memory consumption testing. This revealed some interesting lessons…

Tradeoff #1: Outsourcing work to the OS vs. doing it yourself

First, the reason we had this performance issue to begin with: Helios is C# socket networking middleware designed for reacting quickly to large volumes of data. Inside a Helios networking client or a reactor developers have the opportunity to specify the level of concurrency used for processing requests for that particular connection or connection group – you can run all of your IO with maximum concurrency on top of the built-in thread pool OR you can use a group of dedicated threads for your IO. It was this latter type of Fiber that caused the problems we observed in production.

Why would you ever want to build and manage your own thread pool versus using the built-in one? I.E. manage the work yourself instead of outsourcing it to the OS?

In this case it’s so you can prevent the Helios IConnection object from saturating the general-purpose thread pool with thousands of parallel requests, possibly starving other parts of your application. Having a handful of dedicated threads working with the socket decreases the system’s overall multi-threading overhead (context-switching et al) and it also improves throughput by decreasing the amount of contention around the real bottleneck of the system: the I/O overhead of buffering messages onto or from the network.

In most of applications, outsourcing your work to the OS is the right thing to do. OS and built-in methods are performance-optimized, thoroughly tested, and usually more reliable than anything you’ll write yourself.

However framework and OS-designers are not all-seeing and don’t offer developers a built-in tool for every job. In the case of Helios, the .NET CLR’s general purpose thread-scheduling algorithm works by servicing Tasks in a FIFO queue and it doesn’t discriminate by request source. If a Helios reactor produces 1000x more parallel requests per second than the rest of your application, then your application is going to be waiting a long time for queued Helios requests (which can include network I/O) to finish. This might compromise the responsiveness of the system and create a bad experience for the developer.

You can try working around this problem by changing the priority of the threads scheduled from your application, but at that point you’ve already broken the rule of outsourcing your work to the OS – you’re now in control of scheduling decisions the moment you do that.

Taking the ball back from the OS isn’t a bad idea in cases where the built-in solution wasn’t designed for your use case, which you determine by looking under the hood and studying the OS implementation.

Another good example of “doing the work yourself” – buffer management, such as the IBufferManager implementation found in Jon Skeet’s MiscUtil library or Netty’s ByteBuffer allocators. The idea in this case: if you have an application that creates lots of byte arrays for stream or buffer I/O then you might be better off intelligently reusing existing buffers versus constantly allocating new ones.. The primary goal of this technique is to reduce pressure on the garbage collector (CPU-bound problem), which can become an issue particularly if your byte arrays are large.

Tradeoff #2: Asynchronous vs. Synchronous (Async != faster)

I have a love/hate relationship with the async keyword in C#; it is immensely useful in many situations and eliminates gobs of boilerplate callback spam.

However, I also hate it because async leads droves of .NET developers to believe that you can inherently make your application faster by wrapping a block of code inside a Task and slap an await / async keyword in front of it.2 Asynchronous code and increasing parallelism inside your application doesn’t inherently produce better results, and in fact it can often decrease the throughput of your application.

Parallelism and concurrency are tools that can improve the performance of your applications in specific contexts, not as a general rule of thumb. Have some work that you can perform while waiting for the result of an I/O-bound operation? Make the I/O call an asynchronous operation. Have some CPU-intensive work that you can distribute across multiple physical cores? Use N threads per core (where N is specific to your application.)

Using async / parallelism comes at a price in the form of system overhead, increased complexity (synchronization, inter-thread communication, coordination, interrupts, etc…) and lots of new classes of bugs and exceptions not found in vanilla applications. These tradeoffs are totally worth it in the right contexts.

In an age where parallelism is more readily accessible to developers it also becomes more frequently abused. And as a result: one of the optimizations worth considering is making your code fully synchronous in performance-critical sections. 

Here’s a simple example that I addressed today inside my fork of NStatsD which resulted in a 40% increase in speed.

This code pushes a UDP datagram to a StatsD server via a simple C# socket – the original code looked like this:

foreach (var stat in sampledData.Keys)
{
   var stringToSend = string.Format("{0}{1}:{2}", prefix, stat, sampledData[stat]);
   var sendData =  encoding.GetBytes(stringToSend);
   client.BeginSend(sendData, sendData.Length, callback, null);
}

The code here uses one of the UdpClient’s asynchronous methods for sending a UDP datagram over the wire – it takes this code about 2.7 seconds to transmit 100,000 messages to a StatsD server hosted on a VM on my development machine. Having done a lot of low-level .NET socket work with Helios, I’m suspicious when I see an asynchronous send operation on a socket. So I changed the call from BeginSend to just Send.

foreach (var stat in sampledData.Keys)
{
   var stringToSend = string.Format("{0}{1}:{2}", prefix, stat, sampledData[stat]);
   var sendData = Encoding.ASCII.GetBytes(stringToSend);
   client.Send(sendData, sendData.Length);
}

This code, using a fully synchronous send method, pushed 100,000 messages to the same StatsD server in 1.6 seconds – an improvement of 40%. The reason why? BeginSend operations force the OS to maintain some state, make a callback when the operation is finished, and release those resources after the callback has been made.

The Send operation doesn’t have any of this overhead – sure, it blocks the caller until all of the bytes are buffered onto the network, but there’s no context switching or caching objects to be included in the async state. You can validate this by looking at the .NET source code for sockets and compare the SendTo vs. BeginSendTo methods.

The point being: when you have thousands of write requests to a socket in a short period of time the real bottleneck is the socket itself. Concurrency isn’t going to magically make the socket write messages to the network more quickly.

Tradeoff #3: Memory vs. Throughput

I rewrote Helios’ DedicatedThreadFiber to use a BlockingCollection to dispatch pending work to a pool of dedicated worker threads instead of using a custom TaskFactory – a functionally equivalent but a mechanically significant change in how this Fiber’s asynchronous processing works. After making a significant change like this I test Helios under a heavy load using the TimeService example that ships with the Helios source.

Each TimeServiceClient instance can generate up to 3,000 requests per second and usually I’ll have 5-15 of them pound a single TimeServiceServer instance. On my first test run I noticed that the first TimeServiceClient instance’s memory usage shot up from about 8mb to 1.1GB in a span of 45 seconds. “Holy shit, how did I create such an awful memory leak?” I wondered.

Turns out that the issue wasn’t a memory leak at all – the TimeServiceClient could produce requests 2-3 orders of magnitude faster than its Fiber could process them (because, again, it was waiting on a socket), so the BlockingCollection backing the Fiber would grow out of control.

I decided to test something – if I capped the BlockingCollection’s maximum size and have it block the caller until space frees up, what would the impact on memory and performance be?

I capped the Fiber initially to 10,000 queued operations and I was surprised with the results – throughput of the system was the same as it was before but memory usage was only 5mb as opposed to 1.1GB. Sure, some of the callers would block while waiting for room to free up in the BlockingCollection but the system was still operating at effectively the same speed it was before: the maximum speed at which the outbound socket can push messages onto the network.

I made a choice to limit memory consumption at the expense of “on-paper” throughput, but it wasn’t much of a tradeoff at all.

Hopefully a theme is starting to emerge here: your system is only as fast as your slowest component, whether it’s the file system, the network, or whatever. Consuming all of your system’s memory in order to queue pending I/O socket requests faster doesn’t improve the speed of that slow component.

You’re better off blocking for a picosecond and conserving memory until that slow resource becomes available.

However, imagine if I had taken a different approach and decided to use more memory to group related socket messages in batches before we sent them over the socket. That might result in an improvement in total message throughput at the expense of increased memory consumption – I’d have to write some code to ensure that the receiver on the other end of the socket could break up the batched messages again, but there’s potential upside there.

Tradeoff #4: Heavyweight Resources vs. Lightweight Resources

Lightweight resources are primitives, structs, objects, and so forth. Heavyweight objects are threads, processes, synchronization mechanisms, files, sockets, etc… anything that is usually allocated with a resource handle or implements the IDisposable interface is a good candidate for a “heavyweight” object.

After I fixed the issue I described in tradeoff #3 – we had another memory-related performance problem inside our Executor object, used for executing operations inside a Fiber. When we terminate an Executor, we do it gracefully to give it some time to wrap up existing operations before we shutdown.

Helios offers two tools for “timed operations” – a lightweight Deadline class and a heavyweight ScheduledValue class. Both of these classes have the same goal: force some value to change after a fixed amount of time.

The Deadline class accomplishes this by comparing its “due time” with DateTime.UtcNow – if DateTime.UtcNow is greater than due time then the Deadline is considered “overdue” and starts evaluating to false.

The ScheduledValue is a generic class backed by a built-in .NET Timer object – you tell it to change its value from A to B after some amount of time, which the Timer does automatically once it elapses.

We use Deadlines most frequently inside Helios because they’re simple, immutable, and don’t pose any risk of a resource leak. Deadline is what we were using inside the Executor object’s graceful shutdown mechanism.

Every time a Fiber dequeues an operation for execution it checks the Executor.AcceptingJobs property (which is determined by the Executor’s internal DeadLine) – if this expression evaluates to false, the Fiber stops processing its queue and releases its threads. In other words, this property is evaluated hundreds of thousands of times per second – and as my performance profiling in Visual Studio revealed, generated a TON of GC pressure via all of its DateTime.UtcNow calls, which allocates a new DateTime structure every time.

I tried, in vain, to rewrite the Deadline to use a Stopwatch instead but wasn’t able to get reliable shutdown times with it. So I decided to use our heavyweight ScheduledValue class in lieu of Deadline – it uses a Timer under the hood but doesn’t allocate any memory or use any synchronization mechanisms when its value is polled.

This resulted in a significant drop in memory usage and garbage collection pressure for high-volume Fibers, and the ScheduledValue cleans up after itself nicely.

Even though the ScheduledValue requires more upfront resources than a Deadline, it was the superior performance tradeoff because it doesn’t have any additional overhead when its value is frequently polled by executing Fibers.

If the scenario was a little different and we had to allocate a large number of less-frequently polled objects, the Deadline would win because it wouldn’t require a large allocation of threads (used by the Timer) and heavyweight resources.

Wrapping Up

High-performance code isn’t black magic – in a general sense it comes down to the following:

  • Correctly identifying your bottlenecks;
  • Understanding the limitations and design considerations of built-in functions;
  • Identifying where work can effectively be broken into smaller parallelizable units; and
  • Making resource tradeoffs around those limitations, bottlenecks, and opportunities for beneficial parallelism.
    One thing I have not talked about is the cost of developer time vs. application performance, which is the most important resource of all. I’ll save that for another post, but as a general rule of thumb: “don’t performance-optimize code until it becomes a business requirement.”

1I open sourced our Akka.NET + StatsD integration into a NuGet package – Akka.Monitoring

2I complained about this habit before in “10 Reasons Why You’re Failing to Realize Your Potential as a Developer

If you enjoyed this post, make sure you subscribe to my RSS feed!



The Profound Weakness of the .NET OSS Ecosystem

July 3, 2014 13:58 by Aaronontheweb in .NET, Open Source // Tags: , , // Comments (39)

I’m in the process of writing up a lengthy set of blog posts for MarkedUp about the work that went into developing MarkedUp In-app Marketing, our real-time marketing automation and messaging solution for Windows desktop applications (and eventually WP8, WinRT, iOS, Android, Web, etc…)

During the course of bringing this product to market, I personally made the following OSS contributions:

    There’s more to come – I just finished a Murmur3 hash implementation this week (not yet OSS) and I’m starting work on a C# implementation of HyperLogLog. Both are essential ingredients to our future analytics projects at MarkedUp.

I really enjoy contributing to OSS, especially on Akka.NET. It’s a successful project thus far, attracting several strong contributors (Roger Alsing, the developer who originally started Akka.NET, is a genius and overall great person) and lots of support from big names in .NET like Don Syme and others.

But here’s the kicker – MarkedUp is a very small company; we’re operating a business that depends heavily on doing distributed computing in .NET; and I have lots of tight deadlines I have to hit in order to make sales happen.

I didn’t make any of these contributions because they made me feel all tingly and warm inside – I don’t have the free time for that any more, sadly. I did it because it was mission-critical to our business. So here’s my question: in the ~15 year history of .NET, no one built a reactive, server-side socket library that’s actively maintained? It’s 2014 for fuck’s sake.

Over the course of working on this product, I was constantly disappointed by a .NET OSS landscape littered with abandoned projects (looking at you, Kayak and Stact) and half-assed CodeProject articles that are more often factually wrong than not.

This week when I started work on HyperLogLog1 I fully expected that I was going to have to implement it myself. But I was incredulous when I couldn’t find a developer-friendly implementation of Murmur3 in C# already. The algorithm's been out for over three years – I could find a dozen decent implementations in Java / Scala and two barely-comprehensible implementations in C#, neither of which had an acceptable license for OSS anyway. I had an easier time porting the algorithm from the canonical C++ Murmur3 implementation than I did following the two C# examples I found online.

So I had to ask myself:

Do .NET developers really solve any hard problems?

We came to the conclusion early on that the right architecture for MarkedUp In-app Marketing depended on a successful implementation of the Actor model. We thought to ourselves “this is a programming model that was invented in the early 70s – surely there must be a decent actor framework in .NET we could leverage for this.”

We weren’t just wrong, we were fucking wrong. We found a graveyard of abandoned projects, some half-assed Microsoft Research projects that were totally unusable, and a bunch of conceptual blog posts. Nothing even remotely close to what we wanted: Akka, but for .NET.

So we spent two weeks evaluating migrating our entire back-end stack to Java – we already depend heavily on Cassandra and Hadoop, so being able to take advantage of 1st party drivers for Cassandra in particular really appealed to us. However, we decided that the cost of migrating everything over to the JVM would be too expensive – so we went with an slightly less expensive option: porting Akka to .NET ourselves.

Why in the hell did it fall on one developer working at a startup in LA and one independent developer in Sweden to port one of the major, major cornerstones of distributed computing to .NET? Where the hell was Project Orleans (released by Microsoft AFTER Akka.NET shipped) five years ago?

Did none of the large .NET shops with thousands of developers ever need a real-time distributed system before? Or how about a high-performance TCP socket server? No? What the hell is going on?

.NET is the tool of choice for solving rote, internal-facing, client-oriented problems

There’s a handful of genuinely innovative OSS projects developed by .NET programmers – and they largely deal with problems that are narrow in scope. Parsing JSON, mapping POCOs, dependency injection, et cetera.

The number of projects like MassTransit, i.e. projects that address distributed computing, are rare in .NET – I can’t even find a driver for Storm in C# (which should be easy, considering that it uses Thrift.)

The point I made four years ago this very day about why .NET adoption lags among startups is still true – .NET is the platform of choice for building line of business apps, not building customer-facing products and services. That’s reflected strongly in it’s OSS ecosystem.

Need a great TCP client for Windows Phone? Looks like there are plenty of those on NuGet. Or a framework for exporting SQL Server Reporting services to an internal website? A XAML framework for coalescing UI events? .NET OSS nails this.

The paramount technical challenge facing the majority of .NET developers today looks like building Web APIs that serve JSON over HTTP, judging from the BUILD 2014 sessions. Distributed computing, consistent hashing, high availability, data visualization, and reactive computing are concepts that a virtually absent from the any conversation around .NET.

And this is why we have a .NET OSS ecosystem that isn’t capable of building and maintaining a socket server library, despite being the most popular development platform on Earth for nearly 10 years2.

Compare this to the Java ecosystem: virtually every major .NET project is a port of something originally evented for the JVM. I’m looking at you, NAnt, NUnit, NuGet (Maven), NHibernate, Lucene.NET, Helios, Akka.NET, and so on.

You know what the difference is? There’s a huge population of Java developers who roll hard in the paint and build + open source hard shit. The population of people who do this in .NET is miniscule.

We are capable of so much more than this

The tragedy in all of this is that .NET is capable of so much more than the boring line of business apps Microsoft’s staked it’s business on and CRUD websites.

The shortcomings of .NET’s open source ecosystem are your fault and my fault, not Microsoft’s. Do not point the finger at them. Actually, maybe blame them for Windows Server’s consumer-app-hostile licensing model. That merits some blame.

But the truth is that it’s our own intellectual laziness that created a ghetto of our OSS ecosystem – who’s out there building a lightweight MMO in .NET? Minecraft did it with Java! How about a real-time messaging platform – no, not Jabbr. I mean something that connects millions of users, not dozens.

We don’t solve many hard problems – we build the same CRUD applications over and over again with the same SQL back-end, we don’t build innovative apps for Windows Phone or Windows 8, and there’s only a handful of kick-ass WPF developers out there building products for every day consumers. Looking at you, Paint.NET – keep up the good work.

Don’t make another shitty, character-free monstrosity of a Windows Phone application – no, it’s not“new” because you can write it using WinJS and TypeScript instead of C#.

Do something mind-blowing instead – use Storm to make a real-time recommendation app for solving the paradox of choice whenever I walk into a 7-11 and try to figure out what to eat.

There are brilliant developers like the Akka.NET contributors, the Mono team, Chris Patterson, and others who work on solving hard problems with .NET. YOU CAN BE ONE OF THEM.

You don’t need Ruby, Node.JS, or even Java to build amazing products. You can do it in .NET. Try a new way of thinking and use the Actor model in Akka.NET or use the EventBroker in Helios. Figure out how to fire up a Linux VM and give Cassandra or Storm or Redis a try. Learn to how work with raw byte streams and binary content. Learn how to work with raw video and audio streams.

The only way to clean up our acts and to make an ecosystem worth keeping is to stop treating our tools like shit shovels and start using them to lay alabaster and marble instead. .NET is more than capable of building scalable, performant, interesting, consumer-facing software – and it falls on us, individual and independent developers, to set the example.


1here’s the only known HyperLogLog implementation in C#, which appears factually correct but out of date and not production-usable

2no, not going to bother citing a source for this. Get over it.

If you enjoyed this post, make sure you subscribe to my RSS feed!



What Do You Need to Become an Elite Developer?

MarkedUp Analytics’s customers are developers and so are most of the people who work at the company, so I spend a lot of time thinking about and refining my answers to the following two questions:

  • What are the lowest common denominator skills and programming knowledge that my customers have?
  • What are the lowest common denominator skills and traits that the developers on my team need to have in order to best serve our customers?
    As I’ve been exposed to more customers and as I’ve turned over members of our team1 I’ve started refining my answers to these questions.
    Turns out that most of our customers are fairly sophisticated and thus I expect the developers on our team to be one step ahead of them.

I’m sure every company says this, but in our case it’s true: we need elite developers in order to solve our customer’s problems.

MarkedUp builds distributed systems that integrate into native third-party applications, written by our customers, on multiple platforms and use machine learning to create insights in as short a timeframe as possible, a task that’s many orders of magnitude more challenging than your average iPhone or web application.

There are companies like DataStax or Liquid Robotics that have to deal with radically harder problems than ours, and I’m amazed by their ability to attract really great engineering talent. So this problem is solvable, but how do I identify elite developers who are going to be able to contribute to the business and tackle these challenges?

I’m still figuring it out, and I’ve made some big mistakes along the way thus far. But I’ve had some successes in attracting great engineering talent to our company too. Here’s my opinion on what makes a software developer elite (your mileage may vary!)

Traits

An elite developer is determined more by their character, attitude, intellect, and diligence more than anything else. Knowing any specific framework, programming language, design pattern, development platform, and so forth isn’t nearly as relevant.

So what character traits does an elite developer have?

Humility – the best developers I’ve worked with know that they are talented but don’t know just how good they are relative to their peers. Even if they did know, it wouldn’t change their attitude. They do the best job that they can and do it knowing that their work isn’t perfect; contains bugs; might not completely meet the spec; and might be changed in the future.

Able to accept criticism – part and parcel with humility is the ability to accept criticism, whether it comes from a peer, a customer, a manager, or anyone else. Whenever you do anything of consequence you should expect criticism from some corner of the universe. Elite developers not only accept it, but they listen to it and try to distill actionable insights if possible.

Doesn’t let good be the enemy of perfect – a lot of talented developers struggle with perfectionism, myself included; over time the great ones learn to live with impurities and get software deployed to production while the perfectionists piss time away on remote edge cases and other activities with no economic value.

Inquisitive – some of our interview questions at MarkedUp are live-coding exercises, and here’s a little secret: we really don’t care very much about the quality of the code produced by a candidate during an interview.

But we care a lot about the questions a candidate asks about the programming challenge.

If a candidate starts coding right away without asking us any questions about the scope of the challenge or the technical details, it’s usually an instant fail. Inquisitive developers do a much better job of learning how their code fits inside a larger system and learning about the real-world use cases for it.

Independent learners – the developers who’ve delivered the most value for me are ones who constantly want to learn and improve their skill set; they ask if they can pair-program with me while I work on our API or on the SDK; independently review some of our code and create JIRA issues for me when they find bugs with my own code (!); they buy O’Reilly books on some of the technologies we use, like Hive and Hadoop, and read them over lunch; and they ask if they can leave work early to attend a tech talk or even give one themselves (!).

Everyone needs help along the way, but the truly great developers are the ones who learn for the sake of learning and the satisfaction of self-improvement. It’s humbling to work with this type of developer, because typically they get other members of the team excited about learning too and turn this into a group activity.

Able to break down large projects into small tasks – people don’t launch rockets or build massive systems by setting out to do everything all at once; they break down massive projects into smaller milestones and small, fine-grained tasks. Really strong developers have the ability to visualize the end in mind and the steps for getting there. It’s an essential skill for an architect of any sort.

Able to visualize relationships between abstractions – part and parcel with the previous point, really great developers have the ability to visualize relationships between abstractions in the systems they work with and build. This can be as simple as being able to see how services interact with each-other in the course of fulfilling an end-user’s request or how classes should be composed inside any given system. This allows a developer to work on a small part of a really large system and understand how their work will integrate with components that aren’t finished or haven’t been started yet.

Embraces challenges – great developers can operate outside their comfort zone, even if it means failing initially. Challenges are viewed as an opportunity to learn and improve, not as a threat to appearance and performance.

Focuses on immediate results – sticking with the previous analogy about launching rockets, great developers break up their work into small deliverables and ship small pieces immediately and frequently into a development branch. They don’t hoard commits or wait until “it’s done.” They ship small deliverables often.

Behaviors

The traits above are the most important ingredients of a great developer, but there are learned and acquired behaviors that every developer must develop before they can become elite.

Unconsciously, religiously commits everything source control – the greatest sin you can commit as a developer is failing to put something into source control for you deploy it. Most companies try to automate deployment in such a way that it’s impossible for deployment to occur without source control involvement, but this isn’t always feasible. Little things like shell scripts, SQL queries, configuration files, and others often fall between the cracks since they aren’t considered part of “the app.”

However, a great developer is religious in their use of source control – anything that gets used in the course of regular business, even a one-off business intelligence script, finds its way into source control when an elite developer is behind the wheel. They rack up pull requests and HipChat spam with religious fervor, because they live in perpetual fear of being the stupid asshole who forced someone else to reverse-engineer a critical backup / restore script during an emergency.

They master their source control system, make liberal use of feature branches and version tags, and clean up after themselves once a feature goes into production. Source control is as natural to them as breathing.

Writes README files, comments, and docs even for internal tools – I tell every developer this when they start at MarkedUp “your code will be a part of this organization longer than you will.” The point of that is that people change careers, companies, and jobs frequently – so when we write a piece of code that does something important, we need to make it possible for someone else to use and modify it without us present to answer questions.

Great developers recognize this and make it easy for other developers to leverage their work, during and after their time on the job.

Embraces bug tracking and agile processes – organizing your work is just as important as performing it, and bug tracking / agile tools like Pivotal Tracker and JIRA enable teams to prioritize and distribute workloads across large projects.

But more importantly, they allow PMs and peers to see what work has been completed / performed without having to hold numerous meetings or calls. Bug tracking, pull requests, and agile boards are communication tools – and great developers embrace them for efficacy in measuring, quantifying, and communicating progress.

Masters debugging, tracing, and monitoring methods – just because the code is in production doesn’t mean it’s finished. Great developers master the tools they use for debugging, logging, tracing, and monitoring apps that are in production or are about to be.

In the .NET universe, this means mastering the Visual Studio debugger, Fiddler, IntelliTrace, the Windows Event Viewer, performance counters, and others. In the OSS world this might mean performance monitoring tools like Graphite and Nagios, or others.

Great developers understand the necessity of these tools and master them, which enables them to respond more quickly to infrastructure failures and bugs.

Communicates concisely and asks relevant questions – most developers are not social butterflies; like any STEM field, it’s often populated with introverted people who like to spend most of their working hours concentrating on issues at-hand.

However, the elite developers are ones who recognize what needs and doesn’t need to be communicated – if there’s something contradictory in a customer spec, it needs to be raised with the stakeholder. If someone broke convention and used camel case instead of PASCAL, just go fix it and send the offender a note, not the entire team alias.

Engages other developers on the team – programming is a team sport, and elite developers love working with other people whom they can help and who can help them. They ask for and solicit help when necessary.

Programming Skills

Now for the programming part – what skills does a programmer need to have before he or she can be considered elite? This is subjective and sometimes domain-specific, but there’s my take.

Experience with multiple languages and platforms – diverse taste in tools is the greatest skill that a developer can have, because it keeps the developer on a position where they know how to learn new things if necessary (and it often is!)

Being a one-trick pony and limiting yourself to a single platform will naturally limit your ability to grow and learn, so great developers try their hands at new things even if it’s just for fun.

Understands language / framework implementations – the most powerful .NET developers I met prior to joining Microsoft all highly recommended that I read this book: CLR via C#. I did, and the content from this book was directly responsible for passing my technical interview at Microsoft. Above that, it’s changed the way I look at all of my .NET code.

Understanding your how code is executed at the OS or hardware level can provide some huge benefits, especially if you’re doing a lot of work with concurrency or native programming. For instance, understanding how SQL Server’s row / table locking algorithms and its journaling system work allow you to design around potential performance bottlenecks in high-performance systems. Great developers learn these implementation details and leverage that knowledge to write more robust code.

Writes code for patterns, not specific instances – it’s an intuitive skill that can’t really be learned, in my opinion. You either have it or you don’t. Really talented developers infer the patterns in a system, even before a module or a piece of code is written and they code for those patterns, rather than specific instances. This skill limits technical debt and results in a tighter, more usable codebase.

Knows how to learn – this might seem obvious, but I’ll reiterate: there are a lot of developers who simply do not know how to learn something new. They can ape examples they’ve seen before and often need to be hand-held along the way, and they can’t truly internalize a new concept and form the muscle memory to code independently with new technologies.

Great developers know their mind and know how to teach it something new – what works for one developer may not work for another, but nonetheless they all know how ot learn.

Has experience with multiple types of software (native, distributed, web, etc…) – a great developer is a well-rounded developer; if your only experience doing software development is with simple CRUD applications, then you’re missing out on a lot of the corpus of modern software development. A great developer isn’t necessarily an adept professional in each domain area of programming – they might focus primarily on web development and dabble in native, but they take away new lessons from each experience and understand more about computing overall.

Until I wrote the MarkedUp SDK, I never had any practical experience with advanced data structures in production like concurrent binary heaps and circular buffers; I likely would never have encountered those had I stuck to doing just ASP.NET MVC or Node.JS development all the time. Now that I have that experience, who knows – I might find some applications for those in a distributed program or a Web API application in the future.

Experience with multiple types of development tools (IDEs, Text Editors, command line compilers, and more) – I have some bad news: if you’re an EMACS ONLY or VS2012 ONLY developer, you’re limiting yourself. Experience with multiple types of development tools is a good thing, because great developers recognize that improving your workflow habits over time is just as important as improving your programming knowledge and experience.

The right tool for the job will often be different – Visual Studio, for instance, is a fantastic tool for when I’m debugging C# or C++ but I much prefer Google Chrome developer tools and Fiddler for debugging JavaScript.

Some sysadmin / operational knowledge – writing the code is only the first step; deploying it or releasing it comes next. Great developers are not often expert system administrators also, but they know enough about their operating environment to avoid pitfalls and execute a basic deployment if necessary.

Knowing how to run a build / release process, deploy a piece of server software to production, or how to configure a piece of COTS software like Apache or IIS to host a web application is critical to ensuring that the software actually meets its functional requirements. If you aren’t able to produce a development build of a native app using compiler flags, then you can’t very well participate in that part of the QA process, can you?

The point is – great developers don’t wait for someone else to solve their problems; they can do enough sysadmin work to build and test on their local environment, and are self-aware enough to not proceed any further if they don’t know enough to run a live deployment.


1developer turnover is a natural and expected byproduct of growth in a technology company, I’ve come to learn. Don’t let anyone tell you otherwise.

If you enjoyed this post, make sure you subscribe to my RSS feed!



How to Use Dependency Injection (Ninject) with WCF Services

August 16, 2011 15:32 by Aaronontheweb in .NET, WCF // Tags: , // Comments (1)

I spent a lot of time late last week trying to figure out exactly how to set up dependency injection for a WCF service I was developing on Windows Azure; there’s some documentation out there on how to do it, but it’s not nearly as helpful as I would like it. Thus I decided to document how I made WCF and Ninject play nice with each other, and I even provide a sample template you can use yourself.

Step 1 – Install Ninject.Extensions.WCF via NuGet

The developers who maintain Ninject were kind enough to put together a set of extensions for working with WCF applications specifically, and we can install this via NuGet (install it from CodePlex.)

Simply type this into the “package manager console” in Visual Studio: install-package Ninject.Extensions.Wcf

image

This will automatically grab the appropriate version of Ninject and the other binaries you’ll need to get the WCF ServiceHost to play nice with your service.

Step 2 – Write Your Own Ninject Module

The next step is to set up your dependency injections by writing your own NinjectModule like this:

using Ninject.Modules;

namespace wcf_ninject.DI
{
    public class WCFNinjectModule : NinjectModule
    {
        public override void Load()
        {
            //Injects the constructors of all DI-ed objects 
            //with a LinqToSQL implementation of IRepository
            Bind<IRepository>().To<LinqToSQLRepository>();
        }
    }
}

Step 3 – Add the “Factory” Attribute to Service1.svc

The next thing you need to do is tell the service host to use the Ninject Factory to instantiate the WCF service by way of a custom ServiceHostFactory included in the Ninject WCF Extensions.

To do this, right click on the “Service1.svc” file (or whatever you name your service) and select the “View Markup” option:

image

Once there, simply add this line:

Before

 

<%@ ServiceHost 
    Language="C#" 
    Debug="true" 
    Service="wcf_ninject.Service1" 
    CodeBehind="Service1.svc.cs" %>

After

<%@ ServiceHost 
    Language="C#" 
    Debug="true" 
    Service="wcf_ninject.Service1" 
    CodeBehind="Service1.svc.cs"
    Factory="Ninject.Extensions.Wcf.NinjectServiceHostFactory" %>

Step 4 – Add Global.asax Make It Inherit from NinjectWcfApplication

The final step is to add a Global.asax file to your WCF project and make it inherit from the NinjectWcfApplication class, like this:

public class Global : NinjectWcfApplication

In order for this code to compile, you’ll need to add a “CreateKernel” method to Global.asax – this method is what utilizes your Ninject module and uses it to inject dependencies into your WCF service. Here’s what that code looks like for this example:

protected override IKernel CreateKernel()
{
    return new StandardKernel(new WCFNinjectModule());
}

Now there’s just one last step…

Step 5 – Remove the Default Constructor from Your WCF Service; Have Dependency-Accepting Constructor Instead

Your final constructor in this example should look something like this:

 

 public Service1(IRepository repository)
{
    _repo = repository;
}

Get rid of any default constructors (ones that don’t accept arguments) – Ninject will raise an error if it finds one in the signature of your class as of writing this.

Grab the WCF + Ninject Visual Studio 2010 Project off of Github

You can download the Visual Studio 2010 project that contains this WCF + Ninject sample off of Github if you want to use it as a starting point.

If you enjoyed this post, make sure you subscribe to my RSS feed!



How to Securely Verify and Validate Image Uploads in ASP.NET and ASP.NET MVC

One of the more interesting things I had to do as part of building XAPFest was handle bulk image uploads for screenshots for applications and user / app icons. Most of the challenges here are UI-centric ones (which I resolved using jQuery File-Upload) but the one security challenge that remains outstanding is ensuring that the content uploaded to your servers is safe for your users to consume.

Fortunately this problem isn't too hard to solve and doesn't require much code in C#.

Flawed Approaches to Verifying Image Uploads

Here's what I usually see when developers try to allow only web-friendly image uploads:

  1. File extension validation (i.e. only allow images with .png, .jp[e]g, and .gif to be uploaded) and
  2. MIME type validation.

So what's wrong with these techniques? The issue is that both the file extension and MIME type can be spoofed, so there's no guarantee that a determined hacker might not take a js. file, slap an extra .png extension somewhere in the mix and spoof the MIME type.

Stronger Approach to Verifying Image Uploads: GDI+ Format Checking

Every file format has to follow a particular codec / byte order convention in order to be read and executed by software. This is as true for proprietary formats like .pptx as it is for .png and .gif.

You can use these codecs to your advantage and quickly tell if a file is really what it says it is - you quickly check the contents of the file against the supported formats' codecs to see if the content fits into any of those specifications.

Luckily GDI+ (System.Drawing.Imaging), the graphics engine which powers Windows, has some super-simple functions we can use to perform this validation. Here's a bit of source you can use to validate a file against PNG, JPEG, and GIF formats:

using System.Drawing.Imaging;
using System.IO;
using System.Drawing;

namespace XAPFest.Providers.Security
{
    /// 
    /// Utility class used to validate the contents of uploaded files
    /// 
    public static class FileUploadValidator
    {
        public static bool FileIsWebFriendlyImage(Stream stream)
        {
            try
            {
                //Read an image from the stream...
                var i = Image.FromStream(stream);

                //Move the pointer back to the beginning of the stream
                stream.Seek(0, SeekOrigin.Begin);

                if (ImageFormat.Jpeg.Equals(i.RawFormat))
                    return true;
                return ImageFormat.Png.Equals(i.RawFormat) 
|| ImageFormat.Gif.Equals(i.RawFormat);
            }
            catch
            {
                return false;
            }
        }

    }
}

All this code does is read the Stream object returned for each posted file into an Image object, and then verifies that the Image supports one of three supported codecs1.

This source code has not been tested by security experts, so use it at your own risk.

If you have any questions about how this code works or want to learn more, please drop me a line in the comments below or on Twitter.

Bonus: How Do I Make Sure Files Are below [X] Filesize?

Since I had this source code lying around anyway, I thought I would share it: 

public static bool FileIsWebFriendlyImage(Stream stream, long size)
        {
            return stream.Length <= size && FileIsWebFriendlyImage(stream);
        }
    }

Super-simple, like I said, but it gets the job done. Express the maximum allowable size as a long and compare it against the length of the stream

 


1The other important catch to note here is that I move the Stream's pointer back to the front of the stream, so it can be read again by the caller which passed the reference to this function.

If you enjoyed this post, make sure you subscribe to my RSS feed!



How I Built CaptainObvio.us

Captain Obvio.us - a place to share ideasI made a tiny splash on Hacker News a month ago when I asked for feedback on my newest side project, CaptainObvio.us – a simple portal for sharing ideas and soliciting feedback from a community of peers. The idea was popular and I’ve received a ton of feedback – I’ve implemented most of the Hacker News community’s suggestions but haven’t had the chance to do another round of customer development.

What I wanted to share in this blog post was some of the secret sauce I used for creating CaptainObvio.us – I originally created it mostly to learn MongoDB, and learned way more than that along the way.

Webstack: ASP.NET MVC3 on AppHarbor

I used ASP.NET MVC3 as my webstack of choice with AppHarbor as my hosting platform. ASP.NET MVC3 is a massive improvement over MVC2, and I took advantage of Razor syntax, the built-in support for DI (dependency injection) on controllers, and wrote a number of customized helpers to do things like create an action filter for Twitter @Anywhere.

AppHarbor has been a great experience to work with - I use Git for souce control for most of my personal projects like this one so deployments are a breeze on AppHarbor, but the other major reason I picked AppHarbor is that it shares the same Amazon AWS datacenter as MongoHQ - another [Thing]-as-a-Service that I used for hosting my MongoDB instance.

Data: MongoDB on MongoHQ

The original purpose of CaptainObvio.us was for me to learn MongoDB, a schemaless (NoSQL) document database written in C++ that is becoming all the rage in the Ruby on Rails universe. CaptainObvio.us is a good fit for Mongo given that the vast majority of its content consists of simple documents with a small amount of relational data for tying authors to ideas / comments and so forth.

I could not have gotten very far with MongoDB in C# were it not for the NoRM Project MongoDB drivers for C# - NoRM's drivers are much better than the default MongoDB drivers for C# and work similarly to LINQ-to-SQL (although not exactly.) It was a matter of hours for me to go from installing Mongo to having a functional site running with NoRM and ASP.NET MVC3.

Authentication: Originally Twitter @Anywhere; Sign-in-with-Twitter and Hammock Later

Twitter @Anywhere is a fairly new JavaScript-only framework for integrating Twitter into existing websites quickly and effortlessly - it automates all of the OAuth workflow, comes with tons of useful built-in widgets, and eliminates the need to write much (if any) plumbing needed to support Twitter integration.

This is all nice in theory but if you're building a site like CaptainObvious where your users use Twitter to sign-in and leave behind persistent data in your own data store, then this framework can really cause problems. I had to gut Twitter @Anywhere eventually because the post-authentication event hook would misfire on occasion due to issues on the client and thus I would have an "authorized" user running around adding comments and voting despite no record of them existing in the database.

In order to resolve the issue, I dumped Twitter @Anywhere and went with traditional Sign-in-with-Twitter powered by Hammock, which works fine.

Final Thoughts

I'm going to continue working on CaptainObvio.us, although I put it off largely due to all of the work I had to do engineering XAPFest's online presence on Windows Azure. If the project taught me anything, it's the value of continuous integration environments like AppHarbor and the ease with which you can get something up and running quickly with MongoDB.

I'd highly recommend checking out AppHarbor, MongoHQ, and the NoRM drivers if you're a .NET developer who's new to Mongo and wants to learn how to use it. I guarantee you that you'll appreciate traditional .NET databases like SQL Server 2008 and SQL Azure a lot better after you've worked with Mongo, as it'll help you learn the strengths and weakness of each respesctive platform.

If you enjoyed this post, make sure you subscribe to my RSS feed!



How to Create a Twitter @Anywhere ActionFilter in ASP.NET MVC

My newest project, Captain Obvious, got a fair amount of attention this week when it landed on the front page of Hacker News – one of the key features that makes the first version of Captain Obvious tick is Twitter @Anywhere integration.

Twitter @Anywhere is brand new and there isn’t much developer documentation for it – the way to think about Twitter @Anywhere is as a Javascript platform that allows you to outsource user authentication and registration to Twitter’s servers, and in exchange you get less hassle but also less intimate access to your user’s accounts.

One of the key features to integrating Twitter @Anywhere users with your ASP.NET MVC site is reading the cookie that Twitter sets after users have authenticated – this cookie contains two parts:

  1. The Twitter user’s unique ID, an integer representing their unique account (because remember – Twitter users can change their handles!)
  2. A SHA1 hash of the Twitter user’s unique ID + your application’s consumer secret – you use this to verify that the cookie was set by Twitter, since they’re the only ones who know your consumer secret other than you.

Naturally, if you are going to use this cookie as your authentication mechanism, then you are going to need to write your own Authorize attribute that allows you to validate the content’s of the Twitter @Anywhere cookie. Here’s the source code I use for doing that:

 

ValidTwitterAnywhereAttribute

/// <summary>
    /// Controller Action Filter Attribute which requires that
    /// </summary>
    public class ValidTwitterAnywhereAttribute : AuthorizeAttribute
    {
        protected override bool AuthorizeCore(HttpContextBase httpContext)
        {
            var twitterCookieValue = httpContext.Request.Cookies["twitter_anywhere_identity"];
            var consumerSecret = ConfigurationManager.AppSettings["TwitterConsumerSecret"];

            return TwitterAuthHelper.ValidateTwitterCookie(twitterCookieValue, consumerSecret);
        }
    }

 

Here’s the relevant source code from the TwitterAuthHelper that I use to actually validate the hash in the cookie:

TwitterAuthHelper

 

 public static bool VerifyTwitterUser(string twitterCookieValue, string ConsumerSecret)
        {
            var results = twitterCookieValue.Split(':');
            var sha1 = new SHA1CryptoServiceProvider();
            var hash = BitConverter.ToString(sha1.ComputeHash(Encoding.UTF8.GetBytes(results[0] + ConsumerSecret)))
                        .ToLower().Replace("-", "");
            if (hash.Equals(results[1]))
                return true;


            return false;
        }

I’m using this code in production and it works great – all you have to do to use it is decorate your controller methods with the [ValidTwitterAnywhere] attribute and it will behave just like Forms authentication if you have that enabled in your ASP.NET MVC app.

If you enjoyed this post, make sure you subscribe to my RSS feed!



How to Make Any Operation Asynchronous in .NET

I’m in the middle of writing some updates to Quick and Dirty Feed Parser for use in a new personal project of mine; namely, I need to make QD Feed Parser work asynchronously so I can use it in conjunction with asynchronous controllers in ASP.NET MVC3, and eventually Silverlight + Windows Phone 7.

Asynchronous network IO is a breeze in every version of .NET since 1.1 – WebRequest and many others have supported asynchronous methods for as long as I’ve been using them. However, asynchronous disk IO, which I need to support in QD Feed Parser, is not something that comes so easily in .NET 4.0 and below.

StreamReader is the most user-friendly tool for reading files off of local disk because you don’t have to manage any buffers or do any of the sort of accounting that a class like FileStream requires1. Here’s how nice and easy life is using StreamReader, using actual code from QD Feed Parser as an example:

protected static FeedTuple DownloadXmlFromUri(Uri feeduri)
{
    string xmlContent;
    using (var reader = new StreamReader(feeduri.LocalPath))
    {
        xmlContent = reader.ReadToEnd();
    }

    return new FeedTuple{FeedContent = xmlContent, FeedUri = feeduri};
}

Given that StreamReader doesn’t have any built-in methods for making this asynchronous, what’s the best way to do this, given that the  async and await keywords coming down the pipe in .NET 5.0 aren’t fully available yet? The answer is: we’re going to wrap our disc IO operations using delegates.

Out of the box delegates have both a BeginInvoke and EndInvoke methods, which behave like any other standard asynchronous method call and you, the developer get to decide what functions are invoked on the background thread.

Here are the steps:

1. Create a delegate and a static worker method

protected delegate FeedTuple BackGroundWorker(Uri feeduri);

protected static FeedTuple DownloadXmlFromUri(Uri feeduri)
{
    string xmlContent;
    using (var reader = new StreamReader(feeduri.LocalPath))
    {
        xmlContent = reader.ReadToEnd();
    }

    return new FeedTuple { FeedContent = xmlContent, FeedUri = feeduri };
}

The delegate and the static worker method need to have the same signatures.

2. Define your own Begin[Operation] and End[Operation] methods

For Quick and Dirty Feed Parser, here is what I created, minus some integrity checks in order to make the code more readable:

public override IAsyncResult BeginDownloadXml(Uri feeduri, AsyncCallback callback)
{
    return FeedWorkerDelegate.BeginInvoke(feeduri, callback, 
		new FeedTuple());

}

public override FeedTuple EndDownloadXml(IAsyncResult asyncResult)
{
    var result = FeedWorkerDelegate.EndInvoke(asyncResult);
    return result;
}

Your begin method should return the IAsyncResult from your delegate – this way your caller can pass the asynchronous result back to the End[Operation] method and return your result. You can also use the IAsyncResult’s WaitHandle to put a block a calling thread if you wanted.

When dealing with delegates you have to be careful with your accounting – for every BeginInvoke there should be exactly one EndInvoke.

3. Calling the asynchronous methods

Here’s a quick unit test I wrote for testing this method in Quick and Dirty Feed Parser.

[Test, TestCaseSource("TestCases")]
public void CanDownloadXmlStreamAsync(string rsslocation)
{
    var feeduri = new Uri(rsslocation);
    var result = Factory.BeginDownloadXml(feeduri, null);
    var resultantTuple = Factory.EndDownloadXml(result);

    Assert.IsNotNull(resultantTuple);
    Assert.That(resultantTuple.FeedContent != String.Empty);
    Assert.AreEqual(feeduri, resultantTuple.FeedUri);
}

You should note that I’m effectively blocking the calling thread until the asynchronous worker thread returns a result in this method, and that’s because it’s easier to write unit tests this way.

The best practice for taking advantage of asynchronous method calls is to utilize a callback function, which you can do like so:

public void DownloadXmlStreamAsync(string rsslocation)
{
    var feeduri = new Uri(rsslocation);
    var result = Factory.BeginDownloadXml(feeduri, async => 
	{
		var callbackTuple = Factory.EndDownloadXml(async);
		Dispatcher.BeginInvoke(() => { 
		//... Do some client-side stuff with the data...		
		});
	});
}

And that’s it!


1It should be noted that FileStream does support asynchronous operations out of the box, but they’re a pain in the ass to use due to the reasons I just described.

If you enjoyed this post, make sure you subscribe to my RSS feed!



How-To: Remote Validation in ASP.NET MVC3

ASP.NET MVC3 has been a major boon to my productivity as a web developer since I started using it at the beginning of November – the new Razor view engine has been attracting most of the attention with this iteration of MVC, but one extremely sexy feature has gone unnoticed thus far: Remote validation.

Remote validation was one of the new features added in the November Release Candidate (RC) for MVC3 – I had a chance to demo it in front of the LA .NET User Group last night and it was a monster hit.

Example:

You’ve all seen remote validation before – ever see one of these when you’re signing up for a service like Twitter?

image

That’s remote validation at work. Twitter, Facebook et al make an AJAX call to a remote service hook that checks the database to see if the username is available as the user types it. It’s a major user experience improvement as they get that feedback instantly instead of having to wait until after they fill out the rest of the form and submit it.

In the past with ASP.NET MVC you had to write your own custom jQuery scripts on top of the jQuery validation engine to achieve this end-result; in ASP.NET MVC3 this is taken care of for you automatically!

Let me show you how it works:

1. Decorate a model class with the Remote attribute

Take the class you want to validate and decorate the attributes you need to remotely validate with the Remote attribute.

public class NewUser
{
	[Remote("UserNameExists", "Account", "Username is already taken.")]
	public string UserName { get; set; }

	[Remote("EmailExists", "Account", "An account with this email address already exists.")]
	public string EmailAddress { get; set; }

	public string Password { get; set; }
}

In both of these instances of the Remote attribute, I’ve passed the following arguments:

  • The name of an action method;
  • The name of the controller where the action method lives; and
  • A default error message should user input fail this validation challenge.

2. Implement an action method to support your Remote attribute

You will need to implement an action method that supports your Remote attribute. Add an action method which returns a JsonResult to the controller you named in your Remote attribute arguments. In this example I’ll need to add these action methods to the “Account” controller:

public JsonResult UserNameExists(string username)
{
    var user = _repository.GetUserByName(username.Trim());
    return user == null ? 
		Json(true, JsonRequestBehavior.AllowGet) : 
		Json(string.Format("{0} is not available.", username),
			JsonRequestBehavior.AllowGet);
}

public JsonResult EmailExists(string emailaddress)
{
    var user = _repository.GetUserByEmail(emailaddress.Trim());
    return user == null ?
		Json(true, JsonRequestBehavior.AllowGet) : 
		Json(
			string.Format("an account for address {0} already exists.",
			emailaddress), JsonRequestBehavior.AllowGet);
}

 

If the repository returns null, meaning that a user account with this particular user name or email address doesn’t already exist, then we simply return a JsonResult with a value of true and go off on our merry way. This will suppress the jQuery validation library from raising a validation error.

If the action method returns false, then jQuery will raise a validation error and display the default error message provided in the Remote attribute arguments – if you didn’t provide a default error message yourself then the system will use an ambiguous default one.

If the action method returns a string, jQuery will raise a validation error and display the contents of the string, which is what I’m doing here in this example.

Small Gotcha – Naming Action Method Parameters

There’s one small gotcha that can be easy to miss – the name of the argument on your action method must match the name of your property on your model. If I changed the EmailExists body to look like this:

public JsonResult EmailExists(string email);

Then ASP.NET would pass a null value to this method.

Case 1: parameter name matches the name of the model’s property

image

Case 2: parameter name does not match the name of the model’s property

image

This is because the jQuery parameter takes the name of the property on the model and passes it as a querystring argument to your action method – here’s what your validation request looks like in Firebug:

[host]/account/emailexists?area=an%20account%20with%20this%20email%20address%20already%20exists.&EmailAddress=test%40test.com

The ASP.NET MVC model-binder isn’t all-knowing – it’s not going to be able to tell that EmailAddress and email are the same thing, thus it ultimately won’t bind an argument to your action method, hence why the null value is passed.

If you follow the convention of using a common name for your Remote validator action method arguments and your model properties, you won’t run into this issue.

UPDATE: Thanks to Rick Anderson for directing me to the much more extensive MSDN documentation on how to implement custom Remote validaiton in ASP.NET MVC3.

If you enjoyed this post, make sure you subscribe to my RSS feed!



Search

About

My name is Aaron, I'm an entrepreneur and a .NET developer who develops web, cloud, and mobile applications.

I left Microsoft recently to start my own company, MarkedUp - we provide analytics for desktop developers, focusing initially on Windows 8 developers.

You can find me on Twitter or on Github!

Recent Comments

Comment RSS

Sign in