オープンソースカンファレンス2018 HokkaidoでDjangoの紹介をしました

7/7にオープンソースカンファレンス2018 Hokkaidoに行ってきました。

www.ospn.jp

北海道のOSCにはここ数年は参加し続けてますが、セミナーや展示の数も多く、毎年楽しめてます。

今回もdjango-ja名義でDjangoフレームワークの紹介をしました。資料は去年のものをアップデートしたものです。

スライドとサンプルコード

speakerdeck.com

github.com

Python札幌の勉強会

翌日にはPython札幌の勉強会で、Djangoチュートリアルを手伝ってきました。

python-sapporo.connpass.com

質疑応答もしっかりできたのでよかったと思います。

PythonでQRコードのSVGを生成する

PythonQRコードSVGを作るには、qrcodeモジュールを使えば簡単でした。

pypi.org

Python3.6で試しました。

pip install qrcode

SVGPNG(pymaging-png)はPure Pythonのモジュールだけで生成できるようです。

PILでPNGを生成させることもできるようです。

main.py:

import qrcode
import qrcode.image.svg


def make_qrcode_svg(text):
    # 拡大したときに余白が入らないようにする場合はSvgPathImageを使う
    return qrcode.make(text, image_factory=qrcode.image.svg.SvgPathImage)


def main():
    img = make_qrcode_svg('https://example.com/')
    with open('test.svg', 'wb') as output:
        img.save(output)

if __name__ == '__main__':
    main()

f:id:nullpobug:20180626232214p:plain
生成されたSVGChromeで拡大表示した

昨今のWebブラウザはSVGを表示できるので、これで十分かな。

DjangoCongress JP 2018に参加しました

DjangoCongress JP 2018にスタッフとして参加しました。

djangocongress.jp

Djangoフレームワークのみをテーマとした100人以上の規模のイベントは、日本では初めてだったように思います。

半年前から準備してきたイベントですが、無事終了できてよかったです。

会場

サイボウズ株式会社さまが無償で提供してくれました。かなり余裕のある広いスペースで、Wifiも快適でしたので、良かったと思います。ありがとうございました。

サイボウズではエンジニアとつながるイベントを開催しているそうです。

cybozu.connpass.com

開催の準備について

  • 月1回程度、集まって作業、それ以外は各自進められることを進めた
  • やることを極力減らせたので、開催直前の準備も持っていく荷物をチェックする程度ですぐに終わった
  • CfPへの応募が予想以上に多く、選定はすごく悩んだ
    • DjangoCongressでしか発表の場がなさそうな内容をなるべく選んだ
  • Webページを早くから公開できてたのはとても良かったと思う
    • 海外や遠方から来る人が準備できるよう、遅くとも3ヶ月前には確定情報を出せるように気をつけた

講演内容について

  • 全体を通して質が高く、ボリュームもあってすごく良かったと思います
    • 12枠全部聞きたいレベル
    • すべての枠が45分と長めなので、深い内容になっていたのかな

感想

  • やりきった感
  • 会場に入ってから受付開始までの準備が30分、撤収も30分ほどで終わったので、スムーズでとてもよかった
  • スタッフの人数もそこそこいたので、1人の負担が少なくてよかった
  • Twitterハッシュタグが盛り上がっていたのを眺めるのも楽しかった

来年以降は、今年の各種テンプレートを使い回せるので、もっと楽にできるかなと思います。

Python入門者向けハンズオン #pynyumon にメンターとして参加してきました

Python入門者向けハンズオンにメンター枠で参加してきました。

python-nyumon.connpass.com

会場

Retty株式会社のオフィスが会場でした。綺麗で広くてよかったです。

メンターをやってみた雑感

個人的には、Djangoの初心者向けハンズオンをそのうちやろうと思っていて、ハマりどころなど知識のアップデートが目的の1つでした。積極的に歩き回って、困っている人がいないか見るようにしていました。

最近はcondaやpyenv、WSLなど、Pythonのインストール方法も広がっていて、提供されたチュートリアルドキュメントの手順通りで動かせないパターンがあったりするのだなと知りました。サポートするときの参考になりそう。

MacBookAir(Xubuntu)の無線ルーター化の件

会場の都合で無線LANが提供不可となったそうで、モバイルルータなどを持ち寄って対応することになりました。

テザリング用の端末を持っていない人にもインターネット接続環境を提供すると、モバイルルータだけでは性能に不安がありそうだったので、Linuxをインストールした端末を無線ルーター化して持っていけないか考えました。

やったことはないけど、モバイルルータとPCの無線ルータ化でインターネット接続を提供する事例をどこかで見たことがあったので、「できそうならやってみるかー」ぐらいの気持ちで調査して試したらうまくいったので持っていって使いました。5~6台つないでみたけど余裕っぽかった。iptablesでパケット転送の制御を設定してるので、モバイルルータが複数台あれば、IPアドレス範囲を区切ってそれぞれに流すのもできそうだし便利。

f:id:nullpobug:20180515223432p:plain

詳細はまとめませんが、ハマった点や参考にしたページなどを自分用にメモしておきます:

  • インストールしたパッケージ
  • 手元にMacBookAir(Core2 1.4Ghz)があり、Xubuntu 16.04がインストール済みの状態だった
  • Ubuntuiptablesufwのラッパーのようで、ufwを有効にしないと動作しなかった。
    • ipv4のforward許可はufw側の設定も必要だった(DEFAULT_FORWARD_POLICY)
    • Ubuntuiptablesはデフォルトだと内容が保存されなくて再起動で消えてしまう
  • NetworkManagerをoffにすると、USBテザリング側のイーサネットのインターフェースが自動で有効にならなくて、シェルスクリプトでコマンド実行する形にまとめた
  • USBテザリング側のインターフェース名がusb0から別の名前に変わる
    • kern.logを見てたらログがあった。そういう機能があるらしい?
  • 接続状況を手軽に確認するにはarpコマンドが楽だった
    • hostapd_cliでつないだけど、欲しい情報のとり方がよくわからなかった
  • 通信できているかの確認はnslookupやpingコマンド

参考にしたページ:

ZenFone 4 Maxを購入した

普段使いのスマートフォンはNexus4でしたが、バッテリーの保ちが悪くなってきたのと、ストレージが足りなくて厳しくなっていたので、機種変更を検討しました。

Nexus4は2013年に1台目を購入し、フロントパネルを何度も修理したりして使ったあと、2年前ぐらいに中古で2台目を購入して使ってました。

今回は予算は3万円ぐらいでバッテリーの保ちが良い端末を探し、ZenFone 4 Max(ZC520KL)に決めました。ヨドバシカメラで2万6千円ぐらい。ポイント使い切って支払は2万円。

f:id:nullpobug:20180511173802j:plain

ASUSZenPadを持ってるので、操作面の違和感はさほどなし。画面サイズが5.2インチで、Nexus4より一回りでかい。ポケットに入れるにはそろそろつらいかな。

アプリ操作中に一瞬画面が暗転したり、ポップアップを閉じる動作のときにチラツキのようなものがあって、少し気になる。

この端末を最低でも3年ぐらいは使いたい。

DjangoフレームワークとVue.js (Vuex)を使ってアプリケーションを作る

以前作成した DjangoフレームワークとVue.jsを使ってアプリケーションを作る - 偏った言語信者の垂れ流し の、Vuex対応版です。

よかったらGitHubでStarをつけてください! github.com controllerとしていた部分を、VuexのStoreに書き換え、Vueコンポーネントも同様にVuexのコードに書き換えました。

どのぐらいの粒度でstateを作成するのか、UI側の表示制御(モーダル表示など)とどう組み合わせるのかなど、参考になれば幸いです。

NGINX UnitでDjangoアプリケーションを動かしてみる

NGINX Unitは、NGINXの開発元が作ってるアプリケーションサーバー。

http://unit.nginx.org/

Pythonのアプリケーションも動かせるとのことなので、Djangoアプリで試してた。

試した環境は、Vagrant上でUbuntu 16.04 LTS、Python 3.6.2(deadsnakes PPA)、Django 2.0.4、NGINX UnitはGithubのmaster(749f7c0)

インストール

ドキュメント通りだとPython3.6用のモジュールが提供されないので、ビルドしてインストールした。

python3.6やpython3.6-develなどはdeadsnakes PPAからインストール済み。

インストール先は、 /opt/unit/ としました。

git clone https://github.com/nginx/unit.git
cd unit
./configure
./configure python --config=python3.6-config
make all
sudo make install DESTDIR=/opt/unit/

※参考にしたページには、virtualenvに対応するためにパッチを当てる旨の記載があったが、masterで問題が修正されたので特に変更なしで動いた。

unitdの起動

オプション指定なしだと起動時のカレントディレクトリにログファイル unit.log が作成される。また、カレントディレクトリから相対パスで拡張モジュールを探しにいくので、 --module で指定したほうがよさそう。

今回はUbuntuへのログイン時のユーザー vagrant で起動してみる。

cd /home/vagrant/
/opt/unit/sbin/unitd --modules /opt/unit/build/

これで、unitdが起動し、API経由で設定を投入できる状態になった。

Djangoのアプリケーションを用意する

「Hello, World!」と表示するだけなので手抜きで。

cd /home/vagrant/
python3.6 -m venv venv
. venv/bin/activate
django-admin startproject myproject

myproject/myproject/settings.py(変更部分):

ALLOWED_HOSTS = ['*']  # ホスト側のブラウザから確認したかったので設定

myproject/myproject/urls.py:

from django.urls import path
from django.http import HttpResponse

def index(request):
    return HttpResponse('Hello, World!')

urlpatterns = [
    path('', index),
]

設定の投入

curlで投入してみるので、設定をファイルで用意する。

myproject.json:

{
    "listeners": {
        "*:8000": {
            "application": "myproject"
        }
    },
    "applications": {
        "myproject": {
            "type": "python 3.6",
            "processes": 1,
            "path": "/home/vagrant/myproject/",
            "home": "/home/vagrant/venv/",
            "module": "myproject.wsgi"
        }
    }
}

home キーの値にvenvのディレクトリを指定するが、末尾にスラッシュがないとエラーになった。ソースを確認したところ、よしなにしてくれない。

設定の投入が問題なければ、レスポンスは正常終了の旨が返される。

$ curl -X PUT -d @./myproject.json --unix-socket ./control.unit.sock 'http://localahost/'
{
        "success": "Reconfiguration done."
}

Webブラウザで 8000 ポートを確認し、「Hello, World!」と表示されればOK。

感想

  • NGINX Unitは動的に設定を投入できることが特徴ということだが、現状ではそれ以外にあまり利点がないので、gunicornやuWSGIで事足りる場合は、そちらを使ったほうが良さそう。
    • 無停止でワーカープロセス数を増やすぐらいならgunicornやuWSGIでも可能
  • 1つのホストでUnit経由で複数のアプリケーションをホストするにしても、リソース制御などがほしくなるから、Dockerか何かコンテナに対応してないと使いづらいか...
    • その用途なら今だとdocker-composeで事足りそうな気も。
    • クラスタ化して使えるようになったとしても、それはk8sでよいような気もするし..
  • NGINX Controllerで制御する自前のプロダクトということでUnitを作っているのかな?
  • HTTP/2のルーティングに対応するなら、NGINXとの組み合わせでオーバーヘッドが減るかも?
  • アプリケーションのプロセスは、killしても自動で再起動されてた

参考