Python・Django学習記録①

Python

背景

  • 最近はJava（Spring）でWebアプリを作っている。
  • サーバーサイドで第二の言語を学習したい。
  • よしPythonやろう。

JavaでWebアプリ書くのって結構敷居高いなーって思っています。なぜかというと、全部自分で作らなければいけないからというのと、色々な部品を組みあせなければいけないからという事情があると思います。 他言語の様子を見るともっと簡単に作れそうな雰囲気を感じるので、じゃあ実際どうなんだということで学んでみようとなりました。

とはいえWebアプリのフレームワークはRuby on Railsを名前だけ知っているくらいでしたので、少し調べてみました。すると、どうやらPythonにもDjangoというフレームワークがあるらしい。結局Pythonを選んだのは最近流行ってるっぽいからとかそういうのが強いです。

環境

  • windows 10
  • Python 3.6.3
  • Django 1.11
    • 勉強している間に2.0が出てしまいました。
  • PyCharm

やったこと

Qiitaや公式のチュートリアルを実施しました。

①Qiita入門記事

qiita.com

②Django公式チュートリアル（日本語対応あり）

docs.djangoproject.com

③DjangoプロジェクトをHerokuにデプロイする

qiita.com

herokuへのデプロイは成功して、指定したURLを見るとローカルと同じように動いています。

身についたこと・感想

  • 結果： github.com

  • 初歩的なgit技術

    • とりあえずinitしてー、addしてcommitしてー、GitHubの方にレポジトリ作ってーのあたり
    • Pycharm使っていると.ideaフォルダが発生するので、それを.gitigoreに放り込む
  • フレームワークはめちゃくちゃ楽
    • 自動で管理ページが作られていておったまげた。
  • Heroku基礎
    • Procfileとかrequierment.txtとか
    • HerokuはPostgreSQLじゃないとうまくいかないよ、という謎の先入観がありましたが、Djangoのデフォルトのsqlite3でも普通に動いていそう

僕のツイッターのTLだとRuby on Railsの人が多くて、Django使っている・関心がある人どれくらいいるのかなって不安でしたが、つい先日の2.0リリースでDjango勢があぶり出されていったのが良かったです。

次はPythonそのものの学習かしら。

JJUG CCC 2017 Fall 参加日記 #jjug_ccc

Java イベント

JJUG CCC という、Javaユーザーのカンファレンスにいってきました。

JJUG 2017 Fall

プログラミングも経験浅く、Javaさわり始めて1年くらいですが、どれくらい理解できるかなと思ってやってきました。

■聞いたセッション

ユニットテストのアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て

うちたてりょーすけ (@b1a9idps) | Twitter

Slideshare

JUnitだったのをもうちょい短く書けるぜ！って内容だと思います。記述量とメンテナンス性が良くなるって話だけど、劇的に変わる感じではなさそう。

OCJP for good coding

slideshare

恥ずかしながらOCJTが何なのか知らなかったのだけど、Javaの資格のことでした。技術力とはコードを読む力だ、という主張を聞いて、読むコードが良いコードばかりだったらいいなと思いました。

劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜

slideshare

CIについてはあんまり関わったことがないので分からないが、どれが一番短縮に貢献したのか、あるいは全く貢献していないものがあるのか気になった。

Spring Security にできること・できないこと

Qiita

今回のセッションで一番興味があったところで、なおかつ最も面白かったです。Spring Securityの実装の解説は少なめでしたが、ウェブサイトの脆弱性について、デモを交えてわかりやすく解説していました。

新しいプログラミング言語の学び方　～HTTPサーバーを作って学ぶJava、Scala、Clojure～

スライド見つかりませんでした……。

特にLL言語の学習の場合、簡単なウェブアプリを作成することが最有力な学習法とされていますが、HTTPサーバーを作るのも有用ですよという内容でした。

僕の場合はDBとかHTMLとかも書きたいし大事だと思っていますが、プレゼン内で指摘されていたように、それが煩わしいと感じる気持ちもわかります。

発表者のノリがツイッターっぽいなと思いました。

■振り返って

ちょっとでも触ったことあるのは聞いててなんとなくわかるし、全く触ったことないのは聞いても全然わからないという当たり前の感触になりました。

ぼっちで参戦したので懇親会は行かずに帰ってしまったのですが、ややもったいない気もしたので次は友達作って行けたらなと思いました。

JUnit、Spring Secuirityについて学ばないとなーと思いました。

■おまけ

今回メモは手書きでとろうと思ってました。ところが、セッションルームには机がありません。こういう場合、太ももにノートPCを置いて下敷きにするとめちゃくちゃ書きやすいのでオススメです！！

PCでメモ取ればいいじゃんってツッコミはなし！！！！

以上です。

3分で読めるSQLアンチパターンまとめ #sqlap

書評 RDB

発売されてしばらく経ちましたがまとめました。

SQLアンチパターン

SQLアンチパターン

電子書籍はこちら https://www.oreilly.co.jp/books/9784873115894/

ご存じない方に概要を説明すると、DBを扱う際の「やってはいけないこと」集です。

まとめにあたっては、各章1行で終わることを重視して、アンチパターンのみを否定文の形式で記載し、解決策については省きました。

論理設計

章 タイトル 一言まとめ
1. Jaywalking 一つのフィールドにカンマ区切りで複数の値を格納するな
2. Naive Trees 再帰的に参照する親を直接参照するな
3. Id Required すべてのテーブルでId列を設定しようとするな
4. Keyless Entry 外部キーを避けるな
5. Entity-Attribute-Value 汎用的な属性テーブルを作成するな
6. Polymorphic Associations 複数テーブルを参照しようとする外部キーを作るな
7. Multi-Column Attributes Tag1,Tag2,Tag3...のような列挙のために複数の列を作成するな
8. Metadata Tribbles テーブルの行数を減らすために列やテーブルを分割するな

物理設計

章 タイトル 一言まとめ
9. Rounding Errors FLOATデータ型は避けろ
10. 31 Flavors ENUMデータ型は避けろ
11. Phantom Files 画像ファイルを必ずしも外部に格納するな
12. Index Shotgun インデックスを全くしない、またはテキトーに設定するのやめろ

クエリ

章 タイトル 一言まとめ
13. Fear of the Unknouwn NULLとその他の一般値を混同するな
14. Ambiguous Groups 単一値の原則に反するクエリを書くな
15. Random Selection データをランダムにソートするな
16. Poor Man's Search Engine パターンマッチ述語を使用して全文検索するな
17. Spaghetti Query 無理に一つのクエリにまとめるな
18. Implicit Columns Select * やめろ

アプリケーション開発

章 タイトル 一言まとめ
19. Readable Passwords パスワードを平文で保存するな
20. SQL Injection 動的SQLクエリの入力に対する検証を省くな
21. Pseudokey Neat-Freak 欠番は埋めるな
22. See No Evil 例外処理をおろそかにしたり、最終的に発行されたSQLを確認しようとしないのやめろ
23. Diplomatic Immunity データベース開発を特別扱いしてアプリケーション開発から切り離すな
24. Magic Beans データベースアクセスクラスをモデルクラスとして使用するな
25. 砂の城 サービスの長期的な安定稼働のための施策を怠るな

この書籍では一つのアンチパターンを簡潔にワンフレーズで言い表しています。すると、二人とも内容を身に着けている場合、以下のようにコミュニケーションを洗練できます。例えばジェイウォーキングの場合、

「このテーブルのこの列、データをカンマ区切りで複数入れられるようになっているけど、これって良くないよね。なんでかっていうとえーっと…」

↓

「このカラム、ジェイウォーキングだね」

補足

天元突破グレンラガン（ネタバレ）

とにかく気合と根性でなんとかなるタイプの熱血ロボットアニメ

しかし、このアニメの出来が良いところはこれでもかと燃えたぎる要素がある。

  • だんだん上がっていくスケール
  • テンポの良い展開
  • BGM
  • 合体
  • どんどん巨大化するロボット
  • 完璧な人間性を持ち合わせていたアニキの死
    • それを乗り越えていくシモン
  • どん底からの復活
  • 仲間の死を乗り越えて強くなる
  • 最終形態がタイトルと同一

とりあえずでかくなるのは単純だが結構有効だということがわかった。

第三部（七年後の前半パート）がすごい好き。ピンチ感がロシュの悲壮感のせいで最も強く感じたため。

若干ラストバトルで失速した感があったのがマイナスかな。「天元突破グレンラガン」の宣言が最高潮。

良作だと思います。

CodeIQ感謝祭に参加しました。 #codeiq39

イベント

codeIQ感謝祭に参加しました。

codeiq.jp

ちなみにこのイベントを知ったのはしがないラジオの湊川あいさんゲスト回です。

shiganai.org

パネルディスカッションや講演が合わせて5つありましたので、それぞれ感想を書こうと思います。

1. 多様化するエンジニアのキャリアパス、その先を考える

ここで僕が大事だと思ったことは一点、

「例え辛くても楽しく見えるように仕事しよう」

です。これはプログラマがなぜマネージャーを目指さないかという問いに対し、マネージャーが辛そうだからという答えがあることについての及川さんのコメントです。実際辛いかどうかは置いておいて、部下や同僚はマネージャーのことをしっかり見ているので、それを意識するだけでも違ってくると思います。

2. エンジニア採用担当者が読みたくなる職務経歴書のポイントは？

A:そんなものはない（AA略）

ここで身につまされたのは、「ツイッターアカウントなんてググれば分かるんだぞ、変なこと書くんじゃないぞ」という話です。

鍵を掛ける、公式っぽいアカウントを用意するといった対策もありますし、そもそも僕はキツい内容は書いてないので見られても問題ありません。

一方で、営業ガシガシやってます、戦略的に運営しています、なアカウントを見ると、こういう意識が大事なのかなあとちょっと思います。

個人的には、そのような運営方針のアカウントは人間味がないなと思いますが。

スライドも貼っておきます。

Three points to write resume that recruiters will want to read // Speaker Deck

3. スタートアップを支える、入社一人目のエンジニアの想い

題名の通りスタートアップに創業間もないころから参加して成功したエンジニアの話です。

この段階ではどのようなサービスを作っていくかが大事だということはもちろんですが、僕が重要だと感じたのは下記の点です。

・そのサービスを生み出そうと思った原体験は何か

僕はそういうの上手く言語化できてないので、やっていかないとなと思いました。

4. ヨッピーさんがインターネット広告の未来を探る

ここ1年くらいでヨッピーさんのファンになったので生で見れて良かったです。

スライドで紹介されたネット広告業界図（カオスマップ）が非常に興味深かったです。

ネット広告嫌い！ってざっくり切り捨てている人が多いなというイメージでしたが、ちょっとだけ認識が正確になった気がします。

5. 新しい言語、開発ツール、どれが使える？

最後の方なので疲れててあんまりメモ取れてなかった。

結局のところ、新しい言語・フレームワークを身につけるにはそれが求められている仕事に就く（もしくは作る）のが一番だという話がありました。

しかし、例えば仕事に就く場合、新しい技術とかをこれからやります！では信用力がないので、その技術である程度やれることを示すか、新技術を導入するのが得意だというアピールが必要だと思いました。

リンク

CodeIQ感謝祭に参加して #ドラレコ を初めてしたら思ったより楽しかった件 #codeiq39 - めも

I begin listening to a lot of Rebuild.fm episodes

実家で（自分用のPCがなくて）ヒマなので書きたかったブログを書きます。

友人がポッドキャストを始めたのが大きくて、

しがないラジオっていうんですけど、そこで初めてポッドキャストを聞くようになりました。

その影響で、かねてから噂は聞いていたRebuild.fmを聞き始めました。

最初は聖杯問答回やSHIROBAKO回などをピックアップしていたんですが、先月半ばくらいにエピソード1から聞き始めました。

初回は2013年2月なので、

現在までおよそ4年半にわたって続いていることになります。つまり大量のエピソードがあります。2017年8月25日現在、エピソード189まであります。めちゃくちゃ多いですね。通勤途中やぼーっとしたいときはいつも聞いているんですが、今60を回ったくらいです。今年中に最後まで行けたらなあと思います。

情報のシャワーという感覚がすごくあって、

プログラミング言語、開発ツール、働き方、マネジメント、セキュリティなど、話題は多岐にわたるうえ、1.5倍速で聞いているのでめっちゃ濃密です。雑談風の講義みたいな。

まあでも一番詳しくなるのは

Appleの動向ですね。WWDCの話は毎年数回のエピソードでするので頭に入っていきます。今iOS8まで来て現在のiOS10まであと二つ！

現在とのギャップを感じられるシーンも

面白くて、列挙すると

  • Swift登場とObjective-Cの終焉
  • Goの隆興/流行
  • Dockerの登場
  • 電王戦

あたりですかね。もちろんiPhoneなどのデバイスのバージョンもあります。

ありがたいことに最近は落ち着いた公開ペースなので、どんどん聞いていきます。

Digitize my (lonely) life

家計簿アプリのマネーフォワードを導入して1月弱経過したのでそれについての所感です。

なぜ導入しようと思ったか

  • ひとり暮らしに伴い支出が多様化するのを把握する。

  • とりあえずいちばん有名なアプリを導入してみた。

導入前

導入にあたっては銀行口座等のデータを連携する必要があります。

僕はスマートフォン含むWEB上でそのようなデータをやり取りするのに抵抗があってやっていませんでしたが、今回は連携しました。

口座残高くらい別にバレてもいいや～という感覚もあります。

導入後の感想

良い点

  • 食費が月いくらくらいかかっているか把握できるようになった。

  • 節約志向になった。

  • ICカードを用いた交通費のデータが別アプリを使えばほぼ手間いらずで取得できる。

悪い点

  • レシート撮影が全く使い物にならない。

  • 1日でも記録を忘れるとリカバリーが困難になる。

    • 習慣化が強制されるので悪いばかりでもない気もする。

家計簿アプリの得意分野・苦手分野

家計簿アプリの得意分野は何か。それは、様々な金融資産の情報を連携し、収支を算出することだと思います。

逆に、従来の手書きの家計簿のように、支出を細かく分類して、何にいくら使ったか正確に把握するのには向かないでしょう。

長所の方は、口座の入出金を自動で入手してくれることに起因します。僕は普通預金口座しかもっていないのでありがたみを感じにくいですが、証券口座や定期預金など、いくつかの種類の資産を持っている場合はかなりありがたい存在だと思います。

短所の方は、支出の分類を手動で記入しなければならないことから来ています。例えば、Suicaでコンビニの商品を買うと、分類不明とされるため、何を買ったかを思い出して手動で更新しないといけません。

Digitize my life

興味深いと思ったのは、これらのアプリを最大限に生かそうと思った場合、支払いに関する生活スタイルと、お金に対する考え方を変えるよう促されることです。

具体的に言うと、

  • 支払いはなるべくクレジットカードで済ます。

  • 収入や支出は総額さえわかればよく、具体的に何に使ったかはそこまで気にしない。

  • 証券投資をする。複数の口座を持つ。

なお、自分の資産を増やしていく上で、収支の正確な把握が重要であることは広く知られていることだと思います。