What are the most interesting equivalences arising from the Curry-Howard Isomorphism?
I came upon the Curry-Howard Isomorphism relatively late in my programming life, and perhaps this contributes to my being utterly fascinated by it. It implies that for every programming concept there exists a precise analogue in formal logic, and vice versa. Here's a "basic" list of such analogies, off the top of my head: program/definition | proof type/declaration | proposition inhabited type | t
書きやすく、レビューしやすいRSpecのためのRSpec拡張ライブラリ(Gem) RSpecZ の紹介 - Qiita
先日、 表参道.rb に参加させていただき、LTをさせていただきました。 Matz さんがいるとは知らず、驚きました。 なんとそこでMatzさんから「本家 RSpec にPR出したら？」とコメントをいただき、PRの出し方のアドバイスまでいただきました（ 煽り大事 とのこと）。 まだ本家にPRは出せていないのですが、意外と興味持ってくださる方が多いということがわかったので、まだまだ作って間もないライブラリですが、興味ある方に意見をいただきたいので、紹介記事を投稿することにしました。 RSpecZ とは RSpecの問題点である、 長い 、 レビューつらい の解決を目指す RSpec の拡張ライブラリです。 現状では、RSpec の、 let , context , subject などを拡張したメソッドなどを用意しています。 将来的には、Generatorや構文解析などをしてRSpecの書き
Coq/SSReflect/MathCompの設定
[2024-10-11 Fri]: Sonoma 14.6, Coq 8.20, MathComp 2.2.0 [2023-02-24 Fri]: Ubuntu 22.04.1 LTS, Coq 8.16.1, MathComp 1.16 [2023-01-06 Fri]: Ubuntu 22.04.1, opam 2.1.4, ocaml 4.14.1, Coq 8.16.1, ProofGeneral 4.6, MathComp 1.15.0, MathComp-Analysys 0.6.0 [2022-09-09 Fri]: Ubuntu 22.04.1, Coq 8.15, MathComp 1.15 (opam), ProofGeneral 4.6 [2022-08-03 Wed]: Windows 11, Coq 8.15, MathComp 1.15 (WSL 2) [202
やさしいRubyメタプログラミング: RSpecを自分で作って学ぶ（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Build your own RSpec - a gentle introduction to metaprogramming in Ruby 原文公開日: 2018/03/01 著者: Paweł Dąbrowsk 以下の記事を参考に、テスト対象コードとテスト用コードを1つのファイルにまとめて記述しておくと試しやすいでしょう。 Rails tips: コードとテストを同じファイルに書けるRSpec autorun（翻訳） RubyのDSLとメタプログラミングのやさしい入門記事です。 DSL（Domain Specific Language）: 言語を新たに作ることで特定の問題を記述する、プログラミング技法の一種です。Ruby on Railsフレームワークのルーティングや、RSpecの構文はDSLのよい例です。 メタプログラミン
RSpec の feature spec でヘッドレス Chrome を使う - Speee DEVELOPER BLOG
Speee エンジニア組織推進室の服部 (yhatt) です。 みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpec、Capybara、 Poltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。 そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。 ヘッドレス Chrome ことはじめ | Web | Google Developers [A
rails, rspecでVimのsnippetを使うためのベストプラクティス (自己流) - Qiita
Vimにはtextmateちっくなsnippet補完を実現するためのプラグインがいくつかあります。 neocomplcache-snippets-complete, snipMate, UltiSnipなどなど。 私が利用しているのは、neocomplcache-snippets-completeなので、それを利用する時の流れについての話です。 neocomplecacheを使っていると、補完が統合されるので、neocomplecacheユーザーは大体これに落ち着くと思います。 ちょっと調べたところだと、UltiSnipはかなり高機能っぽいのですが、pythonインターフェースが必要で、ちょっと複雑過ぎるかもしれません。 読み込みのルール 現在のneocomplecacheは、内部でvimのバッファが持っているファイルタイプとは別に、 独自のファイルタイプ情報を持っています。 最近になって
指定したspecのファイル/ディレクトリだけrspecを実行する - Qiita
exampleが大量になってくると毎回毎回全部起動するのは大変なので指定したファイルやディレクトリのspecファイルだけを実行したいケース。 指定したファイルだけ
Rails: RSpecをもっとDRYに書くテクニック（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Small steps to DRYer RSpec 原文公開日: 2017/01/22 著者: Victor Shepelev-- ウクライナ在住のRubyプログラマーで、SciRubyのメンテナーとメンターでもあります。 2017/11/29: 初版公開 2023/07/11: 更新 🔗 これは何？ RSpec APIは可能な限りDRYで読みやすいDSLへと絶え間なく進化し続けています。しかし、specをさらにDRYにできる方法（トリックや追加メソッドなど）はまだまだあるのです。 警告: 本記事を読んで「この方法を使うより先に、テストしやすいコードを書けるように設計を見直す方がいいのでは？」と言いたくてたまらなくなるかもしれませんが、そうした方法は既に知られているとお考えください。 更新情報（2017/08/15）: sah
Rails: システムテストをRSpecで実行する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Rails system tests with RSpec 原文公開日: 2017/12/28 著者: Mateusz Dominiak @jnchitoさんの以下の記事も合わせてどうぞ。 rspec-rails 3.7の新機能！System Specを使ってみた Rails 5.1のSystemTestCaseを試してみた 2018/01/25: 初版公開 2023/10/12: 更新 RSpec 3.7登場前のfeature spec は、実物（またはヘッドレス）のブラウザ環境でJavaScriptの絡むアプリのやり取りをフルスタックでテストする手段でした。最近リリースされたRSpec 3.7（訳注: 現在はRSpec 4.0です）では、Railsのシステムテストを元にしたsystem specが追加されました。Rails 5
Rails tips: RSpecテストを遅くする悪い書き方3種（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 3 things that slow down and make your RSpec tests worse（現在はリンク切れです） 原文公開日: 2018/03/21 著者: Paweł Dąbrowsk 2018/05/01: 初版公開 2023/11/14: 更新 テストが遅くなる原因はさまざまで、コードに関係するものもあればそうでないものもあります。今回は、specを高速化して改善するちょっとした変更のコツをご紹介します。 🔗 1. trueかfalseだけを期待する場合はbe_truthyやbe_falseyを避ける まずは以下のコードをご覧ください。 expect(true).to be_truthy expect(1).to be_truthy expect('string').to be_truthy expe
RSpecによるRailsテスト入門
テストの原則 テストは信頼できるものであること テストは簡単にかけること テストはかんたんに理解できること スピードを重視しないこと テストの中では過度にDRYなコードを目指さないこと テストの重要なテクニック 期待する結果は能動形で明示的に記述すること 起きて ほしい ことと、起きて ほしくない ことをテストすること 境界値テストをすること 可読性を上げるためにスペックを整理すること describe: クラスの機能に関するアウトラインを記述する。 context: 特定の状態に関するアウトラインを記述する。 before: スペック内の重複コードをきれいにするために必要不可欠。describe ブロックの中にある各 example の前(before)に実行される RSpecのセットアップ group :development, :test do gem "rspec-rail
「Docker時代の分散RSpec環境の作り方」の補足 - Qiita
この記事は、大江戸Ruby会議06で発表した Docker時代の分散RSpec環境の作り方 // Speaker Deck の補足です。 何人かに質問されたことや、良いことばかりじゃなくて現状存在している課題について補足として、ここで書かせてもらいます。 まず、良く質問されたのがテストケースの分割方法です。 テストケースの分割は、現状とても雑にやってます。 まず、featureスペックのファイルだけをリストアップして適当にシャッフルして詰めます。 その後で、他のテストケースを順番に詰める、という感じです。 多少、無駄ではあるんですが、前のテスト結果のプロファイルの収集と詰めるロジックを書くのをサボっても、現状大分早くできたので、とりあえず作りを簡単にする方を優先しました。 課題の中で最も大きな問題は、ログが見辛いという点です。 ECSはログを準リアルタイムで確認するのが、かなり難しいという
Rails tips: RSpecの`let`ブロックや`before`ブロックは基本避けるべき（翻訳）｜TechRacho by BPS株式会社
2018.04.11 Rails tips: RSpecの`let`ブロックや`before`ブロックは基本避けるべき（翻訳） 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: RSpec - you should avoid let and before blocks to use natural flow 原文公開日: 2018/02/06 著者: Paweł Dąbrowsk Rails tips: RSpecのletブロックやbeforeブロックは基本避けるべき（翻訳） RSpecの作者はそれなりの理由があってbeforeやletブロックを考案しましたが、本当に必要でない限りこれらの利用は避ける方が賢明です。理由は以下のとおりです。 テストの本体からletの定義にジャンプ（またはその逆のジャンプ）することで、テストの自然な流れを妨げることになります。 letを使うとテスト
Reddit - Dive into anything
Computer Science Theory and Application. We share and discuss any content that computer scientists find interesting. People from all walks of life welcome, including hackers, hobbyists, professionals, and academics.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What are the strengths and weaknesses of the Isabelle proof assistant compared to Coq?
Using forall within recursive Function definition
Redirecting…
collacoq
CarrierWaveを使いつつfixtures + minitestでtestを書く - Qiita
GitHub - krtx/agda-handson: agda handson
