Gitでハードリンクしたファイルを管理するのはやめたほうがいい

たぶん、checkoutしたときなどにファイルの上書きが起こって、そこでリンクが切れてしまうということなのだろう。いつの間にかリンクが切れてた。

シンボリックリンクだとメタ情報がコミットされるだけだし、ハードリンクだといつの間にかリンクが切れる。やっぱり、リンクとgitを組み合わせて使うのは良くなさそう。

サブモジュールとかいう機能を使うのと面倒くさくなりそうだし、どうしようかなー。

django.db.utils.ProgrammingError: relation "auth_group" does not exist

Djangoで、manage.py test をしたら、

django.db.utils.ProgrammingError: relation "auth_group" does not exist

とかいうエラーになって困った。開発環境のmacの上では起こらないんだけど、Ubuntu Server14.04で起こる。データベースはPostgreSQL。

何だろうっていろいろ調べたけど、ここが答えをくれた。 次のように言ってる人がいた。

Did you run python manage.py makemigrations appname first, where "appname" is the name of the app containing your custom user model inheriting from AbstractUser?

AbstractUserを定義しているappnameを指定して、makemigrationsをしたら解決。モデルがちゃんとつくられていなかったみたい。そういえば、DBをflushした後、これを実行するの忘れてたかも。

migrationのテーブルに不完全なデータしかない状態で、テスト用のテーブルを作成しようとしてエラーになっていたということだろうか。

外付けUSBメモリをexFATでフォーマットしたらタイムカプセルできなかった

MacBookのディスクに空きがなくなって困ったので外付けのUSBメモリを買った。親指の爪くらいの小ささで、出っ張らないやつを挿しっぱなしにする計画。

で、外付けUSBのフォーマットについてなんだけど、USBメモリはデフォルトではFATで、これだと大きいサイズのファイルを扱えないかった。exFATにフォーマットしたら、Windowsパソコンともデータを共有できていいんじゃないかと思った。いまはVirtualBoxの中にしかWindows入ってないけど、そのうちWindowsのパソコンも買うかもしれないから、そのときに便利なようにという配慮。

しかし、exFATにはタイムカプセルでバックアップをとれないという落とし穴があった。バックアップはとっておきたい。小さなUSBメモリは嬉しいんだけど、なんかそのうち壊れたりするんじゃないだろうかって不安になる。

ということで、データを一時的に退避させて「Mac OS 拡張（ジャーナリング）」ってやつにフォーマットしなおすことにした。「Mac OS 拡張（大文字／小文字を区別、ジャーナリング）」というのもあるけど、大文字／小文字は区別しないのが普通みたい。実際のところ、Max OSXでは、大文字／小文字が異なるだけで同じ名前のファイルを作成できない。というわけで、大文字／小文字を区別しない方の「Mac OS 拡張（ジャーナリング）」にフォーマットするのが無難な選択のようだ。

もう再フォーマットはしたくない。けど、USB3.0はなかなか速い。

DjangoでModelFormのカスタマイズ

DjangoでModelFormを使っていて、FormFieldを追加するとき。Modelのinstanceとの値のやりとりをどうしようか迷う。どうやら、初期値はModelFormの__init__()でモデルからフォームに渡してやり、フォームからモデルへの値の変更はModelFormの_post_save()でやるのが良さそう。

理解可能なように説明すると面倒くさいからできそうにない。

class ArticleForm(forms.ModelForm):
 
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.fields["text"].initial = self.instance.get_nice_text()
    
    def _post_clean(self):
        super()._post_clean()
        self.instance.set_nice_text(self.cleaned_data["text"])

という感じだといいのではないか。

django-allauthを使ってTwitterアカウントでログイン

django-allauthを使って、Twitterアカウントでログインする機能を追加しようとしている。いくつか注意点。

django-allauth側の設定としては、settings.pyでの設定と、Webの管理画面でのDBの設定と二つやらないとダメ。管理画面では、social applicationsのとこでサイトIDを忘れずにと追加してあげないといけない。

Twitter側の設定としては、Callback URLを指定していないと、Twitterでログインする機能を利用できないでエラーになる。「Allow this application to be used to Sign in with Twitter」っていうのにチェックを入れていても、それだけじゃダメ。




ちなみに、Twitterにウェブアプリを登録しようとしたんだけど、現時点では日本語ドメインに対応していないみたい。punycodeでもダメ。不正はURLとして扱われる。

Ubuntu14.04でDjangoを複数動かす

Apache2.4のVirtualHost、python3.4のvenv、mod_wsgiのdaemon mode、これらを使った。手順というよりも注意点を書き留めておく。

Ubuntu14.04では、python3のvenvが失敗するという情報があったけど、大丈夫だった。venv（もしくはpyvenv）は、「apt-get install python3.4-venv」でインストールしないといけない。
venvが失敗するというのは、ensurepipモジュールが欠けていて、pipがインストールされないとのことだった。その場合に、手動でpipをインストールすれば良いとかいう情報もあった（手動でpipをインストールした場合、apt-getからインストールしたpython3-psycopg2とかpython3-lxmlとかへのパスが通っているのかは謎）。しかし、問題なくvenvを実行できた。

仮想環境をつくるときは、pyvenvではなく、python3 -m venv を呼び出すクセをつけておいた方が良さそう。複数のバージョンのpython3が入っている場合に、どのpython3を使ってvenvを実行するのかで、仮想環境で使うpythonのバージョンを選択できるからだ。pyvenvだとこれができない。

とはいえ、mod_wsgiを動かすpythonのバージョンを細かく指定することは、たぶんできない。だから本番のサーバーではpyvenvを使おうがvenvを使おうが同じことだ。

仮想環境をつくるときは、「python3 -m venv --system-site-packages --symlinks 仮想環境ディレクトリへのパス」という具合にオプションを与えておくと、activateしたときに、mod_wsgiを動かすときに近い環境になるはず。--upgradeを付けとけば、失敗してもやり直せる。（--upgrade なしでもやり直せそう。あと、--symlinks はデフォルト値だから省略していい。）

activateするには、「source 仮想環境ディレクトリへのパス/bin/activate」。 activateした後でsudoすると、環境変数が上書きされてしまうのでやってはいけない。たとえば、activateした後で「sudo pip install django」とやると、デフォルトのpython2のsite-packagesにdjangoがインストールされてしまう。そうならないように「sudo -s」としてから、activateする。で「pip install django」とやれば、仮想環境のsite-packagesにインストールされる。

Apache2.4でBasic認証の設定が効かないで困った

Apache2.4で、Basic認証を設定しようとしたんだけど、普通にアクセスできてしまって困った。Apach2.2では動作していた設定を、ほとんどそのままコピーしたつもりだったのに、何がいけないんだか悩んだ。

Basic認証のために「Require valid-user」と設定したかったのに、「Require all granted」が前の方に書かれていて、これが効いてしまっていたのが原因だった。