しばらく前になるけど、
http://blog.ponpokopon.me/ に移転した後
http://ghost.ponpokopon.me/ に移転しました
WhiteWater
2014年12月9日火曜日
2014年3月13日木曜日
phdocとherokuでシンプルなwiki作成
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
これで公開されました。めでたしめでたs…ん??なんか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日金曜日
2013年12月16日月曜日
Agile Samurai Base Camp行ってきました!
初心者向けみたいで参加しやすそうだなと思ったので行ってきました。明日から始められるというフレーズもいいですね。そういうのに弱いです私は。
TDDとインセプションデッキのセクションがあって、私はインセプションデッキの方に参加してみました。 メモや感想を書き出してみます。
はじめに著者のジョナサン・ラスマセン氏からのビデオメッセージが。やってほしいことを3つ。
前半はインセプションデッキとTDDは別れておらず、なぜアジャイルサムライという本が誕生したかといった内容や影響を与えた書籍、なぜサムライ?と言った話でした。
様々な書籍がある中で、
デッキを作るタイミングはたくさんある!
インセプションデッキ。自分で始める際どうやってみようか考えました。とらわれ過ぎない。現場ごとにやりかたは変わる。
準備→理解→調整→まとめという流れ、うまく取り入れられないだろうか。
きっと理解、調整の部分は毎日の朝会でできるんじゃないかな、とか。
1周間そんなことを意識してみたりしました。そして常に改善していく!
今回参加してよかった!皆々様ありがとうございました!
TDDとインセプションデッキのセクションがあって、私はインセプションデッキの方に参加してみました。 メモや感想を書き出してみます。
はじめに著者のジョナサン・ラスマセン氏からのビデオメッセージが。やってほしいことを3つ。
- 学んだことや今日あったことを共有する
- 常により良い方法を探し続け改善し続けること
- 楽しむこと
前半はインセプションデッキとTDDは別れておらず、なぜアジャイルサムライという本が誕生したかといった内容や影響を与えた書籍、なぜサムライ?と言った話でした。
様々な書籍がある中で、
- 現場にどう合わせていくか
- 手法や用語にとらわれ過ぎない
- 学びながら調整していく
インセプションデッキの話
明日からインセプションデッキを始めようの話。基本アジャイルサムライに則ったお話でした。それをどう明日から実戦していくか。- 準備→理解→調整→まとめ
- 準備
- まずは自分の理解をまとめてみる
- 見聞きしたこと、経験、ドキュメント、調査したこと
- たくさんのインプット
- 理解
- 知っている人に聞いてみる
- 達成するべきこと
- 誰が使うのか
- そもそも経緯は
- マネージャ、エンジニア、等、それぞれの立場
- デッキじゃなくて質問しよう
- 調整
- 自分が不安に感じていることを伝える
- こういうところが気になるんですが…程度で良いので聞く
- まとめ
- 最新情報をまとめて周りに伝える
- スライドにまとめると伝えやすい、次に繋がりやすい
- 共有フォルダはアカン!(誰も見ないw)
デッキを作るタイミングはたくさんある!
- プロジェクトが始める前
- 自分にとっての初日(参加した日)
- ふりかえりのとき
- 悩んだ時
- などなど…いつでも良い
自分に当てはめてみる
インセプションデッキのお話のあと実際にワークショップを行いました。その後再び講演で現場ごとのお話でかっこいいセリフが出たりしていました。インセプションデッキ。自分で始める際どうやってみようか考えました。とらわれ過ぎない。現場ごとにやりかたは変わる。
準備→理解→調整→まとめという流れ、うまく取り入れられないだろうか。
きっと理解、調整の部分は毎日の朝会でできるんじゃないかな、とか。
1周間そんなことを意識してみたりしました。そして常に改善していく!
今回参加してよかった!皆々様ありがとうございました!
2013年12月2日月曜日
jawbone up apiで自分をnagios監視下に置く
JAWBONE UP APIを触ってみた。
先月届いたリストバンド型ウェアラブルデバイスのUP。APIがあったのでなにかやってみようと思います。
運動量が一定の値以下なら警告をだしてみます。
nagiosではこんな感じ。
サーバに混ざって自分がnagios監視下に置かれています。
認可コードから先はcurl使って手動でアクセストークン取得、運動量取得するスクリプト内ではアクセストークン決め打ち。
このへんはoauth2のgem使って汎用的にしたいところ。あとnagiosじゃなくてTwitterと連携させたい。
流れと言いつつ色々端折っているのでもっと細かくまとめたい。
参考
UP for Developers
Nagios 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分講師と話す。問題解決、議論のトレーニング。急激に伸びる人もいた。一人ひとり丁寧に。自信を付けさせる。自信は成長のための潤滑油。
人にフォーカスした研修は人生を変える。
ほかにも各社特色があっていろいろ参考になることあったけどもう目が開かない。。。
おやすみ。
登録:
投稿 (Atom)