kimutanskのブックマーク / 2016年7月8日

kimutansk id:kimutansk

2016年7月8日のブックマーク (3件)

blog/hapens-before-rule-in-akka.md at master · TanUkkii007/blog
アクターのロケーション透過性は、アクターがどのサーバー、どのCPUコア、どのスレッド上で実行されようが同じ挙動になることを保証する。これはプログラマがアクターの実行環境を意識しなくていいという点ですばらしい。この性質により僕のような並列プログラミングや分散システムにそんなに詳しくない開発者でも安全に並列分散システムのコードを書くことができている。アクターが並列プログラミングを簡単にするもう１つの特性はカプセル化である。アクターは内部にミュータブルな状態をもつことができ、それを安全に更新することができる。つまりvarを使うことができる。ここでもプログラマは並列環境で実行されていることを意識する必要はない。アクターの強いカプセル化は内部状態を外からのアクセスから守ってくれる。もしプログラマが並列環境を意識しなくてはいけなかったら、このアクター内のvarは@volatile宣言がされてなけれ
kimutansk 2016/07/08
メッセージ管理側でvolatile化してるので状態壊すはありませんが、false sharingはまぁ発生しますよね・・・
リンク
Infrastructure as Codeと組織構造
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定複雑な領域探索理解反応カオスな領域行動理解反応込み入った領域無秩序な領域理解分析反応明白な領域理解分類反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大きい領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能になる
kimutansk 2016/07/08
『根本的にアプリとインフラの境界線は曖昧で、つなぎ方＝アーキテクチャ』と。で、技術面以上に人間系が泥臭いのは確かにありそうです・・・

infrastructure as code
リンク
Infrastructure as Code のこれまでとこれから/Infrastructure as Code
A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation
kimutansk 2016/07/08
Infrastructure Def Toolsで広がったというのはなるほど。昔と比すといつの間にかそこまで前提になってきましたね。自動／バージョン管理／テストと。

infrastructure as code
リンク
- 2016年7月10日
- 2016年7月8日
- 2016年7月4日