So to celebrate the release of my first iPhone app (MuniMe, in the app store now , I decided to take a little bit of my spare time away from coding and play around with music again, so I spent an afternoon a few weeks ago tinkering around with my keyboard and Garage Band, and this is the result.

The production value might not be exquisite, but since I’ve been a bit of a purist in the past, I wanted a chance to muck around with different effects and explore beat frequency by overlaying an auto-tuned track with the original (e.g., the last chorus).

And no, this song is not a secret message to anyone. There’s no subtext here. None at all. (You’ll know if this message is directed at you. Don’t call me. Really.)

No related posts.

No related posts.

Not a problem – I had backed up my hard drive en toto, so recovering my addresses and calendars wasn’t difficult… but since a quick google search didn’t return any suggestions, I thought I’d share what I did in case you find yourself with the same need.

note:

~/ = /Users/soychicka/ = my user home directory, just like ~/ = /Users/yourHomeDir/ = your home directory.

Sadly, it appears that although they now have much nicer names, all of my screenshots in Snow Leopard are no more than black boxes of appropriate dimensions…. so that means you’ll actually have to *gasp* read directions (just for the time being).

To recover your Address Book contacts:

Open up two finder windows, one for your backup drive and one for your regular old hard drive that you’ll be using on a daily basis… and go to ~/yourHomeDir/Library, then find

~/Library/Application Support

in both windows.

You should see a folder called

AddressBook

in both windows. Drag the copy of AddressBook on the backup drive into

~/Library/Application Support.

If you dragged the folder into the right location, you’ll see a dialog that asks if you want to Keep the original, Keep Both, or Replace. Go ahead and click Keep both – it’ll keep a backup copy of the original for you in case something goes dreadfully wrong.

Then launch Address Book: you should see all of your contacts happily coexisting once again…well, at least as happily as they co-existed before, as sadly, Snow Leopard was not shipped with the power to resolve family quarrels or workplace personality conflicts.

To recover your iCal calendars:

Open up two finder windows, one for your backup drive and one for your regular old hard drive that you’ll be using on a daily basis… and go to ~/yourHomeDir/Library.

You should see a folder called

Calendars

in both windows. Drag the copy of Calendars from the backup drive into

~/Library/

on your regular hard drive.  If you dragged the folder into the right location, you’ll see a dialog that asks if you want to Keep the original, Keep Both, or Replace. Go ahead and click Keep both – it’ll keep a backup copy of the original for you in case something goes dreadfully wrong.

Then launch iCal : you should see all of your calendars happily coexisting once again…again, at least as happily as work and your personal life existed before, as Snow Leopard was not shipped with the power to add hours to the day and give you a raise.

Unless there was some new setting I forgot to enable…..

Random fact: One of Snow leopard’s new spots is pretty nice: if you are attempting to copy a file that has the same name as an existing one, instead of offering the option of replacing or canceling, it gives you the option of keeping both, and renames the original

Filename (original).
 Although it still doesn't allow you to merge the contents of two directories (hint hint), it's a step in the right direction.   Thanks, friendly apple UX team!

No related posts.

I was looking for a new backup hard drive today, and after becoming frustrated with the lack of usability on the ShopLocal.com, I reverted to switching back to viewing the weekly ads of individual retailers, where I happened to stumble across this perfect example – a weekly ad from Best Buy.

We’ll leave aside the fact that this opened in a pop-up, cosmetic issues and the use of flash for the time being…. What’s key here is that the majority of advertisement content that is of interest to the consumer is below the fold, requiring that the user scrolls down the page to see the content that is of interest to them. And if you look at the next image, you’ll see why.

The layout of the ad is intended to reflects the dimensions of a page in those the traditional weekly newspaper advertisments… the ones that were so unwieldy, where you had to either clear a 3′x5′ space to read on, or make a real effort to keep the paper from flopping over on itself… the ones that have been largely replaced in print by a more manageable tabloid format.

Perhaps the old-style ad layout was selected by the designer to reinforce metaphor of a print ad by as a way to make users comfortable with the notion of viewing an ad online. Or perhaps they are simply unwilling to put their ads in a more usable format in order to force more user interaction with their content in hopes of increasing conversions.

No related posts.

Do you find yourself with a migraine from the incessant *headdesk* associated with trying to figure out why your Radiant app that works so beautifully on your dev box turns into a megaFAIL after you try to deploy it on Heroku?

/*headdesk*/

Wait… are you using any radiant extensions?

Aha! Something isn’t explicitly clear in the vast majority of documentation on Radiant extensions: when you install an extension using ./script/extension install extensionName, you’re actually installing the extension as a submodule.  There are some good reasons to install an extension as a submodule: it’s super-easy, and it provides an easy way to update your extensions when the master branch has been updated.

But there is one very good reason NOT to install extensions as submodules: at this time, Heroku doesn’t support the use of submodules.  So that means even if you’ve followed the instructions and gotten it to work in your development environment, once you deploy to Heroku, the extensions disappear.  No listing in the admin panel, no files in your extension directories, everything is broke-ass, and….  /*headdesk*/

So what to do?  Most offering advice recommend that you find a way around this by installing the extension “normally”.   But what is ‘normal?’

We’ll install the Settings plugin as an example, since it is fairly lightweight and provides some functions that would likely be useful for most installations.    Here goes:

Manual path to installation:

will download a file that looks something like

Squeegy-radiant-settings-someOtherStuff.tar.gz

Extract and rename the file and delete the tarball:

Since you’re integrating the extension into the app, you need to… uh… integrate the extension into your database.

Start your server using

and make sure that the settings tab is visible in the admin interface… if not, something didn’t go right.

Now comes the fun part:

making it work on heroku.

Cue choir of angels, and set aside the excedrin: if you check out your app’s admin interface on Heroku, it should now be blinged out with a new tab for your settings extension.

No related posts.

This tutorial assumes that you have already installed and configured the following:
- Rails (2.3.4)
-  Git (1.6.4.1)
- Heroku gem (1.3.0)

Specifically, it also assumes that you either a) have configured an ssh keys for use with git, or b) know how to deal with it if you haven’t.

If you don’t meet all of the above criteria,  get crackin’… but once you’re ready, read on.

Install gems:

You’ll need, at bare minimum, the radiant (v0.8.1), taps (v0.2.19), and rspec (v1.2.9) gems.

Create your app

This step automagically creates your Radiant app, and spits out the names of the files it creates followed by a set of instructions for completing installation. Ignore what you see there and follow these instructions instead.

Create your database

This will set up the necessary database structure in your local install. There are a few options you’ll need to select:

Get git

Initializes your new git repository.  If you don’t get git, get it here

Make caching Heroku-Friendly

In your environment config file (config/environment.rb), you need to update the cache configuration. Heroku’s file system is read-only, so all cache must be written in the tmp directory.

replace config.middleware.use ::Radiant::Cache:

Let Heroku know what gems you need.

Since direct access to the command line is not available on the heroku server, create a .gems file to let Heroku know what gems (and what versions of the gems!) are required for your app. When you push your project, the required gems will automagically be installed for you.

Check in

Deploy!

The returned lines will include the url for your new app, and the address of the git repository pushed to heroku.

is what you should see if all goes well.  You can see that the server was started, so you’re almost ready to go.  But first, you need to…

Push your database to Heroku

is what you should see if all goes well here.

At this point, your app should be live at the url you received when deploying.  Make sure to check it out before tinkering with anything…  and then you know that you have a safe starting point to return to when you have caused what otherwise would have been irreparable damage to your app.

On that note, I’d recommend taking advantage of Heroku’s new Bundles feature that lets you create an archive (tarball) of your application code repository and a dump of the database. By default, the bundle is stored on the Heroku servers, but you can download the bundle to your local machine, keep one  or more on Heroku (, upload bundles from your local machine and re-animate a bundle with the “heroku bundles” commands.  You can get one bundle for free, or unlimited bundles for $20/month.  The re-animation process seems a little wonky for the time being, but it’s a good option if you want to unabashedly tinker with abandon (and without fear).

So there’s a simple installation path for deploying a standard Radiant application on Heroku.  Play around with your install and see if it suits your needs.

Heads up, though: if you want to install extensions in your Heroku-deployed app,  there is a custom path for that too!  Using the built-in ./script/extension install extensionName doesn’t play nicely with heroku – it installs the extensions as submodules, which are not supported by Heroku at this time.

No related posts.

Milk that has started to spoil may no longer be drinkable, but you can still use it up in cooking and baking without much to-do.

You might want to note, however, that milk tends to become more acidic as it ages. This normally isn’t too much of a concern to our stomachs, but if you’re using it for baking, you might want to fight off the acid using a pinch of baking soda.

If you’re using it to make any breads with yeast, I suggest tossing a pinch of baking soda in with your warm milk before measuring and adding the yeast. That gives the baking soda a few seconds to work its magic, and the yeast won’t be ‘injured’ by the shock of an acid bath. And with older milk, you might want to consider adding a little more sugar or honey than the original recipe calls for when proofing the yeast.

You might even be able to extend the life of a carton of milk by adding a pinch of baking soda a few days after purchase… by restoring the pH of the milk to its more alkaline state, you can help to ward off hungry bacteria that need a lower pH to thrive.

Of course, this won’t save that 2-month old carton of milk that mysteriously emerges from behind the orange juice and under the lettuce in the back of your fridge… but hopefully it will give you a way to use it up before then!

—- random facts for food geeks —

The optimum pH for the growth of yeast is right around 7… and fresh milk usually comes with a pH around 6.7. But spoilt milk can get down to pH 4.4, making for some very unhappy yeasties.

More milky geekery can be found at:

http://www.ilri.org/InfoServ/Webpub/Fulldocs/ILCA_Manual4/Milkchemistry.htm

No related posts.

In case you need to modify your httpd.conf on your local system and restart apache, but you can’t bear the thought of 20 seconds downtime when you could be getting back to …. the important stuff.

No related posts.

While some sites continue to grow organically, attracting users by word-of-mouth and link-of-google for the limited content they already have, a new practice has been spreading like the plague for sites that seek to obtain user-contributed content (UCC): ‘data’ scraping.

My personal opinion: the only time it’s okay to scrape data is when it’s actually “data” – e.g., addresses, events, etc. Scraping conversations or articles – content that people took the time and energy to craft – even though it may be legal, just isn’t right. But I’ve come across this practice with increasing frequency over the past few months… and every site I’ve come across that engages in this practice or -even worse – uses it as their business model – has been put on my blacklist (e.g., BigResource, etc.).

Reasoning? It takes 10 sec. for a page to load. After I’ve seen 6 pages in a row that have the same exact content, I’ve wasted over a minute of my life, and want to throttle someone. And when the first 3 pages of results on google are all links to the same two pieces of content, it makes me want to run down to the Googleplex, and defeated, drop to my knees, and bang my fists on the ground, while crying “Why, Sergei, Why?????”

Okay, it’s not quite that bad… but it wastes my time, and chances are, will frustrate your user. And since first impressions are the ones that last, if the first impression a user gets of your site is one that makes them vow not to use your site again, you’ll end up far less successful than if you were to wait and allow your content to grow organically.

A better option: look for topics that haven’t been covered elsewhere (or at least topics that aren’t easily found through google), and ask and answer the questions yourself (maybe even using a different account so it looks ‘real’) with a mind towards SEO. Because if you don’t have any value to add to the space other than aggregating or snagging content from other sites, why would a user return to your site instead of the originator?

No related posts.

According to Pablo Livardo’s blog, Dreamweaver will always try connecting to the svn repository when booting up before allowing you to do anything… and it might hang for 10 minutes or so before it gives up and completes loading.

While you could try to figure out what the problem is, sometimes you just don’t care. In my case, I hadn’t made any changes to my svn repository, and I discovered my svn host was simply down.

Easy solution: disconnect from the network, then launch dreamweaver again. If, like me, you only rely on subversion for checking in major changes, you should be on the road again in a couple of minutes.

No related posts.