いがにんのぼやき

WEBエンジニアのブログ。IT、WEB、バンド、アニメ。

MANABIYA 2日目に参加して来た

勉強会

参加して来ました

manabiya.tech

teratailを運営するレバレジーズが主催するMANABIYAの2日目に参加して来ました。 自分なりにレポートをまとめたので公開します。

エンジニアのための自分経営戦略

資料

講演者

サイボウズ・ラボ、ビープラウドの機械学習周り(PyQとか)の技術顧問
西尾 泰和

著書
  • コーディングを支える技術
  • word2dev
  • 世界一わかりやすいプログラミングのしくみ(新発売!)

転機

違う領域を学ぶために、2011年に社会人大学院生として東工大に経営学を学びに

この講演の目的

最初の一歩を歩ませること
5~10年経った時に役立つようなタネを撒きにきた
Facebookにエンジニアのための自分経営戦略というグループを作っているのでそこで質問やら情報を追加するので是非参加してほしいとのこと

きこりのたとえ

  • 木を切るのは大変な仕事だ
  • 少し休んでのこぎりの刃を研いだらもっとはかどるよ
  • 切るのに忙しくて研ぐ時間なんてないんだよ

これは自分への投資と同じ

損失額の限定

新しいことのへの不安
やることによって何が得られるか、分からない
そんなときは 基本戦略:損失額の限定
結果はわからないのでそれをしたことによる損失を小さく限定する
例えば本を読む時に15分と決めることで、これを実行した時に15分使ったという時間を失われるだけという損失で済む

経営戦略とは 限られたリソースを何に配分するかの意思決定

自分個人の経営に注力 法人ではなく個人 プログラミングでも同じでめっちゃ書いてから試すのではなく小さく小さく試していく

経営を勉強するタイミングで一般社団法人の理事の提案が来てタイミングがよかった

個人のリソースとは

法人だとヒト・モノ・カネ・情報と言われている
列挙したものがすべてかということを疑っていこう
個人のリソースは 時間

配分をして何を得たいのか

何を得たいかは経営者が決める
法人によってはあえて赤字になっても投資をしていったりしている
単純に給料を下げれば利益があがるがそれによって従業員がハッピーになることはなく満足度が下がるときどうなるか、それぞれのリソース配分を考える

個人では自分自身が何を求めたいかを自問していく
今、確実に言えるのはこの場にいる人は知識を求めている、時間を使ってこの場で聞いて知識を得るぞという投資戦略をとっていると言える
このように自分自身がしている経営判断を自覚していこう
自覚するとそれを改善していこうというサイクルが生まれてくるはず、これでより良いものになっていく

お金は使うとなくなるが、知識は使ってもなくならない
使ってもなくなるものではなく使ってもなくならないものを得ていこうという経営学の一派がある
それはエンジニアにもマッチするものであるだろう
なのでそれを掘り下げていく

知識獲得の3タイプ

知識獲得

1.教えてもらう学び

教える側に負荷が集中している
会社の教育とか、先輩、後輩

2.自分で行動しての学び

だから次に必要なのは自分で行動して学んでいく
エンジニアであればプログラムを実行して、バグを直して実行してを繰り返し学んでいく

行動の結果から学ぶ

サイクルを回して学んでいく
よくあるサイクル

3.知識の交換によって学ぶ

お互いに教えられる

知識の総量、分野が違うものから学び合うことができる
自分よりも知識が少ないものからも学ぶことができる
総量が少なくても違う分野を知っていてそれを交換できる

狭き門から入れ

限られた時間を大勢が学んでいるものにかけるのはもったいない

社外に交換相手を作ろう

同じ分野を勉強しているので別の情報を取れる

社外の勉強会に参加

一時的なグループでしかない
なかなか知識の交換になりにくい

知識交換のネットワークづくりをしていく

グループを作っていく
小さい非公式グループを作る

グループと聞くとイメージが大人数 それはただ目にしやすいから

質問に回答する例
人数が多いと質問者のバックグラウンドを把握して回答することが難しい
質問の文字だけ見て答える状況になってしまう

小さいグループだと質問者はあのプロジェクトをやっていたから〜ってことを使って知識の交換が円滑になる

答えられない場合 自分では答えられないけどあの人がわかるんじゃないかと紹介することができる
よく回答している人はわかるけど・・・なので小さいとそれを把握しやすくなり紹介することができる

ゲートを置く

小さいグループを作るには制限を作る
ゲートがない場合有益なら人が集まるが、得ることをするが与えることをしない そういう人はそのグループがなくなれば次に行く
効率を考えたら仕方ない

そういう形になるとリソースを食いつぶして行ってしまう

OSSコミュニティの二重性

自由にユーザーコミュニティに入れるがコミッターには条件がある
ものを与える人のみが入れるように

グループを自分で作ろう

あなたが入ることができてしかも小さいっていうものを探すのは難しい
最初は非公式で身近な人2、3人で構わない

互恵的コミュニティにするために
まずはあなたが「与える」
Give & Take

複数のグループに所属しよう

複数のコミュニティに所属することでパイプになる
Aで知ったことをBで教えることができる
何が仲介する価値があって何が価値があるかを判断する力も鍛えられる
ググって手に入る情報を共有しても意味がない

知識交換の必須条件

周囲が持っていない知識を提供して、持っていない知識を提供してもらう
その分野の専門家には知識で負けるが多くの分野をまあまあ知っているのでその専門家と対等に情報交換をできる

技術進歩による海面上昇

ググったら手軽に入手できる知識レベルが10年前より上がった
海面が上がっている
ググって手に入らない情報を持っていたら専門性と言える

マニュアルとか見てもわからないことがあったら、それを試したことによってわかったらそれはもう専門性のある知識
それを交換に使って行くべき
それをみんなブログを書いて行くのでまた海面上昇していくので注意

トリガー

時間が経ってから価値がわかることがある

時間が経った頃に思い出せるようなトリガーを用意して置く
1年後とかに通知とかをすると、それを話題に再度コミュニティを活発化したり

与える人を可視化して、その人たちだけでコミュニティを作って濃縮化したり 多くのことは失敗する
定着までは時間がかかるので再度活発化できるようにトリガーを活用する

行動して学ぶは多くの人が経験済み、見落とされがちなのは「知識交換」
これを構築するための方法を学び作っていこう

生存戦略 技術顧問/テクニカルアドバイザーとしての生存戦略

講演者

  • 是澤(元Speee)
  • 及川
  • 井原(ビットジャーニー)
  • 岸川(Realm)

社会人1年目

及川

デックという会社で営業サポートから その後Microsoft -> Google -> Increments 今はフリーで色々な会社を手伝っている

井原

1年目はジャストシステムで三四郎というWindowsのソフトウェアを作ってきた
そのあとYahoo Japan -> CookPad -> ビットジャーニー
開発から組織を作る側に移ってきた
技術顧問の提案が来て技術顧問を開始
10数社くらいを見ている

岸川

iOSデベロッパーをしていた
今はピクシブとかを手伝ったり
iOSのアプリ開発の設計周りを手伝ったり

1社あたりの稼働

及川

3つの契約形態を設けている

  • 月額ベース
  • 時給ベース
  • プロジェクト単位

最初は1、2ヶ月のもので契約して状態を見てから半年とかの契約にしている

井原

3ヶ月やってみて、良さそうと思ったら続ける
さっさと自分が辞められるようにしていく、自分に依存しないように

岸川

よくわからないときは3ヶ月くらいで始める
自分のメインの仕事を優先するので緊急対応などはできないということを対応している
多くて3つか4つくらいの掛け持ち
コードの相談が多くて裏を取ったり調べたり書くという試行錯誤の時間が増えるので、それ以上になるなら別の関わり方を考えなくて行けない

顧問は儲かるか

及川

結構たくさん食える
労働集約的な仕事
月額もどのくらい稼働時間か会社と決める
自分の時間を費やせばその分貰える

Googleでストックアワードがあったりするのでそれには全然足りない
肉体を酷使しても割に合わないとは考えている

井原

クックパッドで貰ったときよりも最大で5、6倍貰えた

岸川

時給換算すると高いが、案件増やしたりしてもコンテキストスイッチも大変だし自分の仕事も大変だしで苦労は多い
そういう仕事ができるならそのまま会社員でも稼げるのではと考えている

顧問に向いている人

及川

引き出しを引き出して行く
その引き出しを満たしていくことが重要

井原

何かしらやり遂げた人にその経験がある人
その知見を共有できたり、更に今はそれでいいのかということを考え学び続けられる人
出せるものもなくなっているので気をつけなくては行けない

岸川

最適解を導ける人
偏っていてはいけない
誠実であること、あまり大げさにいったりしなかったり

メンタリングやコーチの力をどうやって鍛えたか

及川

Microsoftのマネジメントトレーニングがめちゃくちゃ優秀
実際にここだけの秘密だよってことで実際の苦労話を吐露したり、実際のロールプレイを行なったり

井原

特別勉強しているわけではなく、直感になっている
なのでその感性を磨いて行く
無理して磨くなら他のことを伸ばした方がいいのではないか

岸川

エンジニアなどは各々力関係がわかるのでそこを理解して行く

開発手法、ロールプレイなどの学習の機会をどうやって作るか

及川

知り合いづてで実際の現場を見せてもらう
知識を切り売りしていない
その知識を全部持っているというわけではなく、現場と一緒に考えて行くというスタンスでやるので学ぶ場にもなる

井原

自分の言ったことが全て正しいというわけではない
同じように一緒に考えようというスタンスでやるので学ぶ機会になる

顧問受け入れる側としての体制

及川

早めに終わるところとかうまくいかないというときは問題が明確ではない
自分から提案していくというよりは状況を聞いてヒアリングしてやったりスタイルなので明確でないと困る
抽象的なように話されても無理、絶対に具体的に詳しく話さないとアドバイスできないのでNDAの契約をするので話してほしい

井原

自分が一番できると思っている社長がいると困る
エンジニアリングを信じてくれる経営陣であってほしい
経営陣の鶴の一声で決められるのはやっていけない

岸川

質問だったら困っていることなど問題設定が明確であるとありがたい

顧問とかアドバイザーをやっていて得られるもの

及川

目指してなっていたものではなく結果的になっていた
主体性を持ちづらい
結局人の会社であり人のプロダクトを作ったりになる
製品にサインするのが好きなのだがそれができない

いくつもの会社を見るのでそれぞれの知見が溜まる

井原

会社員は楽勝、安心
色々な会社を観れるのはやっぱり知見が溜まるのでいい
主体性を持って取り組めるものを心の拠り所があるといい

岸川

上記二人と同じような感じ
やっぱり会社員の方が時間はある

最後に

岸川

あまり顧問はソフトウェアエンジニアとしてのキャリアとしてはおすすめしない
けどやっぱり知らない世界を知れるのでいい
簡単なら前の会社とかを観たりとか

井原

自分からは行かない、誘われたら顧問をする
顧問として誘われるということがあるのは、そういう経験、信頼を残せたということなのでいいこと

及川

兼業でやっていくのはいい
コミュニティでの活動をするでもいい
たまたまそれが技術顧問だったりしただけ
それを目指していくのは違う

CROSS SESSION エンジニアにとっていい制度ってなんだろう？

講演者

背景

VGの背景

新規事業など若手しかいないチームがあった
ただ評価の観点で正しく評価できない背景があった
なので他の部署のエンジニアが評価する制度を作っていった
社外の人を呼んでいるのは客観的な視点をもらえることがいいことだということを浸透させ文化にしようと考えて進めている

クックパッドの背景

今は手厚い研修生度を用意していない

自分として色々やってこれたのは、何かやりたいと思った時に手助けしたり邪魔しない環境がよかったから
そういうことを会社が実現していくのがいい環境になっていくと
一押しするような環境をやってあげるようにしている

メルカリの背景

新卒の一律給与はやめた
新卒の一律給与はおかしい
中途と同じレベルで来る人もいるのでそれはおかしい

フレックス制などの制度

VG

裁量労働制
チームごとにデイリーミーティング、時間はそれぞれチームごと
朝こないことはなんで困るんだということを考え、それをチームとかで考えて振り返りを行いつつより良い方向を探って行く

ビジネス側のゴールはビジネスを成長させることと考えている方が多い
なのでエンジニアの価値の出し方を聞くとそういう働き方もあるねって話になったりする

Face to Faceの方がやっぱり生産性が高い
でも難しい

クックパッド

コアタイムなしのフレックス制度
グローバル展開して行く中でタイムゾーンが合わない
チームごとにいい時間が別なので同じ時間を設定しても意味ない
チームごとに決められるようにゆるくしている
マネジメント側としてはみんな顔を揃えていてほしい
でも開発フェーズとかは縛っていてはよくないと考えている

エンジニアだけフレックスだった時は反発があった
今は全部フレックスなので大丈夫
営業で外出が多い人とか子供がいる人にもとても役立っている
家でもセキュアに仕事できる環境を用意して、合理的に働けるようにする

リモートワーク
運用は難しいと思っている
部長に許可もらったり、家庭の事情で遠くで働かなくちゃ行けない人とかはしている人がいる
会社に来てほしいとは個人として思っている

メルカリ

フレックスタイム制
全職種共通
会議とかはなるべくコアタイムで

会社としてはリモートワークはOKとしていない
やむを得ない理由があればOKなときも

国外で開発拠点もあるので実質リモートワークではある

エンジニアの評価制度

VG

定量化は難しいと考えている
1時間半の時間に複数に関わり、更に事前資料を読み込む時間を確保して評価に取り掛かって行く
定量的なものでやるよりも柔軟性を重視しようという方向でやっている

CTOになったときスピード重視の傾向が強いと思った
テストやCIなど
その結果技術的負債が溜まっていっていた
人事からエンジニアが評価に納得いっていないという相談から始まった

最初は昇格候補者だけに評価を実施していった
そのころはトップがやっていて、結果的にいいねという話が上がって来たので全社で進めた
小さいところから始めて行くのは重要だと実感した

評価者二人が書いたレポートはGithubに上がり閲覧可能
なのでかなり真面目に書かなきゃいけない
評価者がもっといい評価したいということで参考するために公開することにした

評価されるように制度をハックするようにしてほしい

評価レポートは公開される前に全部CTOが見ている
かなり負担にはなっている

クックパッド

技術力や生産性を数値化しようというのは難しすぎて無駄
そういうことよりも他のことを

年2回部長とテックリードが評価していく
今、ヒントをあげるということを試している
評価期間が長いので5ヶ月前って何したんだっけっていうことがあった
なので毎月全員分良かったこととか通信簿みたいなものを書いている
毎月1on1をして評価に加味していく形にしている

部長などが本ににフィードバックしていく

最近は本人にすら見せない方がいいんじゃないかと思っている
馴れ合いになってしまう
仲良くしてるけど仕事できないって思ってるとか知られるのは微妙
それだったら部長だけに知らせるとかの方がいいんじゃないか

グレード制

  • 課題発見
  • コミュニケーション

などの軸がある

メルカリ

技術の伸び幅や影響力がどう変わったかを観ている

1on1でフィードバックしていく
目的になってしまうのは嫌

All for oneという指標があり、それも評価に入るので円滑に進める力も評価に入る

社内エンジニアの教育制度

VG

ない
入って来た人にシステムやサービスの説明はする
日々の業務でレビューとかをしていく

レビューや注意をできる文化を作ることが大事

語学は必要に応じて程度の支援
事業責任者がMBAとか受けにいったり

クックパッド

ない
当たり前のものはある
最近は海外カンファレンスなど

教育で一番大事なのは機会を与えること
会社がどうやって与えるか
CTOの耳に入るようにしている

若い人は感度も高く会社から押し付けるものではない
なので自分で見つけてあとは会社が後押ししてあげる
やってるんなら支援してあげるよくらいの距離感が大事

英語などのサポートはメルカリほど手厚くはない
いちなり勉強しなければいけない環境をどうやって作るかを考えている
英語勉強したいとかいってないでいきなりブリエステルに送り込むとか

メルカリ

ない
メンターをつけてサポートしたり社内で有識者がいたりして勉強会を行ったり

知的好奇心が多い人を採用していく
新卒研修、何かのアプリを作ってリリースするとかを考えていたが、OJTで現場で働くことを検討中

英語しか話せない人も増えて来ているので語学サポートをしてきている
DMM英会話や通訳サポートの部署とか

中途入社のエンジニアに研修しているか

VG

このチームはこういうサービスでこういうシステムでやっているか

エンジニアの給料を下げたことあるか

クックパッド

下げるからプレッシャー感じてというよりはもう辞めてに近い
業界が業界なので他の会社でもやっていけるから

VG

下げたことはある
けどそこから成長していったということはなかった
部署異動などを試して見た結果下げたりするので難しい

C#(.Net Framework)でStackExchange.Redisを扱うときの例外を想定する

Redis C#

単純に使うだけ

まずNugetでStackExchange.Redisをインストール。

using StackExchange.Redis;

Azureの記事だけどこれが参考になる。

docs.microsoft.com

IDatabase cache = ConnectionMultiplexer.Connect("localhost").GetDatabase();
cache.StringSet("key", "value");
string result = cache.StringGet("key");

例外

Redisを使う以上、あらゆる例外に向き合わなければいけない。

C# Redis Samples · GitHub

ここではString型にJSONが入っていることを想定し値をオブジェクトにマッピングするときに、想定しうる例外を各々キャッチする処理を書いてみた。
ここに挙げたコードを元に発生しうる例外を挙げてみる。

接続失敗

単純に接続情報が間違えていた時やRedisが落ちた時。
Redisの操作がある場合、一律でRedisConnectionExceptionをcatchしておかないと例外が発生し落ちる可能性がある。

try
{
    cache = Connection.GetDatabase();
}
catch (RedisConnectionException e)
{
    WriteException("接続失敗", e);
    return;
}

キーが存在しない場合

存在しないキーをStringGetメソッドに投げるとRedisValue型でNullを表すような値が返ってくる。
それをDeserializeObjectに投げると当然例外が発生する。
ここではArgumentExceptionになる。

try
{
    var notExist = JsonConvert.DeserializeObject<EmployeeDto>(cache.StringGet(key));
}
catch (ArgumentException e)
{
    WriteException("キーが存在しない場合", e);
}

String型ではない別の型で保存されていた場合

String型が欲しい時にハッシュ型などの違う型で値が格納されている場合は一律でRedisServerExceptionが発生する。

key = "other-type";
HashEntry[] hashEntries = {
    new HashEntry("a", 1),
};
cache.HashSet(key, hashEntries);
try
{
    var hash = JsonConvert.DeserializeObject<EmployeeDto>(cache.StringGet(key));
}
catch (RedisServerException e)
{
    WriteException("String型じゃない場合", e);
}

パースするJSONとマッピング対象のクラスが一致しない場合

下の例だとマッピングしたクラスのプロパティはNullで何もマッピングされない。
なのでしっかりNullチェックをしないとNullReferenceExceptionが発生する。

key = "anonymous";
var objDto = new { T = "a" };
cache.StringSet(key, JsonConvert.SerializeObject(objDto));
var eAnonymous = JsonConvert.DeserializeObject<EmployeeDto>(cache.StringGet(key));
try
{
    // そのままオブジェクトのプロパティにアクセスするようなメソッド
    Write(key, eAnonymous);
}
catch (NullReferenceException e)
{
    WriteException("パースするJSONとマッピング対象のクラスが一致しない場合", e);
}

中身がJSONではなくただの文字列の場合

JSON形式で文字列が保存されていない場合Json.Net側でJsonReaderExceptionが発生する。

key = "string";
var stringDto = "test";
cache.StringSet(key, stringDto);
EmployeeDto str = null;
try
{
    str = JsonConvert.DeserializeObject<EmployeeDto>(cache.StringGet(key));
    Write(key, str);
}
catch (JsonReaderException e)
{
    WriteException("中身がJSONではなくただの文字列の場合", e);
}

中身が配列の場合

中身が配列の文字列を格納したString型の場合Json.NetのJsonSerializationExceptionが発生する。

key = "array";
var badJsonDto = "[1, 2, 3]";
cache.StringSet(key, badJsonDto);
try
{
    var arr = JsonConvert.DeserializeObject<EmployeeDto>(cache.StringGet(key));
    Write(key, arr);
}
catch (JsonSerializationException e)
{
    WriteException("中身が配列の場合", e);
}

まとめ

こんな感じで数多の例外が発生する可能性がある。
防御的に各々全ての例外をcatchしてもいいのだが、格納されている型が違うだとかJSONの形式として正しい形式で値が入っていないとかは値を保存する側のプログラムのバグや仕様把握漏れになると思うので取得側では契約的に例外をcatchしなくてもいいんじゃないかと思っている。
でも間違えられた瞬間システムが落ちるので悩みどころ。

とりあえず最低限としては接続確認としてRedisConnectionExceptionと、キーが存在しないとき用に値のNullチェックあたりをして、そこからはシステムの要件と相談という形になりそう。

Vue.jsとか使って時間管理マトリックスのWEBアプリを作ってみた

JavaScript Vue.js

Time Management Matrix

作ってみた。リポジトリは下記。

github.com

Vue.jsとかSVG周りの勉強がてらなんか作るかーと思って作ってみた。
時間管理マトリックスってなんぞや？って人は下記を参照されたし。

www.franklinplanner.co.jp

概要

f:id:igatea:20180307160457p:plain

左下に入力項目の表示非表示ボタンがある。
ボタンを押すと左上に可変の入力欄があり、そこに項目名を入力、重要度と緊急度を数値の入力欄かスライダーで変更できるようにしている。
各値が変更されればそれに合わせてSVGのtext要素の値、座標も変更するといった感じだ。
今はLocalStorageに変更した値を保存するようにしているので再度開きなおしてもそのまま前回の画面のまま編集できるようにしている。

見た目はもっと良くしたいなーと思いながらも今の優先順位的にそこまで入れ込む気はないので手は付けず。

ぶつかった問題とかTipsとか

初めてGithub Pages使ってみた！

各リポジトリのSettingsからGitHub PagesのSourceを選択するだけでページを公開することが出来て便利。
基本的にはmasterブランチのファイルが公開されるが変更する方法もあるっぽい？（ここよく分かってない）

masterブランチにビルド後のJSファイルも含める形になる。
仕方ないとは思うけど何かいい方法がないかな。

あとmasterにマージしてからファイルが反映されるまで少し時間がかかる模様。
体感数分。

スプレッド演算子がSyntaxErrorになる

VuexのVueコンポーネントへのマッピング時の...mapState等がSyntaxErrorになった。
最終的にoptions取り除いて.babelrcを作成した。

// before
{
    loader: "babel-loader",
    options: {
        presets: [
            ['env', {'modules': false}]
        ]
    }
}

// after
{
    loader: "babel-loader",
}

{
  "presets": ["es2015"],
  "plugins": ["transform-object-rest-spread"]
}

webpack4のモード

webpack4からはmodeを指定することが出来るようになっていて、そこで開発用かプロダクション用か切り替えることが出来る。
もちろんwebpack.config.jsにmodeを追加することも出来るがwebpackコマンドの引数に追加することも出来る。
なので、下記のように指定してあげるとnpm run ***で使い分けが出来て便利。

"scripts": {
  "dev": "webpack --mode development",
  "build": "webpack --mode production",
}

LocalStorage

Local Storageには文字列で登録されるので、そのままオブジェクトを突っ込むと[object Object]となってしまう。

const obj = {x: 1, y: 2};
localStorage.setItem('items', obj);

localStorage.getItem('items');
// [object Object]

なので適宜、設定時と取得時にJSONの変換を行う必要がある。

// 設定時
const obj = {x: 1, y: 2};
localStorage.setItem('items', JSON.stringify(obj));

// 取得時
JSON.parse(localStorage.getItem('items'));
// {"x":1,"y":2}

Vue.js、Vuex

Vue.jsのwatch

監視する値が何回層かの配列やオブジェクトだったときにウォッチャではdeepというプロパティを定義してtrueにすると内部の値も監視対象としてくれます。

data() {
    return {
        items: [
            {x: 0, y:0},
        ],
    };
},
// 内部監視あり
watch: {
    items: {
        handler() {
            // 処理
        },
        deep: true,
    }
}

// 内部監視なし
watch: {
    items() {
        // 処理
    },
}
SVGの描画時マウントされていないために参照できない問題。

jp.vuejs.org

ref の登録タイミングに関する重要な注意事項として、参照自体は、render 関数の結果として作成されているため、最初の描画においてそれらにアクセスすることができません。それらはまだ存在しておらず、$refs はリアクティブではなく、従ってデータバインディングのためにテンプレートでそれを使用すべきではありません。

地味に躓いた。
text要素の幅を取得して、背景にその幅分のrect要素を広げたかったのだけど、うまくいかなかった。

最終的にはVueのmouted()でフラグを有効にし、それの真偽で処理をするようにした。

data() {
    return {
        isMounted: false,
    };
},
mounted() {
    this.isMounted = true;
},

// ~~~~~~~~ //

if (this.isMounted) {
    // 特定要素の幅取ったり
}
Vuexの各アクションなどのキー名

ミューテーション · Vuex

Vuexでミューテーションやアクションのキーに定数を使用することを提案している箇所がある。
これは本当に好みの問題かもしれない。
一応使って実装してみた。
こんな感じ。

// types.js
export const set    = 'set';

// mutations.js
import * as types from './types';

export default {
    [types.set](state, items) {
        state.items = items;
    }
}

// app.vue
this.$store.commit(types.set, items);

// 文字列のままだと
this.$store.commit('set', items);

定義名はmutationとaction、getterに適用。
gettersはプロパティに生えるから使わなくてもいいかもしれない。

 this.$store.getters[types.initialItems];
 this.$store.getters.initialItems;
VuexのmapStateとmapGettersを産出プロパティに

通常産出プロパティにスプレッド演算子の関係でmapStateとmapGettersは設定できないんだけど無理やりやってみた。
同じキー名のプロパティがあった場合、後方の値で上書きされるので注意。

computed: Object.assign(mapState([
    'items',
    ]), {
        ...mapGetters([
            types.urgentPosition,
            types.importantPosition,
        ]),
    }),
}

これからやってみたいこと

このアプリは遊びで試してみたかったのでそんな時間をかけるつもりはないもののやりたことは色々ある。

  • 文字が枠外に出たりするのでちゃんと文字列が枠内に収まるように
  • 型の導入
  • LocalStorage以外にサーバーと連携してDBに保存するとか
  • なんかもっとかっこいい見た目にしたい！！！

ぶっちゃけ見た目や使い勝手悪すぎて自分のUI周りの実装力の低さを思い知ってしまった。
ここはこれからどれだけ勉強するか悩みどころ。

今までの参加した勉強会のメモを公開した

勉強会

タイトルの通り。

とあるところでキャリアの成長に関してもっと情報公開して恥をかいていこうよということを言われ、まずは今まで参加した勉強会のメモとかを公開していくことから始めようと思った次第。
かなり雑な部分もあるがそこらへん指摘貰えれば直していきます。
まとめ終わったので再度公開します。

まとめてみて分かったが熱量のあるものとないものでメモの質に大きく差があるなあと思った。
これからは公開することも意識してメモの質を上げたい。

2018年の目標

2018年に入って早2カ月。
今更ですが今年の目標を考えたいなーと。

なんで今更？

実は年末年始の時からこの時期だと思ってた。
そう、転職先が決まった時だ。

無事、4カ月という長い無職期間を経て転職先を決めた。
年末年始、人々が目標を書いているのを横目に僕は転職先が決まったら書こうと思ってた。

理由としては、転職先によって達成したい目標、達成しやすさって変わると思う。
それは事業的なミッションだったり、技術的な成長だったり、個人の趣味や人生についてだったり。
職場によってそれを達成する土壌があったり色々な要素が絡み合った上で目標を決めようと思ってた。

目標

  • 一週間に一回は技術系記事を書く
  • 二カ月に一回は登壇
  • Microsoft MVPを受賞する
  • TOIEC 600点

一週間に一回は技術系記事を書く

一週間仕事なり趣味で開発していれば気づきやつまずいたりしたときの対処など書くことはあるだろう。
無ければ技術的なことが出来ていない可能性が高い。
そういう自戒も込めつつ一週間に一回は記事を書けるように励みたい。

二カ月に一回は登壇

アウトプットの機会を増やしたい。
これは前述の記事と同様に気づきなどの棚卸の面と、記事を書く技術とは別の発表技術を学んでいきたい面もある。
ある程度露出を増やしつつ技術的に人に触れ合う機会も作りたいという面もある。

あと今まで登壇をしたことはあったけど身内に近いコミュニティや初心者向けが多かった。
なのでカンファレンスなどに登壇も目指していきたい。

Microsoft MVPを受賞する

これは前述の二つのアウトプットを継続的に行って目指していきたい。
Microsoft MVPとはいわゆる技術発信を行ってる人に対する表彰制度みたいなものである。
自薦他薦問わずエントリーでき、受賞すればMicrosoftから特定のソフトの提供や限定イベントへの参加権などを特典として貰える。
気になったらググってほしい。
特典が目的というわけではないが一つのアウトプットしていった結果としての目標としたいと思う。

TOIEC 600点

これは個人的なコンプレックス。
エンジニアでありながら英語が全くできないのでこれを克服していきたい。

全くできないというのは具体的にどんなレベルかというと、2015年12月に受験したときのスコアは355点である。
本当に大学を卒業しているんだろうか。僕のキャンパスライフは夢だったのかもしれない。
英語のページを見るときには常にGoogle翻訳を横に並べている。
エンジニアとしては英語で書かれた第一ソースを読めるか読めないかは成長に大きく変わってくる。
ここは努力していきたい。

最後に

目標立ててみた。
年末だけじゃなくて時折見返してうまく達成していこうと思う。
転職したばかりは忙しくて大変そうだが頑張っていこう。

Webpack4ではCLIが切り離された

JavaScript

Webpackの4からCLIが別に切り出された。
なのでそれ以前のWebpackと同じように実行するとエラーが発生する。

> [project name]@1.0.0 dev [working directory]
> webpack

The CLI moved into a separate package: webpack-cli.
Please install 'webpack-cli' in addition to webpack itself to use the CLI.
-> When using npm: npm install webpack-cli -D
-> When using yarn: yarn add webpack-cli -D
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! time-management-matrix@1.0.0 dev: `webpack`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the time-management-matrix@1.0.0 dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\[user name]\AppData\Roaming\npm-cache\_logs\2018-02-28T18_56_30_320Z-debug.log

github.com

言われた通りインストールしてみる。

 npm install webpack-cli -D

ちなみに-Dは--save-devらしい。
npm installのhelpに出てこないので知らんかった。

これでまたwebpackコマンドを打つとビルドが実行できるようになる。