[B! 手法] damedogのブックマーク

モデリングをはじめるまでの道筋 - 日々常々

自分の描いたものが伝わりやすいかどうかとか、正直よくわかりません。直接「わかりやすい」とか言ってもらっても、社交辞令かなーとどうしても思ってしまいます。思ってしまうのは仕方ないし、でも社交辞令と決めつけるのも失礼だよなーと思ったりもしつつ。それはそれとして、「どうやったら描けるようになるのか」みたいな話をちょいちょいされます。そんな会話を集めてセッションにしたものがモデリングのきほんです。ただこのセッションは半年前の私のスナップショットで、道筋は無い。なので改めて描いてみました。出発点は「わかりやすい」「わかりにくい」とか感じるところです。この感覚を持てるかどうかで、モデリングの向き不向きがちょっとわかるんじゃないかなと。たまにどのような表現物であっても咀嚼できてしまう方がいて、そう言う方はおそらく「わかりやすい表現」を作り出すのは難しいんじゃないかなって。できるとし

damedog 2020/08/13

リンク

自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み

長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。著者についてプログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。自動テストの限界自動テストとは私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。この記事でいう自動テストとは以下のようにテスト対象を実際に

damedog 2020/05/29

リンク

【変数を笑う者は変数に泣くぞ】20分で学ぶ！読みやすくバグを生まないローカル変数を書く方法 - Qiita

変数に泣かされた事ありますか？変数はいい大人でも泣かしにかかってきます。リリース直前であろうと、某ジャ〇アンのようにギッタンギッタンにしてきます。大抵は意図していないタイミングで書き換えられ、その結果が他のロジックに引き継がれ結果、微妙にズレた結果となり…テスト結果はプログラミングの初歩中の初歩である変数で、泣かされるなんて馬鹿らしくないですか？良い機会なので復習してみませんか？本記事について読み方重要なことだけ教えろって方は、大項目と強調文字だけ読んでください。対象者駆け出しエンジニア、２－３年目のエンジニアリーダブルコードを書きたい方目的変数の書き方について復習する。より良い変数の書き方を理解する。注意点サンプルコードはJavaScriptで書いています。すべての言語に適用可能でない可能性があります。業務でコーディングする際は、プロジェクトのコーデ

damedog 2019/07/30

リンク

Logger を Spring に DI させれば同じようなコードを毎回書かなくて済むしテスト記述性も改善できる - ~saiya/hatenablog

SLF4J などの Logger を使うときに、毎回以下のようなボイラープレートを書くのにうんざりしていませんか？少なくとも私は大変うんざりしています: class TestController { // Kotlin Example companion object { private val log = LoggerFactory.getLogger(TestController::class.java) } // 長くてつらい... } class TestController { // Java Example private static final Logger LOG = LoggerFactory.getLogger(TestController.class); // これは 1 行だが、とはいえ長いし class 名を二度書くのが辛い & コピペ間違いも起こしやすい }

damedog 2018/12/11

リンク

失敗を表現する手法としてNullObjectパターンが不適切でEitherが適切だと思う理由 - Qiita

真面目な気分出して書いていたらすごい長くて堅苦しくてもったいぶった感じになってしまった... この記事の9割は壮大な前置きですw なにこれ失敗の表現としてNullObjectパターン（以下楽なので勝手にNOPとします）を使うべきか議論をした際に論理立てて話せなかったので、持論整理をしてついでにこの場を借りて晒してみようと言う記事です。全ての状況において必ずEitherだ！と言うよりは、議論になったら僕はこう考えてますって言うためのポエムです。 DDD的な考えも少しこの記事は実装都合のみに閉じていますが、DDD的な観点からも考えてみたことがあるのでこんな記事も書いてみました。先に結論前置きではない1割の部分だけ先出します。それで「あ、そうか」とか「は？」とか思える人は以下の長大な前置きは不要ですw NOPは成功と失敗を区別しようとすると破綻する、けど区別したい事が珍しくない。

damedog 2017/03/29

リンク

GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita

2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきますネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。本家リモート upstream を追加する方法本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使いますあなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R

damedog 2016/10/14

リンク

サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog

今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About JapanとはそもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。（サーバー構成は後に記述