ゆるふわ技術日誌

エンジニア見習いの悪戦苦闘日記

社会人になって半年経った。

表題の通りです。

ちょっとだけ振り返っておく。

4月/5月

この辺の話は過去にブログに書いてた。

yurufuwa-tech.hatenablog.com

初めての一人暮らしで浮かれているのがよくわかる記事。

あの頃は、目覚ましかけなくても朝目が覚めてしまって、それで凝った朝食を作っていたなあというのを思い出した。

多分一人暮らしに体が慣れずに目が覚めてしまっていたというのと、業務もそれほど忙しくなかったのがあるのかなあ。

結局朝食は、目玉焼き+トースト+(ときどき)ヨーグルト+コーヒーというので安定しました。ウインナーとか毎朝焼くのはちょっとコストパフォーマンスが悪いのでやめました。

6月

なんだか必死に目の前のタスクだけをこなしていたような。

試しにそのあたりのSlack遡って見てみたら、オリジナルなライブラリ作ってプロダクションコードにマージされて喜んだり、React Nativeのアニメーションが扱えるようになってニヤついたりしてた。

あとは業務でHTML/CSS書いたり。(CSSなんて趣味のレベルでしか書いたことなかったのに、急に書くことになって雑に書いたら「コーディング規約あるよ…」って言われて死んだ)

この頃はとにかく、毎日会社にいけば新しいチャレンジができて、自分のスキルが上がっていくのが身を以て体感できて仕事が楽しいと思っていたような気がする。

yurufuwa-tech.hatenablog.com

yurufuwa-tech.hatenablog.com

TSの言語機能勉強したりとかもしていた。

記事にしていないことを含め、継続的に勉強していたのだが、いつの日かやめてしまった。

というのも、プロダクトのコードを触る程度であれば、基本的な型やinterface/enum/typeあたりがわかっていれば差し支えなく、やっても実戦に活きないと感じたから。

実戦の役に立たなければそれは無駄な知識なのか、と言われれば絶対にNOだと思うしなんでやめてしまったんだろうと、ちょっとこの記事を書きながら後悔している自分がいる。

こういうところから差は広がっていくんだろうな。

7月

驚くほどに何をやっていたか思い出せない。それくらい虚無。

それなりに毎日仕事をして、帰ってご飯食べて寝て翌朝仕事に行くという生活をしていたんだと思う。

Slack遡って調べてみたら、Reactのパフォーマンス計測/チューニング的なことをやっていた。

結局、shouldComponentUpdateを適切に書いたり、PureComponentを使って再レンダリングを抑制するのがもっとも効果がある、という結論が出て、じゃあやるか、と思ってコードに手をつけたら、構造上手をつけられないコンポーネントが大多数で、結局ちょっとだけ手を入れて終了した記憶。。。。

8月

業務は引き続きなにをやってたんだか全く覚えてないくらい無難に黙々とタスクをこなしていた気がする。

プライベートでは勉強会に2本登壇した。なぜか2週連続で。

nihonbashi-js.connpass.com

meguroes.connpass.com

喋りが苦手とかそういうのは練習不足だったのもあるし、致し方ないと思えたが、やっぱりエンジニアとして自分はイマイチなんだなと思った。

こういう場にいくと上には上がいることを思い知って辛くなってしまう。こういうタイミングで、悔しさをバネにして成長できる人は大成するんだろうと思うが、残念ながら僕はそう言うタイプではない。

こんな発言をしていた。発言当初はできると思って発言しているんだと思うが、今は全く自信がない。

9月

流石にまだ記憶にある。

ここまでの振り返りでお気付きの通り、普段の開発アイテムは一通り無難にこなせるようになって、完全に仕事がつまらなくなっていた。

そんなタイミングで降ってきた巨大開発アイテム。ある画面の挙動を変更するために、アプリケーション全体のデータ構造を変更するというものだった。

普段の開発アイテムは、雑に見積もっても大抵それ通りに終わるし、と思っていつも通りろくに既存の実装も確認せず見積もりをしたら大誤算。数日残業しまくっても終わらず、決められたバージョンでのリリースができなかった。

ここにきて初めて挫折した。

というのが半年の振り返り。綺麗にまとめて、じゃあ次の半年もがんばるぞ！って言って終わるつもりが記事を書き始めたらこうなってしまった。

慣れって怖くて最近全然仕事に対して、やりがいとか楽しさを感じなくなってしまった。

おまけに、周りはすごい人だらけ自分は上半期トータルで見ると全然成長した実感がない。

今目の前にある仕事に本気で向き合ったら、その先には何があるんだろうか。

そもそも自分がどうなりたいというのがなさすぎて、何に向かって努力すればいいのかわからない。

あるのは、自分の書いたものが意図通りに動くことは嬉しいし楽しいという気持ちだけ。とはいえそんなの学生インターンでもできる。

じゃあどうすればいいのか、何を目指せばいいのか。全くわからん。

そして、こういう自分の意思がない人は会社も求めてないだろうと思うと、余計に苦しい。

追記

将来とか知らんけど目の前の仕事は全力でやることにした。

点と点はどっかでつながるかもしれないし

スティーブ・ジョブス 伝説の卒業式スピーチ（日本語字幕） - YouTube

この動画、中学生の時に初めて見て、それなりに感銘を受けたつもりだったが、先日思い返してまた観たらその時より染みた。

TypeScriptのReadonly/Partial/Pick/Recordについてまとめる

引き続きTypeScript handbookの英語に苦しみつつ読み進めています。

ちょっとだけ日本語訳にも頼ったりしているけど許してね。

さて、今日はAdvanced TypesのMapped Typeというところに出てくるReadonly/Partial/Pick/Recordという型について。

つい先日やりたいと思っていたことが全部解決したので、自分用メモとしてまとめておきます。

www.typescriptlang.org

Readonly

これは、既存の型の各プロパティを読み取り専用にしたい時に使う型。定義は以下。

type Readonly<T> = {
    readonly [P in keyof T]: T[P];
}

使い方は、

interface SomeType {
    hoge: string;
}

type ReadonlySome = Readonly<SomeType>

これでReadonlySomeは、

{
  readonly hoge: string;
}

と等しくなります。

Partial

これは、既存の型の各プロパティをoptionalにしたい時に使う型。定義は以下。

type Partial<T> = {
    [P in keyof T]?: T[P];
}

使い方はReadonlyと変わらないので省略。ちなみに僕はこれがやりたくて、つい先日interfaceを2個書きました。。。

Pick

これは既存の型から、一部のプロパティを抜き出した型を作るのに使う型です。定義は以下。

type Pick<T, K extends keyof T> = {
    [P in K]: T[P];
}

だいぶ型が複雑になってきますね…。使い方は以下。1つ目の型引数には元となる型を渡して、2つ目の型引数には、キーを渡してやります。

interface SomeType {
    hoge: string;
    fuga: string;
    piyo: string;
}

type PickedType = Pick<SomeType, 'fuga' | 'piyo'>

PickedTypeは、

type PickedType = {
  fuga: string;
  piyo: string;
}

となります。

Record

新しい型を定義するための型。(ちょっとうまく説明できない)

定義は以下。

type Record<K extends keyof any, T> = {
    [P in K]: T;
}

使い方は以下。

type SomeType = Record<'hoge' | 'fuga' | 'piyo', string>

↑のようにするとSomeTypeは、

type SomeType = {
  hoge: string,
  fuga: string,
  piyo: string
}

と等しくなります。

実際はkeyofとかと組み合わせて、動的に型を生成するのに使うのかなと思います。

const some = {
    hoge: 1,
    fuga: 2,
    piyo: 3
};

type SomeType = Record<keyof typeof some, string>

こんな感じ？？？

所感

Readonly/Partialあたりは割とすぐ使いどころが出てきそうな感じがした。

あと、副作用として、これくらいのレベルの型の定義を読み解けるようになっておくと、他でも役に立つ気がした。

今日も朝から学びになりましたね。

JavaScriptのインスタンスメソッドを変数に代入してはいけない

JSerにとっては当たり前の事なのかもしれないが、うっかりハマってしまったので備忘録として書いておく。

こんな感じのコードがあったして…

class User {
  constructor(name) {
    this.name = name;
  }

  getName() {
    return this.name;
  }
}

const user = new User('mirin');

UserクラスのインスタンスであるuserのgetNameメソッドを呼び出します。

user.getName() // -> mirin

これは間違いなく、インスタンスかする時にコンストラクタで指定した名前が返ってきます。

しかし、以下のような感じで呼び出すと…

const gn = user.getName
gn() // -> Uncaught TypeError: Cannot read property 'name' of undefined

となる。

なぜか。

(ちょっとこの辺は正確さに欠ける表現があるかもしれないので、ご承知おきください)

JavaScriptのthisは、呼び出したオブジェクトが入ります。(アロー関数を使った場合の挙動は別になります。要注意)

user.getName()の場合は、userがthisになるため、名前を取り出す事ができますが、メソッド自体を変数に代入して呼び出してしまうと、thisはundefinedとなってしまうため↑に示したエラーが起こります。

ちなみに

実際に僕がやらかしたのは、条件によって呼び出すメソッドを変える必要があるという、割と複雑なロジックを書いていた場面でした。

結局、それくらい複雑なことをやるなら関数分けた方がいいよね、となってやめたのですが、もしインスタンスメソッドを変数に代入したい場合は、

const gn = user.getName.bind(user)
gn() // -> mirin

という感じで、bindを使ってthisを束縛してやればOKです。もしくはメソッドの定義をアロー関数を使う、でもOKです。

TypeScripのkeyofについて

TypeScriptのHandbookに一通り目を通す、というチャレンジを今週はしております。

なんとも読みにくい英語だなーなんて思いながら読んでたらkeyofという知らない演算子が出てきたので、調べてみました。

keyofが出てきたのはこちらの「Using Type Parameters in Generic Constraints」というセクション。

www.typescriptlang.org

サンプルコードを引用すると、

function getProperty<T, K extends keyof T>(obj: T, key: K) {
    return obj[key];
}

let x = { a: 1, b: 2, c: 3, d: 4 };

getProperty(x, "a"); // okay
getProperty(x, "m"); // error: Argument of type 'm' isn't assignable to 'a' | 'b' | 'c' | 'd'.

こう。

どうやら、keyofにオブジェクトのキーを渡すと、そのオブジェクトのキーのいずれかを取るUnion Typeになるみたいです。

単純にするとこう

interface HogeInterface {
    a: string;
    b: number;
    c: boolean;
}


type Keys = keyof HogeInterface;

const hogeKey: Keys = 'a';
const fugaKey: Keys = 'd'; // error

Keysは'a' or 'b'or'c'になります。

特定のオブジェクトのkeyの値しか許容しない、みたいなパターンの時に使えるって話なんだとは思うのだがこれがどこで使えるのか…というのはちょい謎。。。

誰か教えてほしい。

追記 2019/06/15

誰か教えて欲しい。

と書いていたら本当に教えてくれた方がいました。感謝。

shgam.hatenadiary.jp

結局ジェネレータって何に使うの…?って話

JavaScript基礎力強化を図っています。

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

この本を読み返しながら、知識のないところを学習するシリーズ。

※先に結論を話すと、表題に関して答えを見つけられませんでした😉

ジェネレータについて話す前に、イテレータについて。

JSのイテレータについてざっくり

他の言語にあるイテレータ同様、繰り返しのための機構で、JSの場合Array/String/Map/SetなどがIterable(イテレート可能)なオブジェクトです。

イテレート可能なオブジェクトは[Symbol.iterator]という名前で、iteratorプロトコルに準拠したメソッドを実装しています。(Symbol.iteratorについては前回の記事参照)

developer.mozilla.org

詳しくは↑のMDNをみてもらうとして、ざっくり説明すると、

  • nextという名前のメソッドを持つ
  • 呼び出した時に{value: any, done: boolean}なオブジェクトを返す

というのがイテレータの条件です。

上記の条件を満たすことでfor..ofが使えたりします。もちろん自作のクラスに対して実装してあげてもOK。

で、ジェネレータは？

で、なぜイテレータについての説明を先にしたかというと、ジェネレータは呼び出すとイテレータを返す特殊な関数のことです。

こんな感じで定義します。

function* generator() {
  yield 'hoge'
  yield 'fuga'
  yield 'piyo'
  return
}

function*とyieldという特別なキーワードを使って宣言するのが特徴で、この関数を呼び出すとイテレータがかえります。

const it = generator();
it.next(); // -> {value: 'hoge', done: false}
it.next(); // -> {value: 'fuga', done: false}
it.next(); // -> {value: 'piyo', done: false}
it.next(); // -> {value: undefined, done: true}

こんな感じ。

何が起こっているかというと、ジェネレータが返したイテレータを実行していくと、ジェネレータ内のyieldまで実行して、渡された値を返します。 実行はその時点で一旦ストップし、次に呼ばれたら、前回のyieldの位置の続きから実行して、次にyieldが出てきたら、渡された値を返します。

最後、returnが呼ばれるとイテレータはdone: trueを返すようになります。

また、イテレータのnextメソッドには引数を渡すことができ、

function* generator() {
  const name = yield 'What is your name?';
  console.log(`Your name is ${name}.`);
  return;
}

const it = generator();

it.next(); // -> {value: 'What is your name?', done: false}
it.next('mogami');
// Your name is mogami.
// -> {value: undefined, done: true}

みたいな感じで、前回実行したyieldの返り値がnextに渡した値になります。

何に使えるのか

やっとここで何に使えるのか、という話になります。

オライリー本では、イテレータ/ジェネレータの説明は12章で行われているのですが、14章 非同期プログラミングのところで再度ジェネレータが出てきます。

ジェネレータランナーという関数を用意することで、非同期処理が同期的に書けるという話。

本のソースコードを引用すると、

function grun(g) {
  const it = g();

  (function iterate(val) {
    const x = it.next();
    if (!x.done) {
      if (x.value instanceof Promise) {
        x.value.then(iterate).catch(err => it.throw(err));
      } else {
        setTimeout(iterate, 0, x.value);
      }
    }
  })();
}

こんな感じの関数を用意してやって

function* fileReadAndWrite() {
  const dataA = yield readFile('a.txt');
  const dataB = yield readFile('b.txt');
  const dataC = yield readFile('c.txt');  
  yield writeFile('d.txt', dataA+dataB+dataC);
}

(readFile/writeFileはいずれもPromiseを返す関数)

最後にこのジェネレータを最初に作ったジェネレータランナーに投げ込む

grun(fileReadAndWrite);

すると、非同期処理が同期的に書けて人間にみてもわかりやすいよね、と書いてありました。

とはいえ、コレって今となってはasync/awaitで解決しちゃう問題なんですよね…。

async function fileReadAndWrite() {
  const dataA = await readFile('a.txt');
  const dataB = await readFile('b.txt');
  const dataC = await readFile('c.txt');  
  await writeFile('d.txt', dataA+dataB+dataC);
}

fileReadAndWrite();

こうか？

で、よりわけわからなくなった。

じゃあもうジェネレータって何に使うのよ、って感じですね。

はぁ…。

RegExp.prototype.execが偶数回しか動かない謎に遭遇したハナシ

先日、既存のコードのテストをしていたところ、正規表現のマッチの結果が実行するごとに変わるという謎の現象に遭遇しました。

適当な例を作るとこんな感じ。

const regExp= /\*\*(.+?)\*\*/g; // MarkdownのBoldの箇所を抽出する正規表現
const markdown = "こんにちは。今日の気温は**33度!**とめっちゃ暑いので熱中症に注意しましょう!"

regExp.exec(markdown);

意図としては、Markdownの文章中からBoldのところ(アスタリスク2つで始まり、間になんらかの文字があって、アスタリスク2つで終わる)を抽出するという感じ。(もちろん実際のMarkdownパーサを書くならもっと考慮する事はありますが。。。)

実際には、これがUtil系の処理の一部として組み込まれていて、場合によっては数回叩かれるケースがある、というようなコードでした。

さて、これを実行してみると以下のような結果になります。

regExp.exec(markdown)
/* ↓結果
[ '**33度!**',
  '33度!',
  index: 12,
  input: 'こんにちは。今日の気温は**33度!**とめっちゃ暑いので**熱中症に注意**しましょう!',
  groups: undefined ]
*/

Node.jsで実行していますが、ブラウザでも同じだとおもいます。

見事「33度!」という値が取り出せているので、これで良さそうな感じがします。

しかしこれと全く同じコードをもう一度実行するとこうなります。

regExp.exec('/hoge?fuga=thisisvalue')
null

なんということでしょう…。

ちなみにこれ以降、もう一度実行すると成功し、さらにもう一度実行すると再びnullになるという挙動を繰り返します。

MDNのexecメソッドの説明をみると以下のように書いています。

developer.mozilla.org

exec() メソッドは、指定された文字列内で一致するものの検索を実行します。結果の配列、または null を返します。

実はこれが罠で、結果の配列を返すというのは、一致する全ての結果を配列で返すという意味ではないのです…。

今回正規表現にgフラグが付いているのに気づいたでしょうか…?

これはグローバルフラグと呼ばれるもので、文字列中から正規表現に一致する全ての結果を得たいときに使います。今回の例の場合、これをつけるとexecは実行するたびに、前回ヒットした位置より後ろで、正規表現にマッチする箇所がないかを探すという挙動をします。

探した結果、存在しなければnullを返します。偶数回しかうまくいかなかった原因は、1回目は文字列を先頭から探して、ヒットする箇所があったので値が返却されましたが、2回目の実行では、前回のヒット位置より後ろ側にヒットする箇所がなかったためnullが返ります。これが今回遭遇したバグの原因となっていました。。。

どう解決するか

解決アプローチは複数あります。

まず1つ目。RegExpクラスのインスタンスは前回のヒットした位置をlastIndexというプロパティで持っています。

developer.mozilla.org

lastIndex は、次のマッチの始まりの位置を示す、正規表現インスタンスの読み書き可能な整数値のプロパティです。

とあるので、この値をexecの実行前に0に戻してあげれば、毎回同じ結果を返す事になります。

ただし、通常gフラグを使うという事は、複数マッチする事が想定されているはずなので、毎回0に戻すと、先頭のマッチしか取得できなくなってしまいます。

そこで2つ目のアプローチは、String.prototype.matchを使うというパターン。

developer.mozilla.org

こちらはexecとは異なり、gフラグが付いている正規表現を使用すると、一致する全ての箇所が配列となって返ってきます。

"**hoge** fuga piyo **puyo**".match(/\*\*(.+?)\*\*/g);
// -> [ '**hoge**', '**puyo**' ]

ただしこちらは、マッチした位置のindexなどの詳しい情報や、カッコを使ったキャプチャ(正規表現内でカッコを使うとカッコ内の文字を取得できる)を使う事ができないため、必要に応じてマッチした文字列をさらに加工する必要が出る可能性があります。

……あ、もちろん先頭のマッチ結果しかいらないならgフラグを外す事でexecの結果は冪等になりますことよ!

要件次第というところかなとは思いますが、一つ言えるのはgフラグが付いている正規表現を使うときはロジックを一度確認してみたほうが良いということですね。

なるべく副作用のない関数を書きたいと心がけているのですが、まさかこんなところに罠が潜んでいるとは…。という感じでした。おわり。

ES6で追加されたSymbolって結局なんなのか

JavaScript基礎力強化を図っています。

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

この本を読み返しながら、知識のないところを学習するシリーズ。

ES6から新たにSymbolという型のデータが追加されました。

developer.mozilla.org

Symbol() 関数は常に一意の値を返します。symbol 値はオブジェクトのプロパティ識別子として使われます。symbol 型はこの目的のためだけに使われます。

とのことなので、実際にどんな感じで使われるのかをみていこうと思います。

シンボルの特徴

シンボルはSymbol()関数で作ることができます。

先頭が大文字なのでクラスっぽいですが、new Symbol()は使えず、 エラーになります。

Symbol()は呼ばれる度に一意な値を返します。つまり

Symbol() === Symbol() // -> false

となります。

使われ方 その①

MDNにもあるように、シンボルはオブジェクトのプロパティ識別子(=キー)として用いることができます。具体的には

const sym = Symbol()
const obj = {
  [sym]: 'hoge'
}

ということができます。([sym]としないと、symという名前のキーになってしまうので注意)

これが具体的に役に立つケースは、既存のオブジェクトやクラスに対して、プロパティを追加したりするパターン。

Symbol登場以前は既存のオブジェクトやクラスに対してプロパティを追加する際に、キーが競合する可能性があるのを回避する手段がありませんでしたが、Symbolは作成する度に一意な値となることが保証されているので、安全に行うことができます。

const TATEGAKI = Symbol();

// Stringのインスタンスメソッドに縦書き(1文字ごとに改行)にするメソッドを追加する
String.prototype[TATEGAKI] = function () {
    return Array.from(this).join('\n')
}

console.log("文字列"[TATEGAKI]())

これでESの仕様で縦書きにするメソッドが実装されても(笑)自分の作った縦書きメソッドと衝突する恐れはないので、実行系が新しくなった瞬間に既存のコードが壊れるといった現象を回避することができます。

使われ方 その②

シンボルにはSymbol()を使って自分で作る値だけではなく、事前に定義された値があります。

その中の一つに、Symbol.iteratorという値があります。この値は、イテレート可能なオブジェクト(StringやArray、Map、Setなど)がイテレータを持つときのキーとして使われています。

"Stringはイテレータを持っています"[Symbol.iterator]; // -> function
new Date()[Symbol.iterator]; // -> undefined

なぜシンボルをキーに使うかについては、以下の記事が大変わかりやすかったです。

qiita.com

ざっくりとまとめると、

  • JSには特殊メソッド(使用者が上書きしてはいけないメソッド)を定義する方法がない
  • いきなり、イテレータを返すメソッドの名前を仕様で決め打ちにしてしまうと、正常に動かないプログラムが発生する可能性がある
  • そこで定義済みのシンボルを用意し、その値をキーとして用いることで、安全に特殊メソッドを実装することにした。

という感じ。言語の仕様を考えるような人たちって、本当に頭いいんですね…と思いました。