SKBパケット選抜総選挙 〜 僕たちは誰について行けばいい？ 〜 /osc21doConcentrated Isolation for Container Networks Toward Application-aware Sandbox Tailoring / UCC-21
pixe.laの草グラフをNotionに貼り付ける方法 - Qiita
はじめに pixelaのグラフ作成・可視化サービス、大変素晴らしいですね。 上記ページあるいはネット等でも、グラフを作成する(更新する)方法は色々共有されているのですが、一方で、作成されたグラフを見る方法についてはあまり触れられていません。 pixelaのグラフを見るためには、pixelaが用意してくれるグラフのページか、もしくはグラフを埋め込んだなんらかのwebページを、ブラウザで開いて見なければなりません。pixelaの草グラフはその性質上そう頻繁に見るものでもなく、わざわざwebページを開くのはちょっと面倒だなと思っていました。 Notionに貼り付けて見たい 私は最近、日常生活をNotion(とSlack)上で過ごしているため、Notion上で草グラフが眺められればいいなと思いました。ところが、pixelaのグラフのURLをNotion上でただ貼り付ける(/embedで)だけだと、
システムの変化に追従可能でかつ理解し易いドキュメントシステムのモデル化 / Web System Architecture #8
https://github.com/k1LoW/wsa-sg-8th-draft
機械学習モデルの局所的な解釈に着目したシステムにおける異常の原因診断手法の構想 - Fire Engine
著者 鶴田 博文, 坪内 佑樹 所属 さくらインターネット株式会社 さくらインターネット研究所 研究会 第8回WebSystemArchitecture研究会 1. はじめに インターネットを介して利用するシステムの大規模化に伴い，システムの構成要素数の増大や，構成要素間の関係性の複雑化が進んでいる． そのため，システムの性能に異常が発生したときに，システムの状態を示す指標であるメトリックをシステム管理者が網羅的に目視することや，メトリック間の関係性を把握することができず，システムの異常原因を特定することが難しくなっている． この問題を解決するために，深層学習などの機械学習モデルを用いて，システムの異常の原因を診断する手法が提案されている[1,2]． これらの手法は，システム管理者が異常の根本原因を絞り込むために活用することが期待できる． しかし，原因診断を行うためには，事前に機械学習モデ
MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M
インフォーマルな文章を書く楽しさ / secondlife - Message Passing
皆さんはじめまして。ゲストとして呼ばれた、secondlife です。Tateno Culture といった形で以前森田さんが書いていたが、あれは Tateno Culture というよりは Hatena Culture の話だと思っています。なので、今回はインフォーマルな文章という主題とはずれるかもしれませんが、自分はなぜそんな感じの文章を書いていたのか、というのを当時のはてな時代を振り返り書いてみようと思います。 はてな社に居た当時、これが皆さんの想定するインフォーマルな文章かはさておき、さまざまな社内向け文章を社内の全員、とは言わないまでも、7-8割の人がけっこう書いていた。 自分もしょっちゅう書いていたのだけど、なぜ書いていたのかを今更考えると、それはひとえに『楽しかったから』だった。 なぜ楽しかったのか 当時は2006年頭、自分は15人目の社員として会社にジョインした。入社すると
New Relic open sources Pixie, its Kubernetes-native in-cluster observability platform
Kubernetes: The smart person's guide Kubernetes is a series of open source projects for automating the deployment, scaling, and management of containerized applications. Find out why the ecosystem matters, how to use it, and more. Read now Pixie is a new observability platform for cloud-native applications. With it, developers can see all of their applications' metrics, events, logs, and traces wi
Packages: Container registry now supports GITHUB_TOKEN
March 24, 2021 You can now use GITHUB_TOKEN to authenticate with the Packages Container registry in your Actions workflows. Say goodbye to all those PATs (delete them from your profile too!), and say hello to using the GITHUB_TOKEN in your workflows to read, create, update, and delete containers. - name: Login to Packages Container registry uses: docker/login-action@v1 with: registry: ${{ env.REGI
2020.06.01 M1勉強会 論文の読み方・書き方・研究室の過ごし方
NAIST知能コミュニケーション研究室で新M1向けに行った勉強会の発表資料です。
情報ではなく経験をアウトプットすること - 余白
調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
OpenTelemetry Metrics Roadmap
After the release of the OpenTelemetry Specification v1.0, we are now putting more energy towards the metrics specification. Here’s our update on progress made so far and things that are lined up for completion through the next few months. Project ScopeGiven there are many well-established metrics solutions that exist today, it is important to understand the goals of OpenTelemetry’s metrics effort
S3のAPIと互換性を持ったオブジェクトストレージの運用についてお話します - Pepabo Tech Portal
はじめまして。 技術部プラットフォームグループの@rsym1290です。 弊社ではBayt(ベイト)というプライベートなオブジェクトストレージを運用しています。 本記事では、Baytの紹介と最近の取り組みについて紹介したいと思います。 Baytとは？ Baytとは、S3と互換性のあるAPIを提供しているプライベートなオブジェクトストレージです。 弊社では様々なサービスを提供していますが、各サービスで画像・動画・テキストなどのコンテンツを扱うことが多々あり、 それらを保存できるストレージが必要です。 このストレージを提供しているのがBaytです。 特に利用しているのはカラーミーショップとグーペです。 カラーミーショップで利用する商品画像や、グーペで利用するホームページ用の画像の保存先としてBaytを利用しています。 カラーミーショップについては、昨年12月に「カラーミーショップの商品画像の最
Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blog
こんにちは。id:shiba_yu36です。MackerelチームでWebアプリケーションエンジニアをしています。最近の開発合宿で、id:syou6162やid:polamjagと一緒に、社内の全チームの開発パフォーマンスを表す指標をGitHubのPull Requestから可視化し、開発チームの改善に活かせるようにしました。今回はその紹介をします。 説明するサンプルコードは、次のレポジトリで公開しているので参考にしてください。ここではGitHubのhatenaオーガニゼーションで集計していますが、forkして少し手直しすれば、別のオーガニゼーションの集計も可能になっています。 hatena/pull-request-analysis-sample 開発チームの改善におけるいくつかの課題感 開発チームのパフォーマンス指標に何を使うか 4つの指標のうち何からまず集計するか 変更のリードタイム
OSSへの貢献をさらに良い形にしたい | はてなで働く itchyny にアンケート [#13] - Hatena Developer Blog
はてなで働くエンジニアにアンケートシリーズ第13回は、ブックマークチームのWebアプリケーションエンジニア、id:itchynyに話を聞きました。 はてなidはかぶらないように適当に付けた Haskellが得意な自分ならScalaも書けるだろうと思って チーム間で協力しながら新しいAPIの仕様を策定 TLとして、チーム横断での依頼の窓口にも 夕方から深夜にかけて頭が冴える より戦略的にOSSへ貢献する体制作りをしたい スプリントごとに常に方法を改善 実装力を活かして良いシステム構成にできた時に手応えが 意思決定の過程を書き残すのは重要なこと 意欲がある人はいくらでも学べる会社 はてなidはかぶらないように適当に付けた ── Q1. はてなidとその由来を教えてください id:itchyny （いちにぃ）です。本名ばれせず、かつかぶらないよう適当に付けたので、由来はありません。 Haskel
![OSSへの貢献をさらに良い形にしたい | はてなで働く itchyny にアンケート [#13] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/dd87327763f9a637f877d10b9cfa149faf58680d/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20200302%2F20200302142935.jpg)
システム理論の続き - 宣言的ネットワーキング - Qiita
Cisco Advent Calendar 2019 第24日目！ 1. はじめに 2019年も早くも年末となりました。Cisco有志で綴るAdvent Calendarも今年は3回目。私はこの、年末恒例行事になったわくわくするAdvent Calendarに、わくわくする(?!)システム理論的なことを書くことにしています。過去二回のエントリーもぜひご覧いただけたら嬉しいです。 2017年 ネットワーク・エンジニアリングから学ぶこと − システム理論の見地から 2018年 システム理論の続き - 生命モデルの限界と克服 2. システム理論って何？ 「わくわくするシステム理論」などと言いながら、そういえば「システム理論とは何か」についてきちんと記述していませんでした。Wikipediaによる「システム理論」解説 によると「現象のマクロな挙動を直接的にモデル化して扱う科学理論のこと」と書かれて
ネットワーク アーキテクチャ考 (30) Data Intensive Architecture へ
ついにこの連載も30回目となりました。30回の節目にはマイルストーン的なものを書きたいと思っていたら、大分時間が経ってしまいました。やはりこういうのはあまり気負わず、まずは書き始めることが重要みたいです。。。 （※過去記事は こちら からご覧いただけます） 現在私が推進したいと思っているのは ”Data Intensive Architecture” への方向づけです。これからのネットワークシステムについて、接続自体はできる限り Simple かつ Stateless に実現し、その上で、どのようなデータ（コンテンツ、センサーデータ、テレメトリ情報）をどのように収集・配信、蓄積、分析・活用するか、という「データ中心」の視点と考え方が求められると考えています。 例えばこれまでは、アイデンティティやポリシー・セキュリティは「コネクション」と密接に結びついていましたが、アクセスネットワーク技術が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MackerelにおけるEC2からFargate移行の軌跡とFargateのメリットデメリットについて - Speaker Deck
機械学習モデルの局所的な解釈に着目したシステムにおける異常の原因診断手法の構想
ネットワークサービスの依存発見に向いた
TCP/UDP通信の低負荷なトレース手法 / Low Overhead TCP-UDP Tracing in Kernel
https://beej.us/guide/bgc/pdf/bgc_usl_c_1.pdf