FFmpegの基本的な使い方 | NM Maxのブログ
FFmpegで、動画から音声のみ抜き出すとか、一部切り出しを良く行っていた 今日、将棋の動画を撮っていて、途中で通信エラーになった部分を除いて(対戦中2度発生)みて、その手順を動画にしてみようと思い、このシリーズ作りました。 公式マニュアル https://ffmpeg.org/ffmpeg.html 公式フィルター関係 https://ffmpeg.org/ffmpeg-filters.html ネット検索するなら、「ffmpeg やりたいこと」でネット検索すれば、すぐ調べれる。ただ、昔のバージョンだけでしか使えない記述方法があったりして、最新のffmpegだと使えないケースあるので、公式サイトの文書や配布物に含まれる文書で確認した方が安全 wiki https://trac.ffmpeg.org/wiki/で興味深い項目 FFmpeg Filtering Guide https://t
HTTP | MDN
HTTP Guides Resources and URIs Identifying resources on the Web Data URLs Introduction to MIME types Common MIME types Choosing between www and non-www URLs HTTP guide Basics of HTTP Overview of HTTP Evolution of HTTP HTTP Messages A typical HTTP session Connection management in HTTP/1.x Protocol upgrade mechanism HTTP security Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-
The Rust Programming Language 日本語版 - The Rust Programming Language 日本語版
The Rust Programming Language 日本語版 著：Steve Klabnik、Carol Nichols、貢献：Rustコミュニティ このテキストのこの版ではRust 1.58（2022年1月13日リリース）かそれ以降が使われていることを前提にしています。 Rustをインストールしたりアップデートしたりするには第1章の「インストール」節を読んでください。 HTML版はhttps://doc.rust-lang.org/stable/book/で公開されています。 オフラインのときは、rustupでインストールしたRustを使ってrustup docs --bookで開けます。 訳注：日本語のHTML版はhttps://doc.rust-jp.rs/book-ja/で公開されています。 rustupを使ってオフラインで読むことはできません。 また、コミュニティによるい
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
開発ドキュメントの書き方！9つのコツ【エンジニア】
文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し
信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤
このページについて この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。 muziyoshiz.hatenablog.com 想定する環境 この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント（仕様書や手順書など）を書けるようになっている環境を想定しています。 私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。 ルール：「更新され続ける」ページと「更新されない」ページをはっきり分ける ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、こ
ドキュメント作成時のあるあるアンチパターン20 - Qiita
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テクニカルライティングの基本