上記の方法でインストールしたとすると
vim /usr/local/bin/jmeter/bin/jmeter
HEAP="-Xms512m -Xmx512m" ↓ HEAP="-Xms10240m -Xmx10240m"
でHEAPサイズを変更できます
修正しているファイルは実行シェルなので、インストールしたパスが違う場合でも実行シェルを編集してしまえばOKです
また、Xmx > Xms を満たしていれば Xmx と Xms を同値にする必要がありません
HEAP="-Xms512m -Xmx512m" ↓ HEAP="-Xms10240m -Xmx10240m"
# -*- coding: utf-8 -*- # sample.rb require 'gviz' gv = Gviz.new gv.graph do # グラフ全体のレイアウトを定義 global layout:'dot', overlap:false # 共通のサービスを宣言 cloud_storage_services = [:Dropbox, :GoogleDrive, :Evernote, :Github, :codeBreak] local_storage = [:disk200a, :disk200b] net_services = [:Twitter, :Facebook, :Blogger, :Cacoo] # 起点となるノードからのつながりをここで定義 ## ここですべてを定義しなくても後からedge等を使ってつながりを作成することは可能 route :yoshi0 => [:Internet] route :yoshi1 => [:yoshi0] + cloud_storage_services + net_services + local_storage route :yoshi2 => [] + cloud_storage_services + net_services route :yoshi3 => [] + cloud_storage_services # すべてのノードに対するルールを定義 nodes color:'black', fillcolor:'white', style:'filled' # 特定のノードに対するルールを定義 cloud_storage_services.each {|k| node k, fillcolor:'green' } node :yoshi0, fillcolor:'gray99', label:'yoshi0\n(gateway)' node :yoshi2, label:'yoshi2\n(Jenkins)' node :fndb, fillcolor:'orange' net_services.each {|k| node k, fillcolor:'lavender' } node :Internet, fillcolor:'lavender' # 特定のエッジに対するルールを定義 ## routeで定義したつながりを「_」で区切ることでエッジを特定して設定できる edge :yoshi1_yoshi0, color:'lightslateblue', label:'wi-fi' edge :yoshi1_yoshi2, style:'dotted', label:'rdp' edge :yoshi1_yoshi3, style:'dotted', label:'ssh' edge :yoshi2_yoshi3, style:'dotted', label:'ssh' edge :yoshi2_Github, style:'dotted', label:'git clone' edge :yoshi2_codeBreak, style:'dotted', label:'git clone' edge :yoshi2_fndb, style:'dotted', label:'xmlrpc' edge :fndb_Twitter, style:'dotted', label:'api-tweet' edge :fndb_Facebook, style:'dotted', label:'api-post' # ノードをグループにまとめる subgraph do global label:'cloud' node :yoshi2 node :yoshi3 end subgraph do global label:'home_net' node :yoshi0 node :yoshi1 end end gv.save :my_system, :png
@charset "utf-8"; #main-table { background-image: url(jenkins_logo.png) !important; } #top-panel { background-image: url(topbar.png) !important; }
@charset "utf-8"; #header { background-image: url(topbar.png) !important; }
1年弱くらいチケット駆動開発をして来て感じたことがあったので今更ながらメリット・デメリットの観点でまとめてみました
作業をタスクに分割しBTS(Bug Tracking System/バグ管理システム)のチケットに割り当てて管理を行う開発スタイル
Wikipediaより一部を抜粋
要するに「やること」や「やりたい」ことをチケットという単位で管理し開発を進める手法
Githubのissueみたいな感じ、Closeされれば終了
また今回、私はBTSにRedmineを使いましたのでRedmineでの話を中心に記載したいと思います
特殊な使い方をしていたつもりはないので至って普通かと思いますがコンテキストをまとめておいたほうがいいと思うので簡単に記載します
基本的には上記の機能を使うことが多かったです
上記を踏まえて運用した上でのメリット・デメリットを考えてみました
進捗を把握しやすい
全てはチケット管理なのでシンプルかつ明確にタスク管理することができると思います
進捗率や期日も設定できるのでガントチャート的な見え方もできてGood
優先度を駆使すれば今やるべきことがすぐわかる
子チケットを駆使すればタスクのカテゴライズができて把握しやすい
マネージメントが簡単
日本の会社のようにヒエラルキー型の会社にはがっつりハマると思います
上の人がチケット切って「はい、これやって、これやって」とホイホイ下の人に割り当てればいいだけなのでマネージメントはめちゃくちゃ簡単
アサインしている人ごとにチケットも見れるのでリソースの空き状況もすぐに把握できる
チケットさえちゃんと作成できていればという点はあるが
ルールが勝手に出来上がる(出来上がった)
これはいい事象かなと思ってます
例えば、文書管理のフォルダ名とかwikiのタイトルとかは全くルールがない状態で初めたんですが、初めに誰かが作成した命名規則的なものを次の人がそれに沿って「いい感じ」に作ってくれるようになりました
例えば、wikiページは必ずYYYYMMDD_
で始まるように記載していたら、他の人もそれに合わせて書いてくれるようになったりとか、文書管理のフォルダ名もはじめに00_hogehoge
とか数字をつけるようにしていたら次のフォルダ名が01_barbar
とかになって自然にルールができていたのはいいなと感じました
通知機能
チケットを更新するとメール通知できるので他の人の作業内容が把握しやすいです
自分はgrowlと組み合わせて担当者が自分にアサインされるとgrowlで通知してくれる機能を作ってチケットの見落としを防いでいました
低学習コスト
かなり個人的な間隔もありますが、そこまで勉強しなくても使えると思います
ツールにもよりけりですが、Redmineに関しては低いと思います
ただ、機能は本当にたくさんあるので使い込もうとするとそれなりのコストがかかると思っていただければと思います
クローズされない亡霊のようなゾンビチケットができあがってしまう
「よし、絶対やるぞ!」とその場の勢いで作成したチケットが半年後に誰にもアサインされずに残り続けてしまう
残り続けてしまうこと自体は「やるべきこと」なのでいいのですが、誰にもアサインされず「いや、これ誰がやるんだよ・・・」的な感じでみんなから無視され続けてクローズもされず、ほっとかれる現象が発生してしまう
こうなってしまうと一生消化されることがなく「やっほうがいいのかな・・・でも他に優先度高いことあるし・・・今更そんなのやってるなよとか言われそうだし・・・」とか、精神衛生上もよくない、疑心暗鬼、そわそわしちゃう
なのでそんなチケットが出来ちゃわないために「6ヶ月以上更新のないチケットはクローズして別チケットを発行して誰かにアサインする」とか「アサインを外して対応保留カテゴリに割り当てる」などルールを作ることが必要かなと感じた
ルールでどうにもならないときには「カンバン機能」や「API」もあるので可視化、自動化でシステムに解決してもらうのがいいと思います
チケットの粒度
なんでもかんでもチケットが切れる状況だったので、開発者それぞれでチケットの粒度が統一されていないのが微妙でした
これも「ルール」の問題なので事前に粒度のルールを決めておけばいい話なのですが、そもそも粒度をルール化するのは難しいという問題点もあります
やるとしたら粒度のルールというよりかはチケットを発行できる人を制限する感じかと思いますが、それもそれで開発者の自由を縛るようなルールなのでやるのは微妙かと思います
私の場合はだんだん各人が粒度を「暗黙的に」理解したので徐々によくなりましたが、最初のほうは1つのチケットにいろんな作業記録をコミットメントしまくってカオスな状況でした
検索機能が弱い
デフォルト提供されている検索がそこまで賢くないのが残念でした
せっかくチケットやwikiに貯めたノウハウもうまく取り出せないんじゃ意味がありません
検索が微妙だった分カテゴリやトラッカーを適切に付与してカバーしてましたが、さすがに規模が大きくなると検索なしでは厳しかったです
また、文書管理にあるファイル名と説明までは検索対象にできるのですが、ファイルの中までは検索対象にならないので、なるべく文書管理にノウハウを貯めるようなことは避けるようにしました
よくある設計書にオフィス製品を使っちゃう問題もありましたが、極力ドキュメント類はコードに落とすか、wikiに記載するようにしました
GoodかBadかで言うとGood
100点満点な開発方法ではないと思いますが、10点とか20点でもないです
man powerで解決しなければいけない面(ルールとか縛りとか)もありますが、システム的に解決できる部分もあるので、なんとかなります
全然、開発手法が決まっていなくてどうしたらいいかわからんときには、とりあえずチケット駆動にしておけばなんとかなると思います
チケットエンジニア
簡単に言うとチケットの進捗とか状況とかを管理する人
ゾンビチケットやアサインされていない人を見つけたときに適切にアサインしたりする人
マネージャではないので進捗管理とかタスク割り当てをするわけではなく、チケット駆動が回るために適切に振る舞う人
的な人がいると更によくなるとは思うが、そこまでしてやるかというのと
そもそも、そこにリソースを割り当てる人がいないという問題があるので正直やる価値はないと思うが、なんとなく思ったので記載
ツールは
今回はRedmineを例に話を進めましたが、それ以外にもめちゃくちゃあります
参考 -> バグ管理システム
「決定版はどれだ」という議論をするときっとキリがないのでここではしませんが、正直どれでもいいと思います
あえて進めるならオープンソースでまだ開発が続いているツールにするのがいいと思いますあとは、拡張機能が作れるとか
文字ばかりですが、以上です
これからもチケット駆動を続けるのでまた何かあれば別ポストでもして、今回と見比べて解決してる点とかしてない点とか比較すると面白いかなと思いました
require 'colorize' ... puts "Start server-spec ".colorize(:color => :red, :background => :blue) + `hostname`.colorize(:color => :red, :background => :blue) ... puts
pre { white-space: pre-wrap; /* css-3 */ white-space: -moz-pre-wrap; /* Mozilla, since 1999 */ white-space: -pre-wrap; /* Opera 4-6 */ white-space: -o-pre-wrap; /* Opera 7 */ word-wrap: break-word; /* Internet Explorer 5.5+ */ margin: 0; background-color:black; color:white; } .CodeMirror pre { color:black !important; }
{ "require" : { "parse/php-sdk" : "1.0.*" } }composer install
<?php require 'vendor/autoload.php'; date_default_timezone_set('Asia/Tokyo'); use Parse\ParseClient; use Parse\ParseObject; ParseClient::initialize('Application ID', 'REST API Key', 'Master Key'); $testObject = ParseObject::create("TestObject"); $testObject->set("foo", "bar"); $testObject->save();
percol.view.PROMPT = ur"%q" # Emacs like percol.import_keymap({ "C-h" : lambda percol: percol.command.delete_backward_char(), "C-d" : lambda percol: percol.command.delete_forward_char(), "C-k" : lambda percol: percol.command.kill_end_of_line(), "C-y" : lambda percol: percol.command.yank(), "C-t" : lambda percol: percol.command.transpose_chars(), "C-a" : lambda percol: percol.command.beginning_of_line(), "C-e" : lambda percol: percol.command.end_of_line(), "C-b" : lambda percol: percol.command.backward_char(), "C-f" : lambda percol: percol.command.forward_char(), "M-f" : lambda percol: percol.command.forward_word(), "M-b" : lambda percol: percol.command.backward_word(), "M-d" : lambda percol: percol.command.delete_forward_word(), "M-h" : lambda percol: percol.command.delete_backward_word(), "C-n" : lambda percol: percol.command.select_next(), "C-p" : lambda percol: percol.command.select_previous(), "C-v" : lambda percol: percol.command.select_next_page(), "M-v" : lambda percol: percol.command.select_previous_page(), "M-<" : lambda percol: percol.command.select_top(), "M->" : lambda percol: percol.command.select_bottom(), "C-m" : lambda percol: percol.finish(), "C-j" : lambda percol: percol.finish(), "C-g" : lambda percol: percol.cancel(), }) Let's percol >
M-x load-library RET package.elでパスが表示されると使われていることになります
/usr/share/emacs/24.3/lisp/emacs-lisp/package.elc
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
if [[ "$OSTYPE" =~ "cygwin" ]];then # Chocolatey alias choco='cmd /c choco' alias cinst='cmd /c cinst' alias cup='cmd /c cup' alias cuninst='cmd /c cuninst' fi