Marcos Dione: sandboxing-whatsapp

I never wanted this. Whatsapp and its parent company are some of the things I most hate about what tech has become, showing the utter lack of ethics in a industry that has too much impact on the rest of the planet. Just go and read all the reports about groups abusing these platforms (and them allowing them to) to change politics all over the world, or all the shitty security a lot of IoT stuff has, and how they're used to attack services on the Internet.

But reality is more complex than that. In my home country, Facebook and Whatsapp specifically are very popular, to the point that, due to our lack of net-neutrality laws, phone companies offer cheap contracts where those two application's data usage do not count as such, becoming completely free. This means people almost stopped using the phone or SMSs, but instead send text, pictures and voice messages via these platforms. That includes my whole family, which also almost stopped using email.

So for the moment I left my principles aside and installed the app. My last attempt at this had failed because you can't install it on a tablet; the device has to have phone capabilities. Even more, when you try to register it, it forces you to use a cellular phone number; Signal at least has the decency to let you register it to a land line too (if it can't send you an SMS, it gives you the option of being called and the registering code is spelled to you). Luckily I had a spare number from a throwaway line I bought in my last trip to homeland, so I used that number instead of the real one. I know it's a useless step, it's equivalent to giving the finger to someone's back.

Once installed, I tried to send a message to my wife. The app denies you to do so if you don't give it in exchange access to your contacts. Again luckily for me, this phone was mostly empty, but I still took steps to avoid giving it all my contacts. The few I had were already sync'ed to my owncloud instance back home.

First, I exported all my contacts locally and deleted them all. I reimported them after I got the app running. Then I created a new, empty owncloud account, so when Whatsapp asked me which 'account' to use to get/sync the contacts, I gave it that one. This way, when you add contacs, they go to this 'honeypot' and it doesn't have access to your real Contacts. If you don't have a owncloud or similar service you control, you can simply create a bogus Google account and use that instead. The only downside is that you will get dupe'd contacts, but once you sent them a message, you can safely delete the contact and even completely disable sync'ing the account. You can also revoque the permission to access Contacts, but that means you're back to square one, except for the conversations you already have started.

I'm sorry can't give you the exact steps I did, I was on the bus, and with all the failing attempts I lost track. Of course, removing all the contacts means that you only see phone numbers and their photos, but after a while you can recognize them by that. Right now I only have my wife and my family's group, and I hope I can keep it like that for a long, long time.

One last thing: Whatsapp asks you for your contacts, but you can't nicely ask them back: the phone numbers of new contacts are very difficult to extract. You either export them to the Contacts Account if you still have around (I didn't) or you copy them by hand (which I did). Last but not least, I still have the nagging sensation that Whatsapp would have been able to read the contacts; I really whish that Android would gives us more fine grained firewall capabilities. Also, remember that Whatsapp has no option to store media in an SD card, only the phone's internal storage (WTF, people, seriously!), and it's a pain in the ass to clean up the stuff you don't want. So for the moment I haven't gave it access to Photos, Media and Files.


misc rant

Facundo Batista: Eddie el entusiasta y la señorita Moneypenny


Vengo a comentarles sobre una serie que vi parcialmente hace mucho tiempo, y que volví a ver recientemente para verla completa, porque recordaba me había gustado bastante.

Y confirmé, la serie me gusta mucho. Así y todo es bastante desconocida, y tuvo sólo una (corta) temporada. Se llama Keen Eddie.

La serie me gusta en varios planos, aunque más allá del ritmo que tiene y de ciertos trucos visuales que son interesantes para contar la historia, lo mejor son las relaciones interpersonales, de las cuales está plagada.

A Eddie (estereotipo de policía/detective yanqui desastre) lo mandan a trabajar a Londres por una temporada, y hay todo un choque cultural, que a mí me gusta bastante. Y toda la dinámica entre Eddie y su "compañera forzada de casa", Eddie y su perro, su perro y su compañera de casa, Eddie y su pareja-detective, Eddie y su jefe, ...

... y Eddie y la señorita Moneypenny.

Y acá hago un aparte, porque más allá de cierta tensión subrepticia entre Eddie y Moneypenny (que cabe aclarar, no se llama realmente así, sino que Eddie la llama así en homenaje al conocido personaje de ficción) durante la serie hay algunos segundos en la mayoría de los capítulos donde la interacción entre ambos se escapa de los parámetros normales, pero todo en la imaginación de Eddie, aunque eso a él no le queda tan claro... y a veces tampoco nos queda tan claro a nosotros :)

En esta lista de YouTube están separadas estas partes, pero con demasiado contexto (un tiempo antes y un tiempo después de los detalles en cuestión).

Yo me permití hacer una recopilación (con video de mejor calidad), y más enfocada en lo que quería mostrar (e incluso dejé en la secuencia la parte correspondiente al capítulo donde esta interacción rara NO pasa, ya que en ese capítulo todo sale al reves).

Eddie y la señorita Moneypenny

Damián Avila: RISE 5.1.0 is out!

We're pleased to announce the release of RISE 5.1.0!

RISE allows you show your Jupyter notebooks rendered as an executable Reveal.js-based slideshow. It is your very same notebook but presented in a slidy way!

What are the new goodies for this release?

Read more… (1 min remaining to read)

Facundo Batista: Distribución de teclado


Arranquemos la historia a principios de siglo, porque en algún momento hay que arrancarla.

Mi computadora principal hogareña tenía un teclado con distribución "en español" (lo que normalmente se consigue en las casas de computación), pero en el laburo que arranqué en el 2000 (Unifón) todas las computadoras tenían distribución "latinoamericana" (que es lo que venden las marcas grandes, como IBM, Dell, etc, en toda latinoamérica).

Los teclados eran diferentes, sí, pero no tanto. Encima alrededor del 2004 decidí comprarme un teclado de buena calidad, y elegí uno marca IBM, como los de la oficina, que me gustaban mucho. Obviamente, era distribución latinoamericana.

Desde ese momento usé esa distribución exclusivamente.

La laptop que usaba los últimos meses de Movistar, la que me dieron en Cyclelogic (una Dell Inspiron), y la que me dieron en Ericsson (creo que una HP) todas eran compradas acá así que eran todas con teclado latinoamericano.

Cuando entré en Canonical, me compré una laptop yo. En ese momento compré en Argentina una Dell XPS m1330, muy linda máquina. Al momento de renovarla busqué mucho y terminé en una Samsung que nunca me convenció mucho, también comprada acá. En ambos casos, teclado latinoamericano.

Y mientras tanto, seguía usando en la desktop el excelente teclado IBM que me había comprado hace tanto tiempo.

El año pasado volvía a renovar la laptop, y luego de buscar varios meses algo que me convenciera acá en Argentina, en Chile o en Uruguay, terminé tomando la decisión de comprarla en USA (una Lenovo Thinkpad). Claro, con teclado en inglés, pero mi idea era luego comprar el teclado acá y cambiárselo.

Muchas personas (desde hace mucho tiempo) me preguntaban por qué no usaba teclado en inglés y listo. Puedo agrupar toda esa gente en dos grandes grupos:

  • los que usan el teclado en inglés configurado como "inglés", sin acentos ni eñe, pero escriben todo el tiempo con faltas de ortografía; esto es llanamente inaceptable para mí.
  • los que usan el teclado en inglés configurado como "internacional con teclas muertas" (que era como yo tenía la laptop nueva), donde para poner un acento hay que teclear el tilde y luego la vocal; el problema de esto es que para escribir el tilde sólo, hay que teclear el tilde y luego espacio (y como es la misma tecla, para comillas hay que hacer shift+tilde y luego espacio). Funciona, pero es tremendamente ineficiente y molesto.

El 2017 me encontró con el mismatch de teclado entre el desktop y la laptop, algo que me molestaba bastante. Y en Agosto pasaron dos cosas.

Por un lado ya me había cansado de esperar que Lenovo Argentina me vendiera un teclado en latinoamericano para la laptop. Nunca lo importaron, siempre me lo patearon para adelante, ¡durante un año!

Por otro lado, Joac me mostró que hay una configuración "internacional con teclas muertas por AltGr", que lo que hace es evitar el "doble tecleo": para poner una á, sólo hay que hacer AltGr+a. Y listo. Tilde es tilde, comilla es comilla, etc. Hay casos donde necesitamos componer caracteres con varias teclas, pero no es frecuente (por ejemplo, si queremos escribir una ü, donde ahí si tenemos que teclear AltGr+shift+tilde, y luego la u).

Esta configuración me resultó bastante funcional (aunque no ideal), así que lo que tenía que hacer también era solucionar el mismatch con la desktop, por lo que me compré en el último viaje un teclado Lenovo que es igualito al IBM que tenía... pero en inglés.

Así que acá me ven, a la vejez viruela, etc, etc.

Mariano Guerra: State of the BEAM 2017: Survey Results

Intro

You can't improve what you don't measure, and since I think there are areas in the BEAM community (Erlang, Elixir, LFE, Efene, Alpaca, Clojerl et al.) to improve we need to have a better picture of it.

That's why some months ago I decided to create this survey, I told to some people and started researching other "State of the X Community" yearly surveys, I wrote some draft questions and published to some people for feedback, after a couple of rounds I made a Form and ran a test survey for more feedback, after a couple dozen answers I cleared the results and announced it publicly with a weakly reminder on multiple channels.

Result Analysis

We got 423 Responses up to this point.

I present the results of the State of the BEAM Survey 2017 here in two ways:

  • Bar charts sorted by most answers to less
    • On questions with many answers I make a cut at some point
  • Raw data tables sorted by most answers to less
    • Here I did some consolidation of answers to avoid making them too large

I was thinking on doing a deep analysis on the answers but later I realized that if I did an analysis many people would read mine and avoid analyzing it themselves in detail.

Instead I decided to open an analysis thread in some forum and later maybe summarize the most interesting comments.

To ease the discussion I will do some light observations where I see it makes sense and make some questions to open the discussion.

Before diving into the result I want to make explicit two things that may make the results less representative than they should:

1. The "Elixir Effect"

I think the Elixir community is bigger or at least more active than the rest of the BEAM community, because of that and the fact that Elixir already has its own survey, I decided not to promote this survey there, to avoid the number of Elixir specific answers to skew the results and make this survey just be yet another Elixir survey with some BEAMers also replying.

With this clarification, and looking at the answers, I can identify some answers that are from Elixir-only developers, you can see that when some Elixir specific tools appear in the answers (Mix, ExUnit, Distillery, deploy to Heroku etc.), just keep that in mind when analyzing the results.

2. The "Survivorship Bias Effect"

From the wikipedia article on Survivorship bias

Survivorship bias or survival bias is the logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility. This can lead to false conclusions in several different ways. It is a form of selection bias.

Survivorship bias can lead to overly optimistic beliefs because failures are ignored, such as when companies that no longer exist are excluded from analyses of financial performance.

/galleries/state-of-beam-2017/Survivorship-bias.png

The damaged portions of returning planes show locations where they can take a hit and still return home safely; those hit in other places do not survive.

This survey is done on people that wanted to learn Erlang, learned it, and are still active enough on the community to see the survey announcement.

This means that the answers are from the ones that "survived", which makes it really hard to get good feedback on the bad parts of the language, tooling and community since the most affected by it aren't going to stay around to fill this survey.

How to reach those? I don't know, propose solutions on the discussion.

I forgot to ask if I could make public the name of the companies so I won't, but I can say that I got 202 responses and most of them are not duplicates.

Things to improve for next year

  • Ask users if they want their answers available to be distributed in raw form for others to analyze
  • Ask users if I can share publicly the name of the company where they use Erlang
  • Decide what to do about Elixir-only replies, maybe make a question about it
  • Make specific questions regarding better tooling
  • I forgot Russia and Central America options, maybe next time do Latin America?

Let's see the results!

Which languages of the BEAM do you use?

/galleries/state-of-beam-2017/lang.png

Clearly Erlang is the most used language, ignoring the Elixir Effect, I'm kind of disappointed by the lack of users trying alternative languages. More so given the fact that many of the complaints or requests in other questions are already solved by other languages in the ecosystem, for example "better macros" or lisp inspired features being solved by LFE, static/stronger typing or better static analysis being solved by Alpaca, Elixir's pipe operator and a more mainstream syntax being solved by Efene.

My advice to the community, try the other languages, blog/tweet about it and share feedback with their creators, there's a language for each taste!

Erlang 326 54.42%
Elixir 231 38.56%
LFE 14 2.34%
Luerl 12 2.00%
Alpaca 9 1.50%
Clojerl 4 0.67%
Erlog 1 0.17%
Efene 1 0.17%
PHP 1 0.17%

How would you characterize your use of BEAM Languages today?

/galleries/state-of-beam-2017/use.png

Many people using it for serious stuff, the Open Source answer is really low here but is contradicted by another answer below.

I think I should add another option for something like "experiments", "try new ideas".

I use it at work 327 48.66%
I use it for serious "hobby" projects 245 36.46%
I'm just tinkering 62 9.23%
I use it for my studies 35 5.21%
Learning 1 0.15%
katas 1 0.15%
Open Source Software 1 0.15%

In which domains are you applying it?

/galleries/state-of-beam-2017/domains.png
Distributed Systems 225 15.20%
Web development 214 14.46%
Building and delivering commercial services 172 11.62%
Open source projects 149 10.07%
Network programming 136 9.19%
Enterprise apps 92 6.22%
Databases 80 5.41%
IoT / home automation / physical computing 75 5.07%
System administration / dev ops 60 4.05%
Big Data 51 3.45%
Mobile app development (non-web) 46 3.11%
Research 33 2.23%
AI / NLP / machine learning 28 1.89%
Games 28 1.89%
Math / data analysis 23 1.55%
Scientific computing / simulations / data visualization 21 1.42%
Desktop apps 14 0.95%
Graphics / Art 4 0.27%
Music 3 0.20%
Industrial Automation 2 0.14%
log system 1 0.07%
videostreaming 1 0.07%
soft real time analytics 1 0.07%
Security Event Processing 1 0.07%
Media encoding and distribution 1 0.07%
Ad delivery 1 0.07%
Telecom Apps 1 0.07%
telecom and chat 1 0.07%
video 1 0.07%
Developer Tooling 1 0.07%
Telecommunications 1 0.07%
embedded systems 1 0.07%
Advertising/RTB 1 0.07%
Prototyping network apps 1 0.07%
Real time systems 1 0.07%
Real-Time Bidding 1 0.07%
Instant messaging / VoIP / Communications 1 0.07%
ad traffic management 1 0.07%
REST/GraphQL API 1 0.07%
Test systems 1 0.07%
Learning 1 0.07%
telecommunications 1 0.07%
VoIP 1 0.07%
Code static analysis 1 0.07%

What industry or industries do you develop for?

/galleries/state-of-beam-2017/industries.png
Enterprise software 117 15.04%
Communications / Networking 103 13.24%
Consumer software 85 10.93%
IT / Cloud Provider 83 10.67%
Financial services / FinTech 69 8.87%
Telecom 67 8.61%
Media / Advertising 46 5.91%
Retail / ecommerce 41 5.27%
Academic 29 3.73%
Healthcare 28 3.60%
Education 26 3.34%
Government / Military 22 2.83%
Scientific 16 2.06%
Legal Tech 6 0.77%
Energy 5 0.64%
Gaming 2 0.26%
HR 2 0.26%
Security 2 0.26%
Logistics 2 0.26%
sports/fitness 1 0.13%
Retired 1 0.13%
Sport 1 0.13%
Business Intelligence 1 0.13%
Telematics / Car industry 1 0.13%
Manufacturing / Automotive 1 0.13%
Cultural/Museum 1 0.13%
Utilities 1 0.13%
Open source 1 0.13%
Travel 1 0.13%
Sport analysis 1 0.13%
Fitness 1 0.13%
Online Games 1 0.13%
Automotive 1 0.13%
Marketing 1 0.13%
Real estate 1 0.13%
Consumer electronics 1 0.13%
Non profit 1 0.13%
Client driven 1 0.13%
Industrial IoT 1 0.13%
Electric utility 1 0.13%
SaaS 1 0.13%
Automobile 1 0.13%
energy sector 1 0.13%
utilities 1 0.13%
Recruitment 1 0.13%
Energetics 1 0.13%

How long have you been using Erlang?

/galleries/state-of-beam-2017/howlong.png

The entrants (1 year or less) being less than 2 and 3 years may be discouraging or maybe as a sign that this survey didn't reach as many newcomers as it should.

> 6 Years 116 27.62%
2 Years 76 18.10%
3 Years 58 13.81%
1 Year 52 12.38%
Less than a year 45 10.71%
5 Years 36 8.57%
4 Years 34 8.10%
I've stopped using it 3 0.71%

What's your age

/galleries/state-of-beam-2017/age.png

Similar to the previous one, the survey shows that we are not interesting to young programmers (or this survey is not interesting to them :)

30-40 179 42.42%
20-30 112 26.54%
40-50 93 22.04%
> 50 31 7.35%
< 20 7 1.66%

What's your gender

/galleries/state-of-beam-2017/gender.png

One I was expecting, but bad nonetheless.

Male 401 95.02%
Prefer not to say 15 3.55%
Female 5 1.18%
attack helicopter 1 0.24%

Where are you located?

/galleries/state-of-beam-2017/location.png
North America 127 30.09%
Western Europe 117 27.73%
Eastern Europe 42 9.95%
Northern Europe 39 9.24%
South America 30 7.11%
Asia 25 5.92%
Oceania 11 2.61%
Russia 7 1.66%
India 6 1.42%
China 6 1.42%
South Saharan Afica 3 0.71%
Middle East 2 0.47%
Europe 1 0.24%
Iran 1 0.24%
Central America 1 0.24%
Australia 1 0.24%
Thailand 1 0.24%
East Africa 1 0.24%
Central Europe 1 0.24%

What is your level of experience with functional programming?

/galleries/state-of-beam-2017/fpexp.png

7 answers got the joke or are really awesome programmers :)

/galleries/state-of-beam-2017/profunctor.jpg
Intermediate 202 48.44%
Advanced 148 35.49%
Beginner 57 13.67%
Profunctor Optics Level 7 1.68%
None 3 0.72%

Prior to using Erlang, which were your primary development languages?

/galleries/state-of-beam-2017/prevlang.png
C or C++ 163 14.75%
Python 145 13.12%
Javascript 144 13.03%
Ruby 138 12.49%
Java 135 12.22%
PHP 72 6.52%
C# 56 5.07%
Perl 46 4.16%
Go 26 2.35%
Haskell 25 2.26%
Swift or Objective-C 24 2.17%
Common Lisp 20 1.81%
Scala 20 1.81%
Scheme or Racket 14 1.27%
Visual Basic 11 1.00%
Clojure 8 0.72%
R 8 0.72%
Rust 7 0.63%
None 6 0.54%
OCaml 3 0.27%
F# 3 0.27%
Kotlin 2 0.18%
Standard ML 2 0.18%
Fortran 2 0.18%
Pascal 1 0.09%
Ocaml 1 0.09%
KDB 1 0.09%
so "primary" here for me is "what was most used at work" 1 0.09%
TypeScript 1 0.09%
Microsoft Access 1 0.09%
Groovy 1 0.09%
but I am a self-proclaimed polyglot 1 0.09%
Shell 1 0.09%
Tcl/Tk 1 0.09%
Limbo 1 0.09%
Smalltalk 1 0.09%
clojure 1 0.09%
ActionScript 1 0.09%
Actionscript 1 0.09%
Prolog 1 0.09%
Racket 1 0.09%
Bash 1 0.09%
ML 1 0.09%
TCL 1 0.09%
Elixir 1 0.09%
C ANSI POSIX 1 0.09%
D 1 0.09%
ocaml 1 0.09%
Assembly 1 0.09%

Which client-side language are you using with Erlang?

/galleries/state-of-beam-2017/clientlang.png
Javascript 257 44.93%
None 90 15.73%
Elm 69 12.06%
Java 36 6.29%
Swift/Objective-C 36 6.29%
Clojurescript 13 2.27%
ReasonML/Ocaml 10 1.75%
Kotlin 8 1.40%
Typescript 7 1.22%
Scala 7 1.22%
Purescript 6 1.05%
C++ 4 0.70%
TypeScript 3 0.52%
Go 2 0.35%
typescript 2 0.35%
Python 2 0.35%
Erlang 2 0.35%
Flow + Javascript 1 0.17%
HTML-CSS 1 0.17%
Haskell 1 0.17%
What do you mean by "client-side language"? 1 0.17%
other 1 0.17%
Action Script 3 1 0.17%
Coffeescript 1 0.17%
d3.js 1 0.17%
lua 1 0.17%
Python/PyQt 1 0.17%
Dart 1 0.17%
Golang 1 0.17%
Ruby 1 0.17%
M$ C# 1 0.17%
Python (interface to legacy system - not web based) 1 0.17%
clojure 1 0.17%
C# 1 0.17%
Tcl/Tk 1 0.17%

In your Erlang projects, do you interoperate with other languages? if so, which ones?

/galleries/state-of-beam-2017/interop.png
C or C++ 156 24.19%
None 92 14.26%
Python 87 13.49%
Javascript 72 11.16%
Java 51 7.91%
Ruby 37 5.74%
Rust 27 4.19%
Go 27 4.19%
Swift or Objective-C 14 2.17%
C# 12 1.86%
Scala 11 1.71%
PHP 9 1.40%
Perl 8 1.24%
R 8 1.24%
Haskell 6 0.93%
Common Lisp 4 0.62%
Clojure 3 0.47%
OCaml 3 0.47%
Elixir 2 0.31%
Scheme or Racket 2 0.31%
Bash 2 0.31%
Kotlin 1 0.16%
KDB 1 0.16%
I use Erlang from Elixir 1 0.16%
lua 1 0.16%
SQL 1 0.16%
java 1 0.16%
Ocaml 1 0.16%
go 1 0.16%
Not directly via NIFs/ports but via HTTP/rabbit with ruby 1 0.16%
Tcl/Tk 1 0.16%
Lua 1 0.16%
python 1 0.16%

Which is your primary development environment?

/galleries/state-of-beam-2017/editor.png

I thought Emacs would win here by the fact that the Erlang creators use Emacs.

Vim 116 27.49%
Emacs 114 27.01%
IntelliJ 47 11.14%
Visual Studio Code 47 11.14%
Sublime Text 39 9.24%
Atom 32 7.58%
Eclipse 6 1.42%
spacemacs 2 0.47%
nano 2 0.47%
linux with vim as my text editor 1 0.24%
Kate 1 0.24%
textmate 1 0.24%
TextPad 1 0.24%
Simple text editor 1 0.24%
Notepad++ 1 0.24%
Also nvi. 1 0.24%
mcedit 1 0.24%
PSPad 1 0.24%
geany with erlang syntax support 1 0.24%
Kakoune 1 0.24%
Neovim 1 0.24%
Acme 1 0.24%
Spacemacs 1 0.24%
Atom and Emacs both very equally 1 0.24%
ed 1 0.24%
elvis 1 0.24%

Where do you go for Erlang news and discussions?

/galleries/state-of-beam-2017/news.png
Twitter 204 20.20%
Mailing List 188 18.61%
Slack 116 11.49%
Reddit 111 10.99%
Stack Overflow 103 10.20%
IRC 62 6.14%
Erlang Central 60 5.94%
Newsletters 50 4.95%
Podcasts 33 3.27%
Planet Erlang 31 3.07%
ElixirForum 31 3.07%
Elixir Community 1 0.10%
lobste.rs 1 0.10%
EUC 1 0.10%
Reddit and ElixirForum 1 0.10%
This week in Erlang 1 0.10%
Gitter 1 0.10%
Awesome Elixir 1 0.10%
OTP's github for PRs and commit log 1 0.10%
elixirstatus.com 1 0.10%
Google Plus 1 0.10%
youtube 1 0.10%
Search on github 1 0.10%
Erlang solutions 1 0.10%
not interesting 1 0.10%
Medium 1 0.10%
None 1 0.10%
Watch talks 1 0.10%
Conference Videos 1 0.10%
Elixir Sips 1 0.10%
https://medium.com/@gootik 1 0.10%
https://lobste.rs/t/erlang 1 0.10%

Which versions of the Erlang VM do you currently use for development?

/galleries/state-of-beam-2017/versiondev.png

We are really up to date, we are near a point where we can assume maps on our libraries :)

20 305 46.71%
19 213 32.62%
18 84 12.86%
17 30 4.59%
16 16 2.45%
<= 15 5 0.77%

Which versions of the Erlang VM do you currently use in production?

/galleries/state-of-beam-2017/versiondeploy.png

Of course production is a little more conservative

19 215 37.65%
20 183 32.05%
18 94 16.46%
17 43 7.53%
16 26 4.55%
<= 15 10 1.75%

Which build tool do you use?

/galleries/state-of-beam-2017/buildtool.png

Nice to see Rebar3 picking up momentum, Mix being mainly the Elixir Effect, next year I should add an option for "Mix for erlang or mixed projects".

Rebar3 220 32.59%
Mix 177 26.22%
Makefile 111 16.44%
Rebar 71 10.52%
erlang.mk 46 6.81%
Custom build scripts 44 6.52%
Distillery 1 0.15%
maven 1 0.15%
redo 1 0.15%
mix 1 0.15%
synrc/mad 1 0.15%
MBU 1 0.15%

How do you test your code?

/galleries/state-of-beam-2017/howtest.png

Surprised by EUnit being on top, why do people prefer it over Common Test?

EUnit 216 34.67%
Common Test 158 25.36%
ExUnit 74 11.88%
PropEr 69 11.08%
I don't write tests 45 7.22%
QuickCheck 33 5.30%
Custom 4 0.64%
Triq 4 0.64%
ESpec 3 0.48%
CutEr 3 0.48%
StreamData 2 0.32%
Lux 2 0.32%
py.test 2 0.32%
Functional tests 1 0.16%
Don't have time to write tests 1 0.16%
katana-test 1 0.16%
riak_test 1 0.16%
Dialyzer 1 0.16%
Integration tests 1 0.16%
Elixir tests. 1 0.16%
Concuerror 1 0.16%

How do you deploy your application?

/galleries/state-of-beam-2017/howdeploy.png

Lot of custom deploy scripts and docker/kubernetes here, maybe we should have better deploy support in our tools?

Custom deploy scripts 186 32.75%
Docker 128 22.54%
Kubernetes 50 8.80%
Ansible 44 7.75%
I don't deploy in other servers 40 7.04%
Chef 39 6.87%
Puppet 11 1.94%
SaltStack 11 1.94%
Heroku 11 1.94%
Edeliver 8 1.41%
deb 7 1.23%
Distillery 7 1.23%
Zones 5 0.88%
AWS CodeDeploy 3 0.53%
Rancher 1 0.18%
VM image 1 0.18%
boot from flash 1 0.18%
https://github.com/labzero/bootleg2 1 0.18%
Not my job 1 0.18%
copy paste 1 0.18%
mad 1 0.18%
CD 1 0.18%
Exrm 1 0.18%
rpm 1 0.18%
Nomad 1 0.18%
AWS ECS 1 0.18%
FreeBSD Jails 1 0.18%
lxc 1 0.18%
WIX 1 0.18%
os packages 1 0.18%
nanobox 1 0.18%
cloudfoundry 1 0.18%

What is your organization's size?

/galleries/state-of-beam-2017/orgsize.png

Can we say that Erlang works on organizations of any size?

11-50 109 26.20%
2-10 93 22.36%
Just me 75 18.03%
500+ 65 15.62%
101-500 45 10.82%
51-100 29 6.97%

Which operating system(s) you use for development?

/galleries/state-of-beam-2017/osdev.png

Almost same amount of Windows and FreeBSD, is it because Windows support is bad? or is this a reflection of the usual developer OS choice in any programming language?

Linux 307 47.01%
MacOS 253 38.74%
Windows 38 5.82%
FreeBSD 34 5.21%
Illumos 8 1.23%
OpenBSD 7 1.07%
Solaris 3 0.46%
NetBSD 1 0.15%
GRiSP 1 0.15%
ChromeOS 1 0.15%

Which operating system(s) you use for deployment?

/galleries/state-of-beam-2017/osdeploy.png
Linux 378 75.15%
FreeBSD 43 8.55%
MacOS 25 4.97%
Windows 22 4.37%
I don't deploy in other servers 11 2.19%
Solaris 9 1.79%
Illumos 8 1.59%
OpenBSD 3 0.60%
RTEMS 1 0.20%
GRiSP 1 0.20%
OSv 1 0.20%
NetBSD 1 0.20%

Where do you deploy your applications?

/galleries/state-of-beam-2017/wheredeploy.png

I don't think this question provides useful information, maybe I should add options?

Public Cloud 188 27.85%
Use on local machine(s) 162 24.00%
Traditional Infrastructure 157 23.26%
Private Cloud (or hybrid) 156 23.11%
Distillery 1 0.15%
VMs on ESXi 1 0.15%
embedded systems 1 0.15%
Rented physical server 1 0.15%
Vagrant vms 1 0.15%
Embedded appliances 1 0.15%
Heroku 1 0.15%
VPS 1 0.15%
hyper.sh 1 0.15%
Containers (Docker) 1 0.15%
Edeliver 1 0.15%
GitHub 1 0.15%

Which events have you attended in the last year?

/galleries/state-of-beam-2017/events.png

Local Meetups at the top is a nice one, we can work to promote more of these.

Local Meetup 124 46.97%
Erlang Factory 39 14.77%
Erlang User Conference 38 14.39%
Erlang Factory Light 20 7.58%
ElixirConf 12 4.55%
ElixirConfEU 9 3.41%
None 6 2.27%
Lonestar Elixir 3 1.14%
Code Mesh 2 0.76%
Lambda Days 1 0.38%
ElixirConfEU + ElixirLDN 1 0.38%
ElixirConf USA 2017 1 0.38%
Elixir London 1 0.38%
ElixirConf 2017 1 0.38%
Elixir meetup in Leeds UK 1 0.38%
ElixirLive Conference in Warsaw 1 0.38%
J on the Beach 1 0.38%
Peer gatherings in region 1 0.38%
Empex 1 0.38%
Elixir Camp 1 0.38%

Do you use HiPE?

No 301 74.32%
Yes 104 25.68%

Do you use dialyzer?

Yes 280 66.99%
No 138 33.01%

How important have each of these aspects of Erlang been to you and your projects?

Remember that charts and tables are sorted by most to less answers to compare correctly in the following set of questions.

Community

/galleries/state-of-beam-2017/ocommunity.png
Very Important 157 37.74%
Fairly Important 112 26.92%
Important 79 18.99%
Slightly Important 52 12.50%
No Opinion 8 1.92%
Not Important at All 8 1.92%

Concurrency facilities

/galleries/state-of-beam-2017/oconcurrency.png
Very Important 306 73.73%
Fairly Important 58 13.98%
Important 36 8.67%
No Opinion 7 1.69%
Slightly Important 7 1.69%
Not Important at All 1 0.24%

Ease of development

/galleries/state-of-beam-2017/oeasedev.png
Very Important 205 49.52%
Fairly Important 98 23.67%
Important 72 17.39%
Slightly Important 27 6.52%
No Opinion 10 2.42%
Not Important at All 2 0.48%

Functional Programming

/galleries/state-of-beam-2017/ofp.png
Very Important 207 49.88%
Fairly Important 105 25.30%
Important 53 12.77%
Slightly Important 33 7.95%
No Opinion 9 2.17%
Not Important at All 8 1.93%

Immutability

/galleries/state-of-beam-2017/oimmutability.png
Very Important 222 53.62%
Fairly Important 90 21.74%
Important 60 14.49%
Slightly Important 30 7.25%
No Opinion 8 1.93%
Not Important at All 4 0.97%

Runtime performance

/galleries/state-of-beam-2017/operf.png
Very Important 148 35.75%
Fairly Important 122 29.47%
Important 95 22.95%
Slightly Important 36 8.70%
Not Important at All 7 1.69%
No Opinion 6 1.45%

The REPL

/galleries/state-of-beam-2017/orepl.png
Very Important 145 35.02%
Fairly Important 106 25.60%
Important 74 17.87%
Slightly Important 61 14.73%
No Opinion 19 4.59%
Not Important at All 9 2.17%

Tracing

/galleries/state-of-beam-2017/otracing.png
Slightly Important 96 23.02%
Very Important 95 22.78%
Fairly Important 90 21.58%
Important 82 19.66%
Not Important at All 29 6.95%
No Opinion 25 6.00%

What has been most frustrating or has prevented you from using Erlang more than you do now?

App deployment

/galleries/state-of-beam-2017/fappdev.png
Not Frustrating at All 120 30.08%
Slightly Frustrating 93 23.31%
Frustrating 54 13.53%
Fairly Frustrating 41 10.28%
Quite the contrary: I love this feature 38 9.52%
No Opinion 29 7.27%
Very Frustrating 24 6.02%

Error messages

/galleries/state-of-beam-2017/ferrormsgs.png
Slightly Frustrating 119 29.82%
Not Frustrating at All 89 22.31%
Frustrating 48 12.03%
Fairly Frustrating 43 10.78%
Quite the contrary: I love this feature 39 9.77%
Very Frustrating 38 9.52%
No Opinion 23 5.76%

Finding libraries

/galleries/state-of-beam-2017/flibs.png
Slightly Frustrating 137 34.08%
Not Frustrating at All 121 30.10%
Frustrating 64 15.92%
Fairly Frustrating 31 7.71%
Quite the contrary: I love this feature 21 5.22%
Very Frustrating 15 3.73%
No Opinion 13 3.23%

Hard to Learn it

/galleries/state-of-beam-2017/fhardlearn.png
Not Frustrating at All 204 51.13%
Slightly Frustrating 77 19.30%
Quite the contrary: I love this feature 48 12.03%
Frustrating 29 7.27%
No Opinion 21 5.26%
Fairly Frustrating 14 3.51%
Very Frustrating 6 1.50%

Hiring and staffing

/galleries/state-of-beam-2017/fhiring.png
No Opinion 124 31.47%
Slightly Frustrating 78 19.80%
Not Frustrating at All 71 18.02%
Fairly Frustrating 43 10.91%
Frustrating 41 10.41%
Very Frustrating 25 6.35%
Quite the contrary: I love this feature 12 3.05%

Installation process

/galleries/state-of-beam-2017/finstallation.png
Not Frustrating at All 218 55.05%
Slightly Frustrating 67 16.92%
Quite the contrary: I love this feature 54 13.64%
Frustrating 23 5.81%
Fairly Frustrating 16 4.04%
No Opinion 14 3.54%
Very Frustrating 4 1.01%

Long term viability

/galleries/state-of-beam-2017/fviability.png
Not Frustrating at All 194 48.87%
Quite the contrary: I love this feature 74 18.64%
Slightly Frustrating 46 11.59%
No Opinion 41 10.33%
Frustrating 28 7.05%
Fairly Frustrating 9 2.27%
Very Frustrating 5 1.26%

Need more docs/tutorials

/galleries/state-of-beam-2017/fdocs.png
Not Frustrating at All 127 32.32%
Slightly Frustrating 124 31.55%
Frustrating 44 11.20%
Fairly Frustrating 37 9.41%
Quite the contrary: I love this feature 22 5.60%
No Opinion 22 5.60%
Very Frustrating 17 4.33%

Need more text editor support/IDEs

/galleries/state-of-beam-2017/fides.png
Not Frustrating at All 168 42.00%
Slightly Frustrating 93 23.25%
Frustrating 39 9.75%
Quite the contrary: I love this feature 32 8.00%
Fairly Frustrating 28 7.00%
Very Frustrating 22 5.50%
No Opinion 18 4.50%

Need more tools

/galleries/state-of-beam-2017/ftools.png
Slightly Frustrating 128 32.16%
Not Frustrating at All 99 24.87%
Frustrating 58 14.57%
Fairly Frustrating 40 10.05%
Very Frustrating 34 8.54%
No Opinion 26 6.53%
Quite the contrary: I love this feature 13 3.27%

No static typing

/galleries/state-of-beam-2017/ftyping.png
Not Frustrating at All 113 28.18%
Slightly Frustrating 105 26.18%
Quite the contrary: I love this feature 63 15.71%
Frustrating 40 9.98%
Fairly Frustrating 34 8.48%
Very Frustrating 25 6.23%
No Opinion 21 5.24%

Release schedule

/galleries/state-of-beam-2017/freleasesched.png
Not Frustrating at All 258 64.99%
Quite the contrary: I love this feature 57 14.36%
No Opinion 43 10.83%
Slightly Frustrating 26 6.55%
Frustrating 9 2.27%
Very Frustrating 2 0.50%
Fairly Frustrating 2 0.50%

Runtime performance

/galleries/state-of-beam-2017/fperformance.png
Not Frustrating at All 185 46.25%
Slightly Frustrating 72 18.00%
Quite the contrary: I love this feature 57 14.25%
Frustrating 32 8.00%
No Opinion 25 6.25%
Fairly Frustrating 17 4.25%
Very Frustrating 12 3.00%

Unpleasant community

/galleries/state-of-beam-2017/fcommunity.png
Not Frustrating at All 224 56.14%
Quite the contrary: I love this feature 79 19.80%
No Opinion 45 11.28%
Slightly Frustrating 26 6.52%
Frustrating 14 3.51%
Very Frustrating 7 1.75%
Fairly Frustrating 4 1.00%

Version incompatibility

/galleries/state-of-beam-2017/fversioncompat.png
Not Frustrating at All 212 53.13%
Slightly Frustrating 84 21.05%
No Opinion 40 10.03%
Quite the contrary: I love this feature 29 7.27%
Frustrating 19 4.76%
Fairly Frustrating 11 2.76%
Very Frustrating 4 1.00%

Any feature you would like to see added to the language?

This was an open ended question, I'm summarizing similar answers here in groups

Static Typing 20
Performance 7
Pipe operator 7
JIT 6
Currying 6
Better GUI lib 5
Better macros 4
Docs in shell 4
Better language interop 4
JSON in stdlib 3
Compile to single binary 3
Namespaces 3
Rebind variables 2
Numeric performance 2
Elixir protocols 2
Language server protocol 2
Non full mesh disterl 2
Consensus implementations in stdlib 2
More than 2 version of same module 2
Atom GC 2

Other answers with one vote:

  • Backward compatibility
  • BEAM on browsers
  • Better binary syntax
  • Better container support
  • Better datetime support
  • Better documentation
  • Better errors
  • Better global registry
  • Better if expression
  • Better map support in mnesia
  • Better ML integration
  • Better module system
  • Better proc_lib
  • Better profiler
  • Better site
  • Better string module
  • Better unicode support
  • Bigger standard library
  • Bring back parameterized modules
  • Cleanup standard library
  • Code change watcher and loader
  • Consistent error return
  • CRDTs
  • Curses version of observer
  • Database drivers/support
  • Early return statement
  • Encrypted inter node communication
  • Erlang leveldb/rocksdb (better DETS)
  • First class records (not as tuples)
  • Function composition
  • IPv6
  • Laziness
  • LLVM based Hipe
  • Map comprehensions
  • Monads
  • More behaviors
  • More Lispy
  • More robust on_load
  • Multi-poll sets
  • Native compilation
  • New logo
  • Numerical/GPU support
  • Orleans
  • Package manager
  • Rational numbers
  • Remove stuff
  • Short circuit folding a list
  • Single file distribution
  • String performance
  • Top-like tool
  • Type checking as you type
  • Type inference
  • WebRTC
  • With expression like Elixir

Any advise on how we can make Erlang more welcoming and easy to use?

This was an open ended question, I'm summarizing similar answers here in groups

Better guides 20
Better documentation 18
Better error messages 13
Better tooling 9
Central/better landing page 4
Better REPL 3
Translated documentation 2
Better libraries 2
Friendlier community 2
Better learning curve 2
Learn from Elixir community 3
IDE support 3
Marketing 2
Searchable docs 2
Throw away legacy 2
Simpler release process 2

Other answers with one vote:

  • A killer app
  • Better tracing tools
  • Better Windows experience
  • Embrace BEAM languages
  • Erlang forum
  • Introductory workshops
  • More conferences
  • More welcoming mailing list
  • Nicer syntax
  • Performance
  • Templates

Would you like to share any frustrating experience?

This was an open ended question, I'm summarizing similar answers here in groups

Bad tooling 6
Lack of libraries, immaturity, not maintained 5
Lack of guides 5
Unwelcome community 4
Lack of strong/static typing 4
Syntax 4
No examples on documentation/in general 3
Bad documentation 3
Mnesia 3
Bad debugging experience 3
Ignoring other languages/communities/feedback 3
Niche language 2
Bad shell 2
No jobs 2
Learning curve 2
Difficulty contributing to the BEAM and OTP 2
Confusing errors 2
Performance 2
Package management 2

Other answers with one vote:

  • Atoms not garbage collected
  • Elitism
  • Flat namespace
  • Hard to hire
  • Lack of features in standard library
  • Lack of language features
  • Not a clear overview of the ecosystem
  • People complaining about syntax
  • String vs binary
  • Upgrades break code

Marcos Dione: dinant-0.5

I have a love and hate relantionship with regular expressions (regexps). On one side they're a very powerful tool for text processing, but on the other side of the coin, the most well known implementation is a language whose syntax is so dense, it's hard to read beyond the most basic phrases. This clashes with my intention of trying to make programs as readable as possible[1]. It's true that you can add comments and make your regexps span several lines so you can digest them more slowly, but to me it feels like eating dried up soup by the teaspoon directly from the package without adding hot water.

So I started reading regexps aloud and writing down how I describe them in natural language. This way, [a-z]+ becomes one or more of any of the letters between lowercase a and lowercase z, but of course this is way too verbose.

Then I picked up these descriptions and tried to come up with a series of names (in the Pyhton sense) that could be combined to build the same regexps. Even 'literate' programs are not really plain English, but a more condensed version, while still readable. Otherwise you end up with Perl, and not many think that's a good idea. So, that regexp becomes one_or_more(any_of('a-z')). As you can see, some regexp language can still be recognizable, but it's the lesser part.

So, dinant was born. It's a single source file module that implements that language and some other variants (any_of(['a-z'], times=[1, ]), etc). It also implements some prebuilt regexps for common constructs, like integer, a datetime() function that accepts strptime() patterns or more complex things like IPv4 or IP_port. Conforming I start using it in (more) real world examples (or issues are filed!), the language will slowly grow.

Almost accidentally, its constructive form brought along a nice feature: you can debug() your expression so you can find out the first sub expression that fails matching:

# this is a real world example!
In [1]: import dinant as d
In [2]: line = '''36569.12ms (cpu 35251.71ms)\n'''
# can you spot the error?
In [3]: render_time_re = ( d.bol + d.capture(d.float, name='wall_time') + 'ms ' +
...:                       '(cpu' + d.capture(d.float, name='cpu_time') + 'ms)' + d.eol )

In [4]: print(render_time_re.match(line))
None

In [5]: print(render_time_re.debug(line))
# ok, this is too verbose (I hope next version will be more human readable)
# but it's clear it's the second capture
Out[5]: '^(?P<wall_time>(?:(?:\\-)?(?:(?:\\d)+)?\\.(?:\\d)+|(?:\\-)?(?:\\d)+\\.|(?:\\-)?(?:\\d)+))ms\\ \\(cpu(?P<cpu_time>(?:(?:\\-)?(?:(?:\\d)+)?\\.(?:\\d)+|(?:\\-)?(?:\\d)+\\.|(?:\\-)?(?:\\d)+))'
# the error is that the text '(cpu' needs a space at the end

Of course, the project is quite simple, so there is no regexp optimizer, which means that the resulting regexpes are less readable than the ones you would had written by hand. The idea is that, besides debugging, you will never have to see them again.

Two features are in the backburner, and both are related. One is to make debugging easier by simply returning a representation of the original expression instead of the internal regexp used. That means, in the previous example, something like:

bol + capture(float, name='wall_time') + 'ms ' + '(cpu' + capture(float, name='cpu_time')

The second is that you can tell which types the different captured groups must convert to. This way, capture(float) would not return the string representing the float, but the actual float. The same for datetime() and others.

As the time of writing the project only lives on GitHub, but it will also be available in PyPI Any Time Soon®. Go grab it!


python ayrton


[1] for someone that knows how to read English, that is.

Manuel Kaufmann (Humitos): Diversidad, inclusión y todo eso

Atención, este artículo puede ser difícil de leer y fácil de juzgar. Sin embargo, me gustaría desahogarme y que podamos hablar de "lo prohibido" para que entre todos podamos construir una sociedad/comunidad mejor, sin prejuicios y en el que todos podamos hablar libremente sin ofender a los demás: entendiendo a todas las partes involucradas.

Como muchos sabrán, hace tiempo que venimos trabajando en "todo esto de la diversidad e inclusión" en el mundo de la programación. Sin embargo, yo, quien fue uno de los que empezó a impulsar esta idea entre mis conocidos (incluso antes de que Django Girls existiese) tengo un montón de dudas y problemas con este tema que es tan sensible.

Sí, dudas y problemas.

Luego de la PyConBr 13 hablé bastante con @turicas, a quien considero una persona sumamente abierta con la que se puede hablar sin problemas de los temas que nos molestan y de los problemas que tenemos. Él, luego de su charla en la que mencionó "Género y Número", me ayudó muchísimo a reflexionar sobre todo esto y a tratar de comprender un poco más la situación.

Es por eso que hoy me gustaría escribir todo lo que me quedó dando vueltas en la cabeza.

Me gustaría remontarme un poco a mi infancia, al lugar en el que fui criado y que me ayuden a entender un poquito porqué yo, entre tantas otras personas que queremos cambiar este mundo, tenemos estos problemas.

Nací en un barrio "normal" de Paraná, Entre Ríos, Argentina a una cuadra del río Paraná y rodeado por el mismo. El barrio tenía una única salida hacia "el centro" y había que caminar 5 cuadras para llegar a "la civilización" donde pasaban los buses, taxis y cualquier medio de transporte. En fin, yo pagaba $5 (en ese entonces ~USD 5) de taxi para llegar a ese lugar en vez de ir a pie por el miedo que tenía a que algo me ocurriese en el camino. El barrio, estaba "bien" en mi cuadra, pero esas otras 5 eran muy desoladas y rodeadas de "villas".

Ahí pasé toda mi infancia escuchando a los vecinos decir "estos negros de mierda" cuando a algunos de mis amigos cualquier persona le robaba las zapatillas, la bicicleta, la billetera o incluso nuestra pelota de fútbol (en general, la mayoría de los robos que hemos experimentado en mi barrio no han sido violentos). También, en reiteradas oportunidades nos entraron a robar a mi casa e incluso en una de ellas nosotros estábamos adentro.

Esas veces, "negros de mierda" era una expresión que se quedaba corta -según vecinos y familiares. En Paraná, donde nací yo, esta expresión tiene una connotación negativa y pésima que lamentablemente vive dentro de mí ya que me crié con esto.

En fin, lo que quiero decir en este punto es que incluso gente con la mente un poco abierta, que está a favor de la inclusión y la diversidad (como yo me considero) aún tiene este tipo de problemas. ¿Cuál es exactamente el problema? No estoy del todo seguro, pero al menos sé que ni siquiera nos sabemos expresar correctamente.

Personalmente, no tengo amigos de piel negra. Pero no es porque no quiera, al contrario. Sino que supongo que es simplemente porque en el lugar en el que yo nací "no es común": la mayoría de la gente es blanca leche (como yo) o de piel morena (esos a los que pésimamente le hemos llamado "negros de mierda" durante muchos años); pero de piel negra no hay.

¿Hasta acá, cómo vamos? Ya me odian. Espero que no. Todavía quiero seguir escribiendo sobre los problemas que tengo con respecto a "todo esto".

Pasemos al tema de la "diversidad de género". Anteriormente comenté un poco el trabajo que venimos haciendo organizando talleres Django Girls en diferentes países de Latinoamérica con el fin de acercar mujeres al mundo de la tecnología/programación y que se sientan cómodas. ¿Bien? Bueno, eso sería "diversidad de sexo" pero no de género, en realidad. Sexos hay solo 2, pero géneros hay algunos más. Hablemos un poco de eso.

Nuevamente me gustaría remontarme a la infancia. En esas épocas mientras estábamos jugando al fútbol si alguien te iba muy fuerte y a vos te dolía, la mayoría de los niños te decían cosas como: "ah, no seas mamita", "qué puto que sos", "maricón", "parecés mi hermana" y cosas similares. Eso, durante años.

Este tipo de frases, denotando una debilidad en el sexo femenino o burlándose de los homosexuales y demás va tomando su lugar en tu cabeza, en tu memoria... y ese tipo de expresiones pasan a ser una especie de "muletilla inconsciente" en ocasiones similares en tu adolescencia o madurez.

Lo mismo aquí. No tengo ningún amigo homosexual ni tampoco transexual. Resumiendo, no tengo ningún amigo que su sexo no coincida con su género o que no encaje en los "estándares religiosamente tradicionales". Pienso que probablemente haber vivido inmerso en este tipo de situaciones desde pequeño han hecho que frente a la posibilidad de ser parte de un grupo diverso, me distancie de estas personas (quizás consciente o quizás inconscientemente -hoy no lo sé)

Sigamos adelante, pero volvamos a lo que nos concierne: ¡queremos diversidad e inclusión en el ambiente en el que nos desenvolvemos! (¿verdad?) Bueno, en principio, creo que toda la gente que nos consideramos "abierta" necesitamos pensar bastante en esto nuevamente; pero más aún, creo que necesitamos pertenecer a estos grupos de las minorías y aprender de ellos. Una de las preguntas que les hago a las chicas que alcanzo a conocer un poquito más en los talleres de Django Girls o en las conferencias a las que asisto es: "¿Cómo es ser mujer en este evento/comunidad?" y "¿Has vivido alguna situación en la que te hayan dejado de lado en un trabajo o que ni siquiera te lo asignen por ser mujer? ¿Cómo fue? ¿Cómo se siente?".

Lamentablemente, incluso haciendo estas preguntas cuando tengo la oportunidad y creo que no voy a ofender a la otra persona, siento que sigo teniendo nada de información y todavía me cuesta comprender el problema. En varias oportunidades esto me hace pensar que quiero "ayudar a resolver" un problema que ni siquiera entiendo y al final del día me lo cuestiono y creo que estoy equivocado en el camino que estoy tomando.

En los últimos años he visitado varios países y he estado involucrado en diferentes comunidades y "siento" (quizás porque es la que más viví de cerca) que Argentina es el país con más discriminación, el país de la burla, del chiste fácil, del hacer quedar mal al otro en todo momento y en la mayoría de las veces, sin importar si le hacemos daño a la otra persona o no.

Hoy en día, creo que la gente "de grande" se está ubicando un poco más pero, ¿qué hacemos con todo eso que tenemos dentro de nuestra cabeza, en nuestra memoria y que muchas veces sale "sin querer"? Esto no es una excusa para llevarse todo por delante sin importar nada, al contrario, creo que lo que necesitamos es aprender de los demás (de los grupos diversos) a comportarnos, a expresarnos y crecer humanamente juntos: siendo parte.

Personalmente creo que esto es un problema de todos (inclusión y diversidad como un todo -lo otro aún no lo entiendo: no tengo idea lo que se siente ser parte de las minorías aún y quizás nunca lo logre sentir) y que todos necesitamos trabajar juntos. Juntos de verdad. No nosotros haciendo Django Girls por aquí, la gente de Afro Python haciendo eventos por allá y la comunidad Trans por otro lado. Eso creo que ayuda mucho, pero creo que lo ideal sería que empecemos a mezclarnos. Yo lo necesito. Yo, que quiero impulsar esto, lo necesito. Necesito esto porque necesito aprender de las minorías. Necesito verme forzado a cuidar mi lenguaje, a no discriminar, a bloquear toda esa infancia que llevo dentro y poder naturalmente hablar con todas las personas con respeto.

En fin, creo que para empezar a resolver la problemática de la diversidad y la inclusión lo que debemos hacer es justamente eso: participar de grupos diversos e inclusivos. Aunque eso suene tonto. Sin embargo, creo que si las personas que pertenecemos a los grupos de las mayorías, si no nos abrimos mentalmente y los grupos de las minorías nos aceptan, nos va a tomar mucho más tiempo poder seguir avanzando en erradicar esta problemática.

Estoy seguro que este artículo puede molestarle a algunas personas y pido disculpas anticipadamente por eso. Además, acepto un "sos un pelotudo" en los comentarios pero no sin una lección que me enseñe/ayude a entender el problema, me haga cuestionar mis pensamientos y me de pautas sobre como seguir creciendo.

Facundo Batista: Usando Go desde Python


¿Alguna vez necesitaron usar un código de Go desde Python? Yo sí, y acá cuento qué hice.

Antes que nada, un poco de background, para que el ejercicio no sea demasiado teórico: en el laburo tenemos que validar las licencias que se incluyen en el .snap, y aunque el formato en que están sería estándar (SPDX), una condición de contorno es usar el mismo parser/validador que se usa en snapd, para estar 107% seguros que el comportamiento va a ser el mismo hasta en los corner cases o bugs.

El detalle es que snapd está escrito en Go, y el server está escrito en Python. Entonces tengo que compilar ese código en Go y usarlo desde Python... de allí este post, claro.

Es más fácil de lo que parece, ya que el compilador de Go tiene la capacidad de buildear a "biblioteca compartida", y de ahí usarlo desde Python es casi trivial ("casi", porque tenemos que poner algo de código en C).

Para ser más claro, si queremos ejecutar "la lib de SPDX hecha en Go" desde nuestro Python, tenemos que poner dos componentes, que funcionan casi de adaptadores:

  • Un pequeño código en C para armar "como módulo" una funcioncita que recibe y entrega objetos Python, y hace la traducción al "mundo C" y llama a otra función en Go.
  • Un pequeño código en Go que traduce los parámetros desde C y llama a la biblioteca SPDX correspondiente.


Adaptador de Python a C

El archivo completo es spdx.c, paso a explicarlo haciendo antes la aclaración que es para Python 2 (que es lo que tenemos hoy en ese servicio), pero si fuera para Python 3 sería muy parecido (la idea es la misma, cambian algunos nombres, revisen acá).

Antes que nada, incluir la lib de Python

    #include <Python.h>

Vamos a llamar a una función de Go, necesitamos explicitar lo que va recibir (una cadena de bytes, que a nivel de C es un puntero a chars)  y lo que nos devuelve (un número, que interpretaremos como bool).

    long IsValid(char *);

Definimos la función que vamos a llamar desde Python... es sencilla porque es genérica, recibe self y argumentos, devuelve un objeto Python:

    static PyObject *
    is_valid(PyObject *self, PyObject *args)

El cuerpo de la función es sencillo también. Primero definimos 'source' (el string con la licencia a validar) y 'res' (el resultado), luego llamamos a PyArg_ParseTuple que nos va a parsear 'args', buscando una cadena ('s') la cual va a poner en 'source' (y si algo sale mal nos vamos enseguida, para eso está el 'if' alrededor).

    {
        char * source;
        long res;

        if (!PyArg_ParseTuple(args, "s", &source))
            return NULL;

Finalmente llamamos a IsValid (la función en Go), y a ese resultado lo convertimos en un objeto de Python tipo bool, que es lo que realmente devolvemos:

        res = IsValid(source);
        return PyBool_FromLong(res);
    }

Ahora que tenemos nuestra función útil, debemos meterla en un módulo, para lo cual tenemos que definir qué cosas van a haber en dicho módulo. Entonces, armamos la siguiente estructura, con dos lineas; la primera habla sobre nuestra función, la última es una marca en la estructura para que sepa que es el final.

    static PyMethodDef SPDXMethods[] = {
        {"is_valid", is_valid, METH_VARARGS, "Check if the given license is valid."},
        {NULL, NULL, 0, NULL}
    };

En la linea útil tenemos:

  • "is_valid": es el nombre de la función que vamos a usar desde afuera del módulo
  • is_valid: es una referencia a la función que tenemos definida arriba (para que sepa qué ejecutar cuando llamamos a "is_valid" desde afuera del módulo.
  • METH_VARARGS: la forma en que recibe los argumentos (fuertemente atado a como luego los parseamos con PyArg_ParseTuple arriba.
  • "Check ...": el docstring de la función.

Para terminar con este código, va el inicializador del módulo, con un nombre predeterminado ("init" + nombre del módulo), y la inicialización propiamente dicha, pasando el nombre del módulo y la estructura que acabamos de definir arriba:

    PyMODINIT_FUNC
    initspdx(void)
    {
        (void) Py_InitModule("spdx", SPDXMethods);
    }


Adaptador de C a Go

El archivo completo es spdxlib.go.

Tenemos que meter el código en un paquete 'main'

    package main

Importamos el código para SPDX de snapd (tienen que bajarlo antes con go get github.com/snapcore/snapd/spdx):

    import "github.com/snapcore/snapd/spdx"

Importamos adaptadores desde/a C, indicando que cuando buildeemos vamos a usarlo desde Python 2:

    // #cgo pkg-config: python2
    import "C"

La función propiamente dicha, donde indicamos que recibimos un puntero a char de C y vamos a devolver un bool:

    //export IsValid
    func IsValid(license *C.char) bool {

El cuerpo es nuevamente sencillo: llamamos al ValidateLicense de SPDX (convirtiendo primero la cadena a Go), y luego comparamos el resultado para saber si la licencia es válida o no:

        res := spdx.ValidateLicense(C.GoString(license))
        if res == nil {
            return true
        } else {
            return false
        }
    }

Cerramos con la definición obligatoria de main:

    func main() {}


Lo usamos

Primer paso, buildear (yo tengo Go 1.6, creo que necesitan 1.5 o superior para poder armar directamente la biblioteca compartida de C, pero no estoy seguro):

    go build -buildmode=c-shared -o spdx.so

Segundo paso, profit!

    $ python2
    >>> import spdx
    >>> spdx.is_valid("GPL-3.0")
    True

Juanjo Conti: Goodreads review: Nunca corrí siempre cobré (Leonardo Oyola)

Lindo libro para leer en corte autobiográfico.

Destaco:

* Lisa Hayes era del barrio Los Pinos: que termina con las líneas "Y que falta una copa en la misa. / Y que sobra un alma en el cielo" que dialogan con la conferencia que Oyola dio en Medellín en 2016 titulada "De cuando falta un vaso en la mesa y sobra un alma en el cielo".

* Campeón de campeones: un relato sobre ver en familia la película Best of the best.

* Casi sábado a la noche: el mejor cuento del libro. Una western con hijo, padre y abuelo de protagonistas.

* Tony Plana: que ya lo había escuchando en Animal que cuenta.

* La más linda del baile: una historia de amor.

Tiene muchas referencias a bandas y películas de una generación anterior a la mía y eso me jugó en contra como lector en algunos de los cuentos.

Rating: 3/5

Original: https://www.goodreads.com/review/show/2130076144

Mariano Guerra: Papers (and other things) of the LargeSpanOfTime III

I got to this papers by following the references from another paper, they were interesting but not as much as I was expecting:

This was on my queue:

A good one, I found it quite hard to find good overviews about datalog before this one.

Finished reading the book (or collection of 19 papers), really good chapters/papers in it: Your Wish is My Command: Giving Users the Power to Instruct their Software

Reading:

Papers this not so long span of time: 5 (count books as 1)

Papers+Books so far: 59