行政文書はMarkdownで管理できるか｜Hal Seki
（9月3日追記）元のタイトルは「行政文章はMarkdownで管理できるか」でしたが、ここで言っているのは「文章」ではなく、「文書」だろう、というご指摘をいただき、本文も含め訂正させていただきました。（追記終わり） 先日下記のTweetをしたところ、多くの人からコメントをいただきました。 行政文章のMarkdown化、進めていきたい。公開時だけでなく、普段からMarkdownでやりとりできるといいんだけどな。Wordを使って文章作ってる人をターゲットにしたMarkdownエディタを作ってみたい。 HackMDでもまだ難しいイメージ。実務に寄せていく必要がある。https://t.co/3iVDjXVHcQ — Hal Seki (@hal_sk) August 31, 2021 賛同の意見が多かったのですが、下記のような懸念点もいただきました。 ・編集する側も見る側も大変になる。何故やる必要
LINEの社内には「テクニカルライティング」の専門チームがあります - LINE ENGINEERING
こんにちは、Developer Contentチームのmochikoです。LINE株式会社でテクニカルライターとして働いています。今日は「テクニカルライター」というお仕事と、LINEにあるテクニカルライティングの専門チームについてお話しします。 テクニカルライターという職種があります テクニカルライターって何をしてるの？何を書くの？ ドキュメントはどうやって書いてるの？ どんなメンバーで仕事をしてるの？ ドキュメントを書く以外にこんなこともしているよ でもドキュメントを書くだけだと技術力が下がらない？ どんな人がテクニカルライターに向いてるの？ テクニカルライターという職種があります 私はもともとウェブ制作会社のインフラエンジニアでした。とある技術書を書いたことをきっかけに「テクニカルライターとして一緒に働きませんか？」と声をかけてもらい、LINEへ転職するに至ったのですが、実はお誘いをい
GitHubヘルプドキュメントが日本語化されました
GitHubのヘルプドキュメントサイト help.github.com が、日本語と中国語(簡体字)でも利用可能になりました。新たに翻訳されたヘルプサイトには、GitHub.com、GitHub Enterprise、GitHub Desktop、およびGitHub Pagesのドキュメントがあります。 日本語サイトおよび中国語(簡体字)サイトにアクセスするには、help.github.comにアクセスし、ドロップダウンメニューから使用する言語を選択します。また、日本語の場合はhelp.github.com/ja、中国語(簡体字)の場合はhelp.github.com/cnにアクセスすることで、翻訳されたドキュメントのディレクトリに直接アクセスすることもできます。 ヘルプと製品ドキュメントはCI（継続的インテグレーション）が採用されており、これにより、サイトの利用者には常に最新のコンテンツ
有用なドキュメントを作るために心掛けたいこと
有用な文書を作るために心掛けたいこと この記事は rogy Advent Calendar 2018 の21日目の記事 (#LATECH) です。 前日の記事は STM32でマウスとキーボードを作る – 東京工業大学 ロボット技術研究会公式ブログ でした。 文書を“作る” この記事を読む皆様は、少なからず日頃から文章を書くことがあるかと思います。 文章を書き公開しようというとき、「良い文章の書き方」はいろいろなところで目にしますし、必要とあらば勉強することもあるでしょう。 しかし、文章そのものではなく「良い文書の作り方」を意識したことはありますか？ どんなに良い文章であっても、駄目な性質を多く持つ文書として公開されると、その価値は暴落します[0]。 本記事では、内容はさておき「良い文書」を作ろうというとき私が心掛けていることなどを紹介します。 良い文書とは 私の考える良い文書とは何なのか、
✓DO、X DO NOT の誤訳事案
だいぶ炎上してる例のあれ doの意味が全体的に逆になっています。 #118 対応ミスってるとはいえさすがにかわいそうなレベルでいいがかり付けられてる感じもするのでちょっと補足を。 元々の問題 マイクロソフトの機械翻訳がよくやらかすのはいつものことなんですが。 今回は何をやらかしたかというと、よくある ✓DO: 〇〇してください X DO NOT: 〇〇はしないでください みたいなやつを、DOもDO NOTもどっちも「しないで」と訳してしまっているという問題。 「しないで」も不自然だし、ましてDOの方は真逆の意味になっているという誤訳。 どうしてこうなる… みたいな気持ちはもちろんあるものの、こういう「普通の文章」になっていない部分の単語ってのは、機械翻訳では一番ミスを起こしがちな部分です。 たぶん、原文の時点で何らかのアノテーションでも付けておくとかしないと、今後も同様の誤訳は起こりまくる
PythonパッケージをPyPIにアップロードする際にMarkdownをreSTに変換 - Steel Dragon 14106
PythonパッケージをPyPIにアップロードする際にMarkdownをreSTに変換 By raimon, 2018-01-30(火), in category Python MarkdownフォーマットではHTML描画されない問題 Pythonパッケージの開発もGitHubが使われるケースが増えている。それに伴って、パッケージのドキュメントもMarkdownフォーマットが採用されるケースも散見される。 ただし、MarkdownフォーマットでPyPIサーバーにアップロードすると、Web UIではHTML描画されないため、ユーザーフレンドリーではない。 そこで、Pythonパッケージの新しいバージョンをPyPIサーバーにアップロードする際に、オンデマンドでreStructuredText（以降「reST」）フォーマットにオンデマンドで変換してやると、いい感じにWeb UIでもHTML描画さ
Swift API Design Guidelinesの紹介(Swift 3版) - Qiita
Swift.org - API Design Guidelinesを読みながら日本語で書き起こしてみました。 (全訳では無く、また一部意訳など混ざっています。) API Design Gudelinesということで、例えばアプリ実装の特に画面側のコード書く際にはあまり気にしなくても良い気がするものも少し混ざっている気がしました。 原文に豊富にあるコード例はほとんど省いたので、適宜原文見た方が分かりやすいかと思います。 基本 用途が明確なこと 用途が明確なことは、最も重要なゴール。コードは書かれるより読まれることの方がずっと多い。 明確さは簡潔さより重要 短いコードを追い求め過ぎて、可読性など損なうのは良くない。 ドキュメンテーションコメントを書きましょう すべての定義にはドキュメンテーションコメントを書きましょう。 (訳注: 処理に添えるコメントではなくクラス・メソッド・フィールド定義など
国際化 — Sphinx 1.4.4 ドキュメント
Sphinxでは、ナビゲーションバーなどの文字列を各国語にする機能を提供していましたが、 文章 そのものを翻訳する機能を提供します。細かい設定については 国際化のオプション を参照してください。 Sphinx 国際化について¶ gettext [1] は国際化とローカル化の手段として、よく使用されている方法です。プログラム中で使用されるメッセージと、翻訳文字列の対応表を使って置き換えてきます。Sphinxはこの機能を使って、ドキュメント全体を翻訳していきます。 まず最初に、プロジェクトのメンテナーはすべての翻訳文字列を集めてくる必要があります(これを メッセージ と呼ぶ)。これを翻訳者に渡します。Sphinxでは、 sphinx-build -b gettext を実行して、これを行います。 すべてdoctreeの要素は、それぞれがメッセージとなります。巨大なパラグラフは原文のまま残ります
MySQL 5.6リファレンスマニュアル日本語版のお知らせ
MySQL 5.6 リファレンスマニュアル というわけで、日本語版のマニュアルがリリースされた。これまでMySQL 5.6のリファレンスマニュアルは英語版しか無かったのだけど、公式に日本語版がリリースされる運びとなったので、是非参照して頂きたい。 かつてMySQL 5.1の日本語版マニュアルが存在したのだが、そちらは現在ウェブから参照できなくなっている。（PDF版はダウンロードできるという話も。）MySQL 5.1の日本語版マニュアルは、ぶっちゃけ翻訳があまりイケてなかったので、今後はぜひMySQL 5.6の日本語版を参照してもらいたい。ついでにもう古のバージョンは窓から投げ捨てて、この機会に是非新しいバージョンへ移行してみてはいかがだろうか。 何か問題が見つかった場合には、ぜひバグレポートをお願いします。バグレポートのカテゴリは「Japanese Documentation」を選択してく
vim-jp » Vim の作者 Bram Moolenaar への 10 の質問
10 Questions with Vim’s creator, Bram Moolenaar - Binpress の翻訳です。 Vim の作者 Bram Moolenaar への 10 の質問 by Alexis Santos, November 19, 2014 Vim の登場から 23 年、何百万行ものコードが Vim で書かれました。私たちはこの偉大なテキストエディタの作者である Bram Moolenaar にお話を伺い、20 年間の開発で彼が学んだことや、NeoVim についての彼の考えなどを聞きました。また、Reddit の Vim ユーザーからの質問も投げかけてみました。Bram の回答をご覧下さい。 1: このような大きくて広く使われるソフトウェアを長期間メンテナンスすることから学んだことは？ 人が間違う可能性のあるあらゆることを学びました。自分自身の失敗や他人のコード
JS NICE: Statistical renaming, Type inference and Deobfuscation
Welcome to JSNice — we make even obfuscated JavaScript code readable. We will rename variables and parameters to names that we learn from thousands of open source projects. Furthermore, often we are also able to guess or infer type annotations. Try JSNice on your JavaScript code to see how it works! Override the names suggested by JSNice (by enabling "interactive renames" in settings). Click to le
ホーム: Java Platform, Standard Edition (Java SE) 8リリース8
Oracle | Hardware and Software, Engineered to Work Together
JSDoc Toolkit→JSDoc 3移行ガイド | BLOG - DeNA Engineering
こんにちわ、DeNA San Francisco の渋川と申します。エンジニアブログには初登場です。 JavaScriptのソースコードからAPIドキュメントを生成するツールには何種類かありますが、日本語の書籍やウェブサイトでも情報が得やすいこともあって、JSDocの系統が幅広く使われています。Google Closure Compilerも、JSDocを拡張したドックコメントをアノテーションとして読み込んで最適化します。 JSDocは長い期間メンテナンスされているオープンソースプロダクトです。初代はPerlで書かれたJSDoc 1です。これはすでにリポジトリも削除されています。現在最も使われているのが JSDoc Toolkit (JSDoc 2) です。弊社の ngCoreのドキュメント でも使用しています。 ただ、これも現在は機能追加を停止していて、後継プロダクトの JSDoc 3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://tink.elliptium.net/2021/05/30/how_to_use_python_official_documentation.html
http://pytest.org/latest-ja/contents.html