2020→2022
明けましておめでとうございます。 ブログの存在をすっかり忘れていたりしましたが、心を入れ替えて簡単に近況報告だけ書いておこうと思います。
2020年のこと
- SES×2と請負×2が同時並行になるという謎の事態に陥り精神的に死にかける
その辺が落ち着いてSES×2になった辺りでcovid-19の流行が始まりほぼ完全在宅勤務に移行
pyconjpにオンラインとはいえ初登壇。そんなに目新しいことはしませんでしたが、blackとか知らない層に届いたならいいなと思います。
ちなみにスライドはGitPitchにおいたのですがそちらがサービス終了してしまいました。／(^o^)＼
あと今関わってるpjにこの辺りの知見が全く導入されていないので紺屋の白袴とはこういうことだろうなと思う。
お仕事(SES)
- お仕事は相変わらずDjangoRestFrameworkとなんとなくAWSのインフラの面倒
- 新しいSES先はコードレビューがあるのでそれだけでも感動的な職場だった。 ｰ 元々リモートでの働き方に慣れていたのと良い環境だったのでスムーズに入れたとは思う
- レビューがまともに存在する現場が初めてだったので、色々ご迷惑をおかけする
基本テストさえ書いておけばどうとでもなるやろ！みたいな発想の自分を猛省
そんな感じで一人SESチームとしてリモート勤務をしつつ在宅生活を続ける
体調
- 良くなかった
- SES×2と請負×2のストレスと在宅運動不足のせいか、手汗や動悸などがするようになる。
- 心療内科でパニック障害と診断される。
- この辺は抗不安薬さえあれば落ち着くのでどうとでもなっている(2022年現在は症状は大分緩和)
2021年
DjangoCongress jp 2021
− 悲願の長野開催ができた。 - 現地スタッフとは名ばかりで実質なにもできなかったのですが - スタッフの皆さんありがとうございました。 - 弊社(意味深)からも登壇者が出せたので良かった
お仕事
- 相変わらず一人チームでSESをしていた。
- Django RestFrameworkだけど別システムとの連携とかなんとなくPMという立場になったりする
- なんとなくPMになった結果コーディングをあんまりしなくなってissueとgoogle スプレッドシートを眺める仕事をしていた
- 今年一年ほとんどコーディングができなかったので、技術者としては完全に衰えていった気がするので今年は業務以外でコーディングをするようにしたい。
- 夏頃から自分は実質フリーランスで会社に所属している意味なくない？と自分の立場に疑問を持ち始める
- 思い立ったが吉日(?)ということで9月末で退職、10月からSES先にそのまま個人事業主として雇ってもらうというエキセントリックな退職を実行(よくできたなと我ながら思うのですが)
- 10月以降も変わらずに同じところで同じように働いている。
- 後になってリモートマネージメントの教科書という本を読んでいたらこんな一説があったので、あ、わいのことだ！と思うなどする
元々リモートワークでは、オフィスなど、会社に所属していると認知できるものと触れる機会が減る上に、会社の方向性と自分の仕事とのつながりを感じる機会が減ってきます。メンバーにとってこのような時期は、他社が魅力的に映ります。せっかく育ったメンバーが辞めていくことはもったいないことです。
武藤久美子. リモートマネジメントの教科書 (Japanese Edition) (Kindle の位置No.658-661). Kindle 版.
退職理由は他にも色々あり思うところだらけですがさすがにそれをネットにまき散らすほど幼稚ではないので気になる人は個人的に聴きに来てください :pray:
ただ一つ、会社の人たちとはもっと一緒に仕事をしたかったなという思いは強いし若干悔いもあるが、でもそうはならなかったんだよロック....
趣味
- 2020年がcovid-19でほとんどアイドルオタク活動ができなかったので在宅アニメくんをしていたが、2021年はその反動で一気に推し活を始める。
- 多分2021年は人生で一番オタクをした年になったように思う。
- ライブアイドルは色々良い感じのグループが増えて全体的な質は上がったように見えるけど、2016年ぐらいにおきた楽曲派アイドルの登場のようなパラダイムシフトはなくなってきている気がする。
- ただ、個人的に最後の希望として"クロスノエシス"というアイドルグループが前衛的に攻めているので僕の残り少ないオタク人生のラストアイドルとしてつぎ込んでいきたい
- コンセプトだけでなく曲とダンスもかなり強いので推していきたい
2022年に向けて
健康
- ノルディックウォーキングを始めたので継続していきたい
- 早寝早起き(人生の一生の課題)
仕事
- 必要とされ続けたい
- 来た球を全力で打ち返せるようにしたい
- 学んだことはこのブログに随時書き残せたらいいなと思う
趣味
- クロスノエシスが売れますように
以上簡単ながら近況報告でした。
2022年もよろしくお願いします
Django BackGround Tasksのテスト方法を考える
前提
background tasksについてはこちらをご参照いただけると良いと思います。
ざっくり言うと非同期処理したいけどcelery入れるのはちょっと大変だしpipだけで完結すると楽だよねって時に使っています。
ここら辺の基本的なことは知っている前提で話しを進めます
環境
Python == 3.7
Django==2.2.6
django-background-tasks==1.2.0
処理を書く
こんな処理があったとします。
view.py
from django.http import HttpResponse from app.tasks import honne def index(request): param = request.GET.get('q', 'ヨシ！') if param == 'ヨシ！': honne('ヨシ！') else: honne('シらない') return HttpResponse('ヨシ！')
どんなリクエストが来てもクライアントにはヨシ！と返します
合わせてクエリパラメータを見て”ヨシ！”か”シらない”をデータベースに登録します。
from background_task import background from app.models import Emotion @background(queue='honnne', schedule=5) def honne(emotion): Emotion.objects.create(emotion=emotion)
もちろん本音はクライアントに返す必要がないので非同期処理で 心の内 データベースに登録します。
テストをどうする？
テストを書きましょう
class TestYoshi(TestCase): def test(self): client = Client() # ヨシ！を送る result = client.get('/app/', dict(q='ヨシ！')) # Responseがヨシ！であることを確認する self.assertEqual(result.content.decode('utf-8'), 'ヨシ！') # 非同期処理を上げていないとモデルが作られない self.assertEqual(Emotion.objects.all().count(), 1) e = Emotion.objects.all().first() self.assertEqual(e.emotion, 'ヨシ')
テストを実行しましょう
Failure
Traceback (most recent call last):
File "*****/DjangoBackgroundTasksTest/app/tests.py", line 12, in test
self.assertEqual(Emotion.objects.all().count(), 1)
AssertionError: 0 != 1
非同期処理が実行されないのでモデルが登録されずに落ちました！
どうする？
裏でBackGroundTasksを上げる?
テストの度に別processを上げなければならない。
test用のデータベースはsettingsで指定されたものにtest_が付いたものになるので、それ用のsettingsを用意する必要がある。
→面倒だし個人的にあまりやりたくない方法なので割愛します。
個人的解決案
まず、tasks.pyを修正します。
@background(queue='honnne', schedule=5) def honne(emotion: str): _honne(emotion) # 引数を渡すだけ def _honne(emotion: str): # 今まで honnne でやっていた処理をそのまま Emotion.objects.create(emotion=emotion)
次にテストを直します
import json from background_task.models import Task # 今回新たにimportしたところ from django.test import TestCase, Client def test_resove(self): client = Client() result = client.get('/app/', dict(q='ヨシ！')) self.assertEqual(result.content.decode('utf-8'), 'ヨシ！') # 非同期処理を呼んだときは裏ではTaskというモデルにレコードが作られている tasks = Task.objects.all() self.assertEqual(tasks.count(), 1) params = json.loads(tasks[0].task_params) # 非同期処理を呼ぶ際のパラメーターが正しく渡っていることを確認する self.assertEqual(params[0][0], 'ヨシ！')
後はhonneの中身をテストします。
class TestHonne(TestCase):
def test(self):
# _honneの中のテストはここで行う。
# 登録されていることを確認する
_ = _honne('ヨシ！') # 同期処理なので普通に呼べる
e = Emotion.objects.all().first()
self.assertEqual(e.emotion, 'ヨシ！')
どうでしょう？ こうすれば非同期処理の中もテストできますし、テストを動かしたいときにいちいち別processを立ち上げる手間も省けます。
あくまで業務中に思いついたネタなのでもっとよりよい方法があったら(優しく)コメント頂ければと思います。
ソースはこちらになります。
PyCon JP 2019参加記録、何事も準備が大切だと思った
先日太田区産業プラザpioで行われた PyCon JP 2019に参加してきましたのでメモになります(4年連続)
PyCon JP 準備
社内で予行演習会を主催しました
弊社からは三名がプロポーザルを通過したので、そちらの方々の予行演習会を2週間ぐらい前から主催しました。 主催と言っても登壇予定の方々との時間調整や、リモートワークをしている人に中継をしたり等の段取りをした程度で、誰にでも出来る簡単なお仕事です。 しかしそうした雑務でも誰もやらないと誰もやらないので(トートロジー)自分がやりました。(こんな些細なことでも社内での評価は地味に上がりますよ！！) 弊社以外の他の登壇者を見るとまだまとめきれてなかったりスライドが読みにくいものとかもあって、せっかく専門的知識ある方なのに勿体ないなぁと思うこともあり、予行演習はもっとガチでやったほうが良いのになぁと思いました。
よかったこと
聞く内容について予習をした
一番の目当てはDjangoでDDD、しかしDDDについての知識がなかったのでboothでこちらの本を購入し読了してからいきました。 相変わらず泥縄で時間がなかったので一発で覚えるためにノートを取りながら一夜漬けしました。
その甲斐あって講演を聴いてる際に単語の意味が分からなくて詰まると言うことがなくて良かったです。
残念ながら質問には至らず・・・
- jetbrainsのブースでオススメのショートカットキーを教えてもらった。
- .ifなどと入力するとif文を自動生成出来ることなど正直知りませんでした。。 相談して良かったです。
- 英語のセッションを頑張って一つ聞いた
akiyokoさんのポスターセッションが面白かった！
- Django本の第一人者のakiyokoさんの同人誌作りの話しが聴けて面白かったです。ポスターセッションはやりとりも出来るので登壇の話を聞きに行くよりも良いかもしれません。
よくなかったこと
- 荷物が重すぎた！ - 正直一日中宿泊装備も含めたリュック姿でうろうろするのは疲れました。ホテルに荷物全部預けて、ノートPCは入り口でもらえる手提げ袋に入れて動くのが正解の気がしています。 来年はそうしようと思います。
- 予習が足りない！
- 全部の講演を予習できるはずもなく、割とぼんやりと過ごしてしまったものもあります。 年と共に集中力の低下も感じます。。
- 15分が意外と・・・
- 15分にまとめきるって難しいですよね、、この枠よりももっと長い時間でがっつりみたいなのが増えた方がいいのかなぁと思いました。
やること！
短いですが、やることは減らしていきたいのでこんなところで・・
最後になりますが、コミュニティを支えるスタッフの皆様には毎年頭が下がる思いです。 今年からは配信もありましたし、本当にありがとうございます。 :pray:
多分、風邪。 アジャイル
本日夕食後、若干の立ちくらみとけだるさを感じ、休む。
その後、心拍数が上がり、体のだるさもどんどん進み、後不安が破裂しそうなほど膨らむ。
というのは、三年前に脳梗塞(奇異性脳梗塞という心臓に時々穴が開いてそこをたまたま血栓がすり抜けて脳に当たって脳梗塞になるやつ)を患った際も夕食時だった。
そのトラウマは今も残っていてちょっとでもふらつくと、また血栓が当たった？？のではという恐怖に支配され、心拍数は上がり、手は震え、何故か咳まででてきた。
特に激しいめまいや吐き気はなかったが不安が不安を呼び、結局車で40分先の病院に連れて行ってもらった。
そこで事情を話し、心電図と脳のCTをとってもらった。
結果は(まぁ分かっていたとはいえ)問題なし。
ただ、熱が若干あるということで、解熱剤だけもらい病院を後にする
深夜料金込みでお値段7640円、今は何の不安もなくむしろ前より元気になって床につこうとしている。
不安というものは本当に人間を病気のようにするので恐ろしいと感じた。
ITの世界でも心理的安全性などといったことが叫ばれている。
自分も心理的安全性の低い仕事をしていた時期があったが、あの頃はじんましんがでたり、しょっちゅう風邪を引いていたし、バグもたくさん出していたり、自分がやることが整理できなかったりしていた。
ということで、安心が人生をより良くしていくなぁと思ったところで
そんな心理的安全性を高めるかもしれないアジャイルイベントが東京よりスクラムマスターの方を二名招いて土曜日に開催されるのでぜひお越しください！（宣伝 心の問題というのは仕事のパフォーマンスにもたぶんめっちゃ、影響するので技術習得も大事ですが、パフォーマンスをフルに発揮するための開発手法というのも同じぐらい大事で、いうなれば両輪じゃないかと思います。
eventは和気あいあいと自由闊達にすすむのでとても楽しいものになると思います！
https://agile-shinano.connpass.com/event/140917/ #agileshinano
DjangoCongress JP 2019に登壇したので事故らないためにやったこと
昨日登壇したDjangoCongress JP 2019についてですが、技術的振り返りと言うよりは登壇が決まってから当日までの振り返りになります。
自分は正直技術者としてのレベルも素地も低いしこういった規模の登壇経験もないにも関わらず、入念に準備するほどの真面目さもなく、直前になって泥縄でとにかく事故らないように奮闘した話になります。
なのでこの話は素晴らしい講演をした話しではなく事故らない講演を目指した話しになりますのでご了承下さい。。。
当日のスライド
一部会場限定スライドがありましたが本筋にまったく影響は有りません)
www.slideshare.net
読んだもの
マイクロソフト伝説マネジャーの 世界№1プレゼン術
プレゼンの世界で有名な澤円さんの本を読んだ。
とてもためになる上に分かりやすく文量としても多くないのでオススメです。
一度読んで終わりではなくスライド作りや当日の準備で行き詰まったら読み返してみると良いと思います。
本書を読んで反映できたこと
- プレゼンの核を作れ
- ジョークを決死の覚悟で言うな
反映できなかったこと
- レーザーポインターは使うな。
- スライドで戻るな
- 聴衆を見ろ
- 鼻腔共鳴
- 無意味にうろうろするな
登壇後に読み返して見て実はほとんど出来てなかったことに気付く・・・
- 作者: 澤円
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/08/24
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
Software Design 2017年7月号
DjangoのQuerySetAPIが分かってもSQLが分からないのでselect文特集の箇所を大分参考にしました 。 言葉の使い方などは大分参考にしてます。
買ったもの
いちいちPCを操作しないと次に進めないのは不便なのでフィンガープレゼンターなるものを買いました。
時間もなかったのでアマゾンの評価だけで選択、レーザーポインターは澤円さんの本では推奨されていませんでしたが選択肢としては残しておきたかったのでレーザーポインター機能があるものを購入
スライド作りで心がけたこと
- 公式の情報を出典にする
- ところどころに笑える要素を入れて聴衆を飽きさせない ☆
- 顧客の要求とその達成という共感得られそうなストーリー仕立てにした
- ファクトチェックを必ず行う(実際に動かす)
- 1スライド1要素(完全には出来ませんでした)
- 小ネタで一部の人にしか通じないネタはなるべく排除(アニメのことなど)
- 政治の話しはしない(タイトルの元ネタがトランプ大統領なのでそれに絡めようと思いましたが、避けました)
- 著作権に抵触する画像は使わない
- 45分の登壇時間だったので42分ぐらいの完了を目指す
- 目次は章が変わる毎に改めて表示
登壇練習
準備は何度か社内で話して皆様にご意見を頂きました。
フィードバックは本当にありがたく誤字脱字、フォント、内容不備まで一通りご意見を頂くことが出来ました。
これをしないで当日を迎えていたら登壇後に逃走していました。
また自分でもちゃんと分かっていないところが一発で浮き彫りになります。
練習は以下の日程で実施
- ４日前に会社で独りで練習(時間計測にしかならず。。)
- ３日前に社内でみんなに聴いてもらいながら話す(壊滅的内容)
- 前日にもう一回やる(まだ分かりにくい内容)
スライド修正
スライドの修正は割とぎりぎりまでやっていて前々日と前日は朝の４時までスライド作り込みをやっていました。
登壇後にSNSでクソ内容だったとかDjangoコミュニティ出禁になるみたいなことを想像して震えながら修正してました。
当日はアイドルの宣伝も入っていたのでフィロのスのオタクは技術に対して不誠実な連中と思われてしまうとアイドルさんに迷惑がかかると考えると諦めて寝るという選択肢はありませんでした。
でまぁこの週は連日３時近くまで起きていたので結構ふらふらでした。
ただし、スライド修正は前日までと決めていたので4時にslideshareにうpしたところで終了。
直前は どうせまともな精神状態じゃないのでそこで直そうとすると迷走する危険性があったので新幹線の中や直前の改修は行いませんでした。
新幹線ぐらいは寝ないとさすがに当日発表する体力もなさそうでしたので。
当日
当日は２時間睡眠+新幹線で1時間30分寝たので３時間３０分睡眠でした。
寝不足になると寝ないように心臓が必死に動いているせいか緊張してるからなのか朝から心臓バックバックでした。
朝からSNS炎上や登壇後に怖い人に詰め寄られるとか寝不足で登壇中倒れるとか事故のことばかり考えてました。
後、そもそもこんな初級話を聞きに来たわけじゃないぞって顧客が本当に望んでいたものとのアンマッチが起きたらどうしようとか思ってました。
直前
直前はエゴサして朝一は(同じ時間の別の発表である)静的ファイルの扱いの話しを聴くぞ〜みたいなのを見る度に安心したりしてました。
それでも緊張と不安で死にかけていたので社内slackで騒いだりしてましたが、始まってしまえば孤独。
そこで、か弱いオタクの守護天使、推しメンにすがることにして登壇場所に 十束おとはさんのランチェキを置くことにしました。
いわゆる助けて 推しメン・・・ですね。
後はレッドブルとポカリスエットを混合すると無限に起きていられるということなので呑んでました。(科学的にはどうか分かりませんが少なくともプラシーボ効果はありますし、効果がなくても副作用もないと思って呑んでました)
それにここまで来るともう俺を選んでしまったスタッフが悪いという謎の押しつけ理論が脳内で展開され、もう俺の発表を貫くしかない、、、という気持ちにもなってきました。
まとめると、推しメン、レッドブル、他責思考で気持ちが少し楽になってきました。
登壇開始
始まってしまうとまぁもうやるしかないでよね
幸いなことにスライドの最初に入れた "ウケる" 鉄板ネタを仕込んでおいたので(会場限定スライド)でそこで笑い声が聞こえた時点で勝った！！と思いました。
面白いことに本番を迎えると変なスイッチが入るのか今まで思いつかなかった小ネタや突っ込みが即興で浮かんだのでそれでさらに笑いが取れたのでとりあえず沈黙の中淡々と話しをするという辛い状況にはなりませんでした。
登壇後
登壇後は知ってる人や知らない人からも(！) 面白かったですと言って貰えたのが良かったです。
質問がなかったのはちょっと残念でもあり、答えられない厳しい質問が来なくてよかったと思うところでもあり。。。
後登壇後はもう完全にふ抜けていて話半分しか訊いてなかったりしてまぁ廃人みたいなもんでした。
後直後を除いては声も掛けられませんでした。(懇親会でも)
意外と登壇者だからと言っても人がいっぱい集まったりリアルに刺されたりみたいに特別になるわけじゃないんだな〜という感想
事故らない発表のためにやったことまとめ
- フィンガープレゼンターは買おう
- 会社の人とかに聴いてもらって練習しよう
- 体力は直前に使え
- 登壇しても殺されないし人気者にもならない
- 準備は直前まで頑張りたいけどどこかで区切りは決めよう
- スライド単位の情報量は減らした方がいい
- オタクには守護天使が付いてる
ということで今回は事故らないが目標という割と低いハードルだったのですが今後もこういった機会を頂けたらもっとちゃんと伝わることを目標にしたいなぁと思いました。
このような機会を設けていただいたスタッフの皆様、会場提供をしていただいたサイボウズ様には本当に頭が下がる思いです。
ありがとうございました。 そして守護天使に感謝を・・・
Pythonで何年何月の何回目の何曜日を取る方法
具体的には 2019年1月の初回の月曜日を取得する方法で説明します。
例えば2019年1月のカレンダーはこんな感じ
# January 2019
# Su Mo Tu We Th Fr Sa
# 1 2 3 4 5
# 6 7 8 9 10 11 12
# 13 14 15 16 17 18 19
# 20 21 22 23 24 25 26
# 27 28 29 30 31
なので2019年の第一月曜日は1/8日になるんだけど、pythonの標準モジュールのカレンダーで指定した月のカレンダーを使うと週毎に取るために週単位に取れるので12/31日(月)が最初の月曜日になってしまう。。。
import calendar
c = calendar.Calendar()
c.itermonthdates(2019, 1)
# リストで帰ってくる
[
datetime.date(2018, 12, 31), # Monday -> start week
datetime.date(2019, 1, 1), # Tuesday
datetime.date(2019, 1, 2), # Wednesday
datetime.date(2019, 1, 3),
・・・
datetime.date(2019, 2, 3),
]
import calendar c = calendar.Calendar() mondey = 0 index = 0 # d.weekday(): 曜日の情報が0(Monday)〜6(Sunday)で取れる [d for d in c.itermonthdates(2019, 1) if d.weekday() == mondey and d.month == month][index]
って書くと2019年1月7日が取れるよ！
カレンダーモジュールってあまり見かけないけど割と便利なので必要に応じて使っていきたいなって思った。
カレンダーのドキュメント見ると結構色々なことが出来るみたいなので、頑張って処理を書かずにライブラリにどんどん助けてもらおう
PycharmのDjango Consoleでshell_plusを動かしたい！
shell_plus 便利ですよね。
毎回 from myapp.models import * って入れる手間がなくなります。
そこでそれをターミナルからだけでなくpycharmのDjango Consoleからもshell_plusを呼ぶにはどうすれば良いのかって小ネタです。
pycharmはproの2018.1 を使ってます。
基本はここの通りにコピペすればおｋです stackoverflow.com
貼り付ける内容はこれで
import sys; print('Python %s on %s' % (sys.version, sys.platform))
import django; print('Django %s' % django.get_version())
sys.path.extend([WORKING_DIR_AND_PYTHON_PATHS])
if 'setup' in dir(django): django.setup()
import django_manage_shell; django_manage_shell.run(PROJECT_ROOT)
from django_extensions.management import shells
from django.core.management.color import color_style
imported_items = shells.import_objects({}, color_style())
for k, v in imported_items.items():
globals()[k] = v
ここにこんな風に貼り付けます
from myapp.models import * なんぞに今後は時間を奪われないようになりました！
