HashiCorp が OSI オープンソース・ライセンス のソフトウェア (以降 OSS) 製品を Mozilla Public License 2.0 (以降 MPL) から Business Source License 1.1 (以降 BUSL) にライセンス変更して話題になっています。 自社は主力製品はクローズドソース、それ以外は Apache License 2.0 で OSS として公開という戦略をとっていることもあり、 BUSL について自分の考えを雑に書いておこうと思います。 法律の専門家ではないので、間違いもあると思います。きっちり理解したい人は弁護士に相談しましょう。

かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er

いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った

フューチャーアドベントカレンダー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 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ

正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして

起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資本金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな

Today we're making it easier to go live and interact with your community from your computer and phone. First, if you've… YouTube が WebRTC を利用した配信に対応した。つまり今まで YouTube で配信するには何かしらのツールが必要だったが、WebRTC を利用した配信機能を使うことでブラウザとウェブカメラだけあれば配信ができるようになる。 そう、つまり pixiv Sketch Live が実現したあの手軽な配信が YouTube でも可能になった。ただ、まだ画面共有に関してはまだできなさそうだ。 配信者はブラウザから配信して、あとは YouTube が HLS や MPEG-DASH に変換してくれるので、スケーラビリティを気にする必要はない。もちろん

見てみると、たしかに 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 の仕様になっている。