http://share.buzzvideo.com/s/sffQMj
SONY BANK WALET
https://moneykit.net/visitor/sbw/
コメント:
将来は、LINE銀行&SONY BANK WALLET&楽天銀行も統合して頂き、
中国でのカード支払いに、中国の銀行に口座が
必要もしくは、スマホ決済で代替えの方法も、
あるらしいので、中国旅行やマネーレス、
カードレスのスマホ決済やビットコイン、リップルなどの仮想通貨決済なども
考慮して欲しいです。
マネーレス、カードレス、スマホレスで、
顔認証+手の静脈認証などの個人認証での、
決済による支払い方法も将来は、ご考慮頂きたいと思います。
なお、上記の統合した銀行のLINEアプリのインターネットバンキング機能は、
マネーフォワードの様になると良いですね。
ガス、電気、水道、インターネット、スマホ代金や通販やバーコードの紙を
スマホで撮影したり、カードの督促の支払いなどにも、LINEのスマホアプリ上で選択して支払いに対応して頂けると助かります。
WEBプログラマー
AON代表
石塚 正浩
TEL:042-559-8638
Mobile:070-3861-5011
http://aon.tokyo
http://aon.co.jp 準備中
cloud9slack@gmail.com
skype
live:cloud9slack
2019年12月31日火曜日
120年ぶり民法改正（改悪）へ、システム開発費「高騰」のリスクで、2020年以降IT企業倒産ラッシュか？法改悪の責任はどこが取る？
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00989/112600009/
シェアしました。
シェアしました。
山端 宏実＝日経 xTECH／日経コンピュータ
約120年ぶりに債権法を抜本的に見直した改正民法の施行が、約4カ月後の2020年4月1日に迫っている。改正によりIT業界で新たな火種となりそうなのが、ITベンダーが納品した情報システムに対して、ユーザー企業が無償改修や賠償を請求できる期間が実質的に延長される点だ。大手ITベンダーや業界団体は対応に乗り出しているが、システム開発費が「高騰」するリスクをはらんでいる。
改正民法は2017年に国会で成立した。売買やサービスなどの「契約」に関するルールを定めた債権法を約120年ぶりに抜本的に見直す。建築業界と並んで大きな影響を受けるのがIT業界だ。ITベンダーとユーザー企業それぞれで対応が必要になる。
最長10年間、ユーザー企業は無償対応の請求が可能に
ユーザー企業とITベンダーが交わすシステム開発の契約形態は大きく2つある。ITベンダーが成果物に対する完成義務を負う「請負」と、ユーザー企業が設計やプログラミングなどの作業に対して報酬を支払う「準委任」である。準委任の場合、ITベンダーは完成義務を負わない。請負と準委任は仕事の完成を目的にしているかどうかに大きな違いがある。
このうちITベンダーが身構えているのが請負への影響だ。民法改正により請負契約の内容が見直されると、ユーザー企業がシステムにバグがあった場合にITベンダーに対して無償改修などを請求できる期間が実質的に延びる。この見直しにITベンダーは戦々恐々としている。
表 民法改正の主なポイント
システム開発の契約や実務に混乱が生じそうだ
| 契約形態 | 変更点 | 概要 |
|---|---|---|
| 請負 | 用語 | 「瑕疵（かし）」という言葉が無くなり「契約不適合」に |
| ユーザー企業が無償のシステム改修などを請求できる期間 | システムの引き渡しから1年間だったが、契約不適合を知ってから1年間に。ただし、引き渡しから最大10年間 | |
| ITベンダーが報酬を請求できる権利 | システムが完成していなくても、一定の要件を満たせば報酬を請求できるように | |
| 準委任 | 契約の類型 | 従来の「履行割合型」のほかに、達成した成果に対して報酬を支払う「成果完成型」を追加 |
現行民法は「瑕疵（かし）」に対して無償のシステム改修などを請求できる期間について、システムの引き渡しから1年間と定めている。一方、改正民法は従来の瑕疵とほぼ同じ意味の「契約不適合」を知ってから1年間へと変わる。さらにシステムを引き渡してから最長10年間、ユーザー企業は無償の改修などを請求できるケースも生じる。
引き渡しの9年後にユーザー企業がバグを見つけても、ITベンダーはシステム改修に無償で応じなければいけないケースが出てくるわけだ。ITベンダーにとっては、長年にわたって無償改修のリスクを抱え込む。対応コストがかさむと見られる。
ユーザー企業は「無償対応期間が延びた」と喜んでばかりもいられない。ITベンダーが長期化する無償対応に対するリスクを織り込んで開発コストを見積もると、料金が上がりかねないからだ。
「長期的なリスクを見込んだ体制を維持するためのコストの積み増しなどが必要になれば、システムの提供価格の上昇を招くだろう。結果として発注者側のメリットは小さいのではないか」（NTTデータ広報）。ただしユーザー企業が値上げを受け入れるかは分からない。
この先は有料会員の登録が必要です。今なら有料会員（月額プラン）が2020年1月末まで無料！
日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら
無料版 PyCharm で Django 開発環境を構築するまでの手順（「現場で使える 基礎 Django」本の補講その２）
https://akiyoko.hatenablog.jp/entry/2018/06/17/182651
シェアしました。
PyCharm 関連でよく話題に上がるのが、エディションとライセンス、そして料金体系です。
まず、「ファイルの同期とリモートデバッグ」は、私が Professonal 版を選んでいる一番大きな理由です。ファイルの同期とはその名の通り、Vagrant や AWS の外部サーバに SFTP 等で自動的にファイルを同期してくれる機能で、実サーバで動作検証する際に非常に便利に使うことができます。リモートデバッグとは、サーバで動作させている Django のプロセスをブレークポイントで止めて IDE 内でステップ実行できる便利機能です。pdb を使ってコンソールでデバッガを使うのと比較して、見慣れた環境でデバッグできるのため効率が劇的に上がります。
最後に、ターミナル上で次のコマンドを実行して、Django プロジェクトのひな形を作成します。設定ディレクトリ名は拙書に倣って「config」としています。
これで PyCharm で Django を開発する環境が整いました。
シェアしました。
akiyoko です。
この記事では、私が執筆した Django の同人誌「現場で使える 基礎 Django」で説明しきれなかった部分の加筆・補足をしています。まだ本を読んでいない方にも読める記事になっていますので、ご安心を。
この記事では、私が執筆した Django の同人誌「現場で使える 基礎 Django」で説明しきれなかった部分の加筆・補足をしています。まだ本を読んでいない方にも読める記事になっていますので、ご安心を。
補講その２として今回は、「無料版 PyCharm で Django 開発環境を構築するまでの手順」 について取り上げます。
記事の前半で「PyCharm」の概要や利点、「Professional 版」と「Community 版」（「CE」と略されます）のエディションの違い、Professinal 版のライセンスと料金体系を説明し、後半で無料版の「PyCharm CE」を使って Django の開発環境を構築するまでの手順を解説します。
同人誌を購入済みの方のために補足すると、技術書典4 で頒布したバージョン（v1.0.0）の「付録A：macOS の Python 3 環境構築の方法」や 6月以降に再販したバージョン（v1.0.1）の「付録A：macOS における Django 開発環境の構築手順」とは若干手順が異なっていますので、すでにお読みの方はご注意ください。改訂箇所は以下の通りです。
- （使う必然性がなかったので）Anaconda を使わないように改訂（v1.0.1）
- 初心者でも簡単に環境構築できるように PyCharm CE を使うやり方に改訂（v1.0.1）
- 説明を簡便にするために、Python をインストールするまでの手順を省略（本記事）
- インストールする Python のバージョンを 3.5.2 → 3.6.5 に変更（本記事）
本ブログ記事では長々と書いていますが、同人誌ではスッキリと書いていますのでご安心ください。
《2018/8/17 追記》
BOOTH で販売していた技術書典4バージョンの「現場で使える 基礎 Django」（紙の本）はおかげさまで完売いたしました。そしてこのたび、36ページの加筆（本文144⇒180ページ）、Django 2.1 対応などの改訂をおこなった「現場で使える Django の教科書《基礎編》」を Kindle Direct Publishing で出版することになりました。電子版と紙の本を予定しています。
BOOTH で販売していた技術書典4バージョンの「現場で使える 基礎 Django」（紙の本）はおかげさまで完売いたしました。そしてこのたび、36ページの加筆（本文144⇒180ページ）、Django 2.1 対応などの改訂をおこなった「現場で使える Django の教科書《基礎編》」を Kindle Direct Publishing で出版することになりました。電子版と紙の本を予定しています。
PyCharm とは
「PyCharm」は「統合開発環境」（IDE）と呼ばれる開発ツールで、Python で開発をする際にいろいろと便利な機能を利用することができます。 仕事の現場でメモ帳を使って開発するとあまりにも非効率なので、このようなツールが一般的に使われています。
JetBrains 社の IDE では Java 向けの「IntelliJ IDEA」や、PHP 向けの「PhpStorm」が有名ですが、Python 向けの IDE が「PyCharm」という位置付けになっています。私は、Python 開発にはもっぱらこの「PyCharm」を愛用しています。
メリットとデメリット
私が Python の開発に PyCharm を使う理由は、以下の点が気に入っているからです。
- コードジャンプ機能と自動整形機能を使うことで開発効率が著しく向上する
- インストールしたそのままの状態で快適に使える
その他にも以下のようなメリットがあり、Python があまり得意でない方にも便利に使うことができるのも魅力です。
- 「venv」（仮想環境を作成するためのモジュール）や「pip」（パッケージ管理ツール）のコマンドの使い方が分からなくても、PyCharm の画面からポチポチと操作できる
- Windows 版も Mac 版もだいたい同じ操作性や見た目になるのでナレッジが共有しやすい
現時点でのデメリットとしては、例えば以下のものが挙げられるかと思います。
- 一部機能が有料の Professional 版でないと使えない（後述します）
- 現時点で Pipenv に未対応 *1
- conda を使っている場合に PyCharm の画面からパッケージがインストールできない不具合がある（？）
PyCharm 関連でよく話題に上がるのが、エディションとライセンス、そして料金体系です。
エディション（Professional 版と Community 版の違い）
PyCharm には有料の「Professional」版と無料の「Community」版（CE）とがあり、Community 版では一部機能が使えないといった制限があります。
機能の比較表が以下になります。 *2
機能の比較表が以下になります。 *2
この中で私が考える Professional 版のメリットはズバリ、以下の三点です。
- ファイルの同期とリモートデバッグ（Remote development capabilities）
- データベースのサポート（Database & SQL support）
- Django などの各種フレームワークのサポート（Python web frameworks）
まず、「ファイルの同期とリモートデバッグ」は、私が Professonal 版を選んでいる一番大きな理由です。ファイルの同期とはその名の通り、Vagrant や AWS の外部サーバに SFTP 等で自動的にファイルを同期してくれる機能で、実サーバで動作検証する際に非常に便利に使うことができます。リモートデバッグとは、サーバで動作させている Django のプロセスをブレークポイントで止めて IDE 内でステップ実行できる便利機能です。pdb を使ってコンソールでデバッガを使うのと比較して、見慣れた環境でデバッグできるのため効率が劇的に上がります。
二点目の「データベースサポート」は、IDE 内でデータベースのレコードを表形式で表示したり、表のセルを更新することでレコードを直感的に変更できたりと、データベースの操作を IDE 内で統合的に使えるようにしてくれる機能です。
SQLite については良さげなクライアントツールがないので個人的にこの機能は重宝していますが、例えば MySQL であれば Sequel Pro、PostgreSQL であれば「PSequel」などのクラアンとツールがあれば特に必要ないとは思います。あと、ER図の作成機能があるので、プロジェクトによってはニーズはあると思います。
SQLite については良さげなクライアントツールがないので個人的にこの機能は重宝していますが、例えば MySQL であれば Sequel Pro、PostgreSQL であれば「PSequel」などのクラアンとツールがあれば特に必要ないとは思います。あと、ER図の作成機能があるので、プロジェクトによってはニーズはあると思います。
最後の「Django などの各種フレームワークのサポート」ですが、例えば Django の場合であれば、テンプレートエンジンに合わせたシンタックスのハイライトや、ファイルに合わせたコード補完をサポートしてくれます。これらの機能はあればもちろん便利なのですが、私の感覚では必要不可欠とまでは言えないように感じています。詳しい情報は「Full-stack Web Development - Features | PyCharm」を参考にしてください。
ちなみに後述する通り、 学生は無料で Professional が使える ので、問答無用で Professional 版を利用すればよいと思います。
ライセンスと料金体系
以降で、Professional 版のライセンスについて説明します。
2017年以降はそれまであった「永久ライセンス」は無くなり、「サブスクリプションライセンス」方式になりました。PyCharm のサブスクリプションは、継続年数によって値段が異なるので少しややこしいです。また、基本は年払いですが、初年度に限り月払い（継続課金）も可能です。 *3
ライセンスは、PC1台ごとではなく、ユーザー1人ごとの料金になっています。ライセンスが1つあれば複数マシンで（別のOSでも可）利用できる のは嬉しい限りです。ただし、同一のユーザーが使うという前提でなければいけません。 *4
次に、コマーシャルライセンスとパーソナルライセンスの違いについて説明します。両者に機能的な差はありません。目的（開発するものが企業の製品・サービスなのか否か）によって、そのライセンスが異なります。パーソナルライセンスは、個人用に使うため（企業ではなく自分のお金で自分のために使う）のものですが、商用サービスの開発にも使えるとのことです。 *5 企業の業務内で利用する場合はコマーシャルライセンスを使いましょう、とのこと。 *6
そして気になる料金体系はこちら。
正確な値段については、公式サイトを適宜ご確認ください。
正確な値段については、公式サイトを適宜ご確認ください。
【パーソナル（個人）ライセンス】 *7
| 継続年数 | 料金（年額） |
|---|---|
| 1年目 | 10,300 円 /年 |
| 2年目 | 8,200 円 /年 |
| 3年目以降 | 6,200 円 /年 |
【コマーシャル（企業）ライセンス】 *8
| 継続年数 | 料金（年額） |
|---|---|
| 1年目 | 22,900 円 /年 |
| 2年目 | 18,300 円 /年 |
| 3年目以降 | 13,700 円 /年 |
また、大学のメールアドレスなど何らかの証明が必要となりますが、学生であれば無料で Professional 版が利用できます（PyCharm だけでなく JetBrains 社の全製品が無料になります）。 *9
私は個人的に有料の Professional版を利用していますが、以降で説明する内容は無料の Community 版でも問題なく動作させることができますのでご安心ください。
Django 開発環境を PyCharm CE で構築するまでの手順
手順の解説
今回の手順について、全体像となぜそのようにするのかを Ｑ＆Ａ形式で説明します。
まず、全体像はこちらになります。
1．Python 3 をインストール
Ｑ．Python 3 のバージョンは何を選べばよい？
Ａ．3.5 系でも 3.6 系でも Django 2.2 を使う上では特に問題ないと思いますが、3.7 系の最新安定版（現時点の最新版は「3.7.5」）を選ぶのがよいです。Python のバージョンの違いについては以下を参考にしてください。（参考）
Ｑ．Python 3 はどうやってインストールすればよい？
Ａ．Python 公式サイト からダウンロードしてインストールするのが一番簡単です。macOS の場合は、Python のバージョンが簡単に切り替えられるように Pyenv というツールを使ってインストールすることをオススメしますが、やや手順が面倒になります。『現場で使える Django の教科書《基礎編》』の付録では Pyenv を使ってインストールする手順についても説明しています。
Ｑ．pip とは？
Ａ．Django などの Python パッケージをインストール・アンインストールするためのパッケージ管理ツールです。Python 3.4 以降では「pip」が標準で付属しています。 *11
2．PyCharm をインストール
Ｑ．初期設定は？
Ａ．PyCharm は「out of the box（箱から取り出してすぐに使える、難しい設定などは一切なしで使える）」というのが大きな魅力のひとつですので、インストール直後の状態でほとんどそのまま使えます。より開発しやすくするための最低限の設定については、拙ブログの過去記事「 PyCharm のオレオレ最強設定 - akiyoko blog」を参考にしてください。
3．PyCharm プロジェクトを作成
Ｑ．PyCharm プロジェクトを作成するときに何を指定すればよい？
Ａ．ワークスペースのディレクトリのパス、仮想環境のディレクトリのパス、Python のベースインタープリタのパスを指定します。ワークスペース以外はプロジェクト作成後でも指定できますが、プロジェクト作成時に済ませておくことをオススメします。
Ｑ．ワークスペースのディレクトリは何を設定すればよい？
Ａ．私はデフォルトのディレクトリを使っています。macOS であれば「~/PycharmProjects/」がデフォルトのワークスペースを配置する場所になります。
Ｑ．仮想環境のディレクトリのパスは何を設定すればよい？
Ａ．デフォルトのまま、プロジェクトが作成されるディレクトリ直下に「venv」という名前のディレクトリを作ればよいでしょう。
Ｑ．Python インタープリタのパスは何を設定すればよい？
Ａ．macOS であれば「which python3」で表示されるパス （*12）、Windows であれば「where python」で表示されるパスを指定します。
Ｑ．Django をローカルPC にインストールするのはなぜ？
Ａ．以下の理由があります。
- Django に同梱されている django-admin.py（Django 管理コマンドユーティリティ）でプロジェクトのひな形を作るため
- プロジェクトのひな形作成時に生成される manage.py（プロジェクト管理コマンドユーティリティ）でアプリケーションのひな形を作るため
- PyCharm 上で Django モジュールへのコードジャンプができるようにするため
以降で、無料版 PyCharm で Django 開発環境を構築するまでの手順を実際に進めていきます。なお、私の環境は macOS 10.13（High Sierra）でそれを前提に進めていきますが、Windows 環境でも問題なく進められると思います。
1．Python 3 をインストール
Python 公式サイト から Python 3 をインストールします。
なお、macOS にはデフォルト状態では Python 2.7 が入っています。Windows 10 の場合は Python はインストールされていないと思います。
なお、macOS にはデフォルト状態では Python 2.7 が入っています。Windows 10 の場合は Python はインストールされていないと思います。
https://www.python.org/downloads/ から、インストーラをダウンロードします。
インストーラをダブルクリックしてインストールします。
macOS の場合は自動的に PATH に指定されますが、Windows の場合はインストーラ実行時に「Add Python 3.6 to PATH」をクリックして PATH に追加します。
今回の場合では、macOS では「python3」として実行できるようになります（Windows の場合は「python」）。
（macOS 10.13 の場合）
$ python3 --version Python 3.6.5 $ which python3 /Library/Frameworks/Python.framework/Versions/3.6/bin/python3
（Windows 10 の場合）
> python --version Python 3.6.5 > where python C:\Users\akiyoko\AppData\Local\Programs\Python\Python36-32\python.exe
2．PyCharm CE をインストール
https://www.jetbrains.com/pycharm/download/ から、Community 版である「PyCharm CE」のインストーラをダウンロードします。
インストーラをダブルクリックしてインストールを完了させます。
PyCharm CE を起動すると、いくつか初回設定を選択する画面になりますが、こちらは自分のスタイルに合わせて適宜選択します（後で変更し直すこともできます）。
なお、最初に出てくるキーマップ（keymap scheme）は、以前から使っているユーザーであれば「Mac OS X 10.5+ keymap」がよいかと思います。PyCharm 公式ショートカット一覧（Windows版 / Mac版）も非常に役立ちます。
3．PyCharm プロジェクトを作成
PyCharm プロジェクトを作成するには、PyCharm 起動後に「Create New Project」をクリックします。
次の内容を入力してプロジェクトを新規作成します。
この際、「Virtualenv」を指定することで、プロジェクトごとに仮想環境が作成されます（仮想環境のディレクトリ名は「venv」としています）。 *13
この際、「Virtualenv」を指定することで、プロジェクトごとに仮想環境が作成されます（仮想環境のディレクトリ名は「venv」としています）。 *13
| 項目 | 設定値 |
|---|---|
| Location: | 「/Users/akiyoko/PycharmProjects/mysite」 |
| New environment using: | 「Virtualenv」 |
| Location: | 「/Users/akiyoko/PycharmProjects/mysite/venv」 |
| Base interpreter: | 「/Library/Frameworks/Python.framework/Versions/3.6/bin/python3」（「which python3」の実行結果をコピー＆ペースト （*14）） |
PyCharm プロジェクトが作成されました。
「Preferences」（⌘ + ,）から「Project Interpreter」を開き、下部の「+」ボタンをクリックして、Python パッケージをインストールする画面を開きます。
例えば、「Django」を検索して、現時点の 2系の最新版である「2.0.6」をインストールします。
依存パッケージを含めてインストールが完了しました。
次に、左下のアイコンをマウスオーバーして「Terminal」を選択すると、仮想環境がアクティベートされたターミナルが起動します。
アクティベートされない場合は、「Preferences」から［Tool］>［Terminal］>［Activate virtualenv］にチェックが入っているかを確認してみてください。
それでもダメな場合は、仕方なく以下のコマンドを実行します。
$ source venv/bin/activate
最後に、ターミナル上で次のコマンドを実行して、Django プロジェクトのひな形を作成します。設定ディレクトリ名は拙書に倣って「config」としています。
(venv) $ django-admin.py startproject config .
これで PyCharm で Django を開発する環境が整いました。
最後に
最後に一番大事な話。
4月に「技術書典4」で販売して即完売した「現場で使える 基礎 Django」が、現在増刷して絶賛発売中です！完売しました！
4月に「技術書典4」で販売して即完売した「現場で使える 基礎 Django」が
無償の PyCharm CE を利用すれば、仮想環境を作成するための「venv」やパッケージ管理ツールの「pip」のことがよく分からなくても、Python 開発のためのプロジェクトを簡単に作成することができます。今回紹介した手順に従えば、Django の開発環境もラクラクと構築することができると思います。これで安心して Django の開発に取り組めますよね。あとはこの本を読んで勉強するだけですよね。
この本は B5サイズ・148ページの 本格的な Django 解説書 ですが、Django を仕事の現場で６年ほど使っている私が 「現場でこんな本があったらなぁ」という想いで書いたので、仕事で使っているあなたにぴったりな本 に仕上がっているはずです。
そしてこの本は特に、
そしてこの本は特に、
- Django の日本語書籍が無くて困っている方
- Django で一度挫折したことがある方
に絶対オススメの一冊となっています。
過去記事で読みどころの解説や読者の方々の評価を紹介していますので、気になる方はこちらも合わせてご覧ください。
《過去記事》
akiyoko.hatenablog.jp
akiyoko.hatenablog.jp
*3:4. If I choose a monthly subscription, do I have to place an order every month? – Licensing and Purchasing FAQ
*4:Can several products be used at the same time with the All Products license? – Licensing and Purchasing FAQ
Django 1.11 と 2.0 の違い （「現場で使える 基礎 Django」本の補講その１）
https://akiyoko.hatenablog.jp/entry/2018/06/15/161850
シェアしました。
Django のバージョンごとのサポート状況
2.0 の利用率が22～23 ％にとどまっているという結果は要注目です。私の率直な感想は「意外と少ないなぁ」でした。半分まではいかないとしても、もう少し多いのかなと予想していました。もちろんアンケート自体は何ヶ月か前から収集していたはずなので、現時点での数値とは多少の開きがあるとは思いますが。
（Python 2 系をサポートする最後のバージョンである）Django 1.11 LTS のサポートは早ければ 2020年4月に終了、Python 2.7 自体のバグフィックスのサポートは2020年1月に終了 するので、Python 2 を使っているプロジェクトは2019年末までには3系への移行を済ませる必要があります。
シェアしました。
akiyoko です。
この記事では、私が執筆した Django の同人誌「現場で使える 基礎 Django」で説明しきれなかった部分の加筆・補足をしています。まだ本を読んでいない方にも読める記事になっていますので、ご安心を。
この記事では、私が執筆した Django の同人誌「現場で使える 基礎 Django」で説明しきれなかった部分の加筆・補足をしています。まだ本を読んでいない方にも読める記事になっていますので、ご安心を。
補講その１として今回は、「Django のバージョン」、とりわけ「Django 1.11 と 2.0 の違い」 について取り上げます。
「現場で使える 基礎 Django」の表紙に書かれた 「1.11 LTS 対応」という文字を見て、「なーんだ、最新の Django 2 じゃないのかよ！」と敬遠している貴方のためにせっせと書き上げました。
《宣伝》
《2018/8/17 追記》
BOOTH で販売していた技術書典4バージョンの「現場で使える 基礎 Django」（紙の本）はおかげさまで完売いたしました。そしてこのたび、36ページの加筆（本文144⇒180ページ）、Django 2.1 対応などの改訂をおこなった「現場で使える Django の教科書《基礎編》」を Kindle Direct Publishing で出版することになりました。電子版と紙の本を予定しています。
BOOTH で販売していた技術書典4バージョンの「現場で使える 基礎 Django」（紙の本）はおかげさまで完売いたしました。そしてこのたび、36ページの加筆（本文144⇒180ページ）、Django 2.1 対応などの改訂をおこなった「現場で使える Django の教科書《基礎編》」を Kindle Direct Publishing で出版することになりました。電子版と紙の本を予定しています。
Django のバージョンについて
昨年2017年12月に、Django 2.0 がリリース されました。
Wikipedia によると 1.0 がリリースされたのが2008年9月なので、実に9年3ヶ月ぶりのメジャーバージョンアップとなりました。
Wikipedia によると 1.0 がリリースされたのが2008年9月なので、実に9年3ヶ月ぶりのメジャーバージョンアップとなりました。
それから半年ほど経ちましたが、現場ではまだ1系と2系が混在している、いわば過渡期の状況ではないでしょうか（あくまで私の肌感覚ですが）。
理由は３つほど考えられます。
【理由その１】
まずは、LTS の問題です。LTS とは「Long-Term Support」の略で、開発コミュニティからセキュリティパッチが長期間提供される特別なバージョンのことを指します。その点、Django 2系はまだ LTS バージョンがリリースされていません。LTS として予定されている「2.2」のリリースは 2019年4月となっており、まだ 10ヶ月ほど先になっているのが、2系へのバージョンアップに踏み切れない理由の一つに挙げられます。
すでに次期 LTS の「2.2」のロードマップも細かく決まっていて（多少ずれるようですが）、2019年の4月にリリースされることが予定されています。
| 予定日 | 詳細 |
|---|---|
| 2019年1月14日 | Django 2.2 アルファ版; 追加機能凍結 |
| 2月15日 | Django 2.2 ベータ版; バグフィックス凍結（致命的なバグ対応は除く） |
| 3月15日 | Django 2.2 RC 1（リリース候補）; 翻訳凍結 |
| 4月1日まで | Django 2.2 正式版 |
なお、1系のマイナーバージョン「1.12」はリリースされないことが決まっているため、「1.11」が 1系で最後のマイナーバージョンとなります。1系の最新バージョン は本記事の執筆時点で「1.11.14」となっています。
ということで、ビジネスで利用するとなると公式サポートが長い 1系がまだまだ主役の場合が多いのではないでしょうか。実際、現場の動きとしては「早く 2系へ移行しなければ！」という切迫感はまだあまり感じられません。
【理由その２】
次に、「Django 2系が Python 2のサポートを打ち切った」というのも、Django 2 への移行を阻害している大きな要因になっているのではないかと考えています。例えば、Python 2 で実稼働している Django 1系のプロジェクトでは、直ちに 2系にバージョンアップできない事情もあるでしょう。
【理由その３】
最後に、状況によっては利用しているライブラリが Django 2 にまだ対応していないということも考えられます。
結論として、現時点では、仕事の現場で使うなら「1.11 LTS」（2.2 LTS に向けて 2.0 から追従していくなら 2系でもOK）、趣味や研究で利用するなら「2系」を使えばよい と私は考えます。
ここで、実際の Django のバージョン別の利用状況を見てみましょう。
5月に開催された DjangoCongress JP 2018 で発表された事前アンケートの結果によると、Django 各バージョンの利用状況は以下の通りでした。
| Django バージョン | 利用率 |
|---|---|
| 1.8 以前 | 約 12 ％ |
| 1.8 LTS | 約 20 ％ |
| 1.9〜1.10 | 約 21 ％ |
| 1.11 LTS | 約 24～25 ％ |
| 2.0 | 約 22～23 ％ |
2.0 の利用率が22～23 ％にとどまっているという結果は要注目です。私の率直な感想は「意外と少ないなぁ」でした。半分まではいかないとしても、もう少し多いのかなと予想していました。もちろんアンケート自体は何ヶ月か前から収集していたはずなので、現時点での数値とは多少の開きがあるとは思いますが。
Django 1.11 と 2.0 の変更点
Django 2.0 のリリースノート には、1系の最終バージョンである「1.11」から「2.0」への変更点が記載されています。
大きな変更点としては、
- Python 2 のサポートが打ち切られた
- URLconf の書き方が簡単になった（django.urls.path() が追加）
- モデルの ForeignKey と OneToOneField で「on_delete」オプションが必須に
が挙げられるでしょうか。後で詳しく説明します。
それ以外の細かな変更点のうち個人的に気になったところを以下にズラズラと挙げましたが、ぶっちゃけ、そこまで大きな変更点はありません。 一番インパクトが大きいのはやはり、上で挙げた 「Python 2 のサポート打ち切り」 でしょう。
- ミドルウェアを settings.py で設定する際の変数「MIDDLEWARE_CLASSES」が廃止（「MIDDLEWARE」を使う）
- User.is_authenticated() と User.is_anonymous() がメソッドではなく、属性になった
- 管理サイトの画面がレスポンシブ対応に
- Window 関数の OVER 句に対応
- MySQL では 8.0.2 以降で対応
- MySQL でクエリ内の「__search」ルックアップが使えなくなった
- MySQL のトランザクション分離レベル（isolation level）のデフォルトが「read committed」に。1系では「repeatable read」だった
- runserver で立ち上がるサーバが HTTP/1.1 に対応
- django.conf.urls.include() の namespace を指定するときは、インクルード先の URLconf に app_name の指定が必須になった
- app_name が指定されてあって、且つ namespace を include の引数として指定すると、値を上書きできるっぽい
- django.conf.urls.include() の app_name 引数がなくなった
- カスタムテンプレートタグがキーワード引数のみを許容
- handler404 などのハンドラがコーラブルに（1系ではドット区切りの文字列だった）
- バイト文字列はインプット・アウトプット以外の部分では扱わないようになった *1
- AbstractUser.last_name の max_length が 150 に増えた（これまでは 30）
- クエリをスライシングした後に QuerySet.reverse() や last() ができなくなった
- 外部キー制約が SQLite でも有効に
- QuerySet.iterator() が一度に取得する行数が 100 から 2000 になった
ここに挙げたものの中には検証していないものも多々ありますので、誤訳や誤解がありましたらご指摘いただけるとありがたいです。
大きな変更点として挙げた３点について、詳しく説明していきます。
1. Python 2 のサポート打ち切り
先に述べた通り、Django 2.0 では Python 2系のサポートが打ち切られました。Django 2 を使う場合には、Python 3.4 以降が最低限必要になります。Django 1.11 および 2.0 がサポートする Python のバージョンをまとめたものが以下の表になります。
| Python 2.7 | 3.4 | 3.5 | 3.6 | 3.7 | |
|---|---|---|---|---|---|
| Django 1.11 | ○ | ○ | ○ | ○ | ー |
| Django 2.0 | ー | ○ | ○ | ○ | ○ |
（Python 2 系をサポートする最後のバージョンである）Django 1.11 LTS のサポートは早ければ 2020年4月に終了、Python 2.7 自体のバグフィックスのサポートは2020年1月に終了 するので、Python 2 を使っているプロジェクトは2019年末までには3系への移行を済ませる必要があります。
Python 2 で苦労した私としては、Python 2 のサポートをバッサリ切ったことはかなり嬉しいのですが、対応に追われるプロジェクトも今後出てきて大変そうだなという印象です。 *2
2. URLconf の書き方（URL ルーティングのシンタックス）
Django 1系では、正規表現の URL ルーティングは django.conf.urls.url() 関数を使って
from django.conf.urls import url ...（略）... url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive), url(r'^shop/(?P<book_id>\d+)/$', views.detail, name='shop_detail'),
というシンタックスで書いていましたが、新しく追加された django.urls.path() 関数を使って
from django.urls import path ...（略）... path('articles/<int:year>/', views.year_archive), path('shop/<int:book_id>/', views.detail, name='shop_detail'),
と簡潔に書くことができるようになりました。
django.conf.urls.url() を使った書き方は、Django 2.0 でもそのまま使えるように互換性が保たれていますし、同じ用法で使える django.urls.re_path() が追加されたのでそれを使って書き直してもよいと思います。
django.conf.urls.url() を使った書き方は、Django 2.0 でもそのまま使えるように互換性が保たれていますし、同じ用法で使える django.urls.re_path() が追加されたのでそれを使って書き直してもよいと思います。
3. ForeignKey と OneToOneField で「on_delete」オプションが必須に
モデルの ForeignKey と OneToOneField で「on_delete」フィールドオプションが必須になりました。このあたりは、「現場で使える 基礎 Django」の中でもしっかり説明してあります。
ここで、細かな変更点のうち、Windows 関数のサポートについても少し説明を加えておきます。
Window 関数について
Windows 関数は、あるまとまったデータ群（Window で区切られた集合）に対して集計処理をするための機能です。ランク付け（RANK 関数を使う）が一番理解しやすいでしょうか。なお、全ての Window 関数には「OVER句」が必要になります。
Window 関数自体は、PostgreSQL や Oracle では以前からサポートされていましたが、MySQL では 8.0.2 以降で導入されています。なお、Django 組み込みのバックエンドも PostgreSQL、Oracle、MySQL（8.0.2以降）で Window関数をサポートしていますが、データベースの種類と関数によってはサポートが異なる場合もあるとのことです。 *3
最後に、MySQL のトランザクション分離レベルについて調べたことを書いておきます。
MySQL のトランザクション分離レベルについて
「tree-tips: MySQLのトランザクション分離レベル | MySQL」に簡潔にまとめられていたのですが、1系でデフォルトだった「repeatable read」は 2系でデフォルトになる「read committed」に比べて「ファジーリード」（他セッションがコミットした更新データを参照してしまう）や「ファントムリード」（他セッションがコミットした追加データを参照してしまう）は起きないが、性能は「read committed」の方がよい（バージョン管理の範囲が狭くなるため）とされています。
MySQL 自体のデフォルトの分離レベルは MySQL5.6の公式ドキュメント によると「repeatable read」で、8.0 でも変わりません（変わるという噂もあるようですが）。それに対して、Oracle、PostgreSQL、SQL Server などでは「read committed」がデフォルトとなっています。
（参考）
- MySQL :: MySQL 8.0 Reference Manual :: 15.5.2.1 Transaction Isolation Levels
- InnoDBの分離レベルによるMySQLのパフォーマンスへの影響 | Yakst
- MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
- MySQLのデフォルトトランザクション分離レベルはREPEATABLE READだけど…
そもそも 2.0 へのバージョンアップは必要なのか？
さて、そもそも 2.0 へのバージョンアップは必要なのでしょうか？
パッケージをアップデートする理由は、
- 新しいバージョンで導入された新しい機能や改善点を利用したい場合
- バグ修正によるリスク減少
- セキュリティパッチのサポート延長
- 一気にバージョンアップすることのコストを抑える
- 例えば、LTS から LTS への大ジャンプはコストが掛かるため、普段から出来るかぎり最新バージョンに追随しておく
- 依存しているパッケージ・言語のサポートの問題
などが考えられます。 *4
しかしながら、これらのメリットが無いのであれば、現在使っているパッケージを無理にバージョンアップさせなくてもよいでしょう。バージョンアップしなくても、例えば、特定箇所のバグ修正であれば手動でバックポートすることで対応できることもあります。
最後に
最後に一番大事な話。
4月に「技術書典4」で販売して即完売した「現場で使える 基礎 Django」が、現在増刷して絶賛発売中です！ 完売しました！
4月に「技術書典4」で販売して即完売した「現場で使える 基礎 Django」が
対象バージョンは「Django 1.11 LTS」となっていますが、この記事で説明したように、Django の「1.11 LTS」と「2.0」は（Python 2 のサポート以外は）それほど大きな変更点はなく、「2.2 LTS」がまだリリースしていないため様子見が必要ということを踏まえると、もう買うしかないという気持ちになってきたはずですよね。
この本は B5サイズ・148ページの 本格的な Django 解説書 ですが、Django を仕事の現場で６年ほど使っている私が 「現場でこんな本があったらなぁ」という想いで書いたので、仕事で使っているあなたにぴったりな本 に仕上がっているはずです。
そしてこの本は特に、
そしてこの本は特に、
- Django の日本語書籍が無くて困っている方
- Django で一度挫折したことがある方
に絶対オススメの一冊となっています。
過去記事で読みどころの解説や読者の方々の評価を紹介していますので、気になる方はこちらも合わせてご覧ください。
《過去記事》
akiyoko.hatenablog.jp
akiyoko.hatenablog.jp