勤怠戦隊キンタインを使ってみた #kintain

勤怠戦隊キンタインを1週間使ってみました。作者の一人ですけど。

1週間のグラフ

こんな感じで、出社時間同じぐらいだけど、曜日によって働いている時間違うのが視覚化されるの分かります。帰社から帰宅まで長い日は遊んでいる感満載ですね。

1日の詳細

例えば、2012年5月11日(金)の詳細はどうなっているかというとこんな感じ。実際は、夜飲飲みに行っているので「ピザ以外を食べた」が入るべきなんですけど、押し忘れましたね。

押し忘れや、押し間違えに関しては色々とフザけた機能で対応出来ないか検討中です。

• 友達を上司設定して、申請しないと直せないとか
• コンプガチャ…っとこんな時間に誰か来たようだ

その他遊び方

bot風のひとが現れたり

@ppworks おつかれーっす！

— FakeStarBabyさん (@fakestarbaby) 5月 10, 2012

ピザ食べてそうなひとに強要させてみたり

@TomiTomi_Club キンタインでピザ管理をお願いします！

— PP worksさん (@ppworks) 5月 12, 2012

bot風のことをしてみたり

@hyshhryk おつかれさまでーす！

— PP worksさん (@ppworks) 5月 13, 2012

紹介されました

以下サイトで紹介されました。ありがとうございます。

• 戦え企業戦士！「勤怠戦隊キンタイン」
• 「行ってくる！」「出社った！」「帰る！」「ピザ！」　SNSと連動して勤怠報告をを行える「勤怠戦隊キンタイン」

P4Dハッカソン( #p4dhack ) に参加して勤怠戦隊キンタイン というwebアプリを作成しました。 #kintain

デザイナー向けプログラム部の第2回デザイナー x エンジニアハッカソンに参加してきました。

• 第2回デザイナー x エンジニアハッカソン デザイナー枠
• 第2回デザイナー x エンジニアハッカソン エンジニア枠

事前勉強会にて決定したペアと一緒にハッカソン。私はエンジニア枠で参加してまして、パートナーのデザイナーさんは、@kkotaro0111さん。

会場はいつものKDDIウェブコミュニケーションズです。今回はハッカソンということもあり、とにかく時間が足りないので本当に作ることだけに集中した結果、当日の写真をほとんど撮っていないことに気付きました。ウッカリ！

当日のtogetter

hashtagは#p4dhackでした。togetterのまとめにまとめておきました。よろしければどうぞ。

作ったもの

勤怠戦隊キンタインという勤怠管理アプリを作成しました。

facebook、twitter、githubのいずれかのアカウントでログインすることで、家出た時間、会社ついた時間、会社出た時間、家ついた時間を記録していくアプリです。

現在は、mixiアカウントでのログインも対応しました。

p4dhackの懇親会がピザということで、なぜかピザを食べたボタンも実装しました。以下のようにログイン後の画面でボタンを押すだけで記録されます。

記録した勤怠データは以下のように記録されます。謎のチャートは青が家にいる時間、黄色が移動時間、赤が社畜勤務時間です。

事前準備

パートナーさんとアイデアを練る時間がとれなかったのもあり、とりあえずアイデアを色々出す作業をしました。10個ぐらい適当につぶやいていたものの中から、前日あたりに、「家出た時間、会社ついた時間、会社出た時間、家ついた時間だけを登録するアプリ。」で行こう！ということになりました。

そして夜と行きの電車で作ったのがこの辺

• 何となく仕様
• 画面一覧
• ログイン周りの実装

何となく仕様

こんな感じで、ものすごくざっくり。仕様と書きつつ何故かテーブル設計もしました。この中から出来るところだけに集中という感じです。

仕様

家出た時間、会社ついた時間、会社出た時間、家ついた時間だけを登録するアプリ。

共通

• ログインする

イベント記録

• イベントを選択する
• [記録]ボタンをクリックする
• 〜にも通知する？みたいなのでfb, tw連携

イベント閲覧

• 日別
• 月別

フォロー

• 友達をフォローとか？

タイムライン

• 友達の勤怠？

fb連携

• open graph action対応したい

table

• events
  • id
  • name
  • user_id
• posts
  • event_id
  • user_id
  • scope_id
• likes
  • parent_type
  • parent_id
  • user_id
• scopes
  • id(:public, :followee, :private)
  • name

画面一覧

OmniGraffleで作成。超ざっくりだけど、@kkotaro0111さんと、手分けする際に、こんな感じで画面考えてます。というのを伝えるのには役に立ちました。

ログイン周りの実装

いつも作るところの割には久々に作ると、色々なgemのバージョンが上がっていたりして、ハマるところなので前日に実装。mixi対応までしたかったのですが、昔作ったwebサイトのときとoauth2バージョンが違い、うまく動かなかったのでwe love herokuと同じく、facebookとtwitterとgithub対応としました。

heroku の準備

herokuにアプリ作成しておきます。

heroku create kintain -s cedar 

heroku addons:add newrelic:standard heroku addons:add pgbackups:plus heroku addons:upgrade pgbackups:auto-week 

heroku labs:enable user_env_compile heroku config:add RUBY_VERSION=ruby-1.9.3-p125 

当日の作業

スケジュール

9:00〜 スタッフ集合会場準備
9:30〜 開場・受付
10:00〜 趣旨・スケジュール・開場説明など @satococoa
10:15〜 開発
18:00〜 成果発表LT
18:30〜 懇親会
20:00 撤収

各SNSのアプリを作成する

本番用は前日の準備で出来ていたのですが、パートナーさんにもローカル環境で動作させてもらうために以下の3サイトからアプリ作成をお願いしました。

• facebook DEVELOPERS
• twitter developers
• github Register a new OAuth application

git cloneしてもらう

こんな感じでお伝えしました。

mkdir work # お好きなところ cd work git clone git://github.com/ppworks/p4dhack.git bundle --path vendor/bundle --without production 

ローカルで動かす

database準備

mysql-serverを入れてもらったりしたのですが、これは出来ればsqliteが良いだろうなと思ってます。

rake db:create rake db:migrate 

rake db:migrateはハッカソン中に、何度も使うことを伝えておきました。

サーバー起動

各SNSのOAuthコンシュマーキーやコンシュマーシークレットが必要なので、それらを環境変数にセットしておきたい、というわけでforemanを使いました。

.envに以下のように記述してもらい

RACK_ENV=development FB_APP_ID=xxxx FB_APP_SECRET=xxxxx GH_APP_ID=yyyy GH_APP_SECRET=yyyyy TW_APP_ID=zzzz TW_APP_SECRET=zzzzz 

以下のコマンドで起動してもらいます。

foreman start 

作業タイム

10:30〜11:00

まずは環境構築をして、デザイナーさんの環境でもローカルでアプリが起動するところまでを作業しました。

11:00〜12:00

先の画面イメージを見せて、どの順番で機能を作りどんなページを作成して行くかをすり合わせながら作業。

12:00〜12:40

カレー食べた

12:40〜18:00

とにかく作業。まじ作業。周りの人と懇親的なことをする余裕がまったくなかったです。10:00に会社来たら、まだ何も作ってないシステムの顧客レビューが18:00に行われるというのを聞いた体で作業にいそしみました。ヤバい、時間ない！

18:00〜

発表。みんなの発表を聞きたかったので、作業は完全にストップさせました。以下のwebサービスが発表されました。

• comugi @satococoa x @coddledegg
• o-giri @naoty_k x @murokaco
• taskwell @tyabe x @retemo
• キンタイン @ppworks x @kkotaro0111
• weego @shu_0115 x @s_katsushima
• lunchtime @hyshhryk x @averagefury
• JogCalc @u1tnk x @mahohori
• FrontLine @amesel)) x @machida
• imakita @japboy x @ken_c_lo
• rails講座 @yotii23 x @inner_village
• Hakolog @r7kamura x @naoaky27
• deep "EXP" RECORD @tkawa x @honma_tora
• TREMU @quattro_4 x @binoske
• Ohanashi Shitter @jinho x @akrong_world
• た
  て
  が
  き
  言
  葉 @iR3 x @yukiferret

twitterを見た限りでのurlを露出されていた方々のサービスにリンク貼ってあります。まずい場合は外しますので、@ppworksまでご連絡下さい。逆にリンク貼っても良い方いたら、url教えて欲しいです。

というわけで、その後は懇親会だったのですが、疲れすぎてあまり懇親出来なかったのがもったいないなかったなぁ自分。という感想。

当日の声

#p4dhack 勤怠戦隊キンタイン これは流行る twitpic.com/9f4k6g

— Kojiro Kamikawaさん (@K_Kamikawa) 4月 29, 2012

キンタインすてきです！！！！つかいます！@ppwork @kkotaro0111　#p4dhack

— あ子さん (@akrong_world) 4月 29, 2012

ktkr

その後

発表のタイミング残っていたbugやら、やり残し作業は後日じゃ絶対やらなくなるという確信があったのでその日の夜までスタバとか自宅とかで終わらせました。そう考えるとハッカソンの時間 x 2ぐらいが全体の作業量だったのかも知れません。

追加した機能

GW中にいくつか機能追加してます。

• 日別のページデザイン
• mixiアカウントによるログイン
• 各イベントのラベル変更
• ポストした内容の閲覧権限を設定

日別のページデザイン

mixiアカウントによるログイン

無理やりボタン追加したので大変なことになってます。あと2つ連携先を追加してごまかす方法で何とかしたいです。googleとhatenaとか？

各イベントのラベル変更

当日もラベル変えたいという意見をそれなりに頂いていたと言うのと、最初から本当は作りたかったというのもあり実装しました。

これで、「会社に着いた」を「チャリで来た！」に変えて見たり、「ピザ食べた」も「ピザ食べてない」に変えれば、「ピザ食べた」のtwitter連携後も、わざわざ「食べてない」とtwitterでつぶやかないで済みますね。

ポストした内容の閲覧権限を設定

勤怠の内容って、人に見えていいのだろうか？という疑問もあり、閲覧権限を変更できるようにしました。privateにしているときには、post時のfacebook連携、twitter連携もチェックボックスを出さないようにしています。みんなに見えちゃうのはちょっと、、、と思って居た人も、これで安心して使えますね！

やり残し作業

https://github.com/ppworks/kintain/issuesに色々ご意見・ご要望を貯めてます。#kintain つきでつぶやくか、@ppworksか@kkotaro0111さん当てにメンションを下さい。

心配

あれに似ているので

今、俺の一番の懸念事項は、 #kintain のボタンデザインがゴレンジャーを元にしている、という点。版権的に大丈夫だろうか。

— 川嶋 光太郎さん (@kkotaro0111) 5月 1, 2012

思ったこと

• 1日で作れると思ったものは作れない
  • というのは予想していたので3時間ぐらいで作れるものを考えていきました
• 1時間で作れると思うものを作ろう
• railsは楽しい
• 開発は楽しい
• ハッカソンは楽しい
• デザインが吹き込まれた瞬間、もうサービスとして成り立ちそうな感じがする
• p4dは素晴らしい

というわけで、次回も楽しみです。

最後になりましたが、パートナーの@kkotaro0111さんお疲れさまでした！本当に楽しく作業出来て良かったです。

またこのような機会を作って下さったp4dの皆様感謝しております。

Receibo へ Pull Request した

Receiboが便利すぎて、機能追加してしまったお話。

追加した機能

「いま、何買った？」の入力欄に過去の購入履歴を検索する機能を付けました。いつも同じような項目を入力するので、会社行き帰りのコンビニ買物後の入力が怠くて仕方なかったんですよね。

んで、その日も帰りにコンビニ寄った際に、めんどくさいなー、もう作っちゃおうかなーと思ったのがきっかけです。その帰りにスタバに寄って作りました。

「いま、何買った？」をクリックするだけで、履歴から項目が選べるようになりました。便利ですね。

準備

機能追加の準備です。

forkします。

githubにあるreceiboのrepositoryで[fork]ボタンをポチッとな。

んで、forkしたものをcloneしたんですがrubyのバージョンなんだろな、と。@shu_0115さんにバージョン確認したら、blogの記事があるとのことで、Receibo開発舞台裏 - プログラマ編を参考にしました。urlが*.heroku.comなので、Bamboo Stackを調べるとRubyのバージョンは大体想像は付きます。(Aspen Stackということもありうるのかな？)

gemsetを用意

最近は、デフォルトをruby-1.9.3-p125にしていたので、まずは1.9.2にして、receibo用のgemsetを作って作業。

rvm use ruby-1.9.2-p180 rvm gemset create receibo rvm use ruby-1.9.2-p180@receibo 

やるべきこと

READMEを見れば、たいてい書いてあって素晴らしいなと思いました。

bundle install 

touch config/local_setting.rb 

なんか適当に作ったtwitterアプリのCONSUMER KEYとCONSUMER SECRETを設定

LOCAL_OAUTH_CONSUMER_KEY = "YOUR_CONSUMER_KEY" LOCAL_OAUTH_CONSUMER_SECRET = "YOUR_CONSUMER_SECRET" 

localにdatabaseを作って

bundle exec rake db:setup 

サーバ起動

bundle exec rails s 

作る作業

やったことは、

• 履歴表示用のactionをcontrollerに生やす
• javascriptで入力欄に履歴を出す
• cssの調整

ぐらいです。

差分はこちらです。実際取り込まれた差分はこちらを見てもらえると良いです。

@shu_0115さんとやりとりをして、履歴全件持ってくると大変なことになるよねー、とか数値入力を数字だけにすると-入力の裏技使えなくなるよねーとか、いうお話をして取り込む部分の相談をしました。

困ったこと

• rails3.0だったので、いろいろ忘れていた
  • assetsがない！あ、そうか。
• prototype.jsのままだったので、最初びびった。
  • 調べてみたところ、結局、jsはそれほど使ってなかったので、jQueryに置き換えました。

pull request

pull request時は、GitHubへpull requestする際のベストプラクティスを見つつ、rebase -iを駆使してコネコネしてから送りました。

その後のtwitter

こんな感じで、ドキドキpull requestを送って

@shu_0115 receiboにpull request送りました。なんか初めてのpull requestでよくわかってないところあるのでおかしいかも知れないです。その際は、それとなくお伝えください。＆pull requestそもそも受け付ける予定なかったりしたらすみません。

— PP worksさん (@ppworks) 4月 4, 2012

いろいろやり取りした後に、このように告知して頂きました。

#receibo Receiboに @ppworks さんのPullRequestにより、入力履歴機能が付きましたー。

— 松本瞬／Shun Matsumotoさん (@shu_0115) 4月 9, 2012

まとめ

自分が使っているサービスのソースが公開されている場合は、欲しい機能は言うだけでなくて、作ってしまえば良いというソーシャルコーディングの楽しさを初めて実感しました。今後もこういったソースが公開されているサービスが増えると良いなと思います。

#kobitoapp と #qiita とblogの関係について考えた

ちょいと前に、kobitoのユーザーインタビューのオファーを頂き、中の人とお会いしました。ちょっとテンションがあがってしまい、しゃべりすぎてうるさかったのではという噂があります。

その後、kobitoとqiitaの関係について考えてみました。

kobitoとqiitaの関係

qiitaはエンジニアがローカルに貯めたメモを公開することで、世の中で同じことに困っているエンジニアの無駄な時間を省くためのサービス、だと思います。

kobitoは、qiitaに上げる前のメモを貯めるアプリと考えています、私は。

私がメモアプリに望むこと

となると、メモアプリに望むことを考えるわけですが、ざっとあげるとこんな感じかな。

• 軽い
• マークアップが使える
• すぐに何かに対して共有出来る

私がメモアプリに望まないこと

逆に考えると、こんな感じ。

• 余計な修飾機能
  • とあるアプリ、コピペで何、勝手にスタイル継承してんだよアホか(主観です)
• ライフハック感
• bookmark的な機能
• 画像クリップ機能

でkobitoはどうなの

私がメモアプリに望むことをすべて満たしているですね。こりゃ、もう使うしかないでしょ。もうちょっとここがこうだったらなー？と感じたら要望だすでしょう、そりゃ。という感じです。

ちなみに、kobitoに書いてある3つの特徴

• Markdownとリアルタイムプレビューで快適に入力
• シンタックスハイライトでコードをきれいに記録
• ボタンひとつで簡単に公開

何これピッタリ。ローカルにメモを書き溜めるkobito、書き溜めたメモを公開して共有するサービスであるqiita、この関係が絶妙ですね。

kobitoとblogの関係

kobitoとblogの関係を考えるときに、重要なのが、blogに上げる情報と、qiitaに上げる情報との違いなのです。そう考えると、必然的にkobitoとqiitaとblogの関係を考えることになります。

kobitoとqiitaとblogの関係

と、いいつつ、この点に関しては未だ答えが出ていないのですが、いまのところ以下の使い方を試して見ています。

qiitaとblogの使い分け

qiitaをエンジニアのメモ集、blogをイベントにひもづく時事ネタと考えると

• qiitaには技術的なメモを書く
• blogには勉強会などイベント系メモを書く

という感じかなと思っています。こう考えると、qiitaに書くネタは更新性があり、正確性が求められるので他人が更新出来る仕組みが欲しくなります。古くなった使えない情報は他のエンジニアを助けるどころか、逆に困らせる可能性がありますよね。

kobitoに書くもの

こちらは、すべてのメモやblogの下書きを書きます。基本的にはありとあらゆるテキストはここに集約したいという気持ちがあります。

• 技術的なメモ
• 勉強会などイベント系メモ
• blogの下書き

qiitaに書くもの

• kobitoにためたもののうち
  • 技術的なメモは
  • 勉強会などイベント系メモ

qiitaには直接書かないというポリシーを持ちたいと思っています。これは、qiitaに書いたものはすべてkobitoにあるという状態にしたいからです。同じくblogに書いたものはすべてkobitoにあるという状態にしたいです。

欲しい機能

qiita

• qiitaに下さい
  • blogの記事に対して、これはqiitaに投稿して欲しい！という記事を記事書いた人に知らせる何か
  • 更新性の高い記事はqiitaに集めたいという理由から
• wikipediaのように誰でも更新出来る機能
  • 更新性の高い情報は、古くなると逆に有害な情報になりうる
• レビュー機能
  • qiitaの記事のの信憑性をチェックしたい

kobito

• 一覧でのtagクリック時に、勝手に絞り込み検索
• レビューのON/OFF機能(と思ったら、左下にあった！)
  • インタビュー時にもあると言われた気がする
• みんな要望提出済みなDropbox連携
• blog投稿機能
  • octopressだったら一発で出来るpluginとか用意すれば出来そうかな
• iOS版
• あとは、随時 #kobitoapp 付きのツイートを投げます。

エンジニアを幸せにするサービスの素晴らしさ

Increments株式会社のmeta[name="description"](なぜ見つけた)にある

Incrementsは、「プログラマの誰もが楽しくプログラムを書いて、いろんなモノを生み出すことができる世界」を実現する会社です。

というのが素晴らしいなと思い、共感するわけです。

私は、世の中のシステムを作っているエンジニアやデザイナーなどクリエイター達がストレスなく幸せに伸び伸びと、素晴らしいものを生み出せる環境が広がることを望みます。

まずはクリエイターが幸せになってから、他の事したいですよ。まずはそれから。

合わせて読みたい

@fakestarbaby さんの Kobitoのユーザーインタビューに参加しました！もどうぞ。

git道場#1参加した #gitdojo

はじめに

• 最後には師範代に認定
• git覚えたらプロジェクトを heroku.com へ deploy しよう

心: git総論、心構え

• @iwamatsu
• 岩松さん
• DebianのOS開発
• 師範
• 彼がmergeやrebaseができなかった。別れたい

gitは分散

• リモートリポジトリとローカルリポジトリ
• 主な作業はローカルリポジトリで行う
  • 必要なデータがローカルにあるので動作が速い
• プッシュしてはじめて、他のユーザーと履歴共有する。
• ローカルリポジトリはおれのもの。リモートリポジトリはみんなのもの

リモートリポジトリとローカルリポジトリ

• HEAD いまチェックアウトしているもの
• 作業中に誰かがコミットをプッシュしても、ローカルは認識できない
  • リモートの作業を反映するまではその辺は気にしないで良い

gitは頑健

• 乱暴に言うとスナップショットシステム
• SHA1ハッシュで管理されている。
  • コミット、ツリー構造、実際のファイルのどれかが変更されるとハッシュ値が更新される

gitは時間的な変遷を管理する

• コミットの前はどうなっていたのか
• 前の状態に戻すことが出来る
  • git reflog
  • 消したbranchとかも参照を消しているだけなので、戻すことが出来る
  • 90日まで
  • git gcするまで
  • git config --global gc.auto 0 でgcを無効にできる
• 常にコミットしておいた方がむしろ安心。

質問

• svnから移行するときの説得方法は？
  • コミット権限とりあげよう
• githubが重い
  • enterprise速いよ
• git gc実行こわい。どれくらいのサイズですればいいの。
  • 大きいのは仕方ないのでは
  • git objectを集めるのが趣味なので気にしない人もいる
  • 検索かけたときに遅くなったら、とか目安になるかも。

技:

• 小川さん
• @@conceal_rs
• jpmobileの人
• 師範

本日の課題

• 3〜5人のチームで
  • コミットメッセージちゃんとかく
  • git pull --rebaseを怖がらずにやる
  • git pull との違いを実感する

コミットメッセージをしっかり書く

• 当たり前のことだが、あまり実践されていない
• コミットメッセージのみを介して会話する
• 意思疎通が出来るレベルでメッセージを書くことが目的

git pull -rebaseを怖がらずに

• 今日はコンフリクトが起こりやすい題材となっている

git pull との違いを実感する

• mergeとrebaseの違いを実感する
• mergeだとコミット家系図が入り込んでしまうため、コミット間の相関関係が分かりづらい

題材

• Numbersファイルをチームで編集
• チーム間ではコミット内容に関する相談、会話をあまりしない
• pushのタイミングは告知しないでいいよ
• commitしてpushすることを5回ほど繰り返す

Numbersとは

• 1〜10の数値が書かれた10行のファイル
• 好きな数値の後ろに記号を追加/削除する
• コンフリクトしやすくしよう！
• コミットメッセージに、追加した記号や数値に関する情報を記載する
• コミット内容に関しては、このコミットメッセージでやりとりする
• コミット内容に関しては、相談・会話をしない！
• コミットメッセージは、コミットオブジェクトの要約であることを意識する
• 自分のコミットが連続しているのは敗北！
• git pushの声掛けはok

最後にやったことの確認

• githubのNetworkを確認
• git log --graph --pretty=oneline --decorate

repository

http://github.com/git-dojo/teamNN をcloneして始める

実技

Numbersを自由に更新

実技2

pull時に必ずrebaseでやる縛り

git commit -> git push | git pull --rebase 

git remote update -> git rebase origin/master 

テクニックの解説

• rebaseはコミットをかぶせる感じ
• mergeはコミットを統合する

git pushが失敗するのは？

• remoteに新しいコミットがあると失敗する

このときgit pull

• remoteにある、差分をmerge
• localのコミットをmerrge

git pull --rebase

• remoteの差分を先にrebase
• localのコミットをmergeする

git pull --reaseでconflict

• 無名branchがチェックアウトされた状態
• どうする

1. ファイル編集
2. git add Numbers
3. git rebase --continue

• つまりgit commitしないこと

git rebaseの利点

• 見やすい
• 誰がcommitしたか分かりやすい

git merge

• conflictしない
• 自分の元々の編集履歴が残るので、後になって調べやすい
• commitに問題があったかどうかなどの調査しやすい

merge か rebase か

• 状況次第であることを意識する
• 基本的にはrebaseしてからpushが良い
  • 他人がcommitしていることが意識出来る
• ブランチはmergeが良い

無名ブランチ

commitしないこと

• git rebase --continueで続ける
• git rebase --abort
• git rebase --skipでそのコミット捨てちゃう

今日覚えた事のメモ

git push するたたびにgithubのアカウントとpw聞かれるのはなぜ？

以下のように、.git/config内の記述がhttps〜になっていると聞かれる

 url = https://github.com/git-dojo/team10.git 

ので、このように変更する。

 url = git@github.com:git-dojo/team10.git 

githubのNetworkみたいなものをコマンドラインで見る

git log --graph --pretty=oneline --decorate 

git pullする際のお作法

--rebaseをデフォルトで付ける。

git config branch.master.rebase true 

diff

git diff --word-diff 

作業の流れ

1. いろいろ作業
2. git add
3. git commit
4. git pull --rebase
5. conflictを解決
6. git add
7. git rebase --continue

githubのNetworkの遷移

git pull --rebaseを知らない頃

git pull --rebaseを覚えた後

「小さく賭けろ！」を読んだ

Amazonのleanstartupセミナーに行ってきて、そこで売っていた「小さく賭けろ」についてのメモです。「リーン・スタートアップ」の出版記念的なところもあったと思うのですが、なぜかこちらが気になって買いました。

がっつり、各章の気になったところをローカルにメモったのですが、さすがに引用多すぎてヤバい感じがしたので、こちらのエントリーはさらっとしたメモにしておきます。

小さな賭けの原則

小さな賭けの原則として以下の6つが挙げられています。

• 実験する
• 遊ぶ
• 没頭する
• 明確化する
• 出直す
• 繰り返す

心構えをこうした考えへシフトしていくと、どのような変化が訪れるかということが中心です。

成長志向のマインドセット

固定的なマインドセットを持った人たちと、成長志向のマインドセットの違いは本書にも掲載されていた以下の図が分かりやすいです。

遊びの天才

ミハイ・チクセントミハイのフロー理論また出てきました。まさにフロー状態で読めました。そろそろ、フロー理論の本読みたいですね。

実際に人間と語り合うことや体験することの大事さ書いてあり、ちょうどいま自分が考えていることってたまたま手に取った本にも書いてあることが多く、本との出会いにも縁を感じます。

プログラム未経験者向けの社内勉強会をやってみた

主にプランナー向けとして、プランナーがプログラム出来るようになると嬉しいよね、といった趣旨で勉強会をしました。

p4dにインスパイアされて、planer向けだし、p4pと名付けてみました。(すみません)

その時の資料は以下

P4p20120408

View more presentations from Naoto Koshikawa

やったこと

内容としては、以下の説明と実技という感じでした。

• git
• ruby
• sinatra
• heroku

git

一年ぐらいまえに非エンジニア向けにgitをレクチャーしたときの資料を元にgitの概要を説明。バージョン管理システムの概念や使う利点は伝わったかなと思います。

割と丁寧に説明したので、ここまでで2時間ぐらいです。

githubにアカウントを作っておいてもらったので、実際にリポジトリを作ってもらって、そこにRERADME.textileをおいてもらって編集してみるという作業。textileにしたのは社内のプロジェクト管理でredmineを使っているのでtextileが慣れているのでは！？というところからです。

gitにおいては、ローカルリポジトリとリモートリポジトリの関係、インデックスの概念を教えるのが難しいですね。

git 概念図(2012.4.21追加)

勉強中に手書きで書いたものを電子化しました。

ruby

• ドットインストールのruby基礎をみんなで見る
• 見た後に手を動かしてみる
• 補足説明をする

という感じです。動画を見る形式の講義は、一人だとやらなさそうという意見や、何か分からなかった時にすぐに聞けないと躓いてしまうという意見があったので、その場でフォロー出来る状態でみんなで見るというのは成功だったと思います。

課題としては、class以降が急に難易度が上がったという参加者が多かったので、オブジェクト指向以降はかなり丁寧に別途説明をしました。

1回3分の動画で32回分なので単純計算で1時間半だし、大丈夫だろうと思っていたんですが、途中休憩しつつも4時間ぐらいかかったような気がします。いっきに詰め込みた感はありますね。

補足で良くわからない図を沢山書いたので、のちほど気が向いたらデータ化する予定ですが、そういうのってやらないですよね。うん。

classの概念図(2012.4.21追加)

sinatraのREADMEを写経

この辺は時間が押してきていたのと、みんな疲れていたのもありHello worldの写経のみで終わってしまいました。

次回開催するとしたら、この辺から再開して、実際に動く何かを自分で考えて作ってみる感じにしたいと思います。

herokuに上げる

herokuに関しては、gitの操作を説明していたのですんなりと作業出来ました。

実際には、私がsinatraアプリを作るときに、config.ru 上げ忘れた状態で一度、sinatraアプリを起動してしまうと

Error H14 (No web processes running) 

というエラーが出てしまい。config.ruを上げなおしても直らないという状態でハマってしまいました。解決策を探る段階で色々試したんですが、決定打は

heroku destroy {app_name} 

して作りなおすでした。この辺、何が問題なのか分からず仕舞で困りましたが、その後は順調でした。

次回

今回は基本的に社内の人だけで、業務時間内に実験的にやらせてもらいました。次回以降どうするかは白紙です。場合によっては公開イベント的にやってみるのも面白いかなと思っています。

今のところ、planer向けとかも外してRuby初心者向け勉強会的な感じでもいいのかなーとか色々モヤモヤしている状況です。