チクメキメモリアル

2015/08/23

万歩遅れてのエンジニア開始、約1年間の軌跡。

Haskellをやっておく

言語自体は仕事で使わないかもしれないけど、Haskellの考え方が後々非常に参考になった。「プログラミングHaskell」という本が非常に考え方の部分を重点的に書いていて参考になる。「すごいHaskell、ゆかいに学ぼう」はどちらかというと実践形式。

[2014-07-07]

プログラミングHaskellを購入して朝勉強会で読んでいる。ただし、これやっぱり書かないとだめだなという事で読むと書くを毎日交互にやるスタイルに変更。また、Preludeの写経も有効な気がしている。

[2014-08-06]

まだプログラミングHaskell終わってないので1回全部読み切って終わらせる。理解は2周目の俺に任せる。

[2014-10-22]

プログラミングHaskell読み終わった。第9章くらいから理解までせずに適当に読んだ。書く事もはじめる為にLearn You Haskell for Great Goodを写経し始めた。

次はReal World Haskell

これは難しそう、Parallel and Concurrent Programming in Haskell

[2014-12-07]

実践関数型プログラミングの説明が非常にいい感じだと気づいた。何かガツッと作らないとおぼえれない可能性が非常に濃厚。

[2015-02-01]

最近全く触ってない。もはや忘れつつある。30分勉強会がほぼ無くなった。

[2015-03-08]

30分勉強会復活させようかな。どうしようか悩むな。なんかあの朝の時間、ダラダラとFeedを追う時間になってる。

[2015-05-27]

ダメです。完全に割く時間がGolangにうつってしまった。このConcurrency and Parallelismというスライドとトークが最高にわかりやすかった。

この辺の並行/並列の辺りは一度ブログに書いて自分の理解を定着させたい。

[2015-07-13]

ERDツール使う時にちょっとだけHaskellしたが最早やってない。あとこのツール導入する時にちょっとコード読んだ、くらい。 https://github.com/olivierverdier/zsh-git-prompt

自分が興味を持ち続けれるプロジェクトにPRを出す

by @maddydickson

他の人々に教えてもらういい機会。コミュニティへの恩返しにもなる。ただし、自分が使ってる、興味を持ってるところに出すのが大事。続けれないと面白くない。

[2014-07-07]

未だできてない。やりたいのはluigiのS3対応が一番仕事にも近くていい気がしている。

[2014-08-06]

未だできてない。luigiにはS3のTarget入ってる事に先日気づいた。となるとどこに出そうかな。botoのImpalaセットアップのコード辺りか。

[2014-10-22]

できてません。興味あるプロジェクトなんだろう。

[2014-12-07]

ShibにtypoだけどPR出してマージしてもらえた。

https://github.com/tagomoris/shib/graphs/contributors

OSSへのPRはできそうなタイミングでやっていこうと思う。正直今は上手く使わせてもらうだけで精一杯な部分が多く、何か必要な機能があるのであればp-rよりも、別のサービスやOSSを探してしまう。

どうしても無い、っていうケースは、本当にその分野の先端を走るか、本当にニッチな領域に関してじゃないと無さそうだなという気がする。

[2015-02-01]

一旦自分もOSSを出してみた。使ってもらえるかどうかは知らん。

https://github.com/achiku/hubot-piptools

自分で書いた紹介記事

http://achiku.github.io/2015/02/02/hubot-piptools.html

あとshibはやっぱり便利なので継続的にコードベースを見て、何がしかのPR出せるようにしたい。 embulkがもしかしたらOSSで名を上げる為には結構いいのではないかという説がある。黎明期のfluentdのような着眼点、かっけー。 https://github.com/embulk/embulk

[2015-03-08]

ついにshibに対してprを出した。これマージされたら嬉しい。

https://github.com/tagomoris/shib/pull/30

あとテストが落ちるのでその報告的なやつ。

https://github.com/tagomoris/shib/issues/29

[2015-03-14]

マージされた！！

https://github.com/tagomoris/shib/pull/30

今後も継続的に色んなライブラリを見て行きたい。

[2015-05-14]

botoに対してpr

https://github.com/boto/boto/pull/3156

awsbootstrapactionに対してissue

https://github.com/awslabs/emr-bootstrap-actions/issues/90

PyHiveに対してissue

https://github.com/dropbox/PyHive/issues/14

motoに対してissue/pr

https://github.com/spulec/moto/issues/347

[2015-07-13]

motoへのprがマージされた

https://github.com/spulec/moto/pull/375

django-s3-storageに対してprしてマージされた

https://github.com/etianen/django-s3-storage/pull/1

[2015-07-29]

jungleというAWSのYet Another CLI作った。そして初PyPI登録した。

コンセプトとしては"Unix-linkなAWS CLI"という感じ。 aws-cliは本当に便利で最高なんだけど、全部載せ且つオプション長すぎてCLIとして普段使いするのは結構面倒。その中でaws s3 lsとかはかなり直感的に扱えるなぁというのがこれを作った動機になってる気がする。 EC2やELBやASGとかだってCLIっぽく軽く扱えたらいいな、と。あとclickっていうPython製CLIライブラリが結構良さそうだったので使ってみたかったってのもある。

hotdogっていうDataDogとやりとりするCLIがあるんだけどコレも参考になる。

とにかく時間を投資する

by @voluntas

効率とかよりもまず費やす絶対時間を増やすこと。効率は二の次。

[2014-08-06]

できてない日もあるが、概ねできている。酒飲んで帰宅遅くなるとできてない。写経のやり方もう少し効率化できる気がしてきた。

[2014-10-22]

最近帰ってからコードかけてない。けど、会社でコード書く時間がかなり増えた。

[2014-12-07]

会社でコード書く時間が格段に増えて、家では本読む時間になってる。

[2015-02-01]

休日に書くコードが会社のコードではなく自分のプロジェクトのコード(CoffeeScript/Golang)になった。平日は相変わらずコード書く量を維持できてる気がする。

[2015-02-23]

プロダクトのコード書き中。自分のプロジェクトは一旦お休み。ただ、「何を解決すべきなのか」という部分により多くの時間をさくフェーズな気がするので、そこまでガツガツは書けていない。来月もっと書きたい。

[2015-05-27]

3月はガッツリプロダクトBのコードを書いた。ココで結構Presto + SQLAlchemyの知見溜まってる。4月はプロダクトの改善、購買履歴系ランキングのデータを作った。5月は購買履歴系ランキングのデータ改善。プロダクトCの数値棚卸し。4月以降ガッツリ時間を取って何かを開発する時間をとれていない。

[2015-07-13]

6月はAnsible化と既存AWSインフラの整備、プロダクトAのadminに時間を費やした。しっかり時間を取って開発は無いけど、既存のAWSインフラをAnsibleで整備するのは知見が溜まった気がする。あと、Obje-CとArduinoを休日プロジェクトとして開始した。月末にはある程度のものにしたい。

写経する

by @voluntas

新しい言語覚える場合は写経有効。興味のある分野のOSSの写経の効果は抜群。

[2014-07-07]

現在django.http写経中だけど、非常にいい。知らない書き方や、知った気になってた部分結構ある事に気づける。なんといっても開始する際の心理的障壁が非常に低い。まだ新言語を学ぶ際の写経は取り入れた事ないけど、Erlangをやる時にはやってみよう。あとプログラミングHaskell一段落させて、何かHaskellのプロジェクトを写経してみる。

[2014-08-06]

今はMQTTのPythonクライアントを写経中。コードやコメント自体が非常に綺麗で参考になっている。ただし、全体の構造を把握する前段階から写経に入ってしまっているので、ここは次回以降効率化できる気がする。やっぱり全体の構造が分かってから写経したほうが良い。

[2014-10-22]

サイボウズ式のコサキさんのお話がとても良かった。

http://d.hatena.ne.jp/nishiohirokazu/20140905/1409908066

今はGolangのチュートリアル完了。

[2014-12-07]

Golangの写経もう少し進めないと。最近Golangに関しては全く時間がとれていない。新しいものジワジワやっていきたいけど、メインのPythonももう少し知りたい。

[2015-02-01]

GolangのWebAppの写経実施中。このチュートリアルは結構良い。

[2015-03-14]

最近はプロダクトのコードばかりで特に書けていない。

[2015-05-27]

プロダクトコード書けてないので写経中の物が多い。

mackerel-agent
fluent-agent-hydra
fluent-forwarder

[2015-07-13]

プロダクトコード書けてないので写経中。今はObj-CのTutorialを書き写してるところ。iosアプリ開発は基礎整えるのにある程度時間かかる。ただ、明細アプリはこれ以上何か発見しようとすれば、どうしてもプロトタイプが必要なんだよな。「リアルタイム決済通知や予算方式は本当に人間の購買行動に影響を与えるのか」を検証したい。現状の環境ではarduino + BLE + iPhoneで検証する予定。もしかしたらスクレイピングするかも。

10分で今思い描ける最高のエンドプロダクト

by @ariyasu

10分じゃなくてもいいけど、とにかく短い時間を区切るの大事。真面目属性を持ってる人はずっと考え続けてしまうし、行動にうつらない。スタートアップはスピード無いとやっていけない。10分で思い描いたらそれその週にリリースな。

[2014-08-06]

これは良さそうな習慣。懸念点は10分で本当に本質に迫れるのか、というところ。ただし、10分間鼻血が出るほど考えて、とにかくエンドプロダクトまで行く。このエンドプロダクトがその時点で本質に迫っていないのであれば、ソレはもはや自身の実力の欠如と認める。上記サイクルを何回も回しながら「10分」のクオリティを上げ続けるというのはいい策かもしれない。

難易度にもよるだろうけど、結果的に10分で本当に本質に迫れるような鋭い思考ができるようになるかもしれない。継続してやっていく。

[2014-10-22]

10分で解決できる問題を切り取る力が上がる。計測可能な制約を加えると新しい知見たまる事ってある。

[2014-12-07]

継続中。システム設計の部分に関しても応用できないか考える。制約は計測できれば時間じゃなくてもいい気がする。

[2015-02-01]

継続中。最近はコードについて考える時に使う事の方が多い。hubot-piptoolsもとりあえず細かい部分は実装せずにOSSにした。

[2015-05-27]

継続中。だけど最近これに対する意識が弱い気がする。引き締める。特にプロダクトB、彼らに取って最高とは一体なんなのかを考えて財布がついてこなかった感はある。「本当に最高」であれば財布も自然とついてくるもんなのかな。ここで財布を気にする必要があるのかどうか、まだまだケース毎にどの地点でバランスを取るか考える必要がある。

会社のどの部分を伸ばすの？から始まるプロダクト設計

by @ariyasu

読んで字のごとく。

[2014-08-06]

ものすごい当たり前なんだけど、なんか全然出来てない気がしている部分。

[2014-10-22]

できてない。

[2014-12-07]

データ系、ちょっとづつできてきている。

[2015-02-01]

CLOに関してはでっかい目標があり、今いい感じで達成出来て言ってると思う。ここのデータ系部分もっとアクセル踏みきりたい。

[2015-03-08]

データ系、Dashboard作ることで少しづつ見えてきてる感がある

思考より試行

by @ariyasu

読んで字の如く。

[2015-07-29]

デザイナ氏の提案で3時間に1回ハマり相談会をエンジニアチームで開催するようにした。コレもとりあえずヤル、駄目ならやめる、で即やろうってなったのは良い傾向な気がする。

100回書き直したら100回目が一番良いコード

by @voluntas

101回だったら101回目が最高だボケ。

[2014-10-22]

最近書き始めたコードベースを一回全部捨てた。意外に捨てれる。

[2014-12-07]

超雑に書いて捨てるのはいいかも。ただし、書くスピードが早くないと(WAFだったらそのWAFに慣れてないと)効果出にくい。

[2015-02-01]

それでも書いてると捨てにくいコードができてしまう。。捨て難いコードとそうじゃないコードの差、ちょっと考えて見る価値ありそう。

[2015-02-28]

この捨てるコードは「個人の中で完結する」事が大前提だな、って思う。結局クソ雑に作ったプログラムの中身を知っているのはその人個人で、イケてない部分も改善点も、その人の中に溜まっていく。プロト作って文章化するコスト支払うくらいだったら、書き直す時に同一人物がやるべき。そうでなければ捨てる用のコードを書く意味は、コードの品質を上げるという意味において、半減から8割減な気がする。(とにかくプロダクトを出す、という意味はある。あるけど不健康だしそんなコード引き継ぎたくない。)(引き継ぐぐらいだったらちゃんと時間とって作り直し。そして流用によって開発時間短縮になるという考えを捨てる。)

[2015-05-27]

プロダクトBは大分雑だけどCI/テスト/エラー通知/デプロイ/コードフォーマット/データモデルは揃ってる。基盤となるような部分だけ丁寧に作ってコードはTODOベースで開発していくの、有りだなと思う。そもそも良くないコードはテストが無くて触れない、っていう不安が一番大きい。何が起こるかわからんから。CIがちゃんと回ってれば最悪壊れた事はわかるし、テストでカバーできてなくてもエラー通知があれば気づけるという安心感は大事だなぁと思った。

エンジニアのエゴとの向き合い方

by @_achiku

[2014-12-07]

自分で感じた部分だけど、真にシンプル且つスピード上げようと思ったら要らない部分がある。具体的にはnginx + luaの部分。アレは結局不要だったので捨てた。新しい技術使ってみる事と作り出す価値のバランス意識的だと思ってたけど案外だめだった。けど、ちゃんと考えて、捨てて、期日までに作り直せたのは良い事だと思う。

[2015-02-01]

難しい。新しいモノを使いたい、っていうのはしょうが無い。ただ、「ソレは本当に価値あるのか」って問い続けないと意味ないもの作ってしまうし、「何を解決すべきか」という課題定義できずに作られたものは醜いと思う。カッコいいエンジニアリングとは、ボトルネックになってる課題を言語化/構造化し、シンプルに最小の手数で、狙った課題をぶっ潰す事だ。ただコレも自分の中の宗教でしか無い部分だから、チームとしてどうするのかは引き続き考える必要がある。例えばなんでも好きな技術をぶっ込めるSandBox的な社内サービスを作る、とか。

[2015-02-10]

新しいモノ/サービスに躊躇するのはやはり、「慣れ」の部分が大きい気がする。凄いスピードで失敗できる環境があった方が良い。あと、違和感を持っても一旦実行してみる事が大事。新しいライブラリの利点と欠点をいくら言語化してみようとも、結局触って実行してみないと見えない部分が沢山ある。違和感を感じる領域が自分の限界なので、結局その先に行くべきか留まるべきかは踏み込んでみないとわからない。個人でやれ、っていうのはある程度その通りなんだけど、チームとして上手くやってくには会社としてサポートしても良いのではないかと思う部分あり。会社が潰れない程度、というのを適切に調整してやっぱりSandboxt的サービスがあるといいかも。

[2015-02-23]

Slackでやりたい事/気になった事を共有
チームで話す時間の捻出
ただ自分の事をガーガー話していくのはなんとなくエゴい部分はある
- http://www.slideshare.net/zigorou/ss-44864139
- カッコいい技術とは課題を定義し、それを解決するもの、ってのはあるんだけど
- でもそれだと定義しきれない課題は解決できないし見つけれない事になる
- 非常に難しい
- でもまだそこまで高いレベルの事はやっていないから粛々と2015年の当たり前に近づける
もしかしたら自分はコンサル気取りのチャレンジできないコストカッターなだけなのかもしれないなと思った

[2015-02-28]

そうならないように毎週「モクモク会」を開催するようにしようと思う
単になんかのチュートリアルをやってみる会
- 裏目的は急進派が保守派に書き心地を共有し、お互いちゃんと書いて良い悪いを言い合えるようにしたい
- ただ、本当にコレが最適な形なのかは不明
- 正直領域の責任者をひとり決めて全部丸投げる、の方が楽だし良い気もしている
- チクが何か話したからといってフロントエンド側に対して適切な指摘ができる気がしない
- 逆もしかり
- だけどとりあえずやってみる
落ちないシステムではなく、落ちても障害が起きにくいシステムを作ろう
- コレはモカさんにやってもらい中か

[2015-05-27]

モクモク会、結局最近はやらなくなってしまった。
ISCON部的な活動するのがよいか。どうしても誰かがコスト払ってやらないと前に進まない気がする。
なのでもう勝手にしろこの時間は、とかでいい気もする。
悩ましい

[2015-07-29]

結局仕事遂行上課題となってる部分を新しい考え方やフレームワークで解決する、という形にするのがベストか？
課題を定義、言語化する力

「なんとなくできていない」のほとんどはそれを指摘する人の不在が原因です

by @voluntas

[2015-03-08]

この部分、確かにできてなかった。とりあえず自分がやいのやいの言う役をヤル事にする。KPTでは意識してできてない事を明確にする、解決できそうな工夫をする、という話は継続してできてる。

[2015-03-14]

結局約束を立てて、守る、くらいしか言えないのかもしれない。

[2015-05-27]

KPTで自分の事を棚に上げて理想論を振りかざすおじさん役が板についてきた。ツライ。ツライが、「じゃあ今から自分は理想論を振りかざします」って言うとキャラっぽくなってハードルさがってツラみ軽減される。

[2015-07-29]

KPTで継続中。現在は自分がリードなんだ、という気持ちを少しづつ抑えてる感ある。スケジュール切ったり基盤作ったりするモカさんが今はリードっていう形になってる。

好奇心を止めない事

by @murururu

[2015-06-18]

プログラミングうまくなる為に大事なことは好奇心を止めない事。あとパン屋やりたい。