2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2010年03月24日1

いや、だから、Appleの「ガラクタは作らない」って
いうのも立派ですよ。ただ、それをやるのは大変でしょう。

それに、Appleにしたって最初はApple IIとかなわけで
しょう。Apple IIがガラクタとはいいませんけど、でも、
洗練された製品だったとはとてもいえないでしょう。

本家Permlink


2010年03月24日

『フリー』(C.Anderson, NHK出版)の中で、Limor Fried氏の
言葉が紹介されています:

  結局、物語性の問題なのです。人々は物語の始まりや中盤、
  結末や筋を知りたがるのです。どこかに購入ボタンがあれえば、
  彼らはときどきそれをクリックして、私たちがまじめに働いて
  いることに対してご褒美をくれるのです。

物語、ああ、物語。物語こそお金の成る木。

でも、自分、物語性を疑ってるんですよね。『ブラック・スワン』
の影響なんですけど。

人間は、物語のないところにも物語を見出してしまう生き物
でしょう。ならば、ヘタな物語を考えるより、あるがままに
任せたほうがウケるかもしれないじゃないですか。

こういう、あえて筋を作らないやり方って、そんなに珍しい
わけじゃなくって。映画や小説でよく『難解な〜』なんて
いわれるものは、作者がどう思ってるかどうかは別にして、
受け手として物語を感じ取れないわけだから、物語や筋
として成り立っていないわけでしょう。でも、熱心な人は、
そこにムリヤリにでも物語を見つけ出そうとする。

結局、デコボコな感じだったり、異様なものだったり、
それこそ未完成なものであれば、人間はそこに物語を
見つけようとするんじゃないでしょうか。

新しいものはいつも未熟で、だからこそ人に期待を抱かせる。
そんな気がするんですよね。

本家Permlink


2010年03月16日

javax.swing.undo.UndoManagerがよくわかんねーなーと
思っていろいろやってたんですけど。ようやくなんとなく
わかってきました。

UndoManagerの何がよくわかんないかといえば、連続した
Editの束ね方。たとえば、UndoManagerとJTextComponentを
組み合わせて使うとき、何の工夫もしなければ、1文字
ずつundoされちゃいます。

123

とタイプしたとして、1回undoすると:

12

となって、もう1回undoすると:

1

になる。このときredoすると:

12

になる。

でも、フツーは:

123

とタイプしたときに、1回のundoですべての文字が消えて
ほしい、さらにredoしたらまた123が復活してほしいもの。

で、こういうときはCompoundEditを使うんだっていうのは
よく知られてるんですけど。でも、その使い方がよく
わかんねーなーっていう。javadoc見ても大したこと
書かれてないし、巷に流通してるコード見ても、なんか
違うなーと。

で、そもそもUndoManagerの動きがよくわかってねんじゃね?
ってことになって。わざわざNetBeansもらってきて、
デバッガでUndoManagerの動きを追って。それでようやく
なんとなくはわかってきて。

最初のうちは、CompoundEdit使うにはUndoManagerの
サブクラス作るしかないのかと思ったんですよね。巷の
コード見るとそんな感じのが多くって。でも、そりゃ
おかしいだろと、思ったわけですよ。オレは継承嫌いだし。

そもそも、UndoManagerがCompoundEditのサブクラスに
なってるのは設計間違ってるでしょ? is_a?が崩れてん
じゃん? イマドキ、Javaのライブラリでこんなアンチ
パターン見るとは思わなかったわ。

閑話休題。で、やっぱりCompoundEdit使うのに継承は
いらなそうだとわかってきて。書いたコードが下のヤツ。
ほんとにサンプル目的なんで実用的じゃないんですけど。
Editを2個ずつ束ねてるっていう、ただそれだけ。

また脱線すると、JTextComponentで起こるUndoableEditEvent
から取れるEditって、AbstractDocument.DefaultDocumentEvent
ってヤツなんですよ。これがもうバリバリの内部クラスで。
外からだとサブクラス作れない。名前もおかしいでしょ?
実際のコードだと:

public void undoableEditHappened(UndoableEditEvent event) {
    AbstractDocument.DefaultDocumentEvent edit =
        (AbstractDocument.DefaultDocumentEvent)event.getEdit();
    ...

ってなるんだぜ? わけわからん。歴史的な理由でもある
んですかね。

include Java

java_import java.awt.BorderLayout
java_import javax.swing.JButton
java_import javax.swing.JFrame
java_import javax.swing.JPanel

class UndoManagerTest
  include java.lang.Runnable
  include javax.swing.event.UndoableEditListener

  def initialize
    @undoManager = javax.swing.undo.UndoManager.new
  end

  def run
    createAndShowGUI
  end

  def createAndShowGUI
    frame = JFrame.new("UndoTest")
    frame.setContentPane(createContentPane)
    frame.setDefaultCloseOperation(JFrame::EXIT_ON_CLOSE)
    frame.pack
    frame.setVisible(true)
  end

  def createContentPane
    pane = JPanel.new(BorderLayout.new)
    editor = javax.swing.JEditorPane.new
    editor.setPreferredSize(java.awt.Dimension.new(320, 240))
    editor.document.addUndoableEditListener(self)
    pane.add(editor, BorderLayout::CENTER)
    pane.add(createButtonPane, BorderLayout::SOUTH)
    return pane
  end

  def createButtonPane
    pane = JPanel.new
    undoButton = JButton.new("Undo")
    undoButton.addActionListener do |actionEvent|
      @undoManager.canUndo and @undoManager.undo
    end
    pane.add(undoButton)

    redoButton = JButton.new("Redo")
    redoButton.addActionListener do |actionEvent|
      @undoManager.canRedo and @undoManager.redo
    end
    pane.add(redoButton)
    return pane
  end

  def undoableEditHappened(event)
    seq = SequentialEdit.new
    seq.addEdit(event.edit)
    seq.evenId? and @undoManager.lastEdit and @undoManager.lastEdit.end
    @undoManager.addEdit(seq)
  end
end

class SequentialEdit < javax.swing.undo.CompoundEdit
  @@count = 0

  def initialize
    @id = @@count
    @@count += 1
  end

  def isInProgress
    return false
  end

  def evenId?
    return @id % 2 == 0
  end
end

if $0 == __FILE__
  javax.swing.SwingUtilities.invokeLater(UndoManagerTest.new)
end

本家Permlink


2010年03月15日

(setq Buffer-menu-buffer+size-width 36)
(define-key ctl-x-map "\C-b" 'electric-buffer-list)

もう、ね、26とか、バカかと。バッファ名が途中で
チョン切れるとかね。ありえないからね。サイズなんて
どうでもええっちゅーねん。モードなんてどうでもええ
っちゅーねん。なんか前にもおんなじこと書いた気が
すんだけど、もっかい書いたる。

本家Permlink


2010年03月07日

忘れないように、こないだの話をまとめつつ、自分の
考えも整理しておく:

* 朝会をストーリー・ベースで進めるべきか、それとも
  人ベースで進めるべきか?

  朝会はプロジェクトの進捗を確かめるためにやるの
  だから、ストーリー・ベースでやるべき。その
  イテレーションの中でストーリーが減っていっているか
  どうかを確かめる。メンバー全員に作業が割り当たって
  いるかどうかは二の次。

* 作り壊しは避けられないのか?

  避けられない。機能追加にしても、修正にしても、他に
  影響を与えずにやることはできない。ただし、作り
  壊しを減らす努力は必要。その努力とは:

  * コードをよく読む。
  * 経験者に注意点を聞く。
  * 実装に入る前の方針段階でのレビュー。

  さらに、作り壊しが避けられない以上、テストが重要に
  なる。テストを習慣づける。

本家Permlink


2010年03月05日


本家Permlink


2010年03月04日1

More Joelを読んでるんだけど。

やっぱり『手持ちのプログラム』を持ってることは
大切なのかもしれないと思った。

もし自分が面接官になったとして、被面接者に頼みたい
ことは『あなたの書いたプログラムを見せてください』
っていうこと。そんなとき見せられるプログラムを持って
いるか。

前の仕事で納品したコードは、常識的には、見せられる
もんじゃない。契約的にも、倫理的にも。だとすると、
面接のようなときに見せられるのは、自分のために書いた
プログラムってことになる。

自分のためにプログラムを書くってことは、それだけでも
プログラマの資質があるんじゃないかと人に思わせる。

もちろん、このやり方は、どっかから拾ってきたコードを
見せられる危険がある。それでも、見せられたコードを
ネタに話をすることができるし、パクるほうにしても
ヘタなコードをパクるわけにもいかない。

『手持ちのプログラム』っていうのは使い捨てじゃない
っていう意味。繰り返し使うために書くプログラム。
結局は一回しか使わなかったりもするけど、でも、
書いてるときは本気度は高いはず。

本気度が高いと、そのプログラムをきっかけにいろんな
ことを考えるようになる。ユーザ・インターフェイスとか
エラー処理とか。そうしたことは本を写経するだけだと
素通りしちゃう。

仕事ももちろん本気なんだけど、仕事の場合、本気に
ならざるを得ない仕組みが働く。自分のために書く
プログラムだったら手抜きしても怒られることもない。
だから、自分のためのプログラムを本気で書くっていう
のは案外むずかしい。

だから、ネタ選びが重要になってくる。自分の本気を
維持できるくらいのネタじゃないと、すぐ飽きちゃう。
それがわかってくると、自然とネタを探すようになる。

プログラムのいろんな面を考えることとネタの目利きを
養うこと、これが手持ちのプログラムを持つことの
利点かなぁと。

本家Permlink


2010年03月04日

/~tko/cgi-bin/bakagaiku.rb?bakaid=20100303では
質の定義がよろしくなかったかと反省した。

まぁ、ぶっちゃけ、質の高いコードというのは、ゼニに
なるコードのことだ。ゼニを失わないということも含めて。
バグがあればゼニは失われる。バグをなおすのに人手も
時間もかかるし、評判も落ちる。

そんなわけで、たくさんお金を生み出せるのがよい
コードなわけだ。

そして、同じコードベースからはゼニをできるだけ
たくさん絞り取らないといけない。

つまり、よいコードとは、水気をたっぷり含んだ雑巾
みたいなものだ。絞れば絞るほどゼニが出てくる。

こんがらがったコードは、固く絞られた雑巾のような
ものだ。これ以上絞っても水は一滴も出てこないし、
雑巾を広げるのさえ苦労する。

水気をたっぷり含んだ雑巾というは、何も再利用のこと
だけを意味するわけじゃない。新しい機能を追加する
ときに手間がかからなければ、それだけたくさんゼニが
得られる。また、新しい機能を追加するときも、水気の
多いコードにしておけば、コードベース全体がまた
潤いを取り戻す。

本家Permlink


2010年03月03日

彼らはお金を稼ぎたいと思ってこの若い、カーストの
定まっていない業界に入ってきたのだし。どうすれば
お金が稼げるかもわかっている。要は質の高いコードを
書けばいい。そのくらい合理的に考えられなきゃ
プログラムなんて書けるわけがない。

当然、若い業界の常で、向いてない人も集まってきて
しまう。しかし、十分に人が集まっているなら淘汰も
早い。だから、向いてない人のことはそれほど気に
しなくていい。

やる気はある。質の高いコードを書きたいとも思ってる。
ただ、質の高いコードは、書きたいと念じただけで
書けるものではない。質の高いコードを書くやり方と
いうものがある。

ザッと思いつくままにあげると:

* 4S
* バージョン管理
* 計画することとテストすること
* 失敗と真因追究

こんなところか。これらを徹底することが重要だ。徹底
することが本当に重要なのだ。

徹底するということは、活動の規範、ルールになるという
ことだ。これらを怠るのは悪いことだということを
本能的に理解できるようになることだ。

これらはアジャイルもウォーターフォールも関係なく、
質の高いコードを書こうとするなら欠かせないことだ。

ベスト・プラクティスと呼ばれるものはたくさんある。
たくさんあるということは、それがベストではないと
いうことでもある。場面場面でベストは変わる。でも、
これらは場面場面で変わることはない。やらなければ
質の高いコードを書けない。それだけだ。

--

オッと。『その質ってなに?』ってつっこまれそうだ。

まぁ、みんながフツーに思ってる質の高い状態で
構わない。あまり厳密に定義しても意味はないから。
バグが少なく、十分に設計されていると感じるような
状態とでもしておく。

--

まーなー、オレもユーダケ番長だからなー。

本家Permlink


2010年03月01日

どうも:

  condition or false_action

っていう書き方がダメなんですよね。どうしても:

  !condition and false_action

のほうが書きやすいんです。慣れなのかもしれませんけど。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails