50代の銀行員がプログラミング(Python)を始めた話

はじめに

先日、Pythonを始めた50歳銀行員の方についてツイートしたところ、多くの方からの反響がありました。

今回はこの銀行員の方について、少しだけ触れたいと思います。

目次

エピソード

この銀行員の方とは5, 6年前から仕事でのお付き合いがあります。

私は以前からこの方を尊敬していて、

  • 40歳を超えてから初めて社内のIT関連部署へ。配属当初、周囲や発注先のシステムエンジニアが話すシステム開発関連の用語が理解できなかった為、キャッチアップの為に情報処理技術者試験の高度資格であるプロジェクトマネージャを勉強して早々に取得。

  • 私が出会った当時40代半ばでしたが、若手顔負けのエネルギッシュさで、どんな未経験システムのプロジェクトに対してもその都度勉強しながら前向きに取り組む。

といった感じで、自分もこうありたいと思っていました。

私の転職活動を打ち明けたら

その後、私はPythonを学んだことをきっかけに約2ヶ月強に渡るWebエンジニア転職活動を行ったのですが、なんとか内定が出始めて活動終了が見えてきたころ、普段お世話になっているこの銀行員の方に転職活動の話を打ち明けたところ、なんとこの方も冒頭のツイートの通り3ヶ月前からPythonの学習を始めていたのでした。

非常に驚きましたし、お互いがPythonやっていることがわかると、そこからはPythonの話題で大盛り上がりになりました。

Djangoに関しては私の方が先行していましたが、Anaconda, JupyterNotebook, NumPy, Pandasあたりの話は私は頷くことしかできませんでした。

twitterや勉強会などを除けば、リアルな生活の中では私はPythonの勉強をある種孤独に続けてきた為、こんな身近に仲間がいるのであれば早く知りたかったー、と思いました。

ちなみにその方、AI・機械学習のオンライン学習コースを社内で受講できるようになり志望したところ、人気が高く若手が優先されて受講できなかった為、個人で申し込んで最速で修了させたそうです。凄い。

今後について

私が転職することによって、その方と仕事上の繋がりは無くなってしまうのですが、今後も連絡を取ってPythonの勉強会などに一緒に参加していきたいと思います。

その方は、Pythonスタートブックという辻 真吾さんの著書からPythonの勉強を始めたそうなので、辻さんが登壇されることもある勉強会にお誘いできたらと思います。

最後に

プログラミングを学んで*1Webエンジニアにキャリアチェンジ*2するという今回の私の決断について、この方はエールを送ってくださいました。

この方も、このまま機械学習を中心にPythonを学び続けたら、データサイエンス方面に転向してもおかしくないのではないかと私は思っています。

「少なくとも70歳までは働くだろうし人生100年なのだから、いつまでも学びを続けよう!」という志を共有して、今後も切磋琢磨していきたいと思います。

Pythonスタートブック[増補改訂版]

Pythonスタートブック[増補改訂版]

*1:働きながらプログラミングをゼロから学んで半年でWebサービスを作るまでの記録

*2:実務未経験からのWebエンジニア転職活動の記録

プログラミングを学び、Web系エンジニアへの転職が決まるまで

はじめに

今年2019年1月からWeb系エンジニアへの転職活動を行っていましたが、このたびWeb系の自社開発企業(自社のWebサービス等を外注せず社員で内製開発・運営している企業)から内定をいただき、入社を決めました。

目次

転職の動機とその活動記録

2018年5月〜11月:転職をまだ考えていなかった時期

現職は非IT系企業にてプログラミングを一切行わない仕事をしているのですが、担当するWebサービスや社内システムの改善が様々な事情・制約で思うようには進まない中、現状を少しでも変える為、また自己研鑽の目的で、昨年2018年5月から独学でプログラミング(Python)の勉強を開始しました。

そして半年後の2018年11月、個人開発でWebサービスを完成させたことを機にそれまでのプログラミング勉強法をブログにまとめ、初めて作ったtwitterアカウントで告知をしたところ、はてなブックマークのホットエントリー入りするなどしました。

プログラミングでのモノ作りそのものに加えて、その成果や学びをブログやtwitterで発信することの楽しさに目覚めた私は、GitHubやQiitaのアカウントも取得し、アウトプットを継続していきました。

また、connpassに登録されている勉強会やもくもく会にも参加し、Web系エンジニアの方々との交流も開始しました。

2018年12月:転職を意識し出した時期

こうした活動を通じて、趣味や自己啓発ではなく本業としてWeb系エンジニアの世界に飛び込んでいきたいという思いが高まり、12月中旬ごろから転職の為の情報収集を開始しました。

なお、決して若くは無い年齢で家族を抱えながら実務未経験の職に転向するわけですので、上記の「好きが高じて」といった動機だけではなく、他にも現職への様々な思いや自身の将来への考えもある中での転職なのですが、それらも書くとあまりに長くなるので、ここでは割愛します。

2019年1月:転職活動開始

Wantedlyにプロフィールとポートフォリオを掲載の上、1月中旬からWeb系の自社開発企業に絞って面談を申し込みました(企業側から面談のお誘いを受けることもありました)。

また、twitter上でも転職活動開始を宣言。これがきっかけで面談に繋がった企業も僅かながらありました。

1月下旬には実際に企業との面談を開始しました。

2019年2月:各社との面談〜選考面接〜内定

2月は各社との面談、選考面接を順次行いました。

中には技術面接を行う企業もありました(技術面接と銘打っていなくても、技術的な理解度を確認する質問が出る面接もありました)。

最終面接を経て、2月の下旬ごろから内定が出始めました。

2019年3月:オファー面談〜退職に向けた社内調整〜入社承諾

内定を通知いただいた企業とは再度面談(オファー面談)を行いました。

処遇に関しては内定通知書に記載されているので、実務未経験であった私の場合はそこはあまり話題にはせず、内定通知書には書かれていない、Web系エンジニアとしてスキルを伸ばせそうな環境であるかどうかを重視して改めて確認しました。

  • 当面はコードを書くことに専念させてもらえるか(現職でプロジェクトマネジメント経験があることから、その方面の仕事に最初からアサインされたりするようなことがないか)

  • コードレビュー、テスト、CI/CD、Docker活用の取り組み状況

それまでの面談や面接でも同種の質問はしてきたのですが、採否がかかっている面接の場よりも、内定を貰った後のオファー面談の場の方がやはり遠慮なく質問しやすいので、そこで自分が気になる点は納得行くまで確認させてもらいました。

面談後は、現職の上司と退職に向けた調整を行い、退職日も定まった段階で転職先企業へ入社承諾の連絡をしました。

これから

2019年3月末を現職の最終出社日とし、4月は有給を消化、5月から転職先の企業へ入社する予定です。

現職は10年近く働いたこともあり、社内や取引先に知り合いも多く、特に親しい人・お世話になった人には最終出社日までにできる限り会って、これまでのお礼も含め話をしておきたいと思っています(現在進行中)。

4月の過ごし方はまだ計画中です。

最後に

昨年2018年5月の連休中、私は漠然と「プログラミングを学んで簡単なアプリ程度を作れるようになりたい」と思いながら、書店で初心者向けの本を手に取っていましたが、まさかその1年後にプログラミングを仕事にする職に就くことになるとまでは想像していませんでした。

日々の行動を変えることが、自分の考えも変え、(ちょっと大げさな言い方ですが)人生も変えてしまうのだと実感しました。

いずれにせよ、まだWeb系エンジニアとしてのキャリアのスタート地点に立ったばかりですので、これからも変わらずインプット・アウトプットを継続していきたいと思います。

今回の転職活動を応援して下さった方々、本当にありがとうございました!

そして

2019年5月から予定通りWebエンジニアとして働き始めました。

以降の話はこちらからどうぞ。

Python版悟空語ジェネレーター「gokulang」を作った振り返り

はじめに

先日、きんみさん(@_kinmi)の悟空語ジェネレーターに触発され、Pythonモジュール版であるgokulangとそのWeb API版を作成して公開したので、その振り返りです。

qiita.com

目次

反響

ありがたいことにtwitter上でもたくさんの方に紹介していただきました。

そのおかげもあって、Qiitaでデイリートレンド入りし、120以上もいいねを獲得しました。

何がウケたか

モジュール化してPyPIに登録したり、Web API化したりと自分としては初の試みを行なっており、作者本人は勉強の意味で実はマジメに取り組んでいたりするのですが、Qiita記事タイトルの方は遊びました。

ここで滑らず、反応があったのは嬉しかったですねー。

悟空語に変換しても'Ruby'は'るびー'のままだし、'PHP'は'ぴーえぇちぴー'で'ぺぇそん'ほどのインパクトは無いし、Pythonやってて本当に良かった。

ペーぴーえぇ(PyPI)

'PyPI'は、'ペーぴーえぇ'になります。

Python関連は、'Py'が付くことが多いから、悟空語と相性が良いです。

テストについて

きんみさん(@_kinmi)の悟空語ジェネレーターでは、とある固有名詞の悟空語変換がなかなか思うようにいかず、苦労されています。

その為、gokulangではテストを書いて、デグレートに備えました。

これもテストの勉強になりました。

# ...

class GokuLangTest(unittest.TestCase):
    def setUp(self):
        self.G = GokuLang()

# ...

 def test_dekami(self):
        q = 'ぱいぱいでか美'
        a = 'ぺぇぺぇでか美'
        self.assertEqual(a, self.G.translate(q))

#...

最後に

gokulangの作成に取り掛かる前は、完全二番煎じなのが少し気掛かりではありましたが、皆さん好意的に受け止めて下さって良かったです。

何より、Pythonモジュール化、Web API、テストと自分にとっては良い勉強になりました。

Qiitaでいいねして下さった方々、twitterで紹介して下さった方々、そして今回のきっかけを作って下さったきんみさん(@_kinmi)、ありがとうございました!

PHP/Laravelの学び方をYYPHP(わいわいPHP)で聞く

はじめに

PHPの情報交換や仲間作りをする集い、YYPHP(わいわいPHP)に参加してきました。

yyphp.connpass.com

会場

写真を撮り忘れたので当日の様子では無いのですが、会場はこんな感じのスペースです。

会場の写真

参加のきっかけ

私はここ10ヶ月ほどはずっとPythonとDjangoを独学でやってきました。

それが何故PHPかというと、今年に入ってからのWebエンジニアへの転職活動をする中で出会った企業には、PHPやLaravelで開発している企業が数多くあり、入社後にはそのスキルが求められる為、PHPのコミュニティにも参加しておきたいと思ったからです。

このYYPHPは、主催者側にQiitaでContribution4位の@suinさん がいらっしゃることもあり、前々からその存在が気になっており、参加申し込みをしました。

qiita.com

会の流れ

ゆるく雑談をしながらスタートし、各自自己紹介としてPHP歴と今日聞きたい・話したいテーマを挙げます。

全員の自己紹介が終わったら、挙げられたテーマに関して、順次参加者で話し合う、といった流れです。

参加人数は10人ほどと少人数であることと、主催者の一人である@nouphetさんのファシリテーションが素晴らしく、終始活発かつ和やかに意見交換ができました。

また、個人的には、同じく主催者側の@reoringさんがやたらと@nouphetを鋭くイジる?掛け合いが面白くツボでしたw (お二人の仲の良さが窺えましたw)

勉強会メモ

私からのテーマは

  • これまでPython/Djangoの経験はあるが、これからPHP/Laravelのスキルを習得するにあたって、どんな学び方が良いか知りたい

というものです。

これに対して様々なアドバイスをいただきました。

1. Webアプリから入らず、まずはPHPの課題を解いてみる

課題とは、例えば以下のようなものです。

  • 九九の表を出力する
    • 九九ができたら20x20をやってみる
    • 桁がずれるので合わせる
  • 多次元配列を1次元配列に変換する関数を書く(再帰処理で)
  • カレンダーを出力する
  • 多次元配列から要素を一撃で取り出す関数を実装する

インフラエンジニアである@nouphetさんがPHPを学ぶにあたって取り組んだことが以下のQiita記事に詳しくまとめられており、これに沿って説明いただきました。

qiita.com

2. 自分の知っている言語の使い慣れたコードをPHPでも書いてみて両者を並べてPHPの特徴を理解する

PHPerである@suinさんがScalaを学んだ際に実践したことを基にしたアドバイスです。

私の場合だと、Pythonでコードを書いて、それをPHPでも書いてみる、ということになりますね。

3. Laravel学習のおすすめコンテンツや勉強法

3.1 Udemy動画

Fullstack Web Development With Laravel and Vue.js - Udemy

参加者のkawasaki-tさんのおすすめです。

Udemyの日本語のLaravelチュートリアル動画は、扱っているLaravelバージョンが5.1と古いらしく、英語の動画がおすすめとのことでした。

定価12,000円ですがセール時にはきっと1,200円くらいになると思うので、その時に購入したいと思います。

3.2 LALACASTS

laracasts.com

こちらもLaravel学習では有名な動画チュートリアルサイトだそうです。

3.3 過去にDjangoで作ったWebアプリをLaravelで作り直してみる

こちらは参加者のbun0325さんのアドバイス。

Laravelを学ぶ目的で何かを作ろうとする時に、どんなアプリにするか考えることに時間がかかってしまいがちなので、過去に別フレームワークで作ったWebアプリをLaravelで作り直すことにすれば、設計や実装にすぐに着手できる、というものです。

3.4 技術書「絶対に挫折させないアプリ開発 はじめてのLaravel」

@nouphetさんからのおすすめ。

booth.pm

同じWebアプリを素のPHPと、Laravelそれぞれで作る内容となっているそうで、PHPの基礎とLaravelの中身の理解ができそうです。

4. PythonできるならPHPもできる!

ラストは参加者のたべたつさん(@ttabtt3)からの力強いアドバイス!(会場一同は爆笑)

確かにPHPもPythonと同じく動的型付け言語ですので、あれこれ考えずにまずはやってみるのが大事かもしれません。

最後に

YYPHP(わいわいPHP)の名前にふさわしく、初参加でも本当にわいわいと楽しめ、かつ多くの気付きと刺激を得られる素晴らしい勉強会でした。

参加して本当に良かったです。

いただいた貴重なアドバイスをもとにPHPの学習を継続したいと思います。

主催された株式会社クラフトマンソフトウェアの皆さま、参加者の皆さま、ありがとうございました。

WEBエンジニア勉強会 #11に参加しました

はじめに

2019/2/1(金)に開催された、WEBエンジニア勉強会 #11に初参加してきました。

web-engineer-meetup.connpass.com

会場

会場は渋谷にある株式会社ミクシィさんの本社です。

WEBエンジニア勉強会 会場

勉強会の進め方と参加者間の交流について

当日の参加者は60〜70名ほど。

最大4人まで座れるテーブル席でピザとお酒などのドリンクをいただきながら、登壇される方のお話を聞くスタイルです。

勉強会後の懇親会は希望者のみ別途移動して渋谷駅前のお店で開催されたようです。

より多くの方と交流したい方は懇親会に参加されると良いのではと思います。

私は勉強会が始まるまでの時間と休憩時間に同じテーブルの方と色々とお話しさせていただきました。

勉強会メモ

写真共有アプリ「みてね」に見る簡潔な良UI/UX

@ngmt83さん

「みてね」を推す理由/Reason for recommending "Mitene" - Speaker Deck

mitene.us

  • 写真共有アプリは数多あるが、多機能な写真共有アプリは祖父母世代にとっては操作が難解
  • サービスとして「なんでも提供できる」は「何も提供していない」のと(ある意味)同じ
  • 自由度を定義・制限することで、使いやすさを向上できる
  • このアプリの場合、ITリテラシーの高い子育て世代がアップロードなどの複雑な操作を担い、祖父母世代は写真を見るだけ、でも良い
    • 【感想】ユーザーを点では無く線で捉えることでサービスとして完結しているかどうかを評価できる、という視点を得ることができました
  • ユーザーの最大の関心はアプリの機能やサービスの内容ではなく、こども(孫)がかわいらしく写った写真
    • 「みてね」はそこに集中してもらえるような作り

WEBエンジニアが知っておきたい決済の仕組み

@ykaganoさん

WEBエンジニアが知っておきたい決済の仕組み - Speaker Deck

  • ECサイトで、買い物カートに商品を入れてくれるユーザーは全体の10%ぐらいで、決済してくれるユーザーは当然さらに少ない
  • より多くの決済方法を用意することで売り上げを伸ばせる
    • ただし、サービスや客層に応じた決済方法を用意する必要がある
    • クレジットカードを持たない若年層向けには携帯電話のキャリア決済など
  • クレジットカード決済における消費者、加盟店、アクワイアラ、イシュアの関係性やオーソリに関するお話
    • 【感想】クレジットカードに紐付けたQRコード決済も、同じ仕組みの上に成り立っているのだろうなと勝手に理解しました
    • 【疑問】与信審査が無く高校生でも持てるデビットカードのオーソリは、銀行口座残高をリアルタイムに確認に行くのかな?

心理的安全性の「持ちつ持たれつ」

ユアマイスター株式会社CTO 星 長亮さん(@inase17000)

心理的安全性の 「持ちつ持たれつ」 - Speaker Deck

  • 心理的安全性を高めるためには(抜粋)
    • 理解を示す
      • 同意できる点、できない点素直に伝える
    • 共に意思決定する姿勢を示す
      • 意思決定の根拠を示す
    • 【感想】傾聴は大事ですが、迎合することが心理的安全性を高めるわけではなくて、同意できない点や根拠を素直に伝えることもまた必要なのですね。そのあたりを曖昧にしてしまうことは、相手に対する無関心であり心理的安全性を低めることに繋がる、と私は理解しました。

gRPC入門

みずりゅさん(@MzRyuka)

  • gRPCはGoogleが開発したRemote Procedure Callのプロトコル
  • 様々なプログラミング言語でサポートされており、異なる言語間で通信できる
  • REST APIのようにcurlで気軽に叩くことはできないらしい
  • 【感想】調べたところ、Pythonではgrpcio-toolsというライブラリで使用することもできる様子

なぜ僕はプログラミングが苦手なのか

VTRyoさん(@3s_hv)

なぜ僕はプログラミングが苦手なのか / Why am I not good at programming - Speaker Deck

  • プログラミング初心者はエラー文を読めていないことがままある
    • 本当に全く読んで無いケース
      • 自分が追加・修正したコードをエラー原因もわからないまま、また別の追加・修正をしてエラーから抜け出せない
    • エラー文を読んではいるが読み解けていないケース
      • 経験不足のため、各エラーに適切に対処できない
  • 自分にセンスが無いと感じ自信を喪失した際にマネージャーに相談したところ、周囲の協力も得ながら修正できたのであればそれはちゃんと貢献できているのではないか、とのコメント
    • 難しく考えすぎて、自らハードルを上げてしまっていたことに気づく
  • 良い習慣を積み重ねることで、センスは身に付く
  • 【感想】とても勇気付けられる内容であると同時に、相談先のマネージャーさんのコメントがとてもセーフティ!(心理的安全性が高い、の意)

Word CloudでTweetを可視化してみた

なおとさん(@naoto_7713)

Word Cloudでツイートを可視化してみた

  • Twitter APIと形態素解析のライブラリとWord Cloudを組み合わせることで、特定のtweet群を1枚のイメージに可視化
  • 【感想】お話を聞く限り、APIの申請や形態素解析を使うためのコードはコピペで済ませたそう。まずは最短距離で「動くモノ」を実現してしまう、というのはモチベーションを維持しながらのものづくりを行う点でも大事な観点だと感じた。
  • 以下はWEBエンジニア勉強会#11に関するtweetを登壇中に可視化したもの

Word CloudでWEBエンジニア勉強会#11のtweetを可視化

MDX-DECKとCode Surferでスライドを作ろう

たくもんさん(@inouetakumon)

takumon.com

  • スライド作成ツールはパワポ、MacであればKeynoteなどがあるが、MDX-DECKはマークダウン記法で書ける
  • Reactコンポーネントでリッチな見た目にもできる
  • Code Surferはmdx-deckのプラグインでソースコードをリッチに表示してくれる
  • 【感想】スライドといえば会社ではパワポ、個人ではKeynoteでしか作ったことが無いので、MDX-DECK含む様々なスライド作成ツールに触れてみたい

フロントエンドコーディングにおけるPageSpeed Insights対策

Kouさん(@kkoudev)

フロントエンドコーディングにおけるPageSpeed Insights対策 / frontend pagespeed insights- - Speaker Deck

  • PageSpeed Insightsは、サイトアクセスのパフォーマンスを測定し改善点を提案してくれるGoogleのサービス
  • 【感想】私は、自分の作ったサービスのパフォーマンスを調べるのに https://testmysite.withgoogle.com/を使っていましたが、PageSpeed Insightsの方がわかりやすいですね。どちらもGoogleのサービスですが、なぜ似たような目的のサービスが2つ存在するのだろう?
  • よく指摘されやすいパフォーマンス上の問題点はレンダリングブロック、画像読み込み
  • レンダリングブロックについて
    • headタグ内に指定したJavaScriptやCSSの読み込み中は、HTMLの読み込みを実行できない
    • JSやCSSを非同期で読み込むことで改善可能
    • JSやCSSファイルをそれぞれ1つにまとめることでも読み込み時間を短縮できる
      • ブラウザがひとつのドメインに対して一度に並列接続できる数は決まっているため
    • なお、CSSの非同期読み込みすると画面崩れが一瞬発生してしまう
      • FOUC(Flash Of Unsyyled Content)とも呼ばれる
      • ファーストビューの描画に必要なstyleをHTMLにインライン記述することで対策(Critical Path CSSの指定)
      • criticalというNPMモジュールでインライン要素を自動生成
  • 画像読み込みについて
    • 画像解像度ごとに読み込む画像を指定できるsrcset属性を利用し、画像サイズを最適化
      • CSSではimage-set関数を使う
    • 画像の遅延読み込みの利用
  • その他サーバーサイドの配信時の改善点としてcss, js, 画像のgzip圧縮
  • 【感想】Webサイトのパフォーマンス向上に関して非常に参考になる内容でした。Webサイト全般に利用できる汎用的なテクニックだと思うので、ひとつずつ実際に試して覚えていきたい。

最後に

上記の通りテーマは多岐に渡り、非常に多くの気づきを得られる勉強会でした。

主催されたOSCA(@engineer_osca)さん、設営に携わられた方々、会場を提供されたミクシィさん、登壇者の方々、ありがとうございました!

モグモグDjango読書会に参加しました

はじめに

現場で使えるDjangoの教科書《基礎編》の読書会である、モグモグDjango読書会に参加してきました。

mogumogu-django.connpass.com

会場

会場はENECHANGE株式会社さんの提供でした。

勉強会終了後、ENECHANGE CTOの白木さんのご厚意でオフィスをぐるっと見学させていただいたのですが、とてもおしゃれなオフィスでした。

www.wantedly.com

ちなみにENECHAGEさんでは、Djangoエンジニアを現在募集中だそうです!

www.wantedly.com

勉強会の進め方

著者である@akiyokoさんが講師となって、Djangoの教科書《基礎編》の

  1. はじめに
  2. アーキテクチャ
  3. プロジェクト構成
  4. URLディスパッチャとURLConf
  5. ビュー
  6. モデル

を対象に解説していきます。

《基礎編》全体からすると対象は4割にとどまりますが、解説と参加者の質問が「濃い」ので、勉強会の4時間はあっという間に過ぎます。

流れとしては、各章ごとに

  1. その章に関する質問を共有のスプレッドシートに各自書き込み
  2. 上記の質問を踏まえつつ、akiyokoさんが各章のポイントや補足事項を事前準備した資料に基づいて解説
  3. 各参加者から前述のスプレッドシートに沿って質問し、akiyokoさんがそれに応える
  4. その後、3名程度がその章の感想を自由に述べる

といったサイクルを繰り返していきました。

参加人数は12名と比較的少人数な分、誰かが質問すると、それに触発されてまた別の質問が生まれて・・・と全員が積極的な参加スタイルとなった勉強会でした。

なお、「モグモグ」とある通り、各参加者が持ち寄ったお菓子をみんなでモグモグしながらの勉強会となります!

ちなみに私はカントリーマアムを持っていきました。

www.fujiya-peko.co.jp

勉強会メモ

URLConfとURLディスパッチャ

  • URLConfは、urls.pyのこと
  • では、URLディスパッチャの正体は?
    • django.core.handlers.wsgi.pyのWSGIHandler

Djangoアプリの適切な粒度

  • アプリはできるだけ小さく
  • 機能をひとことで表せる程度
  • ひとつのアプリあたり、モデル数は3〜5個程度
  • 例えばREST APIなら、モデルだけを持つアプリと、シリアライザ等のアプリといった感じで分割するなど
  • (私からの質問)汎用的にカスタマイズしたUserモデルだけを持つusersアプリを作って、他の機能は別アプリに作り込んでいく方針はどうか?
    • 良い方針だと思う。

クラスベースビューのビュー関数化

Djangoの教科書では、views.pyでクラスベースビューをビュー関数化している。

from django.views import View

class HelloView(view):

# ...

hello = HelloView.as_view()

これはurls.pyからだけでなく、他のビューからも呼び出せるようになるというメリットがあるが、urls.py側でビュー関数化するのでも構わない。むしろ、そのやり方が多数派。

from django.urls import path

from .views import HelloView

urls = [
  path('', HelloView.as_view(), name='hello'),
]

書籍では、ビュー関数化をURLConfの章で解説するよりもビューの章で解説した方が構成上わかりやすくなるので、そのようにしたとのこと。

models.pyの管理方法

  • views.pyのロジックは最小限とし、models.pyにはビジネスロジックを寄せてファットにするのが良い
  • ファットになり過ぎたら、utillsディレクトリあるいはutills.pyを作って、そこに機能を切り出す
  • ファット過ぎるかどうかの基準は一概には言えない

最後に

参加者については

  • 普段は機械学習や画像解析をされている方
  • Railsエンジニアの方
  • 日頃の業務の効率化にPythonを活用されている方

など、様々なバックグラウンドの方が来ていました。

こうした参加者の方とも交流が図れ、とても有意義な勉強会でした。

主催者の@shinseitaroさん、講師のakiyokoさん、会場を使わせてくださった白木さん、ありがとうございました。

django-allauthでカスタマイズしたUserモデルを使う場合の設定について

はじめに

DjangoのUserモデルについて、ユーザー名(username)を削除し、代わりにメールアドレス(email)を追加するカスタマイズはよく行われるものかと思いますが、その場合にDjangoの便利な認証パッケージ「django-allauth」を使うには、settings.pyの設定をいくつかいじる必要があります。

django-allauth公式ドキュメントでの各種設定のページから、関連する設定をひとつひとつ調べた結果をまとめ、以下の通りQiitaに投稿したのですが、

qiita.com

それとは別の「高度な使い方」のページに、そのものズバリの解説があったので、そちらの要点を拾って意訳してみました。

カスタムユーザーモデルに関する説明の要点

  • カスタマイズしたUserモデルにusernameフィールドが無い場合、ACCOUNT_USER_MODEL_USERNAME_FIELDNoneに設定する必要がある。これにより、django-allauthにおけるusernameに関する機能が無効になる。

  • ACCOUNT_USERNAME_REQUIREDFalseに設定する。

例として、メールアドレスをユーザーIDとして扱い、ユーザー名は持たないカスタムUserモデルの場合、settings.pyの設定は以下になる。

ACCOUNT_USER_MODEL_USERNAME_FIELD = None
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_USERNAME_REQUIRED = False
ACCOUNT_AUTHENTICATION_METHOD = 'email'