apk zipalign

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:

1. aodl, Martial Notary Supplies


2. lap dancer, Changing Room of Cameras


3. lap dancer, The Mountain Witch Liturgy


4. aodl, Kiss My Toad, Watch it Explode

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.

• It uses Ajax to load an add form into the index page the first time ‘add new…’ is clicked. After that, clicking on the ‘add new’ button toggles the add form.


• The add form uses Zope 3’s widget system, and uses the built in addform system. I made a custom template that was a bit more stripped down while still using Zope 3’s widget macros and other facilities. Basically, this is the naked objects / scaffolding type system that’s long been in Zope 3 wherein an object’s specification can be used to assist in building forms and validation. And while I did have to mix in some custom code to support working in an Ajax environment instead of regular full page request / response environment, I didn’t have to do much. Zope 3’s system is pretty well structured here.


• It incorporates a custom widget for doing ‘tags’. The ‘tags’ widget is a regular HTML textinput widget, but on the server side it is cleaned up and parsed into keywords (split on whitespace, punctuation removed).


• When the form is submitted, AJAX is again used. Zope 3’s add form submits to itself and performs a redirect on success, or highlights validation errors in place. On a validation failure, this works out quite well with prototype.js’s AjaxRequest and AjaxUpdater objects. It was a little more tricky to deal with on a success. I’ll cover that in a minute.


• Tags are indexed right now as simple ‘tag’ objects which find their associated posts. It’s a brute force solution, but it’s working. The reindexing occurs every time a Snippet post is added using Zope 3’s events system. When I expand the system, this will deal with modifications and deletions as well.

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.

1. Eucci,
   
   tah'naer (Halo and LGL Variations)
   
   
   Piano, prepared electric piano and tape variations of "tah'naer", a composition for piano, hospital, and typewriters by J.Shell.
   
   
   
   tah'naer: Jeff Shell (Scream Sheet Studios, 1995)
   
   Halo Variation: Fay Marcy (Halo Auditorium, 1999)
   
   LGL Variation: Jeff Shell for Eucci (Eucci Pierpont 2005)
   
   Halo + LGL Variations: Jeff Shell (Eucci Pierpont 2005)
   
   
   


2. Eucci,
   
   Catalog Life
   
   
   
   1.Summer at LGL Point
   
   2.You've Ruined Me
   
   
   
   Scenes from a life that inspired a summer catalog collection.
   
   
   
   Jeff Shell's Eucci brings banjo, rhodes, aggressive leads, and more and runs it through the minimalist musique concrete tape machine, bringing a cut up and softly distorted sound to faintly recognizable objects and a touch of bluegrass.
   
   
   
   Percussion, pops, and dusty instruments swarm around your ears like summer dreams in urban parks.

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.