Anyone out there a Cocoa Touch developer using the iPhone SDK? If so, I want to hear from you. We (WBR) and I (Ethan Kaplan) have some ideas for Cocoa Touch applications that I would like to get made. Hopefully by launch of the App Store, since these are pretty simple apps.

I spent yesterday diving into some hacking because I never get a chance to during the week. A caveat though, I’m not a great programmer, just a clever one. My code is messy, non-refactored and more akin to some finger painting than careful architectural execution.

However, a “painting” approach to programming has yielded me some interesting things over the years. One of which was pStruct, which is/was a massive multi-threaded agent-system that I kind of organically grew from the World object up in Java.

I’ve since switched my “painting” language to Python, as its nicely object oriented when necessary, has a steady stream of libraries and API’s available, and is nice and elegant to play with.

Right now my coding is centered around the concept of Decoupling. IE: removing dependencies and synchronicity between web-front ends and the backend systems, as well as better methods for realtime process communication.

These efforts are motivated by the fact that our sites are basically Lego construction kits that use a lot of external services to do various things. For instance, CRM, mailing list management, SMS management, geo-coding, analytics and more. Each of these is dependent on an out-of-band system, but essential for front-end operations.

Time to decouple.

The premise for this is to keep the front-end process smooth from end to end, while providing the ability of asynchronous data-processing on the back-end. Also complicating this is that our sites are atomic databases, so the only way to do any consolidation is through backend processing.

Spread

The concept of using a Message Queue is not new in this Web++ world, as Twitter, etc use it, as does Digg and Flickr. Our need for a Queue is not related strictly to asynchronous and long-running processes, but also because of the variability of availability of some of the systems that we require to implement.

We also have a case where the queue will be handling a significant amount of different message types, from “user logged in” to “user changed profile.” Each message would have a number of things that could happen to it. For example, a “profile change” would need geo-coding, CRM sync, mailing list sync and more.

I like Spread as a method for using the queue because its robust, well maintained and easy to implement. While Starling and Sparrow are pretty cool, and there are other projects like Apache MQ that are more suited, Spread is nice, realtime and easy to work with.

The Daemon

Our sites (drupal of course) will drop messages into Spread at various hooks. They will all go into a common queue.

Sitting at the App server level will be a Python Daemon that monitors the Spread queue. Upon finding a message in Spread, the Python Daemon spawns an “Analyzer” thread which looks at the Message to determine would should be done. For a “user registered,” it’ll execute a geocode, crm sync, mailing list sync and maybe some other things. Upon completion, it’ll package the results of all this up into a new message and stick it into a Responder thread.

The responder takes the “callback” method and URL from the original message an issues an XML-RPC callback to the Drupal site. This would fill in the geocode information to Drupal and such.

By running Analyzers and Responders as independent worker thread pools, we remove any blocking caused by either external services (ie, Google API for geocoding) or Drupal (the XML-RPC callbacks and database loads).

In my tests on my machine here using GeoPy, this all worked really well.

The API

In order to avoid our Daemon having any dependencies on other people’s API’s, we’re probably going to use Drupal to create an API abstraction on top of all the external services. This will be done using Drupal modules for each service, and the Services module to provide the API.

This way we can swap out the Mailing List manager and not have to alter the API’s from the Daemon or indeed any other external service (widgets, etc) using it. The ideal would be for this API abstraction to apply to everything from payment processing, merchandise fulfillment, SMS sending and more.

XMPP

Yesterday I also ended up coding a Twitterbot that used the XMPP protocol for Twitter (twitter@twitter.com in Jabber). This was interesting as it provoked some thought into the power of XMPP as a realtime information distribution method for system info. The Twitterbot is fun, and we’ll probably make it responsive and semi-intelligent, but what was more fun was seeing the power of the XMPP protocol (which I just barely tapped into). Vs. an HTTP based API, XMPP has lower latency, lower overhead and no polling.

One thing I do want to do is create a XMPP PubSub publisher using the xmpppy package. I haven’t yet started that. I could see using this as a method of getting realtime information from our systems, such as a the feed of users signing up for sites.

I also could see XMPP’s usage in terms of public artwork or installation artwork as an easy socket based system for distribution of information onto visualization displays. When I was in school I had to write my own socket servers and protocols for this.

For the Bot testing I installed OpenFire XMPP server, which works very well. I’m impressed.

Datacenter Simulator

I also should mention that Wiredtree has provided us for a low-cost a parallels Virtuozzo box to act as a “Datacenter Simulator” I have it setup with two WWW servers, one DB server, one DEV server and one APP server. Its running each as a virtual machine on one box within the same subnet.

The goal of this is to simulate in a small scale the topology of a data-center for the creation of systems and tools for our web infrastructure. This includes Spread, the API, Daemons and SVN/Trac and other tools.

—–

I’ll post source code and diagrams when the code isn’t embarrassing and the diagrams are more complete.

Twitter crapped out. Nice to see how many Ruby libraries they depend on. Maybe its time for… PHP or Python?

Please pass this to anyone you know:

If you are in the LA area, we are seeking interns. You can get school credit. We need interns who can work their way through technology systems such as mailing list managers, content management, uploading graphics, updating social networking sites.

Basic HTML or PHP is a huge plus.

We have a cool work environment that is super casual and fun.

E-mail wbrtech (@) gmail.com with a resume.

Since I took some heat for my weekend post as people confused me asking a genuine question about the value of art to talking about a policy I have no opinion about, I thought I’d write a bit on my philosophy for artist websites.

Up above is about 1/4 of the total sites WBR has done on the Drupal platform. The aim in using Drupal as the backbone to our sites was motivated primarily by its ability to be amorphous to the final functionality requirement for any given website. Meaning: when entering into the development of an artist site, we can design the site from the get-go to the demands of the artist, not to the demands of technology.

Our central approach for artist websites is that each site should be as individual as each artist. No artist is similar, in the same way that nothing they produce is similar. So why should their site be similar to anyone elses? Everything an artist does, from a CD to their concert to even a poster should reflect the art, not the concept of product. In the same way, the site that we develop for an artist should be a reflection on the artist rather than a fetishizing of technology or the debasement of artistry under the guise of “easy” and “quick.”

This approach to sites is how I worked in the newspaper business when I was there. However it didn’t scale that well. However with music, since there is a semi-regimented process regarding the translation of idea into an actualized entity, its easier to insert web architecting into that and make it work in a unique fashion.

So in the spirit of Top 10 lists, here’s my Top 10 guidelines I try to adhere to for artist websites.

1. An artist site is not a social network, but it should be social: I’m a firm believer in the power of users in terms of a website. The Internet was not made for single direction communication, and when possible, any website should provide a high degree of control, communication, community and social ability for a user, to the degree they are comfortable with. However, it makes no sense to make a “social networking site” in the generic capacity for an artist. There are better sites for that, they provide nice API’s and the criticality of mass that enables “social network” as a concept rarely can be solidified around only one common theme.
2. Along the same lines: a community doesn’t have to be a social network: You can have a community on your website that is rich and vibrant and thriving without having to fall into the traps of the common social networking paradigms. In fact, to focus on communication rather than the “collecting” notion of social networking is better in the long run for fan relationships with the artist.
3. The artist should be a user, not the site itself: we treat the site as extension of the artifact and artistry produced by the artist, not as the artist’s entity themselves. That means the voice, tone, messaging and imaging needs to be treating the artist as a user, like the site was their home rather than the site is the “artist” as an entity. Its a tough distinction to make. Think of it this way: in order to carry through the notion that the Internet breaks the hegemony that is used to differentiate the “star” from the rest, you need to carry that through in the tone, messaging and design of the website. This isn’t necessarily universal however, but it should be a good starting point. Site = home for the artist, not the artist themselves.
4. People want only a few things from a site, but will stick around if there is more there: the most common things people come to artists websites for is tour dates and music. The second most common is news, and the parts that keep users around are any form of media. The reason fan sites (such as, ahem, murmurs.com) took a lot of traffic from artist sites in the past is that they used these as the gateway drug into a larger experience that celebrated the notion of fandom instead of keeping it at a distance. To keep people in the site, you need to celebrate those people.
5. Which carries to this, an artist site should celebrate fans and create a home for them. Fansites did this very well. The notion of fanaticism is actually quite a beautiful thing and deserves to be celebrated in the context of the object of fandom itself. The tone of a site should therefore welcome fans like it was their long lost home rather than a place to just extract time and attention and money.
6. Fans want a safe place. Running Murmurs.com, this was and is always the key to how I wanted it to feel. I remember being a hard core R.E.M. fan growing up and being constantly made fun of for it. The whole reason I created Murmurs.com is that I wanted a safe place to enjoy being a fan with other fans.
7. Make commerce easy, fun and social. This is a difficult one, but people do enjoy talking about, wearing and socializing around the objects they purchase. Malls are designed to take advantage of flocking behavior, and to a degree, Amazon is too using computer algorithms. The whole process of being a fan is also a process of objectification, which can and should be a fun process.
8. No Flash! This is simple. Flash belongs for certain things: media players and video. Nothing else. If a site isn’t easy for me to navigate, how will it be for someone on a small screen on dial up? I have four monitors and four processors for fucks sake and my processor gets pegged on any site with Flash. Say no to gratuitous SWF’s!
9. Its called the web for a reason: a web doesn’t survive without strong enough links to support it. In the same way, sites need to be one with their own community in order to function as full entities. Leverage what other people do better and don’t reinvent. Embrace and integrate on an API level. Facebook, MySpace, Twitter, FriendFeed, Upcoming, Jambase, etc. Anything and everything that can be attached can and should. In the same way, the site should (and we’re working on) provide an API for others to extend it.
10. 365 days, 7 days, 24 hours… the web doesn’t stop because an album is dropped from rotation. Keep things fresh, updated and working. Its hard to keep 100 entirely differently functioning sites functioning, but its essential and we spend tons of time doing so.

Anyone else have any to add?

My photos here, these are from my mom

Amy and me

My uncle and me

Bellatrix

Mom and her brother

[Relating to: blackrimglasses.com » Blog Archive » Reducing Back to Art]

Back to the point I was trying to make:

Where do you all see the import of art and music education within the public school system?

And along those lines: what are everyone’s opinions regarding the diminishing importance of the Humanities in general in education?

I ask this having first hand experience with the elimination of art in education, having a wife who’s a children’s art educator, and having her job systematically eliminated from everywhere she has ever worked.

The point I was trying to make, or trying to get to was:

How do we value cultural artifacts when there is little to no value of culture itself in the educational systems, public sector and society at large?

That, more than anything is the root of the problem I think.

I’m asking this not as a music industry person, but as someone who taught, practiced and supports art my entire life. And who is married to an artist and art educator.