Tips for using your phone as a wifi hotspot

I recently was working remotely.  Typically when I do this, I try to find a coffee shop or library–someplace I can park for free or cheap and get access to wifi.

On this trip, for a variety of reasons, finding such a place was going to be more of a hassle than usual.  I had noticed my phone had wifi hotspot capability in the past, so I decided to try it out.

I have AT&T service, and an Android phone (an HTC Inspire running Android 2.3.3).  With my existing 2GB/month data plan, I could not turn on wifi hotspot cability.

However, a quick call to AT&T customer service revealed that the only obstacle was upgrading to a 5GB/month data plan, and that I could downgrade easily if I wasn’t happy.  The change would take place immediately (or at the next billing cycle if I desired). After a day of deliberation, I placed the order, and started using my phone as a wifi hotspot.


  • great to work from anywhere where I can get a decent signal
  • able to use go to meeting, video, browse the web, email, skype–there was really no online tool I was not able to use
  • you can control number of users and apply access control


  • Speed was like DSL (I had 2 bars most of the time and was on the 4G network, but the phone was a 3G hotspot–not sure what that means)
  • A variety of things could cause internet access to stop: incoming phone calls, downloading lots of data (photoblogs), having three or more browser tabs downloading data, trying to upload a photo and download data in another tab
  • Internet access would stop working every thirty minutes or so with normal usage, requiring me to ‘reset the router’ by turning off the hotspot and mobile data, then turning them back on


  • Use an offline mail client (thunderbird is my favorite, even though it is no longer being developed).  This will let you respond to emails without using notepad or some other desktop app to capture your thoughts.
  • Practice patience, and if you absolutely must have bulletproof network access, go to a coffee shop.
  • Focus browsing on crucial pages.
  • Having another phone available (for web meetings or regular phone calls) is really helpful
  • Have someone else host skype calls–trying to host didn’t work, but I could participate just fine if someone else hosted

Even though the experience wasn’t optimal, frankly it is pretty amazing that I can use my computer and have reasonable access to the internets from anywhere that has a decent phone signal.

Review of Emergent One

A few weeks ago I sat down with some folks at Emergent One and got a demo of their product.  The reason I reached out to them is because I heard great things about their demo at GlueCon.  My company is considering building a mobile app (who isn’t, right!) and I thought that what EmergentOne offered was a great way to accelerate the server side development of that app.

We are slightly outside of their target market–our API would be solely for internal use of a small team, while it seems like they are aiming at companies who want to make an API available to a larger audience (either external or a larger internal development staff).

Regardless of target market, they have a slick product.  They have a self service web application which can generate APIs directly from database tables.  You allow the app select access to your database.  (I believe only mysql and postgresql are supported at the moment, but I know things are moving fast over there as well.)  You then work within the app to build an API based on the tables in your database.  You can have derived fields as well as fields that map to columns in your database directly.  You can filter your data (so if you only want to expose a subset of your data, you can create an endpoint that only displays that: “users over 40”, for example).  You can also add comments to fields.

After you define as many API endpoints as you want, you can manage access to them with application keys or usernames and passwords.  Automatic documentation with datatypes and whatever comments you have added is generated, and there is a developer portal where it is easy to play around with the APIs and see what you missed.

What they showed me is great, but this product is still in private beta.  That means there are some rough edges.  The biggest hole (a fix for which the demoer promised was coming very soon in their development plan) is that you can’t search against the API.  So, if you have an API exposing your pets table, you can create an endpoint to retrieve all pets, and you can retrieve one pet based on id.  You can create a ‘dogs-only’ endpoint, and get all dogs or one dog.  But you can’t query the dogs-only endpoint for dogs that weigh over 25 pounds and have short hair (or any other type of querying).  I only played with read-only APIs, so I’m not sure how the write-access APIs work.

There’s also always the issue of introducing another vendor into the system.  Since we are looking at this for mobile apps, performance is very important.  It seemed like the demoer was well aware of this issue.  He mentioned an SLA would be likely when they went public, and also talked about some of the steps they are taking to make sure their app uses indexes and other metadata about the tables being exposed to execute as quickly as possible.

I haven’t built an API with any of the other tools out there, so I can’t compare the ease of Emergent One with, say, tools like jboss resteasy that work with a java layer, or usergrid, which autogenerates an API but requires moving data into it.  But I can say that this was a very easy way to go database to API in less than an hour (with iptables troubleshooting mixed in!).  If they get searching right–making it easy to use and performant–this will be a fantastic product.

© Moore Consulting, 2003-2017 +