Slack情報収集のためのチートシート

モヒカンSlackなどに限らずSlackをRSSリーダーのように使っている人が多いと思いますが、特定の分野の情報を追いかけるときの覚え書きです。

基礎

SlackではRSSアプリでスラッシュコマンドが用意されているので、一度アプリを登録しておけば、フィードを追加するときは以下のコマンドが使えます。

/feed subscribe ＜RSS等のURI＞

RSSフィードのURI

だいたい以下を追加しておくと良いです。＜keyword＞は目当てのキーワード（"azure"とか"javascript"とか) に置き換えます。

その分野で精力的に情報発信している人が居れば、以下のURIでQiitaやSlideshareがストーキングできます。

あと、個人的にはDevelopers.IOも追いかけてます。

特定のブログを追いかけたいときは、メジャーどころなブログエンジンなら、ソース開いて「feed」とか「atom」「rss」あたりを検索すればRSSフィードのURIがmeta要素とかに入っているので、そこから持ってきます。

 

Dockerのログ出力先

Docker

ツイートしてて自己完結してしまったので記録のために。

前提と考察

  • Unixの世界では、stdout(標準出力)とstderr(標準エラー出力)という二つの出力チャンネルが標準として提供されている。
  • Twelve-Factor Appでは、アプリケーション側はログをイベントストリームとして出力し、実行環境側のほうで開発環境であればstdout、運用環境ならばfluentdなどに送って処理するべきとされている。
  • 近年[要出典]のログは、そもそも古臭いNCSA combinedアクセスログのような複雑怪奇な正規表現で取り出すようなテキストではなく、最初からJSONやLTSVなど構造化されたデータとして扱われるべきものである。
  • Dockerではコンテナのログをlogging driverという仕組みで処理し、stdoutとstderrを1行1エントリとしてloggin driverに送る。logging driverは標準出力なりFluentdなりAWS CloudWatch Logsなりに送る。
  • コンソールアプリでパイプ使う場合は、docker runに-aでstdoutだけ出力できるので、きちんとやる必要があれば出力はstdoutでパイプにつなぎ、ログはstderr経由でloggin driver送り、という使い分けができそう(未確認)

参考リンク

docs.docker.com

docs.docker.com

sourceでstdoutかstderrか取れる。

12factor.net

 

SORACOM Discovery 2019で登壇します(Serverless × IoT)

7/2のIoTカンファレンス「SORACOM Discovery 2019」で、サーバーレス×IoTで話します。

毎日の料理を楽しみにするためにIoTサービスを開発するクックパッドのkannyさん、 日本のサーバーレス推進の第一人者である吉田さんと一緒に、 なぜIoTで「サーバーレス」という考え方・手法が重要なのかを議論します。

f:id:nekoruri:20190518122355j:plain

"IoTを超えて"新しい世界を作りたい人、是非登録してお越しください！

 

www.discovery2019.soracom.jp

もう「サーバーレスだけどサーバあるじゃん」という話をしたくない

3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1。

一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。

これを真面目にやろうとすると、キューやPub/Subによる非同期タスク（イベント駆動）が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。

 

その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさんでてきます。そういうゼロからスケールできるフルマネージドサービスの性質もサーバーレスと呼んでいます。

メリットが分かりやすいためクラウドベンダーが主張したいのはこちらの性質なんですが、でもこれって「所有せず利用する」というクラウドコンピューティング全体の流れの延長線上でしかないんですよね*2。

 

この設計と運用の二つの性質が混ざったのが現在の「サーバーレス」です。

というわけで、サーバーレスという単語に関しては、

　× サーバが無い
　○ プログラマがサーバを気にしない
　◎ プログラマがサーバを(設計上)気にしてはいけない＋(運用上)気にしない

と捉えるのが良いと思います。単純に「サーバが無い」というだけの解釈をしやすいのは事実なので、こういう理解をした方が楽しいよ、という話です。

日本語圏だとサーバと言えばサーバマシン（ハードウェア）を指すことがほとんどですが、英語Wikipedia見ると、サーバマシンよりも先にクライアント・サーバにおける提供側の"a computer program or a device"が先に来ますし、サーバの仮想化はVirtual ServerではなくVirtual Machineなんですよね。この英語と日本語でのニュアンスの違いが大きいのかなという気はします。

（追記 2023-12-17：正直名前として良くないとちょっぴり思ってはいます）

 

という話をまとめて書いてあるのでみんな買ってください😇

nekoruri.booth.pm

追記

(2019-05-11 10:00)

あまり記事の意図が伝わってない感じなので、脚注に書いていたことを本文に組み入れました。

こんな読まれると思っていなかったのでポイントをあまり気にせず書いていたのですが、伝えたいのは以下の2点です。

  • サーバーレス（Serverless）という単語にも理由があるし、サーバマシン、サーバプロセスへの依存排除というこの抽象化の世界は面白いので、そう単語自体を否定しないで欲しい。
  • 「こういう背景もあるのか」ということで一定の納得をしてもらい、この名前の話はとっととやめて、サーバーレス技術を使っていかに楽に楽しくシステムを作るかの話をしたい。

(2023-12-17 18:00)

薄い本へのリンク、もう4版がでているのでそちらに切り替えました。

*1:「Developers working in a distributed world are hard pressed to translate the things they’re doing into sets of servers.」とあるとおり、そもそも分散システムでものを作ってる人達はサーバとかいう考え方じゃないよね、という背景

*2:まあ実は一つめの話も、関数型プログラミングで言われるような、副作用排除、宣言型などのプログラミングの抽象化の流れの延長線上ではあります。

CROSS Study #2 で登壇してきた #cross_study

同人 技術書典 ssmjp同人部 めもおきば

技術書典でふらふらしていたら、当日のじゃない方の非公式アフターで喋ることになりました。

cross-party.connpass.com

 

パネルセッション前半の「技術書典6 非公式振り返り」で、ssmjp同人部からほかに2人もいるので、どちらかというと個人サークル「めもおきば」の人よりの立場で好き放題話させていただきました。

まあ詳しい内容は実況勢がたくさん居たのでTogetterを見ていただくとして。

togetter.com

話したこととその補足です。

書き手として

もともと「普段考えていることを整理してアウトプットする機会」と位置付けていることもあり、技術書典の一般の「売れ筋」であるような解説書とかとはちょっと違う路線で、クラウドやセキュリティをテーマに、全体像や技術トレンドから勝手に分析した考え方のような「読んだ人に新しい視点を提供できる本」というエモい路線を中心にひた走っています。

そこを評価していただいている方がいて本当にありがたいかぎりです。

引き続き、エモいポエムコラム本というジャンルを確立すべく頑張っていきます。
d.nekoruri.jp

ネタ出し

私の場合は、Workflowyにネタ帳の階層を作って放り込んでます。

workflowy.com

まあぶっちゃけツールは何でも良いですが、スマホロック解除して10秒ぐらいで入力できる状況で敷居を下げておくとよいです。24時間常時ブレスト状態。とにかくキーワードを放り込んでおいて、あとで考えます。

人によってはボイスメモとかもありかもですね。最近だとScrapboxが人気なのかな。

scrapbox.io

scrapbox.io

あと、Twitterとかに書いちゃって満足してしまったネタをあとからきちんとまとめたいときは、Twilogでキーワード検索してその日の自分の前後ツイートを読み返したりします。外部記憶と検索重要。

twilog.org

入稿について

頑張れば短い時間でも本は出ます。

とはいえ極道入稿は悪です。誰も幸せにしないので早めに頑張ろう。

湊川さんも言っていたとおり早割（今回のねこのしっぽ様だと最大20%割引）で出せばその分同じ予算で1.25倍刷れて完売リスクを減らせますし、告知などにも時間を割けます。

今回の締切ラッシュの中で、自分の中で1ページ1時間というペース配分がはっきり確立したのは良かったなと思っています。要するに100ページの本を書こうと思ったら100時間かかるので、毎日3時間掛けても一ヶ月かかるわけです。3日徹夜しても24ページにしかなりません。いいですねおれ。はやくフォルダとファイルとレポジトリを作るんだ。

読み側として

今回もたくさんフルスタックしました。ありがてえ。

とはいえ途中で力尽きてしまい、お昼ぐらいまでに回れたのは1/3ぐらいで、残りはかなり遅めの時間でしかも最後の方まで人が多かったため流す感じになってしまったので、あとで他の方の戦利品写真をみて入手し損ねた本がかなりあったのが残念なところです。

それでもかんたん後払いシステムの電子書籍サービスが始まったこともあり、電子書籍での頒布を続けているサークル様がたくさん増えたという印象を受けました。じつにありがてえ。

今回は使えるサークル全てかんたん後払いシステムで決済しました。入手した本のリストも取れるしDLCもあるしほぼ良いことづくめなのですが、その結果として人類は頒布価格を見なくなり書典破産の危機が迫っています。ありがてえ。

 

まあ、そんな感じで「めもおきば」「ssmjp同人部」ともども引き続きよろしくお願いします。