読者です 読者をやめる 読者になる 読者になる

『Teem Geek』読んだ

結構前に買った本ではあるが,思うところあって読みかえした.以下,要約.あくまでも,このように理解するというものなので,はずしている部分あると思う.

1.天才プログラマの神話

いかに優れた人(プログラマ)であっても全てを一人でできない.チームが大切だ. そのため,一人隠れて作業をするのではなく,オープンな状態で作業を進め,他者とうまくやることが大切だ.

2.素晴しいチーム文化を作る

エンジニアリングチームにおける文化とは繁殖した菌.改善に対してオープンだが,害をあたえる急激な変化に対しては防御的.

3.船にはキャプテンが必要

マネージャーはメンバーを信頼するリーダーであるべき.マネージャーは謙虚・尊敬・信頼の雰囲気づくりをする.

4.有害な人物に対処する

特定の人ではなく,有害な振舞を排除する.

5.組織的操作の技法

うまく機能している組織は失敗を恐れず,チャレンジできる.が,現実そううまくいかない.組織に対して継続してはたらきかける必要がある.

6.ユーザも人間

ユーザを分析する.一般に使いやすいソフトウェアは対象のユーザの技術レベルを低く想定している.

MySQL で実行されるログを確認する general_log の設定方法

OR Mapper などでクエリを発行するとき、実際どのようなクエリが生成されているのかわからないです。 またアプリケーションからクエリを呼ぶときに、意図した変数をわたせているかも確認もできます(もちろんテストも書くべきですが)。

そんなとき、my.cnfの [mysqld] に次の設定をすれば、ログファイルからクエリの内容を確認できます。

general_log=1
general_log_file=/usr/local/var/log/mysql/query.log

上の設定の後、MySQLの再起動で/usr/local/var/log/mysql/query.logで保管期間1日でログ出力されるようになります。

なお、設定したままにするとログファイルが出力されっぱなしになって、ストレージを圧迫することになり兼ねませんので、確認を終えたらコメントアウトしておくのが無難かと思います。

OSX で PostgreSQL の初期設定

先日、 突然 Standard user に降格されるという事件があったので、 OS のクリーンインストールを行いました。

mdkn999.hatenablog.com

パッケージのインストールは Ansible + Homebrew でやったのですが、PostgreSQL の初期設定の手順は手動で行ったのでメモとして残しておきます(いずれこれも自動化したい。。。)。

環境をば。

$ uname -mprsv
Darwin 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64 i386

$ brew --version
Homebrew 0.9.9 (git revision 95863; last commit 2016-09-07)
Homebrew/homebrew-core (git revision 24d3; last commit 2016-09-08)

$ postgres --version
postgres (PostgreSQL) 9.5.4

まず、手動で Homebrew で PostgreSQL をいれるときは多分こんな感じだと思います。

$ brew search postgresql

$ brew install postgresql

続いて DB の初期化と起動。なお、initdb したときに、/usr/local/var/postgresが既に存在してるヨ。削除するか別のディレクトリ指定してネ。と言われたのでrm -rf /usr/local/var/postgres してから初期化した。

$ initdb /usr/local/var/postgres -E utf8

$ pg_ctl -D /usr/local/var/postgres -l logfile start

psql -lで DB の一覧が表示されれば OK。

次に、Role と DB の作成。

Role は postgres という名称で、Superuser, Login の権限を付けます。\duで Role の一覧が確認できます。

# create role postgres with superuser login password 'postgres';

DB は sample_database という名称で Owner を postgresに。

# create database sample_database owner postgres;

なお、DB と Role の削除は以下のコマンドで。postgressample_databaseの Owner なので先に Role を削除しようとすると怒られる。

# drop database sample_database;

# drop role postgres;

以上。

user is not in the sudoers file. This incident will be reported. [unsolved]

Ansible でローカルの環境をいじってたら、突然sudoできなくなりました。

$ sudo su -
Password:
user is not in the sudoers file.  This incident will be reported.

f:id:mdkn999:20160905180245p:plain

原因・対処法はあまり調べられていないですが、再インストールするしかなさそうです。

ERROR: No query specified

[mysql] mysql> select * from user\G;
...

ERROR:
No query specified

\G;がダメ。\Gまでがひとつの文とみられる。

[mysql] mysql> ;
ERROR:
No query specified

Homebrew の古いパッケージが削除できない。

$ brew cask uninstall --force dockertoolbox
Error: Cask 'dockertoolbox' definition is invalid: Bad header line: '{:v1=>"dockertoolbox"}' does not match file name

/usr/local/Caskroom のディレクトリに dockertoolbox という空のディレクトリが残ってしまった。

$ rm -rf dockertoolbox

brew cask listしても表示されなくなった。

今日読んだエントリー[2016-08-19]

今日読んだエントリー[2016-08-19]

2016-08-19に読んだエントリー。

f:id:mdkn999:20160819232048j:plain Photo via Visualhunt

エンジニア業務に役立つ英語学習のコツ

labs.septeni.co.jp 業務でも英語を使うことはおおいので勉強しないといけない。したいと思っているんですが、いろいろな方法があふれていてどの方法を使ったらいいかよくわからなくなるときがあります。

Google Translate のような翻訳ツール、 Ginger のような構文チェックツールを使用することもありますが、Google 検索の結果の数で正しい表現を調べるという観点は面白く試してみたくなりました。

2016年ウェブオペレーションエンジニアの新卒研修

developer.hatenastaff.com 新卒向けのエントリー。自分が新卒のときにこんな研修を受けたかったと思いました。

社内インフラの知識が必要になりますが、よっぽどの企業でもないかぎり、社内マニュアルや社内の手順書の整備はできていないかと思います。

そのような状況でどのようにしたら業務をこなしつつ技術を身につけることができるのか考えられていてすごいなーと思いながら読んでました。

「あとがき」で述べられている、研修の経緯の部分が個人的には面白く、研修の計画に至るところがすごいなーと思いました。

【保存版】エンジニアが見るべきテックブログ一覧(2016年編)

creive.me 今日読んだわけではないのですが、常に情報インプットを行うことが大切といつも考えています。

News feed, SNS などを通じて情報の収集を行って関心をもちつづけるように努力しないと思いました。

ただ、ブログのほとんどが理解できないのが辛いところ。

Wantedlyを支える技術をギュッと1冊の本にして技術書典に出展しました

www.wantedly.com インプットだけでなくアウトプットの大事だよ、と感じた。

また、電子媒体ではなく、書籍にしてしまったところがすごい。「まとまった情報を一貫した形で矛盾無く伝えるには1つの書籍という形が良い」というところも思わず納得できました。

コードレビューの基本

チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。 · GitHubソースコードはプロジェクトの共同所有物」。そのとおりですね。

時間が無いときは雑にプルリク投げてしまいがちですが、後に口頭での確認とかが必要になります。 口頭の確認はそれはそれでいいのですが、きちんとプルリクに仕様とか変更の内容を書いていたらあとから他の人が見たらわかりやすいですよね。

プロジェクトやチームにその程度の経緯はもっていたいと思う。いや、思った。