GitHubKaigi資料公開「GitHub実践入門は活用するためのガイドブック」 | Act as Professional
GitHubKaigiに登壇しました。その際の資料を公開します。 当日はLiveStreamの調子が良くなかったようなので、期待して頂いていた方、ご迷惑をおかけしました。後ほど動画が公開されるはずです。（公開され次第こちらにリンクも追加する予定です。） GitHubを利用した開発の世界(日常)を知る GitHubを(利用|活用)する違いを知る GitHub実践入門はガイドブックGitHubを日常的に使ってない人もいるので、その日常の風景を想像できる話しをしました。 また、使っている世界の中でも、使っているだけの人と十分に活用できている人や状態を解説しました。 GitHubを使っている人達が、いち早く十分に活用できるようになるために体型系的な知識を「GitHub実践入門」にまとめました。個人的には多くなエンジニアにGitHub利用している状態や、活用している状態になって欲しいです。 そのため
dockerが正式サポートしたOS Xの環境を構築してみた！ | Act as Professional
正式サポートの概要DockerはこれまでもOS Xの上で動かそうと思えば、動かすことはできました。これはOS Xの上でVagrant（実稼働しているのはVirtualBox）などを利用した仮想マシンで通常のUbuntuやCentOSなどのLinuxを立ち上げて、そのLinux環境の中でDockerを稼働させるというものが中心でした。もちろん公式サポートはされていませんでした。 これはDockerそのものがLXC (Linux Containers) と呼ばれるLinuxのOSレベルでの仮想化技術を利用したものなので、Linuxの上でしか利用できなかったからです。よって、バージョン0.8からもOS Xの上でネイティブに動作するわけではありません。 では、どのようにして正式サポートしたのかというと、Dockerが専用の軽量仮想マシンイメージを用意し、OS Xからこの仮想マシンに対してDocke
vagrantで開発環境（仮想マシン）を自動構築しよう | Act as Professional
Wii起動したらドラクエX鯖が死んで何もできなかった@HIROCASTERでございませう。 インフラ環境の自動構築は、もはや当たり前ですよね？ vagrantというVirtualBoxをラップして、chefやpuppetを利用したVMの環境自動構築をしてくれるソフトウェアがあります。 これを利用して、開発環境のセットアップを自動化すると共にVM化して、すぐにコードを書くことだけに集中できる環境を構築する状態をつくっておくことを推奨します。 プラグインを利用すれば、vagrantを通してAmazon EC2への環境構築を自動化したchefやpuppetのコードを再利用できます。 小さい環境であれば、chef-soloを利用して単独で環境構築自動化をオススメします。試しにインフラ構築の自動化を学ぶのにも今回の様な環境で学習してみてはいかがでしょうか。 vagrantのインストールgemを利用し
jenkins エレガントなコードを書くための執事のすすめ | Act as Professional
勉強会したので、資料公開。 jenkinsを使って、自動テストだけでなく静的コード解析や統計情報をおこなって、ケント・ベックが提唱した「コードの臭い」を察知して、リファクタリングのタイミングや具体的な指摘のフィードバックを自動で得ようというお話。
これからGitHubを始めるチームが準備したり考えたりすべきこと | Act as Professional
Gitのメンテナーである濱野さんが書かれた本がオススメ。 お金を出すのが惜しい人は Pro Gitあたりで、学ぼう。 「githug」でgitの基本操作を算数ドリルみたいに学ぼう！githugなどで実際に手を動かしながら学習して身につけましょう。 個人的にはGitはコンソールから実行するのが一番シックリ来ています。 .gitconfiggitの設定を徹底的にきちんとしておくこと。 あたりで知識を補完しながら .gitconfigに設定してるaliasなどのまとめ – ゆるよろ・オブ・ザ・( ;ﾟ皿ﾟ)ﾉｼΣ ﾌｨﾝｷﾞｨｨｰｰｯ!!! 日記あたりの実際に使用している人の設定を参考にすると、スタートダッシュできる。 ブランチ戦略ブランチ戦略をきちんと立てないと、カオスになるので、考えよう。 見えないチカラ: A successful Git branching model を翻訳しました“A
Git,GitHub,Jenkins,Emacs,Vimが1冊で学べる 開発ツール徹底攻略 | Act as Professional
GitHub特集記事を再編集した@HIROCASTERでございませう。 4月10日(水)にWEB+DB PRESS Vol.69に寄稿したGitHub特集記事を再編集して開発ツール徹底攻略 (WEB+DB PRESS plus)が発売されます。 1冊で現役の開発者が愛してやまない開発ツールの最新事情と利用方法が学べる1冊に仕上がっています。 4月に入って新しい会社や学校で開発をはじめる方多いかと思います。そんな方に、ぜひ手にとって頂きたい1冊です。そういった方達を教える立場にある方も、参考資料として利用して頂ければ幸いです。 これ1冊で Git GitHub Jenkins エディタ(Vim/Emacs) Linuxの基礎知識の最新の状況と設定、利用方法まで学ぶことができます。少ない時間で、開発ツールを使うまで学ぶのにはとても効率的でオススメです。2,000円でお釣りがきてしまうので、ぜひ
Vagrant 1.1リリース、VMware Fusion, EC2, Rackspace が新たに対応 | Act as Professional
Vagrant 1.1リリース、VMware Fusion, EC2, Rackspace が新たに対応 リリース早かったなぁと思う@HIROCASTERでございませう。 Vagrant 1.1 がリリースされました。 今回の変更点はとても大きなものであると感じています。そして、開発者にとって、素晴らしい機能が追加されました。 Vagrant は VirtualBox のラッパーとして機能し、VMの立ち上げや管理からpuppetやchefで記述された内容に基づくプロビジョニングをおこなってくれます。 これは、Proxyサーバ、Appサーバ、DBサーバなど複数台構成の開発をおこなっている開発者のローカル環境で、複数台のVMを本番さながらの構成で稼働させるためには非常に重宝されるツールでした。プラグインの対応で、VirtualBoxだけならず、AmazonのEC2を操作することができました。
git 1.8.2 リリースノートを眺めて、新機能把握と設定を追加 | Act as Professional
世の中はGoogleリーダーで盛り上がってる中、Livedoor Readerに移行した@HIROCASTERでございませう。 そんななか、ひっそりと git 1.8.2 がリリースされました。 リリースノートを眺めていたら知らない機能があったので書いておきます。 git check-ignore * “git check-ignore” command to help debugging .gitignore files has been added. 1.8.2からの新機能です。 .gitignore ファイルに記述されてい内容と実際のファイルが該当するかチェックできます。 例えば .gitignore ファイルに /tmpと書いたとします。 $ git check-ignore -v ./tmp .gitignore:1:/tmp ./tmpのように1行目の設定に該当して、exclu
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
あの「ウノウ」って会社を覚えてますか？ | Act as Professional
元ウノウな@HIROCASTERでございませう。 それはそれは、ちょっとだけ昔の話、とても風変わりなウノウ株式会社というのがありました。 ウノウという会社の昔話をしたいと思います。 ウノウラボのラボブログこの会社がはじめた画期的な文化の1つは、ラボブログと呼ばれる在籍するエンジニアが直接技術情報をブログとして公開するというものだ。 今では業界各所でおこなわれていることだが、当時は在籍するエンジニアが顔と名前を出して、技術情報を惜しげもなく公開することに注目された。 このブログの読者も、当時はウノウラボのブログをよく読んでいた人もいるのではないだろうか。 ウノウの歴史ではかなり後半の2010年になるが、私もウノウラボを執筆できたことが嬉しかったです。 もちろん、ブログを書く時間も業務時間として認められていました。 勉強会で会場を提供するなどの取り組みなど、今となっては常識となりつつあるような
ソースコードレビューをするにあたって、参加者が心得ておくべきこと | Act as Professional
前回はコードレビューを始めて組織で行うために、具体的にどうやって行くべきか？そして、加速させるためにどのように実施していくべきかについて考えました。 そして、今回はコードレビューという貴重な機会と時間の価値を最大化させるためのポイントがあります。 このポイントを意識して望むことにより、より効果的なコードレビューとなるでしょう。 ぜひ、これからコードレビューを始めるチームは共有してみてください。 懐疑的な視点に立つレビュー対象に対して懐疑的な視点に立って、レビューをおこないましょう。 上司のコードだから、先輩のコードだからといって、楽観的な視点でのレビューは、コードレビューという機会の価値を下げます。 プロダクトの品質が悪くても、レビューに報いるどんなにプロダクト（製品）の品質が悪くても、1人のプログラマーとして、あなたはコードに実直に向かい合い、レビューに対して報いるべきです。 評価しない
はじめてのコードレビューは、どうやって始め、加速させるのか？ | Act as Professional
前回はコードレビューを始める動機や始めるために必要な心得について考えました。 今回はこれからコードレビューを始める組織が、どのようにして具体的にはじめて行くべきなのかを考えます。 コードレビューが定着していない人達がどのようにして、コードレビューを始めるべきでしょうか？ まずは、コードレビューをやってみるまずは、重圧などはかけずに、気軽な気持ちでやってみてください。今回は「はじめること」が目的です。 コストの高い準備や学習はしない使い慣れたコードレビューツールがあるれば、それを利用してやれば良いでしょう。なければ、既存のIDEやエディタをプロジェクタで投影しながらやれば良いです。とにかくツールを覚えるコストや準備するコストは、なるべく省きましょう。フットワーク軽くはじめる事が重要です。 実際にやってみることによって学ぶ姿勢コードレビューをやった経験が十分にないのですから、最初はグダグダにな
これからソースコードレビューをする人達へ向けての心得 動機編 | Act as Professional
コードレビューについて勉強してみた@HIROCASTERでございませう。 コードレビューについて古い資料をあさり、学んで、経験と照らし合わして、書いていきたいと思います。 今回は、これからコードレビューを実施していきたいという人達に向けて、コードレビューをする動機と、どこからやるべきなのかという視点を考えます。 ソフトウェア開発において、多くの問題はコードを起因にして起きます。そのため、多くのプログラマー達がコードレビューをしようと考えます。これは良くある会社の光景ではないかと思います。そして、コードレビューをする出発点となります。 医者が患者に苦悩を伴ってもらわないと、大病が治らないのと同じように、プログラマーが苦悩を伴ってもらわないと、ソフトウェアの大きなバグや致命傷は治りません。 よって、コードレビューは 苦悩が最大と思われるところからレビューを始めよ。 といわれます。 重圧が大きい
コードレビューツール 6選 どれが最適？ | Act as Professional - hiroki.jp by HIROCASTER
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
プロとしての行為 Act as Proffesional
Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応
TDD(テスト駆動開発)を学ぶための動機になる話 | Act as Professional
TDDがアジャイル開発では前提ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテストリファクタリングテスト駆動開発（TDD）継続的インテグレーションこれら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニア一人一人
1日に175回もGitHubはデプロイしているだとぉ…！？ | Act as Professional
GitHubは普通の会社とどう違うのか？ リリースマネージャーがいない（いる必要がない） 週次のデプロイセットもありません（この週にこれだけの機能をまとめてリリースとかがない） 開発者とデザイナーは、早く提供できるように自分たちでデプロイする（できる）作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[資料] Jenkins + GitHub in 第6回テックヒルズ | Act as Professional![[資料] Jenkins + GitHub in 第6回テックヒルズ | Act as Professional](https://cdn-ak-scissors.b.st-hatena.com/image/square/5982ec5d456c2a9dfea45b84e23982e769f0800f/height=288;version=1;width=512/https%3A%2F%2Fhiroki.jp%2Fwp-content%2Fuploads%2F2013%2F06%2F20e9e04b1540e442fafaea0a16963b8f.jpg)
資料公開「あたりまえのアジャイル と その先の世界」 | Act as Professional
【無料】NoSQLデータモデリング技法に関する資料（日本語訳） | Act as Professional
