Ignoring properties when serialising to Json

This afternoon I was figuring out an interface for a service and I was trying to establish a nice way of exposing an object as a Json parameter in .Net. The object I wanted to work with is a standard .Net class, however it has properties that I didn’t want to confuse the user with so I needed to somehow hide those properties when serialising the object. Here’s the method I used;

I am using Json.Net to do all my Json work – its really simple to serialise, deserialise a class – for example the class I’m working with is the SyndicationLink class, to serialise this class I can simply do this:

var json = JsonConvert.SerializeObject(new SyndicationLink());

The output would look something like this:

{
  "SyndicationLink": {
    "AttributeExtensions": {},
    "BaseUri": null,
    "ElementExtensions": [],
    "Length": 0,
    "MediaType": null,
    "RelationshipType": null,
    "Title": null,
    "Uri": null
  },
}

That’s all cool, but I don’t really want my interface object to so closely relate to the underlying implementation, it would be nicer if I could rename the object and hide a few of the properties which I won’t expose. Json.Net provides an attribute called JsonIgnore – which you can use to decorate a property, when using the JsonIgnore attribute the property will be ignored when deserialising the object. Ok that’s just what I need, but I also want to make use of the standard .Net class – so how can I do this?

 public class Link: SyndicationLink
 {
     [JsonIgnore]
     public new Dictionary<System.Xml.XmlQualifiedName, string> AttributeExtensions { get; set; }
 
     [JsonIgnore]
     public new SyndicationElementExtensionCollection ElementExtensions { get; set; }
}

Firstly I inherit the .Net class, hiding the properties which I don’t want to be seen by using the ‘new’ keyword when declaring identical properties in my wrapper class. I now have the ability to add the JsonIgnore attribute to my new properties. This results in a cleaner Json object when serialised:

var json = JsonConvert.SerializeObject(new Link());

{
  "Link": {
    "BaseUri": null,
    "Length": 0,
    "MediaType": null,
    "RelationshipType": null,
    "Title": null,
    "Uri": null
  },
}

When my service receives this object it can simply de-serialise it:

Link myLink = JsonConvert.DeserializeObject<Link >(JsonString);

I can now work directly with the .Net class without any serious heavy lifting needed to convert the object in and out of the service.

Forgive me Father for I have sinned.

Software products are attractive. Developing a successful software product can reap benefits. If you’re running your own business, selling services or somebody else’s products,  software of your own may well be attractive. After all, once you have the software succeeding in the market you’re more independent and potentially making a good margin once you’ve recouped your  initial development costs. If you’re a software developer or someone who’s remotely interested in software development then engineering that killer product may well be on your todo list – there is after all something deeply satisfying about seeing your own work succeed.

This is what I thought about a year ago – drawn in by the allure of products, dare I say it – the glamour. Then I woke up and sniffed the bacon.

So what happened?

Well it all began with naivety, idealism and vanity. I’d done ok in the services world, had a good run of projects under my belt and was feeling confident I had what it took to take on a software product. The role was ill defined, sniffed of danger and had a chequered past, but my bollocks told me otherwise and I decided to give it a shot.  Very quickly I discovered some of the perils of software product development and I thought I’d share these with you:

Strategy

I hate the term strategy – I think people like saying it without understanding what it really means (especially men, with furrowed brows and ill fitting suits).  What I mean here is when it comes to product development have some sort of plan and follow it through. It’s impossible without a plan, you need to know where you want to go otherwise your product is in danger of becoming bloated. Without forming a strategy your default plan may turn into one driven purely by demand, without restraint. With this bloat comes complication, technical debt and confusion, unless well marshalled (See People below..)

That said, I wouldn’t want to drown a software product in a strategy. I would want something to lean back on, check decisions against and use as a guide to help me. If a product strategy revolves solely around profit then I think this is a problem. If a software product grows without a strategy then it very quickly becomes a tangled mess difficult to understand and control – like an unruly teenager who’s hell bent on sticking two fingers up at you. I spent a great deal of time staying up late, waiting for the teenage years to finish only to be disappointed.

Keep it real

Great products and brands have very little veneer. What you see is what you get, when the brochure is produced before the first line of code is written – there’s a problem. Brand has value, but the bottom line is it can be very quickly eroded if the product is weak. Sales companies aren’t necessarily great product companies (and vice versa perhaps) – pushing boxes is easier than building them. Developing a product takes commitment beyond paying the wage bill – you and your team need to have an appetite and a passion for it. Customer loyalty, support and trust are much more valuable than short term sales figures. It’s about achieving a balance between product integrity and long term growth.

Listen

Your strategy dictates your audience. Who is it that you want to sell your software to? If these two things don’t align then you can have  problems – your product strategy (if it exists at all) may be targeting a certain audience, whereas your customer base is actually another – and in between is nothing but a sea of problems. Your customers have an expectation of you and your software - surprisingly this expectation isn’t always about when the next feature will be added, sometimes your customers want to know that your product has a plan. They want to know it’s in safe hands.

People

People make software products, its very simple. Make an effort in understanding what makes a software product team tick and you’ll have a fighting chance. When a team matures under good guidance and leadership the software can mature too. When a team is shaken about and constrained then the software tends to  follow. I learnt a great deal about the effect of implementing an agile methodology on a team who had very little experience of agile, however this is not the only way to gain the best out of a software development team, and in some ways it’s much harder to implement this type of methodology in a team and product which has strayed off the path.

Where did it end?

It’s hard to measure the experience, but I felt an overwhelming sense of dissatisfaction that I wasn’t succeeding so I grew up and got out. Done.

Simon

GeoCoder

This post is inspired in part by Eric Wolf’s comments on the recent NoGIS post by Sean Gorman.

Whilst I’m not going to pretend to truly appreciate what’s pythonic or not I agree with Eric’s comments and have my own twopence to contribute to the conversation. You may ask:

“What qualifies you to talk to these matters, you mouthy Northern….?”

Well I’ve spent about 10 years working as a pseudo geographer\software developer. I say pseudo because I’m really neither of these things. I am ‘qualified’ as a human geographer (I know, I know), and I’ve been known to write some software, but like many people I meet in GIS, I am here entirely by accident. In my case the accident was a prolonged binge drink fueled university rampage. Anyway my point is that I staddle both camps, I have been a shit software engineer in my time and an even worse geographer, but I’ve also done some things in code that I’m proud of and on occasion I’ve been capable of placing space in the centre of things.

Eric states:

“To me, the nature of noGIS is people who’ve learned enough computer science to realize that the Goodchild/ESRI model is fundamentally flawed. Instead of teaching programming in the Geography Department, someone should be teaching a little Geography in Computer Science Departments.”

I couldn’t agree more, and here’s why. I’ve seen some car crash software developed under the banner of GIS and much of it rolled out by Geographers pretending to be software engineers. Now that’s not to say there aren’t great software engineers out there who are hardcore GIS people too, but I’d like to share some of what I think are some of the common traits of a ‘GeoCoder‘.

1. Reach for code….all the time

Some of the first code I came across was Magik. Now I’m not reflecting on the language, however during this time I learned that a disgraceful amount of code was being written by Smallworld application developers because GIS folks* would want something to work a certain way – this still goes on today – layers of ArcObjects is written all over the place to deal with ‘work flow’ issues or ‘productivity issues’ which often don’t really exist. It seems like as a profession we’re hell bent on creating new tools instead of using the ones we’ve got to drive new results. I’m not suggesting that we shouldn’t  recognize tooling deficiencies but rather when we do, evaluate the cost of re-tooling against the gain and if new tools are required then don’t become a blacksmith yourself.

*I make the distinction here between GIS folks and people whose primary motivation for using GIS is to achieve a goal. The former are often employed to administer systems and data – the latter just want to use the tools to get shit done.

2. Ugly code

Not Designed. Not tested. Not re factored. Not reviewed. Not defensive. Not Good – just ugly.

3. Heavy Lifting & Home cooking

GIS coders, don’t code enough to understand when they’re heavy lifting. I’ve seen this loads –  home cooked configuration, data access layers, user interface components etc. If you find yourself writing a lot of code to solve an issue – the first question in your head should be – hang on a second, what am I doing wrong here? What problem am I trying to solve and hasn’t someone else been here before me? Patterns & Frameworks my friend.

4. Over cooking

This is kind of related to point number one, but it’s about over complicating code – GIS coders are prevalent to over cooking code – they add complexity and configuration where it’s not required, they write verbose code which reeks. Is this down to a selfish desire to tinker with more code? Know when to stop, keeping it simple will aid your software usability and maintainability. If you hear the words ‘we might need this down the line’………..chances are you probably won’t.

5. “But you don’t understand spatial data is different.”

This old chestnut is total guff. I was recently working with a non GIS coder who was stumbling slightly on some geometry conversion issues, it took all of five minutes and a sketch on the back of a cigarette packet to explain all there is to know about Geometry. (That’s not an entirely accurate statement). Why do we cling onto this nonsense in desperation? Back to my human geography days – as geographers we seem to continue to struggle with our identity, especially in a climate where even more people are engaged with maps – this is no bad thing. The fact that spatial is not special is something we should be proud of – somewhere along the way we must have done our jobs right (Or did Google just do our job better?)

Of course not all ‘professional software’ developers are great coders either – shit  - is there no winning! On balance my experience makes me agree with Erik – Some geography basics taught in computer science courses would go a long way.

Now to NoGIS – #NeoGeographyReDux

Searching Sucks

Recently I gave a quick presentation at the Melbourne Open GIS Group. The basic premise was that following my previous rant on crap maps I thought I would stick to the theme and talk about crap searching. You can check out the slides below. @manicmapper posted some images from the event here

This was the first meet up that @manicmapper introduced the idea of bringing a slab along if you wanted to talk – it worked well!

‘The Business’

Picture yourself. You’re in a workshop trying to figure out exactly what it is your customer wants you to do and then you hear this line:

“That’s for the business to decide…”

Suddenly your heart sinks. You’ve been here before haven’t you? You’re familiar with ‘The Business’ – it’s that amorphous beast where all decisions go to die.

Here are a few facts about ‘The Business’

Fact no. 1

Small businesses don’t have ‘The Business’. This situation seems unique to larger organisations, where the worker bees are detached from all forms of decision making. See Fact no 4. Smaller organisations have the luxury of understanding that if they don’t take decisions things will never get done – this sometimes gets called ‘work’.

Fact no. 2

‘The Business’ doesn’t exist – only people ready to make decisions exist. If they’re not in the room and you need them to make a decision then get them in the room. This will make your life much easier.

Fact no. 3

‘The Business’ is used like a get out of jail card. Don’t accept ‘The Business’ as an excuse, you’ll inevitably never get an answer from ‘them’  - so ask whether the person blaming ‘The Business’ should in fact be taking responsibility.

Fact no. 4

If you’re hearing a lot about ‘The Business’ in a meeting, this should tell you something is seriously wrong, you’re talking to the wrong people or the people who you are talking to inevitably hate or disagree with ‘The Business’

Fact no 5

‘The Business’ is like glue. Once it takes hold in an organisation it sticks. Suddenly you’ll find it everywhere, leaving you and your project in a state of utter dysfunction. Nip it in the bud – see fact no 3.

Watch out for it.