タグ

2015年8月25日のブックマーク (7件)

  • 英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita

    〔提案に対して〕いいと思う;問題ないと思う;〔コードレビュアーが、問題ないコードに対して〕レビュー終了;(コードの)承認

    英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita
  • Baton d'or(バトンドール)

    バトンドール 9月~10月の催事情報 バトンドールでは関西を中心とした直営6店舗以外に 期間限定で百貨店の催事に出店しております。 今後のスケジュールをお知らせいたします。 お近くにお越しの際はぜひお立ち寄りくださいませ。 【 関東 】 ・井上百貨店 アイシティ21店(長野県東筑摩郡) 販売期間:2024年9月14日(土)~2024年9月23日(月) ・西武所沢S.C.(埼玉県所沢市) 販売期間:2024年9月24日(火)~2024年9月30日(月) ・そごう千葉店(千葉県千葉市) 販売期間:2024年10月9日(水)~2024年10月15日(火) ・そごう横浜店(神奈川県横浜市) 販売期間:2024年10月15日(火)~2024年10月21日(月) ・ラスカ茅ケ崎(神奈川県茅ケ崎市) 販売期間:2024年10月16日(水)~2024年10月22日(火) 皆様のご来店を心よりお待ちしており

    Baton d'or(バトンドール)
    shifumin
    shifumin 2015/08/25
    通常の3倍ポッキー。
  • Gitでやらかさないための事前予防策 - Qiita

    Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある

    Gitでやらかさないための事前予防策 - Qiita
  • オープンソースプロジェクトで上手いことやってくための10の方法 - Qiita

    何も考えずに書き始めたけど10の方法って書いちゃった。 いくつになるかはわかりません。 一般的なプロジェクト運用でもある程度同じ方法論でイケると思います。 なお、筆者であるvvakameはDefinitelyTypedのメンテナをしています。 そのため、これから先の文章について、TypeScriptJavaScript関係固有の事象が含まれていると思います。 書かれている内容について、contributeする側、される側、両側へのアドバイスを書きます。 ちなみに、わかめ的にはTOMOYO Linuxに学ぶ説得術とかはすごい参考になりました。 こまけぇことはいいんだよ!まずはやろう! 貴方が世界に存在するためにはまず誰かに存在を知ってもらわなければいけません。 pull requestを出そう!無理だったらIssueを書こう! まずはそこからだ!! pull requestのmergeを拒

    オープンソースプロジェクトで上手いことやってくための10の方法 - Qiita
  • 技術的な文章を書くための1歩、2歩、3歩 - Qiita

    ちょっと書きたくなったので書くんじゃーい! この文章を読み終わった時、読者がそれなりわかめ品質な文章を出力できるようになり、どこかに寄稿した時に全面リテイクをらったりしないようになることを目指します。 mhidaka が 0歩目を書いてくれました! 背景 筆者は普通のエンジニアです。その辺の開発とかしてる会社に勤めています。技術系の原稿も書きます。 原稿書きでご飯べてるわけではありません(晩ご飯が豪華になることは稀にあります)。 今まで有能なレビューワー(muなんとかさんとか)編集さんとか(某社の安藤さんとか)とかとかに鍛えていただきました。 この場を借りてお礼を述べておきたいと思います。ありがとうございます。 なお、この文章は2013年10月時点での筆者(わかめ)のやり方です。 将来的にはより良いやり方を見つけるでしょうし、これとは全く違う書き方で上手にやっている人もいると思います。

    技術的な文章を書くための1歩、2歩、3歩 - Qiita
  • GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita

    2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 家リモート upstream を追加する方法 家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R

    GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita
  • git fetchの理解からgit mergeとpullの役割 - Qiita

    gitを使い始めるとcommit, push, pullなどはある程度理解出来るようになりますが、fetchってなんだ?ってなりますよね。 あまり馴染みにくいのは、pullがfetchとmergeの両方を組み合わせたコマンドだからなんですね。 fetchとは gitの場合、リポジトリはリモートとローカルの2ヶ所あります。fetchとはリモートリポジトリから最新情報をローカルリポジトリに持ってくるコマンドです。 fetchをしても、pullのようにファイルが更新されるわけではありません。 あくまでもローカルリポジトリが更新されるだけです。 もっと詳しくいうと、例えばmasterブランチを使っているのであれば、 origin/masterが更新されるということです。 masterとorigin/masterの違い masterは、例えばローカルのファイルを更新してコミットする場合にはmaste

    git fetchの理解からgit mergeとpullの役割 - Qiita