PS: this repo is an expression of my very personal view and process of going through a new programming language, plus some random thoughts of mine included in the process. It is also my proposal of solution to a nice coding challenge
Sample api in REST built on python that provides autocomplete suggestion for cities.
This repo is a fork of Coveo Backend Coding Challenge and represents my solution proposal to its challenge at the date of the fork.
I built this application using Python version 3.6. By the time I coded this, I was not literate in this language. I didn't have any previous background prior to this small challenge. Even its famous libraries are relativelly unknown to me. But altough it's the first time I write in python, I do take responsability for the design choices I made with the languages capabilities that I discovered whlist building this simple app.
Honestly, I didn't overthink in order to choose Python for the challenge.
- I wanted to use a language that I didn't have any previous knowledge because my primary intention is to learn and stimulate my brain, not to show off. It also has a lot of scripting traits (which envolves a different mindset from what I am used to) and it seemed easy to take a grasp.
- It's validated by the community : widely appreciated, trending, relatively mature (still have its way to grow though).
Another reason that I considered for this was the fact that this language has become very popular inside universities. Altough I've never built an autocomplete algorithm before, I foresaw that I would need some specialized data structures and/or ML algorithms, ressources that are constantly improved on academic research and are largely available with permissive licenses on this language.
- Very cool language, succinct, easy to grasp, fast to code.
- Has tons of built-in components and it's growing steadly.
- Syntax is clean and elegant.
- A little too much permissive for my personal taste. At the root level, everything is public. Maybe it's just a shift of perception, but this kind of openess is a little odd for me, since it might open space to some unwanted, non-orthodox creativity from unexperienced developers.
- The language changes (that's only natural) and so does the syntax for achieving a result. However, I stumbled across async/await on python 3.X, for example, and found a lot of different patterns (some created on the beginning of the language, others rather recently) and you can achieve similar results with very different syntaxes. Some choices becomes confusing when your introduction to the language is on a late version. I feel like I mixed old and new patterns in this coding challenge.
But in summary, the language is awesome and its Pros wheights a lot more than these small Cons.
I consider myself relatively proficient on Visual Studio, so it was my first choice of IDE. The idea was to invest time on the learning curve through the core concepts of the language and gain time on the tools. My intention was to lever from that VS way of creating some closed tiers of abstraction on the IDE in order to hide and handle some command lines, marginal downloads, installations, etc. Not the wisest choice, I guess. Identation/spacing bugs on the text editor has been annoyingly painful and cost me some precious time. Besides, I'm missing some alerts and errors on compilation time.
Migrated (partially) to VS Code. Much better!
src: Application codetest: Test project
I was considering to add pytest as test framework. But I decided to only stay with 'unittest' because it integrates better with the IDE that I'm using.
About the project structure, I found two main streams of thoughts :
- (1) test files inside the src project and side-by-side to the content it tests (with some name convention, like, 'test_foo.py' to test 'foo.py' or 'test_foo_sufix1.py' if multiple test files are preferable)
- (2) test project in a different module
I'm going with (2) the test project in a different module because I don't like the idea of doubling the size of the deployable and send test code mixed with production code. The path to the tests is the same path of the source element it tests in 'src'.
There is however a somewhat hidden beauty on the simplicity of (1) : you keep phisically together things there are semantically related and intuitively supposed to be close. Maybe a decent solution to this would be to go with (1) but skipping the compilation of every test related content (including eventual external dependencies).
All test methods have a 'test_' prefix. This name convention is necessary for the IDE I'm using to find the tests on compilation time.
I was between Flask and Django, since both are well stablished web frameworks for python. I decided to go with Flask because from what I saw Django uses a "batteries included" approach that brings the gorilla and whole forest when all you asked for was a banana. Flask on the other hand is this web microframework that contains only the core tools for web development, which seems a better fit for a simple scenario such as this.
Flask-RESTplus is a lightweight plugin that improves Flask by adding better annotations to describes the REST API and expose its documentation as a Swagger interface, which is pretty clean and free from heavy dependencies.
Typings is a library that adds hint typings. It helps mitigate some basic compilation issues.
Geopy is a geolocation library. I use it to compute lat-long distance using Vincenty's equation, ellipsoid standard WGS-84, which gives better results since it considers a more realistic curvature of the earth.
This sample application uses Geonames's dataset to build autocomplete recommendation for cities in Canada and the USA. Geoname is governed by a CC3 license. More information is available at http://download.geonames.org/export/dump/readme.txt