ChatGPT で何が変わったか
2023 年 3 月時点で、自分の開発スタイルがどう変わったかを雑に書いておく。 どんなタイミングで何を聞いているか主に Go と TypeScript や W3C や IETF の仕様について聞く場合はほぼ ChatGPT Plus を利用している。間違いとかはどうせ公式ドキュメントを読めばいいので、正しさは求めておらず、きっかけを求めている。 最近では Cloudflare Workers 上で動く WebAuthn サーバーを実装しているが W3C の WebAuthn を開きつつも、ほぼ ChatGPT に相談しながら実装している。 TypeScript で Uint8Array から ArrayBuffer に変換する方法を聞いたり、証明書について聞いたりと色々。参考までにどんなことを聞いているかを紹介しておきたい。 WebAuthn で送られてくる署名の r と s がたまに
なぜ Zig の採用を検討しているのか
かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er
Visual Studio Community 2019 のライセンス
Web アプリケーションとクラウド サービスだけでなく、Windows、Android、iOS 向けのモダン アプリケーションを作成するためのフル機能を装備した、拡張可能な無料の IDE です。 Web アプリケーションとクラウド… さすが Microsoft です、ライセンスについてとても丁寧に書かれているので、見ていきます。 組織が学習環境のクラスルームで、アカデミックな研究のため、あるいはオープン ソース プロジェクトに寄与するために、Visual Studio Community を使用する場合には、ユーザー数に制限はありません今回、自社で開発予定の Momo の Windows 版と Sora の Windows SDK はオープンソースプロジェクトとして公開し、開発をしていきます。オープンソースの寄与であれば問題ないようです。 エンタープライズ以外の組織では最大 5 ユーザーで
HTTP/3 や QUIC はまだ早すぎる
フューチャーアドベントカレンダー2018](https://qiita.com/advent-calendar/2018/future)のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされて... 渋川の記事の補足というか、実装者目線からみた話を書きます。 立ち位置仕様策定には関わっていません。あくまで出てきた仕様を実装する実装者（Implementor) です。 また HTTP/3 や QUIC がメインというよりかは WebRTC がメインです。WebRTC が利用しているプロトコルが QUIC に置き換わる流れがきているため、QUIC を実装しており、さらに QUIC を利用したプロトコルとして、まずは HTTP/3 が採用されていることから、HTTP/3 に手を付けている状況です。 現時点では Chrome Canary M74 で利用可能な
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
Discord Game Store – V – Medium
なんというか、正直にいって衝撃を受けてる。Discord は「ある程度ユーザ数を集めたら MS とかに買収されて終わりなのでは？」なんて思っていたからだ。 月 4.99 ドルの Nitro なんかではこの大規模なサービスを支えきれないだろう。 Discord は自分の大好きなサービスの一つだ。WebRTC や Electron 、Elixir 、React 、React Native 、GCP といった自分好みな技術選定。 自分が運営している技術コミュニティや、自社の OSS な製品のサポートツールとして使ったりもしている。安定感があり、軽量でパーミッションも考えられていてとても使いやすい。 お金大丈夫なのか？ともずっと思っていた。もと OpenFeint の CEO が起業したこともあり、(GREE に買収されたので) お金はあるんだろう。さらに調達も 30,000,000 ドル以上を調
一方通行な「情報交換させてください」
Twitter では何度もつぶやいていたのだけれど、自分の意見をまとめておく。 「情報交換させてください」は殆どの場合で「自分はよく知らないので、貴方ならよく知ってるんだから教えて欲しい、タダで」というパターン。つまり一方通行が多い。 何者かわからない初対面の人に「Erlang/OTP の情報交換しましょう」と言われる怖さ。いや、貴方は誰なんだ。 特にビジネスでの「情報交換させてください」はネガティブな印象しか持たれないので本当にやめたほうが良い。特に、その技術でお金を稼いでいる会社に対して大変失礼だということを理解してほしい。 普通に技術的に困っているなら「困っているので相談にのってほしい」でいいし、興味があるなら「今はわからないが興味がある」でダメなのだろうか。 一方通行な「情報交換させてください」を撲滅したい。 一方通行な「情報交換をさせてほしい」の方に「技術相談ということであれば、
同時接続 700 万、秒間 2 万通という Nintendo Switch 向けプッシュ通知システム NPNS の資料を読んで
AWS Summit Tokyo 2018 で実施されたセッション資料・動画をダウンロードすることができます。（順次公開） ※AWS Summit 2018 へお申し込みいただいていない場合、別途ダウンロード申し込みが必要となります。… 【任天堂様ご登壇事例】Nintendo Switch （TM） 向けプッシュ通知システム「NPNS」AWS はよくわからないので Erlang/OTP 視点のみです。 ejabberdejabberd はフランスの ProcessOne という会社が開発している XMPP サーバです。XMPP が何かはここでは説明しません。 ejabberd は TLS や XML 周りの性能を出すため C で書かれている以外、他はすべて Erlang/OTP で書かれています。 ejabberd の歴史はとても古く、自分が Erlang を学び始めた頃にはすでにありまし
カスタマイズしないとどうなるか
続き。自社製品のミドルウェアでカスタマイズをしないと実際にどうなるかを書いていく。 カスタマイズの相談をされた場合一切対応していない事を伝える。メールが返ってこない事が多い。そのためビジネスチャンスを逃している可能性は高いが、カスタマイズをするリスクのほうが高いため問題ない。 カスタマイズを要求していくる会社から相手にされなくなる。 注文から提供までメールにて申込書を送り、記載して返送してもらう総務が社内に立っているライセンスサーバでライセンスを発行する製品のダウンロード URL とライセンスファイルをメールで送る終わり。製品の提供まで 30 分くらい。自社製品は最小ライセンスの費用が 60 万円/年なので 30 分で 60 万円の売上になる。これが毎年。 この後はサポートのお仕事。 サポート対応全ての顧客が同じ製品を利用しており、自社製品は最新版を利用していることがサポートを受ける前提と
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
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 はかなりの差があるというのを最近調べていて気づきました。 ということでインターネッツのちからを使って募集してみることにしました。この記事を読んだ人も是非お時間あれば、気軽にコメントして
少機能で高機能な製品を作る
ついついやってしまいそうになるのが新しい機能の追加だが、そこは心を鬼にして本当に必要な機能なのかを考えるべきだ。 多機能な製品は市場の幅を広げると思いがちだが、そんなに簡単に市場の幅は広がらないし、多機能にすればするほど価格を上げていく必要が出てくる。 高くて多機能な製品が必要なお客さんはほんの一握りだし、もともとの市場が小さい場合は、そんなお客さんはいない可能性がある。 一度追加した機能は外せない最初のうちに色々便利な機能を追加しようと躍起になりがちだがそれらの機能は一度でも積んだらそう簡単には外せなくなる。 外せないとりあえず付けた機能をメンテナンスしていくのはなかなかしんどい。その機能が邪魔で新しい機能をつけづらい、といった問題もでてくる。 多機能は製品の寿命を縮める場合がある機能を追加すればその分だけコードが増える。さらにテストも増える。依存関係も増える。 つまり、その製品のメンテ
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Business Source License 1.1