お金を使うということ
画家もデザイナーもエンジニアも、社会の役に立つ仕事じゃないわけよ。自分の好きな事を仕事にしちゃってるわけ。医療や介護の仕事をしているような人に比べてね。だから「自分が自分が!」という傾向の人が多いし、日ごろから気を付けてないと一般の人から見て「クソ野郎だな!」とバレやすいのよ。
— Moritsugu Keiko 森次慶子 (@W_Fei_hung) July 11, 2018
このツイートを見てちょっと思うことがあったのでポエム.
この人自身も画家なので自嘲が入っていることも理解して.
そもそもに「仕事」って「世/人の役に立つこと」だと思う. つまり, 役に立たないならお金にならない.
今の時代, 「生きるために必要なもの」って大体飽和しちゃってて生活インフラや食物の供給なんていくらでもある.
じゃ何に人々はお金を払っているかというと, 「楽しいもの / 便利なもの」に払う. この暇で長い人生をどうにか楽しもうと,笑おうと, 自分が好きなもの,やってて楽しいものにお金を払い始めている.
YoutubeもTwitterもVRも生活の役には立たないけど, 人生を楽しむために開発されてる.
その感覚を持たないと,この先, お金が生まれる感覚って掴めないんじゃないかなと思う.
なぜヘッドホンのサイトを作りたいのかリストアップしてみる
- 自宅にいながら自分にあったヘッドホンを見つけることができるサイト
- 良いヘッドホンとの出会い
- 偶然の出会いを大切にしたい. 思ってもみなかった良いものに出会いたい
- 扱う在庫数の多さ, マイナーからメジャーまで
- まずは, 自分が持っているもの, ajitoにあるヘッドホンから撮っていこう
- 人が持っているものは借りてもいいかもしれない
- あとは, ビックカメラとかe-イヤホンで視聴
- 多分この作業がコンテンツ作りのコアになる
頭が痺れるような, 心を揺さぶるようなヘッドホンに出会いたい
届けたい人
- 使えるお金は限られているけど, 自分に合うヘッドホンを見つけたい人
- 地方に住んでいてなかなか視聴の機会を持つことができない人
良いヘッドホンを買ってみたいけど違いがいまいちわからない人
届けたい思い
- 偶然の出会いを大切にしたい. 思ってもみなかった良いものに出会ってほしい
- 頭が痺れるような, 心を揺さぶるようなヘッドホンに出会ってほしい
- 日常の1部分が非日常になるような体験を支えたい
eイヤホンいった感じだと若い層が多い?感じなのかな? きっとお金がないけど良い音で音楽を聞きたい人がいるんだと思う. 自分もその1人だったのでそれを支えられる, 助けられるサイトにしたいな
Reactの勉強会に行った
Reactとは
勉強会の講師
React とは
- Componentを作るだけ
- データの流れは単方向
- 仮想DOMを扱う
Component
再利用可能なパーツ Componentを作って組み合わせる JSXを使って行く
JSX JSの構文中にXMLをかける
propsとstate
props Component生成時に親から渡されるオブジェクト イミュータブル 外部とのインタフェース
state 動的に値を変化させられる Component内で管理
Componentのライフサイクル
https://qiita.com/kawachi/items/092bfc281f88e3a6e456
Redux
ReduxをつかうことでReactのComponentでは Stateを管理せずにpropsだけを使うようにできる
yarn
パッケージ管理ツール package.jsonで管理する
bable
ecmascriptのトランスコンパイラ ReactはES6で書く ES6はブラウザでそのまま動かない
webpack
アセットを生成するビルドツール 複数のソースを1つにまとめられる
flow
javascriptは動的かたつけ 静的型チェックできる
css modules
cssをComponentごとに持たせられるツール
create-react-appみてみる すぐにreact appのbootupできる
勉強法
公式チュートリアル 自分でちょっとアレンジ Reduxのチュートリアルやる
入門Reactを使用して輪読会 1人React.js Advent Calender 基本的なところが簡潔にまとまっている ライフサイクルの部分は常に見えるところに置いておくとよい
オープンソースにコミット 未マージだけど, 機能追加のコミットを試みた
オープンソースを読む Material-UI
実務での開発 / 実践が一番 手を動かすことが大事 他の人のコードも見れるので良い 教えてもらう
フロントは進化のスピードが早い はてぶ, qiita, SNSを毎日チェック
ランサーズの開発メンバーが書いたブログ公開中
- ランサーズ龍React.js/reduxアプリ開発入門
気づき
ポエムを書く.
このブログは技術ブログにしようと思っていたけど,
力が入りすぎて肩が凝るのと,
気が重くなって書く気になれないので考えてること書くためにも使おう.
120%の力を出す
人のツイートを見てふと気づいたことを書く.
革新的で、人々を幸せにして、世の中を前進させるようなプロダクトって簡単には作れないし、天才でなければ1人で作ることもできない。
— 桑原翔大 (@_skuwa) 2018年4月14日
だから、それぞれが120%のパフォーマンスを出して、組織として200%のパワーを発揮するような環境を作りたい。
よく120%の力を出すっていうけども, これってどういう意味なんだろう, と考える.
120%と聞くと 体壊すくらい頑張って他のこと捨てて必死こいてやる
みたいなイメージを受ける.
ちょっとブラックな思想.
実は そんなにハードルが高い, 高尚なことじゃなくて 今できないことをちょっと頑張ってやる
というシンプルな意味なのかなと思った.
わからないことが目の前にあった時に, 自分が今できることを元にちょっと強くなるのが120%の力を出すことになるんじゃないのかな, と.
無理すること = 120%じゃないのかもしれない
無理して傷ついてちょっと強くなるのが人間だと僕は思う.
でも, 誰しもむやみやたらに傷つきたいわけではないと思う.
そんな無理しなくていいじゃん, 楽しみながらやろうよと思ったりもする.
"本気で考えてもできないこと"ができるるようになった瞬間
= 120%の力が出た瞬間
なんだろうな.
その瞬間の120%がこれからの自分の100%になる.
無理せず楽しみながらわからないことを理解して行くほうが良いなと思えた.
コメントと名前付けの難しさ それに対して僕らができる防衛術
TL;DR
- 命名はプログラミングの中で重要かつ難しいタスクである
- コメントが出てきた時点で一考しよう. リファクタリングのチャンス
- 抽象化は慎重に
- 仕事を小さくすることで命名は比較的簡単にできる
- コードに残らない事情はコメントで表明する
あるslackの雑談から始まった
僕が属しているコミュニティであった雑談から.
ういろう [11:26 AM] 結構、コメント書くって難しいよね・・・ コメントと変数名は、プログラム書くより難しいんじゃないかって思ってる。 抽象メソッドにどんなコメントを書くかーみたいなことも今考え中。 okashoi [11:41 AM] 抽象メソッドなら入出力だけわかればいいんじゃないのかな > コメントと変数名は、プログラム書くより難しいんじゃないかって思ってる。 わかる。プログラミングするときに最も脳のリソースを消費するのは命名かなっておもってる(やや大げさ) ういろう [11:59 AM] > プログラミングするときに最も脳のリソースを消費するのは命名かなっておもってる(やや大げさ) わかる・・・ある程度テンプレートがあるとはいえ、 正解がコード書くより不明瞭で・・・ リーダブルコード読んでも、までこう書くといい!みたいなのがないから難しい (edited)
そう!
プログラミングにおいて 命名はかなり重要 & 難しいタスク だと思う!
今回は, 名前付けやコメントを書くときに自分がどのようにやっているか,
どのようにして名前付けをしやすいコードの書き方をしているか書いていこうと思う.
そもそも一般的に名前付けは難しいのか
ここは, プリンシプル オブ プログラミング から引用する
2.7 名前重要 コードで命名は最重要課題プログラミングにおいて、「命名」を最重要課題として認識し、慎重に取り組むようにしましょう。 「名前を付ける行為」、そして、それを経て生まれた「名前そのもの」、両方に重要な価値があります。 ・名前を付ける行為 適切な名前を付けられたということは、その要素が正しく理解されて、正しく設計されているということです。 逆に、ふさわしい名前が付けられないということは、その要素が果たすべき役割について、プログラマ自身が十分理解できていないということです。 適切な名前を付けることができたら、その設計の大部分が完成したと言っても過言ではありません。 ・名前そのもの 名前は、コードを通じて、プログラマ同士がコミュニケーションするための最大の場となります。 コードを書いた人と読む人が同時にその場にいて、「リアルタイムの会話」ができることは稀です。 たいていは「コードを通じての会話」となるので、名前が適切でないと、コード上の会話は成り立ちません。 このリアルタイムでないコミュニケーションを円滑にするため、名前には最大限の配慮がなされるべきです。
特に大事な部分をpick upする.
コードで命名は最重要課題プログラミングにおいて、「命名」を最重要課題として認識し、慎重に取り組むようにしましょう。
つまり, プログラミングでもっとも頭を使うのは「命名」と考えていいだろう.
上記に記したようにやはり命名は難しいのだ.
ではなぜ命名が難しいのか
ではなぜ命名が難しいのだろうか.
ここに関しては色々意見はあるのだろうが,
僕自身が考える一番の理由は
命名は設計の出来にかなり影響されるから
だと思っている.
...何が言いたいかというと...
名前付けが難しい = 設計がよくない
つまり, プログラマが名前をつけるのが難しい!!!
と感じた瞬間に,
設計を見直すべきだよー
というサインをコードが教えてくれているのだ.
適切な名前を付けられたということは、その要素が正しく理解されて、正しく設計されているということです。 逆に、ふさわしい名前が付けられないということは、その要素が果たすべき役割について、プログラマ自身が十分理解できていないということです。 適切な名前を付けることができたら、その設計の大部分が完成したと言っても過言ではありません。
例を見て考えてみる
命名(コメントも同様に)が難しいことはわかってきた.
じゃ, その難しさに僕たちはどのように立ち向かっていくべきか考えて行こう.
ということで雑談の続きを例に進めていく.
ちなみに, webアプリケーションの話をしていることに留意して欲しい.
コードはphpで書いていく.
ういろう [11:53 AM] ふむふむ。 ただ、変数名が意味を持ってしまうから、難しいところ。 最低限のコメントあったほうが良いのかなとか。 下のコードのようにやるとやり過ぎなのかなとか。
/* * htmlを表示させる */ abstract class exClass { abstract public function show(); } /* * データベースからデータを取得して、htmlを表示させる */ abstract class exClass { abstract public function show(); }
ういろう [11:58 AM] > プログラミングするときに最も脳のリソースを消費するのは命名かなっておもってる(やや大げさ) わかる・・・ある程度テンプレートがあるとはいえ、 正解がコード書くより不明瞭で・・・ リーダブルコード 読んでも、こう書くといい!みたいなのがないから難しい
ここまで読んでみるとなんとなく Controllerっぽい挙動を意図したmethodについて話していることがわかる. 読み解ける情報を列挙して行こう.
- showというメソッドでhtmlを表示したい
- showメソッドに対して
htmlを表示する
という役割をコメントで表現しようとしてる - 抽象クラスとして宣言することでいろんなところで使いたい
1つずつ見て行こう.
1. showというメソッドでhtmlを表示したい
まずは, メソッドの役割を明確にしたい.
名前付けにおいてメソッドや変数の役割を日本語で明確に定義する工程
は有効である.
なぜならば, 名前付けをする際には名前をつける対象をよく知る必要があるからだ.
日本人が生まれたての女の子に太郎
と名付けないように, 名付けられる対象が持つ特徴や置かれたプロダクトの文化, コードの文脈を理解して初めて名前をつけることができる.
先ほどのコメント htmlを表示する
という表現は不明瞭さを含んでいる表現である.
viewとしてhtmlそのものを表示する
役割を担っているのか,
controller内の1つのActionとしてhtml形式でresponseを返す
のか,
CLIにhtmlを表示するdumpメソッド
なのか(多分こんなことはしないけど),
メソッドが担う役割を明確に示す必要がある.
ここでは, controller内の1つのActionとしてhtml形式でresponseを返す
という文脈で話を進めていこう.
一般的にはController内のエンドポイントをAction
と表現するため, showAction
という名前付けが妥当に思える. (もちろん, プロダクトの文化や一貫性にもよるのでshow
という名前もなくはないし, Controllerの中で宣言されていればそれはきっとActionだろう)
showAction()
のように明確にhttp responseを返しそうな名前付けをすると役割が明確になる.
明確に役割を定義することは名前付けを手助けするのである.
2. showメソッドに対して"htmlを表示する"という役割をコメントで表現しようとしてる
showAction
のような名前付けを行なった結果, http responseが返ってきそうなメソッドとして扱えるようになる.
では, もう一度コメントを見てみよう.
- htmlを表示させる
- データベースからデータを取得して、htmlを表示させる
どちらもhtmlを表示させる
ことを意識したコメントである.
showAction
という名前からhtmlをresponseとして返してくることは容易に想像できると思う. 名前が自分の役割をはっきりと表明していれば, メソッドに対してコメントを書く必要はないのである.
業務委託でいらっしゃっている@t_wadaさんが
コメントが出てきた時点でリファクタリングチャンス
とおっしゃっていた.
コメントを書いた時点で一度立ち止まり設計や命名を考え直すべきだろう.
下にサンプルコードを書いてみるが, おそらく読みやすさはそれほど変わらないと思う.
abstract public function showAction(); /* * htmlを表示させる */ abstract public function showAction();
実装に語らせる
あとは, 実装に語らせるという方法も取れる.
これは変数の命名で役割を明確にする方法である.
例えば, showAction
が返しうる値がhtml
, json
, array
の3種類だったとしよう.
この場合, 以下のように実装すればコメントは不要となる.
// jsonを返すパターン public function showAction() { $json = createJsonResponse; return $json; } // htmlそのものを返すパターン // 多分あんまりない public function showAction() { $html = createHtmlResponse; return $html; } // テンプレートにレンダリングするパラメタを返すパターン public function showAction() { $response = []; $response = createResponseParams(); return $response; }
リーダブルコードにもあるが, 変数名は短いコメント
と考えておくことが大切である.
メソッドと変数に対して正確に役割を示す端的な名前をつけておくことで, 名前に役割を説明させることができるのである.
これによって必然的にコメントは減っていく. コメントを減らすことでメンテナンスコストが下がるのも嬉しい部分である.
3. 抽象クラスとして宣言することでいろんなところで使いたい
抽象化(abstract), 実はこれも難しい.
これは命名とは別の話であるが,
実際早すぎる抽象化は命名を難しくすることもあるので触れておこう.
DRY (Don't Repeat Yourself), 同じものを繰り返すな
という有名な言葉がある.
これに素直に従うと抽象化
を急いでしまう.
実はこれも慎重に行うべきで, 早すぎる抽象化
は負債化することがある.
YAGNI You ain't gonna need it: 実際に必要となるまでは追加しない
とも呼ばれるが, 同じようなパターンが出現していない時点で想像で抽象化を行うと使われず, いじりにくいコードとなり負債化する.
同じような実装が3回,4回登場した時点で抽象化を始めても遅くはないのだ.
例えば, 2. showメソッドに対して"htmlを表示する"という役割をコメントで表現しようとしてる
で示した例のように同じような役割で少しだけ実装が違うようなものが3回, 4出現した時に初めて抽象化を考えればいい.
@t_wadaさんとペアプロした時におっしゃっていた言葉を引用しよう.
共通化は2out, 3outしてから考えていい. 1回目で共通化しようとしても将来生まれる需要と食い違って使われないことが多い. 2,3回, いや, 3,4回くらい同じコードを見てから共通化しても遅くない.
設計として正しくない場所に抽象化した概念を置いてしまった場合,
無理に抽象概念を使いまわそうとすると設計に歪みが生まれる.
これによって, 役割が複雑になってしまい命名が難しくなる.
このような副作用もあるため抽象化は慎重になるべきである.
命名の難しさへの防衛術
つらつらと述べてきたように, 変数やメソッドの名前がうまく決まらない(コメントが必要な程度に複雑さを持っている)場合は変数, メソッドの場所がおかしい/役割が多いことを示している. なのでコメント書いた時点で一旦考えてよいとおもう.
では, どのようにしてその複雑さや難しさを回避していくか.
3つの手順を踏むことでその難しさを軽減することができる. ここからは, コードで示しながら進めていく.
これは大きなメソッド(多分こういったメソッドにコメントが生えがち)をリファクタリングするときに使える手法である.
1: まずはやりたいメソッドをべたっと1つのメソッドに書く(もしくは最初からある)
class exController { // requestを受けて新規データを作成する public function createAction($request) { process1 process2 process3 process4 process5 process6 process7 process8 return process9 } }
2: メソッドの処理を役割ごとにブロック化してそれぞれにコメントをつけていく
class exController { // requestを受けて新規データを作成する public function createAction($request) { // request parse する process1 // requestのvalidation process2 process3 process4 // requestからentity作る process5 process6 // ORMにentity登録してdbにinsert process7 process8 // response返す return process9 } }
3: コメントごとにmethodに切り出す
class exController { public function createAction($request) { $req = parseRequest($request) validateRequest($req) $entity = createEntityByRequest($req) insertEntity($entity) return process9 } } public function parseRequest($request) { return process1 } public function validateRequest($request) { process2 process3 return process4 } public function createEntityByRequest($request) { process5 return process6 } public function insertEntity($entity) { process7 return process8 }
実コードでこのやり方を実践すると, きっと初期状態よりもずっと追いやすく読みやすいコードになるだろう(この例だと初期状態が複雑に見えないためメリットを感じづらいが, やってみると効果が実感できると思う)
上記のようなフローでコード書くと, 以下のような良さがある
- まずべたっと1枚岩でコードを書くことで処理の流れをそのまま表現でき書きやすい
- 分割した後はメソッドの役割がシンプルになり命名しやすい
- メソッドや変数の仕事が少なくなるため役割がシンプルになる
- その結果, 副次的に命名がしやすくなる
- 各メソッド, 変数の役割や仕事が小さくなるため状態管理が楽, かつ, 汎用的になる
- メソッドの使い回しが効くようになる
- 変数のスコープが小さく, 状態管理が楽なのでテストしやすい
- 参照透過性も守りやすい
コメントを書かなければならない場合もある
コメントを書かなければいけない場合もある.
これはコードでは表現できない事情や背景
がある場合である.
これらはコメントで残さなければ後に残っていかないため, コメントに残すべきである.
パフォーマンス上の制約でしぶしぶ選んだ選択や事業的な理由など, コードそのものでは示せないものはコメントに残すべきである.
裏返せば, コードを読めばわかることはコメントに書くべきではない ということを示している.
コメントを書いた時点で立ち止まる癖は付けても良いだろう
まとめ
- 命名はプログラミングの中で重要かつ難しいタスクである
- コメントが出てきた時点で一考しよう. リファクタリングのチャンス
- 抽象化は慎重に
- 仕事を小さくすることで命名は比較的簡単にできる
- コードに残らない事情はコメントで表明する
Fluxとは何か MVC, MVVMとの違いも含めて
動機
仕事で, React + Redux + TypeScirpt + WebPack
を使うことになりそうなので学んでいく.
そもそもjsに疎いので探り探りやっていく.
間違えもあるかもしれないが, 徐々にやっていこう.
TL;DR
- Fluxとは, アプリケーションのデータフロー管理のためのアーキテクチャパターン
- イベント駆動であり, 一方向のデータフロー制御を行う
- Fluxの特徴は,
Viewで独立したデータを持つ
,データ状態を一方向のフローで制御
,Event駆動
である. - Fluxは
Action
,Dispatcher
,Store
,View
の4要素で構成される.
Reduxとは
Reduxとは, Facebookが提唱, 開発しているJsApp.
jsにおいて, データの状態(データの流れ)を管理するためのツールである.
ReduxはFluxの実装と聞いたことがあるので, Reduxの前にFluxについて学んでいこう.
FluxもFacebookが提唱しているアーキテクチャである.
Fluxとは
FB公式から抜粋
Flux is a pattern for managing data flow in your application. The most important concept is that data flows in one direction. Fluxとは, アプリケーションのデータフロー管理のためのアーキテクチャパターンである. もっとも重要なコンセプトは`データフローが一方向にしか流れないこと`である.
JavaScriptでWebページのデータを制御する際に, データの状態制御が複雑になりやすい.
Fluxはデータの流れを一方向に限定することで状態遷移を単純にし, データ状態の複雑さを軽減させようとする考え方である.
あくまでも考え方なので, 実装は伴わない.
RESTの実装がHTTP
のように, Fluxの実装がRedux
という関係性なのかなと想像している.
Reduxの源流なので, Fluxから追っていこうと思う.
Fluxのアーキテクチャ
図をみると, 4つのパーツから構成されていることがわかる.
- Dispatcher
- Store
- Action
- View
データは必ず以下の動作で変更されていく.
- 何らかの
Action
があり(Apiからのレスポンス, ViewEvent),Dispatcher
がその全てを受ける. Dispatcher
がStore
にAction
を伝搬.Store
は,Dispatcher
から受けたAction
によってデータの状態を変更.change event
を発火する.Store
のデータ状態がView
に渡される.change event
でトリガーされる.View
がStore
から受けたデータを表示.View
で何らかのAction
が発生. 1に戻る.
store
は必ずしも1つではなく複数個持てる.
todoアプリであれば, 未消化タスク
, 消化済みタスク
でstore
を分けることが可能である.
Fluxとはなんなのか より引用
Fluxのなにがいいのか
Fluxとはなんなのかより引用するが,
Fluxを導入すると以下のメリットがあると言える
- ViewにEvent(Action)の発行元だけ持たせ, App全体をEventDrivenにした
- Storeに状態や副作用を集約したことで, そこ以外では参照等価になった.
- これにより, App全体の見通しがよくなった
個人的にまだよくわかっていないこと
MVC, MVVCとの違い
正直, MVC(Model/View/Controller)との違いがそれほど大きくわかってない. MVVC(Model/View/ViewModel/Contoller)もそうだが, Viewの中の話でほぼ終始しているような気がする.
一回整理してみよう
MVC
MVCについて振り返る. at-grandpa.hatenablog.jp より図を引用.
View
はModel
の状態を参照しているだけ.
View
はあくまでもModel
の状態を表示しているだけで, ユーザの入力はController
を伝ってModel
で処理されデータの状態が変化する.
サーバサイドレンダリングで作ったページを思い浮かべると良さそう.
View
の中でデータの状態そのものは気にせず, ユーザの明示的な操作(formのPOSTなど)としてフォームの値が渡ってくるイメージ.
(View
の中でformデータなどの状態はあるがDOMで閉じる)
MVVM
qiita.com より図を引用.
MVC
の場合は, View
がModel
を直接参照していた.
MVVM
では, View
とModel
の間にViewModel
という中間層を置く.
View
はViewModel
の状態を参照し,ViewModel
は常にView
の入力を監視する.View
に対する入力(Event
)があれば, 即座に検知してViewModel
の状態が変わる.- 逆に
ViewModel
の状態が変わればView
の表示が変更される.
これを, Two-way data Binding
と呼ぶ.
Modelの状態変更は, ユーザの明示的な操作(formのPOSTなど)によって行われる.
このとき, ViewModel
の状態がModel
に反映される.
この図には, Controller
が存在しないが Model
とViewModel
の間にControllerがある.
言い換えれば, MVVMC
となる.
Flux
Fluxの場合は, 上のような図になる. MVCと比較するためあえてMCを書いている.
Fluxは Fluxのアーキテクチャ
で述べた通り, データフローが一方向に制御されるコンセプトを持っている.
こうやって見てみると, MC
とV
で明確な境界線がある.
View側で独立のデータ
を持ち, データ状態の制御だけに関心をあてているのがFluxである.
Viewで独立のデータ構造をもつアプリケーション, と考えてしまえばMVVMとそう変わらない
MVVM
と比較すると, ViewModel
がStore
となり, データの方向制御のためにDispatcher
が登場したという形になる.
Fluxでは, Event
をAction
と呼ぶためここは同義として見て良いだろう.
MVC, MVVM, Fluxの違い まとめ
こうやってMVC
, MVVM
, Flux
を同じ構成で見てみると,
実はどれもMVC
の延長線上にあることがわかる.
というか, そもそもVIewのデータフローアーキテクチャなのでMCとは関係ないものである.
そもそも関心ごとが違うので比較するまでもなかった.
MVC
とMVVM, Flux
で大きく異なるのは, View側にサーバ(Model, Controller)とは独立したアプリケーションがあり, Viewで独立したデータ状態を持つ/制御する
ことであろう.
ここさえ理解すれば, MVVM
, Flux
はあくまでもデータフローが双方向か一方向かの違いしかないことに気づける.