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'

Start Python Club「みんなのPython勉強会#41」に参加してきました

はじめに

Webエンジニア転職活動中のやんばるです。

1月16日にStart Python Clubの「みんなのPython勉強会#41」に参加してきました。

startpython.connpass.com

以下、勉強会の内容のメモと、懇親会のレポートです。

#1 Pythonの話をしよう 辻 真吾さん

  • Pythonの発案者 Guido van Rossumについて

    • PEP572の導入是非の議論を巡って慈悲深き終身独裁者(OSSの少数のリーダーに与えられる称号)から2018年に引退

    • 大食いYouTuber木下ゆうかさんの動画がお気に入りとのツイートが昨年話題に

  • PyPI

    • PyPIはpip installによってインストールされるパッケージの配布元
    • 2018年にpypi.python.orgからpypi.orgにリニューアルされた
  • Python仮想環境周辺の話

    • virtualenvとvenvとpyvenvとpyenvの違い
    • virtualenvの一部機能がvenvとしてPython3.3から標準機能に組み込まれた
    • pyvenvスクリプトは3.6から非推奨
    • pyenvはPython自体のバージョン管理可能
    • Anaconda
      • AnacondaによってインストールされるパッケージはPyPIとは異なる場所から配布される?
      • 故にAnaconda環境化でpipを使う場合は要注意
      • pipとconda、混ぜるな危険(ブログからの引用)

#2 ウェブサイトとCMS 山下 陽介さん 株式会社アカリ代表取締役

  • 良いウェブサイトとは

    • マルチデバイス対応
    • 検索性
    • SEO(文章構造を踏まえたマークアップがなされている)
    • レスポンス
    • 多言語対応
  • 先進的なテック企業と古き良き事業会社との間でウェブサイトの質に格差が生まれている

    • 古き良き事業会社でも質の高いウェブサイトを導入・維持可能とするサービスが求められている
  • ウェブサイトの作り方

    • フルスクラッチか、外注してCMS
  • CMSとは

    • Content Management System

    • CMSの特徴

      • 記事ページ、カテゴリページから構成
      • その他コンテンツも含む
      • 文言編集、ブロックごとのテンプレートのマネジメントが可能
      • ブログ、EC、フォーラム(掲示板)、wikiなどがベースであることが多い
    • 既存の一般的なCMSの課題

      • フルスクラッチと比較し、UI/UXの品質を高めづらい側面がある
      • CMSを導入してもフロントエンドはフルスクラッチする必要がある
      • フロント、サーバー双方を跨ったロジックの追加が困難
      • インフラ構築の工数はやっぱり必要
      • 最終出力物がhtmlなので情報の再利用が困難
        • 例えばディクショナリ型で管理されていると再利用しやすい
      • メンテナンス性に課題
      • 複雑な要件には大量のサードパーティプラグインに頼らざるを得ない
    • Headless CMSとは

      • JSONをレスポンスしてくれる
  • Okra

    • 株式会社アカリが開発したCMS
    • Angular / nord.js / Python / Django REST Framework
    • dominoというライブラリでDOMをエミュレート可能
    • 特徴
      • 1 クラウドネイティブ
      • 2 ドキュメントの質
        • デザイナーがhtmlに触れることなく、見た目そのままに編集できる
      • 3 テンプレーティング
      • 4 データセントリック
        • htmlではなくディクショナリ型で保存し、デザインのリプレースが容易
      • 5 テスト自動化
      • 6 グローバライズ
      • 7 SEO対策
        • Twitterカードなど
      • 8 どこでもキャッシュ
    • DBに詳しいdenzowさん、Webアプリケーションに詳しい関根 裕紀さん、株式会社システム技研さんなどの助言、協力を得て開発されたとのこと
    • 実際にデモを拝見しましたが、SPAのためレスポンスはサクサクで、変更も見た目のまま編集できていました

#3 排泄検知をやってみよう!~排泄センサと排泄検知アルゴリズム ~ 宇井 吉美さん 株式会社aba代表取締役

  • 排泄センサー Helppadを開発

    • センサーにPythonの機械学習モデルを利用

    • 介護施設の高齢者など、排泄時に自らおむつ替えの必要を訴えられない方に代わり、センサーが介護職員に排泄を通知する

    • これにより介護職員によるおむつ替え要否の定期的な巡回作業負担を軽減する

      • もしそうしたセンサーが無ければ巡回作業が空振りに終わったり、あるいは巡回時に手遅れで排泄物が衣服にまで漏れている可能性があり、一連の作業負担は極めて高い
    • 介護職員の8割がこうした排泄に関わる対応に肉体的、精神的負担を感じている

      • なお、介護職は3年以内に離職7割
    • このような介護現場の真のニーズを拾い上げるために、自ら3年間介護施設で勤務

      • 実際に施設の高齢者の方の介護にあたっているお写真の紹介もありました。最強のユーザー調査であり、本当に頭が下がります。
    • センサーはベッドに敷くタイプで、高齢者が身に付ける必要が無い

    • においによる検知なので、水分や電気による検知方式より便の検知がしやすい

    • aba社員菅野さんからのセンサーに機械学習モデルを採用した理由の解説

      • 高齢者の便のにおいは個人差が大きく、シンプルなしきい値判定では誤検知や検知漏れが多かった
      • また、ガスセンサー自体も同一メーカー、同一型番の製品でもセンサーの精度に個体差があった

懇親会(ビアバッシュ)

懇親会では登壇された株式会社アカリの山下さんのほか、参加者の株式会社キカガク、株式会社ビープラウド、株式会社マンハッタンコードの方々とお話しすることができました。

キカガクさんについては、会社主催のもくもく会にお誘いまでいただいて本当に感謝です!

セッションでも懇親会でもたくさんの刺激を受け、大変楽しい時間を過ごせました。

運営に関わられた方々、本当にありがとうございました。

okra-lab.com

www.bk.mufg.jp

Djangoのモデル(Model)定義・操作に関する解説ページ11選

はじめに

Djangoのモデル(Model)に関する解説ページについて

  • できるだけ日本語の記事
  • 網羅性がある記事
  • 何かに特化した記事

の観点で集めました。

前半5記事はモデル定義、後半6記事はモデル操作に関するものとなります。

なお、マイグレーションの解説記事は今回は載せていません。 機会があれば別途まとめたいと思います。

モデル定義関連

1.【一部英語・Django2.1・Django公式】モデルフィールドリファレンス

https://docs.djangoproject.com/ja/2.1/ref/models/fields/

完全に翻訳化されてはおらず、一部英語が残っています。

以下の一覧・解説・サンプルコードが掲載されています。

  • CharFieldなどのフィールドの型
  • uniqueなどのフィールドオプション
  • ForeinKeyなどのリレーションシップフィールド

2. 【日本語・Django1.0・Django公式】モデルの作成

http://djangoproject.jp/doc/ja/1.0/topics/db/models.html

ひとつ前のページのDjango1.0版に相当します。

ひとつ前のページで翻訳化されていない部分を、バージョンの違いには注意しつつ、このページで補完すると良いかと思います。

3.【日本語・Django2.0・Qiita】モデルフィールド 設定テンプレート

https://qiita.com/okoppe8/items/a1149b2be54441951de1

以下の一覧・解説・サンプルコードが掲載されています。

  • CharFieldなどのフィールドの型
  • nullなどのフィールドオプション
  • ForeinKeyなどのリレーションシップフィールド

4.【日本語・Django2.0・Qiita】モデルフィールド:データベースフィールド 型対応表

https://qiita.com/okoppe8/items/13ad7b7d52fd6a3fd3fc

以下の一覧・SQLが掲載されています。

  • モデルフィールドとMySQL, PostgreSQL, SQLite3, SQL Serverの型対応表

5.【日本語・Django1.11・Qiita】モデルフィールドリファレンスの一覧

https://qiita.com/nachashin/items/f768f0d437e0042dd4b3

以下の一覧・解説が掲載されています。

  • CharFieldなどのフィールドの型
  • nullなどのフィールドオプション
  • ForeinKeyなどのリレーションシップフィールド
  • get_internal_type()などのField API
  • Field.auto_createdなどのフィールド属性
  • Field.many_to_manyなどのフィールドリレーションのための属性

モデル操作関連

6.【日本語・Django2.0・Qiita】データベース操作 についてのまとめ

https://qiita.com/okoppe8/items/66a8747cf179a538355b

以下について解説されています。

  • Django公式サイトのモデル関連各記事へのリンク集
  • クエリ(QuerySet API)一覧
  • クエリ、クエリセットとは何かについて
  • gt, ltなどの検索キーワード(フィールドルックアップ)について
  • Upper()などのデータベース関数について
  • add()などの対Nリレーション操作専用メソッドについて
  • Avg()などの集計関数について

7.【日本語・Django2.1・Qiita】Djangoのモデル操作でobjectsが必要な場合・不要な場合を理解する

https://qiita.com/shonansurvivors/items/12b087cf5ab591273c8c

Model.objects.all()などで登場するobjects(モデルマネージャ)は何であるのか、モデルを操作する時に必要な場合、不要な場合を解説しています。

Djangoはモデル操作メソッドを連結できますが、この記事を読むと

  • Model.objects.filter(id=1).exits()は正常
  • Model.objects.get(id=1).exits()はエラー

になる理由が理解できるかと思います。

8. 【一部英語・Django2.1・Django公式】クエリを作成する

https://docs.djangoproject.com/ja/2.1/topics/db/queries/

Djangoのモデル操作に関する各種の概念、考え方について解説されています。

完全に翻訳化されてはおらず、一部英語が残っています。

9. 【日本語・Django1.0・Django公式】クエリを生成する

http://djangoproject.jp/doc/ja/1.0/topics/db/queries.html

ひとつ前のページのDjango1.0版です。

ひとつ前のページで翻訳化されていない部分を、バージョンの違いには注意しつつ、このページで補完すると良いかと思います。

10.【英語・Django2.1・Django公式】QuerySet API reference

https://docs.djangoproject.com/ja/2.1/ref/models/querysets/

Djangoのモデル操作のメソッドの一覧および解説です。

URLとしては日本語のページなのですが、翻訳化がほぼ未実施なため、全編英語です。

11. 【日本語・Django2系・ブログ】ManyToMany フィルターなどのオブジェクト操作一覧

多対多(ManyToMany)の関係を持つモデルの操作に特化して解説されています。

https://www.djangobrothers.com/blogs/many_to_many_objects/

終わりに

以上です。参考になれば幸いです。

Django公式サイトの2系記事の日本語化がまだ進んでいないのが残念ですね。

英語版でもGoogle翻訳など活用して読んでいきたいと思います。

Djangoのキャッシュ機能に関する記事をQiitaに投稿しました

はじめに

ここ最近はDjangoで作ったWebサービス「世界遺産トラベラーズ」のレスポンス向上に取り組んできました。

なぜ、レスポンス向上なのか。

それは、世界遺産トラベラーズを作り始める際に参考にさせていただいた「ホット チリ レビューズ」の作者ジャバ・ザ・ハットリさんのQiita投稿がずっと気になっていたからです。

無料だからと言ってレスポンスが遅いサイトになったら意味が無い。レスポンスにもとことんこだわっている。

(略)

  • HerokuのRedis(無料プラン)には25Mのキャッシュが置けるのでできるかぎりここにデータを置く
  • 全てのレスポンスはRedisキャッシュからとしてHerokuログ上では5ms以内とする
  • データベースが更新された際には、自動でその内容をRedisに書き込む処理を入れる
  • ユーザーからのリクエストを受けた際にそのレスポンスは常にキャッシュから返して、データベースはほぼ動かさない

Herokuの無料プランは30分間アクセスが無いとスリープ状態に入ってしまい、そうなると次のアクセス時はレスポンスが返ってくるまで10秒以上は待たせられます。

そんなHeroku無料プランで高速なレスポンスを実現しているのは私にとって異次元の技術なのですが、少しでもこれに近づくためにレスポンス向上に関して調べ、サービスに取り込んで行きました。

レスポンス向上の為の取り組み内容とQiita投稿内容

まず最初は、各画面でデータベースにアクセスする為のSQL文が無駄に発行されている傾向があったので、これをできる限り減らし、その上でキャッシュ機能を導入しました。

このキャッシュ機能の導入方法や、導入したことでレスポンスがどのように変化したかをQiitaには投稿しています。

1記事目

まず、最初はキャッシュの保存先をデータベース(RDBMS)としました。

これに関しては、

  • 追加のパッケージ等のインストールが不要
  • ローカルの開発環境とHerokuそれぞれのsettings.py等の設定方法が同じ

であるため、導入はお手軽なのですが、キャッシュを保存・更新する際はそのデータベースアクセスによってレスポンスが逆に悪化します。

Djangoでとりあえずビューやテンプレートをキャッシュする方法を試してみるには良いのですが、本番で提供するサービスに実際に導入するのは厳しいかなと感じています。

qiita.com

2・3記事目

続いて、キャッシュの保存先をMemcachedにしました。 Memcachedはデータベース(RDBMS)よりも読み書きが高速です。

こちらに関しては、

  • ローカルの開発環境、HerokuそれぞれへMemcachedのインストールが必要
  • Herokuで使う場合は追加のパッケージが必要
  • ローカルの開発環境とHerokuそれぞれでsettings.pyの設定内容が異なる

といったように導入時の若干の手間はあるものの、レスポンスが逆に悪化するようなデメリットは見受けられず、おすすめです。

以下2記事目ではローカルの開発環境への導入方法を、

qiita.com

以下3記事目ではHerokuへの導入方法を解説しています。

qiita.com

レスポンス向上に取り組んだ結果は?

以下のGoogleのサービスでは、URLを入れるだけでそのWebサイトをモバイル向けサイトとしてレスポンスに問題が無いか診断してくれます。

testmysite.withgoogle.com

こちらで世界遺産トラベラーズ(https://www.sekaiisan.site)を診断したところ、「特に良好」という結果になりました。

この結果を出せた時はちょっと感動しました(笑)

f:id:shonansurvivors:20181222194247p:plain

Djangoのソートが50音順にならない時の対処法をQiitaに書きました

はじめに

Djangoで作ったWebサービス「世界遺産トラベラーズ」では、世界遺産や世界遺産の存在する国を50音順に表示している画面があります。

f:id:shonansurvivors:20181207001429p:plainf:id:shonansurvivors:20181207001918p:plain

世界遺産や国の情報はデータベースに持っていて、データベースからデータを引っ張ってくる時にその名称で昇順ソート、つまり、あいうえお順に並び替えています。

発生した問題

開発途中は期待通りに50音順に表示されていたのですが、Herokuにデプロイして本番環境で見てみると50音順とは全く異なる順序で表示されてしまうという問題が発生してしまいました...。

原因と対処方法

この50音順にならないという点はサービスの機能に与える影響としては致命的ではなかったのですが、見た目としてかっこ悪いのでなんとかしたいと思い、原因と対処方法を調べたところ解決できたので、その内容をQiitaにまとめました。

原因はQiitaの方にも書いていますが、HerokuでのデータベースとしてPostgreSQLを使用した場合に、このPostgreSQLの初期設定が影響したためでした。

Djangoのチュートリアルを終えた方に

Django Girls Tutorialやその他Qiita等での各種Djangoチュートリアルでは、多くの場合HerokuでのデータベースとしてPostgreSQLを使用しているかと思います。

そのため、チュートリアルを終えた後、データベースに(Modelに)日本語文字列カラムを持つようなWebアプリを作った方は同様の事象に遭遇しているケースが結構多いのでは、と思っています。

以下の記事を参考に解決いただければ幸いです!