「白と黒のとびら オートマトンと形式言語をめぐる冒険」を読んでオートマトン学習モチベがMAXになった話
こんにちは、 しがないラジオ パーソナリティのgamiです.
友人から借りて、オートマトンと形式言語をファンタジー調で解説した本を読みました.
内容は物語ですが、研究者である著者が、東京大学出版会というガチガチなところから出しているので、技術的な裏付けのある書籍です.
- 作者: 川添愛
- 出版社/メーカー: 東京大学出版会
- 発売日: 2013/04/18
- メディア: 単行本
- この商品を含むブログ (14件) を見る
3行で感想
あらすじ
主人公は魔術師アルドゥインの弟子のガレットです.
ただし、師匠からはいっこうに魔法を教えてもらえず、毎日よくわからない言語の勉強をさせられます.
古代ルル語や古代クフ語という古代の言語で、文字は○と●の2文字しかありません.
しかし、各地で不思議な遺跡と出会い、それらを探索する中で、古代語を学ぶ意味に気付いていきます.
遺跡は白と黒のとびらのついた部屋の集まりから構成されていて、とびらを開ける順番を誤ると、二度と出てこられないものもあります.
ガレットは古代語の文法と遺跡の関係についての謎を紐解いていき...
オートマトンと形式言語
各古代語には、それぞれ固有の文法があります. 例えば、第三十三古代クフ語は、「偶数個の○と●の文字からなる回文」のみを、正しい文とみなします.
そして、各遺跡にも、どの状態で、どの行動をしたら、どの部屋に飛ばされるか、といったルールがあります.
古代語や遺跡などのよくわからないけどものから、こうした固有のルールを、読者もガレットと一緒に見つけ出していくような作りになっています.
巻末には、物語の解説がまとめられています.
物語の中の要素との対応としては、実は
を表していることがわかります.
また、オートマトンと形式言語の「現実世界」での発展に沿って、物語のストーリーが組まれています.
その対応関係も、解説を読んだときに後から知らされるので、「そうだったのか！」という感覚が味わえます.
オートマトンや形式言語を学ぶ意味
この本を読む前は、「オートマトンとかよく聞くけど、ライフゲームみたいなやつでしょ」くらいの知識でした(雑).
読んだ後は、かなりオートマトン学習モチベが上がりました.
こちらも解説に書いてある内容ですが、オートマトンと形式言語は、とってもとっても大事な基礎理論らしいです.
情報科学も数学も、漠然と「学び足りてないなあ」と思っているので、その基礎を知れるというのは良いなあ.
また、オートマトンと形式言語を深く学ぶことによって、以下のような問いに対して答えることができるとのこと.
- 「計算」とはそもそも何なのか？
- 計算機械にできることと、できないことの境目はどこにあるのか？
- 人間の脳を一種の「計算機械」と見なした場合、私たちの持つ言語能力をどのように説明することができるか？
個人的には、特に「2. 計算機械にできることと、できないことの境目はどこにあるのか？」という問いにはすごく興味があります.
この本の終盤のテーマも、「何でもできそうな計算機械でも、実はできないことがある」という点にあります. こうした「直感に反する事実を論証する」というところに、理論の強さがある気がします.
最近の機械学習/ディープラーニング熱の高まりを見ていると、「もうAIが全部決めてくれればいいのに」と思うことがあります.
しかし、実際には、その「全部」という領域の範囲は、理論上は「全部」ではないかもしれない？ということなんですかね.
こんな感じでもやもやしてくるので、この本はオートマトンと形式言語の入門書として、最適な本だと思いました.
「白と黒のとびら」というオートマトンと形式言語を物語にした本を読んだ. 面白かったが、オートマトンを知らないと「だからなんなんだ」感がすごいので、関連書籍を読むことを強いられる. 入門書として逆に優秀.https://t.co/hRjp2j90Vw
— j_ikegami (@jumpei_ikegami) 2018年1月1日
自己肯定感を爆上げする、MRM(Morning Routine Management)を始めてみた
あけましておめでとうございます.
しがないラジオ パーソナリティのgamiです.
2018年になるにあたって、今年の目標を何にしようかなーと考えました. やっぱり「普段やりたくてもできていないこと」を、まずはちゃんとできるようにしたいなあと.
例えば、Webエンジニアなので趣味でコード書きたいですし、昨年で15kg太ったので運動したいです. 家の掃除とかも、ついサボって埃だらけになります.
MRMってなあに？
唐突ですが、MRM(Morning Routine Management)という概念があります.
特に仕事以外で日々やるべきことを、毎日のルーチンに分割して、朝の時間ですべてやるための習慣マネジメント手法です.
さっき私が考えました.
ネーミング自体は先ほど5分くらいで考えたのですが、構想は3年前くらいから持っていた気がします. ただし、ちゃんと実践できていなかったので、今年はこれをちゃんとやっていきたいなと思うわけです.
なぜ朝なのか？
朝活と夜活のどっちがいいのかという論争は、ググるとたくさん出てきます.
私は朝活派です.
毎日決まったことをやろうとするとき、夜だとどうしても予定が入ってしまう日が多く、まとまった時間が取りにくいです. 一方、朝であれば、起きる時間と出社時間は(頑張れば)固定できるので、毎日2時間とか3時間とか確保できます.
なので、決まったルーチンをやるなら、朝の方がいいと思いました.
これまでのMRM実践
これまでもMRMっぽいことを実践しては、うまくいったり挫折したりしてきました.
私はむかし公務員試験を受けて失敗したりしているのですが、そのときは自己肯定感が大変なことになったので、リカバリのために数ヶ月間、毎朝ランニングをしました. 特に複数のルーチンを管理するには至りませんでしたが、毎朝同じことをすることの良さを実感しました.
また、2016年には、Google SpreadSheetに朝やるべき習慣をすべて書き出して、それをスマホで見ながら毎日こなしていくということをしました. そのときは、掃除、洗濯などの家事から、爪切りなどの週一タスクも曜日限定ルーチンみたいにして管理していた気がします.
これも、何も考えずにSpreadSheetに書いてあることを上から順番にやるだけで、自然と運動できるし、部屋は毎日きれいだし、最高でした.
ただし、SpreadSheetをスマホで見るという運用が地味にめんどくさくて、やめてしまいました.
MRMのプロセス
というわけで、これまでの実践から、 「日々の生活でやるべきことを毎朝のルーチンとして細かい粒度ですべて定義し、その通りにやっていく行為」 はすごくいいという結論に至りました.
ただし、その行為を何と呼べばいいかわからなかったので、今回、MRMという呼称を付けました.
私の中のMRMプロセスをざっくり定義すると、以下のようになります.
1. 日々の生活の中で、やるべきこと、やりたいことを洗い出す
感覚値では、以下のように分けると出しやすいです
すでに毎朝やっている当たり前のこと
- 例
- 「朝起きて立ち上がる」
- 「トイレに行く」
- 「シャワーを浴びる」
- 「歯を磨く」
- 「服を着る」
やるべきだけどできていない家事など
- 例
- 「洗濯をする」
- 「掃除機をかける」
- 「皿を洗う」
- 「爪を切る」
自己成長のためにやりたいこと
- 例
- 「読書する」
- 「ブログを1記事書く」
- 「趣味の開発でcommitする」
2. 毎朝やるルーチンとして正規化する
毎朝何も考えずに同じルーチンを回すために、以下の3要素を適切な度合いに調整します.
- ルーチンの「頻度」
- ルーチンの「粒度」
- ルーチンの「程度」
「頻度」の調整
例えば、「爪を切る」は毎日やると深爪になってしまいます.
そこで、曜日別ルーチンを作成し、例えば「爪を切る」をその月曜日に割り当てます. イメージとしては、ある1つのルーチンの中身が曜日によって変わる感じです.
「粒度」の調整
例えば、「シャワーを浴びる」というルーチンは、私の場合、以下の子ルーチンを含んだ複雑なものです.
- 「下着とタオルを持って浴室に行く」
- 「服を脱ぐ」
- 「シャワーを浴びる」
- 「身体を拭く」
- 「服を着る」
- 「浴槽を掃除する」
こうした大きな粒度のルーチンを、適切な粒度まで分割します. 「どの粒度だと、『何も考えずに』実行できるか」を考えると、いい感じになります.
「程度」の調整
例えば、「ブログを1記事書く」というルーチンは、毎朝やるには重いです. 仮に実行しても、薄めの記事が量産されてしまうことになりそうです.
「どのくらいやるのか？」が不明確なルーチンについては、毎朝やれる/やるべき量を設定します.
ブログの例で言えば、「30分間以上書く」など時間の長さで定義したり、「50行以上書く」などアウトプットの量で定義したりします.
3. 朝起きる時間を決める
朝起きる時間を決めることで、毎朝のルーチンにどのくらいの時間を割けるか決まります.
私は毎朝6時に起きます(宣言).
4. どのルーチンをどの順番でやるかを決める
効率性やモチベーションの観点から、ルーチンをどの順番でやるかを決めます. 時間内に終わらないルーチンは、程度を下げたり消したりします.
最初は仮置きで決めて、やりながら調整すればいいです.
5. 毎朝決まった時間に起きることを決心し、実行する
一番大事です. これができると、勝ちます.
6. 毎朝PDCAを回す
毎朝決めたルーチンを淡々とこなしつつ、順番や内容をチューニングしていきます.
うまくできない、そもそも朝起きられない、というときは、自分が悪いのではなくルーチン設定が悪いと考えて、ひたすら改善します.
私のルーチンリスト
ということで、2018年1月現在の私のルーチンは以下です. 再開してすぐなので、ちょこちょこ変わると思います.
- 立ち上がる
- ポッドキャストを聴き始める
- 1日の予定を確認する
- トイレに行く
- 20分以上ランニングする
- 体重計にのる
- 布団をしまう
- commitする(=プログラミングする)
- 筋トレする(毎日部位を変える)
- Slackに筋トレ報告
- COMPとプロテインとサプリを飲む
- 皿を洗う
- タオルと着替えをもつ
- イヤホンを外す
- シャワーを浴びる
- イヤホンをつける
- 浴室をシャワーで掃除する
- スクイージーをかける
- 髭を剃る
- 歯を磨く
- 髪を乾かす
- 歯をジェットウォッシュする(ドルツEW-DJ61-W)
- 掃除機をかける
- 1 tweetする
- ブログ20分以上書く
- 服を着る
- 家を出る
30個弱あります. すごいですね.
数日続けた感じ、最初のランニングさえできれば、他は結構いける気がします. ランニングモチベを上げるために、3万円のスニーカーを買いました.
NB1という、NewBalanceのスニーカーの全パーツの色と素材をオンラインで選んで注文できる夢のようなサービスを使って注文した靴が届いたけど、完成品も非常に好みで良い. これが、マス・カスタマイゼーションっ！https://t.co/By7s83KZFI pic.twitter.com/WkpETTMatR
— j_ikegami (@jumpei_ikegami) 2017年12月29日
あと、起きた瞬間に出発できるように、夜は靴下とウィンドブレーカーを身に付けて寝ています.
筋トレは、ダンベルとフラットベンチが家にあるので自宅でやります.
- 出版社/メーカー: ファイティングロード
- メディア: その他
- この商品を含むブログを見る
ファイティングロード (FIGHTINGROAD) フラットベンチPRO
- 出版社/メーカー: ファイティングロード
- メディア: その他
- この商品を含むブログを見る
トレーニング内容は、石井直方先生を信奉しているので、この本をやっています.
- 作者: 石井直方
- 出版社/メーカー: マイナビ出版
- 発売日: 2014/02/22
- メディア: Kindle版
- この商品を含むブログを見る
まだ洗濯とかゴミ出しとかがルーチンに入ってないので、今後どっかに混ぜ込みます.
MRMの効用
MRMを少し実践してみた感じ、すごくいいです. もうちょっと言語化します.
QOLが上がる
掃除や皿洗いなどを毎日ちゃんとやるので、部屋がきれいな状態で保たれてQOLが上がります.
「やるべきだけどやれてない」感が減る
QOLと似てますが、より精神的なメリットです.
仕事から帰ってきて、家が埃まみれだったり、洗っていない皿が大量にあったりすると、「やってねえ...でも疲れた...」という気持ちになって意志力とかが削られます. そういう「やるべきだけどやれてない」感からくる精神ダメージを軽減できます.
自己肯定感が上がる
自分で決めたことをその通りにこなすと、「自分をコントロールできている」という感覚から自己肯定感が上がります. また、単純に学習やアウトプットに時間を割けるので、スキルや周囲からの評価も上がります.
良いこと尽くめですね！
MRM実践のために諦めること
とはいえ、毎朝MRMをちゃんと実践して上記のメリットを得るには、何かを捨てなければいけません. ここは、選択と意志の問題です.
夜更かしする
確保したい睡眠時間にも依りますが、家で夜更かしできなくなります. 私は23時には寝ます(予言).
夜の飲み会でお酒をたくさん飲む
上と同じですが、飲んで終電で帰るとかができなくなります. 「飲んだ翌朝は休む！」と決めてもいいですが、飲み会が続くとグダグダになります.
「ちょっと朝のランニングがあるので...」とか言って颯爽と飲み会を抜け出しましょう. 飲み過ぎると寝坊するので、お酒も控え目にします(自戒).
朝、布団の中でゴロゴロする
微睡みの中で布団と蜜月の時間を過ごすことができなくなります.
特に冬はまだ日の出前に目覚ましに叩き起こされて、運動を強いられたりして辛いです.
MRMを実現するための強い味方
MRMを実現するときに私が使っているものです.
ルーチンを記録するアプリケーション
ルーチンを脳内に記録し続けるのは辛いので、外部化します.
むかしはGoogle SpreadSheetを使っていましたが、辛いので今は自分でアプリケーションを作っています. 自分がエンジニアで良かった、良かった.
kesamoというスマホ向けWebアプリです.
ルーチンを1つずつ表示させることができたり.
一覧から編集や並び替えができたりします.
使いたい方は、どうぞ！ まだ開発中で大きな仕様変更がありうるので、ご了承ください！
ポッドキャスト
ランニングや家事の最中は耳が暇なので、ずっとポッドキャストを聞いています. 好きなポッドキャストが見つかると、「ポッドキャストを聴くために運動する」みたいに主従が逆転するので、ハードなルーチンでも心理的ハードルが下がるという効用もあります.
私はエンジニアなので、Tech系のポッドキャストをガシガシ消費してます.
同じくエンジニアの方なら、まずはこのポッドキャストが軽くておすすめです(PR).
自分がポッドキャスターで良かった、良かった.
マジレスすると、エンジニアならまずはRebuildを全部聞けばいいと思います.
非エンジニアなら、バイリンガルニュースとかを聞けば英語の勉強になっていいんじゃないでしょうか(適当).
まとめ
- 日々やれてないことにモヤモヤしてるなら、MRMおすすめ！
2018年の目標
ということで、2018年はMRMのプロセスの中で、以下をやっていきます.
- 毎日運動する(そして10kg痩せる)
- 毎日コード書く
- 毎日ブログ書く(週1回くらいでshipする)
(なんかラジオで言ったやつから変わった気がする)
今年もしがないラジオとがみぶろと @jumpei_ikegami をよろしくお願いします.
We Are JavaScripters!@14th まとめ
We Are JavaScripters!@14thに参加したので、その内容についてまとめました！ プレゼント企画などもあって楽しかった！
イベント自体の詳細は、こちら！
LT1: node.jsでプレゼンツールつくったお話 @ykyk1218
資料
自己紹介
- ニワトリのアイコン
悩み
- 勉強会で質問しにくい
- 勉強会に登壇しても、反応がわかりにくい
SlideChat
- 作った
- pdfをアップロードし、スライド形式に変換
- プレゼン中にコメントできる
- なるほどボタンで、なるほど数を表示できる
スタック
- Meteor(node.js)
- Mongoとの相性がいい
- フロントエンド周りの環境を整えるのが楽
- webpackなどを別途用意する必要がない
- React.js
- PDF.js
- MongoDB
Qiitaスライドで使いたい！
- QiitaスライドをpdfにするChrome拡張作った
LT2: Nuxt.jsで始めるPWA @takanorip
資料
自己紹介
- 株式会社スマートドライブ
- Polymer-Japan翻訳チーム
Service Worker
- networkとcacheからいい感じにデータ取ってきてくれる
Nuxt.js
- ユニバーサルVue.jsアプリ
- SSR
- ルーティング便利
導入は簡単！
- pwa-moduleを使う
- ライブラリをNuxt用にモジュール化したもの
- nuxt.config.js
- 設定ファイル
- gitignoreにsw.*を追加
プッシュ通知
- One Signalを使う
- モバイルAppもWebPushも
- Uberも使っている
- nuxt.config.jsにonesignalモジュールを登録し、設定を追記
- デフォルトの通知設定ダイアログを出す前に、確認をはさまないとユーザービリティ的にだめ！
- OneSignalで、確認用の独自UIを出せる
まとめ
- Nuxt.jsでPWAの導入が簡単！
LT3: (スポンサー)アライドアーキテクツのサービスで使わているJavaScriptの話 @oremega
資料
自己紹介
- デザイナー
- 社内で1人なので、UI,UX,HTML,CSS,JSなんでもやる
アライドアーキテクツ
monipla
- 企業と人をつなぐ
- 全部jQuery！
Brand Touch Manager
- 企業が、自社とつながっている人を可視化
技術スタック
告知
- フロントエンドエンジニアとデザイナーを募集しています！
LT4: jquery? state管理? どっち使えばいいの？ @fukaminmin
資料
www.slideshare.net
自己紹介
画面から友達を削除する
jQuery
state管理
- state側のデータを判別して、そっちをいじればいい
使用基準
- jquery
- LP
- 動きがないページ
- animation
- vue, knockout
- ポップアップやコメント一覧
- react, angular
- 1ページで色々したい
- フルSPA
デメリット
おすすめ
- 最初に始めるなら、Vue！
スポンサーセッション
LT5: facebookのフロントエンド開発 @boiyaaaaaa
資料
自己紹介
- Persol P&T
- フロントエンドエンジニア
- ITスペシャリストに昇格
Facebookでのフロントエンド開発
- StackShareによるスタック
- React, Flux, Relay
- Jest
- Phabricator
- Jenkins
- Nuclide(内製エディタ)
- Mercurialの単一リポジトリにぶち込んでいる
弟に訊いてみた
パッケージ管理
- 全社でYarnを使っている
- 必要なモジュールを全て内製している
Facebook製のものしか使えない？
- 強制ではない
- Nuclideが自社構成だと使いやすい
品質管理
- Flowで型チェック
- Jest
YarnやJestは書き換えた？
- 1週間でソースがほとんど変わることがある
バンドラは？
- 内製
Facebookの開発者になるためには？
LT6: SlackはどうやってBrowserViewに乗り換えたか @tipo159
資料
内容
- 以下の内容に沿って、Slackの実装上の変化を紹介
WebViewからBrowserViewへの乗り換え
- まだβ版
- webViewよりもChromeのタブに近い動作
- Electronで維持管理できる
複数Redux Storeの同期
- 前は必要だったが、不要になった
非同期Actionによる副作用
- redux-observableを使い、非同期Actionとユーザー操作に伴うActionを一元化
リファクタリング
- TypeScriptによる正確なリファクタリング
- Observableを使ったコード記述に、型が役に立つ
LT7: 関数の話 @chikoski
資料
function宣言とアロー関数式
- 書き方が色々
関数適用
- 関数を呼ぶ方法
add(1,2)
パイプライン演算子
- 最近議論されている仕様
value = 7 |> double |> addOne
関数適用は遅い
- 普通に演算子で書いた方が早い
- 関数呼び出し時にローカル変数を使ったりするので、メモリ操作が多い
- でも、関数で書いた方が読みやすい
末尾呼び出し
- ES6の仕様で、内部的に演算子で展開してくれる
- なかなか実装されなかった
関数
- 手続きの列に名前をつけたもの
関数はオブジェクト
- つまり、関数 = モノ
クロージャ
- 外の変数を使って定義できる
部分適用
- クロージャがあると、関数の一部分だけを固定した別の関数ができる
- utilityが簡単に作れる
ロジックのパラメータ化
- map, reduceなど、ロジックを引数で渡せる
- 部分適用と組み合わせるといい
シューティングゲームに使ってみる
- 当たり判定の計算をしてみる
- Enemyクラスに、ColliderとRendererのプロパティを設ける例
LT8: アウトプットしよう！ @brn0227
自己紹介
- V8のコントリビュータになった！
新卒時代
- JS書けるだけで即戦力に
転職
- CAへ
- 上司に勉強会を勧められるが、嫌いだった
- 発表内容も大したことないし...
- 懇親会が苦手...
インプット
- ひたすらインプット
- babelよりも前にトランスパイラを作ったが、公表せずに殺した
世間から消える
- 社員数が多いと、知られていないことも多い
- フロントエンドテックリードになったが、自分を知っている人があまりいなかった
行き詰まり
- インプットだけを続けても、成長が見えなくなってきた
- OSSはPR送っていたが、遠い存在に感じていた
2017年
- 月に2〜4登壇を目標
- 23登壇した
- speaker deckが2ページになった
感じたこと
伝えたいこと
- 明日からでもアウトプットすべき
- 自分の価値を高めるのは、自分の責務
- 社会から受けた恩を返していこう
- 立ち止まっている間に、ベテラン達はさらに先に行ってしまう
伝えたいこと2
- インプットとアウトプットのバランスをとる
- アウトプットがあるから新鮮な情報に触れられる
- 自分の情報の鮮度を確認できる
- 「十分な目玉があれば、全てのバグは深刻ではない」
知見
- ありとあらゆる知見は、価値がある
- 自分にとって取るに足らない内容でも、他の人にとってはとても価値がある
方法
- 片っ端からLT枠に申し込む
- 申し込んでから内容を考える
- 喋る練習をする
- 懇親会で人と話す
- ブログ頑張る
まとめ
- 迷う必要はない！
Vue.js Tokyo v-meetup #6まとめ
Vue.js Tokyo v-meetup #6に参加したので、その内容についてまとめました！
イベント自体の詳細は、こちら！ vuejs-meetup.connpass.com
セッション枠1: Future of Vue.js
資料
自己紹介
- Vue.jsコアチームメンバー
爆発した2017年
- Google Trendで2016/10にReactを抜いた
- GitHub Starsも、reactに近づく
- VueConf2017が開催@ポーランド
- v2.2〜2.5の4つのリリース
- エコシステム
- NUXT, onsenUIなど
- コアチームメンバーの増加
- AWA with Vue.js Teamの開催(9月)
- 「コアチームメンバーだけでなんか聞きたいことある？」
Vue Project Roadmap
公式スタイルガイド提供
- 公式ドキュメントに公開済み
Cookbook
- よくある落とし穴への対処をドキュメント化
- 着手はこれから
eslint-plugin-vue
- Vue.js向けのコードをLint
- v4.0.0-beta.2
- 公式スタイルガイド対応中
vue-test-utils
- Vueの単体テストツールを公式でサポート
- v1.0.0-beta.7
- 日本語ドキュメントもほぼ揃っている
vue-component-compiler
vue-cli
- 楽に環境構築できるツール
- v2.9.2
- 課題
- テンプレートのメンテが大変
- CLIから問われる質問が難しい
- 3.0アーキテクチャ
- プリセットモデルの採用
- オンデマンドでプリセット追加
- プリセット毎にnpmで管理
- browserifyを廃止し、webpackテンプレートへ
- configファイルによる集中管理
- vue-cliの分離(vue buildコマンドが分離される)
Core
- v3.0？
- 2.x系と並行してメンテされる
- ネイティブにES2015をサポートするブラウザのみサポート
- リアクティブシステムの改善
WebComponents対応
クラスベースのAPI提供？
WebAssemly対応？
- DOMアクセスできるようになったらあるかも
2018カンファレンス
- Vue.js Conference Amsterdm
- UI
- London
- EU
- 日本でも！
セッション枠2: eslint-plugin-vue
資料
自己紹介
- 長島徹
- ESLintのメンテナの1人
- Vue.jsのESLintチームメンバー
目次
- 開発動機
- 今まで
- 使い方
- templateタグを検証するルールの書き方
1. 開発動機
- polumerで開発していたときのtypoを見つけて欲しかった
- React/JSXでは、静的検証が優れていた
- Vueでも欲しい
2. 今まで
課題
- .vueファイルはHTML形式だが、ESLintはHTMLを扱えない
- カスタムパーサーを作った
検証
- 試しに25個の検証ルールを作成
開発
3. 使い方
- 以下のサイトで試用できる
- configファイルに設定を記載
4. templateタグを検証するルールの書き方
- みんなで新しいルールを書こう！
基本的にはESLintのルール作成と同じ
- 既存ルールに悪影響を与えないためにtemplateタグ部分の AST は分離されているため、特別な関数を使ってアクセスする必要あり
ここで、試しに1つのルールを作ってみる(ライブコーディング)
ローカルのルールを利用する場合は、
--rulesdir指定が必要
$ eslit src/*.vue --rulesdir eslint-rules
- プロジェクト独自のルールを作成すると、生産性が上がるかも？
- 自動修正もする場合は、ルールを定義するjsファイル内で、fix関数を定義
質問
- プリプロセッサへの対応についてどう考えているのか？
- pugはサポートしようとしているが、他のものは検討していない
LT1枠: vue-test-utils
資料
スライド
デモ
自己紹介
- Lachlan Miller
コンポーネントのテスト
- データを正しく表示するか？
- ユーザーのアクションに合わせて正しく動作するか？
API
- レンダーとマークアップ
- 状態・関数を設定
- モック、スタブ、インタラクトの登録
DEMO
LT2枠: Vue.jsとともにいきる
資料
自己紹介
- エンジニアかつデザイナー
エンジニアとデザイナー
- お互いに話す言葉が違う
- ハイブリッドタイプ
- jQuery帝国を捨てて、Vue.js王国に来てください！！！
デザイン現場では意外と使われてないもの
- Vue
- Gulp
- Webpack
- SASS
- ループや分岐 -関数構造家 -エディタ
- 外部データ通信
- git
デザイナーにVue.jsを広める辛さ
- 「世間のデザイナーから見れば、下北沢のインディーズバンドと同じレベルの知名度」
jQuery帝国とVue.js王国の考え方の違い
- コンパイル
- イベント処理
デザイナーがVue.jsを使うまでの3つのハードル
- データをかくない
- Vue.js難しい
- DOMを見てくれない
- F12を知らない
5つの工夫
- Vue.jsのドキュメントは読まなくてもいい
- コンポーネント定義をHTML側に寄せる
- ディレクティブという概念を隠蔽
- 非同期データ通信を無くす
良かったこと
- 変更に強くなった
- 将来の見通しがよくなった
- Vueのdataを考えるようになった
デザイナーが覚えたVue.jsの機能
- 3%
私以外のメンバーがウェブサイトを作った分量
- 92%
開発効率
- 2,000%
質問
なぜVue.jsか？
- Angularを使ったら疲弊した
ソースコード管理はどのようにやっているか？
- プルリクベースはやめて、masterのみ
- gitのログがあるだけですごい！という世界
LT3枠: 10年前のレガシーシステムをVue.js TypeScript Elementでフルリニューアルしている話
資料
自己紹介
- エムスリー株式会社
- ベルセルクが好き
リニューアル前
リニューアル後
Element
- Vue.jsのデスクトップUIフレームワーク
- 2.0.0でTypeScript型定義がバンドルされた
- フォーム部品周りが豊富
- Vue.js系のUIフレームワークで一番人気
- i18n対応
- Vetur(VSCodeプラグイン)もサポート
- 補完が効く
- rulesにバリデーションルールを記載できる
- パーツが豊富で、少ない手数でリッチなUIを構築できる
TypeScript
- Vue.js2.5でサポート
- オブジェクト構文でも、thisの型が推論されるようになった！
- APIの1エンドポイントのプロパティが50個あったりするので、型定義が欲しい
- Kotlin側の型定義から、TSの型定義を自動生成
開発の流れ
まとめ
- 管理画面開発にElementはおすすめ
- Vue.jsのTypeScriptサポート強化は嬉しい
- swagger-codegenでTypeScriptの型定義自動生成をするのは、あり
LT4枠: VS Code&TypeScript&Vue.js
自己紹介
VSCode
- OSS
- GitHub Octoverse 2017 でも話題
TypeScript
- 「JSは、Webのアセンブリ言語」
ライブデモ
- 以下のリポジトリを使用
8つのSIer退職エントリから学ぶ、日本のSIerの実態
この記事は、しがないラジオAdventCalender8日目の記事です。
私は、「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」という、全国のSIerを敵に回すようなタイトルのポッドキャストをやっています。
タイトルを決めた理由の1つとして、よく「SIer退職エントリ」がはてなのホットエントリーに入っているのを知っていたことがあります。
SIやばいよ、SIやめたよ、みたいな話は、界隈で興味や関心を得やすいのだなあという感覚もあってのタイトルです。
そこで改めて、富士通の退職者の1人として、「SIer退職エントリ」をまとめてみます。
ざっと探して見つかったものに限るので、偏りがあるかもしれません。 また、SIerの営業職/コーポレート部門などについては、本エントリのスコープから外しています。
ネガティブ寄り
まずは、SIerに対してネガティブな感情が滲みでているエントリたちです。
2016-04-13: 富士通を退職した話 (1256ブクマ)
はてブ界隈の話題を席巻したエントリ.
入社する前は大学の情報系学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。 (中略) 自分の希望についてはしっかりと主張したつもりだったけれど、 入社して1週間後に告げられた自分の配属先は、山奥の工場でメインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。
多くの大企業では、採用部門と事業部が切り離されていて、入社時の希望と全く違う配属になることがあります。 この現象を、私は「大企業ガチャ」と呼んでいます。
20代そこそこの新卒社員が化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかった (中略) せめて担当業務はオープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。
直感的には、ちゃんと情報科学を学んできた20代にCOBOLを書かせるのはもったいないと思います。 その辺りの感覚が日本の大手SIerの中にどのくらいあるのか、非常に気になります。
2011-12-04: ２年半務めたSIerを退職しプログラマとして再スタートを切ることにしました (82ブクマ)
プログラマに憧れて就活をしたけれど、SI業界ではPGは地位が低いという話を聞いてSEになった人の退職エントリ。
どうにもプログラマというのは飯が食えないらしい、 日本においては価値が低い職業として位置づけられているらしい、ということが見えてきました。
今にして思えば、それは「SI業界における下請け専門のPG」の話でしたが、 当時は「それがPG」だという風に見えてしまい(後略)
一般的にはモノを作れるプログラマーの方が価値が高そうですが、SIerではPGが単純労働とみなされ、 SE > PGという明確な身分差を付ける文化がある印象です。
一番大きく感じた違和感は 上流SIerのSEってITスキルなんて皆無でもやっていける、という点です。
特に大手SIerにいるような上流のSEは、技術職ではなく「技術系総合職」です。
技術が好きでコードを書きたい人は、上流SEになるとミスマッチになりやすいです。
2016-04-24: 富士通を退職して思うこと (1104ブクマ)
3年で辞められた、公共系SEの方。 富士通の悪いと感じた点が章立てで記述されていて、強い思いを感じます。
富士通には、人材キャリアフレームワークという社員評価制度があり、現場には、入社何年目はこのレベルの仕事、といった暗黙の了解がある。 本人の能力や意欲とは全く無関係に、入社後の経過年数で、仕事の裁量の幅が大きく制限される。
富士通の成果主義について深く知りたい方は、こちらの本がオススメです。文体に癖がありますが、生々しくて面白いです。
Amazon | 内側から見た富士通「成果主義」の崩壊 (ペーパーバックス) | 城 繁幸 | 企業動向
２．社内既得権益集団が絶対に損をしないルール
富士通という会社には多数の既得権益集団がいる。そして、社内のルールは彼らが決して不利にならないように作られている。 なぜなら、ルールを作る権限は、先頭を走る集団、1980年代に大成功を収めた既得権益層がガッチリ握っているからだ。
これは日本の社会保障制度がヤバいのと非常に似た理由で、大手SIerには若い人が一線を退いた世代を支えなければならない構造があります。 日本から脱出するのは大変ですが、SIerから若者が脱出するのは比較的簡単です。
こちらも深く知りたい方は、こちらの本がオススメとのこと。
若者はなぜ3年で辞めるのか? 年功序列が奪う日本の未来 (光文社新書) | 城 繁幸 |本 | 通販 | Amazon
４．発展途上国レベルの業務標準化の原因
ここにおいて、ITシステムが業務に合わせるのではなく、ITシステムに合わせて業務の方を変えていかなくてはいけないのだ。 (中略)
富士通は、既存顧客の業務標準化およびデファクト・スタンダードとなるITシステムの開発の陣頭指揮をとる役割を果たすべきだが、その望みは期待できない。 なぜなら関係が深い企業において、業務が効率化すると大量の社内失業者を出すことになるからだ。
これは日本全体の問題で、自治体や事業会社が業務をシステムに合わせて変えられれば全ての組織が同じパッケージを使うだけで済むので効率的ですが、現状はSIerがシステムを各組織の業務に合わせてカスタマイズしているので、生産性も利益率も全然上がらないという話です。
カスタマイズで関係性や利益を得るのは短期的にはいいですが、利益率が下がる割に保守コストがどんどん膨れあがるので、長期的には社会にも会社にも望ましくないです。
最近、新興企業を中心に業務でもSaaSの利用が進んでいるのは、良い傾向だと思います。
2013-09-01: SIerを退職しました - hotchemi.ja.blog (707ブクマ)
1年半で退職して、より技術寄りのキャリアにチェンジした方。
強いて言えば､下記の様な問題を考え続けた結果､転職という選択肢が自分にとって最善であると感じたという事です｡
・業界の方向性に疑問を感じた｡開発をアウトソーシングしマージンを抜くといったビジネススタイルでは開発者が幸せになれないと感じた
・エンジニアとして生きていく上で技術から取り残される焦りを感じた
わかる。
実際に現場に入ってみて｢楽しくなさそうにプログラミングをしている人が多いな｣と感じたのも事実です
多くのSIerの中で、プログラミングは仕様書をプログラムに落とし込む単純労働とみなされており、「プログラミング楽しい！」という人は少ない印象です。
人月(必ずしも悪だとは思いませんが)､一括納品のビジネスモデル､多重請負構造､ディフェンシブな開発体制(この辺りの思想は倉貫さんに強く影響を受けています)…パッと思いつくだけでもSIerの受託開発には多くの問題や矛盾が存在しています｡ (中略)
未熟な頭で必死に考えた結果､上記の問題を解決する為には､2つの道があるのではないかと考えます。 ・永和システムマネジメントやソニックガーデンなど､新しい受託開発を提案できる環境に身を置く｡リスクを丸投げしてくるような発注をそもそも受けない｡ ・ユーザー企業(敢えて幅広い言い方をしています)に身を置き､既存のSIではない事例を作っていく
これも同意で、多くの場合はユーザー企業とSIerのパワーバランスは顧客の方が上なので、無理な発注を受けざるを得ない状況があります。
この状況が変えるためには、やはり
- 他の会社には持っていない技術やノウハウをもった「強い受託会社」が増えてユーザー企業側の目を覚まさせる
- SIerのような受託会社ではなくユーザー企業側に多くの開発者が移る
のどちらかだと思います。
ちなみに、米国では日本と違い、ユーザー企業側に多くの開発者がいるようです。 paiza.hatenablog.com
また、本エントリでも言及されていますが、「納品のない受託開発」に取り組む株式会社ソニックガーデンさんは、まさに「強い受託会社」である印象で、受託IT業界に燦然と輝く光です。
2016-02-29: SI企業を退職しました - 無理なご乗車はおやめ下さい。
SIerに2年11ヶ月勤めて辞めた人のエントリ。 自分で仕事を取りに行ったと書いてあるので、たぶん会社の規模は小さめ。
私が文系出身でありながらこの世界に来たのは、サラリーマンとしてのビジネス力を磨きたかったのではなく、技術をもっと追い求めたかったから。「システムなんて中身がどうであれ、とにかく動けばいい」ではなかったはず。エンドユーザのシステムを理解・把握し、新規事業の提案をして、開発を外注に投げて私はその管理だけをするということがしたかったわけではないはず。
ウォーターフォールの受託開発だと、要件を実現することだけが優先されやすく、作っているシステムをもっと使いやすくするための努力をしにくいです。
この会社にいて得られる技術力は？VBやCOBOLや古い仕様のままのCといった枯れた技術は必要悪、エンタープライズ向けシステムには不可欠な技術だけど、でもそれを私は習得したかった？違う。
VBやCOBOLを書く人はまだ日本に必要だけど、それを自分が書くべきか、という問題。安い給料でCOBOLを書く若いエンジニアがいる限り、COBOLは死なない。
2015-10-04: 中小SIerを退職しました記事。 - るがぶろぐ (111ブクマ)
2年半勤めたSIerを辞めて、一旦無職になった方。 まず辞めてから考える勇気！
一番大事なのはやっぱり給与。諸々不満があったとしても、十分な報酬貰えてるなら文句言わず働くよねっていう。 (中略) 特に私の場合は、入社以来、何回も表彰されてた (個人でも、プロジェクト単位でも) っていう実績があって、「若手の期待の星」みたいなことも経営層から (対面では) 言われてたので、なのに昇給が同期と変わらず、無いも同然っていうのは…っていう感じでした。評価してるっていうなら形で示してください。これ大事。
これはSIerだけの問題ではないと思いますが、利益率の低さや年功序列が原因であることがある気がします。
ポジティブ寄り
次に、新しいチャレンジをしたいという理由で転職をしたケースと、転職後に辞めたことを後悔しているケースです。
どちらも、SEではなく研究開発寄り。
2014-01-20: 富士通を退職してGunosyにjoinしました - Ryoの開発日記 (298ブクマ)
スパコン向けのミドルウェア開発などをされていた方。 受託案件ではなく、研究や製品開発周りであれば、大手SI系の企業でも活き活き働いている人が多いイメージです。
前職に大きな不満があったわけではありません。 学生時代から興味のあった*6 データマイニングの技術を活用するGunosyのキュレーション事業に関わってみたい、スタートアップのベンチャーで自身の能力を活かしてみたい、身近で使われるようなB2Cの事業に関わってみたいという思いが日増しに強くなり、決断した次第です。
ポジティブな転職理由。
2013-12-21: 退職します. 拝承 - テストステ論 (987ブクマ)
こちらも、非常に話題になった日立退職エントリ。エントリ自体はネガティブ。
その攻撃的な内容に公開当時も話題になったが、何よりもその後筆者がTwitterで「転職は完全に失敗だった」「土下座で謝るので日立に戻りたい」と手のひらを返したところまで含めて多くの人の興味を引いた。
なお、転職後のTweetについては、以下の記事に詳しいです。本人のTwitterアカウントも調べましたが、凍結されている模様。
ざっくりまとめ
SIerに対するよくある批判や不満
- 開発言語や環境が古い(メインフレーム、COBOLなど)
- 実際に開発をするプログラマの方が、SEより地位が低い
- SEは「システムエンジニア」なのに開発させてもらえない
- ユーザー企業の業務をITシステムに合わせて変えるケースが少なく、カスタマイズが絶えない
- プログラミングを楽しんでいる人が少ない
- システムの品質や使いやすさを追求しにくい
- 給料が安い(特に若手)
わかったこと
- プログラミングが好きで仕事にしたい人は、SIerのSEになってはいけない
- SIer界隈では、業界の構造的な問題として、生産性の低い開発を強いられるケースが多い
- 大手SIerの研究開発部門であれば、技術的に凄い人に囲まれてスキルアップできる環境はあるかも
- 富士通は他の大手SIerに比べて退職エントリーが圧倒的に多い
以上です。
SIerに限らず、日系企業や大企業にありがちな問題も含まれていますが、おおよそSIerの負の側面については、網羅できた気がします。
ただし、退職エントリを書いた人の意見しか記述されていないので、だいぶバイアスがかかった内容だと思います。
実際、私の富士通時代の同期の中では、SEとして活き活きと働いている友人がたくさんいます。
そのため、辞めた側の一つの意見として、誰かの参考になれば幸いです。
大手SIerでCOBOLを書いていた私が新卒2年目でWeb系スタートアップに転職するまで
しがないラジオパーソナリティのgamiです。
しがないラジオAdvent Calendar2017 2日目の記事です。
これを書くために、ブログを始めました。きっかけ大事。
「SIerからWeb系への転職エピソードのアドベントカレンダー」ということで、自分の転職話を書きます。
私は富士通にSEとして入社してから、1年半でWeb系スタートアップであるプレイドに転職しました。 ポッドキャストでもこの辺の回で話しましたが、1年越しの転職エントリを赤裸々に書いていきます。
転職活動
富士通時代は、ブラックSIerとは真逆の働き方をしていました。 ほぼ毎日定時で帰っていて、累計残業時間も10時間以下です。
ホワイト労働だったのには、以下の理由があります。
- 自治体向けのビジネスだったので、そこまでハードじゃなかった
- パッケージ開発元のチームだったので、顧客から距離が遠かった
なので、転職に関して特に強い思いをもっていた訳ではなく、スキルアップに関するもやっとした不安だけを抱えて働いていました。
本格的に転職活動をし始めたのは、2つのきっかけがありました。
ベンチャーへの会社訪問
ある日、エンジニアとして働いていた大学の同期が、遊びに誘ってきました。
「転職サイトでスカウト受けた会社に遊びに行くけど、一緒に来る？」
当時の私にとって、会社に遊びに行くとはどういう概念なのか、全く理解できませんでした。 会社とは、お金とスキルを得るために働くところで、遊ぶところではありません。
ましてや、スカウトを受けているのは友人の方なので、「なんだこの金魚のフンみたいなやつは」と思われるのがオチです。
当然、そんな気乗りしない誘いは断ってもよかったのですが、なぜか行くことになりました。
この頃の記憶はあいまいですが、漠然とした不安に突き動かされて、何でもいいから「会社と家の往復以外のこと」がしたかったのかもしれません。
職場のあった海浜幕張から目黒までの電車では、現職の人への軽い罪悪感と、一歩踏み出せた自分への高揚感が入り混じった不思議な気持ちでした。
訪問した会社は、ラクスルという主に印刷サービスを提供するスタートアップです。 raksul.com
他の多くのWeb系スタートアップがそうであるように、ラクスルのオフィスは空中庭園を模した遊び心のある空間でした。
正直、友人がCTOと話している内容は半分もわかりませんでしたが、「世の中を変えるために遊ぶように働く人たちがいるのだ」という当たり前の事実に、震えました。
仲の良い同期の転職
ちょうど同じ時期に、仲の良い同期が転職してWebエンジニアになるという話を知りました。
そのときは、長い研修を終えて配属されてから、まだ1年もたっていませんでした。
「とりあえず3年」という言葉を信じてはいませんでしたが、何となく「今辞めるのは、世間体的に早すぎるかなあ」と思っていました。
そんな中で、同期が転職を決めたという話を聞いて、もう辞めてもいいんだな、という思いなおしました。
その同期とは、今も一緒にポッドキャストをする仲です。
転職活動を始める
Web系の会社に転職をしようと決心をしましたが、まず壁にぶち当たりました。
自分が何をやりたいのか、そして世の中にどんな会社があるのかも、全くわからなかったのです。
漠然と、「世の中を良くしている実感を持ちながら」、「エンジニアとして」働きたいと思っていました。
しかし、転職サイトを見ると、その条件に当てはまりそうな会社は星の数ほどあるのでした。
スカウトサイトに登録する
そこでまず、スカウトサイトに登録して、自分の経歴を詳細に書きました。 Wantedly、キャリアトレック、Greenあたり。
すると何件かスカウトが来るので、カジュアル面談の予約をします。
- どの会社がいいのかわからない
- 技術力に自信がない
というのが目下の課題だったので、「スカウトしたのはそっちじゃん」という言い訳ができることを重視しました。
今思うと消極的ですが、とにかく自信がなかったので、まずはそこから。
選り好みせずに面談を重ねていくと、結構いいことがありました。
- 自分のことを話すのに慣れる
- 興味のある会社とない会社の特徴がわかる
- (選考が通れば)自信がつく
やりたいこと、いきたい会社があいまいなときは、とにかくたくさん面談すると見えてくるものがあります。
とりあえず転職活動をしてみる、というのは、辞める確証がなくてもオススメです。
イケてるエージェントに登録する
面談慣れしたころに、Goodfind Careerの転職エージェントと面談をしました。
エージェント経由だと、自分の経歴や適性をみて合う会社を探してくれるので、実際に会社の人と面談をしてみても、マッチング度合いが高かったです。
今働いているプレイドも、そのときのエージェントの方に紹介してもらった会社です。
ただし、大手の転職エージェントはベンチャー界隈とのつながりが弱い印象です。 ベンチャーに転職をしたいなら、同じく人材系ベンチャーを頼った方がいいと思います。
転職活動のためにやったこと
定時退社で暇だったので、少しでも有利に働くよう、転職活動以外にも色々やっていました。
勉強する
「COBOLとJavaで開発してます！」というのは全くアピールにならないということは、薄々感じていました。 そこで、Web系の企業で多く使われている技術を勉強しました。
どの言語を学んでいいかわからなかったので、とりあえずRailsチュートリアルをやりました。
一通りこなすだけで、Rubyはもちろん、Git、Heroku、TDDなどWebアプリケーション開発に必要な知識をざっと学べるので非常に良いです。
今だったら、N予備校 プログラミングコースをやると思います。
何か作って公開する
Wordpressのカスタムテーマから自作したWebサイトを公開したりしました。
当時、全くPHPは理解していませんでしたが、コピペ開発でどうにか見れるものを作りました。
もう公開されてないと思ったらまだあったので、黒歴史ですが貼っておきます。
コンセプトは、「俺が効率的に生きるためのノウハウを1人の力で書き溜めてnanapi超えるわ」みたいな感じでした。 今見ると色々とやばいですが、皆さんのアウトプットのハードルが下がれば幸いです。
Tech系ポッドキャストを聴く
何かのきっかけで知ったRebuild.fmを、通勤中に狂ったように聞いていました。
聴き始めた当初は、話していることの1/5もわかりませんでしたが、「これが自分の目指す世界の言語なんだ」と念じて耐えていました。
Web寄りのTech系ポッドキャストを聴くのは、他業界からWeb系への転職するときには、とても良いと思います。
- Web界隈で勉強しなければいけない内容がなんとなくわかる
- Web界隈で最近話題のトピックを知れる
採用面接でも、Rebuildで仕入れた知識を、さも昔から知っていたかのように話していました。 「この人は話が通じるな」と思ってもらえるのは大事です。
最初は背伸びしているように感じたとしても、当たり前の界隈の知識を、ポッドキャストの力を借りて、ひたすら脳にインストールしました。
今だったら、しがないラジオを聴くと思います。(宣伝)
そんな感じで、Web系スタートアップに転職しました。
FAQ
書いていたら、読者の方からの質問が頭に浮かんできたので、その妄想に勝手に答えます。
新卒2年目でSIerを辞めるのは早かったか？
いいえ。
もちろん会社に依りますが、Web系の会社は、長くSIerにいた人を採用するのを嫌う傾向にあります。 カルチャーや開発環境にギャップがあるのが、その理由だと思います。
また、Web界隈は複数社経験する人がゴロゴロいるので、すぐに会社を辞める人へのマイナスイメージはかなり薄いです。
長くいるメリットはない気がしています。
ほぼ未経験でWeb系エンジニアになるのは技術的に大変か？
勉強が好きなら、なんとかなります。
また、技術以外のスキルやカルチャーマッチを重視する会社も多いので、自分に合った会社を見つければ大丈夫だと思います。
転職して楽しいですか？
楽しくて仕方がないです。
そんな訳で、楽しくて仕方がないラジオ、今後ともよろしくお願いしますー
