読んだ: スタンフォード式最高の睡眠
最近、眠りが浅いらしく夜中に起きてそのまま眠れないということが度々ある。そんな時に店頭で見かけたので買ってみた。
- 作者: 西野精治
- 出版社/メーカー: サンマーク出版
- 発売日: 2017/02/28
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
色々と最新の研究事例などをもとに説明がされているのだけど、結局対策としては俗説で聞いたことがあることだったりして、結局そうなのかよ…という残念な感じが拭えない。
例えば、よく聞く睡眠時間を90分の倍数にしようという俗説に意味はないと言いつつも、最初の90分を大事にしようというところとか。
なぜそうなのか、ということがわかったのは良いが、俗説にあるようなことでもできて入れば、こんな苦労はしてないわけで…。
期待外れ。
Goでプログラミング未経験の新入社員の研修をやった
今年の6月に配属されてそれから10ヶ月、3月末まで新入社員の研修を行った。
新入社員(以下Aさん)はプログラミング未経験ということで、どんな言語で研修を進めるか悩んが、これからチームとしてはGoでやって行こうという状況だったので、Goで研修を行うことにした。
以下散文。
プログラミング未経験向けのGoの情報は多くない
まずは参考になる書籍を探してみた。もともとGoの書籍は少ない上に、既存の言語を経験したことがある人を対象とした書籍ばかりなので、その辺りがなかなか悩ましかった。
とりあえず店頭で中身を眺めながら、スターティングGoにした。とりあえずこの書籍を中心に基本的なことを学んでもらうことにして、写経をしつつわからないところをフォローするというスタイルで始めた。
あとは、過去に自分が作っていたGoの基本的なハマりどころを確認するための問題集をやってもらうことにした。
最初はそんな感じで進めた。
カレンダーを扱うライブラリを作る
あるプロジェクトで必要だったので、カレンダーを扱うライブラリを作ってもらうことにした。
もともとRubyの実装があったので、それを元に作ってもらうようにお願いしていたが、自分も忙しかったりしてほとんどフォローできてなかったので、正直モチベーションは高くなかったと思う。
ちょっとしたウェブプリケーションを作る
一通り書籍の学習ができたタイミングで、グループ内で使用するための社内ツール的な位置づけで、ウェブプリケーションを作ってもらうことにした。
ここではDB周りの学習もするため、ER図書いたり、SQLを頑張って書くということもやってもらった。
LINEのボットを作る
年明けあたりからLINEのボットを作ることにして、天気予報ボットみたいなものを作ってもらった。
ボットは実装したら実際に動かして確認のレスポンスが得やすい、というところが研修には向いているのかもしれない。
多分この辺りから本人も楽しんでプログラミングができるようになってきたんじゃないかなと思う。
もともとLINEのボットはやるつもりだったけど、もっと早く着手してたら楽しめたかなぁと思う。ここは研修の見通しが良くなかった反省点。
大阪で行われていたLINEのハッカソンにも参加したりとなかなかアクティブに動いてもらっていた感じ。
社内の情報共有
社内の情報共有用のサイトに、Goのスライスについてきちんと調べてもらって記事を書いてもらった。
他にもポインタの話とか、よく調べてくれてまとめてくれた感じ。
自分が教えたこと
まぁそんな感じで10カ月を過ごしてもらった。自分ができることはあまり多くなくて「プログラマかくあるべき」みたいな話が多かったと思う。
Goって初心者向きなのか?
自分としては向いていたと思う。
Goは愚直に書くことが許されるというか、洗礼された書き方を追求しなくて良いというか、やってることは一緒だけどコードの書き方がイケテナイのでダメみたいなこともあまりない。
そういう観点で素人も玄人も近しいコードになると思っている。
なので、最終的にAさんが書いていたコードは設計上の問題を除くと、特にどうこういうつもりもないし、それで良いんだというのがGoの良いところだと思っている。
とはいえ、Goで飯が食っていけるのか?
これについてはちょっと確信が持てない。東京にいるならまだしも、大阪だとGoやってれば食いっぱぐれないみたいな状況も想像できない。
わかんないけど、転職したいんですけど〜みたいな状況になるとGoだけでは厳しいかもしれない。
本人もそういうあたりは理解していると思うので、うまく自分のスキルを磨いてもらえればと思う。
終わりに
特にまとめはないんだけど、そういう環境でGo勉強してたプログラミング未経験者もいたよって話です。
花粉症の薬かれこれ1年くらい飲んでる
薬に頼らずなんとかがんばろうとしていた時もあったけど、薬飲みだすとなんかそういう抵抗がバカらしくなった。
花粉症で薬を飲まない人は、つらいつらいと嘆いてばかりではなく、さっさと病院行こう。
自分は皮膚のアレルギーの関係もあってもう丸1年くらい薬を飲んでるけど、QOLがかなり向上した。
眠くならないクスリもある
自分が薬に頼りたくなかった理由が、眠くなるからだった。病院に行って相談したところ「アレグラ」を勧められた。
先生曰く「飛行機のパイロットが飲んでも大丈夫なやつ」らしい。その分効き目は弱いらしい。1日1回みたいなやつは眠くなるからやめといたら、とも言われた。
とりあえず飲んでみて、改善しなかったら違う薬試そうってなった。特に問題なかったので、アレグラ飲み始めて、今はジェネリック医薬品のフェキソフェナシンを飲んでる。
薬局で買うと高い
フェキソフェナシンは安い方。近所のドラックストアでは、56錠(4週間分)で1700円くらい。アレグラは錠数が半分で同じくらいの金額する。
病院で出してもらうと、56錠を3割適用で504円。アレグラだともう少し高いかも。でも3割適用されるし、市販よりは確実に安い。
初診料とか取られるけど、2回目からは薬だけ出してもらえる。前回行った時は、他の薬とか色々出してもらって、2000円くらいだった。
皮膚科でも花粉症の薬は出してもらえるから、今の時期、耳鼻科混んでそうだったら皮膚科に行ったら良いと思う。
あと、病院の待ち時間は読書する。それにスマホがあれば暇つぶしには困らない。
飲み薬以外の対策
ドラックストアとかに置いてる、体質改善するようなことを匂わせているサプリメントとかあるけど、あれは高いし効果もハッキリしないし(まぁサプリだから)、オススメしない。
花粉症ってプラセボでどうにかなるレベルではないと思うんで。
塗り薬ならオッケーみたいな感覚があったので、鼻の周辺に塗るような薬も試してみたが、あまり効果が感じられなかった。
目の周りにワセリン塗ると目が痒くなりにくいらしく、試してみたこともある。保湿することは皮膚を痒くしにくくする効果があるので、目の周りが痒くなるのを軽減することはできた。
目の中が気持ち悪いときには効果ない。アイボンとか使ってた。なんかそれも良くないみたいな話も見聞きするけど。
シーズン前に飲み始めるみたいな
病院で処方される花粉症の薬はシーズン前に飲み始めないといけない、みたいな話を見聞きすることがある。
実際先生にも言われたし、今年は去年と比べても明らかに辛くないので、まぁそういうもんなんだろう。
でもシーズン前に飲み始めないと全然効果がないわけではない。自分は飲み始めた日から効果はあって症状が軽減されていた。
なので、早めに病院行って薬飲もう。
丸1年くらい飲んでも大丈夫なのか
心配だったので飲み始める前に聞いてみたが、先生は「常用しても大丈夫」と言っていた。
しかし全く副作用がない、ということはないだろう。長年飲んでいた結果、何か別に影響が出るってことは今後あるかもしれない。
今は皮膚のアレルギーの関係で、飲まないと日常生活に支障があるので、常用しないといけなくて、結果として花粉症もつらくなくなった。
おわりに
特にまとめはない。 とにかく、花粉症しんどいんだったら、心にシワが増える前に、さっさと病院行って薬もらおう。
読んだ: 証明と論理に強くなる ~論理式の読み方から,ゲーデルの門前まで~
ツイッターで見かけて気になったので読んだ。
証明と論理に強くなる ~論理式の読み方から、ゲーデルの門前まで~ (知の扉)
- 作者: 小島寛之
- 出版社/メーカー: 技術評論社
- 発売日: 2017/01/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
1年くらい前に、別の論理学の本を読んだときは分からな過ぎて断念したが、この本は理解できてないなりになんとか読み進めることができた。
特に2部が面白かった。というか、3部以降はだんだんわからない箇所が多くなったのできちんと理解できてない。
学校で数学の証明はやったことがあったが、内容が正しいかどうかという点に注目して解いていた。この本では、そうではなくもっと形式的なものとして扱える(演繹というらしい)ことが説明されており、演繹のやり方から完全性・健全性という話に進んでいく。(この辺りまでがなんとなくわかった限界だ)
読んでいて「あれこれプログラミングじゃね?」と思うことがたびたびあって、ちょっと調べたところ「数理論理学」というのがあって、情報工学にも関係あるらしい。
気になったこと
ホフスタッターの定理、
MIUの演繹システムでは、項MUを演繹できない
をホフスタッター数を利用して証明するってところで、なぜ
M→3, I→1, U→0
となるのか分からなかった。
他の書籍
参考書籍に上げられている本で「ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版」というのがあって気になった。でも安くないししかもページ数が多い。体力ないと読めなさそうだ…
ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版
- 作者: ダグラス・R.ホフスタッター,Douglas R. Hofstadter,野崎昭弘,柳瀬尚紀,はやしはじめ
- 出版社/メーカー: 白揚社
- 発売日: 2005/10
- メディア: 単行本
- 購入: 14人 クリック: 432回
- この商品を含むブログ (145件) を見る
数理論理学面白そうなので何か入門書を探して読んでみよう。
apexでAWSのprofileの指定
apexを使ってデプロイするときに、AWSのprofileを切り替えたい。
オプションを使う
--profile
を使う。
apex --profile=another deploy func
たまに切り替えるならこれで良いと思う。
project.json に指定する
profileという項目で設定できる。
{ "name": "linebot-demo", "description": "linebot demo", "memory": 128, "timeout": 5, "role": "arn:aws:iam::218010143316:role/linebot-demo_lambda_function", "environment": {}, "runtime": "golang", "profile": "another" }
アプリとしては認証情報に依存しないと思うので、この設定は良くないかもしれない。 開発環境とCI/CD環境でprofile名を統一しないといけないとか、色々メンドくさそう。
環境変数を使う
AWS_PROFILE
で指定することができる。
export AWS_PROFILE=another apex deploy
これが一番良さそう。
ただ、aws cliだと AWS_DEFAULT_PROFILE
を使うので、できたらこっちに合わせて欲しいような気もする。
swagger.json のルーティングをCLIで確認する
goaを使ってAPIのデザインをしているときに、ルーティングの確認がしたくなる。
ikawahaさんの、goa tips : swagger-ui を使って手っ取り早く API を試す - 押してダメならふて寝しろ にあるように、swagger-ui用のルーティングを使うことで確認ができるのだが、正直もんにょりする。
という話を会社で話していたところ、後輩がCLIのツールを作ってくれた。
swagger.json をパースして、ルーティングを表示してくれる。
$ curl -s http://petstore.swagger.io/v2/swagger.json > swagger.json $ swrt http://petstore.swagger.io/v2 PUT /pet POST /pet GET /pet/findByStatus GET /pet/findByTags GET /pet/{petId} POST /pet/{petId} DELETE /pet/{petId} POST /pet/{petId}/uploadImage GET /store/inventory POST /store/order GET /store/order/{orderId} DELETE /store/order/{orderId} POST /user POST /user/createWithArray POST /user/createWithList GET /user/login GET /user/logout GET /user/{username} PUT /user/{username} DELETE /user/{username}
さっと確認したいときはこれで十分。便利。
jsonをPIPEで受け取れた方が楽かなぁと思ったので、そのうちプルリクしよう。
作業手順書を書くときに気をつけたいこと
最近社内で手順書をレビューしてて気になったことがあったので、書いておく。
作業の目的を明確にする
まず、なんのための作業なのか明確にしておく必要がある。例えば、
- 管理者を追加したい
- データをクリーニングしたい
- リリース作業したい
など作業の目的は様々であるが、それがはっきりしないことには、そもそも手順が正しいかどうか判断できない。
「今度削除するデータをお客様の要望により念のためバックアップしたいです。」
「はい、でも対象になるデータは、n週間前のデータなので週次バッチでバックアップが残っていると思います。そもそもこの作業は不要で、削除だけの手順で十分だと思いますがどうでしょうか?」
「確かにそうですね」
みたいな不毛なことがないようにしたい。
日本語の表現を曖昧にしない
例えば履歴のデータをクリーニングするとする。
#先月までのデータを削除する
DELETE FROM hoge_table WHERE created_at < ‘2017-02-01’;
「ちょっと待って、先月までって、1月までってことで1月は含まないんじゃないでしょうか???いや私が勘違いしているかもしれないし、「まで」ってのは含むの含まないの?」
日本語は難しい。口語でサラッと書いてしまうと境界条件が曖昧になってしまう。 SQL見れば自明だろ!って思うかもしれないけど、日本語とSQLとどっちが正しいか確信が持てない。
スコープを揃える
スコープと言う表現が適切ではないかもしれないが。
先の例でいうと、履歴データは年月日のデータを持っているので、「先月まで」「半年」みたいな月や年単位の表現ではなく、日をベースに範囲とかを記述すべきだと思う。
#2017-02-01未満のデータを削除する
DELETE FROM hoge_table WHERE created_at < ‘2017-02-01’;
と書いてもらえると、SQLと日本語で違いがない。日本語の表現としては少し変な感じがするかもしれない。でも、境界条件はハッキリしたい。
時刻は固定された表現にする
ついでに書くと「先月」という表現は作業をする時点で変わってしまう。2月だと1月だし、6月だと5月になってしまう。
作業をする時点での、明確な時刻を指定した方が揺るぎがないので、極力時刻を固定した方が良いと思う。
作業が延期されたりすることもあるが、その際にはその時の日時で手順書を更新すべきだと思う。
後から振り返ったときに、いつやった作業なのか明確になっている方が良い。 「2017-02-01データクリーニング手順書.txt」となっていても、実際には3月に作業したみたいなこともあって、そういう時にファイル名も更新すべきだし、手順書の内容もちゃんと日時を合わせるべき。
根拠を明確にする
手順書に落とし込む必要はないかもしれないが、作業の根拠は明確でないといけない。
「データクリーニングの対象レコードが1億件あるので、メモリが足りない可能性があります。」
「メモリが足りないという根拠はなんですか?」
「前回2千万件のレコード削除の際にはメモリが枯渇していました。」
「(トレンドのグラフを見つつ)前回の作業の時には明確なメモリ使用量の変化はないようですが…」
「COPYを使ったので…(モニョモニョ…)」
「逆に同じレコード件数で、別の作業の時にpg_dumpを使用していますが、コレはメモリには影響なかったんでしょうか?」
「それは…」
例えばレコード数が同じだった時にCOPYはダメでpg_dumpは大丈夫という根拠が明確でないといけない。
同じ操作ではないのでもちろんリソースの使い方も違うと思うし、一方が良くて一方が良くないという理由はちゃんと説明できないといけない。
そもそもどちらの作業も考慮が足りてなかったんじゃないか?と思ってしまう。たまたま影響がなかっただけで。
実際、何が影響して障害になったりするかわからない部分も正直あるんだけど、少なくとも自分がやる作業については、どういう作業でどういう影響があって、どういうリスクを伴うかというのは根拠を持ってないといけない。
根拠が間違っているかもしれないんだけど、そこが揺らぐと何もできないし、自分で説明できるレベルで根拠はしっかりしておいてほしい。
他にもあった気がするけど、とりあえず終わり。