2016-09-14

BOTを作ってみたっていう記事を書いた話。

JavaScript Node.js

Qiita記事を書いたのでそれの話

Node.jsでTrelloとSlackとTwitterを連携させてタスク管理をちょっと良い感じにする

Qiitaでこういう話を書いた。
詳しくは全部そっちで書いているので内容はそっちを見て欲しい。
そしてリポジトリは以下。

https://github.com/nabeliwo/trello-slack-twitter-bot

経緯

最近Trelloでタスク管理を個人的にしていて、毎朝タスク決めて毎晩終わったタスク眺めて満足感を得るっていう自己肯定メソッドを使っているのだけれど、そこらへんの自動化をしたかった。
どこまで自動化するべきかとか考えて、タスクが終わったらslackに僕が投稿して、それを見てTrelloのcardを移動してもらうとかも考えたけれどそれだったら普通にTrello上でdndした方が早いなあとかそんなあほみたいなことも考えていた。

結果的に自動化されたのは終わったタスクをまとめて削除する処理ってだけだったけれど、あの処理をTrello上でやろうとすると確か3回くらいアクションを必要とするようなめんどくさい感じだったのでそれはわりと強い。
こなしたタスクが増えれば増えるほどこの自動化に意味が出てくるというわけだ。

やってみてQiitaに投稿もしてみて

いろんな人が記事を見てくれる中で、他の人も使いたいっていう状況を一応想定していて、設定ファイルに諸々入れて起動してもらえばその人の環境でも動くように作っているけれど、だがしかしもうちょっとここをカスタマイズしたいだとか文言を変えたいだとかになったときに、まあソース見て該当部分をなおしてくれればそれでいいんだけれど、そうではなくてもうちょっとカスタマイズしやすい形で提供するってことを考えないといけないなあと感じた。
(実際に使う人がいるのかなんて話はナンセンスです)

そろそろnpmにパッケージを出すとかをやっていこうっていう考えがあって、まずは簡単なライブラリからって思って最近考えているんだけど、出したいものはだいたい決まったけれどインターフェースがなかなか難しい。
とても簡単なことしかしないライブラリだとしても実際に使う人のいろんな状況を考えると柔軟なインターフェースにしなきゃいけないんだなーと。

そういうことを最近考えている。

あとはタスクの粒度とかが大事かなあという。
タスクを1個こなしたって言ったときのその1個が全部同じ重みでないといけないと思うから、それを前提にしてタスクの細分化をできるようになっていきたい。

最後に

教えてくれくれ君、サンプルくれくれ君、まあそんな感じのエンジニア人生2年半だったので、最近は貢献したさがある。
貢献したいというとなんか良い言い方を選んでしまってる気がする。要は自己顕示欲が強くなってきたという感じだ。

技術力をもってして自己を顕示していきたい。とそう思っている昨今でした。

2016-09-12

React勉強会 2016/09/10 @Gizumo-inc.

JavaScript React

Reactの勉強会をしたよ

僕が所属している会社でReactの勉強会を行いました。
やるに至った経緯として、僕が9月いっぱいで退職をしてしまうため、社内で動いているReactで書かれているプロダクトの保守・運用が現状だと心配っていうのがあって、僕が辞める前にReactの布教をしておかねばと言うことで。

もちろん別で引き継ぎ用のドキュメントは作っているけれど、技術的に触ることができる人ってのが増えれば増えるほど安心感がある。
実際のところ、社内のプロダクトはReact + Reduxという構成なので今月中にReduxの勉強会も開くつもり。

勉強会を開くにあたって

いつも社内勉強会やるときはなんとなくで進めちゃうんだけれど、今後外に開いた形の勉強会を作っていきたいなあーとふわっと考えているので、その練習も兼ねて今回はちゃんと時間設定してそれに合わせて進めていくっていう形をとってみた。
なので事前にスケジュールをたてました。

開始時間は13:00で、16:30終了が目標。3時間半で全てを終えられるように流れを組んだ。

流れ

当日のスケジュールは以下。

【13:00 ~ 13:30】Reactの概要説明スライド
【13:30 ~ 13:40】質疑応答
【13:40 ~ 14:00】ツール解説＆環境構築
Reactハンズオン
- 【14:00 ~ 14:10】hello world
- 【14:10 ~ 14:20】親子コンポーネント
- 【14:20 ~ 14:40】状態の変化(カウンターサンプル)
- 【14:40 ~ 14:50】ライフサイクルメソッド
【14:50 ~ 15:00】休憩
【15:00 ~ 15:30】Fluxの概要説明スライド
【15:30 ~ 15:40】質疑応答
Fluxハンズオン
- 【15:40 ~ 16:00】カウンター
- 【16:00 ~ 16:20】todoアプリ

かなりきつきつで辛そうな雰囲気がひしひしと漂うスケジュール。

勉強会の内容について

スライドは以下になります。

リポジトリはこちら。
https://github.com/nabeliwo/simple-react-sample

まずはスライドで概要を説明して、その後リポジトリをcloneしてもらってその中にあるコードでハンズオンをしていくという流れでした。
src/app.jsx がメインのファイルになって、そこに処理を書いていく感じ。書いてほしいコードは sample/ の中に全て入れています。コピペではなく、写経していく形で進めた。

やってみて

実際にやり終えてみての感想的な話。箇条書きでいく。

最初に懸念してたところなんだがやはり時間通り始められなかった。20分遅れでスタート。うちの会社は基本土曜の勉強会の開始時間が守られない。
環境構築でWindowsの人でちょっと手こずってしまった。そもそもリポジトリcloneしたときにGet Startedに書いてたコマンドがWindowsで動かないものだったり。そこらへんの配慮が足りてなかった。まあコマンドとかを何でも使えるものだけでやらせるとかをクリアしてたとしても、個人個人が入れてるNodeのバージョンとかそういう諸々を固定したいだとかそういうとこ考え出したら、本当にしっかりやりたいのであれば今後はvagrantで仮想環境立てて〜とかでいかねばならぬのだろうか…それはそれで環境構築のコストかかりそうだが…まだ悩みどころ。
ハンズオンパートでのスケジュールの考え方がだめだめだった。一つのパート10分くらいでいけんだろと思ってたが実際はその倍は普通にかかった。JSに慣れてない人であるとか、そもそもプログラミングを始めたばかりの人とかもいる中で、動かない〜ってなる人がたくさんいたが、それはまあ予測できることだった。大体タイポとかが原因のほとんどなので僕がいってコードを見ればすぐに解決するものではあったが、そこらへんのケアレスミスを予防する環境を作っておくべきなのだろうか。lintをリアルタイムで出してくれるエディター用意させるとか。現実的ではなさそう？
結果的にReactのパートだけで17:00を迎えてしまい、泣く泣くFluxのパートはまったくやらずに終了した。結果だけ見ると予定を40分超えてそして約半分しか終わらず終了っていうひどい形…。まあReact勉強会という名目なので特に問題はないが、その先を伝えたかった感はあった。なのでFlux勉強会をまた開く必要がありそう。
まだ受講者からのフィードバックをしっかりもらってはないので正確なところはわからないが、JSの初心者の子とふわっと会話した感じでは「雰囲気はなんとなくわかった」っていう曖昧な感じだった…。今回はJSをある程度わかる人を対象にしていたからまあ仕方ない。ただそこに飛び込んできてくれた勉強しはじめの子に対してのケアとかもなんらかの形でできないものかとは思っている。思っているけれど難しい…。

今後意識すること

勉強会の目的と対象者をはっきりさせる
必ずトラブルは発生するのでそれに対応する時間をスケジュールに考慮させる
終わったあと必ずフィードバックをもらう

まとめ

総じてスケジュール感が甘い、状況の想定が足りてなさすぎるという感じだった。
スケジュール組んで資料を作り終わった段階で一度ロープレしてたらよかったかも。

あと当日これないけど話聞きたいって人がたくさんいて、スライドとリポジトリ共有すればまあいいかなとは思うけれど、スライドは口頭で補足することを前提に作っているからキーワード的な部分しか載せていないわけで、勉強会に来ない人も想定して作るのであればスライド内で全てを説明する必要があるなあと思ったり。
そうなると勉強会内でスライドをする意味が薄れてくるからスライドは事前共有しておいて、当日はさらーっと流す感じにしてもっとハンズオンに時間を割くべきであるかとか。。。

考え出すといろいろと止まらないけれど、前提条件として「開くことで僕が得をする」ってのだけはブレることのないように今後も勉強会の開催とかをやっていきたい。
そして少しずつ規模をでかくしていけたらいいなあ。

2016-09-08

【メモ】React vs Angular2 2016/9/7 @TechFeed Live

JavaScript React Angular2 Redux

React vs Angular2と聞いて

ここのところ僕は仕事でReactばっかり書いてるわけですが、最近は趣味でAngular2も触ったりし始めてまして、まあ圧倒的にReactが好きなわけだけれどそれでもAngular2にも興味津々になっているっていうステータスです。

そんな中でこんなイベントがあって、僕的にはとても胸が熱い感じだったので参加してきました。
TechFeed Live#2 「React vs Angular」

やっぱりこういうトピックは人気がすごくて、connpassの抽選によって参加できるか否かみたいな形になってました。
僕は抽選で落選してしまったのですが、参加者の何人かがキャンセルしてくれたので繰り上がりで参加できるっていう運びでした。

100人規模くらいの勉強会だと補欠になっても、30人くらいはキャンセルするからわりと望みあるってことがわかった。

本題

勉強会メモを綴っていきまする。
形式はトークバトルって感じだったので雑にメモってます。
メモはReact側の意見とAngular2側の意見と僕の感想って感じでわけて書いてます。
(LTに関してはメモするの忘れてました…)

React陣営： @yosuke_furukawaさん, @koba04さん
Angular2陣営： @laco0416さん, @armorik83さん

開発言語について

React

Babelをメイン。TypeScriptのサポートもあるのでいける。
Babelとの親和性が高い。JSXは気持ち悪いけど、やっぱり必要。

PropTypesが微妙なのでそこをflowTypeに切り替えようっていう動きがある(facebookがそう言ってるわけではない)。

Angular2

可能な書き方は、TS,JS,Dart。推奨はTypeScript。
ドキュメントとかもTypeScriptがほぼほぼ。Dartはリポジトリ別れた。

感想

結局、言語はなんでもいいので、規模感に合わせて使い分けていくべきっていう話だった。
だとしても、親和性という面でいうとReactはBabel、Angular2はTypeScriptが高かった。

最近静的型付けの素晴らしさを感じ始めたのでTypeScriptにしろflowにしろ仕事の開発に導入したいな…。

アーキテクチャについて

React

Reactはviewのライブラリなので、Reactだけだと厳しい。
イベントや状態を管理するための機構が必要。fluxだったりReduxだったり。今はReduxが一番流行ってる。
ただ、React + ReduxにしたとしてもAngular2のようなフレームワークにはならない。ライブラリの組み合わせでしかないから、いろいろ考えないといけない。

React

Angular2の、フレームワークという形で学習コストが抑えられるのであればそれは良い
現実が見えてないけど理想を掲げてて良い

Angular2

Reactは人気が出てて羨ましい
安定板出せてて羨ましい

感想

Angular2の安定版が早ければ今月に出るらしいので、それが出たら一気に楽しそうな気がする。そもそも未だに安定版出てないのにこんなに盛り上がってるのはすごいことだと思う。

相手側の悪い点

React

早く安定板をだしてください

Angular2

Reactはもっとコミュニティ増やした方が良い。下からすくっていくのがない。
JavaScriptに自信のある人はReactに行ってしまう…。

感想

そんなにお互い悪い点はなかったらしい。

まとめ

もっと激しいディスり合いがあるものかと期待していたがわりと優しい感じの世界だった。
1回Reactだけで頑張ってみてそのつらみを感じてから、fluxとかReduxを触って便利さを感じてほしいって話とか、Reduxはフレームワークではなく薄いライブラリなので、フレームワークと勘違いをして不満を持ってる人が多いって話とか、自分のこれまでの行いを反省させられる言葉が多々あってよかった。
まだまだ自分でしっかりと設計をする力もないのにフレームワーク入れて、フレームワークに使わされてるような現状なので1度0から自分で頑張ってみる経験をしとこうかなと思った。

Angular2に関しては1回チュートリアルをやったことある程度の経験だったけれど、もう少しで安定版が出るらしいのでそしたらがっつり触ってみようかなと思った。

まとめおわり。
楽しかった良いイベントでした。

2016-08-28

『君の名は。』を見たぞい。胸が痛いぞい

Diary

注釈1。ネタバレはしないから安心して良いぞい。
注釈2。レビューなぞしない。

朝6時に起きたのさ

休日の朝6時から起きるなんて。
平日は9時に起きているというのに。

そんなわけで早朝に劇場に行って『君の名は。』を見てきた。
ここ1,2ヶ月でなかなか映画館に赴いている気がする。しかもどれも当たりだ。良き日々だ。

感想

たまらん。胸が痛い。

この胸の痛みは別にストーリーが悲しかったとかそういう話じゃなくって。

自分語りをはじめる

なんかこう、人はみんな劇的な人生を期待していて、いや、違うな、みんなではないかもしれない。少なくとも僕は、そして僕が考える多くの人は劇的な人生を期待している。と思う。
それでも、期待しつつも実際劇的なものなんて何もないってことに気付いていて、だから自分で日々を楽しくしようと努力する人もいれば、楽しいと思えるものにひたすら打ち込んでいる人もいれば(僕はこのタイプだ)、ないと心のどこかでわかってはいても劇的な何かが向こうからやってくることをただ待っている赤子のような人もいる。
人はいろいろだ。

映画っていうのは、なかなか日常を映したりはしないものだ。日常の中の非日常を映してみたり、はたまた非日常の世界の中の日常を映してみたり。
とにかくいつもこう思う、そんなこと実際はあるわけがないと。

あるわけがないとは思っているけれど、でも僕はそういうものを求めて映画を見に行くわけだから、別にそれが悪いとかそういう話ではなくて。
まあそれでいいのだ。「んなわけねー」とか言いながら笑ったり、驚いたり、悲しんだりできたらそれで良い。

今日はなんだか、「んなわけねー」的な気持ちがなかった。
別にそれはとても日常的なお話だったからとかじゃなくて、やっぱり映画になるくらいだから実際には「んなわけねー」的なことがまああるんだが、そんなこと感じないくらいに世界に入り込むことができたというか。
「がんばれ！がんばれ！」ってなったり、失った何かを取り戻したい気持ちになったり、まあなんか総じて常に胸が痛かった。

人はそれを青春コンプレックスと呼ぶ

そうだ。あれは間違いなく青春だった。青春映画だ。青春映画を僕は見てしまったんだ。
でもさ、ただの青春コンプレックスだとか、よくあるやつだとか、そういうことを言ってくれるな。そうじゃないんだ。

僕の人生は確実に劇的ではない。
そりゃあまあ人に言ったら驚かれるような体験談はあるし、笑いの種になるような話もいっぱいある。けれどそれはまあ日常の中の一つの出来事という枠から抜けることはない、人並みの「色々あった経験」だ。
劇的ってのはもっとこう、いちごパンツの女の子を追っかけてたら気付いたら自分のことを好きな女の子が四方八方にいてその狭間で揺れたりとか、幼い頃結婚の約束をした女の子が高校生になってからたくさんでてきて誰が本当にその相手なのかって探ったり、しゃーんなろーって言ってる女の子を好きになったんだけど気付いたら白眼の使い手と結婚したり、サイヤ人だったり、そういうやつだ。

劇的じゃなかったから劇的なものを見て羨んだり、素晴らしい青春じゃなかったから青春を見て羨んだりとか、そういう話をしているわけじゃないんだよ。
別に青春コンプレックスなど僕にはない。星新一も言っていたじゃないか。「青春とはもともと暗く不器用なもので、明るくかっこよくスイスイしたものは商業主義が作り上げた虚像にすぎない。」っつって。

つまりですね

僕はもう26歳なわけです。僕とか言ってる歳じゃないな…。

そんでね、もうこんな大人だから、高校生がわちゃわちゃする話を見ると仮に高校生のときに見た場合と比較したとすると、確実に何か余計なバイアスのかかった感想を持ってしまうわけですよ。

だから僕がさっきからうだうだ言ってるのを見てね、本当にただの青春コンプじゃないかと思うんだと思うんですよ。
でもね、そうじゃなくてね、僕が胸が痛いのはね、そういうことじゃないのさ。

ようやく結論にはいる

なんかこう、人生は劇的ではないし青春はもう送れないし、だけれどね、僕の心の中には劇的な何かだったり、いまでも青春できる何かが眠ってるんだと思うんですよ。
そこをね、チクチクと突いてきた。『君の名は。』のやつが。

あーー、疼く、僕の中にある情熱の炎が。疼く。血湧き肉躍る！
っていう、簡単に言うとそんな感じの感情がもうちょっとスウィーツな方向に寄った感じの、そんな気持ち。

あ、わかった

書いていて今ようやくわかった。
若干映画の内容に踏み込んじゃうので、冒頭でネタバレはしないって言ったので申し訳ないんだけれど、ほんのちょっとだから許してほしいのだけれど、「何かをずっと探している」みたいなフレーズがあって。

そいつだ。そいつがずっと僕の琴線をぐわんぐわん振り回してくるんだ。
探しているんだと思った。僕はまだきっと見つけられていない何かがあるんだなって。その探しているものが何かさえわからないのだけれど、きっと何かを探しながら人生を送っている。

それなりに幸せな日々を送っていて、それなりに楽しいことをライフワークとして続けることができていて、でも何か現状に満足できない渇きみたいなものがあるんだ。それはきっとみんな同じなんじゃないかな？知らんけど。

見つけたいという気持ちを強く揺さぶられた。だからこんなに胸を痛くさせられてしまったのか。

よし、決めた

僕は、走ろうと思う。
これは人生を謳歌するとか走り抜けるとかそういう比喩的なやつではなくて、物理的に走っていこうと思う。
我ながら何言ってんだって思うけれど、とりあえず今はひたすら走ってたら何か気づきがある気がしてならない。

『君の名は。』によって気づかされた僕の中に眠っている探しものには、走ったら近づける気がしてしょうがないのだ。

以上です。
最後に、今回の学びから僕が気付いた当たり前教訓は、「人生は自分の手で劇的にするものだ」ということでした。
こちらからは以上です。ではまた。

2016-08-27

エンジニアとしての今後の身の振り方を考える

Diary

転職活動をしていました

まだ現職の同僚でも伝えきれてない方もいるのでここで書くのも微妙なところなのですが、転職することにしました。
理由としてはひとえにスキルアップのためという感じで。

ここで言いたいのは転職するよって話ではなくて転職活動をする中で多くの気づきがあったよって話で。
色々な気づきがあったのでけれど、それを大きくまとめると自分の技術力は全然エンジニアとして通用するレベルではなかった、という。
そんなわけで今回の転職活動を機にエンジニアとしての生き方を考えなければならない状況になりました。

逃げとしてのフロントエンドエンジニアという言葉

バックエンドができないエンジニアのことをフロントエンドエンジニアと呼ぶわけではなくて、HTML・CSSでマークアップ書けてJSがちょこっと書けるようなエンジニアのことをフロントエンドエンジニアと呼ぶわけではなくて。
ていうか呼び方なんて実際どうでもいいんだけれど、自分はこれまで意気揚々とフロントエンドエンジニアを名乗って開発をしていたけれど、そこに世の中のフロントエンドエンジニアの方たちと同じように誇りがあったかは甚だ疑問が残るところで。

僕の中で無駄に肥大化してしまっていたフロントエンドエンジニアとしてのプライドは今回の転職活動で脆くも崩れ去ってしまって、改めて僕がやってきた開発に関して考えてみると、考慮すべき面倒臭い点をことごとく無視してきた自分の中途半端なソースコードの残骸が目についてしまった。

多分、作った先にいるユーザーの存在を、考えていたつもりでも全然考えきれていなかったから自己満足の開発で終わってしまっていたんだと思う。
かっこいいモダンな技術を使っている自分に酔っている場合ではなかった。

僕は個人で開発をするのがすごく好きで、これまで趣味開発で作ってきたアプリケーションでプログラミングについての学びを得てきた。
仕事の開発を適当にやってきたわけではないけれど、仕事の開発の中で学びを得ようっていう姿勢が薄かったのは事実かもしれない。
でも結局のところ、仕事だろうが趣味だろうが自分が開発しているものを使うユーザーのことを意識していたら、その2つには何も差はないはずで、そこが僕にはまだまだ足りなかった。

今後も変わらず僕は、個人の開発には重きを置いていこうと考えている。もちろん次の職場での開発への意識はこれまでとは全然違うものになる。
いずれにせよ、自分の作るものの先にいるユーザーをもっと意識していこうと思う。

自分でジャンルを定めるのは違うなっていう

フロントエンドエンジニアという肩書きを持とうとするのをやめようと思う。
結局クライアントサイドの開発をしていたって、バックエンドの実装の知識なしでは局所的なものしか作れないし、クライアント側のことを考慮できていないバックエンドの実装はくそだし、一つの領域でしっかりとしたものを作るには全体的な知識が必要になってくる。

そう考えたらできるエンジニアがフルスタックになっていくのは当然な流れなんだと今回の件でようやく気づいた。
あとは自分のJavaScriptへの異常なこだわりも、そこに論理的な整合性があるわけでもない以上、初めて手に入れた遊び道具への執着でしかないなと考えるようになった。その場その場での最適解を常に選択できるようになるためには、特定の技術に執着していてはいけないな、と。

とにかく今後は執着を捨てて、必要なものを必要なときに習得していくスタンスで勉強をしていこうかと。

まあそんな感じ。

2016-08-17

ここ最近の遊んだ話

Diary

海ほたるに行ってそしてシン・ゴジラを見てきた

初めて海ほたるに行ったんだけれどあれはサービスエリアだったんだな。
なんか盛大な観光地だと思っていた自分がいた。一つ知見を得た。

そして海ほたるついでに木更津で4DXでシン・ゴジラを見てきた。 4DXはやはり楽しい。水プシューが楽しい。映画自体もとてもよくてもう一度映画館行くのもありだなと思う。

ゴジラの実寸大足跡

海ほたるでわいわいしたあとにシン・ゴジラ見たのだけれど映画で海ほたる出てて高まった。だから実寸大足跡とかあったのか。

はじめてのコミックマーケット

コミックマーケット90に行ってきた。

コミケには以前から興味があったものの、その楽しみと同時にそのつらみの話もよく聞くのでそれを受容してまで行きたいだけの理由がこれまでなかった。
しかし今回は明確な行かねばならぬ理由があったので行ってみた、という話。

はじめてコミケにきたぞい！

目的はこれだい。

買ったぞい

TypeScript 2.0に対応しているということで丁度勉強しようとしていたのでタイミングよく行くことにした。
こういう技術本を作っているサークルもあるのかあーとまた一つ新たな世界を知った。

こんなもんです

いやだ、まだまだ夏を満喫するんだ。
こんなもんじゃ終わらないんだ僕の夏は。

2016-07-31

arrow function素晴らしいなって話

JavaScript

技術力を伸ばしたい

ここ最近自分の技術力の無さと、エンジニアになってからの2年半の間に全然最大限の行動と努力ができていなかったことを実感している。
そんなわけでどうやって技術力をつけていこうかってのを考えながら生活している。

方向性としてはいくつかあると思っていて、

まったく新しいパラダイムの勉強をする
別の言語の勉強をする
JavaScriptをさらに深くつきつめていく
流行り廃りの関係の無いITの基礎を勉強する

っていう4つに分けられそう。

まったく新しいパラダイムの勉強をする

例えば関数型の考え方を勉強したり、今までやってきたプログラミングとは違うアプローチの実装の仕方を学ぶことで、開発のアプローチの幅を増やすという方法がある。

ちょうどよくこの本を持っているのでやってみようかなと思っている。

JavaScriptで学ぶ関数型プログラミング

作者: Michael Fogus,和田祐一郎
出版社/メーカー: オライリージャパン
発売日: 2014/01/18
メディア: 単行本（ソフトカバー）
この商品を含むブログ (5件) を見る

別の言語の勉強をする

これは、エンジニアとして複数の言語を扱えるのが当然であるという前提のもとに、その前提にとりあえず到達することを目指す感じ。
一応仕事でPHPを触っていた時期があるってのと、RubyとScalaの基本構文だけは知っているという状況ではあるが、JavaScriptのように頭の中の設計をそのままコードにすらすらと落とし込むことは確実にできないし、現状一人の力でまともなものを作れる気がしない。

これも幅を広げるというジャンルに入る勉強方法だと思っている。が、現状優先度は低いと思っている。
挙げた4つの中では一番優先度を低く考えている。

JavaScriptをさらに深くつきつめていく

ここがとても大事だと思っていて、勉強方法としては「ひたすらGitHubをあさって他人のJavaScriptのソースを読む」、「色々な縛りを設けて(外部ライブラリ使用禁止etc)開発をしてみる」とかがある。

毎日時間を設定して上に挙げたようなことをやるってのを日課にすればちゃんと積み重なっていくと思われる。

流行り廃りの関係の無いITの基礎を勉強する

一番大事であるはずだけれどなかなか気合いが入りづらいのがここで。
1年近く前に、基本情報技術者試験を受けるためにその試験対策の勉強をしたのだけれど、あれは仕事で役に立っているかと言われればそんなことはないけれど確実に意味があったと思っている。

そんな感じでまた目標を作れば腰を据えてここらへんの勉強をできるかなと。とりあえず次は応用情報技術者を受ければ良いんだろうなとは思うけれど、まあ今のドタバタ(仕事周りで色々ある最近)が落ち着いたらって感じになってしまう。

そうやって後に後にまわしてしまうのがこのジャンルなので、やるやる詐欺だけは避けなければ。

はい、そんな感じで以上の4つを優先度つけつつバランスよく勉強していこうと考えています。

本題

そんなわけで最近はよくpaizaとかがやっているプログラミング問題とか見ると、じっくり眺めたくなっている。
そこでこんな問題を見つけた。

配列を引数に受けて、和を返す関数と二乗和を返す関数と三乗和を返す関数を作りなさい。

問題とともにいろんな人の回答がすでに載っていて僕が考える間もなく答えを見てしまったのでアレではありますが、美しいなあと思う回答もいくつかありつつもなんかまだつきつめられそうな気がするっていう回答ばかりだった。

そんなわけで良い感じの回答を拾ってそこから自分なりに色々手を加えまくって作ったのがこれ。

const sigma = f => array => [0, ...array].reduce((acc, current) => acc + f(current));
const sum = sigma(n => n);
const sqSum = sigma(n => n * n);
const cubeSum = sigma(n => n * n * n);

sum([1, 2, 3, 4]);  // 10
sqSum([1, 2, 3, 4]); // 30
cubeSum([1, 2, 3, 4]); // 100

関数を引数に受けて関数を返すsigmaという関数を作っていて、これが鍵になっている。
ちなみにこういうsigmaのような関数のことを 高階関数 と呼ぶらしい。

高階関数（こうかいかんすう、英: higher-order function）とは、関数（手続き）を引数にしたり、あるいは関数（手続き）を戻り値とするような関数のことである。

高階関数 - Wikipedia

問題に対する答えとしては、たった4行で作ることができた。ひとえにこれはES2015から実装されているarrow functionのおかげだ。
この回答をarrow function無しで実装すると以下のようになる。

const sigma = function(f) {
  return function(array) {
    return [0, ...array].reduce(function(acc, current) {
      return acc + f(current);
    });
  };
};
const sum = sigma(function(n) {
  return n;
});
const sqSum = sigma(function(n) {
  return n * n;
});
const cubeSum = sigma(function(n) {
  return n * n * n;
});

returnだらけだ…。
今更だけれど、arrow functionは単純なfunctionという文字の省略ではなく、「thisのbind」と「statementが一つだけの場合は波括弧とreturnを省略する」という構文です。

そんなわけでarrow functionのおかげでArrayのメソッドがとても書きやすくなったりする。
この回答もarrow functionのおかげであそこまで綺麗になった。

ちなみに#1

reduceの引数に渡す関数の引数は現在(acc, current)になっているが、最初は(pre, current)にしていた。
これを同僚に見せたところ、reduceに渡す関数の引数は(前の値, 今の値)ではなく、正確には(累積値, 今の値)であるので、preではなくacc(アキュムレータ)を使うべきということを言われた。

腹落ちしたのでそれに変更している。

アキュムレータ（英: Accumulator）は、コンピュータにおいて、演算装置による演算結果を累積する、すなわち総和を得るといったような計算に使うレジスタや変数のことである。

アキュムレータ (コンピュータ) - Wikipedia)

ちなみに#2

[0, ...array]という構文があってわかりづらいとは思うが、これはreduceの最初にaccに入ってくる値を渡された配列の一番最初の値ではなく、0にしたかったためだ。
そのために、渡されたarrayにいい番最初に0を結合している。
でないと、渡された配列の1番最初の値を2乗・3乗することができなくなってしまうので。

しかしこれには問題がありそうな気がして

確かに回答としては4行にまとまっているし、僕としては綺麗だなーと思うコードになっている。
けれど、sigma関数を定義する部分がぱっと見では多分何をしているかが伝わりづらい。読み取る側のスキルが求められるし、果たしてそれはチーム開発をする上で考えると良いコードと言えるのだろうか。

とか考えていたら何が良いコードなのかわからなくなってきた。
短いのは良いことだしかっこいいアプローチには憧れる。しかしわかりやすくなければチーム開発の障壁になるし、それは単純にみんながこれをぱっと見でわかるようになるべきって話にはならないと思う。

うーん、わからん。
これに関してはいろんな人の意見を聞いてみたい。

何か意見があれば教えてくれるとありがたいです。
ていうかそもそももっと良いコードにできるよ、とかの意見も待っております。

まとめ

今日はarrow functionの話になったけれどとにかく僕が言いたいこととしてはスキルアップしたいというそれだけなのである。
自分なりに考えたり友達に聞いたりして今は良い方法を模索しながら勉強している。

こういうやり方で自分は勉強してったよって話とかももしあれば教えていただけると嬉しいです。

こちらからは以上です。