gedit 3.14 がいろいろと便利

geditが落ちたりて不安定だったのでしばらくvimを使っていたが, 3.14 が普通に動くようになって久々に戻って来た.

Ctrl + Alt + N で分割

vim でいうところの vsplit ができる. Ctrl + Alt + Shift + PageUp/PageDown で移動.

水平方向は無いっぽい.

git plugin

前からあったような気もする.

git diff の行に印をつけてくれる. 野良の git plugin よりもシンプルで便利.

gedit 3.14 の snippet で Segmentation fault する

Fedora 21 を入れてみたけど, Nvidia で wayland が動かなくてがっかりしている.

もう一つがっかりしたことがあって,gedit 3.14 の snippet が Segmentation fault する.

/usr/lib64/gedit/plugins/snippets/completion.pyProvider.do_get_start_iter で設定しているイテレータが悪いので,

def do_get_start_iter(self, context, proposal, iter):
    return False

としてしまって構わない. gtksouceview3のデフォルトが働くようになる.

pptxをpdfにしてLaTeXに取り込む

PowerPointで図を作って、PDFにしてからLaTeXにすると、拡大してもOKだしテキストがコピペできる感じになって便利。

PDF で出力した後は、PDF Slim でトリミングしていたんだけど、Windowsが更新されてから動かなくなってしまった。 そこで、pdfcropを使う。

pdfcrop --pdftexcmd pdflatex --clip input.pdf output.pdf

なぜかコマンドを指定しないとpdftexになってエラーを吐く。

あとはextractbbでxbbを作成してincludegraphics

extractbb output.pdf

PDFの作り方 - TeX Wiki

スケール可能なプログラムを書くために

卒論・修論の影響なのか、ソースコードの規模が壁になって詰まっている人を最近よく見る。 Web以外の人達にももっと MVC の考え方が広まってほしいなぁ。


一定の規模を超えると、ファイルを分割したりする必要があります。 しかし、そのステップはなかなか険しい。 特にC++なんかは近代的なファイル分割の方法が無いので、 結果として、ファイル分割をあきらめて縦に長い main.cpp ができるか、 かえって面倒な設計になってしまうのではないでしょうか。

プログラミングをするといっても、数値計算やシミュレーション、ゲームなど、様々なアプリケーションに対して様々な設計が考えられます。 ただ、その中でも、Webアプリケーションはかなり作り方が完成されているように感じます。 Model と View と Controller に分ける MVC の考え方は、Webのエンジニアにとっては常識と言って良いでしょう。

元々、MVC は UI をもつあらゆるアプリケーションに対して考えられたもので、*1特に Web アプリに限られたものでもありません。 例えば、CUI のアプリケーションでも UI は UI であって、例えば引数をパースする部分を Controller と見ることができます。 内部でも持つデータは Model で、ファイルやコンソールに書き出す部分が View。 MVC に分離するという考え方は、Webだけでなくもっと多くのプログラミングをする人に知られて良いノウハウだと思います。

そして、 俺が勝手に考える正しいMVCの実装。モデルはデータAPI! - はかますたいる! に書かれているように、 Model を太らせるとなかなか良い感じになるのではないでしょうか。 Controller は Model を操作しなくてはいけないので Model に依存しています。 View も Model を表示したいので、Model に依存しています。 Model は Model 単体で成立することが多いので、テストがしやすく、 オセロの確定石のように安定した部分を作ることができます。 それに比べて、見た目や入力方法なんてのはコロコロ変えたくなるはずで、 入力や表示以外の本質的な部分が Model に書かれるはずです。

Model の肥大化は、パターンによって回避することができます。 特に巨大なコンストラクタは、生成に関するパターンとしてまとめられています。 他にも、Iteratorパターン等は、View や他の Model に、 その Model をどのように扱ってもらうかに利用したりできます。

Web に限らず、Model をしっかり作るということは、 ソースコードの大規模化に対応する一つの対処法だと思います。

  • MVC という考え方はWebアプリ以外でも強力な考え方
  • Model を太らせるというのも同様に通じる場合が多そう
  • デザインパターンでさらに具体化すると良さそう
  • 少なくとも Model ぐらいはテストしよう

Ubuntu Server で wsgi を使うと SetEnv が効かない

Djangowsgi.py は、

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")

となっているので、 Apacheの設定で

SetEnv DJANGO_SETTINGS_MODULE mysite.settings.prod

って感じに本番環境と開発環境でsettingsを切り替えるというのは、結構よくある手段だったと思う。

しかし、Ubuntu Server 14.04で wsgi-py3 を使うとうまく動かない(2系の方は試してない)。 http://stackoverflow.com/a/9017610 に書いてある通り、 環境ってのはリクエストごとにあるべきであって、起動時に環境変数を読むっていうのはなんか変ってことで、リクエストが来る前の環境変数は特に設定されなくなってしまったらしい。

仕方がないので wsgi.py をシンボリックリンクにして、サーバ側で用意することにした。 AnsibleとかChefのテンプレートでサーバごとに生成すると、開発環境・テスト環境を分けやすい。

DebianのAnsibleにMySQLを入れる

DebianにAnsibleを使って単に apt: pkg=mysql-server state=latest とかすると、 root でログインできなくなる。

debconf を使うと初期パスワードが設定できるのでそれを使ってからインストールする。

- name: MySQL | Set debconf vars
  raw: echo mysql-server mysql-server/root_password password $mysql_root_password | /usr/bin/debconf-set-selections
- name: MySQL | Set debconf vars
  raw: echo mysql-server mysql-server/root_password_again password $mysql_root_password | /usr/bin/debconf-set-selections

英語で探すとすぐ出てきたけど日本語ではあんまりなかったので。