パスワードを忘れた? アカウント作成

tabateeさんのトモダチの日記みんなの日記も見てね。 過去1週間(やそれより前)のストーリは、ストーリアーカイブで確認できますよ。

12765541 journal
日記

tabateeの日記: 掃除された物 2

日記 by tabatee

この10年かそこらでLinuxの界隈から事実上無くなっていった物たちを列挙してみました。古いのに慣れた人からparanoid扱いされつつも将来のために掃除していく努力に感謝です。(適当に列挙したので、意味不明なところはスルー推奨)

  * cron, inetd, initでバラバラなサービス定義
  * rootにsetuidされているpsコマンド
  * NIS
  * hosts.equiv
  * mountコマンドによる /etc/mtab の更新
  * fontの追加にroot権限が必要
  * /usr/X11R6/というディレクトリ
  * 認証無しに複数ユーザーが使う日本語入力のサーバー
  * ソースの変更をファイル単位でしか追ってくれないソースコード管理ツール

12553014 journal
日記

tabateeの日記: 日本語入力のその後 6

日記 by tabatee

今年のOSS貢献者賞Mozcの主要開発者達を推薦してみたんですが、誰も受賞してないようです。

この賞ができて以来10年ぐらい、その時代に日本語入力に関わってる人はちょくちょく推薦されてたっぽいですが、全敗というのが現状のようです。

個人的には悲しいですが、彼等の価値判断なら仕方ないですよねー

12526938 journal
日記

tabateeの日記: Mir

日記 by tabatee

どっかに書いた事の転載なんですが、Canonical(Ubuntu)の作ってるdisplay serverのMirを他の色んな人達が作ってるWaylandと比較してみました。
* C++で書いてて、今時 struct foo_list { .. *next, *prev; .. } なんてものを見なくて良い。(STLとBoostも使ってる)
* Autotoolsの代わりにCMakeを使ってる
* Protocol Buffersを使ってる
* google-glogを使ってる
* continuous buildがある
* unit testsがある
* code reviewが必須

古くからPC-UNIXのGUIのコードや開発者に親近感と信頼を持つような人だとCanonicalのやり方は誰も得しないように感じたりするんでしょうけど、Mirの方が扱いやすい場合もありそうです。

11403070 journal
日記

tabateeの日記: 日本語入力のその後 1

日記 by tabatee

僕が日本語入力のためのコードを書かなくなって5年ぐらい経過しました。ほとぼりが冷めたら思い出話や裏話を書こうかなと思ってたのですが、PCの代替わり等で資料が散逸しちゃってて色々と確認できない状況です。

日本語入力だけじゃなくてLinuxのデスクトップの開発に興味を持つ人も減ってしまってる今日この頃で、忘却が進むのかなと思うと少し寂しい感じです。

89406 journal

tabateeの日記: リリース経路

日記 by tabatee
以前に開発したanthyというカナ漢字変換のソフトがユーザの手元に届く経路が複数あったので、ちょっと比較してみました。
  • OSS的なリリース: sf.jpでプロジェクトを持ち、MLで議論、ディストリビューションへの収録がメインの経路。
  • Webアプリ(Social IMEのバックエンド)としてのリリース:広く使われるクライアントもリリースされているが、webでのAPI公開によって色々な使い方が試行錯誤されているのが興味深い。
  • Windowsアプリ(WinAnthyのバックエンド)としてのリリース:Windows向けの単発のアプリであり、物議を醸す機能もないため使える環境は多い。
  • コミケ向けリリース(cシリーズ):内輪受け用。

コミケ向けを除けば、ネット上のあちこちでポジティブな言及(「設計がcool」「こんなのが欲しかった」等)やネガティブな言及(「この作者はアホ」「この動作は最悪」等)があり、適当に探せば作者として受けているであろうフィードバックが推測できるかと思います(当然、作者の所にしか来ないためネット上に公開されていないものもあるはずです)。同じソフトでありながら、出した経路によってフィードバックの性質が異なる点はかなり興味深いと感じます。

この例に限らず、作ったソフトに対するネガティブなフィードバックがいっぱいあればダメというわけでもなく、開発を楽しめるかどうかは個人の感性やら状況、虫の居所などに依存しそうです。自分としては、アマチュアとしてやる場合には、開発者への共感が得られることが重要だと考えています。(参考になりそうなストーリー)

リリースの経路の違いよりもソフトの性質や開発者の違いに依存する部分が大きいかもしれませんが、これから非ビジネスでソフトを作って楽しもうとする人がどの経路からどのようにリリースするのか考える時の参考になればと思います。


(このエントリ書く前に不適切な悪口のエントリを書いてしまったので削除済み)
そう言えば、夏が近い...

62978 journal

tabateeの日記: key/value storageの話 1

日記 by tabatee
key/value storageの話を聞きに行くので、ちょっと予習
人によって色々なのを思い浮かべそうなので、思いついたポイントを列挙。
  • 速度: 超高速(数十クロック~数百クロック/look up)←→人が見てインタラクティブ←→低速
  • キー: 数値、文字列、バイナリ
  • 更新: 不可、高速、低速
  • lookup: 1 per 1 operation, multiple keys
  • backing store: 無し、ディスク、ネットワーク
  • 構成: 1thread, multi threads, cluster
  • 記憶効率: compressed, succinct, 普通, 富豪
  • 信頼性: 耐タンパ、耐故障(RAMのソフトエラー等)、ACID、特になし

例によって何か抜けてるとは思いますが、こんだけ組み合わせがあると既存のものがフィットしないで悩むことも多そうです。SQLサーバが全部をカバーしてくれると楽で良いんですが…

454753 journal

tabateeの日記: implicit tasks 1

日記 by tabatee
下記のリストはオープンソースのソフトを作ってた時の経験を内輪で議論した時の資料で、資料としてはウケが良かったのでメモ的に公開しときます。(作るソフトの内容やユーザ層によっては意味のない項目も含んでいます)
自分としては、アマチュアとしてソフトウェアの開発を楽しみたい人が(ソフトの種類や開発者の気分によって異なりますが)どういう所を活動の場とすると良いのかに興味を持って議論していました。ありそうな選択肢としては、(1)sourceforge等にあるようなOSSとして、(2)vector.co.jp等、(3)コミケ等のイベント、(4)ウェブアプリ等、が思い浮かびます。
  • ソフトウェアの名前は十分に考えてつける
  • 一貫性のあるバージョン番号付けをする
  • 定まったリリースプロセスを持つ
  • 気まぐれに開発を終わらない
  • READMEやCOPYINGといったファイル名の慣習に従う
  • 公開リポジトリを持つこと
  • 各commitは論理的に一つの変更であること
  • 各commitには説明的なlogがあること
  • セキュリティ問題が発生した時には標準的なプロセスに従って迅速に対応する
  • API/ABIはむやみに変更しない
  • API/ABIを変更するときは前もって移行プランをアナウンスをする
  • API/ABIの変更時には適切なバージョン付けをする
  • リリース時には変更点の説明を付ける
  • 同じ名前でリリースしたものをさしかえない
  • 開発に参加する人向けの公開MLを作る
  • エンドユーザが参加できる公開MLを作る
  • MLで誰も返事しない質問には返事する
  • バグの対応方針をすぐに言う
  • 隣接レイヤーの開発者に負担をかけていないか確認する
  • ディストリビューションの担当者とのコミュニケーションを取る
  • 評判を適宜検索し、報告されていない問題がないか確認する
  • 一般的なスペックの環境でそれなりに動くようにする
  • メジャーでないOSでも動くようにする
  • メジャーでないCPUでも動くようにする
  • メジャーでない環境で動かせるようにする変更を受け付ける
  • リソースの消費は同等機能を持つ商用ソフトの数倍以内が望ましい
  • マイナーなライブラリ等への依存を避ける
  • パッケージのどのファイルにもライセンスを記載する
  • ソフトウェアを作るのに使うデータ、ツールもオープンソースで入手可能なものを選ぶ

(適当に過不足があるので真に受けないでください。アマチュアの場合は全部やるのは無理っぽいので、どれを省くかの選択も重要になってくるかと思います)

457909 journal

tabateeの日記: late excuse

日記 by tabatee
Linux等で日本語入力のソフト等を色々なレイヤーで協調して開発ができてるうちに開発者の誰かが日本OSS貢献者賞(参考)を取れたら良いなあなんて思ってたのですが、結局、誰も受賞しないうちに現役開発者と呼べそうな人がほとんどいなくなってしまっているのが現状だと思います。
実際のところ、審査に関わられたmatz氏の日記によると、ビジネス的な側面も求められるようで、さもありなんという感じです。

...という感じで残念と思ってたところで、anthyをバックエンドに使ってくれているSocial IMEネットランナーの賞受賞したというのを知って、ちょっとうれしかったです。

#IPAのOSSなんとかによる頭越しの"標準化"に嫌気がさしてinput methodsの周辺から逃げてしまった身としては色々申し訳なく思う今日この頃です。(2004年頃のフレームワークがどうとかの時は対立を辞さなかったのですが…)
464932 journal

tabateeの日記: lc 2

日記 by tabatee
何気なくLinux conferenceのcfpを見てたら「自然言語処理: SocialIME、Anthy、ChaIME など」とあって当惑。
まあ、深く考えずに書いたであろうところを深読みしてもしょうがないのでスルーですかね。

あとこのストーリーで内定を取り消された人が自分の友人であることに気付いて愕然。
467337 journal

tabateeの日記: 最近した議論 1

日記 by tabatee
自分も含めて以前にオープンソースのソフトウェアを書いていた人たちで自分たちの書いたソフトウェアの性質について議論する機会がありました。その場のメンツの書いたソフトウェアの特徴として(1)Computer Science系の手の込んだアルゴリズムとデータ構造を持ち、その部分は開発に参加する敷居が高い。(2)それらのソフトウェアの出力は比較的エンドユーザに見える形で利用される。このような特徴を持ったソフトウェアの開発には往々にして周辺を肥大化させてコアのメンテナンス性を悪化させる方向に圧力がかかってしまうという傾向があるんではないかという話がありました。

コアをいじる側の人間としては、自分のバックグラウンドと小難しい技術を振りかざして周辺の開発者を妨げるような最悪最低なことはしたくありませんし(そんなことするぐらいならどこか別の所へ行くべきでしょう、特にこれはオープンソースの話ですし)、周辺の開発者も悪意があってやっているわけではないはずです。
とは言っても、コアの側への理解の無い人間がフレームワークとか言ってたり、予算を取って(コアのメンテナンス性を犠牲にした上で)コアの部分以外で色々な成果っぽいものを出してたりすると、もっと適切なバランスはないものかと考えてしまいます。
typodupeerror

ソースを見ろ -- ある4桁UID

読み込み中...