Karoshi Ethos

This is well trod ground, but I didn't find a lot of really basic info about what to do, what not to do, and generally how to get your feet wet with SVN, and what to do when suddenly you're up to your neck. I'm certainly no expert on source control, but sometimes a fellow beginner can explain things more gently.

The first hurdle is getting the plugin(s) installed. I'm personally not sure which are best. Try them for yourself and see. At the time of writing, here are the Eclipse update URLs to add for installing several SVN-for-Eclipse clients. I like the subversive icon set on the Team menu specifically, so I'm including it even though the download site was an absolute pain. I had to download to my local drive first. Your mileage may vary.

• http://eclipse.svnkit.com/1.3.x/
• http://subclipse.tigris.org/update_1.6.x
• http://download.eclipse.org/technology/subversive/0.7/update-site/ (if it works for you, didn't for me) I downloaded from:
• http://www.eclipse.org/downloads/download.php?file=/technology/subversive/0.7/builds/Subversive-incubation-0.7.8.I20090904-1300.zip">Subversive-incubation-0.7.8.I20090904-1300.zip

Here're those pretty icons. I like them because they help remind me what direction the operation goes in. "Update" Does that mean update my stuff or their stuff? "Commit" Which direction is that?

1. Go to the Window Menu >> Software Updates
2. Go to the "Available Software" tab
3. Add Site
4. Enter the URL or local hard drive path
5. Click OK
6. Click the Refresh button on the list of  update locations.
7. Wait for Eclipse to do its thing.
8. Check off the subclipse, subversive, and / or svnkit bits you'd like to install.
9. Click the Install button.
10. Restart Eclipse.

Next hurdle is getting logged in. If you're also setting up your first SVN server, best of luck to you. We're not covering that here today. You probably want to be familiar configuring an SVN client before you try setting up a server as the access control can be really tricky, especially if it's remote, which, usually it is.

Window >> Show View... >> Other... >> SVN Repositories

Right-click (Control-click Mac) >> New

Set yourself up a connection with the URL, username, and password provided by your system administrator.

Say a prayer.

With any luck, you'll be browsing the project tree!

Checking out a New (to you) Project

Browse to a project you'd like to check out in the SVN Repositories window.

Right-click (Control-click Mac) >> Check out

What you select from here depends on whether your team members have agreed to share their entire Eclipse project workspace (the second bullet) or if individual team members are managing their own Eclipse projects on some level (the default bullet). Confer with someone already on the project.

Click Finish!

Take a moment and look at the SVN Settings for icons in the Explorer view. You'll actually learn a little about the terminology you'll soon master, and begin to be able to recognize the state of a file by glancing at it's icon and know what step needs to be done next.

Eclipse Menu >> Preferences... >> Team >> SVN >> Label Decorations

Go to the Icons tab.

If you toggle the checkboxes back and forth, you'll be able to see which labels go with which icons. This is really useful to know.

Adding a New (local) Project to the SVN Repository

Chances are, if you're just starting, your first project already exists, and you can skip ahead for now. If not:

Right-click your main project folder in the Explorer view >> Team >> Share Project

SVN >> Next

Choose your repository >> Next

I think "Use project name" is best. Next

Get used to entering comments that describe what you're checking in. This dialog gives you the opportunity to do that. It's probably pre-populated with something brief about sharing this project.

Click Finish!

The project will be analyzed and you'll be given the opportunity to de-select any files you don't wish to add to the repository.

Once the files are successfully shared via SVN, your files' icons should change to reflect their state with respect to SVN. This comes in handy. You'll also see a version number appended to your filenames. You can modify details in Eclipse preferences.

Adding a New (SVN) Project to Your (local) Workspace

Use the SVN Repositories view to browse to the project's root folder.

Right-click and choose "Check Out"

If you already have a project at the default location, you'll be asked to reconcile conflicts / overwrite files. Otherwise, you should have a brand new project in your workspace!

Getting the Latest Updates

Ok, someone's made a change to files you've previously checked out, and you need to update your local copy.

Always do this before making changes (see the next section). It will keep you and the rest of your team from spending a lot of time in the last section.

Right-click the project folder >> Team >> Update

Commits - Making Changes

You've changed some things, and you're ready to check them into the repository.

Right-click the project folder >> Team >> Commit

(It also doesn't hurt to update again after a commit.)

Adding Files

Some SVN clients require you to "Add" files to the repository before you "Commit" your changes. It's a bit like when you "add," you only add an empty entry. It's the commit that sends the data. This separation keeps you from thinking you're adding a brand new file, when in fact there's already an existing file with that name in the repository. Eclipse's plugins seem to handle this automatically.

Deleting Files

Delete the file(s) as you normally would.

Perform a commit on the containing folder. SVN should detect the change and update the remote repository.

When Things Go Wrong (and They Will)

I can't Update because I've got a conflicting Local File.

(or)

I can't Commit because there's a conflicting Remote File.

Sometimes, the conflicting changes can be (and are) resolved automatically. Sometimes, it'll require more manual effort. The parent folder will have some new files with names based on the one having a conflict.

MyClass.as (your local working copy -- it probably contains some diff comments now)
MyClass.as.mine (an untouched copy of your local version)
MyClass.as.rVERSION_NUMBER (the last good copy known by both the local machine and SVN)
MyClass.as.rVERSION_NUMBER+ (SVN's latest copy)

If you don't see these in your Explorer view, right-click the parent folder and choose Refresh.

Still nothing? Do an Update and repeat.

There should be enough here to help you resolve the issue and no risk of loosing anything.

Edit MyClass.as so that it contains whatever you now believe to be correct. You can use Eclipse Synchronization perspective, an external diff / merge tool (I like DeltaWalker), or the standard Eclipse editor.

To use Eclipse's tools, Right-click the file with conflicts >> Team >> Edit Conflicts

The local working copy should appear in a left pane with the most recent repository version on the right. The goal here is to get the local working copy to contain the "correct" code. Merge anything from the SVN version on the right that should be present in the new version. (Eclipse will not allow you to make any edits to the SVN version.) When you're done, Save. Close the Edit Conflicts tab. Your changes should migrate to the local working file. Note: If you Edit Conflicts again (before Committing), you may loose the merges you made the first time. This is a bug or a feature depending on how you think about it.

I set up a custom DeltaWalker launcher shell script as an external diff / merge tool. Let me know if you'd like to try it. I doubt there's much (any?) functionality that isn't available in Eclipse's Edit Conflicts, but I really like DeltaWalker's GUI, color scheme, etc.

Right-click the file >> Team >> Mark as Merged (or Mark Resolved...) Click Ok.

Immediately Commit changes! You aren't finished resolving the conflict until you do so!

The Three-Way Merge

What you've probably worked with so far is a two-way merge. SVN also keeps track of the latest known good ancestor to those two files. In the Edit Conflicts view, click the icon in the toolbar to enable this pane. I rarely find this necessary, but it's good to know it's there if you need it.

I've been using FDT for awhile, and convinced the project manager on a new job to purchase licenses for the whole team. I'd not used FDT in a team environment before, let alone with FDT / Eclipse noobs. That makes me the de-facto expert, and I was asked how to import a project I sent over. I'd assumed there was just a menu item for that, or it was a google-able thing. Well, you know what they say about assumptions.

I'm going to include export directions for completeness, but I imagine you could just zip up the whole project folder and get away with it in many cases. Using the export feature will capture source libraries located outside the project folder in your filesystem hierarchy and give you the opportunity to select/deselect the ones you specifically want included/excluded. With great power comes great responsibility!

Exporting

1. Right-click your project in the Flash Explorer. Choose "Export..."
2. Choose General >> File System
3. Click Next.
4. Choose a directory to export to. A top-level folder will be created within it having a name matching the project name.
5. Deselect any libraries (etc) you specifically want to exclude from the project tree. Coordinate with your team members!
6. Click Finish.

That covers exporting the project and any source libraries you want to package with it. One thing remaining -- the launch configuration(s) -- those settings cover what classes get compiled into what swf files, custom compiler arguments, etc.

1. Right-click your project in the Flash Explorer. Choose "Export..."
2. Choose Run / Debug >> Launch Configurations
3. Click Next.
4. (Your choices here depend on how you've been using FDT.) Expand "FDT AS3 Application" and select the appropriate file(s).
5. Browse to the same folder you selected in step 4 of the project export process above.

Importing

Before you begin, especially if you're following along and you've just done this on your own machine, be sure you don't have an existing project with the same name as the one you'll be importing. Eclipse will complain: Some projects were hidden because they exist in the workspace directory. To change it:

1. Make sure the project is open. (You can't rename a closed project)
2. Right click the conflicting project.
3. Enter a new name.
4. Click OK.

Eclipse will do all the hard stuff for you.
Now to do the actual importing.

1. File Menu >> Import
2. General >> Existing Projects into Workspace
3. Click Next
4. Browse to the exported project folder and select it.
5. Eclipse will list all the projects it finds within. Verify the one(s) you want is/are checked.
6. Personally, I check off "Copy projects into workspace" at the bottom. Make sure you don't have any conflicting projects with the same name. See above. It's helpful to understand Eclipse workspaces when deciding which is best for you.
7. You should now have a new project in your workspace.
8. Ideally everyone on the team will want to use the same project name. Change it using the instructions above.
9. Project Menu >> Clean...

Import your Run Configuration file using the same steps, but you'll probably want to read the next section first.

Mangled Run Configurations

If you don't do this, you will likely have problems with your Run Configurations and have no easy way to fix them or any reasonable explanation what's wrong (Null Pointer Exception). For your reference, the original launch configuration files are located in:

{workspace}/.metadata/.plugins/org.eclipse.debug.core/.launches/{PROJECT_NAME}.launch
Edit the line that reads: <stringAttribute key="PROJECT_NAME" value="MODIFY_ME"/>

I really wish this were part of the project export...

Comments on this article are particularly encouraged. If you find a better technique or an inaccuracy, please let me know!

I've been looking for a way to force "Same JRE as Workspace" as the default in my ANT build targets under FDT / Eclipse. I haven't figured it out yet, but I finally found where this setting is stored:

Remove the entries for org.eclipse.jdt.launching.JRE_CONTAINER & org.eclipse.jdt.launching.MAIN_TYPE, and Eclipse should use the workspace's JRE.

I'm sure someone could take this information and throw together a plugin / fix? The powerflasher team would honestly make the best candidates. (Hint! hint!)

Add -verbose-stacktraces=true to your mxmlc compiler arguments to get the line number of the dreaded "Cannot access a property or method of a null object reference."

How have I been programming ActionScript 3 for this long and not known this?

Continuing in the vein from yesterday, I wanted to post some findings about a great little utility called TTF2EOT. It's an open-source alternative to Microsoft's WEFT, which I'm not even able to compare it to because it crashes before I can export the first font! That's fine, I didn't want to use it anyway (I want to run on OS X for example).

The first issue is that you might want to convert an OTF (OpenType) font to EOT. TTF2EOT won't give you an error, but I wasn't able to get the outputted file to work. (Comments?) No problem, FontForge handles this nicely. You can even script this process so it's available from the command-line. Awesome.

So TTF2EOT should work now, right? Well, perhaps. It didn't for me with the font I'd chosen. I'm sure it varies greatly. I did some troubleshooting with FontForge and TTX and eventually determined that there was a problem in the resulting TTF's name table. If you don't get this part just right, you can expect problems with all sorts of downstream utilities, including the one we care about: TTF2EOT (which will fail silently. Very helpful.)

Paraphrasing O'Reilly's Fonts and Encodings here's the magic recipe to fix incorrect name tables with TTX.

Here's an example excerpt:
<namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
MyFont Std
</namerecord>
<namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
Regular
</namerecord>
<namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
UniqueID
</namerecord>
<namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
MyFont Std-Regular
</namerecord>


The "font family name" in nameID 1 added to the "style" in nameID 2 should match the value in the "complete name" in nameID 4 (separated by a hyphen). NameID 6 is the "postscript name." I use the value from nameID 4.

EOT files run on Windows, where usually the following Windows-specific entries would be required as well. If I'm just interested in generating EOT outlines, I've had luck omitting them.

<namerecord nameID="16" platformID="3" platEncID="1" langID="0x409">
MyFont Std
</namerecord>
<namerecord nameID="17" platformID="3" platEncID="1" langID="0x409">
Regular
</namerecord>

I simply use the values from nameID 1 and nameID 2. You may have noticed a change of platformID, platEncID, and langID. Those refer to Windows, Unicode, and American English respectively.

To repeat, if you just want EOT outlines, I've had success with the minimum block including nameIDs 1, 2, 3, and 4. If you actually care to use the resulting TTF for anything else though, I highly recommend using the "full set", which I'll go out on a limb and specify as nameIDs 1, 2, 3, 4, 6 (PostScript Name), 16, 17, and 18 (Mac Family Name). In addition, you'll want to duplicate all namerecord entries using the following attributes:

Unicode, Version (use 0 or 3), and Language (supposedly unused, but TTX fails without it)
platformID="0" platEncID="0" langID="0x0"

Mac, Roman, and English
platformID="1" platEncID="0" langID="0x0"

Windows, Unicode, and American English
platformID="3" platEncID="1" langID="0x409"

I haven't (and can't) test every combination, so I'm not sure if including a malformed "optional" record would cause the output to fail. It's probably possible.

Again, I don't know whether the problem lies with FontForge (at the OTF to TTF conversion step) or the name table in the initial font. I have a feeling I'll find out.

I've been doing some deep font science as have a bunch of other folks, both with flash and without.

If you want to play along, I highly recommend, O'Reilly's Fonts and Encodings. It's the business. Be careful though -- it's a monster. Check with your local laws concerning weapon permits, etc. Also proven effective as a powerful sleep aid!

One of the many useful utilities thoroughly discussed is TTX, an extremely powerful font decompiling / recompiling tool. In short, it allows you to dump TrueType and OpenType to XML, make modifications (or inspections), and roundtrip back into a working font again.

So I'd been playing with this and FontForge, and if you manage to screw up a font so it's unusable, you'll get used to Flex giving an error like:

/Users/projects/externalFontLibrary/src/classes/EmbedFontLibrary2.as(14): Error: exception during transcoding: The font file:/Users/projects/externalFontLibrary/mxml/fonts/MyFont.tff is not usable.

[Embed(source="/Users/projects/externalFontLibrary/mxml/fonts/MyFont.ttf", fontFamily="MyFont", mimeType="application/x-font")]

/Users/projects/externalFontLibrary/src/classes/EmbedFontLibrary2.as(14): col: 3: Error: unable to build font 'MyFont'


I'd gotten so used to it, in fact, that I managed to overlook a subtile difference in error message for a font that had actually exported correctly:

TTX will generate unique names for its output files so it doesn't accidentally overwrite an original. You'll end up with filenames like: MyModifiedFont#1.ttf

So, let's try plugging that into our ActionScript class to embed outlines:

[Embed(source="/Users/projects/MyModifiedFont#1.ttf", fontFamily="MyFont", mimeType="application/x-font")]
private var myFont:Class;


To which Flex replies:

/Users/projects/externalFontLibrary/src/classes/EmbedFontLibrary2.as(14): col: 3: Error: transcoding parameter 'symbol' is not supported by 'flex2.compiler.media.FontTranscoder'

[Embed(source="/Users/projects/externalFontLibrary/mxml/fonts/MyModifiedFont#1.ttf", fontFamily="myFont", mimeType="application/x-font")]

/Users/projects/externalFontLibrary/src/classes/EmbedFontLibrary2.as(14): col: 3: Error: Unable to transcode /Users/projects/externalFontLibrary/mxml/fonts/MyModifiedFont.


Maybe you've got a sharper eye than I do, or maybe you're just more clever. In any case, I saw my compile fail and didn't look closely enough at the details. And the days that became weeks! It never did dawn on me (until today!) that the mysterious "symbol" parameter was the result of the pound symbol ("#") in the filename! After a rename to remove it, everything works awesomely!

Looking forward to talking about this more. I'm still looking into similar problems that can occur when exporting fonts from FontForge and ttf2eot Online typography is really heating up right now and I'm hoping to assemble some useful developer tools, or at the very least cobble together a workflow I can count on.

Recently, Blogger began appending a tracking gif to the content of each entry in their Atom feeds. The URL used in the image src uses https, most likely to avoid warnings when it's rendered in a https context. For some reason, when rendering the feed content containing the tracking image, the Flash player can crash, taking the browser with it on certain platform/browser combinations. We found the problem in FireFox 3.0 on OSX, but only on PPC Macs. Go figure.

In our case, we are proxying the Atom feed through a PHP script so we can display the feed contents to user agents without the Flash player. This made it fairly easy to iterate through the entries, and with a simple bit of regex, strip out the offending markup from the contents.

Blogger is wrapping the image tag in a div with a very specific CSS class, which makes our job easy:

Depending on what you're using to parse the feed, you may or may not need to be concerned about decoding and encoding html entities during this process.

I just ran across a really annoying problem with Thickbox after upgrading from jQuery 1.3.1 to 1.3.2. The gallery functionality in Thickbox broke after the upgrade - instead of opening with the first image, the loading animation displayed forever without loading any content at all.

Turns out, the @ selector syntax was deprecated in jQuery 1.3, and was removed in 1.3.2. Simply removing the single occurrence of the @ character in the Thickbox js solved the problem.

I knew you wouldn't believe me, so I made a movie to prove it. This is on a macbook pro 15" with a 24" cinema display. The dock and menu bar are running on the laptop display. If I mirror or move the dock and menu bar to the external display, the problem disappears! If I plug it into another external display, it does exactly the same thing.

ClipStation is a free lightweight solution for writing to your user’s clipboard from an HTML page. Using a small SWF that is embedded dynamically via JavaScript, you can pass an unlimited number of content clips onto the clipboard.

ClipStation is designed to be lightweight, flexible, and easy to implement. What makes ClipStation different from other clipboard SWF solutions is the ability to decode HTML character entities, allowing you to pass complex HTML markup to the clipboard from within form elements, divs, pre tags, etc. We developed ClipStation for use on a widget sharing page we've implemented for a client. After looking around for a good lightweight cross-browser solution and coming up empty handed, we decided to build our own. We're now happy to offer it to you at the low, low price of free.

Version 2.0 includes changes to allow access to the clipboard in Flash Player 10. Adobe changed the security requirements for clipboard access in version 10 of the player; now a user action is required before a SWF may access the clipboard. Instead of using a single hidden instance of the ClipStation SWF, we embed an instance for every clip that the user clicks to perform the clipboard copy. A source distribution is available, so you can change the design to fit your needs.

More information and the release package can be found at thirdpartylabs.com/clipstation/

»Download ClipStation 2.0