親です。

子ども産まれたんで育児とかについて書きます。映画とか心理学とかITとかの趣味についても書きます。

【索引】真面目に書いた記事

おつです。真面目に書いた記事をまとめとく。(未来の投稿日時だからトップにくるぞ)

小説系記事

  1. 16_導入および第一ターニングポイントについて - 親です。
  2. 20_ミュージカル映画2本「アニー」「ピッチパーフェクト」 - 親です。
  3. Mommy - 親です。
  4. コミュニケーションと権力関係について - 親です。
  5. 絶望と責任について - 親です。
  6. 【映画感想】『ROOM』と未評価な地点について - 親です。
  7. クソな夫婦喧嘩を「論点」の概念から考える。 - 親です。
  8. 優しさと責任範囲について - 親です。
  9. ゆらぎ荘の幽奈さん問題ーーセックスとレイプは別物じゃヨ - 親です。
  10. 素直さについての雑記 - 親です。
  11. 幸福学っての、慶應でも流行ってるじゃないすか - 親です。
  12. 小説について最近思うこと - 親です。
  13. 『その後の不自由 「嵐」のあとを生きる人たち』を読んで - 親です。
  14. 嫌なことにも依存はするよな、って話 - 親です。
  15. 馬鹿にされて馬鹿にし返すことについて - 親です。
  16. 親になることと責任について - 親です。
  17. 他者との関係性について、また絶望について。 - 親です。
  18. おそらく俺のモラトリアムが終わった - 親です。
  19. 【日記】最近は孤島の鬼を読んでます - 親です。

 

技術系記事

  1. 【COBOL】COBOLについての思い出 - 親です。
  2. 【Python】Pythonについてのまとめ記事 - 親です。
  3. 【HTML,CSS,JS】フロント三種分からんからまとめ - 親です。
  4. 【PHP】PHP分かんねえからまとめ - 親です。
  5. 【SQL】SQLわけわからんからまとめ - 親です。
  6. 【Git】Gitマジ完全理解したから聞いて - 親です。
  7. 【FileMaker】FileMakerについてのまとめ - 親です。

 

 学問系記事

  1. 【心理学】データ分析的な記事まとめ - 親です。
  2. 【数学】高校数学〜機械学習に使われる数学を復習する - 親です。

 キャリア・お仕事系記事

  1. 【お仕事】お仕事する上で気を付けときたいことまとめ - 親です。
  2. 【キャリア・転職】キャリアについて考えたことまとめ - 親です。
  3. 独立系SIを退職した - 親です。

その他の記事

  1. 【飯のメモ】ホットクックのオリジナルレシピ集 - 親です。
  2. 【英語】Fucking English Study Notes - 親です。
  3. 【ご飯】海外行っても手軽に作れそうなメシ - 親です。

 

これは随時更新する。なんか真面目なお話のネタは10個以上あって、けどあんま記事にするくらいまとまったら書けばいいかなーなんて思ってたら全然書けねえし鮮度も落ちてきてしまいそうだったので、早々に書いてしまうことにする。だいたい全部一年以上前に思いついたことだが、書かないと忘れそう。

【Python/Django】DjangoでHttpResponseの中身をグダグダ調べた

おつです。普段DjangoでHttpResponseを作成するときって、views.py内でテンプレートとレンダリングしたい変数を指定してreturnしていると思います。ただ、よくよく考えてみればテンプレートも変数もHttpResponseのボディに関わるところで、そのほかの構成要素(ステータスライン、ヘッダ)はどう設定されているのか分かりません。
今回は、ステータスラインやヘッダの設定周りについて、DjangoにおけるHttpResponseの基礎的なとこを振り返りつつ調べます。(今回はなぜか丁寧語で記事を書いてしまった。)

前提 -- render関数とHttpResponseクラス

はじめに前提として、HttpResponse自体について少し曖昧なところを整理しときます。 DjangoでHttpResponseを返却する方法はふたつあり、一つはrender関数、もう一つがHttpResponseクラスです。これらは何が違うの? って思うんですけど、調べてみたところ実際はrender関数もHttpResponseクラスを作成しているみたい。

(こんな感じのコードを書いた。)

class ProjectListView(View):
    template_name = 'board/project_list.html'

    def get(self, request):
        # HttpResponseOBJがどんなプロパティを持っているか?
        print('--HttpResponseの実験--')
        response = HttpResponse()
        print('Responseのtype:', type(response))
        print('Responseの中身', response)

        # render関数は何を返しているのか?
        projects = Project.objects.all()
        context = {'projects': projects}

        print('--render関数の実験--')
        print('render関数のtype:', type(render(request, self.template_name, context)))
        print('render関数の中身', response)

        return render(request, self.template_name, context)

流すとこう。

--HttpResponseの実験--
Responseのtype: <class 'django.http.response.HttpResponse'>
Responseの中身 <HttpResponse status_code=200, "text/html; charset=utf-8">
--render関数の実験--
render関数のtype: <class 'django.http.response.HttpResponse'>
render関数の中身 <HttpResponse status_code=200, "text/html; charset=utf-8">

作成されるオブジェクトやその中身は同じものっぽい。ではなぜわざわざふたつもやり方を用意しているのかというと、確か、HttpResponseOBJの作成されるタイミングが双方で異なり、テストをする場合はHttpResponseクラスを使った方が都合がよかった気がします。(詳しい人いたら詳細と検証の仕方リプください。。)

まあとにかくHttpResponseを返しているということが分かりました。

前提 -- HttpResponseOBJとは?

HttpResponseOBJの詳細について、公式は下記。
docs.djangoproject.com

概要は下記。

In contrast to HttpRequest objects, which are created automatically by Django, HttpResponse objects are your responsibility. Each view you write is responsible for instantiating, populating, and returning an HttpResponse.

TOEIC350点しかないけど、訳すと、

HttpRequestOBJがDjangoによって自動的に作られるのと対照的に、HttpResponseOBJはあなた自身によって作られます。あなたが作った全てのviewはHttpResponseOBJのインスタンスを生成し、値を放り込んで、そして返り値を返さねばなりません。

まあ、分かる。(ちな、調べたらpopulatingの意味が面白かった。リストに値をどんどん入れるとかそういう意味なんだなあ。)

じゃあ、このHttpResponseOBJにステータスラインやヘッダについての情報がまとまっているのでしょうか? どんなプロパティを持っているのか見てみると、

class ProjectListView(View):
    template_name = 'board/project_list.html'

    def get(self, request):
        response = HttpResponse()
        print('Responseのアトリビュート:', dir(response))

結果は下記。

Responseのアトリビュート: ['__bytes__', '__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '___getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_charset', '_closable_objects', '_container', '_content_type_for_repr', '_convert_to_charset', '_handler_class', '_headers', '_reason_phrase', 'charset', 'close', 'closed', 'content', 'cookies', 'delete_cookie', 'flush', 'get', 'getvalue', 'has_header', 'items', 'make_bytes', 'readable', 'reason_phrase', 'seekable', 'serialize', 'serialize_headers', 'set_cookie', 'set_signed_cookie', 'setdefault', 'status_code', 'streaming', 'tell', 'writable', 'write', 'writelines']

たくさんある。アンダーバーふたつで囲まれていないものは基本的にプロパティだと思います。いくつか表示させてみて、中身を確認したところ、ステータスライン、ヘッダーについては下記のように分かりました。

ステータスラインの設定

まずはステータスライン。これはみっつの要素(プロトコルバージョン、ステータスライン、テキストフレーズ)で構成されますが、HttpResponseで取り扱っているのはステータスコードのみでした。
残りの要素についてはsettings.pyの内部で設定されているっぽいですが、実際に確認はしていないです。要調査。

ヘッダの設定

・content_type
基本的にはsettings.pyに定義された値が設定されるみたい。HttpResponseの親クラスであるHttpResponseBaseに下記の記述があります。

if content_type is None:
            content_type = '%s; charset=%s' % (settings.DEFAULT_CONTENT_TYPE,
                                               self.charset)
        self['Content-Type'] = content_type

HttpResponseOBJにもcontent-typeを扱う_headerがあるが、アンダーバー始まりなので読み専。ちなみにprintするとこんな感じで表示されました。

print('_headers:', response._headers)
_headers: {'content-type': ('Content-Type', 'text/html; charset=utf-8')}

HttpResponseのまとめ

以上のような感じ。とりあえず分かったのはrender関数とHttpResponseがどちらも同じHttpResponseOBJを生成しているということ。そしてこのHttpResponseOBJはそれだけでHttpResponseを完全に取り仕切る訳ではなく、settings.pyの設定内容を反映したりしているということです。
まあ若干もう少し知れればと思うところもあるが、今回は以上。今後もちょいちょい調べていきたいなーと思ってます。

【FileMaker】FileMaker久しぶりに使うので思い出しついでに基本操作まとめる

おつです。久しぶりに触るので思い出しついでに操作まとめます。ちな、この記事は複数日使って更新予定です。。

一日目 - 基本操作

FileMakerはDBソフト兼カスタムApp。まあ普通にWebApp作るときと同じで、DB(テーブル)構築、バックエンド、フロントエンドの3つが主な作業内容。
それぞれやり方としては、 ・DB構築 → 『ファイル → 管理 → データベース管理』でテーブルの作成画面に行ける。そこでテーブル切って論理設計して云々する。 ・バックエンド → ボタンとかにトリガー貼って色々スクリプトを走らせることができる(フロントでは?)。そういう意味では、画面遷移とかフォームとかそういうのはもうFileMaker側がやってくれてるんだよな。あと何かあるとすると、ビジネスロジックの実装をやるくらいだなあ。 ・フロントエンド → これはレイアウトモードでやる。テーブル作った後ならフィールドピッカーからフォームを作成したりできる。後はボタン置いたりか?

一日目はこんなもんー。

【FileMaker】FileMakerについてのまとめ

おつです。むかしFileMakerについて勉強したことがあってインデックス記事作ってなかったので作る。

過去のFileMaker記事まとめ

  1. データベースのマジで初歩(概要とか)まとめ - 親です。
  2. FileMakerの勉強 vol.2 - 親です。
  3. FileMakerの勉強 vol.3(4〜6章) - 親です。
  4. FileMakerの勉強 vol.3.1 (索引について) - 親です。
  5. FileMakerの勉強 vol.1.1(概論) - 親です。
  6. FileMakerの勉強 vol.4(第7章) - 親です。
  7. FileMakerの勉強 vol.5(第8,9章) - 親です。
  8. FileMakerの勉強 vol.6(第10章) - 親です。
  9. FileMakerの勉強 vol.7(第11章) - 親です。
  10. FileMakerの勉強 vol.8(第12章) - 親です。
  11. FileMakerの勉強 vol.9(第13章) - 親です。
  12. FileMakerの勉強 vol.10(第14章) - 親です。
  13. 【FileMaker】FileMaker久しぶりに使うので思い出しついでに基本操作まとめる - 親です。

以上!

【Python/Django】去年の技術書典5で買った『どじゃんご本』の感想(関心事の分離について)

おつです。去年の技術書典5で購入したDjangoについての本を今更読んだんですが、購入した当時はよく分からなかったところ(特に関心事の分離)とかが理解できてマジ助かり本だったのでそれについて軽くまとめます。
ちなみに参考にした本はこちらで買えるぞ。

booth.pm

関心事の分離

俺はもうWeb系についてはマジ初心者で自分の立ってる位置も右も左も何も分からなかったので、去年この本を購入したときは関心事の分離について読んでもはぁ? 何それ? って感じで全く理解できなかった。多分初心者はそういうのあると思う。ただ、今になって思えば関心事の分離を理解すれば解決する疑問(フォームから受け取ったデータを使って計算をして返す関数をViews.pyの中に書いてしまって良いのか? みたいなやつ)は当時からあった。
関心事の分離ってのはまあそういうモジュール分割的なことで、モジュールを作成するときは目的(?)を設定し、その目的ごとにモジュールを切り分けていきましょうねみたいな考え方のことだ。そうすると一つのモジュールがすごい行数になったり、ここで何をしているのか分からん、みたいなことも防げる。
まあこういうのはWeb系の思想というよりはシステム構築の際の基本的な考え方だ。俺が元いたCOBOLの現場だってCOBOLなりにモジュールを分割し、契約系は契約系、帳票系は帳票系というふうにモジュールをまとめたりしていた。
なので、Djangoフレームワーク自体にも基本的な関心事の分離の思想は入っている。例えばviews.py, models.py, forms.py, urls.pyみたいなもの。しかしその分類では収まらないものがあるので、そこについてこの本では押さえてくれている。

出力に向けたmodelの変換 -- view_models.py

そのうち一つ目が、view_models層だ。『どじゃんご本』では大学のシラバスみたいなアプリを例に説明しているが、例えば科目テーブルに科目詳細というフィールドがあったとして、画面に表示するときは詳細の先頭100文字だけを抽出したいみたいな場合がある。こういう、『モデルにフィールドを切るわけにはいかないけれど、表示に向けて変換をしたい』みたいな目的を果たすために、view_models.pyを作るといいぞ、と書いてあった。
(実際のコードは上の本を買ってくれよな!!!)

ビジネスロジックの実装 -- services.py

二つ目がservices層だ。これはビジネスロジック、つまりそのWebサービスでまさにやりたいことの実装だ。
説明が前後するが、ビジネスロジックの実装方法には二つあると本書には書いてあり、一つのモデルに関わるロジックはmodels.pyに、複数のモデルに関わるロジックはservices.pyを切って実装せよと書いてあった。

本にはだいたいそんなことが書かれていた。関心事の分離についてはこんな具合だったけど、アアーッ俺が今まさに悩んでるところ!!という感じで大変役に立った。細かいことだけど@propertyの使い方とか知らなかった。

現場で書いている人の知識を知れるから技術書典っていいなって思いました。ちなみに、他にもいろんなことについてこの本では扱ってるので、上のリンクをのぞいてみると良いと思います。

今回は以上。

【Python/Django】Djangoのセキュリティについてちょっと調べた

乙です。Djangoのセキュリティについてちょっと調べたのでまとめる。

XSS対策

XSSって何かっていうと、こんな感じ。
クロスサイトスクリプティング(XSS)とは?仕組み・脅威から対策についてのまとめ

で、DjangoにはXSSへの対策が取られている。らしい。

Django におけるセキュリティ | Django documentation | Django

『多数の XSS 攻撃に対抗することができます。』っていう書き方がなんとも煮え切れないんだが、多分大多数のものに関してはこれで対応できてるんだと思う。テンプレートタグを使ってhtmlを作っている限り、変なスクリプトを埋め込まれることはないだろう。あってんのかな???

X-Content-Type-Optionsヘッダの設定

http通信で送られてきたファイルはcontent-typeで指定されたコンテンツとしてブラウザに読み込まれる。例えばhtmlだとか。で、ただ一部のブラウザはファイルの内容をみて勝手に判断してこれはhtmlだなとかjsだなとかしてしまって(sniffing)、それがためにセキュリティリスクとなることがある。 そんなときに重要なのがX-Content-Type-Optionsの指定。これを「X-Content-Type-Options : nosniff」と指定することで勝手な判断を阻止できる。 Djangoでの実装の仕方は簡単で、settings.pyに下記の設定を行うだけ。

SECURE_CONTENT_TYPE_NOSNIFF =True

Cookie関連

認証周りで使うcookieもセキュリティリスクになる。httpResponseHeaderにHttpOnlyだとかSecure属性を付与することでリスクの軽減が見込める。HttpOnlyはcookieの内容をhttpからしか読めなくする(JavaScriptから読むことを禁止する)もので、Secureはhttps通信の時のみcookieを使用するよう制限をかけられる。

CookieのSecure属性/HttpOnly属性の指摘と修正方法と脆弱性の解説 – Self branding

Djangoでの書き方は簡単。settings.pyに設定するだけ。

CSRF_COOKIE_HTTPONLY = True
CSRF_COOKIE_SECURE = True

設定 | Django documentation | Django 設定 | Django documentation | Django

ちなみにこいつら、ローカル環境では効かないっぽい。一旦テスト環境とかにデプロイすれば設定が効いているか確認できる。

cache関連

キャッシュってセキュリティ上のリスクあんの? って思ったけどメルカリで個人情報が流出してる。

CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog

まあこのケースはかなり複雑な感じだけど、要はキャッシュに個人情報が含まれてしまい、またそのキャッシュが意図しない形で他人に配信されてしまう、というケースがあるらしい。 ( わかりやすく説明してくれてるページ: セキュリティ対策としての Cache-Control ヘッダについて - 理系学生日記


そのため、キャッシュを保存しないようにする。方法をググったら下記の投稿が見つかった。

Fighting client-side caching in Django - Stack Overflow これでできるはず。

以上!!

最近の生活

おつです。日記。最近の生活について書く。

息子・家族のこと

息子は1歳3ヶ月。まだ歩きはしないけど伝い歩きをよくしている。手をとってあげると歩いて、そのとき「てーっち、てーっち」と言うのがかわいい。何かをするときに掛け声的に出す声ってのが息子にはいくつかあって、まあそれはすべからくかわいい。たとえば他にはご飯を食べるときに「あーん、もぐもぐもぐ」って言うとか、水玉模様のまるを次々指差しながら「らるらるらるらる…」と言ったりとか。「あーん」はひとにあげるときとかにもやって、息子のご飯中、ハンバーグとかを掴んで親にたべさせようとしてくれたりする(食べさせるふりをして結局自分で食べたりもする)。
そのほかまねっこが多くなった。はなかみ、おなら、などを真似する。
あーあと、パソコンで猫の動画を見せると「なーな!」と言って画面に釘付けになる。そしてときどきうふふと笑っている。その様子があんまりかわいいものだからよく猫動画をみせるんだが、最近はパソコンをつけるだけで「なーな」と言って猫動画をみせろとせがむ。かわいい。
妻とは相変わらず踊ってる。あと一緒に映画を見たり。最近は「ソウル・ステーション/パンデミック」「クレイジーパーティー」「ネクスト・ロボット」が面白かった。全部Netflixで見れます。

仕事・勉強

仕事は1月末で一旦落ち着いて、勉強に使える時間が増えた。まあ勉強っていっても仕事で使うものを調査してついでに自分の興味あるものと一緒に実装してみたりって感じなんだけど。
UdemyでgitとDBの講義を購入して勉強した。gitはなかなか良かった。DBもSQLってこういうことかとやっと納得がいった。今はWebアプリを作りつつ、git, Heroku, DB, WebAPI, OOP, JavaScriptなどを練習してるかんじ。
あとこれは確定ではないんだけど、もしかしたら物語と機械学習をかけ合わせたようなところで仕事ができるかもしれないので、そこに向けて勉強したりもしてる。うまいこと生活に組み込めたらいいなと思う。
あと忘れてはならない確定申告。やってます。クレジットの明細が届けば、家賃や水光熱費、Udemyやらカンファレンス代が分かるから、それ打ち込んで終わりだと思う。フリーランス的な仕事は今後も続けたい。給料もらいながら事業所得的なの稼ぐのは税金的にも強いなって感じてる。
そろそろ忙しくなるらしいから、プロジェクト管理等頑張りたいなと思う。

ご飯

ヴィーガンになることにしたので、そういうメニューを作ったりしてる。ひよこ豆のスープ、トマトとアボカドのスパゲッティ、ポトフ、ソイミートの唐揚げ、ソイミート唐揚げの味噌和えあたりが美味しい。もう少しレパートリー増やしたい。
あと、妻がヴィーガン用の通販サイトを見つけてくれて、そこで購入したハンバーグとか餃子とかがめっちゃ美味しい。インポッシブルフードとか見てても思うけど、そのうち大豆食品は肉の代用ではなく肉より美味しい何かになりそう。大豆のほうが肉より世代交代のスパンが早いから品種改良もしやすかろうし。

カナダ移住

カナダ移住は10月。はやいところ金を海外口座に移さねばならない。あと英語もそろそろ再開したい。

以上!