Sphereとともに

scalaとかplayframeworkとか。技術ブログにしたいなと。環境は Windows7x64, mac です。たまに声優さん情報が混ざります。最近ちょっとClojure触りました。

npm runとはなにか

package.jsonに記述しているscriptsに定義されたタスクを実行させるためのコマンド

npm run {scriptsに定義されたタスク名}

という感じ

例えば以下のような定義があれば

// 略
"scripts": {
    "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  }
// 略

npm run dev と叩くことでタスクが実行される

WebRTCをいろいろ調べてまとめてみた

www.slideshare.net

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

B to Cサービスの難しさとその崩壊 - ビジョンを失うということ -

夢に満ち溢れた初期

初期段階は、サービスを作って誰かの役に立つこと、社会へのインパクトを夢にサービスを作りはじめる

その夢が正しいかどうかわからない

だからいかに早く市場へ出すかに注力する

多少汚いコードであっても、後々に負債になることがわかっていても

この時のファースト・プライオリティはサービスを世に出す事である

市場に受け入れられるか受け入れられないかがわからないものに時間と金をつぎ込み続けるのは愚かである

少人数のメンバーで全員がそれを理解してスピード感を持って開発に臨む

どんなに大変だったとしてもそこには希望がある

社会のために

世の中をより豊かにするために

自らの手でイノベーションを起こすことへの高揚感にあふれ

世界の革新を胸に秘めて

ローンチ

ある程度形になった段階でローンチされるサービス

まだまだ未熟ではあるが、その思想や未来に期待したイノベーターが付く

顧客は契約の段階では、思想や未来に胸を膨らませて契約を行うが

いざ業務において使い始めると、不足していることがたくさん目についてくる

すると、はじめは要望として様々なものがあげられてくる

開発者たちは自分たちの目指す思想・未来と照らし合わせて

取捨選択を行い

時には大胆な方向転換を行う

初期段階は少人数での開発であり、コードもまだまだ少ないためそれほど難しくはない

顧客の増加と売上

様々な要望を取り入れていくと、細かい部分では気になるところはあるものの

大枠では使えるサービスが出来上がってくる

この頃にはアーリーアダプターもそこそこの数になり

アーリーマジョリティが付いてくる

そうなってくると、このサービスはどんどん伸びていくものであると経営的判断がなされる

すると何が起きるか

急速な人員の増加と、売上伸長へ意識偏重

エンジニア、セールス問わず急拡大が行われる

新規採用・他部署からの異動

人を集める方法はいくらでもある

急速な組織の拡大

少人数で壮大なビジョンを掲げて開発して来たところに

急な転換

なにが起きるか

少人数で図れていた意思疎通ができなくなる

コードが崩れはじめる

初期メンバーはどこが負債になるかを理解しているし

なぜその負債が生まれているかは十分な理解をし共通認識として受け入れている

けれども、急拡大にて配属された人にはそういった共通認識もない

目にするのは人の手垢まみれのコードだ

そこに思い入れはない

そうこうしているうちに別の新規事業立ち上げで初期メンバーは引き抜かれていく

残るのはほんの一握りの初期メンバーと、出鼻を挫かれた途中入場のメンバーだ

途中入場者は初期メンバーの残した負債に苦しむことになる

負債に足を取られながらも売上を上げるために

開発スピードを落とさないために努力する

しかし、そこには行き場のない怒りと虚しさがある

途中入場者も初期メンバーの残した負債の理由を理解できるからだ

理解できるからこそ、その怒りの矛先をどこに向けることも出来ず

苦悩する

徒労でしかない

コードに限界が来たときに

大きなテコ入れをしようとしたときに

どれほどのメンバーが快く手を挙げるだろうか

売上伸長

売上を伸ばすためにトップが変わる

どんなにエンジニア経験のあるトップであって

エンジニアの心を理解しようと努めても

経営層から売上を求められている以上、思いはどうしても売上へ変調し偏重する

そして次第に

壮大なビジョンは失われる

そのトップにとっては、今自分が抱えているサービスの売上を伸ばすことがファースト・プライオリティだから

最初のビジョンがどうあろうと関係ない

最初のビジョンを理解していたとしてもそれを推し進めるだけの推進力はない

なぜなら最初からそこに携わっていないからそのビジョンに対する熱量がない

その熱量の違いから何が起きるのだろう

顧客が求めるものを作り続けるだけの日々

ときに自らの発想でものを作るが続かない

もどかしい

誰のための

一体、誰のためなんのためにサービスを作っているのか

組織の急拡大に向けて採用された人物は

少人数でやっていたころのビジョンやその組織のあり方に突き動かされて来た人たちばかりだ

それがいざ足を踏み入れるとそこにはあの頃の輝きはもうない

見えない敵と戦う日々

暗闇でもがく日々

崩壊

少人数でのマネジメントは大人数には使えない

破壊して構築しなおすか

構築し直すだけの希望はパンドラの箱に残っているだろうか

夢見るその先は

エンジニアはものを作ることがゴールではない

その先になにを夢見るのか

www.youtube.com

www.youtube.com

Elixir ecto の自動生成IDをUUIDにする

blog.fourk.io

プログラミングElixir

プログラミングElixir

Elixir/Phoenix 初級?: はじめの一歩 (OIAX BOOKS)

Elixir/Phoenix 初級?: はじめの一歩 (OIAX BOOKS)

さて、ここで問題です。(将来推計人口をもとに)

愛知県に岡崎市という中核市がある。

岡崎市 - Wikipedia

平成29年12月1日現在の人口はおよそ38万人 岡崎市/統計ポータルサイト

岡崎市を独立採算制として、将来推計人口をもとに未来を少し考えてみる。

データの元はここ 日本の地域別将来推計人口(平成25(2013)年3月推計)|国立社会保障・人口問題研究所

男女5歳階級別データ- 日本の地域別将来推計人口(平成25(2013)年3月推計)|国立社会保障・人口問題研究所

【前提事項】

物事をすごく単純にするために高齢者(65歳以上)は年300万円を必要とする

税諸々も考えない。

収入はすべてその人のものとなり、そのなかでやりくりをする。

高齢者は一切の収入が無いものとし、15歳~65歳を労働力人口とする。

労働者の平均年収は600万円で推移しないものとする。

【2010年の負担】

2010年は 18%が高齢者なので、100人いたら18人が高齢

労働力人口は66.6%なので100人居たら67人が労働者

労働者の平均年収が600万円とすると40,200万円(67 x 600)が全体の収入となる。

高齢者は18人いたので、高齢者が必要とするお金は5,400万円(18 x 300)

5,400万円 / 67人 ≒ 80万円 が一人あたりの負担金

80 / 600 ≒ 13% が負担率

高齢者を支えるだけで収入の約13%

労働力人口の人たちは520万円程度は自由に利用できる。

【2040年の負担】

2040年は31.7%が高齢者なので、100人いたら32人が高齢

労働力人口は56.4%なので100人居たら56人が労働者

労働者の平均年収が600万円とすると19,200万円(32 x 600)が全体の収入となる。

高齢者は32人いたので、高齢者が必要とするお金は9.600万円(32 x 300)

9,600万円 / 56 人 ≒ 171万円 が一人あたりの負担金

171 / 600 ≒ 28.5% が負担率

高齢者を支えるだけで収入の約28.5%

2010年から2040年に移ると負担の割合は約15.5ポイント上昇する。

労働力人口の人たちは434万円程度は自由に利用できる。とは言っても100万円近く利用できるお金が減っている。

さて、この計算には0~14歳を含めていない。

0~14歳の人数は減っていく一方なのでそこにかかる"負担は"軽くなるので大した問題ではないだろう。

一方で労働力人口が減っていくので自信の首を締めているのに代わりはない。

現在進行形で真綿で首を絞めている状態

どうやって今の暮らしを続けていく?

(※ いろいろ数字いじって試したのでどこかで数字がおかしくなってるかも)

LIFE SHIFT(ライフ・シフト)

LIFE SHIFT(ライフ・シフト)

Elixir Phoenixのドキュメントを読み漁る Routing

Routing – Phoenix v1.3.0

use HelloWeb, :router と書いてRouterであると宣言している感じ

get とかは match/5 なマクロで、ほかにも POST, PUT, PATCH, DELETE, OPTIONS, CONNECT, TRACE and HEAD. があるよ

最初の引数はpath、2つめは処理をするController

複数のルーティング定義をした場合は上から順に見ていって、マッチした部分で処理を終了する

resources というのを使うとちょっと楽ができる

resources "/users", UserController とするだけで、

user_path  GET     /users           HelloWeb.UserController :index
user_path  GET     /users/:id/edit  HelloWeb.UserController :edit
user_path  GET     /users/new       HelloWeb.UserController :new
user_path  GET     /users/:id       HelloWeb.UserController :show
user_path  POST    /users           HelloWeb.UserController :create
user_path  PATCH   /users/:id       HelloWeb.UserController :update
           PUT     /users/:id       HelloWeb.UserController :update
user_path  DELETE  /users/:id       HelloWeb.UserController :delete

と解釈される。

もちろん only とか except で必要なものだけに絞ることもできる

forward を使うと他のPlugに処理を渡せる

パスヘルパーもあるよ

resource のネストもできる!便利だ

スコープ付きルートも定義できるよ scope "/admin", as: :admin do とか scope "/admin", HelloWeb.Admin, as: :admin do みたいにね

ところで pipe_through :browser ってなんだ?

https://hexdocs.pm/phoenix/routing.html#pipelines

ぐぐってたらいいまとめがあった

qiita.com

プログラミングElixir

プログラミングElixir