内的品質を無視せざるを得ない状況に陥るな - Object.create(null)
ソフトウェアの品質 ソフトウェアの品質といえば, 大まかに外的品質と内的品質に分けられます. 外的品質: ユーザーから見た品質 例: 安全かつ確実に動作すること, 操作しやすいこと 内的品質: 開発者から見た品質 例: 変更しやすいこと, 型・linter・テストなどに守られていること, 読みやすいこと 当然ですが, ソフトウェア開発者としては外的・内的どちらの品質も高い, という状態を目指すべきでしょう. 場合によって優先度こそあれ, どちらかを一方的に切り捨てるべきではありません. どちらの品質から高めるか ある程度の複雑さを持ったソフトウェア (のコンポーネント) を作る場合, 大抵はどちらの品質も高い状態に向かって一直線に進めることはなくて, まずはどちらか一方の品質が高い状態を目指すのが普通かなと思います. こういった開発の進め方については様々な流派があると思いますが, ここでは
コード書き仕草 - Object.create(null)
たまには雑談っぽいことでも書くか〜 他の開発者のためにコードを書く コードを書くにあたっての話題は尽きることがないです. ざっと思いつくようなことを挙げてみるだけでも, 性質 可読性 柔軟性 堅牢性 変更容易性 原則 驚き最小 DRY SOLID 道具 コーディングスタイル 設計 契約 テスト 型 ドキュメント などなど. ところでこれらが何のために存在するか考えたことがありますか? もちろん最終的にはユーザーにとっての価値を産むということなのですが, コードの書き方自体が直接ユーザーの価値になることはないです. まあほぼ絶対にない. 私は他の開発者のためだと考えています. コードの書き方を工夫することで, 他の開発者が価値を提供するのに役立てば良い. これは単純に私の性質の問題もあって, 元々そういう裏方的なコードを書くのが好きなのもあるし, 必ずしもユーザーに価値を提供することに興味が
共通化すれば良いとは限らない - Object.create(null)
ここのところ偶然なのか「共通化」という言葉を多く聞いているのですが, その言葉を聞くたびに身構えていることに気がついたので, この気持ちの出どころを共有しておきます. なぜ身構えているかというと, 共通化が必ずしもコードを良い状態にするとは限らないにも関わらず, それ自体が目的になってしまっている (ように見える) ことが多いからです. この手のリファクタリングの目的はあくまでコードの改善のはずで, そのことを忘れて共通化するだけで満足してしまうと, 良くてリファクタリングの効果が半減, 悪ければ逆効果になってしまいます. 個人的にコードを共通化する上で注意してほしいと思っているのは以下の二つです. コードを共通化すべきでない場合もある 共通化されたコードは一般的な原則にしたがって設計されなければならない 似たようなことは歴史の中で何度も繰り返し言われていることだろうと思いますが, 改めて
プログラムの複雑さ・表面積・グラフの構造 - Object.create(null)
特に何かしらの出典はありません. プログラムの複雑さに対する大局的で直感的な指標として, 表面積とグラフの構造というのを個人的に意識しているという話. いわゆる code smell をどう嗅ぎつけているか. 表面積 プログラムは最も単純には 1 つの入力チャンネル (引数) と 1 つの出力チャンネル (戻り値) でモデル化できます. 要するに関数ということですが, 関数型プログラミングに限らず大抵は似たような考え方ができます. graph LR yield[ ] -- 引数 --> program[プログラム] -- 戻り値 --> return[ ] 一方で現実世界で価値のあるプログラムとなるためには引数と戻り値だけでは不十分で, 実際にはその他の入出力チャンネルも必要になってきます. 例えば, 可変な変数の読み書き 環境変数の読み取り ユーザー入力の読み取り 画面への出力 ファイル
コードや Pull Request をコミュニケーションの手段として使ってほしい - Object.create(null)
レビューなり, 過去の経緯を調べる目的なりでコードや Pull Request (以下 PR) を読むとき, 書かれていてほしいと思う内容が書かれていないことが少なくない. 例えば, 背景や目的 全体的な実装方針 (特に複数の PR で一つの目的が達成される場合) これまでやったこと, 今やっていること, この次にやること 実装方法 他の方法との比較検討, あえてやらなかったこと, 今はやらないこと 気持ち 気になっていること, 迷ったこと, 自信がないこと, わかっていないこと ということで, こういうのを列挙してなぜ書いてほしいのかをまとめよう...かと思ったけど, 挙げるときりがないし, それぞれは表層的な問題でしかないのでやめた. では根底に何があるかというと, コードや PR がコミュニケーションとして成り立っているかどうかだと思う. 上に挙げたような個別の要求は, コードや P
CloudWatch Logs Insights を使って Mackerel 上にアプリケーションのメトリック監視環境を手早く構築する - Object.create(null)
この記事は Mackerel Advent Calendar 2021 の 15 日目の記事です. 昨日は id:kazeburo さんの mkr plugin install 時の403 API rate limit exceededエラーを回避する方法 でした. こんにちは id:susisu です. 普段は Mackerel 開発チームでアプリケーションエンジニアをしています. 先日 mackerelio-labs にて cloudwatch-logs-aggregator という Terraform モジュールをひっそりと公開しました. github.com この記事では, このモジュールについてと, これを使って AWS 環境で動作するアプリケーションのメトリックの監視環境を手早く Mackerel 上に構築する方法を紹介します. アプリケーションのメトリックについて (ここでア
GitHub Actions で mkr を使う - Object.create(null)
mkr とは何ですか? Mackerel の CLI です. GitHub Actions 上で mkr をセットアップする setup-mkr アクションを作りました. github.com こういう感じで uses: susisu/setup-mkr@v1 と一行書くだけで mkr コマンドが使えるようになります. steps: - uses: susisu/setup-mkr@v1 - run: mkr org env: MACKEREL_APIKEY: ${{ secrets.MACKEREL_APIKEY }} mkr の詳しい使い方はここでは紹介しませんが, mkr throw で何らかのメトリックを投稿したり, mkr wrap でジョブの成否を監視したり, mkr annotations create でイベントを記録したりといったことに利用できるかなと思います. さてここ
TypeScript で次元つきの物理量を安全に扱う - Object.create(null)
キーワード: 型レベル整数, 幽霊型 前回の記事の予告通り, TypeScript 4.0 で次元つきの物理量の計算を安全に行うためのライブラリを作ってみました. ただし現状では PoC で, 実用に足るかまでは考慮していません. github.com 物理量についての計算を行う場合, その次元や単位系には特に注意を払う必要があります. 次元の違う値同士 (例えば質量と長さ) の足し算には意味がありませんし, 単位系の違う値同士の計算は誤った結果を導いてしまいます (火星探査機の事故が有名ですね). こういった次元や単位系の取り違えを型システムを使って静的に検出する手法については, Haskell のような型システムが比較的高機能な言語においていくつか先行事例があります (例: dimensional, units). 今回作ったものは, 同様のことを TypeScript でも実現できな
テストの説明に安易に「正しく」とか書かない - Object.create(null)
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
差分検出アルゴリズム三種盛り - Object.create(null)
こんばんは. 気がつけばもうずいぶんと涼しくなってきました. 勢い余って凍ってしまったりせぬよう, くれぐれも普段の言動にはお気をつけください. はじめに さて, 我々人類にはどうしても二つの文字列 (あるいは行ごとに区切られたテキスト) 間の差分を求めなければいけない瞬間が発生します. 先人たちはそういった時のために diff のようなツールを開発し, それを利用することで文明はめざましい発展を遂げてきました. しかしながら, 使用するアルゴリズムを比較検討したい場合, 「差分」の定義を変えるなどして既存のアルゴリズムに変更を加えたい場合, diff のない異世界に飛ばされて自分で実装しなければいけない時などにおいては, 差分検出アルゴリズムについての理解が必要不可欠です. というわけで, この記事では文字列間の差分検出とは何かということと, 差分を求める三種類のアルゴリズムの紹介・解説
はてなインターンに参加したのでアレをアレします - Object.create(null)
題のとおり, 参加していました. hatenacorp.jp この記事はアレなので, 是非アレしてください. 自己紹介 参加までの流れ インターン中の生活 前半 後半 その他雑多なこと 通勤 食事 水分 Perl 語彙 おわりに インターン参加者の記事が集まるコーナー 自己紹介 ひょっとすると初めて見に来てくださる方もいると思うので. id:susisu (@susisu2413) 大学院生です (M1) 普段は JavaScript を書いていて, Perl, Web アプリケーション開発ほぼ未経験でした 詳しくはこちらをご覧ください. このブログについて - Object.create(null) 参加までの流れ はてなインターンは以前に友人の id:spring_raining が参加していたり, Twitter で頻繁に情報が流れてくることで存在を知っていました. 今年になって,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Atom のカーソル上下移動を改良するパッケージを作った - Object.create(null)