ふり返る暇なんて無いね

日々のメモ書きをつらつらと。メインブログに書くほどでもないことを流してます

$GREP_OPTIONSはdeprecatedらしい

Ubuntu16.04でgrep実行したらこんなwarningが出た

grep: warning: GREP_OPTIONS is deprecated; please use an alias or script

どうやら、将来的に$GREP_OPTIONSは廃止されるらしい。

This variable specifies default options to be placed in front of any explicit options.  As this causes problems when writing portable scripts, this feature will be removed in a future release of grep, and  grep  warns  if it is used.  Please use an alias or script instead.

ちなみにgrepのバージョンは以下の通り。

% grep --version
grep (GNU grep) 2.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script

docker上のUbuntu16.04でPOSIX::strftime::Compilerのテストが失敗した

その通りで、こんなDockerfileでビルドしたら

FROM ubuntu:16.04

WORKDIR /opt/ex
RUN apt-get update
RUN apt-get install curl perl make -y
RUN curl -L https://cpanmin.us | perl - App::cpanminus

RUN cpanm --verbose POSIX::strftime::Compiler

こんな感じで失敗したというお話。

    #   Failed test at t/04_tzset.t line 35.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-1-10 => Australia'
    #   at t/04_tzset.t line 37.
    #                   'Australia'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 45.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-1-10 => GMT'
    #   at t/04_tzset.t line 47.
    #                   'GMT'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 35.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-5-10 => Australia'
    #   at t/04_tzset.t line 37.
    #                   'Australia'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 45.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-5-10 => GMT'
    #   at t/04_tzset.t line 47.
    #                   'GMT'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 35.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-8-15 => Australia'
    #   at t/04_tzset.t line 37.
    #                   'Australia'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 45.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-8-15 => GMT'
    #   at t/04_tzset.t line 47.
    #                   'GMT'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 35.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-11-15 => Australia'
    #   at t/04_tzset.t line 37.
    #                   'Australia'
    #     doesn't match '(?^:A?CST)'

    #   Failed test at t/04_tzset.t line 45.
    #          got: '+0000'
    #     expected: '+0930'

    #   Failed test 'Australia/Darwin / 2013-11-15 => GMT'
    #   at t/04_tzset.t line 47.
    #                   'GMT'
    #     doesn't match '(?^:A?CST)'
    # Looks like you failed 16 tests of 16.
# 以下略

最初見たときtimezone設定してるのにGMT????何やっても+0000なの?????? は???って感じだった。

どうやらtzdataが入ってなかったようで、どっかのタイミングでapt-get install tzdataをしてあげれば良さそう。 イメージがコンパクト過ぎると逆に思いもやらないところでやられてしまうという好例でした。

逆に言うと普段の環境が盛々すぎるとも言えるのかな。

ブルーグリーンデプロイと些細なデプロイ

アプリをDocker化してそれをもってブルーグリーンデプロイできれば良いなあって妄想している。

ただ、設定ファイルのちょっとした変更だけで全部入れ替えになるのはどうなんだろう。ファイル配って再起動で終わりにしたい気分のときもあるだろう。 そういうときどうするんだろうね。。。。?

って発想が出てくるのはビルドをしない言語を使ってるからかもしれない。ビルドを基本とする言語を使っていれば、ちょっとした変更でもビルドが必要となるから、Dockerのリビルドは気にならないのかも知れない。 そういうことですかね。。。?どうなんでしょ?

Dockerをどっかーんと入れたい

けど、どうしたものか。

てのはありつつも、開発環境の構築フローが楽になるというメリットはすごいので、なんとか諸問題クリアしたい。 というかこれではざっくりしすぎなので、もう少し深掘りしたい。

現在の問題についても深掘りしたい。

GitHubのデプロイキーの管理みんなどうしてるの?

GitHubにはデプロイキーがあって、こいつがあれば、特定のレポジトリをpullできたりcloneできたりするわけですが、こいつの管理ってみんなどうしてるんでしょうか?

例えば退職者とか、悪意がある人がいたとして、デプロイキーとレポジトリのURIさえ知っていれば、レポジトリを社外に持ち出せてしまうわけですよね?

定期的にデプロイキーを更新するという手もあるかと思います。ただ、そればベストとは思えなくてどうしたらうまく回るのかなと迷い中の今日この頃。

不満の対処

人間だもの何かしら不満があるのは仕方ない。

不満が出たときの行動はだいたい以下の三つだと思う。

  • 不満を解消する(改善)
  • 不満を受け入れる(受容)
  • 不満を遠ざける(逃避)

とりあえず、どれかの行動を取れないかまず考えてみよう。

、、、、 自身でなんとかできる不満事項なのにぐだぐだ文句を言い続けて、何もしないのを見ていて余り気分良くないなって思いながら、この記事書いてた。

エンジニアとしての停滞

1年前とか2年前はわりかしブログとかTwitterでも技術系のことを書いていたのに、ここ最近ほぼ書かなくなった。勉強会とかも参加しなくなった。

これは、別の趣味に時間とお金を取られていたのが大きなところではある。ただ、エンジニアリングに対するモチベーションが下がっていたからこそ別の趣味に力を入れていたという側面もある。

こうして、(エンジニア的には)怠惰に1年過ごしたわけだが、ここで得たものは焦燥感しかない。技術的成長がほぼなかった(実感として)、新しめやトレンドの技術をほぼキャッチアップできてないそういう状況が目に見えて分かってきたのである。

1年のビハインドどうやって取り戻すか。これから考えているところ。少なくともこれ以上停滞するとエンジニア的には死しかない。

この焦燥感をバネに動くのは今しか無い。これはそういう決意表明的なメモです。