オンラインドキュメントと日本語全文検索
自社では Sphinx というドキュメントツールを利用しているのですが、残念ながらこれに付属している検索機能の日本語検索はかなり厳しいです。また残念ながら Sphinx 開発側も検索周りを改善するという予定は直近ではないようです。 そして検索というのはとても難しい技術なため自分のような素人では導入して「普通に期待する動作」をさせるまでの距離はとても遠いです。 ただ、なんとかして日本語全文検索を実現したいという思いはここ10 年くらいずっと思っていました。これは自社の Sphinx テーマを作ってくれている社員ともよく話をしていたのですが、どうしてもリソースをつぎ込めずにいました。 まとめ日本語検索に対応している Meilisearch を採用したドキュメントスクレイパーの実行は GItHub Actions (Self-hosted Runner) を採用した自社 Sphinx テーマの検
なぜ WebAssembly 生成を Go にしたのか
オンラインイベントで聞かれて、ツイッターにつぶやいたら思った以上に反響があったので、もう少し詳細に書いてみます。 思ったより反響があったまとめ信頼できる暗号ライブラリがある自分が TypeScript より Go のほうが書けるGo の Wasm バイナリサイズを気にする必要がないWebCrypto にない暗号が必要自社の WebRTC SFU において End to End Encryption (E2EE) をブラウザ上で実現するためにはいくつかの壁がありました。 一つは WebCrypto が提供していない暗号を利用したいというものです。 今回 E2EE を実装するにあたり採用した Signal プロトコルでは公開鍵暗号に Curve25519 を採用しています。残念ながら WebCrypto では Curve25519 に対応していません。この時点で「暗号ライブラリをどこからもって
E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
企業 OSS を継続開発するためにやっていること
時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発
PleaseContactUsError
時雨堂が提供しているサービスは個人と紐づく情報として GitHub ID (変更不可能なユニークな数値)と GitHub Username (変更可能な文字列) 以外はサーバに保存していません。 そのため、ルールを守っていない可能性の高い利用者に連絡を取ることがかなり難しいです。いきなりBAN してもいいのですが、それよりは優しいメッセージで伝えたいなと。もしかするとドキュメントを読んでないだけかもしれないですし。 優しいメッセージをどうしようかと考えていたのですが、認証エラーの理由に PleaseContactUs という文字列を返すことにしました。設定ファイルに please_contact_us_list: というのを用意してそこに GitHub Username か GitHub ID を書くことで対応できるようにしました。 データベースに入れるとかはめんどくさいのでサボりました。
Lua はオープンソフトウェアだが、オープン開発されたことは一度もない
これは Lua のよくある質問からリンクされているメールの文章に書かれている文章で、 Lua のスタンスについて書いてある。 Lua is open software, but it has never been open developed.メールにはもう少し踏み込んで書かれているので興味ある人は読んでみてほしい。 この開発をオープンにしないという考えが自分にフィットしている、そのため自社で公開しているオープンソースは基本的にこの考えを適用している。 理由としてはオープンな開発は負担が大きすぎると感じているのが一つある。小さな会社はリソースが少ないため、オープンな開発をやっていくのはとてもむずかしい。 もう一つの理由は、なにかあればパッチではなく、フォークして開発してもらうという方針を取りたいというのがある。自分たちでコントロールできる範囲で開発していきたいう考えが強いからだ。 開発をオ
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 の仕様になっている。
ありがとう、 Joe
Erlang/OTP の作者の一人である Joe Armstrong が亡くなられた。まだ 68 歳であまりにも早すぎた。 残念ながら自分は彼にお会いする機会はなかったが、彼からはとてもたくさんのものをもらった。自分と Erlang の話でも雑に書いてみようと思う。 Erlang に出会ったのは R12B が出る前、R11 の頃だったと思う。2007 年くらいだろうか。 それまで自分は Python と Django ばかりやっていて、 C/C++ は全然だし PHP もかけない。Rails もまったくダメ。 ただのプログラムが好きな人だったのだが、転職をきっかけにミドルウェアの開発に携わることになった。 今まで使ってきた Python ではミドルウェアを作るのは厳しい、だからといって自分のスキルでは C/C++ でマルチスレッドプログラミングは無理がある。 ただ、仕事はしないといけないと
リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
打ち合わせの条件
自社ではミドルウェアパッケージ製品を開発して販売しています。営業はおらず、検索からの問い合わせがほとんどです。 その場合、詳細な要件は内緒だが、まずは打ち合わせしてほしいと言われることがありますが、もともとの知り合いとかではない限り、打ち合わせをするため条件に１ヶ月間、無料で利用できる評価版を使ってみることをお願いしています。普通はまず打ち合わせをして、そこから評価版へと行くのが多いと思いますがその逆をやってみています。 打ち合わせの前に評価版を提供する理由結構ネガティブな理由が多いです。 小さい会社なので打ち合わせに時間を取られなくない要件がまとまっていない打ち合わせはお互い嬉しくないただ一方的な情報交換がしたいだけなので会いたくないそもそも製品を買いたいなら使ってみるのが一番本気で検討しているなら検証する時間を取る実際に使いながらの質疑応答が効率がいいミドルウェアの場合は実際使ってみな
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
自社製品で食べていけるようになるまでやったこと
ミドルウェアのパッケージ製品で食べていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、
評価制度について – V – Medium
評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評
WebRTC からみた Edge のChromium ベース
Microsoft Edge. Contribute to MicrosoftEdge/MSEdge development by creating an account on GitHub. MS Edge が Chromium ベースになることが発表されました。いろいろいわれてるようですが、 WebRTC 視点で書いていきます。 要約 (TL;DR)Chromium ベース最高！ Edge の WebRTCそもそも Edge の WebRTC 実装はよくわからない実装でした。 まず暗号ライブラリはインターナルです。さらに WebRTC ライブラリもインターナルで、リリースノートすらない状況で、 Edge がアップデートしても本当によくわからない状況で、 Edge の WebRTC 対応は難航していました。 また動作も H.264 と VP8 以外に Skype 独自用のコーデックを用意
受託開発の罠 – V – Medium
資金調達していない零細 IT 企業を経営していると抜け出せなくなる受託開発の罠ですが、罠にはまるパターンと、そして自分がどんな方法で罠にはまらないように経営しているのか書いていきます。 前提そもそも受託開発が目的の会社であれば、罠にどっぷりハマって問題はないので、ここでは自社サービスなり自社製品をメインとする会社を前提とします。 経営者が全力で稼いで、社員が自社製品やるパターンや、その逆あったりはここに当てはまりません。当てはまるのは自社製品やりたいけどお金を稼がないといけないといってずるずる行くパターンを受託開発の罠としています。 自転車操業調達していない零細 IT 企業は基本的に自転車操業になります。会社にお金がないと当たり前ですがキャッシュフローが苦しくなるため、受託開発を行いお金を稼ぐようになります。 受託開発は毎月契約でお金をもらって開発リソースを提供するタイプと、いくらでお願い
自分が働きたい会社にしない
時雨堂は会社の仕組みを Gist でオープンにしている。実はあの仕組みは自分が働きたいと思う会社の仕組みではない。 時雨堂は 10:00–17:00 の定時制で 6 時間労働。さらには仕事は選べない。技術もあまり選べない。月給は安く抑えられており、賞与は保証なし。ただし儲かった場合は賞与を高めに出す。評価制度はない。 時雨堂で自分が従業員として働きたいとは思っていない。自分が従業員として働くのであれば、裁量労働で、仕事は好き勝手に選べて、給与は稼いだ分だけほしい。さらに技術は自分が使いたいものを使う。ただし食堂はあってほしい。 ではなぜ時雨堂は自分の働きたい会社になっていないのか。それは単純で自分はあくまで経営者であり、従業員ではないからだ。そして自分は社会不適合者であるため、従業員としてやっていけなかったから起業した身であるからだ。 つまり従業員としてやっていけなかった人が望む会社の仕組
集中力のない人の戦略
集中力がないといろいろなところで苦労します。とりわけ苦労したのが学校です。学校では決められた時間で学ぶ授業、決められた時間で問題を解き結果を出す試験があります。これが本当に集中力のない自分には地獄でした。とにかく決められた時間で何かをするというのがとても苦手でした。 恐ろしいほど集中力がなく、決められた時間の中で結果を出すことができない自分がどうやって仕事をしているのかという話を書いてきます。 ダラダラ継続する結論を先にいうと「人の何倍も時間をかけて、常に変化する分野ピンポイントにダラダラと継続する」という戦略を取ることにしました。 継続といえばカッコイイですが所詮は「ダラダラ」です。つまり気分が乗ったときだけダラダラとやっていきます。 ただ、ダラダラやるのも１年、５年、１０年と続ければ結果は出ます、多分。 また、常に変化する分野であれば集中力よりも、継続が求められるはずだとも考えました。
SmartHR 主催入社歓迎会練習会
さて、自分はこのようなイベントにはまったく顔を出さないのですが、今回は誘ってくれた kakipo が SmartHR の共同創業者ということで、とても興味を持っていたこともあり、参加してみた次第です。 イベントは普段とは違う感じで、とてもキラキラした方たちが出迎えてくれていました。異世界体験してる感じです。 イベント会場には風船が設置されて、ますますキラキラ感がすごかったです。ただ、キラキラ感があるわりに、嫌味がない。キラキラを継続しようとしない感じ。ただ一生懸命に参加してくれた人たちを歓迎しようとする感じが素敵でした。 また、ほぼ全員の SmartHR のエンジニアの方が参加されていて、席を色々移動しながら一生懸命話しをしていました。素敵なのは「うちに来てくださいよ」という感じは一切なく普通に技術トークをしていました。 あくまで歓迎会の練習に徹していたのがすごく良かったです。これが Sm
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
採用事例の重要性
自社製品をリリースしてから、採用事例は製品の機能よりも強いというのを実感している。 実は採用事例自分はあまり重要視してはいないかった。もちろん無いよりはあったほうがいいだろうとは思っていたので採用事例「なし」の場合は「あり」よりも価格が高くなるという仕組みだけ考えた。 採用事例公開できる場合は 60 万円採用事例公開ができない場合は 84 万円採用事例が公開できない場合は多めにお金がもらえると嬉しい、その程度の考えだった。 採用事例が何よりも重要そんな中、採用事例が何よりも重要という考えを打ち出したのは一人の社員だ。 その社員が採用事例を重要視した第一の理由は顧客は採用事例をみて、自分たちがやりたいことと似ている事例を探し、この製品を買えばいいのかどうかを判断するという考えだ。 この考えは的中した。打ち合わせや問い合わせで「〜という感じで使いたい」が採用事例の中から選ばれる事が多かった。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
