ChatGPT で何が変わったか
2023 年 3 月時点で、自分の開発スタイルがどう変わったかを雑に書いておく。 どんなタイミングで何を聞いているか主に Go と TypeScript や W3C や IETF の仕様について聞く場合はほぼ ChatGPT Plus を利用している。間違いとかはどうせ公式ドキュメントを読めばいいので、正しさは求めておらず、きっかけを求めている。 最近では Cloudflare Workers 上で動く WebAuthn サーバーを実装しているが W3C の WebAuthn を開きつつも、ほぼ ChatGPT に相談しながら実装している。 TypeScript で Uint8Array から ArrayBuffer に変換する方法を聞いたり、証明書について聞いたりと色々。参考までにどんなことを聞いているかを紹介しておきたい。 WebAuthn で送られてくる署名の r と s がたまに
2022 年に学んで良かった技術
雑に書いていきます。 バックグラウンド自分のバックグラウンドスキルは以下の通り。専門はリアルタイムな通信プロトコルを利用したサーバーの設計と開発とマーケティング。 Erlang/OTPWebRTCEnd to End Encryption細かいのはこちら。 SQLGo で sqlc を使うために学ぶことにした。sqlc を採用したのは複数人数で開発するときの共通言語としては SQL の方がいいだろうというのと、SQL はどんなデータを持たせたいのかを伝えるのに便利と判断したため。 今までずっと通信系ミドルウェアの開発をしてきたこともあって SQL を学ぶ必要が無かったが、今回いい機会なのでちゃんと学ぶことにした。 まずは利用データベースを完全にしぼって TimescaleDB (PostgreSQL ベース) で利用する SQL だけを学ぶことにした。 書籍は元 SIer のガチ SQL
Erlang と GPGPU
GPGPU はもともと名前も知っていたし、なんか使えるらしいレベルで知っていた。ただ個々数年で機械学習系で人気がでてきたことで、色々便利になっているという印象はあったが、機械学習系も興味ないかったので無視してた。 最近になって重い腰を上げて GPGPU を調べているまだどんなことができるのか、何が嬉しいのかを知ろうとしているレベル。 いろいろ調べたので、せっかくなので調べ始めた経緯などもふくめて書いてみた。 Erlang/OTP C 拡張のリスク自分は Erlang/OTP で製品を書いているが、 Erlang/OTP の最大の弱みとして計算処理が弱いというのがある。計算処理が弱いというのは何かしらの変換処理などを行う場合は外部のツールまたは、C 拡張 (NIF) を利用したりして処理を刷る必要がある。 ただ NIF はメリットが少ない。ビルドがその C 拡張に引っ張られることもあるが、ス
値下げをしない
自分の方針としてもう一つ。値下げに応じないというのがある。 製品を売っていれば一度はかならず顧客から「料金交渉をお願いしたい」という名の値下げ交渉をされることがあるだろう。その場合は値下げは一切しないことを伝える。 もし値下げを粘られた場合は取引をしないほうが良い。また、値下げを一度でもしてしまうと、交渉さえすれば値下げをしてくれる会社と勝手に認識されてしまう。 顧客ごとの料金表は提供しないほうが良い。なぜなら世間は狭い。あの会社にはこの料金でだしているのに、なんてめんどくさい話も出てくる。 そのため、自分はすべての顧客に同一な料金表の提示。そして大量購入による割引。これ以上のことは一切やらない。顧客は相談はできず選択しかできない。 自分の会社の料金体系に合わない顧客とは取引をしないという方針を取っている。無理に値引きするのはその製品の寿命を縮めてしまう上に、会社の寿命も縮めてしまうと思う
サポートで稼がない
クローズドソースなパッケージ製品となると、どうしてもサポート費用という話がよく出てくる。 例えば、最初に製品を買って貰い、その後は毎年製品価格の 10% をサポート費用として貰うというモデルはよくある話だと思う。 このモデルはサポートが発生しないと 10% がそのまま利益になる。ただ、このモデル自分が経験したパターンだと、毎年値下げ交渉が発生する。 つまり顧客としては問い合わせもしないのにサポート費用を今まで通りの費用で払い続けたくないという話が出てくる。めんどくさい。 ミドルウェア屋さんになって 10 年以上が過ぎたが、ずっとこのモデルに違和感があったので、自分の会社の自社製品はサポートで稼ぐのをやめることにした。 サポート費用という概念をやめたそもそも製品にサポートはあって当たり前。それを別の費用として切り出されているのに違和感があった。 サポートを特別扱いするのをやめたたとえばプレミ
初の新入社員が入った
今までのメンバーは全員起業時に参加してくれた社員なので、5 期目で初めての新入社員。 零細企業である自分の会社が、新入社員を受けいられるようになったというのは会社としてはとても喜ばしい事だと思う。 自社製品である程度売上があげられていることから、まずは自社製品に全力でコミットしてもらいつつ、何かお手伝いできそうなお仕事があったら手伝うという方針を取ることにした。 これも、自社製品の売上が出ているからできることだなと実感した。自社製品での売上が出ているというのは、ここまで攻める姿勢がとれるものなのか、と。 もし売上がお手伝いだけの場合は、自分は採用をできなかったと思う。自社製品の売上は本当に大きいことを実感した。
自分が欲しいサポートサイトの仕様書を書き始めた
長い間パッケージベンダーで働いているので、サポートと切っても切れない関係なのだが、自分が求めているようなチケット方式のサポートツールをまったく見かけないので、作るしか無いのかと途方にくれている。 もともとはやり取りをシンプルにするためのチケット方式のサポートシステムが欲しかった。 ただ、自分の色々要求仕様を書き出したりしていると、顧客管理やライセンス発行、アップデート版の提供といった、チケットシステムだけでは実現できない機能がたくさんある。 実際、今はメールと Google docs とちょっとした Python スクリプトで実現しているのをできるだけサポートサイトとして提供していきたい。 悩んだ結果まずは、自分が欲しい機能の仕様書を書くことにした。 仕様書を書くといっても机上の空論ではなく、プロトタイプを動かしながら仕様書が書きたい、ということでせっかくだから GAE/Go でも勉強する
CPU の AES 高速化
Intel と AMD の CPU には AES-NI という CPU 命令拡張が搭載されています。詳細は Wikipedia を読んでください。ちなみに ARM にも AES 拡張が搭載されているものがあります。 ちなみに 私自身はハードがわからないので AES-NI の知識はまったくありません。AES がハードウェアによって高速化される程度の知識です。 ただ、AES といっても暗号の種類は CBC 以外にも、最近良く使われている AES-GCM (TLS 1.2 で利用) や、 WebRTC の SRTP で利用されている AES-CTR があり、実は CPU ごとに AES-GCM や AES-CTR はかなりの差があるというのを最近調べていて気づきました。 ということでインターネッツのちからを使って募集してみることにしました。この記事を読んだ人も是非お時間あれば、気軽にコメントして
自社製品の売上で従業員の給与をまかなえるようになった
目標としていた社員の給与をすべて自社製品の売上でまかなうというのが達成できた。ということで自社製品ほんとうに売れるまでの距離が長いという話をしたい。 前提資金調達は一切していない社外のお手伝いしてお金を稼ぐ資金調達している時点で、そのビジネスに注力できるのでこの話は関係ない。 よくある話そもそも資金調達していないので、完全に社外のお手伝いに依存することになる。社外のお手伝いはいつなくなるかわからない。 社員に給与は払わなければいけないので、役員は自分の給与以上に働く必要がある。忙しくなる。自社製品作ってる暇がなくなる。 結局社外のお手伝いがメインの会社になる。 ここまでがよくある話。 社外の手伝いが忙しい会社ほど自社製品を作りたいという話を良くしている。実際は何もしていない。 自社製品を作るのが難しい誰もが売れる製品を作れるわけではない。売れる製品は正直、運の要素がかなり高いと思っている。
SDK の開発と維持の難しさ
SDK を使ったことがあっても作ったことがないので、SDK を作るぞとなってもまったくの手探り状態だった。 必要な SDK は ブラウザで利用するための JavaScript で書かれたSDK 、iOS で利用する Swift で書かれた SDK、そして Android で利用する Kotlin で書かれた SDK が必要になった。 そして残念ながら自分には今回求められるような SDK を設計したり開発したりする能力はない。 SDK というのはとても専門知識が求められるし、特に設計が重要だ。使う側の人が簡単につかえて、さらに汎用的に書かれている必要がある。 どう考えても、難易度が高すぎる。 まずは社内で開発できるところまでやっていこうということになり、 JavaScript の SDK は JavaScript が得意な社員が書いてくれた。
品質を上げてサポートの負担を減らす
自分で会社を持ったタイミングで、実現したいと考えていたのが、自社製品やドキュメントの品質を上げることで、サポート問い合わせへの負荷を下げるという考え。 顧客が増えれば、その分サポート問い合わせは増える。最初のうちは良いが、顧客が多くなった場合、サポート問い合わせが多くなると他の業務ができなくなる。 もちろん社員を増やし、対応する人を増やすことで対応は可能だ。ただその分の給与を払う必要があるため、製品の価格を上げる必要上がる。 では、サポート問い合わせの数を減らすためにはどうしたらいいか、そもそも顧客は問い合わせはしたくてしているわけではない。 ドキュメントを読んでよくわからないから問い合わせをしているのがほとんどだろう。そうなるとドキュメントの品質を上げる事でサポートの問い合わせを減らすことはできるだろう。 また、製品がよく落ちたり、バグっていたりした場合、問い合わせは増える。当たり前だ。
自分が考えるテックリード
このエントリがとても素敵だったので。自分が考えるテックリードの役割を書いてみることにした。個人の意見なうえに、自分自身がテックリードという職を経験したことないので、完全に妄想である。 自分はコードを書くプロダクトマネージャー、たぶん。 テックリードの条件積極的にチャレンジできる困ってる人を技術力で助けられるチームの成功を意識して行動できる技術力のある雑用。コードをゴリゴリ書いて解決というイメージではない。それよりも自分の担当範囲は粛々とこなしつつ、他のメンバーが困ってる所を助ける。さらに、ボトルネックになりそうなところを早めに潰して回る。 テックリードと言う素敵な名前だけれど、むしろ裏方。 技術力をつけるためには、そのための努力は惜しまない。その技術は自分のためというよりもチームのため、チームが成功するために他の人をサポートするために使う。サポートするためには自分のタスクを早めに終わらせる
一方通行な「情報交換させてください」
Twitter では何度もつぶやいていたのだけれど、自分の意見をまとめておく。 「情報交換させてください」は殆どの場合で「自分はよく知らないので、貴方ならよく知ってるんだから教えて欲しい、タダで」というパターン。つまり一方通行が多い。 何者かわからない初対面の人に「Erlang/OTP の情報交換しましょう」と言われる怖さ。いや、貴方は誰なんだ。 特にビジネスでの「情報交換させてください」はネガティブな印象しか持たれないので本当にやめたほうが良い。特に、その技術でお金を稼いでいる会社に対して大変失礼だということを理解してほしい。 普通に技術的に困っているなら「困っているので相談にのってほしい」でいいし、興味があるなら「今はわからないが興味がある」でダメなのだろうか。 一方通行な「情報交換させてください」を撲滅したい。 一方通行な「情報交換をさせてほしい」の方に「技術相談ということであれば、
シンプルなチケット方式サポートシステムが欲しい
長い間パッケージベンダーで働いているので、サポートと切っても切れない関係なのだが、自分が求めているようなチケット方式のサポートツールをまったく見かけないので、作るしか無いのかと途方にくれている。 ちなみに、こんな感じのが欲しいというのはすでに体験済み。 それは Vultr のサポートツール。Vultr はかなり価格が安いクラウドサービスで、愛用している。ここのサポートツールがかなり理想で、シンプルかつとても使いやすい。 Vultr のサポート画面チケットを作成する時、通常のサポートなのか、課金関連のサポートなのかを問い合わせられるようになっている。素晴らしい。 None となってるのはどのクラウドインスタンスのサポートを要求するか指定できるようになっている。 そして件名と内容、さらに添付ファイル。あとはチケットをオープンするだけだ。そうすると Vultr 側に通知される。返信が来ればメール
自社製品の販売終了
本日自分が経営する会社の自社製品第一号の販売を終了した。なんとも言えない気持ちだ。 自社製品をリリースするときは、もちろん売れて、顧客に長く使ってほしいと思ってる。 ただ、売れるかどうかは自分たちが決めるわけではなく市場が決める。売れない場合はコストを積み重ねていき、会社の経営状況を圧迫してしまう。 また製品は生き物だ。メンテしてあげないとすぐにダメになる。メンテするのは体力を使う。 売ることの難しさどんなに良い製品でも利益を挙げない以上、製品を売ることを諦める必要がある。アップデートしなくても売れる製品なら良いのだが、そんなうまい話はない。 最近は売れる製品というのはかなりの率で運の要素が入っているのではないか、と思ってしまう。 もちろん、世界初やその分野に革命がを起こせるような製品であれば、話は別だろう。ただ自分はそのようなものが作れる人ではなく。少し便利になる何かが作れる程度。そう考
一つの技術で食べていく怖さ
自分が経営する会社は今年の 7 月から自社製品が WebRTC という技術を利用したサーバ製品のみになる。 現段階ではすごく売れているというよりは、だんだん売れてきたという段階だ。大手にも採用され始めてきた。リリースして 2 年目。順調な方だろう。 一つの技術に依存する怖さは、前職で恐ろしいほど学んだ。特にある程度売れてくると怖い。 なぜなら売れるとリソースを集中し始めるからだ。まさに今のタイミングだ。リソースを集中すると他のことに目が向かなくなる。 ではどうしたらいいのか、自分が取った行動をまとめてみた。 一つの技術で食べていくためにその技術で、なんとなく一番を取り続けていくのが一番手っ取り早いと考えている。そのため WebRTC といえば時雨堂というのを市場に刷り込む必要がある。 継続は力なりじゃないが、とにかく継続的に発信していく。 発信だけだと難しいのでうまく顧客や一緒に組んでくれ
リモートワークに対する考え方
自分の中でリモートワークに対する考え方をまとめておくことにする。 そもそも自分自身はリモートワークをするのはかなり難しい、職種的に人と会って話すことを求められる事が多いためだ。 ということで、ここでの考え方というのは、自分が一緒に働く仲間がリモートワークを行う場合の考え方とする。 まずリモートワークに対する考えだが積極的に採用していきたい、という方針だ。ただしその本人がリモートワークに向いており、一緒に働く仲間がリモートワークでも良いと思えるのであれば、という条件付き。 そのため、誰も彼もがリモートワークに向いているとは思っていない。リモートワークを希望し、さらに向いている人のみがリモートワークを行うべきという考えだ。 身近なリモートワーカーまず、自分がどんなリモートワーカーと一緒に働いているのかを書き出してみた。一人は自社役員、もう一人はフリーランサー。 自社の CTO完全フルリモート。
Elixir Conf で話してきました
Elixir を一行も書いたこと無いですし、今後も書く予定はありません。むしろ最近は Golang を勉強しています。 話す内容はなんでもいいっていわれていたので、Erlang/OTP の細かい話をしてきました。余り皆が話さそうなマニアックな話。 なぜ Erlang/OTP を使い続けるのか #elixirjp というハッシュタグで Twitter を見ていたら、受けが良かったようで良かったです。 何度もドワンゴさんの話をした理由ですが、ドワンゴさんは日本というか世界レベルで見て大規模な Erlang/OTP で書かれたシステムを運用している会社のため、色々ノウハウがあるので公開して欲しいな、という気持ちです。 ドワンゴで Erlang/OTP 書いていた人達とは面識があります。ちなみに懇親会で色々おしえてもらいましたが、内緒話だったので内緒です。 さて、Elixir Conf ですが 3
少機能で高機能な製品を作る
ついついやってしまいそうになるのが新しい機能の追加だが、そこは心を鬼にして本当に必要な機能なのかを考えるべきだ。 多機能な製品は市場の幅を広げると思いがちだが、そんなに簡単に市場の幅は広がらないし、多機能にすればするほど価格を上げていく必要が出てくる。 高くて多機能な製品が必要なお客さんはほんの一握りだし、もともとの市場が小さい場合は、そんなお客さんはいない可能性がある。 一度追加した機能は外せない最初のうちに色々便利な機能を追加しようと躍起になりがちだがそれらの機能は一度でも積んだらそう簡単には外せなくなる。 外せないとりあえず付けた機能をメンテナンスしていくのはなかなかしんどい。その機能が邪魔で新しい機能をつけづらい、といった問題もでてくる。 多機能は製品の寿命を縮める場合がある機能を追加すればその分だけコードが増える。さらにテストも増える。依存関係も増える。 つまり、その製品のメンテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Discord の採用している技術