サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
セキュリティ
blog.nekokak.org
自分は最近流行りのCTOでも技術系執行役員でも無く、中間管理職ど真ん中なミドルネージメントなわけですが、2年ほどやってきた事をつれづれなるままに書いてみようと思う。 技術的スキルってtry&errorが簡単なのですがマネージメント、特にヒューマンマネージメントはtry&errorが簡単では無いです。 なんせ自分のヒトコトでその人の人生が左右されることがあるから。なので自分は少しでも精度を高める為にメンバーと話す事を第一としています。 今まで50人以上のメンバーをマネージメントしてきて改めて思うのは一人として同じ人は居ないこと。その、一人ひとり特色も考え方もスキルも違う人たちをマネージメントするには圧倒的なコミュニケーション量が必要だと思います。 私の場合は業務時間の多くをメンバーと個別に話す時間にあてています。 1on1と呼ばれる手法ですね。 1on1でのコミュニケーションの取り方は 1)
Archive 駄文:ABテストがモノづくりを破壊する あーなんか書こうかなーと思っても時間もなくて、ぶっちゃけあんまりモチベーションわかなくて、ずっと書いていなかったんだけど何となく思うことをつらつら書き溜めていこうかなと思う。年末だし。 なんとなしに頭にあるのを吐き出すテイなのであんまり読みやすさとか考えない。あと極論書いてる。(という予防線を貼るあたり若干ひよってる) 今回はABテストについて思うことを書いてみるかなと。 ABテストって簡単に言うと2つ以上ある選択肢のうち一番良い結果を出すことのできるものを見つける事ですね。 言葉だけ見るとなんかよさ気にみえてしまうけどモノづくりする上での弊害がかなり大きいと考えています。 一つ目 ABテストやっちゃうと正直工数が余計にかかる。結構掛かる。最近だと低コストでABテストを実現するためのツールとかもあるんだけど適用したいケースによっては設
背景としては、私自身がTengのメンテナスに時間を割くことができず、利用者からの要望に答えることが難しくなってしまった為です。 せっかくpull-requestを送ってもらっても気づくこともできず長期間放置してしまったり、 仕様に関する議論もしっかりできず、これでは死んだプロジェクトとなってしまうと思いました。 後任としては現在Tengを実際に利用しており、意欲的にpull-requestを送ってくれているcho45さんにお願いすることとなりました。 cho45さんであれば安心して後をお任せできると確信しております。 cho45体制のTengをこれからも応援よろしくお願い致します。 :D
WEB+DBのRedis特集をひろせまさあきさんと共同で執筆しました。 WEB+DB PRESS Vol.73posted with amazlet at 13.03.05設樂 洋爾 白土 慧 奥野 幹也 佐藤 鉄平 後藤 秀宣 mala 中島 聡 堤 智代 森田 創 A-Listers はまちや2 大和田 純 松田 明 後藤 大輔 ひろせ まさあき 小林 篤 近藤 宇智朗 まかまか般若波羅蜜 Mr. O 技術評論社 売り上げランキング: 335 Amazon.co.jpで詳細を見る 買ってください。 このRedis特集の第五章では、Redisを使ったリアルタイムランキングについて取り上げたのですが、 記事中にある同点問題について、執筆時から状況が変わりましたのでupdateします。 記事中では、RedisのSortedSetsはスキップリストというアルゴリズムを使っている特性上、 同じス
2WaySQLというものがあるわけです。 2WaySQLについてはhttp://www.slideshare.net/t_wada/tokyo-rubykaigi-01-twada-presentation を参考にしてもらうとして、 超絶簡単に説明すると、実行可能なSQLを書いておいて(where句の値もデフォルト値を書いておくので実行可能となる) プログラム側で良い感じにプレスホルダーとかに置き換えて値を良い感じに置き換えます。 どんなSQLかというと SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)こういう感じ。 普通に実行可能ですよね。 これを、 my $sql = q{SELECT * FROM USER WHERE id = /*:id*/1
今期からJPAの理事となりました。 よろしくお願いします。
と言う事で Fukuoka.PM #1 は JPA 講師派遣制度として発表してきました。 他の方のまとめ記事はこちら http://yokoninaritai.hatenablog.jp/entry/2012/04/03/012440 http://spring-mt.tumblr.com/post/20696127846/fukuoka-pm 前日入したとたん屋台に連れて行ってもらったり、深夜にラーメンに付き合っていただいたりと 堪能することが出来ました。 福岡名物のラーソーメンも食べれたし満足ですた! はやしさん++ 自分は最近ぽちぽち作ってるClutchの発表をしてみました。 資料を https://github.com/yoshiki/markdown2impress で作ってエフェクトを多めにかけたら 酔う酔うと言われて(´・ω・`)ショボーン 自分はいままでHokkaid
@shiba_yu36さんがQudoの発表をするというのがKyoto.pmに行く強いきっかけになったので、 一番まえの席に陣取って発表を見ていました。 @Yappoさんのように発表者が発表している最中にtwitterという公開の場でlive disをするのはためらわれたので、 今あらためて@shiba_yu36さんの発表内容を振り返りつつ突っ込んでみたいと思う。 disじゃないよ。 @shiba_yu36さんの発表資料 http://shibayu36.hatenablog.com/entry/2012/03/18/230525 拡張性について Job Queueを使う上でTheSchwartzではなくQudoを使った利用に、 「TheSchwartzはオーバースペック」 「たくさんカスタマイズ詩たいわけではない」 ⇩ 「Qudoがちょうどよさそう」 とあったのですが、Qudoは拡張性が高
第一回のKyoto.pmに帰省を兼ねて参加してきました。 自分の発表資料は以下 http://nekokak.org/presen/kyoto01/ ORMとはといったような概論的なはなしをしながら、 最後は一緒にTengを開発しませんか? といったかんじ。 プレゼン中でも触れていますが、今あまり(ほとんど)Tengの開発に注力できないので 新機能だったり、リファクタリングだったりが滞っています。 DBIx::SkinnyもTengも多くの人に使われるようになってきているので、 使っている人からの開発リソースの還元を受けたいなーとか 開発に関わりたいと思っているような人をうまく取り込みたいなーと考えています。 プレゼン後の懇親会で、Tengは必要最低限の機能にわざと絞ってるのに、 新機能開発ってどういうこと? という質問を受けたのですが、Tengは自分の理想を完璧に形にできているわけではな
ということで、2012/03/31にFukuoka.PMに行ってきます。 去年のYAPC::AsiaでFukuoka.PMの方々とお話する機会があり、 北のHokkaido.PMの次は南のFukuoka.PMだろ!ということで行きます。 http://atnd.org/events/25550 当日はJPA代表理事であるlestrratさんも参加され、 まだ若干余裕があるようですので、福岡だけでなく近県の方々でお時間ある方はどしどしご参加ください。 予定では前日の03/30に福岡入りして、04/01のお昼に帰ります。 支援2回目なので、なるべく安く済ませて他の人に回せるように注意する所存でございます。
Just Ideaなんですが、 Forkして子プロセスに処理を行わせる事はよくやることなんですが、 実際の全ての処理にある程度時間がかかる場合に、現在走っている処理を一時停止したり再開したりすることができるとおもろいかなぁとおもったので サクっと書いてみた。 #! perl use strict; use warnings; use Parallel::ForkManager; use Time::HiRes qw(sleep); my $pm = Parallel::ForkManager->new(10); my $pause=0; $SIG{HUP} = sub { $pause ^= 1 }; my $finish=0; $SIG{TERM} = sub { $finish = 1 }; sub pause { $pm->wait_all_children; while (1) {
最近Redisに興味があったんで 色々な使い方を検討してるんですが、その中でRedisをつかったJob Queueを思いついたので実装してみました。 ちなみにRedisをつかったJob Queueは既出で、githubなんかで使われている resqueというのがあります。 まぁ通常のJob Queueだったら正直別にRedisつかわなくていいのでちょっと違う感じで実装してみました。 # 個人的には普通のQueueだったらQ4MとかQudoとかTheSchwartzでいいとおもう。 # こんなところで無駄にRedisとか使うメリットないわ。 通常JobQueueだと1個ずつjobをとりだして(dequeue)処理を行うと思います。 ただ、ケースによってはある一定の個数のjobをまとめてdequeueして処理を行いたい時があります。 私は普段業務では、Q4Mを多用しているんですがQ4Mにはそう
投げっぱなしrequest まぁ、Gearmandで言うところのdispatch_backgroundである。 clientはworkerにリクエストを投げる、 workerはリクエストを受け付けた事だけをclientに通知し、client - workerの接続を終了する。 workerはその後clientからのリクエストを処理する。 こうすることでclientはworkerの処理結果は受け取れないが、即時に処理を終了させることができる。 usecaseとしては、ページングの際の先読みキャッシュを作ったりとか。 multi request 複数のworkerに対してまとめてリクエストを投げたいケースもある。 一つの方法としてはclientが対象となるworkerにまとめてリクエストを投げる方法。 各workerへの接続をそれぞれ持ち、selectかけつつぐるぐるループさせて、read
Clutchを作ってる上で、やり残しの部分だったり、懸念点だったりもろもろが頭の中に残っているので 現状の仕様等をまとめつつ書きだしてみる。 長くなりそうだからその1としている。 なぜGearmanではないのか ClutchはGearmanのように中間daemon(gearmand)を基本持たない。 Gearmanの場合はclientは実際に処理を行うworkerがどこにどれだけ居るかを知る必要はなく、 gearmandの居場所さえ知ればよい。 clientがgearmandにリクエストを投げれば、あとはgearmandが対象となるworkerにrequestを回す。 自分としてはこのgearmandという存在がうっとおしく思えた。 例えばちょっとしたツールでjob queueを使いたい場合、workerプロセス以外にもgearmandを起動する必要がある。 別にそれくらい起動しとけばいい
ちょっと落ち着いたので振り返りなどしてみようかとおもう。 1月 転職を決意し動き出す Teng作ってたみたい Jonkも触ってた 2月 退職の準備とおもいきや10日で1サイトつくるとかやってた SQL::Objectとかつくってた 3月 転職 地震 4月 HandlerSocketに興味を持ってたみたい CPANモジュールガイド献本もらったり tmux入門してすぐにscreen回帰した MySQueueとかネタでつくったみたいだ 5月 Yokohama.pmでHandlerSocketの発表とか 6月 Redisの検証をしてた Hokkaido.pmに参加する準備してた DBIx::Handlerを作ったりしてた 7月 Hokkaido.pmに参加。飯が美味かったなり 8月 Web+DBにJobQueueについて寄稿 9月 Test::Function後のTest::Attribute::
https://github.com/nekokak/p5-Clutch 公開してみた。 あんまり触る時間なくてこのまま腐るなら出してしまおうということでだしてみました。 まぁ何をやる人なのかをざっくり書くと、 gearmanみたいな中間管理職daemonを立てずに client - workerが直接通信してjob queueを投げる感じです。 gearmandみたいなのがいないので、基本的にworkerがどこにいるのかとかはclient側が管理する必要があるけど ちょっとしたツール作るときとかそんなに管理に困るわけでもないので。 前回のHokkaido.pmでの発表でだいたいやりたい内容とか書いてるのであわせてどうぞ http://nekokak.org/presen/hokkaido06/ (発表の時からは微妙に仕様はかわってるけど。) あとパフォーマンスとか今のところ追求していない
やぁ。可愛いアイコンでお馴染みの@nekokakだよ。 mysql-casualとか言ってるけどカジュアルな記事が@oinumeさんくらいしかないよね。 ドン引きだね'`,、('∀`) '`,、 ということでガクンと敷居を下げようって感じで超絶カジュアルな話をしてみようと思うんだ。 カジュアル運用していると、「あれなんかこのテーブルまじレコード数おおすぎね?」 とかあるあるですよね。 そこでカジュアルにcountして見るわけです。 InnoDBのテーブルになのにそれもmsaterに対して。 カジュアルですね。 mysql> select count(*) from accesslog; +----------+ | count(*) | +----------+ | 11676738 | +----------+ 1 row in set (1 min 36.99 sec)1分半くらいかか
ふと思ったのでメモっておく位の感じ。 仕事ではquick hackって重要だなぁと。 業務で本当に必要と思うような仕組みがあったとして、それをすぐに導入できるかは大人の事情とかがあり なかなか難しかったりするのが普通じゃないでしょうか? 必要な仕組みだから周りだったり上司だったりを説き伏せて正しい(?)手段で導入するのももちろん正道だとおもいますが、 それがなかなかムズカシイのも世の常かなぁと。 自分は必要だとおもっても、周りにその問題意識があるかどうかは別なので。 好き勝手やっていいよって会社であれば別なんでしょうけど、そういう会社って結構珍しいんじゃないかなぁ。 もちろん相談出来る相手がいて、色々と相談や議論をし、協力者を見つけるのもいいし、そういう相手がいるんであればやるべきだとは思います。 そうすれば自分が思っていなかったような問題点なんかが出てきて考えの幅が広がるかもしれない。
自腹で参加してきました。北海道の人から事前に、「コケるなよ*2」と言われ天気予報みたら普通に最高気温が氷点下だったのでかなりビビってたんですが、 お陰様でコケることもなく、寒さにもなんとか耐えることができました。 帯広はもっと寒いとか。 今回は最近自分が作ったClutchというdistributed job queueを開発に至る経緯/設計方法/仕組/簡単なデモで紹介させて頂きました。 コードはまだどこにも公開してないのですが、書きなぐったままなので、もうちっと整えたらだそうかなと思っています。 Job QueueだったりMessage Queueだったりを使ってる人自体あんまりいない風味だったので どこまで響いたかわからないのですが&サービスが大きくないから使うまでも無いんですという話もお聞きしましたが、 そういうアーキテクチャがあるんだとココロの片隅にでもあると今は必要無くても何かあっ
前の記事で、 clone使ったら接続きれてもて再接続できるよーといいましたが、 これは DBIを生で使う人が reconnectを実現するための機能ではありません reconnectするためだけにcloneつかうとかバカなことはやめましょう。 ORMを使わないケースで、処理中で接続が切れる可能性があり、自動で再接続をしたい場合はDBIx::Handlerを使いましょう。 DBIx::Handlerをつかわずに接続切れたらcloneとかいうコード書くと トランザクションに不整合が発生する可能性が生まれます。 なお、DBIx::Connectorではそのあたりの処理が中途半端でdatabase側から接続が切られた場合や ネットワーク的な問題で接続が切れた場合はよしなにやってくれないので やっぱりDBIx::Handlerをつかいましょう。 # DBIx::Connectorでは$dbh->FE
http://search.cpan.org/dist/DBI/DBI.pm#clone DBIにcloneメソッドがあることを@nihenさんがみつけました。 #いやーDBIのドキュメントは良く読むと便利メソッドが一杯ありますね TengとかSkinnyではconnect_infoを受け取るだけでなく、 $dbhを受け取って利用する仕組みも提供しているのですが、 そこで一番問題になっていたのはdbへの接続がブチギレた場合のreconnectの問題でした。 connect_infoがある場合は接続情報を自分で持っており、簡単に再接続できるんですが $dbhしかない場合はいままでできないとおもっていました。 DBI的にも接続時につかったpasswordを取るインタフェースがなかった。 なので$dbhを渡された場合は自動reconnectは行わずにエラーで死亡にするようになってたんですが、 D
Tengのv0.13をreleaseしました。 今回の変更ではinflateのbugfixが入っているのでupdateをおすすめします。@kentaro++ またDBD::SQLiteのバージョンによりtestが一部おかしくなるもののfix。@charsbar++ もういっこがsingleメソッドのチューニングになります。 singleメソッドが結構色々無駄が多かったので色々ショートカットしました。 挙動の変化はありません。
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
ほんとjust ideaですが DBIx::Handlerにquery methodを足して見ました。 my $handler = DBIx::Handler->new(@connect_info); my $sth = $handler->query('select * from query_test where name = :name', +{name => 'nekokak'}); m $row = $sth->fetchrow_hashref; # +{name => 'nekokak'}; bindで渡す引数の形に応じてnamed_placeholderしてくてたり、 prepare / executeまでやってsthをかえすだけなんですが。 また { package Mock::Result; sub new { my ($class, $handler, $sth) =
YAPC::Asia 2011関係者の皆様ほんとうにお疲れ様でした。 自分は本編の発表だけのつもりだったのですが、 急遽1日目のLTにも参加させて頂きました。 LTの内容では@kamipoさんをネタにしてしまっていますが、 @kamipoさんにはいつも色々とご意見いただいており本当に感謝しております。 @kamipo++ですね! LTについて 資料 LTではORMはheavyだぜへへへ的な話になっています。 実際今の自分の環境ではなかなかORMを使う余地はないなぁとおもっておりますし、 周り近所の人々もORMを使わない用にしている人がおおいんですが、 ORMがイキテくる場所ももちろんあると思ってます。 今回懇親会でTeng使ってますという声を頂いたり、 DBIx::Skinnyを便利に使わせていただいてますという声も多く頂いております。 開発者として、とても嬉しい限りです。 いつでもpat
http://blog.nekokak.org/show?guid=6JbK6Erh4BGSM4iYghOgLw こちらでかいたTest::Functionですが @kamipoさんからパッチもらったりして微調整した後renameしてreleaseしました。 リリース名はTest::Attribute::AutoLevelです。 use Test::More; use Test::Attribute::AutoLevel; sub test_fail : AutoLevel { fail 'oops'; } test_faile(); done_testing;などとします。 attribute嫌いな人もいますが、個人的には嫌いではないです。 ついでにTengとDBIx::Skinnyもリリースしました。
名前は適当なんだけどねっ local $Test::Builder::Level = $Test::Builder::Level + 1 するのに飽きたので Test::Level 書いた @xaicronとこの件についていつもイケテナイよなぁってはなしてたら @xaicron便利系を実際に実装してるのみてついカッとなって書いてみた。 https://github.com/nekokak/p5-test-function use strict; use warnings; use Test::More; use Test::Function; sub test_foo : test_foo { ok 0; } sub test_nest2 : test_nest2 { ok 0; } sub test_nest1 : test_nest1 { ok 0; test_nest2(); } t
WEB+DB PRESS Vol.64posted with amazlet at 11.08.23柏木 泰幸 松野 紘明 林 聖高 杉 義宏 飯塚 直 高橋 征義 徳永 拓之 Tehu(張 惺) 中島 聡 おにたま 技術評論社 売り上げランキング: 204 Amazon.co.jp で詳細を見る 連載が続いているPerlHackersHubに今回JobQueueの記事を寄稿しました。 自分が使用している、自分が作った、使ったことのある Q4M, TheSchwartz, Qudoをザックリ紹介したのと、JobQueueを利用する上で気をつける事などをまとめてみました。 原稿書いててTheSchwartzはなんどもtypoをして残念な子だなぁと思ったり、 Qudoをもっとチューニングしてqpsあげたいなぁともおもったり いやいやJonkをこの夏リリースするんだったと思いだしたり、 Q4Mは
次のページ
このページを最初にブックマークしてみませんか?
『blog.nekokak.org』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く