With some luck, and some free time, I will get to the second-prize scenario presented here: a library much like this one will work under ASP MVC vNext without fragile reflection hacks and low-level workings. This is based on discussion here. Continue reading...
I have released a new version of the ASP Mvc RouteTester, numbered 1.3.0, with builds for ASP MVC 5.1 and ASP MVC 5.2.
Now, a little bit about the project's status, origins and future.
I have an update on our experience with using Nancy for web APIs. Since I last wrote in part two we have made a couple of changes which make the code simpler.
Firstly we removed the HttpException class. It turned out to be an antipattern.
The enduring problem with passwords, in the way that we are asked to use them, runs deep:
Each login on each website should be given a unique password. It should not be simple. It should not be repeated on another site. It should not be written down. Repeat this across all websites, i.e. for somewhere between 20 and 100 websites.
This is not humanly possible; not even close. Memorising that many unique passwords is asking a champion feat of memory from average people as a casual by-product of living in the 21st century. It is the advice given, and it simply cannot be followed. Something has to give, and it does.
To carry on from Part one about patterns of web services in Nancy, we have a functional approach, but I'll start with an easy refactoring about modules:
I wanted to write a bit about c# and HTTP and some patterns of code in NancyFx to tie them together. This is informed by some of the things that I’ve been doing at work at 7digital. The lessons that I have learned are due to 7digital, but the faults and opinions in this post are mine.
The goal in a lot of our coding is to integrate small services over HTTP into an Api. We use a few different web frameworks, including NancyFx. The main things that we want from Nancy and other web frameworks are:
After fixing the issues mentioned in part 1, there are three passwords that I have to remember:
To log onto my home computers.
To log onto my work computers.
To unlock the password manager on those machines that contains all the other passwords. And there are over 100 of those.
Logging into a website or other computer system using a user name and password is in principle a reasonable way to do things. But we are supposed to follow these rules:
Do not to write down a password, just remember it.
Passwords all have minimum length and complexity requirements. A longer, more complex password is more secure, all other things being equal.
Use a different password on each site.
There aren't many comments visible on this site. I delete over 90% of the comments that come to this blog, because they look obviously spammy. Continue reading...
I like gadgets, cameras included. When the Contour +2 was announced, this seemed like a pretty nice gadget. A small but high-quality and rugged video camera with GPS, with good specs, USB and bluetooth. I could wear it while cycling. I would use it for snowboarding. I could even strap it to a top hat. The looks of it are IMHO much nicer than those boxy GoPro devices.
But without lots of spare money and without a pressing need for one, I didn't rush out and buy one as soon as it came out (more than a month ago now). I just kept an eye on the reviews.
The latest release of Nunit (version 2.6.2) supports tests with the type declaration public async void. I talked about wanting this behaviour in in my blog post about how NUnit was not handling public async void tests. I submitted a bug report and the good people of the NUnit project quite quickly had a go at it.
I tried again today with NUnit version 2.6.2. I took the code from the previous tests, and updated to the 2.6.2 version of the NUnit Nuget package.
I read about the Diaspora project recently.
I always had mixed feelings about it. I was sure that it was both a very good idea, and that it was very unlikely to get anywhere.
Windows server 2012, with the latest version of Microsoft's web server platform, Internet Information Services, is now out. Congratulations! But I have two related questions from the perspective of an ASP.NET MVC web developer.
Both of them are approaches to the question "why should I prefer IIS8 over IIS7".
What would you do if you wanted to use a website, had to make a login, and then ran up against rules that prevent you from using a secure password? For instance, a maximum length of 10 characters, and those chosen from letters and numbers only? Part of the problem with password rules is that everyone does these "eye of newt" rules slightly differently for no good reason, but far worse is when what is mandatory in one place (e.g. "password must contain a non-alphanumeric character") is forbidden elsewhere. Continue reading...
Further to my last blog post about async and await with NUnit, its worth noting that there is a trick to using async and await in a console application. The async reaches the top of the code that you write - i.e. the Main method you have a problem since the method signature is different to what the framework needs.
Who uses console apps anyway? Console apps are the simplest kind of app that produces output, so you see them in technology demos among other things. Sooner or later you will see async demonstrated in a console app. But this code doesn't work:
This is just a beware note. The Net 4.5 async … await feature doesn't work well yet with NUnit. Update: It works fine in the latest version.
The thing about async is that it bubbles up the call stack, as long as you care about return values. If you await the result of a call, then that method is async and must be awaited in turn. At some point this must either meet a point where you either have no return value, or you reach the top of the code that you wrote and you meet framework code. In ASP MVC 4 this happens when you meet an asynchronous controller method and the framework handles the return value, which can now be a Task.But what happens when testing with NUnit? NUnit tests will assert on return values, so they may have to await them.
The Github for windows app is out today. I have installed it on a machine or two.
I like github's social coding model. Quite a bit. I'm even working on learning the commands needed to use some of the real power of the underlying git source control system.
When github for mac came out a while back, I was puzzled – what need did this app fill? Weren't mac users already well served by the github website and existing git clients. A native app might make sense if the website was rubbish, but it's not. The github website is top-notch. And if it was rubbish, wouldn't fixing that be the priority? That migyht benefit all users.
Remember this code? You probably don't.
procedure TForm1.Button1Click(Sender: TObject);
// code goes here, maybe read a file
It's the code that handles the click of a button on a form in Borland Delphi, which was one of the best way to make windows programs in the mid and late 1990s. The main problem with the "code goes here" part is what code, how much code, and how do you organise it as it grows. Managing complexity is the usual problem in coding. If there are several buttons, do they call common methods or is it cut-and-pasted? (we quickly learned that this wasn't the best idea ever).
My blog post on multiple returns and why they are actually quite useful has a small but enduring popularity (some of it negative) among those who obsess over minutia. Yes, that includes me sometimes.
For instance this blog post, which argues for single returns, with an example where a single return is better.