Make組ブログ

Python、Webサービスや製品開発、ライブラリー開発についてhirokikyが書きます

日本語アンチパターンその1「日本語ぶった切りプログラム」

ドキュメントやサポート、チャットでの説明で日本語を書く機会は多いと思います。 「プログラムについて日本語で伝える」ノウハウは、単に日本語の美しさだけではない部分もあるので難しい点です。

今日はその1つ、「日本語ぶった切りプログラム」というアンチパターンを見つけたので共有したいと思います。 アンチパターンとして名付けて、伝えやすく・覚えやすくしようという目論見です(今後の僕自身のためにも)。

アンチパターン:日本語ぶった切りプログラム

このアンチパターンは、日本語の文の途中にプログラムが入ってしまうアンチパターンです。 とくに「以下のように、」や「このような、」のあとにプログラムの引用を文中に書いてしまって、日本語が途中で切れてしまうものです。

以下がアンチパターンの例です

time_it 関数では以下のように、

def time_it():
    …
    …

関数の冒頭で処理を実行しています。

「以下のように、」の後にプログラムが貼られることで日本語が途中で切れてしまっています。 書き手の意図としては「この関数では以下のように〜『ここでプログラムを指差す』」というイメージはわかりますが、 読み手としてみるとプログラムのどこに集中して読めば良いのかが分かりにくくなります。

問題

以下のような問題が考えられます。

  • プログラムを読ませられる意図が事前に分からないので、どの点に注目して読めば良いのか分かりにくい
  • プログラムを読んでいる間にも、プログラム前に説明された日本語を記憶しておく必要があり疲れる

改善方法

プログラムを貼って説明したいこと・伝えたいことを、まず1文で表現してからコードを貼りましょう。

time_it 関数では以下のように、関数の冒頭で 〜 という処理を実行しています。

def time_it():
    …
    …

time_it 関数の冒頭で 〜 することによって、〜の意味があるためです。

* 〜するので、〜しやすい
* 〜するので、〜がわかりやすい

細かい説明や意図の説明は、プログラムを貼った後にすると良いと思います。 逆にプログラムの前に説明しすぎると、それはそれで前の文を覚えきれなくなってしまうので避けましょう。

アンチパターン日本語ぶった切りプログラム でした。

楽するための、日常動作のバッチ処理化

どうも、こんにちは id:hirokiky です。

今日は日常生活する中で僕がやってみていることを話します。

完全に僕理論なので、「最近そんなことやってるんだ」くらいに楽に聞いてください。

習慣になると色々と楽

id:haruo860 さんと話していたときに、「習慣になってしまえば強い」という話題になりました。 何か動作をするときや決めるときに、習慣になっていれば迷いがなくて「楽」になる。 大切なことに集中できるので強いという話でした(だったと思いますが、あってますかね、はるおさん)。

そのとおりだなぁと僕も思っていて、例えば朝起きて出社することは大変です。 これは誰しもたぶんかなり辛いことだと思います。

「今日は遅刻しちゃおうかなぁ」「何着ようかなぁ」「顔は洗わなくていいかなぁ」と毎朝だらだらしてしまう。 でもそこが習慣になっていれば余計な考えなく済ませられます。 余計なエネルギーを使わずに超強大な定期タスク(朝出社するとか)をこなせるということです。

自分の中でココ最近試していた

僕なりにココ最近気をつけて実践していたことの話をします。 これは何かの本に書いてたことではなくて、単にここ数週間自分の中で試していることです。

「何かに影響されたんじゃないの?」ということは無いので安心してほしいのと、 実践するときも人には気づかれないように試せるので、「アレに影響されたんでしょ」と言われる心配もありません

頭の中だけでやります

やりかたは簡単で、日常やる動作を頭の中で「まとめておく」ことです。 対象になるのは以下

  • 毎日やる動作
  • だらだらしてしまう動作

オススメは「朝起きた瞬間〜着替え終わるまで」です。

やることは3つだけです:

  • 頭の中で動作順の流れを決める
  • 全く同じように自動でやる
  • その動作中は他のことをしない

紙に順序を書き出したりはしません。 ポイントなのが 何をやるかでなく、どうやるか いかに 無思考で、自動で、意思決定なしに できるかが重要。

例えばここ数週間で確立した僕の「朝起きた瞬間からの動作」

  • 朝起きる
  • 顔を洗う
  • 歯を磨く
  • トイレに行く
  • 着替える

文字に列挙すると何ともないですが、決めておかないと日常どうしても「もうちょっと寝ようかなぁ」とか思ったりSNSをチラチラ見たりしてしまいます。 この「着替える」まではそういったことをせずに、機械的にやります。

僕の中では 日常動作のバッチ処理 と呼んでいます。

各処理を意思決定なしにできることが大事

単一の処理、例えば「着替える」をとっても、自動でできるようにしておく必要があります(MUST)。

クローゼットの順番を整えておいて、何でもすぐ着れることだったり、服は着合わせしやすい服ばかり用意しておくとかです。 (例えば僕は着ない服をクローゼットから除外しました)。

バッチの設計は最小で

バッチ処理は短く終わるほうが良いですよね。

それと同じように日常動作のバッチ処理も短くしておきます。 例えば朝であればそれ以外の動作、ゴミ出ししたり、水槽の様子を見たりもありますが、 それはこのバッチが終わった後にやります。

ゴミ出しとかは曜日や時間という外部要因が関係して、かつ判断や分岐が必要になるのでバッチ処理からは除外したほうが良いです。 SNSやメールを見るのも、バッチ処理後にやったほうが良いです。

  • 日時、曜日
  • 判断が必要な動作、判断を迫られかねない動作
  • 他人、ペット
  • SNS、メール、Slack

こういった要因はバッチ処理の複雑化につながります。 とりあえず朝目が覚める〜朝出社するまでの最小構成(かつ気が重い場所)を、バッチを走らせるだけで完了するようにしておきます。 また外部要因にすぐ応えられるようにも、バッチは最小構成の設計にしましょう。

やろう!としないで良い

普段、自分がすでにやっている流れで、バッチとして意識するようにするだけで良いです。

色々試す中で、「化粧水をはたく」など「必須ではないがやっておきたい動作」を増やすと途端にやる気がなくなりました (いつもの朝起きられないモードに突入する)。除外をオススメします。

バッチは最小構成で、普段やっていることをまとめるだけで良いです。 その代わり、確実に自動でできるようにします。

バッチ化はどうでも良い意思決定の自動化

僕はもうずっと5年10年くらい朝食にカロリーメイトを食べてるんですが、これは「朝食が決まってないときはカロリーメイトとコーラ」と決めているからです。

とにかくどうでも良いことは事前に決まっていると色々楽だなぁと最近気づいて、ここ1ヶ月くらい自分で実験して日常動作のバッチ化をやってみています。

気持ち的な面が大きいですが、朝起きてからの流れが気楽になります。 ぜひ、ちょっと意識するだけで済むのでバッチ処理化をしてみてください。

まだ僕の勝手な理論でしかないので、実践してみた報告やコメントがアレば直接伝えるか、ブログに書いてみてください。

おまけで、意思決定についての考え

実家を離れたとき、何でも自分で決められることが本当に嬉しかったことを覚えています。 でもそれは逆に、自分で何でも決めないといけないということですよね。 僕の場合はそれは苦ではなかったんですが、ココ最近は色々と大事な意思決定が増えてきて、細かい日常の迷いみたいなのを無くしたいと思っていました。

例えば製品づくりやイベント開催などは意思決定が大事です。 やることとやらないこと、それを決めて線を引くこと、集中することが良い製品を作るのに大切です。 PyQ を作っていると、とくにそれを感じます(まぁ小さいチームだからというのもありますが)。

最近大事なことを考える時間と必要性が指数的に増えてきて、正直いうとココ数年は大変です。 なので日常の細かい迷いくらいは無くして、その瞬間くらいは脳みそを休ませてあげたいんですね。

何かを作るときは「人との調整」でなく「意思決定」することが大事だと思います。 とても大事なので、大変だからといってその機会を捨てる気はないです。 それ以外の余計な迷いはドンドン捨てていきたい、そんな今日この頃の、セキララトークでした。

Ubuntu17.10にしたら日本語が打てなくなった問題を何とか解決した話

f:id:hirokiky:20171021190512j:plain

雑メモです。

Ubuntu16.04からUbuntu17.10にアップグレードしたら日本語が打てなくなっちゃいました (まぁよくある話です)。

平たくいうと fcitx とIMの環境変数周りの設定がうまくいってなかったということで、色々場当たり的に直してたら動いて良かったという話です。

あんまりアテにならない情報です 間違ってたら教えてください。

まず「入力メソッド」 im-configfcitx を設定するも状況改善せず。

im-config

GUIから設定して再起動するも変わりませんでした (単に im-config が設定している先のファイルを読んでないとか、 im-config が古いとかもありえます)。

とりあえず fcitx-diagnose で状態を確認。

fcitx-diagnose

以下の環境変数周りでエラーがでているようでした。

  • GTK_IM_MODULE
  • QT_IM_MODULE
  • XMODIFIERS

(間、 ibus をアンインストールしたりも試していました)

XMODIFIERSやQT_IM_MODULE環境変数の設定先

Ubuntu 17.10では /etc/environment環境変数を設定しました。

export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

Ubuntu17.10からWaylandで動いているそうで、 ~/.xprofile を読めないそう。 なので /etc/environment で設定しました(これって何かマズイとかありますかね。。?)。

とりあえず .xprofile とか .xinitrc とか .xinputrc とかに設定してみていましたがダメでした。

ArchWikiを参考に設定しました。

非デスクトップ環境

以下の行をデスクトップのスタートアップスクリプトファイル (GDM, LightDM, SDDM を使っている場合は .xprofile もしくは > .profile、startx や Slim を使っている場合は .xinitrc、Wayland を使っている場合は /etc/environment) に追加してくださ> い。この設定で、fcitx は gtk/qt のインプットメソッドモジュールを使うようになり xim プログラムをサポートします (必要なインプットメソッドモジュールがすでにインストールされているか確認してください)

まじっすかーということで、 /etc/environment に設定しました。

GNOME/Wayland 上での Fcitx の利用

Wayland は ~/.xprofile に保管された環境変数を読み込むことができないため、Wayland 上では Fcitx は正常に動作しません。Fcitx を利用するにはディスプレイマネージャから Xorg セッションを起動してください。

https://wiki.archlinux.jp/index.php/Fcitx

かなり場当たり的にですが、とりあえず解決して今も日本語を打てているという状態です。

僕のツイート

あとで見返して笑えそうなので残しておきます。

まとめ

ArchWiki日本語情報ほんとうにありがとうございます! IMまわりとかは、英語での情報があんまり見つけられなかったので助かりました。

逆に今、消費的な趣味を大切にしてみる

「趣味」という言葉に対してのハードルが日に日に強くなっていると感じませんか。

「このレベルでは趣味じゃないから」、「終わったら内容をまとめておかないと」、「まだここがコンプできてないな」など、 単に「趣味」と言ったときに付随する感情やレベル感、義務が大きくなっていると近ごろ自分の中に感じます

もちろん頑張れることや何かを生み出すこと、達成することは素晴らしいことです。 ですけど最近は人生の99%がそういった頑張りの必要な時間になっている気がしているので、逆に、完全に消費的な趣味を考えてみました。

対象の人、対象でない人

最終的な目標や、生産的なこと、やりたいことはすでに持っている人と共有する考え方です。 「やってること多すぎてるかな。。。」「趣味へのハードルが高いなぁ」と思う・思ったことがある人です。

僕がまとめる内容はより生産的で健やかな人生を送るために書いています。 単に「何もしない優しい世界になろうよ」というつもりはありません。より生産的かつ心地良く生活や仕事をしたいという考えがまずあります。

静かな趣味

「消費的」というと語弊があるので、これからは「静かな趣味」と呼びます。 より生産的になれるように、あえて静かな趣味を考えてみます。

静かな趣味は完全に 静か でなくてはいけません。 趣味中にも頭の中で「ここまでやりたい」、「こうでなくては〜いけない」という考えは捨てるようにします。

静かな趣味では、以下のことを しません

  • No Goal: 目的を持たない
  • No Sharing: 共有しない(まとめない、アウトプットしない)
  • No Review: 批評しない(分析しない、コメントしない
  • No Agreement: 合意しない(一人でできる。社会に反しない)
  • No Planing: 計画をしない
  • No Choosing: 決断をしない(必要無い、少ない)

以下のことを します

  • 自分が気楽に楽しむ

自分が癒やされる、気楽になる、焦燥感がなくなるためにやります。

例えば私なりに、自分の好きなことで静かな趣味を考えてみました:

  • 音楽をただ聴く
    • とくにお気に入りのLinkinParkやGreenDay、BobDylanをただただ聴く
    • not「僕はロックが好きだから一通りのアーティストは聴いておこう」
    • not「ついでに英語の勉強にもなるかな、意味を調べよう」
  • 料理をする
    • 新しい料理でなく流れでできる煮物や炒め物をただ作って食べる
    • not「最高のチャーシューを作ってみたい」
    • not「米はミネラルウォーターで美味しさが変わる、どれが良いだろう」
  • 風呂に入る
    • 入浴剤を適当に入れてただ入る
    • 風呂あがりにホットアイマスクでもする
    • not「あそこの銭湯にも行ってみたかった。行ってみよう」
    • not「日本の名湯には一通り入っていないとね」
  • バイクでいつもの道を走る
    • 知ってる道をただ無意味に走る
    • not「友人とツーリングの計画をたてよう」
    • not「ヒザが擦れるようになりたい」
  • 知ってるゲームをする
    • 脳みそを動かさず、どこまでクリアしたいかも考えない
    • not「この新作をプレイして感想を書こう。ぜひプレイしておきたい」
    • not「スコアは3000以上いかないと、やったとは言えないだろう」
  • ペットをただ眺める
    • not「一通り飼育設備は揃えておきたい」

こうやってみると、自分が 趣味 としていることでも自分の中でのハードルが勝手に上がったりしていることに気づきます。 ささやかな瞬間にも頭の中の「頑張り」や「自己顕示」がでてくるので、それの無いようにします。

すでにある趣味でも「意識の高い」要素を抜いていくことで、気楽な趣味にできそうです。 僕はプログラミングが大好きですが、どうしても「目的」がついてくるので静かな趣味からは外しました。また、前提として前準備や注意点が多いツーリングなどもそもそも「静かな趣味」には向いてないようです。

「頑張り」を抜いて静かな趣味に変えるには、この辺りを意識してみるといいかもしれません:

  • 「コンプリート」をやめる
  • 「こういうものを作って便利にしたい」、「勝ちたい」、「今日はここまでいきたい」という目標をやめる
  • 「ちゃんと参加しないといけない」、「毎日続けよう」という義務感をやめる
  • 「こんなことやっています」、「新しいこの曲はここが最高なのでオススメです」などSNSへのシェアをやめる
  • 始めるまでの準備や調整がいることは一切やめる

この視点で考えるだけで気楽な趣味に変えられるんじゃないでしょうか。 せっかく見つけた自分の好きなことです。その好きなことに潰されないようにしたいものです。

まだ僕なりにも考えてみている段階ですので、間違っている点や他にも良い視点が今後でてくるかもしれません。 何かあれば、ぜひ教えてください。

心の疲れをとる技術という本にある「静のストレス解消法」

僕のお気に入りの本に「自衛隊メンタル教官が教える 心の疲れをとる技術」という本があります。 この本は、実際に自衛隊のコンバットストレス教官をしていた下園さんという方が、事故や災害、ショックな状況に対面する自衛官心理的ケアに関わる中で培った方法論を紹介する本です。

「心の疲れをとる技術」でも「静」のストレス解消法を持つことが大切だと書かれています。

ポイントは、「動」と「静」のストレス解消法を持つことだ。特に「静」のストレス解消法を準備することを強調している。 エネルギーが低下している第2段階以降は、活発に活動する「動」のストレス解消法は、確かに快感も大きいかもしれないが、その活動のための疲労が大きく、結果的にムリが深まっていく。 例えば、疲れている人が、休日に趣味のサッカーをしたとしよう。その時は楽しいかもしれないが、次の日はもっと疲れている。 ドライブや海外旅行なども、かなりのエネルギーを使う。

「第2段階」というのはこの本で語られている心の疲れの3段階の2段階目ということです。

夜更かし系のストレス解消法も、第2段階以降はマイナスが大きくなる。アルコールが加われば、さらによくない(アルコールについては、後述)。 第2段階以降は、静のストレス解消法を選択するべきなのだ。 ヨガ、軽い散歩などは、疲労回復に効果があることが証明されている。 話をするという作業は、悩みの整理になるだけでなく、静のストレス解消法でもある。 (中略) 他にも、森林浴、庭いじり、俳句や短歌、囲碁や将棋などの頭脳ゲーム、読書、音楽(聞く、奏でる)、映画鑑賞、プラモデル作り、料理、日曜大工などの単純作業、何か作り出す作業などは、心に栄養を与える。 ただし、オンラインゲームやマージャンなどのギャンブルは、なかなか抜けにくいし、夜更かしになりがちだ。お金を使いすぎたりすると、後で自責感が大きくなるというマイナスも大きい。注意が必要だ。 このような、静のストレス解消法は、動のストレス解消法に比べて、瞬間的な快感が少ない。しかし、続けているうちにじわじわとその良さがわかってくる。 だからこそ、第2段階までの比較的元気な時に、「育てて」おかなければならないのだ。

あまり詳細に「静」のストレス解消法については書かれていませんが、イメージは静かな趣味かなと思います。 こちらの本も良い本ですので、「ケガした時の保険」的に読んでおくと良いと思います。

引用元: 「自衛隊メンタル教官が教える 心の疲れをとる技術 下園壮太」1章より

自分の趣味は何だっけ?どんな姿勢でやっていたっけ?

最近こそ「趣味」と言えるまでのハードルが高くなっている気がします。 SNSの普及で専門的なコミュニティに関わりやすくなったからでしょうか。より高い「趣味性」や「SNS映え」が大切になってきている気がします。 また「好き勝手なセリフや批評を控えて、正しい意見をやり取りすべきだよね」という良い流れも感じます。ですが逆説的に、好き勝手やれる・言える隙間が少なくなっているようにも思います。

今ある静かな趣味は何でしょうか。 単に好き勝手できて、誰にも言わない趣味。 少し気を抜いてできるものを考えてみるのはどうでしょう。

自分の好きにできる趣味なんだから、本当に何にもならなくても良いと思います。 そのリラックスできる時間で心身が回復して、頑張りたいときに頑張れるようにしておきたいです。

Pythonで何が作れるの?その疑問に答える本がPythonエンジニアファーストブック

f:id:hirokiky:20170929114020j:plain:w500

こんにちは、埼玉のジャックニコルソンです。 シャイニングのつもりがよくあるYouTuberっぽくなった画像がこちらです。

さて、Pythonエンジニアファーストブックが発売されました!

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

どんな本なの?と聞かれることがありますので、紹介します。

Pythonで何か作ったこと、ありますか?

そんなことありますよね。僕もWebばかりだったので、つい1、2年前までPythonでのデータ分析は触ったことすらありませんでした。

一通りPythonでできること、作れるものを知っておきたくはないですか?

  • Pythonで何ができるかだいたい分かっている 。できないことも分かっている。
  • データ分析Webアプリの作り方スクレイピングのやり方 など一通り知っていて、作ってみて動かしたことがある。

そうなれる本があります。 それが、Pythonエンジニアファーストブックです。

他の言語を知ってる人向けの本です

プログラミング自体全く全然分からない方、ごめんなさい 。この本は他のプログラミング言語をほんの少しでも知ってる人に向けた本です。

ですので、言語の説明やライブラリーのインストール方法などは必要最低限に絞っています。 逆に言うと、他言語を少しでも知っている、PCに慣れている人には簡潔で分かりやすい内容になっています。

そして、データ分析スクレイピングWebアプリ開発Pythonでのオススメ開発環境 などたくさんの内容が盛り込まれています。 もちろん、PythonのトレンドやPythonの基礎、インストールや導入方法、プログラミング開発の基本なども網羅されています。

初心者の人には説明が不十分の場合があるかもしれません。ですがその代わりに、この一冊でPythonの広い広い世界をぎゅっとまとめて体験できます。

(プログラミング自体分からない方が一通りPythonを勉強したいときは PyQ をオススメします)

自分で各ライブラリーを調べる必要がありません

この本にはPythonの基本はもちろん

  • Git
  • Pycharm
  • Sphinx
  • Pandas
  • JupyterNotebook
  • BeautifulSoup
  • Requests
  • Scrapy
  • Django

などが盛りだくさんで登場します。

もしそれらすべてを知ろうと思うと、インストール方法はもちろん、基本的な使い方やチュートリアルを調べるのは大変だとは思いませんか。 公式サイトやQiitaやブログを色々調べて、「これが良さそうかなぁ」という情報を探すのも大変です。

このPythonエンジニアファーストブックなら、それら すべてのインストール方法や基本的な使い方、実際の作り方が網羅されています

調査の時間で長いと1、2時間かかったりします。Pythonエンジニアファーストブック1冊分で、合計で10時間ほどの調査時間を短縮できるんじゃないでしょうか。

もちろん、この本を中心に分からない点は調べていただく必要があります。 ですが基本的な使い方をマスターしたうえで学んでいただくので、間違いなくその時間も短くて済みます。

スクレイピング、データ分析、Webアプリを作りながら学べます

さらに、本の中で一気通貫して 「レゴのサイトから情報を取って解析、Webで表示する」という課題を実際に作りながら学べます

プログラミングを学んでも身についていないということがありませんか? 作りながら学べて、しかも一通り抑えておきたい分野の内容を身につけられたらすごいですよね。

Pythonエンジニアファーストブックなら実際に作りながら学べる ので、Pythonやライブラリーの要点を抑えつつシッカリ身につけられます。 また、勉強のために自分で課題設定をしたりアプリを設計する必要もありません。

さらになんと、 すべてのソースコードGitHubで公開されています 。 正直これだけを参考にプログラムを読み進めてもかなり勉強になるんじゃないでしょうか。

github.com

もちろん本を買って勉強すれば効果や効率は高くなります。

未来のハッカーにもぜひ、体験いただけると嬉しいです。

要らない人には要らない本でしょう

言ってしまうと、Pythonでのスクレイピング、データ分析、Webについてよく知っている人には必要ない本でしょう。 また、全くのプログラミング初心者という方には厳しい内容だと思います。

ですので「ぜひどんな人でも買ってください」とはあんまり思いません。

ですが、 他のプログラミング言語をやってPythonに興味がある人 や、 Pythonを知っているけど知らない分野を体験したい人 にはオススメしたい一冊です。

前の版?全く違う本です

実は、この本は「Pythonエンジニア養成読本」という本を元に書かれた本です。購入いただいた方もいるかもしれません。 「同じ内容なら要らないかな」と思われるかもしれません。

ですがそれは違います。

こんな内容を学べます。

  • 1章 Pythonの動向
    • 最新のトレンドにアップデート
  • 2章 最低限知っておきたいPython言語の基本
    • 最新のPython3.6にアップデート。インストール方法も修正、言語の内容も追加修正
  • 3章 開発環境とチーム開発
    • 最新に各種アップデート。最新の仮想環境の作成方法など、ハマりどころも回避しています
  • 4章 スクレイピング
    • 完全書きおろし
    • 課題設定から アプリケーションまで新規に作っています
    • スクレイピングとは?」から学べます
  • 5章 PyData入門ガイド
    • 新規の課題に合わせて大幅修正、アップデート
    • 実際に4章で取得したデータからデータ分析を学べます
    • 販売されているレゴのデータから、ピース数と値段の回帰を求めたりできて面白いです!
  • 6章 Webアプリケーション開発
    • *完全書きおろし
    • 以前あったものはすべて捨てて、今回の課題に合わせてDjangoで書き直された大作です
    • Djangoアプリの設計から、DBの設計まで作っています
    • 取得したレゴデータを取り込んで、管理できるWebアプリを作れるようになります
    • 著者間のレビューで相当議論したので、かなり ノウハウが詰まったDjangoアプリと内容 になったと思います

内容からコンセプトなど全く新しい本となっています。

前回の「Pythonエンジニア養成読本」は、ムック本として全体をつまみ食いする雑誌的な面がありましたが、今回のPythonエンジニアファーストブックは本の体裁として大きく生まれ変わりました。

この本のお話をいただいとき、「本の改訂」という名目だったので気軽にやるかーと参加させていただきましたが、新しい本を作りあげる話だとは思いませんでした。。大変でした。。。w

300ページを超える厚みです

300ページを超える、けっこうな厚みのある本です。 Pandas、Scrapy、Djangoを学ぶ内容についても、実際の課題に取り組みながらプログラムを作る濃い内容になっています。

f:id:hirokiky:20170929102522j:plain

しかも、Scrapyで取得したデータをPandasで操作したり、Djangoで表示したりと章の間で課題が一貫しているのでかなり楽しめる内容です。 また、本の中にあるプログラムはすべてGitHub公開されていますので、このプログラムを読むだけで十分勉強になるような内容です(もちろん、本を買って読めばさらに効果的かつ時短になります

300ページという厚みは、今、僕の家の中で探したものだと「サーバ/インフラを支える技術」と同じくらいの大きさ、厚さです (上の写真がそれです。サーバ/インフラを支える技術は昔僕がお世話になった本です)。

内容の十分さを感じてもらえるのではないでしょうか。

Kindle版で、今すぐ始められます

Pythonエンジニアファーストブックには Kindle版もあります

今すぐこの下のリンクから購入いただければ、今すぐ、Pythonの世界を歩み始められます。

他のプログラミング言語は知っているのにPythonは知らない、Pythonは知っているけど分野が限られてしまっているなという方、ぜひ、Pythonエンジニアファーストブックで作りながらPythonの広い世界を体験してください

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

Pythonって便利で楽しいな、こんなものも作れるんだ、と感じてもらえると嬉しいです。

PyConJP2017で発表したり、PyQのブース出展したり、本のサイン会をしました

IMG_4090

9月8日から10日にPyConJPに参加して、発表したり、PyQのブース出店したり、チュートリアル講師したり、本を売ったりと色々やりました。

pycon.jp

発表

PyConJPで発表するのはこれで6回目で、2012年から毎年Djangoについての発表をさせてもらっています。

今年の発表はとくに、かなり気合をいれて準備、練習をしました。 というのも、今年はプロポーザルもとても多くて、発表の枠も例年より少なく、発表がかなり狭き門だったからです。

発表の内容は、Djangoでアプリケーションを作る時の認可についてです。 パーミッション関連のハンドル方法やライブラリーの紹介をしています。

僕が作ったdjango-keeperというライブラリーの紹介もしています。 https://github.com/hirokiky/django-keeper/

資料はこちらです。

発表中の写真も撮っていただきました。 ありがとうございます!

IMG_4300

時間としてはまるまる10日くらいはドップリ使って事前準備、資料準備、発表の練習をしていました。 仕事もあり執筆もあり大変な中でしたが、発表の質はイベントの質とも言えるほどだと思いますので頑張りました。 当日は部屋いっぱい(100,200人くらい?)の方に聞きにきていただいて嬉しかったです。 発表のあとで、パーミッションなどについても色々話せて僕自身学びがありました。

ブース出展

PyQ のPRのためにブースを出展していました。

この日のために新しく機械学習、Pandas、Web APIスクレイピングを学習できるコンテンツをドンドンと追加しています。 またJupyterNotebookを実際に動かして学べるようにもしていました。

ここ半年はかなりハイペースに開発やコンテンツ充実をしていましたし、トラブルなどもあって体力的にも精神的にもかなり疲れましたが、ブースでお客様に喜んで貰えたり、すごい!勉強したい!と言っていただいてとても嬉しかったです。

9月8日のチュートリアルでもPyQを使ってのチュートリアルBeProudとして提供しましたが、そこでもチュートリアル自体とPyQがご好評で嬉しかったです。

あと、カレーメシ先輩に内部の話をしていて、これはすごいと褒めてもらったのも嬉しかったです。

最後まで諦めずに、投げ出さずに頑張って良かったです。

これからもPyQ をもっと良いものにして、より多くの人がPythonのプログラミングを身につけられる、仕事にできるお手伝いができればと思います。

pyq.jp

本のサイン会

著者として関わった「Pythonエンジニアファーストブック」のサイン会も開きました。

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

かなりの盛況で、たくさんサインしました。 来てくださった方、買ってくださった方ありがとうございました!

ぜひ、Pythonでこんなこともできるんだなぁと知ってもらえると嬉しいです。 私は2章を担当しています。フィードバックなどあればお気軽に教えてください。

この本もまた一苦労ありましたが、レビューを何度も繰り返して、率直な意見を交わしてかなり良い本になったと思います。 初稿からの怒涛のレビューは本当に著者みんなでがんばれたなぁと思います。 これも、最後までちゃんと良い仕事ができて良かったです。

f:id:hirokiky:20170910200021j:plain

またPythonエンジニアファーストブックの読書会の企画もしておりますので、開催する際はぜひ参加いただければと思います。

あと、一緒にサイン会をやっていたJupyter実践入門を買ってサインをもらいました!

f:id:hirokiky:20170910200028j:plain

商品はこちら。

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

楽しかった様子

あとはPartyで色々お話できて楽しかったです。

Keithと僕。 1,2年ぶりにPyConJPに来てくれて、久々にお会いできました。

f:id:hirokiky:20170910200008j:plain

肉を食べるaodagさん

エッシャー感のあるaodagさん

PSFボードのYounggunとaodagさんと僕。

f:id:hirokiky:20170910201219j:plain

Justusと僕。楽しそう。

f:id:hirokiky:20170910200038j:plain

本当にイベントでも楽しかったです。 今回はBreakの時間が多かったのか多くの人と話せたのがとても良かったです。

まとめ

PyQ や僕の発表や本がお役に立てれば嬉しいです。 ですがとにかく、今年は本当に疲れきってしまったので少し休みをとりたいなと思います。

またどこかでお会いしましょう!

DjangoでDB非依存に権限管理できるライブラリーdjango-keeperを作りました

f:id:hirokiky:20170903164740p:plain

Djangoで権限管理ってどうやっていますか?

Django自体が持つGroupやPermissionはイマイチ業務では使えないというのが実際のところなのではと思います。

そんな悩みを解決するために django-keeper というライブラリーを作りました。

こんな悩みに:

  • DBで権限を管理したくない
  • 権限を見通しの良いリストやマッピングで定義したい
  • ModelやUserに依存しない グローバルで汎用的な権限も扱いたい
  • ViewやTemplateでも使いたい

django-keeperって?

以下のようにACL(AccessControlList)というメソッドによって「権限」を決定します。

from django.conf import settings
from keeper.security import Allow
from keeper.operators import Everyone, Authenticated, IsUser


class Issue(models.Model):
    author = models.ForeignKey(settings.AUTH_USER_MODEL)
    ...

    def __acl__(self):
        return [
            (Allow, Everyone, 'view'),
            (Allow, Authenticated, 'add_comment'),
            (Allow, IsUser(self.author), 'edit'),
        ]

これで、以下のような権限を決定します。

  • すべてのリクエストには "view" 権限
  • 認証ユーザーには "add_comment" 権限
  • この Issueauthor で認証している場合は "edit" 権限

というように __acl__ メソッドによって、リクエストがこのモデルに持つ権限を決められます。

Viewで使おう

以下のようにViewで使います。

  • @keeper デコレーターを適用
  • 第一引数: 必要な権限
  • model=引数: Viewの対象のモデル
  • mapper=引数: モデルを取得する上限を返す関数
    • 引数: View関数と同じ引数
    • 戻り値: objects.get(id=issue_id) のようにキーワード引数として渡す辞書
from keeper.views import keeper


# Model Permissions
@keeper(
    'view',
    model=Issue,
    mapper=lambda request, issue_id: {'id': issue_id},
)
def issue_detail(request, issue_id):
    request.k_context  # 取得したModelが取れます。
    ...

これで @keeper が自動で Issueインスタンスを取得して、リクエストが "view" 権限を持つかをチェックします。 権限が無い場合は403となります(@keeperon_fail= 引数で権限が無い場合の挙動も変更できます)。

また、 request.k_context@keeper が取得したオブジェクトが取れます。

Operator

ACLに設定した Authenticated などはOperatorというもので、リクエストがこの条件を満たすときに権限を追加したりできます。

例えば、リクエストが認証済みの場合 "view" を付与。

    (Allow, Authenticated, "view"),

このOperatorというものは keeper.operators 内にいくつかあります。

自作のOperator

自作する場合も簡単で、Operatorは単に Callable[[HttpRequest], bool] なのですぐ作れます。

例えばIPアドレスからのアクセスかどうかを判定するOperatorはこうなります。

class IsIP:
    def __init__(self, ip):
        self.ip = ip
        
    def __call__(self, request):
        return request.META.get('REMOTE_ADDR') == self.ip

この自作OperatorもACL内で使えます。 自社のIPアドレスからアクセスした場合に強い権限を与えるようにしておくなどできそうです。

MY_IP = "..."

class Issue(models.Model):
    def __acl__(self):
        return [
            (Allow, Everyone, 'view'),
            (Allow, IsIP(MY_IP), 'edit'),
        ]

このように django-keeper はUserに依存しない条件(今回はIPアドレス)なども使って権限の管理ができます。 また、Operatorという形で「リクエストが何者かを判別する処理」と「権限」を分離できるので変更に強いですし、見通しも良いです。

他にも

django-keeper は他にも

  • モデルに依存しないグローバルな権限を扱えます
  • テンプレート内でも has_permission という条件を使えます
  • 権限のないリクエストの場合の処理を変更できます
  • 権限のDenyも設定できます

詳しくは以下から見てみてください。

PyConJP2017で発表します

来る PyConJP 2017 でも django-keeper を交えた発表をします。

発表の内容:

  • Djangoでの権限管理をする定石
  • 検討したライブラリー
  • django-keeperの紹介

をします。 以下の日程ですのでぜひ来てください。

要注意

django-keeper はまだベータというレベルのライブラリーです。

本番環境にガッツリ導入するというのは避けたほうがいいです

導入する場合は、権限チェック周りのテストをちゃんと書くことをオススメします。 ちょっと使ってみて、不備があったり足りない機能があれば教えてください。 まだ自分としても「実験段階」、「こんなものがあったらいいなぁ」という段階なので、何かあれば教えてください PyConJPのパーティーなどで権限周りの定石や悩みを共有できたら良いなぁとも思っています。

おわりに

まだまだ作っている段階のライブラリーですが、僕自身が仕事をしていて欲しかったものを考えて作っています。 他にも良い方法や機能の提案、バグ報告や他オススメのライブラリーがあればぜひ教えてください。

できれば、ぜひPyConJP 2017でお会いしましょう。