$ curl localhost:8000
$ curl -XPOST -d "foo=bar" localhost:8000
$ curl -XPOST -H "Authorization: Bearer YOUR_TOKEN" -d "foo=bar" localhost:8000

# サーバー側のログ↓
127.0.0.1 - - [03/May/2018 04:44:15] "GET / HTTP/1.1" 400 -
127.0.0.1 - - [03/May/2018 04:44:26] "POST / HTTP/1.1" 400 -
127.0.0.1 - - [03/May/2018 04:44:41] "POST / HTTP/1.1" 200 -

蛇足

virtualenv -p python3 . で環境つくっておく
pip install autopep8 と autopep8 -i foo.py しとく

最初から '0.0.0.0' 指定したからそれで動かないのか自信がないが↩

2018-04-24

TaPL読書録 #4

TaPL 技術系日記

前回:

hkdnet.hatenablog.com

今回は5章終わりまで、と思っていたが 5.2. の最後まででいい時間になってしまったので終わり。

今回は記憶がおぼろげなのでおぼろげに書きます。

ラムダ計算におけるリストの表現などについて Scott encoding, Church encoding と言われて何もわからなかったが、以下のブログに詳しい。

d.hatena.ne.jp

ラムダ計算ができる言語が欲しくなるが、arrow function があるJavaScriptがよろしいのではないかという話になった

github.com

power の話になったときに、回答例の power2 がこれは確かに power であるという確信がもてない。ここで power2' について考える。

power2  = \n. \m. m n;
power2' = \n. \m. \s. \z. m n s z; # イータ変換による

型のようなナニカを雰囲気で想像したときに(要は定義をせずに使う)。
まず Church数は2引数関数であり、第一引数に a -> a な関数を、第二引数に a を取り、a を返します。

cn :: (a -> a) -> a -> a

ここで m n に注目すると m :: (a -> a) -> a -> a と n :: (a -> a) -> a -> a について、 A = (a -> a) とすると n :: A -> A と捉えることも可能で型が一致しているような雰囲気があって面白い。

m :: (A -> A) -> A -> A
m :: ((a->a) -> (a -> a)) -> (a -> a) -> (a -> a) # 展開した
m n :: (a -> a) -> (a -> a) # nを適用した
m n :: (a -> a) -> a -> a # カリー化を考えると括弧に意味がない気がするので消した

となり m n が Church 数の型と一致するのが確認できる。

さて、我々は plus を手に入れ times を手に入れ power を手に入れるに至った。そうすると Knuth の矢印表記についても考えたくなるのは必然であるという話になった。ので、軟弱な私は即座にググった。

mindsarentmagic.org

やっぱりあったね。相性いいね、という気持ちになって終わった。

equal について、回答例では再帰を使わなかったが以下のようにも書けるような気がする。

eq = \m. \n. test (iszro m) (iszro n) (eq (prd m) (prd n));
eq = \m. \n. test (or (iszro m) (iszro n)) (and (iszro n) (iszro m)) (eq (prd m) (prd n))
2引数をとる関数に対応するYコンビネータ G に関して
equal = G eq

不動点コンビネータを使うようにするコミットのコメントで Fix って書いて一人で笑ってる
— はくどー (@HKDnet) 2018年4月22日

ここで教えてもらったのが、不動点コンビネータを使わずに関数を引数にとる方法もある。 lambda計算においては、適用するときに同じ項をそこに平べったく書けば良いとのこと(未検証)

fact f c = if (iszro c) then (succ 0) else (f f (prd c))
showFact = fact (if (iszro c) then (succ 0) else (f f (prd c))) c4

次回は5.3 〜 6章全体まで。

2018-04-22

『わかばちゃんと学ぶ Googleアナリティクス』の献本をいただきました

技術系日記

f:id:hkdnet:20180422143933j:plain

はいどうも、 ハイクオリティ神レビューア のはくどーです。
頂いたの3月末なのですが……。遅くなりましてすみません。

感想

ざっくりGAの使い方が紹介されていてよいんじゃないでしょうか。アクセス解析にまつわる諸概念についてもざっと紹介され、各概念を混同しないように説明しようという意思を感じました。
また、いつもの湊川節で「どうしてそれやるんだっけ？」「それってほんとにちゃんと目標に沿ってるんですか？」と優しく詰められるのが心地よかったです。

経緯

え！では今私が書いてるGoogleアナリティクス本のレビューアになっていただけないでしょうか！
インセンティブは焼肉（の予定）です🍖🍖🍖
— 湊川あい🌱技術書典 DL販売中！ (@llminatoll) 2017年11月19日

Twitterすごい(こなみかん

ふりかえり

実際にやってたこと

GitHub ベースでのレビューでした。
レポジトリが用意されて、markdown原稿がPRでとんでくるのでレビュー。
おそらくレビューが終わったあとに出版社の人が組版してくれて本になっている。
僕がレビューしてる段階ではあくまで markdown ( + そこから生成されるHTML )が対象。

よかった

対象ドメインがわからないので最初の読者として質問しまくれた
- 結果、わかりにくい点が減ったと思う
はじめて用語の統一などを意識して文章を構築する経験ができた
- ふだんは適当なので……
文章だけでなく、マンガ・イラスト部分にまで足を伸ばせた

わるかった

PRが巨大になりがちで難しい
- chapter 単位でのPRになっていたのだけど、分量が多い
修正が妥当かどうかを確認するのが難しかった
- 特になんどもすり合わせをしているようなとき、outdated な変更と見比べるのが難しかった
GitHub の diff viewer で画像が見れないのがめんどい
うまく違和感が言葉にできないことがあった
- なんかよくわからないんだけどこの言い回し変な気がするんだけど俺の語彙力がないせいなのかはたして、みたいなやつ
- いつもの仕事だったら適当に対面で話すんだけどどうしたもんか

次あったらどうしようか

問題: PRが巨大になりがち
- 解決策: chapter 単位ではなく section 単位でPRにする
  - 懸念: 用語の統一とか section 間での流れの悪さに気づけるか？
  - feature ブランチで chapter を作って各 section を feature 向けのPRとする、とよさそう
  - 今回はこういうブランチ運用とかまでちゃんと話せなかったなーという追加反省
問題: 修正が妥当かわかりにくい
- 解決策: PRブランチへのPRで修正を反映する
  - 懸念: ちょっとめんどくさいかも

2018年04月24日 00:25頃追記図を書きました

f:id:hkdnet:20180424002556j:plain

2018-04-22

草活1周年、に失敗した話

日記

f:id:hkdnet:20180422141206p:plain

3/31なんですけど、とあるレポジトリにコミットしてたのが、とある事情によりレポジトリごと消えたので草も一緒に消えてしまいましたとさ……。

これ private repo のも含めていて(= 会社のも含んでいる)、OSSっぽいことをしているわけではないのでアレなんですけどね。
達成したら記念に日記書こうと思ってたのだけど達成できなかった記念に置いておきます。

2018-04-15

『現場で役立つシステム設計の原則』感想

技術系日記読書

読んだ。

雑多に感想を書く。

いわゆる Rails Way において到達できるところと、実際にシステムが要求するところの水準に乖離があるような現場はそこそこあると思っていて、Rails から入ったけどそういうところに困っている人(= つまり僕だ)にいい本だと思った。
ふだんなんとなく気にしていることが明文化されているのがよかった。

とりあえず本記事の読者層をRailsさわったことありますという人として、第8章(アプリケーション間の連携)以降はあまり読む必要はなさそうだった。本書のよさはそこにはなく、蛇足だと感じたが、それは普段どういった情報に触れているかという話でもあるので読む人によるのだろう。

たとえばいわゆる Rails Way の何が厳しいのか。それを語るには Rails 歴がたりなさすぎるのであるがそれはおいておくとして、1つの指摘として「REST表現におけるリソースとDBのテーブルが1対1に対応する」という素朴な前提がよく育ったアプリケーション(あるいは対象ドメインによっては)当てはまらないということがあると思う。

bin/rails g scaffold Post でうごいたわーいというのはプロトタイピングとして優秀であるのですが、たとえば post を作るのは1つのクチでいいのか、という話。
たとえば有料課金ユーザーにのみに許されるアフィリンク追加みたいな機能があるかもしれない、あるいは記事を「書く」のではなくツイートの切り貼りで1つの記事を作りたいかもしれない。もしかしたら記事自体を売りたいというような要求が出てくるかも。こういった posts テーブルにまつわる種々の事柄¹をどう捌いていけばいいのかというのが Rails Way を超えた先にあるような気がしている。

Rails Way 以外のナニカに触れる機会として本書は非常によかったように思う。いま対峙しているアプリケーションにおいてどう設計するのがよいか、Rails Way と違う点は何かを考えるための機会を得たという感触がある。

posts 以外のテーブルに入れたほうがいいような例もあった気はしつつ↩