DockerでサクッとDBからER図を作成する - Qiita
SchemaSpyというDBのスキーマを解析してテーブルの一覧やER図を出力してくれるツールがあります。 このツールの公式Dockerイメージが公開されており、非常に使いやすいので紹介させて頂きます。 https://hub.docker.com/r/schemaspy/schemaspy/ コマンド docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:snapshot \ -t <DB種類> -host <DBホスト名/IP>:<ポート> -db <DB名> -u <DBユーザー名> -p <DBパスワード> このコマンドを実行するとカレントディレクトリのschemaディレクトリに解析結果のHTMLが出力されます。 （コンテナは自動的に終了します） docker run のオプション -vオプションで指
社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤
このページについて これは、社内 Wiki に情報を書くときに、私が個人的に守っていて、チームメンバにもできるだけ守ってほしいルールの紹介記事です。このルールを実際に運用するためのコツについても、基本ルールの派生という形で紹介します。 想定する環境 この記事は、社内に Wiki があって、フォーマットが決まったドキュメント（仕様書や手順書など）とは別に、各人がメモを自由に書いて共有できるような環境を想定しています。 Wiki の種類は問いません。PukiWiki、MediaWiki、Confluence、Esa、Redmine などのプロジェクト管理ツール付属の Wiki などなど……何でもいいです。Word 文書などにも適用できなくはないですが、文書を気軽に分けるのが難しい場面には、あまり向かないかと思います。 ルール：「このページについて」という欄をページの先頭に用意し、そのページの概
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
素直にいれてみたQiita Teamの効果 - 日本経済新聞社 | Qiita Team事例 - Qiita Blog
当記事は、こちらへ移動しました。 引き続きQiita:Teamをよろしくお願いいたします。
Heroku HTTP API Design Guide
JPC2016: PUP-02: 今すぐできるソフトウェア資産を活かした Azure ビジネス展開 ～ ソフトウェア資産をお持ちの方も利用する方も ～MPN Japan
ライセンスの選択を恐れる必要はありません - Qiita
この記事はCC BY 3.0に基いて公開されてゐるWebサイトChoosing an OSS license doesn’t need to be scary - ChooseALicense.comのコンテンツ各ページを翻訳し、単一記事として再構成、訳者による補足を追加したものです。 2017年5月9日に開示されたコミュニティガイドラインに伴って、本記事の翻訳部分につきましては削除いたしました。 (この記事が削除または非公開化されない限り、編集履歴からお読みいただくことは可能です。) (訳註: この「はじめに」及び末尾の「訳者による補足」の章は原文にはなく、翻訳者(@tadsan)によるものです。記事の著作権表示及び元Webサイトの利用規約、免責事項、そしてこの記事についての訳者の見解について記します) (この記事の一部または全て ——ただしコメント欄は含まれない—— はCC BY-SA
脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
ソースコードを読むための技術
$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ
Dashを入れてみたらjQueryやらのドキュメントを見るのが想像以上に快適だったよ。 | Ginpen.com
自分も正直「え、別にブラウザーで見れば良いじゃん？」と思ってたんだけど、想像以上に快適だったので、皆さんにもお薦めしておきますよ。 なにそれ？ jQueryやBackbone.js、HTMLにCSS、あるいはRubyやJava、PHPといったもののドキュメントを閲覧するソフトウェアですよ。 事前にダウンロードしておくのでさくさくだし、検索が簡単だから欲しい情報がすぐ手に入るし、グローバルキーボードショートカットなんか設定しておくと一瞬で検索開始できるからお手軽です。 ウェブブラウザーのブックマークから開いて見れば良いじゃん、てな人も一度使ってみてくださいな。 インストールも簡単です。 検索してみたところ。 公式サイト Dash – Documentation Browser, Snippet Manager – Kapeli インストール App Storeからインストールします。公式サイ
MongoDBの薄い本
2.6対応版 MongoDBの薄い本 The Little MongoDB Book Karl Seguin 著 / 濱野 司 訳 i 目次 目次 i この本について iii ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 著者について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 最新バージョン . . . . . . . . . . . . . . . . . .
Git ユーザマニュアル (バージョン 1.5.3 以降用)
Git ユーザマニュアル (バージョン 1.5.3 以降用) NextGit ユーザマニュアル (バージョン 1.5.3 以降用)Table of Contents Preface1. リポジトリとブランチgit リポジトリの取得方法プロジェクトの他のバージョンのチェックアウト方法履歴の理解：コミットブランチの運用新しいブランチを作成せずに古いバージョンを取得する方法リモートリポジトリのブランチの調査ブランチ、タグ、その他リファレンスの命名法git fetch を用いたリポジトリの更新他のリポジトリからのブランチの取得2. 履歴の探索リグレッションを見つける為の bisect の使用方法コミットの指定方法タグの作成方法リビジョンの閲覧方法差分の生成方法古いファイルバージョンの参照例3. git を使用した開発git に自分の名前を教える新規リポジトリの作成コミットの方法良いコミットメッ
Mercurial 入門セッション資料 - SCM Boot Camp #2 — SCMBC 2011.11 Mercurial Intro-Session 0.0.1 documentation
この資料について¶ SCMBC #2 Mercurial 入門セッション資料です。 http://bitbucket.org/troter/scmbc-2011.11-mercurial-introsession この資料ではMercurialを利用するに当たって必須の用語や概念について説明しています。 この後の演習で参考になるよう、効果的に利用する為のお作法、作業フローについても解説します。 (狭義の)リポジトリ¶ SCM ツールにおいて、 作成／改変／移動／削除といったファイルに対する作業内容や、 実施者／日付といった 「履歴」 (history) に関する管理情報を格納しておく領域を、 (狭義の)「リポジトリ」 (repository) と呼びます。 作業領域¶ リポジトリに格納されている情報を元に、 ファイルを取り出したり、 取り出したファイルに対する作成／改変／移動／削除といった
Bazaar入門セッション — Bazaarスタートアップガイド v0.0.1 documentation
基本用語のはなし¶ Bazaar をはじめ、バージョン管理ソフトでは、名詞と、 その名詞が指すものを作る操作の動詞が、同じ単語になっていることがよくあります。 先に用語をしっかり理解しておくと、あとは文脈で動詞か名詞かを判断できるはずなので、 混乱しないように丁寧に解説して行きます。 リビジョン¶ １回のコミットで保存される情報をまとめたものです。１回コミットするたびに、新しいリビジョンがひとつ作られます。 「チェンジセット」と呼ばれることもあります。また、「コミット」(名詞)をリビジョンの意味で使うこともあります。 リビジョンに含まれる情報は、こんなかんじです。 リビジョンのID どのファイルが、どのように変更されたか コミットしたユーザ コミットした日付 コミットメッセージ 親(ひとつ前)のリビジョン ブランチ¶ リビジョンを積み重ねることで、開発が進んでいきます。この、一連のリビジョ
Facebook開発者向けドキュメントの日本語訳とTips
2015年04月05日18:15 by oklahomer Graph API v2.3 からは access_token の返され方が変わります カテゴリ 4/25 から開催された F8 2015 で、Graph API v2.3 が紹介されました。Graph API を扱う上で影響が大きいと思われるものをここでは紹介します。詳細は公式 Changelog や Upgrade Guide を参照してください。 /oauth/access_token のレスポンス変更 これまでは URL エンコードされたクエリ文字列が以下の様な形式で返されていました。 access_token=foobar&expires=5183814 今後は以下のように JSON オブジェクトが返されるようになり、項目も若干変わります。 expires が expires_in に変わっている点も要注意です。 {"a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
IntelliJ IDEA クイックスタート | 株式会社サムライズム
http://documents.mazgi.com/fluent/doc/