なぜ Zig の採用を検討しているのか
かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er
企業 OSS を継続開発するためにやっていること
時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発
食べていけてる時は無理に稼がない
ありがたいことに自社製品が多くの企業に導入して頂けており、自社製品の売上だけで食べていけるようになりました。 今までは自社製品だけでは食べていけなかったため、外のお手伝いをしていました。ただ自社製品だけで食べていけるようになったのは経営者としてはじめてなので、どうしてみてるかを書いていきます。 会社の状況従業員たちの給与と会社の維持にかかる費用はすでに自社製品の売上で十分まかなえています。普通に賞与も出せるレベルです。 自社製品はパッケージ製品のため、運用などはありません。労働時間は 6 時間の定時労働、土日祝日、年末年始はお休みです。残業はお手伝い系の仕事が忙しくなるとありますが、自社製品に関しては皆無です。 パッケージ製品の開発方針機能より品質重視という方針をとっています。またカスタマイズは受けていません。そのため、自社製品に関しては顧客との調整などは発生しません。サポートの問い合わせ
リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
pixiv TECH SALON に行ってきた
FAVORITE が Erlang/OTP なのは自分ひとりだったそうです。アイコンすみません手間かけて。 発表の感想技術発表を楽しみにしていったのですが、すべての発表がとても洗練されており、楽しかったです。メモとかは特にとっていないので間違っていたら申し訳ないです。 ピクシブ流データ活用基盤のこれまでとこれからBQ をガシガシ使ってる話かと思いきや、横断的な解析チームを持たないと言う話がとても良かった。チームごとに解析できることが大事。 チーム単位での解析を実現したのは slack にチャネルを作っただけ、あとはうまくいったと言う話を聞いて、これこそ pixiv の文化がうまく根付いているということなんだろうと聞いてて感じた。 あるものをうまく使い、文化にマッチさせ、データを上手く使っているのがとても良かった。 pixivのおすすめを改善する話難しい話か？と思ったらとてもわかりやすく解説
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 で利用可能な
Chrome Canary M70 でScreen Capture API 利用できるようになった
Chrome では今までスクリーンキャプチャ機能を利用するには Chrome 拡張が必要でした。ただ、かなりの手間がかかるうえ、最近ではインラインインストールができなくなったこともあり、かなり不便になっていました。 ただ、Chrome は Screen Capture API を実装すると 2018 年 6 月に発表していました。その後は音沙汰がなかったのですが、先程実装されたという発表がメーリングリストに流れていましたので、試してみました。 以下を Chrome Canary 70.0.3532.6 以上で console にて叩きここんでください。 navigator.getDisplayMedia({audio: false, video: true}) .then(stream => { let videoTracks = stream.getVideoTracks(); cons
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
経営者になってわかったこと
起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資本金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな
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 の仕様になっている。
リモートワーカー達との働き方
最近リモートワークな人とお仕事をする事が多い。自分がプロジェクトマネージャー的に働くことが多いので、リモートワークで働いている人がどうしてくれると自分が楽かということを書き出してみることにした。 殴り書きなので、読みづらいと思う。 ２つのタイプの案件でリモートワーカー達とやりとりしているので、わけて書き出す。 外貨稼ぎ案件外貨稼ぎ（社外のお手伝いをしてお金を稼ぐ）は自分がプロジェクトマネージャーとしてリードして、社外のお手伝い二名が開発担当として入ってくれている。 連絡はすべて Slack でのみ行う情報共有は Slack と GitHub で行うフェーズに分けて進捗管理完全非同期で労働するタイミングは縛っていないQA は GitHub で Markdown で質問してもらうお手伝い二人共技術的には申し分がない仕事は開発案件で、顧客とのやりとりは全て自分がやっており、お手伝いしてくれている
YouTube が WebRTC 配信に対応した
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 に変換してくれるので、スケーラビリティを気にする必要はない。もちろん
時雨堂 2017 年振り返り
今年 1 年を振り返ってみた。時雨堂とはなんぞやという人は時雨堂コトハジメでも読んでみていただければ。 これは、スタートアップではない、台東区にある小さな IT 会社の振り返りです。 自社製品が売れ始めたリコー様の導入を皮切りに、スクウェアエニックス様、ソフトバンク様といった大手企業に導入されたり、pixiv 様やタイトー様のようなお絵かき配信やネットクレーンなどに採用されたりと、できすぎたくらい採用していただいた。他にも事例公開ができないお客様も含め、多くのお客様に採用していただいたのは本当に感慨深い。 個人的にはフロンティアリンク様の開発担当者とお会い出来たことがとても嬉しかった。自社製品を社長が反対した中、ゴリ押しで採用してくれたとのことだった。本当にありがたい。 製品を購入いただいた方はほぼウェブサイトを見てからの問い合わせで、評価版を 1 ヶ月触っていただいて採用していただいたこ
AV1 の未来が開いた – V – Medium
今、よく使われているビデオコーデックといえば H.264 でしょう。ただ H.264 は最先端の技術とはいえません。今後は H.265 に切り替わっていくかと思われましたが、H.265 はパテントがとても複雑です。そのため広がっていくとは思いにくいです。 そんな中、H.265 のパテントの闇に取り込まれないようにするための光が AV1 です。
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。 配信の場合は P2P で Web
Rust と Erlang
Erlang/OTP は仕事でずーっと書いているので、仕事ではまだ使えるレベルでは全然ない。 とにかく Rust のドキュメントを読んだりソースコードを読んだりしている。 最近は MQTT の実装が Rust で色々落ちているので、それを読んだり写経したり、色々上手くぱくって実装したりしている。 時雨堂 CTO の szktty が Rust を以前勉強してくれていたので、 Slack に Rust チャンネルを作ってマンツーマンで教えて貰っている。やはりわからない事を聞いているのが気軽に聞ける環境はありがたい。 よく使ってきた言語が Python と Erlang/OTP というあまあまな人なので、 Rust のような静的型推論言語は正直よくわからない。 さらに、GC 前提のコードばかり書いてきているので、 Rust のように GC が無い言語は久々だ。 普段 Erlang ばかり書いて
値下げをしない
自分の方針としてもう一つ。値下げに応じないというのがある。 製品を売っていれば一度はかならず顧客から「料金交渉をお願いしたい」という名の値下げ交渉をされることがあるだろう。その場合は値下げは一切しないことを伝える。 もし値下げを粘られた場合は取引をしないほうが良い。また、値下げを一度でもしてしまうと、交渉さえすれば値下げをしてくれる会社と勝手に認識されてしまう。 顧客ごとの料金表は提供しないほうが良い。なぜなら世間は狭い。あの会社にはこの料金でだしているのに、なんてめんどくさい話も出てくる。 そのため、自分はすべての顧客に同一な料金表の提示。そして大量購入による割引。これ以上のことは一切やらない。顧客は相談はできず選択しかできない。 自分の会社の料金体系に合わない顧客とは取引をしないという方針を取っている。無理に値引きするのはその製品の寿命を縮めてしまう上に、会社の寿命も縮めてしまうと思う
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 はかなりの差があるというのを最近調べていて気づきました。 ということでインターネッツのちからを使って募集してみることにしました。この記事を読んだ人も是非お時間あれば、気軽にコメントして
自分が考えるテックリード
このエントリがとても素敵だったので。自分が考えるテックリードの役割を書いてみることにした。個人の意見なうえに、自分自身がテックリードという職を経験したことないので、完全に妄想である。 自分はコードを書くプロダクトマネージャー、たぶん。 テックリードの条件積極的にチャレンジできる困ってる人を技術力で助けられるチームの成功を意識して行動できる技術力のある雑用。コードをゴリゴリ書いて解決というイメージではない。それよりも自分の担当範囲は粛々とこなしつつ、他のメンバーが困ってる所を助ける。さらに、ボトルネックになりそうなところを早めに潰して回る。 テックリードと言う素敵な名前だけれど、むしろ裏方。 技術力をつけるためには、そのための努力は惜しまない。その技術は自分のためというよりもチームのため、チームが成功するために他の人をサポートするために使う。サポートするためには自分のタスクを早めに終わらせる
WebRTC サーバを開発する理由
ブラウザ同士がやりとりする WebRTC 、当たり前だが WebRTC をサーバ側に用意することでブラウザとサーバでのやりとりを実現する事ができる。 理由はたった一つでサーバ側で配信データをコントロールすることが出来るようになるからだ。 通常の WebRTC を使って一人が複数人に配信する場合はこうなる 大きく違うのはサーバがブラウザを管理したり、データの流れを管理できるようになることだ。これはニコニコ動画の生放送をイメージして貰えば良いと思う。 もちろんサーバを経由することでサーバ側での録画も可能になる。もともとクライアント側で録画はできたが、P2P で動作されるとサーバ側での録画は難しくなるからだ。 これらの仕組みをプラットフォームとして提供しているのが tokbox だ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
