AWS リソースを Backlog Wiki によしなにドキュメント化 (一覧化) するツール, その名も Furikake を作った - ようへいの日々精進XP
tl;dr 作ったもの furikake 使い方 ちっぷす 以上 まだまだ awspec ということで tl;dr ギョームにて AWS リソース一覧を Backlog Wiki や Excel にまとめる度になんて不毛な作業をやっているんだろうと自問自答を繰り返しておりました. そう, EC2 を追加したり削除する度にそれらの Wiki や Excel 表は誰がいったい更新するんだ, きっとそのうち誰もこの Wiki や Excel 表はメンテナンスされなくなるんだろう, そして, なにかトラブルが起きた時には情報が古いままになっているとか...せめてコマンド一発でこれらの Wiki や Excel 表が更新できたらどんなに嬉しいものかと...思いは強くなっていきました. 今日は利用中の AWS リソース一覧をガサッと取得して wiki (Backlog を想定) に登録するオレ得ツール
Backlog Wiki をオフラインでも管理したいと思ったので daimyo を作ってみました - ようへいの日々精進XP
これは 本当は daimyo = 大名 daimyo は daimyo の使い方 .daimyo.yml の作成 プロジェクトの Wiki 一覧を出力する プロジェクト単位での Wiki の書き出す Wiki を更新する 色々とやりたい ということで これは adventar.org Backlog Advent Calendar 2018 の第 7 日目の記事です. qiita.com 初老丸アドベントカレンダー 2018 の第 7 日目の記事です. 本当は 指定した AWS アカウントの指定したリソース一覧を取得して #Backlog Wiki に投稿するツールを @inokara さんが公開中！👏https://t.co/s0QxrmHCc1— Backlog | プロジェクト管理ツール (@backlogapp) 2018年11月16日 furikake について書こうと思ってい
知的生産ツール「Notion」は、現代人を悩ます“情報の散らかり”から私たちを救う | inquire.jp
情報管理と創造性は関係する。だから、人は昔から知的生産に熱心に取り組んできた。 情報が膨大になった現代において、私たちの創造性を引き出してくれる救世主「Notion」を紹介したい。 ジェームズ・W・ヤングは著書『アイデアのつくり方』で、「アイデアは既存の要素の新しい組み合わせ」だと語った。1940年のことだ。 ヤングの言葉を信じるなら、現代は最も創造的な時代を迎えている。変化が激しく、情報が溢れている現在は、これまで以上にアイデアの元となる要素に溢れているはずだからだ。 現代人を悩ます「情報の散らかり」が私たちの時間を奪う 「そういえば、あの情報ってどこに残しておいたんだっけ？」 通勤途中に読んだWebの記事や、仕事中に思いついたアイディアのメモ、友人から聞いた美味しいレストランの名前。どこかに記録したはずなのに、見つからないことがよくある。 メモアプリに書いたのか、写真で撮っておいたのか
GROWI Docs
Markdown x Wiki 左右2画面でのリアルタイムプレビューが可能。言語ごとのコードハイライトや絵文字や注釈(footnotes)、タスクリスト、Bootstrap による HTML コードにも対応しています。 高いカスタマイズ性 テーマ選択、認証機構の変更、ユーザーごとに Vim/Emacs/Sublime Text のキーマップを選択できたりと、管理者とユーザー両方に合わせた柔軟なカスタマイズが可能です。 育ち続けるプロジェクト WESEEK, Inc. のエンジニアを中心とした活発なコミュニティが、システムを常に成長させ、ユーザーのみなさまと一緒により良いコミュニケーションツールの在り方を模索します。質問や提案があれば私たちの Slack にご参加ください。
チケットの書き方 - Qiita
メンバーの一部がスムーズに情報共有できるチケットを書けず 苦戦しており、相談を受けた時に色々言った内容を 書き起こしたもの。 荒いけど誰かの参考になるかもしれないので共有。 2019/09/07 宣伝追記 技術書典サークル参加します。 チーム運営どう考えて何をやったかまとめた本とセキュリティの 入門書を頒布するので気になった方は是非。 https://techbookfest.org/event/tbf07/circle/5671044488626176 書いた人の環境 業務ツールとしてチャット、Redmine、Wikiを使用。 チャットで会話して相談・整理・調整する。 タスク、課題はチケット化して管理。 ナレッジはWikiに書いて共有。 業務内容はシステム開発と運用保守でソフトウェア開発ではない。 Redmineはタスク・課題管理に使用。 以下、メンバーに伝えたことを清書したもの。 前提
wikiのコードとかテーブルをリストに反映する方法 - アルパカDiary Pro
Tips的な話。 失敗例 Redmineのwiki記法で、リストの下にpreタグとか表とか入れたい時 普通に記述するとうまくいきませんよね… wikiテキスト * リスト１ ** リスト２ サンプルコードはこちら <pre> #!/usr/bin/perl print "Hello World!!\n"; </pre> *** リスト３ 一覧表です |ほげほげ|ふがふが| |ふげふげ|ほがほが| イメージ なんじゃこりゃぁ〜！ 成功例 上記のテキストをちょっと変えるだけでOKです。 それはpreタグや表タグの前に半角スペースを１つ挿入するだけ！ wikiテキスト * リスト１ ** リスト２ サンプルコードはこちら <pre> #!/usr/bin/perl print "Hello World!!\n"; </pre> *** リスト３ 一覧表です |ほげほげ|ふがふが| |ふげふげ|ほ
gollum + docker + Kitematicでローカル環境にWikiを建てる | DevelopersIO
個人的なメモ取り環境としてWikiが欲しいな、と思ったので建てました。 以下macOSで作業していますが、LinuxやWindows環境でも大きく変えるところなく使えると思います。 Wikiエンジンにはgollumを使う gollumはバックエンドにGitを使っているシンプルなWikiです。 gollum -- A git-based Wiki GFMで記述するようにもできますし、レポジトリに直接コミットしてもちゃんと拾ってくれるので、取り敢えず適当なテキストエディタで殴り書いたメモを取り込む場合にも手間があまりかかりません。 勿論複数人でバリバリ使うような用途には向いていないかもしれませんが、個人的な用途で使う場合にはその手軽さが助かります。 Dockerで構築 一昔前ならローカルにLAMP環境を構築したり、VirtualBox等で仮想VMのLinuxを起動して〜となるところですが、今の
Knowledge - オープンソースのナレッジベース
個人のもつ暗黙知を形式知に変換することにより、知識の共有化、明確化を図り、作業の効率化や新発見を促します。 また、Knowledgeはパソコン／タブレット／スマートフォンといった全てのデバイスに対応していますので、いつでもどこでも情報共有を行えます。
情報の共有化を徹底し、仕事の属人化を防ぐ！ Markdown記法対応の「社内Wiki」11選 | HRナビ by リクルート
創業時は少人数で始めた事業でも、規模が大きくなるにつれて互いの手元にある仕事が見えづらくなり、属人的になりがち……。社員が増えるに従って、社内ルールやマニュアル、表記法・命名規則の統一など、各種情報を簡単に参照できるように組織環境を整える必要も出てくるだろう。 こうした時に役に立つのが社内での情報共有ツール、「社内Wiki」である。 社内Wikiを活用することで、社員の情報発信が習慣化され、有益な情報を組織全体で共有できるという大きなメリットが生まれる。今回は、GitHub（ギットハブ）やGitLab（ギットラボ）で標準採用されたことで、エンジニアの共通言語となりつつある「Markdown記法【※】」に対応した社内Wikiに活用できるサービスを紹介しよう。 ※「見出し」や「箇条書き」「引用」といった文書の装飾を簡単に行える、軽量マークアップ言語の一つ 社内Wikiとはなにか 社内Wikiと
Markdownで書ける、よさげなWikiサーバーソフトまとめ - Qiita
※この記事は僕のブログ（最近始めました）のクローン記事です。 なんとなく、グループ内部用のWikiに最適なやつって無いのかなあと思ったのです。特にどのグループというわけじゃありませんが、ええ、なんとなく。 サーバー設置型のWikiソフトウェアというと国内で有名なのはPukiWikiでしょうか。設置も手軽で拡張性も高く、すでに慣れ親しんだWikiですが、最近では各方面がMarkdownを採用してそれに慣れ親しんでしまい、このブログもプラグインを入れてMarkdownで書いているぐらいなので、Markdownで書けるWikiを探していたのです。 必要要件はこんな感じ。 サーバー設置型 グループ内部向けのポータル的Wikiに適している Markdownで書ける 使い方が簡単 日本人に厳しくない デザインがナウい というわけで昨日から丸２日ぐらいぶっ通しで調べぬいた結果はっぴょー。どんどんぱふぱふ
ぼっちWikiに最適なGollumについてのメモ - Qiita
自分だけが使うぼっちWikiをGollumで作成したときのメモ。 GollumはデータベースにGitを使い、Markdownで書けるWiki。 Gollumの特徴は以下の通り。 シンタックスハイライトや数式に対応している 様々な記法で書ける GitHub Flavored Markdown Textile reStructuredText MediaWiki などなど gemコマンドで簡単にインストールできる データベースとしてGitを使うのでMySQLなどが不要 Ruby＋Sinatraで実装されている Rubyでマクロを書いて拡張できる 欠点は、日本語の扱いに気をつける必要があること（後述）。 Gollumのインストール ICUという文字コード変換ライブラリに依存しているのでまずはそれをインストール。 # OS Xの場合 $ brew install icu4c # Debian/Ub
gollumというwikiエンジン - Test
gollum というwikiエンジンがある． 個人的に思うgollumの特徴は ページはデータベースじゃなくてテキストで管理 バージョン管理(Git)ベースでいろいろ管理 ただのリポジトリで管理されたプロジェクト風wikiなので(?) オンライン でも オフラインでも運営可能 Githubでのマークダウンが使える (やばい) Mathjaxも普通に使える (やばい) デザインが こんな感じ でシンプルで素敵 (cssとかでカスタマイズも可能) (Sinatraベースっぽい？のでいろいろWebアプリとして勉強できる) 以上の点でとても素晴らしいと思いましてひっそり使っております 自分がどう使っているかメモ残しておきます． gollumは以下でインストールできました
シンプルな wiki 「gollum」 を評価した - vimtaku blog
TL;DR backlog はかなり緑だけど、よく出来てた gollum は backlog と比べると、今の組織ではまだ早い 気合があれば gollum を修正して使うといいんじゃないの 背景 1 【緩募】シンプルな wiki で無料で markdown がかけてデザインがイケてて添付ファイルが up できて backlog より便利なヤツ こういう要求があった。 今、会社で wikiシステムにも backlog を使っていて、よく出来ているんだけど、 エンジニア的な視点からは非常に使いづらい気がしていて、 markdown でもっとイイ感じのなにかが欲しかった。 はたして backlog の何が不満なのか なんか全体的に緑なデザイン markdown プレビューがだるい点 (重要)コンフルに比べて、小ページの概念がないこと いま気づいたけど、これがマジでイケてない。コンフルはそれが便利
【GitHub】GitHubのWikiを書く | AdMax Tech Blog
AdMaxSDKの使い方はすべてWikiに書いています。 ライブラリなどを作成してGitHubを使って世に公開したときにREADME.mdに使い方すべてを書いてしまうと、とっても読みづらいです。 どんなライブラリか、対応バージョン、インストール方法など簡単に書けるものはREADME.mdに書くで問題ないと思います。 しかし、細かい使い方やAdMaxSDKみたいにあまり使い方がわかっていない人に対して「SDKを用意したから勝手に使ってください。」という姿勢は失礼だと思ったのでWikiにすべてを書きました。 なので、今回はGitHubにWikiを公開するまでの流れを書きます。 リポジトリの作成 なにはともあれリポジトリを作成します。 ここは割愛させて頂きます。 Wikiの作成 ではさっそくWikiを作成します。 リポジトリの画面の右にWikiのリンクがあるのでそれをクリックしてください。 リン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - oreno-tools/daimyo: Backlog Wiki をオフラインで編集, 更新することを目的にした小さなツールです.
【Bitbucket】Wikiを使ってみる - ShikaShikaMemoの日記
GitHub - lodge/lodge: イントラネット内で誰でも構築できる情報共有サービス
Crowi
GitHub - dreverri/gollum-site: Static Site Generator for Gollum Wikis
Home
