Worus

I worked almost all day today. I got a lot done. I get so much more done on the weekends. I wish that I had the option to skip a day of work during the week and work a Saturday or Sunday instead if I was incredibly busy. However, that would probably sound strange to my boss. If I’m that busy, shouldn’t I work now instead of later? Yeah, probably.

In any case, my day was filled with productivity. Work flows! Buckets! Advancers! Returners! All sorts of fun stuff! Returners are really just the name that I gave to an instantiation of a bucket, but I needed to make the Final Fantasy VI reference for the sake of Banon. My Returners actually make usability strides where I was having engineering troubles, so I am grateful to them.

So what did I really do? Efforts now move through most statuses of the system now. Each object in the system may take on a status by being placed into a bucket, which they need to have completed. This allows objects to have arbitrary steps assigned to them, and even steps interjected as needed. There are different screens to display what’s in a bucket. Each one has a unique set of actions that can be performed on that object. Objects either advance through each screen or they don’t.

If the advancement option is chosen on the screen, an advancer is run. However, depending on the job associated with that object, it may actually have a different work flow than another item on the list. Each work flow has its own implementation of the advancer and smaller advancing classes. When processing the action advancements trigger the advancer to call that work flow’s advancer on the fly, passing in the bucket that the object’s in, from which it can determine which object had which action complete. The current bucket is deactivated and any other qualifying buckets are activated.

There are still problems with this system, but all in all, it works out pretty well. In the future, advancers are going to include a rejection method so that if the action is not a confirming one, the logic for rolling things back can be placed by the logic to move them forward. That way, it can vary by work flow. I also want to include a custom action method when the choise isn’t as simple as advancement and rejection.

Right now, the rejection code lives in the processing screen, which I’m not all that fond of. Keeping the code to generate presentation separate from the code to do database stuff makes each easier to read. Spreading it out across files can make hunting down the right file kind of hard, but that’s what makes the same action able to trigger different events work in the first place.

Finally, what’s a Returner? It’s a simple query string passed from the job screen to highlight the job’s entry on the action screen and once the action has been processed, return the user back to the job screen instead of the action screen. This helps me from having to re-implement various forms and validations for the job screen. This also has the added usability feature that if the user is redirected to a batch entry screen, they can complete not only the highlighted entry, but a bunch more before returning. I think that’s neat.

I think that’s enough downloading what I did at work the last two days for tonight.

Things at work have been just dandy the last week. Last Friday, we had a two or three hour freak-out meeting about the project that I’m working on. Apparently, the IT department at our client has a completely different idea where we’re going with this project. As a result, talking about how to exchange data has been more of an issue than thought. Once the client’s business people realized this, they called and our people had to suddenly have a meeting. As a result, people from my company will be flying to Virginia to demo what we have and get things worked out.

I guess I’m glad that I haven’t been the requirement collector at this point. I’d feel kind of silly if I had been. I’ve just programmed what I’ve been told. Now, the project has been running behind as I’ve had about a thousand other things come up in the last few months, but I’ve been able to make really decent progress in the last week. Before that, even, I’d been able to delegate some of the more isolated projects out so there has definitely been progress, albeit not as much as I would have liked at this point, either.

My coworker and I have been coding like mad all week to get this project moving in a good direction. Part of the slow start is that we’ve decided to use Cold Fusion’s object oriented model to manage most database transactions, so if I make an object and use it’s setters to set different fields and then call the save function, the object is either inserted or updated, depending on the object’s status. There are several benefits here. One is that there’s no difference between inserting and updating. Another benefit is that once one person has done all of the strange SQL for specialized deletes or formatting of some value, all instances of that method call take advantage of it.

At the moment, there is still no way to update just one value in a table, but I think I know how to fix that. The really nice thing is that all of these database objects are inheriting from a common object, so once the parent object is modified, it’s available to everyone (and, of course, everyone can override it, keeping a common API for simple database stuff.

This is still our first try with this sort of thing at work, so I’m sure that there will be some lessons learned here, but like I told the my coworker when I requested that we handle repetitive stuff this way, we won’t know until we try. So far, he’s really digging this whole idea, so I’m glad that I have him on board and not begrudgingly doing the work.

So we had this meeting last Friday. I was told what they needed from me for next week’s demo, and my coworker was told the same. We were both on track to finish these today. When we arrived, there was an e-mail with a lot more stuff that was requested for the demo. The demo is Tuesday and this is the first that we’ve heard of needing these things for it. Our direction on Friday was very, very clear. I made sure to ask on mine, because I was trying not to have requirements pop up at the last minute. Yeah, that didn’t work. As a result, I was planning on working this weekend.

The message did say that some things could be mock ups, but I think that mock up to the message writer means something completely different than to me. To me, a mock up means that it is at least pulling live data and maybe not doing anything with it. To the message writer, I think it means to literally just hard code some fake data in. Why spend the time to hard code in all of that data only to find out later that actually putting the data in those places is a lot harder and won’t work? I guess I just like to have a good plan in those situations.

At 4:30 p.m. this afternoon, we are asked if we could come in at ten in the morning to go through the demo that they are going to do. We agreed, but I told the people asking that as I was planning to work this weekend on things that they wanted for the demo that it would not all be done, but that we could go through what was done and talk about what wasn’t if they liked. So now I probably get to go in in the morning and spend two hours going through stuff when I could be working on the requirements that were dropped on us this morning.

The scary part that’s left undone has a lot to do with work flow and job statuses. I have a vague idea how to do it, but I’m afraid that I’ll miss something. We’re talking in the morning about it, no doubt. Charge forward, I guess.

I don’t want to work this weekend.