Monthly Archives: July 2016

Building a Python portfolio

Leave a reply

Recently I’ve struggled to find the time and energy to write blog posts, for various reasons of which I cannot deny that Pokémon Go might’ve been one. However, there were also some valid reasons too, I realised that while I might do some automation, write some Python tools and generally dabble in programming, none of that is visible really from my LinkedIn profile or on my CV.

Sure, I can say that I have experience with Python 2.7.X and Python 3.4/3.5, but where’s the evidence? I can’t exactly put my code from my work repositories online, because that code belongs quite rightly to the company I work for.

 

Thus if I ever want to make it clear that I can write programs and that I am familiar with Python, I decided that I needed to put a Github repo up with some examples of the kinds of things I am capable of doing in Python. Great idea so far and I quickly spun up a repo and initialised it and… Then what?

 

I started asking around in the Tester’s Slack ( http://www.testers.io/ , if you’re a tester and you’re not on that Slack, you’re really missing out on a wealth of resources and advice) about what people would look for in a portfolio, did I want to build a gigantic project with lots of functionality to show what I could do, or did I want to build lots of smaller tools? Luckily the consensus on Slack was that the smaller tools route was the right way to go. I love writing little tools, so that worked out well for me.

Now I had a plan, a rough idea of what I needed  to do, so I sat down and I started to do it.

 

Or I tried to.

 

Turns out that I had no ideas about what it was that I could write, normally when I write Python it’s to solve an immediate problem. For example, I started my job 6 months ago and I’ve filled a small repo with ten or so small scripts that all solve an issue I’ve been facing in my work. One spins up a suite of VMs for regression checking, one resets variables and enabled dev options in builds, one is a simple https server that swaps out a served file at a command. Essentially very small, self contained scripts that make my day to day life easier.

 

So, once again I turned to the community to get some ideas and maybe someone to help me, after all I am not the best programmer, I would appreciate some input from someone who’s more experienced and nothing says “I can work in a team” like a collaborative project. For this I turned to Robert Page, a fellow tester from the Testers Slack (spotting a pattern yet? ) who’s kindly agreed to be the person I bounce my ideas off and hopefully throw a few pull requests my way.


Caution: Python technical part.
But what will we be actually making? Well, nothing groundbreaking but I liked the idea of making a dead link scanner. Not a new idea, but it seems like a fun thing to write . My idea was at first to just use scrapy and pull all the URLs in a domain, then I’d run those URLs through requests and see if I get a 404 on a requests.get(url).status_code . If I did then I would append the url to a list and display it at the end of the run.
Robert convinced me that that wasn’t enough, and he was right, what about pages that return 200, but display a set “We couldn’t find your page” message? Or when you hit a 403? Basically scanning for simple 404s isn’t enough.

 

But it’s definitely my minimum viable product, so I plan to start with the link scanner taking a url and a recursion depth argument. As I commit and push this, I’ll try and make my comments and commit messages explanatory enough to allow them to support this narrative. Github is at https://github.com/Dominic-Kua/Random-things , please have a look and enjoy watching me learn.

The far side of localisation

Leave a reply

I’m sure many of you have to deal with localisation of strings and inputs from users. You probably outsource the actual translation to a translation house and you get back a list of strings you can’t really read, but that’s why you hire a company to make your website say “你好!” instead of “Hello!”. Don’t worry however, I am not going to write a post on the wonders of testing in a language you don’t know, mainly because I’ve never done it. Though the subject is almost certainly immortalised in blog posts already, it’s certainly a worthy subject for it.

My experience lies on the far side of that localisation. You might be set up to receive the input of a string in a non-roman language, but how exactly does the user input that string?
My experience is mostly with Mandarin Chinese, so my examples will largely be in that language as opposed to Japanese, Korean or other types of Chinese. If I forget to mention which IME I am using, you can probably assume it’s Microsoft’s Chinese Simplified PRC.

So first of all, why am I sharing this information? Well, simply put I think that this is something that many people will be unfamiliar with and one that it might help you to understand your non-latin userbase more.

So, what does an IME look like?

IME-basic
Something like this. Here I’ve typed in the phrase “hanzi”,meaning Chinese characters in Chinese. As you can see there’s a range of options, because Chinese is a language of homophones differentiated (sometimes), by tone*. Thus for any arrangement of valid syllables, there can be many valid translations of these into Chinese characters. Thus the user is presented with a drop down menu showing all the choices.

How does this affect you? Perhaps your input options include hints. How do these hints interact with the IME? Is the layout of your page conducive to this kind of input? If you test a desktop application, does it try and steal input from the OS? A good example of this would be a game with a chat channel, would you steal input while the chat channel isn’t focussed? Do you have a way to ensure that you don’t steal input if someone enables or disables the IME inside the game?

You can try this out yourself by installing the Chinese keyboard input pack on Windows, SCIM on Linux or I am sure there’s a version for the Mac, but I’m not familiar with the platform. You’ll probably want to try out a few different languages if you decide to really see what the issues are around IMEs, the so called CJK languages (Chinese, Korean and Japanese).

However for me these languages present a slightly different challenge. Due to the nature of the software I test, we can’t devolve language handling to the OS completely, instead we have to implement some areas of it ourselves. Thus while I can read and write a little Chinese and much less Japanese, I’ve recently had to pick up enough Korean to test the Korean IME. To this end I actually resorted to the Microsoft documentation on the Korean IME* which proved that while I could type hangul, it wasn’t the characters for Hangul that were being shown.

I’m not suggesting that everyone who wants to test using an IME learn the languages of the IME, because that would take far too much time and not everyone enjoys learning languages. However it is possible that a few words of each and, importantly, how to input them on your supported platforms, could be extremely useful.

* https://support.microsoft.com/en-us/kb/130053