Mobile Factory Tech Blog

技術好きな方へ!モバイルファクトリーのエンジニアたちが楽しい技術話をお届けします!

モバファクのフロントエンドランチ会の紹介

こんにちは。ブロックチェーンチームのソフトウェアエンジニアの id:odan3240 です。

この記事では昨年の9月から社内で取り組みを続けているフロントエンドランチ会について紹介します。

フロントエンドランチ会とは

第2木曜と第4木曜のランチの時間 (13:00-14:00) にフロントエンド技術に興味がある有志のメンバーがオンラインで集まってランチする会です。

この会の目的は以下の通りです。

  • フロントエンドに関する技術の情報交換
  • フロントエンドに興味がある人の親睦を深める

この会で実際に行っていることは以下の通りです。

  1. 13時頃にみんなぼちぼち集まってくる
  2. その日のファシリテーターを2人決める
    • ファシリテーターは約30分で交代する
  3. ファシリテーターの画面を共有しながら JSer.info の最近の記事を開く
  4. ファシリテーターが記事の内容を読み上げつつみんなで深堀りしていく
    • わからない単語/概念はないか?
    • 実際に仕事に活かせそうか?

企画しようと考えたきっかけ

物理出社時代のランチでの雑談の再現

東五反田オフィスには「リフレッシュルーム」と呼ばれるランチを食べるための部屋がありました。そこで相席になったエンジニア同期とゆるいテックトークをするのが当時の楽しみでした。しかし昨年の2月からのリモートワーク化に伴いこの時間が失われてしまいました。

なんとかゆるいテックトークを会社の人とオンラインでやりたいという気持ちを抱えて半年が過ぎていました。

他社のフロントエンドランチにあこがれて

ゆるいテックトークで思い出したのはサイボウズさんのフロントエンドランチ1でした。自分がこの催し物を知ったのはコロナ禍以前で、参加者の方が Twitter でその様子を実況しているのを見て、「羨ましい」「いつか参加してみたい」などと考えていました。この理由としてはお互いの知見を広げられることや単に自分がテックトークをするのが好きだからです。

このときはもし転職するならこういう文化がある会社が良いなぐらいの気持ちでした。しかし上記のランチでのテックトークをオンラインで復活させたいというモチベーションと掛け合わせたときに、文化がある会社に行くより今いる会社で文化を作るほうが面白いという考えに至りました。

この流れがあり、去年の9月にフロントエンドランチ会を企画することにしました。

実際の様子

2021-07-08 に開催されたフロントエンドランチ会の様子を紹介します。

この日は 2021-07-06のJS: TypeScript 4.4 Beta、immutable-js 4.0.0-rc.13、petite-vue - JSer.info をみんなで読みました。このときのサマリーを紹介します。

  • TypeScript 4.4 beta の useUnknownInCatchVariables は顧客が求めていたものと言う話になりました
  • imutable-js は OSS の運用周りでなにかあったらしい
    • 大変そう
    • 最近だと immer をよく聞くよね
  • 社内で Vue.js を採用しているプロダクトが多いため petite-vue に関心が集まった
    • HTML の構文に違反しないように v-effect が新しく導入されたのでは
    • コミットログを見返すと Evan You が約1週間で petite-vue をフルスクラッチから実装していてやばい
  • actions/setup-node にキャッシュ機能が入ったのは便利そう
    • ただ actions/setup-node の存在と UNIX 哲学ことを考えると諸説あるのでは
  • The State of WebAssembly 2021 について
    • The State of Hoge を見ると年末感出るけどまだ6月w
    • やっぱ Rust が多いよね
  • polyfill とは別に ponyfill という概念があるんだ

実際にフロントエンドランチ会を開催してみた感想

第一に企画当初の狙い通り、定期的にフロントエンド技術についてキャッチアップすると技術的な雑談をする時間を確保できたのが嬉しい点でした。

企画当初には考えてなかった嬉しい点もありました。それは会社に入ってきた新しいメンバーとの交流の場にもなった点です。会社のフルリモートワーク化に伴い別のチームのメンバーとの交流の機会が減る中で、チームを超えた交流が促進されました。

運営で心がけていること

ゆるく継続して開催することと、参加者の意見を取り入れて内容をブラッシュアップすることを心がけています。

ゆるく継続して開催するために、ファシリテーターを交代制にすることと、開催頻度を隔週にしました。ファシリテーターを交代制にすることで主催者である自分自身の負荷を軽減しています。開催頻度については、毎週開催にすると「木曜日はフロントエンドランチ会」という固定概念とともに参加に対する義務感が生まれてしまうのではという懸念から隔週にしています。

また参加者の意見を取り入れるために、開催初期は表明じゃんけんを使って最後に参加者に良かった点と改善点の声を募るようにしていました。この結果記事に対する深堀りの方針として「実際に仕事に活かせそうか?」という視点が追加されました。

終わりに

フロントエンドランチ会の概要、企画のきっかけ、実際の様子を紹介しました。フロントエンド技術のキャッチアップだけでなくチームを超えた人との交流も促進されるため個人的な満足度は高くおすすめの取り組みです。

EIP-2718: Typed Transaction Envelope が Ethereum の未来を感じる提案だったので紹介したい

こんにちは、ブロックチェーンチームでソフトウェアエンジニアをしている id:odan3240 です。 来月に予定されている Ethereum Berlin Upgrade の調査を行う中で発見した EIP-2718: Typed Transaction Envelope が、Ethereum の未来を感じさせる提案だったので紹介します。

EIP-2718 の提案内容

EIP-2718 は新しいトランザクションタイプを定義する提案(以下「この提案」と呼びます)です。

この提案での有効なトランザクション (Transaction) とトランザクションのレシート (Receipt) の定義は次の通りです。|| はバイト列の結合演算子です。

  • Transaction: TransactionType || TransactionPayloadLegacyTransaction のどちらか
  • Receipt: TransactionType || ReceiptPayloadLegacyReceipt のどちらか

LegacyTransaction/LegacyReceipt はどちらも従来の Ethereum のトランザクションとトランザクションのレシートの定義です。

TransactionType はトランザクションのタイプを識別するための 0 から 127 までの128通りの数字です。

TransactionPayload/ReceiptPayload はそのトランザクションタイプの payload です。

EIP-2718 のモチベーション

この提案以前ではトランザクションを拡張する場合は後方互換性を保つ必要がありました。例えば EIP-155: Simple replay attack protection では secp256k1 の署名の v の値に chainId を考慮した値を加算することで、要件を満たしつつ後方互換性を実現しました。この提案では TransactionType の値でトランザクションを判別するため、後方互換性を気にする必要がなくなります。

そのため以前では、トランザクションの data の構造を自由に設定できることを活かして EIP-712: Ethereum typed structured data hashing and signingEIP-1613: Gas stations network などが提案されてきました。今回の提案によりトランザクションの構造についても自由に設定することができるようになり、トランザクションレベルでのマルチシグトランザクションの実装などが可能になります。

EIP-2718 を応用する提案

この提案を使って新しいトランザクションタイプを定義している提案を紹介します。

EIP-1559: Fee market change for ETH 1.0 chain

ガスの支払いを変更する提案です。maxInclusionFeePerGasmaxFeePerGas などのパラメータがトランザクションに追加されています。

EIP-2711: Sponsored, expiring and batch transactions.

以下の3つのトランザクションタイプを提案しています。

  • Sponsored Transactions: トランザクションの送信者とガスを支払う人を分離可能
  • Batch Transactions: 複数のトランザクションをまとめて実行可能
  • Expiring Transactions: トランザクションに有効期限を設定可能

EIP-2733: Transaction Package

トランザクションの success や gas_used などの実行情報を次のトランザクションに渡せるようにする提案です。

EIP-2930: Optional access lists

トランザクションがアクセスする予定のあるアドレスとストレージを事前に渡せるようにする提案です。事前申告されたアドレス以外にアクセスするとコストが増加します。

EIP-2938: Account Abstraction

コントラクトが EOA と同様に料金の支払いやトランザクションの実行ができるようにする提案です。

EIP-2972: Wrapped Legacy Transactions

従来のトランザクションタイプをこの提案の形式で定義し直す提案です。chainId が明示的にトランザクションのパラメータに含まれています。

EIP-2976: Typed Transactions over Gossip

devp2p が新しいトランザクションタイプを受け入れるようにする提案です。

終わりに

EIP-2718 はこれまで固定だったトランザクションの構造を可変にする提案で、その紹介をしました。トランザクションの構造が柔軟になることによってこれまでなかった提案がされ Ethereum の自由度は更に高まっています。特に EIP-1559 からは目が離せないですね。