これの続編(?)です。酒を飲みながら書いています。
続きを読むキュレーションサイトには無くてQiitaにあるもの
以下の記事を読みながら、そうだよなあ...見た目だけ立派だけど質が悪かったり無責任な情報の断片寄せ集め記事ってたくさんあるよなあと再認識しました。僕も間違った情報に騙されることがよくあります。
Qiita最高
ところで、ソフトウェアエンジニアの仕事は情報収集がけっこう大きな割合を占めます。書籍による情報と自分の想像だけでプログラムを書くのは至難の技です。
そんな時、情報を集めるときに信頼できるものとして真っ先に思い浮かぶのがQiitaです。僕はQiitaが大好きです。前職ではQiitaにアクセスできなかったので辞めました(それほど過言でもない)。
Qiitaを閲覧したりQIitaに投稿していると日々最高だと思うので、ソフトウェア・エンジニアリングの分野だけでなく、各分野の専門知識がQiitaみたいなものの上で共有されるといいなあと思います。しかし、なぜそんな風に感じられるのでしょうか。僕個人の完全な主観で、そもそもメディアとして違和感を感じるキュレーションサイトと、常日頃から最高だと感じているQiitaの間にある違いについて整理しておきたいです。
編集リクエスト
Qiitaにも間違った情報はたくさん載っています。誰でも登録・執筆できるのだから当然です。しかし、Qiitaでは編集リクエストという機能があります。これは執筆者以外のQIitaユーザーが、元記事の一部分を編集し、それによって記事を更新してくれとリクエストすることができる機能です。
キュレーションサイトにはこのような機能はありません。僕の知っている限り、キュレーション記事の執筆者は記事単価ベースで記事を生産しているに過ぎない場合が多く、その後の更新にまで気を配っているようには見えません。少なくとも、全くの第三者がその記事を更新する(させる)仕組みは提供されていません。
所属企業の表示
Qiitaの執筆者がQIitaを利用している会社に所属していると、その所属企業のアイコンが表示されます。閲覧者としては判断材料の一つとして心強いですし、執筆者としては会社のイメージにも影響することを意識して、間違った情報は書きにくいです。
キュレーションサイトで、執筆者の所属企業を表示しているものが見たことあるでしょうか。僕はありません。
議論(コメント)
個人ブログなんかだとスパムが嫌でオフにしがちなコメント機能ですが、Qiitaのコメント欄は活発に、かつまともに機能しています。エンジニアが他人が書いた間違った情報に対してツッコミを入れるのは、間違った情報に騙されて時間を無駄にした経験があるからでしょう。
対して、多くのキュレーションサイトではコメントという仕組みが提供されていません。そのサイト上で記事に対する議論を見ることはできず、真偽の程を見定めるられるかどうかは読者のリテラシーや知識にかかっています。URLをTwitterやはてなブックマークで検索することくらいはできますが...。
Wikipediaは?
と、ここまで書いておいて専門記事の執筆に向いているウェブサイトをもう一つ思い出しました。Wikipediaです。分野問わず有用な情報がたくさん蓄積されています。
しかし、Wikiの仕組みやコンテンツ量と質は素晴らしいですが、記事が中心にありすぎて議論や著者性が見えなくなっているような雰囲気があります。間違った情報と正しい情報の見分け方が難しいという点で、ニッチな情報についてはキュレーションサイトと変わらないような気もします。ページを開くと視認性が異常に高い文字で寄付をせびられるのも気分が悪い。あと、書く側として気持ちの良いものには見えないのに、なんであれだけの情報が集まっているのか不思議です。
まとめ
このブログ記事の冒頭で参照した記事(医療情報に関わるメディアは「覚悟」を - 問われる検索結果の信頼性(朽木誠一郎) - 個人 - Yahoo!ニュース)では、医療分野で無責任な情報が検索エンジンを通じて、それを本当に必要としている人に届いてしまう危険性について書かれていました。著者は最後に、検索結果ページの進化に期待しています。
検索結果を司るGoogleが、医療のような特定の分野の検索結果について、独自のコンテンツ提供を推し進めていくのであれば、このような問題は、いずれ一定の解決を迎えるのかも知れない。
僕も同じ意見です。とはいえ人が検索エンジンを使う限り先の問題解決にはならないので、やはりQiitaのように正しいコンテンツ作成を促す仕組みの上で作られた記事が、(Googleにかぎらず)各検索エンジンでより評価されていけばいいなあと思いました。
余談
Googleで表示される独自コンテンツ、指摘できるっぽい(さすが)。
余談その2
公式ドキュメントを主な情報源にしているような優秀なエンジニアの中には「Qiitaもろくなもんじゃない」という人もいるみたいなんですが、じゃあQiitaにStackoverflowのようにdownvote(-1投票)機能が付いたらどうなるんでしょうか。おそらく僕みたいな雑魚エンジニアは的はずれなことを書くことを恐れて、投稿しなくなります。
なんというか、キュレーションサイトみたいに出しっぱなしの無責任記事でもなく、downvoteを実装して生煮えの情報が無言で消えていく代謝の悪い未来のQiitaでもなく、間違った情報は更新あるいは削除されることを前提としていて、情報の確度も含めて正しく伝わるようなメディアが良いんじゃないかと思っています。あくまでも理想ですが...。
関連
ターミナル作業をGIFにするツールとしてasciinema2gifがとても良さそう
よさそう。
Asciinemaとは
ターミナル作業をレコーディングできるツールです(@_ayato_pさんが使ってるの見て知りました)。インストールして使うと、以下の様なものが出来上がります。
でもこれ、この表示するためにブログにスクリプトタグをはっつけてる。
<script type="text/javascript" src="https://asciinema.org/a/5upf1fujvze7z81skh3k8phoy.js" id="asciicast-5upf1fujvze7z81skh3k8phoy" async></script>
はてなブログだと許されてるけど、Qiitaとかだと実行してくれなそうなので、できればgifの方が嬉しい。調べると、asciinema2gifというドンピシャのツールがあった。
asciinema2gif
Homebrewで入れてすぐ使える。
$ brew install asciinema2gif $ asciinema2gif https://asciinema.org/api/asciicasts/5upf1fujvze7z81skh3k8phoy
できた。
余談
埋め込んだAsciinemaのスクリプトがやっている描画を見てみると、Reactを使ってDOMをガリガリ書き換えてる。面白い。
焼きそばについて
手軽で安くて美味い
作業が遅い問題
どうしたもんか。。
開発環境
- 工夫はしてるつもりだけどファイル検索とかタグジャンプがいまいち
- これはすぐ改善できそう
考え方など
- 一つの問題に集中できてない(問題を適切に分割できていない)
- 機能とコードが頭のなかで結びついていない
- ちゃんと記憶すれば解決
- 製品を開発・保守する者として、記憶する義務があると考えるくらいがちょうど良さそう
- アプリケーションコードの層分けがどうされているのかなど抽象的な理解が足りない
- 新しい機能を実装するときに、そのコードをどこに書くか(なんとなくではなく)明確に決められるべき
- 理解ができていない時に、関係ないところまで含めてコードをコピペしてしまうようなことがある
作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。
検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。
だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。
作業計測について
日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。
作業時間
現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。
- チケット
- 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.net や http://codepen.io などといった、フロントエンドエンジニアのお絵かきサイトみたいなものがあることを知りました。ここで検索すれば、(そこそこ人気のあるライブラリなら)何かしら自分のニーズに合ったものが見つかりそうです。
参考
転職3週間振り返り
転職して3週間が経ちました。少し振り返ります。 Twitterでは転職したいけど迷ってるという方も見かけるので、こういうことを(会社の迷惑にならない範囲で)こまめに振り返って伝えていきたい。
前職から変わったこと、感じてること
- 自由が増えた(開発環境や勤務について)
- 開発が速い(新機能の企画からリリースまでが1〜2週間とか)
- 製品に対する反応がダイレクトに分かる
- 一夜の障害がAppstoreのレビューに如実に現れたりする
- 良い反応も見れる。(自分はさておき)サービスが社会のお役に立ってる感がある。
- テスト自動化へのモチベーションが高い
- 同僚のエンジニアのレベルが高い
個人的な課題
個人的な課題たくさんあるので技術的なこととそれ以外でまとめる。
技術的なこと
- Railsのデフォルト機能を使っていない部分についての理解
- RESTとJSON Schema
- RSpec
- 一度Qiitaなどにまとめたい。
- DDD
- まず基本概念だけでも理解しないと議論に参加できない。
- git
- まだぎこちない
- 障害対応
- サーバーの負荷が大きくなってアラートが発生したときに、障害対応を眺めていたが今後は自分もできるようになっていないとまずい。
- DBのクエリを特定 -> 発行しているアプリケーションコードを特定 -> Issue化 -> プルリク までできるようになりたい。
- DBの知識がとにかく大事。今日はこの辺読んだ。
技術的なこと以外
- アウトプット少ない
- 自分の存在価値みたいなものを出せていなくて焦ってる
- 明らかにこうした方がいいと思うということは共有したりプルリクで投げたりしていきたい
- 立ち位置
- 何エンジニアになろうとしているのかが自分でも不明瞭。
- 正直何でもできるようになりたいけどそれでは中途半端なことになりそうでもある
- 既存機能のデータをどこでどう持って、どのように出し入れしているのかを把握できていない
- これがわかっていないとディレクターの方にマスタデータのcsv渡すときなんかに時間がかかる
- 砂場を準備できていない
- 業務で扱う技術領域で趣味プロダクトみたいなものを作って、壊せるオモチャとしてプライベートで運用していきたい( nekobito.github.io のリニューアル考えてる)
- 時間の感覚が鈍い
- いつまでに何ができるかという判断力が貧弱。
- 仕様理解
- ミーティングなどで、話についていけなくなる瞬間がある。おそらく自分でもっとアプリ使った方がいい。
関連
(他のエンジニアの方の転職その後エントリみたいなやつ大好物です)
ぜんぶPryでやりたい気持ち
これを少しずつ更新してる。今後は自作コマンドからいろいろやりたい。
SOAP全盛時代に何があったんだ???
http://r7kamura.hatenablog.com/entry/2014/06/10/023433r7kamura.hatenablog.com
これを見てすごい良いなあと思ったんですが、ブコメを見るとSOAP時代とやらになにがあったんだ?という疑問が浮かびました。何があったんだろう。
転職しました
中規模のシステム開発会社から、学習支援アプリを運営するベンチャー企業へ転職しました。前職では新卒入社から1年と2か月お世話になりました。
感じていることなど
前職のWord, Excel, Outlook, ファイル名に日付でバージョン管理というような環境から、Qiita Team, Slack, Github という今時の環境になりました。勤務の仕方や開発環境の作り方など、前職では考えられなかったほどの自由が与えられています。夢見ていた環境なので、きちんと成果を出していきたいです。
転職の際にはいろんな方にお世話になりました。会社の話を聞きに行って人生相談させてもらったり、言語の勉強会なのに転職体験談を聞かせてもらったりしていました。WantedlyやForkwellのように転職支援の便利サイトやネットに転がる数々の転職エントリがあっても、実際に転職に踏み切るのはけっこう重い決断でした。そのため、生身の人から聞く助言がありがたかったです。本当にありがとうございました。
今後
今後勉強しなければいけないことは凄まじく多そうです。知っていることはQiitaに、知らないことは会社のSlackや自分のTwitterなどに投げて人様の力を借りたりして、効率よく学んでいきたいです。
まとめ
頑張ります!!!