From X died enroute Y records comes a new aodl / lap dancer split CDR, Carpet Hag.
best new harsh guys out there! you need this if you're into wall of fucked sounds! edtion of 40! only $5 ppd! snippets in the mp3 section!
Tracks:
Alright! Finally, I have the first stage of my snippets library for Zope 3 rolling. It’s not displaying much at the moment, but it is doing what I’ve been trying to do.
So far, I’m actually using very few of Zope 3’s more advanced features, but they’re there to grow into.
So how did I deal with the add form’s success? Expecting to do a redirect from within Zope didn’t quite work, because the XMLHTTPRequest system would follow the redirect and put that in the middle of the page. So I needed to return a value that I could use within Javascript to do a redirect. Again – this is only on a success. On a validation failure, Zope 3’s addform’s basic behavior is exactly what I want. So on a success, I needed Zope 3 to redirect to something that would return a URL I could redirect to. No existing object or class, aside from my modified addform view, needed to know of this new view’s existence. Zope 3’s view system made this easy, and with a couple lines of code, and a couple of lines of configuration to register the view, I have my ridiculously simple but useful view working.
On the client side, I have the following in my Javascript library. There may be a better way to do this, but I’m no Javascript/DHTML guru, except for where libraries like prototype.js have liberated me.
function respondToAddSnippet(content, container) {
// When a snippet is added, refresh the page if the result starts with
// http. Otherwise, place the contents of the result back into the container.
if(content.substring(0,4) == 'http') {
window.location = content;
} else {
$(container).innerHTML = content;
}
}
function add_snippet(url, form_id, container) {
var parameters = Form.serialize(form_id);
parameters = parameters + '&UPDATE_SUBMIT=Add';
new Ajax.Request(url, {
parameters: parameters,
onComplete: function(transport) {
respondToAddSnippet(transport.responseText, container);
}
})
return false;
}With “add_snippet” being bound to the add form’s onSubmit event. My custom code for the add view consists of the following:
class SnippetPostAdder:
def add(self, content):
"""See zope.app.container.interfaces.IAdding
"""
container = self.context
chooser = INameChooser(container)
# check precondition
checkObject(container, None, content)
name = chooser.chooseName(None, content)
container[name] = content
return container[name]
def nextURL(self):
next_url = '%s/@@index_url' % zapi.absoluteURL(
self.context, self.request)
return next_url
With the ”@@index_url” being the call to the custom “index url” view mentioned above. Other code that is used by the Zope add form machinery uses ‘nextURL()’ to redirect to the next url on success. It’s Zope’s add form machinery that processes the input, with a lot of options on when to set positional and keyword arguments on the factory and setting properties directly. It also fires off relevant Zope events. When done, it calls self.add(content), as shown above. This is a straight-ahead adder which generates a name (a unique id for the container) before adding the content to the container. There is Zope machinery that handles this when one goes through a slightly heavier add process, but this is all that is needed here.
For my first twelve (give or take) hours of mucking with Zope 3 to make this snippets app, I've made OK progress. Firefox does not seem to be loading the prototype.js resource, but Safari is loading it fine.
I'm trying to figure out how to get a dynamic 'add form' to render on the page. So far, I have a fresh one loading (Safari only) via Ajax. The tricky bit will be validation and returning the form segment with validation errors inside of it. I may have to extend or replace some of the Zope 3 'adding' components for this purpose. Looking at their source, it might not be *too* bad to have to do, and it will give me a good chance to learn more about the schema and widgets system.
Today, I decided to pick up Zope 3 yet again. Zope 3.1b1 was released recently, as was Zope 2.8.0. Zope 2.8.0 includes Five, a product for Zope 2 that allows use of Zope 3 technologies. It's my hope that some upcoming work projects will allow me to use Five in order to start transitioning some of our work to Zope 3 without having to do the massive jump immediately. But today, while looking at source code and interfaces for some other simple but effective web applications like Snippets (yes, another Rails app), I decided that I wanted to try a full Zope 3 application again.
There have been some issues - documentation hasn't caught up with Zope 3.1b1 yet. This isn't a huge issue - 3.1 is in beta after all, and Zope 3 documentation and engineering is really quite good, but I was bit in a small change that exists in the default skin setup as I was trying to wire up a custom (and simple) skin for my application.
I'm still quite impressed with the system. It seems more manageable. For small applications, it does feel like there's a fair bit of overhead involved. But, nicely, Zope 3 seems to tell you that you can use as little of zope.app (the main Zope application server framework) as needed.
If working with the Prototype.js Javascript library is any indication of what programming Rails is like, I would say that Rails has one more interested user out there.
prototype.js says its development is driven heavily by the Rails framework, but could be used with any system since it is just a browser side Javascript library. I very rarely use Javascript. In fact, I've tended to avoid it as much as possible due to bad memories of it stemming back to the mid to late nineties. All of that changed this week. I'm still not intimately aware of how to program in Javascript, but with prototype.js I was able to put a simple AJAX based UI together in a couple of hours. Half of that time was spent learning some simple DHTML tricks, which the prototype.js library made easier. On top of its AJAX (or XMLHTTPRequest) capabilities and special effects, prototype.js adds some nice object oriented features to Javascript that made JS feel less foreign to me, and it also adds a couple of nice extra methods to the core DOM. One of those that came in handy for me was getElementsByClassName, which lives up to its name by returning an array of DOM elements with a particular CSS class name.
What I liked most about working with the prototype.js library was that while it does not come with very much at all in the way of documentation, the source code is very clean and easy to figure out. I got my user interfaces going by reading its source, using Firefox's Javascript Console, lots of page reloading, and occasional consultations to some public web applications that use this library. By the end of my first day of working with it, I realized that the style of the code was rather similar to what little Rails code I've seen.
But I don't need to concern myself with Rails or any of the scads of knock-offs based on Rails. Wiring prototype.js up to Zope required almost zero thought. Zope's been publishing objects and methods on simple URIs for longer than most systems have even existed, and throwing in a couple of Ajax specific view methods which performed their update and returned a simple string of "OK" (all that this application required) took no time at all. Note that I could very easily have dispatched off to a page template that returned HTML to display in line and Zope and prototype.js's Ajax commands would have been just as happy. So again, I tip my hat to Sam Stephenson and all who contributed for making it fairly platform agnostic when it comes to the server side. (note: the form serialization stuff could probably be tweaked / extended to work better with Zope's parameter marshalling).
So why did I decide to try Ajax / Javascript for this application? Because this is an instance where the small set of targeted users need to go through a big list and check off items as they reconcile them against another system. I decided that I would make it so that if their browser supported these technologies that the updates to the server should happen instantly so that the users don't have to go through and find the 'Update' button every time they finish the list. It's also easier now to give visual communication about cleared items since table rows in these reports can be so easily highlighted.
Combined with the browser_detect.js library, it was pretty easy to structure this UI in a series of fallbacks for browsers with less functionality, back to zero Javascript. But for the users who can do it all, it should help their job move along quicker. And I like that.
The D*I*Y Planner: Hipster PDA Edition: "So, why are we suddenly seeing a resurgence in paper-based organizational tools like planners, index card sets (a.k.a., the Hipster PDA), file folders, pocket briefcases, and honest-to-goodness real-ink pens? Outside of a number of philosophical reasons, I believe that it's ultimately a matter of knowing that these things actually work. After all, not even the trendiest tools last for more than a season if they don't deliver (and I have a junk drawer overflowing with orphaned gadgets to prove it). There's a proven track record behind paper-based planning, and an endless array of options for those people wanting to define --and redefine-- their systems."
Over the past few months, I've returned to paper based planning / thinking / etc, carrying a pocket moleskine in my back pocket and using assorted other notepads in the office and in the home/studio. Paper's not a perfect solution - filing, portable storage, etc, bog down. But it's always on. Writing is always natural. Drawing always works. It allows me to focus on writing something down or thinking something out without worrying about how to write it down and think it out. If what I produce needs a longer life span, I can transfer it to a computer.
One thing that I tried recently was a variation of Getting Things Done with Index Cards. I only applied this to one project, but it worked great for what I was doing. I had many tasks to get done, and new ones that would pop up in the queue as I thought things out. Normally I like using an outliner program for something like this, but sometimes I just get overwhelmed by the outline. I forget to pop the outliner app back to the front, or I end up spending too much time looking at the tasks ahead and thinking about them and effectively distracting myself from the task at hand. With the index cards, I could keep the current task on top. I could reorganize and insert new cards as needed when I needed to look ahead at what was coming next. But for the most part, I could confidently keep my mind on the one task in front of me. When it was done, I ripped up the card and tossed it in the trash - a very satisfying (albeit a bit wasteful) way to mark a task as complete.
It doesn't work for every project, but it worked out great for that one.
I’ve picked up a lot today and haven’t had chance to catch up to it all yet. Right now I’m watching / listening to an interview with Laetitia Sadier about Monade. You may know Ms Sadier as the vocalist of Stereolab. Monade is her solo project. It’s in the latest issue of The Brain.
I’ve got the new White Stripes to catch up to. I’ve heard excerpts of it and liked what I heard.
From iTunes today, I made the following purchases:
But oh gods – this HEM is killing me. There are excerpts here. It’s killing me in the “I want to be alone at a sad sack country bar listening to this on the jukebox and just crying crying crying behind my hair and beer and cigarettes.” It’s killing me in the “riding through the foggy winter desert landscape” way. It’s killing me in the “on the train through the Sierra’s full of longing” way. It’s killing me in the “walking around a northeastern lake full of longing” way. Holy shit. It’s so good.
Jon "Hannibal" Stokes adds in his voice on the Apple-to-Intel transition. He reiterates that it is Apple's plan on introducing x86 based Macs in the low-end and portable configurations first, where I think it also makes sense. Aside from the laptop series falling behind in overall performance, Hannibal notes that laptops and low-end macs are the least in need of high end PowerPC 970 (G5) features such as 64 bit support, and so on. The G5 is a nice processor and will be a nice one for the next couple of years, but it is a bit beefy (especially in its energy consumption / heat production) for portable and low-end machines, whereas Intel has made some highly effective mobile processors in recent years.
A problem that's been in my head since Apple announced their transition plan to move from PowerPC to Intel processors is one of fairly serious concern - professional applications. While I imagine that many of the smaller Macintosh developers or long time Cocoa (Yellowbox/OpenStep/NeXTStep) will have applications ready to go when the transition occurs, it's a different story for professional applications.
Andreas Pfeiffer picks up on this in eWeek. He covers many of the issues that have been troubling me, and he seems equally troubled about them. The overall message is still a bit uncertain right now - what about 64 bit? What about AltiVec? These were considered chief advantages of the G5 over an x86 based architecture and were rightly touted as such over the last couple of years for developers to take advantage of. On the lower end of the scale, there are few things to worry about here. Lower end audio applications, for example, written expressly for Mac OS X probably use Apple's standard libraries and subsystems such as Core Audio for plug-ins and other audio processing, and aren't likely to be affected. But professional applications like Pro Tools are likely to have a lot more work ahead of them. Many of these professional applications, such as Pro Tools, QuarkXPress, and much of Adobe's suite, all took their time in coming to Mac OS X. These applications have longer release cycles and cost hundreds or thousands of dollars and they're expected to work right, just out of the box. Furthermore, they depend on plug-ins. The plug-in business for Pro Tools alone is a sizable industry. Even if the next version of Pro Tools shows up shortly after Apple's professional machines switch over to Intel processors, it can take much longer for all of the plug-in developers to come on board. A few studios that I know of have not been able to make the move to Mac OS X because they still have unsupported plug-ins or may not be able to authenticate them (license enforcement in the pro audio field is legendarily rigid).
According to some early reports I remember reading about Apple's switch to Intel, Apple plans to move their consumer machines to the new architecture first. According to Apple's industrial designs and professed reasons for choosing Intel (better performance per Watt), this makes sense. Getting the G5 processor into anything smaller than an iMac G5 - a beautiful piece of engineering, but definitely too hot and too big to put on a lap yet - is apparently proving difficult, and the G4 processor is rapidly falling behind on performance. Higher end machines can probably still enjoy the benefits of power of the G5 processor and architecture and stay fairly speed competitive for a bit longer without having to worry about fitting into smaller spaces and the associated cooling challenges. In the meantime, Apple's laptop line can also catch up on performance without the apparent G5 heat / space issues over the next couple of years.
Apple's current long-term plans are pretty vague. I know there are quite a few Mac purchasers - whether individuals or corporations - that are worried about making purchases now on what seems to be a dead architecture. There are at least two years worth of new PowerPC based products yet to come from Apple, and I imagine that they're all going to remain adequately competitive. Beyond that, there are a couple of years at least of continued support for those machines from software.
The concept of universal binaries is that applications will run fine on both processor platforms. Developers do have plenty of time to make the crossover. I highly doubt that there are going to be any applications for the first few years of Intel based Macs that will only run well on the Intel based boxes. So a PowerPC based purchase in the near future is not going to be worthless or useless over night. Personally, I'd rather have a late model PowerPC based Mac than an early model Intel one.
My prior weblog, Industrie Toulouse faces an uncertain future. As do I as a blogger. I don't post heavily these days. I'm lazy. I've long lost the feeling of overwhelming self-importance that some bloggers seem to have in spades. However, I admit that I miss having a place to post to easily.
So for now, this is the new home. It may change up yet again in the near future if I decide it's worth throwing some money or time at. But right now, let's get back to thoughts on Python, Zope, Design (Fashion, Graphic, User Interface, Product, Industrial, Interior), art, noise, and on and on.
