元公務員のエンジニア。仕事、プライベートに悩みながらも前向きに生きたいと思ってる成人男性のブログ

ふりかえりって楽しい(2020.04.13 ~ 2020.04.19の週報)

ふりかえり エンジニア ソフトウェア 週報 TypeScript Golang

今週考えていたこと

  • ふりかえり会をやる意味について
    • 短期的に達成したいこと
      • コミュニケーション不足の解消
      • コントローラブルなことに目を向けることでのストレス軽減
    • 中期的に達成したいこと
      • あんまり考えてなかったかも
        • まず短期の目標達成が優先
        • 先の計画を立てて行動するのが苦手
          • その時の状況、環境などを考慮して決めていけばいいのでは？
    • 長期的に達成したいこと
      • 会社の文化としてふりかえり会が定着している
        • 会社の文化って誰が作るの？
          • 会社にいる個人の良さがうまくマージ(溶け合って)して出来上がるものというイメージ
          • そうした時に考えるべきことは、自分の良さとか自分が得意なこと、好きなことを黙々とやっていくこと。
          • 意図して作ろうとすると、しらけた感じになりそう

フロント

  • TypeScriptの型
    • Literal型
    let clothSize: "small" | "medium" | "large" = "large"
    
    const cloth = {
    
    color: "white",
    
    size: clothSize
    
    }
    cloth.size = "small" // compile error
  • typeエイリアス
  • void型
    • TypeScriptは関数でundefinedを返すことを許していない
  • unknown型
    • anyより少し厳しい制約がある。
    • 基本的にanyと同じく代入できるが、代入した値を利用する時には、型を保証する必要がある
        let unkniwnInput: unknown
        
        let text: string
        
        unkniwnInput = "hello"
        
        text = unkniwnInput // Type 'unknown' is not assignable to type 'string'.
        
        if (typeof unkniwnInput === "string"){
        
        text = unkniwnInput
        
        }
  • TypeScriptのコンパイラー
    • tsconfig.json
      • include/exclude
      • sorceMap
        • ブラウザでTypeScriptをデバッグしたい時に使用する。
          • JavaScriptからTypeScriptを生成する際に使用される
  • TypeScriptでClassを使う
  • Interface
    • Objectの型
      • オブジェクトのみ利用可能 <=> Type
      • オブジェクトにはInterface, 変数はTypeを利用する
    • Interfaceを満たしているのであれば、問題なし
      • 部分的に構造を定義することが可能
    • Interfaceで関数の型を定義する
            interface addFunc {
              (num1: number, num2: number): number;
            }
  • インターセクション
        type NumberBoolean = number | boolean
        type StringNumber = string | number
        type Mix = NumberBoolean & StringNumber
        
        const TEST1 : Mix = "TEST" //  TS2322: Type '"TEST"' is not assignable to type 'number'.
        const TEST2 : Mix = true  //  TS2322: Type 'true' is not assignable to type 'number'.
        const TEST3 : Mix = 100
  • Type Guard
        class Dog {
          speak() {
            console.log("bow")
          }
        }
        
        class Bird {
          speak(){
            console.log("tweet")
          }
        
          fly(){
            console.log("fly")
          }
        }
        
        type Pet = Dog | Bird
        function havePet(pet: Pet) {
         if(pet instanceof Bird){ 
           pet.fly()
         }
        }
- [https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/instanceof](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/instanceof)

        // HTMLElement => HTMLInputElementへの型アサーション
        const input1 = <HTMLInputElement>document.getElementById("input")
        const input2 = document.getElementById("input") as HTMLInputElement // jsxを使用している時にはこちらの方が紛らわしくない
        (document.getElementById("input") as HTMLInputElement).value = "hogehoge"
        interface Designer {
          name: string;
          age: number;
          [index: string]: string
        } // TS2411: Property 'age' of type 'number' is not assignable to string index type 'string'.
        
        interface Designer{
          name: string;
          age: srting;
          [index: string]: string
        } // ok
  • 関数のオーバロード
        function toUpperCase(x: string): string;
        function toUpperCase(x: number): number;
        function toUpperCase(x: string | number): string | number {
          if (typeof x === "string"){
            return x.toUpperCase()
          }
          return x
        }
        
        const hello1 = toUpperCase("hello")// string
        const hello2 = toUpperCase(20) // number
  • Nullish Coalescing
        const downLoadData: DownLoadedData = {
          id: 1
        }
        
        const userData = downLoadData.user ?? "not-set" // undefined or null の時に「not-set」になる
[https://blog.jxck.io/entries/2019-08-14/nullish-coalescing-optional-chaining.html](https://blog.jxck.io/entries/2019-08-14/nullish-coalescing-optional-chaining.html)
  • LookUp型
    • objectのメンバー型を取得する方法
        interface DownLoadedData {
          id: number;
          user: {
            name?: {
              first: string;
              last: string
            }
          }
        }
        
        type id = DownLoadedData['id'] // number
        type user = DownLoadedData['user'] // user
        function copy<T>(value:T): T {
          return value
        }
        
        console.log(copy<string>("ddd").toUpperCase())

        class DataBase<T extends string | number | boolean> {
          private data:T[] = [];
          add(item: T){
            this.data.push(item)
          }
          remove(item: T){
            this.data.splice(this.data.indexOf(item), 1)
          }
          get(){
            return this.data
          }
        }
        
        const database1 = new DataBase<string>()
        database1.add("string-only")
        
        const database2 = new DataBase<number>()
        database2.add(11)
        
        const database3 = new DataBase<boolean>()
        database3.add(true)
  • kyeof
        // 柔軟なジェネリクスを作りたい時
        function copy<T extends {name: string}, U extends keyof T>(value:T, key: U) {
          return value[key]
        }
        
        copy({name: "test", age: 20}, "age)
        interface Todo {
          title: string;
          text: string;
        }
        
        type Todoable = Partial<Todo> // オプショナル型
        
        const todo: Todoable = {
          title: "s"
        }
  • conditional Types
        type ConditionalType1 = "tomato" extends string ? number : boolean // number
        type ConditionalType2 = string extends "tomato" ? number : boolean // boolean

バックエンド

                    buffer := make([]byte, 4)
                    size, err := io.ReadFull(reader, buffer)

                    r := strings.NewReader("some io.Reader stream to be read\n")
                    
                    if _, err := io.Copy(os.Stdout, r); err != nil {
                        log.Fatal(err)
                    }

その他

学習中

  • https://www.udemy.com/course/typescript-complete/
    • 体系的に学習したい & 倍速でサクッと学習したい
    • ハンズオンなのでわかりやすい
  • Goならわかるシステムプログラミング
    • 会社の上司に勧めらた本
    • 難易度高いな〜と感じてて寝かせてたけど、気合入れて読んでみたら意外と読めてる

Goならわかるシステムプログラミング（紙書籍＋PDF版）

学習終了

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

こんなご時世だからこそ、自分ができることに集中したいよねと強く感じた1週間(2020.04.06 ~ 2020.04.12の週報)

ふりかえり ふりかえり エンジニア ソフトウェア 週報

今週のハイライト

  • 会社のメンバーで1週間のふりかえりを試験的に始めてみました（僕が巻き込んだ形）

    • 理由としては二つ

      • リモートワークでコミュニケーションが減っており、ラフな話ができる機会を設けたいと感じた。
      • コロナの影響でアンコントローラブルな事象は増えており、ストレスの変数が多くなっている。

    • なんで「ふりかえり」なの？

      • 自分自身の行動・思考をふりかえることで、アンコントローラブルな事象ではなく「コントロールできる」ということに意識を向けることで、ストレスの軽減を実現したい
    • どんなふりかえりをしたの？
      • 「ファン・ダン・ラーン」というフレームワークを用いたふりかえり
        • 「Fun」「Done」「Learn」という軸で、1週間の行動・考えていたことを書き出してもらう。
      • あえて「KPT」はやらない
        • KPTをやる場合、「Problem」に意識してしまいがちなのでは？と思っている。
          • 平常時でKPTはとても有効だと思うが、非常時に課題に意識がいくと「ただしんどい」という状況が生まれてしまうのでは？という仮説を持っています。
    • やってみてどうだった？
      • 自分が感じたこと
        • ファシリテートとタイムキーパーを同時にやるのはむずい。ファシリテートに集中したい。
        • スプレッドシートでにふりかえりを記載してもらったが、シートの構成、運用などあいまいな部分があると感じた。
    • 今後どうするの？
      • 継続したいと思っている
        • ふりかえりの力は、継続してようやく実感できるので、少なくとも１ヶ月は続けたい
        • シートの改善、フレームワークの選択などチャレンジできることはたくさんあるので、少しづつやっていく

今週のアウトプット

logmi.jp

  • 読んでいて面白いと感じた部分

・ 究極的に、技術というのは我々にとっては手段です。プロダクトの価値を最大化させ事業を成功させることこそが目的。この目的を忘れないことが非常に重要だと思っております。

・もともとザ・スタートアップの時にはモノリシックなPHPのシングルリポジトリのアプリケーションで動いていたのですが、やはり当時は少ない人数でrapidに開発していたというところで負債もたくさんたまっております。

  • 感想
    • 技術負債よりも別の課題解決を優先した結果、技術負債も溜まってしまう。スタートアップあるあるな気がする。 　- 技術負債を見越して、「あえて実装しない」ということもできるようになりたいと感じた。(割と高等テクニックな気がする)
      • スタートアップは１プロダクトに集中して開発することがほとんどなので、技術負債が出てしまうのは仕方ない気もする。
    • 技術負債を許容した上で、ドメインの課題解決するのに力を注ぐことは適切ではあるけど、最適解ではない気がする
      • では最適解は何か
        • プロダクトのロードマップを描ける人間(プロダクトマネージャー)が、技術負債を意識した上で適切な機能開発を行うか、意思決定していくことだと思う。
        • ドメインの課題解決と技術負債とのバランスを絶妙に取れる人が、初期のスタートアップには必要ではないか。
        • 上記を実現できる人材は、なかなかいない印象がある。

フロント

バックエンド

その他

2020.03.30 ~ 2020.04.05

ふりかえり エンジニア ソフトウェア 週報

今週のハイライト

  • あまり技術的なことをキャッチアップすることがなかった。詰まったことをメモ書きしているので、キャッチアップが少ないということは、詰まらずに作業できているのかも。
  • リモートワーク疲れてきた。全く外に出れないことってストレスでしかない。身体的な疲れと言うよりも、「いつまで続くのか」という先が見えない状態にしんどさを感じている
  • とはいえ、自分にできることにフォーカスして日々を過ごしたいと思っている。手洗いうがい、アルコール消毒！
  • そろそろこの週報のクオリティも上げたい！

フロント

  • 広域的に広く公開されるメソッド、変数に関しては省略しない方がよい

    • グローバルに参照される変数、メソッドがある場合、名前を省略すると意図しない使い方になってしまい、結果バグとなる。
    • そういったバグを避けるためにも、少し長くなってしまってもいいので、意味が正しく伝わるメソッド名、変数名を考えたい。
      • 逆に狭いスコープなどの変数は省略してもいいのでは？
        • private, ループの中での変数宣言など

  • TypeScript

  • React useStateでオブジェクト扱いたい問題

バックエンド

その他

2020.03.23 ~2020.03.29の週報

エンジニア ソフトウェア 週報 ふりかえり

今週のハイライト

  • 基本情報技術者試験を受けようと思ったけど、コロナの影響で中止。勉強に当ててた時間を別のことに使おうと思う。何勉強しようかな〜

フロントエンド

    

バックエンド

その他

- LRU(Least Recently Used)は、ページアウト要求があった場合に管理している中で「最後に参照された時刻が最も昔であるページ」を置換え対象とするアルゴリズムです。このアルゴリズムにより最近参照されたページが主記憶に残り、使用頻度の低いページは新しいページと入れ替わることになります
- PMBOKによればプロジェクトにマイナスの影響を与えるリスク(脅威)への対応戦略には「回避」「転嫁」「軽減」「受容」の4種類があります。
    - 回避
    リスクそのものの除去や、プロジェクトのスコープや目標を縮小・変更するなどしてリスクの影響をゼロにする戦略。
    - 転嫁
リスクのある業務・作業のアウトソーシングや、損害保険の契約によってリスクによるマイナスの影響を第三者へ移転する戦略。
    - 軽減
リスクの影響範囲を狭くしたり、発生確率を低減したりする戦略。
    - 受容
リスクが現実化した時の影響が許容可能範囲内である場合やリスクの除去が困難であるときに、特に対策をせずにそのままにしておく戦略。対策費用が予想される損失金額を上回っているときなどに採られる。

2020.03.16 ~ 2020.03.22 の週報

ふりかえり エンジニア ソフトウェア 週報

この記事は何？

1週間の振り返りとして、インプットしたことを「週報」という形でアウトプットしたもの。 業務では、フロント(React,TypeScript)とバックエンド(Golang)が多いので、その辺りのインプットが多い。 また、仕事を進めるにあたりマインドセットに課題を感じているので、その辺りのインプットも多めとなっております！

フロントエンド系

lodash

Axios

エラーハンドリング

  • Axiosのエラーに型をつけて書くだけで、エラーハンドリングがとたんにしやすくなったのを実感した。

TypeScript

  • ジェネリクス
  • 記事
    • https://logmi.jp/tech/articles/322649

      • そもそも型とは、値とその値に対して実行できる操作の集合ということはもうみなさんご存じですよね。私はけっこうこれが目から鱗でした。

      • 数字で「2」とあったらこれはnumber型だよねとか、「text」って文字があったらtext型だよねというのはなんとなくわかっていたんですが、それに対して、型が決まると実行できるアクションが決まるというのは、言われてみれば当たり前のことなんですが、文字にされると「あっ、そうか、そういうことか」ということですごく腑に落ちました

      • 自分もこの記事を見て、「あ〜確かに」と腹落ちした。
      • 「型が決まると実行できるアクションが決まる」 = コードを理解する時間が短くなる。という理解。
        • コード読むってしんどいよね...
      • ただ、コード量が多くなるので、全てのプロジェクトで使うべきかは、検討する必要あり。複雑なプロダクト(ドメインが複雑である)を作る時には、有効だという理解をしている。

コンポーネント とロジックの分離

async/await

スプレッド構文

react-router

バックエンド系

その他考えていたこと、学び

プルリクのお作法

  • ブランチを切ったら、まずは空でも良いのでPRを作る
    • 周りの人がタスクをやっているかも知れんし、見といてくれるかも
  • フローを整理すると。。。
    • タスクをもらう
    • ブランチを切る
    • PRを作る(空でも良い)
    • PRに作業内容を記載
    • 上長に報告
    • 一旦、このフローでタスクをこなしていく中で、改善を積み上げていく。

どのタイミングで周囲の人と相談するのがベストか

  • 自分の経験との差分が大きい場合
    • スキルと経験の棚卸しをしていないと、差分が見えない
      • ex) フロントエンド => Reactはできるけど、TypeScriptは厳しそう
      • ex) バックエンド => 簡単なモデリングはできる
    • 経験を積んでいくと、差分は小さくなるので、周囲との相談が減っていきがち？
  • 解決すべき論点が多い場合
    • 前提：タスクに取り掛かる前に論点の洗い出しを行う(一人 or チーム)
    • 論点の構造化をすると把握しやすそう
      • Google Docで大論点、中論点、小論点を意識して書き出してみる
    • 自分のスキル、経験でどの論点まで検討・解決できるのか目星をつける。
    • 解決できない物が多いと感じたら、ヘルプを求める
      • 「多い」とはどのくらいか、タスクをこなす中で言語化していきたい。

マインドセット

  • タスクフォーカス
    • 自分のタスク(課題)にフォーカス、それ以外については仲間を信頼する。
    • https://logmi.jp/tech/articles/322464

      • たちはその意識を変えることはできるんですね。外側の環境を変えることはできませんが、自分がその環境をどう捉えるかということは変えることはできるんです。今日の覚えて帰ってほしいことの1つは「コントロールできないものと戦わない」ですね。わからないものはわからない。変えられないものは変えられないんです。