git diffでのパッチ作成＆適用スクリプト
gitのdiffでパッチを作成
#!/bin/sh PATCH_FILE=/tmp/patch.`date +"%Y%m%d%I%M"` echo "---" > $PATCH_FILE git diff --stat | sed 's/^[ \t]*//' >> $PATCH_FILE echo >> $PATCH_FILE git diff >> $PATCH_FILE echo "--" >> $PATCH_FILE git version >> $PATCH_FILE echo Finish:$PATCH_FILE
パッチの適用(第1引数にパッチファイルを指定)
#!/bin/sh patch -p1 < $1
Ryu Topology Viewer On Docker
RyuにOpenflow switchのトポロジを表示できる機能を試してみた。
ソースに書いてあるとおりのコマンドを実行すると「アドレスを既に使ってます」というエラーがでる。
#ryu run --observe-links /usr/local/src/ryu/ryu/app/gui_topology/gui_topology.py
(...中略...)
instantiating app ryu/app/gui_topology/gui_topology.py of GUIServerApp
hub: uncaught exception: Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 52, in _launch
func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 70, in __call__
self.server_loop()
File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 93, in server_loop
datapath_connection_factory)
File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 108, in __init__
self.server = eventlet.listen(listen_info)
File "/usr/local/lib/python2.7/dist-packages/eventlet/convenience.py", line 39, in listen
sock.bind(addr)
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use
(297) wsgi starting up on http://0.0.0.0:8080/そこで、GUIトポロジ用にコントローラ(ryu2)のコンテナを別に立てました。
(ryu2をdocker runさせるときに-p 8080:8080でポートフォーワードのオプションをつける)
Web server for viz
+-------------+ +-------------+
| ryu | | ryu2 |
| (Container) | | (Container) |
+-------------+ +-------------+
eth1 | 192.168.100.100/24 eth1 | 192.168.200.100/24
| |
| br3 br4 |
-+------------+- -+------------+-
| |
| eth4| 192.168.200.200/24
192.168.100.200/24 |eth3 |
+-------------+
| lagopus | eth2 br2
| (Container) |--------------------+
+-------------+ 169.254.0.200/24 |
| eth1 |
| 169.254.0.100/24 eth1 | 169.254.0.2/24
| +-------------+
| | server2 |
| | (Container) |
| +-------------+
| +-------------+
| | server1 |
| | (Container) |
| +-------------+
| eth1 | 169.254.0.1/24
-+-----------+-
br1Dockerで同じブリッジにできない＆ルーティングが面倒だったので、
別セグ、別ブリッジにて新しいコントローラのコンテナを立てる。
構成に合わせてlagopusの設定ファイルも編集する。
# vim /usr/local/etc/lagopus/lagopus.conf
interface {
ethernet {
eth1;
eth2;
}
}
bridge-domains {
br3 {
port {
eth1;
eth2;
}
controller {
192.168.100.100;
}
}
br4 {
controller {
192.168.200.100;
}
}
}ryu2で下記のコマンドを実行して、lagopusを再起動(killしてlagopusコマンド実行)する。
#PYTHONPATH=. ryu run --observe-links ryu/app/gui_topology/gui_topology.py
lagoshでコントローラがふたつになっているか確認。
# lagosh f9e9b97c595f> show controller 192.168.100.100 Controller 192.168.100.100 Datapath ID: 000000003777c04e Connection status: Connected f9e9b97c595f> show controller 192.168.200.100 Controller 192.168.200.100 Datapath ID: 000000002066009b Connection status: Connected f9e9b97c595f>
肝心のトポロジの画面が下のとおり。
描画でD3.jsを使っているので、ソースをいじればいろいろ拡張できそうです。
Lagopus + Dockerでの性能評価
こちらを参考にDockerにLagopusの環境を作り、
スループットを評価を行いました。
チューニングなどは特に行っておらず、Intel DPDKの支援もなしです。
チューニングの余地はまだまだあるので、今後も評価を継続していきます。
[ Environments ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
CPU: Intel(R) Core(TM)2 Quad Q8200@2.33GHz
Memory: 4Gbyte
OS: Ubuntu 14.04.1 LTS (64bit)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Docker Version: 1.0.1
Docker Image: Ubunu 14.04
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Ryu Version: 3.13
Lagopus Version: 0.1
Lagpus DPDK Option: No
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[ Network chart ]
+-------------+
| ryu |
| (Container) |
+-------------+
eth1 | 192.168.100.100/24
|
| br3
|
eth3 | 192.168.100.200/24
+-------------+
| lagopus | eth2 br2
| (Container) |--------------------+
+-------------+ 169.254.0.200/24 |
| eth1 |
| 169.254.0.100/24 eth1 | 169.254.0.2/24
| +-------------+
| | server2 |
| | (Container) |
| +-------------+
| +-------------+
| | server1 |
| | (Container) |
| +-------------+
| eth1 | 169.254.0.1/24
-+-----------+-
br1
[Ryu command]
# ryu-manager --pid-file /var/run/simple_switch_13.pid --nouse-stderr --log-file /tmp/simple_switch_13.log /usr/local/ryu/ryu/app/simple_switch_13.py &
[lagopus command]
# lagopus -d -l /tmp/lagopus.log -- -- -p3 &
[ Perfomance Test ]
Case1: [server1]->[lagopus] # iperf -c 169.254.0.200 ------------------------------------------------------------ Client connecting to 169.254.0.200, TCP port 5001 TCP window size: 340 KByte (default) ------------------------------------------------------------ [ 3] local 169.254.0.1 port 37516 connected with 169.254.0.200 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 19.4 GBytes 16.6 Gbits/sec Case2: [server1]->[lagopus]->[server2] # iperf -c 169.254.0.2 -w 16k ------------------------------------------------------------ Client connecting to 169.254.0.2, TCP port 5001 TCP window size: 32.0 KByte (WARNING: requested 16.0 KByte) ------------------------------------------------------------ [ 3] local 169.254.0.1 port 36218 connected with 169.254.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 1.50 MBytes 1.24 Mbits/sec # iperf -c 169.254.0.2 -w 32K ------------------------------------------------------------ Client connecting to 169.254.0.2, TCP port 5001 TCP window size: 64.0 KByte (WARNING: requested 32.0 KByte) ------------------------------------------------------------ [ 3] local 169.254.0.1 port 36212 connected with 169.254.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.3 sec 640 KBytes 511 Kbits/sec # iperf -c 169.254.0.2 -w 64K ------------------------------------------------------------ Client connecting to 169.254.0.2, TCP port 5001 TCP window size: 128 KByte (WARNING: requested 64.0 KByte) ------------------------------------------------------------ [ 3] local 169.254.0.1 port 36211 connected with 169.254.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-17.3 sec 384 KBytes 182 Kbits/sec
Scala Matsuri 2014 まとめ
去年はScala Conferenceにいけなかったので、
雪辱を晴らしに今年はScala Matsuriに行きました。
満喫満喫、講演者の皆様、運営の皆様に謝謝！！
それでは、以下自分用のまとめ
_______________________________________________
タイトル：Scala Matsuri 2014
会場：株式会社サイバーエージェント
日程：2014年9月5日
【参加セッション一覧】
◆ 基調講演 - Scala 進化論
◆ sbt、傾向と対策
◆ Node.js vs Play Framework
◆ Apache Spark を用いた Big Data パイプラインの統一
◆グリー初のScalaプロダクト！チャットサービス公開までの苦労と工夫
◆Scala 上で実現された制約プログラミングシステム Scarab について
◆Scalaのマクロに実用例から触れてみよう！
_______________________________________________
【内容】
◆基調講演 - Scala 進化論
(EPFL Martin Odersky)
・Scala開発の動機
‐ Funnelをよりよくすることと
‐実践的なOOPとFPの融合
‐コアcalculasと言語との依存をゆるめる
Webサービスではイミュータブルなデータが多いためFPとの相性がいい
・PizzaとScala
PizzaはJVMで動くJavaに関数言語の要素を加えた言語
‐Pizza:代数的データ記型、パターンマッチング
‐Scala:OOPとFPをより意欲的に改善
・ScalaはJavaから持ち込まなかったものがある
publicやstatic、プリミティブ型やbreakなど
Scala.JS(Scala for Javascript)を進めており、
クライアントとサーバで同じ言語で開発ができるようになる
◆ GitBucket: Perfect Github clone by Scala
(株式会社ビズリーチ 竹添 直樹)
・Gitbucketとは
GitBucketはオープンソースのgithubのクローン
Githubからデザインも、ぱく..追従している
・Gitbuckeの開発
バックエンドでscalaのライブラリやJettyなど、
フロントエンドはbootstrap2など
型安全なので少ない人的リソースだけれども、
アグレッシブな開発ができている
既存のJavaの資産が使えるので便利
web framworkはscalatraを利用している
・今後の予定
Gitbucketにscalaのプラグインを追加できるようにする
パフォーマンス改善など
◆Fifty Rapture One-Liners in Forty Minutes(Jon Pretty)
・Raptureとは
URLやファイルURLのアクセスを簡潔にするscalaライブラリ
raptureが読み込めるものは何でもパースすることができる(jsonなど)
jsonのデータのパースやアクセッサといった利用ができる
文字列をJsonにすることもでき、四則演算子でJsonデータに
追加することができる
ex. json_data+(_.year,2019) =>[“name”:”Mark”,”year”:”20192]
文字列補完子を使ったよりディープなパターンマッチ
Jonsのパーサは自前で書いたものではないが、
逆にimport先を変えることでパーサを選べる仕様にしている（Jacksonなど)
どのパーサを使ってもシンタックスは変わらないようにしている
暗号化やxmlのパースもできる
・発表スライド http://rapture.io/matsuri/
◆(LT) LINE
バックエンドで一部scala導入、ほとんどJava。
サービス指向でシステムを構築している。
ユーザのリクエストは複数のサーバ、サービスにまたがるため
Zipkinというトレーサーで可視化している。
◆ Node.js vs Play Framework
(LinkedIn Yevgeniy Brikman)
http://www.slideshare.net/brikis98/nodejs-vs-play-framework
◆グリー初のScalaプロダクト！チャットサービス公開までの苦労と工夫
(グリー株式会社 長谷川 貴之&尾崎 俊)
グリーの主力はPHPだったが、
コネクションのたびにプロセスが立ち上がるのでつらい
動的型で保守がつらい
・Scalaにした理由
ー 並行処理が強い
ーシングルプロセス、マルチコネクション
ー 静的型づけ
・勉強のプロセス
ーコップ本で自学自習、scala逆引きを手元に置く
ーTwitterが公開しているドキュメント
ーEffective Scala(Web)
ーOSSのコードを読む
・ペアプロの実施
ーコードレビューの徹底
・内部機構
ー 並行処理はAkkaを使用(書きやすく、耐障害サポート)
ー ID生成はTwitterのsnowflakeを参考にライブラリを作成
UUIDをプライマリーキーにしたため、mysqlでランダムアクセスが
頻発してサービスが落ちる
・PHPとScalaでは監視でJVMの監視をするようになった
◆Scala 上で実現された制約プログラミングシステム Scarab について
(神戸大学情報基盤センター 宋 剛秀 )
Scarab = SATソルバ(Sat4J) + 符号化(Sugarを参考)
Sugarを参考にしたのでSATを早く解ける
Scalaのおかげで速いというわけではない
(NP完全問題なのでアルゴリズムの影響が大きい)
スライド(日本語版)
http://kix.istc.kobe-u.ac.jp/~soh/scarab/talk-jp.pdf
◆Scalaのマクロに実用例から触れてみよう！
(株式会社ビズリーチ 島本 多可子)
2.10+から追加された機能
いままでのマクロはsbtやコンパイラオプションを利用していた
マクロはexperimentalの位置づけなので
importかコンパイラオプションが必要
(今後、マクロ機能がなくなるとう噂も、、、)
・マクロのルール
ーカリー化
ー第一引数がContext
scala.metaで改善が予定されている
PHPカンファレンス関西2014
PHPカンファレンス関西2014に参加したセッションについて。
❏基調講演: 全てを結ぶ力
講演者:郡山 昭仁(BEAR Sundayの開発者)
(講演以外の内容は補足を追記)
Bear Sundayの開発の経緯やコンセプトを紹介する
基調講演らしい内容。
(補足：Bear SundayはRESTアーキテクチャで構築するリソース指向フレームワーク)
そもそもフレームワークとは何か？
アプリケーション制約がフレームワークである。
Webアプリケーションは
HTTP > Lang > Framework > App
の順で制約を受けている。
制約の上位でもあり、Webが成功した
要因でもあるHTTPやRESTの原則にしたがって、
BEAR Sundayを開発した。
BEAR開発者が考えるRESTとは？
Representational state transferが示すように
状態の移り変わり？（よくわからなかった。。。）
HTTPのセマンティックスにせまれば
開発者じゃない人にもわかりやすい？
BEARでつくられたサイト：pen online
BEAR を構成する技術要素
❏PHPでOSSを維持し続けるには
江藤竜二(baserCMS) 菱川拓郎(concrete5) 紀野 惠(Drupal)
3つのOSSのCMS(Content Management System)の関係者による
パネルディスカッション。
◆baserCMS
国産CMS。PHPのWebフレームワーク CakePHPを
ベースに開発。
コンピュータに詳しくない人でも
ホームページの構築・運用できる仕組みを目指している。
ブログやメールフォームなどのWebサイトに
最低限必要な機能を提供。
◆concrete5
アメリカのCMS。ユーザにとっては操作しやすく、
開発者にとってはMVCのアーキテクチャで開発
しやすいことを目指している。導入事例として
ケンブリッジ大学のプレスサイトやJTBグローバルマーケ
ティングのサイトがある。
◆Drupal
世界中に多くのコミュニティをもち、180言語に対応するCMS。
開発がコミュニティベースで行われているプロダクト。
特徴はWebフレームワークでもあり、CMSでもある。
❏フレームワークを使うべき3つの理由
向井賢一
べた書きのPHPのWebアプリを
フレームワークを使用したアプリへ書き換える
・Viewの分離 変更を柔軟に
・DBからの情報取得をモデル化 コントローラを明確に
フレームワーク化のアンチパターン
設定ファイルを違う場所に書く
【関連書籍】
・ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
・効率的なWebアプリケーションの作り方 ~PHPによるモダン開発入門
❏フレームワーク4本勝負
Laravel Symfony CakePHP FuelPHP
◆CakePHP
「設定より規約」
スピーディな開発のためには、各コードの量を減らすことが目的。
規約にはまらない場合は、設定を書く。
◆Symfony
長期運用に適している(詳細は後日アップのスライドに記載)
バージョン1の時点でデバッグツールが豊富
Symfony1と2は全くの別物
シングルトンでの取得などが変わっている
sfContext::getInstanceが$container->get()など
◆Laravel
Braddesテンプレートという機能でテンプレートを簡潔に
Eloquentによってコードを短く
AristanによってDBマイグレーションを簡単に
Tinker CLIでモジュールを試すことができる
◆FuelPHP
CodeIgniterというフレームワークから派生した
フレームワーク。PHP5.3以上対応。
Routingをサポート(routing.php)
SQL文内にを書く必要がなくて、
:nameと書いてあとでバインドが可能
FuelPHPの特徴はsimple,flexible,community.
「規約より設定」で学習コストを下げる
リクエストごとにアプリケーションを分割して
テストの範囲を限定できる
ex.http://hoge.com/blog はBlogモジュールしかアクセスできない
Fuel2系の開発が進行中
Play Framework からNeo4j(AnormCypher)へアクセスする際の設定
環境
- play 2.2.2
- Scala 2.10.3
build.sbt
name := "Project Name" version := "1.0-SNAPSHOT" resolvers ++= Seq( "anormcypher" at "http://repo.anormcypher.org/", "Typesafe Releases" at "http://repo.typesafe.com/typesafe/releases/" ) libraryDependencies ++= Seq( jdbc, anorm, cache, "postgresql" % "postgresql" % "9.1-901.jdbc4", "org.anormcypher" %% "anormcypher" % "0.4.4" ) play.Project.playScalaSettings
Scala で論理式っぽいことやってみた
論理式をscala&utf8で書くならどうするかなーって感じで表示だけするコードを書いてみた。
ソースコード(Formula.scala)
class Formula(name:String=""){
override def toString():String=name
def ∧(f2:Formula):Formula=Formula(s"($this ∧ $f2)")
def ∨(f2:Formula):Formula=Formula(s"($this ∨ $f2)")
def →(f2:Formula):Formula=Formula(s"($this → $f2)")
}
object Formula{
def apply(name:String)=new Formula(name)
def main(args: Array[String]){
val f = ¬(Bool("p")) ∧ Bool("q") ∨ True //中置記法で記述
println(f.toString)
}
}
case class ¬(f1:Formula) extends Formula{
override def toString=s"(¬$f1)"
}
object False extends Formula{
override def toString ="False"
}
object True extends Formula{
override def toString ="True"
}
case class Bool(name:String) extends Formula{
override def toString = name
}実行結果
$ scalac Formula.scala $ scala Formula (((¬p) ∧ q) ∨ True)
否定"¬"をscalaで書くのは面倒だね。
unary_¬みていな書き方できると楽なんだけど。
参考：ソフトウェア科学特論: Scalaと命題論理
