Writing a minimal Lua implementation with a virtual machine from scratch in Rust | notes.eatonphil.com
Writing a minimal Lua implementation with a virtual machine from scratch in Rust By the end of this guide we'll have a minimal, working implementation of a small part of Lua from scratch. It will be able to run the following program (among others): function fib(n) if n < 2 then return n; end local n1 = fib(n-1); local n2 = fib(n-2); return n1 + n2; end print(fib(30)); This is my second project in
問題を解決して成長し続けるために必要な事 - そーだいなるらくがき帳
私は人が成長するときは 行動した時（そしてその最中） 結果を振り返った時（失敗、成功を問わず） の2つだと考えいる。 その2つを得るには問題にチャレンジすることが非常に重要。 このことについては過去にもブログにしている。 soudai1025.blogspot.jp これはつまり、自分自身にも言えること。 成長するためには、成長し続けるには問題を解決し続けるしかない。— そーだい@初代ALF (@soudai1025) 2017年10月14日 解決できない問題にぶつかることを恐れて、問題に挑まなく鳴った時、人の成長は止まるんだよねきっと。— そーだい@初代ALF (@soudai1025) 2017年10月14日 なので逆説的に言えばこうなるなと。 そう考えた時、自分自身に課題を設定する場合、問題を選択する場合にどうしても解決済みの話や解決できる見込みの高い問題を手に取っていないだろうか？
エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会（呑み会）中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか？って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど（パッチを送るなど） 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
「実践ドメイン駆動設計」から学ぶDDDの実装入門の読了メモ – rinoguchi's techlog
値オブジェクト or Stringやプリミティブ型 Stringやプリミティブ型の不都合 オブジェクト自身が複数のプロパティを組合せ管理できない 例えば、氏名とふりがなを同時に持てないし、姓と名を別々で管理することもできない オブジェクト自体が特別な振る舞いを持つことができない 例えば、郵便番号から都道府県を取得する振る舞いを持たせることもできない オブジェクトが自分自身の不変条件を定義できない 結果として処理開始時点のバリデーションに全て頼る形になり、どこかで値が変更されてないかを気にしながら利用する必要がある 例えば、電話番号は「数値」と「-」を含む10〜11桁の文字列という不変条件を担保したい 値オブジェクトは上記の不都合を解決できる なので上記のようなケースでは、値オブジェクトを利用すると良さそう とはいえ「3.」のケースを言い出すとなんでも値オブジェクトにしなくてはいけない気がす
DDDの構成要素とマイクロサービスの単位をどう合わせるべきか - Qiita
この記事は ドメイン駆動設計 #1 Advent Calendar 2018 の 21日目 です。 前日は @mafuyuk さんの「DDDをチームに導入する際に考慮した4つのこと」でした。 明日は @dnskimo@github さんです。 この記事の内容 実務でドメイン駆動設計（以下、DDD）とマイクロサービスアーキテクチャを実践していますが、 DDDとマイクロサービスの粒度について、チームメンバーでの解釈が異なっていることもありました。 この記事では、DDDの構成要素とマイクロサービスをどう合わせるのがいいのか？ を考察していきたいと思います。 いきなり結論 先に結論を言ってしまうと、「DDDのサブドメインをマイクロサービスの単位とする」 になると考えます。 境界づけられたコンテキスト : サブドメイン（のドメインモデル） : マイクロサービス が、1 : 1 : 1 になるのが理想
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
