devlog

主に web 開発とかプログラミングについて書きます

サイボウズにエンジニアとして入社して1年たったので振り返る

f:id:nkgr:20200614194214j:plain
うちの子供がiPadで書いたピカチュウ

今一緒に仕事してる同僚がブログこんなブログを書いてて、触発された感じです。 せっかくなので自分も記録として残そうと思います。

note.com

これが自分の転職初日のツイート

この時も完全にsakitoさんのツイッターみて、俺もやろうってパクったやつ。

パクリ駆動発信。

まず軽く自己紹介

ブログでは何も書いてなかったと思うので自己紹介をしておくと

2019年6月からkintone開発チームでプログラマーをしています 大阪オフィスに所属しています。ただし新型コロナウイルスによる感染拡大に伴い、今は自宅からリモート開発しています。

主にkintoneの新規機能開発のプロジェクトに参画しています。

最近 Cybozu Tech Meetup #1 kintone開発チーム というイベントで登壇しました。

「kintone × リモートモブプログラミング」

cybozu.connpass.com

入社するまで

サイボウズが転職二回目です。

新卒でSIerに入り7年くらい働いたあとに1度転職して、toB向けの自社クラウドサービスの開発・保守をやっているところに入りました。

いわゆるSIerからWeb系エンジニアに転職したというやつです。

そこからサイボウズ に転職したのは、サイボウズは優秀なエンジニアが多く在籍しているイメージで、そこに入って自分ももっとスキルアップしたいと思ったからです。

実は新卒で入ったSIerを退職するときに、当時の上司(課長)に「自分は2年以内にエンジニアとしてサイボウズかY社に入るのが目標です。」と言って出て行きました。

当時の上司からすると「こいつ何言ってんだ?正気か?」みたいな感じだったのではないかな〜と思います。(当時の上司に会ったらドヤ顔したいw。いや、実際あったらしないけど。)

入社してから感じたことなど

めっちゃ情報がオープン

社内のコミュニケーションは kintone や Garoon 上で行われており、プライバシーやセキュリティに関わること以外はほぼフルオープンです。

オープンなコミュニケーション自体はすごく良いと思っています。オープンであるからこそいろんな人が議論に参加できますし、議論の経緯をあとから見ることができます。

ただ、すべての情報を見ることはできないので、自分で自分に必要な情報を見極める必要があります。 全部みてるととてもじゃないけど時間が足りないです。これが結構難しくてこれは今でも課題です。

早く結果を出したくて焦っていた

中途入社の人あるあるだと思いますが、即戦力として入社するわけなので、早く成果を出せるようになりたいと焦っていた時期がありました。

kintone チームはモブプログラミング を採用しています。

kintoneのモブプログラミング に関してはこちらの記事をご参照ください

blog.cybozu.io

入社して3ヶ月くらいは、モブの中であまり発言ができずモヤモヤした時期が続いていました。

ドライバーをやればただ、指示通りコードを書くだけでナビゲーターになっても特に有用な発言ができないことがありました。

もちろんkintoneのドメイン知識もありませんし、スキルとしても自分が足りていないこともあってなかなか結果を出せていなかったと思います。

早くチームに慣れるために意識していたこと

モブの中でとにかく質問すること

自分の中でよく使った手法としては

「認識があっているか確認させてください!○○っていう認識であってますか?」

っといって自分の理解があっているかメンバーに確認していました。

自分の言葉で言語化すると自分の頭が整理されますし、間違っていればちゃんと指摘してもらえます。

自分が理解できないままモブが進んでいくのが一時期ストレスだったのでちゃんと分かっていないときにはモブを止めるようにしました。

ドライバーの回数を多めにやる

モブの中で今やっている作業や次にやることを呟きながらドライバーをやります。

ドライバーは指示を待つことも可能ですが、自分が宣言しながら進めると早い段階でナビゲーターから指摘が入り軌道修正しやすいです。

またナビゲーターは逐一指示する必要がないので周辺コードをみたりちょっと先を確認するなど視野が広がります。

結果として慣れていない人がドライバーをやることで学習が進みますし、クオリティの高いコードをかけるのかなと思います。

ドライバーをやることでより集中して作業に取り組めますが、どうしても視野が狭くなりがちで周辺のコードに気を配れなかったり考慮漏れが発生してナビゲーターから指摘を受けます。

この流れ自体は悪くないですがやっぱりみんなコードを書きたいのでずっとこの方法をとることはベストではない気がします。

空き時間を使ってコードを読む

モブを実施する時間は9:45~17:00と決まっているので、朝の9:00~9:45, 17:00~18:00までは各人の勉強時間などに当てています。 この時間を使って、今取り組んでいるタスクの周辺のコードを読んでみたり、モブでは採用しなかったコード修正の方法を試したり など探求をすることで kintoneのドメイン知識を得ていくようにしています。

最近は少し慣れてきたので、少し先で実装しそうなタスクの事前実装調査をして仕様の実現方法を試したりしています。

最近挑戦していること

kintoneのReact化

基本的にkintoneの新規機能開発を実装してきましたが、4月くらいから kintone の React化というプロジェクトに取り組んでいます。

kintoneのフロントエンドは

Closure Tools  |  Google Developers

というライブラリでほぼできています。

2010年にリリースされたフルスタックフロントエンドのライブラリで、このライブラリ自体はGoogleGmailなどに採用していることもあってかなりよくできています。

ですが、ReactとTypeScriptで作る昨今のフロントエンドの開発と比べると記載が冗長になったり、実装を読み解くのが難しいと感じる部分が多々あります。

以前からReact化したいという方針はありましたが、4月くらいから本格的にフロントエンドをReact化していくプロジェクトが開始しました。

元々Reactはずっと趣味運用しているサービスで使っていたり、それ以前からずっと書いてきてました。

もしkintoneのReact化が本格化する際は自分も関わりたいと思っていたので今関われてめちゃくちゃありがたいです。

このkintoneのReact化はkintone開発チームだけでなく、フロントエンドエキスパートチームのメンバーと一緒に活動しています。

フロントエンドのツール選定やビルド周りのサポート、実装方針まで今は一緒のモブの中で開発しており、いつもフロントエンドエキスパートチームのメンバーの専門性には助けられています。

blog.cybozu.io

多分Cybozuの一番の福利厚生はプロダクト開発チームが特定技術要素の専門チームのサポートを受けれることだと思います。

kitnoneのエンジニアはフロントエンドとサーバーサイド両方を開発する必要があるので、技術探求が分散しがちです。

特定技術要素で専門性の高いメンバーがサポートしてくるのは心強いです。

サーバーサイドのテストコード改善

hamcrest -> AsserJ移行

kintoneのサーバーサイドのテストコードは JUnit4 + hamcrestを使っていました。

今後 JUnit5に移行していくにあたりJUnit5では assertThatが同梱*されなくなります。

そのためhamcrestをやめてAsserJ移行をする作業を個人の空いている時間を使って進めていました。

何人かの有志メンバーで2ヶ月くらいかけてコツコツ潰しながら全てhamcrestを全て駆逐していきました。

現在は jmockitを外すためにMockUpを駆逐していく取り組みをしています。

2年目以降の展望

とりあえずまだまだ kintone のコードはわからないところが多く、先輩方に教わることが多いです。 技術力的にも足りてない部分も多く自分がモブを引っ張っいけるくらい技術力とドメイン知識をつけていくことが直近の展望です。

おまけ

We are hiring!!!!

kintoneチームではエンジニアを募集しています!

興味がある方がいらっしゃれば、カジュアル面談なども行っていますお気軽にお声がけください🙇🏻‍♂️

もし興味あるという方は、TwitterでDMいただければ、幸いです!

https://twitter.com/nkgrnkgr

cybozu.co.jp

勉強会で手を上げて発言し辛い問題を解決するサービスをリリースしました🎉

f:id:nkgr:20200125201523p:plain
PutYourHandsUp

リリースしたサービス

pyhu.nkgr.app

サービスの概要

f:id:nkgr:20200125212115p:plain
いいねや返信も可能

f:id:nkgr:20200125212542p:plain
投稿画面

  • 勉強会のその場で使える、グループチャットライクなサービスです。
  • 匿名 / Twitter / Google でログインし利用できます
  • 「感想/質問など」タグをつけて投稿できます
  • Twitterハッシュタグ付きで同時投稿できます🐧
  • 使ってくれるイベント募集してます🙇🏻‍♂️

サービスを開発した背景

登壇者と参加者のコミュニケーションをもっと活発にしたい

勉強会で手を上げて質問するのはハードルが高い

f:id:nkgr:20200125202708p:plain
質問するのは難しい

  • こんな質問したらバカだと思われるかも...
  • 理解できていないのは自分だけかも...
  • さっきのスライド文字小さくて見えなかったけど今更言えない...
  • あれ?説明間違ってる?でも自信ない...
  • 仲の良い人たちで盛り上がって話しかけれない...
  • そもそも質問時間を確保できないイベントも...

結果的に登壇者と参加者のコミュニケーションがないまま終わることも

登壇者は質問、感想、指摘なんでもWelcome😆(なはず)

f:id:nkgr:20200125212317p:plain
Welcome

  • 趣旨が伝わったか知りたい
  • 説明スキルを磨きたい
  • 質問だけでなく感想も聞きたい
  • 参加者が何に興味あるか知りたい
  • 間違っていたら指摘してほしい
  • 参加者と交流して知識を深めたい

Twitterハッシュタグのタイムラインでよくないか?

  • 基本的にはTwitterハッシュタグのタイムラインと同じノリのことがしたい
  • Twitterのタイムラインは誰に向けた発言かわからないこともある
  • Twitterは匿名ではないので、ネガティブなフィードバックはしづらい
  • Twitterやってない人にも発言してほしい

Twitterに同時投稿できるので、今まで通りTwitterを使っていた人のことも邪魔しない!

サービスの使い方

詳細な使い方ページ

イベント管理者向け

イベントの作成から参加者にイベントページのURLを連携するまで

イベントページの作成

f:id:nkgr:20200125214836p:plain
イベント作成ページ

下記リンクにアクセスしログイン

匿名アカウントではイベントページのの作成ができません。TwitterGoogleでログインしてください。

新規イベントページを作成する

connpassのイベントページがあれば、イベント情報をインポートできます。

イベントページに登壇情報を追加

f:id:nkgr:20200125215114p:plain
登壇情報の追加

登壇情報を追加してください。登壇情報はイベント投稿ページからでも編集できます。

イベントページのURLの共有

イベントページの直接の共有

f:id:nkgr:20200126122721p:plain
作成したイベント一覧にURLが記載されている

作成したイベント一覧

イベントの参加者には、イベントページのURL共有してください。

イベント当日、スクリーン等にQRコードで表示するのをお勧めします。

トップページからの導線

トップページ

f:id:nkgr:20200126123249p:plain
GET STARTEDから本日開催予定のイベント一覧にもアクセスできます

f:id:nkgr:20200126123459p:plain
本日開催予定のイベント一覧

当日にURLを共有するするだけならトップページのURLでも運用可能だと思います。

f:id:nkgr:20200126125211p:plain
「putyourhandsup 勉強会」の検索結果

URLの共有が難しい場合は、「putyourhandsup 勉強会」でも検索してもらうと検索トップにでるみたいです。(2020/01/26現在)

タグによる質問の抽出

f:id:nkgr:20200126125055p:plain
タグによる質問の抽出

参加者が質問タグをつけて投稿することで、あとで質問タイムに質問を抽出することができます。Twitterのタイムラインをさかのぼるよりも効率的です。 イベント開始時に説明しておくと、よりわかりやすいと思います。

参加者向け

イベントに参加する

イベント管理者からURLを共有してもらうか、イベント一覧 にアクセスし本日開催予定のイベントにアクセスしてください

コメントを投稿する

f:id:nkgr:20200126130815p:plain
コメントの投稿

イベントページではコメント投稿することができます。

コメントにはタグをつけることができます。 質問や感想など規定のタグ以外にも、独自のタグを作って投稿することもできます。

投稿はリアルタイムに反映されます。

Twitterに同時投稿する

f:id:nkgr:20200126132118p:plain
Twitter連携を開始するにはTwitterアイコンをクリックしてください

ユーザー設定ページに遷移します

f:id:nkgr:20200126131859p:plain
Twitter連携開始画面

外部サービス連携のTwitterを有効にすると

f:id:nkgr:20200126200026p:plain
twitter連携画面

Twitter連携画面に遷移します。

f:id:nkgr:20200126200419p:plain

Twitter側のページから戻るとユーザーセッティング画面に遷移するのでそこからDashboardにアクセスしてください。

f:id:nkgr:20200126200750p:plain
Twitterに連携開始

コメント投稿時に Twitterアイコンをクリックしてください。

水色アイコンになればコメント投稿時にTwitterに同時に投稿されます。

Twitterに投稿しない場合は、アイコンをグレーのままにしておいてください。

あとがき

  • 使っていただけるイベントを募集しています!
  • 使い方については大まかには書いたが、不明点等あれば、 @nkgrnkgrにメンションしてくれれば回答します!
  • もし、私が説明しにいったほうがよければ、勉強会にも行きます!(日程が合えばですが...)
  • OSSとして開発しているのでバグ報告は issue上げてくれるとめっちゃ嬉しいです。もちろんTwitterでメンションいただいてもOKです!

Issues · nkgrnkgr/put-your-hands-up · GitHub

  • 参加者と登壇者とイベントオーガナイザーの満足度が上がると嬉しい!

【翻訳】コードを綺麗にするためにCustom Hooks を書こう

前回の続きで英語勉強の翻訳2回目。 がんばりまっちゅん。といいつつ今回の釣り画像はmodel pressさんの斎藤飛鳥さん。 やばいくらい透明感がやばい。(日本語彙力は死んでいる)

今回から英語の本文と日本語の翻訳を交互の載せる

https://img-mdpr.freetls.fastly.net/article/739B/nm/739BeYfAdQoP9TWNlHR94KYMLiewaqjWXyZmJlglhcg.jpg?width=700&disable=upscale&auto=webp

(画像4/8) 齋藤飛鳥、本音を赤裸々告白 “本当の姿”見せる

前回の翻訳記事

nkgr.hatenablog.com

ちなみに前回の翻訳記事を社内で持ち寄ってレビューし合おうって言ったが、1時間で3人全員分の記事をレビューできなかった。

結局、翻訳中の不明点を相談しあう場所にするのが良さそう。という結論になった。

あと社内で翻訳の話したら便利なChrome拡張教えてもらった。マジ感謝。

chrome.google.com

今週の元ネタ

daveceddia.com

ここから翻訳記事

React hooks make it easy to add a single piece of state to a component. But it’s also a breeze to write your very own custom hooks, just by moving the hooks-related code into a function.

React hooks を使うことで簡単に component に 単一の stateを追加することができる。 しかし hooks に関連するコードを関数の中に移動することで、カスタム hooks を書くこともできます。

Say you need a boolean true/false flag to keep track of whether a bit of spoiler text is shown or hidden. You could wire it up like this…

ネタバレの一部の表示非表示を追跡するための true / false の真偽値フラグが必要だとします。こんな風にかけます...

import React, { useState } from 'react';

function SpoilerAlert({ spoilerText }) {
  const [isVisible, setVisible] = useState(false);

  return (
    <div>
      <button onClick={() => setVisible(!isVisible)}>
        {isVisible ? 'Hide' : 'Show'}
      </button>
      {isVisible && <span>{spoilerText}</span>
    </div>
  );
}

The useState here doesn’t do a great job of expressing the intent of that state though. Don’t get me wrong – I’m not saying it’s bad, just that I think it could be better. Wouldn’t it be cool if it looked like this instead?

ここの useState は 状態管理を意とする表現としてはふさわしい仕事をしていない。誤解しないでください。私はわすりとは言っていません。ただもっとよくすることができると思っています。代わりにこんな風にすることでよいと思いませんか?

import React, { useState } from 'react';

function SpoilerAlert({ spoilerText }) {
  // useToggle doesn't exist yet, but what if it did?
  const [isVisible, toggleVisible] = useToggle(false);

  return (
    <div>
      <button onClick={toggleVisible}>
        {isVisible ? 'Hide' : 'Show'}
      </button>
      {isVisible && <span>{spoilerText}</span>
    </div>
  );
}

It’s a small change, but it reads more nicely. The onClick={toggleVisible} prop, especially, is more succinct and clear than onClick={() => setVisible(!isVisible)}.

これは小さな変更です。しかしうまく読めます。 特にonClick={toggleVisible} props はonClick={() => setVisible(!isVisible)} よりも簡潔かつ明快 です。

Let’s write the useToggle hook.

では、useToggle hook を書きましょう

Custom Hooks are Just Regular Functions - Custom Hooks は ただの習慣的な関数です

You can bundle up any chunk of hooks logic into a function to make your very own fancy custom hook! Just make sure your function name starts with “use”.

独自のカスタムhooksを作ることで、hooks のロジックのかたまりを 関数にまとめることができます。単に 関数名を"use"から始まることを確認してください。

Once you see how easy is is to write a custom hook, I think you’ll start to see uses for them all over your app.

一度カスタムフックを書くのがどんなに簡単かを一度みてください。あなたのアプリ全てで利用可能かを見始めるでしょう。

Our useToggle hook is mostly just a call to useState, but instead of handing back a general-purpose “setter” function, we’re gonna create a purpose-built “toggler” function and return that instead.

useToggle hook は ほとんど useState を呼んでいるだけです。しかし 一般的な目的の"setter" 関数の返す代わりに、特別に作った"toggle" 作成し代わりに返却します。

We’re wrapping up the setter logic to make it crystal clear to whoever uses this hook that the value is meant to be toggled.

このhook は トグルを意図している値 であるということを明確するために、setter logic をラップしています。

function useToggle(initialValue) {
  const [value, setValue] = useState(initialValue);

  const toggleValue = () => setValue(!value);

  return [value, toggleValue];
}

I think of little hooks like this as “quality of life” hooks. Did we desperately need to create this hook? Was the code really that bad before? No. It was fine. But this little bundle of 5 lines of code makes it finer.

私は "quality of life" hooks のような ものだと考えている。必ずこのhook を作る必要がある?前のコードは本当は悪かった?いいえ。よかった。しかし、この5行のコードはよりよくしたと言える。

Keep custom hooks like this in a file (say, hooks.js?), and next time you need to create a toggleable value, just import { useToggle } from './hooks' and you’re good to go!

このような カスタム hooks は 単一のファイルに保存して(hooks.js と呼ぶ)、次回トグルが可能な値を作る必要がある場合は、単に import { useToggle } from './hooks' するだけでよいです!

Another Example: useBoolean - 別の例:useBoolean

Just to hammer the point home, let’s see one more simple custom hook – another variant on a boolean value.

家に帰るだけ、真偽値を扱う簡単な別の形のhookをお見せしましょう

This one is meant for a value you need to explicitly turn ON and OFF, instead of toggle. Imagine a modal dialog with only one way to open it, and a few ways to close it (X button, Escape key, Cancel button, after a request succeeds, …).

これは、トグルの代わりに、明確にON と OFFを切り替える必要がある値を意図しています。唯一の方法で開き複数の方法でそれを閉じるモーダルダイアログを想像してください。(X ボタン、esc キー、キャンセルボタン、リクエストが成功したあと...)

You might initially rely on useState to create a boolean:

booleanの useState を最初にあてにするかもしれない。

const [isVisible, setVisible] = useState(initialValue);

Then you could define a couple helpers, and pass one of these wherever you need a callback function (like for an onClick handler or similar).

次に対になるヘルパーを定義し、コールバック関数が必要なところに、これらのうちの一つを渡すことができます。(onClick ハンドラーなど)

const showModal = () => setVisible(true);
const hideModal = () => setVisible(false);

I’d say a function called showModal is clearer than () => setVisible(true). But we can go one step further, and bundle that logic into a custom hook:

showModal が呼ばれる関数のほうが、 () => setVibible(true) よりも明快です。しかし、もう1ステップ進んで、カスタムhook の中にロジックをまとめましょう。

function useBoolean(initialValue) {
  const [value, setValue] = useState(initialValue);

  const setTrue = () => setValue(true);
  const setFalse = () => setValue(false);

  return [value, setTrue, setFalse];
}

Again it’s all about making the intent clear, and tidying up the code a bit. All we’ve done is move the state and the helper callbacks into a new function, and now we can use it in a component like this:

繰り返しますが、これは意図を明確にし、コードを少し整理することでう。stateとヘルパーコールバックを新しい関数の中に移動すれば完成です。そしてコンポーネントの中でこのように使えばよいです。

const [isVisible, showModal, hideModal] = useBoolean(initialValue);

Now you have a reusable bit of state and helper functions! The next time you need a flag to show/hide a sidebar, a tooltip, or whatever else, just import useBoolean.

再利用可能な stateとヘルパー関数を手に入れました。あなたが次回、サイドバーやツールチップなどを表示非表示するフラグが必要な時に、単に useBoolean を importします。

Look for little opportunities to create custom hooks in your own code. How can you make your existing code more expressive?

あなたのコードの中で、カスタム hook を作る機会を探してください。あなたのコードの価値が高くなりますよ!!

かなり翻訳が怪しい箇所と不明点

But it’s also a breeze to write your very own custom hooks, just by moving the hooks-related code into a function.

a breeze to の意味が難しい

Custom Hooks are Just Regular Functions

Regular をどう訳すか

You can bundle up any chunk of hooks logic into a function to make your very own fancy custom hook! Just make sure your function name starts with “use”.

fancy is なに?

I think you’ll start to see uses for them all over your app.

start to see uses の意図 が難しい

handling back

返す?くらいの意味

Just to hammer the point home

家に帰るだけ... 意味不明。

所感

  • 所用時間 4ポモドーロ
  • 前回より早くなった気がする
  • 結構微妙な比喩表現が辛い。無視した箇所もある。
  • 飛鳥ちゃんはやばいくらい透明感がやばい。

【翻訳】TypeScriptとReactHooksをつかった型安全なstateモデリング

社内の英語勉強会の宿題として、毎週英語記事を1つ翻訳することになった。 このブログを投稿してから、数日後に社内でレビューしてもらう予定。

翻訳、がんばりまっちゅん。(インスタの画像の松村沙友理さん)

f:id:nkgr:20191007193119p:plain

今週の元ネタ

Twitterで流れてきたやーつ

thoughtbot.com

ここから翻訳記事

React Hooks の力によって、class componentやglobal state(Reduxのような)を使うことなく、React Componentの中で再利用可能で構成可能な stateを管理することができるようになった。 TypeScriptのinterfaceの柔軟性と組み合わせることで、コンポーネントの状態やコンテキストを型安全に利用する方法はいくつかあります。

この記事では、React Hooks で typescript strict モード を使ういくつかの利点を示します。そして、あなたのTypeScript + React プロジェクトで使うことを検討することをお勧めします。Any型を回避し常に型を返却するようにするような一見些細なことで、型システムが、実行時エラーになる前にミスをキャッチできます。ReactのState管理のデバッグ時これは特に有効です。Reactではどこで実行時エラーが発生したかを追跡するのが特に難しい場合があります。

私たちの目標は TypeScriptの厳密な型利用を維持しながら React Hooks を使ってState管理をする方法を探求することです。(特にuseStateとuseContext) hooks や stateのデータを型安全に提供することに加え、型はアプリケーションのstateがどのように管理されているか明確にする生きたドキュメントとして機能します。

では、React Hooksを使ってユーザープロフィールstate管理をするためのシンプルな例から始めましょう。

const ProfilePage = (): ReactElement => {
  const [firstName] = useState("Foo");
  const [lastName] = useState("Bar");
  const [title] = useState("Software developer");

  return (
    <dl>
      <dt>First name:</dt> <dd>{firstName}</dd>
      <dt>Last name:</dt> <dd>{lastName}</dd>
      <dt>Title:</dt> <dd>{title}</dd>
    </dl>
  );
};

上記の例では、3つの useState が使われており、オブジェクトを使用して値を保持する単一のhook に簡略化できます。これを行う際に、オブジェクトのインターフェースも定義し、state の型モデルを適応できるようにします。

interface Profile {
  firstName: string;
  lastName: string;
  title: string;
}

const ProfilePage = (): ReactElement => {
  const [profile] = useState<Profile>({
    firstName: "Foo",
    lastName: "Bar",
    title: "Software developer",
  });

  return ( . . . );
};

Profile のためのインターフェースを作成することの利点の一つは、stateがどのように見えるかを参照できるようになったことです。useState<Profile>に渡すオブジェクトはどこからでも取得でき、Profile``` だとわかることができます。

またこのインターフェースを使うを使うことで、デフォルトの値の上書きを許容する型安全なカスタム hook を作ることができます。

interface ProfileState {
  profile: Profile;
  setProfile: React.Dispatch<React.SetStateAction<Profile>>;
}

export const useProfile = (overrides?: Partial<Profile>): ProfileState => {
  const defaultProfile: Profile = {
    firstName: "Foo",
    lastName: "Bar",
    title: "Software developer",
  };

  const [profile, setProfile] = useState<Profile>({
    ...defaultProfile,
    ...overrides,
  });

  return { profile, setProfile };
};

const ProfilePage = (): ReactElement => {
  const { profile } = useProfile({
    title: "Designer",
  });

  return (. . .);
};

この例では、 useProfile の引数に Partial<Profile> を受け入れる カスタム react hookを定義しています。もし TypeScript Partial というユーティリティ型 に詳しくない場合、既存のタイプの全ての利用可能なサブセットを表現する新しい型を定義します。 だから、Partial<Profile>は、Profileインターフェース(firstName, lastName, title)の全てのキーの組み合わせを渡すことができます。

userProfile の定義では、staticなデフォルトののセットを定義します。これは、overrides 引数を私ことで簡単い上書きできます。全てのStateをProfile またはPertial<Profile>として構成しているため、useProfile``hook の実装と呼び出し元の両方が正しいkeyとvalue を渡していると自信を持って言えます。

また ProfileState インターフェースを定義し、明確に ``userProfile```hook の戻り値の型を宣言している。これには、別のhookの中で構成したり、コンテキストの中で利用する場合に、戻り値を参照する具体的な方法があるという利点がある。

もし、複数のコンポーネントをまたがって、state のバケットを共有したい場合、おろらくもっとも明確な方法はuseContext をつかって hook を再実装することだろう。

const defaultProfile: Profile = {
  firstName: "Foo",
  lastName: "Bar",
  title: "Software developer",
};

const defaultProfileState: ProfileState = {
  profile: defaultProfile,
  setProfile: (): void => {},
};

export const ProfileContext = createContext<ProfileState>(defaultProfileState);

export const useProfileContext = (): ProfileState => {
  return useContext(ProfileContext);
};

const ProfilePage = (): ReactElement => {
  const { profile } = useProfileContext();

  return (. . .);
};

上記の例では hook の名前を useProfile から useProfileContext に変更し、React useContext hook を使って実装している。デフォルトのprofile state を定数に移動した。それ以外の点では、コンポーネントの実装はほとんど同じままです。以前はuserProfile hook の中にあったロジックは context provider に移動しました。

interface ProfileContextProviderProps {
  defaults?: Partial<Profile>;
  children?: ReactNode;
}

export const ProfileContextProvider = (
  props: ProfileContextProviderProps,
): ReactElement => {
  const [profile, setProfile] = useState<Profile>({
    ...defaultProfile,
    ...props.defaults,
  });

  return (
    <ProfileContext.Provider
      value={{
        profile,
        setProfile,
      }}>
      {props.children}
    </ProfileContext.Provider>
  );
};

最終的に、context profider を定義しそれをアプリの中で利用できます。

const App = (): ReactElement => {
  const defaults: ProfileContextProviderProps = {
    title: "Designer",
  };

  return (
    <ProfileContextProvider defaults={defaults}>
      <ProfilePage />
    </ProfileContextProvider>
  );
};

型の冗長性を犠牲にして、Reactコンポーネントの状態の強く型付けされたモデルを作成しました。stateにする値は、存在して欲しい型であり、カスタムフックのインターフェイスを変更する自己文書化された簡単な方法があると確信できます。

所感

  • 所要時間 5 ポモドーロ
  • Google翻訳にだいぶ頼った。
  • 書いてある日本語がすでに不明
  • 読むときはだいぶ端折って意味を理解している風なのがよくわかる。ちゃんと読んで翻訳しようとするとめっちゃ大変。
  • もっと効率よく翻訳できるように英語力つけよ。

会社のPCがmacOSになったので、zsh環境を見直した

表題の通りだが、zsh環境を見直した。

f:id:nkgr:20190616232129p:plain

TL;DR

zsh + zplug + peco

.zshrcなど設定ファイル類は以下のレポジトリにあります。 README.md も書いたので、もし同じような環境にしたい人がいれば、すぐに再現できるはず。。。 (まだ会社で試してないから試してからちょっと変えるかも)

github.com

きっかけ

転職し、会社の端末がmacOSになったため、自宅の環境と会社の環境を合わせたくなった。

これを機に、まずは自宅の環境を整理して、すぐに会社の環境にコピーできるように色々と整えた。

前まで zprezto を利用していたけど、zplugというのがあって、日本語のドキュメントもちゃんとあるのでこっちに移行した。

参考にしたリンク

zplug

https://blog.cheezenaan.net/dotfiles-on-github

zplugの導入 oh-my-zshのような設定にするまで。 - Qiita

cdr とか history系はこっち

pecoを使って端末操作を爆速にする - Qiita

【勉強会 雑なまとめ】関西のTyepScirpt勉強会 kansai.ts #1 に参加してきました

概要

kansaits.connpass.com

関西でTypeScriptを中心にゆるふわ交流するというのがテーマのイベントに参加してきました。 多分関西では初めてのTypeScirptに特化したイベント。

先月東京で行われたTypeScript のミートアップも4.28倍とすごい倍率のイベントでしたが、関西でも高い倍率でした。TypeScriptの人気すさまじい。

これだけの人気を集める技術要素って今だと他にないのでは? Dockerとか?

【増枠】TypeScript Meetup #1 - connpass

管理者

github.com

コミュニティのDiscord

kansai.ts

会場提供からのお知らせ

あとで更新予定

フロントエンド関連のその他イベント

その他のイベント

Laravel Meetup Connect - connpass

v-kansai Vue.js/Nuxt.js meetup #7 - connpass

発表内容

Advanced built-in types

登壇者

twitter.com

  • Node.js のコラボレーター

発表資料

speakerdeck.com

内容まとめ

以下に記載しれている TypeScript の Advanced-typesについて説明

www.typescriptlang.org

以下紹介されたTypeについて列挙。

聞いてた内容を記載しようと思ったけど、不正確なので多分発表資料のスライドを要確認

  • Partial
  • Required
  • ReadOnly
  • Pick
  • Record
  • Exclude
  • Extract
  • NonNullable
  • Parameters

会場での質問

  • 型じゃなくてInterfaceでも使えるか? -> 使えそう

  • 使いやすいのは? -> Readonly

イベント告知

jsconf.jp

所感🤔

  • TypeScritpでほぼ使ったことない機能ばっかりだった。奥が深い(こなみかん)

AWS-CDK for TypeScript を紹介するぜ

登壇者

twitter.com

発表資料

master.d1r9qwzhk27es2.amplifyapp.com

内容まとめ

  • Typescriptと見せかけて AWS の話

  • CDK -> AWS Cloud Development Kit

  • LambdaなどAWS のサービスを 構成をtsファイルから作って、ビルドしてデプロイするデモ

  • CloudFormationのテンプレート(Yamlつらいという人向け)

  • 実演で Lambda の APIゲートウェイを使って"success"と返すだけのコードをデプロイするというのを実演していだきました(事前準備済み)

  • 絶対にプロダクトコードでつかっちゃだめ!(まだPublic Beta)

質問

  • 最悪逃げるときは、YAMLを使うか? -> JSONなりYAMLで構成を吐き出せるので、最悪それを手でいじる

  • デモはどれくらい時間かかった? -> 30分くらい

  • YAMLをやめたてTSにするのはどっちが早い? => なれたら TSのほうが早い(慣れもある)

  • どのサイトを参考にしたらよい? -> NodeModule の中のTSのinterfeceを見た方が早い

雑な所感🤔

  • CloudFormation 使ってないけど、そんなにYamlつらいんだ...

ざっくりAssemblyScript

登壇者

twitter.com

発表資料

scrapbox.io

内容まとめ

  • 自己紹介-> 要 ScrapBox確認 Reactとか言語処理系とか書いてるヒト

  • WebAssemblyとAssemblyScriptに関する紹介

  • WebAssemblyが出てきた経緯の紹介

  • コンパイル後のファイル.wasmに変換できる言語 Rust, Go , Kotlinなど C ...色々 もちろん TypeScript でも

  • AssemblyScript はTypescritp の サブセット(一部機能制限がある感じ)

  • 環境構築もいつものやーつ。 npm run asbuild で.ts から.wat と.wasm が生成される(超簡単)

  • .wat は読みやすくしたやつ

  • シンプルなレポジトリも用意しているから興味あるひとはあとで発表資料見て

  • AssemblyScriptのメリット -> バックエンドもフロントエンドも、超早くしたいところもTypeScriptで書くことができる

  • 一部Rustより早いらしい

  • 一部Cよりファイルサイズが小さくなるらしい

  • AssemblyScript に関する公開されているDemoページの紹介

所感🤔

  • 説明わかりやすかった(こなみかん)

  • AssemblyScript完全に理解した

Alexaスキル開発で始めるTypeScript

登壇者

github.com

  • Alexaチャンピオンのヒト

発表資料

speakerdeck.com

内容まとめ

  • AlexaチャンピオンによるTypeScriptでAlexaカスタムスキルを作ろうよという話

  • AlexaスキルはTypeScript入門に向いている

  • AlexaDeveloperスキルアワード2019の紹介

  • 興味ない人は猫を見るスタイル

  • Alexa は「音声-> 文字-> JSON」の2ステップ

  • LambdaでJSONを受け取ってJSONで返すだけ

  • Alexa のSDKはほぼTypeScriptで書かれている

  • InputとOutputがほぼ固定なので、TypeScirptの入門向け

  • なぜ型(TS)がいるか?インプットのJSONがすごい量なので、IDEが補完してくれないとつらい

  • 初心者向けのQiita記事

qiita.com

  • ASK-CLIは .ts-> .js への変換が必要がだ、今は自動でやってくれる

  • 型があってもパラメータ探すのめんどくさい -> ask-utils など色々作ったのでIssueください

builderscon.io

質問

  • Alexaのスキルで審査あります? -> 審査あり

  • Push通知みたいなことはできますか? -> リマインダーAPIと「お知らせを開いて」といったら喋るやつがある

所感🤔

  • 確かにInput Output固定なら初心者向けに良さそう

  • VUIの開発している人すくない

Cognitive Complexity でコードの複雑さを定量的に計測しよう

登壇者

twitter.com

発表資料

www.slideshare.net

内容まとめ

codeclimate.com

  • Code Climate を使っていた中で、Cognitive Complexity という評価基準ができてたのでそれを調べた話

  • Cognitive Complexity -> 人間に取って見やすいコードになているかどうかの評価基準

  • どのようなコードならCognitive Complexityが増えるのかをサンプルを使って説明

  • よく似ている概念として、循環的複雑度という概念があるがこれとは何が違うかについても説明

質問

  • 知ったきっかけは? -> CodeClimateを調べてた

  • CIで使えるか? -> 多分使える

  • 心折れたことある? -> 指摘自体は難しくない。メソッド分割とかれすば解決できるのでいままではない

VSCode Remote で始める Nuxt生活 with TypeScript

登壇者

twitter.com

発表資料

  • あとで載せる

内容まとめ

  • VSCode Remote Developmentの話

  • TypeScirpt歴は完全に理解したレベル

  • NuxtでVSCode Remoteを使うメリットについての説明

  • 実際の使ったレポジトリの実演

  • 実際に開発環境を整えたやつのGithubレポジトリの紹介

質問

  • 拡張機能はインストールできるか? -> 事前に設定しておくと、Reopenコンテナーで勝手にインストールさる

所感🤔

  • モブとかで開発環境を共有するときとか良さそう

  • デモだとエラーになるとかはあるある。次は動画を準備するか?

TypeScirptでAPIの受け入れテストを記述

登壇者

twitter.com

発表資料

  • 後でのせる

内容まとめ

  • 登壇がはじまってからTypeScirpt の勉強した

  • シンプルに記述できるVue.jsの良さの残しながらTyepScript を一部導入できないか

  • REST API の戻り値に型を導入してみたという話

  • TypeScirptは実行時はチェックしてくれない -> Runtimeチェックしたい

  • io-ts を使って Runtime時にチェックを実施。さらにIDEでのチェックもできる

  • デモでミスしない一番のポイントはPCを持ち込まないこと(iPadPro)

github.com

質問

  • io-tsを使ったデメリットはありますか? -> テストの時だけ書くので、特に遅くなるとかのデメリットはない

覚えたことを忘れないために /「エンジニアの知的生産術」を読んだ(3)

f:id:nkgr:20190524061917j:plain

前回の続き

nkgr.hatenablog.com

今日は第3章の 「記憶を鍛えるためには」についてまとめていく

TL;DL

  • 記憶を鍛えるためにはインプットとアプトプットの繰り返しが大事。特にアウトプットの繰り返しが重要
  • 長期的な記憶を鍛えるためには、復習を一ヶ月空けるとよい
  • 自分で問題を考えると理解が深まる。

第3章 記憶を鍛えるためには

記憶を繰り返し使うことによって強化される

ただし、インプットを繰り返すのではなく、アウトプットも同様に繰り返すことが大切

本を読むだけでなく、解説記事を書いたり、LTしたりすることで記憶として定着するのではないか?

同僚と本について話すことでも鍛えられるかもしれない。

ウザくない程度で、色んな同僚に別々に本の話をしてもいいかもしれない

インプットも大事だがアウトプットはもっと大事

実験の結果、インプットを繰り返すよりもインプットとアウトプット両方をやるほうが、テストの結果がよいことがわかっている。

インプットして、覚えられたことを書き出し、またインプットしアプトプットする。

プログラミングは小さいテストの連続

「文字列を結合する関数はなんだっけ?」と思ったら、ネットでググり、それを使ってコードを書き、正しく動くことを確認する。これを繰り返すと使い方をだんだん覚えていく

記憶を長持ちさせるための間隔反復法

覚えたことをいつ復習すべきか?という問いに関しては、実験の結果一ヶ月後以降に復習した場合が最も覚えている。

長期的な記憶を鍛えるためには、一ヶ月以上開けて復習することが大事

教材を自分で作る

テストの問題を自分で作る過程で、覚えたことが整理される。 覚えた内容から、自分の記憶をテストするとしたらどのような問題を作成すべきかを考えて自分で問題を作るとより記憶が定着しやすくなる。