Kartones Blog

Be the change you wanna see in this world

Pet project: Shopping Lists published

As I'm moving towards fully removing all .NET projects I had, I've spend some time migrating some C#/ASP.NET code over to Python + Flask. One of the projects that could be of some interest, if only as a sample of a simple Flask app and Python file I/O, is my Shopping Lists pet project.

It's a quick & dirty web solution but we use it at home almost daily so it serves its purpose. As at least my colleage @Saski asked me if I was going to publish the source code, now that it's migrated to Python, you can find it at my Github, alongside some simple instructions of how to setup and use it.

Screenshots

It was one of my new approaches to development, keeping things minimalistic and simple: the "database" are plain text files, it has minimal functionality but it works in mobile (as will be where it will be used most frequently), and while is not a code I would showcase, publishing it can help me in the future to remember some basic Flask routing and redirects syntax, reading and writing files, etcetera.


Software Developer Position for TheMotion

We are searching to fill a software developer position for my team at TheMotion.
Currently we have no open seats for tech recruitment, but I'll leave the description as it was a nice showcase of what we valued.

You can be senior or junior. Although the more experience the better, I don't care as long as you have some development knowledge, will to learn and an open mind (our system evolves fast). If you're senior you'll have more freedom, if you're more junior we'll guide you.

You should be a good team player (we don't want heroes, rockstars or similar buzzwords), and while we currently use Python 3, Docker and a bunch of AWS services, everything might change so there's no need to previously know about the specific languages and tools. In fact, at least half of tech employees joined the company not knowing Python.

You must like to do javascript, as our team currently is the "keeper" of most web services: public API, Web application, mailing, video distribution channels... We also setup the infrastructure for other web projects and APIs and help building and maintaining core platform services. We just do more javascript than the other teams, but not all the time, for example this past months we've done way more backend Python than JS. For the record, we currently use Ember.js 2.x and ES6.

You need to have a minimum level of english to understand and carry a basic conversation, but our British english teacher will help you improve no matter your level. This is why the job offer is not in Spanish ;)

We all do full development cycles from coding and testing to releasing and monitoring, QA and even setup the microservices configuration, so you must not be scared about configuring Dockerfiles or Travis ymls. Forget about "coding your stuff and somebody else will release it". We each push code multiple times per day and aim to have soon continuous delivery and blue/green deploys, but you will see we also already have a nice infrastructure with tools to ease your day to day.

You will be mentored for the first month(s), depending on the needs. One of the core goals is to share and spread the knowledge among all tech, so we not only encourage to do pairing (and TDD if you fancy it), but we're also starting to do inter-team pairing to get fresher points of view and advices, and of course to avoid knowledge silos.

Eventually most engineers will do on-call, but don't worry as we will train you when the time is right and help you so everything will be as smooth and easy as possible. It is a rotating shift (one week long), so the more people the less frequently it will be, and of course paid separately from your base salary.

We are a remote-friendly company (sadly not remote-first yet), so we encourage you to work remotely once per week if you want. You choose the day, but we try to spread so always there's somebody not in the office and we force to do online meetings, keep team diaries and communicate as much as possible. The position is initially for Madrid office, but could be negotiated.

As for the extras, we have fresh food & coffee, english lessons on tuesdays as mentioned earlier, and whenever our beloved teacher is available, also a weekly office yoga class on thursdays. We're trying to have either weekly or by-weekly internal workshops, although depends on availability of the designated speaker. There is also a monthly budget for books, conferences and/or internal training.

We're few engineers but growing at a slow but steady pace, at a young company but already with paying clients, and in general we're on that startup phase where not all is yet defined so anybody can help shape things. We will probably trash or evolve some pieces, iterate dozens of times on others, but we also have a core stable and robust rendering pipeline with scalability challenges.


If some or all of this looks interesting to you, drop me an email (kartones at themotion dot com), a Linkedin message or a Twitter PM (I've got them open so no need of following) and let's talk.


Book Review: Console Wars

A different reading from my recent vacations. I have other similar books in the reading queue, but as I vary the topics/genres...

Review

Console Wars: Sega, Nintendo and the Battle That Defined a Generation

Title: Console Wars: Sega, Nintendo and the Battle That Defined a Generation

Author: Blake J. Harris

Console Wars talks about a small but intense period of time, from 1989 to 1995. Ending the eighties Nintendo had a monopoly at America and SEGA was having a real hard time selling their consoles. 1990 comes and SEGA's 16bit console, the Genesis/Megadrive is also selling badly, so Tom Kalinske, a guy that comes from Mattel where made Barbie sales skyrocket, faces the challenge of breaking Nintendo's absolute reign of videogames.

This book has been a big surprise. I didn't knew exactly what to expect, but for sure wasn't a (good) book about marketing and product. It tells stories (reconstructed from multiple facts and interviews) wihch are about videogames, but not from a development point of view. All the tales of how SEGA got punchy in the anti-Nintendo ads, different ways to build TV commercials, bringing to USA or creating there the first teams to develop games (back then all games were initially done at Japan)... Even the surprising story of how Sony got into building the Playstation and what made it so successful when it launched. Lots of details and tricks they used back then.

You find mentions to some hits of both companies, especially those who really made a dent like Sonic, Mortal Kombat or Donkey Kong Country, but as mentioned before, it is not a listing of "best titles of each platform", it is a story about how to fight against a big and already dominating opponent, and how also things change contantly and you might win today and lose tomorrow, even to an unknown adversary. Nostalgia is there and helps liking the book, but living in Europe this console wars were quite different (and softer) so I learned a lot.

As for the cons, I have a few, although most are things I'd loved to read about more than mistakes or "bad things"... First, it almost doesn't talks about Japan market, which looks it always is and will be a mystery for Europe and America. Also, it tends to focus more on SEGA than on Nintendo, I don't know if because there was more information, more details or just because of the author's taste, but it is a fact and a noticeably biased story-telling. Finally, it ends too early for my taste, with the arrival of the SEGA Saturn... I wish it talked about the Saturn in detail (almost unknown at Spain back then), the Dreamcast and of course the vanishing of SEGA as a console manufacturer.

Despite the "complaints", fully recommended reading. It brought me back great memories of those years, with the emblematic games mentioned, the funny (and radical) Sega scream TV ads, and our school fights about if the SNES was better or worse than the Megadrive/Genesis. Pure geek history :)


Recommended Articles - 2016/11/19

I came few days ago from vacations and had some written, plus others I've read recently and found worthwile of sharing. Very diverse mix :)

  • 10 Modern software over-engineering mistakes: Good examples and advices

  • Taking PHP Seriously: Good points of why PHP is not loved by a large segment of developers but also why it is not as bad as many say. Actually, while I despise its syntax I agree that using object orientation you can do things really well.

  • Cheating at poker James Bond Style: Frigthening talk about physical poker cheating devices. Amazing how close to spy movies we are...

  • Why We're Living in the Age of Fear: Food for tought about the increasing culture of fear, mostly regarding America, but also happening at other countries like UK or Spain. Interesting contents inside, like the "law of group polarization", "illusory correlation", or differentiating fear from anxiety.

  • Lessons Learned from Scaling Uber to 2000 Engineers, 1000 Services and 8000 Git repositories: Lots of good microservices and high scalability hints and tips and "I wish I knew" examples.

  • Five Elements of Effective Thinking: 1. Understand deeply, 2. Make mistakes, 3. Raise questions. 4. Follow the flow of ideas, 5. Change. For details, read the articles.

  • Docker in Production: A History of Failure: Good list of anti-patterns and general advices of what not to do using Docker. We're pretty happy at work using it but we've avoided most of this problems I think; For example, instead of a dockerized database (pretty dangerous), we use a cloud one (Amazon RDS, DynamoDB, etc.) and forget about problems.

  • Running Docker in production for 6 months: And as a counterpoint to last article, one about some good advices of having docker in production.

  • The Secret Algorithm Behind Learning: Explains a technique (the Feynman Technique) to learn better, in three steps:

    • Step 1: Teach it to a child (force yourself to understand the concept at a deeper level and simplify relationships and connections between ideas)
    • Step 2: Review (discover the edge of your knowledge and improve)
    • Step 3: Organize and Simplify (build a simple story with the notes and concepts you've gathered)
  • Practical advice for analysis of large, complex data sets: From Google, just the list of subsections is already great (idea comes from this HighScalability post:

    • Look at your distributions
    • Consider the outliers
    • Report noise/confidence
    • Look at examples
    • Slice your data
    • Consider practical significance
    • Check for consistency over time
    • Separate Validation, Description, and Evaluation
    • Confirm expt/data collection setup
    • Check vital signs
    • Standard first, custom second
    • Measure twice, or more
    • Check for reproducibility
    • Check for consistency with past measurements
    • Make hypotheses and look for evidence
    • Exploratory analysis benefits from end to end iteration
    • Data analysis starts with questions, not data or a technique
    • Acknowledge and count your filtering
    • Ratios should have clear numerator and denominators
    • Educate your consumers
    • Be both skeptic and champion
    • Share with peers first, external consumers second
    • Expect and accept ignorance and mistakes
  • Choosing Ember over React in 2016: A sentence of an advantage of Ember.js (more mature and stable) sums up pretty much my thinking about the dangers of always going for the latest: "surviving the framework hype cycle". React is great but so young it changes too much and lacks some pieces (or has them but they add additional complexity to a system). Anyway an interesting read to see why is good to "think before you act".

  • 10 characteristics of an excellent software developer: I like them:

    • Passionate
    • Open-minded
    • Data-driven
    • Being knowledgeable about customers and business
    • Being knowledgeable about engineering processes and good practices
    • Not making it personal (egoless but open discussions)
    • Honest (admit mistakes)
    • Personable (gets along well with teammates)
    • Creating shared success (team player)
    • Creative

Book Review: Making games with Phaser: Color Zap

Back from holidays, and with some different readings done as I left my Kindle at home but had the tablet. I wanted to touch Phaser.js since I saw some really nice game jam entries and I want my "game tests" to be online if possible (else I'd probably opt for PyGame to practice my Python skills), so I took the opportunity to grab a Phaser ebook.

Review

Making games with Phaser: Color Zap

Title: Making games with Phaser: Color Zap

Author: William Clarkson

This book is 100% practical, oriented to building a single videogame. So almost no introductions, no filling with full descriptions of methods available, etc. This is not a reference book, so you will only learn about the concepts and features required to build a certain game. It is like an extended "how to make a game with Phaser.js" tutorial. You will end with a fully working color-based reflexes game that works in desktop and mobile.

I liked the approach and the focus on just building what's needed, as is precisely what I want, to grasp the basics of this game development framework and then dig deeper by myself. Steps are small and progress correctly, explanations are nice and code is readable. The game built is not too complex but interesting enough to learn basics about sprite handling, inputs, sound, scenes, and a tiny intro to the physics engine.

If I have something "bad" to remark, it might be the too frequent full source code listings, many times after some simple additions. It gets a bit boring and breaks the reading flow to stop and skip a few pages because we added logic to three small functions and we get again the full javascript source code because of them. Either on critical additions, or at the end of each chapter would have probably been better. There is also one or two not-so-good practices, like encouraging to do User-Agent based browser detection, even when Phaser includes a built-in detection (and we're told about it).

We're talking about a small ebook (around 120 pages with small font) with a smal price tag, so considering that I think it is a worthwile read. You might find other free online full game tutorials, but I didn't spend time checking if indeed there are, and this is a quick dive well explained and concise.


Previous entries