旧gaaamiiのブログ

間違ったことを書いている時があります。コメントやTwitter、ブコメなどでご指摘ください

Angular2のウェブフロントエンド開発に携わっていて難しいと思うことなど振り返り

ウェブフロントエンド開発に携わらせてもらっていて、なかなか大変です。てんやわんやでひたすら頑張るしかないという状況で、ブログを書いている場合ではないと思います。しかしせっかく頭を抱えるような難しさを感じているので、それを新鮮なうちに言葉にしておきたいと思いました。

続きを読む

「長岡先生の授業が聞ける高校数学の教科書」を買った

文系エンジニア数人で一緒になって高校数学をやり直そう!という話に乗っかり、教科書を買いました。

そういえば、長岡先生の教科書って前にトミーさんがバズったときに使ってたやつっぽい。

tkykhk.hatenablog.com

高1からちょっとずつやり直していきます。

f:id:shgam:20161113224821j:plain

#ng_jp 主催のAngular 2 ハンズオンに参加してきました

connpass.com

  • 主催:ng-japan
  • 会場提供:レバレジーズ株式会社

という感じのAngular2ハンズオンへ行ってきました。ハンズオンって言葉の意味を実はよく知りませんが、たぶんワークショップとかと同じようなものだと思ってます。ここ何ヶ月か仕事でAngularを使っていて基本的な使い方についておさらいをしたかったので参加しました。

続きを読む

キュレーションサイトには無くてQiitaにあるもの

以下の記事を読みながら、そうだよなあ...見た目だけ立派だけど質が悪かったり無責任な情報の断片寄せ集め記事ってたくさんあるよなあと再認識しました。僕も間違った情報に騙されることがよくあります。

bylines.news.yahoo.co.jp

Qiita最高

ところで、ソフトウェアエンジニアの仕事は情報収集がけっこう大きな割合を占めます。書籍による情報と自分の想像だけでプログラムを書くのは至難の技です。

そんな時、情報を集めるときに信頼できるものとして真っ先に思い浮かぶのがQiitaです。僕はQiitaが大好きです。前職ではQiitaにアクセスできなかったので辞めました(それほど過言でもない)。

Qiitaを閲覧したりQIitaに投稿していると日々最高だと思うので、ソフトウェア・エンジニアリングの分野だけでなく、各分野の専門知識がQiitaみたいなものの上で共有されるといいなあと思います。しかし、なぜそんな風に感じられるのでしょうか。僕個人の完全な主観で、そもそもメディアとして違和感を感じるキュレーションサイトと、常日頃から最高だと感じているQiitaの間にある違いについて整理しておきたいです。

編集リクエス

Qiitaにも間違った情報はたくさん載っています。誰でも登録・執筆できるのだから当然です。しかし、Qiitaでは編集リクエストという機能があります。これは執筆者以外のQIitaユーザーが、元記事の一部分を編集し、それによって記事を更新してくれとリクエストすることができる機能です。

f:id:shgam:20160911022625p:plain

キュレーションサイトにはこのような機能はありません。僕の知っている限り、キュレーション記事の執筆者は記事単価ベースで記事を生産しているに過ぎない場合が多く、その後の更新にまで気を配っているようには見えません。少なくとも、全くの第三者がその記事を更新する(させる)仕組みは提供されていません。

所属企業の表示

Qiitaの執筆者がQIitaを利用している会社に所属していると、その所属企業のアイコンが表示されます。閲覧者としては判断材料の一つとして心強いですし、執筆者としては会社のイメージにも影響することを意識して、間違った情報は書きにくいです。

キュレーションサイトで、執筆者の所属企業を表示しているものが見たことあるでしょうか。僕はありません。

議論(コメント)

個人ブログなんかだとスパムが嫌でオフにしがちなコメント機能ですが、Qiitaのコメント欄は活発に、かつまともに機能しています。エンジニアが他人が書いた間違った情報に対してツッコミを入れるのは、間違った情報に騙されて時間を無駄にした経験があるからでしょう。

対して、多くのキュレーションサイトではコメントという仕組みが提供されていません。そのサイト上で記事に対する議論を見ることはできず、真偽の程を見定めるられるかどうかは読者のリテラシーや知識にかかっています。URLをTwitterはてなブックマークで検索することくらいはできますが...。

Wikipediaは?

と、ここまで書いておいて専門記事の執筆に向いているウェブサイトをもう一つ思い出しました。Wikipediaです。分野問わず有用な情報がたくさん蓄積されています。

しかし、Wikiの仕組みやコンテンツ量と質は素晴らしいですが、記事が中心にありすぎて議論や著者性が見えなくなっているような雰囲気があります。間違った情報と正しい情報の見分け方が難しいという点で、ニッチな情報についてはキュレーションサイトと変わらないような気もします。ページを開くと視認性が異常に高い文字で寄付をせびられるのも気分が悪い。あと、書く側として気持ちの良いものには見えないのに、なんであれだけの情報が集まっているのか不思議です。

まとめ

このブログ記事の冒頭で参照した記事(医療情報に関わるメディアは「覚悟」を - 問われる検索結果の信頼性(朽木誠一郎) - 個人 - Yahoo!ニュース)では、医療分野で無責任な情報が検索エンジンを通じて、それを本当に必要としている人に届いてしまう危険性について書かれていました。著者は最後に、検索結果ページの進化に期待しています。

検索結果を司るGoogleが、医療のような特定の分野の検索結果について、独自のコンテンツ提供を推し進めていくのであれば、このような問題は、いずれ一定の解決を迎えるのかも知れない。

僕も同じ意見です。とはいえ人が検索エンジンを使う限り先の問題解決にはならないので、やはりQiitaのように正しいコンテンツ作成を促す仕組みの上で作られた記事が、(Googleにかぎらず)各検索エンジンでより評価されていけばいいなあと思いました。

余談

Googleで表示される独自コンテンツ、指摘できるっぽい(さすが)。

f:id:shgam:20160911021343p:plain

余談その2

公式ドキュメントを主な情報源にしているような優秀なエンジニアの中には「Qiitaもろくなもんじゃない」という人もいるみたいなんですが、じゃあQiitaにStackoverflowのようにdownvote(-1投票)機能が付いたらどうなるんでしょうか。おそらく僕みたいな雑魚エンジニアは的はずれなことを書くことを恐れて、投稿しなくなります。

なんというか、キュレーションサイトみたいに出しっぱなしの無責任記事でもなく、downvoteを実装して生煮えの情報が無言で消えていく代謝の悪い未来のQiitaでもなく、間違った情報は更新あるいは削除されることを前提としていて、情報の確度も含めて正しく伝わるようなメディアが良いんじゃないかと思っています。あくまでも理想ですが...。

関連

shgam.hatenadiary.jp

ターミナル作業をGIFにするツールとしてasciinema2gifがとても良さそう

よさそう。

github.com

Asciinemaとは

ターミナル作業をレコーディングできるツールです(@_ayato_pさんが使ってるの見て知りました)。インストールして使うと、以下の様なものが出来上がります。

でもこれ、この表示するためにブログにスクリプトタグをはっつけてる。

<script type="text/javascript" src="https://asciinema.org/a/5upf1fujvze7z81skh3k8phoy.js" id="asciicast-5upf1fujvze7z81skh3k8phoy" async></script>

はてなブログだと許されてるけど、Qiitaとかだと実行してくれなそうなので、できればgifの方が嬉しい。調べると、asciinema2gifというドンピシャのツールがあった。

asciinema2gif

github.com

Homebrewで入れてすぐ使える。

$ brew install asciinema2gif
$ asciinema2gif https://asciinema.org/api/asciicasts/5upf1fujvze7z81skh3k8phoy

できた。

f:id:shgam:20160904035703g:plain

余談

埋め込んだAsciinemaのスクリプトがやっている描画を見てみると、Reactを使ってDOMをガリガリ書き換えてる。面白い。

作業が遅い問題

どうしたもんか。。

開発環境

  • 工夫はしてるつもりだけどファイル検索とかタグジャンプがいまいち
    • これはすぐ改善できそう

考え方など

  • 一つの問題に集中できてない(問題を適切に分割できていない)
  • 機能とコードが頭のなかで結びついていない
    • ちゃんと記憶すれば解決
    • 製品を開発・保守する者として、記憶する義務があると考えるくらいがちょうど良さそう
  • アプリケーションコードの層分けがどうされているのかなど抽象的な理解が足りない
    • 新しい機能を実装するときに、そのコードをどこに書くか(なんとなくではなく)明確に決められるべき
    • 理解ができていない時に、関係ないところまで含めてコードをコピペしてしまうようなことがある

作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。

検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。

だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。

ネット上で英語でできそうなことリスト

英語でインターネット読み書きできたらどんなに楽しいだろうなと思う。現状は読みの方でしか利用できておらず、とても歯がゆい。今の自分でも頑張れば英語でできそうなことを挙げてみる。

OSS関連

  • 自分のOSSを出して目につきやすいような工夫をする
  • 自分が使用しているソフトウェアに関して

掲示

  • redditでコメントする
  • Stackoverflowで回答をする

スクリーンキャスト

  • 作ってみた系など

情熱があればいつかできるかもしれない

  • 英語記事の著者にコンタクトを取って翻訳に取り組んでみる

作業計測について

日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。

作業時間

現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。

  • チケット
  • Issue
  • Pull Request

そして、それぞれ関係性がある。

  • チケットとIssueとPull Request は多くの場合1対1対1になる。
  • チケット無しでIssueとPull Requestが作られる場合はバグ修正や途中で気付いた改善点など、元々はスケジュールに無かったもの。

なので、1日の作業を計測するとしたらIssueごとの作業時間を測るのが良さそう。作業時間を測るのには、toggl buttonというChrome拡張があるのでそれを使えばいい。

作業量

では、作業量の計測対象はなんだろう。

  • Issue(閉じることができたやつ)
  • Commit
  • URL

閉じたIssueやCommitはコーディングの成果そのものなので、これを作業量として見るのは違和感ないと思う。

目に見えなくなりがちなのがコーディングする以前の調査量だ。何か作りたいけど実現方法どうしようか。よし調べるぞ。〜〜1時間経過〜〜。みたいなのはよくあると思う。コーディングはもちろん、調査も作業だと考えていいはずだ。

ではこれはどうやって測ればいいのか、と考えてみると、URLというのが計測対象の1つになり得ると思った。論文や本の参考文献リストのように、その日の作業量を表すものとして参考URLが並んでいれば、なかなかやった感があって気持ち良さそうだ。

作業時間
Issue#56 4時間00分
Issue#57 3時間30分
Issue#58 1時間30分

作業量
Issues: 2
commits: +355 −39
URLs: 38
- http://example.com/fieoajfi
- http://example.com/hgoehoge
- http://example.com/fioawjio
- http://example.com/fiaojwfie
- http://example.com/goe
- http://example.com/iofjeai

こういう数値をまとめて出せるようにしておくと、いろいろ学びがありそう。ただ、この数値で同僚のエンジニアと比較されるみたいなことになるとストレスが高まりそうなので良くなさそう。自分の作業時間見積もりの不正確さやざっくりとしたパフォーマンスを知る目的に確認するのであれば良さそう。

ライブラリのサンプルをCodePenやjsfiddleで検索すると捗る

転職して1ヶ月は内製のサポートツール周りなどを触らせてもらっていましたが、8月からはウェブフロントエンドの方にコミットさせてもらっています。Angularのデータバインディング周りに何度もハマっていて楽しいです。

フロントエンドの開発作業で、新たな機能をつくるときにはまずそれ相当のライブラリがあるかどうか調査することが多いと思います。しかしそれが見つかったとしても、僕のように頭が弱く英語力が低い人間にとって、ライブラリの扱い方をGithubのREADMEからすぐに把握するのはなかなか大変です。そのため、さっと動くサンプルを見つけることがとても重要。

そこで、http://jsfiddle.nethttp://codepen.io などといった、フロントエンドエンジニアのお絵かきサイトみたいなものがあることを知りました。ここで検索すれば、(そこそこ人気のあるライブラリなら)何かしら自分のニーズに合ったものが見つかりそうです。

f:id:shgam:20160806124829p:plain

jsfiddle.net

http://codepen.io/codepen.io

参考

qiita.com

転職3週間振り返り

転職して3週間が経ちました。少し振り返ります。 Twitterでは転職したいけど迷ってるという方も見かけるので、こういうことを(会社の迷惑にならない範囲で)こまめに振り返って伝えていきたい。

前職から変わったこと、感じてること

  • 自由が増えた(開発環境や勤務について)
  • 開発が速い(新機能の企画からリリースまでが1〜2週間とか)
  • 製品に対する反応がダイレクトに分かる
    • 一夜の障害がAppstoreのレビューに如実に現れたりする
    • 良い反応も見れる。(自分はさておき)サービスが社会のお役に立ってる感がある。
  • テスト自動化へのモチベーションが高い
  • 同僚のエンジニアのレベルが高い

個人的な課題

個人的な課題たくさんあるので技術的なこととそれ以外でまとめる。

技術的なこと

技術的なこと以外

  • アウトプット少ない
    • 自分の存在価値みたいなものを出せていなくて焦ってる
    • 明らかにこうした方がいいと思うということは共有したりプルリクで投げたりしていきたい
  • 立ち位置
    • 何エンジニアになろうとしているのかが自分でも不明瞭。
    • 正直何でもできるようになりたいけどそれでは中途半端なことになりそうでもある
  • 既存機能のデータをどこでどう持って、どのように出し入れしているのかを把握できていない
    • これがわかっていないとディレクターの方にマスタデータのcsv渡すときなんかに時間がかかる
  • 砂場を準備できていない
    • 業務で扱う技術領域で趣味プロダクトみたいなものを作って、壊せるオモチャとしてプライベートで運用していきたい( nekobito.github.io のリニューアル考えてる)
  • 時間の感覚が鈍い
    • いつまでに何ができるかという判断力が貧弱。
  • 仕様理解
    • ミーティングなどで、話についていけなくなる瞬間がある。おそらく自分でもっとアプリ使った方がいい。

関連

(他のエンジニアの方の転職その後エントリみたいなやつ大好物です)