[ 地球流体電脳倶楽部 ] [ 村上のページのトップ ]
種々の短期的な「野望」をここに記す。
以下に列挙する「野望」はあくまで筆者の個人的な考えであり、
地球流体電脳倶楽部の総意とは無関係のものであることを注意しておく。
また、影響範囲が個人に留まらない場合、提案を経ずに実施しないことを念のため注意しておく。
- 情報管理/電脳関係含む
- ソフトウェア関係: dcdvlop関係
- ソフトウェア関係: 電脳Ruby関係
- ソフトウェア関係: dcmodel関係
- ソフトウェア関係: 電脳その他
- TeX関係
- FreeBSD関係
- ブックマーク整理
- 実績の記述
- 自分のデータのバックアップ体制確立
- 電脳bunkenのカードデータベース <-> BiBTeX形式変換スクリプト
- たぶん作るのは簡単
- MendeleyなどのソフトウェアのBiBTeXの出力を、電脳bunkenカードデータベースに流し込むことが可能になる。
- Mendeleyはいまのところ、書誌情報推定精度はいまいちだが、利用者が増えると精度が上がるかも知れない。
- 新しめのpdfはばっちり解釈する。かなり便利。推薦機能まで付いている。
- あちこちの出版社の提供するbibtex/ris/coins/EndNote形式の相互変換、Webからの自動取得スクリプト
- uwabami さん作のADSから書誌情報を取得するスクリプトは、いまやそのままでは動かない。
- yamlかなんかでほいほいと。
- 現在のSIGENから生成する方式は、やや粒度が荒い感がある。
- うまいことソートして、bibtex形式なりwordに張り付けやすい形式に
フォーマットしてくれるのが理想的。
- 決められた書式でそれっぽく、十分な情報をテキストでさらっと書く。種別と種別ごとに決まった並べ方でテキストを並べる。
→ 適当にparseしてyamlに変換 → 人間がチェックして微修正、とか?
- BiBTeXみたいなのはやや書きにくい。3番目のカラムに書いたらこのkeyに対応するvalueに決まっておるだろう、というのが書きやすい。
GECOS field的な。
- 各種OS/distroでパッケージを作成しやすいように、ソフトウェアに求められるガイドラインを規定
- ライセンスの明示
- 依存ソフトウェア、バージョンの明示
- configure スクリプトなどの標準的仕組みを使ったインストール(ダメな例: qmail)
- バージョン番号の付け方
- major version / minor version / revision と呼ぶとして、それ以上増やさないとか。
- 日付入りファイル名のtarballを展開した時のディレクトリ名がhoge_currentだと困る、とか
- 展開物がいつのものかわからん; mvしたらいいけど面倒。
- ディレクトリ構造は「標準的」にする
- 構造化する。
- トップディレクトリに置くテキストはだいたい決まっている。
- 決まっているファイル以外を置くと「気持ち悪い」(画像ファイルとか)。
- 改竄防止のためのtarballのchecksumを用意することが多いので、同じファイル名で中身だけ変えて再リリースしない、とか
- この項目は「ガイドライン」としてメモに移し、こちらには実行計画と実施状況を書く方が良い。
- 仮想化環境を使ってなんとかうまいこと使って、複数distro用パッケージをほいほい作れないか。
- 商用サービスではその手の仮想イメージインスタンスは一瞬で生成される。
- デモプログラムが期待どおりに動くかテスト。これを自動化する。
- 画素単位で相関抽出、適当な閾値を決め、予め規定された出力に合致するか判定。
- 原理的には可能だろうし、思ったよりは簡単だろうが、ともかく考えるのと作業が面倒。
- サーチエンジンに引っかかるべきモノが引っかかるように工夫する
- リンク切れしてるページが多い。
- 中身も古い場合があるけどそれはさておく。
- wget --spider / curlでなんとかかんとかで、リンク先の存在チェックをやって、直していく
- ruby gem化されていると嬉しい。
- 少なくともFreeBSDの場合は、ruby gemのインストールの方がパッケージメンテナとして楽である。
- ディストリビューション固有パッケージの作成は非常に簡単。
- 依存関係を書いて、/usr/local/binに入るプログラムだけ列挙すれば、あとはほぼ何も考えずに済む。
- ri/rurema/manのどれかがほしい。
- 1.9対応は完全? (たぶん、テストは通るのだろう)
- --helpでhistoryまで出てくるのはどうか。--infoでman相当、--helpはサマリ、がよい。
- gpviewで、手元でなぜかt=1000付近のデータが欠落して描画される。欠損値が-999.9(くらい、たしか。)であることと関係?
- gpcatはruby 1.9.3で動かない。syntax error
- gpcutとかgpcatで、ファイル内の複数gtool変数について適用して欲しいことがある。
- vor.ncに、vor.nc@vorだけでなく、対応するvor.nc@strも保存してある場合など。
- 場合によっては初期値を保存したりもするので、初期値はマージしたくない、とかいう場合がある。
- マージ用途にはgpcatについては、gpmergeとかいうのを作った方がよさそうである。
- gpcatという名前は、オブジェクトの中身が衝突したときにどうなるかイメージできない。
- catは文字列ストリームを扱うので、対応がいまいちかなと。
- gpmerge -o vor.nc --var vor,str vor-0.nc vor-1.nc とかやると、
vor-0.ncをベースにして、vor,strの存在しない値のところをvor-1.ncの変数で埋める。
- 重複した場合には上書きするというオプションがあるとよい。
- gpcommonの中で作っておいて、multivar_enableオプションみたいなのをgpcutとかの中でtrueにしておくと、このfeatureがenableになる、と。
- gpviewに任意の関数内定義を適当なタイミングで実行するhookメソッドを実行するしくみを入れられないか。
--hook-script=hoge としたらhoge内のなんとかhookをevalする(単純にやるとダメかも?)
- tipsの蓄積に協力する
- これまでの分をoutputする。対して何もないけど。
- myrurema で電脳Ruby関係ドキュメントを読めるようにする。
- ドキュメントの変換作業などが必要。
- pryと組み合わせれば、かなり便利になるはず。
- pry上で . rurema NumRu::GPhys::IO とかやると、IOに関するドキュメントがずらーっと出るようになる。
- . rurema GPhys::IO でもいけるはず(文字列がマッチしたら候補が出る)。
- モデルとして使う具体的予定はないが、ドキュメントの整理くらいは手伝いたい。
- 例えば:
- LaTeXから生成されたpdfの数式がはみ出してるのを直す
- 記述が足りないところ/要確認となっている所を補う
- 単純に数式のフォローをして勉強する。
- 古い世代のパラメタリゼーションスキームくらいを一通り把握したい。
- ドキュメント環境を見直す
- Webのドキュメントが古いので直す。
- uwabami さんが中身を分離作業中らしい。
- 電脳ユーザにはいまやPerlよりRubyの方が親しみがあると推定され、
読み書きできる人口が多いと思われる。
- 更新時に送信されるメールの本文に軽微な不具合がある
(データベースを操作された人が操作したことになっている)が、
これすらだれも修正しないほど、誰にもメンテする気力が(?)ないようだ。
- いっそのことRuby化してしまうのが良いだろう。
- 構造の見直しにもつながる
- ついでに周辺ツールのpostfix対応(というかqmail依存脱却)
- 電脳dcmodel公式版は、1.8じゃないと動かなかった。
- Ruby 1.9対応版を作成: <URL:./Makefile.ruby19>
- 文字列エンコーディング周りがネックで、怪しい。
- CamlCaseをやめた。
- 部分的に縦に短くした。
- 1.8だと動かない。
- 1.8, 1.9の両方で使えるMakefileの作成はそれほど難しくないが、余裕があればやる。
- dcmodelへのフィードバックはそのうち。
- dcreal-photo.rbなど、他にも1.9対応が有用なものがあるはず。
- 共有資源のはずが、所有グループが個人になっているとか、よくある。
- 自動検出するスクリプトを作る(これは簡単。誰かやって欲しいな)。
- mksigenフォーマットに沿っているかどうかのvalidationを行うスクリプト(mksigenのオプションにある?)。
- とりあえず理解したい。
- 現代版(ptexlive対応? 具体的にはどの処理系?)が必要であれば試みる
- 基本的にpdfであればそれでいいのだが、ハイパーリンクがないと悲しい。
- 各種ノートのpdfが一つのディレクトリ以下にsymlinkで集積されていると、転送が楽。
- FDEPSやGFDセミナーのスライド類も、公開可能な範囲で一緒に集積されていると楽。
- 「WWWがあれば参照できる」から「電子書籍リーダがあれば参照できる」へ。
- 電子書籍リーダとしては, Kindle/iPad/iPhone/Androidケータイ/Windows Phone/Sonyのなんとか/Sharpのなんとかなど。
- FreeBSDのパッケージングフレームワーク内のtexlive
- texliveは公式には取り込まれておらず、今のところ、portshakerを用いたportsのoverlayシステムを利用して管理されている。
- コマンドフルパス化のパッチを送って取り込まれた。
- " ", "(", ")"などを含むファイル名を正しく取り扱えるようなパッチを送って取り込まれた。
- エラーメッセージの抑制パッチを送って取り込まれた。
- パッケージ削除時に削除対象ディレクトリの列挙漏れを防ぐパッチを送った。
- portshakerでsvnリポジトリのbranchを切るなどして、ptexliveも同じフレームワークで扱えるようにしたい。
- portshakerの仕組みの把握
- ports collectionのtexliveリポジトリの上に更にptexliveパッチをoverlayできるか?
- portshakerのリポジトリ間に依存関係が持たせられるかは知らない
- BSD#(mono(Microsoftの.NETフレームワーク互換処理系))を使ってport skeletonを生成しているようだ。
- tlptexliveのFreeBSD向けバイナリのビルド
- 今のところ、今年頭くらいから、継続的にやっている。
- ある程度自動化した方がいいかもしれないが...
- メンテナになってるportsを更新
- その他のportsも、興味あるやつで古いのはsend-pr(1)していきたい。
- 一部はrubygem化、他にもrubygem化されていない有用なものを新規作成。
- xfce4-netload-plubginもad-hocにはコンパイルできるようにできるが、
なんでうまくいってないかがよくわかってない。
- cuda-mode.el
- textproc/ruby-mode.el が portmaster で更新できない作りになっているので、なんとかしたい。
- コンパイルできるようにした人がいるみたいなので試してみたい。
- ssh-agentとXFCE 4.8の関係(gconfの使い方)
- hal関係(日記にものすごくたくさんアクセスがあるので、きちんとまとめておく)
- ZFS関係(普段づかい、トラブル対応など)
- どうもLinux emulationでできる(?)みたいな記述も見るが、よくわからない。
- llvm関係のコード公開で新しい展開があるかもしれない。
- 公開可能なブックマークを整理して公開。
- はてなブックマークで適当にブックマークしている。
- 既存のものの公開は進んでいない。
- これまでの各種活動実績を詳述する。
- そこそこ詳述したが、ファイルを分けるなり、何か工夫をしないと読みにくい。
- ~/についてはそこそこできているが、各種計算機のdotfile、/etc,/usr/local/etc レベルではまだ管理できてない。
Last modified: 2012/05/12 (村上真也), Since: 2012/02/17 (村上真也)