WhiteWater

2014年12月9日火曜日

blog移転しました

しばらく前になるけど、

http://blog.ponpokopon.me/ に移転した後

http://ghost.ponpokopon.me/ に移転しました

2014年3月13日木曜日

phdocを触った

某団体のためにwikiっぽいものを作ってみようかと思ったんだけどpukiwikiみたいなちゃんとしたwikiは面倒だった…。機能は多くていいかもしれないけど大して複雑なことする気もないし、管理が面倒くさいなと。
でもテキストファイルだけは寂しいし、htmlごりごり書くのも面倒。マークダウンで作れないかなと思ったらphdocなるものがあったので使ってみた。
pythonで書かれたマークダウン→html&css&js変換ツールみたいなイメージ？

インストール

    $ pip install phdoc

wiki初期化

phdoc init wiki名で初期化される。

$ phdoc init ponpoko-wiki
phdoc.init: INFO: Wiki initialization complete
phdoc.init: INFO: Your new wiki is at: /Users/licorice/Desktop/ponpoko-wiki

ディレクトリ構成。wikiディレクトリ以下にマークダウンのファイルを置く感じか。デフォルトで幾つかのファイルが生成されている。

$ cd ponpoko-wiki
$ tree
.
├── phdoc.yaml
├── static
└── wiki
    ├── index.md
    ├── notes
    │   └── pnp.md
    └── publications.md

wikiビルド

デフォルトの状態でビルドしてみる。ビルドするとマークダウンをhtmlとcss,jsに変換して吐き出してくれる。
wwwディレクトリが新たに作成されそこに吐き出されている。

$ phdoc build
$ tree
.
├── phdoc.yaml
├── static
├── wiki
│   ├── index.md
│   ├── notes
│   │   └── pnp.md
│   └── publications.md
└── www
    ├── _list.html
    ├── index.html
    ├── media
    │   ├── _list.html
    │   ├── css
    │   │   ├── _list.html
    │   │   ├── basic.css
    │   │   ├── elements.css
    │   │   ├── index.html
    │   │   └── pygments.css
    │   ├── index.html
    │   └── js
    │       ├── _list.html
    │       ├── addcss.js
    │       ├── fold.js
    │       ├── hyphenator.js
    │       └── index.html
    ├── notes
    │   ├── _list.html
    │   ├── index.html
    │   └── pnp.html
    └── publications.html

wiki確認

その場でサーバを立ち上げて作成したhtmlを閲覧できる。http://127.0.0.1:8008へアクセスすると怪しげな博士の紹介ページ的なデフォルトのwikiページが見れる。

$ phdoc serve
phdoc.serve: INFO: Serving on http://127.0.0.1:8008
phdoc.wsgi: INFO: GET / - 200
phdoc.wsgi: INFO: GET /media/css/basic.css - 200
phdoc.wsgi: INFO: GET /media/css/elements.css - 200
phdoc.wsgi: INFO: GET /media/js/hyphenator.js - 200
phdoc.wsgi: INFO: GET /media/js/addcss.js - 200
phdoc.wsgi: INFO: GET /media/css/pygments.css - 200
phdoc.wsgi: INFO: GET /media/js/fold.js - 200
...

wiki設定

phdoc.yaml内でwikiの設定をする

 $ cat phdoc.yaml

wiki-name: PHDoc wiki
html-dir: www
remote: example.com:public_html
nav:
    pages:
        - index
        - publications
        - notes
    labels:
        index: About
        publications: Publications
        notes: Notes
markdown:
    extensions: [toc, codehilite, def_list]
    safe-mode: false
    output-format: html

wiki-nameでtitleの設定ができる。html-dirはpublic等に設定するとビルド時その名前のディレクトリに吐かれるようになる。
remoteはまだ使ったことがないがrsyncでリモートサーバへ設置してくれるものらしい。便利！
nav内にhtmlファイル一個相当のページ名を書いていく。新しくページを作成したいときはwikiディレクトリ内にマークダウンファイルを追加するのと、ここにそのファイルの名前を書くことになる。
labelsはwikiのナビゲーションタブで実際に表示されるページの名前になる。
markdown内ではエクステンションの設定等ができる。マークダウンファイルの先頭に[TOC]と入れると目次を作ってくれる。[toc]では認識されないので注意！
safe-modeやoutput-formatはまだ使ったことがない。

heroku

herokuにwikiページを設置してみる。

準備

sinatraで動かしてみる。
Gemfile準備。

$cat Gemfile
source :gemcutter
gem 'sinatra'

bundle。Gemfile.lock生成。

$ bundle
$ cat Gemfile.lock
GEM
  remote: http://rubygems.org/
  specs:
    rack (1.5.2)
    rack-protection (1.5.2)
      rack
    sinatra (1.4.4)
      rack (~> 1.4)
      rack-protection (~> 1.4)
      tilt (~> 1.3, >= 1.3.4)
    tilt (1.4.1)

PLATFORMS
  ruby

DEPENDENCIES
  sinatra

rack設定。

$ cat config.ru
require 'rubygems'
require 'sinatra'

get '/' do
  open('www/index.html').read
end

run Sinatra::Application

デプロイ

heroku登録、herokuコマンドラインツール、gitを予め入れておく。
ローカルにコミット。

$ git init .
$ git add .
$ git commit -m "1st commit"

herokuアプリ(リポジトリ)作成。

$ heroku create ponpoko-wiki
Creating ponpoko-wiki... done, stack is cedar
http://ponpoko-wiki.herokuapp.com/ | git@heroku.com:ponpoko-wiki.git

herokuにプッシュ。

$ git push heroku master

これで公開されました。めでたしめでたｓ…
ん？？なんかcssが読み込まれてない…。表示崩れてる…。
なぜかよくわかりませんが、wwwディレクトリではなくpublicディレクトリじゃないとうまくいかないようです。

修正

phdoc.yaml修正。

-html-dir: www
+html-dir: public

config.ru修正。

-  open('www/index.html').read
+  open('public/index.html').read

ビルドしてコミット、プッシュ。

$ phdoc build
$ g add .
$ g commit -m "ディレクトリ名修正"
$ git push heroku master
$ heroku open

おおーうまく表示されたようです。　やったぜ。

完

phdocには他にもクールな機能があるとのことなので面白そうな機能あったら試してみます。
ノシ

----

見づれえ…
mdをhtmlに変換して貼り付けるだけじゃダメか...

2014年1月31日金曜日

Seeq+

旧Seeqから移行

Seeq+インストール後旧Seeq開いて設定から移行

2013年12月16日月曜日

Agile Samurai Base Camp行ってきました！

初心者向けみたいで参加しやすそうだなと思ったので行ってきました。明日から始められるというフレーズもいいですね。そういうのに弱いです私は。
TDDとインセプションデッキのセクションがあって、私はインセプションデッキの方に参加してみました。メモや感想を書き出してみます。
はじめに著者のジョナサン・ラスマセン氏からのビデオメッセージが。やってほしいことを3つ。

学んだことや今日あったことを共有する
常により良い方法を探し続け改善し続けること
楽しむこと

その後講演へ入りました。
前半はインセプションデッキとTDDは別れておらず、なぜアジャイルサムライという本が誕生したかといった内容や影響を与えた書籍、なぜサムライ？と言った話でした。
様々な書籍がある中で、

現場にどう合わせていくか
手法や用語にとらわれ過ぎない
学びながら調整していく

これは重要な事だと思いました。意外に囚われてしまうことは多いんじゃないでしょうか。

インセプションデッキの話

明日からインセプションデッキを始めようの話。基本アジャイルサムライに則ったお話でした。それをどう明日から実戦していくか。

準備→理解→調整→まとめ

の流れで進めていく。

準備
- まずは自分の理解をまとめてみる
- 見聞きしたこと、経験、ドキュメント、調査したこと
- たくさんのインプット
理解
- 知っている人に聞いてみる
- 達成するべきこと
- 誰が使うのか
- そもそも経緯は
- マネージャ、エンジニア、等、それぞれの立場
- デッキじゃなくて質問しよう
調整
- 自分が不安に感じていることを伝える
- こういうところが気になるんですが…程度で良いので聞く
まとめ
- 最新情報をまとめて周りに伝える
- スライドにまとめると伝えやすい、次に繋がりやすい
- 共有フォルダはアカン！（誰も見ないw）

いつデッキ作ればいいの？
デッキを作るタイミングはたくさんある！

プロジェクトが始める前
自分にとっての初日（参加した日）
ふりかえりのとき
悩んだ時
などなど…いつでも良い

自分に当てはめてみる

インセプションデッキのお話のあと実際にワークショップを行いました。その後再び講演で現場ごとのお話でかっこいいセリフが出たりしていました。
インセプションデッキ。自分で始める際どうやってみようか考えました。とらわれ過ぎない。現場ごとにやりかたは変わる。

準備→理解→調整→まとめという流れ、うまく取り入れられないだろうか。
きっと理解、調整の部分は毎日の朝会でできるんじゃないかな、とか。
1周間そんなことを意識してみたりしました。そして常に改善していく！
今回参加してよかった！皆々様ありがとうございました！

2013年12月2日月曜日

jawbone up apiで自分をnagios監視下に置く

JAWBONE UP APIを触ってみた。
先月届いたリストバンド型ウェアラブルデバイスのUP。APIがあったのでなにかやってみようと思います。

API

こんなかんじでした。

OAuth2.0使用
UPに記録されているデータはひと通り取れる
運動の記録(多分睡眠等も)は日付指定しなければ最新10日間分を取得
jsonで値はかえってくる
アクセストークンの期限は1年

自分を監視する

とりあえず何かやってみようということで自分を監視してみました。
運動量が一定の値以下なら警告をだしてみます。

何で監視するか

nagiosで監視してみます

流れ

UP側
- jawbone.comのアカウント作成
- https://jawbone.com/up/developerからorganization登録
- application登録
  - アプリのホームページ
  - 認証のリクエスト等を送る際のウェブページ
  - リダイレクト先のページを登録
- Client Id,App Secretが発行される
- 認可コード取得
- アクセストークン取得
nagios側
- 監視のためのホスト設定追加
- UPから運動量を取得しnagiosに結果を返すスクリプト作成(今回はRuby使用)
  - 10日分のいろんな運動データがjson形式で来るので解析&最新の総歩数のみ取得
  - 1万歩以下ならアラート

結果

1万歩以下だと下記お叱りのメールが送られてきます。よお豚野郎！

nagiosではこんな感じ。
サーバに混ざって自分がnagios監視下に置かれています。

認可コードから先はcurl使って手動でアクセストークン取得、運動量取得するスクリプト内ではアクセストークン決め打ち。
このへんはoauth2のgem使って汎用的にしたいところ。あとnagiosじゃなくてTwitterと連携させたい。
流れと言いつつ色々端折っているのでもっと細かくまとめたい。

参考
UP for Developers
Nagios API

2013年10月18日金曜日

Jawbone UP, runtastic 比較

上がJawbone UP
下がiPhoneのruntastic

4キロのランニングの結果比較。

runtasticの方が正しい数値だと思われる。GPS使ってるし。
UPはGPS無いので多分身長等のデータと加速度センサー的なもので計算した距離なのかな？

正確性にはかけるけど目的はたぶん装着しっぱなしにすることによる日々の運動の習慣化とデータ収集だから大体あってればそれでいいのかも。
勝手に運動データ収集してくれるのはなかなか面白い。

とにかくつけっぱなしにしないと始まらないウェアラブルデバイス。それがUP！

これからのライフログアプリ、デバイスは全自動の時代！
夏休みの絵日記の宿題、ネタに関してはほぼ自動化されるわけです！
でも書くのくらいは自分でやれ！

そしてUPにはAPIがあるみたいですね。
運動、睡眠、食事等UPのアプリで見れる情報はひと通り得られるようです。

もっとこういうデバイスが一般的になれば他のライフログアプリやゲームなんかと積極的に連携されるようになるんでしょうね。
スポーツ用品店やアウトドアショップ、スポーツジムなんかともつながると楽しそうな予感…。

2013年10月17日木曜日

師弟登壇・新米サムライの集い 2013へ行ってきました

先日師弟登壇・新米サムライの集い 2013へ行ってきました。

その内容が大変面白いかったのでメモ。

発表全体を通して共通してるなと思った部分抜粋。

一般的な基礎技術の理解の重要性
実際にWebアプリを作る
レビュー、進捗の共有の徹底
chefやserverspec等Ops系のこと

当たり前といえば当たり前なのか？

でもアプリエンジニアの人もchefとかserverspecとかpuppetを勉強するような流れはちょっと意外だった。インフラもどんどん抽象化されていくんですね。

あと印象に残ったこと。

DeNAの徹底ぶり。Webアプリを作る研修。

各フェーズに分けて成果物をレビュー。1フェーズ5回くらい。多い人は10回とか。レビュー通ったら次のフェーズへ。レビューは研修生にとってアウトプットの場であり、インプットの場。

レビューする側は正しく論破する。だめならだめで相手が納得できるように話す。

レビューでの出来事や内容、対象の強み、弱点、何気ない会話、進捗の話、日報、ひたすら記録。徹底したデータ化とPDCAで成長を正しく計測。

フォローアップという制度も面白かった。あまり進捗が良くない人を対象に毎日1:1で30分講師と話す。問題解決、議論のトレーニング。急激に伸びる人もいた。一人ひとり丁寧に。自信を付けさせる。自信は成長のための潤滑油。

人にフォーカスした研修は人生を変える。

ほかにも各社特色があっていろいろ参考になることあったけどもう目が開かない。。。

おやすみ。