![http://atnd.org/events/33746](https://cdn-ak-scissors.b.st-hatena.com/image/square/d94fa52010927978a5f4178e4a9c9b6bab018a0a/height=288;version=1;width=512/https%3A%2F%2Fatnd.org%2Fevent_images%2F0005%2F3409%2Fvim-girl-3rd-L_08_original.jpg%3F1377153520)
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
複数のmy.cnfがデフォルトで読み込まれるパスに置いてあったり、 中で!includeしたり、直接オプションを渡したりしたとき。 同じパラメータが指定されている場合は、常に後勝ち(後から設定された方で上書き)です。 Linux系のMySQLでは、 /etc/my.cnf -> /etc/mysql/my.cnf -> SYSCONFDIR/my.cnf -> $MYSQL_HOME/my.cnf -> defaults-extra-fileで指定されたファイル -> $HOME/.my.cnf -> 直接渡したオプション の順番で読み込まれる。 優先順位で考えると、後勝ちなので後ろが一番強い。 SYSCONFDIRはcmakeのオプションで指定するものの、デフォルトは/usr/local/mysql/etcになっていた(5.6.8-rcのsource) $MYSQL_HOMEは、mysq
ソフトウェア開発の現場で広く実施されているユニットテストについて、その目的、メリット・デメリットを踏まえた効果的な実施方法について学習します。 1. ユニットテストとは ユニットテスト(単体テスト)は広い意味で使われるようになっている言葉です。 まず、伝統的には、ユニットテストはテストレベルのひとつであり、「個々のユニットを対象とするテスト」としばしば定義されます(例えばJSTQB用語集[JSTQB-glossary.V2.0.J02])。なお、ここでいうユニットとはソフトウェアの最小構成単位を指します。例えば、ソースコードが対象であればC言語等では関数が、JavaやC++等ではクラスが一般的にユニットに該当します。詳しくは後述しますが、そうした関数やクラスを一つ一つ検証していくのが伝統的なユニットテストです。 一方、他の定義として、開発者テストやアジャイル開発の分野では、ユニットテストと
TIPS 扱いされてることも多いけど、いやいや、この辺はどんなプロジェクトでも基礎中の基礎の超捗る設定じゃないですか、ってのをまとめてみる。 .git-completion.bash git コマンドやブランチ名、その他をTAB補完してくれるのと、プロンプトにブランチ名が出せる。 git のソースに含まれるファイルか、このあたりで提供されるものを取ってきて設置して、.bashrc に以下を追記。 if [ -r "$HOME/.git-completion.bash" ]; then . $HOME/.git-completion.bash PS1="[\u@\h\$(__git_ps1 \" %s\") \w]\n\\$ " fi これでブランチ名が長くても安心だし、ブランチ名に dev- とか fix- とかプリフィックスつけとく意味が増す。 似たような設定で、.gitconfig で
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です! こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ? A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう? $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ(master)にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く