GitHub - reconquest/shdoc: Documentation generator for shell scripts (bash, sh, zsh). Javadoc for shell scripts.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Packaging Python Projects - Python Packaging User Guide
Packaging Python Projects# This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index (PyPI). Tip If you have trouble running the commands in this tutorial, please copy the command and its output, then open an issue on the pack
Supercharging GitHub Actions with Job Summaries
ProductSupercharging GitHub Actions with Job SummariesYou can now output and group custom Markdown content on the Actions run summary page. The same familiar functionality that powers pull requests, issues, and README files has come to GitHub Actions! We’re thrilled to announce GitHub Actions Job Summaries, which allow for custom Markdown content on the run summary generated by each job. Custom Ma
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
MarkdownをpandocでHTML化するときのノウハウ - 理系学生日記
MarkdownファイルをPandocでHTML化する際、どのような指定が良いかを迷っていたのですが、いまのところ以下のようなオプションで落ち着きました。 HTMLテンプレート Table of Contents(TOC)の作成 画像ファイルの同梱 $ pandoc \ --standalone \ --self-contained \ --resource-path=/path/to \ --toc \ --toc-depth 2 \ --shift-heading-level-by=-1 \ --metadata title='タイトル' \ --template=html_templates/bootstrap_menu.html \ --fail-if-warnings \ --output=${destdir}/guide.html \ /path/to/target.md HT
行政文書はMarkdownで管理できるか｜Hal Seki
（9月3日追記）元のタイトルは「行政文章はMarkdownで管理できるか」でしたが、ここで言っているのは「文章」ではなく、「文書」だろう、というご指摘をいただき、本文も含め訂正させていただきました。（追記終わり） 先日下記のTweetをしたところ、多くの人からコメントをいただきました。 行政文章のMarkdown化、進めていきたい。公開時だけでなく、普段からMarkdownでやりとりできるといいんだけどな。Wordを使って文章作ってる人をターゲットにしたMarkdownエディタを作ってみたい。 HackMDでもまだ難しいイメージ。実務に寄せていく必要がある。https://t.co/3iVDjXVHcQ — Hal Seki (@hal_sk) August 31, 2021 賛同の意見が多かったのですが、下記のような懸念点もいただきました。 ・編集する側も見る側も大変になる。何故やる必要
ブログは資産！「はてなブログ DevBlog Online Meetup」イベントレポート - 週刊はてなブログ
はてなブログは、2021年5月24日（月）に「企業によるブログを活用した技術情報のアウトプット」をテーマにしたオンラインイベント「はてなブログ DevBlog Online Meetup」を開催しました。 「はてなブログ DevBlog Online Meetup」とは はてなブログは、企業の技術ブログ向けプラン「はてなブログ for DevBlog」の提供をはじめ、OSSコミュニティ支援、週刊はてなブログでの「エンジニアのブログ探訪」連載などを通じて、技術情報のアウトプットを支援しています。その一環として、本イベントでは、技術ブログを運営する企業様・これから始めたいとお考えの企業様に向けたイベント「はてなブログ DevBlog Online Meetup」を開催。 技術ブログを運営する3社（エムスリー様・富士通様・LINE様）をゲストにお招きし、参加者から事前にお寄せいただいたご質問やコ
ちょうどよさのはなし / morrita - Message Passing
その「ちょうどよさ」ゆえに普及したテクノロジ - アイデアや標準があると思う。 そういうのは、科学や工学でなく匠としてのプログラミングを表している気がして成功が嬉しい。 自分にとって「ちょうどいいテクノロジ」の代表は JSON (2002) と Markdown (2004). どちらも技術的にはさほど大したことはないけれど、どちらも広く使われている。 「ちょうどいいテクノロジ」はこれ以前にも色々あった。UNIX(1969) や HTTP/REST (1991) なんかが思い当たる。 ただ同時代性がないせいか成功が華やかすぎるせいか、まいち親近感がない。 ついでにいうと、自分はもはやこれらに「ちょうどよさ」を感じない。 UNIX の代表 Linux は超巨大ソフトウェアだし、HTTP の最新版 HTTP/3 は随分複雑なプロトコルに見える。 JSON と Markdown は、今のところ当
Rebuild: 297: Too Hot To Handle (N)
Naoki Hiroshima さんをゲストに迎えて、ワクチン、Swift、ライブラリ、ソーシャルメディア、将棋などについて話しました。 Show Notes Biden’s New Plan to Get COVID-19 Vaccines to Every American Uniqlo to close S.F. store, adding to flood of retail vacancies near Union Square Google GIGA School Package | Google for Education Swift Concurrency Manifesto swift-evolution/0296-async-await A Proposal for Adding Generics to Go - The Go Blog Swift.org - Pack
ARCHITECTURE.md
ARCHITECTURE.md Feb 6, 2021 If you maintain an open-source project in the range of 10k-200k lines of code, I strongly encourage you to add an ARCHITECTURE document next to README and CONTRIBUTING. Before going into the details of why and how, I want to emphasize that this is not another “docs are good, write more docs” advice. I am pretty sloppy about documentation, and, e.g., I often use just “si
おまえはもうRのグラフの日本語表示に悩まない (各OS対応) - ill-identified diary
2021/9/10 追記: 改めて更新された話を統合して整理して書き直しました. 以降はこちらを参考にしてください: ill-identified.hatenablog.com 2021/1/15 追記: RStudio 1.4 がリリースされたのでなるべくアップデートしましょう 2020/12/06 追記: Japan.R で今回の話の要約+新情報を『Mac でも Windows でも, PNG でも PDF でもRのグラフに好きなフォントで日本語を表示したい (2020年最終版)/Display-CJK-Font-in-Any-Gpraphic-Device-and-Platform-2020 - Speaker Deck』として発表した. ハイライトは「近々出るRStudio 1.4 があれば fontregisterer はほぼいらなくなる」 2020/10/31 追記: geom
Github Profileの設定 - Atsuo Ishimoto's blog
Github Profileの設定 GithubのProfile画面 に自分の好きなREADME.mdファイルを表示できる、という話を見かけて、試してしました。ちょっと前に試したときには、自分のアカウントではこの機能を使えなかったようですが、いつの間にか使えるようになっていました。 Githubで自分のアカウント名と同じ名前のリポジトリ(私の場合なら atsuoishimoto) を作成し、つぎのように表示されれば機能が有効になっているようです。 README.txtの生成 作成したリポジトリに README.md という名前のマークダウンでプロファイルを作成すれば、そのまま自分のプロファイル画面に表示されます。 単に README.md を書いておくのも芸がない話なので、定期的にこのブログのRSSを取得し、プロファイルに表示するようにしてみました。 生成には、SSGにこのサイトや pyt
Rebuild: 265: The Time For Introverts (higepon)
Taro Minowa さんをゲストに迎えて、脳脊髄液減少症、Social Distancing, コンタクトトレーシング、リモートワーク、ノートテイキング、FF7 などについて話しました。 Show Notes Rebuild: 254: Udon Ecosystem (higepon) 突発性脳脊髄液減少症になり1ヶ月以上寝たきりだった話 - higepon blog Apple and Google partner on COVID-19 contact tracing technology Privacy-Preserving Contact Tracing - Apple and Google How Apple And Google Are Going To Enable Contact Tracing Find Your Keys, Wallet & Phone with T
GitHub Flavored Markdown は何であって何でないか - Qiita
のんびりしていたらこんなメンションをもらっていたので、ちょっとまとめてみようと思います。 そろそろ @tk0miya さんがアップしてくる頃。GFMはspecかっちりしてるんでしたっけ(markdown全く詳しくない — Aki Ariga (@chezou) February 1, 2020 かっちりしている? この記事を読んでいる皆さんは Markdown の歴史に精通していると思うので、古い部分はざっくり割愛してしまいますが、オリジナルの Markdown は かっちりしていない ことで有名なマークアップ言語です。 必要最低限のマークアップ要素は規定されていて HTML への変換ツールも完成していた Markdown ですが、マークアップ言語の言語仕様としては貧弱で、インデントのルールやインライン要素をネストしたときの挙動、空行の有無による解釈の違い、などなど、細かい部分のルールにつ
プレーンテキスト Markdown 時代の終焉
なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 Day One がクソになった Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー... portalshit.net 自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。 ひとむかし前の WYSI
なぜScrapboxはMarkdownを採用していないのか - 増井俊之
字下げ.iconMarkdownというマークアップ言語がエンジニア界隈で広く使われている。もともとはHTMLをもっと簡単に記述したいという意図で開発されたものだそうで、<h1>タイトル</h1>と書くかわりに# タイトルと書けたりするので、記述が少し簡単になるというメリットがある。太字(<b>)やリスト(<ul><li>)なども簡単に書ける。 字下げ.iconMarkdownに慣れたエンジニアがよく「何故ScrapboxはMarkdownを採用しないんだ」と言ってくる。「Markdownを採用しないとか馬鹿じゃないの?」とまで言う人もいる。こういう人々は完全にMarkdown脳というか、自分がタマタマ慣れているものがサイコーだと考えているだけに思える。 字下げ.iconScrapboxのようなWikiで一番大事なのはページ間リンクの記述であり、ここに[...]という単純な記法を使っているた
Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
有用なドキュメントを作るために心掛けたいこと
有用な文書を作るために心掛けたいこと この記事は rogy Advent Calendar 2018 の21日目の記事 (#LATECH) です。 前日の記事は STM32でマウスとキーボードを作る – 東京工業大学 ロボット技術研究会公式ブログ でした。 文書を“作る” この記事を読む皆様は、少なからず日頃から文章を書くことがあるかと思います。 文章を書き公開しようというとき、「良い文章の書き方」はいろいろなところで目にしますし、必要とあらば勉強することもあるでしょう。 しかし、文章そのものではなく「良い文書の作り方」を意識したことはありますか？ どんなに良い文章であっても、駄目な性質を多く持つ文書として公開されると、その価値は暴落します[0]。 本記事では、内容はさておき「良い文書」を作ろうというとき私が心掛けていることなどを紹介します。 良い文書とは 私の考える良い文書とは何なのか、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - github/.github: Community health files for the @GitHub organization
linguist/vendor/README.md at master · github-linguist/linguist
