seki

require 'rinda/tuplespace'

class ChannelSpace
  include DRbUndumped

  class ChannelError < RuntimeError
    def initialize(str, handle)
      @channel = handle
      super(str)
    end

fumieval

-- https://github.com/ekmett/free/tree/35467bea6916a2efdd7182d071751af685344b1a

import Control.Monad.Identity
import qualified Control.Monad.Trans.Iter as I
import qualified Control.Monad.Trans.Iter.Reflection as R
import Control.Monad.State
import Data.IORef

destruct :: I.IterT IO a -> IO a
destruct m = do

matarillo

原文はマーティンファウラーの記事です。

#マイクロサービスとSOA (Microservices and SOA)

マイクロサービスについて語る時によく言われるのが「へぇー、この考え方って10年ぐらい前に流行ったただのサービス指向アーキテクチャ(SOA)だよね、10年前に見たわー」だ。この目線からのツッコミにも利点はある。マイクロサービスのスタイルというものはSOA派の人たちが支持していたものとよく似ているからだ。でも問題はあって、SOAが意味するものはバラバラすぎて、「"SOA"と呼ばれている何か」がここで述べているスタイル(訳注:マイクロサービス)とはまるで違うなんてことがすごくよくある。そういう場合は往々にして、一枚岩なアプリケーション群をESBで統合することに主眼が置かれていたりする。

特に、サービス指向のいけてない実装はこれまでいくつもいくつも見てきた。複雑な部分をESBの中に押し込めようとして[7]何年も取り組んだけれども、何百万ドルも浪費して何の価値も提供できなかったとか、モデルに統制をかけて変更を積極的に抑制してしまい、問題点の向こう側にあるものを見えにくくしてしまったとか。

確かに、マイクロサービスのコミュニティで使われているテクニックの多くは、大きな組織の中でサービスを統合してきた開発者たちが、その経験の中から育んできたものだ。「読み取る側は寛容に(Tolerant Reader)」パターンはその好例だ。Webを活用するという取り組みがなされていて、単純なプロトコルを使うというアプローチはそういった経験をふまえている――中央集権的な規約を避ける反応だ。そういうものによって複雑さが生まれてしまうのは[正直言って息が詰まる](http://wiki.apache.org/ws/We

yohhoy

//
// Dead-lock demonstration with condition_variable::notify_one()
//
#include <utility>
#include <mutex>
#include <condition_variable>

template<typename T>
class mt_slot {
  T slot_;

faithandbrave

// Copyright Akira Takahashi 2014
// Use, modification and distribution is subject to the Boost Software License,
// Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)
#include <cstddef>
namespace my_stl {

template <class Iterator>
struct iterator_traits {
    static typename Iterator::reference dereference(Iterator& it)

y-taka-23

Parameter A : Type.
Parameter beq_A : A -> A -> bool.

Section Uniq.

Require Import Arith List.

Hypothesis beq_A_true : forall x y : A,
                        beq_A x y = true -> x = y.
Hypothesis beq_A_false : forall x y : A,

pocketberserker

type ホモビルダー() =
  member __.Delay(f: unit -> _) = f
  member __.Run(f) = f ()
  member __.Yield(()) = ""
  member __.Yield(x: string) = x
  [<CustomOperation("攻め")>]
  member inline __.攻め(_, case) = case
  [<CustomOperation("受け")>]
  member inline __.受け(source: string, case) = (source, case)
  [<CustomOperation("┌（┌＾o＾）┐")>]

pocketberserker

1
2
あぁ＾～
4
こころが
あぁ＾～
ぴょんぴょんするんじゃ＾～
8
あぁ＾～
こころが

hyuki0000

N = 2016_06_01
(1..N).each do |n|
  if (N / n) * n == N
    puts "#{N} can be divided by #{n}."
  end
end
__END__
20160601 can be divided by 1.
20160601 can be divided by 20160601.

y-taka-23

名古屋モデル検査勉強会 #2

前回の勉強会では Promela の文法要素と基本的な SPIN の使い方を眺めたので、今回は LTL 式を用いた性質検査およびハンズオンを行う。

LTL 式による検査

LTL 式の構文

SPIN の LTL は命題論理の拡張となっており、各論理式の真偽が状態に依存する。