(the page is encoded in UTF-8)

以下は，何かソフトをいじれ， と言われてもよくわからないという人のためのとっかり． 「自分はこれだ」というのがある人は， 見る必要はありません

まずは自分が普段使っているソフトを思い出してみると良いだろう．そういうソフトであればある程度機能も把握しているだろうから，どのような変更をする余地があるのか，どうすればうれしいのかもイメージしやすい．

• ブラウザ
• シェル
• よく使うコマンド群(ls, less, grep, sort, ...)
• エディタ
• コンパイラ
• オフィス系
• ドローソフト
• 音楽録音・再生
• 動画録画・再生
• 静止画
• ゲーム
• ...

「Ubuntuソフトウェアセンター」を立ち上げると， パッケージでただちにインストールできる ソフトウェアの要約を見ることができる． 眺めるには時間がかかるが広範な選択肢を， その要約と共に見られるので， 貴重な情報源である． 自分が，名称を知らずに使っていたソフトの名称 がわかることもある．

迷ったら，コンピュータの根幹と言って良いソフトたち， に戻ってみるのはいいかもしれない．

• プログラミング言語: 例えばスクリプト言語などで， 使ったことがあるものがあれば (Python, ruby, javascript)それをいじってみる
• オペレーティングシステム: Linux, FreeBSDなど， ソースが公開されているOSを探求してみる(上級者向け)
• データベース: SQLite, MariaDB, Postgresqlなどが， フリーソフトとしては有名だが， ソフトの規模，取り回しの良さという意味では SQLiteが圧倒的にシンプルでオススメである． すでにデータベースを使ったことがある，という 人以外にはSQLiteを推奨する．

Linux popular softwareなどのキーワードで検索すると， 人気のあるLinuxソフトが出てくる．

なにか，そのソフトにふさわしい機能拡張が思いつ けばこんなによいことはないが，それなりの蓄積の あるソフトウェアに対していきなり新規参入者が簡 単に思いつけるものでもない．

とっかかりとして，いくつかのよくある方向性を示唆しておく (あまり選択肢を限定するのが本意ではないので，あくまで 煮詰まった時，あるいはとっかかりとして利用して下さい)

• 巨大データを扱えるようにする. 例えばス プレッドシートなどデータを扱うプログラム や，グラフの描画など，データがでかくなる といかにもきつくなりそうなプログラムを対 象に，その限界を高めるような工夫を行う．
• 高速化．言語処理系，データベースなどの 基盤系ソフトウェアや，画像処理，動画処理 などマルチメディア系のソフトウェアを高速 化する．ただし，そもそもどこをいじったら 高速化するか自体が大きな探求になるので， 結果的に速くならなくても，ボトルネックを 見つける事自体に価値を感じながら臨むこと が必要かもしれない．
• 並列化．高速化の中でも，複数のCPUを使っ て処理を並列化するのは，もしその仕組みが 既に実装されていなければ，そこそこの成功 率が見込める高速化である．
• 好きなソフト．普段使っている，愛着のあ るソフトウェアであれば，欲しい機能を思い つくのは比較的容易かも知れない．
• バグチケット: バグのないソフトウェアは 存在しない．多くのオープンソースのソフト ウェエアプロジェクトはバグを公開し，担当 者をアサインするための，バグチケットシス テムを持っている．そのようなチケットシス テムに書かれているバグを見つけて，治そう と試みる．地味だがうまくいけば重要な貢献 ができるかも知れない．
• 自動操縦．主にGUIを想定して書かれてい るアプリケーションを，プログラムで操れる ようにしてみる．例えば，お絵かきソフトで， 100個のオブジェクトを整然と配置させると か．ただし，実際には多くのソフトが，マク ロと呼ばれる機能で似たようなことを実現し ているので，機能的に見劣りしないものを作るのは難しい．
• Google Summer of Codeとかで， 進行中のプロジェクトの実例を見てみる． ただし，聞いたこともないソフトに関する記述を見ても， よくわからないかもしれない．

ブラックリストというのは多少言い過ぎで, ブラック(なソフトの)リストというくらいか. これらを選ぼうとする人に「やめろ」というのが目的ではありません. これらを選ぶ人に, 一応過去苦労した人がいるということを伝えておく (選ぶときはわかって選んでね)のが目的です.

主な苦労の元は, 普通にビルドするだけでも苦労する・時間がかかりすぎる, ということで, つまりは本題のスタートの前に随分時間がかかって, 敗北感が生まれてしまうというものです. 過去のレポートを見てビルドの手順を真似することで, 軽減される可能性も大いにあります. そのような観点から情報を提供します.

そもそも本課題のテーマは, 全容を把握しきれないソフトに立ち向かう方法ですから, 大きすぎる・複雑すぎるので苦労するからもっと 簡単・単純なソフトを選びましょう, ということにこだわると目的を見失うという説もあります. したがって自分がそれに立ち向かう勇気(やる気)があれば, 大いに選んでもらってよいのですが, なにしろわずか数週間の課題ですから, あまり本題と関係ないところで時間をかけすぎると充実感が失われ, 敗北感が残ってしまうのも確かです. そのような観点から, 過去におきたことの知見として記します.

• Libreoffice 過去の例1, 過去の例2
• Mozc : 過去の例 : Google様のソフトで, ビルドの手順などが独創的(独尊的?). もしかするとMac OSでやっていたことで災いが悪化していた可能性も
• Chromium 過去の例 Google様である上, 巨大. ビルドに時間がかかりすぎる.

やや, 「定番」化してしまった感のあるソフト. これを選ぶなという意味ではないし, これを選んだ先人(特に初期の開拓者)をdismissする意図ではありませんが, 周りをぎゃふん(死語)と言わせたければ他を選んだほうがいいかなと思われるもの

• Pythonに演算子や構文を追加する. Pythonにお世話になっているのでPythonをいじってみたいという向きは, Mojo, Julia などに手を出すことを考えてみては? 同じPythonでも演算子や構文追加以外の方向を考えるのは十分ありです.

• 対象: inkscape
• もともと何をするソフトか: 描画ツール
• 背景説明: inkscapeには「レイヤ」という機能があり, 各図形 (円, 四角など) はどこかのレイヤに所属している。レイヤごとにファイルを保存する機能もある。これは, スライドにアニメーションを入れるのに重宝する. アニメーションというのはつまり, 少しずつ異なる絵をいっぱいつくるということで, 結果として同じ図形が多数のレイヤにコピーされる. コピーしてから調整したくなったりすると orz となる。
• 変更案説明: inkscapeにはオブジェクトを選択して同じ場所にコピーするという機能, 特定の一レイヤに移動するという機能はある. これを, 「複数のレイヤに」「コピー」できたら, inkscapeで汗水流してアニメーションを作る人の生活は多少楽になる
• 本当は「コピー」せずに, 一つの図形オブジェクトのままそれらのレイヤに「表示」 (つまり, その後の変更も全レイヤに反映される) できればなお良い (保存するときだけ各レイヤにコピーされるイメージ)が, おそらく変更は多岐にわたることになるだろう
• 本当はこれでもマニュアル感は否めず, アニメーション作成においてはPowerPointのようなプレゼンソフトに一日 (百日?) の長があるのは否めない. 本当はそういうプレゼンソフト風のUIを実現できるのが一番良いのだがこれはきっともっと大変

• 対象: typst
• もともと何をするソフトか: 組版ツール
• 背景説明: typstという組版ツール (texのようなもの) で図を取り込むには

        #image(ファイル名)      
  

  とするが, これは独立した図として「段落」のように表示される. 一方 html や tex には あたかも文の中の一文字のような感じで, こんなふうに図を表示することもできる. 文の中にさりげなくイメージを滑り込ませたいときに便利.
• 変更案説明: typstでもそれができるようにする

• 対象: Julia
• もともと何をするソフトか: プログラミング言語
• 背景説明: JuliaはPythonのような対話的なプログラミングが可能, 型の指定が不要でありながら, Just-In-Time (JIT) コンパイルによって高速な実行が可能 な言語 (Just-In-Timeコンパイル：大雑把に言えばある関数が初めて 呼び出されたときにコンパイルされる. その際に, 渡された引数の 型に応じて最適化されたコードを生成してくれる). しかしその性質上すべてのコードはコンパイルされながら実行されるので, どんなプログラムでもコンパイラが必要とするメモリ(100MB近く)や, コンパイルのための実行時間を要する. これをなんとかしたい
• 変更案説明(以下は一例です):
  • 軽量コンパイルモードの導入： あまり最適化をせずに, 極力コンパイルの回数や時間を最小化するモードを導入する. そういうコンパイラを一から作るのはこの演習の時間内では困難と思われる. Juliaは内部でLLVMというコンパイラを呼び出しているのでその呼び方を調節する程度を想定. ただしこういう機能はすでにundocumentedな機能として存在している可能性もある. そうなったらそうなったで目標を変更すれば良い
  • コンパイル時間などの詳細を表示する機能の追加. これも始めから存在している可能性がある
  • コンパイルしないモードの導入. 「軽量コンパイル」のさらに軽量版というつもりだが, これはJuliaがいったんコンパイルしてから実行, という方式を強く前提としていた場合にはおそらく難しい
  • Ahead-Of-Time コンパイルモードの導入. 始めから (指定された型で) 全部コンパイルしておくモード. ただし現状のJuliaの処理系にそれを入れ込むことは困難な可能性もある. 似た機能はすでにある ようなのでこれの問題点があれば改良する

• 対象: SQLite command shell
• 元々なにをするソフトか: データベース
• 問題の背景: SQLiteは手軽な(1データベース=1ファイルで, サーバなしで動作する)データベースソフトで, プログラムから手軽に 呼び出せる(C APIやPython APIなどがある)他, シェルから呼び出せるコマンド(sqlite3)もある. 以下のような感じ

  $ sqlite3 foo.sqlite
  SQLite version 3.22.0 2018-01-22 18:45:57
  Enter ".help" for usage hints.
  sqlite> create table foo(x,y);
  sqlite> insert into foo values(1,2);
  sqlite> select x + y from foo;
  1|2
  

  ちなみにPythonの場合は以下のような感じ.

  >>> import sqlite3
  >>> co = sqlite3.connect("bar.sqlite")
  >>> co.execute("create table bar(x,y)")
  >>> co.execute("insert into bar values(1,2)")
  >>> co.execute("select x + y from bar").fetchall()
  [(3,)]
  

どんなデータベースでも, stored procedureとか, user defined functionなど, データベースクエリ(select文)中で 呼び出せる関数を定義する機能がある. しかしSQLiteでは, CやPythonの API経由でならuser defined関数を定義できるのに, コマンドラインでは出来ない. 例えば C API でなら sqlite3_create_function , Python APIなら, create_function
• 変更案説明 sqlite3コマンドラインから, PythonやC言語で定義されたユーザ定義関数をロードできるようにする. イメージ図 (詳細はC, Python API呼び出しに容易に変換できるよう仕様を決めれば良い)

  sqlite> load_udf fun.py ...
  sqlite> load_udf fun.so ...
  

• 対象: gnumeric
• もともと何をするソフトか: 表計算
• 背景説明: 表計算で扱えるデータの大きさには制限がある．
• 変更案説明: 一つのワークシートに収められるデータ(行と列のサイズ)の上限を調べ， 極力その制限を緩和する．メモリを節約できるような表現形式を 考えても良いし，ファイルの内容全てをメモリに保持しなくても 動作するようにできれば素晴らしい．

• 対象: make
• もともと何をするソフトか: 依存関係にもとづいてコマンドを実行する
• 背景説明: ソフトウェア構築に必ずと言っていいほど使われるmakeは， ターゲット(通常はファイル名)とその依存関係をMakefileから読み取り， ファイルの存否および更新日付にしたがって，実行するコマンドを決定する． オープンソース・ソフトウェアをビルドする時，makeと叩くだけで 多数のコマンドが実行されるのもこの仕組みによる． 一方，昨今のオープンソースプロジェクトは， configureによって，ほとんど人間には解読不能な 巨大なMakefileを生成する．そのため，makeを実行した時に なぜか予期しないコマンドが動作してしまうような場合， その原因を探るのは非常に難しい．
• 変更案説明: makeにオプションを追加して，ターゲット間の依存関係と， ファイルの更新日時などを，グラフ構造として視覚化できるようにする． なお，グラフの可視化はgraphvizというツールを使えば， 簡単に行えるので，実質的にはターゲットと， 依存関係をテキストファイルとして出力すればよい．