Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

ウィーンモダン展に行ってきたWebアプリ開発者の感想

雑談 アート

今日は、総合的な芸術、そして人の集まりというものの大切さを感じました。 ウィーンモダン展というものに先ほど行ってきましたのでその感想です。

artexhibition.jp

展示会として、行くべき？

個人的な感想の前に答えておきます。

今この記事を読んでくれているあなたは、千代田線乃木坂駅に行けて、1600円と1時間30分という時間を使えますか？ Yesで、かつ興味があれば難しく考えずに行ったほうが良いと思います。 平日の4時に仕事を少し早く切り上げて行きましたが空いていました（スケジュールなどはサイトを見てください）。

この展示会について平たく言うと:

  • 美術品だけでなく1800年、1900年のウィーンの文化とか美術史にもついて知れてとても興味深い
  • 「そんなことよりクリムトの油絵がたくさん見たい」という人にはあまりオススメしない

美術品を眺めるというよりも、ブラタモリを見る感覚でも楽しめます。 僕は美術史の背景を教えてもらいながら美術品を見るのが好きなので良かったです。

まぁ、1パイント1600円するクラフトビール飲むなら、1杯だけ我慢して国立新美術館にいくのが良いんじゃないでしょうか。

個人的に良かったこと

エゴンシーレ

そもそも、私の個人的にはエゴンシーレの作品が見たかったのでこの展示会に行きました。 昔からシーレの作風や表現、人生などがとても好きなので地下鉄の広告でこの展示会を知ったときはウヒョウ！となりました。

ja.wikipedia.org

展示会でもエゴンシーレの自画像が見れたことはとても良かったです。ただ印象としては「ひまわり」のほうが予想を超えてすごかったです。 シーレのエンピツ画や水彩の人物画も多数あり良かったです。が、「大量」というわけでは無いのはもう少し寂しい気持ちになりました。 まぁでも実際に生で見れたのは本当に良かったので、エゴンシーレ美術館やプラハ国立美術館に行けということでしょうね。

www.musey.net

分離派ポスター

予想外、というか期待していない点でとても感銘を受けたのは分離派のポスターでした。

とくに「作品だけでなくポスターでも芸術性を発揮しよう」という総合芸術が素晴らしいと思いました。 私も PyQ のようなWebサービスを作っているので、その考えにはとても共感します。 例えばマーケティング用のクリエイティブや文章も、Webアプリケーションという作品の一部と考えられます。 分離派のポスターもアテナを描いたり、タイポグラフィにこだっていたりと大変面白いです。

クリムト

今回の展示会の目玉はやはりクリムトでした。 人生で死ぬまでに見れて良かったなという気持ちです。

ですがこれも予想外で、クリムトのアテナの絵や分離派のポスターなどが印象的でした。 アテナの絵の「やっていくぞ！」という気概は本当に良かったです。 こういうやっていく気持ちを素直にぶつけていくのは大切だなと思いました。

また分離派のポスター用の下書きなども見れて良かったです。 タイポグラフィのためにガイドの線を引いていたり、修正液で文字を直したりしているのが見えました。 芸術の後ろには数多くの習作や練習、計算があるものなんでしょうね。

印象派ポスターの1つ目は検閲を受けて一部が隠されていて、当時の保守的な雰囲気を感じました。 そこも、「歴史から描く」というこの展示会として良かった点ですね。

人の集まりが何かを生むのか

印象派にしろサロンにしろ、芸術のジャンルを超えて交流することで新しいものが生まれたという背景も展示会で描写されていました。 個人的にはこの点が感動して、「まるで現代のIT勉強会だな」という風に感じました。 アテナイのアゴラもそうですが、やはり人が集まって交流する場所には新しいものや素晴らしいものが生まれるものなのかもしれません。

DjangoCongress JPやコミュニティ活動をしていると大変なときや「意味あるの？」と不安になることもあります。 ですが歴史に学ぶと、そういったコミュニティ活動や人との関わり、対話、議論というのはとても意義のあることなんでしょうね。

まとめ

ウィーンモダン展はとても良かったです。 ただの美術展というよりも、歴史資料展や文化の変化を伝える展覧会としてとても良かったです （どうでも良いですが「シューベルト」と聞いてイメージするあの肖像画の本物を見れたのは何気に良かったです）。 個人的にはエゴンシーレの作品に触れられて嬉しかったです（他に見れる良い場所を知ってるという人はぜひ教えてください）。

またそこからWebアプリケーション開発やコミュニティ活動、組織運営というものについて刺激を貰えました。

ぜひ時間があればウィーンモダン展に行ってみてはいかがでしょうか。 1時間30分と1600円に見合うものは得られると思います。

Slackで「お節介しちゃうチャンネル」が増えすぎて疲れてませんか？ROM専力を鍛えよう

考え

仕事用のSlackで時間と集中が奪われすぎていないでしょうか。 Slackは相当優秀なコミュニケーションツールですが、あまり反射的に使っているとSNS疲れのような状態になってしまいます。僕は「お節介しちゃうチャンネル」が増えすぎると疲れて良くないと最近気をつけるようにしています。

こういうことを言うと「雑談をするな」とか「助け合わないのほうが良い」というような極端な話なのかと誤解されるかもしれませんが、そうではありません。 Slackでどうでも良いことを話したり、人に相談したり助けたりするのは大切なことだと思っています。ですが、無作為に自分のリソースを使って良いものか？という意識付けの話です。

（この記事は自戒です）

何が危険なのか

「ちょっと大事そうな話」 が一番危険だと思います。 なぜなら意識、集中、感情、決定など脳のリソースを使ってしまうからです。 力をかける場所はそこでしょうか？

「本当にくだらない話」は無視したり適当にダベれば済みますが、この「お節介しちゃうチャンネル」は要注意だと思います。 「今日はどの曲を聴こうかなー」みたいな話は脳は大して使わないですよね。でも「何だかお客さんとのやりとりが不穏だ」というような話には脳がビビッと強く反応してしまうのではないだろうか。

人間年を取って経験ができると色々言いたくなるものです。でもそれは本当に言う必要があるんでしょうか？

リソースの分散を避けたい

そのお節介はとても大切ですし、すごい能力なのはもちろん分かっています。では問題とは何なのでしょうか。それは リソースが分散されてしまうことで、できることが小さくなってしまうこと です。 人間の脳みそや感情、「決定する意志力」は有限です。そのリソースをどこに使うかを制御しないと、人生や仕事の成果が小さくなってしまう問題があります。

先の例だと「お客様とのやり取りが不穏だなぁ」と気づいてアラートを上げるのはチームにとって有用です。ですが、すでに誰かが問題に気づいて誰かと相談しあってるときは一瞬立ち止まりましょう。大したアドバイスでも無いのならスルーしといたほうがお互いにとってプラスです。

とくに、勤続が長くなったり、スキルがついて頼られるようになったり、重要なポジションになったりすると参加しているチャンネル数は増えるものではないでしょうか。そして自分が役に立てる瞬間も自ずと増えてくると思います。ですが「 反射的に人の役に立っていてはいけない 」と最近は考えています。役に立てることは嬉しいことですが、少し考えてみましょう。自らの意思でどこに力を使うかを制御しないといけません。より多くの人の役に立てる場所が他にあるはずです（例えばコードを書いてお客様のために良いものを作るとか！）

お節介チャンネルには何があるでしょう？例えば...

  • 直接は関係していないけど一応見ている別のプロジェクトのチャンネル
  • あまり自分がコアな話題ではないけど入っている質問チャンネル

逆に、今メインでやっている仕事のチャンネルや、自分が得意な分野の質問チャンネル、従業員連絡用のチャンネルなどは重要と考えたいものです。

ROM専力が必要

大切なのはROM専力を鍛えることだと思います。

親切な気持ちがあるときほど色んなチャンネルを見て「それなりに役立つ」ことをしてしまいがちです。繰り返しになりますが、それなりに助けになってしまうのが罠なところです。良いことをしているけど、本人の集中とエネルギーが分散しているのが問題です。

だからROM専力を鍛えるのが大切だと考えています。「優先度の低いお節介」を見極めて、スルーしないといけません。「自分でなくてもいいかな」ということはスルーして、「誰も反応してないが、これは拾っとかないとヤバイぞ」、「これは自分が答えたほうが早いな」という部分だけお節介を焼きます。

自分がヒーローになろうとするのでなく、全体での最適化を考えると言っても良いかもしれません。

お節介焼かなくても意外と大丈夫

「お節介焼かなくて大丈夫だろうか？」と思うかもしれません。でも意外と大丈夫です。 ココ最近あまりSlackのチャンネルで反応しないように心がけましたが、意外と自分の存在なんてそんなものです。

  • 1つ、すでに何かやり取りがあるところに反応する必要はほとんどない
    • リアクションでイイねとか付けとけば良い
  • 2つ、お節介を焼かなくても、より何とかしようとすべき人が何とかしようとしてくれる
  • 3つ、何とかならないなら困っている人が（より広いところで）助けを呼んでくれる
    • ここで参加したほうが良さそうなら参加する
  • 4つ、それでもうまくいかないなら社内のアサインやコミュニケーションのあり方が良くない

私も「意外と自己満足でお節介焼いていたかな」と振り返れば思うときがあるので、そこまで一生懸命に反応しなくても大丈夫だなと思っています。

まとめ

お節介を焼かない分、今集中すべき仕事に全力を傾けましょう。 お節介を焼かない分、他の人が頑張るチャンスができるでしょう。 本当に見ておきたい案件のチャンネルや、質問チャンネルなら全力で助け合いましょう。でも優先度の低いチャンネルや優先度の低いお節介もあると思うので、場所を選んでROM専になっていきましょう。

明日からは「このお節介、いるかな？」、「今集中すべきことって何だっけ？」と気にしてみませんか？ やるべき仕事がシッカリして、良い気分で布団に入りたいものです。

（この記事は自戒です）

もうPythonの細かい書き方で議論しない。blackで自動フォーマットしよう

Python
  • 「ここで改行するほうがキレイで良いと思います」
  • 『いや、私はこちらのほうがキレイ良いと思います』

コードレビューでこういう議論をしたことはありませんか？ 大切なことだとは思いますが、生産性にはあまり直結しません。議論を避けるために書き方を決めるほうが良いでしょう （個々の問題について逐次議論するのがエネルギーを無駄にしてしまいます。一度決めて、再利用するようにしたいものです）。

今日はそのために使える black というツールを紹介します （「私はflake8を使ってるから結構です」と思われるかもしれませんが、少し違う話なので読んでみてください）。

blackを使おう

Pythonのコードを自動でフォーマットしてくれる black を紹介します。

github.com

blackはPythonのコードフォーマッターで、自動的にPythonプログラムの書き方を修正してくれます。 PEP8 というPythonのコードスタイルにも準拠していますので安心です。

Python向けの自動フォーマッターはいくつかありますが、他のフォーマッターとの違いは何でしょうか？一言で言うと、blackはより制限が強いということです。

blackの特徴

Pythonの自動フォーマッターといえば autopep8 や yapf などありますが、blackはより制限が強く、自由に設定ができないのが特徴です。

PEP8では触れられていない、改行の仕方や、シングルクォートとダブルクォートの統一、末尾カンマの統一、余計な丸括弧の削除、数値リテラルの書き方統一などをしてくれます。 私の捉え方としては、blackは「自動フォーマッター」というよりも「制限のきついPEP8」です。

設定できることはせいぜいファイルの幅（文字数）や除外するディレクトリーの設定くらいでしょうか。 開発プロジェクトごとの違いや好みを反映することはほぼできません 。 「うちのプロジェクトはルールで、こう改行するように決めている」というのであれば、改宗するか、諦めるしかありません。 改行位置とかも自動で揃えられるので「ここの論理行はここで改行するのが好き」とかそういうのは無理です。

  • PEP8に自動で従ってほしい
  • PEP8で触れられてない以上のルールを設定したい
  • どこで改行するか議論したくない
    • \ で改行するか
    • () で改行するか
    • () のどこで改行するのか
  • シングルクォートを使うのか、ダブルクォートを使うのかで議論したくない
  • 「プロジェクトごとに色々設定」できないほうが楽で良い

私個人としてはこの「設定させない」というのは良いと思っています。

ただ「シングルクォートをダブルクォートに統一する」などのblackのルールは正直好みに合いません（私には『シンボル』的な文字列ならシングルクォートを、『文字列』的な文字列ならダブルクォートを使うというマイルールがありまして、そういった美的センスも大切だとは思いますが）。

誰がblackを使っているの？

ココ最近、私の仕事での開発環境を整備していて、black をプロジェクトに導入しました。 Used by を見ると他に使っている人のコメントが読めます。

また、Djangoのソースコード開発ではblackを使うというプロポーザルがアクセプトされています。

github.com

ただ、blackはまだ公式には「まだベータだよ」と言っていますので、性急に捉える必要はないでしょう。

2022年2月8日追記：正式リリースされています！　black最高！

blackを使おう

blackは単なるコマンドなので、インストールして使うだけです。

pip install black
black <target>

blackを設定しよう

基本的にblackにはあまり設定できる項目がありませんが、文字の幅や無視するパスを指定できます。 Pythonのプロジェクト配下に pyproject.toml をおいて、以下のように書けます。 この例では「1行の文字数は99文字」という設定と、blackの対象にしないディレクトリーを設定しています。

[tool.black]
line-length = 99
exclude = '''
(
    migrations
    | .mypy_cache
    | .pytest_cache
    | .tox
    | venv
)
'''

書き方はこちらを参照してください。

github.com

blackをプロジェクトに導入しよう

既存のPythonのプロジェクトにblackを導入する場合、単に「コマンドとして使う」だけでは不十分です。 プロジェクト内で定期的に実行して、Pythonコードの品質を保つようにしましょう。

オススメの方法は、 tox.ini やCIで定期的に実行することです。 以下の例は tox.ini に書いて単体テストとして実行する方法です。

[testenv:black]
basepython = python3.7
deps = black
commands =
    black . --check

--check オプションを付けると「blackの書き方に則ってるかどうか」のチェックだけしてくれます。 他にも --diff コマンドで差分表示、 --version でバージョン表示もできるので同時に実行していても良いでしょう。

blackを自動で実行しよう

エディターで実行するようにすると良いです 。

ただspacemacsは対応中のようです。2019年6月3日現在だとdevelopブランチにはマージされているようです（yapfでなくフォーマッターとしてblackを指定できるようになるようです）。

私はgit の precommitの実行は設定していません。

flake8と共存する

Pythonのプロジェクトであれば flake8 を使っていることと思います。 blackはflake8と併用できますが、併用する場合は一部非互換の部分があるのでちゃんと設定しましょう。

[flake8]
max-line-length = 99
ignore = E203,W503,W504

max-line-length はblackと同じ幅を指定すればOKです。blackはデフォルトで88文字なので、black側で設定しないときはここで88を指定しましょう。 次の ignore は、flake8とblackで 互換がない点を無視するための設定です。

isortと共存する

Pythonのモジュールインポート順を自動で修正してくれる isort ともblackは共存できます。 blackはインポート順は直さないですが、isortのデフォルトの書き方に文句を言うので設定します。 以下のように pyproject.toml や tox.ini に設定すると良いです（例によって行の文字数は99文字に設定しています）。

[tool.isort]
include_trailing_comma = true
line_length = 99
multi_line_output = 3

これは pyproject.toml に書いた例です。 細かい話ですが、isortを pyproject.toml で設定したい場合は pip install isort[pyproject] でインストールしましょう。

まとめ

blackは

  • PEP8より制限のきついルール
  • 色々設定できない
  • 使いやすい

スペシャルサンクス

aodag さんに実際のプロジェクトでどう使ってるかを色々と教えてもらいました （上記の --check オプションについてや、エディターの設定など）。

blackについてはaodagさんのこのトークでも紹介されてます。Pythonのプロジェクトにおいて効率的に開発する方法が説明されてますので参考にしてください。

他のオススメ記事

blog.hirokiky.org

blog.hirokiky.org

ぜひTwitterアカウントもフォローしてください！

twitter.com

DjangoCongress JP 2019を主催したよという話

Django

DjangoCongress JP 2019というイベントを主催しました。

f:id:hirokiky:20190518151953j:plain

2018年もDjangoCongress JP 2018 を主催しましたが、今年も主催しました。 全員であわせて130人くらいが参加するイベントになりました。 「130人にもなるとやっぱ人多いなぁ」 と、集合写真を撮っているときに思いました。 スタッフのみんなお疲れ様でした。去年とメンバーはあまり変わらず、考え方や効率の良さも相変わらずでとてもやりやすかったですね。 参加者の方も積極的にツイートしたり、手伝ってくれたり、交流したり、暖かいコミュニティだなぁ、ありがたいなぁと思っていました。

映画やアニメやゲームもそうですが、大体のものというのは2がつまらなくなってしまいがちですが、今回のDjangoCongress JPは2回目も大盛り上がりでした。 そして何よりスタッフも参加者の方もみんなで楽しめたかなと思います。

djangocongress.jp

f:id:hirokiky:20190521204035p:plain

後日、当日の動画を公開しますのでお待ちください。

写真

当日の写真はこちらから

photos.app.goo.gl

パーティー

とくに今年は、去年用意できなかったオフィシャルのパーティーを用意できました。 スタッフのayakoさんが中心になって頑張ってくれました 。やっぱり発注となると金額も大きいですし、規模も読みにくいですし、タイミングも重要なのでかなりヒヤヒヤしますね。

でも当日うまくいってよかったです。

f:id:hirokiky:20190518185043j:plain

f:id:hirokiky:20190518181603j:plain

発表

今年は僕も発表しました。 英語の発表ですが、練習もしていたのでそれなりに詰まらずに話せたかなぁと思います。 今年はさらに動画撮影もありましたので、後日動画も公開されます（自分の発表を観てまた落ち込みそうですが）。

f:id:hirokiky:20190518160206j:plain

gitpitch.com

他の人の発表などについては参加者の方のレポートを読むのがオススメです。ぜひ他の人の記事も読んでね。 たくさん記事あるので後でまとめるかも。

kumappp.hatenablog.com

mizzsugar.hatenablog.com

まとめ

来年もぜひイベント開催したいのでぜひ楽しみにしていてください。 スタッフになりたい方も募集中ですので、次回のDjangoCongress JPのキックスタート会ができたらぜひ来てください（そして継続して手伝ってくれると嬉しいです）。 僕は来年はより身を引いて、周りの人にもっと任せたり、仕組みで解決していけるようにしたいなぁと思います。

雑談: YouTubeの話題を共有できなくて寂しいのでオススメのYouTuberを共有したい会

雑談

hirokikyです。 最近はYouTubeばかり観ています。Twitterのみる頻度が減って「話題」についていけて無い寂しさを感じる今日この頃です。

そこで オススメのYouTuberを紹介して僕の友達にも観てもらおう という記事です。

そしてよく「YouTubeよく観るよ」というと「どれを観たら良いのか全くわからない」とよく返されるので僕のオススメを紹介します。 チャンネル登録数は50か60くらいです。チャンネル登録してまめにYouTubeを観始めたのはここ3,4年くらいでしょうか。

すべては紹介できないのでピックアップして紹介します。公式チャンネルとかは紹介しません。 基本的には気になった動画を観ていればYouTubeがレコメンドしてくれるので、順番も特に気にせず観たいように観ていくのが良いと思います。

よく観る、とても好き枠

東海オンエア

一番のオススメは東海オンエアです。 どの動画もクオリティ高く、東海オンエアの面白いネタを提供してくれます。 言ってしまえばバラエティです。とくに「ぷっすま」とかの雰囲気の、「テレビとしてはチープだけど面白い深夜番組」と思えば正解です。

www.youtube.com

ここ1年くらいの再生数の多い面白そうだなぁという動画を観ていれば大体かなり面白いです。 バラエティ的なやつも面白いですが、46道府県旅行やコント系の動画も結構好きです。

東海オンエアの空気感が好きになれば、東海オンエアのサブチャンネルもオススメです （「サブチャンネル」というのはYouTuberのメインではないサブ的な内容を出すチャンネルを総称してこう呼びます）。

www.youtube.com

僕が東海オンエアで一番好きなのは ミリオンエア ですが、ちょっと背景知ってないと面白くないと思います。

SUSURU TV

ラーメンYouTuberのSUSURU TVです。 編集も観やすいしレビューも分かりやすいし良いです。 ラーメン特に好きじゃなくても楽しく見れると思います。

www.youtube.com

とくにSUSURU TVはサブチャンネルがメインよりも面白いと個人的に思ってます。 3人の掛け合いが良いのでとてもオススメです。

www.youtube.com

僕は好き系

僕は大好きだけど万人にはオススメしないよ、という系のチャンネルをまとめてみました。

PDRさん

時事ネタを批判する系のYouTuberです。 昔から好きでかなり長いこと観ています。時事系が好きというよりも、PDRさんの独特の雰囲気とかが好きです。

www.youtube.com

PrimitiveTechnology

原始的な生活を実際に頑張ってやる人です。 普通にすごい。更新頻度は低いですが観ていて面白いです。 定期的に話題にはなるので知ってる人は多いかも。

www.youtube.com

kouichitv

独特のコント、ネタを出しているYouTuberです。 「何が面白いの？」と言われると難しいですが、とりあえず3分くらいの動画を観てみて好きになればかなりハマると思います。

www.youtube.com

ウィッキー

東海オンエア個チャンネル

東海オンエアのメンバーそれぞれが活動している「個別チャンネル」系です。 上から順に好きです。東海オンエアがすごく好きだなーとか、この人好きだなぁというのがあればオススメします。 とくに虫さんのラジオは仕事の友としてもとても良いです。

夕闇に誘いし漆黒の天使たち

東海オンエア系のバラエティです。 テイストは東海オンエアに近いですが、編集にも凝ってるところがあったり面白いです。 小柳の勢いが好きです。

www.youtube.com

VTuber系

今話題のVTuberです。 「にじさんじ」所属のVTuberだけでも100近くいますし、「先週デビューした」とか「デビュー1ヶ月おめでとう」とか言うレベルの速度の早い世界です。 とくに僕が好きだなぁというのを紹介しますが、VTuberは本当にテイストの好みで合う人を観るのが良いかなと思います。

生配信のアーカイブなんかは、適度にグダってくれるのでラジオ代わりに仕事中に聞いています。 喫茶店で適度に雑音が聞こえて、聞くでもなく聞かないでもないくらいに話が聞こえてると集中できるみたいなやつです。

ジョー力一

にじさんじ所属でも新しいくらいですが、とてもオススメです。 男性のライバーさんですが、話のキレや突発的なネタの面白さがすごい良いです。 年代も近そうなので、話のネタがドン刺さりで良いです。芸人か小噺をする仕事をしてたんじゃないかなぁと思っています。

www.youtube.com

とりあえずこれ観て

www.youtube.com

ぽんぽこチャンネル

動画系でだんちで面白い。 毎日投稿を始めてからさらに面白い。すごい。

www.youtube.com

月野美兎

にじさんじ所属のトップの美兎さんです。 まぁクセは強めですが、話は面白いし持ってくるネタも面白い。 動画中もサービス精神旺盛で楽しいです。めんどくさいサブカル女子感MAXですが、それの最終進化系なのかなと広い心で観るとハマります。

www.youtube.com

エルフのえる

にじさんじ所属のライバーさんです。 にじさんじ1期生で長めですが、最近は新興に押され気味な雰囲気です。 でも独特のゆるさとか話し方が好きなのでよく観ています。とくに観ていて不快感になることがないし、毒もないのでラジオ代わりに聞くと癒やされます。

www.youtube.com

他VTuber

観てるけど毎回全部観るほどではないよーという人たち

趣味系

他、僕の趣味で観ている系です。 この辺は完全に僕の趣味なので、オススメと言うよりも「この趣味が合うなら観ると良いよ」くらいです。 熱中して観るというわけではないですが、長い間ちょいちょい観ているという感じですね。 最近だと英語の「あいうえおフォニックス」がオススメです。

お笑い系だと（サンドイッチマンの）GrapeCompanyやザコシ、ラーメンズ、ひろしもチャンネル登録してますが、今回はYouTuberに絞ってるので除外しました。

他、定番系

まぁ特別好きと言うわけでもないけど定番だし登録してたまに観てる枠。 もしくは昔観てたけど最近観ていないチャンネル。

MEGWIN、フィッシャーズ、ジョーブログとかも昔観てました最近は観ていない。

まとめ

オススメは間違いなく東海オンエアです。 バラエティとして観るなら東海オンエアだけで良いと言ってもいいです。

あと最近はザ・YouTuberよりもVTuberをよく観ています。 とくににじさんじ所属のライバーをよく観ます。 昔からニコニコのらんたんとかうるすぐ、馬冶かよ とかを観てたので、完全にその延長ですね。

YouTuberは色々報道されたり「よく分からんけどなりたい職業ランキングに入ったやつ」と認識されることがSNSで多いように見えますが、僕はけっこう面白いなぁと思っています。

ぜひ観てみてください。そして僕と東海オンエアの話で盛り上がりましょう。

他にオススメの記事

blog.hirokiky.org

雑談: 約束の時間に早く行き過ぎる病

雑談

僕は待ち合わせというのがすごく苦手です。何なら、先に予定が入っていると不安になります。 楽しい飲み会でも、「1週間後にこの時間で」となると、その間の時間ソワソワしてしまって急激にテンションが下がります（予定が始まればすごく楽しい）。

それで、僕は約束の時間に早く行き過ぎる傾向があるなと最近ずっと考えています。 人に聞いてみるとそういう傾向の人は意外とたくさんいるなぁと発見しました。

今日も車のディーラーのところに朝10時に行ったんですが、9時38分には到着していました （お店が開いていなかったのでマクドで時間をつぶしました）。 今朝については僕がお客さん側なので、「出迎えるために準備しないと」という心配もないはずです。 全然ゆったり行けば良いはずなんですよね。極論ちょっと渋滞して遅れてしまっても「道が混んでてー」と言えば、5分10分遅れちゃっても死にはしないです （良くないことですが、商機を逃してしまうような心配だとか、相手が怒って帰っちゃうような心配はまずないわけですよね）。

考えてみたんですが、僕は時間をピッタリ合わせるのが苦手なのかもしれないです。 そういう意味では遅刻する人と同じ体質と言えます。感覚的に、10分で間に合うところでも30分取りたくなってしまう。 むしろ余った20分の時間をつぶすためにカフェに入ったのに、椅子に座った瞬間すぐ外に出たくなるくらいの感覚です。 面白いのが、毎日の出勤とかは焦燥感はないんですが、たまの1回のイベントとなるとすごくソワソワすることです。

ただ自分が早く行くのは自分が制御できる時間なので気が楽です。 遅刻すると相手の時間を奪ってしまうので避けたいと思っています。 結局、約束の時間っていうのはお互いに無駄になる時間を最小に下げるゲームなので、早く行き過ぎるのも遅刻も変わらないと思います（両者の時間を総合するとすれば）。 ただ気持ちの問題として自分が先に行って時間をつぶすほうが楽で良いんですよね。

同じ気持ちの人いますか？ 5分くらい遅刻しても良いかな、くらいで生きていったほうがいいんでしょうか。

PythonでValueError: I/O operation on closed fileを避けるためにwith open() return せずにコンテキストマネージャーにする

Python

Pythonでファイルを with open してファイルを読む前に return しちゃうとファイルがクローズしてしまいます。 ValueError: I/O operation on closed file エラーが発生します。

def load():
    with open(...) as f:
        return csv.reader(f)


>>> for row in load():
...     print(row)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

こういうときは contextlib.contextmanager を使ってコンテキストマネージャーにすると、ファイルを全部読み込むまでちゃんとファイルが閉じられません。

import contextlib


@contextlib.contextmanager
def load():
    with open() as f:
        yield csv.reader(f)


>>> with load() as rows:
...     for row in rows:
...         print(row)

yield from を使って書くとループの途中で抜けたときにジェネレーターが生き続けるんで、ファイルがクローズされなくなります。

def load():
    with open(...) as f:
        yield from csv.reader(f)

そうするとGCがジェネレーターを消すまでファイルが開きっぱなしになります。 with load() で書けるようにしとけば、その with を抜けたときにファイルもクローズされます。

勉強になりました！

他のオススメ記事

blog.hirokiky.org