社内Wikiを改善して、開発体験をより良くする - Qiita
はじめに ◆この記事は何？ 社内Wikiの改善方法について紹介する記事です。 ◆この記事のねらい 社内Wikiを改善することで、チームの生産性や品質を向上させ、開発体験をより良くするのがねらいです。 先に結論 「ルール」ではなく「ポリシー」を設ける 「Working集」と「アーカイブ集」をつくる ページごとに目的を書く 大切な思考法 「中途半端なドキュメントは中途半端な文化を生む」 「誰でもできるは誰もやらなくなる」 社内Wikiのよくある課題 皆さんの社内Wikiで次のような課題を感じたことはありませんか。 情報が散乱 更新中のページがそのまま メンテナンスされていない構造 多くの人が作成・編集できる社内Wikiは、改善の意志がないと上記のような状態になりがちです。 最悪の場合、開発体験の低下につながります。 良い社内Wikiとは 良い社内Wikiの必要条件は以下の通りです。 開発体験を
共同編集できるWiki「Hedgedoc」のデータをLiteStreamでS3にレプリケーションし永続化する - Qiita
はじめに どうも、共同編集できるWikiが大好きなinajobです。 今回はHackMDのオープンソース版のHedgedocのデータをLiteStreamを使いS3にレプリケーションして永続化する方法について紹介します。 （LiteStreamを使いたかっただけです。） 材料 共同編集ができるWikiを動かす時に必要なのは、アプリケーションをホストするサーバと、データを蓄えるストレージです。 愚直にやるならサーバにアプリケーションと、データベースサーバをインストールして、設定ファイルをいい感じに書く、というのをやればこれを用意できます。 しかし、昨今はXaaS(なんとか あず あ サービス)の時代。愚直にサーバにセットアップするより、それぞれを得意とするサービスを組み合わせてサービスを構築することで、より柔軟なシステムを作ることができます。 アプリケーションを動かすプラットフォーム、 デー
第704回 高機能でMarkdownや作図もサポートするWiki.js | gihyo.jp
Wiki.jsはNode.jsベースのWikiシステムです。モダンな作りとスタイリッシュなデザインで、「とりあえずWikiだけあれば良い」という用途には最善な選択肢のひとつでしょう。今回はそんなWiki.jsをUbuntuにデプロイしてみます。 あなたのWikiはどこから？ 一般的に「Wiki（ウィキ）」と言えば「Wikipedia」を暗黙的に意味することが多い昨今の状況ですが、本連載の読者ならおそらく誰でもご存知のように、現在ではウィキソフトウェアで動いている、ウェブブラウザーで複数のユーザーが共同で編集可能なコンテンツ管理システムの総称です。 生のHTMLを書くのに疲れた人にとって、Wikiの「人に優しいマークアップ言語[1]」は魅力的に映り、現在では非常に多くの環境で様々なWikiが活用されています。その最も成功した例が、Wikipediaを支えているMediaWikiでしょ
継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの
［復刻］ドキュメント記述の心構え - ESM アジャイル事業部 開発者ブログ
2004年中途入社の koic です。来月で入社17年。長いですね。 17年の間で人や技術が流転する長い勤務の中で伝承の途切れを観測していることから、私がいまの勤務先に入ったころ Wiki への考え方への影響を受けたものを発掘してみました。今回、私的解釈を交えて一般公開します。 はじめに 『ドキュメント記述の心構え』原文 私的解釈 {{toc}} 木構造よりも、ネットワーク構造を好め ネストしたリストよりも、見出しによる構造化を好め リストで文章を区切るよりも、空行をあけてPタグでレンダリングせよ 安易に項目追加する前に、リオーガナイズを検討せよ 正規化と重複の均衡点を探せ PREとQUOTEを使い分けよ リオーガナイズのメカニクスを用意せよ おわりに はじめに 本記事で取りあげるのは 2006年以前に「ドキュメント記述の心構え」 (WikiName は DeciplinesOfWriti
階層整理型WiKiはスケールしない - 橋本商会
しかし2つが合わさると、「WiKiマスターにお伺いを立ててどのフォルダに入れるか決めてから書いてください」という謎の運用ルールができたり、間違った階層に配置すると「ちゃんとルールに従って整理しろ！」と滅茶苦茶怒られたりするようになって、誰も書かなくなる。
Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita
初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ
Outline - チームで活用するWiki&ナレッジベース
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました Wikiは年々進化しています。新しいニーズを取り込み、さらに既存のソフトウェアの中にWiki風の機能が追加されて生き残っています。特にオンラインでノートを取ったりするのが当たり前になっている現在、Wikiも自然と使われるようになっています。 今回はそんな最新のWikiエンジンとしてOutlineを紹介します。UIがイケてるWikiエンジンです。 Outlineの使い方 トップページです。最近アップデートされたページなどが表示されます。 表示画面です。 編集画面です。表示画面と変わらない表示で編集できます。 文字を選択すると装飾用のツールバーが表示されます。 セクションを追加する時には別なツールバーが表示されます。 画像の追加も簡単です。 OutlineはWikiのようにメモが可能で
最強のWiki「Crowi」のフォーク、「GROWI(旧crowi-plus)」を公開した話 - Qiita
経緯 Crowi とは node.js + jQuery (一部React) 製の、オンプレにディプロイ可能な Wiki システム。Qiita でも Crowi タグ で検索すると20エントリーほど引っかかる。 Pukiwiki から Crowi へ うちの会社では創業から10年来 Pukiwiki Plus! を使っていて、サイトを簡単に量産できるようにするための Pukiwiki Plus! Plus! なんていうリポジトリもある程使い倒していたのだが、やはり Markdown で書きたいという動機から代替システムを検討、2016年末くらいから Crowi の試用を行っていた。 が、どうにもかゆいところに手が届かない。 Pukiwiki では利用可能だった以下2点の機能が、移行にあたっては必須事項だった。 任意のページの下の階層のツリー表示を行う事ができること Pukiwiki では
GitHubとSlackの連携の基本＆知られざる便利機能Wiki、Releases、Graphs、Pulse
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回の記事「開発者のスケジュール管理に超便利、GitHub Issues、Label、Milestone、Projects使いこなし術」ではイシューやプルリクエストの周辺機能を解説しました。 連載第13回目の本稿では、Pulse、Graphs、Releases、Wiki、外部サービスとの連携について解説します。 リポジトリ上での直近のアクティビティーを表示する「Pulse」 Pulseとは、リポジトリ上での直近のアクティビティーを表示する機能です。下
社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤
このページについて これは、社内 Wiki に情報を書くときに、私が個人的に守っていて、チームメンバにもできるだけ守ってほしいルールの紹介記事です。このルールを実際に運用するためのコツについても、基本ルールの派生という形で紹介します。 想定する環境 この記事は、社内に Wiki があって、フォーマットが決まったドキュメント（仕様書や手順書など）とは別に、各人がメモを自由に書いて共有できるような環境を想定しています。 Wiki の種類は問いません。PukiWiki、MediaWiki、Confluence、Esa、Redmine などのプロジェクト管理ツール付属の Wiki などなど……何でもいいです。Word 文書などにも適用できなくはないですが、文書を気軽に分けるのが難しい場面には、あまり向かないかと思います。 ルール：「このページについて」という欄をページの先頭に用意し、そのページの概
Markdownで書ける、よさげなWikiサーバーソフトまとめ - Qiita
※この記事は僕のブログ（最近始めました）のクローン記事です。 なんとなく、グループ内部用のWikiに最適なやつって無いのかなあと思ったのです。特にどのグループというわけじゃありませんが、ええ、なんとなく。 サーバー設置型のWikiソフトウェアというと国内で有名なのはPukiWikiでしょうか。設置も手軽で拡張性も高く、すでに慣れ親しんだWikiですが、最近では各方面がMarkdownを採用してそれに慣れ親しんでしまい、このブログもプラグインを入れてMarkdownで書いているぐらいなので、Markdownで書けるWikiを探していたのです。 必要要件はこんな感じ。 サーバー設置型 グループ内部向けのポータル的Wikiに適している Markdownで書ける 使い方が簡単 日本人に厳しくない デザインがナウい というわけで昨日から丸２日ぐらいぶっ通しで調べぬいた結果はっぴょー。どんどんぱふぱふ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Type.md
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
Wiki についての今昔物語 / Crowi