Sharepoint Hacks - field visibility

I've had a few people trying to use the replacement New/Edit list form hack I posted a  week or  two ago, and struggling to get the correct set of fields to display so I've written a couple of followup wiki entries:


Hopefully these will prove useful for anyone trying to make use of these hacks, and provide enough hints to implement something functional with the code snippets.
Read More

Architecture Chat 20

A good turnout this week, with I believe 8 or so attendee's, and some great discussions.

So let's get into it...

First off while everyone was arriving Keith talked about his recent experiences with F#, including the implementation of the classic TDD "bowling game" exercise - which he's been blogging about lately, I myself have bitten by the F# bug and have been grappling with getting my head around the concepts in the language this weekend - it's a lot of fun, especially pattern matching and pulling apart the type system - but I've got a few more "ah hah" moments to go through before I've grokked it I think... Considering this language is going to be mainstreamed into the VisualStudio.Net product, and it's suitability for building parsers (among other things) I definitely think this is a skill worth adding to the toolbox.

From F# Keith then talked about his tangent into non-Von Neumann programming languages, and in particular Function-level programming, which works at a higher level then functional languages, suited to working with array-level information i.e. matrices - allowing for variable-free development (Tacit programming) it lets you do some pretty amazing things.

The function-level language that Keith took a look at was "J" (an APL-like language) which is cryptic - just like APL (at least to the uninitiated) but incredibly powerful i.e. a tacit implementation of the quicksort algorithm looks like this:

quicksort=: (($:@(<#[) ,="" (="#[)" ,="" $:@(="">#[)) ({~ ?@#)) ^: (1<>

Yes, no variables, and one line of code! Compared to the C# equivalent which is normally 12 to 20 lines long, depending on braces etc.

Keith highlighted some good points - in that it actually becomes very readable once you understand how the language is put together, and it certainly shouldn't be discounted before your attempted to understand just what it is your discounting - I guess the message here is don't be a blub programmer.

I actually wonder wether working at this higher level actually makes the barrier of understanding what's going on lower in many cases - for instance, no variables = no mental state you have to keep in your head as you look at the code... I suspect long-term it would probably take less time to understand what this one line of code is doing, then reading through 20 to 30 lines of C# code, with variables, recursions/loops state and scope - especially with a set of unit tests to back it up, providing the specification and aiding in understanding what's expected/happening in your snippet of J code.

And of course, function-level programming is well suited to parallelization and optimization, more so then value-level or functional languages - a popular topic among the group.

After that a little discussion was had around SSIS, ETL tools etc. - largely caused by a protagonist (who shall remain nameless ;o) stirring up some trouble in the dot.net.nz Sql mailing list this week - the net effect is that there are largely disparate views between many of the senior DBA/Dev community at the coal face vs. Microsoft, marketing etc. To quote the message:

"SSIS is a dog, great for BA's, but otherwise is always seems to fall short!".

Everyone basically agreed with this statement - SSIS just doesn't provide a good experience for developers and admins, take a look at Ayende's list on his wiki if you want a bit of a (depressing) laugh at the common pain points for developers.

As much as Microsoft employees reiterate that SSIS "is not a dog" - the reality is drawing pretty pictures with a sub-par UI is not productive for a developer, and the end results are notoriously brittle and hard to collaborate with other developers on.

On the flip side, we discussed alternatives i.e. cutting your own code, windows services, emerging tools like Rhino ETL - which a few of us like, but just can't justify dropping into a clients infrastructure at this point because it's a bit of a unknown quantity and quite immature - a bitter pill for a Microsoft-only organisation to swallow, because it's not necessarily mort-friendly at this stage.

After that we had the discussion about the IKVM.Net, boojay and grasshopper java <-> .net technologies - there still doesn't seem to be a silver bullet here for solving the problems of developing in .Net with the BCL etc. and then having it just "work" in the JVM on a Linux virtual machine, suitable for dropping into say the Amazon elastic cloud (EC2) - the more reasonable approach seems to be developing in java and then targeting either .Net or the native JVM, or developing in vanilla C, on a side note  I spent some time evangelizing about the boo language, and more importantly it's great extensible parser/compiler experience which makes it so very easy to write template engines and DSL's with it.  I'm still not 100% sure why mono doesn't work well in this case, but by experience a few have had a lot of trouble getting it work properly.

A short warning and Rant was had about Flash 8 (Action Script 2) by Peter - believe it or not, it doesn't have native support for 64 bit integers ... I haven't got time to verify it, but I'm assuming it's probably because it represents all numbers as double-precision floating point values. Grim tidings!

Following that we had a discussion around Framework development - this is a topic that's cropped up a number of times, so I won’t go too heavily into it... but basically it focused around a few discussion points:

  • Building applications with re-use in mind, and in fact building frameworks/factories for producing the application i.e. spend 80% or more of your time building the framework, and 20% of your time implementing the project with the framework, with the view of reusing/re-purposing the framework "next time".
  • It was argued that building frameworks is often YAGNI.
  • Why are parts of software you’re developing not naturally reusable?
    • Largely because development practices aren't focusing on composability and enforcing the principle of single responsibility.
    • Test driven design encourages Composability.
    • Without an IoC container it may be a little challenging at times.


  • Frameworks often require additional skills to maintain.
    • Is there a risk in letting Junior/Intermediate resource make changes?
    • Does the difficulty in finding/retaining senior resource make frameworks risky?




Lastly, we touched on other subjects - but my memory is a little hazy on the details:
  • The challenges in Porting data binding from WinForms to WPF when upgrading an application.
  • Brief thoughts on the features in Lightspeed 1.1, I like the aggregate-level validation support - something I forgot to mention was that the source code is available with the enterprise edition, which is great news - and that Ivan Towlson has joined the Mindscape team, you can see his first blog post here.
  • The Xero revenue announcement - a lot of us have either worked / started startups in the past, or are in still in the process of "starting up" - so it hardly came as a surprise that progress is slow... I think Nic Wise had it about right in this post - this led onto a discussion about the nature of the banking market, competing products, white boxing etc.
  • The fact that expression web is pretty sweet, and that there is still a load of html-only work out there.


At any rate, see everyone in 2 weeks time (29th of this month) - and thanks all for coming along, it's encouraging to see the numbers climbing back up after the Alex James exodus (btw, he has an msdn blog now, for anyone who missed the announcement).
Read More

2007-11-13 - Upcoming Architecture Chat

Yep, that time again, the 20th Architecture chat will be held this thursday, 11:30am at the Sylvia Park in Auckland (at Garrisons), all are welcome to come along.

Some topics (off the top of my head) this week include:

  • Java & .Net (didn't make it in last week)
    • The IKVM project (Java VM implemented in .Net)


  • ORM Love
    • NHibernate 2.0 features/maturation (and yes, it looks like the Castle trunk will be moving to it, hurray!)
    • Lightspeed 1.1 has been released.
    • Experiences of writing a Linq to query parser.


  • VS2008 very close
    • But ReSharper for C# 3.0 a while off.
    • Tempted by TeamSystem just to get the in-line "annotate" functionality.




And if anyone else has suggestions, feel free to throw me a comment/email etc. - obviously a bit topic light at the moment.

See you all Thursday!

Read More

Thoughts on CAML.Net

So first off... for those who don't know SharePoint...  CAML is a bit of swiss army knife... if you understand it, can stand it, and know where to stick it you can pull off some interesting and useful results with SharePoint... I'm no expert however, having only touched it for querying and tweaking it here and there for some custom views. Though I think I can confidently say CAML is a wonderful example of XML Abuse :)

At any rate, one aspect of CAML is being able to write CAML queries to query data sources i.e. SharePoint Lists.... I'm against constructing strings for querying data sources, because they're ugly - and difficult to mutate with code, so I decided to give CAML.Net a try (and ended up using it, albeit reluctantly) - here's an example query in CAML:

    My Content Type      

And then in CAML.Net - at first glance it looks ok:
Console.WriteLine(CAML.Where( CAML.Or( CAML.Eq( CAML.FieldRef("ContentType"), CAML.Value("My Content Type")), CAML.IsNull( CAML.FieldRef("Description")))));

But of course then you look a little closer and see that CAML.Where, CAML.Or, CAML.Eq etc. all return strings... so your not actually building a model of your query - which to me immediately removes a large part of the value for this solution.

Looking around the blog-sphere I see lots of people using CAML.Net, and yet nobody seems to have a problem with the way it works?... it puzzles me... At any rate.. let's dive into why I don't like this approach... with another example:

Console.WriteLine(CAML.Where( CAML.Or( CAML.Eq( CAML.FieldRef("Title"), CAML.Value("My Title")), CAML.Or( CAML.Eq( CAML.FieldRef("ContentType"), CAML.Value("My Content Type")), CAML.IsNull( CAML.FieldRef("Description"))))));

And here's the CAML for that:
    My Title     My Content Type       

Notice the Or inside an Or... this is direct feedback from the CAML query language itself - notably that you can't construct a query with multiple root-level criteria, so your left to construct a tree of Or and And's as required to represent your query - which is ugly, and ultimately confusing - it doesn't express intent well... So my first problem with the CAML.Net approach is it makes me aware of the problems in CAML, when they could've been abstracted away for me... now let's look at a reasonably dynamic CAML query.
string title = "My Title"; string contentType = "My Content Type"; List orFragments = new List(); if (!string.IsNullOrEmpty(title)) { orFragments.Add(CAML.Eq( CAML.FieldRef("Title"), CAML.Value(title))); } if (!string.IsNullOrEmpty(contentType)) { orFragments.Add(CAML.Eq( CAML.FieldRef("ContentType"), CAML.Value(contentType))); } orFragments.Add(CAML.IsNull(CAML.FieldRef("Description"))); string query = CAML.Where( OrCamlRange(orFragments.ToArray()));

And suddenly I'm forced into a world of pain - having to manage the various criteria myself, and strings no less - in this case I'm only using Or's - so I can use a little function to stitch everything into a valid query:
private static string OrCamlRange(string[] items) { if ((items == null) || (items.Length < 1))="" throw="" new="" argumentnullexception("items");="" if="" (items.length="=" 1)="" return="" items[0];="" string[]="" remainingitems="new" string[items.length="" -="" 1];="" array.copy(items,="" 1,="" remainingitems,="" 0,="" remainingitems.length);="" return="" caml.or(items[0],="" orcamlrange(remainingitems));="">

But I can't help feeling that an opportunity for CAML.Net to really shine has been tarnished by an initial design choice of returning strings, instead of models.  At least for my use cases, I would've been much happier with something that returned a model which I could post-parse - to smarten up the experience so I could identify misspelled fields, mutate the query based on user choices etc.

Finally, just to be clear - this is not a dig at John Holliday - CAML.Net's author, he's a smart guy who knows a lot more then I ever will about SharePoint!  It's merely an opinion/observation on the negatives of query building approaches which don't embrace an intermediate model which can be parsed or mutated.

Read More

Trung Nguyên Coffee


So I rediscovered my Vietnamese coffee dripper today... and a small cache of Trung Nguy?n coffee I had secreted away after getting back from my Asian excursion a while ago... a little dubious as to whether it would have stood the test of time I brewed a test batch...

And had completely forgotten just how strong it is... yikes - I've been on caffeine buzz for the last hour or so ... it has such a distinctive flavor too... took me straight back to sitting in 35 degree heat, drinking extremely strong coffee mixed with ice cubes and condensed milk in the Vietnamese jungle... (it was a lot more fun then it sounds, though the sweetened condensed milk is a bit too sweet for my liking)

So at any rate - I'm starting to unwind after an incredibly busy period of work - think 16+ hour days for a couple of months ... which has left me a little shattered to say the least... so I'm unwinding a little today...  The lawns are mowed, the sun is
shining and I've started to read  Beautiful Code - which I've heard mixed reviews of, but I
figure it'd be a nice change from SharePoint blogs and should hopefully put me in the right frame of mind as a shift my focus back to projects revolving around ALT.Net technologies once again.

Read More