It was quite strange when I woke up this morning. As I lay there in bed, I thought to myself "this is the last day of 2003!" It's a silly and simple thought, I know, but it was a strange first thought, considering I hadn't paid any attention to the new year at all up to this point.
Aesthetically, I've grown fond of 2003 as a year and number, but I've been quite excited about 2004 for quite some time. It will be the tenth year since I started giving serious attention to my art projects, and I've had a good energy over the last few months building up to it.
There are three releases planned for the new year. One was recorded last summer, one is still being worked on, and one was primarily recorded back in 1994 and has new layers of sound from 1999 and 2003 on it. The first two mentioned will be on CD, and the last one will be copied over thrift store tapes.
After much internal debate, I've decided to release this new work under a new project name, aodl. aodl will primarily be straight up big analog noise, allowing me to keep Eucci focused more on minimalism.
So.. While I've been anxiously awaiting 2004, I'm still surprised that it's just about here. And it sounds like I'll be welcoming it in with Southern Comfort, David Lynch movies, friends, and [most likely] more fresh snow. Excellent.
Other big changes go into motion when the new year hits. More on that later.
I forgot just how big (and wide) a Zope 2 inheritance hierarchy can be:
Acquirer --+
|
Acquirer --+ |
| |
Base --+ | |
| | |
EtagSupport --+ | | |
| | | |
LockableItem --+ | |
| | |
Resource --+ | |
| | |
Collection --+ |
| |
Base --+ | |
| | |
CopyContainer --+ |
| |
Base --+ | |
| | |
Navigation --+ |
| |
Persistent --+ |
| |
Base --+ | |
| | |
Tabs --+ |
| |
Traversable --+ |
| |
ObjectManager --+
|
Acquirer --+ |
| |
Base --+ | |
| | |
Base --+ | | |
| | | |
CopySource --+ | |
| | |
Node --+ | | |
| | | |
Element --+ | |
| | |
Base --+ | | |
| | | |
Owned --+ | |
| | |
Base --+ | | |
| | | |
EtagSupport --+ | | | |
| | | | |
LockableItem --+ | | |
| | | |
Resource --+ | |
| | |
Base --+ | | |
| | | |
Tabs --+ | |
| | |
Traversable --+ | |
| | |
Base --+ | | |
| | | |
UndoSupport --+ | |
| | |
Item --+ |
| |
Persistent --+ |
| |
Base --+ | |
| | |
RoleManager --+ | |
| | |
RoleManager --+ |
| |
SimpleItem --+
|
Acquirer --+ |
| |
SqlGateway --+
|
Base --+ |
| |
ImmutableId --+ |
| |
UniqueObject --+
|
ZopeGatewayGateway
The Senate passed it with a voice vote to avoid individual accountability.Pardon my language, but all I have to say to this is: you sick fucks.
While broadening the definition of "financial institution," the Bush administration is ramping up provisions within the 2001 USA Patriot Act, which granted the FBI the authority to obtain client records from banks by merely requesting the records in a "National Security Letter." To get the records, the FBI doesn't have to appear before a judge, nor demonstrate "probable cause" - reason to believe that the targeted client is involved in criminal or terrorist activity. Moreover, the National Security Letters are attached with a gag order, preventing any financial institution from informing its clients that their records have been surrendered to the FBI. If a financial institution breaches the gag order, it faces criminal penalties. And finally, the FBI will no longer be required to report to Congress how often they have used the National Security Letters.Pardon my language again, but all I have to say to this is: you sick sick fucks.
Ashcroft and Co. disassembled Patriot Act II, then reassembled its parts into other legislation. By attaching the redefinition of "financial institution" to an Intelligence Authorization Act, the Bush Administration and its Congressional allies avoided public hearings and floor debates for the expansion of the Patriot Act.And again: sick sick sick sick fucks.
What is all this? Bush signs parts of Patriot Act II into law — stealthily
Apparently, our Senators, scared of accountability, have helped the FBI run free of accountability. I still love this line: And finally, the FBI will no longer be required to report to Congress how often they have used the National Security Letters.
I suppose that's a good thing, since the last thing congress wants to do is be accountable and to hold others to some degree of accountability.
Sick sick fucks.
What makes this even better is: Bush signed this in to law the same day Saddam Hussein was captured, causing it to receive absolutely no airtime from the media who were too busy building replicas of Hussein's hidey-hole to care about this potentially very significant bill.
A really nice feature of iTunes, particularly in Mac OS X, is that if you had a multi-button mouse you could right-click on any of the buttons (play, next, etc) and the event would fire off immediately but without user interface feedback (the visual of "clicking the button" would not fire off). While a small thing, this little feature gave a nice impression of speed, particularly on older and slower Macs.
As of iTunes 4.2, it's practically gone. It still works if iTunes is in its "mini-player" mode AND it's in the background. But it no longer works all the time, which is a frustrating little inconsistency.
David Byrne has been making PowerPoint art. All I can say about this is that I want a copy.
"Software constraints are only confining if you use them for what they're intended to be used for," Byrne said in a phone interview. "PowerPoint may not be of any use for you in a presentation, but it may liberate you in another way, an artistic way. Who knows."
Considering the abuse I like to inflict upon the QuickTime Pro Player, I have to sigh and agree.
Martin Fowler has a recent entry about Anemic Domain Models as an antipattern. The gist of it is that a common [anti] pattern he sees is that application layer (or service layer) is very heavy with logic, whereas the domain model (the core business/data objects) is too thin, if not completely devoid of logic. Fowler claims that this turns development back into a procedural model, with the application layer providing all of the procedures that operate on the domain model data structures; and that this flies in the face of a founding tenet of object oriented development - namely, the joining together of data and process.
This is an issue I've been struggling with, and I have to say that I tend to prefer the service layer approach, at least in my current external data store based applications. Knowing what to put in the domain model, and ensuring it gets loaded up in the places it needs to get loaded, is a fair bit more difficult. Most applications and business processes revolve around more complex actions that deal with multiple objects, and exposing those interfaces as a service tends to be much easier to manage (situation depending). I agree that a domain model should not be completely devoid of process - but I'm finding most complex process code gravitates away from the model.
I'm finding this to be even more true when dealing with very central and complex business objects. In one case that I have, there are three different Table Gateways that map to a single table. They have different business responsibilities:
Still, the "where does the domain logic go?" question plagues us. I have my data layer, which has not been extracted into a harvested framework yet; a coworker has been developing a much more detailed one with (with different requirements) based initially on my patterns but going towards different goals; and as we go into 2004 we hope to turn them both into a solid data access framework to develop and deliver applications on. The domain logic organization problem is significant. Actually, logic of any kind's organization is significant. Already, much of the data access logic is encoded in rule sets that can be combined in different ways off of a schema, and that alone is a significant piece of business logic. However, that does not encompass business processes. Placing an order, filing a maintenance report, managing email servers - all of these processes are services. They can be objects, in that they can be persistent and are often some sort of class instance (true in our case), but ratio of data to process is heavily skewed in the process direction.
Maybe I'm just thinking about it all wrong. In any case, as we start evaluating architecture, I'm hoping something solid will reveal itself for our situation(s). In the meantime, I'll probably continue to read articles and books championing the process heavy domain model and thin service layer approach, and ones championing the heavy service layer and thin domain model approach.
Each year, I feel less and less of Christmastime. I walk through the crowds of suburbanites visiting the city with little notice. The sales don't jump out at me. The whole "real meaning of Christmas" left me a long time ago. Christmas has for a long felt far more commercial than holy (I'm not complaining - I have no semblance to a holy person).
Now that I'm living back in the same area as my parents and grandparents, and have no children of my own, it's even more distant. While I was living in Virginia, Christmas always meant that I'd do a big shopping trip to New York and that I'd get to travel back to this tiny city to see friends and family. That was always something to look forward to and prepare for (it was nice to be able to take almost two weeks off work yet only take four days of personal time).
It's very surprising to me that today is Christmas Eve. If it weren't for family, I imagine that I'd actually spend Christmas laying on the couch watching Comedy Central and/or David Lynch movies. Or I'd be skiing (Christmas is the only day during this next couple of weeks where the resorts aren't overcrowded).
About a month ago, Ian Bicking wrote of a web application pattern concerning status notification. It's a common thing that all of us web developers do - display on a page, usually in a common place, messages like "2 items placed in cart" or "Account Preferences Changed" or anything else along those lines. How it's done varies, but it's usually passed along as an argument to the page being rendered or it's passed along in the REQUEST (ie - as a GET parameter on a redirect). Ian proposes putting these messages in a users SESSION, and removing them immediately after being displayed. I like this. For one thing, it cuts down on the user seeing (or worse, bookmarking) URL's with the message as part of the query string. For another, it causes messages to be displayed regardless of where the user is taken to.
The code in Ian's post shows page headers/components that manipulate the SESSION directly. I don't like doing that, especially in Zope's [excellent] Page Templates. So I opted to make a service object that I can always acquire in Zope, and have it deal with saving and retrieving messages. This allows for application code to send the user messages without knowledge of implementation details, and I could imagine tying it in to a logging framework so that lower level systems and objects could log messages as part of their normal lives, and the higher level web framework would pick up on certain log entries and present them to the user in a unified way.
The Page Messenger service has some other benefits as well. For a while, I've been wanting a way to send messages to all web site visitors - something that might warn of impending maintenance, for example. To add that to my page messenger, all I have to do is add code to the message retrieval interface to look for messages in another location besides the user's session, and the web site will pick up those messages without me having to modify any front end templates.
Somewhere around Thursday, I got a nasty sore throat. I had hoped to avoid getting sick this year, and thought I was home free. Oh well. It gives me an excuse to stay in and catch up on my The Lord of the Rings DVD's in anticipation of Wednesday. Although I really want to go outside and play. It's a warm day (lower 50's), cloudy and windy, in advance of a storm.
And although I'm sick and shouldn't be smoking, I had to try an Eclipse inside the apartment. Eclipse cigarettes are funny things. Instead of burning the tobacco, the end of the cigarette remains heated and draws hot air through the tobacco. It's almost steam like. There's also very very little lingering odor (I never smoked inside my own apartment for dislike of the stench - although I love smoking in hotel rooms for love of the smell...). As for taste - it reminds me a lot of smoking pipe tobacco. Because there's far less burning going on, there's far less elements that inflame the lungs and cause other smoking problems. It's not completely free of all smoking related issues, but it's pretty damn good, in my opinion.
Oh man. A lot of us here in Utah have been waiting for the first game between the Jazz and the Lakers, now that Malone (a staple of the Jazz for 18 years) is a Laker (a team I still consider to be our arch-nemesis, dating back to a perceived rivalry back in middle school).
But Malone is ordered to sit out tonight's game for something that happened in the Lakers - Dallas game.
Dammit
Apple's Safari web browser is generally quite good: lean, fast, very good CSS support, simple interface. But it has one very nagging problem: when in HTTPS mode, it slows to a crawl. Maybe people with newer machines than my G4/400 don't notice it so much. But it's very noticeable on mine.
Checking out a couple of our own sites in Safari, which most of us here in the office use daily, I decided to open up a page in the Mac OS X port of Mozilla Firebird. The same page loaded much much much faster in Firebird. So then I decided to try OmniWeb 4.5, a native Mac OS X browser that now uses the same HTML core as Safari. Much Faster, Again!.
While OmniWeb now uses the Safari WebKit core, it still uses other OmniGroup frameworks, including extra networking libraries. So it's not terribly surprising that it could be faster, even with the same HTML kit. But it is annoying.
(OmniWeb also prints better than Safari, which has decided to print ENORMOUS text starting with version 1.1)
This makes OmniWeb and Firebird interesting products. They both take an open source rendering engine and in many places outdo the browser that is supposed to be that engine's champion.
This little baby, full of knobs, should be shipping to me very very soon. I may modify the packaging a bit once it arrives - it's just something I had to have now and couldn't wait for customizations.
A similar (but different) item, with even more knobs, will be done in about three months.
One of these is also being built for me and should hopefully be done by the end of the year.
The website for Harper's Magazine has been redesigned. Among other things, it now features RSS feeds. Besides its excellent Weekly Review and Harper's Index, certain readings have been posted online as well. A great one, published in the magazine last spring, is The Proclamation of Baghdad - a proclamation made by the British in 1917 that is eerily reminiscent of recent proclamations by the U.S. and, well, the British. Hopefully things work out better for everyone involved.