2016年のまとめ。

大晦日です。今年2本めのエントリーですが、今年のまとめです。

去年の大晦日のエントリーはこんなでした。

ozamasa.hatenablog.jp

KPTはこんなでした。

K:塩尻にいながらお仕事を継続的にいただけるように来年もがんばります。

P:プログラムを書くことが少なかったので、特にフロント周りでなにかしたい。あと、もっとたくさん本を読みたい。

T:経営を真面目に勉強して実践したい。そして、英語は新しい環境をうまく使ってなんとかしたい。

1月
  • オフィスを引越しました。
  • Cookpad TechConf 2016で刺激をうけました。
2月
  • OSC2016 Tokyo/Springに行きました。
3月
  • いろんなことが立て込んで、よく乗り切ったなという感じでした。
4月
5月
  • 柏崎にシラサギハンズオンのお手伝いに行きました。
6月
  • 塩尻市立桔梗小学校でラズパイ講座をしました。
  • 塩尻市のこども科学探検団でもラズパイ講座をしました。
  • 初のイドバタ会議が開催されました。
7月
  • 晴天が続きました。
8月
9月
10月
  • うんざりするぐらいの雨天が続きました。
11月
  • RubyWorld Conference2016に行きました。松江は相変わらずよかった。
  • CoderDojoShiojiriを復活させました。来年は本格的にやります。
  • 塩尻商工会議所フォーラムで変革?イノベーション?って話を聞きました。
  • 秋葉原で飲みました。また行きたい。
12月
  • 再び!オフィスを引越しました。
振り返ると、

できたことも、やろうと思っててできなかったこともあったけど、あっと言う間で、いい年でした。

すごい刺激のあるお仕事をいただけたので、ありがたいの一言につきます。これからも継続できるように頭を使います。

今年は特に経営的な立場で何かするってことが多くて、事務仕事も増えたのだけど、そういうめんどくさい仕事の解決方法を見つけるために、今の状況は変えないでおこうと思った。例えば、クラウド会計ソフトとかって事務処理ではもう手放せないんだけど、使うとちょっとした気になることが沢山あって、そういうところにチャンスがあるかなとも思っているので、当面、事務仕事は自分でやります。

会社としては、人を増やすのが先か、仕事を増やすのが先か、という課題でぐるぐるしてるところもあるんだけど、雇用する側と、される側の利害がタイミングよくマッチするってのは奇跡に近いのかなって場面にいくつか遭遇して、来年はその奇跡を増やさねばとも思った。

あとは、視野を広げるために多くの人の話を聞きたいし、多くの本を読みたい。山にも行きたい。

ということで、

K:塩尻にいながらお仕事を継続的にいただけるようにがんばります。

P:組織としての体制を作ることに取り組みます。

T:英語と数学をもう1回勉強し直します。

それでは、よいお年を!

Rails Girls と関わるいくつかの方法

このエントリは、 Rails Girls Japan Advent Calendar 2016 - Qiita の15日目の記事です。
前の記事は、12日目 Ayumi-Imaizumiさんの デザイナーの私がRails Girlsに参加して良かったこと - UX/UIデザイナー walkey's デザインブログ でした。

こんにちは。
2015年の3月に長野県塩尻市で開催された Rails Girls Shiojiri にコーチ&レポート班として参加した ozamasa です。
あれから2年近くが経つんですね。早いものです。

さて、 Rails Girls は「より多くの女性がプログラミングに親しみ、アイデアを形にできる技術を身につける手助けをするコミュニティ - Rails Girls ガイド」です。
どんなコミュニティでも、そこと関わりを持ちたいなと思ったとき、その扉を開けるには相当の勇気が必要ですよね。それもプログラミングとなると、まったく触ったことがなければ、怖気づいてしまうばかりです。

今回のエントリでは、Rails Girls コミュニティを例に、まったく関わりのなかった人が関わるにはどのような方法があるのか、ざくっと紹介したいと思います。

1. 宣伝する

まずは、FacebookTwitter などのSNSで流れてくる Rails Girls の情報を追いかけてみましょう。そして、目に止まったら拡散してみましょう。
これが関わりを持つことができるとても簡単な方法です。拡散には、職場の同僚との会話に登場させてもよいですね。

2. Rails Girls イベントに参加する

開催情報をキャッチしたら、ほんの少しの勇気を出して、参加申し込みをしてみましょう。プログラミングの知識は必要なく、年齢制限もありません。軽い気持ちで大丈夫です。
Rails Girls は世界各地で開催されていますので、次はあなたの町かもしれません。開催情報は 近日開催のイベント に掲載され、 FacebookTwitter で流れてくるほか、フリーペーパーや町の広報誌に掲載されることもあるようです。
ちなみに、ウェブアプリを作りたがっている女性と一緒であれば、男性も参加を申し込むことができます。

3. スタッフになる

イベントを運営するスタッフとして、裏方を担当したいという方も歓迎です。
特別な資格は必要ありません。スタッフをしたいと申し出てみましょう。きっと大歓迎されます。

4. コーチになる

もしプログラミングの経験があるなら、コーチとして参加してみてはいかがでしょう。
参加者とプログラミングを一緒に楽しもうという気持ちがあればきっと大丈夫です。
コーチをしてもいいよと申し出てみましょう。きっと大歓迎されます。

5. 記事を書く

イベントの開催レポートを書くレポート班として参加することもできます。
レポート班の存在はとても貴重です。記事書くよと申し出てみましょう。きっと大歓迎されます。

例えば、
公式ブログ
Rails Girls ブログ

るびまの記事
Rubyist Magazine - Rails Girls Tokyo 6th 開催レポート

Shiojiriのときに僕が書いた記事
女性がプログラミングを学ぶきっかけを作りたい!「Rails Girls Shiojiri 1st」開催レポート | Think IT(シンクイット)

このような感じです。

6. スポンサーになる

イベントは多くのスポンサーさんの支援によって成り立っています。
Rails Girls の活動に興味のある企業は申し出ていただくとよいでしょう。
企業としては、Rails Girls イベントの場が貴重な人材と巡り合える場になるかもしれません。


どうでしょうか。そんなに難しいことはないですよね。
Rails Girls は、プログラミングとコミュニティという、2つの素晴らしい体験を同時にできます。
ぜひ体験にしきてくださいね!

2015年のまとめ。

大晦日です。今年のまとめです。

去年の大晦日のエントリーはこんなでした。

ozamasa.hatenablog.jp

最後のところを抜粋すると、

もっとたくさん本を読みたいし、山にも行きたいし、いろんなとこに行きたい。ブログとかちゃんと書きたいし、CoderDojoもRailsGirlsも継続できる取り組み方を考えて実践したい。オープンソース界隈の人たちとの繋がりをもっと広げたいし、スクラム方面の人たちとももっと繋がりたい。プログラムはそこそこ書き続けたいけど、世の中にはこんないいやり方があるんだよって田舎のプログラマに教えてあげたい。つーか、根本的に働き方を変えたい。

「根本的に働き方を変えたい。」のところは達成できました。他のはもうちょっとがんばればよかったかなと思うところもあるけど、あっという間の1年だったので、充実してたとおもう。

1月

  • 柏崎のお仕事をしました。

2月

  • OSC2015 Tokyo/Springに出展しました。

3月

  • 塩尻のRailsGirlsでコーチをしました。レポートも書きました。

thinkit.co.jp

4月

  • Matzが塩尻に来ました!講演57回のうちの1回を塩尻で聴きました。
  • QCon Tokyo 2015に行きました。

5月

  • サラリーマンを辞めました。

6月

  • AWS Summit Tokyo 2015に行きました。
  • XPは何を伝えたかったんだと思う?に行きました。

7月

  • 塩尻の中高生向けRuby講座の講師をしました。

8月

  • 奈良のお仕事をしました。
  • YAPC::Asia Tokyo 2015に行きました。

9月

  • CTCさんのサイトでコラムの連載がはじまりました。

コラム:今からはじめる Amazon Web Services|CTC教育サービス 研修/トレーニング

10月

  • OSC2015 Tokyo/Fallに出展しました。
  • ヒューマンリソシアさんのサイトでコラムを1本連載しました。

初心者が躓きやすいRails4中級編 アーカイブ | 特集・コラム特集・コラム

11月

  • OedoRubyKaigiに行ってきました。
  • RubyWorld Conference2015で松江に行ってきました。
  • 京都に遊びに行ってきました。
  • ノワーズRubyを教えることになりました。

12月

  • RubyKaigiに行ってきました。
  • 統計やっておいたほうがいいかなと思って勉強を始めました。(ある方面で実践始めたので、結果出したい。今のところぜんぜんかすりもしないってのは手法がおかしいのかな。)
  • 年明け早々にオフィスを引っ越します!決まってよかった。

振り返ると、

けっこういろんなところに行ってた。。

今年は一般公開向けのサイトを作るよりも、内部でがんばるみたいな処理を作らせてもらうことが多くて、刺激も受けたしとても勉強にもなった。あと、コラムを多く書かせてもらえたけど、なんというか、もっと洗練された文章を書けるようになりたい。

そして、半分、経営的な立場になって、そういった観点での視野とか思考とか広げていきたい。

ということで、

K:塩尻にいながらお仕事を継続的にいただけるように来年もがんばります。

P:プログラムを書くことが少なかったので、特にフロント周りでなにかしたい。あと、もっとたくさん本を読みたい。

T:経営を真面目に勉強して実践したい。そして、英語は新しい環境をうまく使ってなんとかしたい。

それでは、よいお年を!

たくさんの人にメールを一斉送信する「somen」(Rails製)を公開します。

github.com

概要

たくさんの人にメールを一斉送信できるRails製のWebシステムです。
メール本文にはURLを含むことができて、URLリンクのクリックデータを取得することができます。

  • マーケティング
  • アンケート
  • ここのところ話題の標的型攻撃メール対応訓練

などに使えます。

デプロイ

さっそくですがデプロイの方法です。

  1. clone します
    git clone https://github.com/ozamasa/somen.git
  2. heroku にログインしプロジェクトを作ります
    herokuにアカウントがない場合は事前に作っておきましょう。
    herokuのプロジェクト名は適当なものを設定してください。

    ※ もちろん、GitHubからHerokuへ直接デプロイしてもよいです。
    cd somen
    heroku login
    heroku create somen
  3. heroku に push します
    git push heroku master
  4. db:migrate します
    heroku run rake db:migrate
    ちなみに、MacでherokuのPostgreSQLを触るには「PG Commander」が超便利です。

  5. basic認証のためのユーザー名、パスワードを設定します
    heroku config:set AUTH_USERNAME=hogehoge
    heroku config:set AUTH_PASSWORD=fugafuga
    このシステム全体には一部を除きbasic認証が入っています。認証するための適当なユーザー名とパスワードを設定します。

  6. mandrillのユーザー名、APIキーを設定します f:id:Ozamasa:20151025103300p:plain SMTPにMandrillアドオンを使っているので、まずは、Herokuの管理ページにいって、Mandrillアドオンを有効にします。

    ※ MandrillにはFreeプランがあったはずなんだけど見当たらないので変更があったみたい。無料で運用する場合には別のSMTPアドオンを使ってください。
    SMTPアドオンには送信制限があるので、事前に確認しましょう。

    Mandrillアドオンを有効にしたら、Mandrill管理ページに行き、さらに「Get API Keys」のページに行くと、USERNAMEやAPIKEYが発行されているので、それを環境変数に突っ込みます。
    heroku config:set MANDRILL_USERNAME=xxx@heroku.com
    heroku config:set MANDRILL_APIKEY=xxxxxx

  7. ブラウザで確認できます
    heroku open
    
  8. ブラウザが起動し、basic認証が出ればとりあえずOKです。上記で設定したユーザー名とパスワードで認証すると、こんな画面が出てきます。 f:id:Ozamasa:20151025103317p:plain

デモサイト

デモサイトってほどのことでもないけど、ここです。

http://somen.herokuapp.com

basic認証は「hogehoge/ fugafuga」で突破できます。メールの送信はできません。

使い方

簡単に使い方も書いておきます。

  1. 組織を作ります
    ここの組織はターゲットの組織です。つまりエンドユーザーさんです。
    「新規組織」のページに進んで、もろもろ入力して組織を作ります。
    f:id:Ozamasa:20151025103330p:plain
  2. メールフォームを作ります
    組織を選択して、「新規メールフォーム」をクリックすると、メールの入力フォームになります。
    f:id:Ozamasa:20151025103324p:plain
    - 「To」
      送信先のメールアドレスで、改行して入力すると複数アドレスに同時に送れます。
    - 「本文」
      送信されるメール本文はHTML形式です。よって、HTMLタグを含むことができます。URLを偽装する場合は、アンカータグのhrefに設定してください。
    - 「ランディングページ」
      URLをクリックしたときに表示するページです。自前で持つ場合は、public下にファイルをデプロイしてください。
  3. メールを送信します f:id:Ozamasa:20151025103336p:plain
    メールフォームの右肩の「メール送信」ボタンをクリックするとメールが送信されます。

    ちなみに、送信されたメールはこんな感じ。 f:id:Ozamasa:20151025103243p:plain
  4. 結果を確認します f:id:Ozamasa:20151025103351p:plain
    メールフォームの下にある「結果」ボタンをクリックすると結果画面が表示されます。リンクをクリックしたメールアドレスと時間などが見れます。

公開の経緯

このシステムは、実際の標的型攻撃メール対応訓練で使ったものを改変したものです。魑魅魍魎の独自要求に応えることができないので、ソースを公開してしまいます。テストコードはないけど、ご自由にお使いください。

「手動でメール送信→URLのクリック結果を自分でCSVファイルにまとめてお渡し」と、自分がオペレーションすることしか想定していなかったので、他の人が使うとなったときにはいろんな問題が起きると想像できます。

例えば、

  • メール本文の誤字・脱字
  • メールの誤配信
  • メールが迷惑メール入りする
  • メールがスパム判定される
  • プログラムの誤動作とかエラー(バグ含み)
  • 動作環境に起因する想定外の動作

などなど。

あ、もし、標的型攻撃メール対応訓練を考えていたら、ご連絡ください。少なくとも上記の問題が発生することはないし、プラスαでいろんな提案もできます。

CTCさんのサイトでコラムを書いてます!

『IT・技術研修ならCTC教育サービス』のCTCさんのサイトで、AWSに関するコラムを書かせていただくことになりました!月に1本の予定です。

こちら↓ お時間あるときに読んでみてください!

コラム:今からはじめる Amazon Web Services|CTC教育サービス 研修/トレーニング

 

T字系ER手法で僕がしていた論理削除(via とりあえず削除フラグ)

@t_wadaさんのこのスライド

www.slideshare.net

 

パラパラと眺めていたら「T字系ER手法」ってのが出てきて、久しぶりにいろいろ思い出してしまったので、ちょっと書こうかなと思います。

 

T字系ER手法は西暦2000年あたりにSIerの一部で流行っていたデータベース設計手法で、原則(なのか?)についてはこのエントリーに書いてもらってあるとおりです。

mike-neck.hatenadiary.com

 

抜き出すと、

  • テーブルに状態を持たせない
  • 究極には機械が認識するキーと、人間にとって意味のあるデータだけのエンティティだけですべての業務のデータを構成できる
  • 日付を持つデータはイベント(これもひとつのエンティティ)
  • NULLのデータは絶対に持ってはならない
  • テーブルはでかく作るな、小さく作れ
  • テーブル同士の関連は直接持つな、関連を表すテーブルを作れ
  • 1:1の関連になったとしても、イベントとそれに付随するデータは分離しろ
  • データが増える?金と物理で殴れ(ディスク増強しろ)

1システム1600テーブルあるとか言うのもあながち嘘ではなく、テーブルを分割してナンボみたいなおかしな雰囲気が漂っていたことを思い出しました。

ま、ここまでテーブルが増えると、発行するSQLはJOINの嵐で、酷いものではA41枚にビッシリSELECT文が1個だけだったりして、どうやってテストしてたのか思い出したくもありません。(テストしてません)

当然のことながら、その後のO/Rマッピングの勢力拡大によって、この設計手法は衰退の一途を辿ることになります。プログラマ泣かせでしたし、ほんとよかった。

 

T字系ER手法の原則にある「テーブルに状態を持たせない」というのは、「ステータス列を持たせない」ということです。ステータスを持つようなテーブルをどのように設計していたかというと、とにかくテーブルを分割してました。

例えば、社員でいうと、

  • 社員
  • 退職者

という2つのテーブルを実装します。(これを社員のサブセットと呼んでました。)

この2つのテーブル、含まれる列の構成はほぼ同じで、退職日列が含まれるか含まれないか程度の違いです。「テーブルに状態を持たせない」というよりも、テーブル自体が状態を表していると言えます。

 

ちなみに、先のエントリーでも、こういった社員テーブルはマスター(リソース)でないとおっしゃっていますが、入社、退職というイベントが起きるのでイベントとして扱うようにと、僕も言われていました。(ER手法という名前は、たしか、イベントとリソースの頭文字を取ったんじゃないかなと思います。)

 

で、本題の論理削除ですが、このケースだと、

  • 社員テーブルのデータを退職者テーブルに移動(&退職日を入れる)

としていました。つまり、退職者テーブルにINSERTして、社員テーブルからDELETE。

削除フラグを立てるという論理削除ではなく、いわゆる履歴テーブルみたいな使い方をしていたなあと思い出しました。トランザクショナルな永続的なデータストアといえばそうです。

 

まあ、この設計方法は、論理削除を論じる前に、テーブル構成が冗長になることでの混乱が大きいと思います。マイグレートしながら実装を進めるようなイマ風の開発には向きません。

いま僕が設計するなら、社員と退職者のテーブルはまとめて退職日列を持ちます。削除フラグは持ちませんが、状態を表すような日付列を持つと思います。

 

エクストリームプログラミング刊行記念『XPは何を伝えたかったんだと思う?』トークセッション


角 征典×角谷 信太郎 XPは何を伝えたかったんだと思う? - YouTube

 

6月26日にジュンク堂池袋本店で開催された、エクストリームプログラミング刊行記念『XPは何を伝えたかったんだと思う?』のトークセッションに行ってきました。

登壇は、『エクストリームプログラミング』翻訳者の角さんと『アジャイルサムライ』監訳者の角谷さんです!

そのときの様子がYouTubeにアップされたので、とにかく見てください。面白いです。

 

そもそもエクストリームプログラミングとは

エクストリームプログラミング(XP)は、ソフトウェア開発手法の1つで、世間ではアジャイル開発と呼ばれる部類に属しています。(というとちょっと語弊があって手斧が飛んできそうだけど、、まあいいか。)

ソフトウェア開発のやり方は、よりよい方法はないものかと今も世界中の人たちが議論しているのですが、XPもそのうちのひとつ。ケント・ベックらによって提唱されたものです。

 

作家主義』から読む技術書

このトークセッションで面白かったのは、『エクストリームプログラミング』を『作家主義』という観点からお話しされたところ。『エクストリームプログラミング』は文章が難しく、行間を読む必要があったりして、内容を理解することがちょっと大変。それを、ケント・ベックの人となりを知ることでXPを理解してみようというのは、すごく優しいアプローチだと思いました。

そういった意味では、『エクストリームプログラミング』 は技術書を超えた”何か”と言ったほうがよさそうです。

 

詳しすぎる参考文献

そして、『エクストリームプログラミング』に付録している参考文献にはいちいち注釈が書かれていて、これがけっこう味わい深いのです。

XPはパタンランゲージに大きく影響を受けたのかと思っていたのですが、もっと多くの理論から着想を得ていることを知りました。

そんな参考文献の1つ、『パーマカルチャー』も勢いで買ってしまいました。

パーマカルチャー―農的暮らしの永久デザイン

パーマカルチャー―農的暮らしの永久デザイン

 

 

個人的にはスクラムが好きなんだけど、トークセッションを聞いてケント・ベックが好きになってしまったので、XPも勉強します! 

エクストリームプログラミング

エクストリームプログラミング