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
ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化
- 作者: Ilya Grigorik,和田祐一郎,株式会社プログラミングシステム社
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/05/16
- メディア: 大型本
- この商品を含むブログ (3件) を見る
B to Cサービスの難しさとその崩壊 - ビジョンを失うということ -
夢に満ち溢れた初期
初期段階は、サービスを作って誰かの役に立つこと、社会へのインパクトを夢にサービスを作りはじめる
その夢が正しいかどうかわからない
だからいかに早く市場へ出すかに注力する
多少汚いコードであっても、後々に負債になることがわかっていても
この時のファースト・プライオリティはサービスを世に出す事である
市場に受け入れられるか受け入れられないかがわからないものに時間と金をつぎ込み続けるのは愚かである
少人数のメンバーで全員がそれを理解してスピード感を持って開発に臨む
どんなに大変だったとしてもそこには希望がある
社会のために
世の中をより豊かにするために
自らの手でイノベーションを起こすことへの高揚感にあふれ
世界の革新を胸に秘めて
ローンチ
ある程度形になった段階でローンチされるサービス
まだまだ未熟ではあるが、その思想や未来に期待したイノベーターが付く
顧客は契約の段階では、思想や未来に胸を膨らませて契約を行うが
いざ業務において使い始めると、不足していることがたくさん目についてくる
すると、はじめは要望として様々なものがあげられてくる
開発者たちは自分たちの目指す思想・未来と照らし合わせて
取捨選択を行い
時には大胆な方向転換を行う
初期段階は少人数での開発であり、コードもまだまだ少ないためそれほど難しくはない
顧客の増加と売上
様々な要望を取り入れていくと、細かい部分では気になるところはあるものの
大枠では使えるサービスが出来上がってくる
この頃にはアーリーアダプターもそこそこの数になり
アーリーマジョリティが付いてくる
そうなってくると、このサービスはどんどん伸びていくものであると経営的判断がなされる
すると何が起きるか
急速な人員の増加と、売上伸長へ意識偏重
エンジニア、セールス問わず急拡大が行われる
新規採用・他部署からの異動
人を集める方法はいくらでもある
急速な組織の拡大
少人数で壮大なビジョンを掲げて開発して来たところに
急な転換
なにが起きるか
少人数で図れていた意思疎通ができなくなる
コードが崩れはじめる
初期メンバーはどこが負債になるかを理解しているし
なぜその負債が生まれているかは十分な理解をし共通認識として受け入れている
けれども、急拡大にて配属された人にはそういった共通認識もない
目にするのは人の手垢まみれのコードだ
そこに思い入れはない
そうこうしているうちに別の新規事業立ち上げで初期メンバーは引き抜かれていく
残るのはほんの一握りの初期メンバーと、出鼻を挫かれた途中入場のメンバーだ
途中入場者は初期メンバーの残した負債に苦しむことになる
負債に足を取られながらも売上を上げるために
開発スピードを落とさないために努力する
しかし、そこには行き場のない怒りと虚しさがある
途中入場者も初期メンバーの残した負債の理由を理解できるからだ
理解できるからこそ、その怒りの矛先をどこに向けることも出来ず
苦悩する
徒労でしかない
コードに限界が来たときに
大きなテコ入れをしようとしたときに
どれほどのメンバーが快く手を挙げるだろうか
売上伸長
売上を伸ばすためにトップが変わる
どんなにエンジニア経験のあるトップであって
エンジニアの心を理解しようと努めても
経営層から売上を求められている以上、思いはどうしても売上へ変調し偏重する
そして次第に
壮大なビジョンは失われる
そのトップにとっては、今自分が抱えているサービスの売上を伸ばすことがファースト・プライオリティだから
最初のビジョンがどうあろうと関係ない
最初のビジョンを理解していたとしてもそれを推し進めるだけの推進力はない
なぜなら最初からそこに携わっていないからそのビジョンに対する熱量がない
その熱量の違いから何が起きるのだろう
顧客が求めるものを作り続けるだけの日々
ときに自らの発想でものを作るが続かない
もどかしい
誰のための
一体、誰のためなんのためにサービスを作っているのか
組織の急拡大に向けて採用された人物は
少人数でやっていたころのビジョンやその組織のあり方に突き動かされて来た人たちばかりだ
それがいざ足を踏み入れるとそこにはあの頃の輝きはもうない
見えない敵と戦う日々
暗闇でもがく日々
崩壊
少人数でのマネジメントは大人数には使えない
破壊して構築しなおすか
構築し直すだけの希望はパンドラの箱に残っているだろうか
夢見るその先は
エンジニアはものを作ることがゴールではない
その先になにを夢見るのか
- 作者: リチャード・シェリダン
- 出版社/メーカー: 翔泳社
- 発売日: 2017/01/20
- メディア: Kindle版
- この商品を含むブログを見る
Elixir のサンプル
1対多のテーブルとか
Elixir ecto の自動生成IDをUUIDにする
- 作者: Dave Thomas,笹田耕一,鳥井雪
- 出版社/メーカー: オーム社
- 発売日: 2016/08/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
Elixir/Phoenix 初級?: はじめの一歩 (OIAX BOOKS)
- 作者: 黒田努
- 出版社/メーカー: 株式会社オイアクス
- 発売日: 2016/11/21
- メディア: Kindle版
- この商品を含むブログを見る
さて、ここで問題です。(将来推計人口をもとに)
平成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歳の人数は減っていく一方なのでそこにかかる"負担は"軽くなるので大した問題ではないだろう。
一方で労働力人口が減っていくので自信の首を締めているのに代わりはない。
現在進行形で真綿で首を絞めている状態
どうやって今の暮らしを続けていく?
(※ いろいろ数字いじって試したのでどこかで数字がおかしくなってるかも)
未来の年表 人口減少日本でこれから起きること (講談社現代新書)
- 作者: 河合雅司
- 出版社/メーカー: 講談社
- 発売日: 2017/06/14
- メディア: 新書
- この商品を含むブログ (16件) を見る
- 作者: リンダグラットン,アンドリュースコット,池村千秋
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2016/10/21
- メディア: 単行本
- この商品を含むブログ (16件) を見る
Elixir Phoenixのドキュメントを読み漁る Routing
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
ぐぐってたらいいまとめがあった
- 作者: Dave Thomas,笹田耕一,鳥井雪
- 出版社/メーカー: オーム社
- 発売日: 2016/08/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る