Lily Maraと信頼性の高いKafkaデータ処理パイプラインを構築する 今日の回では、Thomas Betts氏がカリフォルニア州サンマテオにあるOneSignalのエンジニアリングマネージャー、Lily Mara氏に話を聞いた。 彼女は、OneSignalの他のエンジニアリングチームが使用する社内サービスを担当するインフラサービスチームを管理している。信頼性の高いKafkaデータ処理パイプラインの構築方法について議論する。OneSignalは、RustのKafka...
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru
オープンソースやテクノロジーを中心としたコミュニティの維持や発展を支援する組織「Open Collective」は、Web技術のドキュメント化を長期的に支援する取り組みとして「Open Web Docs」を発表しました。 Open Web Docsはおもに既存のコミュニティによるドキュメント、特にMozillaのMDNをまずは優先的に支援するとしています。 We’re happy and proud to announce Open Web Docs, to support a community of technical writers around creation and long-term maintenance of web platform technology documentation that is open and inclusive for all.https://t
Kubernetes (K8s)は、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、オープンソースのシステムです。管理や検出を容易にするため、アプリケーションを論理的な単位に分割し、コンテナをグルーピングします。KubernetesはGoogleでの15年にわたる経験を基に構築されており、コミュニティのアイディアや慣習との最善の組み合わせを取っています。 惑星規模のスケーリングGoogleが週に何十億ものコンテナを実行することを可能としているのと同じ原則に沿ってデザインされているため、Kubernetesは運用チームの人数を増やさずに規模を拡大することができます。 いつまでも使えるローカルのテストであろうとグローバル企業での開発であろうと、Kubernetesの柔軟性はあなたの要求がどれだけ複雑になろうとも問題なく、矛盾無く、簡単にアプリケーシ
AWSの各種サービスやSDKのドキュメントがオープンソースとしてGitHubに公開。誰でもコントリビュートや再利用が可能に Today we are adding over 138 additional developer and user guides to the organization, and we are looking forward to receiving your requests. You can fix bugs, improve code samples (or submit new ones), add detail, and rewrite sentences and paragraphs in the interest of accuracy or clarity. 今日、私たちは138以上のデベロッパーガイドとユーザーガイドを追加し、みなさんの要望を心待ち
はじめに こんにちは植木和樹@上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 (この記事を読むのにかかる時間の目安:5分) 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
Velocity gives your Windows desktop offline access to over 150 API documentation sets (provided by Dash for OS X) Download Buy Now A Huge Documentation Library Over 150+ API documentation sets are available in Velocity covering some of the most popular languages and API frameworks that you use for everyday development. If you've every seen or used Dash on the Mac then you have a good idea of what
はじめに こんにちは。Sphinx Advent Calendar 2012 の4日目のエントリです。@tk0miyaより受け取りました。 Sphinx を使い始めてまだ日が浅いですが実際に仕事で使ってみてすばらしいツールだと今更ながら気づき、Sphinx に特化したエントリというよりも Sphinx + blogckdiag を使って仕事に使えるダイアグラムの表現方法についてご紹介します。 非プログラマでも簡単に作成ができ修正も簡単、イライラしないでサクサクと図が書けます。 ソフトウェア開発プロジェクトで作成されるドキュメント(特にマニュアルで利用)は顧客に説明するための図解を多用します。これまでの経験で Word/Excel の描画ツールをつかってがんばって作った図 調整と編集がとても大変 Visio を使ってわかりやすく綺麗に作成されているが、Word/Excel/PowerPoi
Twitter で知人に紹介したら周囲から「これは便利」という声が結構聞こえてきたので、ブログでも紹介しておこう。Dash というドキュメントビューワー。 iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。 本来 Dash は "Snippet Manager" ということで、コードスニペットを管理するためのアプリケーションのようだけど自分は単なるドキュメントビューワーとしてしか使っていない。RubyMotion の勉強会に行ったときに、これが便利というのを教えてもらってその後愛用しています。主に iOS の開発のときに利用していた。 http://satococoa.github.com/blog/2013/01/22/view-rdoc-
ブロック図生成ツール blockdiag¶ blockdiag シリーズはシンプルなテキストからブロック図などの画像を生成する画像生成ツール群です。 blockdiag を用いると以下のような図が簡単に生成できます。 blockdiag の主な機能: 数種類の図に対応 ブロック図 (blockdiag コマンド) シーケンス図 (seqdiag コマンド) アクティビティ図 (actdiag コマンド) 論理ネットワーク図 (nwdiag コマンド) テキストベースの定義ファイルから画像ファイルを生成 (graphviz 風の文法を採用) 定義にあわせて図の配置を自動的に決定 (自動レイアウト) Sphinx, Trac, Redmine, 各種 Wiki エンジン等、多様なシステムへの画像埋め込みに対応 Enjoy documentation with blockdiag !
アジャイル開発におけるドキュメンテーションの実際(1) ―― 本当に必要ですか? そのドキュメント 細谷 泰夫 要求仕様書や設計書から取り扱い説明書(マニュアル)まで,システム開発ではさまざまなドキュメント(文書)を作成する必要がある.特に,ウォータ・フォール・プロセスによる開発の場合は,各開発工程においてドキュメントを作成し,それを次工程に引き継ぐことになる.それでは,分析 - 設計 - 実装 - テストを繰り返しながらスパイラルに開発を進めるアジャイル開発の場合は,どのようなドキュメントをどのように作成しているのだろうか? 本連載では,アジャイル開発とウォータ・フォール開発の両方を経験している筆者が,アジャイル開発におけるドキュメントの位置づけや作成方法について解説する.(編集部) 「アジャイル開発注1ではドキュメント(文書)は作らない」と思っておられる方も多いのではないでしょうか.「
自分がNode.js でプログラミングをする際に、必ず参考にするページがあります。それは Node.js の公式ドキュメントです。 Node.js v0.8.12 Manual & Documentation バージョンアップにも追随して、最新の情報が得られるので、書いている人には頭が上がりません。情報量も十分です。(たまに空っぽのページとかありますが) ただ、このドキュメントを見たことある人ならわかると思いますが、すごく見難いのです。より具体的にはナビゲーションが良くないのと、検索がない、という2つの難点を抱えています。 というわけで、この問題を解決する Document Viewer を作りました。 名付けて 「YAND」=「Yet Another Node.js Document Viewer」です。 Yet Another Node.js Document Viewer [追記]
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く