What's it all about, Alfie?

Today I spent the time getting all the new portfolio groupings into my web app prior to the second big push for the additional calculated values that will nearly complete the set of calculated risk values deliverable by the legacy risk engine. I wanted to get these groups in and stable and delivered to UAT before this so that it's one less "moving part" in the codebase.

It wasn't that bad, and I also added in a few alerts for Jeff so that the risk managers and portfolio managers can get these alerts as needed. The data is still a little rough, and it's possible to get a few false alarms due to the problems in the legacy risk engine, but it's the best we have at this point, and we need to get this in front of the users to force an increase in the quality of the data driving it.

So it's been a good day and I know I'm not going to look forward to the next few as it's the adding of the calculated values to the old app. Yeah... it's not a lot of fun. But I have to do it.

Today was the first day back from a nice, lovely, long four-day weekend, and it was tough. It was hard to get up, hard to get in to work, and a tough day of writing code that I personally think is a mess, but the time to re-write it is still in the future, so I have to fix this version.

I left the office beat down tired. I mean really beat-down-tired.

But it was a good day.

There's nothing quite like leaving it all, and I do mean all on the track. There's no doubt in my mind that there's nothing more I could have give to the cause today. Nothing. I can walk out of here, sleep on the train home, and know beyond a shadow of a doubt that there's nothing I could have done more today.

It was a really good feeling to have.

Today I started adding several new fields to an application that is targeted for a re-write, but we still need to get many more miles out of it before that point in time. The problem is, it's very brittle in the sense that I'm still not sure what touches what within the code. Sure, I'm getting closer to having a good understanding, but this level of change makes me more than a little nervous.

Still... if I take it slow, and make sure I make all the changes in the interfaces, and the factories, and the classes and the output, I should be able to get this done in one pass. That's my goal anyway.

Today I've been doing a little Snow Leopard tracking - following all those folks that got Snow Leopard on the opening weekend and reporting their successes and failures. I'm really surprised that I have as much 'unusual' software as I have - Growl and Dropbox are the holdouts to be sure, but a ton of apps have released 'Snow Leopard' releases. Great for me, I'll try to upgrade this coming weekend.

I was also facing a tough update cycle with an application I'm working with. I needed to change the source app so that it published more data that could then be read by the 'receiver' app and presented to the clients. I didn't want to have to go through two QA and release cycles, but there didn't seem to be any alternatives.

Then, while talking to my manager about the issue something popped into my head - clever configuration! Currently, my 'collector' app looks at the data received from the 'source' - a URL-referenced web server, serving up XML files. It parses this data and then works on it. But what I really wanted to do was to have the additional information in the parsing. However, it's also valid to think of adding that in the configuration of the 'receiver'.

What I decided to do was to add optional, additional, configuration to say "for this URL, here's the 'overrides' for the values you'll be reading". With this, I was able to very easily set up the additional information I needed without the need for the release of the other 'source' application.

I'll still add in the additional information to the 'source' application, but there's no need to wait for it and this opens the door for other overrides in the future. Pretty neat.

Being new at a job means trying to fit in. At least it does for me. After you've been around and seen how things are done, and why they were done that way, you can start to critique what's going on. Short of that, you're a clear outsider looking in, and your statements are written off as "...well... if you really understood how we do things here..." and dismissed. So I've been trying to understand the usage of 29West as the messaging system and Google Protocol Buffers on top of that.

I can see the many advantages of Google Protocol Buffers:

• Language independence
• Transmission protocol independence
• Automatic class code generation

But if you look at these classes, they are really very thinly wrapped objects with simple setters and getters and no real place to put higher-level methods on top of the data package.

I can also see that any good messaging system has the exact same capabilities. 29West is no exception, and in it's API you can package up elemental datatypes, shoot them out, and pull them out at the receiving end in an entirely different language.

Sure, 29West is a single transmission protocol, but that's the point of settling on a standard messaging platform for the organization: you want to have one, and only one, messaging system you have to deal with. Given that you make this selection, it seems like overkill to use Google Protocol Buffers to package up the data into a generic byte stream 'payload' in a 29West message.

I suppose if 29West had adopted this, or Google Protocol Buffers had a 29West 'wrapper', it might make sense, but neither does exist. It's just payload packaging on top of a system that already handles the problem of payload packaging quite well.

And as I'm thinking this I read in their C++ tutorial:

Protocol Buffers and O-O Design Protocol buffer classes are basically dumb data holders (like structs in C++); they don't make good first class citizens in an object model. If you want to add richer behaviour to a generated class, the best way to do this is to wrap the generated protocol buffer class in an application-specific class. Wrapping protocol buffers is also a good idea if you don't have control over the design of the .proto file (if, say, you're reusing one from another project). In that case, you can use the wrapper class to craft an interface better suited to the unique environment of your application: hiding some data and methods, exposing convenience functions, etc. You should never add behaviour to the generated classes by inheriting from them. This will break internal mechanisms and is not good object-oriented practice anyway.

They echoed the exact thoughts I was thinking at the time. This is a "data encapsulation" system for transmission on multiple protocols. It's not advisable to subclass these guys because the generated code could get changed at any time and break your code -- so it's really just a data 'packager'. Which is nice, if you need it. But why do you need it if you have a messaging system that does this already?

Answer: You don't.

In the applications I'm looking at, it's clear overkill. There's no added functionality, and just added overhead. If there were the chance that we'd need to use a different transport in the future, then that would be something. If we were abstracting away the 29West messaging so that it could be changed out easily, that would be something. But we're not.

I can see this as something that someone wanted to do - no real need - just a want. That's a pretty thin reason to make organizational standards.

Who knows... maybe there's a reason for it that completely evades me at the time. But I don't think so. I think Google said it best:

...they don't make good first class citizens in an object model.

and if that's the case, and you've already standardized on a messaging system that does this same packaging, why would you choose to use them?

Everyone has them - those days when you really don't get excited about a lot, but you have to get up, get ready, go to work, do your best, etc. It's just a day, and today was one of those days for me.

Sure, I learned that I really needed to be careful about the centering of divs in the page - more application of the CSS margin-left: auto; margin-right: auto; style, and I also fixed up a co-worker's code who was out of the office today, but that was just a simple thing.

I added a nice database-driven configuration variable to an app that originally had manual configuration. Nothing amazing, but the data was in the database, and the SQL query wasn't that hard to find all futures within a group that had no options on them, and then I'll never have to hassle with the manual configuration again. Nice, but not amazing.

I did the work. Nothing fancy. Just one of those days.

I know it's a good thing to do, but there are times, like today, that I just find it so hard to sit down and write design docs for something I've already written before. OK, sure... I haven't written it here before, and that's the same as not really ever having written it, but when you're writing the design docs from memory, it really doesn't have the same effect as those design docs that you really need to think about.

Still... it's something that has to be done. I just have to push through it and get it done.

Intellectually, I know that there are people that really do enjoy doing nothing. The Dilbert Wally's of the world. They enjoy the amount of work they don't have to do. I'm not one of them. Today was a very un-Wally day for me, and I loved a lot of it. While not everything was going my way, the vast majority was, and it was really fun.

I was able to get several things done for my webapp. They weren't terribly hard, and it didn't take more than an hour each, but the cumulative effect is to make the app seem like I was really making progress. Lots of little things that had been nagging at the users were cleared off my TO DO list.

It's great to have that feeling of accomplishment.

Today I was in a meeting about a service/project and realized that the best thing I could do was to keep my big mouth shut. This is a big step in personal growth for me, folks. There are a lot of ways to write systems - lots. You can do the huge design docs and then go off in a room and code, you can sit with the users and have them involved from the jump, lots of ways. But today I ran into yet another person that wanted to do what they thought was best - regardless of what the users were asking for.

This isn't new. Letting technology drive the project is common, and often a horrible mistake. Today I saw a user of this project ask (twice) for a C++ wrapper for the low-level RPC calls that the group felt was their interface. I would have written the wrapper before it was asked for, but that's OK, being asked isn't so bad.

But this manager said they were going to write it. Several people very gently objected, and it was still maintained that this was what was going to be delivered.

The funny thing is, they have to write some kind of wrapper in order to test their code, so why not take a few more days, make it nice, and let everyone have it? Don't know the answer to that one, but I was glad that I saw what I saw as it led me to believe that my opinion wasn't being requested (on this topic), and I should therefore just let them do what they want.

In the end, I can write a wrapper for the service, and probably will. If someone wants to use it, great, if not, then that's OK too. I'm not trying to make my stuff used in every project in the Shop. I'm just interested in doing a good job.

After the meeting I talked with my Manager - a nice guy that's trying to understand my point of view. After about 30 mins of talking to him I think I made it clear as to why I was feeling the way I was, and why it was futile for me to try and express those opinions and feelings to the group responsible for the project - it'd be completely unwanted and make me look like a judgmental individual.

While the latter may be true, it's not exactly the point. They asked for feedback on the project, someone asked for something that was very reasonable for them to provide, and it was rejected. Period. End of story. Done.

I really don't like working with people like this, but there are people like this in all walks of life. You just have to do your best to identify them and hope you don't have to deal with this too awfully much.

Today I've been working on a lot of ideas for a barrier breach alert - something where a data stream is coming into the system and you have set up a series of barriers defined by an expression - typically something like this:

  value > (2.0*n + 1)*10000.0

where:

  n = 0..5

so that the first barriers are actually at:

so now we have the barriers we'll be crossing through.

The trick is that when I cross any two barriers, I need to alert on the last one we crossed. So if we're going from 50,000 to 550,000 I want to alert on the 500,000 barrier not all the ones getting up to that value. Likewise, if I fall from 550,000 to 50,000 I need to alert on the 100,000 barrier not anything before that.

So we have to have an idea of direction of each barrier we're crossing, and we have to maintain a history of some sort to know what we crossed last, so as to know if we need to report on the crossing we're making right now.

This has been something I've been working on most of the day. Sadly, I do not, as yet, have a solution to the problem, but I'm sure I'll get something tomorrow.

[8/19] UPDATE: Yeah, I have something that seems to work rather nicely. I have two arrays of booleans - one for the previous state of all the barrier equations and another for the current state of the same equations. Then, I can compare the differences. If there's a difference, that's the "edge detection" we need. By looking at the values, we can tell if the current values are rising or falling.

Slick ideas that seem to be working nicely. Love this stuff.