Proofreading Your Text with Mac OS X’s Text-To-Speech

Mac OS X Speech Panel

I write an almost weekly blog post for HuffPost and I’m terrible at proofreading my own work. I use the text-to-speech function on my Mac to read the text to me. I find I can hear grammar errors in my own work more readily than I can see them. Most word processors and text editors that I’ve found don’t have a specific feature for text to speech. I like to have a short-cut key for this feature so I can review the text, make changes, listen again, and repeat the process without slowing down to find a menu item.

Apple has a great facility in Mac OS X that makes it easy for me to send a selected paragraph to the Mac’s speech service that works with most applications. Well it works with Pages, Chrome, Dictionary, TextEdit, and Scrivener. It doesn’t work with TextWrangler and I have not tested it with Microsoft Word.

The location of the speech service control panel has changed over the years and is a little hard to find in Mountain Lion. (I’m sure it will change in Mavericks too.) But as of today this is what you do:

Go to the Apple menu and choose “System Preferences…” In the System row click the “Dictation & Speech” icon. In the Dictation & Speech panel click on the “Text to Speech” tab. Check the “Speak selected text when the key pressed” checkbox. Whew! That was crazy!

The default key for speaking text is “option-escape” which I can not easily remember or press. For ultimate productivity I set it to a single keystroke (F13) which makes having a full size keyboard rewarding.

Getting Xcode and GitHub to work together like besties

Updated for Xcode Version 7.3.1 

Thanks to Jake for pointing out that his blog post needed a little freshening up!

After watching the WWCD keynote I wanted to fool around in Cocoa and Objective-C again. It’s been a while and my Xcode skills were rusty. One task that always seems tricky is getting Xcode’s local git repository to work well with GitHub’s remote repositories. I clicked around, read some docs, did a little Googling, and experimented until I got it to work and in way that works every time.

There are many other blog and stackoverflow posts on this subject but most are either missing a critical step or making it out to be way more complicated than it really is. That’s the problem with Apple magic: Sometime’s they design away the details to a point that you really don’t know what is going on.

The best tutorial on Git, Xcode, and GitHub for the white belt hacker is here: http://www.raywenderlich.com/13771/how-to-use-git-source-control-with-xcode-in-ios-6

But the part on connecting your local Git repository created and managed by Xcode to your remote GitHub repository is a little brief and lacks detail that might trip you up. Here is all you need to do to get Xcode and GitHub to play nice…

  • Create your Xcode project with a local Git repository and write some code
  • Commit your changes locally (File > Source Control > Commit…)
  • Create your GitHub remote repository on GitHub but do not initialize it and do not add a readme.md file!
    • Note: You can give that remote repository any name you want, I gave it the same name as my local git repository because I’m lazy
  • Go to the Source Control menu and and choose the second item with the name of your repo. This item leads to a popup menu. Choose the last item of that popup menu which has the name of your repo and word “configure”
  • In the configure dialog choose the Remotes item
  • Click the + button and choose “Add Remote” to associate a remote repo
  • In the Add a Remote dialog box you have two fields to fill out
    • In the name field enter the name of the GitHub repository you just created
    • In the location filed paste the “HTTPS” URI from GitHub for your repo
    • It will look like this: https://github.com/you-account-name/your-repo-name.git
  • Now you have a connected local and remote repository 🙂
  • Go back to the Source Code menu and choose Push…
    • A dialog box pops up with a drop down menu
    • Choose the only option you can which will be something like your-repo-name/create
    • Click the push button
    • Enter your user name and password in the dialog box that appears

You Win!!

Remember to check “Push to remote” in the Commit dialog box so you check in your code both locally and remotely.

Extra Credit:

I use Two Factor Authentication and I had to turn it off to test this. That made me a little nervous and I immediately turned Two Factor back on.

However you can generate a Personal Access Token so that that you can push to GitHub from Xcode and keep Two Factor on!

  • Log into you GitHub Account and go to Settings > Personal Access Tokens
  • Click the Generate New Token button
  • Give the button a description such as “Xcode Repo-Name”
  • Check the least amount of scope needed to commit code remotely: “Repo”
  • Click the Generate Token button at the bottom.
  • Copy the token (which is a long string of numbers)
  • Back in Xcode go to Preferences > Accounts and choose your repo under the list of repositories.
    • The Address field will contain the HTTS URI you entered earlier
    • The Description is the name of your repo
    • Authentication should be set to User Name and Password
    • User Name should be your GitHub user name
    • In the Password field paste token

Boom! Now you can commit remotely with Two Factor Auth in full effect!

 

Opps! Errors in Google’s Chrome Extension Tutorials

I don’t know why, but I got interested in writing a Chrome Extension. Yeah, I know, like 3 years too late. I figured it would just take an hour and I might learn something about well designed plug and play component architecture. I quickly found the Getting Started tutorial. The screen shots were a bit out of date but the instructions were clear and simple. After following the tutorial the example extension (kitten photos from Flickr) failed to display images and failed to post any errors to the debug console.

So I went the Debugging Tutorial but I could not get my extension to load in the debugger.

Fooling around I could make text to and images display in the example extension’s popup window but the example code, provided by Google, failed to work. Did the Flickr query API change? Was a bug introduced in a Chrome update? Is my computer broken? A glitch in the matrix?

I love that feeling you get when you’re debugging utterly simple code and completely lost: “It should work and when I figure it out I will feel like an idiot!” (because generally it’s a missing a “}” or some other typo).

But this time it wasn’t me! It was Google’s tech writers.

First, if you want to debug a Chrome extension do not follow the instructions: Right-click the Hello World icon and choose the Inspect popup menu item.

Instead do this: Left-click the Hello World icon so the popup appears and then right-click the popup window! (Unless you are left-handed like me and you have to right-click where the world says “left-click.”)

Clicking with the “other mouse button” (the handed-neural way to say “right-click”) on the extension’s window brings up a context menu that let’s you inspect the extension and load its code and resources into a Chrome debugging window.

Second, if you want to see the kittens, change this line in popup.js:

    req.open("GET", this.kittensOnFlickr_, true);
to the much more effective:
    req.open("GET", this.searchOnFlickr_, true);
The function kittensOnFlickr_ is never defined. The function searchOnFlickr_ is defined instead. The kitten look excellent when they finally appear!
Sometimes when looking through a tutorial I find errors like this and wonder two things: Am I the only one who actually reads and runs programming tutorials? Is this an intelligence test?
Given that Chrome extensions are no longer a hot technology it probably doesn’t matter 🙁

My Huffington Post Blog Posts

I’ve been writing a weekly blog post for the Tech section of the Huffington Post. Here are links to what I have written so far:

I’ve learned a lot from writing these blog posts and I’ll continue to do until our editors lock me out of the CMS. Reading the commentors as they alternately boo and cheer, correct my grammar and spelling, and point out technical mistakes is awesome!

Figuring out what to write about is always a panic. I don’t have time prepare and want to tie each post to something topical. The other hard thing is keeping each post short. Nobody, not even me wants to read more than 1500 words of John Pavley 🙂

HyperCard: What Made it Leet

I posted a blog entry on HyperCard yesterday on The Huffington Post: HyperCard: The Original Bridge Over the Digital Divide. From the comments and tweets that I got it was pretty clear that us older hackers have fond memories of HyperCard. But there’s the rub–Us older hacker. Kids today, i.e., people in their twenties, missed out on the whole HyperCard phenomenon.

The children of HyperCard are ubiquitous! Every web browser, every presentation app, and even Apple’s iBook Author tool and Adobe’s AIR environment are Jar Jar Binks to HyperCard’s Qui-Gon Jinn.

But like Jar Jar himself, HyperCard’s children are flawed. All these apps and tools that link, animate, and script are over-specialized or over-complicated.  iBook Author is a great example. It’s a quick and easy (and free) way to create an app that runs on iPhone and iPad but only if you want that app to look and feel like a high school text book. Not sexy!

On the other end of the spectrum is RunRev’s LiveCode. It’s the most HyperCard-like of HyperCard’s successors, allows you to import HyperCard stacks (originally), uses many of the same stack and card metaphors, and provides a programming language very similar to HyperTalk. Unfortunately LiveCode has become a tool for creating serious desktop and mobile apps. It’s become as complex as Adobe Flash/Flex/AIR and almost as expensive. I have to give points to RunRev for keeping the dream alive and they deserve to generate a profit but it’s not about 10-year-old kids and school teachers making interactive lessons anymore.

Here’s my list of what made HyperCard great. I hope someone picks it up and runs with it.

  • You could do a lot but you couldn’t do everything with HyperCard. Limitations are a great way conserve complexity and keep doors open to the general public.
  • HyperCard was a general “software construction kit”. You could create a presentation but it wasn’t optimized for presentations or anything else. In its heyday HyperCard was used for everything from address books to to calculators to role playing games but it always felt a little amateur and frivolous.
  • HyperCard was free, preinstalled, and came with a great set of sample stacks. Some people just used the stacks as they came out of the box. Others noodled around with a bit of customization here and there. A few brave souls created new stacks from scratch. But it didn’t cost a dime (originally) and was easy to find.
  • HyperCard’s authoring tools were bundled with it’s runtime environment. Any stack (originally) could be opened and every script inspected. If a stack did something cool you could easily cut-and-paste that neat trick into your own stack.
  • HyperCard’s scripting language, HyperTalk, was very very English-like. More English like than AppleScript and 10,000 times easier for the amateurs and kids to master than JavaScript, Python, Ruby, or Processing. I’m sorry but “for (var i = 0; i < x; i++)” is just not as readible as “repeat with x equal to the number of words in line 1” to normal literate humans. (Python comes close, I give it props for trying.)
  • HyperCard stacks looked like HyperCard stacks. You could easily spot a stack in a crowd of icons and when it was running HyperCard stacks had their own visual language (originally). This visual identify made HyperCard authors feel like members of a special club and didn’t require them to be User Experience experts.

Limited, Free, Simple, Open, Accessible, Generalized, Frivolous, Amateur; The characteristics of greatness that also define what is great about the World Wide Web (originally).

Note: The careful reader might wonder why I’m clarifying my statements with the phase “(originally)”. Towards the end of its life HyperCard added complexity and locking and became something you had to buy. The parallels with the closed gardens and paywalls of today’s Inter-webs  are a bit uncanny.

The Little Computer that Taught Me

The TI 99/4a from Texas Instruments still looks pretty awesome after 32 years!

The personal computer I really wanted to work with back then was the Apple II but as a university student of modest means the big Apple was too much for my bank account to handle. I considered the Commodore VIC-20 and Atari 800, both more popular but they were inferior engines of calculation. The TI 99/4a contained a true 16-bit CPU that might be considered one of the first RISC chips available to home users. But I didn’t know anything about CISC vs RISC or 8 vs 16 bits. I only knew that I could afford it, that it ran BASIC relatively fast, and I could save my programs to cassette tape. I no longer have a TI 99/4a but I still have the matching cassette recorder, which also doubled as an ordinary audio cassette player.

Back then there was a truly great hobbyist computer magazine called COMPUTE! Every month it would contain the source for several BASIC and machine code programs for each of the home computers of the day. I would dutifully type in each program for the TI 99/4a and then modify it beyond recognition. After a few months I started creating my own, original works, that served no other purpose but to amuse me. My TI99/4a started to attract other nerds (I don’t think we had the word hacker back them) and thus began a journey that took me from painting and drawing pictures with brushes and pens to developing real software on serious computer systems.

The simplicity and limitations of the TI 99/4a gave me an advantage that today’s young hackers lack: Focus. There was no question about where to begin and what to begin with. Most importantly I had to type in every line of code myself: No cut and paste (it had not been invented yet) and no code editors with auto complete. All my code was DRY because wet code was too time consuming to type in.

How Engineers Will Win

Before reading this, you should read Why Engineers Never Win and Why Engineers Should Win.

Ok, now we’re all caught up.

I’m optimistic. Yes, I know the world is hurting. I see how the people trying to do good often make things worse. I can’t claim to be insightful when I observe how we celebrate buffoonery and berate competency. (At least the Romans got bread with their circuses.)

I’m optimistic because engineers have become poets and code has become poetry.

Every age, every culture, every society is measured by the breath and depth of it’s poetry and the brilliance of it’s poets. This poetry can be visual or musical or sculptural or theatrical or even wordy. Sometimes it’s hard to identify the poetry, hidden behind fashion and fads but it’s there if you look long and hard and unblinking.

A month ago I had an opportunity to visit the Louvre for the first time, in person. I only had a couple of hours so I made beeline for the Ancient Greek sculptures. My mature interest in making art, oops, I mean visual poetry, was born from my experience of the Kourus and Kore gradually coming to life from stiff abstractions in the 7th century BCE to expressive examples of humanity in the 5th century BCE. Walking past these sculptures in the Louvre was like watching a culture awaken from myth to science.

And that same transformation is taking place today: The boxy utilitarian desktop computers of the last decade have become light and glassy iPhones and iPads; The awkward and inflexible HTML websites of yesterday have become elegant and animated HTML5 web apps; CDs and DVDs with hard data limits have become unlimited streams.

We are waking up. Engineers are not arguing for a better world, they are not waiting for the next election or for military action or for protesters to start marching; Engineers are writing new poems that express our better natures in code and chips.

Admittedly, things are a little messy right now. Tech isn’t always used for good. But a program or a device that gives an individual the research and communication power of a corporation or government is inherently good.

Already we have tech poetry that is starting to enable individuals to navigate and bypass complex legal and political boundaries. This is true equality: When you can talk to anyone, anywhere, without permission from anyone else. People are talking to people without adult supervision on Reddit, Facebook, Tumblr, Twitter, Ventrillo, and more. And it’s not the end of the world–rather it’s the start of the world, a new kind of unfettered speech.

Poets know that language both enables communication and limits expression. That why they use novel formulations and metaphors: A great poet breaks free of the constraints imposed by his native tongue.

We can’t solve the problems hurting the world with the tools and languages that created these problems in the first place. But engineers will solve them with ideas that can only be etched in silicon and written in RAM.