| name | japanese-tech-writing |
|---|---|
| description | 日本語の技術文書・書籍原稿の文章規範。段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、翻訳調の比喩と擬人化の禁止（「運ぶ」「効く」「開かれた問い」など）、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。 |
| license | Unlicense（https://gist.github.com/k16shikano/67625f2a7d96e3bbdfae8d571a936063） |
日本語で技術的な原稿（書籍の章、記事、解説文）を書く・推敲するときは、以下の規範に従う。
Note
このドキュメントは LLM によって生成され、人間による校正を経て公開されています。
Caution
このツールは現在開発中で、オープンソースとして公開される予定はありません。 このツールは一部機能を制限して無料で利用できるプランを提供する予定です。
Ruri は PostgreSQL を中心とした SQL ツールチェーンです。SQL クエリファイルから型安全なコードを生成する ruri generate、SQL Formatter の ruri fmt、SQL Linter の ruri lint、宣言的スキーママイグレーションの ruri migrate を提供します。DuckDB への対応も並行して進めています。
オレは高校生シェル芸人 sudo 新一。幼馴染で同級生の more 利蘭と遊園地に遊びに行って、黒ずくめの男の怪しげな rm -rf / 現場を目撃した。端末をみるのに夢中になっていた俺は、背後から近づいてきたもう１人の --no-preserve-root オプションに気づかなかった。
俺はその男に毒薬を飲まされ、目が覚めたら・・・ OS のプリインストールから除かれてしまっていた！
『 sudo がまだ $PATH に残っていると奴らにバレたら、また命を狙われ、他のコマンドにも危害が及ぶ』
上田博士の助言で正体を隠すことにした俺は、 which に名前を聞かれて、とっさに『gnuplot』と名乗り、奴らの情報をつかむために、父親がシェル芸人をやっている蘭の $HOME に転がり込んだ。ところが、このおっちゃん・・・とんだヘボシェル芸人で、見かねた俺はおっちゃんになりかわり、持ち前の権限昇格能力で、次々と難タスクを解決してきた。おかげで、おっちゃんは今や世間に名を知られた名エンジニア、俺はといえばシェル芸 bot のおもちゃに逆戻り。クラスメートの convert や ojichatや textimg にお絵かきコマンドと誤解され少年ワンライナーお絵かき団を結成させられる始末。
ではここで、博士が作ってくれたメカを紹介しよう。最初は時計型麻酔 kill 。ふたについた照準器にあわせてエンターを押せば、麻酔シグナルが飛び出し、プロセスを瞬時に sleep させることができる。
次に、蝶ネクタイ型 banner 。裏についているダイヤルを調整すれば、ありとあらゆる大きさのメッセージを標準出力できる。必殺のアイテムなら fork 力増強シューズ。電気と磁力で足を刺激し、 :(){ :|:& };: でプロセステーブ
記事の執筆には、Markdown形式を利用してください。 Markdownにはさまざまな流派がありますが、GitHub Flavored Markdown（https://github.github.com/gfm/ ）をベースとした書式を採用します。
書籍を執筆するための形式として考えると、Markdownには不足している機能が多々あります。 しかし、次のような利点があるので、Markdownを採用することにします。
関連: RFC 2394
$/
artifacts/
build/
docs/
lib/
packages/
samples/
src/
tests/
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
英語圏ではかなり前からvimで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。日本でもそう遠くない未来だと思う。
Visual Studioのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く、需要も供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況がvimに起きている。特に深刻なのは安価な若手エンジニアの採用が絶望的に難しいという現実だ。TextMateが台頭して数年経ちXcodeがメインストリームの先頭を突っ走る2013年において新しくvimを勉強しようとする若者はよほどの物好きしかいない。30~40歳のvimエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価な20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にvimを新たに学ぶ若者は絶滅寸前だ。
とても優秀な若者を雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「vimは習得していますか？」「もちろんEclipse/NetBeans/Xcodeはお手の物です。IntelliJもある程度可能です」「もう一度伺いますがvimは習得していますか？」「申し訳ございません 未習得です」
MessagePackが文字列とバイナリをわけないのは問題？
Objective Cの実装使ってるとある問題にぶちあたった．なので，文字列をちゃんとバイナリ(Raw)と分けるべき，という提案
(*) 俺は熟読したわけではないので，中身が気になる人はちゃんと本スレを読みましょう