How to test your android app works when the disk is full


It's very common that mobile users fill the disk, so your app needs to deal with situation checking whether it can store the data needed to run.

Here you are the steps needed to fill the disk quick:

  • open Android Studio
  • navigate to Tools > AVD Manager
  • create a device and run it
  • connect to the virtual device in a shell: $ adb shell
  • switch to root user: $ su
  • check disk space: $ df | grep data
  • $ cd /storage/self/primary
  • create a for e.g a 600MB file to fill the disk: $ dd if=/dev/zero of=big.file bs=1047552 count=600
  • use a bigger size if your virtual device has a bigger storage
  • launch and test your app

About software engineering


This blog post by Rob Pike, one of the fathers of the Go programming language, made me think in the shower so I wrote this list of things about building software:

  • as a software engineer you want to add value to your company building software solutions
  • software economy: you need to be agile to reduce time to market
  • devops is the culture where you build your solution AND ship it to production
  • also you are in charge of its maintenance - both infrastructure and code
  • since company requirements change fast, your code base must change to, and sometimes your infrastructure must too.
  • to adapt to these changes rapidly, you need to deliver those changes as fast as you can
  • if you want to be agile delivering those changes you need to automate as much as possible
  • Infrastructure-as-a-service providers (aka "The Cloud") automate building virtual infrastructure so use them
  • infrastructure-as-code tools automates defining the virtual infrastructure declaratively so use them
  • one of the best ways to improve and change the code is the red-green-refactor testing technique, therefore write good tests
  • Continuous Integration tools help you automating those tests
  • since you will probably work in a team, you want your solution to be as simplest as possible so it's understandable by the rest of the team
  • also the simpler the program, the easier is to test, refactor and change it.
  • making simple software solutions is hard, require years of practice and good tools
  • choosing the right programming language to build simple yet powerful tested software is key for success

I <3 Go

Some notes on Go error handling, FP and railway programming


These last months I've had the chance to implement some new microservices with the Social Point backend team. We have taken advantadge of some Go functional programming features to be more expressive when modeling our domain and be able to apply some techniques to make the code base simpler to understand, like implementing middlewares to decouple the domain logic from logging or tracing.

On the other hand, last year I attended Software Craftmanship BCN '16 conf and one of the talks I liked most was named Railway programming: all aboard! by Ignasi Marimon-Clos (thank you @ignasi35!) which explained how to use certain features found in some functional languages to avoid repeating error handling code bits all over your code base.

So with that in mind I tried to dive a little bit more in those concepts and I wrote some notes and references in this hackmd document to gather together techniques to apply this kind of approach when programming in Go.

I hope you find them interesting.

About IT learning & GolangUK '16


I'm addicted to learning about software engineering and IT. The last couple of years i've been focusing in topics like concurrent languages, distributed systems, cloud infrastructure, the web and mobile. If I stay some time without learning something new i feel unproductive. I think that's not very healthy but well here we are ¯\_(ツ)_/¯

My primary sources are twitter and HackerNews, which are social aggregators of information. I haven't found anything better. I try to follow the sources of knowledge and deactivate almost all retweets.

I also love tech talks. I watch most of them in YouTube: learn from the masters from home. Blowmind. I listen to some podcasts but not consistently. Basta ya de picar and We.Developers are my favourites in spanish. And i don't know why but i've tried some online courses platforms but i never finish any course. I guess i'm not very good at doing something consistently in my spare time.

Sometimes I like to attend in person to tech talks because later I can interact with the speaker and the attendees, which can give me different insights, even off-topic ones: I'm very interested in learning things from people who has a similar job in life related with time management, family, traveling, sports, hobbies, side projects etc. I also think that's why lately I'm very interested in remote work and the digital nomad movement.

So i try to go to local tech meetups and conferences. Lately I've been involved with the Golang Barcelona meetup guys and helped making a couple of events at my company offices and i've enjoyed it a lot. Even I made a couple of talks, which has been a great experience.

About conferences, I've had the chance (thanks Social Point & Trovit!) to attend to several international ones in the last years, mainly related with Erlang, Golang and the Symfony PHP framework. I also have attended the Craft Conf a couple of times and it's been the best experience by a BIG margin. One can always learn, but I've arrived to the conclusion that once you reach a certain seniority impact of the things that you can learn in certain conferences is limited if you are into that topic in your day job. By contrast, there are some confs that are more general and inspirational where I feel that I'm really learning a lot and that gives me inspiration and motivation to keep on improving. The CraftConf is one of them for sure. If you have more recommendations please share them with me!

Last week i attended to the Golang UK in London. I've been programming Go full time for almost the last two years, so it made sense to attend to a big Go conf, and since the GopherCon (Denver, US) is a little far from Barcelona I decided that going to the Golang UK was a good pick.

The overall experience has been really good: the colleagues I went with are amazing (Alberto, Ferran, Hernán & Sergio <3), London is one of the most interesting cities in the world and the thing that made it so great is that the first day we attended the Ultimate Go workshop done by Bill Kennedy. He's an outstanding speaker with a broad experience, kept everyone engaged with his presentation style and gave us tons of insights and advices related to computer architecture, data-driven programming, interface design, Go programming and tons of other things. In the first hour of the workshop i felt that going to London was worth the cost. We also took a lot of notes collaboratively with, a very powerful online editing tool based in markdown and web formats that i discovered recently and i'm using a lot. You can find our notes in the the workshop hackmd. Hope you enjoy them.

After the workshop, the following two days were the conference days. The organisation, food and venue were great. About the talks given, a few I really liked, some of them were OK and the rest they not were that much interesting being realistic. I think it's because 30 minutes was too short time for exposing a topic properly without being too general, and also there was no Q&A. But well, I also could attend more talks thanks to this format so in the end I'm not sure whether I really liked it or not. We also tooks tons of notes, you can find them in the conference hackmd.

the crew

An Erlang journey, from start to... finish?


It's been more than a year since I wrote the last Erlang lines that went to production in a Social Point project and I thought that it would be cool to share the experience, so here it is. Also please keep in mind that this is my humble opinion, not from my employer.

First, we started with Erlang because we needed a high-concurrent platform to build a chat and some other real-time features for our games. Like many, did our research and found and studied ejabberd, but we found it too complex for our needs and decided to build it by ourselves from scratch.

So we went for it and invested a lot of time learning the things that surround the amazing world of distributed systems, concurrency and Erlang and OTP (the Open Telecom Platform): the behaviours, the BEAM VM, fault tolerance and the let it crash philosophy, functional programming, recursion, pattern matching, the concurrent programming model, the Actor Model VS the CSP model, the supervision tree, the benefits of message passing and immutability, distributed systems theory topics (high availability, replication, eventual consistency, CRDTs, consistent hashing rings, distributed hash tables, distributed process registers...), clustering BEAM VMs and epmd, benchmarking, OS tunning, compile/release/deploy strategies, dependency managers, remote debugging, learn and use amazing libraries (cowboy, ranch, riak core...), read some books and articles, went to a couple of Erlang User Conferences, did an in-house workshop with Loïc Hoguin...

Screenshot 2016-05-16 16.28.21

Lots and lots of really interesting and useful things there.

And the services we built worked rock-solid, no question.

But we found that to reach a good development speed and time-to-deploy a lot work had to be done, maybe too much. We found ourselves like we had hit a wall somehow. And we felt that it was not easy to introduce Erlang in other backend projects, there was too much friction. We couldn't engage the development team neither the systems team. We were fighting too much. And now I think it's somewhat related to the next tweet I posted the other day from the distributed framework Microsoft has built:

[tweet id="731560538543669250" align="center"]

Are you a distributed systems expert? Maybe, but I know certainly I'm not.

Sometimes it felt that one had to be almost an expert (maybe not a distributed systems one, but an expert nevertheless) to succeed in Erlang development. We wanted our whole development team to participate in this journey, but found that the developer experience wasn't very good, the documentation looked somewhat old, the syntax wasn't familiar, the open source ecosystem and libraries are very small, almost no one knows how to put a serious Erlang project in production, we couldn't find developers in Spain.... It was like we had a very powerful tool but that's very difficult to master. Remember the concepts I wrote in the second paragraph? Certainly they are not something that your learn in a week or a month.

So we tried, succeeded in some aspects, failed in others, and moved on.

As I said, learning Erlang brought a lot of knowledge and experiences about concurrency and distributed systems and many other things. We knew we wanted to move from some parts of our software from a stateless, request/response based, monocore model in PHP to a stateful multicore model and bring those big performance improvements we saw in some projects. We knew we wanted to implement new services with soft real-time capabilities because in game development this paradigm is key in making awesome game experiences.

And this is were Golang matched and now is succeeding in our company, because it was designed to be rapid: rapid to learn (the language syntax is super simple), rapid to develop (amazing standard library), rapid to build and deploy (compile times, no VM, just package and copy), rapid to execute (the performance is stunning) and rapid evolution (vibrant ecosystem, new release every 6 months).

We have been writing Golang code for almost a year and we are very happy about our development speed. We know it's not Erlang, the great platform which has been battle-tested for 30 years in production by some of the biggest telecoms, we don't have OTP and distribution and fault-tolerance for free so we have to do it ourselves if we want those features... but this is fine. Like everything, all decisions have trade-offs and we have decided to change, and in our experience, for the better.

Going back to Erlang, it seems that lately (i mean the last few years, since Erlang is from 1986!) Ericsson has taken more seriously some of these DX issues. They moved the code to GitHub and are more open to user's feedback, releases are faster and bring many goodies (maps, several performance improvements in many areas, new FSM behaviour)... Looks like exciting times are comming for the Erlang community. Maybe it's because the Elixir project, a Ruby-inspired language that compiles to the BEAM VM, is getting some traction lately and I think is trying in some ways to fix some of these Erlang developer experience issues. Or maybe not, anyway we all are lucky that it's happening. I haven't studied it deeply but it looks promising and its documentation looks very good. And the latest ElixirConfEU '16 videos look very interesting.

Finally I hope some day I can hack again in Erlang in my work time, because it's been an amazing experience and I think we are far better software engineers thanks to diving in it.