サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
tanakakoichi9230.hatenablog.com
Firebaseについて、事前知識 Firebaseとは、以下のような機能群を「Serverless」の文脈でバンドルしたものである。「Serverless」として、これらの統合管理コンソールの出来栄えが秀逸。 - Firestore ... Document-oriented KVS - Cloud Functions ... AWSのLambda - Cloud Storage ... AWSのS3 - Hosting ... Web Assetsのデプロイ先の提供、CDN展開サポート - Authentication ... ユーザー管理・統合認証サービスの提供 - Cloud Messaging ... iOS/Android/Web(JS)クライアントアプリへの統合プッシュ通知サービス - その他 いうまでもなく「Serverless」とは「サーバー運用・管理レス」の意味。まさに
ScalaMatsuri 2019 Unconference Day 16時からC会場で開かれました「From Go To Scala Easy vs Simple」セッションを受けて、自分としてのまとめを記します。 ※当日のツイートまとめました。→ https://togetter.com/li/1371467 ◇ まず、私はかつてDSLを作ろうとして「プログラミング言語とは?」といったお題をある程度深く考えたことがある経緯もあって、元来次のような考えをもっていましたが、このセッションを経てそれを強化することとなった次第です。 (主張A) たぶん、「Simple」というのは、言語のSemanticsとして構成要素が十分に少なくて、それでいてどんなに複雑な構造物や機能をも応用的に組み立てられるようなことをいう。言語の構文として覚えるべきことは少ない。十分に少ない構成要素で、十分に広い応用が
J. Coplien氏、および奥様のGertrud Bjørnvig氏による、こちらの講演に参加してきました。PHPメンターズの久保氏、杉本氏他の皆様は、以前よりCoplien氏と交流(※ぃぇ、こ←れだけじゃないですが。。)があって、機会あって今回の開催に至ったとのことです。 会場は、ポート株式会社様にご提供いただきました。様々な勉強会に参加させていただいておりますが、全て主催者様、スポンサー様、そして各スタッフ様あって開催が実現されるわけで、感謝いたします。(※ポート様の入居されているビルは、TIS様、セプテーニ・オリジナル様の入居されているビルと同じでした。いつのまにか馴染みのあるビルになっていました^^ ) 濃密な3時間半でした。Coplien氏はとてもゆっくりと話していただいたので、TOEIC自己評価400台の自分にもだいぶ聞き取れました。 #dcitokyo pic.twitte
以前の記事で、DSL(Domain Specific Language)の仕組みの在り方のバリエーションを整理してみた。今回は、DSLの成立過程についての私の見立てを記す。なお、本記事中で単に「DSL」と云った場合、「外部DSL」を意味する。 ◇ プログラミング言語高級化の流れと、その先端に位置付くDSL アセンブラは低級言語で、Cは高級言語(High-Level Language)、Javaはさらに高級な言語、という言い方がある/あった。DSLはこの考え方の延長に置かれるものと捉える。つまり、現時点で考え得る「最高級」、もしくは「“超”高級」の言語、という訳だ。 より「高級」であるとは、目的の“ドメイン”のセマンティックスをより直接的に記述できる言語要素を持つ、ということである。アセンブラで、「レジスタをPushしてJump」と記述していたのは、「関数(サブルーチン)」を表したかったから
◆まとめ◆ プログラミング言語では「型」がドメインモデルを表現する重要ツールである。一方、モデリング観点からはデータ値に対する制約こそがある意味本質で、(主にNominal Subtypingが想定されるところの)型も制約の一手段なのだと気付く。 制約一般を型として扱う上でのツールとしては、Nominal Subtypingに限られること無く、依存型やStructural Subtypingを用いることができる。もう少しカジュアルには(=動的評価でよいなら)、型にDbC不変条件を常にセットしたものを考えられる。実装的には、バリデーションの一般的な仕組みをDbCを担うものとして扱う方式が取れる。目下の実現手段(=動的評価するフレームワーク)と理論的なところ(=依存型など静的評価を目指す)とを、宣言的プログラミングによる静的なセマンティックスと実行モデルの分離を以って繋いでみる。 〜・〜・〜
(※前回からの続きです。) 「サブジェクト指向」の考え方は、オブジェクト指向分析・設計における「関心の分離」に関わる一つの方策として古くから提唱されているものです。人によって多少ニュアンスに違いがありますが、私はおおよそ下記記事が説明するところの「サブジェクト指向」で理解しています。 @IT、「次世代開発基盤技術“Software Factories”詳解」-「第4回 フィーチャの実現法とサブジェクト指向パラダイム」-「可変性を実現する先進的な開発手法「サブジェクト指向パラダイム」」: http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory04/softfactory04_03.html これは2005年の記事です。なお「サブジェクト指向」でググると、OLAP、DWH用語としての「サブジェクト指向」についての記事がたくさん見つかり
こちらの会に参加いたしました。 「単独主キー主義」の是非を問う<超高速開発コミュニティ&第57回IT勉強宴会in東京> ※“予習編”の記事もご覧ください。 ◇ 懇親会含め活発に意見交換がなされ、いわゆる“学びしかなかった”会となりました。 このテーマ立ては非常に多くの文脈を含んでいて、それを紐解くこと自体、複合主キーを的確に見出すのと同じような困難さがあるように思えました。 DDDでもそうなのですが、「ユビキタス言語を捉え、定義せよ」といいつつ、DDD自体を語る言葉にブレが内包されたままです。(※DDDの自己言及的な性質)複合主キー問題もまた、この問題の構造モデル自体にバリエーションがあるようです。まーそれも当然で、DDDのいう境界付けられたコンテキストが多様に異なるところの立場から語られているからです。 ■ 改めて論点まとめ それでも、論点は、つまりは文脈は、次の三つに集約されそうです。
6月28日開催の下記のイベントに参加させていただく予定です。 「単独主キー主義」の是非を問う<超高速開発コミュニティ&第57回IT勉強宴会in東京> * 開催の経緯としては、まずは、渡辺幸三氏の以下の記事があって、 「単独主キー専用環境」と賢くつきあうために この記事を受けて「IT勉強宴会」さんは、次のようなイベントを大阪にて開催しました。 緊急開催:複合主キーは必須なのか?<第55回IT勉強宴会Light> 複合主キーは必須なのか?<第55回IT勉強宴会Light>(※主催者による記事) 複合主キーの扱い方(※イベントに参加された阪井氏による記事) 今回は、「超高速開発コミュニティ」、「IT勉強宴会」共催で、同テーマでの嬉しい東京開催が実現しました。 * 以下この問題の予習復習です。 #用語整理 o 主キー(primary key) レコードを一意に特定または指定するキー(=候補キー)の
結局のところGraph DBはどういった場面によく適用できるのでしょうか?オブジェクト指向の言葉で、 RDBと対比しながら考察してみました。 * RDBの広域構造と局所構造は次のように理解できます。 広域構造の特徴 テーブルはクラスの存在を、テーブルに格納されるレコードはインスタンスの存在を表現します。テーブルのリレーションは、クラス間の関連を表します。 局所構造の特徴 テーブルに定義されるカラムは、クラスの属性を表現します。カラムは平坦に並び、構造化データは表現しません。 ここで強調すべきは、RDBのアーキテクチャーでは、表現されているのはクラス間の関連である、ということです。個々のインスタンスの関連の状況を個別に表現してはいない、という点です。 * Graph DBは、Vertex(=頂点)とEdge(=辺)という要素から構成されます。多くのGraph DBでは、各Vertex、Edg
要約 境界付けられたコンテキストは、次のように階層的に認識すべきだろう。 (1) 複数のステークホルダー同士が一式の業務用語セットを共有している範囲としてのコンテキスト *一般に複数のサブドメイン横断的である。 (2) (1)のコンテキストと、サブドメインとのインターセクション(共通部分集合) *(1)のコンテキストをサブドメイン毎に切り分けたもの。 (3) (2)のコンテキスト内にて、一つのサブドメインの一つの管理対象に関する複数のモデル=サブジェクト *一つのサブドメインの一つの管理対象についても、例えば参照系主体モデルと更新系主体モデルといったように、複数のモデルが想定される。 ◆注意◆ ・本記事の内容は独自見解です。DDDの用語を参照、使用していますが、各用語は本記事として独自にアレンジ、再定義しています。本記事はDDDそのものを説明しているものではなく、独自の応用や解釈を述べてい
以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは? ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源(=オブジェクト)に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ(≒管理対象)に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都
6月5日に開催された、かとじゅん氏(Twitter:@j5ik2o)主催の「DDD座談会」に参加してきました。 後半戦、アルコール後は、文字通りの座談会となり、大いに盛り上がりました。 #dddzk 盛り上がってきたww pic.twitter.com/Ytgj21us5G— なおぴ! (@naopi) 2016年6月5日 #学んだことの覚え書き 原田「プロダクトの最初はやっつけで作って3ヶ月生き残ったらDDDにリファクタするでもいい。」 #dddzk— じょいとも (@joytomo) 2016年6月5日 「アトミックなロックが必要な在庫管理システムを設計をする奴は素人」w #dddzk— アンヘルシーなイキリすーたん (@a_suenami) 2016年6月5日 そういえば、在庫管理でロックなんか必要ねぇ!という話ですが、システムじゃなくて業務フローに目を向けましょうよ、ということでし
要約 エンタープライズ・システムでは、同じ用語でも、部門や担当が異なれば意味も異なっている、という状況は日常的です。各担当が各人のリアルとして見ている個々の"Fact"と、全ての担当の見解を統合的に説明できる“イデア”であり仮説である"Truth"には、乖離があるのが普通です。複数の"Fact"から唯一の"Truth"を見出すところは、まさにシステム屋に期待されているポイントではないかと思います。 Truthを見い出し得る限り、Truthを共有する統合された唯一の境界付けられたコンテキストを設置することを目指した方が、実装上の重複を避けられるなどの開発メリットを受けられます。これは普通のOO的方法論(=古典的OO)です。 対象領域の規模や複雑さからTruthを見い出し難い、あるいは見い出すことが出来ても共有し難い場合、個々のFactに寄り添って複数の境界付けられたコンテキストを設置する方が
要約 動的振る舞いのモデル化には、単に関数型というよりも、純粋関数型の一つの適用と捉えられる「データフロー・プログラミング」としての理解が有用です。データフロー・プログラミングとは数値計算処理を関数型の概念で再構成したものです。データフロー・プログラミングの要は、「アルゴリズムのライブラリー化」、即ち「演算子のユーザー定義」だと考えます。これにより「処理の単位」を自在に拡張することができます。これにより、動的振る舞いを、計算式の拡張としてモデル化することができるようになります。(※とは云っても大きな目線でいえば、関数型のセマンティクスの内です。) ◇ 先日次の記事を投稿いたしました。 →《OOは静的構造を、関数型は動的振る舞いをモデル化するのに有用だという話 - たなかこういちの開発ノート》 上記記事に対して、「ある程度理解できてある程度おもしろかったが、何かがいまいちすっきりせず少し残念
要約 関心対象について分析し理解しようとしたら、多かれ少なかれ「要素分解していく方法」を取るでしょう。「要素分解していく方法」とは構造を捉えることに関してのアプローチです。 構造を捉えるに当たって、OOは「要素分解していく方法」をよく支援します。構成要素はオブジェクト、構成要素間の関係はオブジェクトの関連、階層理解はencapsulationとして表すことができます。しかし、OOは動的振る舞いについては、implementationに“押し付けた”のみで、なんらの解法を提供していませんでした。 ところで、動的振る舞い=「手続き」と漫然と捉えていましたが、「手続き」とは万能チューリングマシンに由来する処理のモデル化でした。「手続き」以外に、チューリング完全である処理のモデルが存在しました。それがλ計算であり、関数型言語の「関数」です。 処理を「手続き」=状態の時系列的変遷と捉えている限り、モ
要約 (1) 参照系の要件はもっぱらデータ資源利用側から発せられ、更新系の要件はもっぱらデータ資源提供側から発せられる。 (2) よって、もし「フロントエンド・アプリ」と「バックエンド・サービス」とに階層分けするならば、参照系は「フロントエンド・アプリ」が装備すべきで、更新系は「バックエンド・サービス」が装備すべきである。 (3) 以上のように分離された参照系と更新系は、同一データ資源を扱っていても、もはや異なる境界付けられたコンテキストに属すると云うべきである。 (4) DDDにおける「CQRS」は、参照系と更新系が異なる境界付けられたコンテキストに置かれるとした場合の設計アプローチに関する論だと捉え直すことができるのではないか。 ◇ 参照系と更新系の非対称性について気付いたのは、かつて「ROA」と「SOA」の差異の本質は何なのかを考えた時でした。 ROAでは、リソースを比較的“裸”に公
もはや3、4年前ですが丸山先生よりCAP定理やBASEトランザクションの講義をうかがう機会がありました。今回改めてまとめてみました。 <参考資料> 丸山不二夫、「Cloudの技術的特徴について」:http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2-Maruyama.pdf 本記事は上記丸山先生の資料を基に学んだことについての考察となりますので、まずは上記資料を読んでみてください。 ■ CAP定理、Availability優先かConsistency優先か(※資料の43〜53ページについて) CAP定理とは、「Consistency、Availability、Partition(※分散構成の意味)の三つのうち、同時には二つまでしか達成できない」、とする主張です。ここで一つの命題、「Scalabilityが求められる故、分散構成(Pa
先日参加の「PHPメンターズセミナー」には相当に触発されました。本記事はその勢いのままに書いたエントリーとなります。 ※下記記事もご参照ください。 →《PHPメンターズセミナーに参加してきました》 〜・〜 突然ですが、下図は、視点Aから見ると対象物は四角に見えて、視点Bから見ると三角に、視点Cから見ると円に見えるという様子を表したものです。一つの同一の対象物なのに視点によって見え方が異なる、という現象を説明するのによく使われるようです。 図1:四角、三角、円の三面図 例えば、渡辺幸三氏が下記記事にて、ご自身の「三要素分析法」を説明するのに用いています。『一つの開発対象システムだが、「データモデル」、「機能モデル」、「業務モデル」の三つの異なる視点、観点がある。各観点での設計をそれぞれ行って擦り合わせることで、対象システムの実体が浮かび上がる。』、、、このような趣旨の説明をされています。 I
下記は一般的なn層アーキテクチャーの図です。各層をここでは「Presentation」、「Business Logic」、「Data Access」と表現しています。 ただしいくつか特徴があります。一点目は、参照系と更新系のBusiness Logicを分別して表現していること。二点目は、「Access Control」機能を明示し、かつ、参照系では「Operation」と明確に分離させていて、更新系では境界を曖昧としています。 更新系Business Logicに対して「Lifecycle Management Operations」と別名を与えています。ここで「参照系」「更新系」の用語を、低レベルI/Oとしての単純CRUDを意味するものとしては用いていません。業務データは、作成され、何段階かの更新(※一般に更新操作は複数種類ある)がなされ、最後に破棄されるという経緯を経るでしょう。業務
ここ1年ほど、コンシューマー向けのWebサービス開発のプロジェクトに参画できました。タイミングとしては、フロント側のミニマム版の先行リリースが済んだところから、バックオフィス側を含めた当初予定の機能一式が揃うまで(いわば「Ver.1.0」といったところ)です。その後の継続的エンハンスにも引き続き携わっています。 このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。 当初は本当に戸惑いました。 自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙さ
2015年現在、関数型言語が勃興しつつあります。エンタープライズ分野で関数型言語が次世代のプログラミング言語マーケットの覇権を握ることとなるのだとしたら、いつどのように握るのか、それはどの関数型言語なのか、その動向が大いに気になるところです。 ・ 関数型言語の行く末を見定めるにおいて、過去のプログラミング言語興隆の歴史はどうだったのか、エンタープライズにおける主たるプラットフォーム・アーキテクチャーの変遷に絡めつつ振り返ってみます。 今から40〜50年程前のメインフレームの時代、そのメインフレームをターゲットとしたプログラミング言語、COBOLが覇権を握っていました。 時代を下って20数年前程になるとWindowsを始めとするGUIそしてクライアント/サーバー・システム開発用として、次にはC++が覇権を握ることとなります。そしてJavaが登場しました。Javaは当初Microsoft社のW
ようやく「実践ドメイン駆動設計」を読み終わりました。 髙木正弘訳、ヴァーン・ヴァーノン著、「実践ドメイン駆動設計」 実際にありそうな開発プロジェクトのストーリーに沿うかたちで話が進められます。コードExampleが極めて具体的に示されて、どうすべきかが非常に分かりやすい参考書だと思いました。コードのExampleはJava、C#がメインでしたが、これのScala版(関数型言語版)があったら、これまたすごい参考書になりそうな予感がしました。 DDD(Domain Driven Design、ドメイン駆動設計)は、エンタープライズ・システムのアーキテクチャーに関するパターン集です。DDDが言うのは「パターン」ですので、DDDの用いる用語でそれを認識しておらずとも、DDDが言及するパターンを少なくとも部分的には適用している開発の現場は実は数多くあるはずなのです。私もその辺整理、確認したくて同書を
(※前回からの続きです。) CQRSはモデリング上の本質的な課題への対応である CQRS(Command-Query Responsibility Segregation、コマンド・クエリ責務分離)の採用は、現代的なシステムではほぼ全て必然的にそこへ帰結すると考えた方がよいと思います。CQRSという用語は「実践ドメイン駆動設計」を読むまで知りませんでした。というよりも、参照系と更新系を分離して設計しようという話をDDDが言及しているとは知りませんでした。しかし、下記記事で書いたように、要求・要件の分析観点から、参照系業務ロジックと更新系業務ロジックは非対称に構築すべきという点はむしろモデリング上の本質的な課題だとの考えを持っていましたので、CQRSはすんなり理解できました。 ※下記記事を参照してください。 《業務プロセス、業務ロジックの理解と、フロントエンド−バックエンド間I/Fの詳細》
そもそも「Reactive」とは何か? まずは参考資料をリストします。 InfoQより、「注目を集めるリアクティブプログラミング」: http://www.infoq.com/jp/news/2013/09/reactive-programming-emerging ※オーバービューとして マルレク、2013年1月21日、開催テーマ「Reactiveプログラミング」、講演資料: https://drive.google.com/file/d/0B04ol8GVySUuUmtwbmhvYWFfTzg/edit ※「Reactive」の詳説 @okapies氏、2015年6月24日開催 JJUG 講演資料、「Reactive Streams入門」(12〜66枚目): https://speakerdeck.com/okapies/reactive-streams-ru-men-number-j
ときどき参加させていただいている「Scala勉強会」にて、OE氏(@OE_uia)より、ScalaDays 2015 in San Franciscoのレポートがありました。いろいろ話はあったわけですが、その中でひとつ気になったフレーズがありました。それは、 "CRUD is dead" です。 調べましたらTwitter上でこのような会話がされているのが見つかりました。"CRUD is dead"を唱えているのはJonas Bonér氏、Typesafe社の設立者の一人で現CTOです。会話の最後の方で、 "FP is nice. But this slide is about killing 'update-in-place'. Event logging is my primary tool." ※「FP」は「Functional Programming」です。 と述べています。「「更
このページを最初にブックマークしてみませんか?
『たなかこういちの開発ノート』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く