We are all sometimes strange, inconsistent, frail, error-prone beings. That seems to be the nature of the human condition. Weakness comes in many forms: sickness, injury, lapses of judgment or character, mistakes, or bad luck. Your happiness and even survival depends on your ability to accept the limitations of your own abilities. Your ability to help, teach, lead or console others depends on your ability to accept their weaknesses.

I had this realization a few years ago, and it seems I continue to have experiences that lead me back to this truth: You cannot have compassion for others without embracing your own weakness. You can never be truly happy with yourself if you are unable to accept and understand the human weakness of others. The two are directly linked.

“The reach of your compassion is the reach of your art.” – Joseph Campbell

Subreala allows you to easily upload words and images and then create interactive pages for them. It’s as easy as just selecting which visualization you want to use, preview it, and then publish it. You can also link pages together and create interactive menus that link to your pages. And you can embed any page on another site, like your blog for example.

Right now, there are dozens of visualizations to select from, mostly based on original code from artist Gerard Ferrandez. It’s an open platform that lets javascript developers create new visualizations, so as time goes on, there will be more interesting ways to present your art.

You do not need to make a huge time investment. You just upload your stuff, create a page, and share the link anywhere (or embed it.) You create a byline with a link back to your site or blog, and that credit appears on every page created with your art.

Subreala is still in development, so you need an invite code from me or another member to get started.

Dear Javascript Developer

Subreala is an experiment I’ve created in my spare time that gives javascript developers access to the DOM for pages containing artist content, such as words and images. The visualizations already on the site offer a good example of what is possible.

The platform has been designed to not use any javascript libraries for the site frame and navigation, so you can use any frameworks or libraries you want with no namespace collisions. You have access to load javascript, CSS, and HTML on the page, and of course full access to the DOM. All the content is always structured the same way, with classes and ids to make things easy to find.

You do not need to make a huge time investment. This is perfect for demos you’ve already created and just need an easy place to show it off. You create a byline with a link back to your site or blog, and that credit appears on every page created with your code.

Subreala is still in development, so you need an invite code from me or another member to get started.

Thanks for reading

I hope that Subreala will teach me more about how artists and geeks can collaborate better to build more interesting things. I’m completely open to your feedback and suggestions. I’ve been working on this in the background for about a year, and I’ll continue to improve it in small steps.

What is Subreala?

Subreala is an experimental project, still in active development, and might become almost anything.

Subreala is an exploration into how artists and developers can collaborate more effectively.

Subreala is a private beta because it’s not completely finished yet. (Email waltjones at subreala.com for an invite.)

Subreala is a way to create stories that lead anywhere and everywhere.

Subreala is a way to credit both artists and developers, while providing an immersive adventure for the curious explorer.

Artists

Upload your visual or textual content and create pages from a library of interactive visualizations.

Link your pages to other pages, creating a path that may be linear or labyrinthine.

Developers

Upload javascript targeted to a structured DOM model for content.

Test your code against a library of artist content, and release it to be used by others.

Many thanks to

Gerard Ferrandez, who released his Javascript under Creative Commons, and without whom this project would still be just an idea.

The Behance artists who released their images under Creative Commons, and whose work I have used to create the initial demos.

All other Creative Commons artists, whether or not they appear on Subreala.

The Open Source development community.

Email me

This project exists in order to help push creativity forward on the web. If you have ideas, comments, feedback, etc. email waltjones at subreala.com.

• Problems uploading images
• Problems installing themes, plugins
• Problems auto-upgrading Wordpress
• Anything else where Wordpress needs to write files

And here is a typical error message:

“To perform the requested action, connection information is required.”

Or…

Unable to create directory [...]. Is its parent directory writable by the server?

The problem is that Wordpress is executing in the context of your web server process, but the directories have write permissions based on the user context used to originally create the directories.

Many of the suggested solutions on the web simply won’t work, while other solutions work but create security problems with your Wordpress installation. Here is the full solution that should work on all Linux systems, regardless of the specific environment. What we are going to do is give your web server ownership of the directories and files of your Wordpress install. This requires you to be knowledgeable and comfortable in your bash shell environment, which is probably reasonably true if you installed Wordpress yourself.

First we will give everybody write access so that WP can write the content directories. Some solutions on the web stop at this step, but this leaves your files with no filesystem security. We are only doing this briefly in order to determine what user context is being used by the web server.

Go to your Wordpress root directory:

# cd /var/www/html/my_wp_blog

Give the world write access to the content directory:

# chmod 777 wp-content

Now log into Wordpress and upload a photo to a blog post, causing WP to create the new directories required. Then look on the server to see what user created the directories. This would commonly be apache, but also many people are reporting that this is the user “nobody” on their server.

# cd wp-content
# ls -l
total 16
-rw-r--r-- 1 root root   30 May  4  2007 index.php
drwxr-xr-x 3 root root 4096 Feb 10 19:31 plugins
drwxr-xr-x 5 root root 4096 Mar 23 03:04 themes
drwxrwxrwx 3 apache apache 4096 Mar 24 02:08 uploads

Notice that the uploads directory was created by user apache:apache. This is the information you needed. Go back down one dir level and set the permissions back to a secure level.

# cd ..
# chmod 755 wp-content

Now for the actual fix. Recursively set the owner and group for your Wordpress installation to the user that created the uploads directory.

# cd ..
# chown -R apache:apache my_wp_blog

You’re done. Wordpress now has access to the file system for photo and attachment uploads, automatic upgrades, and anything else needed by your plugins.

There are several places in the InPlaceCollectionEditor code (controls.js) where document.createElement() is used to add an element to the DOM. In all other browsers, the new elements is implicitly extended with Prototype goodness. In IE7 you have to explicitly extend it.

(Line numbers from controls.js version 1.8.2)

Line 518:

var btn = document.createElement('input'); Element.extend(btn);

Line 527:

var link = document.createElement('a'); Element.extend(link);

Line 542:

fld = document.createElement('input'); Element.extend(fld);

Line 547:

fld = document.createElement('textarea'); Element.extend(fld);

Line 763:

var list = document.createElement('select'); Element.extend(list);

Line 798:

tempOption = document.createElement('option'); Element.extend(tempOption);

Line 841:

option = document.createElement('option'); Element.extend(option);

After these changes, InPlaceCollectionEditor worked flawlessly for me in all major browsers including IE7+.

There are some really interesting options out there for managing sitemaps in rails. Sitemap (http://github.com/queso/sitemap/tree/master) is a full application in itself, with five controllers, three models, and tons of features. There are others that spider your site from the outside, as a third party tool would. And many variations on rake-driven tasks, or other processes outside Rails that must be automated some way or run manually.

Instead of having to run a separate task, here we are going to simply generate the sitemap only when it is requested. If it hasn’t changed, it will be served from the page cache. You may outgrow this technique if you have a very large sitemap, although using a sitemap index (allowing multiple smaller sitemaps) would help quite a bit in this case.

This solution is for people who want to:

1. Customize what gets included and/or updated
2. Stay up to date with frequently changing content
3. Keep the code lean
4. Set it and forget it (no rake tasks)

This article is based on how I implemented sitemaps for subreala.com, however in researching it, I (finally) stumbled on an article by Ilya G in 2006 where he describes essentially the same technique. I decided to go ahead and publish this as an update, since some things have changed in three years, though not as much as you’d think.

The first thing you’ll do is add a route to handle sitemap.xml:

map.connect 'sitemap.xml', :controller => 'portal', :action => 'sitemap'

Then in your controller:

caches_page :sitemap
 
def sitemap
  @pages = Page.find :all
    respond_to do |format|
      format.xml
    end
end

Then use builder to generate the XML. (views/page/sitemap.xml.builder):

xml.instruct! :xml, :version=>"1.0" 
 
xml.urlset('xmlns:xsi'.to_sym => "http://www.w3.org/2001/XMLSchema-instance",
'xsi:schemaLocation'.to_sym => "http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd",
         'xmlns'.to_sym => "http://www.sitemaps.org/schemas/sitemap/0.9"
  ) do
 
  @pages.each do |page|
    xml.url do
      xml.loc page_url(:only_path => false, :name => page.link)
      xml.lastmod page.updated_at.strftime("%Y-%m-%d")
      xml.changefreq 'monthly'
      xml.priority '0.5'
    end
  end
end

Check sitemaps.org for the full spec on the XML elements. The ones used above are reasonable defaults to start with.

The only thing left is to expire the cache when the sitemap should be regenerated.

expire_page(@page.link)

This is the quickest, easiest way to keep your sitemap current if you’re serving a moderate amount of content. The cost of generating a new sitemap is only incurred when the sitemap.xml is requested by a spider and the cached version has expired. If your site grows to the point where you want to use a background task, the above method can be converted to be called from a rake task.

I never did figure it out.

There were two things in that situation I didn’t really understand at the time. The first was that no one else knew how to reproduce that chord either. Fast forward to 1998, when math professor Jason Brown finally unlocked the secret using Fourier transform analysis on the recording. What he found is that in addition to two guitars and bass, Beatles producer George Martin had also overdubbed piano on the track. I guess the band knew how to keep a secret, or did they even know what Martin had done?

The other thing I didn’t realize is how compelling sound itself can be, completely apart from what we think of as music. That chord was a great example. There is no melody, no rhythm. There is just the sound, by itself, apart from any real composition. It stands on its own.

The whole thing reminds me of Eric Tamm’s book on Brian Eno, The Vertical Color of Sound. He quotes Eno naming the grand piano as his favorite instrument:

“I like it because of the complexity of its sound. If you hold the sustain pedal down, strike a note and just listen… That’s one of my favorite musical experiences. I often sit at the piano for an hour or two, and just go “bung!” and listen to the note dying. Each piano does it in a different way. You find all these exotic harmonies drifting in and drifting out again, and one that will appear and disappear many times. There’ll be fast-moving ones and slow-moving ones. That’s spellbinding, for me.”

It was through Eno’s words that I fully appreciated that enjoying sound for its own sake can be just as much a first class experience as enjoying music. Sound, on its own merits, is just as interesting and beautiful as melody, harmony, or rhythm. And it justified what I had always felt in those moments when the “music” parts of music momentarily disappear. What is left in that unstructured space? Just sound.

Thanks to Eric Tamm and his publisher for making his books available online.

Also thanks to Steve Turnidge for turning me on to Eric Tamm’s work.

How To Work Better

1. Do one thing at a time.
2. Know the problem.
3. Learn to listen.
4. Learn to ask questions.
5. Distinguish sense from nonsense.
6. Accept change as inevitable.
7. Admit mistakes.
8. Say it simple.
9. Be calm.
10. Smile.

This made me realize two things.

First, change where you sit. The more the better. It will give you new insights, and help you think better.

The other thing? I really miss having Peter Kappus around, although everyone else at DC is similarly awesome.

def update_soundex
  eval("#{self.class}").sdx_columns.each {|c|
    eval("self.#{c}_soundex = #{self.class}.soundex(self.#{c})")
  }
end

Which I rewrote to use zero evals:

def update_soundex
  self.class.sdx_columns.each {|c|
    self.send("#{c}_soundex=", self.class.soundex(self.send(c)))
  }
end

How did I come up with the first version?

• I didn’t realize object.class returns a Constant which can be used to directly call class methods. (I thought it returned a string.)
• I didn’t understand the power of object.send, which allows methods to be called using strings.

I’m sure if I come back to this in another six months, I’ll find a way to improve it again.

In real life, we don’t usually think that way. We like the advantages of having valuable things, whether they may be bank accounts, passwords, or documents. The truth is, security achieved by having nothing to steal is not really security at all.

Real security is having all that stuff and then actually protecting it.

Which brings me to a strange technical discussion that’s been bubbling around lately. It turns out that a feature built into the HTML standard allows any website to test your browser history against a set of “interesting” URLs and send that information back to their server, associated with your IP address and browser cookie, and of course your login if you have one on that site.

For example, Amazon could (hypothetically, and I’m not suggesting they are doing this) have a list of hundreds of book authors’ web sites and know whether you visit the blog or website of any of them. Your employer could invisibly test you from your home computer against any set of domains they might care to put in a list. This can all be done with javascript disabled (although who does that anyway), and with full security filters on, and on every browser on the market.

Here’s the part that baffles me. Most of the smart, technical people talking about this seem to think it’s pretty much OK. In fact, some blog add-ons for social networking links will peek at your history in order to know which social networks you are actively using.

The prevailing opinion is that it’s a fairly innocent quirk in the HTML standard, that the information gained isn’t really that private, and that you can always just use “private browsing”, clear your history, or turn off history completely.  The widespread description of private browsing mode as “pr0n mode” has led to an almost Orwellian attitude that if you want your history to be private, you must be doing something wrong.

Meanwhile, modern browsers can do some really cool things with history. Chrome and Firefox both integrate history into the address bar suggest feature. Some browsers have history search, and Explorer has had a pretty decent tree view for a long time.

All this stuff is valuable, and it all works without sharing my history with the rendered HTML page. The proposed security solution of disabling history in order to protect it is a lot like protecting your documents or bank accounts by just not having any.

Technically, the fallacy lies here: Existing solutions (like private browsing) are trying to control how history gets into the browser, but no effort has been made to limit how history gets *out* of the browser. Here is what I said in a comment on Vitaly Sharovatov’s blog and has been quoted on Slashdot:

The idea that the only way to protect your history data is to give up keeping history at all seems broken to me. Just because the information is in the browser, and I may use it in other ways, doesn’t mean it has to be used to mark up the rendered HTML on sites I visit. There’s nothing that inextricably ties history to the browser’s rendering engine.

Chrome and the latest versions of Safari have thumbnail screens for your top recently visited sites. Again, cool stuff. But why have new browser features at all if you’ve already decided that reasonable people should all just turn them off?

So, please consider this an open letter to browser vendors. Either you intend for this private information to leak out with no controls, or you intend to fix the situation. Otherwise, your enhancements and features around history information are crippled at best, and pointless at worst.