XML Schemas and ANY

I was tasked with creating an XML schema with extensibility, both from the application perspective and from the “we don’t have the requirements finished yet” perspective.

My solution was a simple key-value pair approach within a generic array. It could work:
<xs:element name="person">
   <xs:element name="attrKey" type="xs:string"/>
   <xs:element name="attrVal" type="xs:string"/>

But then someone mentioned the use of the “any” element. I had never heard of it.

Turn out you can make a smarter extensible document by using the any element (from http://www.w3schools.com/schema/schema_complex_any.asp):

<xs:element name="person">
   <xs:element name="firstname" type="xs:string"/>
   <xs:element name="lastname" type="xs:string"/>
   <xs:any minOccurs="0"/>

Boy that’s smart stuff. I like it! Now, to just see if we can implement it in time! 🙂


Developing a Real Time Log Analyzer

I had a requirement to build a log analyzer to look for trends and performance-ish issues, which would then be persisted to a database, from which we could query and build reports, etc.

The requirements were for us to get as close to “real time” as possible, without impacting the current system much at all. Perfect requirement, right?

It turned out we got stuck on the implementation – how were we going to make this analysis available, through some ETL job, but without causing performance impacts? And also be very nearly real-time? (The actual requirements were for 10-15 minute increments.)

We had some discussions on what was possible and it boiled down to “what are the requirements?” I was obviously a little annoyed when I restated the minute-interval again.

But what was the goal? Hm, there must be something here, because of the questioning.

What is the user going to use this particular information for? Reporting, seeing spikes in activity, performance, etc.

Ah, but we already have tools (alerts) for that sort of thing. And we have a Production Support team whose existence is to stop something in Production once it occurs – to find the issue, find a way to fix it and then fix it.

So, the question again – What is the information going to be used for?

Ideally, we would do real-time, but it turned out the solution we were developing wouldn’t (ever) be able to do that. And, there are other tools to do the type of granular information we were looking at. No, our tool wouldn’t – couldn’t – do real-time. Or even near-real-time. The ability to react to those spikes or valleys isn’t something that the tool should be designed for. And at the point you are wanting real-time (or 10 minutes from it), you are already late. It’s already old information.

A hard reality to face. What makes more sense is a one-hour cron to capture every hour and graph. Anything less than that time interval is unrealistic and nearly useless vs the cost to implement.

I think as the Analyst, I should have caught this and steered our stakeholders away from this approach – but I had the “you can do anything with technology” mindset, which proved to harm more than help here.

But, lesson learned for me. Sometimes what you want to do, you can’t have. But that’s called making decisions.

jsperf.com – Optimizing Javascript

I love this site. So easy to use. And exactly what I needed. I’ve been trying to shave a few seconds off the load time and other processing time of a heavy .js website. And this tool helped me to do it.

Here are some perfs I’d created:

I’m sure I’ll use this for more and more. It’s just nice to be able to say (1) Which is faster: A or B and then (2) actually go test/prove it out. Nice!

Not Another Technology Blog

Well, sorry to disappoint. Actually, this blog – I’m hoping – will be a place for ideas and pieces of information that I have rattling around in my head to go and rest.

The more I look at technology related things, the more I realize that I like technology. I never considered myself a geek, but then I find myself “geeking out” about something cool.

And if that’s not the definition of “geek”, maybe I don’t know what is. 🙂

So hold on – this could be good, helpful, great, useful. Or it could not really be much good at all. We shall see!