If you are not a geek, sorry about these tacky-techy posts. I like posting them to help others geeks running into same problems later.
I’ve been running my GAE apps locally on my Mac using Google App Engine Launcher. The tool makes it simple and easy to develop and test apps designed to run in Google’s App Engine cloud but I ran into a problem when I tried to test my apps with Internet Explorer (running locally in VMware Fusion). Basically IE couldn’t see my apps.
After a few minutes of googling and poking about, I concluded that GAE Launcher was binding my apps to loopback IP (127.0.0.1) instead of an external subnet IP (192.168.0.x). The fix was simple:
- Stop target application
- Open its application settings dialog by double-clicking on the app in the list of apps.
- Add to Extra Flags box: –address=192.168.0.x
- Start target application. If you have firewall on, you’ll be asked to allow Python.app to accept incoming connections.
Other options for GAE Launcher are:
--help, -h View this helpful message.
--debug, -d Use debug logging. (Default false)
--clear_datastore, -c Clear the Datastore on startup.
--address=ADDRESS, -a Server binding address
--port=PORT, -p PORT Port for the server to run on.
--datastore_path=PATH Path to use for storing Datastore
file stub data
--history_path=PATH Path to use for storing Datastore
--require_indexes Disallows queries requiring composite
indexes not defined in index.yaml.
--smtp_host=HOSTNAME SMTP host to send test mail to.
--smtp_port=PORT SMTP port to send test mail to.
--smtp_user=USER SMTP user to connect as.
--smtp_password=PASSWORD Password for SMTP server.
--enable_sendmail Enable sendmail when SMTP is not
--show_mail_body Log the body of emails in mail stub.
--auth_domain Authorization domain
Yesterday, I went over to checkout Google App Engine and, because GAE made it so easy, ended up writing a little webapp I’ve been thinking about writing for a while. Besides, it’s been a while since I used Python so any excuse would have worked. Currently, it runs only on my laptop because I haven’t added security bits yet but it shouldn’t have any problem on the real thing.
Oh, shit. My MBP’s video memory seems to be on the brink. I am getting random lines on-screen now.
The app is a port/extension of part of the Twitter client functionality I had in Appily, my AIR client from more than a year ago that I shelved before starting SafePage. It scratches a usability itch that prevented me from using twitter more frequently. I wrote it to see how improving accessibility radically affects usage patterns. So far, it’s working but more time will tell.
What I found frustrating while coding for GAE are the usual constraints of sandboxing but, for languages with rich third-party library support like Python, it gets really bad because many of those libraries have to be rewritten or replaced to varying degrees. For example, I couldn’t use existing crop of Twitter client libraries so I had to code the necessary calls myself. Each such incident is no big deal but the difference between hastily handcrafted code and libraries polished over time piles up.
Anyway, it was fun. Hopefully, I’ll still be in playful mood this afternoon so I can add the missing security bits and let others play with it too. Be warned, it’ll be rough as concrete floor as I don’t have the bandwidth to apply normal furnishings over the gears. My intention is to keep churning out snack-size apps like this one until one of them gains some traction then dig-in to see if it has legs, conversing with the users all the way.
Call it, conversational entrepreneuring. 😉
Update: Wonderful. Just in time to catch the newly arriving short–end of the stick. I can understand why Twitter is doing this. They are riding a tiger that’s moving faster and faster, trying to turn it into a golden goose without getting eaten. The problem is that it’s neither impossible nor easy. I say, Hi Ho Silver!