プログラムがメモリをどう使うかを理解する(1)
この記事の狙い この記事は、端的に言えば この図が言わんとしていることを理解できるようになるための解説を目指しています。 昨今のプログラミング環境において、メモリの管理方法やその実態は、詳細を知らずとも目的を達成できるようになっています。といっても、実際にはメモリは無尽蔵に使えません。制約が厳しい環境下で動かさねばならないプログラムもありますし、多少潤沢に使える環境であっても、無駄に浪費するよりは、必要最低限のメモリで効率よく動作するプログラムの方が、多くの場面においては良いプログラムと言えるでしょう。 メモリのことなど知らなくてもプログラムを書けるのは一つの理想ではありますが、現実的にはその裏に隠されている（抽象化されている）仕組みを知っておいたほうが有利です。また、昨今のレトロゲームにおけるタイムアタックで駆使されるメモリ書き換えのテクニックなども、何故そういったことが可能なのかを知る
今goのエラーハンドリングを無難にしておく方法（2021.09現在）
2021年7月現在、goでエラーハンドリングってどうやって扱うのが無難なのかについて、いろいろと調べました。 昔から人気な pkg/errors、Go公式がメンテナンスしていたxerrors、 go v1.13から追加されたfmt.Errorfなどエラーハンドリングの選択肢がいろいろとあるので、stacktrace欲しい場合とそうでない場合で個人的にベストだと思った方法をまとめました。 エラーハンドリングに求める要件 エラーが発生した箇所を追える エラーの原因によって処理を分岐する （場合による）stacktraceがみれる 結論 stacktraceが不要な場合 fmt.Errorfでラップし、errors.Isで判定する stacktraceが必要な場合 pkg/errors.Wrapでラップし、pkg/errors.Causeで判定する log.Printf("%+v", err)で
Wiki.js + Heroku を使って、無料で高機能の情報共有 wiki を簡単に作る
背景: GitHub wiki への不満 私の所属する研究室では、メンバー全員が１つの GitHub Organization に所属しており、情報共有はその Organization 上のリポジトリの GitHub wiki で行われています。 研究室がコンピュータサイエンス系であることもあってメンバーは GitHub や Markdown に慣れており、普段 GitHub wiki を使っていて困ることはそんなになかったのですが、それでも時々不満が出ることがありました。 不満として多いのは、色々記事を書いているうちに全体構造がよくわからなくなってしまうという点にあると思います。GitHub wiki ではディレクトリ構造を持てないので、全ての情報がリンクを経由してアクセスされることになり、段々と整理がつかなくなってしまいます。 複数のリポジトリにそれぞれ wiki を書くこともできます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
