4月3週

自粛でモチベーション管理が難しい

土曜：1h

  • 本当にモチベーションが上がらずでどうしようもなかったので一旦プログラミングから離れて病院行ったり・部屋の模様替したりした。。。
  • goのドキュメントを１時間読んだくらい・・・

日曜：3h

  • reactにてCRUDアプリ作成
  • reduxを使って書いているけど今は何を使っているのか・・・変遷が多すぎて整理せねば

月曜：11h

  • actionsにaxiosの処理を書く

  • componentに記述したイベントは以下の流れで最終的にreducerで状態を処理する

  • component側

async onDeleteClick() {
    const { id } = this.props.match.params;
    await this.props.delete_event(id);
    this.props.history.push("/");
  }

const mapDispatchToProps = { delete_event };

export default connect(
  null,
  mapDispatchToProps
)(reduxForm({ validate, form: "eventShowForm" })(EventsShow));
  • reducer/events.js
export default (events = {}, action) => {
  switch (action.type) {
    case READ_EVENTS:
      return _.mapKeys(action.res.data, "id");
    case DELETE_EVENT:
      delete events[action.id];
      return { ...events };
    default:
      return events;
  }
};
  • connect関数
  • map

火曜：11h

- 好奇心を持つ。今流行っている技術、これから流行りそうな技術、古典的な基礎技術。この3つのカテゴリについて情報を収集し、読みたい本をストックしておく。積んでおくのも良いし、その本の存在を心に留めておくだけでも良い。読みたい読みたい、早く時間を作りたい...という「技術書を読みたい欲求不満」を自分の心の中に育てて、ついに読める喜びにエクスタシーを感じる変態になると良いと思います。
- 仕事の中で学ぶ。忙しい日々の中、仕事の外でさらに勉強時間を持つことは難しいです。だから、仕事の中で学ぶようにします。「あ、あそこで書かれていたテクニック、この仕事で使えるじゃん！」と気付いて、使ってみる、ということです。そのためにも、事前に情報をキャッチしておくことが大事です。使ってみたいテクニックのストックを用意しておいて、その中から今の仕事に使えるものをピックアップして使うわけですね。
- 好循環を作る。たとえば...「EXCELに書かれた固定文言をJSON形式の設定ファイルに手で転記するのはダルいな...」「そうだ自動化しよう」「VBAからやると...ふうむ、文字列を連結するしかないの？ エスケープ処理とか、絶対にトラブりそう...」「そうか、WSHからCOM経由でEXCELファイルにアクセスすれば、JavaScriptでEXCELが読めるのか...JavaScriptならJSON出力はお手の物ですぜ」「やった、自動化に成功！」...みたいな流れを自力で作り出せますと、いろいろな作業が効率化できますし、そこから得た学びが自分を成長させてくれます。みんなも仕事を任せてくれますし、自分も活躍感があって気持ちいい！わけです。

水曜：11h

チートシート

bash： ペーストショートカット： Shift + 0(insert)
git： ローカルのブランチ名でリモートへ登録： git push -u origin 作成したブランチ名
bash： ファイル内の文字列検索： grep -ril "検索したい文字列" .
spring： バックエンド起動： .\mvnw spring-boot:run
spring： バックエンド改行修正： .\mvnw spring-javaformat:apply
git： 特定のファイルの変更を取り消す git checkout <ファイル名>
git： 特定のディレクトリ以下の変更を再起的に取り消す git checkout <ディレクトリ名>
git： 全てを元に戻す git checkout .
git： addしたけどcommitしていない変更を取り消す git reset HEAD <ファイル名>{
git： 別ブランチの同ファイルの比較 git diff 比較元ブランチ名..比較先ブランチ名 <ファイル名>
bash： ファイル名検索（指定フォルダから再帰検索） find [検索対象フォルダのパス] -type f -name "*[検索したい文字列]*"
SQL： 実行中のプロセスを見る https://www.hirooooo-lab.com/entry/development/postgresql-check-process
SQL： マテビューのリフレッシュ REFRESH MATERIALIZED VIEW mvxc_clnt
SQL ："マテビューのリフレッシュ（上記のリフレッシュ中にselect文を発行するとリフレッシュ完了までSQLが停滞する回避策）"
SQL： 実行中プロセスをkillする SELECT pg_cancel_backend([procpid]); ※procpidは14の実行中のプロセスを見ればわかる
windows： 実行中のプロセスを検索して停止する https://mem-archive.com/2019/05/18/post-1870/
git： 未追跡ファイルを含めて退避する git stash save -u "コメント"
git： パスワード省略（初回のみ） git config credential.helper store

■リベース（コンフリクトが起こったとき）の手順（コンフリクトを解消）

・$ git add {パラメータ} ・$ git rebase --continue ・$ git commit {パラメータ} - この手順を間違えてしまい、rebaseモードが終わらない時のコマンド（HEADの状態を維持してくれる） ・$ git rebase --quit

木曜：11h

  • npm run hogeで複数のscriptを実行したいとき
    • npm-run-allを使う
    • qiita.com
    • 例えば、nuxtの起動とモックをnpm run devだけで同時に起動したいときは以下のように定義する
"scripts": {
    "dev": "run-p dev:exec mock:api",
    "dev:exec": "nuxt-ts",
    "mock:api": "node src/api/server.js"
  },
  • 今日もいい言葉をいただいた
あらゆるプロジェクトは、予算と期間の双方が不足している。（あなたのプロジェクトが、たまたま劣悪な条件だというわけではなく、あらゆるプロジェクトで予算と期間の双方が不足するのだ、ということをこの本は指摘しています。）
    なぜそうなるか。ステークホルダ（もともとは利害関係者という意味ですが、この文脈では発注者側---われわれの場合はSBKK様---の各部門の担当者を意味します）はそれぞれの要求（リクエスト）を持っており、今回確保された予算の中で、できるだけ多く自分の部門のリクエストを実現してほしいのが本音だから。



たとえばKIOSKが完成した後、追加のフィーチャーを実現するには、稟議書をあげて審査してもらい、予算を確保して、SBTに発注しないといけない。これはなかなかハードなので、今できることは今やってほしい、という気持ちになるのが自然です。


    複数のステークホルダがそれぞれにリクエストをあげてくるのですが、それらのリクエストはプロジェクトの起案段階では明確になっておらず、したがって確保した予算は簡単にオーバーします。
    予算内で、何をどこまで実現するかを決定するスマートな方法はなく、ステアリングコミッティーを作っても紛糾するだけで時間を浪費することになりがちである。
    かくして貴重な時間が浪費され、実装の時間が削られていくのである。

われわれは、さまざまなプロジェクトを体験していると思いますが、実験的・練習的なプロジェクトではない、実務に関連したプロジェクトは、まずまずこういう経路を辿ります。ふりかえって見れば、例外がほとんどないことに気付けると思います。

幸いなことに、われわれは「使いもしないソフトウェア」を作っているわけではありません。

金曜：11h

  • ミューテーションの呼び出しでハマった
  • qiita.com
  • 第3引数にroot: trueを指定すればルートからミューテーションにアクセス可能
  • commit('common/OTHER_MUTATION', payload, { root: true })

三項演算子でclassを判定

  • :class="[isCollapse ? 'el-icon-arrow-right' : 'el-icon-arrow-left']"

週次報告

  • 年間（2019/8~2020/8）目標時間（業務での設計・実装含む）：3380h
  • 今週を含む累積時間：2244h
  • 週次目標時間：65h
  • 週次実績時間：59h
  • 何を得たか：Nuxt設計
  • 何が必要か：golang基礎・認証の知見・Nuxt・React
  • 来週の目標：新機能追加