Posts tagged with 'mobile'
Posted on 26th December 2007. Tagged as web, javascript, mobile
I'm currently using my T-Mobile 3G connection to do most of my web browsing, what with it being Christmas, and that I've been travelling around a lot without reliable WiFi.
In contrast to a few years ago, when the hardware support for laptop to phone connections was terrible, that is now incredibly simple. I paired my phone and my laptop, then chose 'Connect to network' from the Bluetooth menu. My phone asked if this was okay, and everything worked pretty much flawlessly (and incidentally, I get a better upload speed over 3G than I do over my DSL at home).
So, I was happily doing some lazy Boxing day web development,and I started to notice errors in my Javascript. Not errors because I'd had a few beers, or errors because I was using a library incorrectly, but errors appearing in functions which I hadn't even written.
I checked the source of my pages, and noticed that someone or something was inserting Javascript into my pages. Specifically, a script from http://1.2.3.8/bmi-int-js/bmi.js. The 'Oh shit, my server has been cracked' alarm went off pretty loudly, and after some peer-review, that changed to the 'Oh shit, someone has released a trojan for OSX for which I am very under prepared' alarm.
It turns out that T-Mobile (and Vodafone UK) think it is appropriate to insert their own Javascript into each page which I visit, which pipes all images through a proxy to degrade their quality. However, due to an improperly terminated newline, this script cannot be parsed by Firefox or Opera in conjunction with any XHTML 1.1 or XML documents.
This causes the sort of errors which break all subsequent Javascript. For sites with lots of Javascript, that is kind of a big deal. It isn't behaviour which I asked for, and clearly it hasn't been appropriately tested. Interestingly, script isn't even inserted when using Safari (come on, T-Mobile, browser sniffing is so very Nineties). In addition, it maps key events to Shift-R, which can cause problems with other web applications (for example, GMail), and access keys in Firefox.
This is a terrible solution to a problem which didn't really exist in the first place. I've paid for a data connection, so I expect the data I requested to be delivered to me as requested, not as T-Mobile think I should recieve it. If I download large images, then I'm happy to take responsibility for what I've done and pay the cost of those downloads. Very disappointing.
Posted on 20th April 2010. Tagged as gps, django, python, mobile, yql, location
I've a few projects coming up for 84labs which required location awareness. Location awareness works great with any recent phone, but for traditional clients, I needed to fall-back to obtaining the location from the client's IP address.
There is an excellent free IP location database hosted on datatables.org, which offered the easiest way to get the data which I needed. This meant using YQL, which I haven't used before; YQL is "an expressive SQL-like language that lets you query, filter, and join data across Web services".
So here is the code. I was using Python, Django and Python YQL module, but the same query presumably works with any language you choose. I've removed a lot of exception handling for clarity.
# Get the current user's IP address.
client_ip_address = request.META['REMOTE_ADDR']
# Create a YQL public query object.
y = yql.Public()
# Build the query.
query = 'USE "http://www.datatables.org/iplocation/ip.location.xml" AS ip.location; select * from geo.places where woeid in (select place.woeid from flickr.places where (lat,lon) in(select Latitude,Longitude from ip.location where ip="%s"))' % client_ip_address;
# Execute the query.
result = y.execute(query)
# ... et voila.
ip_place_name = result.rows['locality1']['content']
ip_location = result.rows['centroid']
That's it. The query just performs a simple select against the 'iplocation' database, then retrieves the latitude and longitude from the flickr.places database (flickr.places is part of the standard YQL set of databases, which is why we don't need a specific USE statement to be able to access it).
Posted on 11th August 2011. Tagged as django, web, mobile, event, testled
Leedshack 2 was brilliant.
I'm going to write a more technical teardown on the Testled blog in the next few days, but I thought I'd just blurt out some nonsense while it was still fresh in my mind.
We built Barebones, which is a minimal wireframing tool from the iPad, written using Django, a bit of HTML5 and the Dollar gesture recognition library
Our intention in the weeks running up to the event was to try to 'just hack'; that is, to aim for something technically different and interesting, rather than building a product, which is what we did at the first Leedshack, and what Pete, Bryn and I did at the Opendata Hackcamp. Not that building products it a chore, but at times before now we've spent valuable time building the dull bits (like user registration, payment/subscription systems etc.) and when time is limited that hasn't served us well. We've always 'finished' our products at hackdays, but sometimes if felt like we had created work which we just didn't need to do.
As it turned out, we built the functionality of Barebones earlier than expected (in fact, we were functionally complete by around 2am), so we did end up polishing it into a final product, but this time it didn't feel like a rush, and I'm incredibly proud of what we achieved.
There seems to have been a gradual shift recently at hackdays towards larger teams and building more 'finished' systems. I'm pleased about this, not only for the competition we find in it, but because people are launching truly amazing sites like Please Pledge, which would look at home in the portfolio of any high-end agency. I'm always amazed at what a motivated team can get done in 24 hours, but this year I was particularly impressed. If you consider that our team has a combined day rate of about £2500 (and 24 hours is around four 'working days'), and weigh that against what we would charge for comparable work in a 'day job' setting, motivation is clearly the key difference, but it's still very satisfying to know that you're presenting something which just existed in someone's head 24 hours previously.
As usual, I didn't get around to speak to enough people, but the usual fantastic crowd was there (and Kian's shrieks as he shoehorned 4GB of data into an sqlite database was particularly funny), and if anything Leedshack has made me look forward to Barcamp Blackpool even more eagerly so I can have the opportunity to talk to everyone without the distraction of hacking.
Thanks, Dom and team for organising. You're all invaluable.
