Petrol burned while sitting in a queue for an hour with the engine running: £2.00
Money lost by missing two hours of your minimum wage job: £12:16
Three and a half litres of petrol: £4:89
The look on your stupid, ovine face when you drive by the next day and there’s no queue at all: Priceless.
static class CacheEx { /// <summary> /// Disables caching. /// </summary>
/// <remarks>This method may also be used to destroy Romulan warships.</remarks> public static void EjectWarpCore(this HttpCachePolicy cachePolicy) { cachePolicy.SetNoServerCaching(); cachePolicy.SetCacheability(HttpCacheability.NoCache); cachePolicy.SetNoStore(); cachePolicy.SetExpires(DateTime.MinValue); cachePolicy.SetProxyMaxAge(TimeSpan.FromMilliseconds(0)); } }
Another step on the way to 1.0!
So now you can have transactions in Simple.Data, like this:
var db = Database.Open();
using (var tx = db.BeginTransaction())
{
try
{
var order = tx.Orders.Insert(CustomerId: 1, OrderDate: DateTime.Today);
tx.OrderItems.Insert(OrderId: order.OrderId, ItemId: 1, Quantity: 1);
tx.Commit();
}
catch
{
tx.Rollback();
throw;
}
}
Tested on SQL Server 2008.
Github: http://j.mp/SDcommits
“There’s a time when the operation of the machine becomes so odious—makes you so sick at heart—that you can’t take part. You can’t even passively take part. And you’ve got to put your bodies upon the gears and upon the wheels, upon the levers, upon all the apparatus, and you’ve got to make it stop. And you’ve got to indicate to the people who run it, to the people who own it that unless you’re free, the machine will be prevented from working at all.”
“The world is like a ride at an amusement park, and when you choose to go on it you think it’s real, because that’s how powerful our minds are. And the ride goes up and down and round and round; it has thrills and chills and it’s very brightly colored and it’s very loud and it’s fun, for a while.
Some people have been on the ride for a long time, and they begin to question: is this real, or is this just a ride? And other people have remembered, and they come back to us, and they say, “Hey, don’t worry, don’t be afraid, ever, because, this is just a ride.”
And we kill those people.
“Shut him up. We have a lot invested in this ride! Shut him up! Look at my furrows of worry… look at my big bank account… and my family… this has to be real.”
It’s just a ride.
But we always kill those good guys who try and tell us that, you ever notice that? And let the demons run amok…
But it doesn’t matter because: it’s just a ride. And we can change it anytime we want. It’s only a choice. No effort, no work, no job, no savings and money; a choice, right now, between fear and love.
The eyes of fear want you to put bigger locks on your doors, buy guns, close yourself off. The eyes of love, instead, see all of us as one.
Here’s what we can do to change the world, right now, to a better ride: take all that money that we spend on weapons and defence each year and instead spend it feeding and clothing and educating the poor of the world, which it would, many times over, not one human being excluded, and we could explore space, together, inner and outer, forever, in peace.
”
Having spent a week at Disney World, I’ve been reminded that the best way to have a happy life is to learn to be happy with here and now, rather than constantly looking for something just around the corner. And, because I’m a hopeless geek developer, I got to thinking about how that applies to software. And what I think is: if you set out to build the all-singing, all-dancing solution, and don’t call it done until you’ve implemented every last feature, then you’ll never be done and you’ll never be happy. But if you build something that scratches an itch, and start using it, and then make it better a bit at a time, you’ll have a series of little successes and be done lots of times, and you’ll feel happier and more fulfilled because of that.
I was surprised to see somebody on Twitter saying they didn’t really get what package managers such as NuPack and OpenWrap are for, and why there’s so much fuss about them at the moment. To me, these things are long overdue and I wonder how the .NET world has come so far without them. But then, I’ve also been using Ruby for a couple of years now, and, like all Ruby developers, take the Gem package management facility ingrained in that ecosystem entirely for granted.
So, anyway, I thought I’d try and explain, in more than 140 characters, why package managers are a good thing, and why everybody should be excited that the .NET world is getting them at last.
Convenience
In Ruby, if I want to parse some XML, I can gem install nokogiri, require it in my code, and that’s it. If I want to use a particular database, I can just install the gem for it. Web frameworks, web servers, testing frameworks, ORMs, Twitter/Facebook/OAuth APIs, pretty much anything you can think of and, to paraphrase: There’s a gem for that. Some of them include native code, and the gem manager takes care of compiling that code for whichever platform you’re installing on. Won’t it be cool to be able to do that for ELMAH, or NUnit, or Moq?
Dependencies
In the open source world, people stand on the shoulders of giants. Or at least, other people. If you’re writing a package which needs to parse HTML, you add a dependency to an HTML-parsing package, rather than writing your own from scratch. Package managers take care of those dependencies, including which version of an external package is required to make the package you want work properly. In Ruby, if you install the MongoMapper gem, it will automatically install the versions of the mongo and bson gems that it needs. And it can cope with having multiple versions of the same gem installed, too. The .NET package managers will do this, too, so if you install something which needs Castle.Windsor, it’ll just find it and install it for you.
Distribution
It’s amazing just how many gems there are for Ruby. I’ve written a couple. I’m not even sure they’d be particularly useful to anybody else, I just pushed them up so I could install them from other machines if I need them. If anybody else wants to use them, then great.
The very fact of the gem package manager means that people are more likely to create libraries, or just extract little bits of usefulness from their application and publish them as packages, because it’s not such a performance. It’s as easy as creating a Class Library project in Visual Studio, and just saying to yourself “other people might like this. I’ll publish it as a package.” So you do.
Discoverability
This is another aspect of the above. When there is a recognised system of distribution, it is easier to get a project noticed and used. The Extensions Manager in VS2010 has led to a wider audience for lots of useful extensions, and has inspired more people to create their own extensions because they know there’s a place where they can be found, downloaded, installed automatically, updated automatically, and maybe used by thousands of people. In effect, these new package managers are like a Marketplace or App Store for .NET libraries. And that’s awesome.
In summary, then
So yes, you might be able to download a zip file with the latest version of NHibernate in it, and extract it and add references to it and check all the assemblies into your source control system along with your solution. But how much easier would it be to just add a package reference, and click Build? And to know that another developer who gets your source from TFS or SVN or Github or Bitbucket or Codeplex doesn’t have to worry about whether you remembered to check out those assemblies so that they got updated when you checked back in again; now, when they click Build, the package manager will just find and install the necessary versions of the necessary libraries. That’s the magic. And if you’re still not convinced, try it for a couple of projects, then come back and tell me you don’t need it.
I’m working on an MVC project at the moment, and using Simple.Data for the data access layer. I need to test the controllers in a BDD kind of way, which is always difficult with database dependencies.
I recently added an Adapter model to Simple.Data, which provides an easy way to add support for different data stores. So I decided to knock together a very simple basic adapter which can do reads from XML using LINQ queries. Took about 15 minutes, including tests.
Now, I can inject a Simple.Data.Database instance into whichever DAL classes are needed to run a given test, pre-loaded with an XML adapter initialized from a string in the test code. The tests run happily from this stub, and in production the real database is accessed using exactly the same Simple.Data code.
Proper blog post with code samples soon!
Earlier, I was twittering about HTML5, and in particular Javascript, not being properly obfuscatable in the way that the bytecode used by browser plug-ins like Silverlight or Flash is obfuscatable. One of the advantages to obfuscation that I mentioned was the ability to encrypt strings in client applications, including URLs, keys, passwords, tokens etc. @Grumpydev suggested that hard-coding passwords into client-side code was an offence punishable by shooting, to which I replied “So how do you secure comms between client and server?”
I feel that this comment needs clarification.
Obviously, the best way to keep security keys and similar safe and secure is not to distribute them in any way. But there are plenty of situations where you want the client portion of your application to communicate with the server portion of your application in a secure way, not to prevent third-parties from intercepting the communication, but to prevent horrible little ne’er-do-wells from sending their own requests to your server.
If your application is written in Javascript, it’s very easy for anybody to extract the AJAX URLs from the code, regardless of what’s been done to it. You can’t really obfuscate Javascript, because it’s interpreted; the thing that’s running it has to be able to read the source code. And once somebody has extracted the URLs from your script, it’s very easy for them to inject their own script into pages served from your domain, using Greasemonkey or other such tools, with the result that they can gaily hit your service with whatever data they like.
If, on the other hand, your application has been compiled to bytecode, then it can obfuscated by an application like SmartAssembly (for Silverlight) or secureSWF (for Flash). These tools do awful, terrible things to the bytecode which are still perfectly valid from the runtime’s point of view, but which have no representation in C# or ActionScript. They also move all the strings in the application into a resource table, and then they encrypt it.
Of course, you can get the URLs that an application is requesting without going anywhere near the code. You just have to load up Fiddler and sniff the HTTP traffic. Or the HTTPS traffic, which it will do quite happily using a man-in-the-middle approach.
And so, finally, to my point: given that anybody can see how your application talks to its services, how can you stop them from talking to your services themselves? That’s where you need some sort of secured key or token which can initiate an authentic, encrypted conversation between your application and your web service.
And that’s where Javascript can’t help you. If you disagree, please feel free to implement some form of online gambling system in HTML 5; I’ll come and take your money when you’re done.
Just a very rough idea of how a massively simplified data access wrapper for .NET using dynamic language features might look:
<body>
<%
var db = Database.Open();
var person = db["People"].FindByNameAndPostcode("Mark", "SW1");
%>
<h1><%= person.Name %> - <%= person.Postcode %></h1>
</body>
Database gets connection info from config.
String indexer on Database returns a DynamicTable object.
Query SQL is dynamically generated from the name of the FindBy method, and uses parameters to protect against SQL injection.
(I have the code that does this working.)
