My Redux Experience

30 May 2016

It’s hard to find root of truth sometimes, especially when you have to much hype about it. I’ve usually start from awesome-* one. This time when I decide to take a look on Redux m journey was pretty much the same. Go to Github, and search for Redux Awesome. It leads me to huge list of Article, Videos etc. To much information some times even worth then lack of it.

So my way to get into this is find some kind of step by step introduction. I’ve just find a good one and I hope you will find it useful too.

https://github.com/happypoulp/redux-tutorial

Docker clean up

12 May 2016

Warning: This will destroy all your images and containers. It will not be possible to restore them!

Problem: You use Docker, but working with it created lots of images and containers. You want to remove all of them to save disk space. Some times I go deep in cowboy style development where all I want to do is do things fast. After this jam session I usually find my place ruined with tons of images and containers. It’s nice to start all things from scratch, and what you can do if you want to.

You can easily remove all images and containers by executing following lines.

# Delete all containers
$ docker rm $(docker ps -a -q)

# Delete all images
$ docker rmi $(docker images -q)

Fix for 'SETTING LOCALE FAILED'

10 May 2016

I was recently experience some annoying thing. If you choose to install dokku on DigitalOcean you will probably get something like so:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_CTYPE = "UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

It catching eye and drives me nuts. Following instruction can save you some time if you have the same.

You just need update your locale file

$ sudo cat > /etc/default/locale <<'EOT'
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LC_TYPE=en_US.UTF-8
EOT

and reconfigure it

$ sudo locale-gen en_US.UTF-8
$ sudo dpkg-reconfigure locales

As result you gonna see something like this

dpkg-reconfigure locales
Generating locales...
  en_AG.UTF-8... done
  en_AU.UTF-8... done
  en_BW.UTF-8... done
  en_CA.UTF-8... done
  en_DK.UTF-8... done
  en_GB.UTF-8... done
  ....

Don’t forget to reconnect, this changes will have effect with new session.

Cron tips & tricks

09 May 2016

CronTab is pretty powerful app, but we often don’t pay attention to it, here is some tips i’ve found useful for me.

Format

*    *    *    *    *  command to be executed
┬    ┬    ┬    ┬    ┬
│    │    │    │    │
│    │    │    │    │
│    │    │    │    └───── day of week (0 - 6)
│    │    │    └────────── month (1 - 12)
│    │    └─────────────── day of month (1 - 31)
│    └──────────────────── hour (0 - 23)
└───────────────────────── min (0 - 59)

Some Examples

0 * * * *     every hour
*/15 * * * *  every 15 mins
0 */2 * * *   every 2 hours
0 0 0 * 0     every sunday midnight

Basic commands

Open in editor bash $ crontab -e

List tasks bash crontab -l [-u user]

Cron Tab checkers

It’s hard to remember this format, and crontab doesn’t provide a handy way to check your syntax, like nginx does for instance. But there is plenty of checkers online what you can use.

Apply the principle of least privilege

The sixth column of a system crontab(5) file is the username of the user as which the task should run:

0 * * * *  root  cron-task

To the extent that is practical, you should run the task as a user with only the privileges it needs to run, and nothing else. This can sometimes make it worthwhile to create a dedicated system user purely for running scheduled tasks relevant to your application.

0 * * * *  myappcron  cron-task

This is not just for security reasons, although those are good ones; Similarly, for tasks with database systems such as MySQL, don’t use the administrative root user if you can avoid it; instead, use or even create a dedicated user with a unique random password stored in a locked-down ~/.my.cnf file, with only the needed permissions. For a MySQL backup task, for example, only a few permissions should be required, including SELECT, SHOW VIEW, and LOCK TABLES.

Customize your tasks properly

If necessary, you can set arbitrary environment variables for the tasks at the top of the file:

MYVAR=myvalue

0 * * * *  you  cron-task-which-use-env-vars

Send the output somewhere useful

Another common mistake is failing to set a useful MAILTO at the top of the crontab(5) file, as the specified destination for any output and errors from the tasks. cron(8) uses the system mail implementation to send its messages, and typically, default configurations for mail agents will simply send the message to an mbox file in /var/mail/$USER, that they may not ever read. This defeats much of the point of mailing output and errors.

This is easily dealt with, though; ensure that you can send a message to an address you actually do check from the server, perhaps using mail(1):

$ printf '%s\n' 'Test message' | mail -s 'Test subject' you@example.com

Once you’ve verified that your mail agent is correctly configured and that the mail arrives in your inbox, set the address in a MAILTO variable at the top of your file:

MAILTO=you@example.com

0 * * * *    you  cron-task-1
*/5 * * * *  you  cron-task-2

If you don’t want to use email for routine output, another method that works is sending the output to syslog with a tool like logger(1):

0 * * * *   you  cron-task | logger -it cron-task

Alternatively, you can configure aliases on your system to forward system mail destined for you on to an address you check. For Postfix, you’d use an aliases(5) file.

I sometimes use this setup in cases where the task is expected to emit a few lines of output which might be useful for later review, but send stderr output via MAILTO as normal. If you’d rather not use syslog, perhaps because the output is high in volume and/or frequency, you can always set up a log file /var/log/cron-task.log … but don’t forget to add a logrotate for it!

Named arguments vs Indexed

03 May 2016

There is two ways of using arguments both has pros and cons, I want to emphasize that there is no “silver bluet” and you don’t have to choose one or another. You have to know both and use both whenever it appropriate.

Indexed arguments

Some application, languages, and even syntax contractions force you to use index version of arguments, they all well known and don’t worth to mention, but what is really interesting that some times we can use it in unexpected places.

in Postgres

Each of the arguments you specify in a select has a 1-based index and you can use these indexes in the order by as well as group by statements.

Instead of writing

select id, updated_at from posts order by updated_at;

you can write

select id, updated_at from posts order by 2;

If you want to group by a table’s type and then order by the counts from highest to lowest, you can do the following

select type, count(*) from transaction group by 1 order by 2 desc;

in Swift

Closure automatically provides shorthand argument names to inline closures, which can be used to refer to the values of the arguments by the names $0, $1, $2, and so on.