Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![大規模なリファクタリングを行う方法](https://cdn-ak-scissors.b.st-hatena.com/image/square/1dea079f3c8eee49f636638a061b722d42b294d5/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s1_20240521072209%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
下の本を読んでいた。 プログラミングの基礎 (Computer Science Library) 作者: 浅井健一出版社/メーカー: サイエンス社発売日: 2007/03メディア: 単行本購入: 17人 クリック: 409回この商品を含むブログ (105件) を見る この本はどういう本かといえば、OCamlという、関数型言語と呼ばれる中でも、あまり有名ではないほうの言語(というと失礼だけど)を使ってプログラミングの基礎を学ぶという本。そういうと、OCaml好きな人には怒られるかもしれないけれども。 良いにしろ、悪いにしろ、関数型言語の特徴は、個々のパーツを作って云々という部分が非常にクリアーになっているところであるな、とは思う。というのも、下手に「代入」を使わないことによって、むしろデータ操作の流れがクリアになるし、余りに大きいパーツにしてしまうと、そもそもその流れ自体がよくわからなくなる
「プログラマが知るべき97のこと」の90個目のエピソードは、テストに関する話です。きのこ本には本当に多くのテストに関するエピソードがあります。テストの書き方、目的、心構えなど様々なテストに関する重要なトピックがありますが、このエピソードでは「誰のためのテストか?」という点について書かれています。56ー未来へのメッセージなどでも書かれていますが、プログラムを現在の自分の自己満足にしてはなりません。テストも同様であり、自分の為や製品の品質の為ではなく「コードを見る人のため」にテストを書く事が良いテストの条件です。 ・コンテキスト、出発点、満たすべき事前条件がわかる。 ・ソフトウェアがどのように起動されるかがわかる。 ・期待される結果と、確認すべき事後条件がわかる。 これらの条件を満たすテストは、良いテストです。一見、当たり前のようにも思えますが、他人がテストコードを読んだとき、これらの事が明確
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の1つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」(以下リファクタリングの回帰テスト)の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
テスト駆動開発が有用だと理屈ではわかっていても、 実際になかなか適用できないと悩んでいる方は多いと思います 今回は私がRSpecを通して、自分なりの「テスト駆動開発」を見いだすまでのお話 ・・・すでにやってる方はスルーしてください(´・ω・`) 「プロ」の技術屋であれば誰でも、確実に「テスト」はやってると思います つい先日1年以上続いたプロジェクトが開発完了しまして、 運用フェーズに入ったのですが、 単体からリリースまで、当然いろいろなテストを通してます ただ、そのテスト手法が「プロセス化」されてるかというとそんなこともなく、 テスト駆動開発(TDD)へのあこがれはあるものの、 一人だからいいや・・・という感じで先送りに(´・ω・`) 昔「テストファースト」に失敗したわけ そもそも、私がこの業界に入った頃には、 「XP」とか「アジャイル」って言葉が注目されはじめてました (たぶん、5〜6年
スピリッチャルな与太話ですので、いつにも増して言葉が雑になります。 具体的に言うと、次の行から雑になります。 ウェーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーイ ※ここで言う「テストフレームワーク」って言うのは JUnit とか RSpec とか Test::More とか、 そういうものを指す。もっと適切な言葉があるかも知れない。その場合はご一報下さると助かります。 さて、テストフレームワークには3つの軽さが必要だと思う。少なくとも僕はそう思ってる。 その3つの軽さっていうのは フレームワーク自体の容量が軽いこと (小さいこと) フレームワークの動作が軽いこと (軽快であること) フレームワークの記法が軽いこと (テストが書きやすいこと) の事で、これらが揃っているテストフレームワークっていうのが良いフレームワークなんだと思う。 フレームワーク自体の容量が軽いこと (小
最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。 具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち 特定のsubtestだけを実行するのが面倒 前のテストの状態に依存したコードが書かれがち 僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。 しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en
バグを見つけたとき、どうするか。プログラマなら3つの選択肢がある。 直す 原因を調べる 再現テストをする プログラマなら、直感的に脊髄反射的に1番を選ばないだろうか。 バグを見つけた! このへんが怪しい! よし直そう! やった直った! というのが典型的なプログラマの動物的本能である。いや、そうであるかどうかは知らないけど、わたしはそうでした。 わたしがどういうデバッグをしていたかというと、当たりをつけて直してみて、直らなくて、アテが外れたなあホントはこっちがおかしいのかなーと、別のところも直してみて、ついでにあっちも直してみて、いろいろ直してるうちになにがどう正しいのかわからなくなって、いや待て落ち着け原因をちゃんと把握するんだっと思ってソースを改めて見直したり、print文を埋め込んで流れを追ってみたり、予想と違う動きをするんだけどそれはそれで正しかったり、考えたり唸ったりまたソースを見
リポジトリ https://github.com/syohex/zsh-perl-completions コード "prove -vb"みたいに、1文字オプションを連続で入力した際でも 補完を効かせるには _argumentsに "-s"オプションを指定すればよいみたい。 意味は "--"で始まらないオプションを 1文字とみなすというもの. #compdef prove typeset -A opt_args local context state line _arguments -s -C \ '(-v --verbose)'{-v,--verbose}'[Print all test lines]' \ '(-l --lib)'{-l,--lib}'[Add "lib"to path for your tests]' \ '(-b --blib)'{-b,--blib}'[Add "b
定期的なメンテナンスをRakeタスクとして登録して呼び出したいと考えました。 Rakeタスクの作り方を調べたのでメモ。 シナリオは、メール認証が一週間以上されないユーザーのレコードを削除するです。 $ rails g task inactive_user #=> inactive_userが名前 #=> rake inactive_user:xxx のように使うので名前に気をつけて # encoding: utf-8 namespace :inactive_user do desc "Users中confirm_atから1週間が経過していれば削除" #=> 説明 # $ rake inactive_user:destroy_unconfirmed のように使う # :environmentは超大事。ないとモデルにアクセスできない task :destroy_unconfirmed => :
is a totally awesome idea still being worked on. Check back later.
今朝 Node.js でマージされたPull Request「 add configure option to build with ninja 」によって、Node.js が Ninja ビルドシステムに対応になりました。 Nodeの PaaSでは Nodejitsu や Node Ninjaなど忍者シリーズで命名されたものが思い当りますが、実は今回は全く関係ありません。 Ninjaビルドシステムは、米GoogleのChromiumプロジェクトの開発者、Evan Martin氏が開発した高速なビルドシステムです。このビルドシステムが作られた経緯や背景はこの記事「Chromiumの開発者、「Chrome」でも利用されているビルドシステム「Ninja」を公開」を参照してください。 1. NodeとNinjaの関係 Node.jsは、Googleから提供されている様々なオープンソーステクノロジ
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
DevelopmentモードのBootを高速化する Zeus gem install zeus でインストール。 zeus init でzeus.jsonという設定ファイルが追加されます。 zeus startZeusサーバーが立ち上がります。 Starting Zeus server [ready] [crashed] [running] [connecting] [waiting] boot └── default_bundle ├── test_environment │ ├── test_helper │ └── cucumber_environment └── development_environment └── prerake Available Commands: [waiting] [crashed] [ready] zeus test (alias: rspec,
ACさんから教えていただいた Program Library HOWTO: http://www.linux.or.jp/JF/JFdocs/Program-Library-HOWTO/ 非常によくまとまっていて疑問が氷解しました。 重要そうなところを引用します。 静的ライブラリ .aは静的ライブラリ。arコマンドでオブジェクトファイルをまとめたもの。 静的ライブラリは -l オプションでリンクを行う 共有ライブラリ すべての共有ライブラリは「soname」という特別な名前をもつ。 ディレクトリ名libxxx.so.バージョン番号 バージョン番号はインターフェースが変わったときに変わる。 すべての共有ライブラリは「realname」という特別な名前を持つ。 soname.マイナー番号.リリース番号 「linker name」 sonameからバージョン番号を除いたもの ldconfig は
前回も軽く触れたけれども、automake/autoconfでビルド環境を作るのは少し面倒な印象があった。 ところが、autoreconfを使うと途中の面倒な作業を大幅に軽減できることがわかったので、メモがてら一連の流れについて書くことにする。 手順 ソースコードを用意する Makefile.amを用意する configure.acを用意する autoreconfを実行 あとは./configure && make && make install 1. ソースコードを用意する 今回は、以下のような簡単なソースコード(hello.c)からhelloという実行バイナリを作成するプロジェクトを作成する。 #include <stdio.h> int main(int argc, char* argv[]) { printf("Hello, world!\n"); return 0; } 2. M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く