Adobe Muse is it worth a go?

Back in November 2011 I drafted a blog post on Adobe's new beta, Muse, a designer oriented program to foster an ease of website production for the print media designer. I get it, heck 10 years ago Dreamweaver had layout mode  and I was a fan - draw it, make it happen - no code, no fuss. If I never have to layout a webpage again, that would be fine with me. Well, my first look didn't get me very excited. In fact, I was pretty much ready to flame it and I chose to hold off. It was the holiday season. I didn't want to wind up on Santa's naughty list  and everyone knows you shouldn't bust out the can of whoop-ass around turkey time, it just doesn't go well with the stuffing and the gravy... I hit "Save Draft" and moved on...

Well, it's nearly March and I hate March. Ready to fire away, I just looked over the most recent public beta of Muse (Version 6) and well, there may be some hope, but I'm not counting on it. Below is my original draft of this post along with some updates based on the latest info. Heading in the right direction? Maybe. I don't know when the release date is scheduled and what's next on the road-map so the jury is still out.


Here's what i don't like so far:

  • It's xhtml, not html5 - you're kidding right? after this weeks announcement on adobe's orientation to html5 and emerging web standards? i was so shocked, i almost yelled at firebug when i inspected the page - "you're a liar, firebug!" but it never lies, and it wasn't lying this time - it's old html, and it didn't even validate update: Muse does appear to be generating html5 now, but so far, all i see is the html5 <doctype> / <html> tag - not one single semantic tag for html5 - <header>, <section>, <article>, <aside>, <nav>, <footer> - not one of them appear in the content - so while they can technically say "it's html5", what's the point, really?
  • Kinda obvious after the first point, but guess what - i looked at the Muse showcase websites on mobile devices - and you guessed it, they look terrible. OK, Maybe they don't all look terrible, some looked good and most were lousy and some where unusable. (an entire navigation div was hidden in one case). Now, mobile rendering of content is no picnic, but they don't even have a <meta> tag to set the text scale to 1. difficult or not, mobile is driving the market place right now and it's a big hit to the value proposition of muse if it's not addressing mobile rendering.
  • <div> hell & "class-itis" - well, this is usually a maintenance issue, but since a generator is doing all the work, who cares...My only concern is the massive amount of html & css needed for the rendering which simply can't be efficient for our mobile device friends. oh, maybe this thing is never gonna fly for mobile rendering. ouch.
  • jquery 1.4. WTF? This product is in beta, why wouldn't it be hanging right on the edge with the most recent stable version? update: It's using jquery 1.7 now
  • CSS reset ISO normalization method. again, old school. bummer update: looks like they are using CSS normalization now.

what's not so bad:

  • binding events is happening declaratively (from scripts, not the html tags) so that's good. despite the hellacious nesting of divs and class names up the wazoo, there isn't any embedded events for rollovers, etc...

Long story short - why bother? I got all excited watching the Adobe TV video about the product - the testimonials from the team ("We are so psyched", "Muse is gonna be great") had me charged up! I'd say it would have been a great tool if they rolled it out about 5 years ago. I actually looked to see if this was really an old beta product that got orphaned on adobe labs - perhaps I was simply looking at an archive? Nope, it's real, it's now, and it's not that great. If that puts me on the naughty list, oh well, it won't be the first time.

Making Symlinks to a Directory Work in Dreamweaver CS5.5 on Snow Leopard: Hard Link Style

NOTE: This post is about symlinks and hardlinks as they relate to Adobe Dreamweaver CS 5,5 running on Mac OS X 10.6+ but also applies to very earlier version of Dreamweaver. ALSO NOTE: This technique totally works but be super careful. There is a reason links are treated in special way.

They work in every other IDE, but symlinks do not work in Dreamweaver. I'm sure there must be a reason, but I almost don't care. I want them to work so I can deal with directory structures that use them.

Scroll down to the SOLUTION to bypass all my comentary.

In general, symlinks can result in circular dependencies that can really mess things up but then again, programmers write infinite loops sometimes and seem to resolve them, so what gives Dreamweaver?

I came across this issue when researching sencha touch and making my way through a webinar. The presenter recommended a symlink for linking to the main API and it clicked - how perfect. So I stopped and configured my directory structure the same way and then looked at it in Dreamweaver :(

Dreamweaver hated this and instead of showing me the directory's content, it told me it couldn't find an editor for the file. Ugh.

Hard Linking vs. Symlinking / Shortcuts

A symlink is like a shortcut in Windows without the terribleness of Windows. Windows adds .lnk to the shortcut and doing so prevents the usefulness of treating the shortcut as if it were the actual file or directory.

To create a symlink, run a command like the one below:

$> ln -s /Users/scoobydoo/lib/apache-commons/commons-lang-1.2-4.jar commons-lang.jar

This creates a symlink (notice the -s) to commons-lang-1.2-4.jar named commons-lang.jar. This allows me to swap out different versions of commons-lang yet always refer to it as commons-lang.jar. For the record, that's probably a terrible idea, but you get my point.

Dreamweaver doesn't like this. In fact, it's quite hillarious what Dreamweaver actually does. If you open this link in Dreamweaver, it actually shows you - in a text file - the path to the linked file. Well, that is just cute. Useless, but cute.


Hardlinks: A hardlink isn't really a shortcut but rather a direct link to a file's actual inode. Generally speaking hardlinks are not possible to directories, but Mac OSX allows it. Unfortunately it provides no means to actually make the link...big sad face.

With a hardlink, if you delete the "original" file, any hardlinks that were created still point to the inode, which means that the location in memory can still be accessed.  That's because deleting a file really translates to "unlinking a file." This is referred to as "awesome."

Let's try it out:

$> mkdir t $> cd t $> mkdir lib $> touch original.txt $> cd lib $> ln ../original.txt copy.txt $> cd .. $> rm original.txt $> cf lib $> ls

You'll still see copy.txt because copy.txt does not link to original.txt, it "points" to the inode that original.txt pointed to. Typically, this only works with files and not directories.

Dreamweaver is fine with hardlinks because hardlinks in a way, aren't links, they are just files that point the same location as another filename.

The problem we are left with is how can we create a hardlink to a directory so that Dreamweaver won't flip out?

Easy, write a tiny C program. For real.

Greg Miller wrote pretty cool article Exploring Leopard with DTrace: How to use DTrace for debugging and exploration that includes the code I'm about to show you.

Copy/paste this code into a text editor and save it as hard-linkd.c (or something else).

#include <unistd.h> #include <stdio.h> int main(int argc, char *argv[]) { if (argc != 3) return 1; int ret = link(argv[1], argv[2]); if (ret != 0) perror("link"); return ret; }

To compile it:

$> gcc -o hard-linkd hard-linkd.c -Wall $> cp hard-linkd /usr/local/bin

Now you can use hard-linkd to hard link to a directory and make Dreamweaver happy.

$> hard-linkd src-directory dest-directory

I did this. It works. All is right again.

SFTP Connection Problems from Dreamweaver: Cannot Make Connection to Host

If you were once able to connect to your SFTP server from Dreamweaver but now suddenly you cannot and the error message is something useless like "An FTP Error Occurred - Cannot Make Connection to Host" then the likely cause is that the servers ssh host key changed. Why?

In my case, our hosting company built us a new VM and when we were ready to start using it, they reassigned the same IPs from the old VM to the new VM. We took this approach instead of changing the DNS entries because it would be less disruptive to our clients.

The problem is the SSH host is different and therefore the SSH host key is different. You can verify this by opening your SSH client and connecting to the new server (with the same IP address or host name). When the SSH client sees that the host file is changed, it presents you with a message asking you to accept it. As always, once you accept it, it adds an entry to your known_hosts file located in .ssh/known_hosts if you're on a Mac/*nix and somewhere else if you're on Windows.

This enables all SSH clients to work fine with your new host...except Dreamweaver. Dreamweaver, as it turns out, maintains it's own ssh_hosts file that needs to be updated and it WILL NOT tell you. It will simply "fail to connect" when it sees that the host keys don't match and like a freshman programmer, gives you no reason as to why.

On Mac/*nix the file is located in:

/Users/ Support/Adobe/Dreamweaver CS5.5/en_US/Configuration/ssh_hosts

Or, if you're using an old version of Dreamweaver somewhere in the Application Support folder. Look around, you'll find it.

DELETE IT! Or, remove the offending entry, like I did.

All better. Hope this helps. I plan on submitting a bug to Adobe.

Downgrading Subversion for Dreamweaver CS4: Or Just To Do It

We use subversion everyday to manage updates or other changes to our projects but one problem I encounter from time to time is conflicting client versions on the same machine. Normally, this shouldn't ever happen but it will happen in several scenarios. One example is when I use the command line on my Mac to perform an initial checkout or checkin and then switch over to Dreamweaver CS4 to manage day-to-day updates. If you want to know the version of subversion your system uses, the following command from your terminal:

svn --version

As you can see from the screen shot above, the version I am running is 1.6.16.

Dreamweaver CS4 does not run subversion 1.6.16. It runs version 1.4.5. Why it doesn't just use my system's svn program is beyond me but since 1.4 is incompatible with 1.6, something's got to give.

A quick mention about Dreamwaver CS5.5: It uses svn version 1.6.9 and since 1.6 is the most recent release - as of this writing - you won't have to worry about downgrading.


Download this Python script from Apache that you can run to change the metadata version. I'm saving it to my desktop so if you just want to copy/paste, do the same.

Run the script with --help flag for information on how to run it.

To change the version for your project, run the following command:

python ~/Desktop/ . 1.4

The dot between the command and the 1.4 is the path to the project under version control. Since I was in the root directory of my project when I ran the command, the path was simply a dot. 1.4 is the version I want the project svn converted to.

That's it. Switch to over Dreamweaver and you're now free to commit and perform other svn commands on your site.

More Information

The incompatibility issue is no secret. Both Apache and Adobe have pages devoted to working around it. check out the pages below for a more detailed explanation.