タオルケット体操

サツバツいんたーねっと

プログラマーは業務時間外でも勉強すべきかどうかについて

そんなことを考える暇があればスプラトゥーン2やろ

マジレスすると

  • 「プライベートでもプログラミングするくらい好き/ではない」
  • 「業務時間外であっても勉強すべきだと考えている/いない」
  • 「優秀なプログラマーである」

は相関があるようでそれぞれ個別の問題なので分けて語った方がよいかとおもいます。

一番の人は優秀である確率が高いですが、こういった人が普段している活動は

  • 仕事ではまだしばらく使えないようなエッジの技術を試す
  • 仕事では避けるようなマニアックな技術で遊ぶ
  • 自分でサービスを作って運営する

などで、これらの活動によって「流行ったばかりの技術を軽々使いこなす」「コーディングテクニックがすごい(語彙力)」「一人でサービスローンチまで一通りできてしまう*1」というようなスキルが身につく(つかないこともある)わけです。
ですが、こういった"活動"は「業務時間外でも勉強すべき」という軸足が仕事にあるようなタイプの人間はまずやらないことなのです。

反面、軸足が仕事にある族の人たちがする勉強は業務をスムーズに遂行するためのものなのでムラがなく、成果に結びつきやすいものであることが多いです。でも資格だけは勘弁な。

プログラミングが趣味族の人間は誰も知らないようなことを知っていたり、突然すごいパフォーマンスを叩き出したりする一方で、つい我を忘れて暴走したり、仕事という窮屈なしばりでするプログラミングが退屈すぎて反乱を起こしたりする扱いにくさを持つ傾向にあります。
あとプログラミングはただの趣味で義務感などは存在しないため、スプラトゥーン2などの等価な楽しみが出現するとそちらに突っ走ったりします。
個人的な意見です。

最後の優秀さについて。
効率よく云々の話はありますが、スキルというのは概ね勉強している時間に応じて伸びるものです。そして先述したように趣味活と業務向けの勉強はベクトルがかなり別の方向を向いています。
してる、していない。すべき、すべきでない。などを論じるのも良いですが、例えば経営者の方などであれば自分がどういう人間を欲しているのか分析した上で採用をすると
「あいつプライベートでも勉強してるっていってたのに全然使えないんだけど」
といってしまうような不幸なすれ違いを防げるんじゃないかなとおもいました。

ちなみに仕事中以外なにもしてなくても優秀というチートっぽい人も中にはいますが、ソフトウェアエンジニアリングという領域は求められる知識がそもそも膨大なので、四次元殺法的な引き出しの多さはやはり趣味活によってのみもたらされるものでしょう。というわけでこういった人たちは仕事軸足族よりのスキルセットであることが多いです。
それとは別に仕事中であっても勉強しない人がいますが、そういう話は不毛なのでやめておきましょう。

じゃあ自分スプラトゥーンあるんでこれで。

フレンドコード: SW-0963-2705-5306

*1:非ITエンジニアの人が考えるフルスタックはこれです

Reduxバリデーション実装パターンとReducerの呼び出しを遅延させたい問題(debounced-action-dispatcherを作りました)

アイデアです。
ちなみにredux-observableやredux-sagaを導入している場合はそちらで解決したほうが良いんじゃないかとおもいます。

f:id:hachibeechan:20170714180530p:plain

MVXアプリケーションのバリデーションとパフォーマンス問題

Reduxを使っていなかったとしても、Reactを使って素朴にアプリケーションを開発しているとある程度以上の規模になって発生するのがバリデーションのパフォーマンスではなかろうか。

最初は一つのinputに対応するプロパティの正当性を素朴に判断するだけだったのが、ある程度の規模になった時点で同一モデルの他のプロパティも一緒に合わせてみなければいけなくなったり、あるいは他のモデルの面倒もみないといけなくなったり。 そのうちに、あちこちに散らばっていたバリデーションのロジックを一箇所に集めたくなる。それが終わったら次はパフォーマンスの問題だ。Facebookのアプリケーションなどを使ったことがある人はわかるだろうが、textboxで一文字入力するたびに画面がプチフリーズするうえ、ボタンを連打しようものならしばらくブラウザが固まってしまう。Facebookのアレはバリデーションの問題だけではないのだろうが、無関係でもないだろうとおもう。ともあれ、ユーザーの連続入力が終わるまでバリデーションを待機して別に悪いことはないだろう。

ここで問題になるのは、一体どこの関数呼び出しをdebounceするかという問題だ。

“純粋"関数縛りがあるのでreducerはなし。となるとActionCreatorかCallbackということになるが、ただでさえThunkやなんかのせいでカオスになりがちなActionCreatorにこれ以上余計なボイラープレートを噛ませたくない。 Callbackだが、例えばActionCreatorが常にPromiseを返すようにして終了を監視するようにすればあるいはバリデーションの非同期な呼び出しは可能かもしれないが、明らかに責務の範囲外で筋悪な実装のようにおもえる。

やはりActionをObserveしているReducerが、Storeへ引き起こす変更を検知してバリデーションを行うべきなのではないか。ですよね?

そこでMiddleware(redux-debounced-action-dispatcher)

実はReduxの各層においてActionをObserveしているのはReducerだけではない。もうひとつMiddlewareでも同様のことが可能だ。 (ReduxのこれはMiddlewareというにはなんでもかんでも実装可能すぎてどうなんだろうという気持ちがないでもない)

というわけで作ってみた。 https://github.com/hachibeeDI/redux-debounced-action-dispatcher

サンプルにあるように、TRIGGER_ACTIONSにバリデーション(あるいはLocalStrageにキャッシュするとか)のキーとなるようなActionを宣言して、DEBOUNCED_ACTION_TYPEにそれを受けて発行させたいActionを宣言刷るだけというような使い方になる。

import createDebounceMiddlewareGenerator from 'redux-debounced-action-dispatcher';


const TRIGGER_ACTIONS = [
  'HOGE_CHANGED',
  'FOO_CHANGED'
];

const VALIDATION_DEBOUNCE_TIME = 500;

export const DEBOUNCED_ACTION_TYPE = 'VALIDATE_ALL_DATA';

const debouncedValidationDispatcher = createDebounceMiddlewareGenerator(
  TRIGGER_ACTIONS,
  DEBOUNCED_ACTION_TYPE,
  VALIDATION_DEBOUNCE_TIME,
);

const store = createStore(
  todoApp,
  applyMiddleware(debouncedValidationDispatcher)
);

使いこなせるメンバーで構成されているならばredux-observableやredux-sagaなどが導入するEpicなんかで解決すればいいだろうが、これら2つのMiddlewareはそれなりに難解で、かつオーバーキルな印象がある。
僕の作ったMiddlewareの利点は簡単なことで、欠点はそもそもredux-actionsなしではカオスになりがちなActionの管理だが、TRIGGER_ACTIONSが膨れ上がるとさらに意味不明になってしまうことだ。これは例えば正規表現のサポートを実装して、各アプリケーション内で厳格な命名規約を導入すれば防げるかもしれない。

まとめ

ReduxでSPAのエラー情報の管理を一体どうやっているのかの話をあまり見かけないので僕なりの考えを書いてみた。

たぶんもっといい方法があるだろうとはおもうので教えてくださいお願いします。

今ブログを書きながらふと思いついたが、そもそもエラー情報をReduxのStoreで管理するのはやめて、例えばreselect(https://github.com/reactjs/reselect)を使うようにするなんてのもありかもしれない。その場合、debounceは不可能になるがmemorizeしてくれるのでパフォーマンスへの影響も多少軽減できるのではないか。

まとまりがないけどもこちらからは以上です。

2017年現在の汎用的なJavaScriptの補完環境についての雑なまとめ(Vim濃度高め)

  • 結論
  • 今に至るJavaScript補完プロジェクト(オープンソース)の流れ
  • 各種実装とVimの状況について
    • Ternjs
    • Salsa
    • LSP実装(javascript-typescript-langserver)
      • javascript-typescript-langserverの.tern-projectにあたる設定
  • まとめ

書きなぐりだよ。

結論

諦めが肝心(とりわけVimmer)

続きを読む

試行錯誤を経てMacからLinuxへの移行が完了した

ここしばらく、Macのいいところが薄れ、初期不良やOSの不安定さなど悪い点が目立つようになっているからなのかなのか、あるいはMacBookのパクリにとどまらないラップトップが増えつつあるからなのか、徐々にMacをやめてLinuxへと移行するプログラマーが出てきたようにおもえる。 僕としてもAppleが見ている方向性などについて色々と考えていたこともあり、ぼちぼちMacの次の選択肢をみつけたほうがいいかなと考えていた。そんな折に会社のマシンを買い換える機会があり、Dockerを使っていることや移行コストに関わる自身の生産性などを考えて(最近クールなWindowsも検討したのだが)Linuxを会社のメイン環境にすることに決めた。

僕がMacで主に使っていたアプリケーション

  • iTerm2

  • Vim(Neovim)

  • GoogleChrome

Macである必要なくね? とよく言われていたが、まぁ概ねその通りで僕が数年前にLinuxからMacへ移行した理由はいちいちOSをインストールしてから環境設定をこまごまやっていくのがめんどくさかったからというのと、フォントがキレイだったからだ。
なので昔の環境に戻るのに大した苦労はないとたかをくくっていた。

LinuxデスクトップはMacOSと比較していいクオリティではない

続きを読む

共通化という考え方はアンチパターンを生み出すだけ説

共通化を指針にするのはおすすめできない

「共通化」というワードはプログラマーであれば誰しもが一度は聞いたことがあるだろう。そしてもうひとつ、それと対称であるかのように語られるのが「コピペは悪」だ。
ここで僕が異議を唱えたいのは共通化を善とする教義についてだ。世間的に共通化を良いものだとする風潮があるようなので石を投げるために書き殴ろうとおもう。

続きを読む