Git+Redmine+チケット駆動開発のワークフロー
サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ ビジュアル的にも丁寧でよくまとまっている デザイナのための Git コマンドの要点がまとまったガイド gitの基礎 (全22回) - ドットインストール ドットインストールのスクリーンキャスト Git - Book - いわゆる Pro Git Git - Book - 日本語訳もある Pro Gitの日本語版PDF等 Gitのセットアップ - homebrewをフォークするためのGit&GitHub入門 前編 - A Way of Code GitとGithubのセットアップ ブランチもマージも簡単な分散型バージョン管理システム はじめてのGit - WEB+DB PRESS Vol.50 WEB+DB PRESS 総集編 に含まれてる
kanazawa.rb meetup #1 に参加してきた
参加してきたっつーか、まぁやるって決めたの自分なんだけど。 Meetup #1 - Kanazawarbkanazawa.rb meetup #1 : ATNDkanazawa.rb beerup #1 : ATNDIntrointroを英語プレゼンにしたら会場のボルテージが上がるのではないか？ meetup ってなんか英語っぽくね？ 「ぽかーん」「ぷーくすくす」「ア…ア…」 大失敗orz 全体的な準備正直ものすごく手間が掛かった。始まってみたら想像以上の人数で余計なこと考える必要ない状態だったので、まぁ結果オーライなんだけど。さすがにatndの管理、お店の予約、施設の予約、あれこれissue起こして自分の発表2つ分のスライド作って…、ってのはもう二度とやりません。これは絶対に持続できない。 あとあえて出欠確認表を現地で印刷しようと思ってPDFだけ作ってノートPCに入れたままの状態で持って
chef-solo で環境構築を自動化する練習メモ - present
はじめに さくら VPS に Rails アプリをデプロイするために、Nginx や MySQL やらインストールしてみたけど、同じ作業を VMware Player+CentOS でテストするときにやるかもしれない。さらには、将来 Amazon EC2 を使うときにも。今から環境構築は自動化しておいた方がよさそうだ。 chef を使ってみる chef といっても、chef-solo だけど。chef-client/chef-server は導入が超面倒なので。その点、chef-solo はスタンドアロンで動くから導入が手軽。 パッケージのインストールだけなら rake や capistrano でもできるけど、設定ファイルを配置したいし、chef でいく。 chef をインストール CentOS では既に rbenv + ruby-build を使って Ruby1.9.3 をインストール
chef-soloで環境設定 — そこはかとなく書くよん。 ドキュメント
chef-soloで環境設定¶ chefはサーバ構成管理ツールです。構成を設定ファイルとして書き残しておき、 chefを実行すればそのとおりにサーバを構築してくれます。また、何度実行し ても同じように構築してくれますし、サーバ構成をいじったとしても修正して くれます。 というわけで、chefを使ってみたのでそのメモ。 事前準備¶ chefはrubyで作られていますので、rubyが必要です。また、chef自体のインス トールにはgemが楽ちんです。 chefにはサーバなどがありますが、今回は単独で実行できる chef-solo のみ を使います。 雛形作成¶ 後述するcookbookなどの雛形を作ってくれるRakefileがopscodeのサイトにあ ります。 githubのopscodeから取ってきます。 この構成をそのまま使うのが吉です。また、ここにあるRakefileを使うことで、 c
chef-soloを使ってみる - A Peak Never Ending !
そろそろ本腰いれてchef使ってみようかなと思ったのでちょっと試してみる。 ちょうどさくらのVPSを2つ借りてて、bashからzshに移ろうかな〜と思ってたのでこいつをchefでやってみる。 chefは一言でいうとrecipe(設定のルール)を作ってrole（どのcookbookを使うか)をnode(管理対象ホスト)に割り当てるって感じみたい。 クライアントだけで動かすchef-soloと管理用のサーバを用意するchef-serverとがあるみたいだけど、 chef-serverはもっぱら面倒という噂を聞くのでchef-soloを使ってみた。 zshをchefでインストール インストールして雛形を取ってくる。ちなみにrootでやらかしてます。
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
CentOS6 OpenVPN のインストール（tap L2接続） - わすれないうちにメモしよう
前準備 http://d.hatena.ne.jp/kt_hiro/20120821/1345555381 インストール # yum install openvpn bridge-utils 鍵や設定ファイルの作成 http://d.hatena.ne.jp/kt_hiro/20080120/1200767220 設定ファイルの作成 # vi /usr/local/etc/openvpn/openvpn.conf proto tcp dev tap ca keys/ca.crt cert keys/server.crt key keys/server.key dh keys/dh1024.pem server 192.168.200.0 255.255.255.0 ifconfig-pool-persist ipp.txt port 1194 client-to-client keepal
[CentOS6.2] yumのprioritiesプラグインを追加するの巻
prioritiesプラグインは、yumが利用するレポジトリにプライオリティ(優先順位)を設定することでレポジトリを保護することができます。高いプライオリティが設定されたレポジトリからインストールされたパッケージは、低いプライオリティが設定されたレポジトリを用いて更新されることはありません。また、新規パッケージをインストールする際に複数のレポジトリにて該当するパッケージがある場合、高いプライオリティの設定されたレポジトリからのインストールが優先されます。このプラグインは、特にCentOSのレポジトリに加えて外部の他レポジトリを利用している場合に、外部レポジトリの利用によりシステムファイルが書き換えられサーバの運用に影響を与えることを防ぐことができます。 yumのprioritiesプラグインのインストール方法CentOS-4 or CentOS-6 # yum -y install yum
![[CentOS6.2] yumのprioritiesプラグインを追加するの巻](https://cdn-ak-scissors.b.st-hatena.com/image/square/e0b501d4005aa501f5d887e660d0c377e6e4aa47/height=288;version=1;width=512/https%3A%2F%2Fblog.trippyboy.com%2Fwp-content%2Fuploads%2F2012%2F07%2Fcentos-logo-150x150.png){kind=logo}
俺史上最強のiptablesをさらす - Qiita
#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :
chef-soloで作業環境構築の自動化 - ひげろぐ
さくらのVPSを契約して放置しておいたままだったので、これを機に環境構築をしてみることにした。 なお現状はユーザーakahigeの追加とsshの設定だけ済ませた状態になっている。 すべての設定はChef経由で行うこと というルールでChefで同じ環境をいくらでも作れるものを目指してみよう。 Chefサーバーのセットアップはめんどくさいのでchef-soloでがんばる所存。 Rubyのインストール とはいえChefの動く環境はChef以外で作らないといけない。 このあたりを省略するならシェルスクリプトによる自動化か、Chefが動くところまでセットアップした仮想マシンのイメージを使うほかなさそうだ。 必要なパッケージのインストール $ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.r
kousyoublog.jp – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
Chefを最速で使いこなすためのいくつかのポイント - Masatomo Nakano Blog
前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。 前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。 ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！ client vs node Chef Client Nodes ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。 client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて clien
さようならPuppet、こんにちはChef - Masatomo Nakano Blog
ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。 Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。 基本的な仕組 これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。 rubyな設定ファイル Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので
概要 - tily - Opscode Open Source Wiki
"Chef は小さなシステム管理ロボみたいだ… どんな風にシステムを設定してほしいか教えてやれば、あとは面倒な仕事はすべてやってくれるよ」 ーー Chef ユーザ Chef はオープンソースのシステム統合フレームワークであり、特にクラウドを自動化するために作られています。 現実の問題がどんなに複雑であろうと、Chef を使えばインフラに関するすべての場面で、サーバをデプロイしたりアプリケーションをスケールさせたりすることが簡単になります。 Chef を利用するなら、インフラの各パーツがどんな風に作られてほしいのか、抽象化されたソースコードの形で定義し、それからその内容をそれぞれのサーバに適用する、という流れになります。 その結果は完全に自動化されたインフラです：新しいサーバが用意されてきたときでも、そのサーバがアーキテクチャの中でどんな役割を果たすのかを Chef に教えてやるだけで済
New Ways of Visualizing the Customer Journey Map | Adaptive Path
[Credit: Evan Litvak ] Evan chose to represent his journey as a circular graphic instead of the more common linear or chart structure. As the field of service design evolves so do the tools. At Adaptive Path we often find ourselves debating the form and definition of service design artifacts. I was curious to see how a new crop of interaction designers might interpret the journey map. Luckily I ha
「DevOps」は技術ではなくムーブメント。開発と運用の信頼関係が不可欠
この記事は、日経SYSTEMS 6月号に掲載された連載「新野淳一の技術インパクト」第4回のオリジナル原稿をPublickey掲載用に編集したものです。Publickeyでは日経SYSTEMS編集部との合意を得て、雑誌発行から一定期間後に記事をPublickeyに掲載しています。 あるソフトウェアが利用者に価値を届けるには、そのソフトウェアのコードを正しく開発することと、開発されたコードが能力を発揮するように適切に実行、運用することの両方が必要だ。 これまでのIT業界では正しくコードを開発することが重視され、運用は軽視される傾向にあった。それは一般に、顧客への成果物としてコードの品質が最重要であることに起因した。 クラウドがこの状況を大きく変えつつある。クラウドによってソフトウェアがサービスとして提供されるようになると、コードに実装された機能、性能と同等かそれ以上に、快適な応答速度を実現して
git commit はもう古い! Guard でテストをはしらせた後に自動コミットする guard-notifier-git_auto_commit - tomykaira makes love with codes
tomykaira/guard-notifier-git_auto_commit@kyon_mm さんの https://gist.github.com/2873062 に inspire されてつくった。 rubygems からダウンロードできる。Ruby, Rails では開発環境での自動くりかえしテストに guard がよく使われている。 この guard の通知部分に git commit するものをしこむことで、テスト結果に応じてコミットを打つ。 作業が終了したら git rebase で歴史を綺麗にする。 (Stacked Git というものもあり、なかなかよさそう) 既知の問題点 guard のソースがなかなかひどい。設計理念がよくわからない。 ruby で適当に書きましたなにおいがする。 ビルド失敗とテスト失敗の区別がない。 Spork を使っていると、 Spork
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
Tumblr