いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクト（Chromeや、どうもFire

俺は正規表現が得意ではない。しかし、凡そどんなプログラミング言語でも役に立つ技術なので覚えておいて損はない。だから最近になって頑張って勉強をして、業務でも適切な機会があれば必ず正規表現を用いて書くようにしている。言うまでもなく慣れてくると非常に面白い。正規表現リテラルと称して/^hoge$/と簡単に書けるRubyやJavaScriptの秀逸な設計を改めて認識してしまう。 話は変わってこんな記事がある。いい話（ウェブリオ辞めました） - アスペ日記 はてぶ数が非常に多く、退職エントリまとめでも最上位(ちなみに1位はこの人がGoogleを辞めたとき)。京大大学院卒で元Google社員という経歴から見れば、こんな浅学菲才の俺のような人間とは少し世界が異なるとは言わざるを得ない。プログラマーとしてのキャリアも翻訳ソフトで5年間、Googleで1年と俺のキャリアよりも全然長い。ただ、今日改めて読み直

2017年10月18日、James Coplienさんとその奥様であるGertrud Bjørnvigさんをお招きして、「Lean Architecture / DCI Evening 」というイベントを開催しました。日本ではソフトウェアパターンやアジャイルのリーダーとして知られるJames Coplienさんは、『 マルチパラダイムデザイン 』（1998年）でドメインとドメイン間の関係を中心に据えた設計パラダイムを提唱していました。Coplienさんは2009年、MVCアーキテクチャの考案者である Trygve Reenskaug さんと共に「DCIアーキテクチャ」を発表しました。2010年、CoplienさんはGertrudさんとともに書籍『 Lean Architecture 』を上梓、トヨタ生産方式をソフトウェアアーキテクチャに適用するリーンアーキテクチャについて、DCIアーキテク

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

You understand Event Sourcing and CQRS but are you ready for the difficult, complex edge cases in your domain? You’re a developer in a .NET/SQL Server shop. Your team has used Domain-Driven Design in the past with both success and failure. You have a new project. It’s complex - it has requirements that are new to your team and the pressure is on… It as a significant impact on the competitive advan

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

mpdosaka.connpass.com こちらに参加してきました。 会場を提供してくださったポート株式会社様、主催の@itemanさん@ksetaさんありがとうございました。 詳細は#dcitokyoにて。 オープニングの質問 short introduction trygve紹介 User story/Use case Lean/Agile 最後に short introduction こちらにもある、ATMの口座振替を例にDCIのイントロダクション。 ATM動作のDumpを表示するプログラムを例に、 1. ObjectId -> 規則性がわからない 2. ClassName -> ◯◯Account, ◯◯Account, ◯◯Currencyの順に実行されていそう。 3. RoleName -> 構造がわかる ピアジェのOperational ModelでRoleの判断基準を説明

あすかです。 プログラミングしてる時、たまに気になる話を雑めに書いてみます。 (´・ω・｀) C#、VBやJavaなど、クラスベースのオブジェクト指向言語を前提にした話ですが、this（Me）を書いているプログラム、そうでないプログラムをよく見かけます。 例えば、thisを書くのは このような場面ではthisを書きます。文法上の制約ですから当たり前です。 今回は、このようなものではなく、thisを書かなくてもいい場面の話です。 thisを書くメリット ちなみに私はthisを書く派です。 というのも、後でコードを読み返す時に、ローカル変数とフィールド変数の区別が一発で付くからです。 VSはthisを色分けしてくれますよね。 けっこう地味かもしれませんが、長いクラス（といっても500行を超えるようなクラスはめったに書きませんが）の一部分だけを読む時に、thisの存在はかなり役に立ちます。 他の

ここからはサーバーサイドにフォーカスした大規模改修の詳細についてご紹介します。 大規模改修前のサーバーサイドの構成 当時はこのようなレイヤードアーキテクチャを採用していました。縦はController、UseCase、Repository、データ層で区切り、横はコンテキスト毎にパッケージで区切られています。当初から複雑な仕様・要件でしたが、それぞれの影響範囲は明確となっているので、新規に参画するエンジニアにとっても十分に見通しの良いものとみなしていました。 事実、この設計で２年ほどエンハンスを続けてきましたが、大きな問題が発生することはありませんでした。 なぜ大規模改修が求められるようになったのか 『TOEIC対策コース』の新設が決まり、その仕様を詰めていくうちに次のことが浮き彫りとなってきました。 TOEIC対策コースと日常英会話コースとでは『レッスン』と『トレーニング』のツリー構造が根

アプリケーションアーキテクチャ設計パターン 著者 三菱UFJインフォメーションテクノロジー株式会社　斉藤賢哉　著 発売日 2017年10月12日 更新日 2023年1月6日

エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする

注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査

ってことで、例外のお話です。 どうも僕の知っている限りでは、チェック例外という言語機能をもっているのはJavaだけみたいです。 僕個人としては、すばらしい機能なんですが。 Javaで最初にチェック例外を学んだ時、「そうそう、これこれ、これが欲しかったのよ！」 って思ったあの頃の想いは今も色あせていません。 「ずっと好きだったんだぜ～♪」って斉藤和義の曲を口ずさむくらいに、今もチェック例外を愛しています。 しかし、このチェック例外、他の言語からdisられまくって、最近の言語には取り込まれないという悲しいお話になっています。 過去に様々な議論があった中で、結論としてチェック例外は役に立たないってことになったらしいです。 経緯は知らんがね、そんなん。僕には役立ってるんだから。 ってことで、僕の立場から見た、チェック例外についての考察と扱いを書きます。 反論したい方、自重をお願いします。 だって、

Haskellを学ぶ上でつまずいた所まとめ Twitter上で#1ふぉぼごとにHaskellでつまずいたところを語るで出てきたもの一覧とも言う 適切な入門記事がない Haskellをさらっと体験してみたくてWebでHaskell入門記事を読むもやる気がない(Haskellの凄さを感じられない)記事かやる気がありすぎる(初学者にとっては壁が高すぎる)記事の２つに１つでｱｯってなった 結局7shiさんの記事にお世話になりました stackによる環境構築 環境構築につまずく というのもstackの進化が早すぎて一次ソース以外信用ならんという大変な自体が原因 大半の日本語記事がすでに古くあてにならないというのは完全に一種の罠である ライブラリの使い方、Hackageの読み方 またHaskellというかstackの問題だけど、ライブラリのインポート方法がわからない問題 いや、Control.Mona

🎀にゃおきゃっと🐈Nyaocat🎀 @nyaocat 読み易さをあまり追求すると宗教になるのは、まぁその通りだと思いますが、私が普段指摘しているのは size() == 0 じゃなくて empty() を使ってくださいね、といった感じの、恐らくあまり反対される方はいらっしゃらないであろう内容が中心です。 2017-09-11 13:38:20

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の