年末年始の短い冬休みは何もすることがなく(いや、することはいくらでもあるんですが)、ずっと Rust のコンパイルエラーと見つめ合っていました。去年は後半から久々にそこそこの時間を Rust に費やしたので、思ったことを振り返りたいと思います。 所有権と生存期間は理解できてからが本番Rust と言えば所有権と生存期間です。難しいと言われる理由です。難しいです。難しいのでドキュメントや Rust 本でもページを割いて解説されています。 Rust 本も出版されましたし、理解しやすくなったと思います。 が、所有権と生存期間は理解できてからが本番です。ある程度の規模のコードを書いて間違えて書き直してを繰り返し、設計と実装のトレーニングを積まないと身につきません。コンパイルエラーが出るたび、まだまだ理解が浅いと痛感します。 GC がないとはそういうことです。 とにかくデータ型の設計に苦労するRust
概要 Rust の std::any モジュールには Any という名前のトレイトがあります(ここで boost::any を使ったことのある C++er は何かを察する)。Any トレイトはほとんどあらゆる型に実装されるため、すなわちほとんどあらゆる型の参照を &Any で受けることができます。 std::any - Rust std::any::Any - Rust Any は “A type to emulate dynamic typing” (動的型付けをエミュレートする型)と公式リファレンスで説明されています。これを用いることで「あらゆる型の参照が入る変数を定義する」「実行時の型によって処理を分岐させる」などといった動的型付けっぽいプログラミングが可能となります。しかもダウンキャスト(Any から指定の型への変換1)の結果は Option 型で返ってくるため、パターンマッチを使
κeenです。Rustで何も考えずに標準出力に吐いてると遅いよねーって話です。 今回、標準出力に「yes」と1000万回出力するアプリケーションを書いてみたいと思います。 println! まあ、最初に思いつくのはこれでしょうか。
Lightweight Architecture Decision Records とは? Lightweight Architecture Decision Records とは、 重要なアーキテクチャの意思決定を背景と結果とともに記録する手法 です。 Architecture Decision Records は ADR とも呼びます。 一般にこれらは Wiki や コラボレーションツールに保存されます。 ADRにお役立ち情報 以下のリポジトリに実際に ADR を導入する際の手順などがまとまっています。 github.com と言ってもシンプルなもので、実際にやることといえば テンプレートを決める ファイル名のフォーマットを決める アーキテクチャの意思決定をする 意思決定内容をテンプレートにそって記載してバージョン管理ツールに残す このぐらいです。 ツール ADRのためのコマンドライン
理由 短期的に注目を集めない記事は無価値だという勘違い 人間には承認欲求を刺激すると知能が下がるバグがある 以下の機能を実装しないようにしている #Cosenseの哲学 いいねボタンが無い SNS拡散ボタンが無い projectをまたがったユーザーランキング・記事ランキング・注目記事の様な機能が無い 公開projectであっても、外部からリンクが無ければGoogleにインデックスされない project内のどこかのページ、またはページリストにリンクがあればインデックスされる そこからGoogle botが巡回している様だ 各projectのページリスト画面には「リストです」というmeta tagを付けてある そこをクロールの起点にするはず。多分。 実際、この/shokaiにページを作成した場合 特にtweet等せず、何もしなくても数時間後にはGoogleで検索できるようになっている 既に被
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く