Posts for: #Svelte

起業相談が再び

1時に寝て8時に起きた。寝坊して朝起きれないものの、わりかしよく眠れるようになってきた。

sveltekit の ui からのリクエスト

+page.svelte のスクリプトで onMount() を定義すると bff へ http リクエストを fetch できる。

<script lang="ts">
	import type { User } from '$lib/types/users';
	import { onMount } from 'svelte';

	let data: User[] = [];

	onMount(async () => {
		const r = await fetch('/api/users');
		if (r.ok) {
			data = await r.json();
		}
	});
</script>

bff 側では web api を提供する必要がある。それは +server.ts を定義することで実装できる。内部的にはバックエンドの web api を呼び出して、それを返すだけの実装になる。こういった連携も sveltekit だと簡単に実装できる。前のお仕事は bff も java で作っていたけど、bff なら node.js でいいんじゃないかと思うぐらいにはフロントエンドの技術に慣れてきた自分がいる。

起業相談

少し前にも起業相談 に乗ったが、まったく別の人で12月に起業された方が三ノ宮.dev のコミュニティに入られて起業相談にのってほしいというので行ってきた。個人でもわりと有名な方らしく、ある2つのキーワードでググるとトップに出てくる。スタートアップを目指している方で、できるだけ多くのお金を資金調達して作りたいものを開発したいという話し。いまは金融緩和から緊縮に向かう状況なのでベンチャー資金も渋い状況ではないかと推測する。そんな中で cto をどうやって探せばよいかという質問が大きな話題だった。資金調達する上でもちゃんとした cto がいる方が融資する側からみても印象が違うという。それはそうかなとも思う。

一方で cto を探すのは相当に難しいという話しを私からした。基本的には過去に一緒に働いた人でスキルのある人や同じ意思をもっている知人や友だちに依頼するのがよいだろうと。それも難しい話しだけど、cto 募集なんかでよい人がみつかる確率は低いし、ましては ceo が技術に明るくないのであれば応募してくる求職者のスキルや知識を評価するのも難しい。他のコミュニティメンバーも同意見で、最初は cto を雇わず、普通にテックリードになれる開発者を雇って、プロダクトを開発して実績を作って資金調達した後に再度 cto を探してはどうか?と提案した。

あと資金調達は実績がないと難しいから、最初はすぐにお金を稼げるプロダクト開発をして、それで十分な収益をあげ、その実績から資金調達するのはどうかといった計画の話しをしていて、それはもっと難しそうだと私からは感じた。お金のためだけにやりたくもないプロダクト開発を1-2年やって、その後に本当にやりたいプロダクト開発を資金調達してからやる。それぞれのプロダクトはまったく関係がなく、組織も2つになるという。そんなやり方で成功したスタートアップを私は聞いたことがない。組織の難しさをあまりにも軽視していて無謀だとアドバイスした。

私も起業して早3年が経った。マイクロ法人だから簡単でしょと言われたらそれまでなんだけど、起業相談を依頼されるケースも増えてきた。これはこれで顧問やコンサル業ができるのではないかと少し皮算用していたりする。

今日は打ち合わせの多い日だった

1時に寝て2時、3時、6時と起きて7時に起きた。久しぶりに胃酸が逆流して気分悪かった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。sveltekit アプリで使う ui フレームワークの相談をして、昨日の課題管理の雑談内容 からさらに考察を深めた。私の中では知っていたことだったはずなのに、いつの間にか、そのことを軽視してしまっていることを再認識したような発見だった。

コミュ障の私にとってはペアワークという概念がすっぽり抜けていたことは昨日書いた通りだが、それでもいまマネージャーとしてそれなりにコードレビューやインフラタスクに時間を割いている。プロジェクトマネジメントだけをやっているわけではない。それは自分が遊撃として開発者のメンバーを手伝っていることに相当するなと気付いて、そう言えば、過去に五月雨式にだらだらと遅れるようなプロジェクトでは、他のメンバーのタスクが遅れることを横からみているだけしかやってなかったような気がした。もし私が自分のタスクを投げ出して遅れている課題に介入したらどうなっただろうか?と思考実験するだけの余地はあった。

もう1つ。盛り上がった話しにおっさんはエモい話しをしにくいと私が考えていると伝えた。なぜなら、私の経験則ではエモい話しをするおっさんは総じてスキルをもっていなかった。具体的な知識やプラクティスを話すときはエモい話にならないからだ。その発言に対して、はらさんからはこんなコメントが返ってきた。おっさんもスキルはあるのだけど、そのスキルが時代にあわなくなって古くなってしまった。現場の技術とあわないスキルは、現場の人間からみるとスキルがない人と同じである。少し前に40歳の壁という本を読んだが、そのノリで言うと、40歳になるとスキルが現場に通じなくなる。

sveltekit アプリのデプロイ

昨日の続き。Building your app によると、sveltekit のビルドは vite と adapter の2段階で行われる。gitlab ci/cd で node.js 向けにビルドして、それを docker イメージに同梱して、コンテナレジストリに登録する。あとはテスト環境で構築している docker compose に組み込むだけ。今日中にできたらいいなと思って、ぎりぎりだったけど、テスト環境で node.js 上にデプロイしたアプリと疎通できるところまでできた。ssr を介して web api サーバーと疎通できるところまで整備した。ここから先はメンバーに管理画面を作っていってもらう。メンバーの開発着手前にデプロイが一通りできているという気持ちよさ。

起業相談

過去に働いていた会社の、私と同い年の元同僚が起業するというので相談にのることに。私が会社を作ってなんとかやっているのをみて関心が出てきたという。いきなり会社を辞めると不安だから副業から始めて、本業の収入を上回るようになったから個人事業主から法人化しようと考えているらしい。実際に会社を辞めるかどうかはまだこれから検討するのかな?本業をやりながら最大4つか5つの副業をまわしてたというから驚き。そんなこと物理的に可能なの?と思ったら開発は人を雇ってマネジメントだけやったりしていたらしい。おそらく4人ぐらい開発者を雇っているという雰囲気だったけど、それでも本業をやりながら4つもマネジメントをするのは相当に大変だと思う。十分にその同僚の能力を認めているつもりだったけれど、それ以上の忍耐や集中力をもっていて、もしかしたら過小評価していたのかもしれない。1つの会社内でも3つ以上プロジェクトを兼任して成果を出しているマネージャーなんか私は見たことない。それを本業と副業と寄せ集めの開発者で実現しているのは類稀な能力だと思う。本人も睡眠時間削って働いてやり過ぎたとは言っていたが。法人登記、税金、節税、働き方とか、ざっくばらんに私が起業してやってきた3年間のお話しをした。なにかしら役に立って活躍されるといいな。

sveltekit の ssr を理解した

2時に寝て7時に起きた。キングダムの新刊を読みながら寝てた。

sveltekit の初期プロジェクト

技術選定で svelte を採用した ので昨日から SvelteKit でアプリケーション開発に着手した。Project structure にもだいぶ慣れてきた。開発初期はディレクトリ構成に迷うのでドキュメントに標準的な階層構造を書いてくれているのは素晴らしい。Routing もキモいけど、ssr の場合は +page.svelte+page.server.ts を設けるのに慣れてきた。ssr で proxy 的に web api 呼び出しも簡単に実装した。知らないフレームワークで開発するのは学ぶところが多くて楽しい。区切りのよいところで初期開発の issue はクローズして明日は gitlab ci/cd でテスト環境にデプロイするのをやってみる。

課題管理の雑談

過去に働いていた会社の同僚と課題管理について雑談した。web3 系の会社で働いているのでブロックチェーンや dao 周りの話しも一緒にしたりしていた。一回りぐらい私より若いと思うけれど、私よりはるかに優秀な開発者だなぁと感じながら話しを聞いていた。いま一緒に働いても足手まといになるんじゃないかと思えて身が引き締まる。いくつか話題の中で学んだことを抜き出してみる。

  • 自分の知識やスキルを共有する手段の1つとしてペアワークをやる
    • ペアワークを通してメンバーとの信頼関係も構築していく
    • いまもっている知識やスキルには個人差はあるが、模倣の能力が低い人をみたことがない
  • 上位の意思決定者から低いレベルにあわせる (標準化など) ように指示がきたときは反発する
    • ユーザーファーストが第一ならレベルを下げるような指示はおかしい
    • 「誰を向いて仕事しているの?」と説得する
  • プロジェクトにおいて目的を明確化せずに始めてしまうのは本当によくない
    • 日本人は上意下達で行動するように教育されてきた弊害ではないか
    • 目的を明確化するのは意見を言うことと同じである
      • レイヤーが上がるほどエモい話しになって人生観や哲学の話しになっていく
      • チームのモチベーションを維持する上でも有効ではないか

私はコミュ障だから他人と一緒に作業しようという発想がそもそもなかった。こちらから一緒にやろうと声をかけて知識やスキルを共有する手段もあるのかと気付いた。これまでも何人もの人にいろんな話しを伺っている。他人のノウハウを聞くだけでもこの雑談をすることに意味はあると思えた。

svelte とはリアクティブな ui のための言語

2時半に寝て7時に起きた。なんか意味なく夜更かししたもののよく眠れた。

svelte 調査

年末から svelte のチュートリアル を始めたものの、葬儀と年末年始休暇で間があいてしまった。年始やもくもく会でも少しずつやっていたものの、今日で終わらせようと最後の方は少し端折りつつチュートリアルを終わらせた。svelete と sveltekit の2つのチュートリアルをやっていて時間がかかった。svelte のシングルファイルコンポーネント (SFC) は vue.js とよく似ている。スクリプトやテンプレートの構文が違う程度の印象。vue.js よりもスクリプトやテンプレートの記述がシンプルな分、やはり簡単に思える。svelte の作者である rich harris 氏が書いたメモに次がある。

大雑把にまとめると次のようなことが書いてある。

svelte を ui フレームワークとして開発してきて、svelte 3 で svelte は言語だと気づいた。リアクティブな ui を記述するための言語であると。これまでそういった取り組みをしてきたプロジェクトはいくつかあるが、どれもコンパイラ以上の専用ツールが必要になってしまい、すべてを制御する必要があって、ライブラリの段階的な採用などもできないために大掛かりには導入されなかった。

html, css, js という多くの開発者が蓄積された経験をもっていて、小規模に段階的に導入するには、それらの言語をハックして拡張するのがパフォーマンスもよく、もっとも優れた解決策であると考えるに至った。

実際に svelte のチュートリアルをやってみると、その簡潔さから rich harris 氏の言葉も理解できる。開発者によっては svelte コンパイラが拡張している javascript の構文や機能を受け入れられない人もいるだろう。純粋な javascript を書きたい人には向かないライブラリかもしれない。そこがリアクティブな ui をコンパイラレベルで実現するためのトレードオフと言える。だから svelte は javascript のハックも含めての言語なのだという解釈になる。

svelte のチュートリアルで学ぶ

22時頃から寝てたものの、また2時頃に吐き気で苦しんで何度か起きて7時過ぎに起きた。なかなか体調が悪い。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今週はてんやわんやで議題を整理する余裕すらなかったので近況を軽く共有した。

課題管理を it 業界や開発プロジェクトだけでなく、もっと様々な分野や業界で応用できるようにしたい。最初は私がノウハウをもっている業界や業務のみに特化したものになるだろうけど、いずれはスコープを拡げていきたい。その先に 地域おこし協力隊 のようなところにいって社会貢献ができればおもしろいのではないかといった話しをした。地域おこし協力隊の内容はおもしろそうだけど、1人あたりの経費の上限が480万円に設定されていて、ググって調べると余裕のない自治体では満額支給されていないケースもあるみたい。行政がやらないといけない業務をアウトソーシングする予算が低過ぎて、適切な実績やスキルをもった人が経済的に参加しにくい状況にある。採用の目利きができないから単価を低くして失敗を許容しやすくなっているようにもみえる。行政の予算が低い問題は専門家が入って採用も含めて改善していく必要がある。

svelte 入門

昨日の続きで svelte のチュートリアル を始めた。このチュートリアルはファイル操作とオンラインエディタもついていて、ソースコードを変更するとすぐビルドされて結果も確認できる。フロントエンドのチュートリアル自体がフロントエンド技術のデモになっている。よく作られているよなと感心しながら取り組んでいる。svelte でスクリプトを書くときの、マジックコード的な変な構文がある。simple is not easy の文脈で言うところの easy であり、私のような simple 派からみるとやや気持ち悪い。わりと分量があるので途中にコードレビューや勉強会の講師をやっていたら1日では終わらなかった。

let count = 0;
$: doubled = count * 2;
<script>
  export let answer;
</script>

フロントエンドの技術選定

24時に BOOK AND BED TOKYO にチェックインして雑多なことして25時過ぎには寝て8時過ぎに起きてチェックアウトした。それから新幹線に乗って神戸まで戻ってきた。東京・品川から新神戸間は、往路は EX早特21ワイド だと12,630円で、復路は自由席で14,420円だった。私の中で時間の制約はストレスやエネルギーを使う。帰りは時間に縛られたくないという思いで新幹線の駅に着いてから自由席を買うようにしている。一方で2千円近い差額も大きいので次回以降は帰りの新幹線もEX早特21ワイドで取ることにした。

フロントエンドの調査

昼過ぎに家に戻ってきて洗濯や片付けしたら疲れてまた寝てた。晩ご飯食べて21時ぐらいからオフィスで作業してた。猫みたいな生活。オフィスからお手伝い先のネットワーク接続の設定をやったりしながらフロントエンドのコードを読んでみた。これは作り直した方がよいだろうと私の中で決意して、どういった技術で作り直すかの技術選定のための調査を開始した。既存のフロントエンド開発の背景や経緯を知らないのでまだ確定ではない。提案の準備のために調査をしておく。

ここ最近 svelte の人気があるのをみかける。1年ほど前に三ノ宮.devで教えてもらってチュートリアルをやってみて、そのときは特にどうとも思わなくて、こんなやり方もあるんやな程度にみていた。その後 vue.js (nuxtjs) での開発を半年間ほど経験して、思いの外、私にとって vue.js がよいものにはみえなかった。react よりも簡単と聞いていたけど、私にとってはあまりそうは思えなかった。vue.js は vue.js なりの難しさ (学習コスト) があるように感じられた。管理画面のような小規模な用途に react や vue.js のようなリッチなライブラリ・フレームワークを使わなくてよい方法があるかを考えたときに svelte を思い出した。svelte の実際のアプリケーションのサンプルコードとして次のコードを読んでいた。

vue.js の single-file components は svelte の前身である ractive.js のコンポーネント の概念に影響を受けているという。従って、svelte のコンポーネント開発は vue.js と考え方が近いものの、dom 操作は svelte のコンパイル時にコード生成するので仮想 dom は使わない。これがパフォーマンス上の大きなメリットと言われている。react や vue.js よりもずっと軽量なコンパイラ・フレームワークと言える。次のページに複数のフロントエンドの技術の流行をまとめている。svelte はこの2年ぐらいで人気が急上昇していることがわかる。

また react と vue.js の現状もちゃんと把握しようと調べていて次の記事がおもしろかった。

vue.js は vue3 で react になろうとしていて、その過程の過渡期には様々な問題を抱えているように私からはみえた。

  • vue2 と vue3 は互換性がない
  • vue3 移行へのエコシステムの本気度がみえない
  • vue2 の開発者が本当に vue3 を求めているのか懐疑的
  • シェアだけみたら vue.js よりも react の方が高い