Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
しつこく Hub を読む - yarbの日記
しつこく「Hub」を眺めている。語学学習に精読と多読の2つのアプローチがあるように、コードリーディングにも精読というのがあるはずで、試しにそれをやってみている。モヤッする「分かってない感」を感じたら、基本的に分かるまで調べるのが精読。そのためには、ブログエントリとして分かったことを書き出すのは良い方法のような気がしたのでやってみている。ほとんど誰も読んでないブログだとはいえ、アウトプットの形にするのは手間だし、何だか気分的には常に挫けそうなんだけど、「なんとなく分かった気になる」という厄介な悪癖を変えるには十分に時間に見合うと思う。 で、やってみて分かったけど、RubyのこともRubyのイディオムのことも、まるで分かってないということが良く分かった。「コードを読む」ということが何かも分かってなかったなと思った。なんとなく眺めてちゃ駄目だな。まず精読。そのうち多読ができればいいなと思っている
Scala の開発に学ぶコードレビュー体制とプロジェクト開発 - xuwei-k's blog
コードレビューについて Oh, you `re no (fun _ → more) より引用 単に普段の開発で使っている VCS でそれを行なっていました。 つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。 (もちろん複雑な話になった場合は直接の議論を行い、合議の結果だけを記しておく、なども当然あるでしょう。) レビューをソースコードのコメントとして直接書き込むのは、GHC の開発でも時々見かけますね。例えば、新機能の開発 branch を作って、新しい機能を開発している時とか。 2012-08-14 18:44:19 via OpenTween まあ、主に入った変更に Simon Peyton Jones が（ソースコード上で直接）コメントしそれに従ってソースコードを修正する形なので、レビューと言えるほ
死んで覚える本当のGitの使い方 - mizchi log
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
Shibuya.rbで「俺のRails開発環境」という題で発表してきた (資料補足) - joker1007’s diary
ちょっと前にいつだったか、自分の開発環境についてまとめた記事でも書こうかと思っていたんですが、 ついでだからShibuya.rbでLTのネタにしてしまえと、話をしてきました。 ちなみに、今回のShibuya.rbは何か話したい人が居たらどうぞって感じだったのですが、 いつのまにかLT大会になってましたw 俺のRails開発環境 View more presentations from joker1007 内容としては至極一般的な環境だと思いますが、 資料アップしたところ結構反響があったので、 やっぱ人の環境は皆気になってるのかなーと。 後は、これからRails始める人とかかな？ 資料の補足 インテグレーションテスト cucumberを使ってるのは慣れによる所も大きいですが、 今は業務上の理由でコード書く人とテストケース書く人が分離しているので、 request specは使ってなかったりし
プログラム未経験者向けの社内勉強会をやってみた - ppworks.jp
主にプランナー向けとして、プランナーがプログラム出来るようになると嬉しいよね、といった趣旨で勉強会をしました。 p4dにインスパイアされて、planer向けだし、p4pと名付けてみました。(すみません) その時の資料は以下 P4p20120408 View more presentations from Naoto Koshikawa やったこと 内容としては、以下の説明と実技という感じでした。 git ruby sinatra heroku git 一年ぐらいまえに非エンジニア向けにgitをレクチャーしたときの資料を元にgitの概要を説明。バージョン管理システムの概念や使う利点は伝わったかなと思います。 割と丁寧に説明したので、ここまでで2時間ぐらいです。 githubにアカウントを作っておいてもらったので、実際にリポジトリを作ってもらって、そこにRERADME.textileをおいても
Gitのベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
Lord-of-the-Files.ja.md at master from omo/Lord-of-the-Files - GitHub
ファイル達の王: GitHub はいかにしてフリーソフトウェア(など)を手懐けたか By Robert McMillan, Wired Enterprise サンフランシスコ発 - マーケット通り南の気取った屋根裏オフィスに引っ越した GitHub の創業者一味の、最初の仕事は内装のやりなおしだった。 フロアで一番大きい部屋のひとつを重役室のパロディーに作り替えたのだ - 偽物の暖炉、豪華な革張りの椅子、スライドするとシングルモルトのスコッチが隠れている木製の地球儀をならべて完成。壁には猫の油絵。 ナポレオンの格好で、五本のタコ足がはえている。 猫は Octocat という。 ポイントは、これが重役室じゃないってことだ。 これはチームをまたいだミーティングルームで、誰が誰とくだを巻いても、仕事を片付けるのに使っても、ちょっと遊んだりしてもいい。 同じ時間にそういうことをしていていい。 「
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
技術/組織としてどうスケールするか at GitHub - yaotti's diary
会社をスケールさせていくために組織面，技術面で何を行ってきたか．以下簡単なまとめ 組織面 従業員をよりhappyにするために，面白い仕組みを導入している．ミーティングがない，オフィスに来なくても良い．やりとりはpull requestとcampfire． 他にも組織として強くなるために，個人に依存しすぎない(知識共有を促進する)，internal talk(tech talkみたいなのかな?それとも普通の会話?)は将来の従業員のために全て記録する*1，など． 技術面 自動化可能なことを手作業でやり続けることによるコストは，手間だけではない．新規メンバーに学習コストが発生することになる． masterブランチは常にデプロイ可能な状態に保ち，1日に5~30回デプロイを行なっている． 意味のあるメトリクスをグラフ化しよう．全体でのレスポンスタイム平均がXXXms，というのは意味がない． リリース
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Gemの代わりにGitHubから直接requireする方法 - Hello, world! - s21g
Gemを作るのが面倒になってきたので、githubから直接requireできたら楽になるかもしれないと思い、試してみました。 1 def git(uri, sha1, options = {}) 2 require "tmpdir" 3 basename = File.basename(uri) 4 outdir = File.join(Dir.tmpdir, basename, sha1) 5 unless File.exist?(outdir) 6 sh = proc{|command| IO.popen("#{command} 2>&1"){|io| io.read}} 7 sh["git clone #{uri} #{outdir}"] 8 sh["cd #{outdir}; git checkout #{sha1}"] 9 end 10 $:.unshift
git rebaseって超便利じゃね？ - Seasons.NET
Gitでとても便利だと思っているのが、rebaseというコマンド。 ブランチを切った時点からオリジナルは刻一刻と変化していくわけで、 自分のブランチはあくまで現在最新のオリジナルに対するパッチである 必要がある場合は、このrebaseというコマンドを使って、オリジナル(HEAD)と マージすると、最新のオリジナル(HEAD)に対して、ブランチを切ったことになります。 これチョー便利じゃね？ 以下、git-rebaseから引用 git-rebase を使用して一連のパッチを最新に保つ リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、幾つかコミットを作成したとします： $ git checkout -b mywork origin $ vi file.txt $ git commit $ vi otherfile.txt $ git commit ... m
gitのブランチ名をプロンプトに表示すると結構便利 - （ひ）メモ
gitの配布物に含まれる contrib/completion/git-completion.bash を . すると、gitのサブコマンドやそれに応じたオプション、加えて~/.gitconfigで自分用にaliasしたサブコマンドまで補完してくれるようになり、小学生もにっこりです。 同じく git-completion.bash の中で定義されてる関数 __git_ps1 を使ってシェルプロンプト($PS1)を設定すると、 #... if [ -r "$HOME/.bash_completion.d/git" ]; then # = git-completion.bash # boldにするエスケープシーケンスは省略してます PS1="${PS1}[\$(__git_ps1 \"%s)\")\w]\\$ " else PS1="${PS1}[\w]\\$ " fi #...こんなふうにg
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Add syntax highlighting to gh-pages
Accueil
GitHub - airportyh/Tutti: Interactively run Javascript on multiple browsers
United States
SitePoint Blogs » JSON-P output with Rails
IDEA*IDEA 〜 とあるサービス運営者が学んだことをまとめるブログ