(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には「レイヤ」という機能があり, 複数の図形をレイヤに配置して表示・非表示などを操作できる. そしてファイルからあるレイヤだけを取り出して, ひとつのinkscapeのファイルから複数の絵を取り出すことが出来る. 手動であるレイヤだけを表示してから保存すれば 保存すればそのレイヤだけが保存されるが, 10個もレイヤがあると手動でやってはいられない. 関連する機能としてコマンドラインから

        inkscape 入力ファイル --export-plain-svg -o 出力ファイル --export-id=ID --export-id-only

  というコマンドで, 特定のIDを持った図形やグループだけを取り出したファイルを 書き出す機能があり, 書き出したいレイヤのグループIDがわかれば, 一レイヤだけを取り出すことも可能だが, 書き出したいレイヤのグループIDはファイルの開いてみないとわからない
• 変更案説明:
  • 「レイヤを保存」のようなメニューで, 全レイヤを (一レイヤを一ファイルに)書き出す機能を実装する, または
  • コマンドラインに, --export-layer nのようにして, n番目のレイヤを書き出せるようにしたり, --export-all-layersのようにして, 全レイヤを書き出せるようにする

• 対象: inkscape
• もともと何をするソフトか: 描画ツール
• 背景説明: inkscapeにはレイヤという機能があり, 複数の図形をレイヤに配置して表示・非表示などを操作できる. そしてファイルからあるレイヤだけを取り出して, ひとつのinkscapeのファイル から複数の絵を取り出すことが出来る. この機能は, 少しずつ異なった絵をいっぱい書くときなどに重宝する. 例えば四角形が徐々に増えていくアニメーションなどをする場合に便利. しかし現状の欠点として, ある図形は一つのレイヤにしか所属できない. したがって四角形が徐々に増えていくアニメーションを書きたければ, 最初からある四角形は全レイヤに書かなければならない. コピーすればよいのだが, そうすると後からそれを変更したり, 動かしたくなったときが大変なことになる.
• 変更案説明: 図形はひとつで, それが全レイヤに表示される, という機能を実装する. またはより一般化して, レイヤ$n$に作ったオブジェクトを, 別途指定したレイヤにも表示する(存在しているかのように扱う)機能を 実装する. パワーポイントなどでアニメーションをするときに, あるタイミングから表示されて, あるタイミングで消えるみたいなことが できるようにする

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

• 対象: Mojo
• もともと何をするソフトか: プログラミング言語
• 背景説明: MojoはほぼPythonの文法を保ちつつ高速を売りにした言語. 田浦はそれ以上の経験・知識はありません. Pythonでなにかやってみたい, けど定番と言われちゃった... という向きはMojoにふれる機会だと 思ってとにかくやってみるとよいかも(演算子の追加でもOK)

• 対象: 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というツールを使えば， 簡単に行えるので，実質的にはターゲットと， 依存関係をテキストファイルとして出力すればよい．

• 昔は本当にほしいと思っていが今はZoomにつないでねといえばしまい な時代になったのでややdeprecated. ただしすべてをクラウド経由にしたくない, という話は今もある
• 対象: Remmina
• 元々なにをするソフトか: デスクトップ共有クライアント
• 問題の背景: デスクトップ共有(remote desktop)は 他の人と画面を共有できる便利な機能. Ubuntu 標準のデスクトップ共有クライアント(Remmina)では, 複数のマシンと同時につないで複数のマシンの画面を見ることはできるものの, それを多数とやると何かと問題がある. 教員をやっていると学生の進捗把握やハマっているところを発見するのに, 多人数, 例えば教室にいる全員 (例: 30人)と同時に接続できたらな...と思う. このような機能は教室用の専用ソフトウェアの機能としてしばしば実現されているが, これを普通のデスクトップ共有機能の機能にできたらよい.
• 変更案説明:
  • クライアント(人の画面を見る方, 例えば教員)が, サーバ(見られる方, 例えば学生)の IPアドレスを指定して繋がないといけないので, 多数とつなげようと思うと 手間がかかる. 操作を逆にして, サーバ(学生)がクライアントを指定して繋げると, 画面が共有される, という操作モードがあると良い
  • 発展2: 確認していないがおそらく, Remminaでは, クライアントがサーバの画面を表示していようといまいと, 画面情報が常に通信されている. これでは多人数と快適に接続を保ち続けるのは恐らく困難である. (実際やってみると, しばしばRemminaが再起不能になる)
  • 発展1: 首尾よく全員に接続できたとしても, それらは異なるタブに表示されるので全員の画面を一望できない. 教室用ソフトでは, サムネールのような, 縮小画面(動画)で多人数の画面を一望できる
この内のどれか一つでも問題が解決できれば素晴らしいし, もしRemminaにそのような機能がない(上記のような別のソフトウェアもない) となったら, 取り込まれる可能性もあるのではと個人的には思う.

• 対象: Remmina
• 元々なにをするソフトか: デスクトップ共有クライアント
• 問題の背景: デスクトップ共有は別のコンピュータの操作を手元でできるようにするためのソフト．そのために，Remminaが受け取ったキー入力を，相手のコンピュータに送り込むということをしている(はず)．
• しかし，一部のキーはホストに処理される．たとえばRemminaの画面にフォーカスがあたっている状態で，Alt-Tab (ウィンドウの上下入れ換え)を押してもそのキー入力は相手コンピュータには伝わらず，手元のホストで処理される．したがって，Remminaではない，別のアプリケーションが前面に移ってきてしまう．この動作が望ましいこともあるが，望ましくない(リモートコンピュータのウィンドウをAlt-Tab切り替えたい) こともある．
  実はRemminaには，「全てのキーをキャプチャする」という動作モードも存在する．これを選んでおくと，所望の動作になる．しかしこうすると本当に全てをキャプチャしてしまうので，今度はホスト側で別のアプリに切り替えたいときにマウスに手を伸ばす必要が生ずる．これは耐え難い．
• 変更案説明: そこで，「指定したキーはキャプチャしない」という機能をRemminaに付け加える．
• 一ユーザとして想定している利用場面は以下の通りで出来たら本当に嬉しい．
  • Remminaの画面は別のワークスペースに動かした上で全画面表示
  • Remminaと他のアプリの切り替えはワークスペースの切り替えキーで行う (UbuntuのUnityでは，Ctrl-Alt-矢印. このキーはRemminaにキャプチャさせない)
  • Alt-tabはあくまでリモートのコンピュータ内 でのウィンドウ切り替えに使う
• 捕捉: 「今度はホスト側で別のアプリに切り替えたいときにマウスに手を伸ばす必要が生ずる．これは耐え難い」と書いたが，「全てのキーをキャプチャするか否か」をキー(右Ctrlキー)でトグルできるので， 右Ctrlキー -> Ctrl-Alt-矢印 というキーシーケンスでホストに戻ることは，可能といえば可能である．右Ctrlキーを押すのはひと手間であるし，なにをキャプチャしたくないかは場面によっても異なるので，一部のキーだけをキャプチャしないでおけるという機能は，それなりに有用ではないかと思われる．

• 対象: bash (他のシェルでも良い)
• もともと何をするソフトか: コマンドを実行する
• 背景説明: bashには以下のようなfor文が備わっている．

  for x in .... ; do
    cmd1
    cmd2
    cmd3
    ...
  done
  

  { cmd1; cmd2; cmd3; ... }を，... で指定された文だけ順に実行する．
• 変更案説明: for文と同じシンタクスで， pforという，並列for文をサポートする． { cmd1; cmd2; cmd3; ... }を，並列に実行する．ただし， 同時に実行されるコマンド数が一定(環境変数で指定した数 や搭載コア数)になるように制御する．
• 補足: 2018年に取り組まれた

• 対象: Linux
• もともと何をするソフトか: OS
• 背景説明: Linuxは複数のプロセスを同時に実行するために，スケジューラという仕組みを備えている．すべてのプログラムはタスクという単位で扱われ，複数のプロセスを"適当"なタイミングで切り替えながら実行する．この切り替える優先度が高いものほどCPUで実行される時間が長くなり，より短い時間で処理が終わることになる．
• 変更案: プロセス名によって優先度を変えてみる．そのために，まず/proc/sys以下にファイルを置き，linux内の情報を取得できるようにすることになるだろう．