謹賀新年/2015目標
あけましておめでとうございます。
旧年中、リアル・SNS あわせて交流して下さった皆様、 仲良くして下さりありがとうございました。
また本年もよろしくお願いいたします。
昨年の反省点
- ライフワークの研究開発にかける時間が、(特に昨年後半)一層減ったこと
- 本が増えすぎて生活スペース自体が圧迫され始めたこと
- 体が疲れやすくなっている、ぽいこと
- 本の整理が思ったほど進まず、むしろ増えてしまったこと
昨年の良かった点
- 職場の新体制が、まずは順当に進みだしたこと
YATT::Lite に関して
- 何より、議論を交わせる相手を得たこと。ありがたや…
- テンプレートエンジンNightで発表できたこと 仕事の手離れを良くする手段としての、静的検査のあるテンプレートエンジン (YATT::Lite talk at 2014 テンプレートエンジンNight) from Hiroaki KOBAYASHIwww.slideshare.net
未来塾のお手伝いで、多少はお役に立てたっぽいこと
今年の目標
Fedora20 を UEFI な HP製 notepc にインストールする時のパーティション設定について
.oO(老害っぽいインストールメモ記事ですよ、と…)
年初に Fedora20 を HP の notepc (HP Envy TouchSmart) にインストールした時にメモを残してなかったせいで、先日買った HP elitebook 840 G1 でも同じ試行錯誤をするはめになってしまいました。Fedora20 で UEFI な notepc をカスタムパーティション構成でインストールするのは結構ハマり沼っぽいので、今度こそ記録を残しておこうと思います。(UEFI のブート設定周りは、また別の記事で書きます)
試す場合は自己責任でよろしくお願いします。間違っても HP さんに問い合わせたりしませぬよう…
(自分メモなので、途中で口調が変わりますが、面倒なので放置します)
前提
- あくまで Fedora Linux を常用する人のための内容です。(Dualboot にするとは限らない)
- Fedora は暗号化 lvm の上にインストールします(vg 全体を暗号化する。 lv 毎の暗号化は行わない)
インストール CD/DVD で起動
CD/DVD が優先されない時は、起動直後に ESC を押してしばらく待ち、BIOS に降りて 設定をいじる
Windows領域を縮める
(書き終わってから気づいたですが、コマンド行に降りなくても ntfs パーティションの縮小が出来るっぽいですね…)
コマンド行に降りてパーティション構成を調べる
fdisk -l /dev/sda
- 私の個体は sda1..6 の５つに分けられていた(はず。少しアヤフヤ) 一番大きい sda4 に Windows 本体が入っており、続く sda5, 6 がリカバリー関連だった。
- EFI システムパーテイションは sda2
まず windows 領域 sda4 の中の ntfs を縮める。今回は 128GiB にする。
ntfsresize -s $[128*1024*1024*1024] /dev/sda4
(-s 128G だと 128*1000*1000*1000 になるので注意)
続けて fdisk /dev/sda で
dコマンドで一旦 6, 5, 4 までを delete するnコマンドで sda4 を目標サイズで確保し直す。- (最近の fdisk はサイズ指定で +128G など書けるので、それに頼る)
tでパーティションタイプを6 Microsoft basic dataに戻す
GUI に戻って、インストール先の選択に進む
この時点でディスクの空きが 300GB ほど出来ているはず。
そんなわけで、自動 -> 戻って -> 手動 でパーティションを切る。具体的には：
インストール先の選択画面で、自動パーティショニング(デフォルト)を選んだ状態で、-
データを暗号化する。パスフレーズは後で設定するもチェックして進む- パスフレーズを聞かれるので入力
- するとトップメニューに戻るので、ここから再び手動パーティショニングに切り替える
- 今度は
インストール先の選択画面で、続行する前にまずディスクパーティションの確認または修正を行うを選ぶ
- これで無事に EFI システムパーティションが /boot/efi へとマウントされることになっている、ことを確認する。(そうでないと、 「stage1 のインストール先が無い」というエラーが出てインストールの続行を拒否される)
- 左下の
+で/bootだけは ext4 で作成. (これが sda5) 固定容量で 1GB もあれば十分 /を 12G で確保。- この時点では デフォルトでは luks-fedora-00 のような lv 名が付くが、このままだと lv 単位の暗号化になってしまう。
- そこで
Volume Groupリスト右側の変更ボタンを押して、vg 設定の画面で暗号化をチェックする。サイズポリシーはできるだけ大きくか、固定容量で余裕をもって割りつける。(lvm を使う以上は、サイズを随時増やしていくことが前提なので。)
- lv の画面に戻ったら、そちらの
暗号化チェックは外す。これで変更を押すと、lv の名前からluks-...という接頭辞が消えるはず。
- vg の名前は、私はサルベージ時の vg 名の衝突が嫌なので vg${INITIAL}${YY} みたいな名前をよく使う。INITIAL は自分のイニシャル。
- 残りのパーティションはこんな感じ
/var8G/home1G. これは運用中に lvresize で拡張するswap8G
- 左上の
完了を押すと変更の概要ダイアログが出るので、本当に設定が望み通りになっているか確認する。この構成では下記のようになっているはず(順番は前後しうる)- sda5 は再フォーマット
- sda6 を確保して LUKS でフォーマットして luks-sda6 を作る
- luks-sda6 上に pv 作成
- 上記 pv 上に vg 作成
- root, var, home, swap の lv 作成
後は通常通り。
YAPC::Asia 2014 感想
今年の YAPC::Asia Tokyo 2014 も楽しかった！ので、少しだけ感想など書いてみます。
面白かったトーク
tokuhirom 氏: “お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました - YAPC::Asia Tokyo 2014”
単体テストをもっと分かりやすく書くための、Test::Kantan の話。
is とか is_deeply を使わなくても式渡しで ok {$obj->meth == $val}; みたいに書けるようになる、power assert 的なもの。ついに perl にも来ますよ、と。これは是非使ってみたいです。
- 内部テストの個数を 1 だとしてしまうのは、意図は分かるものの、「自分が何個テストを書いたのか＝自分がどれだけ頑張ったのかの指標」が減って、ちょっとしょんぼりするかも？です。
moznion氏: “Perl::Lint - Yet Another Perl Source Code Linter - YAPC::Asia Tokyo 2014”
具体的な解析ポリシーのコード例と苦労話を聞かせてもらえたのが非常に良かったです。(自分自身では Critic / PBP スタイルとは若干違うスタイルを磨いてきてしまったので、直接うちに導入できるとは限らないのですが、このような静的解析の具体的事例としても非常に参考になりそうだと感じています。)
- playgroundで試せるのも良いですね。
- もっとも、「何故、どんな理由でこれがダメなのか」を PBP に遡って引くのが、結構面倒で…(><)
Hideyo Imazu氏: “TWiki − Perlで書かれたプログラマブルでglueでスケーラブルなCMS - YAPC::Asia Tokyo 2014”
モルガンスタンレー(!)で TWiki がどのようにインフラとして活用されてきたか、の話。
一個インストールすれば複数の wiki が立てられる？っぽく聞こえました。それは確かに、社内マニュアルシステムに適していそうだなぁと。うちの現場でも業務マニュアルを Wiki に置いていますが、長年の運用の結果、ページが増えすぎたり、一ページ内に複数の情報を詰め込み過ぎたりで、情報の検索粒度が問題になっています。それを別立ての Wiki に分けるのが容易であれば、そういう問題も無くなるのかもしれないな、と。拡張が豊富＆容易、というのも興味深いです。TWiki は全くチェックしていなかったので、少し調べてみようかしら、という気になりました。
uzulla氏: “半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情（5.6対応） - YAPC::Asia Tokyo 2014”
今時の PHP 事情。
去年の yapcasia 以後、八王子pm にちょくちょく参加させて頂いていたので、主催の uzulla さんの熱い PHP トーク自体は何度も拝見していたのですが…
今までで一番凄かったです、そして、ベストトーク賞おめでとうございます！納得の受賞ですよ、はい。(私も uzulla さんに一票入れましたよっ)
Sawyer X氏: “Plack for Fun and Profit (But Mostly Profit) - YAPC::Asia Tokyo 2014”
Dancer/Dancer2 の Sawyer X による、booking.com での PSGI 移行プロセス解説。
前段にマルチプレクサ的な PSGI アプリを置くことで、部分url 毎に別のサブ PSGI アプリとして分けた。その上で、サブアプリごとにビジネス的に実現可能な範囲の改善策を取った、と。正しく定石通りの divide and conquer が機能した事例。これも非常に参考になるなぁと。
songmu氏: “Perl for Perl Mongers (YAPCに来た人は皆Perl Mongerでは？)”
個人的に刺さったのは
- スライド54枚目: 小さいパーツを組み合わることのメリット の,
- “パーツの中身自体はどう書いても良い = TMTOWTDI”
- “TMTOWDI とは他人のやり方に口出しをしないということ”
- スライド65枚目: Perl程長い間愛されている言語はなかなかない の、全部。ここ、愛が有って凄くいいですね！
karupanerura氏: “Perl5 meta programming - YAPC::Asia Tokyo 2014”
私も仕事柄、メタプログラミングは避け得ないものの、どんな便利なモジュールがあるのかについて十分調べきる余裕がなく、またメタプログラミングについて意見交換出来る人も中々居ないので、こういう発表はとても有難いです。内容も整理されていて、使うべき手法の優先順位をつけながら解説していたのがとても良かったです。
hitode909氏: “Perlの静的解析入門とPerlリファクタリングツールApp::PRTのご紹介 - YAPC::Asia Tokyo 2014”
sed とかじゃなく AST ベースで安全確実にメソッド名などを書き換えることが出来る…おおぅ、こういうのは大好きです。なんとか導入してみたいです。
個人的な出来事: gugod が g0v について話してくれたこと
Kang-min Liu (gugod) on Twitter氏が一日目のLTで話してくれた、“g0v .tw 零時政府”、LT では(英語は聞き取りやすかったものの) 理解しきれなかったので、懇親会待ちの間に慣れない英語で質問してみました。
(以下、２日前に英語で聞いたものを記憶から辿って書いているので、間違っていたら済みません)
g0v (彼は gov zero と呼んでた、ように思います。もうひとつの呼び方も有ったかも？)は、社会・政治に関するデータをプログラムの力で visualize していくことで、社会の透明さ(＝公平さ、フェアさ)を増してゆこうとする運動、っぽいです。
最初、私は、彼らが「政府を置き換えるもの」を作ろうとしているのかと思ったのですが、そうではなく、政治と社会を良くするための運動であって、敵対しているわけではないそうです。(もっとも、それは彼が今の政府を好きという意味ではなくて、単純に社会を良くするという目的に集中するための、 practical な態度、という感じでした)
今年？少なくとも二度？彼らのデータが大きく報道され、実際の政治を動かしたことがあるそうです。また、g0v が政治を動かし、それがまた g0v を進化させる、そんな双方向的な関係である、というような言い方もしていたように思います。
今年の春に cnn/bbc などでも盛んに流れた、国会へ学生が立てこもった際にも、彼らの一員(である唐鳳 (audreyt) on Twitter？)が？国会に届く wifi を設置して、国会の内情を国民に知らせる支援を行ったそうです。そのお陰で、国民は怖がらずに済み、 violent にならずに済んだのだと。
私が驚き、かつ羨ましく思ったのは、 g0v のような「political」な活動に、 300 人？ものプログラマー(一人を除いて全員が台湾人)が参加している点です。現代日本人は政治的な活動に関わることを(全方位的に)嫌がるので、日本で何百人も協力者が集まることは、余程上手に無色化しないと無理だろう、そう私は思うからです。彼も別に好きで political な活動に関わっているわけではないらしく、ただ、政府がダメだから、自分の出来ることで台湾社会を良くしていこう、という感じでした。
私が、日本人は政治的な活動を忌避しがちなんだ、と片言英語で言った(つもり！)ら、 彼は、台湾人が政治に関わろうとする背景には、やはり政治弾圧の、困難の歴史があるからだろうね、 という感じのことを言っていました。また、彼は、台湾人は自分たちの政府を持ったことがない、とも言いました。 国民党政府、日本、清、オランダ...
それを聞いてようやく、彼らを動かしているものが分かった気がしました。 彼らには渇望があるのです。社会を良くしよう、自らの手で政治を動かせたらどんなに良いか、という。 その渇望を暴力に向けても今の社会は変わらないから、とにかく現実を一歩々々、良くしよう、と。 民主政治の精神、ここに有り、ってなもんです。
それに比べて、日本の投票率…
ホント、なんとか出来ないものですかね…
Dear @Twitter, please do not change my Fav into spam:-<
Dear @twitter
Today, I found you are experimenting a new feature that pushes my favorites into followers' timelines directly. I can easily imagine how such noise will bother, annoy and/or frustrate my friends/followers, so please do not introduce such feature.
If the feature turned on, how my Favs will annoy my friends/followers?
I've been using twitter for 5years. I don't tweet/retweet so many times, but instead I frequently use "Fav". Here is my stats:
- 8,563 tweets(including retweets)
- 103,362 favorites
- in 1,629days.
As above, my fav is 10 times frequent than my tweets. If all (or part) of them are treated like retweets, I will be seen as an astonishingly chatty, noisy person. If such feature comes to my home, the only workaround for me is to stop sending Favs at all. This is very sad, so please discard such plan.
We've been using RTs and Favs as separate channels, so don't mix them up!
Currently, RTs are injected to followers timelines. We know it well. In contrast, Favs are notified only to the receiver and gently stay visible for others. We know it well too. This fundamental difference gave us freedom of choice of who to notify. If I think a tweet from others has enough reason to share/broadcast, I will retweet it simply. If I feel it is interesting, but broadcasting it is not good in some reason (ex. Not so accurate, controversial, or it's just a personal conversation...), I can just send a Fav.
Actually, I've expressed various meanings with my Favs, but I strongly cared whether they met my personal criteria of the Favs. That is:
- I like it!
- I agree with you!
- It's very informative!
- I stand for you!
- Thank you!
And most importantly, I want to send above messages without bothering others. In other words, I want to express my personal respects without being loud like a spammer. As a Japanese, I feel this is very important. I don't want to be a shameless person in Japanese sense. I'm not sure you western people could understand this kind of feeling, but I hope you could.
自戒与太話: 上下意識はハッカー文化に合わない
あくまで自戒として。少しだけ 8p 方面へのエールも。
前提：フィフティー・フィフティーな関係って、言うじゃんよ？
我が国は、少なくとも法律の建前の上では欧米と同じく、 身分の上下のない、平等な社会 を目指すことになっています、よね？ だとして、以下に挙げる関係が、日本で「 50%/50% の、対等な関係 」(お互い様、貸し借りなし、恨みっこなし…)になっていると言い切れる人が、どのくらいいるでしょう？
- 客と店員
- 雇い主と従業員
- 人事部と就職活動中の人
- 上司と部下
- 元請けと下請け
- 大企業と中小企業
- 老人と若者
- 年長と年少
- 先輩と後輩
- 先生と生徒
- お役人と一般大衆
- 政治家と一般大衆
- 先生と呼ばれる地位と、そこから漏れる人
もちろん、以下の点は踏まえるとして：
- 上記の関係の中には、本質的な力量の差が存在するケースもあるので、そこを勘定に入れた関係のアンバランス(貸し借り)が生じるのはやむを得ません。
- あるいは会社や軍隊のように、意思決定と命令の秩序体系を作るため、便法として地位を規定することもあるでしょう。
- 心の中でどう思っているかは自由です。それを社会的に、言葉、態度、行動として外に出した時だけを考えます。
思考実験1. 文脈を外してみる
では、以下のように元の文脈を離れた時に、両者がきちんと「対等な関係」にリセット出来ているでしょうか？
- お店の外での「客と店員」
- 業務時間外の「雇い主と従業員」
- 業務時間外の「上司と部下」
- 部活の外での「先輩と後輩」
- 学校の外での「先生と生徒」
文脈の外まで引きずって「偉ぶる / 下手に出る」部分が有れば、そこには根拠なき「上下意識」があるように思えます。「下手に出ない、といって怒る」などは、相手を(マイルドな)奴隷と見ている証拠でしょう。
フェアか否かは発言内容だけでなく、態度でも決まる
文脈を外れた時に「対等な関係」に戻れるなら、文脈の中ではどう振る舞っても良いのでしょうか？ そんなはずはなくて、例えば「 客から店員への暴言 」は不当でしょう。「強い立場を不当に利用して、抵抗できない相手を攻撃している」と言えます。
ただ、一歩踏み込んで、 どこからが暴言か？ となると、「何を言ったか・行ったか」単体で判断するのは簡単ではない、ように思います。例えば：
- 食堂で客から店員へ「◯◯がマズイ、と苦情をいうこと」
- 仕事で上司が部下へ「どちらのデザイン・プログラムソースコード・…が美しいか、に関して指導すること」
この「マズイ」「美しい」は個人の感覚に依存するので、発言が 妥当か否か を字面だけで判定するには多数の他者の意見も集めない限り無理でしょう。そして妥当か否か定かでない発言が フェアか否か は、どんな態度で、声色で、それを言ったかで決まる所が極めて大きい、ように思います。
思考実験2. 文脈の中で、立場を逆転してみる
そこで今度は、ある発言態度がフェアか否かを判別するための思考実験として、 以下のように(文脈の中で)突如、立場が逆転したケースを考えてみましょう。
- 学校で「夏休み明け、クラスメートに、背を抜かれていた」
- 職場で「以前の部下が、今度は上司になった」
- 職場で「以前は自分が相手のバグを指摘する側だったが、今度は自分が相手にバグを指摘される側になった」
- 時代劇で「邪険に扱ったジジイが、黄門様だった」
ここで強い立場から弱い立場に移っても、全く同じように振る舞える人は、万人にフェアに接する努力をしている人ではないかと思います。逆に「居心地悪く・気まずく」感じたり、「仕返しされないか」怖くなる人は、「上下関係と上下意識が生む、強い立場の力」から不当な利益を得ていた、んじゃないカナ〜
強い立場にある人が、その立場の力を乱用すると、どんな害がある？
- 無駄が無くならない、増えていく
- そこを理不尽に感じる、不幸に感じる人が増える
- 組織・社会に閉塞感が蔓延する
- アノミー(無連帯)が現出する？？
真のハッカーならどうするか
真のハッカーは、無駄や理不尽を嫌うはずです。何故なら、その無駄こそ、ハッカーの愛する計算機が解くべき問題だからです。無駄を無駄のまま放置することを心の底から憎悪し、それを強要する者には (実行できなくとも) 心の中では殺意に近い感情を抱く、それがハッカーの自然な感情であるように、私は理解しています。
また同時に、真のハッカーは、矛盾を嫌い一貫性を追求する心を持っている、ように私は思います。論理や構成の一貫性は、プログラムの美しさと通じる部分があるからです。
それ故に、真のハッカーを目指す人は、自分の中から上下意識を駆逐せねばならない。上下意識に基づく行動を、注意深く見分けて、自分がそれをせぬよう避けねばならない。さもなくば、 無駄への殺意 か 自分の中のダブルスタンダードへの殺意 が自分を殺す日が来るからです。
Q1: 体育会系的な上下関係が全て悪だと言うのか？
いいえ。「敬意を表現する方法」の訓練システムとして、体育会系の上下関係には一定の価値があるでしょう。名誉への敬意を表現するフォームを多くの日本人が学んできたことは、社会の安定に役立って来たのではないでしょうか。
問題は、その敬意を受け取った側が、相手を「目下の者」として扱いがちなことだと、私は思います。敬意には感謝で返せば済むだけなのに。ちゃんとした武道教育にはこれも含まれていたはずですが…
Q2: 具体的に何から始めれば？
例えばコンビニの店員さんに敬語で接するとか…
おまけ
「 自分の力をフェアに使う 」とはどういうことか、主人公と一緒に悩んでみると、学びがある、かも？
世捨て人の(胡散臭い) まじない師ならではの「力の正しい使い方」から、学べることもある、かも？
もう少し真面目に、権力闘争と正義について考えたい人には、 兵頭軍学 をオススメしたいです。それについてはまた今度…
「納品のない受託開発」、フリーランスな私の場合
先日、「納品」をなくせばうまくいく、という本を買いました。タイトルに近いことを自分も長年感じていたので、即買いでした。
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/07/18
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
私は(この本の著者さんと違って)フリーランスですが、 (実質的に)納品のない仕事の請け方を追求してきたので、非常に納得する点が多く有りました。 また同時に、自分の現場には適用できない点や、 フリーランスな自分では辿り着けない点も多々見つけられたので、 少しまとめてみます。
本の要約
私なりに要約すると…
- (特に Web サービス系の) ベンチャー事業にとって、従来の「一括請負⇒納品して終わり」 という形の受託開発は相性が悪い。なぜなら、
- 一括請負型の受託開発ビジネスとは
- 全機能の要件定義と見積もりを最初に行い、
- 全機能をまとめて開発して、納品して完了
- 保守・運営(運用) は別会社に、 というものである。
- これに対し、Web サービス事業で、どの機能が当たるか予め全て予測することは困難。 事業の成否はサービス開始後の、運営しながらの継続的改良にかかっている。
つまり、発注側が「頑張って欲しい」と思っているところと、 受注側が「頑張る所」が根本的にズレている。 ズレの根っこが「納品」というゴール設定にあるので、これを取っ払って、 新しい仕事の請け方、頼み方を組み立ててはどうか？と。
フリーランスな私との比較
共通点
- 仕様書なし、見積もりなし、納品(完了)なし
- (作って納品して終わりでなく) 日々改良していく
- 月額定額制
- 一人の開発者が目標設定の打ち合わせから開発・運用まで、一貫して関与(伝言ゲームにしない)
- 顧客にも動作確認の責任を分担してもらう
私がガチガチの納品というゴールを避けるようになったのは、 本来好きで楽しいはずのプログラミングが、 仕様と締め切りを固められただけで (どんなに凄いプログラムでも) 出来て当たり前となり、 妙に苦しくなることへの疑問が有ったからでした。 そこでいつからか、エンドクライアントの居る案件でも 「お客様にお知らせする仕様＆納期にベストエフォートだと断りを入れる」 ようにした結果、精神的に随分と楽になったので、最近は全てそうしています。
異なる点：スタッフさんの訓練まで請け負うなら遠隔勤務は難しい
フリーランスであること以外で、「納品のない〜」と私の仕事の最大の違いは、 リモート作業が主か否か、です。この著者さんの会社の場合、 基本的な開発作業は自社で行い、会議もリモートで参加するようです。 ですが私の場合は、少なくとも現状では顧客のオフィスに出勤せねばなりません。 その最大の理由は、私が 「サービス運営スタッフさんへのプログラミング教育・訓練」 を請け負っているからです。
私の顧客の事業は受注案件ごとにプログラム開発(作成、と言うべきかもしれませんが)を行うもので、 (年間数百件の開発を私が直接作っていては事業がスケールしませんから) 顧客が人を雇って開発を行ってもらっています。 しかも顧客が雇うスタッフさんは、実はプログラミング未経験者ばかりです。 業務的に知名度がないことに加えて、CSを取ったプログラマーだと すぐに飽きて(辞めて)しまうようなプログラムを、次から次へと年がら年中、書かねばならないためです。 未経験の方が、何年も掛けて現場で学んでいける分、定着して下さっています。
そういう状況ですから、私の仕事は、
- プログラム未経験者でも戦力になれるような Web App Framework と、そのための (簡易) IDE を提供する
- その WAF (や、その後継機) 上で用いる業務応用モジュール群を大量に提供する
- スタッフのプログラミング上の質問に答え、彼ら彼女らの成長・自立を助ける。
- 自ら受注案件間の共通部分を見出して、部品を生み出していけるように。
- 業務のテンプレート集、業務マニュアル wiki なども書きますが、これについては 私が全部を書くのではなく、スタッフが自分で書く勇気と習慣を身につけられるよう、 うまく導かねばなりません。
です。遠隔勤務だとどうなるか、なかなか難しそうです。
フリーランスの限界
私は独りで仕事を請けています。人を雇える状況ではないので、後継ぎもいません。 つまり、 モジュールのマニュアルを読んでくれる人も、 コードレビューもペア・プログラミングの相手も居ない状況を ほぼ 10年以上、引きずってしまいました。
そうして、残念ながら、私自身が顧客の事業の SPOF - Single Point Of Failure になっている…この点が、上記著者さんの会社と見比べて、今の自分が最も見劣りする部分です。
幸い、顧客企業とは散々話し合って、この点の問題意識は共有できているので、 今後は八王子PMなどの勉強会・交流会に少しでも顔を出して、 一緒に仕事をして下さる方を増やしていこう…そういう感じです。
まとめは、ありません！
吹き荒れる OOP 批判の嵐の中で独り言〜
(自分への返信にしたから見辛いっすね...)
.oO(最近 OOP 批判が吹き荒れてるなぁ…
オイラは、オブジェクトをエディタと見なして設計するとうまく行くと感じてる。
システム全体が、エディタの集まりになる。
メンバー変数はエディタの動作オプションや各種のキャッシュに使う)
— h小林:KOBAYASI Hiroaki (@hkoba) 2014, 7月 19debug とか progress、throttle とかのオプションが欲しくなる処理はメソッドにするし、
そうでない、オプションの不要な汎用的なルーチンは関数にする、
そんな感じです。
— h小林:KOBAYASI Hiroaki (@hkoba) 2014, 7月 19プログラム全体の使用目的から考えて「トップレベルに、何のエディタが必要か」をまず考えて、それを必要に応じて細かいエディタや、汎用の関数に分けていく。
この方針は何をクラスにするかで迷う事が大分減る、ように思うので、おすすめですよっと。
— h小林:KOBAYASI Hiroaki (@hkoba) 2014, 7月 19メンバー変数にするもの、アキュムレータを忘れてた。
集計とかは完全にこれだし。
— h小林:KOBAYASI Hiroaki (@hkoba) 2014, 7月 19コード出せよと言われそうなので、一つ貼っときます＞
hktools/sqlite-explain.tcl at master · hkoba/hktools · GitHub
