カンファレンス

明日明後日とQiita Conferenceが開催されますね。

皆さんはもう申し込みされましたでしょうか。

僕は既に申し込んで準備万端です。

Qiita

Qiitaについては最早説明不要かと思います。

エンジニアならば見たことが無い人はいないであろう、開発に関する知識を共有するプラットフォームです。

僕自身もエンジニアになってから現在に至るまでお世話になりまくりのサービスです。

実装で詰まった時、同じようなケースで過去にハマってしまった人が解決策を共有してくれていたりして非常に助かります。

似たようなサービスだと他にZennもありますね。

Qiita Conference

そんなQiitaが開催する今回のカンファレンス。

ドメイン駆動設計入門」の著者である成瀬允宣さんの基調講演を始め、気になるテーマが盛りだくさんです。

ドメイン駆動設計については日々の開発で取り組んでいるものの、まだまだ「完全に理解した」状態からは程遠いので少しでも学びを得て実務に活かせたらと。

他に気になるのは「今日からAuth0でしか認証機能を作りたくなくなるセッション」「ハッカー入門:公開鍵で学ぶ、ものごとの裏側を考える技術」あたりでしょうか。

あと、YouTubeで活動している藤原麻里菜さんの基調講演も個人的にめちゃくちゃ楽しみです。いつも見てます。

ご存じない方は一度見てみてください。チャンネル名どおり無駄なものばっか作ってて面白いです。

www.youtube.com

カンファレンスに参加する意義

これまでにも何度かこうしたカンファレンスに参加したことがあります。

たとえば昨年React Nativeを使ってiOSアプリを作ろうとしてたときはReact Native Matsuriに参加しました。

こういうイベントに参加すると何が嬉しいかというと端的に言えば知見が得られるということ、更に言うと自分たちの環境にも活かせそうな外部からの知見が得られるということかなと思います。

普段の業務でも日々様々な知識を得ては次の開発に活かす、ということをやっていますが、ある意味自分が担当しているプロダクトという特定の環境に限った話だったりする場合もあります。

もちろん日々の開発では個別に課題があるのでそれに対応するには、という具体的な話になってくるんですが、それを噛み砕いてもっと一般化することができれば全然違うプロダクトの似たようなケースにも応用できたりヒントになったりするんじゃないかと思います。

話をカンファレンスに戻すと、こうしたイベントでは登壇する方々が実際に取り組んだ様々な事例に触れることができます。

そうしたケーススタディを少し一般化してみると自分たちの環境と共通点が見えてきたりします。

自分が担当しているプロダクトでもこういうところがネックになるかもしれないから同じような対策が効果的かもしれない、とか。

要は具体的なケースを一般化・抽象化して、それを更に具体的なケースに落とし込むという具体⇔抽象の行き来をする為の知見が得られるのがカンファレンスという場の醍醐味かなと思います。

もちろん担当プロダクトで日々それを行うことが理想ですが、毎日開発しているとなかなか俯瞰して見られなかったりもするので良い機会なんじゃないかと思います。会社ごとに文化も異なるので課題への取り組み方も自社とは違ったりしてそこも刺激になりますし。

まとめ

というわけでカンファレンスについて書いてみました。

シンプルに色んな方のお話が聴けるのも楽しみですし、そこから自分の開発を振り返って新たな学びを活かしていければと思います。

最近ちょっと技術周りのことを書いていないような気がするので次回は何かしら技術周りのことを書こうと思います。

ありがとうInternet Explorer

今日はInternet Explorerのサポートがとうとう切れるということで、各所で話題に上がっていました。

かく言う自分もインターネットに初めて触れた頃はIEユーザーだったのでなんとなく切ない気持ちです。

というわけで今日はそんなIEについて書いてみようと思います。

Internet Explorerとは

今更説明するまでもありませんが、Internet Explorer(以下IE)はMicrosoftが開発したwebブラウザです。

最初のリリースは1995年。まだインターネットが普及するよりも前の時代です。

日本でインターネットが普及し始めたのが98年頃だと思うので、恐らく皆さんがIEを使い始めたのもIE4、ないしはIE5の頃でしょうか。

僕も実家にインターネットが開通したのが確か99年でしたので最初に使ったのはIE5でした。

その頃はブラウザ自体の数も少なく「IE vs. Netscape Navigatorネスケ)」のブラウザ戦争の真っ最中でした。

その後IEが覇権を取ったと思ったら「タブブラウザ」という今でこそ当たり前になった新しいタイプのブラウザが広まり始めました。

当時僕も「IEは重い」とか「もっと動作が軽いブラウザがある」という情報を見ては色々試したりしてました。Operaとか。

全盛期より落ちたとはいえ、それでもまだ高い市場シェアを保っていたIEでしたが、Google Chromeが躍進してからは徐々に勢いが失われ、2015年にはMicrosoftから後継のEdgeがリリースされた上に、2019年には「IEを使い続けていると最新のwebアプリケーションが使用できなくなる」とMicrosoftが公式ブログ上で声明を出しています。

You see, Internet Explorer is a compatibility solution. We’re not supporting new web standards for it and, while many sites work fine, developers by and large just aren’t testing for Internet Explorer these days. They’re testing on modern browsers. So, if we continued our previous approach, you would end up in a scenario where, by optimizing for the things you have, you end up not being able to use new apps as they come out. As new apps are coming out with greater frequency, what we want to help you do is avoid having to miss out on a progressively larger portion of the web!

引用元:The perils of using Internet Explorer as your default browser

そして今日、遂にIEのサポートが終了しました。最初のバージョンが出てから27年。長きに渡ってインターネットを支えてくれたと思います。

エンジニアにとってのInternet Explorer

一方で、エンジニアの立場から見るとIEは実に厄介な存在だった、という方も多いと思います。

フロントエンドをメインで担当している方は特にそうではないでしょうか。

ES6以降のアロー関数find()、非同期処理のPromise等、使用頻度の高いものでも対応していないものが多いです。

またCSSでもgridを始め、使用できないプロパティが存在します。

その中でIEに対応するためにIE専用のコードを書いて分岐させたり、IEでも表示が崩れないように調整したり...と工数がかかってしまう為、エンジニアにとってはあまり好ましい存在ではなかったように思います。

こうした背景からwebサービスを提供している企業は早々にIE非対応を宣言したところも多いと思います。

そんな呪縛も今日で終わりです。

しかしながら

とは言え、やはりインターネットが現在のように普及するまでに至った歴史はIE抜きでは語れないと思います。

ダイヤルアップで接続し、今とは比べ物にならないぐらい遅い回線でしたが、毎日ワクワクしながらネットサーフィンしていたのを懐かしく思います。

www.youtube.com

(当時は家族が電話してるとネットに繋げませんでした)

インターネットの楽しさを教えてくれたのは紛れもなくIEでした。改めて感謝したいと思います。

27年間お疲れさまでした。

Node.jsのパッケージマネージャーについて

Node.jsのパッケージマネージャーといえばnpmやyarnがあります。

ただ具体的にどう違うのかについてはあまり理解していなかった為、この際なので調べてみました。

npm

npm is the standard package manager for Node.js.

引用元:An introduction to the npm package manager

Node.jsの公式にある通り、npmはNode.js公式かつ標準的なパッケージマネージャーです。

2009年にOSSとしてプロジェクトが開始され、運営元であるnpm, inc.は2020年にGitHubに買収されています。

公式なのでNode.jsをインストールすると最初から入っています。なので、特別な設定等無しにすぐ使えます。

yarn

Yarn is a package manager for your code. It allows you to use and share code with other developers from around the world. Yarn does this quickly, securely, and reliably so you don't ever have to worry.

引用元:Introduction | Yarn - Package Manager

yarnはサードパーティーのパッケージマネージャーです。 開発したのはFacebook(現Meta)です。

サードパーティーなのでNode.jsとは別でインストールする必要があります。

# npm経由
npm install -g yarn

# brew経由
brew install yarn

npmとyarnの違い

2つのパッケージマネージャーについて比較してみようと思います。

依存関係の厳密さ

package.jsonを用いることはnpmとyarnとで共通ですが、当初npmに無かったlockファイル (yarn.lock)によって依存関係をより厳密に管理できるようになりました。

ただし現在ではnpmでもpackage-lock.jsonを作成するようになっているのでこの点では差はありません。

速さ

これは一般的にyarnの方が速いと言われています。

色々な検証記事が沢山出ているので気になる方はチェックしてみてください。

As previously stated, Yarn installs dependency packages in parallel, whereas NPM installs them sequentially. As a result, Yarn outperforms NPM when installing bigger files.

引用元:NPM vs Yarn: Which package manager should I use?

セキュリティ

初期のバージョンのnpmではセキュリティ面での懸念がありましたが、version6以降ではパッケージインストール時にセキュリティ評価を行うようになっています。

一方のyarnもパッケージのダウンロード時にセキュリティチェックをバックグラウンドで行っています。

その為、この点でも差は無さそうです。

まとめ

総じて見ると大きな差は無さそうですが、速度の面でyarnに軍配が上がりました。

とはいえ結論としてはどちらでも好きな方を選べば良いような気がします。

また、僕自身全く知らなかったのですがpnpmというパッケージマネージャーもあるようで、「他のツールよりも最大2倍高速」らしいです。

pnpmについてはまた改めて調べてみようと思います。

Nuxt 3での変更点について

業務でNuxtを使っていますが、使用しているバージョンは2系です。

なので最新バージョンであるNuxt 3について変更点など調べてみました。

デフォルトでTypeScriptをサポート

一番大きいのはこれじゃないでしょうか。

これまでReactに比べてTypeScriptとの相性はイマイチ、という声もちらほら聞かれたVueでしたが、Next.js vs Nuxt.jsという構図でも同様だったかと思います。

しかしNuxt 3ではデフォルトでTypeScriptをフルサポートしています。設定ファイルもnuxt.config.tsとなります。

なのでNuxt使いたいけどTypeScript使いたいからNextかな、となっていた方にとってはNuxtを選択する十分な理由になりうると思います。

JSX / TSXもサポート

JSX / TSXJavaScript (TypeScript)の中でHTMLタグが使えるよう拡張した構文のことです。

たとえば、Reactの例ではこんな感じ。

const sampleComponent = () => {
  return <p>Hello, world!</p>
}

これもReactのイメージが圧倒的に強いですが、Nuxt 3ではこちらもフルサポートしました。

ただ、個人的にはそこまで嬉しいポイントでは無いというのが正直なところです。

以前少しだけReactの勉強をしたことがありましたが、JSXの独特の癖みたいなものがあまり好みではありませんでした。

Vite

Nuxt 3ではビルドツールにViteを採用しています。

ViteはVueを開発したEvan You氏が新たに開発したツールで従来に比べてビルド時間がかなり高速になるようです。

サーバーの立ち上げは勿論、開発中のHot Reloadも高速になる為、快適に開発を進められるはず。

Viteの存在は知っていたのですがまだ試せていなかった為、これは個人的にかなり気になる点です。

Vuexが含まれていない

Nuxt 2ではVuexが最初からパッケージに含まれていましたが、Nuxt 3では外れました。

じゃあStore的なものを使いたい時はどうすれば?と思ったのですが、useState()という関数を使うと可能なようです。

が、そもそもNuxt 3以前にVueのComposition APIを使ったことがないのでまずはそこからですね。。

あと関係ないですがuseStateと聞くとどうしてもReactのuseStateと混同してしまいそうです。

まとめ

以上、簡単にではありますがNuxt 3で変わった点について書いてみました。

今回調べてみて俄然使ってみたいと思ったので近々何かしら作ってみようと思います。

社内LT会で発表しました(2回目)

先月に引き続き、社内LT会で発表しました。

資料はこちら。

今回はNuxtのserverMiddlewareについて話しました。

簡単にまとめると、

  • NuxtのserverMiddlewareを使って簡単にAPIサーバーを立てられた
  • ごく簡単なアプリケーションならこれだけで良さそうな気がする
  • ただNode.jsの知見が無いので実践で活用するにはまだまだ

という感じです。

ただとりあえずNuxtだけでもある程度のことはできそうだということはわかったので大きな収穫です。

実装もnuxt.config.jsに

// Server middleware
serverMiddleware: [
  '~/api/'
],

を追加して、/api/index.jsに

const express = require('express')
const axios = require('axios')

const app = express()

app.get('/', (req, res) => {
  res.json({
    message: 'hoge'
  })
})

app.get('/advice', async (req, res) => {
  const advice = await axios.get('  https://api.adviceslip.com/advice')
  res.json(advice.data)
})

module.exports = {
  path: '/api/',
  handler: app
}

こんな感じで書くだけでAPI用のルーティングが追加できます。

ブラウザでアクセスするとこんな感じ。

実際にはコンポーネントから叩くイメージでしょうか。

async asyncData({ $axios }) {
  const response = $axios.$get('/api/advice')
  console.log(response)
}

みたいな。

Expressで拡張できるので他にも色々できそうです。ロガーを追加したりDBやredisに接続したり。

ただ↑でも書いたようにNode.jsのベストプラクティスがわからないので要勉強です。

また次回以降も学習内容を整理して登壇したいと思います。

Immutableについて

昨日チーム内でImmutableについての話をしたので今日はその辺りを書きたいと思います。

Immutableとは

Immutableとは一般的に不変と訳され、状態変更ができないことを意味します。

逆に状態変更ができることをMutable(可変)と言います。

Mutableなクラスだけで実装するとクラスの外部からでもクラス内の変数を書き換えることが可能になります。

簡単に書き換えられてしまうと思わぬところで値が変わっていて想定と異なる挙動をすることに繋がり、バグの温床となります。

1つ悪い例を挙げてみます。

class Car
{
    public Body $body;

    public function __construct(Body $body)
    {
        $this->body = $body;
    }
}

class Body
{
    public $color = 'red';
}

上記のようなCarクラスとBodyクラスがあるとします。

$body = new Body();
$myCar = new Car($body);
echo $myCar->body->color . PHP_EOL;

新しく$myCarというインスタンスを生成します。

これを実行するとBodyクラスをデフォルトのまま変えていないので、

red

という文字列が出力されます。

ここでもう1つインスタンスを生成します。

$yourCar = new Car($body);
$yourCar->body->color = 'blue';

もう1つインスタンスはボディの色を青にします。

ここで

echo $myCar->body->color . PHP_EOL;

とすると、

blue

と出力されてしまいます。

$yourCarの色を変えたつもりが$myCarまで色が変わってしまいました。

修正すべき点

同じ$bodyを使いまわしていることも原因の1つですが、そもそもCarBodyもMutableなクラスです。

どちらもプロパティがpublicになっている為、外部からアクセス可能になっています。

その為、上記のコードのように後から変更することが可能になってしまいます。

これを防ぐにはプロパティにはコンストラクタで値を入れ、後から変更ができないようにすることです。

例えば、

class Body
{
    private string $color;

    public function __construct(string $color)
    {
        $this->color = $color;
    }
}

このようにプロパティをprivateにし、外部からアクセスできないようにした上でコンストラクタで値を入れる。

一旦値を入れたらそのインスタンスは後から変更することができません。

こうすることで不変性を担保することができ、思わぬバグが生まれにくくなります。

同様にCarクラスも$bodyプロパティをprivateにすることで後から変更できないようにします。

class Car
{
    private Body $body;

    public function __construct(Body $body)
    {
        $this->body = $body;
    }
}

また、Carインスタンスの生成にFactoryパターンを使うとよりベターです。

class CarFactory
{
    public function createNewCar(string $color = 'red'): Car
    {
        return new Car(new Body($color));
    }
}

こうすることでBodyインスタンスの使い回しも防ぐことができ、より堅牢なコードにすることができます。

まとめ

以上簡単ではありますが、Immutableについて書いてみました。

プログラミングの世界ではImmutableがデファクトスタンダードになってきているように感じます。

JavaScriptでも変数宣言の際、以前はvarしかありませんでしたが、ES6以降はconstletを使うことがもはや常識となっています。

他にもRustではImmutableがデフォルトになっているようです(触ったことは無いですが)。

バグを生まないためにも、Immutableなクラスを作ることを意識して実装することが重要だと思います。

Mutableな構造、つまり再代入や変更が可能な構造になっている場合にはImmutableな構造にできないか再検討した方が良いように思います。

キーボード買いました

タイトルにある通り、GWにキーボードを買いまして先週の金曜日に届きました。

こちらです。

購入したのはKeychronのK8

JIS配列、赤軸、ホットスワップなしのタイプです。

良いですね。

めちゃくちゃ光ります。

というわけで今回はキーボードについて書きたいと思います。

キーボードの種類

まずキーボードにはいくつか種類があります。

メンブレンキーボードは最も一般的なキーボードで価格も安価です。

キースイッチを押すことで内部のシート状の膜を通じて通電し、入力される仕組みです。すべてのキースイッチに対して1枚の膜でカバーしている構造です。

PCに付属しているキーボードや市販でも安価なものはメンブレンがほとんどだと思います。

続いてメカニカルキーボードはメンブレンとは異なり、各キーが独立した構造になっています。

またメカニカルの特徴としてキーの軸によって打鍵感が大きく異なる点が挙げられます。

カチャカチャとクリッキーな青軸、静音タイプの赤軸、中間の茶軸が一般的です。

また一部のキーボードはキースイッチがはんだ付けされておらず、これをホットスワップと言います。

ホットスワップ対応のキーボードは軸の交換も可能なため、好みの打鍵感に調整することができます。

最後の静電容量無接点方式は名前の通り電極が接触しない構造になっているキーボードです。

接触しないため耐久性が高く、またその打鍵感の虜になる人も少なくありません。

REAL FORCEやHHKBのレビュー動画はYouTubeに数多くアップされています。

非常に人気が高い一方で価格も非常に高価です。物によっては3万円以上するものもあります。

Keychron K8について

今回購入したKeychron K8はメカニカルキーボードです。

ヨドバシカメラにREAL FORCEの実機があったので試してみたのですが、個人的にはそこまで打鍵感が良い印象は受けませんでした。

カニカルキーボードの赤軸の方が個人的には好きな感触でした。

あとREAL FORCEはデザインがダサい。

何より高価なので手を出しづらく他のものを探していました。

ただMac用のキー配列になっているメカニカルキーボードって意外と少ないのか、なかなか良いものが見つからなかったのですが、たまたまネットで見つけました。デザインもグッド。

お財布事情からカートに入れたまま5月になるまで待っていたら10%OFFのクーポンも届いたのでちょっとだけ安く買えました。

1週間ほど使ってみた感想ですが、

めちゃくちゃ良いです。

Macをお使いの方だとわかると思いますが、付属のキーボードってとても薄くてなんとも言えない感触があります。

K8はずっと打っていたくなるような心地良さでもう戻れないというのが本音です。

たまにトラックパッドを操作した流れでそのままMacのキーボードで打っちゃうことがあるんですが、違和感しか無いです。つい1週間前まで普通に使っていたのに。

赤軸でも思ったより音がするなという印象ではありますが全然許容できる範囲だと思います。

欠点としてはワイヤレス接続の際のバッテリーの持ちがちょっと悪めな点でしょうか。

とはいえ自宅では有線接続しているのでその点は全く問題にならないです。

まとめ

という訳でKeychron K8を買ったという話でした。

デスク周りはもっと良くしていきたい思いがあるのでおすすめのガジェット等あればぜひ教えてください。

とりあえずモニターがもう1台欲しいなと思っています。