技術サイト&ブログのRSSフィードまとめ
社内で技術系記事の情報の共有をしようと思い、slackに簡単に連携できるという理由でRSSを漁ってみた。
Google Reader が2013年になくなり、個人的に使ってたlivedoor Readerも2014年になくなり、RSSがほとんど抹殺されて久しいので、今どきRSSフィードなんて提供してるところはどれくらいあるのだろうか... と探してみたが、いやいや思ったよりたくさんあるもんだ。
RSS マークのボタンがなくても、 URLに /rss や /feed と入れてみると意外に配信されていたりする。
以下、探した結果をジャンルごとにまとめておく。
技術系メディアの記事
| サイト | フィード | 補足 |
|---|---|---|
| Publickey | https://www.publickey1.jp/atom.xml | 最新の技術系トレンド、ニュースに関する有益な日本語記事 |
| はてブ テクノロジーの新着エントリー | https://b.hatena.ne.jp/entrylist/it.rss | とりあえず最低限これだけ押さえておけば大丈夫感ある |
| はてブ テクノロジーの人気エントリー | https://b.hatena.ne.jp/hotentry/it.rss | 新着よりもさらに厳選できるかも（かぶりはある） |
| InfoQ | https://feed.infoq.com/jp | 最新のアーキテクチャ事例などに関する記事が毎日配信される。 |
| gihyo.jp：DEVELOPER STAGE | https://gihyo.jp/dev/feed/rss2 | 技術評論社運営。Software Designに載ってる感じの記事がたくさん |
| CodeZine(新着記事) | https://codezine.jp/rss/new/20/index.xml | 翔泳社運営。gihyoと同様だがインタビュー記事なども多く若干好みが分かれそう |
| DevelopersIO | https://dev.classmethod.jp/feed/ | ご存知クラスメソッドのブログ。AWSのサービスの検証記事といったらココ |
| Qiita Blog | https://blog.qiita.com/feed/ | サービスリリースのお知らせなどが流れるくらいかな... |
| UX MILK | https://uxmilk.jp/feed | UI/UXに関わる人は必須 |
クラウドベンダの最新情報
AWS以外もたくさんあるがとりあえず。
| サイト | フィード | 補足 |
|---|---|---|
| AWSの最新情報 | https://aws.amazon.com/jp/about-aws/whats-new/recent/feed/ | みんな大好きAWSの最新情報 |
| AWS News Blog | https://aws.amazon.com/jp/blogs/aws/feed/ | サービスリリースなどに関するブログ(jpドメインだが英語情報) |
企業の技術系ブログ
10年以上前からある、かつて憧れたWeb系企業のブログが未だ元気。見習いたい。 海外のテック企業のものももっと探してみてもいいかな。
セキュリティ情報
セキュリティ関連の情報は通常のテック系記事などと別に流れるタイムラインにフィードを流すと、話題になる脆弱性の情報などがつかみやすい。
| サイト | フィード | 説明 |
|---|---|---|
| JVN | https://jvn.jp/rss/jvn.rdf | JVN(Japan Vulnerability Notes)、脆弱性対策情報ポータルサイト。JPCERTとIPAが共同で運営 |
| IPAセキュリティセンター:重要なセキュリティ情報 | https://www.ipa.go.jp/security/rss/alert.rdf | JVNよりも後で対策などまとまった情報として出る？ |
| AWS セキュリティ速報 | https://aws.amazon.com/jp/security/security-bulletins/rss/feed/ | AWSに関連するセキュリティ情報はこちらで |
| はてブ「脆弱性」の検索結果 | http://b.hatena.ne.jp/search/text?q=%E8%84%86%E5%BC%B1%E6%80%A7&mode=rss | こんな方法もあるのか...ちょっとノイズ多い気がするが使えそう |
O'Reilly
みんな大好きオライリーの新刊情報などを通知してくれるフィード。好みによる。
| サイト | フィード | 補足 |
|---|---|---|
| 新刊・近刊情報 | https://www.oreilly.co.jp/catalog/soon.xml | めったに買わないけど流れるとテンション上がる |
| Community Blog | https://www.oreilly.co.jp/community/blog/atom.xml | 著者対談の記事など |
| O'Reilly Village/オラの村 | https://www.oreilly.co.jp/editors/atom.xml | オライリー・ジャパン編集部の雑記 |
セミナー・勉強会等イベント情報
エンジニア向けの勉強会が多いサイト2つ。どちらも興味あるグループに所属したりタグをフォローすれば関連する新着イベントのお知らせが来る。
| サイト | フィード |
|---|---|
| TECH PLAY | https://rss.techplay.jp/event/w3c-rss-format/rss.xml |
| connpass | https://connpass.com/explore/ja.atom |
参考
情報収集には以下の記事あたりを特に参考にさせていただいた。感謝。
「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ
先日から個人的にフルサイクル開発のことを色々と調べる機会があり、Qiitaに以下の記事を書いたのだが、
この中でほんの少し触れたVOYAGE GROUPの例について、情報源である「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」に書かれているその考えや文化については色々と興味深かったため、もう少し書き留めておきたい。
フルサイクル開発の文化
第2章 「Zucks - フルサイクル開発者の文化」 ではアドネットワークやDSPを提供するZucks社の開発チームの文化について書かれている。 VOYAGE GROUPのフルサイクル開発というのは主にこのZucks社の文化のことを言っている。
Zucks社のフルサイクル開発者
「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それを全て一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。お客さんに届いたものから更にビジネスアイディアが生まれ、また別のサイクルが始まります。
とのことで、開発者のみならずエンジニア全般にフルサイクルを意識して欲しいため、「フルサイクルエンジニア」とも呼んでいるとのこと。
実際にエンジニアに求められる業務範囲のイメージとしては先のQiitaの記事でも書いたが、
全部を作れる必要はないけれど、その代わりビジネス的要件を整理するところから一人でできること。
なおフルスタックである必要がないのは以下のように書かれており、
すでに動いている仕組みについては、その使い方くらいを知っていれば、ビジネスアイディアをお客さんに届けるのに十分でしょう
これだけ読むと小さい改修に限られるイメージをしてしまうが、これは逆に「ビジネス要件の整理から」という上流工程に踏み込む方がフルサイクル開発者としてより重要になるということと理解している。
このことは、Zucks社のエンジニアの求人票 に 「業務を遂行する際、大切にしている1つに、一人のエンジニアが誰かに待たされずに開発を行う点があります。誰かが仕様を決めて、それをただ実装するだけのエンジニアはチームにいません。」 と書いてあることからも見て取れる。
ちなみに、この求人票の経緯について以下のnoteに綴られているので参考まで。
ジョイン初日にリリースする
求人票にも明記されているZucksの文化として、「ジョイン初日に必ず管理画面の機能をリリースする」というものがあるらしい。 かなりインパクトがあるが、これが如何に難しいか。
なぜ難しいか
どんなに軽微なissueをアサインするとしても、ぱっと思いつくだけでも
- オンボーディング、PCセットアップから該当issueにたどり着くまでの時間の早さ
- ツールのアカウント準備やアクセス等で躓くことがない
- そもそも必ず新人が初日クリアできるような適切なissueを整理している
このあたりがクリア出来ていないと絶対に初日では終わらないから。
初日リリースを可能にしている要素
この本の中ではその他にこれを可能にしている要素として以下を挙げている。
- 基本的にmasterブランチしかない
- 広告配信は本番環境でないと分からないことが多いことなども要因と思われる
- エンジニアの権限を分けていない（全員admin権限）
- これは一見「雑」と思われそうだが...
- 切り戻しできるかどうかを重要視
- 小さな変更でも安全に戻せない（破壊的変更）のであれば止める
- DB設計もきれいさより切り戻しが容易であることが優先（カラムを消さないなど）
とは言え
新人にとってはかなり大変な文化なのは間違いない。 広告業界経験者でも初日でそこまでやるのは難しいのに、広告業界が初めての人にとっては「そもそも何を言っているのか分からない」だろうから。
しかもトレーナーになる担当者がつきっきりでもなく「何かあったら聞いてくれ」という放置っぷり。
さらに、issueの内容からして簡単な修正だと思いきや、そのissueの背景などを営業にヒアリングするなどして理解した上で適切な修正方法を取っていないとPRで総ツッコミを受けるとか、レビューしたAさんとBさんで違うこと言ってたりとかして翻弄されるとかあるらしい。
（このトークイベントの中でそんなことを言っていた）
合わない人には全く合わない文化だと思うが、新人が初日でアウトプットを出せる、事業に貢献できる実感が持てるということにはとても価値があると思う。
ドキュメントレス文化
Zucksでは、他社で通常ドキュメント化されるような情報でも、全てGithubのissueだけで管理しているとのこと。
理由は以下。
- 一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続ける作業が発生してしまう
- メンテナンスされないと新しい人が入ってきたとき、古いドキュメントを有効な情報だと思って参照してしまうことにもなる
- コードに一番近いところでドキュメント的な情報を管理しようと思ったらissueが最適だった
※ちなみに、まったくないと言っても監査目的等外部に出すために必要なドキュメント等はきちんと作っているとのこと（少し上に貼ったトークイベントの中で言っていた）。
情報が欲しいときはどうするか
- まずGithubのissueを全文検索（全員この癖をつけている）
- 探しても見つからない情報は、人に聞くか、コードを見るか
- 最終的には動いているコードが正義
- 何かドキュメントが見つかってもそれは当時のスナップショットなので基本的に「ドキュメントは更新されていない」前提
気になったこと
- 動いているコードが読みにくい、意図がわかりにくいためにまずリファクタリングから始めて複数人の認識を合わせることから始めるというケースが結構多いらしい
コードレベルでない情報もissueコメントで追う必要がある
- issueをたどって全ての議論を追う必要はどこまであるのか
- issueコメントの議論をたどると結論が変わっているケースもある
- （これはこの文化の辛い側面として触れられてはいる）
全体の俯瞰、アーキテクチャなどを伝えるのは都度ホワイトボードに集まって説明するなどでカバー
- これは面倒くさくないのか... オンボーディングのコストがめっちゃ高い気がする。。
- これがあるのに初日リリース出来ているのには矛盾すら感じる。
このあたりを見ると特に新人向けにはお互いの伝達コストが高い気しかしないので、正直いってあまり納得感はなかった。 とは言え、だいたいどこの現場でも経緯が分からんというケースの方が圧倒的に多い気がするので、それを考えるとこう振り切ることのメリットの方が大きい、ということだと思う。
なお、新人向けにシステムのことを理解してもらう際には、まずは管理画面を一回触ってもらうことで流れと項目が理解できるので、それとセットで動いているコードを説明するなどして全体像理解のスタート地点に立ってもらうとのこと。これは理解できる。
その他印象に残ったところ
SRE部門の解散の背景
（第1章 「fluct - 広告配信の舞台裏の技術者たち」より）
SSPを運用するfluct社で、2019年11月にもともとあったSRE部門を解散し開発部門に統合。その背景としてこんな理由があった。
- だんだん開発チームからSREチームに「依頼」するケースが増えていた
- DevとOpsが分かれていることは悪くないが、本来は同じ目的を共有するチーム間で「依頼」が発生するのは本意ではない
ビジネスと一緒に開発する
（第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より）
就活支援サービスを展開するサポーターズ社では「ビジネス側から言われたものをそのまま作ることはしない」姿勢を明言している。
- かつては社内受託のような形で「この画面をこういうふうに作ってください」という、アウトプットが規定された「依頼」が普通だった
- 今はそのような来た場合は「なんで？」と即座に返す
- 「なぜ」を聞いた上で当初の提案よりもコストのかかる実装（理想）を提案することもある
- 今すぐ結果だけ欲しい人にとっては「いまはそれは良いから、すぐにできることだけ話してくれ」と感じる
- 「ちょっとしたお願いを相談しただけなのに、なんでこんな大きな話にされて、いっぱい話さないといけないんだろう」
これは非常に「べき論」を地で行っているが、ビジネスの方が立場の強い会社だと開発側が負けてしまうし、開発側が強い場合はビジネス側が「開発は相談に乗ってくれない」と不満を漏らして二度と相談に来ないという結果を生みやすいので、如何に日々コミュニケーションを濃密に取ってお互いを理解しているかというのが伺えるエピソードだった。
ちなみに、このような相談の場合にケンカにならないために押さえておくべきポイントを言うなら、
- ビジネス側：背景をきちんと伝える、結果を急ぎすぎない（サクッと明日までに大体で良いから見積ほしい（でも上振れしないでねという圧）とか）
- 開発側：温度感を踏まえて聞く、むやみに話を大きくしない（エンジニアは「そもそも〜」で話を振り出しに戻して大きくする人が多い）
以上踏まえてお互いに落とし所を見つけることかなぁ、と自分の肌感覚では思っている。
依存ライブラリは週1で上げる
（第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より）
同じくサポーターズ社で、「ガーデニング」と称してフロントエンドやサーバーサイドの依存ライブラリを毎週最新化するという運用を行っているとのこと。
- 最新バージョンへの追随は一度やめると二度と復活できないので、1ヶ月ではなく1週間で実施
- 「ガーデニングガチャ」で当たった人が実施
- 週次で上げるのはマイナーな変更（既存コードの変更がないもの）のみ
- ライブラリを上げる作業自体はコード変更がなければ単純作業なので、ガーデニング作業そのものの大半はchangelogの確認
これは簡単そうにやっているようだが、実はすごいこと。そんなこまめに上げていたことないな...
最初の1,2回なんとか乗り越えれば、後はそれほど苦ではないのかな。
でもメジャーバージョンアップがあるとこのルーティーンとは別タスクでやらないといけないはずだから、そこは同じなのかな。
最後に
2章のことでたくさん書いてしまったため他の章の取り上げ方が雑になってしまったが、 他にもレガシーのシステムといかに付き合っていくか、改修とリプレースの判断はどうやって行うのか、など、外から見ると楽しそうにやっているWeb系企業の現場で直面する決して華やかではない、むしろ泥臭さしかない課題に対する取り組み方などについても臨場感の伝わる記述がされたとても熱量の多い一冊だった。開発現場を経験しているエンジニアならきっとよくうなずく箇所や「いやこれはちょっと...」と賛否両論の独り言になること請け合いなので、是非一度手にとって頂きたい。
MacVim、Atomのvim-modeでEsc時にIMEをOFFにする方法
やり方を忘れてしまい新しいPCSierraでどうすんだっけ、と思い調べると、殆どが Karabinerによる設定方法ばかり。 最近Karabiner-Elementで対応できる様になったというのも見たのでいいんだけど、できればKarabiner無しでどうにかなんないかなぁと思ってたら、
Google日本語入力の設定だけでできるじゃん！
とっても助かりました。
このスケジュールで問題ないですか？
英文でスケジュール打診をするメールを書いているときに
「来週●月●●日以降に始めたいんだけど、問題ない？」と書こうとして、
”問題ない？”の部分をどう書こうかなぁ・・・と思い調べてみたところ、 ちょうどよいフレーズが紹介されていた。
うまくハマった（気がする）のでメモ。
Is there any way that you can adjust to this schedule?
（この予定に合わせて頂く事は可能ですか？）
このサイト、他にも使えそうな気になるフレーズが紹介されている気がするのでちょいちょい見てみよう。
Workflow Engines Night 参加メモ
開催日：2017/6/7
場所：DMM.comラボ 六本木オフィス
『StackStorm ワークフローエンジンによる運用コスト・リスク低減の取り組み』
株式会社DMM.comラボ 大山 裕泰氏
- StackStorm Contributor
- StackStorm AWS maintainer
digdagじゃなく別のWorkflowエンジンの話
運用者を悩ませる問題
- ユーザ（社内）との折衝コスト（口頭、チケット、メールで依頼）
- オペレーションコスト（多種多様なシステム環境、機器）
- オペミスのリスク、熟練オペレータしか触れない、教育コスト高い
- (確かに新人にLBは触らせないとかある…）
理想的な運用形態
- 定型運用のAPI化
- システムの適切な抽象化
- ×個別機器を操作する ◯操作して得たい結果を機械に教える
StackStormとは
- IFTTT x Workflow
- センサーが反応するイベントを受けて、一定のルールでActionを実行
- 例えばイベントに併せてリソースを増やす
- VMを作るだけの単体タスクじゃなく、VM作る→Provisioning→DNS登録→ELBにぶら下げるなど一連のタスク
Stackstormのある環境
- オペレーション用APIの提供
- 知っている人誰かに聞いたり、ドキュメントを漁ったり(用意したり)しなくてもStackStormを見れば分かる
- システムの抽象化（欲しい結果だけを指定する）
- 運用の自動化（個別のシステム状況に応じた対応を機械的に実施）
StackStormが実現するであろう未来
- 折衝業務を行うエンジニアの開放
- オペレータの運用・学習コストの逓減
- サービス運用リスクの削減
Q&A
- スケジュール実行はどのように？
- センサーからのイベントドリブンなので定期実行するのは可能
- 定期実行の際に重複実行を避けたい、どうする？
- 複数ノードに分散しているが、同じノードで同時に複数リクエスト来た場合のことは考慮されてない
参考資料
http://qiita.com/unchemist/items/0e6425396ba1a1e6b43c
『JenkinsからDigdagへ日次バッチを移行して幸せになるお話』
株式会社DMM.comラボ 鈴木 翔太氏
なぜDigdagなのか
- 多数の日次バッチ
- 所謂ETL
- これまではJenkinsで運用
- 問題
- Jenkins依存
- コードで管理できない
- 失敗時のリトライが大変
処理が時間依存
課題解決のためにワークフローエンジン導入を検討
選定ポイント
- ◎可用性
- ◎スケーラビリティ
- コード管理
- 失敗したタスクからリトライ可能
- 進捗確認ができるIF
構成
- Digdag2台、サーバ兼クライアント
- PostgreSQLサーバ2台(PgPool-II使って Active&Standby構成）
Workflow設計
プラグイン自作
- Slack通知を実現するdigdag-slackを作った
- SLAの通知に利用
チーム間連携（＝システム間連携）
- あっちのシステムでファイルができたらこれを実行、みたいなの
- 時間に依存しない形で実行させたい
- mog(go製CLIツール)を作成し提供
- タスク名ベースでステータス確認可能に
- ワークフローのスタート＆リトライも対応
- Github公開していない（が、渋ってるわけじゃないので公開します）
まとめ
- Jenkinsからの脱却
- 全てコード管理可能に
- コードで依存関係も表現
- バッチ失敗時のリトライも楽ちん
- mog CLIにより時間依存の処理を排除
『Treasure DataにおけるDigdagによる大規模データ処理の自動化とエラー処理』
トレジャーデータ株式会社 古橋 貞之
あまりメモ取らなかったけど詳しいレポートができてた
そもそもなぜDigdagを作ったか
- あらゆる手作業を自動化するため
- マルチクラウド、多数のミドルウェア、どんどん新しく出て来るのにエラーコードやハンドリング方法を全部覚えないといけないのか
- シェルで複数ジョブを順次実行するには上から並べることになるが、エラーハンドリングやモジュール化での再利用などに問題がある
デモ
- Treasuredata Workflowの画面で説明（ロゴが違う以外は一緒）
- Timelineにタスクの進捗状況、経過時間がビジュアルに見える（すごい）
- タスクを動的に増やせる
- ループタスクも書ける
使用事例紹介
- TD内で利用しているworkflowのユースケース紹介
LT『Digdagを使ってみて便利だったとこ、はまったとこ』
株式会社VASILY 塩崎 健弘
IQONを提供してる（若い女性ターゲットのファッショなプリ）
- クローラを開発してcronでジョブ管理
- 複数クローラのジョブを並列にcron定義
- 30分毎に実行
- でも30分で終わらなかったら？重複実行は？
- ハンドリングつらい
- Digdagは設定ファイルがシンプル
- AirflowやLuigiとくらべて自由度低い（高い自由度は不要、複雑なジョブができちゃうから）
- dockerサポート嬉しい
一時ディレクトリを切って実行してくれるので他のタスクからの影響を最小化できる
pythonのバージョンでハマった
- py>:オペレータはpythonコマンドを呼び出すが、OSによってバージョンが2で呼ばれる
- python3のdockerイメージを使用することで解決
ruby(rb)でも同じ問題が
一時ファイルの受け渡し
- 一時ディレクトを毎回ジョブ毎に切ってくれるのでまとめて読めない
- 一時ファイルはS3に書いて読み出し
