Tailwindcssの適用にてんやわんや

Electronのプロジェクト構成として、Next.jsをフロントエンドに選択。
CSSとしてはTailwindcssを適用しようとしていたのですが、見様見真似でやっているものの、動いているコードを見る限り正常にTailwidがあたっているように見えない。

ということで、もう一度インストールから見直してみることに。

$ npm install -D tailwindcss autoprefixer postcss

インストール自体は上記コマンドで問題なくインストールできているようです。
これに、初期化するコマンドが必要となるのですが

$ npx tailwindcss init -p
npm error could not determine executable to run
npm error A complete log of this run can be found in: /XXXXX

というようにエラーが出ていることがわかりました。

おかしい。。。Claudeに聞いてみてもセットアップの仕方は上記コマンドで問題ないはずなのですが、、、と調べてみるとどうやらtailwindcssのv4系ではセットアップ方法が変わったようで、上記のコマンドはv3系のもののよう。

そんなわけで、一旦インストールするtailwindcssをv3系にしてみます

$ npm install -D tailwindcss@3.4.17 autoprefixer postcss
$ npx tailwindcss init -p

上記でエラーが解消されました。

v4系のセットアップは、ViteかPostCSSなどによってやり方が変わっているよう。

もう、頭から引っかかりまくっているので大変です。。。
やっぱりフロントエンドは中途半端に手を出すときっついです。

魔女の宅急便 2

魔女の宅急便の2巻であるキキと新しい魔法を読んだ

新装版 魔女の宅急便 (2)キキと新しい魔法 (角川文庫)

キキがコリコの街に来て2年目を書かれた作品。
基本的にはいろいろな宅急便のしごとを通してキキの成長を描くという軸は変わらず、仕事に対する向き合い方だとかそういったことを考えるサマが書かれていた。
そして、成長していくことで過去に挑戦しなかったことへの再挑戦。

比較的読みやすい言葉で書かれているので、子どもが読むのにちょうどいい内容でもあるかもしれないな、と思う一方で、派手な展開に慣れてしまっていると読んでくれるかな?と思うような内容でもあった。

というか、修行の旅は1年で実家に帰るわけではなくそのまま継続されるんだ。
このままコリコに居続けることになるのか、なにかイベントが有って移住したり実家に変えたりするのか。
このシリーズは6巻まであるので、これからどんな物語が続くのか。
気になる一方ですごい気になるというわけでもなく、気が向いたときに手に取る感覚で読み進めていければと思う。

次の3巻では新たな魔女が登場予定。
どうなるでしょう

新装版 魔女の宅急便 (3)キキともうひとりの魔女 (角川文庫)

エール

今日は珍しく会社のメンバーと飲み会。

と言っても私は酒は全然ダメなのでジンジャエールですが。
近々退職をする後輩も混じりで気兼ねない時間を過ごしました。

もちろん相手にとっていい時間になったかはわかりませんが、今後も頑張って欲しいところです。

組織に所属していれば、何かしら不満はあるものだし綺麗事ばかりではないのは分かりつつも、その中で自分はどうあるべきかは歳を重ねても正解はわかりません。

組織を変えていくと言うのが格好いいところではあるけれど、その組織にこだわる理由もなければ、より自分にとっていい組織を目指して転職するのもごくごく合理的です。

全てが糧になると考えて前を向くしかないんですけどね。

何にせよ、いい繋がりを保てれば嬉しいとは思います。

なんかそんな事をふと思いながら帰路についてます

ストレスレベルが高いです

Garmin先生を付けていて面白いな、と思うのはBody Batteryの値です

ちなみに、これが今日のもの。
モヤモヤが溜まってしまっていたので夜にも軽く走りに行きました。

日中帯は在宅で仕事をしていたにも関わらず、常にストレスを感じていたとGarmin先生はおっしゃるわけです

このストレスレベル。
何を持って測定しているのだろう?と

機能と特性:ストレスレベル計測について
https://support.garmin.com/ja-JP/?faq=WT9BmhjacO4ZpxbCc0EKn9

上記公式ページを見ると、下記のようです

各心拍間の可変的な時間の長さは、体の自律神経系によって調節されます。拍間の変動が小さいほどストレスレベルが高いことを意味し、変動が大きいほどストレスが低いことを示します。

正直ここのところ、忙しいというわけではないですがストレスは結構高い状態が続いています。実はHRVステータスもバランスゾーンを超えてアンバランスになってしまっています

うーん、ストレスは感じてはいるものの、実際にこういう風に数値やグラフとして示されるとより意識してしまいますね。

瞑想でも取り入れたほうがいいかもしれないが、そもそものモヤモヤの原因をなんとかしないとどうしようもないですね。。。

坂道トレーニングに挑戦

近所に坂道があったなぁと思い、今日はそこで坂道ダッシュをしてみた。
昨日にもGarmin先生メニューの無酸素を実施したので連日の無酸素になりそうだけれど、今日の目的としてはどれくらいの距離なのか?というところ。

Garmin先生のメニューには当然坂道ダッシュというものはないので、マニュアルでのラップを記録する形になります。

やってみると、ちゃんとランと回復を分けて記録してくれていてわかりやすい。
Garmin先生の無酸素メニューでも40秒くらいのダッシュを求められていたので、比較的いい内容だったのではないだろうか。

40秒前後のダッシュで距離としては200mくらい。
高度としては38m付近から53m付近まで上昇したので勾配としては7.5%、4.3度というところ。
うーん、まぁまぁの坂というところですかね。

距離200mという部分はもう少し延ばせそうですが、勾配に関しては場所を変えるしかないですね。

連日の無酸素トレーニングになってしまったので5本で終えましたし、最後は持たなかった!
距離を伸ばしたり、もっと厳しい坂に挑戦したりとして足を鍛えていきたいところです。

Electron + Next.js + TypeScript

Electronを利用してのアプリケーション開発で、いくつかの選択肢が存在するけれど、どうせならNext.jsやTypeScriptを使ってみたいと思っていた。

いくつか探したところ、ちょうどいいサンプルがあったのでそれをベースにアプリを作ることにする

Electron with Typescript application example
https://github.com/vercel/next.js/tree/canary/examples/with-electron-typescript

利用の方法はReadmeにかかれているが、下記のような形(プロジェクト名をelectron-exampleにした場合
npx, yarn , pnpmそれぞれ書かれている

npx create-next-app --example with-electron-typescript electron-example
yarn create next-app --example with-electron-typescript electron-example
pnpm create next-app --example with-electron-typescript electron-example

これで作られるフォルダ構成としてはざっくりこんな感じ

npm run devを実行してみると

起動した。

ハマったこと

Electron超初心者のわたしがハマったこととしては、、build後のフォルダ構成が下記のように増えたことだった。

今振り返って考えてみると、これはTypeScriptをコンパイルしてできたファイルになるので、それらは管理対象外なんですよね。

チュートリアルやQiitaを見ながらいじっていたので、main/index.jsやそれをコピーしてmain/main.js等としたりしていたので全然動きませんでした。

それらを考えるとコンパイルによって自動生成されるコードはGithubの対象外にするべきなので、gitignoreは下記を追加しています

/.next/
/out/
main
dist
renderer/.next
renderer/out

修正してもビルドしたらもとに戻ったり、思ったものが表示されなかったりと、余計な時間を使ってしまいましたが、ようやくスタートできそう

ランナーズ 4月号

先日、48歳を超えて初サブスリーという見出しで気になっていたランナーズ4月号を購入しました

ランナーズ4月号

いろいろなケースが紹介されていて、皆さん工夫をしているのがわかります。
さすがサブスリー達成者で、しかも48歳超えでの初サブスリー。
工夫しないとなかなか達成できない領域ですよね
そもそも、サブスリー達成という時点でランナー全体の3~4%くらいなのでどれだけの偉業なのかがよくわかります。

紙面に登場している方々の年間走行距離の平均は3779kmということで、月間は300kmを超えるところが一つのボーダーになり、それは日で考えると毎日10km走ることになるんですよね。

昨年で考えると、月間走行距離は200kmを超えるくらいが多く、最大でも276kmでした。
今年に入り、練習量を見直しており今のところ1月、2月と300kmを超え、3月もペース的にはいいペースです

実際のところ、単純に距離を走るという観点で考えるとそうなんですが、日によってはスピード練習などを取り入れることになるので、その日は距離的にはそこまで上がることはないはず。
練習量=距離だけでは測れません。

練習メニューをどういったものを取り入れるのか?は環境的な要因もあって、そもそもできる・できないが出てくるのでこの部分は自分の環境に適したメニューを考えるしかないわけです。
私自身、近所に1kmを超えるような坂道は思い当たらないのですが、坂自体はあるのでそれを試しに取り入れてみるというのは良さそうです。

このあたり、Garmin先生がおすすめしてくれるメニューと、自分自身で考えるメニューをどういう風に組み込んでいくのかが悩みどころですね。。。

まずは、月間300km超えをキープ。
そして、テーマを意識した練習というものをしっかりと取り組んでいくとともに、短時間で効果が上がるような坂道ダッシュができるコースの開拓をしていきたいと考えています。

ランナーズ 2025年 04 月号 [雑誌]

ネットワーキングが苦手です

昨日投稿した、FigmaJapan社主催のイベントは、イベント終了後にネットワーキングとして懇親会が行われました。

私も参加させていただいたのですが。。。さすがにFigma社のイベント。
デザイナーと思しき人々ばかりでキャッキャウフフしている中に50近いおっさんが入っていくのは、いつセクハラのボーダーラインを踏み外すかを考えると危険極まりありません。

そもそも、残念ながらFigma自体、ろくに使っていない中での参加なので話題についていける自信のかけらもないです。
こんな中で、話をするとするとやはり立ち位置としては、自分自身がそういうことに疎いという前提にたった上で教えを請う形での会話という認識はあるものの、あまりにデザインシステムに対しての知見がなさすぎるんですよね。

また、今回まずかったのは、目的みたいなものがなかったんですよね。
知りたいこととしてはデザインシステムに対しての基礎知識だったり適用先に近い部分。
ネットワーキングのことをすっかり考えてなかったんですよね。

このあたりは完全に作戦負けというかノープラン過ぎました。

もともと子どもの体調も悪かったので早く帰宅したほうがいい状況でもあったので、そうそうに帰宅させていただきました。
機会としては少しもったいなかったのですが、色々相まってしょうがないかと。

ただ、このあたり。ネットワーキングとかコミュニケーションは相変わらず自分にとっての課題だなぁと思うわけです。
何でもいいからつながっちゃえばいいんでしょうけれどね。

コミュニケーション強者になりたいものです

デザインシステム構築の実践イベントに参加してきた

3月7日に表参道スパイラルホールで開催されたFigmaJapan社主催のイベント「スケーラブルなデザインシステム構築の実践」というイベントに縁があって参加してきました

https://designsystem102.splashthat.com/TW

デザインシステム。
フロントエンドの世界を主戦場としているわけではないのですが、言葉自体は把握していて、主には mozaic.fm というPodcastでよく話に上がっているので気になっていました。

デザインが特に意識されるのはToCの分野が多い認識でToBに関してはあまり必要性が認識されていない事が多い。
前職でもよくあったのが、画面にできるだけ情報を詰め込むような形。

結局これは、もともと使っていた画面や紙がそれだけの情報量を一目で見ることができ、それを用いた業務にユーザが最適化していることに起因していると思う。
画面を分割したりスクロールやタブが発生すると業務効率が落ちるというクレームが入る。

ただ、その流れは確実に変わってきていると思っていて、それは何よりもユーザがスマホやタブレット端末を日常使いするようになり、デザイン要素を取り込んだアプリケーションに慣れてきたという側面が強いのではないかと思っている。

そんなわけで、これからアプリケーション開発を行っていくうえでデザインシステムの構築みたいなものというのは、どういうシーンで必要で強みになり、どういうシーンでは逆に不要となるのだろうか?というのが自分の中での問いになった。

そんなモヤモヤしながらもしっかりと学習していない中でたまたまFigmaJapan社の方とメールする機会あり、本イベントを紹介いただいたのでホイホイと参加してみた。

こちらのイベントは後ほどYoutubeへ公開されるということなので、興味がある方はFigmaJapanさんの公式Xを追っていると出てくると思う。

実践編ということだけあって、登壇されたYahoo!社もHonda社も少し規模が違いすぎる感覚だった。
そもそも、自社プロダクトを持っているわけでもない立ち位置での話なので、デザインシステムの構築をお手伝いする立場?請負でそれを適用する??
そもそもデザインシステムを作ったこともないのに??

自分の立ち位置にツッコミどころ満載である。

うーん、面白そうで大事そうではあるけれど、やはりちゃんと理解して腹落ちするところから進めないとダメだろうな、、、ということでこちらのYoutubeを一旦見ておこう。
そのうえで公開されるであろう今回のイベントを見返してみたいと思う。

Electronを触り始めた

ちょっと秘匿性の高いデータを取り扱うアプリケーションを作りたくなって、そう考えるとWebアプリは面倒かもな?と。

かといってAccessで作るのも手軽なんだけど芸がないな~と思ってElectronに手を出してみた

https://www.electronjs.org/ja

概要レベルは知っていたけれど、実際にコードを見て改めて面白いな、と思った

スタンドアロンのアプリケーションとなるのだから、いわゆるフロントエンドとバックエンドが一つになっているんだけど、ElectronはそれをWebの技術を使って実装している。

つまりは、一つのアプリケーションにNode.jsで作られたバックエンドであるメインプロセスと、Web技術。ReactやViewなどが利用可能なレンダラープロセスが明確に分離されて存在している。

そして、それらをpreload.jsでつなぎ合わせている。

通常httpなどでそれらをつなぐことになる部分はipcが唯一の通信手段として存在している。。と。

面白い仕組みだ。

悩ましいな、と思うのはいわゆるAIを用いたコーディングスタイルを考えるとこのあたりの仕組みの理解をすっ飛ばしてものができてしまうんですよね。
結果論で言えばそれで問題なくものが作られる世界であればそれはそれで効率のいい話ではあるんだけど、、、

とりあえず、最近ろくにフロントエンドに携わっていないのでNext.jsとかどこまでできるんだろう?という不安はあるものの、やれる範囲まで頑張ってみようかと思っています