tousleshommes.hatenablog.comへ移行します。03:46ブログ移行Tweetもっと読むコメントを書く2017-06-06groongaを使う昨日はいきなりマルチスレッドとかいい始めてしまいましたがやっぱちゃんと書かないとだめだなと気持ちを改めました...インストールhttp://groonga.org/ja/docs/install.htmlこちらを参照。binaryプロトコルから使用するAPIからGQTPを介して使うデフォルトではGQTPが使われるらしい。このGQTPはマルチスレッド対応しており(HTTPとかもしてるけど)、特に指定しなくてもマルチスレッドで使用できる。サーバーを特に起動させずスタンドアロンで使用する場合もマルチスレッドで動くので、DBをopenしたらスタンドアロンサーバーが立ち上がってるんじゃないかな?よくわかんないけど。/tmp/test.dbなどとする。-dオプションはデーモン化するやつ。DBを作成するDBはファイルベースになっている。/tmp/test.dbデフォルトだと/var/lib/groonga/db/に作られる...のかな?サーバー立ち上げると特に指定しない場合はそこにできるみたい。Cのソースコードから作る場合は下記の通り。}テーブルを作成する色々とオプションはあるのだが多分簡単に使うだけなら、もととなるテーブルと全文検索用インデックステーブルさえ作っておけば良さそう。全文検索用インデックスはカラムに対して紐付けを行うので、テーブルを作成する時はnormalizer_typeとtoken_bigramだけをしていしておけばよい。"TokenBigram"おまじないみたいなもんだとおもっとけ。キーのタイプだけは指定しないといけないのとインデックス作ろうと思うとHASH_KEYタイプにしなきゃいけないみたいだが、インデックスいらないならキーのないタイプもあるのでそのあたりはよく読もう。オープン・クローズするソースコードにテーブル作るのを足してみる。//grn_ctx_getで存在しない名前を指定した場合はNULLがかえる。//unlinkでメモリから解放しておかないとメモリーリークが発生する。}この時点ではテーブルには_idと_keyがある(かくれて_scoreとかもあるが)。インデックステーブルとテーブルの関係性はできていないので次はカラムをつくるなお、grn_table_createというAPIもあるのでこっちを使っても良い。tokenをどうやって指定するのかよくわからないカラムをつくる基本的にはスカラー型でつくるのだが、インデックスの場合だけは指定する型が違う。あと関連をもたせたりとかもしないといけない。"UInt32"インデックステーブルにカラムを追加するmain_tableのnameは文字列なので全部検索のためにインデックスを作成してる。"name"注意するのはtypeに指定するのがもととなるテーブル名、sourceにインデックスを作成したいカラム名を指定することくらいかな。これでmain_tableにデータを追加あすると自動的にindex_nameテーブルも更新されるようになるCで書くとこんな具合。}こっちもgrn_column_createというAPIがある。sourceの指定はどうやってするのかよくわからない。10:25groongaを使うTweetもっと読むコメントを書く2017-06-05マルチスレッドでgroongaを使ういきなりgroongaってなんぞやって感じですが、ElasticSearchみたいなもんです。ライブラリがCなのでCから高速に使いたいときはこっちを使うと楽です。日本人が開発してるので日本語完全対応もうれしい。groonga-server-gqtpでできますが、詳しくはマニュアルを参照のこと。ライブラリを作りたいstaticライブラリを作りたい時もありますよね?ありますよね?(白目groongaはcmakeで楽ちんに作れますが、--help-property-listで出力してもstaticライブラリを作れそうなプロパティが出てきません。configureしてもいいけどどうしてもcmakeでやりたい。GRNG_EMBED=onとしてビルドすればできます。ソースコードをダウンロードします。-DGRNG_EMBED=onlibの下にlibgroonga.aができます。zlib1gをインストールしないとだめみたい。C-APIの基本的な使い方C-APIは色々あるんだが、コマンドラインから使うのと同じ感じで使えるのが楽だと思う。いうかまだよくわかっとらん。使い方はこちらが詳しいですqiita.comマルチスレッドで使うよーやく本題。groongaはマルチスレッド対応で特になにか設定をする必要はないようなことを書いてあるが、よーく読むとgrn_ctxは各スレッドに対して一つ与えてやらないといけないらしい。ためしにinsert/deleteをマルチスレッドでやるサンプルを書いてみます。//DBが存在しない場合は作成する。grn_dbをそれぞれのスレッドに対して作ること。15:49マルチスレッドでgroongaを使うTweetもっと読むコメントを書く2016-07-06複数のクライアントからThriftサーバに接続する方法(C++)あんま書いてなかったので。//複数接続する用のプロトコルを使う。0;}マルチスレッドじゃないんで先に撮った方のプロセスの処理が終わるまで待ちが発生するけど、同じポートに二つのクライアントプロセスから接続して処理させるのはできました。docoptPythonとかの情報はあるのだがC++はあんまりないので書いとく。Docoptはgetoptやprogram_optionsのようなCLIから実行するときのコマンドやオプションを解析してくれるパーサなのだが、とにかく使い方がエレガントだ。注意点はGCC4.8だとなんかいろいろ大変ってことだろうか。GCC4.8を使っている場合については後述。基本かきかたはgithubにも書いてあるし、ここにもあるが、違うサンプルでかいてみる。UsageとOptionsを指定するだけであとはよろしくやってくれる//exampleではなぜかcharを使っているが実装はstd::stringだった。//mapのキーはOptionsで指定したオプション名。値を取らないオプションの場合、docopt::valueはboolになる。0;}Usageを書けばそれにそってパースしてくれるというのがスマートでよい。コンパイルする場合はlibdocopt.aをリンクしよう。-ldocoptlibstdc++のリンクをしないといけない。GeekWentFreakここにかいてあるとおりやればよい。Libraryを作ってくださいこれでできたlibdocopt.aを使わないとregex関係のリンクが上手くできないちなみにgcc4.9以上が入っててもCMake3.2未満だとコンパイルできないのでとりあえずcmake3.2は入れる。installそんでおもむろにライブラリを作る。make一度つかえるようになればかなり相当楽になる。Parser、Docopt.cppを使ってみたTweetもっと読むコメントを書く2015-09-08文化がアジャイルを壊すTwitterでもブツブツ言っていたが、最近アジャイルのトレーニングを受けた。参加してたメンバーは主にEU圏内とポーランド・ロシアあたりの人々で講師はアメリカ人。参加者はプロダクトマネージャからジュニアプログラマまで全員みたいな感じ。CTOもいましたね...欧州と米では開発文化はかなり違っていて、一口に言ってしまえば欧州はプロセスがプロセスとして成り立たないレベルで自由なことが多いようだ。プロセス自体に興味がないかんじ。納期とかもゆるゆるでアメリカ以上にリリース日が遅れまくる。会社の人達は基本的なスキルは高いけど属人性を好むところがあり、いつまでたっても自分の手からタスクを離さない。情報の共有文化があまりない。コミュニケーションは基本口頭で、Skypeとかは使うけどあんまり好きじゃないようだ(これはいろんな国から来ているということもあるが、欧州人は基本的にあまり文字のコミュニケーションが好きじゃない。母国語が英語でない場合が多いせいだと思う)。トレーニングではScrumとKanbanがメインだった。ウォータフォールからなかなか抜け出せない古い開発プロセスで開発を回している日本の会社ならScrumはわりと馴染みが良いかなと僕は思っているが、ごりごりにピュアScrumをやろうとすると失敗するだろうと思ってた。基本的にScrumってスプリントの部分ばかりフォーカスされて、その前のとこは?っていったら「完璧な仕様があります」「完璧な要求があります」みたいな感じで紹介されるじゃないですか。あれって非現実的だよね、みたいな。ちなみにこのトレーニングではそこら辺が曖昧な状態での開発方法を扱っており、結局スプリント開始前のフェーズではみんなで膝を突き合わせて大きめのバックログを作るところにフォーカスをおいていたので、アメリカではすでに死屍累々を乗り越えて今に至るのだろうと思われる。バックログの作り方は基本的に昔の要求分析と同じかなぁと思うが、ひとまずミッションステートメントを作って最終的なゴールと優先順位をおおまかに明確化して、そこから必要なバックログ(いわゆる要求ですね)を出していくので、新規開発ではここをしっかりやっていればあまりブレることはなさそう。要求を作っていく作業ってのは誰でもできるわけではなく、こういう時にSysMLとかは役に立つのだが、欧米ではそういうツールがあんまりはやってないのでそのへんの説明はなし。後で書くけどツールを使わない彼らのやり方は今後やっぱり問題になっていくだろうなと僕は思っている。バックログができたらあとは日本でよく紹介されているScrumのやり方ですね。基本的に残業をしない欧州ではデイリーミーティングをやれば工数と期日がだいたい予測できるが、残業の多いアメリカと日本じゃどうなんだろうなと僕は思ったりする。そんで面白かったのがもう一個のカンバン。変な日本語の読み方がいっぱい出てくる(カンバンもケインバンとか呼んでる)からいちいち笑うのだが、要するに優先順位をつけて上からタスクを流れ作業で処理していきましょうという工場の業務フローをソフトウェア開発に持ち込んだものだ。利点は期日どおりにリリースできること(もし終わっていないタスクがある場合も気にせずリリースする)。講師がこれはすごいって賞賛していたのだが、みなさんどう思いますかね。僕は全然すごくないと思います。当たり前すぎるじゃんみたいな。そもそもこれはフローであってプロセスじゃないから、Scrumの問題点を解決してくれるすごい開発プロセスには成り得ない。そもそもすでに優先順位が定まっているタスクが存在していることが前提であって、そうじゃなかったらグダグダになりまくりだろうという。その辺はScrumのスプリントに入る前の作業できちんと議論したうえでスプリント中にKanbanを使用するということらしいのだが、それでもねぇ...っていう。そもそもタスクを分解して流れ作業にするより、ある意味のある単位での要求を一人または数人で最初から最後まで仕上げるほうが生産性も品質も高まるってのが最近の日本のはやり(?)じゃないですか。なに逆行してんだっていう。このトレーニングを一番後ろから見てたんだけど、Kanbanに対する食付きがすごいのね。グループワークがあったのでその様子を見る限りも、なんかKanbanは新しい何か、みたいな受け止められ方をされている。考えると、欧米の人たちって、というか特に欧のひとたちっていうのは「プロセスを守る」という部分が非常におろそかなので、逆にKanbanみたいな思想を導入したほうが失敗が少ないのかもしれないなと思ったりした。ありとあらゆるものをおろそかにするが、その代わり要求されているものをできるだけ最善な形で出そうとする努力は惜しまない。品質に関しては元がいい加減なのでそれなりなのだが(テスト仕様とかひどいもんだ)、それでも彼らなりに最善をつくすべきだとは思ってるみたい。「要求を満たすこと>品質>その他>>>>>>期日」で、要求を満たすための議論は非常に活発に行われる。上下関係は一応あるけれども、上下関係があるから言えないというのもないし(中傷はしませんけどね)、関係性がフラットなのも日本とは違う。いくつか問題があるとすれば、基本的にみんなスキルが高いという前提で話が進むので(なのでプロセスが不要)、抽象的な話のまま議論が終わったりすることと、エビデンスを残す習慣がない。議事録は残さないし、ドキュメントは嫌いだし、あとこれは欧州限定なのだがアメリカ人よりものいいが抽象的なので、欧州系の文化で育っていないと彼らがなにに満足して、なにで合意に至ったのかよくわからないことがある。それゆえにその後ちょっと具体的な話になった時に意見の相違が出てくることがあるのだ。これでXMLでもなんでもいいんだけどツールを使って限りなく具体化するということをやっていればよいのだが、議論しちゃえば早いでしょという感じでつかわない。いつの間にか仕様が変わっている。基本的なスキルが高ければそれでいいのだが、要求をきちんと実装に落とせないタイプがいたり、ジュニアデベロッパーのほうが多かったりすると問題が続出する結果となる。テストも穴だらけなので品質は微妙なものが出てくる。これが欧州のやり方だ。アメリカはもうちょっとプロセスがしっかりしてるんじゃないかなと思うのだが(飽きもせず開発プロセスを発明してるし)、議論が当たり前のように行われるフラットなチームではこういうことが起こりやすいのかもしれない。逆に日本だと絶対にいる「プロセス通りじゃない!」って怒るタイプの人がプロセス通りに物事をすすめることに貢献するし、テストがクソ緻密すぎてコストがかさみまくったりするが、一応あんまりにも予想できないものが出てくることはないような感じがする。開発中に明らかにダメなものを指摘できずにクソ化していく経過を見ることはできるし、出てくるものが妙にしょぼかったりもするのだが、一応は出した要求通りのものが出てくるのが日本だ。期日通りかどうかは微妙なところだが、そもそもスケジュールがタイトすぎる開発現場のほうが多いと思うのでその辺は気にしなくていい気がする。いうか日本のスケジュール感で見積もったものを欧州でやらせようとすると多分三倍くらい時間がかかるな。出てくるものはちょっと豪華になるかもしれないが、どうしようもないクソになってしまっている可能性もあるので注意が必要だ。小さな開発チームでビジョンを共有していれば逆に素晴らしい物が出てくる可能性もあるが、ちょっとチームが大きくなるととたんに欧州は仕事が回らなくなる。ぼくは思うのだが、結局ダメなプロジェクトはどんなプロセスを使っても駄目だし、文化に合わないプロセスはどんなに安全なプロジェクトでもダメにする。その国や文化圏に応じて気をつけるべきことは違っている。欧州に足りないのは決まったことを守るという視点、日本に足りないのはダメなものをダメだと指摘して、建設的な議論をするチームの文化。逆にいえばそれさえあれば、たとえウォータフォールでも、というかプロセスさえなくたってものづくりはうまくいくんじゃないだろうか。20:45文化がアジャイルを壊すTweetもっと読むコメントを書く2015-02-28いまさらか!なんだけどWindowsバッチのはなしprogrammingそれでもやっぱり時々は書かなきゃいけないWindowsバッチ。複雑なことはやらせるなという話なのかもしれないが、他のスクリプト実行環境をどうしても入れられない場合などは書くほかないのである。あとちょいちょいかいてあるとおりにならないんだけどこれはなんでなのかな?文字列を切り刻むなん文字目から切ればいいということがわかっている場合はかんたんなのだが、そうでない場合はfor文まわしてdelimsでスプリットしていかねばならないらしい。for文の中のステートメントは先に展開されてしまうので、取得した文字列をこの配列に代入して...というのは案外難しいらしい。data[n]とやりたい場合の書き方がよくわからなかったりするのである...素直にグローバルスコープの変数に入れて使いまわしたほうが良いのかもしれない(モダンなプログラムをかいている人には気持ち悪いと思うが)ちなみにdelimsはデリミターのことだが、マニュアルには複数指定可、デフォルトはタブとスペースがきくとかいてある。スペースとカンマで分けたい場合はどうするの?という場合は結構探したけど書いてなかった。ほにゃららスペース以外でも分割したい場合、スペースはパラメータの区切りとして認識されるので、そうされないために最後にdelimsを指定すること。%%jこのブロック名の後ろにいる人が引数。使うときは番号で呼ぶ。value=%2ブロックというかメソッドと思えば良いらしいブロックを出てからの挙動ふつうの文が最後の場合はいいのだが、for文の場合は一旦forの終端に戻り、そのままシーケンシャルに実行されるので、ブロックの最後に次に行きたいブロックの場所を指定しておかねばならない。%%jとした場合、最初にメインループ→nextLoop→もとのループにもどる→もう一回nextLoopとなるようだ。呼び出し元に戻ってもらいたいものだがそういえばプログラムとはそういうものだった。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。