最近の「あとで、読む」の環境設定について

いろいろと、Webサービスもアップデートがあって、自分の「あとで、読む」の設定を見直したので、まとめてみます。

「あとで、読む」は、エンジニアの嗜み??

自分は、サラリーマンのWebエンジニアで、朝9時から夜まで、会社に出社し業務をこなしています。 業界特有の問題?ですが、とにかく忙しいです。 どうしても、日々仕事だけをこなして過ごしてしまいがちな家業ですが、同時に技術の進歩は、本当に早い! 自分から追いかける姿勢がないと、気付くと置いてきぼりのエンジニアになってしまい、ゆくゆくはお仕事をもらえない状態になってしまうのかなぁと日々、感じます。

そこで重要になってくるのが、空き時間ですね。 どんなに忙しい人でも、きっと電車を待っている時間だったり、ちょっとした休憩時間などの空き時間がありますよね。この時間を如何に有効に活用するかで変わってくるのかなぁと思います。

そして、空き時間なので、腰をあげて、「よっこいしょ!」って感じの作業は、向かないですね。自然とiPhoneを覗き込むだけで、有益な情報をゲットできたり、新しい技術を習得するきっかけを掴めたりしたら、いいですよね。

そこで、自分は一歩すすめて「Kindle」を有効に扱うという結論に達しています。

どこで情報を集めるのか??

情報を集める場所は、どこがいいのかは、所属する業界や自分が目指している方向性によって、変わってくるかと思いますが、自分のお勧めのWebエンジニアの情報収集方法は、以下の通りです。

  • Reeder2 for Mac
    • 使い勝手が抜群のRSSリーダー
    • とにかく気になるフィードは、すべてfeedlyに登録して、Reeder2で消化しまくる
    • 基本タイトルだけ見て、気になったら、Favすると、IFTTTで連携して、「あとで、読む」系サービスに送る

f:id:urapico:20140511025413p:plain

  • HBFav2
    • アルファギーク系の人たちのブックマークは、かなり有効な情報で、このアプリだとそういった情報をゲットしやすい
    • 気になったら「あとで、読む」系サービスに送る

f:id:urapico:20140511025526p:plain

  • twitter
    • 気になったリンクを「あとで、読む」系サービスに送る
    • Macの公式アプリが「あとで、読む」に対応していないのが、ちょっとストレスw なんで、だろう  

      f:id:urapico:20140511025627p:plain

自分は、この3つのアプリ・サービスで、情報を集めています。 上でも書いた通り、空き時間を有効に扱う為に、まずは情報収集だけをやって、気になったら、すべて「あとで、読む」系サービスに集約し、消化していくという形で、効率化しています。

「あとで、読む」系サービス

「あとで、読む」系サービスは、いくつか存在しますが、現時点では、以下の2つのサービスを利用しています。

今のところ、情報をかき集めて、Pocketに突っ込んでいます。 その後に、IFTTTで、全ての記事をInstapaperにも同期しています。

なぜ、この2つ使っているかというと、もともとPocketに集めて、Readabilityに同期して、そこからKindleに未読の記事を毎朝、送信する設定にしていたのですが、数ヶ月前にReadabilityがサービスをアップデートした際に、記事がKindleに送信されなくなってしまいました。 自分の設定や理解不足なのかもしれませんが、解決することが出来なかった。

そこで、昔触った事のあるInstapaperを思い出しました。 でも、あまり使いたくなかった。理由としては、この系のサービスは、基本的に対象の記事をスクレイピングして取得してくれるのですが、記事に画像があってもInstapaperの場合、取ってきてくれないので、記事を読んでいて、理解できない場合が生じてしまうのが、主な要因でした。

しかし、ダメもとで試してみたら、なんと今のInstapaperは、画像データもちゃんと取ってくるようになっていたので、すぐにReadabilityから乗り替えました。

PocketでFavしたら、はてブ

IFTTTで、メール送信して、はてブしています。

InstapaperでLikeしたら、はてブ

IFTTTで、なぜかInstapaperのTriggerチャンネルがないので、Instapaperの設定で、tumblarに連携ができるので、一旦tumblarに連携してから、IFTTTで、メール送信して、はてブしています。

f:id:urapico:20140511032211p:plain

なぜ、はてブ!をするのか??

なにか、貢献する的な心理的な要因がありますね。 やはり、日本のWeb系のエンジニアは、はてブをチェックしり、コミットしたりする人がまだまだ多いので、自分が見つけた記事で、「こんな記事みつけたぜ!」とか、教えてもらったので教え返す的な感覚かなぁと思っています。

Kindleで集中して記事を読む

Instapaperから送信されたKindleを通勤の合間に読みます。 Kindleは、とにかくドキュメントを読むことに特化したツールなので、 読んでいる最中にTwitterの通知が来て、そっちを見に行っている間に、 時間が過ぎて、結局記事を読まないままになってしまったりということがないのが 気に入っています。

ただ、Instapaperで不満だったのは、Readabilityのように、Kindleに送信したとに、送信した記事を「既読」にする機能がなく、毎日前日に送信された記事と重複した記事が何件が送られてしまっていました。

ストレスを感じて、どうにかIFTTTとか使ってなんかできなかなぁと考えていました。

ある日、Kindleに送られてきた記事のヘッダーをよくよく読んでみたら、こんなことが書かれていることに気付きました。

f:id:urapico:20140511033611p:plain

この「All Archive」クリックするだけで、送信されてきた記事すべてを、「既読」のステータスに変更することができます。 あと個別の記事ごとに「Like」することも出来て、もっと深堀したい記事に関しては、Likeしておいて、PCで確認したりできて、いい感じです。

以上、最近の自分がやっている「あとで、読む」の環境でした!!是非、参考になれば、うれしいです。

参考にさせていただいた記事

受託において、Immutable Infrastructureはちょっと。。。

最近は、「Immutable Infrastructure」が流行っていますが、仕事の受託に取り入れることを考えていたんですが、どうもしっくりこないなぁと思っています。

だって、受託開発の場合、サーバーはお客様のものですから、なかなかImmutable Infrastructureの運用フロー?に合わせてもらうのも難しい(例えば、バージョン管理ツールと使ってもらうとか。。。)。

だから、Chefとかの冪等性のあるプロビジョニングツールの運用がしっくりくるなぁと最近思う訳です。
その辺の、縛りとかで、どっちの運用にしていくのかが、決まってくるかと思います。

SEKAI NO OWARI

最近、SEKAI NO OWARIの曲ばかり聞いている。

とっても自分としては、新鮮でハマった。

幻の命というのも良い曲だ。これは、ピアノのさおりちゃんが、15歳のときに作曲。20歳の深瀬くんが歌詞をつけて、完成した曲のようで、15歳でこのメロディーを作れるって、すげぇなと。

昔のブログを読むとうれていないころに、近くの無料で見れるステージとかに出演していて、見に行けば良かったと後悔?したりしている。

明日も聞こう。

継続的に開発フローを見直し、改善の重要性

一つのシステムの開発フローの種類は、多種多様に存在します。

ただ会社に属していると、その組織で決められた開発フローに対して、なんの疑問も抱かずに日々を過ごしてしまいます。
また、もし自分自身が気づいたとしても、組織の開発フローは、周囲の理解と同時にそれに参加する人たちを本気に出来るのかが、鍵となります。
最近、チームの長という立場に立たせてもらって、痛いほど痛感しいる。
これを打破するには、どうするか?

これ、非公開にしたいのだけど、どうするの?

PhabricatorとGitHubの1つの大きな違い

前にGitHubも使ったことないのに、GitHub Enterpriseの勉強会に参加したことがあった。

GitHub Enterpriseを利用する場合、今まで運用していたリポジトリとは別に運用する必要性もあったり、そもそもGitしか選択できない。そんなこんなで、業務で利用したいけど、エンジニア以外の壁は、大きすぎて乗り越えることができない。

はい、そこでPhabricator!

このソフトは、現状の運用を変更せずに導入することが可能なんです。

それを可能にしているのが、GitHubのように内部にリポジトリを持つという設計ではなく、外部のリポジトリをトラッキングするという設計なんです。
しかもレビューの方法が、2つ用意されていて、Differential(pre-push)とAudit(post-push)になっている。

Differential(pre-push)は、用意されているArcというコマンドツールによって、リポジトリにコミットする前にPhabricator上でレビューをして、その後、OKだったら、コミットするというGitHubにpull requestに似ているかなぁと思います。

もう一つのAudit(post-push)は、リポジトリにコミットのメッセージにレビュアーの名前を記載して、コミットするとレビュアーにレビューして!!という通知が飛んで、Phabricator上でレビューができるようになっている。

自社サービスだけを運用しているのであれば、Differential(pre-push)は強力なサポートになりますし、Audit(post-push)は、受託系のサービスや案件にアサインされているエンジニアが1人で、他のエンジニアはまた別の案件にアサインされている場合に役立ちそうです。

今後のPhabricatorのバージョンアップが楽しみです。