NerdBeach

Thanks to Mountain Lion, Save As is Back

There were a lot of things that I liked about OS X Lion. I won’t go into a list of the pros here, but I will be more than happy to mention one very large con – the loss of Save As. But even as I complain about the loss, I am happy to announce that, what Lion took away, Mountain Lion brings back. Yes, Save As is back again on an OS X machine near you.

To use the brand new old Save As command, you only need to press the option button when the file menu is being displayed. Consider for your viewing pleasure, the image above this paragraph of the TextEdit File menu, which is much like you have come to expect if you are a Lion user. Now look at the image below, which is merely an option press away. There it is, highlighted (if not slightly blurry) in blue – Save As. Thank You Apple.

 

But if you want the “Save As” to show without having to press the option key, the solution is simple. Just go to settings, and Keyboard/keyboard shortcuts. Under “All Applications” on the right, add in a new keyboard shortcut, and label it “Duplicate”. Use the keyboard combination of “shift+command+option+s”, then close the dialog.

 

 

That is all there is to it. To test, activate up any app that has the “File” menu, such as TextEdit, and open the file menu.You should now see both the “Save As” and “Duplicate” choices (as shown in the image below), all without having to press the option key.

 

OS X Mountain Lion

OS X Mountain Lion (version 10.8) is the ninth major release of OS X, Apple Inc.’s desktop and server operating system for Macintosh computers. OS X Mountain Lion was released on July 25, 2012. It gains features from iOS, such as Notes and Reminders as applications separate from Mail and Calendar, in addition to those iOS features introduced to the Mac in OS X Lion.

source:wikipedia

Run Android Apps on a Mac with BlueStacks

So, maybe you have a Mac and an iPad, but you have been eyeing some of those Android apps. But without having the expense of buying a dedicated Android tablet, your choices were rather limited. But now BlueStacks offers a solution for running Android apps on your Mac, so let’s take a look at what it offers.

Installation

Installing BlueStacks was simple enough. The BlueStacks alpha for Mac is available from the website (http://bluestacks.com/bstks_mac.html), and it downloads as an installation package. The install is not small, as it will consume almost a gig on your Mac hard drive (or SSD, as applicable). After selecting the drive, installation proceeds as expected.

When the installation is finished, you will be presented with an image that tells you to open given Android apps directly from your Dock. Now normally I tend to frown upon installations that install to the Dock, but this does make it easy to access the installed Android apps.It might be good to note that the version tested was 0.2.1.17.

Trying it out

Okay, so far so good. I click on the newly installed dock entry and I am presented with a collection of 16 Android apps for my immediate perusal. The installed demo titles with the Alpha are a good mix, ranging from social media to gaming with an excellent newsreader (Pulse) and more. But enough looking, let’s get to testing some Android apps on the Mac.

When you launch a selection from the dock, the Android virtual machine (which explains the install size) is loaded on the screen, and it will download the selected app if it is not already installed. From there things behave like you would expect from an Android virtual instance, with the exception of it being a custom layout.

I continued to put the app through its paces, testing the installed software. Everything seemed to function fine. The only time I had an issue with speed was during the Paper Toss Android app, which was only minimally erratic. The Drag Racing app performed admirably, as did the other games tried. Pulse and the other apps worked fine, with no noticeable issues.

Machine impact

Now, by “no noticeable issue” I am talking about the user experience, not the impact on the machine.Having the BlueStacks window up and running resulted in a marked
increase in CPU load, and this only marginally increased when running an app. Even worse, when exiting the app it left a couple processes running that continued to put a load on the machine (uHD-Pal and uHD-Kal, for example). I had to pull up the Activity Monitor and kill these processes manually in order to put the MacBook Pro back into its usual fan-less operation.

Although this is an early Alpha release, the BlueStacks Android solution shows a lot of promise for easily getting Android apps on your Mac. The Alpha does have some limitations – for example, you cannot add apps to the mix, so you are limited to the apps provided by the install. ; Also, you cannot resize the app window, so the size you first see is the size it stays – at least through the Alpha. A little research shows that the Windows version of BlueStacks does offer a resizable window, so perhaps this is a feature to be implemented later.

Wish list

Still, there are a few things that I would love to see implemented at some later date. It would be great if you could break out the apps to its own window, much like VirtualBox offers for a Windows guest OS. And naturally the ability to add your own apps is a must have, but hopefully that one is coming as the product matures and rolls out of Alpha.

The control paradigms

All said, the biggest problem might not be the ability to run an Android app on your Mac, but rather the fact that the apps are not designed for use with a trackpad. ; While no doubt some apps will work fine on such a control paradigm, you will always find those that fail to make the translation. For example, apps requiring multi-touch might present an interesting challenge to be successfully controlled by a touchpad. While the MacBook Pro does offer multi-touch on its touchpad, the difference in the sizes could be problematic, if supported at all.

BlueStacks is in Alpha, but it does represent one of the easiest ways I have found yet to get Android apps running on a Mac. I feel confident that some of the simple issues will be addressed as the app matures. Soon it might be a non-issue to run Android apps as you need on your favorite Mac – that is, without installing either a VirtualBox image or the Android development environment. And that should please a lot of users.

Virtualization

In computing, virtualization (or virtualisation) is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system (OS), storage device, or network resources. While a physical computer in the classical sense is clearly a complete and actual machine, both subjectively (from the user’s point of view) and objectively (from the hardware system administrator’s point of view), a virtual machine is subjectively a complete machine (or very close), but objectively merely a set of files and running programs on an actual, physical machine (which the user need not necessarily be aware of).

source:wikipedia

How to Move from BlogEngine.net to WordPress

Since its original incarnation back in 2008, NerdBeach has been running on BlogEngine.net . I have no real complaints about the paradigm, and found it be a very easy to upkeep solution for running a blog.

But as time went on I found that it required coding to do anything. In a lot of ways that is a positive, but there are nonetheless a lot of great blog goodies in the form of plugins for popular platforms such as WordPress. So, after a little planning, last week NerdBeach.com took the plunge and moved to a Linux hosted backend running WordPress. And so far I like it.

Now, as they say, even the best laid plans of mice and men sometimes go astray, and the changeover was no exception. There were no big issues, but yesterday I did see that the RSS feed collected previously distributed posts when it sent out subscriber emails. And for that I am sorry, but I’m still going to chalk it up to growing pains. But what did moving from BlogEngine.net to WordPress entail? Well, it wasn’t bad. Let’s take a look.

Step 1: Back up the current site, and create the destination WordPress Host

The first step is to make sure to do a backup of the current blog, including all image assets. Once that is done, go ahead and set up your destination host (Linux, if you want to have WordPress work at its best) and install WordPress.  Once that is done, you can go wild looking for a theme and get the look as you want it. I went with something similar to the original NerdBeach.com site, but it did require a lot of tweaks to get it there. But make sure you have the site like you want it before the move.

Step 2: Move Over the Resources and Assets to Support the Existing Posts

Needless to say, we are going to want to keep our posts intact. And a big part of any modern post are the images. Now, the plan is to NOT rewrite by hand all of those posts (NerdBeach was in the 4 figure range, not huge but too many to change by hand), but instead we will bulk edit the image tags. But before that is going to work, we have to move the existing images to the new server.

On the BlogEngine platform, the uploaded images should be found under AppData/Files. Now that you have local current backup, FTP those files to the new server. Now, instead of dumping them in the wp_content/upload folder, I suggest putting them in their own folder off the root, something like /ExistingContent. This lets WordPress continue to work without overloading its media library. Plus I think that is is a cleaner solution, but it is a matter of taste. So, go ahead, decide where you want the old images, and ftp them in place on the new server.

Step 3: Export The BlogML file from BlogEngine and Edit The Image Links

Next, and while the original site is still running, go to settings and export everything to a BlogML XML file. Now, you need to edit this file for every single image you had in a post. But this is simple enough – just find and replace every “/image.axd?picture=” with the path you used to upload the files. For example, do a global search and replace and change it to “/ExistingContent/”. It should go from

“http://example.com/image.axd?picture=MyImage.jpg”

to

“http://example.com/ExistingContent/MyImage.jpg”

Be sure to get the starting “/” and the ending “=”, and with this simple change your existing images will be fine.

Of course, if you are keeping the same domain name, then they are not going to work until you actually move the domain name to the new server, but that is to be expected.

Step 4: Fix the Categories in the BlogML XML File

Now, if your output BlogML file was like mine, you are going to find that your categories have went from being a descriptive phrase to a GUID. But this is no big deal, and with a few greps you can had this fixed. At the beginning of the XML file you will find a categories section. There will be a category entry for each of your existing categories, and its id will be a GUID. Now, the actual value will be listed as a “title” entry, and it will be a CDATA value. You need to replace all instances of said GUID with the category title.

Depending on the number of categories you have, this may take a short while or a long while. But stick with it, and soon you will have the categories in place, ready for import.

Step 5: Import the BlogML XML file into WordPress

Once you have the corrections made to the BlogML XML file, you are ready to import the file into WordPress. But first, we need to make a change to your new site’s permalinks. When running a WordPress site, I do not like the default /?p=123 URL structure. So go change your permalink structure (under Settings/Permalinks) to something that you find more human and SEO friendly. But do it now before you import the file.

Now you need to add a plugin that allows you to do so. Go ahead and search for a BLogML import plugin, and install it (this can be easily done through the WordPress dashboard). Once you have it installed and activate, go to tools/import and import your file.

With luck, your file will import clean, and you will be given an option at the end of the process to get a conversion file from the BlogML import plugin. This file will very handily list the old post URL and the new, permalink updated one (this is why we changed the permallink BEFORE importing). Grab this, it will make your life easier for the next step.

Step 6: Edit the .htaccess File to Add the Search Engine Redirects

Now, the last thing you want to do in a website move is to trash all of your search engine and web links that you have built up over time. And you certainly don’t want to lose that sterling Alexa ranking that you have worked so hard to build. The good news is that you won’t but we need to tell everyone that things have moved.

The mechanism for doing this on the Linux host is as close as hidden file in the root of your new site, called .htaccess. You will need to edit this file in your favorite editor.

When you first load the .htaccess file, you may be surprised to find a “# BEGIN WordPress” section. The reason for this is simple enough – when you changed the permalink earlier, WordPress uses this file to rewrite the inbound link back to something it likes. This is no problem, but we have to make an important note here: Do all redirects ABOVE the WordPress section in the .htaccess file. Failure to do so will cause you mysterious problems, especially after the original inbound links are re-written.

Okay duly noted. Remember that file you got from the import process? Go open it, and copy its contents to the clipboard. Now paste it into that .htaccess file you are editing, ABOVE the WordPress section. But don’t save yet, we have some editing to do.

You may note that the information we just paste in has two complete URLS, the original and the URL on the new site. We need to have this structure in the file for a redirect to work:

Redirect 301 /post/name-of-article.aspx http:example.com/name-of-article/

Of course, either side may vary depending on your chosen site options. The important thing to note is that the left side has only the path information, and the right has the complete link. Of course, you also need the “Redirect 301 ” bit as well. If your blogengine path was like mine, then a simple search and replace from “http://example.com/post/” to “Redirect 301 /post/” will be specific enough to fit the bill. Your required creativity may vary.

Once you have the .htaccess file complete with the redirects for every existing post on your site, then save it back to the server. Since it should have been a pre-existing file the permission should be fine. If for some reason they are not, set the permission to 644 or whatever you feel is best for your situation. But in most cases a permission change won’t be required. Congratulations, all google juice and web rankings should now be intact after the move thanks to the 301 permanent move notification.

 Step 7: Pull the Hammer

At this point there is only one more thing to do to make the changeover happen – you have to pull the trigger. That is, you need to point the domain name to the new site. This will vary depending on your host service, but in most cases it involves removing the domain from the existng host, waiting for that to take place, and then assigning the freed up domain to the new server.

This is a simple matter if you are keeping the same host company for the new site. In my case the changeover took about an hour from start to finish, at which time NerdBeach was down. But if I had changed host companies in the process, it could have taken much longer for the DNS change to happen. But this is your choice, and it really is a great time to change hosts if you are planning to do so.

After the Domain is officially pointing to the new site, you should find that the old links now take you to the new site posts. And hopefully the images in the old posts now display more or less properly. Congratulations, you have moved your Blogengine site to WordPress.

Step 8: Don’t forget these things

In the rush to get the site moved over, it might be easy to overlook a few details that you need to take care of. First, make sure that any tracking code, such as Stat Counter or Google Analytics, is on the new site. You don;t want to go a few days and realize that you lost all of that tracking information. In fact, you may want to closely monitor it for a few days and make sure that the incoming links continue to do so.

Next, you may want to take note that your feed address has changed. Where before it was something like http://example.com/syndication.axd, it is now probably http://example.com/feed. You can add this to the .htaccess file as a redirect, but if you are using feed burner or other such services, go and update the address. This will prevent future gotchas when you clean up the .htaccess file (the search engines would have updated the address by then) and suddenly your feeds stop working.

Finally, consider grabbing a wordpress plugin that will find missing links in your posts. This may help in detecting any issues with the move. Of course, you may be bombarded with old links that just don’t work anymore, but hey it’s free information.

With a little planning, a move from BlogEngine.net to WordPress can be easily done. The important thing is to have the new site looking as you want it before the move, and being responsive to any issues created during the process. With luck they will be minimal, but it may be entertaining nonetheless.

WordPress

WordPress is a free and open source blogging tool and a dynamic content management system (CMS) based on PHP and MySQL. It has many features including a plug-in architecture and a template system. WordPress is used by over 14.7% of Alexa Internet’s “top 1 million” websites and as of August 2011 manages 22% of all new websites. WordPress is currently the most popular CMS in use on the Internet

source:wikipedia

Debounce Xcode’s Scrolling in Lion

MacOSXHints had a great tip today for debouncing XCode on Lion, and it just might make your development efforts (if so inclined) a bit easier. Starting with Lion, XCode inherited the bouncing scrolliong behavior from iOS. While this may work perfectly fine in a lot of instances, I find it to be a bit disconcerting while cranking out the code. So, I was pleased to see the fix, and it is simple enough to install.



All you have to do is to download the
plugin from their site, unzip it, and place it in this directory: 

~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/

Naturally, if you don't already have said directory, then you might need to create it. Afterwards restart XCode if it was already running, and presto, change-o, no more bounce-O – so to say.

 

Xcode

Xcode is an Integrated Development Environment (IDE) containing a suite of software development tools developed by Apple for developing software for OS X and iOS. First released in 2003, the latest stable release is version 4.3.2 and is available via the Mac App Store free of charge for Mac OS X Lion users. Registered developers can download preview releases and previous versions of the suite through the Apple Developer website.

source:wikipedia