Archive for November, 2003
A fellow developer was discussing his football pool. The players select a winner for each of the 16 NFL games. Each game is ranked. You get points based on the ranking. The question of the maximum number of points came up.
The maximum points would be:
16 + 15 + 14 + 13 + 12 + 11 + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1
This is 136. I remembered that with even numbers, you could calculate this value with the formula i / 2 * (i + 1). This is because 16 + 1 = 15 + 2 = 14 + 3, etc.
For odd numbers, you use the even number calculation and add the odd number to the result.
I then wondered if I could calculate any arbitrary positive integer with a single statement. I came up with the follwing after a couple minutes:
(i + 1 – i Mod 2) * Int(i / 2) + i * (i Mod 2)
This appears to work until we overflow the data type. A stupid example, but it provided me a little diversion from the humdrum.
The following list was passed out at our local community band recently. Surprisingly, Google only found one site with this set of rules. So here’s my contribution:
Community Band . Rules to Follow
- My instrument was tuned at the factory, and it.s still under warranty.
- The audience cannot see the music. If you cannot play it, fake it.
- This is an adult band; all humor should be adult-oriented.
- The low brass belongs in the back row and must earn this right with every possible rude comment.
- Only follow the conductor enough to make him feel needed. Any more would unnaturally boost his ego.
- If playing softer is necessary, remember playing out of tune will cancel out the unneeded sound.
- Hearing aids should be reserved only for older, more experienced players. The experience is necessary because faking it is difficult when you cannot hear to follow the rest of the section.
- .Fortissimo. does not mean .Loud as ****; .Forte. does!
- Remember, a concert is .just another rehearsal.. Take advantage of this time to try something new.
- Everyone should play the same piece.
- Stop at every repeat sign and discuss in detail whether to take the repeat or not. The audience will love it.
- If you play a wrong note, give a nasty look to one of your partners.
- Keep your fingering chart handy. You can always catch up to the others.
- Carefully tune your instrument before playing. That way you can play out tune all night with a clear conscience.
- Take your time turning pages.
- The right note at the wrong time is a wrong note (and vice-versa).
- If everyone gets lost except you, follow those who get lost.
- Markings for slurs, dynamics, and ornaments should not be observed. They are only there to embellish the score.
- If the passage is difficult, slow down. If it.s easy, speed up. Everything will work itself out in the end.
- If you are completely lost, stop everyone and say, .I think we should tune up..
- Happy are those who have not perfect pitch, for the kingdom of music is theirs.
- If the ensemble has to stop because of you, explain in detail why you got lost. Everyone will be interested.
- A true interpretation is realized when there remains not one note of the original.
- A wrong note played timidly is a wrong note. A wrong note played with authority is an interpretation.
- When everyone else has finished playing, you should not play any notes you have left.
One of the issues we have to deal with when implementing CSLA.NET is generating business code for all the existing database tables in the system. Much of this business code is repetitive and formulaic. A code generator would be very helpful.
I was reading an article by Rockford Lhotka about concurrency techniques that can be implemented within CSLA.NET.
With disconnected ADO recordsets, you automatically get a nice set of tools for optimistic concurrency. With ADO.NET, you can have the same thing with datasets. However, the CSLA.NET architecture doesn’t hold a dataset in the business object. This means you have to implement optimistic concurrency on your own.
Rocky suggests in the article that implementing field-level concurrency involves three sets of variables. One set keeps track of the original values. A second set keeps track of the current values edited by the user. A third set is filled with the current database values before you attempt to save the data to the database.
The example in the article implies a series of “If” statements to look for concurrency violations. My concern with this is when we add properties, we have to also add code to the concurrency checking for that field. I’d like to automate the concurrency checking.
Perhaps the concurrency checking could be automated with reflection. During the fetch process, reflection could be used to load a list of original values.
During the update process, a “current” copy of the business object could be loaded. Using reflection, the properties of the of “current” business object could be compared to the original values. The properties of the “edited” business object could also be compared to the original values. If both are different we have a concurrency violation.
This adds a lot of overhead, so performance might be a problem.
One common business requirement is being able to audit important business changes. This means that of the 20 fields that are enterable on a customer record, we care about tracking 5 of them.
There’ve a been a few threads in the CSLA.NET discussion group about creating audit log and audit entry objects. These are absolutely necessary.
What about creating a custom attribute to assign to fields that need to be audited? Perhaps this attribute could be targeted to a class as well, so all fields would be audited?
Should the auditing records only be created when changes are applied? I think this would require the ability to do a comparison of old/new on every field. That could be a lot of overhead, although the comparison would only be necessary on the audited fields.
Should the auditing be recorded as changes are made and included in the state of the object? This could significantly increase the size of the business object.
I’ve started investigating an application framework called CSLA.NET. This framework comes from the book Expert One-on-one Visual Basic.NET Business Objects. As I’ve been reading the book, I’ve been conceiving of how we could implement this framework at work. The ideas have been coming to me at the oddest times. I’ve decided I’ll make entries in the blog relating to these thoughts.
At first, these entries are going to be general in nature. I’m not even 1/4 of the way through the book and I haven’t looked at any code other than the samples in the book. As I dig into the framework in depth, I’m sure the thoughts I have will become more detailed and include code of my own.
At work, we do our development in VB6. The change to VB.NET probably won’t happen until we are forced to do so by competitive pressures. I just finished dealing with a VB6 bug, and I think it makes a good illustration of how VB.NET might make my life easier.
Read the rest of this entry »