時雨堂は Sphinx の開発者である小宮健氏のプラチナスポンサーになりました
追記GitHub Sponsors で組織がスポンサーになれるようになったため、個人アカウントから組織アカウントへ切り替えました。 月 500 ドルなぜスポンサーになったのか時雨堂では自社製品のすべてのウェブドキュメントに Sphinx を利用しています。そのため Sphinx を継続的な開発を少しでもやりやすくしてもらえるようにスポンサーになりました。 個人としても Sphinx は利用させてもらっており、今まで小宮氏への個人的なスポンサーにはなっていました。 ただ今後も Sphinx を自社製品のドキュメントとして使い続けたいという思いから、企業としてメインの開発者である小宮氏への継続的なスポンサーになるべきだと判断しました。 時雨堂がスポンサーになっている開発者Cowboy や Gun の開発者である Loïc Hoguin 氏Blend2D や AsmJit の開発者である Pet
How Microsoft Is Adopting Rust
Microsoft has one of the largest C/C++ codebases in the world. All of its core products from Windows and Office to the Azure cloud run on it. Unsurprisingly, since C++ is not a memory-safe language, a lot of memory bugs popup in their codebase, and a lot of time has to be spent fixing them. Last year, Microsoft began looking at alternative programming languages that could help fix their memory saf
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
TCPが遅すぎる？QUICを使おう！
「それ、QUIC使えないの？」 それがなんであれ、QUICを使うことを主張することで、みんなが「なんか良くわからないけど、TCPを置き換えたほうがいいのかな？」と思うようになるはず。全てのアプリケーションを、TCPの代わりにQUICを使うように修正するとなれば、この先10年間ぐらい、エンジニアみんなの仕事を作ることができます。業界愛ですね。 すでに、SSHやDNSのQUIC対応は始められています。既存のアプリケーションをQUICに対応させる難しさを調査するために、RustでBGP over QUICを実装してみました。 QUICの実装QUICは、TCPと同じく、パケットの再送、輻輳制御など、信頼性のある通信を実現するトランスポートプロトコルです。実装面の大きな違いは、TCPがオペレーティングシステムのプロトコルスタックの一機能として実装されるのに対して、QUICはアプリケーションで実装され
Linuxのネットワークスタックが遅すぎる？RustとXDPでパケット処理！
「Linuxのネットワークスタックが遅すぎる！」 詳細はわかりませんが、すごくエンジニアステージが高そうですね！ネットワークスタックの高速化は多くの前例があり、中途半端に試すと、周辺の詳しい人に一晩中、指導をうけるはめになりかねません。前例のないRustなら安心です。 典型的な高速化手法広く使われている高速化手法は、オペレーティングシステムのプロトコルスタックを使わずに、サーバアプリケーションが直接、NICにアクセスして、パケットを処理するというものです。Linuxの上で、FreeBSDのプロトコルスタックとサーバアプリケーションを統合するという、謎の組み合わせを運用しているクラウド事業者もいます。 上記の高速化手法のポイントの一つが、アプリケーションが、高速に、NICにアクセスするための手法です。たくさん提案されてきましたが、今回は、現在、人気があるXDPを使うことにします。聞いたことが
抱歉您搞錯了，這不僅僅是版權問題
補充資料： 2020.3.17 文章の最後に日本語訳つきバージョンを更新しました、シェア歓迎です！ 2020.3.17 補上日文翻譯在最下方，歡迎轉載分享！ 2020.7.7 收到京都精華大學來信，說明在重新調查後，認定確實有使用「金萱」字型中的部分內容並挪用到「錦黑體」的製作中。校方與指導教授道歉，並說明本案處置情況；同時於校方網頁中公開致歉，https://www.kyoto-seika.ac.jp/news/2020/0707.html 2020.9.3 因仍有朋友關注此事，還是有公開這份聲明的必要，在此補上校方道歉全文（連結）上週剛忙完「jf open 粉圓」的開源計畫（https://justfont.com/huninn/），同一個時間，也不得去處理一些很不想處理的事情。 這是一封我回信給日本某大學的信件： 致 某貴校：一直以來，日本對於字型設計的尊重，是一直是我們欽羨的對象，
「謎水事件」日本システム企画の社長・熊野活行さんの謎のミャンマー事案について
その日本システム企画社の会社概要が、なぜか404 Page Not Foundになってしまうという残念な事態に陥っております。 意味が分かりません。 http://www.jspkk.co.jp/company/company.html もちろんですが、日本システム企画社が展開していたサイトはすべてpdfで確保済みで、また、魚拓を確保しておりますのでご安心ください。 http://web.archive.org/web/20190908002336/http://www.jspkk.co.jp/company/company.html NMRパイプテクターについて、サイトに掲載されていたやや荒唐無稽な雰囲気の技術的な説明もすべて確保していますが、NMRパイプテクターの営業が今日も来ているそうで、北海道支店の支店長・松下博之さんの話はご退職者からたくさん聞いてきました。割り切って営業ができる
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
Undefined というバンドは解散しました。そしてセレモニーは開かれる。
2019年5月頭、Undefined の僕を除く全てのメンバーが会社を去ることになった。それは、創業メンバーの健嗣、かにちゃん、そして唯一のフルタイムエンジニアであった平川の三人だ。事実上、Undefined のチームは解散することになった。僕はこのことを今でも強く覚えているし、きっとこれからの人生においても大きな出来事になるのだと思う。果たしてそれを上手に文章に書き起こすことができるか解らないが、完璧な文章など存在しないから、僕は筆を取る。 NYAGO をリリースしたのは、2018年の3月末だ。沸くTwitter、止まらないダウンロード、僕たちは文字通り浮かれていた。自分たちのつくったサービスが評価され、知人や友人を始め、全く知らない人まで NYAGO を使っていた。世界が色鮮やかに見えて、張り切って早朝に出社して深夜まで残った。それでも様々な事情があって、 NYAGO は一週間でクロー
G Suite x Zendesk API で問い合わせの分析・可視化ツールを作ってみた
システムの全体像はじめにZendesk はヘルプページを作ったりユーザーからの問い合わせにメールやチャットベースで答えられるカスタマーサポートのためのサービスです。 弊社では Zendesk を利用しており、サービス改善のために問い合わせの内容を閲覧・分析しています。カスタマーサポートを業務で行わないが、プロダクト改善をしたい社内メンバー向けに、Zendesk API をたたいて可視化・分析する仕組みを G Suite で作ってみました。 Zendesk に限らず、外部サービスで API が用意されているものでしたら同様に可視化・分析の仕組みを作れるので参考にしてみてください。 できたものダッシュボードWeekly と Monthly の問い合わせ件数を Data Studio で可視化しています。問い合わせのタグや文言で絞り込みができます。 DataStudio によるダッシュボード問い
どう考えてもマネージャなんて不要だからそれで上手くいくなんて期待しない方がいい
色んなマネージャがいる。何をやる仕事だろうか？役に立ってる？要らないだろ？って話をまとめたい。 チームを助けるどうやって？1on1でお互いの理解を深めていく？ 皆さん知らないかもしれないが、この世界は実は、売上とそれを支える進捗が救いなんだ。進捗の源泉はアーキテクチャでありドメインモデリングでありシステム設計者だ。マネージャではない。 経営方針を伝えるそんなもん、直で伝える方が絶対にいい。伝え方が上手くないならなおさらだよ、早めに経験値を稼ごう。 チームメンバはでかいビジョンは理解してるけど、具体的なアクションが見えないかもしれない。伝わってるか否かを観察して、次はもっと上手くやろう。マネージャの出る幕はない。 人事評価をする人事評価はお互いの納得が最低条件であり、丁寧にやらないといけない。マネージャは納得させることができるだろうか？ 元エンジニアのマネージャなら、しばらくは保つかもね。で
Twitter就活でソフトウェアエンジニアになって２年が経った - Takeshi Yoneda - Medium
右も左も分からなかったけど、第一線で活躍するバックエンドエンジニアになれそうな気がしてきた はじめにこんにちは。@mathetake です。先日以下のようなツイートをしたので、有限実行ということでいろいろ書こうと思います。(ちょっと遅くなってすみません) 2017年3月に修士号を取得後ソフトウェアエンジニアとして働き始め、早いもので二年が経ってしまいました。そのきっかけとなったのは、今となってはなんの目新しさもなくなってしまったTwitter就活なんですが、そのフックとなった当時の僕のブログは、過去との決別ということで閉鎖しました。なので改めてここに「当時の経緯」と、それだけでなく「２年間の振り返り」「ウェブアプリケーションと機械学習」「キャリア観と俺流生存戦略」についてつらつらと書いていきたいと思います。 宣伝本題に入る前に宣伝なんですが、会社の同僚と執筆した機械学習関連の本が出版されま
自分がGoogleに入った時の話
自分がGoogleに入った時の話 はじめてこの社名を知ったのは、高校生の時。自他共に認めるパソコンオタクだったぼくは書店で月刊アスキーを立ち読みしていた。そこで、新しく登場した検索サービスについて丸々1ページ使って紹介されていた。その速さの秘密は、インターネット全体をメモリに載せて処理をしているかららしい。信じられない量のメモリを持っている謎の会社。それがGoogleをはじめて知った瞬間だった。 大学は東大に進んだ。志望した主な理由はお金がある大学だと聞いたから。なぜお金が大事か？それはお金がないと速いコンピュータが買えないから。高性能なコンピュータが使いたかった。幸い無事に入学でき、その後無事に志望していた理学部情報科学科に進学した。そこには数百台程度のクラスタがあって、それらを使って友人らとオセロのAIの開発を競った。なぜそんなことを熱心にやっていたのか正直わからない。自分にとっては小
Web 技術をキャリアの中心にしない
うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その
コンビニの雑誌は売れないのではなく邪魔な存在
AUGM鹿児島2018に、じゃんけんマスターとして参加し、翌日、山形屋食堂で名物の固焼きそばを食べている時に、イベントの主催者とコンビニ話しが話題になった。 昔、コンビニエンスストアは、オープン時は、セブン-イレブン、ローソン、ファミリーマートの名前で呼ばれるが、３年が経過すると「コンビニ」という一般名称の店舗に変わり、お客の中の差異はなくなるため、同じメニューやサービスを提供しなければならないという同位競争という珍しい争いが起こることを教えてもらい、かなり勉強になったことがあった。 話しのきっかけは「コンビニでも雑誌は売れなくなっているのか？」という質問だったのだが、実は、コンビニの雑誌は売れないのでなく「邪魔な存在」などだということだった。 セブン-イレブンが何度も挑戦しては失敗してきた「SEVEN CAFÉ」を2013年にヒットさせると、すでに軌道に乗せていたローソンやファミリーマー
ドキュメントを残さない
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
タベリー | とある仕様書 – Yamotty – Medium
グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口
REST is the new SOAP
Written by Pascal Chambon, reviewed by Raphaël Gomès Update: this article mostly deals with the RESTish ecosystem, which now constitutes a major part of webservices. For more in-depth analysis of the original REST, and of HATEOAS, see my follow-up article. How come REST means so much WORK? This is both a paradox, and a shameless pun. Let’s dive further into the artificial problems born from this d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
漫画村と株式会社ファンコミュニケーションズの関係 – mangamurawatch – Medium
not found