mongolyyのブログ

開発(Javascript, Typescript, React, Next.js)や開発手法(スクラム, アジャイル)、勉強したことについて色々書ければと。

「オブジェクト指向 JavaScriptの原則」を読んだ

はじめに

メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。 今回、3連休に次の書籍を読んだので、その感想を書いていこうと思います。

感想

プリミティブか参照型か意識するようになった

ラッパーオブジェクトの存在により、プリミティブ型であってもメソッドが使えていたということもあり、以前はあまり意識していませんでした。
本書を読んで、ラッパーオブジェクトの仕様などが丁寧に説明されており、非常にわかりやすく理解できました。
また、 type ofinstanceof に対して、正直なんとなーくで使っていましたが、本書を読んで、プリミティブ型の場合は type of でそれ以外の独自のオブジェクトについては instanceof という理解が進みました

内部プロパティを知った

関数オブジェクトは [[Call]]、通常のオブジェクトは [[Put]][[Set]][[Get]] などの内部プロパティ、メソッドを保有していることを知りました。 またこれらの値を使って、関数かどうか判定したり、setter、getterの処理が保有されていることを知りました。
内部プロパティの一部は Object.defineProperty() で設定ができるということも初めて知りました。

これを知って、TypeScriptのreadonlyやgetterの記載をしたときに、 Object.defineProperty() を使用したコードにトランスパイルされているのでは?と感じ、実際に次のコードをTypeScript Playgroundでトランスパイルしてみました。

class Employee {
  readonly id: string;
  name: string;

  constructor(id: string, name: string) {
    this.id = id;
    this.name = name;
  }

  get label() {
    return `名前は${name}`;
  }
}

TypeScript: TS Playground - An online editor for exploring TypeScript and JavaScript

面白いことに、TargetをES5としたときと、ES2015にした場合で結果は異なりました。

  • ES5の場合
"use strict";
var Employee = /** @class */ (function () {
    function Employee(id, name) {
        this.id = id;
        this.name = name;
    }
    Object.defineProperty(Employee.prototype, "label", {
        get: function () {
            return "\u540D\u524D\u306F".concat(name);
        },
        enumerable: false,
        configurable: true
    });
    return Employee;
}());

本書で習ったObject.definePropertyが使われてました。

  • ES2015にした場合
"use strict";
class Employee {
    constructor(id, name) {
        this.id = id;
        this.name = name;
    }
    get label() {
        return `名前は${name}`;
    }
}

classが追加されたせいなのか、トランスパイルされた結果もTypeScriptで実装したものとほぼ同一になっていました。
確証はありませんが、classが追加されたことにより、このような変化が生じたのだと思いました。

おわりに

JavaScript初級者という方で、言語仕様をもっと知りたいという方におすすめの一冊でした。
一方、ES2015からクラスが追加されていたり大きな変更があるのに対し、本書はES5ベースで書かれているので、無用とまではいかずとも、注意が必要にも感じました。

最後に、自分の仕事観点での、個人的感想です。
普段はTypeScriptを使っているのですが、仕様がJavaScriptに由来するものなのか、TypeScriptに由来するものなのか意識できていなかったということに気付かされました。

通常のTypeScriptを使用した実装では直接役に立たないかもしれませんが、何か不具合調査のためにトランスパイルされたコードを読んだり、JavaScriptで書かれたライブラリのコードをサクッと読む場合も、JavaScript本来の仕様を知っていることで、理解のしやすさ、深さは変わりそうだなと思いました。
本書はその役に立ちそうにも感じましたし、他の本や情報源も使って、継続的に学習したいと感じました。

「Real World HTTP」を読んだ

はじめに

こんにちは。メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。 前々から気になっていた「Real World HTTP」を読んだので感想を書いていこうと思います。

感想

読み物として面白かった

Cookieの細かい仕様や、HTTP2については概要は知っていたものの、本書をきっかけに理解を深められました。
また、HTTP3、WebRTCについては知識がほとんどなかったのですが、この機会に学べてよかったです。
これらについて、適度な粒度で体系的にまとまっている書籍などもなかなかないように感じるので、Web系のエンジニアの方は手元に置いておいて、辞書的に読むのはおすすめだなと感じました。

クライアントを作るのは新鮮だった

サーバー側の実装は業務などでよくありますが、HTTPクライアントを作ってみるのは初だったので、面白かったです。
特に、HTTPS通信のために証明書を読み込んで、というところは、普段は触れない部分なので、興味深かったです。手を動かしながら学びたい派の方におすすめだなと感じました。

終わりに

HTTP周りについて体系だってまとめられている書籍はなかなかないので、Web系のエンジニアの方は手元に置いておき、知識を広げるためにぜひ読んでみるといいのでは、と思いました。

令和3年度 技術士一次試験(情報工学)の合格体験記

はじめに

今回、技術士情報工学部門で合格できたので、その体験記を共有します。

どのくらい勉強したか?

勉強時間は合計20時間くらい
期間は1ヶ月くらい

何を使用して勉強したか?

次の本を一通り読みました。
よくわからなかったり、忘れそうなところはNotionにメモを残して、繰り返し確認できるようにしていました。

上記の本で基礎を一通り押さえた後、下記の本を使って3年分の過去問を解きました。
情報処理技術者試験と異なり、同一の問題が出題されるということはなさそうという事がわかりました。

結果はどうだったか?

という感じでした。
過去問では適正科目は8割以上取れていましたが、少し低くて、自己採点中はちょっと焦りました。

終わりに

情報工学部門の一次試験の合格率は55.1%と高かったので、勉強時間の確保ができさえすれば合格できそうだと感じました。
また、情報工学の場合は、高度情報処理技術者試験保有者向けの専門科目の免除措置があるので、それもあって合格率が高くなっていそうだと感じました。

二次試験もがんばります!

TypeScriptにおいて、とある型の一部のプロパティのみを必須にする型エイリアスを定義する

何がしたいか?

TypeScriptにおいて、とある型の一部のプロパティのみを必須にした型を作りたいとします。
次の例で言うと、とある型(User)を元に、一部のプロパティ(age)を必須にした新たな型(AdultUser)を作りたいとします。

type User = {
  name: string
  mail: string
  age?: number
  phone?: string
}

// 成人のユーザーの年齢プロパティは必須
type AdultUser = {
  name: string
  mail: string
  age: number
  phone?: string
}

// ageがundefinedになっていることを防ぎたい
const adult: AdultUser = {
  name: 'テスト太郎',
  mail: 'test@example.com'
}
// 次のエラーが発生する
// Property 'age' is missing in type '{ name: string; mail: string; }' but required in type 'AdultUser'.

上記の例の場合はプロパティの数が少なかったので良かったですが、実際はもっと項目が多かったり、Userのプロパティが頻繁に変更されるとミスが出てくると思います。
今回はそのために簡単な型エイリアスを作りましたので、紹介したいと思います。

どんな型エイリアス

type SomeRequired<T, K extends keyof T> = Omit<T, K> & Required<Pick<T, K>>

Utility Typesを使いました。
Utility Typesについては公式のドキュメントを読んでください。 www.typescriptlang.org

新たに定義したSomeRequiredを使うと、次のようにAdultUser型を定義することができます。

type AdultUser = SomeRequired<User, 'age'>

const adult: AdultUser = {
  name: 'テスト太郎',
  mail: 'test@example.com'
}
// 次のエラーが発生する
// Type '{ name: string; mail: string; }' is not assignable to type 'AdultUser'.
//   Property 'age' is missing in type '{ name: string; mail: string; }' but required in type 'Required<Pick<User, "age">>'.

また、OmitPick と同様に、| を使うことで複数の項目を必須にすることができます。

type NewAdultUser = SomeRequired<User, 'age' | 'phone'>

const newAdult: NewAdultUser = {
  name: 'テスト太郎',
  mail: 'test@example.com',
}
// Type '{ name: string; mail: string; }' is not assignable to type 'NewAdultUser'.
//   Type '{ name: string; mail: string; }' is missing the following properties from type 'Required<Pick<User, "age" | "phone">>': age, phone

終わりに

Utility typesを知っている方なら簡単にわかる型エイリアスだと思いますが、知らなかった方は是非使ってみてください!

「レガシーコードからの脱却」を読んだ

はじめに

こんにちは。メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。
最近David Bernsteinさんの研修を受ける機会があり、これをきっかけに、積んでいた「レガシーコードからの脱却」を読みました。
本の感想を残しておこうと思います。

感想

守破離について

本書では「守破離」が紹介されており、とりあえず何も考えずに師匠に言われるがままにやって(=守)、その後、その背景にある理論を理解し、実践する(=破)というステップがアジャイルにはあると書かれていました。

確かに、実体験として、理論はわからずに上司や先輩から教えてもらって、数年がむしゃらにやって、その上で「クリーンアーキテクチャ」や「ドメイン駆動設計」を読んでしっくり来たという経験がありました。
人にもよるとは思いますが、腹落ちさせるためにも、とりあえず言われるがままにやってみるというのは重要かと思いました。

一方、私見ですが、自分自身含めて周りを見ていると、「守」に慣れて、同じプロセスを改善する方に行ってしまい、破の領域に行かなかったり、違う方に行ってしまうことがあるなーとも思っています。
面倒かもしれないですが、自分自身、周囲を鼓舞、刺激し、破(≒理論の理解)の領域に達せられるようにしたいなと感じました。

第一原理について

第一原理や原則について深く書かれているなとも感じました。
今まで読んだ本ではあまり言及されていなかったようにも思います。
私は本書を通して、「第一原理が存在し、その上に原則が存在し、その原理、原則を背景として、XPやスクラムのプラクティスが存在する」というように理解しました。
スクラムをやっていると、プラクティスに目が行ってしまう人を見かけることがありますが、スクラムマスターとして、そのプラクティスの背景を理解し、そういう人に説明していくべきだなーと、感じました。

全ては会話から

ラクティス1の「やり方より先に目的、理由、誰のためかを伝える」、プラクティス4の「協力しあう」を読んで、コミュニケーションの重要性を再認識しました。
スクラムやXPでも色々なプラクティスがありますが、共通して「コミュニケーションを取る」ということを背景に作られているものも多そうだと感じました。
更に、コミュニケーションにより、共通認識を育てたいというのが大きな目標としてあるようにも感じています。
共通認識があると、モチベーションが上がるだけでなく、業務とプロダクトの乖離が少なくなるので、より変更容易性の高い、高品質なプロダクトができるとも思うようになりました。

テスト駆動開発について

テスト駆動開発を行うことで、良いプロセス、設計をもたらし、結果として高い品質のプロダクトが作られるというように理解しました。
今までは、"良いプロセス、設計"の意識がまったくなかったのですが、ふるまいを考えて、テストしやすさを考えて作っていくことによって、良い設計になりそうだなと、本書を読んで感じました。
また、「小さく作る。リファクタリングをする。」という健全なプロセスが自然と入ることにもなるので、そういう観点でも高品質なプロダクトが生み出せそうだと感じました。

終わりに

レガシーコードをリファクタリングして良くするというお話かと思いきや、普通にチームビルディング、ソフトウェア開発に生きそうなプラクティスとその背景が丁寧に書かれており、非常に良かったです。
他にも、良いコードの特徴(「CLEAN」コード)なども紹介されており、エンジニアとして参考になる部分もありました。
各章が比較的独立しているので、興味のある章だけをチームで輪読するのも良さそうだと感じました。

ドメイン駆動設計における「エンティティ」と「値オブジェクト」の違いについて

はじめに

同僚と「ドメインオブジェクトが~~」みたいな話をしていて、「ドメイン駆動におけるドメインオブジェクトの扱いってなんだったっけ?」と思ったことをきっかけに、調べたり、考えたりしました。
また忘れるので書き留めておこうと思います。

本題

ざっくりですが、次のような違いがあると思っています。

  • エンティティ
    • 同一性の概念がある
  • 値オブジェクト
    • 同一性の概念がない

それによって、次のような特徴が生まれてきます

  • エンティティ
    • 同一性を判別するためのキーが存在する
    • キー以外の項目は変更される可能性がある
  • 値オブジェクト
    • 全てのフィールドが同一であれば、振る舞いは同一になるので同一とみなせる
    • 逆にどれかのフィールドが変更されると同一とは見なせないので、不変であるべき
    • String, Intのようなプリミティブな型の代替として、表現力を増すために使われることが多そう

ここからは私見です。
書籍でエンティティも可変となっていますが、"不変であっても良く、むしろそのほうが、バグは発生しにくいのではないか" とも思っています。

参考書籍

終わりに

よく忘れてしまうので、書き留めておきました。
他の特徴があればまた追記しようと思います。

2ヶ月でUMTP L1~L3 を取得したので、その合格体験記

はじめに

メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。
11月中旬頃から勉強を初めて、1月中旬に無事UMTP L1~L3まで取得することができたので、その記録を残しておこうと思います。
UMTPに興味を持たれている方のお役に立てれば幸いです。

どんな資格?

UMTP/JAPAN 特定非営利活動法人UMLモデリング推進協議会」が主催している、UMLの理解、モデリング能力が問われる試験になっています。
求められるレベルは、それぞれのレベルで異なっており、公式サイトの説明では次のようになっています。

UMTP L1:UMLなどを使ってモデリングを行う最低限の知識を持っている。
UMTP L2:UMLモデルの読み書きが普通にできる。 開発範囲の一部を担当し、モデリングができ、他者のモデルの意味を理解できる。
UMTP L3:実務でモデリングが実施できる ・拡張性や変更容易性などの点で高品質なモデルを定義できる。 ・特定分野の専門的な知識を備えている

試験概要 より抜粋

なぜ取ろうと思ったか?

  • Clean Architecture本を始め、設計の書籍では共通言語としてUMLが当たり前に出てくる。しかし、自分のUMLの理解が不十分であることにより、書籍の理解が中途半端になっていそうと感じたから
  • チームで設計について議論するときに、標準を知っておくことで、より効率的にモデリングの議論ができるようになりそうだと思ったから
  • 最近、「現場から学ぶモデル駆動設計」勉強会が頻繁に開催されており、自分の中でモデリング熱が上がってきたから

勉強法

UMTP L1試験

参考書を解きました。
今回購入した本以外は絶版になっていそうであったので、消去法で選択しました。

選択理由はポジティブではありませんでしたが、内容は非常に丁寧で、UML自体の理解が不足していた自分にとっては丁度いい本でした。

勉強期間:一ヶ月(11月中旬~12月中旬)
参考書:次の書籍を購入


受験した感想:
思った以上に簡単、かつ、短時間で解けました(時間は半分も使っていなかったように思います)
点数は96%でした。(80%で合格)

UMTP L2試験

こちらも参考書を解きました。
UML自体はUMTP L1の学習のときに把握できており、モデリング自体は自分は好きなのでサクサク進められました。

勉強期間:二週間(12月中旬~12月末)
参考書:次の書籍のオンデマンド(ペーパーブック)版を購入


受験した感想:
当然L1より難しさは増したものの、短時間で解けました(時間は三分の一~半分くらいは残っていたと思います)
点数は86%でした。(65%で合格)

UMTP L3試験

参考書がないので、いい勉強方法はわからなかったです。
やったことは、公式のサンプル問題とUML関係の書籍を読むくらいです。

勉強期間:二週間(1月上旬~1月中旬)
参考サイト:
umtp-japan.org
読んだUML関係の書籍:


読んだ感想は mongolyy.hatenablog.com
その他過去読んだもので参考になった書籍:

クラス設計の指針を把握する上で参考になりました。
受験した感想:
L2よりも難易度はかなり上がっていました。
ITSSによると、レベル3(=応用情報と同じ)とのことでしたが、問題のレベル的には、レベル4のデータベーススペシャリストにも近いように感じました。
時間もギリギリで、7分くらいしか残っていなかったと思います。
点数は82%でした。(60%で合格)
問題数が少ないので、部分点がもらえない採点方式だとすると、一問落とすとだいぶ点数が削られそうな気がしています。(採点方式をご存知の方、教えていただけると幸いです)

取得した後の変化

取得してから二週間程しか経過していませんが、よかったことは次の二点です。

  • 設計の書籍を読むときに、一々調べることが減った
  • モデリングとは?設計書とは」を見直すきっかけになり、自分の考えを明確にすることができるようになった
    • どう思うようになったか?について、詳しくは、 mongolyy.hatenablog.com の記事をご覧ください

最後に

UMTPを取得している人って、あまり見たことなかったですが、UMLを知っている、モデリングできるというのは開発手法によらず大事なことだと思っています。
それに目覚めるためにも、是非UMTP試験にチャレンジしてみてください!