nDiki : フレームワーク

フレームワーク - framework

2007年4月3日 (火)

WiKickerJSON でのページ出力機能を追加

最近は DiKicker ばかりに手を入れていたが、久しぶりに WiKicker の改良も行っている。 しばらく前から実装を始めていた JSON 形式での出力機能が今日完成。

今までは WikiPage について

  • HTML 形式による出力
  • Wiki 文法で書かれている生テキスト形式による出力

という2つの出力形式を持っていたので、JSON が加わることで3つめとなる。

サーバ側で WikiPage の構文解析まではやる

クライアントサイドの JavaScript でページの内容に合わせて様々な処理をできるように、サーバ側で構文解析まではしてあげるというのが主な目的。

JavaScript でまたパーサを書いてメンテしていくのも大変なので、その部分はサーバでやってしまおうかと。 構文解析した結果の解析木を JSON 形式で返して、JavaScript 側であとはお好きにという形。

CPAN にある JSON モジュールを使用

サーバ側の Perl プログラムには、構文解析をして解析木を作れるようになっている。 この解析木から Visitor パターンで JSON 形式を生成していく。

依存モジュールを増やすことを避けるべく、最初は自前で JSON 形式に変換していこうと思ったのだがやっぱり面倒だった。 ということで CPAN にあるモジュールをチョイス。

JSON 関連では JSONJSON::Syck、JSON::PC などがあるが今回はインストールのしやすさを考えて pure Perl モジュールとして実装されている JSON を採用することにした。

Visitor クラスで解析木を無名ハッシュ/無名配列のツリーに変換して、JSON モジュールに流しこめば OK。

 use JSON;
 my $json = JSON->new(pretty => 1);
 my $js = $json->objToJson($tree);

WiKickerフレームワークにはフォーマット別に出力を切り換える機構があるので、これに JSON を追加して application/json で送るようにして完成。

ちなみに残念ながら JSON 1.07 は Perl 5.005_03 では make test が fail するので、NaneyOrgWiki では使えない。

スポンサード リンク
[ 4月3日全て ]

2010年10月16日 (土)

今日のさえずり: あの牛乳の量ヤバい。腹にヤバい。

2010年10月16日

naney:5085927553

[ 10月16日全て ]

2011年10月14日 (金)

YAPC::Asia Tokyo 2011 1日目

@941 → @obra → @miyagawa → @naoya_ito → @ockeghem → @fujiwara → @zigorou → @ikasam_a → @overlast → @lestrrat (LT)

今年は講堂に YAPC タイムラインを写すスクリーンが公式に用意されたため、発表者が Growl 起動してなくても Tweet をシェアできるようになった。自分の端末に目を落とさなくても良いのでいいね。機材や場所の制約があって難しいのだろうけど、他の会場にもあると嬉しいな。

トーク

Perl 5.16 and beyond: Jesse Vincent (@obra)

Perl 5 が互換性を大切にしていく。コアを小さくしていく。

成熟期に入っているので、膨大な資産が継続して使い続けられることはとても重要な要素。

Carton: CPAN dependencies manager: Tatsuhiko Miyagawa

CPAN モジュールインストール状態の記録と再構築を容易にする Carton の紹介。

6年前とかにこういうの欲しかった。 特にパッケージ製品とか作っていると、動作確認のとれた依存ライブラリ一式の保存と管理が大切。自前で tarball 保存(+ PPM パッケージ作成と PPM リポジトリの構築)をしていた日々が思い出される。

SmartPhone development guide with Node/CoffeeScript and HTML5 technologies, for Perl programmers: Naoya Ito

JavaScript のお話。

Webアプリでパスワード保護はどこまでやればいいか: 徳丸浩

まだまだソルト健在。レインボーテーブルは発想が賢い。

Perlで構築された中規模サイトのDC引っ越し記録: FUJIWARA Shunichiro

稼働中のサービスのサーバ移転に関する顛末。

Mobage オープンプラットフォームの事件簿: Toru Yamaguchi

MySQL なお話。

他言語から見たPerlのテスト: Masaki Nakagawa

テストフレームワーク・テスト用モジュールいろいろあるね。 浅く広く紹介。

Apporoで類似文字列検索: Toshinori Satou

前半は技術開発プロセスに関する雑感、後半は類似文字列検索 Apporo の紹介。

@overlast 氏とは懇親会で話をさせていただいて「うーん、やはり悪徳業者投稿コンテンツの検出はヒューリスティックにやっていくしかないのかな」という点で意見が一致。

LT

いろいろ。

懇親会

思ったより食えました。

前職で一緒に研究開発をしていた @k12u 氏と再会できて嬉しかった。かわらず元気そうで何より。

Perlっ!」って話は最初の2本で、後はその他の技術もろもろ。アリだけど個人的にはもっと Perl の話も聞きたーい。

[ 10月14日全て ]

2013年5月10日 (金)

【日記】reveal.js 使ってみたり SpinNet 解約受諾されたり

reveal.js

HTMLプレゼンテーション作るフレームワークの1つ。

https://github.com/hakimel/reveal.js/archive/master.zip をダウンロードして展開して index.html を書き換えれば基本 OK。お手軽でいい感じ。

SpinNet 解約受諾通知書到着

ご加入日1997年12月25日、アカウント停止日2013年05月25日って書いてあった。 16年5カ月か。当初はダイヤルアップ定額の中では比較的回線速度の評判も良かったんだよね。

AT&T Jens株式会社 -> JENS 株式会社 -> 日本テレコム株式会社に合併 -> ソフトバンクテレコム株式会社に社名変更ときて、ODN をやっている裏で今となっては細々と続いている感じなのかな、値下げもないしまあもう少し早く乗り換えてもよかった。

バイバイ。

[ 5月10日全て ]

2013年6月21日 (金)

今日のさえずり: ベンザブロックといえば和久井映見

2013年06月21日

naney:9099203701

[ 6月21日全て ]

2014年8月29日 (金)

YAPC::Asia Tokyo 2014 1日目

image:http://www.naney.org/nDiki/2014/08/29/ogp_icon_350px.png

昨日の前夜祭から一夜明けての YAPC::Asia Tokyo 2014 1日目。昨年に引き続き慶應義塾大学 日吉キャンパス開催なのでなんとなく勝手がわかってちょっと気楽。去年はなんか多目的教室に入りそびれたので、今回は早めに移動とかしてそちらも回ってみた。

電源の取れる藤原洋記念ホールがなんだかんだいって居心地が良かったりはするんだけれどね。

今日は Go 使ってみようかなと思ったのが収穫。会場でとりあえず golang Debian パッケージインストールして hello.go ぐらいはしてみた。goroutine 以外は思っていたより普通の言語……なのかな?

お昼は @syamata 氏と @bornite 氏と日吉天神でラーメン。去年と同じ店だった。と思ったら去年は同じ場所で「らーめん 元山亭」という店だった。日吉天神は去年10月7日オープンらしい。 @syamata 氏が最近 Facebook で Yelp のフィード流しているのでモチベーションとか聞いてみたら「アーリーアダプターとして、まだデータにないお店やレビューを登録していくのが楽しい」とのこと。あーわかる。

「インフラエンジニア(狭義)は死んだ」 Satoshi Suzuki @studio3104 氏 (多目的教室2)

インフラエンジニアのメンタル的な面に視点を当てたトーク。

  • 物理的なハードウェアにかかわる事は減ってきている。
  • そのかわりコードを書ける必要が高まっている。ただしコードを書けばバグも発生するのでコードを書かない選択肢も常に考える。
  • あとリーダブルコード的な話とか。

Go For Perl Mongers」 Daisuke Maki @lestrrat 氏 (多目的教室2)

Go にいりては Go に従え。

  • いわゆる例外処理無い。
  • いわゆるオブジェクト指向的でもない。
  • fmt は ふむと? / ふんと?。
  • ハードタブ。

Go 使ってみたくなった。

「お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました」 Tokuhiro Matsuno @tokuhirom 氏 (多目的教室2)

Perl のテストフレームワーク回りの話し。

  • 2 の開発中止あるある。

テストフレームワーク関連はできるだけ枯れて安定したものがいいなと思う(テストフレームワークの不具合とか仕様変更まで追いかけ続けなくていいように)。便利さとのトレードオフ。

Perl::Lint - Yet Another Perl Source Code Linter」Taiki Kawakami @moznion 氏 (多目的教室2)

わりに泥臭い世界なのではと思ったら、やはり泥臭い感じだった(実装的に)。

C スタイル for だって goto だって適材適所なので使った方が良い場面だってあるので、そういうのはきちんと説明できるといいんじゃないかと思う(lint がそこまで判別できたら凄いけど)。

「One layer down below.」 Kang-min Liu @gugod 氏 (藤原洋記念ホール)

フルフルの汎用モジュール使わないで、軽くて速い機能を削った専用モジュールを作って使うのもいいよという話。

「いろんな言語を適材適所で使おう」 Kentaro Kuribayashi @kentaro 氏 (藤原洋記念ホール)

経営的な視点まで入った技術選択の考え方の概論トーク。

  • 継続性を見越した技術選択
  • microservices

「WHERE 狙いのキー、ORDER BY 狙いのキー」 @yoku0825 氏 (藤原洋記念ホール)

MySQL のインデックスを Perl データ構造で擬似的に説明。

フォントかわいいけどコード部分とかちょっと見辛かった。

「Mojolicious を使った web アプリケーション開発 実践編」 Yoshimitsu Torii @torii704 氏 (藤原洋記念ホール)

ビギナー向け。

Java For Perl Mongers」 Kazuhiro Osawa @Yappo 氏 (藤原洋記念ホール)

Java = Perl

Lightning Talks Day 1 (藤原洋記念ホール) スタート!

ハッシュタグ #yapcramen

(画像http://yapcasia.org/2014/ より)

今日のさえずり: 2 の開発中止あるある

2014年08月29日

[ 8月29日全て ]

2016年11月1日 (火)

第2回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会2回目。今日は第2章 スクラムフレームワーク。発表当番でした。

プロダクトバックログをまとめるというアクティビティ」に「グルーミング」という名前がついていて「へぇー」となりました。ここらへんはプロダクトオーナー頑張れの世界であまり扱われないのかなと思っていたので。名前がついているとタスク管理ツールに入れておきやすくて助かります。

[ 11月1日全て ]

2017年1月31日 (火)

第13回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。

スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。

ファンクショナルマネージャー

ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。

  • チームを編成する
  • チームを育てる
  • 環境を合わせてなじませる
  • 価値創造の流れを作る

マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。

チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。

本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。

チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。

プロジェクトマネージャー

後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。

[ 1月31日全て ]

2017年2月7日 (火)

第14回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

  • 事前にきちんと計画を作れると思うな
  • 計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

[ 2月7日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ 4月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.056222s / load averages: 0.53, 0.68, 0.68
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker