Submit Search
Upload
Rspec、あなたならどう書く? 20190626
•
0 likes
•
339 views
K
Koske Kano
Follow
2019-06-26 gotanda.rbの発表資料です。
Read less
Read more
Software
Report
Share
Report
Share
1 of 38
Download now
Download to read offline
Recommended
Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版
Hiroki Kondo
Henrik Kniberg氏のKanban vs Scrumの翻訳です。
ドメイン駆動設計 at DDD.rb #5
ドメイン駆動設計 at DDD.rb #5
啓 杉本
DDD.rb #5 における、ドメイン駆動設計についての発表
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
SmartNewsさん主催の『SmartNews Tech Night Vol.2』でお話した内容ですm(_ _)m
正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
2016年10月25日 PMCONF発表 http://pmconf.jp/ 2016年09月16日 デブサミ関西2016発表 http://event.shoeisha.jp/devsumi/20160916/
App013 ここはあえて紙と
App013 ここはあえて紙と
Tech Summit 2016
ここはあえて紙とペン!Value Stream Mapping で開発サイクルの無駄を炙り出せ!
Project Facilitation
Project Facilitation
Kenji Hiranabe
プロジェクトファシリテーション最新版
設計書自動生成への取り組み~手書き設計書から脱却するには?~
設計書自動生成への取り組み~手書き設計書から脱却するには?~
SystemIntegrator2
IT業界ではExcelやWordによる設計書作成が主流ですが、属人化や修正漏れの問題が起きがちです。これら設計工程の課題を解決する設計書の自動生成ツールを紹介します。
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
yoku0825
2017/10/23 MyNA(日本MySQLユーザ会)会 2017年10月 https://atnd.org/events/91275
Recommended
Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版
Hiroki Kondo
Henrik Kniberg氏のKanban vs Scrumの翻訳です。
ドメイン駆動設計 at DDD.rb #5
ドメイン駆動設計 at DDD.rb #5
啓 杉本
DDD.rb #5 における、ドメイン駆動設計についての発表
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
SmartNewsさん主催の『SmartNews Tech Night Vol.2』でお話した内容ですm(_ _)m
正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
2016年10月25日 PMCONF発表 http://pmconf.jp/ 2016年09月16日 デブサミ関西2016発表 http://event.shoeisha.jp/devsumi/20160916/
App013 ここはあえて紙と
App013 ここはあえて紙と
Tech Summit 2016
ここはあえて紙とペン!Value Stream Mapping で開発サイクルの無駄を炙り出せ!
Project Facilitation
Project Facilitation
Kenji Hiranabe
プロジェクトファシリテーション最新版
設計書自動生成への取り組み~手書き設計書から脱却するには?~
設計書自動生成への取り組み~手書き設計書から脱却するには?~
SystemIntegrator2
IT業界ではExcelやWordによる設計書作成が主流ですが、属人化や修正漏れの問題が起きがちです。これら設計工程の課題を解決する設計書の自動生成ツールを紹介します。
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
yoku0825
2017/10/23 MyNA(日本MySQLユーザ会)会 2017年10月 https://atnd.org/events/91275
情報共有は、なぜGoogle Docsじゃなく、 Confluenceなのか。
情報共有は、なぜGoogle Docsじゃなく、 Confluenceなのか。
Narichika Kajihara
弊社の勉強会で発表した資料になります。Google Docsを使ってドキュメントを共有しておりましたが、Confluenceの方がベターだと思い書きました。
明日使える!デザイン思考×システム思考が身につく「 70デザイン項目」まとめ
明日使える!デザイン思考×システム思考が身につく「 70デザイン項目」まとめ
taro fumizono
デザインの「ものさし」を作った人の話がめちゃくちゃおもしろかったので、まとめてみました。 今回聞いたのは、京都女子大学の山岡俊樹先生のセミナーです。 とにかく勢いのある資料なので、勢いに乗ってご覧いただければと思います。
GitHub入門 手順編
GitHub入門 手順編
hideaki honda
もしSIerのエンジニアがSRE本を読んだら
もしSIerのエンジニアがSRE本を読んだら
Tomoki Ando
DevelopersSummit2018でプレゼンした資料です
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
Twitter:https://twitter.com/Nunerm Roppongi Product Manager Meetup #6 のLTで発表した資料 https://pm-roppongi.connpass.com/event/99971/
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama
2022年5月18日 【iCARE Dev Meetup #33】 デザイナー目線のユーザーとの向き合い方 でのスライドです。ユーザーインタビューをするとき、私たちはつねに「認知バイアス」にさられています。認知バイアスの影響を受けると、私たち自分に都合のよい情報ばかりピックアップしてしまいます。ユーザーにしっかり寄り添ったプロダクトをつくるためには、きちんとバランスのよいユーザーインタビューをする必要があります。本セッションでは、陥りがちな認知バイアスをミニワークを交えて体験し、ユーザーインタビューで気をつけるべきポイントを解説します。 なお、今日の登壇を誘ってくださった @murokaco さんが熱心な研究員(BiS というアイドルのファン)なので、 BiS(第3期)のデビュー曲「BiS -どうやらゾンビのおでまし-」をタイトルに入れてプレゼンしています。
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
DevLove関西の以下のイベントのスライドです https://devlove-kansai.doorkeeper.jp/events/75644
機械学習を用いた仕様書からのテストケース自動生成ツールSpec2Testの試作
機械学習を用いた仕様書からのテストケース自動生成ツールSpec2Testの試作
Futa HIRAKOBA
2018年2月に宮崎大学 情報システム工学科 卒業論文発表会で発表したプレゼンのスライドです。
MongoDBの監視
MongoDBの監視
Tetsutaro Watanabe
・MongoDBで何を監視すべきか ・MongoDBのコマンド・メソッドによる監視 ・運用監視ツールとの連携して監視 ・MMS(MongoDB Monitoring Service)で監視
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
2017-06-22 Rails Developers Meetup #2
Swaggerでのapi開発よもやま話
Swaggerでのapi開発よもやま話
KEISUKE KONISHI
API Meetup Tokyo #15 〜OpenAPI Specification (Swagger)特集〜 2016-07-22(金)19:00 - 21:00 API公開に向けたパイロットPJにて、設計、実装(単項目チェック)、ドキュメント、仕様公開にSwaggerを採用した際の経験談をお話します。
Lean coffee
Lean coffee
Takeshi Arai
リーンコーヒーの紹介 アジェンダのないミーティング方法 参加者が集まり、アジェンダを作り、議論を始める そんなミーティングの方法の紹介
Tableauのつまづきポイント
Tableauのつまづきポイント
Shinji Tamura
第2回 関西Tableauユーザ会資料
PayPayでのk8s活用事例
PayPayでのk8s活用事例
PayPay Corporation
Kubernetes Meetup Tokyo #22 での資料
はじめてのアジャイル
はじめてのアジャイル
Yoshihito Kuranuki
Agile Japan 2010のチュートリアルセッションで使った資料。 前半を平鍋さん、後半を倉貫が話しました。
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
年単位でトラブルを起こさないための考え方についてまとめました。システムがトラブル続きだとビジネス速度がどんどん落ちていくので、気をつけましょう。
NuxtでAPIサーバー立ててみた
NuxtでAPIサーバー立ててみた
ssuserbf0fbd
NuxtでAPIサーバー立ててみた
SQL Server のインデックス設計
SQL Server のインデックス設計
Koji Yamada
SQL Server でのインデックス設計の基本的な考え方 - 対象者 - 正規化を含めたテーブル設計は理解しているが、インデックス設計に悩んでいる方
MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版
Masahiro Tomita
MySQL Casual vol.10 での発表スライド
Ruby StyleStatsの紹介
Ruby StyleStatsの紹介
Toshihiro Gotou
Ruby StyleStatsの紹介
ENGINEER WORK!!
ENGINEER WORK!!
sinsoku listy
表参道.rb #45 https://omotesandorb.connpass.com/event/125126/
More Related Content
What's hot
情報共有は、なぜGoogle Docsじゃなく、 Confluenceなのか。
情報共有は、なぜGoogle Docsじゃなく、 Confluenceなのか。
Narichika Kajihara
弊社の勉強会で発表した資料になります。Google Docsを使ってドキュメントを共有しておりましたが、Confluenceの方がベターだと思い書きました。
明日使える!デザイン思考×システム思考が身につく「 70デザイン項目」まとめ
明日使える!デザイン思考×システム思考が身につく「 70デザイン項目」まとめ
taro fumizono
デザインの「ものさし」を作った人の話がめちゃくちゃおもしろかったので、まとめてみました。 今回聞いたのは、京都女子大学の山岡俊樹先生のセミナーです。 とにかく勢いのある資料なので、勢いに乗ってご覧いただければと思います。
GitHub入門 手順編
GitHub入門 手順編
hideaki honda
もしSIerのエンジニアがSRE本を読んだら
もしSIerのエンジニアがSRE本を読んだら
Tomoki Ando
DevelopersSummit2018でプレゼンした資料です
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
Twitter:https://twitter.com/Nunerm Roppongi Product Manager Meetup #6 のLTで発表した資料 https://pm-roppongi.connpass.com/event/99971/
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama
2022年5月18日 【iCARE Dev Meetup #33】 デザイナー目線のユーザーとの向き合い方 でのスライドです。ユーザーインタビューをするとき、私たちはつねに「認知バイアス」にさられています。認知バイアスの影響を受けると、私たち自分に都合のよい情報ばかりピックアップしてしまいます。ユーザーにしっかり寄り添ったプロダクトをつくるためには、きちんとバランスのよいユーザーインタビューをする必要があります。本セッションでは、陥りがちな認知バイアスをミニワークを交えて体験し、ユーザーインタビューで気をつけるべきポイントを解説します。 なお、今日の登壇を誘ってくださった @murokaco さんが熱心な研究員(BiS というアイドルのファン)なので、 BiS(第3期)のデビュー曲「BiS -どうやらゾンビのおでまし-」をタイトルに入れてプレゼンしています。
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
DevLove関西の以下のイベントのスライドです https://devlove-kansai.doorkeeper.jp/events/75644
機械学習を用いた仕様書からのテストケース自動生成ツールSpec2Testの試作
機械学習を用いた仕様書からのテストケース自動生成ツールSpec2Testの試作
Futa HIRAKOBA
2018年2月に宮崎大学 情報システム工学科 卒業論文発表会で発表したプレゼンのスライドです。
MongoDBの監視
MongoDBの監視
Tetsutaro Watanabe
・MongoDBで何を監視すべきか ・MongoDBのコマンド・メソッドによる監視 ・運用監視ツールとの連携して監視 ・MMS(MongoDB Monitoring Service)で監視
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
2017-06-22 Rails Developers Meetup #2
Swaggerでのapi開発よもやま話
Swaggerでのapi開発よもやま話
KEISUKE KONISHI
API Meetup Tokyo #15 〜OpenAPI Specification (Swagger)特集〜 2016-07-22(金)19:00 - 21:00 API公開に向けたパイロットPJにて、設計、実装(単項目チェック)、ドキュメント、仕様公開にSwaggerを採用した際の経験談をお話します。
Lean coffee
Lean coffee
Takeshi Arai
リーンコーヒーの紹介 アジェンダのないミーティング方法 参加者が集まり、アジェンダを作り、議論を始める そんなミーティングの方法の紹介
Tableauのつまづきポイント
Tableauのつまづきポイント
Shinji Tamura
第2回 関西Tableauユーザ会資料
PayPayでのk8s活用事例
PayPayでのk8s活用事例
PayPay Corporation
Kubernetes Meetup Tokyo #22 での資料
はじめてのアジャイル
はじめてのアジャイル
Yoshihito Kuranuki
Agile Japan 2010のチュートリアルセッションで使った資料。 前半を平鍋さん、後半を倉貫が話しました。
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
年単位でトラブルを起こさないための考え方についてまとめました。システムがトラブル続きだとビジネス速度がどんどん落ちていくので、気をつけましょう。
NuxtでAPIサーバー立ててみた
NuxtでAPIサーバー立ててみた
ssuserbf0fbd
NuxtでAPIサーバー立ててみた
SQL Server のインデックス設計
SQL Server のインデックス設計
Koji Yamada
SQL Server でのインデックス設計の基本的な考え方 - 対象者 - 正規化を含めたテーブル設計は理解しているが、インデックス設計に悩んでいる方
MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版
Masahiro Tomita
MySQL Casual vol.10 での発表スライド
What's hot
(20)
情報共有は、なぜGoogle Docsじゃなく、 Confluenceなのか。
情報共有は、なぜGoogle Docsじゃなく、 Confluenceなのか。
明日使える!デザイン思考×システム思考が身につく「 70デザイン項目」まとめ
明日使える!デザイン思考×システム思考が身につく「 70デザイン項目」まとめ
GitHub入門 手順編
GitHub入門 手順編
もしSIerのエンジニアがSRE本を読んだら
もしSIerのエンジニアがSRE本を読んだら
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
アジャイル開発とメトリクス
アジャイル開発とメトリクス
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
機械学習を用いた仕様書からのテストケース自動生成ツールSpec2Testの試作
機械学習を用いた仕様書からのテストケース自動生成ツールSpec2Testの試作
MongoDBの監視
MongoDBの監視
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Swaggerでのapi開発よもやま話
Swaggerでのapi開発よもやま話
Lean coffee
Lean coffee
Tableauのつまづきポイント
Tableauのつまづきポイント
PayPayでのk8s活用事例
PayPayでのk8s活用事例
はじめてのアジャイル
はじめてのアジャイル
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
NuxtでAPIサーバー立ててみた
NuxtでAPIサーバー立ててみた
SQL Server のインデックス設計
SQL Server のインデックス設計
MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版
Similar to Rspec、あなたならどう書く? 20190626
Ruby StyleStatsの紹介
Ruby StyleStatsの紹介
Toshihiro Gotou
Ruby StyleStatsの紹介
ENGINEER WORK!!
ENGINEER WORK!!
sinsoku listy
表参道.rb #45 https://omotesandorb.connpass.com/event/125126/
ぼくのかんがえたさいきょうの Rails スタートダッシュ
ぼくのかんがえたさいきょうの Rails スタートダッシュ
Kenji Mori
ぼくのかんがえたさいきょうの Rails スタートダッシュ
20100619 wakhok important_of_io_with_jror
20100619 wakhok important_of_io_with_jror
Yoshiharu Hashimoto
2010/06/19 に 稚内北星学園大学東京サテライト校での「JRuby on Rails システム構築入門」の出版記念講演のスライドです。
Agile japan2012 agilesamurai_shinjuku
Agile japan2012 agilesamurai_shinjuku
TomomiK
2012.03.16 AgileJapan2012 Change セッション「現場に続くAgileの道を語ろう~アジャイルサムライ読書会が変えてきたこと~ - 新宿道場紹介」にて発表した資料です。
WACATE2018Summer BPP yoshitake
WACATE2018Summer BPP yoshitake
Nobuhiro Yoshitake
http://wacate.jp/2018/summer/program.html WACATE2018 夏 BPPセッションでの資料です。 2017年4月から2018年3月までのJaSSTを振り返りながら、私が学んだことや体験したことを述べています。 #wacate
プロジェクトでRubocopを使って自動コードレビューしてみた話
プロジェクトでRubocopを使って自動コードレビューしてみた話
Cake YOSHIDA
渋谷.rb[:20150318] でLTしたい用
LINEスタンプの作り方
LINEスタンプの作り方
Aoi Motomura
私流LINEスタンプの作り方の説明です。
RubyとRのおいしい関係
RubyとRのおいしい関係
sady_nitro
2015年6月6日 第18回 岡山Ruby, Ruby on Rails勉強会
Rでを作る
Rでを作る
Nagi Teramo
tokyor 61
お前”だれ”やねん? -2012年度社内向け年次活動報告-
お前”だれ”やねん? -2012年度社内向け年次活動報告-
Kazuhito Miura
2013/03/15 自身が「所属する会社向けに行った年に一度の査定・社員セミナーを兼ねる報告会」にて使用した資料です。 ある資料にて引用したいため公開します。 ※社内機密が全く無いため公開しますが、利害・機密的不都合あらば公開を中止します。
2010/11/2 WebプログラマのためのScala入門勉強会@渋谷
2010/11/2 WebプログラマのためのScala入門勉強会@渋谷
wpscala
Webプログラマのための Scala 入門勉強会 @ 渋谷 12/7
Webプログラマのための Scala 入門勉強会 @ 渋谷 12/7
Hitoshi Asai
技術系同人誌を書こう #ssmjp
技術系同人誌を書こう #ssmjp
Masahiro NAKAYAMA
2018-01-12 #ssmjp 2018/01 LT祭り 技術系同人誌を書こう
Eightにおけるエンジニア主導の取り組み
Eightにおけるエンジニア主導の取り組み
Sansan
イベント : Sansan tech meetup #3 Eightを支える技術編 日時 : 2017/02/24
MF GeeksNight pplogの話
MF GeeksNight pplogの話
Naoto Koshikawa
「おれのWebサービス」について個人の視点に立った意見を中心に
プロジェクトマネジメントと開発を両立したい!
プロジェクトマネジメントと開発を両立したい!
YASUKAZU NAGATOMI
PM Beginners #4.1 LT #pmbeginners http://pmbegginers.connpass.com/event/39722/
Rails5クイックスタート
Rails5クイックスタート
Hirata Tomoko
Ruby/ Ruby on Railsビギナーズ勉強会 第13回資料です
人気の勉強会を逃さないシステム
人気の勉強会を逃さないシステム
ryonext Shimamoto
2014/1/15(水)のShibuya.rbでの発表内容です。
チーム開発積み重ね Rails Developers Meetup 2018 Day2
チーム開発積み重ね Rails Developers Meetup 2018 Day2
tatsuo sakurai
Rails Developers Meetup 2018 Day2 で発表した「チーム開発積み重ね」の資料です
Similar to Rspec、あなたならどう書く? 20190626
(20)
Ruby StyleStatsの紹介
Ruby StyleStatsの紹介
ENGINEER WORK!!
ENGINEER WORK!!
ぼくのかんがえたさいきょうの Rails スタートダッシュ
ぼくのかんがえたさいきょうの Rails スタートダッシュ
20100619 wakhok important_of_io_with_jror
20100619 wakhok important_of_io_with_jror
Agile japan2012 agilesamurai_shinjuku
Agile japan2012 agilesamurai_shinjuku
WACATE2018Summer BPP yoshitake
WACATE2018Summer BPP yoshitake
プロジェクトでRubocopを使って自動コードレビューしてみた話
プロジェクトでRubocopを使って自動コードレビューしてみた話
LINEスタンプの作り方
LINEスタンプの作り方
RubyとRのおいしい関係
RubyとRのおいしい関係
Rでを作る
Rでを作る
お前”だれ”やねん? -2012年度社内向け年次活動報告-
お前”だれ”やねん? -2012年度社内向け年次活動報告-
2010/11/2 WebプログラマのためのScala入門勉強会@渋谷
2010/11/2 WebプログラマのためのScala入門勉強会@渋谷
Webプログラマのための Scala 入門勉強会 @ 渋谷 12/7
Webプログラマのための Scala 入門勉強会 @ 渋谷 12/7
技術系同人誌を書こう #ssmjp
技術系同人誌を書こう #ssmjp
Eightにおけるエンジニア主導の取り組み
Eightにおけるエンジニア主導の取り組み
MF GeeksNight pplogの話
MF GeeksNight pplogの話
プロジェクトマネジメントと開発を両立したい!
プロジェクトマネジメントと開発を両立したい!
Rails5クイックスタート
Rails5クイックスタート
人気の勉強会を逃さないシステム
人気の勉強会を逃さないシステム
チーム開発積み重ね Rails Developers Meetup 2018 Day2
チーム開発積み重ね Rails Developers Meetup 2018 Day2
Recently uploaded
NIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしよう
You&I
今年2月に1.1→2.0に更新されたNIST CSFの変更内容について整理したいと思います。
BitVisor Summit 10「3. Thin Hypervisor on AArch64」
BitVisor Summit 10「3. Thin Hypervisor on AArch64」
BitVisor
現在、理化学研究所で研究パートタイマーとしてAArch64向けThin Hypervisorの開発をしています。今回の発表では開発背景、設計、実装、及び進捗状況などをお話します。 https://bitvisor.connpass.com/event/229993/
受発注バスターズ説明資料 株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料 株式会社batton Saleshub掲載用.pdf
ooishi1
受発注バスターズ説明資料
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
You&I
Tree Decades of Agileというブログ記事が面白そうなので、これを読んでみたいと思います。 http://www.managecomplexity.dk/blog/2024/03/12/three-decades-of-agile/
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
yamamotominami
「ASUENE」は、複雑だったCO2排出量算出業務をカンタンにサポートする、CO2排出量見える化・削減・報告クラウドサービスです。温室効果ガス・CO2排出量の算出・可視化、削減・カーボンオフセット、Scope1-3* のサプライチェーン排出量の報告・情報開示を支援します。
Grokking Simplicity探訪
Grokking Simplicity探訪
Yoshitaka Kawashima
2024/6/5のアーキ部で話したスライドです。 Stratified Designの目的を中心に、そのメリットを考えてみます。
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
fisuda
FIWARE Orion Context Broker の日本語の解説資料です。Orion Context Broker version 4.0.0 に対応しています。
Recently uploaded
(7)
NIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしよう
BitVisor Summit 10「3. Thin Hypervisor on AArch64」
BitVisor Summit 10「3. Thin Hypervisor on AArch64」
受発注バスターズ説明資料 株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料 株式会社batton Saleshub掲載用.pdf
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
Grokking Simplicity探訪
Grokking Simplicity探訪
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
Rspec、あなたならどう書く? 20190626
1.
RSpec あなたならどう書く? 20190626 gotanda.rb #37
2.
お前誰よ?
3.
自己紹介 •菅野 幸助 • バックエンドエンジニア (Rails歴3年くらい) •
Linc wellという医療スタートアップで Rails触ってます。 • 個人では最近Apollo + Typescriptなど • Twitter: @saiid_kk • Github: saiidalhalawi • note: https://note.mu/saiid114
4.
お仕事 https://jp.techcrunch.com/2019/05/27/linc-well-fundraising/
5.
ここから本題
6.
• Rspecでテストを書いていて「動くけど、本当にこれでい いんだろうか・・・」と、思うことありませんか? • レビューもCIもパスするし、問題がある訳ではないけ ど・・・ •
どうにもしっくりこない時がけっこうある -> 他の人がどう書いてるのか気になる • 色々な流儀や考え方を知りたい テストのモヤモヤ
7.
そこで、アンケートを とりたいと思います
8.
•「いつもこう書いてる」 •「規模やチームによる」 •「こっちの方が好き」 •「これ以外ありえない!」 •・・・etc 色々あると思いますが、 思い思いの判断基準でご回答ください。
9.
題して
10.
RSpec、あなたならどう書く?
11.
第1問
12.
Request Spec は
. . . 1. Actionごとに分ける 2. Controllerごとに分ける
13.
第2問
14.
System Spec は
. . . 1. 重いので大事なとこだけ 2. なるべく多くのケース書きたい
15.
第3問
16.
SharedExamples は .
. . 1. やり過ぎると逆に読みにくいので あまり使わない 2. DRY!DRY! 積極的に使う
17.
第4問
18.
before/after(:all) は .
. . 1. 便利だから使う時もある 2. Rubocopで禁止 https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/BeforeAfterAll
19.
第5問
20.
RSpec/NestedGroupsは . .
. 1. 構造化させたいので許可 2. Rubocopで禁止
21.
第6問
22.
テストデータの定義は . .
. 1. 呼び出し元でつくる 2. 呼び出し先でつくっておく
23.
第7問
24.
時間は . .
. 1. 止める 2. つくる
25.
第8問
26.
テストの説明は . .
. 1. 日本語 2. 英語
27.
第9問
28.
複雑な事前データは . .
. 1. beforeでまとめて派 2. letで組み上げる派
29.
第10問
30.
it スコープ内は .
. . 1. 絶対に汚したくない! 2. ある程度柔軟に
31.
以上で終わりです
32.
• Request Specは
・・・ Actionごと • System Specは・・・大事なとこだけ • SharedExamplesは・・・あまり使わない • before/after(:all)は・・・禁止 • NestedGroups・・・使う • テストデータの定義は・・・呼び出し元でつくる • 時間は・・・つくる • テストの説明は・・・英語 (背伸び) • 複雑な事前データは・・・letで組み上げる • itスコープ内は・・・絶対汚したくない! 私の場合
33.
回答を見ていると なんとなく人となりが 見えてきますね(!?) ‘’ Tell me
how you write RSpec tests, I'll tell you who you are. ’’
34.
皆さんは どうだったでしょうか?
35.
• Request Specは
・・・ Controllerごと • System Specは・・・大事なとこだけ • SharedExamplesは・・・積極的に使う • before/after(:all)は・・・ • NestedGroups・・・使う • テストデータの定義は・・・呼び出し先(Factory)でつく る • 時間は・・・つくる • テストの説明は・・・日本語 • 複雑な事前データは・・・letで組み上げる • itスコープ内は・・・ある程度柔軟に 当日のアジャイル集計結果(目視) やや優勢 やや優勢 ややこっち 優勢 やや優勢 優勢 やや優勢 圧倒的優勢 やや優勢 勝敗つかず(ケースによる)
36.
他にも「この2択は?」 というものがあれば 是非知りたいです
37.
WE ARE HIRING
!! 的な https://www.wantedly.com/projects/324351
38.
ありがとうございました m(_ _)m
Download now