ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

読んだ: “Quick Desktop Application Development Using Electron”

leanpub.com

Electronの概念と、基本的な機能を一通りさらってみるという感じ。

  • 触ったのは、コンテクストメニュー、トレイ、ダイアログ、通知、電源、クリップボードなど
  • Angular.jsにも少し触っていて、Loki.jsと連携した簡単な例があった
  • Gulpとかそういうのはない...ぞ
  • コードも素のJavaScript
  • Electronのバージョンがやや古く、そのままでは動かないコードも多いので 公式 API ガイド と一緒に見ると良さそう。あれ、じゃあ公式でいいのでは...

へ〜、こんなもんか感はあったが、作る予定のアプリのキャプチャが貼られているのは便利だった。なお、PDF版しかなくコピペは困難。

miamを使ってIAMの権限をいい感じに絞って適用する

IAMというのは例のAWSのアレ。ユーザのアカウントと権限を管理するやつ。

このサービス、機能が多くてややこしいところがあり、具体的には以下のポリシーで運用するときにそのものズバリの情報がすぐに見つからなかったので、この場でまとめとこうかなって思った。

  • 原則、ユーザ管理操作は禁止
  • しかしそれぞれのユーザは自分のパスワードを更新できるようにしたい
  • さらにそれぞれのユーザは、自分だけAPI AccessKeyの発行をしたい

なお管理のために miam を使う。miamの使い方は説明しませんが、簡単なのでREADMEなど見て入れてください。

原則、ユーザ管理操作は禁止

最初に NotAction でiam系のAPI利用を前面禁止する。許可がホワイトリスト型になる。

group "PowerUser" do
  policy "PowerUser-NotAllowIam" do
    {"Version"=>"2012-10-17",
     "Statement"=>[{"Effect"=>"Allow", "NotAction"=>"iam:*", "Resource"=>"*"}]}
  end
end

しかしそれぞれのユーザは自分のパスワードを更新できるようにしたい

こんな感じの許可でOK。というか、公式にだいたい書いてある通り

iam:ListUsers も許可しないと、AWSのコンソールからユーザリストを表示できないので、操作があまりにも不便になる点に注意。

group "PowerUser" do
  policy "PowerUser-ChangePassword" do
    {"Version"=>"2012-10-17",
     "Statement"=>
      {"Effect"=>"Allow",
       "Action"=>
        ["iam:ListUsers", "iam:ChangePassword", "iam:GetAccountPasswordPolicy"],
       "Resource"=>"*"}}
  end
end

さらにそれぞれのユーザは、自分だけAPI AccessKeyの発行をしたい

「自分だけ」というのが鍵で、 "Resource"=>"*" などと指定してしまうと他人のAPI Keyも発行できて、そういう便利さは要らないので。

自分のユーザのarnだけに絞って操作可能な状態にしないといけない。

ということで、以下のようなマクロ的なメソッドを、オープンクラスで定義する。 IAMFile はただのルビーファイルなので冒頭に書いとけばいい。

追記: コメントにある通り、オープンクラスを使うよりmiamのテンプレート機能を使う方がよく、そもそも ${aws::*} といったAWS側で用意された変数を使うことも可能なようなので、この実装は「ふ〜んこんな手もあるんだ〜」といった程度のものと捉えてください。

AWS_ACCOUNT_ID = 12345678...

class Miam::DSL::Context::User
  def attach_accesskey_policy_for(username)
    policy "#{username}-accesskey-creatable" do
      {"Version"=>"2012-10-17",
       "Statement"=>
         [{"Sid"=>"Stmt#{username.gsub(/[^a-zA-Z0-9]/, '')}20160107",
           "Effect"=>"Allow",
           "Action"=>["iam:GetUser", "iam:*AccessKey*"],
           "Resource"=>["arn:aws:iam::#{AWS_ACCOUNT_ID}:user/#{username}"]}]}
    end
  end
end

気をつけることとして、 Sidアルファベットと数字 しか使えないらしい。ユーザ名にはその他の文字列も使えるのでRuby側でなんとかしておく。

その後、それぞれのユーザのカスタムポリシーとしてこんな感じにできる。

user "udzura", :path=>"/" do
  login_profile :password_reset_required=>true

  groups(
    "PowerUser"
  )

  attach_accesskey_policy_for("udzura")
end

あとは miam コマンドで確認しつつ適用。


こんな感じで、いい感じのIAMポリシーは難しいですが、やっていき方を共有するといいと思います。あととにかく miam は素晴らしいと思います。

それでは、良いお年を!

2015年にリリースしたやつらの紹介

octochan

github.com

curlで叩くとGitHubのIssueにコメントするやつ。Ikachan for GitHub

Sinatraベースで、以下のように config.ru を書くと動く。アクセス制限とかは別のRack Middlewareでやってください。

require 'octochan'

module PB
  class GitHub < Octochan::App
    set :access_token, '......'
  end

  class GHE < Octochan::App
    set :access_token, '.....'
    set :api_root,     'https://your.ghe.local/api/v3'
  end
end

map '/github' do
  run PB::GitHub
end

map '/ghe' do
  run PB::GHE
end

run lambda {|e| [404, {'Content-Type' => 'text/plain'}, ["Please Access /github or /ghe"]] }

populus

github.com

Consulの様々なeventにフックして何かするやつを作るフレームワークのはずだった。

Populus.watch :event, name: "echo" do
  cond {|data| data.any?{|d| d.has_key?('Payload')} }
  runs do |data|
    event = data.find{|d| d.has_key?('Payload')}
    Populus.logger.info Base64.decode64(event['Payload'])
  end
end

全面的に設計を見直したい感があり、いまのところ -type event しかサポートしていない。今年は何かが起こる。

soko

github.com

プラットフォームアグノースティックなサーバメタデータリポジトリみたいなのを1行で操作するやつ。

ConsulのKVSとかAWSのタグとかをストレージに指定できるようにしてある。

$ ./soko put Test Hello
OK
$ ./soko get Test
Hello

結局自分で使っていないという問題があり、仕事で構築しているやつもなんか直接 nova コマンドを叩いているまま。この知見をなんかに生かせるだろうか?

packer-provisioner-serverspec

github.com

Packerで作ったイメージについて、イメージ化の直前にServerspecを走らせ、正しくイメージになってるかどうか検査できるやつ。

いまのところOmnibusでServerspecを入れてExecモード前提で動作する。これ、たとえばSSHに必要な情報ってぶっちゃけPackerが全部持ってるよね(だからなんとかしてSSHモードでも動かせるはずだよね)とか、いろいろオプションを追加する余地がある。誰か頼む、じゃなかった今年は何かする。

{
    "builders" : [
        {
            "type": "amazon-ebs",
            "ssh_username": "centos", // should be sudoable
            "ssh_pty": true, // tty should be available after packer 0.8
            //...
        }
    ],

    "provisioners": [
        {
            "type": "shell",
            "script": "/path/to/your-provisoner.sh"
        },
        {
            "type": "serverspec",
            "source_path": "/path/to/your/serverspec-root"
        }
    ]
}

monkfish

github.com

OpenStack Compute APIから、今のテナントに所属しているサーバ一覧を引っ張って、その情報をもとに /etc/hosts を更新し、内部DNSと替えさせていただきますというやつ。DHCPなどがアレな構成でも安心。

もともとのアイディアはkurodaさんという人のPerlによるスクリプトです。

beforedo

github.com

プロジェクトセットアップのためのツールRailsとかによくある bin/bootstrap.sh みたいな環境構築スクリプトシェルスクリプトなので同じような表現がたくさん出てくるな〜と思ってそんならツールにしようと思って書いたが、使っていないのが問題。。。

以下のような Before.yaml を書いてコマンドを打つと、書いてある通りのいい感じのセットアップをしてくれる。基本的にはべき等。ポート空いてるとか、プロセスがいるとかを見てべき等っぽさを確保してくれる。

- task: mysql.server start
  port: 3306
- task: memcached -p 11211 -m 64m -d
  port: 11211
- task: bundle install --path vendor/bundle
  success: bundle check
- task: cp config/database.yml.sample config/database.yml
  file: config/database.yml
- task: bundle exec rake db:migrate
  always: true
- task: bundle exec rails s
  front: true

fluent-plugin-json_expander

github.com

matsumotolyさん? そんな感じのIDの人のために書いたやつ。タグでexpandするやつはすでにあるが、こっちはデータのボディの属性をもとに別のoutputを展開する。

やや内部実装がハッキーなので、利用する際は修正のプルリクをやっていく気持ちが必要と思う。プルリクお待ちしています。

<match access.summary>
  type json_expander
  subtype growthforecast
  delete_used_key false # or true if you want to delete the key
                        # used in template construction

  <template>
    gfapi_url http://127.0.0.1:5125/api/
    graph_path ${data[mothor_host]}/${data[vhost]}/${key_name}
    name_keys count_2xx,count_3xx,count_4xx,count_5xx
  </template>
</match>

puppet-report_slack2

github.com

Puppet masterのSlackレポーター。すでにあるやつは多分なんかgemの関係で動かなかったので、依存をギリギリまで減らして自作した。今思い出したけど Puppetアドベントカレンダー で紹介し忘れてたじゃん!

なんか海外で地味に使われているのを感じる。英語の問い合わせが僕のメアドに直接来たりした。

様子です

yao

github.com

何度か紹介してるからいいか... Yet Another Openstack client for Ruby

stackspec

github.com

awspecの...アレ。OpenStackのテナントが思った通りに構築できているか、APIを叩いて確認する。yaoのリソースのメソッドを知っていればそのまま使える感じの設計のはずが、まだ Server しか検査できないので頑張ります。。

describe server('stackspec.example.com') do

  its(:name)            { should eq 'stackspec.example.com' }
  its(:key_name)        { should eq 'sample001' }

  its(:security_groups) { should have(4).security_groups }
  it { should have_security_group(name: "https") }

  its('flavor.id')      { should eq '8' }

end
$ rspec spec/tenant_name/servers_spec.rb
OpenStack server "stackspec.example.com"
  should have security group {:name=>"https"}
  name
    should eq "stackspec.example.com"
  key_name
    should eq "sample001"
  security_groups
    should have 4 security_groups
  flavor.id
    should eq "8"

Finished in 2.36 seconds (files took 0.2018 seconds to load)
5 examples, 0 failures

今年はもっとでかいの作りたかった。あと改善するというやつもやりたいところだった。

まあ、いろいろ作ると思います。

あ、スター、プルリク、人柱等お願いします!!1

RailsGirls Fukuoka の準備を支えた技術

このエントリは、 pepaboアドベントカレンダー の10日目の記事です。1日遅れすみません! 前回は... gyugyuさん...

RailsGirls Fukuoka やりました。

さっそく本題ですが、今年7月に @murasakipinko さんと shiho さん、 vareal の寺本さん を オーガナイザーに、九州最初らしいRailsGirlsワークショップ、RailsGirls Fukuokaを開催しました。ペパボつながりでは、ペパボはRailsGirlsを継続的に支援している企業の一つとなります。

railsgirls.com

イベントレポートは以下も是非ご覧になってください!

blog.railsgirls.jp

この準備にあたって、福岡のアンクル事務(と言いつつ会計という一番苦手なやつはshihoさんにまかせっきりでしたが...)として、「準備の基盤づくり」に奔走していましたので、他の地域でこれから開催していくオーガナイザーの皆さんや、福岡でもう一度!という方のためにアドベントカレンダーの機会を借りてここに残しておきます。


GitHubに「実況」をする

まずは、GitHubの活用についてです。

そもそも、日本国内でRailsGirlsを開催する場合、RailsGirls JPという組織が全面的にバックアップをしてくれます。そのためオーガナイザーは一番肝心な「どういうワークショップにしたいか」に集中しやすくなると思います。

そのバックアップの一環として、GitHubRails Girls Japan · GitHub オーガニゼーションの配下にプロジェクトを作ってもらえて、それを準備のために利用することが可能となっています。

RailsGirls Fukuoka 1stでは、このGitHubのプロジェクトを全面的に活用していきました。

具体的には、「やるべきこと」ごとにIssueを立ててならべ、その件に関して何かしたらなんでも(やったこと、思ったこと、困っていること)どんどん書き込んで実況していくというスタンスで利用しています。

f:id:udzura:20151211182014p:plain

これ、一時期に「分報」というのが流行っていましたが、それに近い感じがあります。

c16e.com

  • 自分が何をしているのか、書き下すことで冷静に整理できる
  • 状況を他のオーガナイザーやコーチにシェアできる

というメリットを重視した感じですね。

オーガナイザーの方は、必ずしもエンジニアではないので、ことGitHubとなると初めは面食らうと思いますが、最終的にエンジニアではない方々もちょこちょこと進捗をメモしていたように思います。

Slackを全力で活用した

他の地域の方々(最も参考にしたRailsGirls Tokyo含め?)はFacebookグループを使うことが多いようなのですが、今回はSlackを使いました。

Slackを使う上で最も重視したのは、その豊富な連携機能でした。いくつかの工夫を紹介します。

GitHubの通知

RG FukuokaのGitHubイシューについて、コメントなどは基本的に全部流すようにしていました。Slack通知のいいところは「タイムライン」として眺めて把握できるところかなあと思います。

doorkeeperのメール通知の共有

参加者募集はdoorkeeperで行いました(https://railsgirls-fukuoka.doorkeeper.jp/events/26233) が、募集状況や質問などにすぐ気づけるように、それらのメールを受信したらIFTTT経由でSlackに通知されるようにしました。

f:id:udzura:20151211183513p:plain

具体的には、doorkeeperに登録しているGMailで、以下のようなフィルターを作り、doorkeeperからのメールには全てタグ RGFukuoka をつけるようにします。

f:id:udzura:20151211193811p:plain

そして、そのタグがついたメールを、「特定のラベルを付けたメールをslackに通知」レシピを使ってSlackに流している、という感じです。

IFTTT Recipe: 特定のラベルを付けたメールをslackに通知 connects gmail to slackifttt.com

なお、この仕組みは、Slackのメール連携機能がリリースされる前に作った記憶があり、そのためIFTTTを挟むなど少し複雑になっています。doorkeeperのメールアドレスを他のものと兼用している場合などには使えるかと思います。

くじびきbot

おかげさまでたくさんの応募をいただいたため、残念ながら何名かの方を落選という形にしないといけませんでした。 公正になるよう、LitaというRubybotフレームワークを使い、Slack上で当落のくじを引く形をとりました。

f:id:udzura:20151211183451p:plain

今見ると、なんか方言間違ってますね......。

このbotソースコードは以下に公開しています。

github.com

Windows上で直接Ruby on Railsを走らせるのは、今回は諦める

RG Fukuokaでは、非エンジニアであるオーガナイザーの意見も聞いて、Windows環境で直接Ruby on Railsチュートリアルをするのは断念しました。

その代わり、VirtualBox上にUbuntu Linux(Desktop版)の環境を作り、そこで作業をしていただくという方針にしました!

一般的に、学習に必要な概念が増える(今回はPC仮想化であったり、VirtualBoxというツール)のは望ましくないので、他の地域ではWindows環境でのRoR環境の構築を選択していると思いますが、今回は、

  • PC仮想化という概念自体は理解していただけそうな生徒さんが多いこと(非エンジニアの方でも、IT系のサポートの職の方などが多かったです)
  • 難し目の手順が増えるWindows構築より、Linuxさえ立ててしまえばほぼ素直にデバッグできる方が結局トラブルが少ないのでは?と考えたこと
  • 非エンジニアであるオーガナイザー的にも、新しいツールに抵抗を感じないのではないかと思われたこと

結果として、ほとんど全員herokuなどへのpushまでたどり着いています。これはなかなかの成果だと思います。

一方で、純粋にマシンパワーが足りないような(「いんてるせんとりの」、と書かれていました...)Windowsラップトップをお持ちした生徒さんもいて、その方はかなり苦戦、というかいちいちレスポンスが遅くて大変だったようでした。

ほかにも、32bit版のWindowsの存在(Ubuntuも32bitになり、Atomが動かないとか...)など、ちょこちょこと困った点が出てきていました。

Nitrous のようなクラウドでの環境構築ができるツールの検証を進めても良かったかもしれません。

コーチ向けのマニュアル、地域の手順向けのマニュアルをつくる

上記にも関連して、幾つか自分たち向けのマニュアルを作ってみています。

公式のRailsGirls Guideも、もちろん生徒さんと一緒に見るものとして活用しますが、「教える側のメンタルモデル」に沿ったマニュアルがあると便利かなあということで、Guideを通した際に一緒にメモ書きしたものがその一つです。

もう一つ、Ubuntu on VirtualBoxの環境構築のマニュアルを @monochromegane さんの手で作ってもらいました。当日は大変役立ったそうです。

これらについては、公式ドキュメントや coach.info に順次共有するといいかな...と思いつつまだまだなのでした...

KPTについて

以上のように工夫をこらし、当日を迎えましたが、やはりどうしてもうまくいかなかった点、逆に存外良かった点などが出てきました。

KPTという形で後日まとめています。その一部はこんな感じです。

Keep

  • 番長制度(LLイベントの準備でやっている技を盗みました...)を導入し、お弁当番長、会場設営番長など、ざっくり役割を分担した。「担当」という感じではなくみんなで頑張る、けど一番がんばる人、ぐらいのニュアンスを「番長」という言葉で出せた気がする
  • 月一でリアルミーティングを開いたのは良かった
  • フリーコーチという形で、他地域のコーチ経験者を中心にグループに入らないで全体を見て回る係を用意した。いい感じのフォローができた気がする
  • オーガナイザー・コーチでなく、当日動ける人がいると大変ありがたい。今回は、 WANさん という学生団体の皆さんにお手伝いしていただいています。当日レポ

Problem

  • 1日目のインストール、終電もあるので、人によってはある程度で見切りをつけるのも必要だったかも。
  • Facebookなどでもいいが、「その場でコーチと生徒さんが情報共有できるオンラインツール」が欲しかった
  • ミーティングは、オーガナイザーなど企画を考える人とコーチとで別々に行っても良かったかも。コーチはあくまでコーチなので、直接関係ない話も多い......
    • 一方、コーチは人数も多くなるので、当日初めて顔をあわせる人が多いと困ってしまう。全体で集まる機会を事前に作れれば良かった?

Try

  • Google Docsなどをちゃんと使い、運営側の参加者リストも早めに用意する。
  • PC(Mac)貸し出しができないか考えてみる
  • FacebookグループでもOSSチャットツールでもSlackでもいいけど、当日のオンラインコミュニケーションツールがあると良かった。用意する。

他地域でも参考になるかと思います。

最後に

オーガナイザーの3人を始め、同僚でもありコーチとして全面協力をしてくれたmonochromeganeさん、ほかコーチとして様々な検証をしてくださったYukinari3poさん、E-Zuka Railsの主催者として、コーチのほか、コミュニティ的な観点で色々アドバイスをくださった谷口さんには大変お世話になりました。

また、個人的に日本のRailsGirlsの中心人物でもあると思ってるRG Tokyo 2nd(私が最初にコーチをした回ですね)のオーガナイザー、@yotii23さん、前職でもお世話になった藤村さん、Osakaのオーガナイザーでもある@satomicchyさんを始め、経験者の皆様に準備/当日ともに多くのアドバイスをいただきました。

マインド含め一番影響を受けているyotii23さんの地元、福岡でこうして開催できたのは感慨深いと思っています。

その他、スペースの関係で皆の名前を出せませんが、様々な方々の助けを借り、無事成功したと思います。ありがとうございました。


ということで駆け足となりましたが、RailsGirls Fukuokaを支えたかもしれない工夫などを紹介しました。

明日(今日...)は @kurotaky メンバーの記事です(そういえば彼もTokyoのコーチですね)!

雑にTOTPを試してみる

2要素認証でおなじみのTOTP。Railsなどでどう使えばいいか。雑に試す。

Gemfile

今回はrotpというgemと、二次元バーコード(QRコード、というと商標なのでポリコレな表記をしていr)の表示のためにrqrcode_pngを使う

gem 'rotp'
gem 'rqrcode_png'

TOTPを試す

コンソールで:

totp = ROTP::TOTP.new("hogehogefugafuga")                                           
#=> #<ROTP::TOTP:0x007fd5fad22850 @digest="sha1", @digits=6, @interval=30, @issuer=nil, @secret="hogehogefugafuga">
totp.now
#=> "241886"
loop { p Time.now; p totp.now; sleep 1 }
2015-11-27 18:26:50 +0900
"579205"
2015-11-27 18:26:51 +0900
"579205"
2015-11-27 18:26:52 +0900
"579205"
2015-11-27 18:26:53 +0900
"579205"
2015-11-27 18:26:54 +0900
"579205"
2015-11-27 18:26:55 +0900
"579205"
2015-11-27 18:26:56 +0900
"579205"
2015-11-27 18:26:57 +0900
"579205"
2015-11-27 18:26:58 +0900
"579205"
2015-11-27 18:26:59 +0900
"579205"
2015-11-27 18:27:00 +0900
"703388"
2015-11-27 18:27:01 +0900
"703388"
2015-11-27 18:27:02 +0900
"703388"
...

確かに1分単位で変わっている様子がわかる。

これをデバイスに送りつけるための二次元バーコードを生成。

url = totp.provisioning_uri "udzura@auth.udzura.jp"
#=> "otpauth://totp/udzura@auth.udzura.jp?secret=hogehogefugafuga"
png = RQRCode::QRCode.new(url, size: 10, level: :h).to_img
#=> <#ChunkyPNG::Image>
png = png.resize(200, 200)

ChunkyPNG、ファイルに書き出さなくても、data URLを吐き出すメソッドを持っているので便利。

png.to_data_url 
=> "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMgAAADIAQAAAACFI5MzAAAEcUlEQVR4nO1Xv27iTBCfjZGW5jB0sWTHlngCOiNZsjue4+Me4DBpaL7YThqaGPIAl3sOOltC8nbUVyCtgyXoYpPGK2H2Wx4A5bT5ytvOGs14/v1mfnPDr70buPb+Sv5/CUdIRbnviY92HjJjmrYqhELZ/7g8SgBSYROcR9jd2RTxk7TXrMVHzktmTu1b5dlrjYkFqfWFHKDVegLrIGFNiOkrpn+ic13CR33DawLvUIxF3tgf6VyT4BOq9DHoQLjSy+gDOOBSaWspCrz162DftQ9aSZwjbgLUkrWGOC/xsMqaEm7hlcHSpirn0h0..."

表示されている様子です

この画像をGoogle Authenticatorなりなんなりで取り込んで、

loop { p Time.now; p totp.now; sleep 1 }

このループの表示と見比べて満足して今日は終わり。

Devise との連携

github.com

こういうのがあったが、果たして。