Yet Another Blog

I’ve been waiting to try this for a while, and this week while on a business trip I’ve finally been able to give it a go.

Presenting my mobile office! A Nexus 7, a plastic stand and a bluetooth keyboard. While I generally travel with a laptop for work, most of the evening is taken up with note-writing, media and Skype. In the spirit of testing out these things I wanted to know whether I could get by with just these devices. I have to say, I’ve covered most bases here, and am very happy not to have to lug about the heavy(/ier) laptop in the evenings back and forward to the hotel.

Very impressed with the Anker Bluetooth keyboard, which works from a couple of AAA batteries. I got the black one for about twenty quid for aesthetic reasons 🙂 It’s a US keyboard. Unless you’re reaching for the pound sign or double quotes all the time this shouldn’t be too much of a problem (actually the Nexus doesn’t yet support UK keyboards natively anyway). Some of the function keys are iPad specific, but the usual volume up/down and copy/paste shortcuts work. It’s big enough for my fat fingers … I can even touch type on it, and connectivity has been very good so far.

The plastic stand for the Nexus was about three pounds (but currently sold out, so no link) and is fine for the
price. For about a fiver you could probably do a bit better.

Hopefully the Nexus 7 needs no introduction 🙂 I got mine shortly after they first came out and I can’t imagine life without it now.

Incidentally, in the background you may also see my wireless hotspot. This is the TP-Link MR3040 and put shortly, it’s a wireless router which can route Internet from either an Ethernet cable or a USB modem. I am currently in a hotel which only supplies cabled Internet … pretty useless for tablets! With this device, I can connect to the Internet from my phone, tablet or laptop with ease. I also have a USB 3G modem which I use in the UK (with a Three sim-card) although more often than not I use the Wi-Fi hotspot function on my phone to tether.

I hope to write more about each device in the coming weeks, with practical guides, notes and thoughts. This three-day trip is also not nearly enough to test the setup to completion – I’ll be continuing to try out new ways of working and writing to see what is comfortable and shall report back in due course. Let us be clear about one thing though – this is a tiny yet practical mobile workstation for two hundred pounds.

LinkedIn supports HTTPS connections. If you go to https://www.linkedin.com/ your connection will be secure and your session & data kept private.

This is fine, and works well, until you click View Profile or click on a Notification. At this point it appears the site dives back to plain old HTTP. If you’re not paying attention, you won’t even notice.

Why is this a possible cause for concern? First, this suggests the cookie does not have its secure flag set, which means the authentication cookie is also being sent in ‘plain text’ and is therefore sniffable by a third party.

Second, any website being transmitted over HTTP is susceptible to manipulation. For instance, a third party could act as a proxy on a public wifi network and inject a piece of HTML or Javascript to, say, pop-up a dialog window asking you to re-authenticate.

Note – this is all a fair amount of conjecture – I need to build a proof-of-concept (actually, I’m sure many already exist), and LinkedIn is certainly not the only example. I should also point out that at least this website asks for reauthentication when viewing/editing sensitive data, which is a plus point.

It seems that typing File:/// in a Mac application will crash the Mac (OS X Mountain Lion). Most applications appear to be vulnerable, and this is something to do with URI handlers.

A long time ago, there was a bug in Windows which caused a blue screen … accessing C:\CON\CON\ would immediately cause a BSOD. Something to do with DOS redirects for comms ports.

In my foolish youth days, I turned this into a bit of a cruel prank against some friends, by sending them a link to a website which would then attempt to open the above path. Sure enough, it would crash Windows. I then stupidly fell for it myself …

Anyway, it seems this is fine in Chrome and Firefox, but it looks like Safari is vulnerable. Can any Mac users confirm (once you’ve saved all your files!) if the following link successfully crashes the browser? Here it is.

I don’t have a Mac to test, but it looks like the bug is more to do with text entry than anything else … so perhaps creating an INPUT type=text field and autopopulating the field would also work?

I bought a new car recently. I kept the old car for a few days while I decided how to get rid of it. Good grief, car insurance in the UK is a mess. Various cancellations, new contracts, payments and refunds – not to mention about eight different letters, and we’re finally sorted. This got me thinking about my ideal insurance company, and what I’d expect from it:

1. Absolute clarity on premiums. Everything is rationalised and explained to the customer. Getting this car will cost you £x more. Driving an extra 5,000 miles per year will cost you £y. Probably need to work on a fixed profit margin, but you’re a business (maybe a co-operative?) and I accept that. Seems to work for the utility companies.
2. Allow instant feedback, so the customer can make decisions. The car will cost £x more? Okay, I’m willing to accept that but I’ll keep my mileage down and take the train more often.
3. No charges for changing details. Ever. It’s a penalty on the facts of life – worse, I’m willing to believe otherwise honest people are discouraged from keeping their records true and up-to-date because of this.
4. On the same basis, and to keep those admin costs down: everything updated online (and, per point 1, the interactive estimator is online as well).
5. Get rid of this stupid policy of rewarding new customers and screwing loyalty. I get a premium increase next year but Joe Bloggs joins and gets 10% off?
6. Make it absolutely clear what effect No Claims Discount has on the price. Insurance companies in other countries have clear rules on what percentage discount is applied with NCDs. Ours are smoke and mirrors.
7. Make the idea that “to get a good deal, you need to shop around” redundant. See point 5. Many people I know shop around each year to renegotiate their insurance.  I’d rather not be in a position where this is necessary, and it shows how little importance companies seem to put on loyalty. Give me your best price first time, every time. Stop the rigmarole of phoning around every year.
8. Remove the fear from claiming. I’m not sure how to tackle this but there is an implicit problem when people avoid claiming because they can’t be sure what effect it’ll have on their premiums. Even if you have protected NCD, can you be sure they won’t increase your premiums for the next few years (points 1 and 6 may help…). I dread to think how many people resolve their issues with cash rather than going the “proper” way, simply because of this fear and the associated hassle.

Case in point: To change my existing insurance was going to cost a lot more (20%+); to cancel then start a brand new policy (with the same company) turned out to be much less. I don’t care much for the whys and hows … this is a ridiculous, time-consuming and unpleasant way of doing business.

Reading through this article on the BBC about over-familiar websites, I was reminded about how there appears to be an increasing over-familiarity in communication in general.

One business colleague in particular grew quite annoyed at the widespread use of “Hi” at the start of (business) emails, and I have developed a tendency to agree. In client-supplier emails, for instance, the use of such relaxed greeting is (in my mind) both inappropriate and unprofessional.

My mobile provider, for instance, routinely sends out emails: “Hi Sven, we thought we’d just let you know your bill is available.” Great! You want to go for a beer this evening? Play a few games of pool?

Of course, it’s not even a human at the other end. The company probably send out thousands of these messages each day; the idea of familiarity is entirely fabricated.

Even the supermarkets are at it. My local supermarket clearly went through a stage of instructing its cashier staff to ask “how is your day?” as if they would be genuinely interested to hear a cheerful itinerary of my most recent activities. Of course not, and for all the time they’re asking the question behind fake smiles and feigned interest, I can’t help but imagine some marketing person thought this was actually a good idea, and that we enjoy being forced into conversation with somebody we’re never likely to meet again.

Of course, I take the negative view on this stuff. Maybe most people do enjoy the little artificial contact from the otherwise faceless corporations, which would explain why I ended up in a rather awkward conversation the other day when calling up a service provider. The person at the other end cheerfully spoke, “Hi Sven. Hope you’re having a good day. Can I call you Sven?” to which I rather bluntly replied, “No, I prefer Mr Latham.” I don’t think he was expecting somebody to actually object to that cosy relationship, and it put a bit of a downer on the rest of the conversation.

I wonder if he put the phone down at the end and genuinely despaired about losing a friend, but I doubt it.  I  never knew him before – he never knew me and we’ll probably never speak again.

Ongoing thoughts…

A fairly common scenario, particularly with dynamic page rendering, is the need for templates. Specifically, when loading data asynchronously we might want to define a template for each element in that data set.

For example, say I have three rows of data coming from JSON:

[{ 'name': 'John Doe', 'birthyear': 1981 }, { 'name': 'Jane Smith', 'birthyear': 1985 }, { 'name': 'Alice Bobbington', 'birthyear': 1987 }]

For interest, let’s say that both fields will be editable in the table from the outset. We’re aiming to produce something like this:

<table>
<thead>
<tr><th>Name</th><th>Birth Year</th></tr>
</thead>
<tbody>
<tr><td><input type="text" name="name_1" value="John Doe"></td><td><input type="text" name="birthyear_1" value="1981"></td></tr>
<tr><td><input type="text" name="name_2" value="Jane Smith"></td><td><input type="text" name="birthyear_2" value="1985"></td></tr>
<tr><td><input type="text" name="name_3" value="Alice Bobbington"></td><td><input type="text" name="birthyear_3" value="1987"></td></tr>
</tbody>
</table>

Please assume validation, correct HTML5 input tags and proper IDs & row references would be settled for the real thing … 🙂

There are several options to populate this in a HTML table.

1. Start with a blank table body. Use DOM manipulation to add rows and columns in Javascript.
2. Create a dummy row, hide it with CSS. Clone the row node in the table and populate each clone with each successive row of data.
3. Create the HTML for each row in the Javascript (as a string) and use that to set the innerHTML of the table.
4. Use something like JsRender, where the source template is defined in a script tag and we duplicate the template for each row.

There are pros and cons to each.

If we want to take the pure Javascript approach, (1) is the likely best option. No string manipulation, no messy fragments of HTML, but it’s verbose. Start taking this approach in a data-heavy page and you might want to rethink it.

If you’re using a decent editor with good syntax highlighting and completion tools, option (2) might be better. By revealing the rows through CSS, you can also preview how the row will look once complete (since it exists in the table). However, this places an extra row in the table which means you have to be careful when manipulating the table that you don’t include the template row (or, that you do where necessary).

Option (3) seems to be a fairly popular choice, but it leaves me with the awful aftertaste of string escaping and evals (to clarify – I treat innerHTML with the same caution I do with eval … i.e. only ever use them if I’ve exhausted all other options).

Option (4) looks promising, although I am uncomfortable with the idea of HTML markup inside a script tag … it’s (AFAIK) legitimate, but most parsers and editors won’t acknowledge this, and has the same bitter eval taste as Option 3.

Right now I favour the approach of (2), whereby a hidden row is defined in the source HTML, and is duplicated & modified according to each received row. The issues described above could be reduced by placing the template in its own TBODY.

It may not be the most critical of flaws, but there is something akin to a big, red, buzzing warning light whenever I see this.

A few weeks ago, while staying in a hotel in continental Europe, my phone alarm went off at the usual time … except it didn’t. It was an hour late. Odd – and annoying.

In my bag of goodies I often carry a small wireless access point with me. The reason is simple, some of the hotels I stay in have wired Internet only. Not so good when you’re packing a tablet and phone (and don’t want to get the laptop out).

Turns out it was my wireless AP that caused the phone to think it was back in the UK. The last time I’d used the AP was in England (GMT+1), so when the phone detected the AP again, thanks to the wonders of Google’s location services, it put me back in the UK and an hour behind. The clock, the weather forecast – everything was “updated”.

Clearly Google had spotted my AP, placed it in the UK and relied on that information to set the phone’s location. Interestingly, the phone never took into consideration the twenty-or-so other access points visible around the hotel – this was the strongest.

Lesson learnt: be careful of geolocation facilities. Computers can be smart and dumb at the same time.

After somewhat of a hiatus and much soul searching I’ve decided to resume writing on this blog. As I get older, more mature (debate able) and more experienced I have been itching to get writing again.

My business, having gone through its fair share of ups and downs, is now safely in growth mode. It is my responsibility to ensure that the business remains focused, which includes reviewing my own ambitions and assessing where my strengths lie.

We live in increasingly interesting times. In terms of information technology it seems innovation, new use cases and new ideas are constantly appearing and evolving. I watch with fascination as the world around me is constantly changing.

This blog was always meant to be educational as well as fun. It was also a personal soap box for my various rants and idle observations. It occurs to me that I shouldn’t kick the opportunity and habit of writing, as I believe my contributions can be useful and in many ways valuable.

I will try to focus and raise the bar on quality – more thoughtful and intelligent debate. In the meanwhile I just need to rekindle the desire to write. This is day one.

I’ve been working a fair bit on setting users’ homepages within business recently. First temptation was to point directly to the secure Extranet page, but more recently I’ve come to the conclusion this is a bad idea:

– For security reasons you probably want authentication on this page … even the basic authentication dialogue box takes a little while to load on slower systems. If the user wanted to do something else (normally go to Google…) this is nothing but an annoying interruption.

– Secure pages take longer to load than insecure pages. Any startup delay is simply irritating.

– The user may be in a non-private location or presenting something where displaying sensitive Intranet information is unwanted and could potentially be damaging to the business.

– Public wireless networks often redirect users to a sign-in portal. When this redirection occurs with HTTPS pages the user is often presented with a nasty and concerning security warning as the redirection system cannot interfere with HTTPS pages.

Thus, if setting users’ homepages I now prefer to create a non-secure landing page with basic tools such as Google search box and links to useful sites (including Intranet and webmail – these are, after all, secured resources)

By the way, if you’re using cookie-based authentication on your Intranet/Extranet don’t forget to ensure your cookies are set to be. secure. That way, they won’t leak on to an insecure network.