Some GIF, JS and PNG files also had the wrong extension. Once I realized that was the issue, I made use of this handy little tool, Renamer, to allow me to run a batch rename on the contents of the HTML folder which holds all the template files.

After the file names were fixed, it was just a matter of adding the images that were missing from the default theme and the generated docs were finally legible. Next step, create a custom theme using the default as a base and make these docs a little prettier

1. an 8GB memory upgrade kit
2. Official D-I-Y Instructions
3. Open work area
4. Screwdriver (the Husky HD-74501 works perfectly)

With all the necessities acquired, you can prep your MBP for surgery…

Once the bottom lid is removed, it’s time to remove the old memory…

With the memory slots clear, there’s nothing left standing in the way of the max out. Installation is super easy and should go without a hitch. But, if like me, your hand slips on insertion of the final upgrade chip (top) and you push the chip too quickly and it becomes wedged, don’t panic.

Just remove the little black pressure stabilization post which is likely what the chip is wedged against. Once you’ve done that, the chip should be easily removable. Click the thumbnail for a closeup view.

Once you have both chips firmly seated, you can replace the cover and reconnect all your cabling. Reboot and you should be greeted with the following after selecting About This Mac

Dear Steve,

After reviewing your recent comments regarding Flash and the recent amendments to the Apple Developer TOS, I decided to share with you my response to a few of your positions. First, with regards to 3.3.1, Apple should only do QA based on app quality and NOT on app origin. Are we to seriously believe that an iPhone app built with Unity, Flash, etc. pails in comparison technologically to one built via Xcode? Are we to further believe that there are ABSOLUTELY NO poorly written Obj-C apps in the app store? If so, where are the benchmarks and metrics to support these claims?

Logical decisions are typically made based on data collection in some form or fashion. In the absence of such information, those “logical” decisions are eventually revealed to be more subjective in nature vs. being purely objective. Again, if there is data to support the claims against iPhone apps developed in Flash and compiled to *.ipa, please point us to that data.

Now, as to your assertion that Flash is the #1 reason Macs crash, again, we’d like to see empirical data that supports this claim. Having used apple desktop and laptop computers for more than a decade, I’d have to respectfully disagree with you. I’ve personally experienced kernel panics resulting from locked up processes with non-Flash applications (eg, iTunes, Safari, etc). To my knowledge, iTunes makes no use of Flash but yet it has caused my system to enter into a kernel panic on several occasions. Are we still to believe that Flash is the only big bad wolf lurking in the OSX forest? I seriously hope that’s not your intention. Will your position change when Adobe produces a Flash Player version that takes full advantage of hardware acceleration? I certainly hope so because then we’ll know that you’re truly the visionary tech leader that we all hope you to be.

Does this absolve the Flash development community from doing our part to improve the situation? NO!!! Unfortunately, many Flash apps are created by would-be developers that have no clue about memory management, garbage collection and the like. It is far too easy to create Flash apps that consume all of a browser’s memory, don’t close properly and eventually obstruct a user. But, I submit that this same fact holds true regardless of the language or platform used to create said applications. In other words, sloppy coding is the problem not the technology. This is from the perspective of a developer fluent in several languages including Obj-C and ActionScript.

I understand you have your business goals and a board of directors to please, but I implore you to work with Adobe rather than against them. Work with Google, Facebook and the like to make the future of technology truly open which benefits us all. Ultimately, we MUST support a free market economy in order to achieve this technological utopia, the results of which will be exponential growth that lasts for a millennium. Yes, it truly can be that explosive. The only thing standing in the way is our present day greed for money and power.

I sincerely hope that you soften your stance and work with the other technology leaders to usher us into that state of tech bliss…

P E A C E

Hasan

1. For Eclipse, go to Eclipse -> Preferences -> Java -> Installed JRE
2. For Flash Builder, go to Flash Builder -> Preferences -> Java -> Installed JREs

Then, edit the selected Java VM, adding the following value for the Default VM Arguments field
-d32

This just forces the JVM to default to the 32-bit version. Once that’s been done, that error message should be no more…

The interface is dead simple. You basically have a split view. On the left is your library, filled with a variety of different actions that can be performed. On the right, is your workflow designer. You drag your desired actions from left to right to add them to your workflow. Drag/drop allows you to reorganize them in whatever order you choose. You can test the workflow via automator or you can compile an executable application.

Here’s the workflow I use to backup my the content from my trusty friend, Journler. Journler is a great application and although it’s no longer in production, the latest version is still downloadable and will continue to be supported.

If you want to customize the icon of your compiled application, do the following:
1. Right-click the application in Finder and choose Show Package Contents
2. Navigate to Content/Resources in the Finder window that pops up
3. If you don’t already have a *.icns version of your icon, use a free service like iConvert to create one.
4. Rename your desired icon to AutomatorApplet.icns
5. Replace the AutomatorApplet.icns in Content/Resources with your custom version

NOTE: If you ever need to make changes to your workflow, you’ll have to repeat the icon replacement process since your custom icon will be overwritten.

Whether you’re upgrading because you’re using BETA versions that change rather frequently or upgrading to the next major release, you don’t want to lose all your hard work invested in configuring your setup. Here’s how I handle it and hopefully it’s useful to you. If you have other cool ways to persist workflows between upgrades, please share them.

Workspaces

I’ve created a workspaces folder in a custom directory on my HD where I store all the workspaces I like to use with Eclipse-based IDEs. I separate them by IDE and then by purpose. So for Flash Builder, my workspace hierarchy is like this:

/workspaces
  /_fb4
    /air
    /as
    /flash
    /flex

This is where all of my IDE preferences and workbench layout settings are stored. Centralizing them here allows me greater flexibility when upgrading since I never have to worry about any changes to installation procedures overwriting my custom settings. Nevertheless, I backup my workspaces prior to upgrading and since their small text files it only takes a second to archive.

Documents Directory

On OSX, the Flash Builder installer creates an Adobe Flash Builder 4 directory in your Documents directory. The installation instructions advise you to uninstall any previous versions of Flash Builder before installing the new version. Following this advice will delete this folder if it already exists. So, be sure to back this up prior to uninstalling your current version. That way you can cherry pick anything you need after installing the new version.

Applications Directory

You should also backup up your program installation in your Applications directory for the same reasons as with the folder in your Documents directory. If you’ve heavily modified your install with additional plugins, etc., this is vital!

Plugin Restoration

Where are all my cool plugins? They got wiped during the upgrade process but if you followed my advice and backed everything up, you’ll be back up and running in a minute or two. There are generally (2) locations where plugin info is stored for Flash Builder. If you pull the data from your backups and place them in the following locations, you should have full access to all your plugins post-upgrade (provided they still work with the latest release)

#1 – /Documents/Adobe Flash Builder 4/.metadata/.plugins
#2 – /Applications/Adobe Flash Builder 4/plugins

Although this post is slanted more towards upgrading on OSX, it should be similar for other operating systems. Any issues, let me know…

So, after thinking about my most recent updates, I decided I wanted to change the way that the commit view looks but just slightly. This is my 1st pass on some things I’d like to have available via the toolbar.

Would also like to tweak the view selector buttons, revise remote selection and add toolbar buttons for all the contextual menu items, which aren’t many.

I was pushing some commits earlier this morning and realized that I never made the changes to GitX public. It was always my goal to share the updates with the community but I always kept getting sidetracked. Well, today I forked the master project and even added GitHub integration.

You’ll need the latest version of Xcode to compile from source. If you just want access to the customized application, you can download a ZIP of the forked project and you’ll find the application in /path/to/download/build/Debug/GitX.app. Hope others find this as useful as I have…

1. Duplicate my Flex 3 SDK path
2. Rename the duplicate to flex_sdk_3.x_air_sdk_2.x
3. Download the latest AIR 2.0 SDK (currently AIR20_mac_sdk_120209.tbz2)
4. Place the AIR SDK zip in the root of the new Flex SDK directory

/flex_sdk_3.x_air_sdk_2.x/AIR20_mac_sdk_120209.tbz2

5. Open up Terminal in the new Flex SDK directory and execute the following command:

tar -xjf AIR20_mac_sdk_120209.tbz2

6. Open Flex Builder and add the new SDK -> Flex Builder > Preferences > Installed Flex SDKs > Add

Now, when I want to create an AIR app that targets the 2.0 SDK all I have to do is

1. Update the project compiler settings to use the new SDK -> Project > Properties > Flex Compiler > Use a Specific SDK
2. Update the application descriptor file to use the AIR 2.0 namespace

<application xmlns="http://ns.adobe.com/air/application/2.0beta">

All of the above steps can be repeated for the Flex 4 SDK as well.

For those interested, these are the items that were updated and added to the SDK for 2.0:
/bin/adl
/bin/adt
/frameworks/libs/air
/frameworks/projects/air
/lib/nai
/lib/adt.jar
/runtimes/air
/samples
/templates/air
/AIR SDK Readme.txt
/SDK license.pdf

CAVEATS:

1. There’s a new certificate process started in AIR 1.5.3 that may disrupt your workflow if you’re creating signed applications.
2. If you want to utilize the new native process features, you’ll have to implement multi-platform builds (native installers for Win, Mac and Linux) and these must occur on the target platform (ie, can only create DMGs on Mac, etc)