なんかエラー出ると思ったらあるモジュールのバージョン上がってた
あるモジュールが1.1.1 -> 1.3.0 にあがってて、手元で新たにnpm installしたタイミングで import できなくなっていた。つらい。
解決策
npm install --save --save-exact
とやればバージョン固定できるらしい。
今どきは yarn 使った方がいいんだろうか。あまり調べられてないけど、しばらくしたらyarn使うことになりそう。
github.com はCSPってやつに対応してるらしい
CSP(Content Security Policy)って何かっていうと、リソースの取得先を制限するためのリストみたいなやつっぽい。HTTPのレスポンスヘッダに含めるだけならお手軽で強力な感じするけど、GoogleAdsenseみたいな広告入れることを考えると導入できなそう。
githubのPR上のコメントのLGTMを好きな女優の画像に書き換えようと思ったらChromeに怒られてできなくてこういうことだったhttps://t.co/veXLz7jtse
— gaaamii (@gaaamii) 2016年12月8日
関連
このTemplate parse errorsはどこから?
ということが多くてつらい。
何が起きたかというと、divの閉じタグが1つ足りなくて30分近く悩んだ。
Angular2のウェブフロントエンド開発に携わっていて難しいと思うことなど振り返り
ウェブフロントエンド開発に携わらせてもらっていて、なかなか大変です。てんやわんやでひたすら頑張るしかないという状況で、ブログを書いている場合ではないと思います。しかしせっかく頭を抱えるような難しさを感じているので、それを新鮮なうちに言葉にしておきたいと思いました。
続きを読む「長岡先生の授業が聞ける高校数学の教科書」を買った
文系エンジニア数人で一緒になって高校数学をやり直そう!という話に乗っかり、教科書を買いました。
そういえば、長岡先生の教科書って前にトミーさんがバズったときに使ってたやつっぽい。
高1からちょっとずつやり直していきます。
#ng_jp 主催のAngular 2 ハンズオンに参加してきました
キュレーションサイトには無くて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をガリガリ書き換えてる。面白い。
焼きそばについて
手軽で安くて美味い
作業が遅い問題
どうしたもんか。。
開発環境
- 工夫はしてるつもりだけどファイル検索とかタグジャンプがいまいち
- これはすぐ改善できそう
考え方など
- 一つの問題に集中できてない(問題を適切に分割できていない)
- 機能とコードが頭のなかで結びついていない
- ちゃんと記憶すれば解決
- 製品を開発・保守する者として、記憶する義務があると考えるくらいがちょうど良さそう
- アプリケーションコードの層分けがどうされているのかなど抽象的な理解が足りない
- 新しい機能を実装するときに、そのコードをどこに書くか(なんとなくではなく)明確に決められるべき
- 理解ができていない時に、関係ないところまで含めてコードをコピペしてしまうようなことがある
作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。
検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。
だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。