【読書】なぜあなたの仕事は終わらないのか

概要

会社から求められる動きが若干マネジメントよりになってきたこともあって、まずは自分の仕事を早くさばけるようになりたい、との思いから下記の本を購入。

なぜ、あなたの仕事は終わらないのか | 中島聡 |本 | 通販 | Amazon

色々と使えそうな部分があったため、メモ。

※読み切ったのは5日前なので、色々と記憶があやふやな部分があります。

感想

締め切りを守らない天才より、締切を守る天才

直前になって終わりません、は自分もよくやったんだよな〜とその度に上司の青ざめた顔を思い出した。

これは何も徹夜して終わらせろ、という意味ではなく、10日の仕事は2日で8割終わらせる(つもり)でそのタスクの見積もりをする、のが良いという考えだった。

特に自分は不確実性の高いタスクについて調査しまくってしまう傾向があり、とにかくやってみる、というのも見積もりの一つと捉えるといいかも。

もし最初の2日で8割終わらなかったらタスクの締切調整を上司に連絡する、というのも上司目線では重宝される部下だよな〜と思った。

これはアジャイルの「早く失敗する」の考えそのものに思えた。

すべての仕事はやり直しになる

自分もPRなども完璧を目指しすぎるあまり、時間をかけすぎてしまう傾向があるんだよな〜。

でも前前職の上司は完璧主義でほんとめんどくさかったなあ、、そういうときはどうすればよかったんだろう(組織風土も多分に影響してそう) (自分は結局すぐ転職したけど)

午前中に一日の仕事の8割を終わらせる

これも大事。

自分も残業するし午前中はダラダラ仕事するか、、、なんて愚の骨頂な考えに囚われそうになるが、やっぱり午前中のほうが集中力も段違いだし、そっちのほうが効率いいに決まってるよね。

じゃあ午後はなにをするのかというと、前述のやり直しになった仕事の完成度を上げる時間や、自分のやりたい仕事に使うのが良い、というのもなるほどなと腑に落ちた。

勉強のための勉強はするな

自分は、俺ってこんなに勉強してるんだぜムーブをかましまくってる。ただそれの目的がないってのも結構やりがち、、、(そして大抵続かない)。

集中しなきゃいけない仕事なんかするな

好きなことに対しては勝手にやるし勝手に集中して続けられる。

でもそのような「好きなこと」を見つけるにもやっぱりインプット(勉強、すごい人と話す、とりあえずやってみる)は必要だよね。

著者は高学歴だし。

でも本書を読んでもどうせ内容は覚えてないんでしょ?

はい、そうです。

でも筆者が 絶対にやるべきは「寝る前に明日のタスクリストを作る」の一点だけは実践してほしい、人生を変えたいなら、 と断言しています。

でも寝る直前に仕事のこと考えたらストレスで寝れないんだが、、、と思ったりもしたが、寝る前とは退勤前でもいいよな?と拡大解釈すれば簡単に実践できそう。

まとめ

著者が天才すぎて一般人の実践は無理なんだが、、、と思った部分もあったが大部分は凡人でも実践できそうな考え方も多く、ためになる本だった。

以上。

【読書ノート】システム設計のセオリー を読んだ

社内で求められる動きがマネジメント?っぽい役割になってきたので設計のやり方等を俯瞰すべく下記の積読を消化。

https://www.ric.co.jp/images/20210803172128.gif

www.ric.co.jp

仕事で色々あって2ヶ月かかったが、通読できたのでメモ。

概要

エンタープライズ系の硬めのシステムを中心に、ウォーターフォール開発のシステム設計について全体を俯瞰できる本。

自分はコーディングやリファクタなど、いわゆる後工程に携わってきた人間なので、要求分析などの知識不足を痛感していた。

この本を読めば伝統的なウォーターフォール開発でやることはリストアップされ、タスクの解像度が上がるはず。

それぞれの工程は前後でトレースできることが徹底されているため、複雑で手がつけられなくなった既存システムの仕様解析なども対応できる。

対象読者はIT業界3年目程度と思われる。

読み方

前半は「情報システムの使命」などかなり大事な考え方が書いてあるため一旦前半を読んだ後、設計の進み具合に応じて対応する章(データ設計, プロセス設計など)を読めば良さそう。

ぶっちゃけ1章を読んでおけば後は必要に応じて、という感じ。

参考に読書時のメモは下記。

ten-passbook-fcf.notion.site

終わりに

自分が関わったPJではアジャイルだからと、あまり設計せずに突き進んで後で痛い目を見る、、、なんてことがあったような、、、

若干古い本だが、積読を掘り起こした甲斐はあったと思います(毎度偉そうにすいません)

Vue Fes Japan 2023に参加しました

概要

半年ほど前から、仕事でVue3を触っているため最新の動向をキャッチアップ & Vueへのモチベ向上を狙って東海地方から参加しました。

会場の様子

会場のお絵かきオブジェクト (正式名称忘れた)

セッションの様子

全体を通しての感想

※各セッションに対する感想はアーカイブや公開された資料に説明を託します。(アーカイブ動画も公開予定だそうです)

OSSトップランナーはやっぱりすごい

今回はVue作者のEvan You氏が来日し、Vue Fesのトップを飾った。もちろんセッションは英語であるが、同時通訳もあるので言語の障壁はなさそう。 (またNuxtの作者やコアコントリビューターも来日していた。)

彼らの話を聞いて感じたのは、VueやNuxtについて、誰よりもFWの方向性について考えリーダーシップを発揮していること。 その上でコミュニティと協調 & 盛り上げるという、自分なら想像もできないような離れ業を日々実践しているのだなと感じた。

何かと風当たりの強いVue, Nuxtではあるが、自分がそれらの機能に不満を持つとすれば、彼らが考え抜いたFWの思想を汲み取れてないだけなのかも。

有料イベントはそれに見合う価値がある

今回は懇親会なしのチケットで8000円だったが、FW作者のセッション、同時通訳、昼食やドリンクの支給(どらやきノベルティのはず)、昨今の経済事情などを考えるとそれに見合う価値があると感じた。 また各セッションも全体的にレベルが高く感じた。(ひよっこが偉そうにすいません)

自分は有料チケットのカンファレンスは初めてだったので料金の支払いに抵抗があったが、結果満足の行く形になった。

リアルイベントはリモートワーカーのモチベ向上に効く (多分

自分はフルリモートワーカーのため、ずっと自室に閉じこもりコードを書いている。

そのため最近はコードを書くことに対するモチベの低下を如実に感じていた。 しかし、家の外を飛び出し自分よりレベルの高い人の話を聞くと、自然にリモートワークの淡々とした日常に変化が生まれ、業務へのモチベーションにもなりやすかった(はず多分)。

まとめ

  • Vue Fes Japan 2023 面白かった、来年も是非いきたい。
    • 次はプロポーザル通すとか何かしらの貢献とか受け身でなく能動的なアクションも取りたい。
  • フロントエンド領域の知識不足を自覚できたので、キャッチアップ頑張りたい。
  • 運営の方々、本当にお疲れ様でした。

PHPカンファレンス2023にLTで登壇しました。

表題の通り、PHPカンファレンス2023にLTで登壇してきました。

fortee.jp

振り返り

  • プロポーザルを初めて出したが、通していただいた。
    • 登壇したことのない人は選考で優遇されてるかも?
  • 大きめのカンファレンスに初めて登壇することもあり、他のセッションを見る気持ちの余裕がなかった。
  • 懇親会では話しかけたり、話しかけていただいたり、ネットでは出来ない()話もできてよかった。
    • あったことはないが一方的に尊敬している方にも実際に話すことができた。
  • 台本通りを意識するあまり、朗読会になってしまった感がある。
    • ただ5分の制約かつ初登壇で台本なしは怖いので、そこはトレードオフなのかなと思った。
      • こればっかりは数こなすしかないかも。
  • 自分は東京から離れた場所にいるので、土日で技術に触れる時間は基本一人。
    • 東京に出て、信じられないほど技術のあるエンジニアの話を聞いたり、頑張っている他社さんの話を聞くのはかなりモチベーションに効く。
    • 同時に現状に危機感を覚える。
  • 2~300人の方に5分だけでも自分の話聞いて貰う機会なんてあんまない(経験値は格段に上がる(まあ失敗もするんだけど))
  • 次は25分トークやってみたいぞ

結論

技術カンファレンスは行った方がいい。

プロポーザルはとりあえずでも出した方がいい。

※偉そうに言っといて自分ができてないんだけど、これからやっていきたい。

【感想】ソフトウェアアーキテクチャの基礎

背景

エンジニアとして4年目を迎えようとしており、新規開発やリファクタ等をやるうえで目指すべき理想のアーキテクチャを明確にすべく、下記の本を購入。

www.oreilly.co.jp

1か月かけて読み切ったので、購入を検討される方向けに感想をメモ。

概要

アーキテクトとして必要な知識を丁寧に丁寧に今風の視点から解説した本。

実践的なアーキテクチャの解説から関係者とのコミュニケーションまで様々な角度から知識の説明がなされ多くの場面で読み返したいと感じた。

本書に実際のコードはあまり登場せず、詳細な実装よりも高レベルなアーキテクチャパターンの説明にも重点を置いてる。

良かった点

伝統から先端までアーキテクチャパターンを広く説明している。

本書の中盤では、伝統的なレイヤードアーキテクチャから流行り?のマイクロサービスまで、パフォーマンス・コスト・スケーラビリティ等様々な観点から、多くのページを割いて評価している。

これ一冊を読んでしまえば割と多くのパターンをカバーしてしまえる。良いコード/悪いコードで学ぶ設計入門現場で役立つシステム設計の原則などの設計入門的な書籍を読んだ後にこの本を読めば新米アーキテクトとして知っておくべき最低限の知識は補完できるのではないだろうか。

アーキテクトの仕事の進め方を具体的な事例で紹介している

開発者とどんな関係性であるべきか、アーキテクチャの理解を進めるためのプレゼンテクニック、ビジネス側との交渉方法など、分析手法からちょっとした言葉遣いまでアーキテクトの具体的な業務の進め方を説明している。

自身が今まで失敗してきた事例はおおむねこの本にアンチパターンとして言及され、対処法まで細かく説明されているので、アーキテクトのみならず開発者も業務に入る前に通読しておくとストレスが少ない。

用語の説明など初心者への導入部分が手厚い

本書の序盤では、そもそもアーキテクチャとは?、何が良いアーキテクチャなのか?など定義や用語の説明に全体の1/3ほどのページを割いており、アーキテクト駆け出しの私でも序盤の説明があるおかげで本書を通読することができた。

また意外と図表も多く用いられており、「この説明図にする必要ある?」と感じるほどだ。(しかしこれが記憶の定着に役立つのかも)

注意が必要な点

本書は具体的なコードはほとんどなく、アーキテクチャの抽象的な説明(ex. イベント駆動)が多いので具体例は引用されているリンクやGitHub上のコードを探して読むと良い。

また丁寧に用語の説明があるとはいえ、私の場合は初めて聞く技術や概念も多かったので、読書中はnotionに知らない単語をメモしつつ適宜調べて文章への理解度を深める工夫をした。

まとめ

今回は「ソフトウェアアーキテクチャの基礎」を読んだ感想を述べた。

場面に応じて読み返すことで、より精密な理解を得られるので普段の業務中に手元に置いておきたい。

【書評】「Linuxカーネルの教科書」を読んだ

背景

c言語のmainメソッドはどこから呼ばれるのか?を追求した本 を読むにつれてOS(Linux)の知識不足を痛感し、半分読んだところで読み進めることが辛くなってきた。

さらに読み進めるためには、知識を補完する必要があると感じ以下の本を購入。

info.nikkeibp.co.jp

この記事はそれを読んだ時の感想であり僭越ながら書評です。

書評

想定される読者レベル

  • 基本情報レベルの知識がある
  • WSLでもDockerでも何でもいいのでLinuxのような環境でコマンド操作をしたことがある人

良いところ

内容としては、Linuxカーネル周りの初歩の初歩が広く浅くカバーされていると感じた。

この網羅性を割と読みやすい分量でまとめてあり、本腰を入れれば1週間以下で読了できるのではないかと思う。

また各章の最後には、サンプルプログラムを動かし章の内容を「手を動かして」裏付けるような演習があり読者の理解を進めやすいような工夫がされている。

タスクスケジューリングのシミュレーション

物足りないと感じたところ

本の後半は難解と感じる分野が登場したが(コンテキストスイッチ・メモリ管理)、ページ数の関係から若干省略されたような説明が目立った。

もちろん概観をつかむのが本書の目的であるため、より深く時間をかけて理解したいという方はLinuxのしくみがおすすめ。(まだ読んでない

Linuxのしくみ」を書店でパラパラめくったところ「Linuxカーネルの教科書」よりさらに演習が凝っていてかつカバーされる範囲が多いので、「Linuxカーネルの教科書」を読み終えた後に読んでみると良いと感じた。

まとめ

というわけで「Linuxカーネルの教科書」を読んでの感想等をまとめた。

もちろんいい本だと思うのでインフラに興味が出始めた方や、インフラエンジニアを目指す人にはお勧めしたい。

以上。

NestJS x TypeORMでcustom repositoryをDIしたかった

注) やりたいことについて、ただ失敗しただけなので有用性は有りません

これはなに

NestJSのORMとしてTypeORMを使っていた際、かゆいところに手が届かなかったので、これのメモ

背景

TypeORMは自動生成したRepositoryをDI(注入)し、saveupsertメソッドを独自実装することなく使用できる。

@Module({
  imports: [TypeOrmModule.forFeature([User])], // Dynamic module
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}
@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User) // users.module.tsでprovidersに登録されたrepositoryをDI
    private usersRepository: Repository<User>,
  ) {}

  async findAll(): Promise<User[]> {
    return this.usersRepository.find();
  }
  ...

しかしこの方法だとDB操作に関する処理を独自に追加したくなったとき、サービスクラス(ロジック)にDBに関する処理が流出してしまう。 また単体テストを書く際に、Repositoryをモックしづらく、テストコードの整備が進まない。

そこでStack overflowを参考にTypeORMのRepository<T>を継承したクラスを追加

export class ArticlesRepository extends Repository<Article> {
  async customSave(dto: CreateArticleDto): Promise<Article> {
    console.log('custom save called!!');
    return await this.save(dto);
  }
}
@Module({
  // entityでなくrepositoryを引数に渡す
  // https://stackoverflow.com/questions/60777204/typeerror-repository-method-is-not-a-function-nestjs-typeorm
  imports: [TypeOrmModule.forFeature([ArticleRepository])],
  controllers: [ArticleController],
  providers: [ArticleService],
})
export class ArticlesModule {}

実行、、、失敗

[Nest] 74  - 07/26/2022, 8:55:33 AM   ERROR [ExceptionsHandler] this.repository.customSave is not a function
TypeError: this.repository.customSave is not a function
    at ArticleService.create (/backend/src/articles/article.service.ts:13:28)
    ...

調査するとこんなIssue

カスタムリポジトリのインスタンスは @nestjs/core ではなく typeorm ライブラリによって生成されるため、依存性注入機構を利用することはできません。それでも、EntityManager (typeorm からカスタムリポジトリに渡される) を使って、いつでも別のカスタムリポジトリのインスタンスを取得することができます。

なんだと、、、

EntityManagerをDI(コンストラクタインジェクション)することはできんのか、、?

PS) Laravelでクリーンアーキテクチャやるときみたいにロジックはインターフェースを使うよう(抽象に依存)にしたらいいのかも

まとめ

  • よく言われる「NodeのまともなORM問題」の一端に触れた気がする
  • 今やるならPrismaなのか???
  • 指摘歓迎