7 tips for safe surfing while traveling

I’ve been asked many times how do I safely use the internet while traveling. Here’s a summary of my notes that will significantly reduce the possibility of having your identity, credit card info or online credentials stolen. None of us are 100% vigilant and fool-proof especially during the haste and confusion of modern day travel. These are all simple suggestions that can provide you with peace-of-mind.

No free Wifi. Avoid free Wifi if at all possible, period. Being cheap can end up costing you a lot. In my humble opinion, the risks of free Wifi when you are traveling simply aren’t worth it. For more details keep reading and I also offer suggestions to protect your online presence if you have to use free Wifi.

Use 3G or 4G.  Instead, I recommend you use your cellular data plan, tethering or buy a cellular hotspot. Generally speaking, 3G and 4G is more secure than Wifi because the equipment to crack it is significantly more expensive and heavily regulated. If you travel to a foreign country you can also buy phones with short term rental contracts, or if your phone uses a SIM card you buy one of those with a data plan. This may cost less and provide a greater amount of data allowance than having your existing provider activate international roaming.

Verify Wifi SSIDs. If you have to use Wifi, have hotel staff or restaurants/coffee shops write down the SSID number of their free Wifi. That way you are sure to log in to the correct network. The fastest way to get virtually compromised is to accidentally log into an increasing number of fake networks specifically designed to steal credentials. If you aren’t an expert in network security, and that’s the vast majority of us, then you may not know this happened until it’s too late.

Use a VPN. Considering using Virtual Private Network or VPN software. Most companies offer these to their business travelers. Consumers can use these as well, and an example of that is proXPN which has both free and paid options: http://www.proxpn.com. A VPN encrypts your traffic and helps to double protect user names, passwords and content. Look for VPNs that protect not just internet traffic but instant messaging and any other software you may be running such as Skype. The proXPN paid version protects all traffic on web clients and mobile devices, where the free version only protects basic internet surfing. Paid versions also typically provide better surfing speeds than free versions.

Use Tor. Check out the Tor browser for general surfing as it provides you with a decent measure of security against criminals snooping your email or online purchases. If it’s legal for the country you are in, consider installing Tor: https://www.torproject.org/. Recent versions work on Android devices, as well. And, Tor can be used along with some VPNs for even greater levels of security. Not every online vendor that you use is practicing 100%, up-to-date perfect security practices.

Verify HTTPS. Make sure your email connections are using HTTPS. Most browsers have indicators or lock symbols that indicate a secure connection, the most important thing to look for is HTTPS in the URL of the website. In some circumstances this may not protect your username and password but it’s better than no encryption. It will help to protect the contents of your email. Without HTTPS everything you send will be in clear text for bad guys to easily read as a road-side billboard.

Use pre-paid credit. Use a pre-paid credit card for any online transactions while your traveling, for example MasterCard offers these. Doing this can help protect your main credit card for emergencies. If you have to pay for something via the internet it’s much safer to use a pre-paid credit card that has a finite amount of money that you can lose.

Last Words

The good news is that new forms of authentication, such as two-step authentication, are being increasingly used and definitely help reduce the possibility of account hijacking. Having your credit card number stolen while surfing, however, poses immediate challenges unless you happen to carry around a ton of cash with you all the time. Employing the methods above while you are away from home easily provide an extra layer of security to make sure you get home safely and on time with as little disruption and stress as possible.

4 most important tips for doing tech presentations

In my job I not only give many technical presentations per year but I also get to watch many technical presentations. At some point, if you do enough presentations requiring live demos you come up with a battle plan to try and thwart technical glitches that can turn an awesome presentation into spoiled milk. Unfortunately not all of us have a dedicated army of technicians like Steve Jobs did, so we have to fend for ourselves.

Here are my top four survival notes to help you stay in the game.

Internet connection. Conference internet is almost universally bad. It shouldn’t surprise you that if you are presenting to a room full of geeks that almost everyone in the room will be consuming cellular and WiFi bandwidth to some extent.

If you present enough times, I can practically guarantee that you will experience intermittent connections or complete failure at some point. This can be very frustrating if your demos require an internet connection.

So, there are several ways to keep plowing ahead when this problem occurs:

  • Take screen shots of any page in your application that requires a round-trip request to a webserver.
  • While you are at home or the office and have a relatively stable internet connection, make a video your demos. You can play this back on your laptop without an internet connection and simply talk through your demo as if it were live.
  • Pre-cache web pages before you go up on stage.
  • Have a portable cellular hot spot with you. So if the conference WiFi goes down, you can switch to the hotspot. Check the hotspot bandwidth ahead of time! In really big conferences even the cell signal can degrade as thousands of people compete for bandwidth.

True story. I was at a conference of approximately 4000 people in San Francisco.  In a workshop I was attending you had to download a very large file in order to properly set up the development environment. Instead of passing around thumb drives, most of the 75 people in the workshop tried to simultaneously download an executable that was approximately 750 MBs. It crashed the internet for the entire conference and most all of the technical presentations in the building came to a screeching halt.

Lesson learned: following these tips means you can keep presenting and be a hero even if the internet totally fails. The bonus is that the facebook/twitter/gamer addicted audience will have to pay attention to you because “they” won’t have any internet access.

Projector resolution. I use a Macbook Pro with a Retina display so I was totally hosed at a recent presentation because the projector forced my laptop into 800×600 presentation mode. Who uses 800×600 projectors anymore?? At a minimum I prepare for 1024×768 and I consider 1024×768 as the absolute bare minimum needed for technical demos. At 800×600 my screen real estate was so small I struggled to alternate between showing a web app in Chrome and demoing something in the developer tools. The Chrome user agent tools window, which is not resizable, took up more than half of the screen.

Lesson learned: when presenting at a new venue or a new room that you’ve never presenting in, always contact the conference coordinator ahead of time to verify the projector resolution .

Font size. It’s hard to see the code in most technical presentations. What looks normal to you on your 2880×1800 Retina Display looks like mitochondria under a microscope to the audience. If the audience can’t see your code you risk turning your great presentation instantly into a mediocre one that much less enjoyable to sit and watch.

And, as much as it drives presenters crazy, you will always have people sit in the farthest reaches of a room…and I mean way at the back. This can be especially true in very large conference rooms. To them your 12-point font settings in IntelliJ, XCode, Eclipse or Visual Studio make your code look like tiny, slightly blurry stars in the Milky Way Galaxy.

Lesson learned: There’s no such thing as making your font-size too large in a presentation. Seriously, crank up the font-size and then walk to the back of the presentation room and see if you can read it (without the aid of binoculars).  Also make use of your operating systems built-in zoom capabilities. Zoom into the hard-to-see parts of your demo. Another trick is to simply cut-and-paste your code directly into your presentation template and then crank it up to 28 point or greater font size. Wrap your text if it runs off the edge of the slide. Black text color on a white background works the best.

Screen Zoom on Mac

Screen Saver. I’ve seen it happen many times where the presenter is standing in front of the screen talking to the audience and their screen saver kicks in. Then they continue to talk about stuff we can supposedly see  while remaining unaware of what’s going on behind them. It’s even more embarrassing for the presenter if they have baby pandas or their family dogs as a screen saver image.  Or, when trying to log back in they mess up their password a time or two.

Lesson learned: make sure your screen saver is disabled before you present. Thanks to @geeknixta, he told me about an awesome little app on Mac that takes care of this problem with one click…it’s called Caffeine.

Web developers: 10 ways to deal with intermittent connections

This post is about web applications designed for online-only usage that for reasons beyond your control will occasional go offline, or appear to have connection problems to non-techy end users. Even though we expect it, connectivity is not guaranteed. The good news: there are many things that you can control to help improve the usability of your sites and the perception of its uptime.

The Internet is inherently unreliable and it goes up and down as well as faster and slower all the time. It’s even more unreliable if you are talking about mobile web as compared to being plugged into a dedicated Ethernet or WiFi connection. Failures can happen within the app, on the Internet connection and even at the web server or CDN and when it happens it can frustrate users and eventually turn them into unhappy customers. The challenge for you as web developers and IT managers: it’s often hard for the people managing websites to get a real good look at the end-user experience because it can be so hard to duplicate.

In general most users typically blame their “internet connection” which is a euphemism for it’s the cellphone providers fault or the DSL or cable company’s fault. And, most people don’t know or really care where the problem is, they just want it fixed.  A common reflex when there is a problem is for a user to simply reload the entire page. In some cases, a full page reload isn’t possible or it’s painful such as more complex sites where a full reload means potentially walking about through several steps to get to back to the final page or view.

So here are a few suggestions to you, as a web developer, to help minimize occasional disruptions and keep users as happy as possible. Some of these are major repeats but they are well worth seeing yet again:

Performance. Make your web pages as lightweight as possible. Pages that load faster will ‘appear’ to be more responsive to requests even if you aren’t concerned about millisecond response times. Most of you will have already had this drilled into your head over and over: The goal should be fewer and smaller files, using CDNs, moving CSS and JavaScript library loading operations to the bottom of your html pages, use inline images and the list goes on and on. There are many articles on the web about improving performance. Search for ‘website performance’ to find out more. Another example, Steve Souder has an excellent website and even written books on the subject.

Caching. Consider page cache settings carefully. The subject of setting header caches, such as ETags, Expires and Last-Modified headers, is often overlooked and usually misunderstood. Cached content cuts down on the total number of HTTP requests when someone loads your web page. Static content, or content that doesn’t change much, usually has longer cache times than content that changes frequently.  Even though there are many articles on the web about caching, doing it well can be tricky. It can be very handy to hire an expert to figure out optimal configurations in a short period of time. Or in my case, I spent several months of experimenting while subjecting my blog readers to unnecessary page lag, and variety of other problems, until I finally broke down and hired an expert.

HTTP requests that block. Be aware of any HTTP operations that block the loading or use of your pages.  If you have to use a blocking HTTP request then make sure you set a timeout in the client request, such as 20 seconds and display some sort of a loading icon. A good web designer can help walk you through the UI experience. Most modern web servers have server-based timeouts that are longer than most people are willing to wait.

Auto-retry. Alternatively, consider a significantly shorter HTTP timeout setting and retry the connection several times before failing and notifying the user that the app couldn’t connect. These days a single 404 error doesn’t necessarily mean the website is down. But…very, very few websites employ this pattern. So what happens in response is most people reflexively keep hitting reload when there are any loading problems. Reloading an entire page is much more bandwidth intensive on your servers as compared to having the app simply retrying quietly and quickly in the background to load a specific item.

More efficient database polling. Long running database queries can give the impression that the connection is broken. If you have requirements to poll a server-side database for changes, consider implementing a server-based process that simply returns a JSON-based Boolean such as {changes: “false”} if there are no changes. In comparison, most server-side database requests typically run entire and potentially complex SQL queries with every internet request to tell you nothing changed.  From a server resource preservation viewpoint, it’s significantly less overhead to return a simple JSON-based Boolean and let a long-running server side process do all the heavy lifting on a regular timer cycle.

Fail gracefully.  Don’t hang an entire page if your app fails to load a JavaScript library or some other content throws a 404 error, or if a database request fails. Don’t do it. I know this seems obvious, but I see it all the time when doing my daily web surfing. See my suggestions above for handling HTTP requests. Most major companies seem to be guilty of this for activities such as viewing billing pages.  Let the end user know through some sort of a pop-up that a connection has failed or timed out. Native mobile applications have built in mechanisms for doing this, and granted they can auto-detect when the Internet connection goes down, but I still believe regular web apps should mimic the behavior when possible.

ApplicationCache. Consider storing some pages and resources for when a connection goes down by using the HTML5 ApplicationCache interface. This lets you go beyond the typical caching mechanisms using patterns that can be easier to understand and control as compared to the somewhat black box and variable nature of header settings.

Feedback. The ability to email web administrators directly has lost favor over the last five years or so. I suggest bringing this back in a big way, along with clearly posted links. Sometimes the best way to know something is down or slow is to hear it directly and immediately from a customer. Yeh sure, you’ll get some spam email but if it means keeping customers happy then there are both automated and manual ways to deal with it that work. I can speak personally on this topic as my blog has received over 40,000 spam attempts of which I’ve personally deleted over 3,000, and I’m just a team of one. Some techy sites do provide a “Performance” section of their forums, which is fine as long as employees are actually monitoring it (often). The problem with forums is notification of new posts…and, of course, is usually done via email.

Uptime Monitors. Use uptime monitors from different spots around the country you live in, or around the world if you are using a worldwide CDN. Some providers can do this for you, but you should ask questions. The most common scenario I’ve seen is that the update monitor lives in the same server farm as the web server. This is okay but it doesn’t cover the scenario of connectivity outside your firewall. Uptime monitors should not just ping a website, they should also attempt to load and parse actual content, throw a warning email or text message if the content throws an error and throw a warning if a connection takes too long. There are many reasons why you may think your website is up and it’s not. For example, a CDN node could be down, a CDN server could have the wrong permissions, a major Internet router could be down, or your support folks could be using an internal pathway to view pages on your web server that is no longer visible to the outside world. These types of monitors don’t cost much to operate and can significantly boost customer service ratings and help keep customers happy.

Browser Support. Last but not least and probably the touchiest subject is browser support. My recommendation is if you don’t support a particular browser type, then give the end user a message that says some functionality may not work properly. We’ve all been to sites on our tablets or phones, for example, and popups didn’t work right or things didn’t display properly. Non-tech -savvy end users can easily misunderstand these types of things since it rightly gives the appearance that something is broken. If a popup didn’t work it may appear that a sale did not complete, for example. It’s very easy these days to use libraries for browser detection. Doing browser detection should always be part of a web app deployment plan.


HTTP Caching Protocols (W3C)

What is a CDN?

Beginners Guide to ApplicationCache

Browser support – Caniuse.com

How would you rate your smartphones internet connection?

Not including WiFi, what I really want to know is over the period of an average day how happy are you with your 3G and/or 4G smartphone or tablet’s internet connection? Do you ever have moments where web pages are slow to download? Has an app ever taken forever to install, or a tweet or facebook picture upload failed?

Costs and geography aside, could you turn off your WiFi completely and generally have a decent connection at your home? At work? At the airport? At the supermarket?

It’s interesting to note that some really big company’s think that internet on mobile devices isn’t as great as it could be. Have you heard of Amazon Silk or Opera Turbo where they incorporate data compression to try and speed things up to overcome limitations of mobile browsers? I’ve even heard that Google is now working on something similar. Are these just attempts to work around current limitations of cellular 3G and 4G? Most likely, yes.

I’d give my general usage internet connection in my home area a 7 rating on a scale from 0 (no internet) to 10 (always incredible). By home area I mean the geographic location where I spend 98% of my time between home, work, shopping and visiting friends. When not developing apps on my phone, it’s primarily used for email, social media and occasional web browsing. Tethering is a different story. For tethering when I travel I’d give it a 4 rating overall. Tethering uses the bandwidth a lot more strenuously than my home area use case. And because of that it exposes any weaknesses in the internet connectivity a lot sooner and makes them much more noticeable. The typical situation I want to avoid when I travel is having to pay for a hotel internet connection. Besides, hotel internet connections in the U.S. are almost always awful in terms of download speeds, especially if you are in a hotel during a large conference.

If you are wondering if there’s anything you can do about bad cellular internet the answer is YES. First, call your provider and explain the situation in as much detail as possible. Simply calling up and saying “my internet connection is terrible” isn’t going to help. But telling them the geographic location, time of day, frequency of the problem, etc. will help immensely. And, you can always follow-up if the problem persists. Sometimes the problems are equipment malfunctions, sometimes cell towers need to be upgraded. Other times it could be the terrain, buildings and heavy foliage. All of these can degrade signals. As you can see there are many reasons why your smartphone internet could be less than desirable.

If you consistently see internet outages and other major problems and you can’t get a solid answer from your provider then you can also contact the FCC or file a public comment.


FCC Online Complaint form

FCC 3G and 4G Wireless

Amazon Silk

Opera Turbo

3 Steps for Determining if Your Website is Mobile Ready

Here are three step for helping determine the mobile ready strengths and weaknesses of your existing website. I’ve had a number of conversations from website teams recently asking the question: “Can we reuse our existing site for mobile users?” I was surprised to learn that the individuals asking me the question had, in fact, never visited their own site on a mobile device.

Note, this blog describes steps that need to be address before you decide whether to build for the web or native applications.

Step One – Create a small focus group of company outsiders, friends as well as employees.

  • Gather as many different types of mobile devices as possible including: iPad, iPhone, Android tablet, and several varieties of Android phones. Try to use a combination of older and newer devices. Don’t fool yourself by simply using all of the latest great versions, especially if your web visitors are the general public.
  • Get a mobile projector, such an Elmo or IPEVO.
  • Write down the common use cases, and the workflows associated with them. An example use case might be logging in to your site. And, a workflow would describe the steps a user takes to complete the login process  from beginning to the end.
  • Visit your website and run through the common use cases.
  • Turn off wireless, if possible, and let everyone experience typical internet speeds to simulate, for example, standing in line at the grocery store.
  • Trade off using different devices.
  • Hire a user interface (UX) designer if you don’t already have one. Bring them on board at the beginning, or as early as possible, in this evaluation process.

Step Two – Create a grading system to help assess the experience everyone had with each device.

  • Were you able to accomplish your task as easily and quickly as if you were at your desk with a full-size laptop or computer?
  • Did you have to do a lot of extra panning and zooming in and out to navigate through the use cases and workflows?
  • Was there any functionality that simply didn’t work, didn’t work correctly, or didn’t work as expected on the mobile device?
  • Were there any aspects of the site that looked different or wrong? For example, was all the text the right size? Was everything in the right place?
  • Were you satisfied with the amount of time it took for pages and images to load?
  • Were you able to comfortably use the site when rotating the phone between landscape and portrait views?
  • Were you okay with how quickly you were able to switch between different pages on the website?
  • Were you able to access secure resources without any problems?
  • And, perhaps most importantly, were there any obvious improvements you would like to see made to make mobile surfing experience better?

Step 3. Apply some commonly known mobile-specific conditions to your findings and see if helps to provide context to everyone’s experience.

  • One-handed plus gestures. It’s a fact that navigating a mobile web is significantly different from a desktop browser. There’s no mouse! Mobile browsing is usually done with one hand, while the other hand is used to hold the device. The screen is driven by what are called gestures. Examples of gestures are when you swipe your thumb upward on a page to scroll it downward, or when you use two fingers, usually the index finger and thumb, to pinch zoom the screen in or out.
  • Smaller Screens. And, of course the screens are much smaller than what you would find on a desktop or laptop. Different devices have different resolutions. And, navigating a full website can seem more cumbersome as you use gestures to navigate around, in comparison to the desktop experience of seeing the entire page, and using your a precision mouse to whip through the different links on a page.
  • Download Speeds. Download speeds on mobile devices vary considerably compared to your work machine hooked up to a reliable local area network (LAN). A site that seems zippy on your work machine, may load much differently on a typical smartphone. Also, for some older phones they may have much less processor power and that may lead to the perception of slower download speeds as the CPU chugs through displaying the page.

How do I interpret the results?

When you are done compile, discuss and analyze the findings with your internal teams and stakeholders.

Good. If most testers successfully navigated the majority of use cases and workflows then you are in good shape, and you may simply need to do some additional tweaking to your site.

Not so good. However, if most testers had unsatisfactory experiences then you’ll need to spend more time looking more closely as what worked and what didn’t work. You may find workflows that are great on a desktop machine that are clumsy and awkward on a mobile device.

Don’t be surprised. Portions of your site may have to be redesigned. You may not be able to include everything that’s in your full site into your mobile site. You may have to spend a lot of time optimizing the site to speed up page load times. Pay special attention to functionality that didn’t work on mobile. Mobile web browsers have well known limitations compared to full browsers. Looking at what didn’t work may help you decide if you need access to native device capabilities.

You’ve just taken a huge first step towards helping your team set the stage for stepping into the mobile world.

The Art of Internet Connectivity

Everyone’s internet connectivity experience is unique and it can vary from minute to minute. Most internet users can sense slowdowns, and everyone can identify when a connection fails. Web developers absolutely rely on a web connection to build web pages. So, when our internet connection goes down our productivity comes to a halt.

I’ve lost count of the number of times I’ve reported to various tech support organizations that I wasn’t able to reach a particular website or web service and was told by the tech: “I was able to reach it just fine.” This happened again today when I called my DSL provider to inform them our internet service went down completely and then was degraded to 1/10 of what we were paying for (e.g. ~1.12 Mbps on a 12 Mbps service). They told me that the line was stable. Although I’m not real sure what stable means. Then the speed gradually increased back up to normal of over the next hour and a half. This has happened about a half dozen times over the last three months. 

As a web developer, you load web pages up to several hundred times per day. I almost always have monitoring tools hooked up that give the exact time to download a page and its associated elements. So, I have a good idea of when the internet is performing well, and when it isn’t.  Because of this I’ve become sensitized to small, millisecond changes in download times.

I also gained extensive knowledge of internet connections when working on high availability systems with up to five-nines uptime. We deployed systems that monitored web traffic all over the U.S. 24×7. I was amazed to see that internet traffic was very much like our roadways. Sometimes traffic is moving fast, other times it’s slow in spots, and sometimes it’s completely stopped or even re-routed.

In many cases, a modem (or router, as I’m using the terms interchangeably) simply locked up. This is quite common as these devices often run a small linux-based operating system that can occasionally flake out. I can say with certainty in the cases where my DSL modem/wireless router didn’t die, and there was no internet connection, then in 9 out of 10 of these cases it was a problem upstream with the carrier.

Guidelines. So, here are some guidelines for helping you narrow down where the problem might be:

– Check the modem connectivity lights. Usually if a modem is connected to the internet, the connectivity light will be a steady or flickering green. Red  or no connectivity light almost always means no connection. It should be a matter of reflex to simply restart the modem and see if that fixes the problem.

– If the internet connectivity light doesn’t come back after restarting the modem, then call tech support.

– On rare occasions (1 out of 10), restarting the server plus the modem restored connectivity.

– Still no service? You can go get a cup of coffee then come back later and recheck.

– Or, if the internet connection light is green, try blowing away the browser cache and try to reload? Sometimes old versions of pages can stick in the cache.

– Can you load any other websites? If you can, then your particular server or service is most likely down.

– Can you ping the server? (for servers that allow ping). Determines if the server has basic connectivity.

– Can you run a tracert? Let’s you look at the connectivity between you and the remote server.

– Document the problems so you have a record for future reference.

– If you need continuous monitoring with alert thresholds, then look into evaluating continuous monitoring tools such as Paessler.

– If you know how to get the basic troubleshooting out of the way, or if you’ve already done it, then insist on escalation when you call tech support. You need to get back to coding as fast as possible.