Friday, 24 January 2014

css :nth-child pseudo class

example

<div id="holder">
<h2>Heading</h2>
<div class="item">This is even</div>
<div class="item">This is odd</div>
</div>
.item:nth-child(even) {
   background-color:yellow;
}
result

Heading

this is even
this is odd
why?
:nth-child relates to all children of the parent element, not just those with class ".item", so this is saying every ".item" that is an even child of it's parent.
If you're using class selectors, easiest solution is to create a wrapper for the elements that you're targeting, as nth-of-type only works with elements selectors.

Monday, 3 October 2011

Functional Fun with Python

Built in currying:

>>> from functools import  partial 
>>> binary = partial (int, base=2)
>>> binary('000001')
1
>>> binary('000011')
3
>>> binary('001011')
11

Wednesday, 2 June 2010

The state information is invalid for this page and might be corrupted

This is a nice gotcha for load balanced ASP.NET sites:
If you have a dynamically compiled ASP.NET website, and you put objects from a dynamic part into the ViewState, you'll be in for a NASTY surprise when you move to a load-balanced scenario.
Basically, you'll occasionally get exceptions with the message "The state information is invalid for this page and might be corrupted" as the compiled types on the different servers are different.
Either:
  • Move the types you put into ViewState into a compiled assembly (dll for old-schoolers ), or,
  • Only use primitive types (int, byte, string, char, etc) in the ViewState. Enums do not count as primitive types.

Friday, 15 January 2010

Another reason to use log4net rather than rolling your own logging framework

Exception during StringFormat: Index (zero based) must be greater than or equal to zero and less than the size of the argument list. Served {0} coupons out of {1} for {3}{296366, 100, Campaign{id#891e4cb2-da21-456b-bb5e-38cfbf9a90db}}

Wednesday, 16 December 2009

Google Visualisations API

I set up an example of using the Google Visualisations API at
http://swampstaging.co.uk/uk_singles_chart.html

The process for generating this was:
Scrape code from website (ruby+hpricot)
Process code for google's datatable (ruby)

It was a neat way to learn stuff about ruby. programming without a modern IDE is a PITA. i'd forgotten how great resharper+visual studio is. mostly resharper.

Monday, 5 October 2009

jQuery code to cycle background colors


<script type="text/javascript">
//<![CDATA[
$(function() {
$body = $(document.body);
var colours = ["#007777", "#777700", "#777777", "#770077"];
var currentColour = 0;
var fade = function() {
$body.animate({ backgroundColor: colours[currentColour % colours.length]}, 127000, fade);
currentColour++;
};
fade();
});
//]]>
<script>

Thursday, 15 January 2009

ViewModel - the missing link?

With ASP.NET MVC getting all the press now-a-days (well, in my tiny part of the web anyway), it's difficult to (a) not feel jealous if you're still stuck on .Net 2.0, and (b) wonder who's employer let's them used stuff that's still in beta for live websites.

However, whilst ASP.NET MVC/FubuMVC/MyMumsMVC provides a framework, and gives you more opportunity to get things right, there's still a missing piece of the puzzle that makes it all fit together.

Consider the lilly of the field.

If you modelled this, it would probably have a Field property.
Your view can probably handle a FieldId, but it shouldn't really know about a Field property. (Having the View access lilly.Field.Id breaks the Law Of Demeter (or, "Two Dots And You're Out"), and your whole SOLID Principals may as well be thrown out with the trash).

In one project we did, we got around this problem by having our Domain Model classes expose this kind of thing. It get messy really quickly, and really quickly pollutes your Domain Model classes with lots of methods and properties that are only ever used for display. Then they start getting used for business decisions, and pretty soon the project is one big code smell.

So, how else might we go about this?

Two patterns that might give us clues are the Facade Pattern and the Adapter Pattern. Go look 'em up. And, whilst you're at it, go look up the Data Transfer Object in your copy of Patterns of Enterprise Application Architecture. (Yeah, get it out from propping up your monitor, wipe off the dust off (a damp cloth is ok on the coated cover) DTO ison page 401).

So, you get the grasp of taking a bunch of objects (it's called an Object Graph if you're Martin Fowler) and converting it into something else for another purpose. When it's used in the context of aiding and abetting the communications between the Controller and the View (The C and the V in MVC), it's called a ViewModel (people how come up with these clever names are too busy to type a space it seems).

And it's great. Your ViewModel may include a LillyDescription class, which has properties like FieldId and FieldName, but, and here's the important thing, it doesn't have any non-primitive members (i.e. you're limited to strings, numbers and dates). Also, keep any logic out of them. If it wouldn't be universally frown upon, I'd say just use plain old Fields on the ViewModel classes (but that's heresy, so forget I ever said that) .

So now, you've got your controller converting between your Domain Model (used by your Business Logic) and your View Model (used my your view). STOP. Your controllers are not meant to do this. Your controllers are meant to control, not convert. Your SOLID Principals are under attack - your "too cool for school" badge will be ripped off your programmer's blazer, and you'll be asked to hand in your gun and your badge. The ALT.NET gang will ex-communicate you, and you'll loose all your profile points on StackOverflow.com.

So we need something else to assemble the ViewModel objects from the Domain Model objects. Go create another class (or even a Service!) to do this. Unit test the hell out of it - it's a purely programmatical problem, so Unit Testing is easy. Ensure that the ViewModel object has the right set of stuff from the Domain Model, and that it doesn't/does break stuff.

There - wire up your IoC container with the IViewModelLillyConverterService and it's implementation, and you're good to go. (i.e. expect the Yellow Screen of Death a few times).

There's a lot of stuff here. I'm still not entirely sure where the line is between all the parts. Although it seems like it'll create an explosion of classes, it really does simplify things. More code is normally worse, but I'd argue that this is more of a Refactoring (yeah, dubious I know).

Go and play with this idea. See if you can make your view utterly independant of your Domain Model. Go on. Go completely over the top. Then, maybe, you'll get a feel for it.

kick it on DotNetKicks.com