Black Cat CarnivalというSNSサービスを開発している 昨年10月から開発を進めている。反響があるようであればチーム開発に移行したい、とは考えているが今は一人で開発している。（※開発以外は様々な方に助けていただいています🙇‍♂️） 理想的には動く物でベータテストを行えると良いのだが、相当な時間がかかってしまうのでクライアントを先に開発して意見を頂戴しブラッシュアップしようと考えた。…というか、これを使ってくれる人はいるのか？を確認しなければ、不安に抵抗できなくなってきた。 しかしApple AppStoreやGoogle Playで公開ベータテストを行うには審査を通過する必要がある。審査は動作するサービスでなければおそらく通らない。 クローズドテストであれば審査は要らないが、メールアドレスを頂戴して招待をお送りする必要がある。敷居が高いと感じた。 クライアントはCompo

Linearのリニューアル記事がすごく良かった。 A design reset (part I) How we redesigned the Linear UI (part Ⅱ) その記事の中で「LCHカラースペース」について書かれていた。知らなかったので調べてみると、以下の記事を見つけた。 この記事の内容を抜粋しながら、自分用に簡易なメモとしてまとめる。 LCHとは？LCHは簡単に言うと、異なる色相でも同じコントラストに見えるように構成されたカラースペース。 1976年に国際照明委員会 (International Commission on Illumination, CIE) によって最初に定義された色空間であるため、CIELAB とも呼ばれている。 LCH は、Lightness（明度）、Chroma（彩度）、Hue（色相）の略。 HSL と LCH の違いLightness（明度

これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職（テックリードだったり、デザインリードだったりそういうやつ）につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの

こまけぇ話は置いておいて、BearerとSender-Constrainedの話がHTTP Cookieのところでも出てきたよというお話なのですが、ここを少し補足します。このBearer vs Sender-Constrainedという用語が一番出てくるのがOAuthの文脈です。 文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife Bearer Token : 第1回で説明した地下鉄の切符のようなトークン。所持していれば使えるので、他の人が拾っても使えます。 Sender Constrained Token : 利用者を制限するトークン。飛行機の搭乗券のように、利用者が指定されている、制限されているもの。 概念はこんな感じですが、実装方法は色々なものが

前にもここにぽちぽちと書いたりしたけれど、1年とすこし前。こどもたちが大きくなって手狭になったのをきっかけにマンションからいまの家に住み替えたのです。で、住み替えたのはいいけれど、あたらしい家はともかく広く、そして築古の家だったので、断熱性能も高くない。つまり、マンション時代とくらべて、光熱費がドカンと上がったんですね。おりしも世界はエネルギー価格高騰の時代。出てきた電気代にほんと目ん玉飛び出るかとおもったんですよ…。 冷暖房効率がもともと悪いうえに、暖房としてエアコンをつかっていたのでなおさらです。毎月これではやってられん、なんとかせんといかん、ということで、あわてて家庭用太陽光発電の導入を決めました。せっかくじぶんで持ってる建物だし、ね。 家庭用太陽光発電。まあ賛否両論というかえらく嫌われているというか、人によっては本当にボロクソ言われていて。でもまあそんななかいろいろ調べてみると、少

2016年6月から株式会社カケハシのCTOを務めていたが、昨日の2024年2月29日付けで辞任した。 辞任にあたっての想いや在籍中の思い出について熱量高めに書くことも考えたが、一旦は報告を優先してコンパクトなテキストにしておく。それまで比較的ジョブホップ気味だった私にとって7年9ヶ月という在籍期間は到底考えられない圧倒的な長さであり当然思い入れも一入である。350人を超える規模の組織成長という未知の領域で様々な経験を得ることができた。在任中に関わった全ての顧客、同僚、関係者の皆様に心から感謝している。 3月以降の活動については何も決まっていないが、これから色々な方・企業の話を伺って可能性を探っていくことになると思う。ただ、カケハシの前に同じくCTOについていたサイカから考えると10年以上、事業成長のためにあらゆるものを振り捨てて全力疾走してきて少し立ち止まってゆっくり考えたい気持ちが強いた

そうして「メモ帳」「天気予報」「パズルゲーム」... など色々アプリを作っている中で「自分のテスト勉強のためのアプリが欲しい」となり、自作の単語帳アプリを開発した。これが「暗記メーカー」の原型となっている。 また、書籍にアプリのリリース方法についても記載されていたこともあり、この頃からPlayStoreへのアプリの公開を始めた。 今でこそPlayStoreでは「20人のテスターを集めて14日間テストする」「開発者の身元確認」といったアプリを出すまでの工数がかかるものとなっている。ただ、当時は（確か）そういった制限は存在せず$25の登録料を払えばリリースし放題だったので、アプリが完成したらとりあえずストアに公開していた。 基本的に出したアプリは鳴かず飛ばずだったが、その中で「暗記メーカー」だけは定期的にダウンロードが発生していたため、ユーザからのフィードバック等を参考にアップデートを続けるよ

"GPTs Builders Summit" 公式サイト "GPTs Builders Summit"登壇者のGPTsの仕組みを調べました。判明したプロンプトは以下のリンクから確認できます。(著作権等の事情により、日本のGPTsは除外しました) これらはネットの情報の引用ではなく、2024年2月9日にプロンプト・リーキングによって取得された最新情報です。 Video Maker by In…

リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする

これだけで何不自由なく仕事ができる。あとおそらく数ヶ月後の未来には。 Apple Vision Proを日常的に使い始めた。「日常的に」というのがとてもだいじで、デモを体験するとか、ちょっと借りてみるとかではなく、わざわざ大枚はたいてアメリカまで買いに行ったのはこれをやるためだった。はたして、これが普段使いのツールとして便利に、生活に馴染む時代はやってくるのだろうか？というのを見極めたい、とおもったからだ。 実際に作業環境として「空間コンピューティング」というやつを受け入れ始めると、AppleとMetaの違い、Vision ProとQuestの設計思想の違いがより際立って見えてくる。Vision Proの話を見聞きすると、だいたいセットで「それ、Quest3でも同じことができるんだけど」という話もついてくるんだけれども、同じようで、同じでないんだということがよくわかる。 Appleが作りた

けっこういろいろなところで言っていることなんですが、「すごい」技術、「すごい」製品っていうのはあまり一般に普及しないんですよ 「すごい」ということば。辞書を引くと「びっくりするほど程度がはなはだしい。並外れている」なんて意味が載っています。まあ要するに驚きを示すことばであるわけです。でも、驚きって、長続きしないんですよ。人はすぐ新しいものには慣れてしまう。んで、慣れたら「すごい」という感情は失われてしまうのです。だから、単発で受け取るコンテンツとかには「すごい」は向いているんだけど、継続して使い続ける製品を買う動機にはなかなかならない。いや、まあ、技術マニアである私みたいなひとはそれだけでほいほい買っちゃうんですけど。 じゃあ、すげえたくさん売れたりするのはどういうものかっていうと、すごい、ではなくてキーワードは「便利」とか「楽」とかなんですよね。この技術／製品をつかうと、とっても便利。と

この勉強会にオフラインで参加した。資料もわかりやすく、また登壇者の方の実体験ベースの話が聞けたので非常に満足でした。運営の皆様、登壇者の皆様、ありがとうございました。 さて、本来なら各セッションに対して、一言ずつ感想を書いた方が良いかもしれないのですが、うまくセッションごとの感想をまとめるのが苦手なので、聞いてみて私が思ったことを率直に書いていきたいと思います。 (今、生成AI x インシデントレスポンスが私のマイブームなので、その偏見が多量に含まれています) 多くの人が回答を欲しがってそうな部分1. 理想はわかった。でも現実は？作業担当者とインシデントコマンダーはスキルセットが異なるけど インシデント自体少ないので実地で覚える機会は万人にはない 「早く復旧したい」と思っている人が多く、障害を学習機会にしにくい 障害が発生した時に居合わせる人数がそもそも分業できるほど多くない 対応手順を規

Appleの「空間コンピューティング」デバイスのVision Proがアメリカで2024年2月2日に発売されることがアナウンスされました。おねだん3499ドル。日本円で…50まんえん超…。ああ、円安が…にくい…。 アメリカでは2月2日発売ですが、これまでの発表では日本含む他国での発売は2024年末までに、と半年～1年弱遅れる予定となっています。 ううむ、もっとはやくほしいぞ。出るならいますぐほしいんだぼくは。ちょっとこれはしっかりがっつり自分で使って感覚を体験したいやつなんだ。 と、いうわけで。しかたないので！アメリカに買いに行くことにしました。まあしょうがないよね。うまいことにちょうど1人ぶん、日本←→アメリカの往復チケットが取れるくらいマイルが溜まっていたので航空券自体にはほとんどお金はかかりませんし。ってまあ、マイルがあるから行く気になったとも言えますけども。 2月2日に羽田を出て、

ことの顛末5月: Cloudflareで開発を始める/遊び始める2023年5月ごろからとある業務委託で新規開発を任されたので、心機一転新しいスタックで開発を行っていました。 具体的には Cloudflare Workers/Pages (Host) SvelteKit(フロントエンド) Hono (API Backend) Lucia Auth (認証) Drizzle (ORM) Swift UI (モバイル) Planetscale (DB) etc... なるべく安く、なるべく安定させて、かつWeb FrontendもiOSアプリも必要だったのでこのような構成になってます。 当時、この構成でこれだけのものを一人で開発していました。文字通りのfull stack engineerをやってました。とてもしんどかったですが、最近のエコシステムの成熟はとてつもなく、１ヶ月ほどで基本のものは出

こんな言葉を聞いたことあるだろうか。 「あの人は技術力が低い」 「あの人は技術力が高い優秀なエンジニアだ」 「あの人は偉いポジションにいるが技術力は低い」 「あの有名な人は，きっと技術力が高いから働いたら色々と学べそうだ」 ある人が言った。 「この会社の従業員は自分より技術力が低い。技術力が高い俺の言うことが正しい」 どうやらその人にとっては設計力含め幅広い技術的な知見を持っていることが技術力らしい。 だが，その人の技術力をプロダクトに適用している姿を見たことがない。その上での主張だった。 主張と行動が相反しているようだが，と尋ねると 「この会社のコードがクソだからだ。」 そして「一から作ればできる」「（業務での）決裁権を与えてくれればできる」 などという反応もあった。 普通に考えれば，ネゴシエーションを取りながらリーダーシップを発揮して進めるべきなのではないか。別にそこに決裁権も何も関係

私は大学の理工系の学部で、PythonとGit/GitHubを教えています。Pythonが学部2年生、Git/GitHubが学部3年生向けで、どちらも必修です。 これらの講義の中で、私は「今日は重要な回だから集中して聞いて欲しい」「今日はあまり重要でない回だから気軽に聞いて欲しい」と重み付けをしています。その中で、「今日やることはこれからの人生で全く役に立たないから、気軽に聞き流して欲しい」と言う回があります。Pythonでは「Pythonが動く仕組み」という回で、Pythonが入力されたプログラムを抽象構文木を経由してバイトコードに変換して、それがスタックマシンとしてVMで実行される様子を学びます。Gitでは「Gitの中身」と題して、Gitのコマンドが裏で実際になにをやっているのか、特にコミットオブジェクトやブランチがどのように実装されているのかを学びます。 PythonでもGitでも、

子どものころは絵を描くのが好きだった。 学校の休み時間は、クラスメートはみな外にサッカーをしにいっていたが一人教室にのこってノートに漫画を描いている、そんな小学生だった。 自宅に戻っても、自室にこもってよく漫画を描いていた。 漫画と書くいっても、別に人を楽しませるために描いているわけではなかった。もちろん褒められると嬉しかったが、それが目的だったわけではなく、いま思えば、それは自分で自分を癒すかのような行為だった。自分を救うために絵を描いていた。 絵を描いているときは、それに夢中で没頭していて、ほかの何にも代えがたい時間を過ごすことが出来た。この時間が、どこか自分の救いになっていた。 中学二年生ぐらいになって思春期にさしかかった頃だろうか。教室で絵を描いていると浮いてしまうことに気づいて、恥ずかしくなって、描かなくなった。 それでもやっぱり絵を描いたりなにか作品を作ったりするのは好きだった

今年 Withings Body+ という体重計、いわゆるスマートスケールを買った。 以前は健康診断以外で体重計にのることはなかったし、体重の増減が激しいタイプではなかったんだけど、Apple Watch からヘルスケアアプリに健康情報が溜まっていくのがなんとなく楽しくて、ふと体重もプロットしてみたくなった。いい年齢になってきたしね。 で、体重計を選ぼうとしたら、希望にマッチする選択肢が意外と少なかった。 Appleヘルスケアに連動する WiFi 接続 Bluetooth 接続のみで、毎回 iPhone で専用アプリを立ち上げて同期しなければいけない体重計が安物だと結構ある 体重計に乗るだけで、勝手にバックグラウンドでシンクして、ヘルスケアにデータが入ってほしい 家族で使える 家族のプライバシーが保たれる。体重が勝手に共有されない 体重が近い家族がいても誤判定しない 体重以外の体脂肪とか測

今度のカンファレンスで以下のようなことを聞かれそうなので、最近の出来事とともに、記憶に刻むためにも書いてみる。あんまり推敲はしてない、だらだらと。 ソフトウェア開発において、ビジネスの人と開発の人とでなんか意識が合わないみたいなことの根源はどこにあるのか? みたいなのが最近少しわかったことがある。(ビジネス / 開発と区分けすること自体がそもそもなんだけど、それ言い出すと考察が進まないので、あえて分ける) ビジネスの人は、そもそもがそのビジネスの実現だったり顧客の問題解決だったりが最初から目的なので、簡単にいえば「早く顧客の問題を解決してビジネスを実現したい」と自然に思っている。これは当たり前。 たとえば自分が自宅にお客さんを招くときには「そのお客さんに快適に過ごして帰ってほしい」と思って、家を掃除したり振る舞う食事の献立を考えたり、食後にするゲームは何にするか、などを考えたりする。動機は

子どもが生まれたのでそちらに時間をとられて、なかなか技術のキャッチアップが難しいことが増えた。こう書くと、隙間時間を使えばよいではないかと思われるかもしれない。実際うちの子はかなり昼も夜も寝る（寝た）し、お世話がかなり楽な方で隙間時間はある。しかし子育てしている方はわかると思うが、子が寝ている間は親も寝ないと体力が持たない。加えて、子はいつまで機嫌良くいるかわからない。いつ中断されるかそわそわしている状態で、まとまった論考を腰を据えて読む気力などない。というわけで、隙間時間を使っている気力はない。 数ヶ月前に仕事に復帰して以降、どうも最新技術の動向やトレンドを追えなくなっているのが悩みだった。ちなみに、「最新の話題を常日頃から追うべきか」という議論は時折見かけるが、私は今より高い給与得たい、かつ（たとえば組織全体を見るような）難しい仕事をしたいのであれば追い続けるべきという立場だ。というわ