Category: Coding

Redirecting Github project pages to a custom domain

27 December 2015

Recently, Julia set up this site, and I purchased the domain superrr.ninja for it to live at. Finding how to redirect it - as it was a project page rather than a user page - was a little counter-intuitive at times, so in case anyone else wonders in the future, here’s what I did:

Read Post

In defence of shiny tools...

10 February 2015

A couple of weeks ago, I wrote a post about how civic tech tools need to be “less shiny, and more useful”. I got some good feedback about this - most people agreeing with the general premise behind it, but some people spoke out in defence of ‘shiny’:

Read Post

Technology for people: civic tech, data journalism & ICT4D

01 February 2015

I’ve been trying recently to think about the things I’m most interested in, and I realised that with regards to technology, there are a few terms that come to mind: civic technology, data journalism, and Information Communication Technologies for Development, or ICT4D. The more I think about the three seemingly disparate labels, the more similarities I see between them.

Put simply, I’m most interested in the use of technology to improve people’s lives.

Read Post

Developing effective technology tools: less shiny, more useful

25 January 2015

This week, I had the pleasure of joining a group of about 100 people working on topics around ‘following the money’ at a two day workshop in Berlin. There was a mixture of people at this workshop; technologists, activists, journalists, and funders. One of the first ‘spectogram’ questions that was asked was regarding ‘shiny tech tools, and whether they are useful or not.

I found this statement, and the reactions that followed, particularly interesting - for the last year, I’ve been looking closely at how data is put online by international development organisations - normally, through “shiny” data portals, which seem to be used very rarely. The statement, and the rest of the workshop, got me thinking about what we makes an effective and useful technology tool.

Read Post

A few of my favourite things (part 1)

20 December 2014

Here are a few bits and pieces that I discovered this year and enjoyed especially. In Part 1: Artivism, Coding, Data Visualisation, Language, Journalism, Technology and Women in Tech.

Read Post

Setting up a new blog: part 1

26 October 2014

I’ve been meaning to migrate my blog off Tumblr for a while now, and on to Github pages. Why? I don’t like the writing/editing interface for text in Tumblr (the window is too small to be able to see much text) - certain bits of html disappear between the visual editor and the html editor - it’s difficult to use images or put code snippets in, and I want to be able to write in Markdown, to name just a few reasons. I also like the idea of creating lists or resources that other people can contribute to - ie. via Github - that can live on my site, and I want to be able to customise it a little more easily than Tumblr offers.

Read Post

AdaCamp: spending time with women in open source and technology

13 October 2014

I’ve just spent the weekend at AdaCamp, a two day event aimed at increasing women’s participation in open technology and culture. It was great, and gave me lots to think about, some of which I’ve tried to outline here.

Read Post

Nerdy presents: building a 'congratulations' site

12 September 2014

A couple of weeks ago, one of my best friends handed in her PhD, in geology, and the TLD .rocks went on sale. Clearly this was a sign, so I bought her what has to be the best domain for a geologist named Sorcha to own: http://sorcha.rocks.

I built her a little present on the site, too – a memory game, with photos she took during the PhD, and the place names, meaning that she's basically the only one who will recognise the pictures and be able to do it really from memory. Once the game has been completed successfully, a 'to do list' appears at the bottom of the page, so it's hidden to most viewers.

Read Post

Unexpected coding errors: how to find the answer?

03 August 2014

This week, after a couple of months break, I returned to adding things to my project website. I've written before about the things I've learned en route to building that site (the most comprehensive round up being this post, “Newbie hacking coding tips”) but there are a few other things that came to mind during this week's foray.

Namely: what to do when you get stuck, or something doesn't work? I've written before that it's important to try and use your own logic before asking for help, and to try and follow trails as much as you can, but that's still a little vague. So, here's a summary of things I've learned to do when things break, or don't work quite as I expected.

Read Post

Newbie hacky coding tips

11 May 2014

As I've mentioned before on here, I'm in the middle of setting up a new website for my project, the Open Development Toolkit. I'm forking an already established site, Source, and customising it to the project needs, and, excitingly, it's almost ready to launch.

I've learned a lot of new stuff along the way, and I thought maybe some of the more general tips might be useful for other newbies to coding – for those of you who are old hands at this, I imagine a lot of this will sound incredibly obvious! Just trust me; it's not.

Context: I use GitX, Sublime, and Google Chrome, running on my MacBook Air. I'm trying to learn by doing, rather than starting at the beginning or with the basics...whether this is wise or not remains to be seen, but it's a lot of fun.

image

  • Don't panic: yes, this screen can look incredibly intimidating, full of multicoloured words and symbols, none of which make sense. That's fine! It doesn't all need to make sense – it doesn't even need to mostly make sense. You'll learn tiny little chunks at a time.

  • Focus on what you need, and expect to understand very little of the rest: the skill set needed here reminds me a lot of the skill set needed to do foreign language comprehension exercises. In those exercises, you're given a long text in a foreign language and asked some specific questions which test your understanding of it. To answer the questions, you really don't need to understand most of the text – you just need to know what you're looking for, and look out for the key words. Context is key – for example, a question about food means you need to look out for 'eating' or 'food' or 'meals'... it doesn't matter at all what the rest of the passage actually says.

    Apply the same logic when you're looking for something in code. If you want to change, say, a colour, you don't need to understand anything else in what you're looking for, apart from where that colour code is. I use the Chrome plugin 'Eye Dropper' to find out what the colour code is – search for it using “Find in Files” in Sublime, and then replace it with your desired colour. That is all you need. Save, refresh, and check you changed the correct thing.

  • Use your logic, before asking for help: this relies on the code you're looking at being well-written, which in my case is true. For example: I wanted to change the way in which articles were being displayed on the site when they're shown in a list, so I looked at article_list.html. I couldn't find the relevant aspect to change there, and I asked for help... whereupon I realised that the first line in that file was:

  • 	% extends "articles/_base_articles.html" %}

    Even without having a clue what the { or % do, the term extends is a fairly big clue. It appears to be building upon (ie. 'extending') base_articles.html, so I looked there, and found the aspect I wanted to change – which, more helpfully, changed it everywhere rather than just in that one place.

    • Change one thing at a time, and don't be afraid to get it wrong: especially when you're not really sure whether you're changing the right thing, this will help a lot. Make an educated guess as to what might be the relevant section based on the code around it, and have a go at changing it – at worst, you'll have to click 'Undo', and at best, you've found what you wanted! Changing one thing at a time allows you to understand which of your guesses was the right one, which will help you understand future problems.

    • Follow the breadcrumbs yourself: even if you're almost certain you have no idea what's going on, try to at least look at where bugs are coming from. For example, when I get errors on the site, the error message tells me which file the problem is in, and usually the line in question. Most of the time I'm fairly sure I'm not going to have a clue what's gone on, but I try to find the file in question and read through it. Slowly but surely, errors are becoming more obvious – and a lot of the time they're little semantic things that require only logic, like a missing </div>, or not closing brackets, rather than advanced coding knowledge. It's satisfying to fix!

    • Commit often, and with clear commit messages: I like using GitX because it becomes really clear what you've changed, and where. Once you've added a new feature, or modified a specific aspect, don't forget to commit it so you can always get back there, and try and be as specific as possible in the commit message. ie. No “Add new feature” but “Add 'training' to navigation menu” for example. Not only does it allow you to get back there if/when you break something, but it's also pretty cool to look at all the things you've added and changed! I really like this Git style guide, from GDS

    • Inspect Element” in Chrome is pretty much your best friend: when you want to change something, 'inspect' it to see what it looks like in code. You can modify things in the inspect element window to check that you're looking at the right thing, and you can see what line in the css affects how it looks. It's wonderful.

    • Online documentation (sometimes) has the answers – admittedly, sometimes it's written for the expert rather than the beginner, but try not to let the long words/chunks of code/general gibberish put you off. If there's a particular problem you're having, or feature you want to add, Google it first. Look at what other people have done, and in online fora where people might have asked similar questions, or in specific documentation. If there's a step by step guide, try the simpler steps yourself, and if there are terms in there that you don't understand, Google again. Rinse and repeat.

    • Keep an eye out for jargon – my best example of this was with 'white space'. For me, the term “white space” means blank space. I have a plugin installed on Sublime which turns this whitespace into pink space, to make it more obvious to see; so, I described it as “pink space”...which, it turns out, sounds funny to a lot of people. Moral of the story: there are lots of funny programming terms out there, and people you talk to might take many of them for granted, and expect you to understand. It's okay if you don't! 
    • From a pedagogical perspective – don't take people for granted. Just because someone has helped you make sense of a certain problem does not mean that they've signed up to hold your hand throughout your entire learning curve; do yourself (and them!) a favour, and try and get through as much as you can yourself before asking for help. It'll help a lot if you can explain the problem you're having along with your attempted solution – not only does it demonstrate that you're really trying to fix it yourself, but you might find some revealing holes or mistakes in your understanding of how it all works. Remember the first tip here- don't panic!

    • Another pedagogical one: try not to let other people type for you. It might sound silly, but having to do the steps yourself, rather than watching a more experienced person do it for you on your computer, can make a lot of difference. Even if they have to literally spell out what you need to type, typing it will help you internalise and remember it. Ask whoever is helping you to imagine that your keyboard is made out of lava – it's too hot for them to touch, so only you can touch it. (I can't remember who told me about the 'lava keyboard' teaching method – if it's you, remind me!)

    • Be realistic, and patient: you're new to this! Nobody learns a new (spoken) language in a day, and you're not going to learn a whole new (coding) language in a day, either. It'll come. My guess is you'll never stop coming across new things to learn, and that's half the fun, really.

    Any others to add? Let me know

Read Post

Customisation: first forays into Django and Python, and adding new tag fields

29 April 2014

Lots of the explanations here are Tryggvi's wise words; I thought they might be useful to others, so he kindly let me copy them over!

So, customisation. As I wrote about in my last post, I got the local instance of Source fired up, and next came the steps of playing around with it, and customising it for what I need for the toolkit.

As you can see from the Code section of Source, you can 'tag' items. On the Toolkit site, I'll be renaming the 'Code' section as 'Tools', and this will be how people can look through the recommended online tools on the site. From Source, the categories of tags are currently split into 'technology tags', or 'concept tags', but I wanted to have more categories- 'data source tags', so that people can search by data source, and 'skill level' tags, for each code.

I tried first looking at this page about custom tagging in the Django documentation, but it didn't make that much sense to me. So, with the help of my trusty tech mentor Tryggvi, I started off by creating the 'models', ie. how the tags will be represented in the database.

Explanation: Django is made up of “apps”; which have special purposes; here, there is an app called “source.tags”. So, in source/tags/ there is a file models.py which describes the tags models.

In source/tags/models.py, we can see the 'technology' and 'concept' tag models:

class TechnologyTag(TagBase):
pass
class TechnologyTaggedItem(GenericTaggedItemBase):
tag = models.ForeignKey(TechnologyTag, related_name="%(app_label)s_%(class)s_techtag_items")

class ConceptTag(TagBase):
pass
class ConceptTaggedItem(GenericTaggedItemBase):
tag = models.ForeignKey(ConceptTag, related_name="%(app_label)s_%(class)s_concepttag_items")

so, following the same CamelCase notion I added:

class DataTag(TagBase):
pass
class DataTaggedItem(GenericTaggedItemBase):
tag = models.ForeignKey(DataTag, related_name="%(app_label)s_%(class)s_datatag_items")

class SkillTag(TagBase):
pass
class SkillTaggedItem(GenericTaggedItemBase):
tag = models.ForeignKey(SkillTag, related_name="%(app_label)s_%(class)s_skilltag_items")

Next came migration, as the database needs to have everything defined before items get put in, and we had updated the database here.

To migrate the database to the newest version that includes both of the new tags, I activated my virtual environment, then ran:

python manage.py schemamigration --auto source.tags

from the root folder, where manage.py lives, which told it to migrate the app called source.tags.

I got:

+ Added model tags.SkillTaggedItem
+ Added model tags.DataTaggedItem
+ Added model tags.DataTag
+ Added model tags.SkillTag
Created 0002_auto__add_skilltaggeditem__add_datataggeditem__add_datatag__add_skillt.py. You can now apply this migration with: ./manage.py migrate source.tags

...which let me know that the migration for the database schema had been successfully created.

I added the new file ( 0002_auto__add_skilltaggeditem__add_datataggeditem__add_datatag__add_skillt.py ) to my git repo, too, but decided to wait before committing it.

Next, as mentioned above, I migrated the database to make it up to date with the newest modifications, with:

python manage.py migrate

which gave me:

Running migrations for tags:
- Migrating forwards to 0002_auto__add_skilltaggeditem__add_datataggeditem__add_datatag__add_skillt.
tags:0002_auto__add_skilltaggeditem__add_datataggeditem__add_datatag__add_skillt
- Loading initial data for tags.
Installed 0 object(s) from 0 fixture(s)

which told me that the database is up to date. Next came some Django learning:

Django enforces a design pattern (a good solution to a common problem) which is called MVC, Model View Controller, which is about how to structure your code in such a way that it doesn't get messy and problematic when you change a few things. The idea is that you have the database stuff managed by one part (the model), computations and preparations by another (controller), and then user interface to show the results by the third (the view)

But, in Django specifically, other terms for the same design pattern are used; instead of MVC, it becomes MTV; Model, Template, View, where View in Django is Controller in MVC and Template in Django is the View in MVC.

What we've done so far as the 'model' part of the pattern, so next came the 'View'/ Controller part, and we started with the admin interface.

This happens in a file called admin.py, so in source/tags/admin.py, I found:

from .models import TechnologyTag, TechnologyTaggedItem, ConceptTag, ConceptTaggedItem

which is where the models are imported.

I added:

DataTag, DataTaggedItem, SkillTag, SkillTaggedItem

to import the new models that I'd created, and then I looked at how classes were created in admin.py. Here's an example:

class TechnologyTaggedItemInline(admin.StackedInline):
model = TechnologyTaggedItem

class TechnologyTagAdmin(admin.ModelAdmin):
list_display = ['name']
inlines = [
TechnologyTaggedItemInline
]

So following the same pattern, I added:

class DataTaggedItemInline(admin.StackedInline):
model = DataTaggedItem

class DataTagAdmin(admin.ModelAdmin):
list_display = ['name']
inlines = [
DataTaggedItemInline
]

class SkillTaggedItemInline(admin.StackedInline):
model = SkillTaggedItem

class SkillTagAdmin(admin.ModelAdmin):
list_display = ['name']
inlines = [
SkillTaggedItemInline
]

and at the bottom of admin.py, also added the new tags in there:

admin.site.register(DataTag, DataTagAdmin)
admin.site.register(SkillTag, SkillTagAdmin)

and started up my server, to see that the new categories of tags were now added to the main admin interface!

But, although they now appeared in the main admin interface, they didn't yet appear in the 'Add new code' section; so, I couldn't add the tags to new 'tools' or 'code' that was being added to the site.

To do this, I opened up the code models, in source/code/models.py, which has two classes defined: LiveCodeManager and another one called Code. The relevant one here is Code, and the class defines some attributes, which is what I wanted to add more of.

So taking 'Data Source Tags' as an example, I added:

data_tags = TaggableManager(verbose_name='Data Source Tags', help_text='A comma-separated list of tags listing data sources', through=DataTaggedItem, blank=True)

By doing this, I created an attribute which followed the rules of 'TaggableManager' which, judging from the name, manages the tags.

So the way tags are probably managed here is that there is one collection (table) of code objects, and another collection of tag objects; a code object can have many tag objects, and each tag object can be assigned to many code objects, ie. a many-many relationship. The way that many to many is managed in SQL databases is via a table (collection) that connects them; each row in that table will have an identifier to the code and another identifier to the tag.

So, imagining a spreadsheet where each column is a field, it becomes impossible to add a random amount of tags (unless you have some weird delimiter inside the field) which is why they move it to another table, then instead of adding more columns and extending horizontally, they add more rows and extend vertically. The 'through' item mentioned above ( through=DataTaggedItem ) is a way of defining what in the table extends vertically.

But in order to get the classes of DataTaggedItem and SkillTaggedItem, which were created in tags/model.py, we have to import them here.

So, in source/code/model.py, we added the new Items to the line:

from source.tags.models import TechnologyTaggedItem, ConceptTaggedItem, DataTaggedItem, SkillTaggedItem

to tell python where the classes/tables live.

Then, I migrated the new database; but, the View/Controllers part wasn't yet updated, which meant that although the new tag categories appeared on the main admin interface, they weren't in the 'admin' part of the 'code' section.

So, in source/code/admin.py I added the new fields to 'fieldsets':

search_fields = ('name', 'description',)
fieldsets = (
('', {'fields': (('name', 'slug'), ('is_live', 'is_active', 'seeking_contributors'), 'url', 'source_code', 'documentation', 'tags', 'technology_tags', 'concept_tags', 'data_tags', 'skill_tags', 'screenshot', 'description', ('repo_last_push', 'repo_forks', 'repo_watchers'), 'repo_master_branch', 'repo_description', 'summary',)}),

which defines what we see on our admin page.

Then, I added:

data_tags_list = form.cleaned_data['data_tags']
skill_tags_list = form.cleaned_data['skill_tags']
merged_tags = technology_tags_list + concept_tags_list + data_tags_list + skill_tags_list
if merged_tags:

to line 40, underneath:

technology_tags_list = form.cleaned_data['technology_tags']
concept_tags_list = form.cleaned_data['concept_tags']

which describes what happens when we save tags in the admin interface,

Then, I added the new tag fields, to update the looks for these fields here in the controller (which, I'm informed, is bad practice– it should be updated in the template, rather than this function)

if db_field.name in ['url','source_code','documentation','tags','technology_tags','concept_tags','data_tags','skill_tags']:
field.widget.attrs['style'] = 'width: 45em;'

So, with that all done, I ran the server again; and the new tag fields now appear in both the main admin interface, and in the 'Code' admin interface, meaning I can add new tools (code) and tag them under 4 different categories.  

Read Post

Setting up a new website: user stories, installing Source locally, and lessons learned

27 April 2014

Over the past couple of weeks, I've been focusing my efforts at work on the online presence of my project, the Open Development Toolkit. I put up a holding page there at the start of the year, which runs on Jekyll and was forked from another site; I kind of love the site (you'll understand when you click the 'on' button in the top left hand corner), but it doesn't do everything I needed to do.

So, with the help of my lovely tech mentor Tryggvi, I began (and am still in) the process of restructuring things.

Firstly, to work out what I needed from the site, I wrote some user stories, thinking about the people who would be accessing the site, what they wanted to do, why they wanted to do it. I prioritised them in terms of the most important users down to the least important users, and tried to limit myself to just 6 different users, most of which have more than one story. From these, we worked out what feature they would need on the site to be able to do what they wanted to; it turns out that a few of them brought up the same feature, which was really helpful to see.

A couple of examples:

User: Journalist in aid-recipient country

I want to: find a tool to help them understand what projects the World Bank is running in their country

So that I can...investigate the relationship between the World Bank and my government

Feature: tools search function (tag: donor organisation)

Or...

User: Civil society activist/newcomer to accessing aid data

I want to: find a tool to help me understand aid flows to their country, + accompanying training materials to work through alongside

So that I can... have some support while beginning to explore the theme of aid data

Feature: tools and accompanying training materials presented together

One of the most important features was being able to clearly see, and filter through, different tools on the site, as well as having a clear online community around the toolkit which allows people to see who is out there, what they're working on, and what they've contributed to. Another was being able to link between tools and training materials in an easy way, to make it as easy as possible for users to find the resources they needed on a thematic basis.

Now, I've been assured that basically all of the features that I needed are entirely possible to create in Jekyll, the framework that I've been using so far; but I have fairly limited time, and I'm such a newbie that I imagine it would take a long time to set all of these things up! (though, I imagine, be a lot of fun.)

So, I started looking for sites which already do lots of the things I want my site to do, and one which came up pretty quickly is Source, from OpenNews. It's a community site, aiming to

amplify the impact of journalism code and the community of developers, designers, journalists, and editors who make it. 

It acts as a hub around journalism code, and seemed from first glances to do everything that I wanted the new Toolkit site to do.

To check, though, I went through my list of user stories and marked how the Source site would fulfil those requirements. I marked the ones that could be easily ticked off with the site 'as is' in green, those which would require some modification in yellow, and those which couldn't be met in red. Luckily, there were no red rows among my user stories! And the yellow ones were reasonably simple modifications.

So, having checked that, the next step was to install a local version of the site, for me to have a play with. I was really lucky to be introduced to the team behind Source at this stage, who were super kind and offered their help in anything I needed to get the site set up. It's been great having that as a back up when I've had questions, and the whole team have been really responsive and generous with their time; a brilliant example of the joys of the 'open' community. 

But to start with, I looked at Source on Github. Luckily for me, there's a pretty comprehensive 'Readme' section with installation instructions. Given my newbie status though, there were still a few things that I needed to install myself, or look up to understand fully. I'd also never used Python or Django before, so came across some pretty basic stuff for the first time. 

I started with the instructions as they read on the readme; I'd never used the command

pip-install

before, so first I had to install that, and I followed the instructions here. I already had the other dependencies from having Homebrew installed previously.

I ran

pip-install funfactory

(what a lovely name!)

and then I used these instructions on forking the repo from Github's help section.

Then, I learned about what a virtual environment was here, and how to set it up for the first time, by running

pip install virtualenvwrapper

and activated it:

source venv/bin/activate

and changed directory into /code/source, which is where I'd saved the forked directory, before following the last step:

git submodule update --init --recursive

and getting all of the development requirements,

pip install -r requirements/dev.txt

Then, I carried on with the 'Configuration' instructions. I created my own 'HMAC_KEY' and SECRET_KEY in the file /source/source/settings/local.py (and was assured they could be as silly as I liked)

and I added:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'source_app.db',
},

to the same file.

I kept running into errors though, and then realised that I didn't have MySQL, which I had assumed would be there from Homebrew. So, I followed this good advice and ran:

$ brew install mysql

And then, once I had definitely got all the dependencies, I synced:

python manage.py syncdb

and migrated articles, code and people as in the Readme.

I couldn't get the test-articles set up, but I ran 

python manage.py runserver

anyway, and, to my delight, saw my own local version of it running at  http://localhost:8000/

It was so satisfying! I've no idea how recently other people had tried going through those steps, but I filed an issue about the test articles to let them know, and got a very prompt response, saying the test articles need to be updated. 

Ta-da. And that was that. Next has been learning how to customise it, and diving more into Python and Django... coming in another blog post.

Read Post

On learning foreign languages and learning to code, and why they're (mostly) different

23 March 2014

I recently started learning how to code, and increasingly, I've been noticing the similarities and differences in the skills I'm developing now and those I developed at university, while studying languages.

“I'm not coding, I'm just copying and pasting” is the answer that came up when someone asked me how good my technical skills were last week. At the time I believed it, too: I was simply looking for what I wanted to make, finding the code behind it, and copying it and pasting it into the appropriate place. I wasn't creating anything new myself, but rather using the building blocks that others had already created.

But isn't that exactly what happens with spoken languages? With first language acquisition, children learn by repetition; they hear things being said around them, and repeat them. In a way, this is the oral version of 'copying and pasting'; and when children do this, we consider it to be 'speaking.'

One aspect I found difficult when starting my foray into coding was (and, this might sound incredibly obvious to those of you who can code!) not being able to recognise what language it was purely from looking at my screen. To me, it all looked the same; black screen, coloured text, incomprehensible words and symbols. Without checking what file I was in from the name or the file type, I didn't know what I was looking at, and of course the rules and the language used differs dependent upon this. I've often tried to insert a line I've seen elsewhere into a file type that doesn't recognise that language, before realising I'm 'speaking' the wrong one. This mistake reminds me of my 3 year old niece and nephew who are learning both French and English and sometimes mix up the languages within the same sentence or phrase.

It's interesting to me that the mistakes I'm making in learning to code are largely similar to first language (L1) acquisition (what babies/children do) as opposed to second language (L2) acquisition as an adult. With L2 acquisition, the mistakes can often come from, for example, falling back on L1 rules to supplement missing knowledge in the new, second language. With coding, this (for me!) is not possible. It makes sense, though, as I am learning my first coding language – although in linguistics, we learn that due to varying social, cultural and physiological developments between children and adults, the mistakes you make as a child will not be replicated as an adult. Me learning how to code seems to be proving this wrong!

Recognising patterns amongst what you're seeing, or hearing, is another common thread; realising that you can break them up into smaller blocks to perform another function is incredibly liberating, on both the coding and the speaking front. Anyone who studied spoken languages at school or university will undoubtedly remember being given a list of set phrases to use in essays, and inevitably these phrases, originally learned by rote, were broken up and used in different ways when it came to exams. So, when I was shown this Global CSS settings list for Bootstrap, it felt wonderfully familiar as the coding equivalent of this list of set phrases.

While there are other similarities between the various learning techniques, there are also some key differences. I've learned spoken languages in a variety of ways; intensive 8 hours a week of grammar for 2 years (bringing me to a basic level of Arabic); French, in small chunks since the age of 11, in France and at university; Spanish, intensively throughout 3 years and a stint in Spain, and German, exclusively by speaking and listening. The outputs of these methods have been varying in terms of the skills they've given me, but in all cases I've happily ended up with the desired skills, through what I believe to be the quickest route there.

Because of this experience, the main piece of advice I give to people wanting to learn languages is to first understand your motivation, and then choose your learning technique from there.

For example, wanting to speak German and be able to take part in conversations, but not being concerned about having good grammar, meant that speaking and listening to people and podcasts was a good technique, while wanting to learn how to read and write formal Arabic lent itself to intensive grammar lessons. So, what are my motivations with learning how to code?

I want to understand the world better.

I know that I don't yet fully understand what is possible with programming, and I see on a daily basis exciting projects and examples of programming being used to create things that astonish me. I love the idea of being able to communicate complex ideas to people in a way that they can really easily understand, or being able to help people who haven't (yet) been able to get their voices heard by decision-makers to have a say in how their world works.

So, my motivations in learning to code are complicated, and mixed, and, actually, fairly political. Clearly, this is where my stellar advice falls flat on its face; there's no learning technique here that will help me reach my goal quicker than any other.  

There is a key difference between learning a programming language, and learning a spoken language. A desire for communication seems to be the major driving force in learning any language. Whether you want to be on the receiving end of new types of communication (read books in a different language, or watch films), or whether you want to share your knowledge with others (speaking to new people, or writing for a new audience).

The crucial difference here though, is that with spoken languages, you can only communicate with someone who also knows that language. With programming languages, you can communicate with anybody. They can interact with the product of your coding without needing any understanding of how it was made; even if offline or away from a traditional computer, you can create or build things that can change people's perceptions and understandings of the world. 

And this is what I find wonderful, and beautiful, and slightly mystical, about coding.  

Read Post

Funny coding terms - a glossary

03 March 2014

As I've been learning more about coding, a number of unusual terms and phrases have come up, and I've been having fun finding out more and discovering their etymology. I'm documenting these findings in this glossary I've started, and I've set it up on Github to make it as easy as possible for others to contribute. 

It's in very early stages yet - I'd like to add examples of each term, and make sure it's explained in a way that non-coders can understand, too. I've tried to distill some technical explanations down into easy-to-understand definitions, so if I've made any mistakes in my understanding, please let me know! 

If you have any other terms to add, corrections to make or definitions to expand upon, please feel free to submit a pull request directly

Read Post

My first week with Git

25 January 2014

This week, I learned what Git really is, how to use it via the command line, and forked this lovely site to make this, my first Jekyll site! I was exceedingly lucky to have guidance throughout from some very clever, and patient, people.

In part to help me remember things I learned, and in part because part of me hopes one day I'll look back on this first week coding with nostalgic fondness in years to come, I wanted to write down a few things I learned.

First; the very basics. I learned what makes Git different to other Version Control Systems. I'd recommend looking at the diagrams on this page to understand this. We looked at how Git saves data through trees and blobs (incidentally, which stands for Binary Large Object, though I like the name 'blob'), and looked at how each 'commit' generates a unique 40-character object identifier, which you can see by typing 'git-show'.

One thing I found amazing about these identifier numbers is that as they are generated solely from the content of a certain repository, if you happen to have exactly the same content in a repository on two different machines, exactly the same 40-character identifier number is generated! We proved this by copying out two identical text files on two different computers, committing them to a repository, then comparing identifiers. It worked! (Aside: I downloaded the text editor 'Sublime' here to make creating and editing those text files much easier)

Next, some basic git commands to use in the terminal: mkdir, cd and git init, to make a new repository (more detailed instructions here), and also how to add a new file. I also changed the background of the terminal screen to black to make it easier to read, via 'Preferences' in Terminal.

Then; putting it into practice, as I wanted to make a simple website for my new project. As I only needed a holding page, I thought it might be a good time to try using Github pages, which makes it easy to get information from a Github repository onto a website – and, allows people to collaborate very easily – which runs off Jekyll, a “static site generator”, in Ruby. Basically, it makes making websites from text files very easy and really rather beautiful - these are all examples of sites that can be built on Jekyll.

Unfortunately, though much of the online documentation says that you should be able to get “from 0 to blog in 3 minutes!” I ran into a few problems here, as it was my first time using Jekyll, and Ruby, so I didn't have the prerequisites assumed in the quick start up guides. This is where I was very glad to have assistance from people who knew what they were doing – yes, the pains of installation will just happen once, but I would've been completely lost if it hadn't been for help at this point. Pro tip – Homebrew is a good package to install here, too.

Once I had Jekyll and ruby up and running, I set up a basic blog as per the instructions on this page. I picked one of the basic themes from this page and switched themes, after reading the instructions here.

But then some other more beautiful sites came to my attention... including this one, which was done by colleagues of mine for a hackday they ran last year. It's fairly simple, also done using Jekyll and Ruby, and it's on Github. I figured starting with something that looked so good must be easier than starting from scratch (though I have nothing to base this on.)

So – my friend Annabel helped me set up my own version of this, which we put in the repository 'Open Dev Toolkit' on my Github, so it appeared at http://zararah.github.io/opendevtoolkit. We also set up a local server which meant that the site appeared at http://localhost:4000/ in my Chrome window. So, I could make changes 'locally' (just on my machine) without pushing them to git- this made seeing what I'd done a lot easier. I set up the local server by typing “jekyll serve” into the Terminal, and I ended up leaving the command “jekyll serve -w” running constantly in one window of the terminal, and making my changes in git in another window. (The -w part of “jekyll serve-w” makes it automatically regenerate, so you don't need to keep cancelling it (with control-c) and running it again to see changes.

Then, the most satisfying part of this whole thing began – using what I had learned earlier to hack the website!

Here, I quickly established that 'Inspect Element' in Chrome was basically my best friend; seeing something on the site that I wanted to change, highlighting it and clicking 'Inspect Element' allowed me to see where exactly it was in the files, making it much easier to find which part I needed to change.

Once all that was set up, it was fairly simple; for example, the main heading, subheading and basic text was in the index.html file, so I did the following steps to change them to be relevant for my website:

I opened up the project 'opendevtoolkit' with Sublime, so that all of the text files that you can see on Github here were available. Then, I opened 'index.html', edited the relevant text, saved it, and looked what had happened on the local version I was running, at http://localhost:4000/ It had changed! So, as they were good changes, I wanted to keep them and put them online, also known as “pushing them” to Github.

In the terminal, I checked what I'd done by typing 'git-status'. As expected, there were changes there that hadn't been updated online: so next came the following commands:

git add “whichever filename came up when typing git status” (in my case, index.html)

Then, I needed to 'commit' the change:

git commit

...but, other people (and I) need to know what the change was, so here you're asked for a 'commit message' which describes what the change is. The commit message is, I learned, always written in the imperative – so, 'Update heading', for example.

Once that has been added, you're free to 'git push' which pushes the changes online. Ta-da!

Other tips I picked up:

  • If you've got text you want to edit on the website, but you're not sure where to find it within all the files, you can do a project wide search in Sublime, with shift+command+F to find out where it is.

  • Inspect Element is just great. Really.

  • If you're looking for a new font, look at Google Fonts – they're lovely, and really easy to implement (if you don't want to bother having them in a font file, it just takes one line of code which will be generated when you pick your font)

  • For creating the background image, I downloaded Inkscape – admittedly not very Mac friendly, but still good, and picked some public domain gear icons from the Noun Project to play around with. (Confession – I then sent it over to my rather clever friend Julia to arrange into a gorgeous looking tile design for me!)

  • I used the 'Eye dropper' Chrome plugin to find out where the colours were that I needed to change.

Then, it was just a case of lots of little changes, deleting lots of the content from the EnergyHack page as I didn't need it, updating content, changing the design and font, and there you go. My first Jekyll site!

A huge gigantic thank you to Nick, Stefan, Annabel and Michael for a. getting me started on all of this, b. not giving me all of the answers but showing me how to find them myself, and c. having infinite patience with my questions!

Read Post

Women in technology initiatives - all they're cracked up to be?

21 October 2013

Women Only - DAY 6

This article, on Posh white blokes in NGOs, caught my eye a couple of weeks ago. And then this reply, by an employee of an author of the first.

Rather than hashing over the whole discussion again, it's enough to say that I enjoyed a number of things about these pieces; that Ben Phillips was self-aware enough to write the piece, that Guppi Bola was pragmatic enough to, rather than simply talking over the issue, suggest some clear and concrete actions that NGOs and organisations can take.

I also enjoyed the fact that none of these suggestions involved gender stereotypes; no organic juices for the women, no football sessions for the men, but instead genuinely fair and balanced suggestions to help organisations be more diverse and “make change happen for real.”

This is not what I see in many other initiatives also claiming to make change happen; and here, I have specific examples to mention. Women in technology initiatives which, while with the best of intentions, miss the point entirely.

I've talked about women in tech initiatives with a number of friends and colleagues over the past few weeks, and it's been great to get people's feedback on some issues I've been feeling uncomfortable about. Here's why.

For women only

a. I want to be recognised or singled out on a merit-only basis, most definitely not because of my gender. I don't want to be offered special courses or have doors opened to me, purely because I am a woman.

b. The women in tech initiatives that tout the benefits of learning how to code as though its the silver bullet for everyone. An example of an article that does this is “I wasted four years of my life – don't make the same mistake” by Belinda Parmar, founder of Lady Geek. In short: studying anything but a STEM career, was a complete waste of time. Humanities didn't teach her anything.

“The next three or four years of your life may be romantic, inspiring and entertaining, but you are still wasting your time.”

Apparently, being inspired is a “literal” waste of time - slightly ironic then, that the blog was run in the series ‘Inspiring leaders’.

Learning how to code, or having a career in technology, is not for everyone, and this article, “No you don't need to learn to code” explains why, brilliantly.

c. In some ways, all-women initiatives reinforce gender stereotypes entirely. I once came across a list of things required to run a successful women-friendly hackathon, which included having a craft corner, providing organic juices, and running yoga classes.

The depth of gender-related assumptions and stereotypes within those suggestions; the fact that this was coming from someone within an organisation advising others on how to run women-friendly events; the assumption, above all, that all you need to keep women happy in tech is crafts, organic juice and yoga?! Please, give us some credit. Paraphrased from a colleague – what about good wifi and coffee?

But then, there are of course strong arguments to the contrary; women in tech initiatives have, for everything I've said here, done some great things. They've created safe spaces for women who might otherwise have not followed their desire to learn to code, or to start a career in tech, and they are inspiring girls to take up STEM subjects, with strong role models to follow.

It's no mean feat, and I don't mean in any way to undermine these achievements with my comments above; I just can't help but feel a little strange, sitting in a room full of only women, with computers in front of us. But a friend of mine expressed this situation very well recently:

“Perhaps the only way we can bring the balance to the middle is by skewing it really far the other way.”

It's a fair point – maybe, in order to balance out the years of male-dominated technology initiatives, we need to grow and support these all women initiatives, in the hope that one day the two of them balance out.

In the meantime, though, I do wish that all-women technology initiatives would take the time to think about how they are going about what they do, making sure that they're not reinforcing the gender stereotypes they've been working so hard against, and not losing that sense of self-awareness that is all too crucial to discussions about diversity.

Read Post