文系エンジニア数人で一緒になって高校数学をやり直そう!という話に乗っかり、教科書を買いました。
そういえば、長岡先生の教科書って前にトミーさんがバズったときに使ってたやつっぽい。
高1からちょっとずつやり直していきます。
文系エンジニア数人で一緒になって高校数学をやり直そう!という話に乗っかり、教科書を買いました。
そういえば、長岡先生の教科書って前にトミーさんがバズったときに使ってたやつっぽい。
高1からちょっとずつやり直していきます。
以下の記事を読みながら、そうだよなあ...見た目だけ立派だけど質が悪かったり無責任な情報の断片寄せ集め記事ってたくさんあるよなあと再認識しました。僕も間違った情報に騙されることがよくあります。
ところで、ソフトウェアエンジニアの仕事は情報収集がけっこう大きな割合を占めます。書籍による情報と自分の想像だけでプログラムを書くのは至難の技です。
そんな時、情報を集めるときに信頼できるものとして真っ先に思い浮かぶのがQiitaです。僕はQiitaが大好きです。前職ではQiitaにアクセスできなかったので辞めました(それほど過言でもない)。
Qiitaを閲覧したりQIitaに投稿していると日々最高だと思うので、ソフトウェア・エンジニアリングの分野だけでなく、各分野の専門知識がQiitaみたいなものの上で共有されるといいなあと思います。しかし、なぜそんな風に感じられるのでしょうか。僕個人の完全な主観で、そもそもメディアとして違和感を感じるキュレーションサイトと、常日頃から最高だと感じているQiitaの間にある違いについて整理しておきたいです。
Qiitaにも間違った情報はたくさん載っています。誰でも登録・執筆できるのだから当然です。しかし、Qiitaでは編集リクエストという機能があります。これは執筆者以外のQIitaユーザーが、元記事の一部分を編集し、それによって記事を更新してくれとリクエストすることができる機能です。
キュレーションサイトにはこのような機能はありません。僕の知っている限り、キュレーション記事の執筆者は記事単価ベースで記事を生産しているに過ぎない場合が多く、その後の更新にまで気を配っているようには見えません。少なくとも、全くの第三者がその記事を更新する(させる)仕組みは提供されていません。
Qiitaの執筆者がQIitaを利用している会社に所属していると、その所属企業のアイコンが表示されます。閲覧者としては判断材料の一つとして心強いですし、執筆者としては会社のイメージにも影響することを意識して、間違った情報は書きにくいです。
キュレーションサイトで、執筆者の所属企業を表示しているものが見たことあるでしょうか。僕はありません。
個人ブログなんかだとスパムが嫌でオフにしがちなコメント機能ですが、Qiitaのコメント欄は活発に、かつまともに機能しています。エンジニアが他人が書いた間違った情報に対してツッコミを入れるのは、間違った情報に騙されて時間を無駄にした経験があるからでしょう。
対して、多くのキュレーションサイトではコメントという仕組みが提供されていません。そのサイト上で記事に対する議論を見ることはできず、真偽の程を見定めるられるかどうかは読者のリテラシーや知識にかかっています。URLをTwitterやはてなブックマークで検索することくらいはできますが...。
と、ここまで書いておいて専門記事の執筆に向いているウェブサイトをもう一つ思い出しました。Wikipediaです。分野問わず有用な情報がたくさん蓄積されています。
しかし、Wikiの仕組みやコンテンツ量と質は素晴らしいですが、記事が中心にありすぎて議論や著者性が見えなくなっているような雰囲気があります。間違った情報と正しい情報の見分け方が難しいという点で、ニッチな情報についてはキュレーションサイトと変わらないような気もします。ページを開くと視認性が異常に高い文字で寄付をせびられるのも気分が悪い。あと、書く側として気持ちの良いものには見えないのに、なんであれだけの情報が集まっているのか不思議です。
このブログ記事の冒頭で参照した記事(医療情報に関わるメディアは「覚悟」を - 問われる検索結果の信頼性(朽木誠一郎) - 個人 - Yahoo!ニュース)では、医療分野で無責任な情報が検索エンジンを通じて、それを本当に必要としている人に届いてしまう危険性について書かれていました。著者は最後に、検索結果ページの進化に期待しています。
検索結果を司るGoogleが、医療のような特定の分野の検索結果について、独自のコンテンツ提供を推し進めていくのであれば、このような問題は、いずれ一定の解決を迎えるのかも知れない。
僕も同じ意見です。とはいえ人が検索エンジンを使う限り先の問題解決にはならないので、やはりQiitaのように正しいコンテンツ作成を促す仕組みの上で作られた記事が、(Googleにかぎらず)各検索エンジンでより評価されていけばいいなあと思いました。
Googleで表示される独自コンテンツ、指摘できるっぽい(さすが)。
公式ドキュメントを主な情報源にしているような優秀なエンジニアの中には「Qiitaもろくなもんじゃない」という人もいるみたいなんですが、じゃあQiitaにStackoverflowのようにdownvote(-1投票)機能が付いたらどうなるんでしょうか。おそらく僕みたいな雑魚エンジニアは的はずれなことを書くことを恐れて、投稿しなくなります。
なんというか、キュレーションサイトみたいに出しっぱなしの無責任記事でもなく、downvoteを実装して生煮えの情報が無言で消えていく代謝の悪い未来のQiitaでもなく、間違った情報は更新あるいは削除されることを前提としていて、情報の確度も含めて正しく伝わるようなメディアが良いんじゃないかと思っています。あくまでも理想ですが...。
よさそう。
ターミナル作業をレコーディングできるツールです(@_ayato_pさんが使ってるの見て知りました)。インストールして使うと、以下の様なものが出来上がります。
でもこれ、この表示するためにブログにスクリプトタグをはっつけてる。
<script type="text/javascript" src="https://asciinema.org/a/5upf1fujvze7z81skh3k8phoy.js" id="asciicast-5upf1fujvze7z81skh3k8phoy" async></script>
はてなブログだと許されてるけど、Qiitaとかだと実行してくれなそうなので、できればgifの方が嬉しい。調べると、asciinema2gifというドンピシャのツールがあった。
Homebrewで入れてすぐ使える。
$ brew install asciinema2gif $ asciinema2gif https://asciinema.org/api/asciicasts/5upf1fujvze7z81skh3k8phoy
できた。
埋め込んだAsciinemaのスクリプトがやっている描画を見てみると、Reactを使ってDOMをガリガリ書き換えてる。面白い。
手軽で安くて美味い
どうしたもんか。。
作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。
検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。
だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。
日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。
現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。
そして、それぞれ関係性がある。
なので、1日の作業を計測するとしたらIssueごとの作業時間を測るのが良さそう。作業時間を測るのには、toggl buttonというChrome拡張があるのでそれを使えばいい。
では、作業量の計測対象はなんだろう。
閉じた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
こういう数値をまとめて出せるようにしておくと、いろいろ学びがありそう。ただ、この数値で同僚のエンジニアと比較されるみたいなことになるとストレスが高まりそうなので良くなさそう。自分の作業時間見積もりの不正確さやざっくりとしたパフォーマンスを知る目的に確認するのであれば良さそう。
転職して1ヶ月は内製のサポートツール周りなどを触らせてもらっていましたが、8月からはウェブフロントエンドの方にコミットさせてもらっています。Angularのデータバインディング周りに何度もハマっていて楽しいです。
フロントエンドの開発作業で、新たな機能をつくるときにはまずそれ相当のライブラリがあるかどうか調査することが多いと思います。しかしそれが見つかったとしても、僕のように頭が弱く英語力が低い人間にとって、ライブラリの扱い方をGithubのREADMEからすぐに把握するのはなかなか大変です。そのため、さっと動くサンプルを見つけることがとても重要。
そこで、http://jsfiddle.net や http://codepen.io などといった、フロントエンドエンジニアのお絵かきサイトみたいなものがあることを知りました。ここで検索すれば、(そこそこ人気のあるライブラリなら)何かしら自分のニーズに合ったものが見つかりそうです。
転職して3週間が経ちました。少し振り返ります。 Twitterでは転職したいけど迷ってるという方も見かけるので、こういうことを(会社の迷惑にならない範囲で)こまめに振り返って伝えていきたい。
個人的な課題たくさんあるので技術的なこととそれ以外でまとめる。
(他のエンジニアの方の転職その後エントリみたいなやつ大好物です)
これを少しずつ更新してる。今後は自作コマンドからいろいろやりたい。
http://r7kamura.hatenablog.com/entry/2014/06/10/023433r7kamura.hatenablog.com
これを見てすごい良いなあと思ったんですが、ブコメを見るとSOAP時代とやらになにがあったんだ?という疑問が浮かびました。何があったんだろう。