Posts for: #Book

インボイス制度への準備

夜はドラクエタクトやってて2時過ぎに寝て7時に起きた。気のせいか、日記を書くようになってから早く寝付けるようになった。まつのさんが twitter で久しぶりに Python 書いたとツィートしていて、何気なくふと Implement experimental asyncio support #101 #340 をみて、そのツールの関係者でもないのに勝手にクソリプ的なレビューコメントをした。気付いてしまったらみなかった振りするのも気持ち悪いので。

インボイス制度の準備

2023年10月1日から 消費税の軽減税率制度・適格請求書等保存方式(いわゆるインボイス制度) が開始される。開始される前に適格請求書発行事業者に登録しておく必要があり、その登録受付が今日から開始された。前に知人が教えてもらった解説動画を見返した。

ちなみにうちの会社は今期から課税事業者になるのでインボイス制度開始による益税の影響は受けない。前期の決算で消費税を算出したとき、本則課税と簡易課税なら後者の方が46%の納税金額が少なくなることがわかった。IT 業界は経費に占める人件費の割合が大きい (人件費は消費税がかからない) ので簡易課税の方が節税になるのではないかという気がする。そのため、簡易課税で申請している。一度、申請すると2年間適用され、不適用届出を出さない限りはずっと簡易課税で継続される。

国税庁の 申請手続 をみながらe-Tax (WEB 版) で申請した。

個人で副業を受けることを想定すると、個人でも適格請求書発行事業者に登録した方がよいのだけど、私の場合、自分の会社なので法人で仕事を受けるのと個人で仕事を受けることの違いって何だろう?とわからなくなった。法人税と個人の所得税の税率の違いの話しは一旦置いておいて、最も大きな違いは会社で仕事を受けても(直近の)給与は増えないのでその報酬を自由には使えない。個人で仕事を受けたらその報酬を自由に使えるぐらいかな?もうちょっとその違いを調べ直してから考えよう。先の youtube 動画の中で税理士さんが「免税事業者という制度をやめたらいいのに。。。」と言ってたけど、個人はどうしよう?と悩んでしまう本質は免税事業者という概念があるからというのは正しいと思う。

Terminal のカスタマイズ

hugo の Shortcodes で class で任意の CSS クラスを指定できる。

{{< youtube id="E0lOsLfj1T0" class="video-container" >}}

static/style.css をカスタムの CSS として読み込んでくれる。youtube のビデオサイズをよしなに調整するために次のスタイルを定義した。なかなか難しい。

.video-container iframe {
    border:0;
    max-width: 600px;
    max-height: 338px;
    width: 100%;
    height: 50vh;
}

Joel on Software

読み終えた。ソフトウェアの本で test of time (時の試練?) に耐えるのは相当に難しい。本書だとマネジメントや教育、ビジネスや経営に関する内容はいまでも有効でおもしろかった。また後日ブログに書評を書く。いまとなっては手放しでお勧めできる本ではないため、どういう切り口で書くかが難しい。自分にとって学びとして身につけたいと思った本はなるべく書評を書いて自分の言葉で説明できるようになっていきたい。

カジュアル面談

プロジェクトマネージャーを募集している会社の CTO と面談。先方の時間が15分しかないという話しだったので事前に質問は連絡しつつ、バックエンドは Go 言語を使っているという話しだったので私が過去に書いたブログ記事やちょっと前に作った go-sql-executor を連絡して、技術選考の参考にしてほしいと伝えた。募集要項からスクラムを採用するように読めたのでその背景を聞いたところ、外部の技術顧問が推奨しただけでとくにこだわりはないという。いまもメンバーは8人いて1週間のスプリントでスクラムっぽい運用はしているとのこと。私の言う、課題管理とイテレーション開発の概要を軽く説明しつつ、それを実践するためにプロジェクトマネージャーをやりたくて、その実践の場を探しているといった話しをした。外部の技術顧問が欠席したせいか、Go 言語の開発に関する質問はとくになかった。メンバーはすべて業務委託という話しなので寄せ集めグループのドタバタプロジェクトなんだろうなという印象を受けた。心理的安全性や一体化マネジメント法とか勉強したんで グループ じゃなくて チーム 開発できるマネジメントがやりたいなぁ。

窓のある部屋

夜は自民党総裁選の総括の記事を読んでた。政治に関心があるわけではないが、選挙後の総括にはとても関心がある。とくに負けた人がどんなことを言うのか、敗因をどう分析するのか。シンゴジラで矢口の発した 「政界は敵か味方しかいない。シンプルだ。性に合ってる」 という言葉が好き。選挙というわかりやすい勝ち負けが明確に出る仕組みは確かにシンプルだ。その後、3時まで本を読んで寝て7時ぐらいに起きた。

カジュアル面談準備

課題管理と開発方法論の体系化のため、プロジェクトマネージャーの案件を探している。Remogu というリモートワークxエンジニア専門のサイトでギグワークできないかを検討中。ある会社を提案されたのでその会社のサイトとサービス内容を調べてた。飲食業界向けに提供しているサービスを、これまではアウトソースで開発していたシステムを内製化するために開発者を募集しているようだった。いま風に言えば、DX の1つと言えるだろう。これから内製の開発チームを作っていくとのこと。言うても CTO (PMO) 以外はすべて業務委託で集めるとのこと。デメリットはチームにならず、寄せ集めの集団になってしまう懸念がある一方、メリットとして採用したものの、マッチングしなかったメンバーの契約更新しないことで入れ替えることができる。明日、その会社の人たちとカジュアル面談をして双方のマッチングをみてみる。

Joel on Software

昨日の続き。夜に読み切ろうと思っていたけど、ドラクエタクトの新しいイベントがリリースされて、それやってたら疲れて寝てしまった。あともうちょと。特定の技術に言及している内容は2000年代半ばの話しなのでいまとなっては有効ではないものや歴史書のように読めたりもする。中盤からソフトウェアビジネスやソフトウェア会社の運営などが書いてあって、マイクロ法人を始めたばかりの私にとっては興味深い。例えば、オフィスの要件は次の内容をあげている。

  1. 1人1人にちゃんとドアの付いた個室があること、絶対条件
  2. コンセントがたくさん必要、新しいおもちゃを机の上でつなげられる
  3. データケーブルを簡単につなぎ直せる
  4. ペアプログラミングが可能であること (L字型の大きい机を用意する)
  5. 遠くのものを眺めて目を休められるよう窓を設け、ディスプレイを壁に向かって置いてはいけない
  6. オフィスはそこで時を過ごすのが快適なたまり場のような場所であるべき

その上で、会社の成功は、ある部分までプログラマーが実質オフィスに暮らすようになるかどうかにかかっているので、オフィスが平均的なプログラマーの家よりも素敵な場所である必要があると述べている。実際、私は過去に働いた6社すべてで泊まり込みで働いたこともあるのでまさに暮らすように働いていた時期もあったかもしれない。机に伏して寝たり椅子を並べて寝るよりは、ソファやくつろぎスペースで寝る方が快適だった。あと、いまのオフィスの唯一の欠点は窓がないことだと1年ほど働いて、ちょうど私も実感していた。窓がないと1日の天候の移り変わりや季節の移り変わりがみえなくて気分転換ができないのだ。次にオフィスを引っ越すときは窓がある部屋を条件に加えようとまさに考えていた。

あと自分にとっての課題管理の原点をみつけた。過去に働いていた会社で、課題管理システムに顧客からの問い合わせや開発者のTODOやシステム管理のメモなど、すべての情報を入れられていた。こういった課題管理システムの使い方は次の記事に影響を受けて実践されたものだったと当時の上司に確認した。たったこれだけの話なんだけど、私にとっては原点なので宝ものを発見したかのような嬉しい気持ちになった。

読書とイベント参加

読書とイベント参加

0時頃に寝て8時ぐらいに起きる。やや発熱して疲れてたせいか、久しぶりに早く寝付けた。一日を通して体温は平均36.7℃なのでもう副反応は過ぎたみたい。体調もまったく悪くない。

Joel on Software

過去に働いていた会社での課題管理のやり方や開発方法論について、当時の上司と雑談したところ Joel Spolsky に由来するということを聞いた。そこで今更ながらに More Joel on Software を読むことにした。2000年代に書かれた記事の内容なのでいまとなっては古典に分類される本かもしれない。だいたい半分ぐらい読んだ。技術の詳細に言及した内容は古くなっていてあまり有用ではないものも多いけど、マネジメントや優秀なプログラマーの特性などはいまでも通用する内容に思えた。あとで私が関心をもった内容をブログでまとめることにする。

第10章コンピュータサイエンスの学生へのアドバイスで「卒業するまでにミクロ経済学を学ぶこと」という節がある。著者がミクロ経済学を推奨する理由を引用するとこれら。

ミクロ経済学はビジネスで重要な理論すべての基礎となっている。需要と供給とか、競争優位とか、NPV とか割り引きとか限界効能について知らなければ、ビジネスの仕組みが全然理解できないからだ。

マクロ経済学は、当たっているよりもはずれていることの方が多い。スキップしてよい。それ以降はただ悪くなっていく一方。

ビジネスの基礎を理解しているプログラマは、理解していないプログラマよりもビジネスにおいてずっと価値が高いからだ。

学んだことがなかったので簡単そうな ミクロ経済学入門の入門 を購入した。

読んでて気づきを得てふとツィートした。

Java 17 リリースイベント

【オンライン】 JJUGナイトセミナー「Java 17 リリース記念イベント with Foojay」9/29(水) 開催 に参加した。Java の LTS はいま過渡期でややこしいことになって、8, 11, 17 になる。リリースされたばかりの Java 17 は LTS で重要なバージョンになる。Oracle Java SE Supportロードマップ から Premier Support 期限が次になる。

  • 8: 2022年3月
  • 11: 2023年9月
  • 17: 2026年9月

いま 11 を使っている組織はいいが、8 を使っている組織もまだまだ多いと推測する。8 と 11 の Premier Support 期限が近いことから 8 を使っている組織は 17 に一気にバージョンアップすることが想定される。どこかのタイミングで Java 17 を前提した開発に切り替わっていくだろうと思われる。

最初の発表は Pattern Matching & Sealed Classes に特化した内容。これまでは instanceof と共に使う機能だった。switch 構文とパターンマッチングを組み合わせると、コードが簡潔になって Cognitive complexity を下げるという。発表者が Type Guard という呼び方をしていた。Type Guard をググると TypeScript の記事がヒットする。JEP 406: Pattern Matching for switch (Preview) ではこれを guarded pattern と呼んでいる。まだあまり一般的な用語ではないのかもしれない。あとは Sealed クラスと組み合わせた switch 構文のコード例では、すべてのパターンが網羅されていることをコンパイラが検出して default 句が不要になるコード例も紹介されててよさそうにみえた。但し、switch 構文のパターンマッチングは preview なので実際には 17 ではまだ使われないのかもしれない。今後もさらに switch 構文とパターンマッチングの機能拡張が行われる展望らしい。

2番目の発表は Java 17 の全体的な話し。fix した issues のツリーマップで contributor の分布を紹介していた。oracle, redhat, independent の順番に多い。oracle が過半数以上。日本だと ntt data が一番貢献してた。spring フレームワークの次期バージョンは Java 17 がベースラインになる。java のアップグレードを促す要因の1つにはなるはず。lts なのになぜ preview や incubator があるのか?openjdk 開発側は6ヶ月というリリースサイクルを守っている。lts にするか否かは開発者が決めているらしい。graalvm のリリースサイクルは java とは異なる。こちらは年3回のリリースなので次のリリースで出てくるはず?いくつか jep の内容を紹介してた。jep の概要は Java17の新機能をざっくり紹介 にまとまっている。さくらばさんがパッケージの api レベルでの変更を JEPでは語れないJava 17 にまとめている。ざっと目を通して興味があるものがあればみとくぐらい。8 から 17 への移行の記事やドキュメントなども紹介されてた。移行について基本は Oracle JDK Migration Guide を読めとのこと。8 から 17 の移行せずにその次の 23 を待つと作り直しになってしまいますよと 17 への移行を推奨してた。

副反応はいずこ?

副反応はいずこ?

2時過ぎぐらいに寝て5時前ぐらいに起きる。やや熱っぽいかなぁぐらいの印象でもう一度寝る。8時前に起きるともう平気になってた。昨日、書籍や macbook を持って帰ってきて引きこもり対策してたけど、体調が悪くないのでオフィスへ行くことにした。お昼から1時間おきに熱を測ってみたら37℃前後なので少し熱は出ていたみたい。とくにしんどくなかったので普通にお仕事してた。

水分補給

副反応対策として、ポカリスエットイオンウォーターの粉末をウォーターサーバーの水に混ぜて飲んでみる。イオンウォーターと普通の ポカリスエットとの違いは何ですか? によると、基本的な成分は同じで低カロリーという違いがあるらしい。

日記サイト構築

diary リポジトリに push すると GitHub Actions で静的サイトをビルドして GitHub Pages で扱うための gh-pages ブランチに push される。GitHub Actions による GitHub Pages への自動デプロイ を参考にした。gh-pages ブランチにあるものが次の URL で参照される。リポジトリ名の diary がパスになるらしい。

まだ設定は不完全だけど、運用しながらおいおい設定を詰めていく。Hugo は会社のホームページにも使っているので慣れているのと、使い心地も気に入っているのでこのまま使い続ける。会社のサイトはたまにしか更新しないので日記を書く方が更新頻度があがって Hugo を触るインセンティブになるかもしれない。

ジャーナリングとは

読みかけで放置していた 「手で書くこと」が知性を引き出す 心を整え、思考を解き放つ新習慣「ジャーナリング」入門 を読み終えた。この日記も簡易的なジャーナリングになればよいと願っていたりする。「書くこと」への期待値を高くもって読み進めたせいか、内容が薄かったように思えた。ジャーナリングを行うテーマのワークシートが24個ついていて、ページ数を稼いでいるように感じた。日常生活であまり書いていない人には関心をそそるかもしれないけど、プログラマーは日常生活で平均以上の文字数を書いていると推測する。私にとってはあまり目新しいことはなかった。

マインドフルネス (気づき) を得るための方法論の1つとして書く瞑想=ジャーナリングを推奨している。手書きとキーボードのタイピングでは効果が異なるという研究成果はおもしろかった。手書きの方が記憶力や理解力を高める、脳波はアルファ波が出るといった研究があるという。従って、より創造的な仕事に向くかもしれない。ジャーナリングの研究によって、わかってきたことの1つは、自己や他者、社会への適応力を高めると示唆されている。ここでいう「適応力が高まる」というのは、課題や問題をどうとらえ、これからどう行動すればよいかのヒントにつながる可能性があるという意図らしい。ジャーナリングは心身の健全性にもプラスの影響をもたらされる可能性が高いといった研究も紹介されている。私の感覚的にも、書くことで課題や問題を明確化することはストレスを軽減して健康になるような気がする。

ジャーナリングをする際に大事なことは「考えない」 ということです。

書く瞑想とも言われる所以にも思える。そのままの状態を観察して気づきとするような、そういう姿勢を説いている。この内容は業務の取り組みへの応用からは離れてしまう。

前に メタ認知で〈学ぶ力〉を高める:認知心理学が解き明かす効果的学習法 の著者が タイピング思考法の開発とその有効性の検討 という研究発表をしていた。この研究は、思考過程を推測する手法として、発話思考法における問題を解決するタイピング思考法を提案し、既知の問題を解決しつつ、発想の促進効果もみられてそこそこよい結果が出たというものであった。思考過程を発話とタイピングの2つで比較している。比較項目に手書きがあると少し結果に差異が出たりしたのかなぁとか思った。

Atlassian Community Online MeetUp の参加

課題管理システムとチャットツールを連携する Halp というツールがあるらしい。うちは課題管理システムにクラウド jira を使っていて、Atlassian 社から届くメールで本イベントのことを知った。Atlassian Community Event の頭文字をとって ACE と呼ぶらしい。

初めて ACE イベントに参加した。コミュニティ (ユーザー) 主体のイベントになるらしい。運営メンバーの中に前職での jira チームのリーダーが出ていてちょっとびっくりした。何度かやり取りしてお世話になった方だったのでこういうところでも活動しているんだと思ってさらに尊敬の念が深くなった。halp については、想像通り、非開発者向けに slack の操作だけで jira の課題管理システムと連携するためのサービスとしてよさそうだった。slack (halp) と jira は双方向にデータの同期ができる。いまのところ、halp の無料プランがないので試せてないけど、なにかの機会で一通り触ってみたいと思うサービスだった。