Money, politics and cars collide in the blink of an eye.

Should a car drive off a cliff to avoid two jaywalking pedestrians or should it strike the hapless jaywalkers to save its single occupant? The moral questions behind scenarios such as this are important when designing the crash code that drives autonomous cars. This code will have the ability to calculate the risks, costs and consequences of an accident in milliseconds. A key assumption in the debate around these questions is that this code will be transparent, with the public having full access to it and engaged in its design. But will we?

Much like in the healthcare industry, it isn’t the doctors or patients that ultimately decide treatment programs; it’s the insurance companies. And with autonomous cars, it’s likely the insurance companies will be controlling the crash code (either directly or indirectly). Accountancy firm KPMG have predicted the auto insurance industry could decline from $US140bn to around $US50bn over the next couple of decades. With so much at stake, insurance companies will be increasingly engaged in the design and control of the crash code. So what will that look like and what role will users and policy makers have? Let’s start at the point of impact.

Not all accidents cost the same.

Scenario One: An entry level hatchback is driving through a wealthy suburb. Its occupants are two house cleaners from a poorer neighbourhood ride sharing an autonomous car on the way to work. A mother and child dart across the road in front of the car, the car can save the occupants or the pedestrians, not both. It calculates the cost of hitting the wealthy pedestrians to be higher than the cost of saving the occupants, and so off the cliff our cleaners go. Nasty, right? It gets nastier.

Scenario Two: A Ferrari being driven through a poor suburb, let’s say pulling off the motorway to buy gas. Its occupants are a wealthy couple on the way to their holiday house. Same scenario, two pedestrians dart in front. What does the car do? In this case the car calculates the pedestrians are likely poorer than its occupants (and its own self worth). It calculates the lowest cost to the insurance company is to strike the pedestrians and save its occupants.

In essence it’s the same, scenario but with two very different outcomes driven by balance sheet motives rather than morals. They’re extreme examples, but the insurance companies would have to program for scenarios such as these. It’s clearly immoral. So you say we monitor the insurance company software and call out immoral code? There’s a problem with that.

Independent researchers don’t have legal access to the algorithms.

Under the Digital Millennium Copyright Act, there is no legal means by which independent researchers have access to the code. It’s a piece of legislation written in 1998 to protect the ownership rights of movie makers. Basically preventing internet pirates from ripping off DVDs. Some believe it to be a masterful piece of legislation that spawned the internet into the success it is today. Others see it as an antiquated bill that now doesn’t even perform the original task to which it was intended.

“It’s like traffic rules for carriages with horses, and you have autonomous cars now.” Why Taylor Swift Is Asking Congress To Update Copyright Laws, by NPR

This was the problem with the case against VW and its ‘clever’ emissions software. VW was only caught out by researchers testing the actual emissions from the cars. This then allowed law enforcement to open an investigation and discover the sketchy code. With so many variables in a car accident, it would be very hard to prove that something untoward was going on. And without a smoking tailpipe, as in the VW case, it would be almost impossible to open a formal investigation.

But there is hope, an exemption to the legislation allows access to software by legislative researchers. That is, government. It could fall on law makers to legislate the algorithms. But there are a couple of problems with that.

The insurance industry is the second biggest lobby group.

Spending over $150m in 2015 lobbying politicians, second only to the healthcare industry. With so much at stake and very deep pockets, the insurance industry will lobby hard. The way congress is looking these days, it seems improbable they’ll take much of stand against the lobby groups. And even if they did…

Code, code and more code.

Getting access to the code and knowing what it does are two different things. Investigators in the VW case struggled to understand the code and who had written what. The insurance companies could well create code that is so enormous that it would either be too expensive or simply impossible to understand.

Consumers get to choose though, and they’ll choose transparent insurance, right?

Yes and no. When all cars on the road are connected and autonomous, your life is not only in the hands of the software in your car, but in all of the cars on the road. Hands up who believes man-made climate change is a thing. Now hands up who’s still driving a gas powered automobile. Mmmm, why the difference? We’re not exactly selfless when it comes to our buying behaviour. So if given the choice — expensive car insurance that’s open and transparent (but may result in your own death) or the same cheap insurance as every other car on the road — on balance, I suspect most people will choose the later.

And who’s car is it anyway?

Some have said that in the future we won’t own our own car anyway. Consumers could belong to a subscription service, a hybrid of Zipcar and Uber that summons a car on demand. Ownership of the cars could well fall to car manufacturers who will run fleets of their own cars. And it will be the providers of these services that would negotiate and choose the insurance for them. Car companies don’t have a great track record when it comes to putting human life over profit. It’s likely they’ll opt for the cheapest insurance, not the most human-friendly. And I don’t fault the individuals that work for these organisations. Malcolm Gladwell’s article in the New Yorker covering the Pinto scandal in the 1970’s, outlines how hard it is being an engineer in a car manufacturer business and how the organisation has an almost gravitational pull toward profit over morals.

What’s the solution?

Insurance companies aren’t inherently ‘bad’, but they have a responsibility to shareholders to do everything they can to maximise company value. Lobbying politicians is a tool they use to do this and managing the code that determines their cost of accidents will be another. If we want them to act under some form of moral guidance, then we need to create legislation that directs them in the direction we want.

Rather than spend our time debating the morality of 1,001 different accident scenarios, we need to think deeper about DRM and create a framework in which open and transparent crash code can be implemented. We need some way to monitor the crash code the insurance companies create. The Digital Millennium Copyright Act was designed to keep money flowing into film studios. It wasn’t designed to monitor life-and-death crash code. There is work being done by the likes of the Electronic Frontier Foundation, into opening up the software that lives inside cars. But they concede the road is long and hard. I’ll leave the last word to them.

“When you entrust your health, safety, or privacy to a device, the law shouldn’t punish you for trying to understand how that device works and whether it is trustworthy.”

Note: I’m focusing on the situation in the USA. It’s probable that it will play out differently across countries, but I’m based in the US so it makes sense to address the situation here.

Startup Story: EataCity From Start to Finish

I created EataCity because travel is important me. I want more people to travel, to explore, and to have genuine connections with the world around them. Eating is a great way to connect with a foreign land and its people. We all eat, and food has the ability to pull people together, to create shared experiences and a greater appreciation for other cultures. To eat in a foreign country is to experience that country.

The Problem to Solve

I felt (and still feel) that it’s too hard to find genuine places to eat when travelling to a new city. There are some user-generated travel websites that provide guidance from other travellers on where to eat. But frankly, they suck. Homer from Springfield doesn’t actually know much about ramen in Tokyo, in fact he doesn’t really know much about Japanese food in general. Traveller review sites are great for things like hotels and sightseeing, but when it comes to food, they end up creating little echo chambers in which everyone ends up in the same places. So when I say genuine, I mean food that is unique to that city, has a place in that city, or is just so damn good it deserves a mention. Recommendations for these types of places already exist on the internet. There isn’t a lack of good content, on the contrary, there are a tonne of great travel writers, professional restaurant reviewers and food bloggers. But all of this content sits in little silos. With EataCity I didn’t want to write another travel guide, I wanted to tap into existing content and make it more discoverable. So how was I going to do it?

The Idea

I would find the best food writers and local food bloggers with relevant content for foodie travellers. Then use web crawling and machine learning to auto-tag reviews and curate them into city guides with links back to the original websites. This would make it easier for travellers to find the best places to eat as chosen by those who know the city well.  At the same time, I’d be generating traffic for and promoting local food bloggers. Win for the traveller, win for small food blogs.

The Business Model

Now, how was I going to make money out of this? I knew it would be a tough job generating ad revenues given that I wasn’t going to have a lot of original content which means low SEO, and I was targeting a segment with a relatively infrequent need. For both of these reasons, I knew it would be hard to drive a regular audience and readership, which meant getting enough page views for an ad-based revenue model would be hard. I could create an app and charge for it, but a core piece of the proposition was linking back to the original blogger’s website and I couldn’t offer a roaming friendly offline version while providing those backlinks (for obvious copyright reasons I wasn’t going to copy the whole review and post it on EataCity). 

Product Design

So I opted to curate the recommendations around neighbourhood guides that included hand-picked hotels with affiliate links to a booking platform to generate revenue. To do this I was targeting people in the discovery stage of booking travel, maybe they had already booked flights, but wanted to know where to eat and in which neighbourhood they should stay in. Typically this exploratory stage (especially for my target segment of full-on foodies) is done on a laptop/desktop. So EataCity would look like this:

  • A desktop-centric (but mobile responsive) Django web app.

  • Crawl and auto-tag restaurant review websites using machine learning techniques.

  • Curate all reviews into a city guide displaying tags, review title, and link back to the original creator.

  • Auto update content using RSS as new reviews are posted.

  • Segment the city into neighbourhoods with affiliate links to hotels ($$$).

  • Easy, right? What could possibly go wrong?

Building It

Ok, so the first step was to learn how to build a web app. I had some experience with SQL and JavaScript in past roles, but building a website was new territory. I won’t go into great detail here as I’ve covered how I built the site and the tools I used in this post. First step was to find local content to include in each city guide. This was actually pretty straight forward. Find bloggers, crawl their site, grab the post title, link back to the original post, and then add each restaurant reviewed onto a Google Map.

Google have some great APIs for this type of thing. The hard part was knowing that the place called ‘Taberna Laredo’ on Google Maps was the same place bloggers were referring to in the reviews titled: “Tapas at Laredo”, “Restaurant Laredo” or “Dining at Madrid’s Laredo”, but not the same as “Finding a Taberna in Madrid”. As an aside, I had hoped that the web would generally head toward a Structured Data approach and this would make place matching between content and Google Maps easy. Alas, this hasn’t happened and very few, if any, bloggers use structured data.

In the early days, I had a fairly manual approach to matching these up. I used the Google Maps API and a text matching Python package to give me a match score. If a review title matched a Google name perfectly then it would get auto added to my database, whereas if there was a low level of similarity between the title and a Google place name it would throw up an exception. I got better at this once I started matching URLs mentioned in reviews with the website address in the Google Maps Place Details API. URLs have a higher level of uniqueness and I had a far higher success rate than using just the review title.

So now I had a bunch of popular restaurants in a city with links to food blogger reviews of the restaurants. Quickly a couple of problems emerged: depth and quality of content. A few of the early cities, for example Madrid, Prague, Munich, Vienna and Barcelona, are all great food and travel destinations, but the proposition just didn’t stack up. Firstly, there weren’t enough bloggers in each city to warrant a curated guide. And secondly, for cities where there are lots of bloggers, e.g. London, Paris and Singapore, I didn’t have a great library of images to pull from and the images I could use were poor. In an Instagrammable world, this is a problem. People want photos!

From tech-founder to… food blogger?

The solution to this problem became mistake number one. I hit the road… I packed up my camera and started eating! There’s good reason for doing this; I had to be user number one and prove that the guides actually worked. And then there’s a bad reason for doing this; I thought I needed some of my own content like photos and reviews to beef up the general appearance and quality of the website. But I temporarily forgot that I wasn’t trying to be a food blogger, I was supposed to be creating a data driven approach to food travel guides. The upside was that I got to do a bunch of travelling and eating at some amazing restaurants.

Over the course of 18 months, I visited over 600 restaurants, cafes and street food stalls from Tokyo to London. Not to mention, plenty of great bars in between. And because I was creating neighbourhood guides that included hotel recommendations to support the revenue model, I made a point of never staying in the same hotel for more than 2 nights. If I was in a city for 4 days, that would mean staying in at least 3 hotels in 3 different neighbourhoods. It was a great experience! (Except the time we were caught up in the Paris terrorist attack.)

The quality of the content on the site got better, my photography skills got better, and I learned the difference between a bad hotel and a great hotel. But the only thing scaling up was my waistline. It turns out that eating at 5 restaurants a day isn’t that great for your health. On top of that the cost of all this travel was starting to add up. Not that my co-investor (my wife) seemed to mind, she’s an even bigger foodie than me and was happy to come along on several trips to help empty the plates and glasses.

So then the revenue started to roll in?

Now this would have been fine if my assumptions about the revenue model stacked up, but they didn’t. My original assumptions around traffic and conversion required to generate the first $100k in revenue seemed embarrassingly small. Boy was I wrong! The revenue I was getting from hotel bookings through my affiliate partner didn’t come close to covering costs. I don’t blame the booking platform, I blame my naivety.

Firstly, getting traffic was harder than I thought. I was competing on SEO with some big established players, and in SEM, I was competing with a bunch of other established players willing to spend big $$$ on CPC. I could get traffic to the site, I could send this traffic to the hotel booking platform, but it wasn’t converting into bookings at rates that were anywhere close to what I was expecting. The SEO pros will tell you that original content is the way to boost your ranking, so I was stuck between a rock and hard place. I wanted to build a scalable website that curated existing content without the need to constantly write my own content. It’s this conflict that ultimately led me to walking away. Google promotes original content creators over curators and aggregators like EataCity and for good reason. I knew this going in, but a little hubris got in the way. I assumed my amazing product would overcome this hurdle.

Build, Break, Learn, Fix and Repeat.

Over the last 6 months, I tried a few things to scale the site. For example, I created a sentiment analysis program to find the restaurants most liked by bloggers. Unfortunately, this didn’t work, some bloggers give very dry objective descriptive reviews like “I ate a tapas of shrimp on toast”. Basically no sentiment at all. And others write very long reviews that meander in all sorts of directions, something like: “when I visited restaurant X I had fond memories of my time in Spain, the wonderful food, the tapas, fresh seafood and delicious wines. Last month I went to another Spanish restaurant in London called restaurant Y, and it was exactly how I remember Spain, it was utter perfection. Unfortunately, restuarant X does doesn’t stack up. The food missed the mark, it was bland and horrible.” Trying to get a sentiment analyser script to understand what’s going on there is simply beyond my programming skills. So I shelved that one.

I also played around with machine learning and clustering. It worked a little like an Amazon recommender engine to group similar reviews together. Alas, this didn’t work as well as manual curation. In some cities the best restaurants might be a mix of fine dining, local neighbourhood restaurants, and a random Thai place (yes, I’m talking about you Copenhagen). Clustering with machine learning does the complete opposite of this. My last ditch attempt at keeping it alive was to create a purely code-driven guide and see if it worked as well as the current guides. I would rely only on code with little/no manual interference from me. Enter Mexico City. For this I used TFIDF, or Term Frequency Inverse Document Frequency.

So a quick intro to TFIDF. Step one, take all of the reviews in a city and dump all the words in those reviews into a big bag. Now take all of the reviews about a certain restaurant and dump them into a smaller bag. Now compare the words in the restaurant bag against the words in the city bag. TFIDF gives each word/phrase a score based on how frequently it is used to describe a restaurant versus how often that word/phrase is used to describe all restaurants. So a word like ‘good restaurant’ that is used very often gets a very low score, but infrequent phrases like “fresh seafood” and “tuna tacos” get high scores. This way you can tag restaurants against key words/phrases.

So I set up scripts to:

  • Crawl all reviews of restaurants in Mexico City, with links back to original post.

  • Match review URLs to Google Place Details web URLs.

  • Crawl the whole review and create a bag of words model for TFIDF.

  • Use TFIDF to generate tags to describe restaurants, e.g. Reviewers of Don Toribio talk about: "Argentinian/Mexican Parrilla", "Huevos Rancheros", "Milky Coffee", "Old-World Atmosphere Bills", "Skirt Steak", "Spacious 19Th-Century Salon", "Spicy Tomato Sauce", "Sweet Rolls", "Tortilla Soup" and "Typical Mexican Breakfasts".

The result was something that users thought showed promise but needed work. I thought with some tweaking, I’d be able to get it to a place that worked pretty well. But… the guide still lacked what people wanted: photos. I thought about continuing with a word-based website with just a few images, perhaps one per restaurant. But in the end I couldn’t solve the revenue problem. I could scale up EataCity with this approach, but the UX was suboptimal and I still had no way of making enough money to justify the time spent building it.

An Empty Plate

And so that is the finish of EataCity. I’m going to keep it alive to play with on the side, but it’s no longer a full-time deal. Hopefully, this will be useful for anyone wanting to do something similar in the future. If you want more detail or to chat about what I did, feel free to contact me.

Happy travels!

The Quick Guide to Blockchain, Bitcoin and other Digital Currencies

Don’t know your blockchain from your Bitcoin, Ether from your Ethereum? Here’s a quick digital currency guide for non-techies. I've glossed over a lot of the technical detail, this is designed to give you a basic understanding of what's going on.

What’s the blockchain?

Think of the blockchain as a giant book that records information. The first person writes a page of information in the book and passes the book onto the next person. The next person takes a copy of the whole book, writes a new page of information, passes it onto the next person, and so on, and so on. This means lots of copies of the book exist and no one can change information in the book without it conflicting with all the other versions of the book. The blockchain works the same way. Each page in the book is called a block and each page is linked together to form a blockchain.

 You will often hear people say ‘the’ blockchain, as if there is one official blockchain. That isn’t the case. Anyone can start a blockchain to store any information they want. Literally anything. Forgetful with birthdays? Start a birthday blockchain to record birthdays and never forget a birthday again. Want to trace where your coffee comes from? Easy, start a coffee bean blockchain to record each of the following transactions:

  • A coffee bean farmer records the volume of coffee beans harvested.

  • A coffee bean distributor buys beans off the farmer.

  • A coffee roaster buys beans off the distributor.

  • A coffee roaster then sells some roasted beans to your local cafe.

As a consumer, you can now use the coffee bean blockchain to trace back where your cup of coffee came from. Every bean from farm to cup is accounted for and no one can cheat by mixing in some cheap beans in with your fancy coffee.

But how do people know how to record information in each block? There are rules for how information should be stored, like a set of instructions written at the start of the book. These instructions are in the form of a software program called a protocol. This way everyone using the blockchain is working off the same set of instructions/protocol.

That’s it. You now know what a blockchain is.

Ok, so what is Bitcoin?

Bitcoin is different to traditional currencies in that it isn’t controlled by any government. The rules that control Bitcoin are written as a protocol, anyone can buy and sell Bitcoins, and transactions are recorded in the Bitcoin blockchain. If Alice wants to send Bob some Bitcoin, a transaction is recorded in the Bitcoin blockchain that looks something like this:

12 June 2017 12:36 (Time of transaction)

123456789 (Alice’s Bitcoin address)

1BTC (Amount to be transferred)

987654321 (Bob’s Bitcoin address)

Well that sounds easy, but where do Bitcoins come from?

Traditional currencies are issued by a government’s central bank. It’s their job to print new money. But there’s no central bank for Bitcoin, so how do new coins get created? They’re issued to people called ‘miners’. The term comes from the idea that these people are ‘mining’ Bitcoin, but you can think of them as ‘writers’. It’s their job to write a new block in the blockchain to record Bitcoin transactions, and for their effort they get given some new coins. They also receive small transaction fees for the transactions they have recorded to the block. Although this transaction fee is actually voluntary, good luck getting a miner to record your transaction in their block without including a transaction fee.

 Now before you get the idea that you might become a Bitcoin miner, know this: it’s hard! A new block is created every ten minutes, and for each block there are thousands of miners all competing to record that block of transaction. Teams of coders work together to give them a chance of writing the next block. It’s this collective and distributed work that helps keep the chain honest. Every miner that is competing to create the next block gets a copy of every transaction to be recorded in that block. That way if a dishonest miner tries to manipulate any transaction in the block, the other miners all say ‘oh no you don’t!’. The miner who solves the computational problem to create the block gets the reward. Currently, miners recieve 4 Bitcoins for every block, and at today’s Bitcoin prices that’s around US$10,000.

This won’t go forever; the amount of Bitcoin that miners get for their work decreases slowly over time and there is a maximum of 21 billion Bitcoins to be mined. There are currently around 16.4bn Bitcoins in circulation and the last coin is expected to be mined around the year 2040. After that, it’s expected that computers will be fast and cheap enough that miners will make enough money just from the transaction fees to make it worth their while.

How can you buy Bitcoin?

The easiest way to buy Bitcoin is through an exchange, and there are a lot of them. If you’re planning on holding Bitcoin for a long period of time, it’s safer to transfer your balance off the exchange onto a Bitcoin software wallet, or even better a hardware wallet. A software wallet is like transferring money from a share trading account into a bank account, while a hardware wallet is like withdrawing cash and carry it around with you. Before you buy Bitcoin or any cryptocurrency, I suggest you read up on the various exchanges and wallet types. Unlike a bank, there isn’t much in the way of customer support. If you lose your bitcoin address, then you lose your Bitcoin.

 Can you transfer a fraction of a Bitcoin?

Yes. Think of a Bitcoin as being a dollar and a ‘satoshi’ (named after the mysterious creator of bitcoin) as being a cent. There is a big difference though. While there are 100 cents in a dollar, there are 100 million(!!!) satoshi in a Bitcoin. That’s like 0.000000001 Bitcoin.

How many digital currencies are there?

Bitcoin is just one of hundreds of currencies. Just like anyone can start their own blockchain, anyone can create their own digital currency. Most of them are very similar to Bitcoin, others work quite differently. But each have been designed to meet a specific need, and the instructions of how to use each currency are written in their own protocol.

So next I’ll give you three examples of other currencies. This is not a complete list, but hopefully you’ll get an idea of the differences and what’s possible with digital currencies. The purpose of this guide is just to give you a basic understanding of how it all works. If you want to start buying, selling and using any digital currency, then I suggest you start doing your own research into which exchange, which wallets, and which currency is best for you.

1. Apps, it’s all about apps baby! Ethereum and the other new platforms

So remember that all the blockchain really does is store information. This information can be whatever you want it to be, and at the same time it allows for the transfer of digital currency. Well imagine you’re an app builder and you want to build a ride sharing app like Uber or Lyft. Typically, what you do is build an app with a database to record all the rides that people take on your app, and then plug in a payments engine to take payments from riders and pay money to drivers. Now I know what you’re thinking; you’re thinking “wait...couldn’t you just record all of this in a blockchain? No need to pay for an expensive database, no need to use a separate payment engine.” And you would be 100% correct. 

This is the basis for the Ethereum platform. It’s a more sophisticated protocol than Bitcoin’s and allows for greater flexibility. It has it’s own type of currency called an Ether, which works in a similar way to Bitcoin. Ethereum is fast becoming the darling of the tech world and is attracting developers and investors alike. The value of Ether has risen from US$8 at the start of this year to staggering US$350 as of early June 2017; that’s a >4,000% increase! Woah.

So back to your ride sharing app. Users of your app can pay and get paid in Ether. Cool, huh? What’s cooler is that they don’t have to use Ether; you can create your own currency on the Ethereum network. These currencies are known as ‘tokens’. For example, for your ride sharing app, you could create a token called a CabCoin. Congratulations, you’re now the proud owner of your own currency. Which means you can start selling your currency to people. And that leads us to our next jargon acronym, an Initial Coin Offering, or ICO.

ICOs have created a bit of a buzz this year. You probably know how most startups get funding. They find an investor, either an angel investor or a venture capitalist, to invest in their business and use that money to develop their product and grow their user base. You probably also know how Kickstarter works. Companies seek funding for their business by selling the product to the public before it’s launched. Well an ICO is kind of a cross between the two. Startups on Ethereum can bypass VCs and go straight to the public to get investment. But instead of selling part of their business, they’re selling some of the tokens they’ve created. Let’s say you work out you need $10m to get your ride sharing app up and running. You can create 100m CabCoins and sell some of these before your launch to raise money, say sell 10m of your CabCoins to the public for $1 each. If people decide that your Ride Sharing app is going to be a massive hit and therefore the value of CabCoins will rise over time, they can buy some CabCoins during the ICO.

So far this year app developers on Ethereum have raised over $350m in ICOs. You can read more about them on this Techcrunch article.

2. Faster and cheaper transactions, Ripple’s low cost solution to foreign transactions

Currently, big banks pay high fees to move money around the world. These transactions are part of running a big international bank. The system that moves this money around is old, slow, and can involve lots of intermediaries. Ripple is designed as a faster and cheaper alternative to the current system, and has its own currency called Ripples (XBT). In theory Ripple will allow banks to clear international transactions in seconds rather than days and at a much lower cost. It has gathered the interest of quite a few banks across the world and many of these are running pilot schemes.

 Ripple has one big difference to Bitcoin in that it doesn’t have a blockchain of transactions with miners recording each block. Instead it has a thing called a distributed ledger. It’s designed this way to put more of the work behind recording transactions into the hands of the banks participating in the platform, rather than third party miners.

3. Private transactions, secrecy and drugs

All transactions in the Bitcoin blockchain are publicly viewable. No one can see your real name, but they can see your Bitcoin address and this makes transactions somewhat traceable. Some people don’t want their transactions being stored in plain view of the public. They find it creepy. Others believe Bitcoin’s publicly available transactions records make their Bitcoin susceptible to hackers wanting to steal their money. And other people REALLY don’t want people seeing their transactions because what they’re doing is frowned upon by law enforcement agencies, e.g. selling illegal drugs online. So a breed of cryptocurrencies has come along to solve this problem. These currencies specialise in keeping transactions private, away from the eyes of hackers and law enforcement officials. Examples are ZCash, ZCoin and Monero.


So I hope that gives you an idea of what the blockchain is, a basic understanding of what Bitcoin is, and some other currency types. I’ve tried to make this as easy to understand as I can, but if there is an area you’re still unsure about then contact me and I’ll try to update this guide with a better explanation.

Guide to Building a Django Web App, Lessons from a Non-Coder.

Learning to code is fun. Well, I think it is. There is something quite satisfying in building something on your own and seeing it come to life. When I started EataCity I researched a lot of ‘getting started’ resources for how to build a Django app. To help other people wanting to learn Django and Python I’ve written a quick this quick start guide. These are the sites I found most useful. If you follow these you’ll be able to build a pretty good Django web app from scratch, have some basic Python skills, and get an understanding of what’s possible with Django/Python add-ons.


  • Learn Python the Hard Way.  For the most part, the Django resources I’ve listed below cover all of the Python you need to know, but it’s good to start with some basic understanding of Python, especially if you’ve never coded before. This book is a quick way to learn the basics of Python, and don’t be put off of the title - it’s not that hard. Some learning to code sites, especially the ones with online videos where you code through a browser, are like coding with training wheels on. The Hard Way removes the training wheels and makes you a better and more confident coder faster.


  • Django for Girls (The basics). This is probably the fastest way to start with Django. Super easy to understand tutorial (for girls and boys). They’re also a great organization teaching girls to code, so if you do use it consider donating a few dollars to the cause. This will have you build and deploy a basic website in about two hours...that’s FAST!

  • Marina Mele's Taskbuster Django Tutorial. Once you have a basic web app up and running Marina’s tutorial takes you one step further, gets a bit more into the details, and provides a real world example of an app to build.

  • Two Scoops of Django. This covers more advanced topics, written by a couple of Django pros. You can get by with the Django for Girls tutorial, but if you want more flexibility and to make the most of Django, then this is the book to have.


  • W3Schools. Django is just a framework; once you have the basic app up and running you’ll need to fill it with stuff to turn it into an actual website. At a minimum, you’ll need to know HTML, CSS, SQL and some JavaScript. The place on the web for all of this is W3. It might sound daunting to have to learn all of this, but the tutorials are straightforward and you only need to know some basics to get started, then you’ll be up and running in no time.

After Deployment

  • Pony Checkup. Once you’ve built your app you’ll want to check it’s secure. Pony Checkup is a easy way to see how secure your app is. This is more of concern if your website is asking for user data and using forms etc…

  • Stackoverflow. This is the best Q&A site for developers. If you’re just starting out with Django and Python, and can’t find the answer here, then you’re probably doing something fundamentally wrong. At times I relied on Stackoverflow too much, using it as a crutch rather than learning and fixing problems on my own. So before you google “stackoverflow [your problem]”, spend at least an hour trying to solve it on your own, and it’ll make you a better coder in the long run.

  • The real power of both Python and Django is the massive community of developers contributing open source software packages. You’re going to be standing on the shoulders of giants here. I’ve lost count of the packages I’ve tried out. Some were invaluable to EataCity, others...less so. For a list of Python packages refer to Python Package Index . For example, I use Andablog for blogging in EataCity.

  • Google Analytics. You’re going to want to know who’s using your site and how. GA is the easiest, fastest and cheapest way to set up website analytics. 

Congratulations! You’ve now built your first Django web app. Contact me if you have any questions or you want to add to this list.

 Good luck!