リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート(過去のJaSSTの講演資料などが載っています) ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! Yahoo!ショッピングクーポンチームの小倉です。 前回のフロントエンド技術刷新の話とは打って変わり、今回は2019年に行ったバックエンド技術刷新の話です。 刷新前のシステムはノンフレームワークPHPのモノリスでしたが、現在は主にJava/Spring Bootでマイクロサービス化しています。今回は、その中でもっとも仕様が複雑だったマイクロサービスにおいて、ドメイン駆動設計(Domain Driven Design:DDD)を実践した話をご紹介します。 ショッピングクーポンの自由度を知る みなさんは、ショッピングの商品が割引になるクーポンをご存じでしょうか? 実は、クーポンには、ヤフーが予算をだして発行する「モールク
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR(長すぎて読みたくない) 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
A common scenario in an application is deal with authentication and authorization. As I’m a great enthusiast of Domain-Driven Design, I wonder what are the best approaches to use authentication/authorization in DDD. In the following lines I show two approaches based on an imaginary use case. I am eager to hear your comments and suggestions. Prerequisites Concepts that would be good to know: Applic
クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか?と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか?という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同
Your Calendrical Fallacy Is... Helping you navigate the insane complexity of calendrically correct date and time operations False. Even if you live in a place that doesn’t have Daylight Saving Time, you are still subject to rogue leap seconds that get inserted into our calendars every now and then. If you care about being precise, you care about leap seconds. And if you’re writing software for oth
[2020/09/09追記] 本記事の内容は著作権法改正より前に記載されたものです。 最新の情報をご確認下さい。 * 著作権法の一部を改正する法律(平成30年法律第30号)について | 文化庁 * 令和2年通常国会 著作権法改正について | 文化庁 上記に関連して、次の記事を記載致しました。 * 【2020年度版】個人用クローラーの開発手順とその注意点 - Qiita はじめに Webスクレイピングで誰も嫌な思いをしなくて済むように、注意事項一覧を作りました。 ただ、法律の専門家による解釈ではないので責任は取れません。 この記事は、クリエイティブ・コモンズのCC-BYで公開致しますので、ご自由にご改修下さい。 データをダウンロードする時 目的は下記のものに限る。 * 個人や家族間で使用する * Web検索サービスを提供する * 情報解析をする ※参考:著作権法第30条・著作権法第47条(6
yapcjapan2016_lt.md 5分でわかる Perl and web security ma.la CSRFとかXSSとか CSRF: フレームワークの機能使って下さい XSS: Xslateとか自動エスケープして下さい、jsの動的生成はするな 終わり 本題 YAPCなのでPerl固有の問題について解説します。 Webアプリケーションの一般的な流れ パラメータ受け取る(フォームとかJSONとか) 何らかの処理をする レスポンスを返す(HTMLとかJSONとか) フォームやJSONを安全に受け取るには paramはscalarで受け取りましょう Why $params = { name => $r->param("name"), value => $r->param("value"), } これをやると ?name=hoge&name=fuga で壊せる。 list context
はじめに Vue.jsは軽量ですが、数万件のリストを並べるとそりゃ普通につらい。 だから目に見えるとこ以外はdom描いてもらうのやめるってコードです。 デモ デモ(jsfiddle) コード <div id="app"> <div style="overflow:auto;height:170px;" @scroll="getScrollParam"> <ul :style="listStyle"> <li style="height:17px" v-for="num in displayList">{{num}}</li> </ul> </div> </div> new Vue({ el: '#app', data: function(){ return { list:list, scroll:0,//スクロール量 scrollMax: (list.length - displayRow
静的型チェックがあったらテストはあまり書かなくて良いのか - $shibayu36->blog; で静的型チェックがあったとしても、テストをあまり書かなくて良いわけではないという話を書いた。するとブコメでいろいろ意見をもらえた。これらの意見から、関数の仕様を正しく実装していることをどう保証するのかについてもう少し深く考えてみようと思い、その考えがまとまってきたので、ブログに書いておく。 一応前提として、今回の話は自分の経験とこれまでの本を読んだ知識を元に自分で考えたものであり、何かの理論に則って話しているわけではない。この部分が違うなどあれば突っ込みを受けたい。 今回考える仕様 このようなことを考える時、非常にシンプルに考えたほうが理解がしやすいので、以下の様な仕様を持つ関数addNaturalIntを考える。 関数addNaturalIntは正の整数を二つ受け取り、足しあわせて正の整数を
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
書籍「エリック・エヴァンスのドメイン駆動設計」にある全パターンを、3枚の俯瞰図にまとめます。ボリューミーなこの本を攻略するのに、この本自身にある「大規模な構造(第16章)」という戦略に倣おうと考えたからです。巨大なシステムに包括的な原則がなく、そのせいで各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木を見て森を見ず」になってしまう。全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があるのだ。「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。第16章 大規模な構造 P447-448「パターン」の仔細を見る前に、各々の「コンテキスト」の中での「立ち位置」をわかっておいたほうが、理解が「速い」し「深まる」と思います。まず「全体における部
規約ってほどでもないけど、jQuery でコード書くときは以下みたいな感じで書くことが多くなった。 どう書こうが好みだろうけど、jQuery オブジェクトに $ を付けるくらいはしといたほうがよい。
2014-05-22 WEBプログラマの私が開発現場で学んだSEOを一挙公開! SEO 誰もが悩むSEOですが、私が沢山のWEBサイトを開発してきた中で、これさえ対応すればSEOは問題無いよ!というものをまとめたので、公開してみようと思います。SEOは Search Engine Optimize の略で、言葉通り検索エンジンに対する最適化です。決してユーザビリティの向上等、ユーザへの施策では無い事を理解しましょう。(プログラマーなら)最低限SEOをやっておくべきであり、その後にマーケティングやユーザビリティ向上を目指しましょう。 では早速見ていきます。 ちょっと長いですが、頑張っていきましょう!! ■ htmlタグ titleタグ 対応しないとどうなるか titleタグが無い場合や「無題ドキュメント」等となっている場合、検索エンジンが頑張って自動的にタイトルを表示してくれます。すると
僕はコマンドラインで使うシェルスクリプトを書くことがけっこうあるんだけど、インターフェイスというか呼び出し方はとても大事だと思ってるので、そこにわりと時間をかけて考えるようにしてる。実装はいつでも変更できるけど呼び出し方を変えた時は利用者にも変更を強いるので、できれば最初から良い設計で作りたいと思っている。 そこで、僕がシェルスクリプトのオプションとか引数とかの仕様を決める上で注意していることをまとめてみた。シェルスクリプトや、その他コマンドラインのツールを作るときに参考にしてほしい。 シェルの種類は bash や zsh を想定してるけど、実装によらない話なのでどんなシェルでも使えると思う。 エラーの時に Usage (使い方ヘルプメッセージ)を表示するのはやめる エラーになった時に Usage (使い方ヘルプメッセージ) を表示するスクリプトがあるけど、やめたほうがいいと思う。例えばこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く