Seedy Fake Data

With fake user authenication done, we had everything we needed to generate fake data.

The seed data was generated on every deployment to our dev and demo environments - which gave us nice, clean, predictable demos, and our dev server was never a terrible mess of temporary data (yeah, you know what I’m talking about).

Seedy Fake Users

Ever been on a project where a dev comes on board, and has to clone databases in order to get test data? What about when you just want to nuke all your test data and start afresh - is starting afresh pretty painful?

We went whole-hog on seed data and test user generation recently, found it to be incredibly useful, and will be doing it on future projects.

This post covers the fake user creation aspect.

Put your operations on your client

In the last post, I showed how we put our server DTOs into our client code, to ensure changes in our data structures didn’t silently fail. In this post, I’ll show you how we protected ourselves against changing API endpoints.

Put your server types on your client

A recent gig I was involved in relied fairly heavily on code generation in order to make our client/server communications type safe.

We were using TypeScript so a lot of our safety could be guaranteed at compile time - as long as the types were on the client. Since we’re fallibe, and computers like doing things repetitively, we used some codegen to do this for us.

Our goals?

  • Generate DTOs for all models (and dependants) going to/from API controllers
  • For all enums in the models, create a way to get names, values and descriptions
  • Avoid TypeScript’s any keyword, which breaks this whole approach
Chaining Expressions in C#

More and more I’ve been using projections to handle the query side of my applications, which of course includes a lot of Expression objects.

The problem with Expression objects is they’re non-trivial to chain together and combine, because they’re data structures, not code.

I recently had to implement a simple report filter that had optional date ranges on 4 different date fields - each with an optional From and To date. Of course, there were other requirements of this feature, too, which makes it a bit more interesting:

  • Run the whole query in SQL - I don’t want to materialize my enumerable to perform the filtering
  • Somewhat simple SQL query - of course I can be clever with GroupBy and SelectMany, but I’d prefer my SQL to just say WHERE date <= @p0 if possible.
  • Clean code - DRY, reusable, terse et. al.