気づくと1週間経っている恐怖(´ω`) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム(現在は3人)で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
こんにちは、chatiiです。ちょっとまじめに記事書きます。 FuelPHPでけっこう(chatiiとしては)規模の大きい案件がきたので、開発環境をキチっと決めたいと思いました。その中で、今まで手作業でやりつつ、「これ自動化できるだろ」っていうところがあり、今回うまくいったのでご紹介。ちなみに、今回はFuelPHPは関係ないです。 開発会社さんから見たら普通のことなんだろうなぁ。野良プログラマーPHPerだからせけんしらず。 環境・条件 ソースコード管理はGitHub ひとりなのに!ひとりなのに! LAMP構成 開発マシンにはXAMPP/MAMPを入れる。Linuxの場合はyum/aptで取得。 サーバーは 本番サーバー(www.hoge.com) テストサーバー (hoge.dev.example.com) テストサーバーは他人がアクセスできないようにね 他のプロジェクトもテストします
新サービスが続々登場してアツい! 「GitHub」とは 皆さんは「GitHub」を活用しているでしょうか? 「GitHub」(ギットハブ)はソースコード管理用の分散型バージョン管理システム「Git」を使ったホスティングサービスです。 Gitの特徴は、作業用として自分のコンピュータ上にあるローカルリポジトリがあれば、ネットワークに接続できない状態だったとしても、ソースコードの更新や、履歴を調べたりできる点にあります。その特徴はGitHubにも生かされていて、オープンソースとして公開中の既存のコードを分岐(fork)して、新しいプロジェクトとして開発できます。 また、自分が手元のローカル環境でバグ修正したり、拡張したソースコードを本家のオープンソースプロジェクトに取り込んで(pull)もらうことも手軽にお願いできます。 さらに、READMEテキストファイル(README.md)などを独特のマー
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
GitHubで人気レポジトリのランキングが公開されているようなので全解説してみました. どれも素晴らしいものばかり! あなたのプログラミングライフを快適にしてくれるライブラリがきっと見つかるはず!! rails rails 9835 watching Ruby on Rails. 説明不要だよね! フルスタックWebフレームワーク jquery jquery 8710 watching JavaScriptライブラリ.これも説明いらないよね! node joyent 8572 watching 旧名node.js.昔の名前の方が通りがいいです.JavaScriptエンジンのV8用のノンブロッキングIOな何か.主にWebサーバ/アプリケーションに使われる. html5-boilerplate paulirish 6998 watching HTML5とかのテンプレート集.ただし公式ページのデ
ここ1年くらい、僕はソースコードなどを github で公開しています。 つい先日まで書いていた連載記事 GAE for Flasher のサンプルソースコードや、 東京てら子で発表したデモ、今まで作ったライブラリや便利クラスなど なんでもかんでも github で公開しています。 しかし、プログラムに慣れた人ならともかく、これから AS3 をガシガシ勉強していこう! といった方や、AS3 自体はガシガシかけても基本的に SVN 等バージョン管理システムを 使わない方にとっては github 自体がやはり少し敷居が高いイメージがあるという話を聞きました。 GAE for Flasher の記事自体、ある程度 AS3 に関する知識のある人を想定していたとはいえ 流石に当たり前のように使い過ぎたかなと反省の意を込めて github 超入門( for Flasher ) を書く
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
James Khatiblou, the owner and CEO of Onyx Motorbikes, was watching his e-bike startup fall apart. Onyx was being evicted from its warehouse in El Segundo, Los Angeles. The company’s unpaid bills were stacking up. His chief operating officer had abruptly resigned. A shipment of around 100 CTY2 dirt bikes from Chinese supplier Suzhou Jindao…
「クラウド」って言ってみたかった。今は反省していr 上のグラフは前回のエントリーを公開したときの、当blogを配信しているサーバのトラフィックグラフです。記事を公開した17時にぴょーんとトラフィックが伸びています。4時にも増えているけどこちらは謎。 実はこのグラフもCloudForecastを利用して取得しています。CloudForecastはサーバ等のリソース監視を行うツールもしくはフレームワークで、rrdtoolの薄いラッパーとして動作し、小規模から大規模なサーバ群を一括で管理できるように設計してあります。tokuhirom曰く、「perlが書けてrrdtoolがつかえるsysadminの人だったら使いやすいと思われる」というのがもっともしっくりくるような気がします。Perlとrrdtoolが使える運用者によるカスタマイズ前提なのがフレームワークと呼んでいる所以です。 CloudFor
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く