Good news, everyone!

Why Self-Taught Artificial Intelligence Has Trouble With the Real World
https://www.quantamagazine.org/why-self-taught-artificial-intelligence-has-trouble-with-the-real-world-20180221/

Carnegie Mellon Reveals Inner Workings of Victorious AI
https://www.cmu.edu/news/stories/archives/2017/december/ai-inner-workings.html

Simple Rules, Complex Systems and Software Development
https://www.targetprocess.com/blog/2009/03/simple-rules-complex-systems-and/

Understanding Activation Functions in Neural Networks
https://medium.com/the-theory-of-everything/understanding-activation-functions-in-neural-networks-9491262884e0

Creating a user in MongoDB not knowing the admin credentials

Last week I had to setup a staging machine for one of our applications in an environment with a pre-installed MongoDB instance. After creating all the infrastructure in AWS, setting up the environment and configuring the application I got a failed logon attempt to the database. Trying to connect directly (not through the application) resulted in the same error:

 
> mongo --port 27017 -u usuario -p minhasenha --authenticationDatabase novoBD

  Error: 18 { code: 18, ok: 0.0, errmsg: "auth fails" }

OK, it seemed the user didn't have access to the database. In MongoDB authentication is managed at a database level. When trying to connect to the MongoDB using a database, it checks for the provided credentials in the collection <database>.system.users. Solution: create the user in the database.

Well, easy solution if you have the admin credentials, but that was not the case. Workaround: as I had root access to the OS, I disabled MongoDB authentication:

> vim /etc/mongod.conf

  noauth=true
  #auth=true

Then logged in MongoDB and created an admin user:

> mongo --port 27017

  use admin;

  db.createUser(
    {
        user: "admin",
        pwd: "minhasenha",
        roles:["root"]
    });

Logged out MongoDB and enabled authentication back again:

> vim /etc/mongod.conf

  #noauth=true
  auth=true

Logged in MongoDB back with admin user (saved its credentials for future use!) and created the user in the new database:

> mongo --port 27017 -u admin -p minhasenha --authenticationDatabase admin

  use novoBD;

  db.createUser(
    {
        user: "usuario",
        pwd: "minhasenha",
        roles:[{ role: "readWrite", db: "novoBD" }, { role: "dbAdmin", db: "novoBD" }]
    });

After that the application happily connected to MongoDB. If the application is happy, I'm happy too!

Simulating cron environment

Ever added a script to crontab just to discover it didn't run as expected? Well, cron environment is not the same as your user environment and that could make a huge difference depending what your script is doing.

To help me writing scripts taking into account this difference I use the following tip by mmccoo (https://stackoverflow.com/questions/2135478/how-to-simulate-the-environment-cron-executes-a-script-with).

Add this to crontab:

 
30 08 * * * env > ~/cronenv

After it runs, do this:

 
env - `cat ~/cronenv` /bin/sh

This assumes that your cron runs /bin/sh, which is the default regardless of the user's default shell.

If you want to use another shell just change /bin/sh for your favorite shell and don't forget to also change the shell used by cron by adding this to your crontab:

 
SHELL=<your_favorite_shell>

Good news, everyone!

What is backpropagation and what is it actually doing? 
https://www.youtube.com/watch?v=Ilg3gGewQ5U

What Google Learned From Its Quest to Build the Perfect Team
https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?smid=fb-nytimes&smtyp=cur&_r=0&pagewanted=all

Why everything might have taken so long
https://meteuphoric.wordpress.com/2017/12/31/16417/

Why are your bones not made of steel?
https://www.materialstoday.com/mechanical-properties/news/why-are-your-bones-not-made-of-steel/

You’re Descended from Royalty and So Is Everybody Else
http://nautil.us/issue/56/perspective/youre-descended-from-royalty-and-so-is-everybody-else

ON PROOF AND PROGRESS IN MATHEMATICS
https://arxiv.org/pdf/math/9404236.pdf

Checking the version of your MongoDB instance

If you want to know the exact version of your MongoDB instance, simply use:

 db.version();

It couldn't be simpler!

Good news, everyone!

Millennials are obsessed with side hustles because they’re all we’ve got
https://qz.com/711773/millennials-are-obsessed-with-side-hustles-because-theyre-all-weve-got/

Modern B-Tree Techniques
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.219.7269&rep=rep1&type=pdf

The Asynchronous Computability Theorem
https://medium.com/@eulerfx/the-asynchronous-computability-theorem-171e9d7b9423

The Times I’ve Messed Up As A Developer
https://medium.com/@zacharykuhn/the-times-ive-messed-up-as-a-developer-3c0bcaa1afd6

The female code-breakers who were left out of history books
http://www.bbc.com/future/story/20171009-the-female-code-breakers-who-were-left-out-of-history-books

Post-Scarcity Economics
https://lareviewofbooks.org/article/post-scarcity-economics

Your brain does not process information and it is not a computer

https://aeon.co/essays/your-brain-does-not-process-information-and-it-is-not-a-computer

Recovering a crashed MySQL instance

Raise your hand if you've never had a problem with corrupt government officials... oops, MySQL databases.

Last week I was importing a new set of tax calculation rules to our tax engine but forgot to check if I had enough RAM and swap on my machine to do that. As a result, memory consumption hit the ceiling and the OOM killer killed the MySQL process.

When I restarted the machine and tried to connect to MySQL server I was greeted with this message:

 Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'

Trying to stop/start the MySQL process (a trick we all learned in the good old Windows) didn't help.

Checking the MySQL error log in /var/log/mysql/error.log I could spot the following suspect lines:

 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 97983975202 and the end 97984446291.
 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
 [ERROR] Plugin 'InnoDB' init function returned error.
 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
 [ERROR] Failed to initialize plugins.
 [ERROR] Aborting
 [Note] Binlog end
 [Note] /usr/sbin/mysqld: Shutdown complete

OK, so it seems the redo log is corrupt. Well, if the redo log is corrupt, let's remove it! I'm not worried about the data that was being imported. I can re-run the full import again later.

 sudo rm /var/lib/mysql/ib_logfile0
 sudo rm /var/lib/mysql/ib_logfile1

Trying to stop/start the MySQL process still didn't work but after removing the redo log I had a different error in the log file (/var/log/mysql/error.log):

 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.

Checking the link informed in the error message it seemed the right thing to do was to go with the innodb_force_recovery parameter in the config file (my config file was located at /etc/mysql/mysql.conf.d/mysqld.cnf ). I started with 1, as suggested, but I was able to start the MySQL server only when got to innodb_force_recovery=4.

 [mysqld]
 innodb_force_recovery = 4

After starting the MySQL server and being able to read all the databases and tables (but not write, as innodb_force_recovery = 4 put them in read-only mode) I dumped all my data:

 mysqldump -u root -p --all-databases > all_db_local.sql

Having all my data saved in a file, I completely removed my current MySQL installation (and all databases) and installed a new one:

 sudo rm -rf /var/lib/mysql/
 sudo apt-get remove --purge mysql-server mysql-client mysql-common
 sudo apt-get autoremove
 sudo apt-get autoclean
 sudo apt-get install mysql-server
 sudo apt-get install libmysqlclient-dev

With a fresh MySQL install all I had to do was bring my data back in:

 mysql -u root < ~/all_db_local.sql

It took some time but, in the end, I had my MySQL server back to operation.