自身のソースコードと完全に同じ文字列を出力するプログラムは Quine (クワイン) と呼ばれます。 Quine は単純に書けるものではありません。 例えば Python3 で print 関数から Quine を書き始めようとすると、引数に渡すべき文字列は自身のソースコードなので "print( から始まり、その括弧の中身も "print( ... と永遠に続いてしまいます。 # Quine を print から書き始めようとするとキリがない print("print(\"print(\\\" ... ") このように単純には書くことのできない Quine ですが、定石さえ知っていれば下図のような Quine を作れます。 謹賀新年Quineの実行結果 これは私が作った、Ruby 言語によるアスキーアート Quine です。 本稿の投稿時期はお正月でしたので、それにちなんで「謹賀新年」を

interface Animal { ... } class Dog implements Animal { ... } class Cat implements Animal { ... } こういう 「生き物のように感情移入しやすい対象」を例として使うとプログラミング技法の本質を見誤るのではないか？ という話をします。 カプセル化 多くのクラスベースオブジェクト指向言語は、アクセス修飾子によってメンバーの公開範囲を制御できます。カプセル化というやつです。 さて、publicなメンバーが誰でも見られるのはいいとして、privateなメンバーの公開先はどうあるべきでしょうか？候補は次の2つとなるでしょう。 公開範囲は「自分だけ」つまりprivateメンバーを触れるのは this/self 経由のみとする。 同じクラスであれば他のインスタンスのprivateメンバーでも触れるものとする。 ク

ユニットテストのコードカバレッジ（テストカバレッジ。ステートメントカバレッジやC0、C1など）は、不適切な運用が根強く見られます。多いのが、コードカバレッジの確保だけをテストの十分性目標にして、まずいテストを書いてしまうパターンです。 今回はこのコードカバレッジについて、現代的な開発を支えるための適切な運用について解説します。 コードカバレッジのみを直接のテストの十分性の目標にしてはいけない 結論から言うと、まずユニットテストは以下を目標として作成します。 ふるまいの仕様が実現されているか確認する プログラマが感じる品質リスク（いわゆる不吉な臭い等）が許容できる水準であることを確認する 法規制対応など、外部からのテスト要求に対応する コードカバレッジは、上記目標を達成することで副次的に確保されることを目指します。 注意点として、コードカバレッジの確保のみを直接の目標にすると弊害が大きくなり

いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記：ブコメに「設計の定義は？」とあったので末尾に追加しています。 追記(2024/8/15)：設計書ってなんだろう？というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト

カメラとの接続方法でマイクを分類することもできる。大別すると、電源の必要なマイクと電源の要らないマイクがある。まずは、電源の要不要の違いによる分類を解説することにしたい。 大きく分けると2種類。電源が必要なマイクと不必要なマイク マイクを構造で大きく分けると、電源が必要なマイクと電源が不必要なマイクに分かれる。何が違うかと言うと、概して言えば、 電源が必要なマイク＝高感度マイク 電源が要らないマイク＝低感度マイク これを読んで、「高感度マイクの方がいい」と思うなかれ。写真と同じで高感度カメラが万能ではないのは当たり前。感度は用途によって使い分ける。マイクも同じで、高感度マイクと低感度マイクは用途が全く違うのだ。 わかりやすい例を挙げると、雑踏の中でインタビューをする場合、高感度なショットガンマイクを使うと周囲の雑踏まで入ってしまう。そんな時には低感度なインタビューマイクを使えば、周囲の雑踏

TL;DR Android nRF Connect の BLE マクロのサブセットを macOS/iOS/... 上で開発する環境を用意しました。 github.com import Foundation import BLEMacroEasy // You can find your iPhone's UUID by running the following command in Terminal: // $ git clone https://github.com/Kuniwak/swift-ble-macro // $ cd swift-ble-macro // $ swift run ble discover let myIPhoneUUID = UUID(uuidString: "********-****-****-****-************")! let myMac

＠IT 開発変革セミナー 2024 春 ～Spring～ ～効率化、コスト削減にとどまらない、システム開発の在るべき姿～ 基調講演2 https://members09.live.itmedia.co.jp/library/Njc3Nzc%253D

Kapper@Linuxガジェヲタ＆異世界小説家＆生成AI＆電子工作大好き @kapper1224 昨日MicroSoftからリリースしたローカルLLMモデルのPhi-3 mini 4k Q4をllama.cppのサーバ版を動かしてみた。こいつ2.32GBしかないくせに日本語しゃべれるぞ。今までとは桁違いの性能なんですけど・・・ ./build/bin/server -m ../Phi-3-mini-4k-instruct-q4.gguf -n 128 huggingface.co/microsoft/Phi-… pic.twitter.com/DTmUmeh7JE

Pluralistic 詩人アンジェロウの「人が本性を見せたら、それを信じなさい」という言葉、政治における「すべての非難は自白である」という自明の理のを組み合わせると、次のようになる。「誰かがあなたを悪徳だと非難するたびに、その人は自分自身の本性を見せているのであり、あなたはそれを信じるべきだ」。 そうした非難について考えてみよう。CARES法による対コロナ緊急経済対策の小切手をめぐる道徳的パニックを覚えているだろうか？ 支配階級の代弁者たちは、ありとあらゆるケーブルテレビに出演し、「こんなことをしたら、誰も働きたがらなくなるだろう」と口々に不満を漏らした。労働者は、すべて――家、子供、冷蔵庫の食料など――を失うことへの恐怖心のみに突き動かされて仕事に就くのだと彼らは考えている。 これは今に始まったことではない。クリントンが福祉を破壊したとき、「施し」が労働者を怠惰にするという理屈で正当化

今年の世界報道写真大賞（プレス・フォト・オブ・ザ・イヤー）は、パレスチナ自治区ガザで５歳の姪の遺体を抱きかかえる女性を撮影したロイターの写真記者モハメド・サレム氏に贈られた。受賞した写真。（2024年　ロイター/Mohammed Salem） ［アムステルダム　１８日　ロイター］ - 今年の世界報道写真大賞（プレス・フォト・オブ・ザ・イヤー）は、パレスチナ自治区ガザで５歳の姪の遺体を抱きかかえる女性を撮影したロイターの写真記者モハメド・サレム氏に贈られた。 写真は２０２３年１０月１７日、ガザ南部ハンユニスのナセル病院で撮影。病院の遺体安置所で床にしゃがみこんだ女性が埋葬布にくるまれた子どもの遺体を抱きしめ号泣している。「配慮と敬意をもった構成」が評価された。

正しく同値でグルーピングできるかどうかと、同値分割テストの意義をごっちゃにしてます。前者は「正しいとは証明できない」後者は「このテストはコードの正しさを証明する必要条件であり十分条件ではない」です。

Google、PDF論文を劇的に読みやすくするChrome拡張「Google Scholar PDF Reader」 米Googleが「Google Scholar PDF Reader」というPDF形式の論文を読みやすくするChromeブラウザ拡張機能の提供を開始した。 プラットフォームやOSに依存せず、クリーンで、文章の構造が一貫しているPDFは、学術文書の標準的なフォーマットとして広く利用されている。しかし、一方で、引用されている他の文献にジャンプするのが難しかったり、あるいは特定のセクションを閲覧したくても、PDFの構造上、簡単に移動できないなど、閲覧性に関して不便と感じる面もある。Googleは「Google Scholar」という学術論文の検索エンジンを提供している。シンプルで分かりやすい画面構成で、良質な学術文書を効率的に見つけられるサービスである。Scholar PDF R

これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力

今日Rubyを書いていて、なんじゃこれと思った動作があった。 試しに以下のコードを実行してみて欲しい。 class Foo attr_reader :hoge, :fuga, def initialize(a, b) p a p b end end Foo.new 実行してみると分かるが、これには例外が出ない。 initializeで定義した必須引数はどうなったのか？ よくよく見るとattr_readerの引数の末尾に,がある。 つまり、このコードは分かりやすく書くと以下の様になる。 class Foo attr_reader(:hoge, :fuga, def initialize(a, b) p a p b end) end Foo.new このコードを更に分かり易く書くとこうなる。 class Foo def initialize(a, b) p a p b end attr_rea

このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

TDD（テスト駆動開発）の提唱者 Kent Beck による TDD の定義の解説を @t_wada さんが翻訳したブログが公開されました。 t-wada.hatenablog.jp ここで解説されている TDD と私のこれまで理解していた TDD（後述）を比較します。 みなさんの TDD の理解もぜひ知りたいので自身の思う TDD のプロセスを教えてください。 TL;DR 概ね一致していたようです。細かい差異としては Kent Beck は後述する PFD の「脳内の SUT 仕様（D10）」を生成するアクティビティも TDD に含まれていると主張しているようなので、仕様を分析してテストシナリオを洗いだすアクティビティを D10 の前に追加するとよさそうですね。 私の理解していた TDD PFD（Process Flow Diagram） で表現します。 プロセスを自在に設計する: PF