2023-11-01

spacemacsにコントリビュートをした話

実際のプルリクエスト

背景

2022年の年末頃から、日本語文章の執筆用途としてEmacsを使い始めた。

1から設定を積み上げていくのはそれなりに大変であることが予想されたので、Spacemacsを導入した上で、個別の設定を追加している。

Spacemacsでコード補完の候補を表示するレイヤー（パッケージやデフォルト設定集）はauto-completion layerを使用していて、表示フロントエンドにはcompany-boxを使用している。実際の設定は下記の通り。

     (auto-completion :variables
                      auto-completion-enable-sort-by-usage t
                      auto-completion-use-company-box t
                      auto-completion-enable-help-tooltip 'manual
                      auto-completion-complete-with-key-sequence-delay 0.0
                      auto-completion-enable-snippets-in-popup t
                      auto-completion-minimum-prefix-length 1)

この設定で補完候補を表示した場合に、アイコンと文字列が中央揃えにならない、意図しない画像が表示される、という事象が発生していることに気づいた。

この不具合の原因を簡易版、やや厳密な説明版の2つで説明してみようと思う。

不具合の原因（簡易版）

company-boxで defvar を使って定義されている変数 company-box-icons-all-the-icons をuse-packageの :custom で設定をしようとしていため。

:custom に記述した内容は、パッケージが読み込まれる前に実行されるのだが、company-box-icons-all-the-icons はパッケージ読み込み前には当然未定義であるため、設定が正しく行えない

なおuse-packageは下記の記事でも解説を試みた。

qiita.com

不具合の原因（やや厳密な説明版）

少々込み入っているので、箇条書きで説明をすると、

use-packageには:custom で設定した値が custom file に保存されることを防ぐことができるオプション（ use-package-use-theme ）がある
上記のオプションが有効になっている場合 :custom の変数定義は custom-theme-set-variables で行われる
この custom-theme-set-variables は「変数が定義済みの場合には上書き、未定義の場合には指定したテーマのシンボルに対するプロパティの追加のみを行う
- https://github.com/emacs-mirror/emacs/blob/4e4a808eca8f68a8079272442aab0f8815abdaa8/lisp/custom.el#L1073-L1075
他方、上記でプロパティに設定を追加したテーマ（シンボル名: 'use-package）は常に無効な状態になっている
- ちなみに、これはユーザーが意図せず無効化することを防ぐためのものである
- https://github.com/jwiegley/use-package/blob/a6e856418d2ebd053b34e0ab2fda328abeba731c/use-package-core.el#L42-L44

という、事象の掛け合わせで :custom の設定が反映されない状態になっていた。

厳密な説明を試みたものの正しく説明できている自信はないので「defvar で定義された変数を use-packageの :custom セクションで定義をすると設定が反映されないことがある」くらいに捉えてもらうのがいいと思う。

不具合の解消

パッケージが読み込まれる後に実行される :config セクションに移動し、 setq で上書きするように変更したことで修正が完了した。

spacemacsのこのレイヤーでは、自動テストなどは用意されていなかったため、コード差分と動作確認用のスクリーンショットをつけてプルリクエストを送った。

まとめ

変数がdefvarで定義されていることに気づくのもそれなりに時間がかかったが、それ以上になぜdefvarをuse-packageの:custom で上書きできないのか、という調査に時間を取られた。

ただ、時間をかけて原因追及をしたことで、Spacemacsのレイヤーの仕組み、use-package、変数定義（setq, defvar, defcustom）、マクロ展開、テーマなどの多くの知識を手に入れられた。また、本記事では触れなかったがedebugを使ったデバッグなど、Elispの不具合発見方法に馴染むことができた。

今後もEmacsの設定や各種パッケージへのコントリビュートをしていこうと思う。

2022-08-09

TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発[3.6 ~ 7章]

TypeScript プログラミング

昨日の続き。 TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発[1 ~ 3.5章] - Kuranari::Log

TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発

作者:手島拓也,吉田健人,高林佳稀
技術評論社

Amazon

3章

3.6章のNext.js入門は飛ばして4章から読もうと思ったけれど、4章は3.6章のプロジェクトがあることが前提だったため、Next.jsの準備として3章に戻る。以前 Next.js のチュートリアルをやった際にSSR/SSG/CSRは試したことがあったのだけど、ISRは初めてだった。ユーザー投稿型サービスかつ高速なレンダリングが求められるようなサービスだとISRも便利なのかもしれない。知識として頭の片隅に残しておく。

4章

今日の学習ポイント。styled-component や Storybookへのコンポーネント登録はあまり経験がなかった部分だったので重点的にキャッチアップ。一方で jest や React Testing Library は多少馴染みがあったのでサラッと流す。

ここまで手を動かしながら読み進めておかげで、Hooksも手に馴染んできた。

5 ~ 7章

5章は写経しながら進めていたもののESLint関係のライブラリを npm install で列挙するあたりで挫折。サンプルリポジトリの package.json をコピペして進めようかとも思ったが、その後の記述量もかなり多そうだったので、リポジトリをcloseしてアプリケーション挙動やサンプルコードを眺める方針とした。

読み進める中で json-server や SWR のような便利そうなライブラリを知れたのはよかった。

6章はStorybook を起動してコンポーネントを眺めた程度で終了。実際にコンポーネント作成する時に戻ってくる。 MUIやReactstrapのようなUIライブラリを使わずに独自のデザインシステムを構築する場合は、結構気合入れて取り組まないと大変そうだなという感想。

7章も軽く読んで、実運用する段になったら再読することにした。個人開発ならVercelを使うこともあるかもしれないけれど、業務だと別のインフラ環境にデプロイすることになりそう。

感想

5~7章のアプリケーション開発の

現時点での最新版のReact/Next.jsを使って
現場で発生する要件をカバー（認証あり、複数のエンドポイント利用(POST含む)、ファイルアップロード、etc...）した中規模なアプリケーションを
自作のデザインシステムで実装している

という組み合わせが、この本のよさを際立てていると感じた。

このバランスを取るために著者の方は構成に苦労しただろうなと思った。 (シンプルにするならGETだけのアプリケーションを取り上げるのだろうけど、それだと認証もFormバリデーションも不要になってしまうし、MUIなどのライブラリを使ったら見通しは良くなるけれど見栄えはサンプルアプリケーションの域を出ないし、、、)

サーバーサイドの複雑さは json-server などで隠蔽しつつ、フロントエンドのロジック・UIに注力した構成は、何かの折で参考にさせてもらいたい。

6章を丸々使ってUIコンポーネントの解説をしているなど、アプリケーションロジックに加えてUIコンポーネントの開発・管理手法に比重を置いているのが印象的だった。逆に、APIクライアントのような説明は必要最小限に留められていて、飛ばし読みをすると実アプリケーションへの組み込みの全体像が掴みづらいかも知れない。 5章でSWRの紹介があり、6章で fetcher 関数やAPIクライアントを作るのだけれど、それを使うのは Atom / Molecules のコンポーネントを作った後になっていためだ。

個人的にクライアントアプリケーションの学習をする際には、APIクライアントの設計が特に気になることもあり、APIクライアントを作った直後に SWR や Context とのつなぎ込みについて補足を入れてもらえると嬉しかったなと思った。(とはいえ、リポジトリのコードを追ったら短時間で理解できたので大きな問題ではない)

Typescript, Hooks, テストのようなアプリケーションロジックによった部分は読み飛ばしつつ、Storybook / Atomic Design に時間をかけて理解を深められたのが、今の自分に足りていない知識を補うためにちょうどよく、「アプリケーションロジックの実装はできるけれど、UIコンポーネントやデザイン実装は苦手」という人にもおすすめできる。

2022-08-08

TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発[1 ~ 3.5章]

TypeScript プログラミング

『TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発』を読んでいる。

TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発

作者:手島拓也,吉田健人,高林佳稀
技術評論社

Amazon

私がフロントエンド開発に注力していたのは2016年 ~ 2018年3月頃。当時はReact Nativeを使ったアプリ開発や、jQueryベースで作られたサービスを部分的にVue.jsで置き換えるような仕事をしていた。当時からTypescript / Reactは存在していたものの、JS型付けの選択肢としてはFlowが有力な選択肢として残っていたし、ビルドツールもWebpackが優勢だったもののBrowserifyを採用しているプロダクトも多かった。SPAのフレームワークもReact, Vue.jsに加えて、Angular2, Riot.js, HyperApp(builderscon 2017 での発表が印象的だった) など大小様々な選択肢があった時代だった。

当時書いたフロントエンドのコードはほぼ残っていないのだけど、FluxアーキテクチャをRuby実装した形跡が残っていた。

GitHub - kuranari/flux-ruby: 【学習用】FluxアーキテクチャのRuby実装

その後の転職を機にフロントエンド開発からは遠ざかっていた。その間に Hooks や Context など新しいAPIが出ていたり、エコシステムもややデファクトが決まりつつある状態になってきて、周回遅れ感が否めないので今年の夏休みを使ってキャッチアップしている。

今日は1章から3.5章までを軽く手を動かしながら読んだ。明日は「4章: コンポーネント開発」から読み始め、3.6 Next.js入門に戻り、5章以降のアプリケーション開発に入っていこうと思う。直近で必要になるのはSPAのReactの知識だけなのでNext.jsは必須ではないのだけれど、パラパラめくった感じそこまで無駄になる知識もなさそうなので、一通り読んでみることにする。

以下、読んでみた感想。

1章: Next.jsとTypeScriptによるモダン開発

4 ~ 5年フロントエンド開発から離れていた身としては、ここ数年の技術の変遷を総括してもらえるこの章はありがたいとともに懐かしさを感じた。冒頭に書いたような技術選定の話もだし、懐かし話として楽しく読めた。

2章: TypeScriptの基礎

Typescript は軽く触ったことがあったので、軽く気になるところを動かす程度で。

3章: React/Next.jsの基礎

ゆるふわな理解だった Hooks の学習。useReducer は今回初めて使った。

useEffect の節では React v18 の <React.StrictMode> と useEffect の組み合わせの影響か、サンプルコードそのままだとLocalStorageに値を保存してもリロードのたびにLocaleが en-US になってしまう挙動に悩まされた。

いろいろ試してみたのだけど

localstorageへの保存は useEffect ではなく select 要素の onChange のイベントハンドラーで行う
Clock コンポーネントを <React.StrictMode> の外でレンダリングする

で解決できることがわかった。

React18におけるuseEffectの挙動の変化もコラムの情報から当たりがつけられた。出版日が2022/08/06なのに、React v18の情報を含んでいるのがすごい。

というわけで、今日は Typescript と React の API についてざっと調査ができたので、明日以降はコンポーネントカタログや実際のアプリケーション開発について読んでいこうと思う。

2018-09-15

RailsプロジェクトのCircleCI2.0設定ファイルを定義した

自分のサンドボックス用プロジェクトのCircleCIを2.0移行したのでそのメモ。

今回の内容は下記のthoughtbotの記事を参考にすれば動作するはずだし、必要なことは書かれている。 robots.thoughtbot.com

作業したプルリクは以下

Add config file for CirclrCI 2.0 by kuranari · Pull Request #17 · kuranari/mblog · GitHub

Docker image

imageはcircleci/ruby:2.5.0-node を使用した。

circleci/ruby:2.5.0ではないのは、nodeの実行環境が必要なRubyのGem uglifierに依存しているため。

他コンテナの起動を待つ

テスト用のコンテナよりもDBコンテナの起動に時間がかかり、DBへの接続が出来ずエラーになってしまうことがある。(このようなエラーとなる。)

そのためdbの起動をdockerizeコマンドで待つようにした。

Add config file for CirclrCI 2.0 by kuranari · Pull Request #17 · kuranari/mblog · GitHub

thoughtbotのブログの設定ファイルにもその旨書かれているが自分の携わる他プロジェクトでは記述がなかったため当初dockerizeをしていなかった。そのプロジェクトではテスト用コンテナでミドルウエアやnpmのインストールのような多少時間がかかる処理が発生するため、MySQLコンテナの起動待ちとなる状況は発生しないようである。

workflow化

現状のCIで行うことはテスト実行のため実質不要だが、興味があったのでworkflow化をしておいた。 workflowを使うと、複数のタスクを並列に実行させたり、直列に定義された各Jobの実行有無を条件によって切り分けられる。

並列実行の例でいうとRuby2.3, 2.4, 2.5の3バージョンを対象に並列でテストができるようになる。直列実行の例だとbuild, test, deployの3つのJobがある場合、featureブランチではbuild, testまでを行い、masterブランチでのみbuid, test, deployを行うことができる。

またworkflowを定義することでcronのようなスケジュール実行を行うことができる。

この辺は下記の記事が詳しい。 qiita.com

まとめ

RailsプロジェクトのCircleCI2.0設定ファイルの記述についてまとめた。今回はシンプルにrspecを実行するだけの設定にとどまっているが、今後デプロイ設定なども試していきたい。

2018-08-13

Maven + Lombokを使うまでのメモ

Mavenで管理しているプロジェクトでLombokを使うための設定方法のメモです。この記事では

の2つの手順を踏んでいます。なおIntelliJなどのIDEでLombokを使うためには別途設定が必要になります。

事前条件

javaとmavenがインストールされていること。

% java -version
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)

% mvn --version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T03:33:14+09:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_162, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre
Default locale: ja_JP, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.4", arch: "x86_64", family: "mac

Mavenプロジェクトの作成

% mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

...

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.743 s
[INFO] Finished at: 2018-08-13T15:53:17+09:00
[INFO] ------------------------------------------------------------------------

＊Mavenのインストール直後だと時間がかかる。

生成されたファイルは以下の通り。

% tree
.
└── my-app
    ├── pom.xml
    └── src
        ├── main
        │   └── java
        │       └── com
        │           └── mycompany
        │               └── app
        │                   └── App.java
        └── test
            └── java
                └── com
                    └── mycompany
                        └── app
                            └── AppTest.java

12 directories, 3 files

Mavenのテンプレートをビルドする

% cd my-app
% mvn package
[INFO] Scanning for projects...
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.509 s
[INFO] Finished at: 2018-08-13T15:59:04+09:00
[INFO] ------------------------------------------------------------------------

コンパイルした実行ファイルの起動

% java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
Hello World!

ここまででMavenプロジェクトの作成は終了です。続いてlombokの設定を行っていきます。

POM.xmlの編集

% vi pom.xml

下記の依存関係を追加

<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.2</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

`App.java`でlambokのアノテーションを仕様

% cat src/main/java/com/mycompany/app/App.java
package com.mycompany.app;

import lombok.Data;
import lombok.val;

@Data
class User {
    private final int id;
    private final String name;
}

public class App
{
    public static void main( String[] args )
    {
        val user = new User(1, "Alice");
        System.out.println(user);
    }
}

再実行

mvn package
% java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
User(id=1, name=Alice)

2017-12-15

FluxのRuby実装をした

この記事は2016年11月21日に社内ブログに掲載したものの公開版となります。

ソースコードは以下のリポジトリにアップロードしています。

github.com

Flux概要

Facebookが提唱したUI構築用のアーキテクチャ
- 特定のライブラリや実装ではない
Reactとの併用が推奨されている
- React.jsはMVCモデルのV(View)の部分の役割に特化している
データが単方向に流れる

fluxのメリット

イベント発生に合わせてどんな処理をどこの部品として実装すべきかが明確 → コードの見通しが良くなる

非同期イベントに伴うデータの流れが明確になる → デバッグが容易になる

各部品は疎結合かつ入出力が明確 → 再利用性やテスト容易性を確保できる

Rubyで実装してみる

アーキテクチャであれば言語やフレームワークに依存しないはず
作るもの: CUIのカウンター
- 1ファイルにまとめると以下のようなコード
- これぐらいの規模だとわざわざfluxを採用する意味はないが、学習用として目をつぶる

count = 0
print 'input: '
while op = gets.chomp
  case op
  when '+'
    count += 1
  when '-'
    count -= 1
  end
  puts count
  print 'input: '
end

リポジトリ

https://github.com/kuranari/flux-ruby

EventEmitter

いわゆるオブザーバーパターン
イベントを登録しておくと、特定のイベントが発火したときにコールバックが実行される

class EventEmitter
  def initialize
    @handlers = Hash.new { |h, k| h[k] = [] }
  end

  def on(type, &handler)
    @handlers[type] << handler
  end

  def off(type)
    @handlers[type].clear
  end

  def emit(type, data = nil)
    @handlers[type].each do |handler|
      handler.call(data)
    end
  end
end

require './event_emitter'

event_emitter = EventEmitter.new

event_emitter.on('click') do
  puts 'hello world'
end

event_emitter.on('input') do |params|
  puts params
end

event_emitter.emit('click')
# => hello world

event_emitter.emit('input', 42)
# => 42

Dispatcher

Action → Dispatcher → Store ActionをStoreに配送する。

実装

EventEmitterそのものをDispatcherとして使用。実際に使う場合は実行順序の制御機構などもう少し複雑になる。

require './event_emitter'

class Dispatcher < EventEmitter
end

Store

Dispatcher → Store → View - MVCでいうModelに相当。 - Storeが管理するデータはStore自身のみが更新できる - Storeの状態に変更があった場合EventEmitter経由でStoreに通知

require './event_emitter'

class Store < EventEmitter
  attr_reader :count

  def initialize(dispatcher)
    super()
    @count = 0
    dispatcher.on('UPDATE_COUNTER') do |payload|
      on_update_counter(payload[:value])
    end
  end

  private

  def on_update_counter(count)
    @count += count
    emit('CHANGE')
  end
end

ActionCreator

View → Action → Dispatcher - MVCでいうControllerに相当

Dispatcherに対しActionを作成して配信する。

Actionは

UPDATE_COUNTERのようなアクションの識別子
{value: 1}など入力値（パラメータ）に相当するオブジェクト

のペアで構成される。

class ActionCreator
  def initialize(dispatcher)
    @dispatcher = dispatcher
  end

  def increment_counter
    @dispatcher.emit('UPDATE_COUNTER', value: 1)
  end

  def decrement_counter
    @dispatcher.emit('UPDATE_COUNTER', value: -1)
  end
end

View(Component)

Store → View → Action

ユーザーイベントの受付
- clickされたら◯◯するといった動作
- イベントハンドラで対応するActionを呼ぶ
Storeの変更を検知して再描画

簡易版ReactComponent

state=で状態が変わったら再度renderする。

雑に実装すると、ReactComponentがやってることは以下のようなことだと思う。

class ReactComponent
  def initialize
    @state = {}
  end

  # stateに変更があったら再描画
  def state=(state)
    @state = state
    render
  end

  def render
    raise NotImplementedError.new
  end
end

class Component < ReactComponent
  def initialize(store, action)
    @store = store
    @action = action

    @state = { count: @store.count }
    @store.on('CHANGE') do
      on_change
    end
  end

  def increment
    @action.increment_counter
  end

  def decrement
    @action.decrement_counter
  end

  private

  def on_change
    self.state = { count: @store.count }
  end

  def render
    puts "count: #{@state[:count]}"
  end
end

Main

require './event_emitter'
require './action_creator'
require './store'
require './component'

dispatcher = EventEmitter.new
store = Store.new(dispatcher)
action = ActionCreator.new(dispatcher)
component = Component.new(store, action)

print 'input: '
while command = gets.chomp
  case command
  when '+'
    component.increment
  when '-'
    component.decrement
  end
  print 'input: '
end

イベントの末端にスタックトレースを仕込んでみる

Component#on_change

まとめ

Store, Action, Viewを各々EventEmitter(Dispatcher)で監視することでユーザーの入力から画面表示までの1サイクルが回ることを確認した。
fluxを理解するには実装するのが一番早いと思う（普通にjsで実装すればいいと思うが…）

参考文献

公式ドキュメント http://facebook.github.io/flux/
10分で実装するFlux http://azu.github.io/slide/react-meetup/flux.html
WEB+DB PRESS Vol.87, Emerging Web Technology研究室【第13回】Flux ……フロントエンド開発の新しいアーキテクチャ http://gihyo.jp/magazine/wdpress/archive/2015/vol87