GitHub Enterprise Cloudと GitHub Copilot Enterprise に切り替えた
GitHub Team と GitHub Copilot Business から切り替えました。切り替えた理由は GitHub Copilot Enterprise を利用したいという一点です。 雑にまとめを書いてみます。 GitHub の金額 (月契約)GitHub Team は 1 アカウント月 4 ドルGitHub Enterprise Cloud は 1 アカウント月 21 ドル約 5 倍のアップです。GitHub Actions の無料枠が 3000 分から 50000 分になるのは良いです。SSO もそのうち使ってみようと思います。 https://github.com/pricing#compare-featureshttps://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-en
WebRTC と認証付き HTTP Proxy
WebRTC 利用時に認証付き HTTP Proxy を超える話をサクッと話せる人はそうそういないと思います。そもそも情報もほとんどないので、いい機会なので雑に書いておきます。 この記事を書くにあたり libwebrtc ﾁｮｯﾄﾃﾞｷﾙ tnoho より色々教えていただきました。感謝します。 まとめ世の中のブラウザ以外の WebRTC ライブラリは非対応が多いHTTP Proxy (CONNECT メソッド) + TURN-TCP / TURN-TLSPAC ファイル死すべし認証付き HTTP Proxyそもそも認証付き HTTP Proxy についての詳細な説明はここではしませんので以下をお読みください。 https://developer.mozilla.org/ja/docs/Web/HTTP/Proxy_servers_and_tunnelinghttps://developer
お手伝い先でやったこと、やってること
2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止（好み問題）可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対
WebTransport
WebRTC QUIC Client/Server が WebTransport として再出発したようなのでまとめておく。 一般的な説明についてはいかが詳しいので以下を読むのをおすすめしたい。
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 系の零細企業を経営して、自社製品を開発し販売しているとその分野でリソースが潤沢な会社と競合してしまう事があります。そんな時どうしているのか、自分のやっている事や考えを書き出しました。乱文です。 ちなみに調達はしていない前提です。 結論競合が撤退するまで、その市場に残り続けるです。もちろんそこまでしてその分野に残り続けたいのかどうかは会社の方針になると思います。 ここでは残り続けるという方針前提で書いていきます。 他で売上を確保する競合に圧倒されてその市場から自社が撤退する場合の殆どは売上がうまく出せなく事がほとんどだと思います。 であれば、その市場で売上を上げるというのを一旦諦めるという戦略を取るのが良いです。そのかわり他の市場で売上を確保するという方針です。 自社の場合は自社製品以外に２本の売上の軸をもっています。 開発でお手伝いコンサルでお手伝い開発でお手伝いはなにか作りたい人に
集中力のない人の戦略
集中力がないといろいろなところで苦労します。とりわけ苦労したのが学校です。学校では決められた時間で学ぶ授業、決められた時間で問題を解き結果を出す試験があります。これが本当に集中力のない自分には地獄でした。とにかく決められた時間で何かをするというのがとても苦手でした。 恐ろしいほど集中力がなく、決められた時間の中で結果を出すことができない自分がどうやって仕事をしているのかという話を書いてきます。 ダラダラ継続する結論を先にいうと「人の何倍も時間をかけて、常に変化する分野ピンポイントにダラダラと継続する」という戦略を取ることにしました。 継続といえばカッコイイですが所詮は「ダラダラ」です。つまり気分が乗ったときだけダラダラとやっていきます。 ただ、ダラダラやるのも１年、５年、１０年と続ければ結果は出ます、多分。 また、常に変化する分野であれば集中力よりも、継続が求められるはずだとも考えました。
同時接続 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 を学び始めた頃にはすでにありまし
売上の座布団を増やす
受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス（BPStudy発表時の補足） - ヴェルク - IT起業の記録 以前からブログで「受託と自社サービスの両立の取り組み」を書いてきましたが、ついに、2017年11月1日に board の有料アカウントが1000社を突破しました！ ... 田向さんが使われている「売上の座布団」というのは受託をしている場合に、売上の底上げをするため納品の有無にかかわらず毎月請求できるなにかというものです。 この売上の座布団を取りに行く戦略はとても手堅い経営だと感じました。当たり前かもしれませんが、保守費用を請求できるビジネスは顧客が IT 系の技術に詳しくないパターンが多いです。 そもそも詳しい場合は自社で運用できてしまうので保守費用が発生することはありません。 IT 系の技術に詳しくない顧客とのやりとりは
経営者になってわかったこと
起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資本金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな
カスタマイズしないとどうなるか
続き。自社製品のミドルウェアでカスタマイズをしないと実際にどうなるかを書いていく。 カスタマイズの相談をされた場合一切対応していない事を伝える。メールが返ってこない事が多い。そのためビジネスチャンスを逃している可能性は高いが、カスタマイズをするリスクのほうが高いため問題ない。 カスタマイズを要求していくる会社から相手にされなくなる。 注文から提供までメールにて申込書を送り、記載して返送してもらう総務が社内に立っているライセンスサーバでライセンスを発行する製品のダウンロード URL とライセンスファイルをメールで送る終わり。製品の提供まで 30 分くらい。自社製品は最小ライセンスの費用が 60 万円/年なので 30 分で 60 万円の売上になる。これが毎年。 この後はサポートのお仕事。 サポート対応全ての顧客が同じ製品を利用しており、自社製品は最新版を利用していることがサポートを受ける前提と
IT 系零細企業は何に投資すべきか
正社員 5 人未満の IT 系零細企業を経営して 5 年たったので、何に投資して、何に投資しなかったかを振り返る事にした。 それぞれの会社で色々あるだろうから、これはあくまで自社がこうした、こうしているという話である。それ以上の意味はない。 投資すべき事社員の給与何よりも社員の給与が一番の投資先。人は一定額以上の給与を貰っていれば労働に対するモチベーションが下がりにくくなる。 何よりお金はあって困らない、そして無いと困る。 もちろん会社が儲かっている前提。自社は月給と賞与の比率が 3:7 くらいで賞与が多い。そのため、会社が儲かったら賞与を沢山だす。とにかく税理士と総務に「社員に賞与出しすぎです、この辺でお願いします（実話）」って言われるくらいまで出す。 そのかわり会社が貧乏な時は賞与は一切ださない、というか出せない。ここを理解した前提で入社してもらってる。 とにかく会社に多めに残すくらい
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 に変換してくれるので、スケーラビリティを気にする必要はない。もちろん
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。
Kranky Geek WebRTC Show 2017
サンフランシスコでやっている WebRTC のおそらく世界で一番大きなイベントが 10 月 27 日にありました。 雑感基本的にざーっと見ていただけなのであまりしっかり見ていないので間違ってるところもあるかも。 WebRTC を軸にしたサービスを提供していくのは OSS は使わず、自前で作るという流れな印象。Vidyo,Tokbox, Twilio, Atlassian, Facebook, Slack, Appear.in は全て自前 SFU 。 また機械学習で WebRTC に対してプラスアルファで差別化を頑張ってる印象。AR/VR だったり物体判定だったり、IoT だったり、翻訳だったり。 FacebookFacebook Messenger は WebRTC を利用していて、シグナリングには MQTT を利用している。 P2P とSFU 両方を利用している。P2P は 1:1 のみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP API の設計方向
WebRTC からみた SRT
WebRTC スタック Python 実装の紹介