レポートの書き方(Jenkins勉強会レポート編)

http://blog-imgs-19.fc2.com/a/p/g/apg/201204055.jpg

「明日からがんばろう」という発想からは・・・どんな芽も吹きはしない・・・・・・・・・・・!
そのことに20歳を超えてまだ・・・わからんのか・・・・!?
明日からがんばるんじゃない・・・・・・・・
今日・・・・・・今日「だけ」がんばるんだっ・・・・・・・・・・・・!
今日をがんばった者・・・・・・・・・・・
今日をがんばり始めた者にのみ・・・・・
明日が来るんだよ・・・・・・・・・・・!

Jenkinsユーザカンファレンスと直後の第1回福岡Jenkins勉強会も無事終わって、「明日からユーザカンファレンスのレポート書こう」と思ってたうちにお盆休みになってしまってガクゼンとしているikikkoです。こんにちは。

今必死に発表スライドと録画されたやつを聞きながらレポート書いているのですが、レポート書くときにどんな構成でどんなことに気を使って書いているかをちょっとだけ紹介したいと思います。あくまで僕はこんな感じでやってますというだけで、他の人がどうやってるかは知りませんし、これが一番ベストとかも思ってませんので。

ちなみに、今まで書いてきたレポートは、以下のところで掲載させてもらっています。基本は、後述する流れに沿うように書いているので、どなたかの参考になれば。


レポート作成の流れ

  1. レポート用のファイル用意したり、色々下準備(30分)
  2. 発表スライドや当日のUstを見ながら、発表の構成要素を洗い出す(1時間〜1時間半 × 発表数)
  3. 構成要素を元に、文章として清書する(1時間 × 発表数)
  4. 見直し(30分)

こんな感じなので、平日帰宅後だとまあ1週間、週末だと土日作業になってしまってます。もうちょい早く書けるようになりたい気も。

レポートの段落分け

  1. 発表者紹介(1文)
  2. 写真
  3. 発表内容(3~5文)
  4. 意見(2~3文)

文章数を↑に揃えようとして、重文複文が多くなって、1文が複雑になってしまいがちなのは、ちょっとあれです。通常は、1文1文の主語述語が分かりやすいよう単文の方がいいと思うし、他の場所でドキュメント書くときはそうするよう心がけています。

発表内容と意見

発表内容部分では、主観は入れずに事実のみを客観的に説明するようにしています。逆に、意見部分は、個人の意見をちゃんと盛り込むように。

発表内容のところは、どうしても過去形が多くなりがち(〜しました、〜でした)。文末が一緒だと(小学生の夏休みの日記みたいになって)文章が幼稚に見えるので、あの手この手でちょこちょこ変えてるけどちょっとツライ。

意見部分は、レポートで一番大事だと思ってる部分です。発表をなぞるだけのレポートならスライド見たり当日のtwitterとか見てればいいので、それ以上のものを提供できるようにというのは心がけています。もちろん、個人的/主観的な意見ですよというのが分かるように、↑で説明したように段落も分けてます。

あと、意見部分では自分の意見と共に、発表内容では触れなかったけど関連することも積極的に参考情報として入れるようにしています。勉強会参加した人が後からレポート読んだときにも参考になるようにという願いも込めて。

レポートの媒体

前まではWikiに書いていたけど、最近はSphinx。ちなみに、Jenkinsで生成したファイルをBacklogのファイル共有に転送する | Nulab Tech Blogをローカルマシン上で動かしています。

別件でHTML上のドキュメントを直接編集する機会もあったけど、デザインの方に気を取られて文章がなかなか書けない。その点ではWikiの方がまだマシなんだけど、保存のタイミングとかがちょっとあれな感じ。やっぱりSphinxのように、ローカルのテキストファイルで書いておいて適宜保存、きりのいいタイミングでcommit/pushして公開するってのがリズム的にもいい気がしてます。

文章の体裁

そこまで重要視してないけど、体裁的なところはこれぐらいは気をつけてます。

  • ですます調
  • 名称は氏で統一
  • リンクは最初だけ貼って、以降同じものが出てきたときは貼ってない

CentOS 4/5のvagrant用boxを作ってみたよ

某人が博多に移籍したのをきっかけに、僕も何とか博多に移籍できないかを四六時中考えてるikikkoです、こんばんは。博多限定のぶっとびカードないかなー。

http://tamavoi.up.seesaa.net/image/200808201751000.jpg

今日は、最近なんか使えないかなーと思って見てるVagrantで、CentOS 4/5系を使いたかったので、それの準備としてboxを作成してみました。なお、Vagrantの概要については、@ さんのブログとかでも見てください。


主に、後半のCentOS 4系のところが、目新しいところです。ただ、今更CentOS 4の情報が必要な人がどこまでいるかという話ですが。。。

なお、今回作った設定ファイルはGithubにpushしておきました。

環境構築

boxの作成には、VeeWeeというやつが必要みたいです。ちなみに、環境構築〜CentOS 5系の作成は Vagrant & VeeWee を再設定してCentOS 6.2のBoxを作成してみた - wadahiroの日記を参考にやれば、ほぼほぼ問題ないと思います。

CentOS 5.8

上記の参考リンク通りにやれば、特に問題無し。

CentOS 4.8

対応しなきゃいけない箇所は、主に2点です。

yumリポジトリの有効化

postinstall.sh 中でいくつかパッケージをインストールする箇所があるのですが、CentOS 4系は既にEOLなので、そのままではyum updateができません。なので、yumを実行する前に有効なリンク先に向けておくように、下記シェルスクリプトを追加しておきましょう(参考:yum updateできなくなった古いCentOSでyumコマンドを復活させる方法 - Dマイナー志向)。

#enable repos which is now EOL
cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.orig
sed -i "s/^mirrorlist/#mirrorlist/g" /etc/yum.repos.d/CentOS-Base.repo
sed -i "s/^#baseurl/baseurl/g" /etc/yum.repos.d/CentOS-Base.repo
sed -i "s/mirror.centos.org\/centos\/\$releasever/vault.centos.org\/4.9/g" /etc/yum.repos.d/CentOS-Base.repo
ストレージの設定変更

初期設定ではSATAに仮想ディスク(vdi)が割り当てられていますが、これだとOSのインストール時に失敗するので、IDEに割り当てる必要があるようです(参考:VirtualBoxでディスクエラーになる場合の対処法(SATA→IDE) - 走り続けたい社内SEブログ)。ただ、設定ファイルでIDE側に割り当てるやり方がわからなかったので、今回は作成中にいったん止めて、手動で設定変更した後に再度起動するというちょっとあれなやり方でやりました。

  1. "vagrant basebox build" で作成開始
  2. kickstart用の設定ファイル(ks.cfg)の待ち受け中に、VM終了
    • 待ち受け中
      • f:id:ikikko:20120701024828p:plain
    • ssh login待ちまでいったら駄目なので、再度やり直しましょう)
      • f:id:ikikko:20120701024843p:plain
  3. VMの設定>ストレージで、SATAからIDEのプライマリ・マスターに変更
    • 設定前
      • f:id:ikikko:20120701024602p:plain
    • 設定後
      • f:id:ikikko:20120701024627p:plain
  4. ks.cfgの中の"sda"となっている部分を"hda"に変更
  5. VM起動
  6. ブート時のコンソールで下記を入力(環境によっては、IPアドレスが変更されるかもしれない)
linux text ks=http://10.0.2.2:7122/ks.cfg


インフラ系の知識とか、VeeWeeで使われているRubyがよく分かっていないので、ちょい手間取りました。Chefもあるし、Rubyは覚えておいて損はないのかなー。

はてなブログに移行しました

最近あまりブログまで手が回っていないけど、はてなブログに移行してみました。

細かい使い勝手はまだ分かっていません。が、移行に関しては特に問題起きてなさそうに見えますし、問題が起きたらロールバックできる手順とかもろもろ親切だと思いました。こういうところは、ユーザの安心感に直結するところだから、ちゃんとしていると好感がもてていいですよね。僕も見習っていきたいと思います。

取り急ぎ、移行しましたよ報告まで。

このGW中にやったこと

何かブログ書いてないなー。そして今年のGWも安定のヒキコモリ。まともに外に出たのは、近くのファミレスに行ったぐらいだけ。GW前から体調悪いのが、まだ完調していないし。色々すいません・・・>全方位

とりあえず、このGWにやったことをざっと書いておきます。今回は、新しく何か作ったりする系は押さえて、どちらかというと基礎力を高めることに注力しました。4月に仕事の環境変わったので、それに追随していくための基礎固めです。


AWS

周りがプロばかりなので名前だけは十分過ぎるほど聞いてたのですが、何となく後回しになってたやーつ。さすがに避けれそうになくなってきたので、今回やってみました。

もう1年近く前にWeb+DBに@と@が書いた記事を元に、とりあえずはチュートリアルから。EC2のインスタンス立ち上げて止めて、elastic IPとさらに独自ドメイン割り当てて、S3に保存したりとか。

WEB+DB PRESS Vol.62

WEB+DB PRESS Vol.62

  • 作者: cho45(さとう),染田貴志,浜本階生,おにたま,中島聡,角田直行,はまちや2,山本竜三,尾藤正人,石橋利真,ミック,みやけん,個々一番,広木大地,原悠,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2011/04/23
  • メディア: 大型本
  • 購入: 14人 クリック: 1,332回
  • この商品を含むブログ (23件) を見る

その後は、Jenkins EC2 Pluginを試してみました。ただ、Amazon LinuxのAMIだといまいちうまくいかない感じ。EC2 Pluginがrootでログインすること前提で作られているっぽく、"remote user=ec2-user"や"Root command prefix=sudo"を設定してもだめぽ。sshd_configのPermitRootLoginをyesにするとうまくいくようになりましたが、なんだかなーってところです。

とりあえず今すぐ使う予定もないので、これ以上は置きで。何かあったらもうちょい深いところまでみようと思います。

zsh+tmux

デフォルトのbash+Terminal.appでやってきたのですが、これまたそろそろ限界がきたので、この機会にCLI環境を整備しようと思いました。周りはscreen派?みたいですが、今からやるならtmuxの方がよいという風の噂を受けて、tmuxで。

とりあえず、インストールしてざっと触れました。後は、@が言ってた「コマンド一発で複数のホストにSSH接続する」というシェルスクリプトがよさそうだったので、tmuxのコマンドと組み合わせて作ってみました。引数で指定したホスト(複数可)ごとにウィンドウを作成してssh接続するスクリプトです。

ちょっとぐぐったけど、意外とありそうでなかったんですよね。なので、もっと簡単に!tmuxで複数のサーバにSSH接続して同じコマンドを一気に送る | 三度の飯とエレクトロンを参考に作ってみました。他にもっといいやり方とか、そもそも別のツールがあるのかな?あったら教えてください。

rsync

実は触ったことなかったんで。↑で作成したEC2上のインスタンスを対象に、初回バックアップ -> 2回目バックアップ -> 復元ぐらいを。あまり細かいとこは触れずに、さらりとです。

Jenkins業

Jenkinsユーザカンファレンスのタイムテーブル作成中です。来週か再来週ぐらいには公開したいと思っているので、もうしばらくお待ちください。

ちなみに、Jenkins ユーザ・カンファレンス 2012 東京 - connpassも初日こそ300人/日という驚異的な記録をたたき出したのですが、最近あまり伸びてませんね。ただいま600人弱。タイムテーブル作成中にキャパを簡単に算出してみたら、計算上1300人弱は入る見込みです。倍くらいまではいけるので、みなさんこぞってご参加を。


あと、もうちょっとやりたいことがあったのですが、間に合いませんでした。あと数時間GWが残っているので、いけるところまで頑張りたいと思います。

俺はようやくのぼりはじめたばかりだからな
この果てしなく長いGWをよ・・・


未完

http://www1.odn.ne.jp/cjt24200/yamada/text/otokozaka/8.gif

社内ブログ書きました

一応会社ブログなので出落ちネタとかも自重したし、実名で書いたので僕が書いたかどうか分からない方もいるかもしれないですね。

http://bohyou.vis.ne.jp/hokuto/img/hokuto4b12.gif

背景なんですが、この前のJenkins勉強会レポートSphinxを使って書いてみました。で、その際毎回HTMLファイルをビルドしてBacklogにあげるのが面倒だったので、Jenkinsの後処理でファイル共有にあげれるようにプラグイン拡張しようと思ったのが、そもそもの経緯です。

(結局プラグインの拡張が間に合わなかったので、手動でファイル共有にあげていたのですが・・・)

なお、あっちにも書いていますが、何か要望や不具合報告があるならはてだでもTwitterでもFacebookでも何でもいいのでご連絡ください。Twitterは「Jenkins Backlog」で検索かけた結果をRSSリーダーにかけており、@ついてなくても大抵反応できます キリッ

Jenkins勉強会のスタッフ視点からの反省

この前のJenkins勉強会のレポートも無事掲載されたということで、反省すべき点を忘れないうちにつづっておきます。


分割募集の意図を伝えきれていなかった

一番がこれ。「1時間で40人の1次募集枠が埋まってしまう」レベルだったので、告知のタイミングでたまたまチェックできなかった人にもできるだけチャンスを与えようとして、1,2,3次と分割募集したのですが、その意図を明確に伝えきれていませんでした。なので、どこに応募すればいいか戸惑った方もといたかと思います。

この辺、キャンセル待ちとかは使う告知サイトにもよると思うので、ある程度吟味してから選択していきたいです。

色々見積もりが甘かった

  • 時間
  • お金
  • 当日タスク

とか。

当日タスクは先にある程度決めておかないと、土壇場では頼みにくい。みんな発表は聞きたいはずなので。

あと、自分が聞けないのは諦めた方がいいかなと思いました。どうせ、レポート書くときに一からじっくりUst聞き直すから、諦めて裏方に徹しまくったほうが無難かなと。

ビアバッシュはスタッフ側の負担がぼちぼち大きい

ビアバッシュするとなると、当然参加者全員から料金徴収する必要が出てきて、そしたらドタキャンの問題とか受付の負担が増えるとかもあるので。参加料無料だと、ドタキャンについてはそこまで考慮しなくていいんですけどね。

ただ、参加者にとっては、ビアバッシュは結構ありがたい仕組みですよね。安上がりで懇親会的なノリで皆と話せるし、時間もそんなに遅くならない。

なので、毎回は無理ですが年1ぐらいではやれたらなーと思いました。

デジカメ忘れたので、レポートに掲載する写真が少なくなった

タイトルで終わり。


ちょっと今回アップアップになってしまって、心の余裕が無くなってしまったのが申し訳ないです。スタッフ側に余裕がないと、参加者も楽しみにくいだろうし。

今度からは心に余裕を持つことを心がけて、発表者/会場提供者/参加者みなさんに感謝の気持ちを忘れないようにしたいと思います、まる。

http://3.bp.blogspot.com/_LM8HL3MnkQE/Szp6xofYNnI/AAAAAAAAC48/wyOyxnT_XDk/s320/%E6%84%9F%E8%AC%9D%E3%81%A3%EF%BC%81%E5%9C%A7%E5%80%92%E7%9A%84%E6%84%9F%E8%AC%9D.jpg

Jenkins本 & WEB+DB Press Vol.67 を献本いただきました!

レビューをさせてもらった経緯もあって、ついにねんがんのJenkins実践入門を献本してもらったぞ - @ikikko のはてなダイアリーに引き続いて2冊の献本をいただきました。オライリー様・技評様、ありがとうございます!書評遅くなってすいません...orz


Jenkins

一部では蛙本という愛称で知られている、Jenkins本です。

Jenkins

Jenkins

原著がPDFで無償提供されているので読んだことはあるのですが、翻訳版を読み返しても案の定細かいことはまったく覚えていませんでした。英語が全然苦なく読めるという一部の人以外にとっては、やはり日本語で読めるというのはとっかかりとして楽だと思います*1

はじめの一歩でJavaの次にいきなりGitをインストールしてくださいとか、Mavenベースで説明されてるとかで、Jenkinsを最初に使う方が読むのはちょっとハードルが高いでしょう。ただ、「Jenkins実践入門」や「Jenkinsで始めるビルド職人入門」がAntベースだったので、Mavenをメインで使う方は参考になるかと思います。実は僕もあまりMavenベースでJenkinsを運用していないので、勉強になりました。

本書の内容をいきなり全部実践するのは難しいと思うので、一度目を通しておいてこんなときにはこんな手法が使えるんだよ的に使うのがいいのではないでしょうか。

また、日本語版だけの特典として、付録にPlay! Frameworkを題材にプラグイン開発の説明が付いています。ただ、僕のようなPlay弱者にとってはそのまま試すことができないので、ツライこともあるかもしれません。そんなときは、下記資料が参考になるかと思います。この辺は特定のモジュールに依存していないので、Jenkinsプラグイン開発に絞って学ぶことができます。(kiy0takaさんのは一部Twitterに依存してるところがあるけど)

WEB+DB Press Vol.67

今月号のWEB+DBの第1特集に、あの川口さんがJenkins特集を書いています。デブサミの発表でも語られていたそうですが、川口さん自身の口からJenkinsやCIへの思いを知れるというのは、それらを理解する上で重要なことだと思います。

WEB+DB PRESS Vol.67

WEB+DB PRESS Vol.67

特集の中身は、第1、2章でJenkinsについて簡単な紹介があった後に、後半ではJenkinsを使いこなす技が惜しげもなく紹介されています。プラグインの使い方の単純な説明や、単に手動ビルドを自動化への置き換えというだけでなく、Jenkinsを使ったからこそできることが色々と書かれています。

僕はどちらかというと、Jenkinsがなくても開発が進められるようにする方向に倒すことが多いんですよね。「基本的にビルドスクリプトで実装して、Jenkinsではそれを叩くようにする。普段はJenkins上から実行されるけど、いざとなればビルドスクリプトを直接実行することもできる」という方針。ただ、Jenkinsのプラグイン使えば楽にできることも、ビルドスクリプトで実装するのは面倒なことも多いんですよね。デプロイ関係とかレポート周りとか。

そこで、Jenkinsがあることを前提にできる環境ならば、Jenkinsにべったりで組んだ方が楽になる機会も多いかなと思いました。この辺はケースバイケースで考えていきたいです。


なお、これらの書籍はこの前のJenkins勉強会で、余興の一環として参加者にプレゼントさせていただきました。オライリー様・技評様においては、プレゼント用にも提供していただきありがとうございました。

*1:Jenkinsは進化も早いので、なるだけ本家英語版のドキュメントもしくはソースコードを読むにこしたことはないのですが