はてなブックマーク

ROS Navigation Stack に関するもろもろ 気がついたらもう12月17日。明日の Advent Calendar の記事が一行も書けていない。。。あまり時間がないのですが、Navigation Stack に関するもろもろを120分一本勝負で書き留めます。 ROS の Navigation Stack とは ROS が提供する、経路計画やコストマップ生成のためのパッケージです。ROS Wiki が navigation にあり、ソースコードは rosplanning/navigation にまとまっています。 Navigation Stack の構成 move_base を中心に、主に4つの機能から構成されています。 Global Costmap : 大域的なコストマップ Global Planner : 大域的な経路計画 (のための Planner) Local Cost

概要 やや古い記事だけど、InfoQ のドメイン駆動設計・開発の実践には次のように書かれています。 ドメイン・クラスがData Access Object(DAO：データ・アクセス・オブジェクト)クラスに依存し、サービス・クラスがドメイン・クラスに依存するという設計上の依存関係がDDDによる実装に際してDIを"なくてはならない"ものにしています。 Python の場合、DI（依存性の注入）の実現には Inject が便利です。 利用例 ざっと100行程度でサンプルを書くと、このような形になります。 # -*- coding: utf-8 -*- import uuid from abc import ABCMeta, abstractmethod import inject def config(binder): binder.bind(UserRepository, UserMemory

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

追記: 2017-02-12 実は、自分のプロジェクトでは最近、この方法を利用していません。inject による紐付けが出来ていて、必要なメソッドが定義されていれば（duck typing）、必ずしもドメイン層のモデルとインフラ層の実装が継承関係になくても良い、というゆるい考えです。 http://qiita.com/ledmonster/items/3b108be6f0967bfe1093 また、最近の自分のプロジェクトでは、インフラ層を置く代わりに、port, adapter のモジュールを定義しています。adapter には、ドメイン層または port で定義されたインタフェースの実装を書く感じです。ドメインモデルにある概念はドメイン層に置き、外部シストムとの連携インタフェースは port に置く感じです。 時間のあるときにまた記事を書こうと思います。 概要 ドメイン駆動開発にHex

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

I searched for Value object implementation in Python, and found keleshev's implementation in github. But it doesn't provide the feature of immutability of Value object. So, I implemented property based immutable Value object class by myself. explicit property definition value based comparison, including hash Any feedbacks are welcome. ValueObject class class ValueObject(object): """ base class for

タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ

追記 (2018-10-08) 4年以上前に書いた記事ですが、Access Token として JWT を利用することは非推奨なようなので、お詫びして修正致します。 参考: どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ 概要 みんなやってるはずなんだけど、あまりまとまった情報がなかったので書いてみます。認証周りはセキュリティを気にして、みんな書きたがらないのかな？それとも私の調べ方が悪かっただけ？マサカリお待ちしてます。 認証の基本方針 +--------+ +--------+ | | | | | |----(1) Credential ------------>| | | | | | | |<---(2) Access Token -----------| | | | | | | Client | | Server | | | | | | |----(3)

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?