はてなブックマーク

御託はいいから fediverse とは何なのか Mastodon とは何なのか、端的に理解する たとえ話による納得ではなくもっと深い理解が欲しいなら、もう十分書いたので 2017年4月の記事 とか 2017年12月の記事 とかを読んでください。 オタクの語りを嫌というほど読めます。 はじめに まず「Twitter では〜」とか「Tumblr では〜」とか「2ch/5ch では〜」とか「ジオシティーズでは〜」とか「mstdn.jp では〜」とか「Pawoo では〜」とか、そういう知識は全て放棄して読んでください。 先入観は邪魔です。 ではいきますよ。 端的に言えば、 Mastodon とか fediverse とかいうのはメールとメルマガのようなものです。 メールなんて使ったことねえよ！ という人のためにメールの説明をするつもりはないので、その場合は一旦諦めて、メールを知ってから来てくださ

Rust (1.48.0) で独自のスライス型や文字列型を定義する Rust でプログラムを書くうえで、用途や制約に応じた適切な型の定義は大変重要である。 たとえば Rust ではバイト列は [u8]、 UTF-8 文字列は str、OS ネイティブのエンコーディングの文字列は std::ffi::OsStr、パス文字列は std::path::Path といったように、横着すればひとつの型で済むような様々なデータに対してそれぞれの特徴に応じた型を標準で用意している。 ときに標準ライブラリで用意された型ばかりでなく、自分で専用の型を用意したいこともある。 たとえば「相対パスのみを保持できる型」のようなものを実装したくなるかもしれない。 もちろん Rust でこれは可能なのだが、 str のような (値として利用するときは &str のように参照を使う) 可変長のスライスのような型は、定義し

cargo crev でコードレビューをしてみたらバグを見付けた話など Rustの依存関係の信頼性を検証する (crev) - Qiita という記事を読んで、面白そうだったので cargo-crev を実際に使ってみた。 これはコードレビュー自体を完全に自動化するためのものではなく、前準備、結果の公開・共有・利用などを支援するツールなので、コードレビュー自体は自力で行う必要がある。 そんなわけで、基本的な概念の紹介と、実際にいくらかコードレビューをしてみたところ unsafe 絡みのバグを見付けたという話と、ツールを使っての所感なんかを書く。 この記事の半分は雑な日記みたいなものなのでスッ飛ばすのが良い。 というかあまりにダラダラ書きすぎたので、後でいろいろバッサリ削る可能性もある (←放置フラグ)。 前提 このセクションは、わかっている人は読み流しても問題ない。 依存とコードへの信頼

Panic を恐れるべからず Rust で panic! や assert! の利用を躊躇うべきでないという話。 個人の見解マシマシでお送りします。 この記事は Rustその3 Advent Calendar 2019 の18日目の記事である[0]。 TL;DR 不正な値の存在の存在を許してはいけない。 不正な値が存在できてしまう時点で、未定義動作を覚悟するくらいのつもりでいるべきである。 満たされるべき条件を満たさない時点で、プログラムの内部的な整合性は既に破綻しており、未定義動作も同然の状態である。 これ以上余計なことをする前にさっさとクラッシュせよ。 整合性破壊バグから「うまく復帰」できると思うのは甘え (極論)。 もうちょっと詳しくは 本題、大雑把な指針、まとめ を参照。 いろいろな panic Rust で panic させるにも様々な方法がある。 まずはそれらを見ていこう。 O

はじめに git入門記事が巷に(というか主にwebに)満ち溢れる時代である。 で、私は「git使ってみよう！ほら簡単でしょ！」方式の入門記事を見る度に、「ブラックボックスっぽいなぁ」と思うわけである。 プログラミングにおいてもそうなのだが、とりあえず使えはするが原理や思想をわかっていない状態というのは非常に微妙で、ややもすればその言語やツールを嫌い/苦手な状態へと転がっていってしまう。 (私の場合だとPythonなんかがそうだ。) なにかブラックボックスめいたものを使うとき、そのインターフェースに統一性や合理性を見出して楽に覚えるためには、内部を理解するか思想を理解するのが一番の早道である。 そういうわけで、この記事ではgitのコマンドを見て、「それで何ができるか」ではなく「それで何が起きるか」がわかるように概念の解説を試みる。 それから、GitHubとgitは全く別の概念なので、一旦Gi

有用な文書を作るために心掛けたいこと この記事は rogy Advent Calendar 2018 の21日目の記事 (#LATECH) です。 前日の記事は STM32でマウスとキーボードを作る – 東京工業大学 ロボット技術研究会公式ブログ でした。 文書を“作る” この記事を読む皆様は、少なからず日頃から文章を書くことがあるかと思います。 文章を書き公開しようというとき、「良い文章の書き方」はいろいろなところで目にしますし、必要とあらば勉強することもあるでしょう。 しかし、文章そのものではなく「良い文書の作り方」を意識したことはありますか？ どんなに良い文章であっても、駄目な性質を多く持つ文書として公開されると、その価値は暴落します[0]。 本記事では、内容はさておき「良い文書」を作ろうというとき私が心掛けていることなどを紹介します。 良い文書とは 私の考える良い文書とは何なのか、

記憶力が 1 bit 未満になった人の話 この記事は IQ1 Advent Calendar 2018 の22日目の記事です。 揮発する記憶 記憶が揮発します。 boolean さえ覚えておけないことがしばしばあり、日常生活に難が出ます。 この記事では、どのような状況で記憶が揮発しやすく、それが何故なのか、またどのように対処すればいいのか、経験と知見を記します。 記憶力が 1 bit ない人がそれに気付く事例 右に曲がるか左に曲がるかわからない 免許合宿の教習での話。 教習所内で、次の丁字路で右か左どちらかに曲がるよう指示されたのですが、逆向きに曲がりました。 忘却までわずか十数秒。 シャンプーを使ったかわからない 風呂場での話。 いざ頭を洗おうとしてシャンプーに手を伸ばしたところで、ふと思います。 「今日はもうシャンプー使ったっけ……？」 なお、リンスを使ったかどうかも記憶できないので、

ぼくのかんがえたさいきょうの SNS (のメモ) 分散 SNS の(ユーザに面した)設計の在り方について考えたことのメモ。 ……と思ったけど、よく考えたらこれ分散関係なく SNS 全般について言えるわ。 前提 話題による選別 たとえばあるユーザ A がいたとしよう。 A は、主としてお絵描き(全年齢)、お絵描き (R18)、政治的な主張、プログラミングの話題、学校の友人との会話を行うものとする。 さて、あなたは A の投稿を自動的に受信したいと考えている。 ただし、精神の安寧を守るため、政治的な主張は閲覧したくない。 (また、 A とは学友であるとしよう。) 既存のアカウントベースでのフォロー関係やタイムラインは、こういった用途での利用にあたっていくつかの問題を抱えている。 送信者のマルチアカウント twitter をはじめ、既存の SNS サービスで既に用いられている手段である。 たとえ

この記事は、 Mastodon Advent Calendar 2017 の15日目の記事である。 前日の記事は『どうすれば変化するAPIと上手く付き合っていけるのか – Tootle Inside – Medium』、 翌日の記事は『Mastodon フロントエンド改造入門 | THE BOSS's blog』である。 あんただれ GNU Social GNU Social 個人用インスタンス勢 (gnusocial.cardina1.red) nightly 追従勢 クソザコ PR を送ったことはあるが、コードそのものに手を入れたことはない 周辺プラグイン (Qvitter 等)に PR 送ったことはある Mastodon Mastodon 個人インスタンス勢 (mastodon.cardina1.red) master 追従勢 PR とか issue は書いたことなし(純粋なユーザ)

この記事は、 Rust Internal Advent Calendar 2017 の7日目の記事である。 疑問 日常における前提 最後の式がセミコロンで終わっているようなブロックは、全体としては unit 型 (()) となる。 fn main() { let _: () = { 42; }; } 42; はセミコロンで終わる式なので、ブロックの型は unit (()) となる (playground) 絶対に実行が返ってこない、また値が作られないことを示す ! 型 (never type) [0]は、いかなる型へも暗黙に型強制[1]できる。 #[allow(unreachable_code)] fn main() { let _: i32 = panic!("Hello"); let _: Option<()> = ::std::process::exit(0); } panic! や

Mastodon が急に話題になってきた。 しかし、その哲学についてはあまり理解されていないように感じる。 Mastodon や GNU Social は、単なる「ポスト twitter 」ではない。 この記事では、 twitter の根本的な問題や、それに対する Mastodon 等の思想を解説する。 キーワードだけ先に書いておこう。 federation (連合) decentralization (脱中央集権) オープン (オープンソース、オープンな仕様) 長い文章を読みたくない人のためのまとめ でも、できれば本文も読んでほしいです。 Mastodon や GNU Social などでは、どこか信頼できる運営者のインスタンス(サーバ)にひとつアカウントを作って、そこから他のインスタンスのアカウントをフォローすることができます。 (インスタンスはグループのような意味を持つものではなく、

この記事では、ターミナルからコマンド一発で (sh code.cpp のように)ソースコードやファイルをコンパイルし、更には実行・表示できるようにするためのテクニックを紹介する。 概要 コンパイルの必要なファイルを書いたものの、いちいちコンパイルや確認にコマンドを叩いたりオプションを何度も指定するのは面倒ということは偶にある [0] 。 普通の人は素直に Make 等を使ったり、それ用のラッパー等を使ったり、エディタで提供されている機能やプラグインやシェル履歴でどうにかするものなのであろうが。 ものぐさな私は、ソースコードをターミナルから直接コンパイルし実行する方法を考えていた。 そして、以下の言語について良い方法を思い付いた。 C C++ Rust Graphviz 本当は TeX 等にもこの方法を適用したかったのだが、残念ながらうまい手が思い付かなかった。 TeX 等の他のフォーマット

この記事は、 Gentoo Advent Calendar 2016 の6日目の記事です。 昨日の記事は Gentoo on Windows 10 (Gentoo Advent Calender 2016 5日目)でした。 概要 そろそろ普段使いのラップトップが壊れそうなので、別マシンへの移行の準備をしておきたさが高まっています。 Windows 8.1 を gentoo で上書きして以来、これまで様々な設定をしてきましたが、 /etc にあるファイルの多くはコピーで済まされる設定ファイル[0]なので、移行にあたってそこまで問題になりません。 問題なのは、カーネルの .config です。 ハードウェア由来の設定が多く項目も多いため、安直にコピーしてちょっと改変すれば使えるというものでもありません。 そこで、以下のようなスクリプトが欲しくなったため、簡単に書いてみたというお話です。 設定の