駅データ.jpの駅データ保存スクリプトを書きました。
駅データ.jpとは、その名の通り駅データ（鉄道事業者・路線・駅・接続駅）が取得できるサービスです。基本無料で登録しデータを取得でき、より詳細なデータが欲しいときには有料プランも用意されています。
駅データ.jpから無料プランで取得したデータをデータベースに挿入するスクリプトを作成しました。
ソースは以下にあります。
動作環境
使い方
参考： 駅とか路線のマスターデータの入手方法 - Qiita
2015/6/17追記： データは駅データ.jpさんで管理しているので、テーブル定義に外部キー制約は入れておりません。
レポート：AWS Summit Tokyo 2015 デベロッパーが切り拓く、次の時代
AWS Summit Tokyo 2015に参加し、DevConの14:20~15:00の枠である
【パネルディスカッション】デベロッパーが切り拓く、次の時代
のメモを取ったので取り急ぎまとめます。
以下、伊藤様の発言は「伊：」大場様の発言は「大：」で表記します。特に表記がない場合（テーマ1など）はまとめている場合です。
また、発言者についてはまとめてしまっている部分もあり、100%ご本人の発言でない場合があります。
テーマ1 変わったこと、変わらないこと
技術的には、かつて技術はBtoBからBtoCへ流れていた。大手のベンダーから技術提案があり、それにキャッチアップすることが重要だった。ベンダーからロードマップが提示され、それにどう対応するかを考える部署すらあった。今は誰もロードマップを提示してくれない。 ロードマップが提示されないのは技術だけでなく、ビジネスも同様である。
テーマ2 技術を取捨選択した際の大原則・考え方はあるか？（個人として）
伊：オープンな方を選択してきたが、それが正解かは分からない。これはBtoCの業界にいたことに由来しているだけ。そもそも、技術を選択してキャリアを作り上げていくという考え方が良くないのでは。
大：技術を選択してこれでいこう！というのは怖い。今までの傾向としては、目的のものが７割８割しかできない、メインストリームからはおもちゃのような技術を選択してきた。おもちゃで遊ぶ感覚。
テーマ2-1 技術を選択するうえで、興味が先か、課題が先か
伊：課題が先。自分の場合、興味は課題から発生する。技術者が今使えるものを使用すると失敗する。この技術はここまでしかできないからという先入観が邪魔する。
大：課題の中で技術を楽しむ。やはり（ある程度は）背伸びはした方が良い。
テーマ3 これからの外部環境の変化をどう迎え撃つか
伊：マネジメント面、先に話に出たが、技術だけでなくリソース・スケジュール全ての面で曖昧になっている。Saasとかになってくると、様々な要素が不透明な状態で進めなければいけない。エンジニアはこの曖昧さに耐性がなければならない。曖昧な中で仕事の中で進まなければならない。
大：マネジメント面、環境は変化するということを受け入れられることが大事。決められた枠組みで粛々と進めたい人だと厳しい。
また、開発部として開発しかしないような枠組みにしてしまうと「開発だけしてれば良い」という考えを生むため失敗してしまった。事業部ごとに分割すると責任は曖昧になって個人にかかる負担が増えて大変だが、それは耐えなければいけない。また、フルスタック指向があるエンジニアでも、その時興味がある技術にロックインされるし、やりたいことがあっても不慣れな分野だと他に自分よりレベルの高いエンジニアがいたら遠慮したりする場合があるので、組織的にある程度ローテーションさせて新しい技術に触れさせる枠組みを作ることが大事。
以上です。
感想
特に印象に残ったのが「曖昧なまま進む強さ」が必要だとお二人ともに同意していた点です。これは私がSier系の下請けからWebサービス(BtoB)分野への転職した際に大変だと感じたことだからです。
当たり前ですが、サービスの場合はそもそも作るものやニーズが確定していません。もちろん、顧客対象となりうる方々からのヒアリング等を実施し可能な限り調査しますが、たとえその場合でも、サンプル数は不足しており無作為抽出ではないので、統計的なことは言えず、「このような分野・機能にニーズがあるという意見がある」としか言えません。そのような状態から、ユーザー目線で試行錯誤し何を作るか決めなければならないのです。
このように、サービスのケースでは不特定多数がお客様であり、ニーズや流れを捉えきれないとサービスを継続することは困難である一方、受託の場合はまず相手が決まっていて、話合いを重ねた上で何を作るか確定させることができます。仕様変更があったとしても（特定の）お客様の要望であるので、考えるべきリスクは仕様変更の影響で生じる工数追加などのコストが主です。これは、サービスの機能追加が必ずしもユーザーからの要望のみで行われるわけではなく、ニーズを生むために先手を打って機能追加を実施するのとは対照的です。当然、この場合はそもそも当該機能が必要とされる100%の根拠はなく、ユーザーの反応によっては徒労に終わるリスクがあります。
ビジネスモデルの差異はエンジニアの意識の違いにも反映されます。前職の場合は機能追加などの指示があっても「何を」作るのかは上から降ってくるので「どの位の期間で」「どのように」作ることだけを報告し考えれば良かったのですが、現職で同様の指示があった場合「それが本当に必要か」「具体的にどのような機能を作るのか」まで一エンジニアが考える必要があるのです。
これは私の経験に基づいた話で、お二人の話す「曖昧さ」が全て上記に合致しているのかを判断することはできませんが、大きくは外れていないのではと思います。
自分でも強く意識していた不確実性への対応が必要という点を、お二人のような方からの口からも聞けて良かったです。色々曖昧なまま進むことが良いのか、判断を先延ばしにしてももう少し不確実性を排除した方がいいのか、転職してからずっと悶々としていて、やはり決まらないことはあるので進みながら試行錯誤しその都度対応していくのが良いんだろうなぁと思いました。
追記 : 誤記を修正しました。感想を追加しました。
AWS体験ハンズオン ～セキュア&スケーラブルウェブサービス構築～に参加してきました。
RDSの導入を検討していたので、AWS体験ハンズオンに参加してきました。
5月19日 AWS体験ハンズオン ～セキュア&スケーラブルウェブサービス構築～(東京都)
ハンズオンの流れ
導入: VPC・サブネット・ルートテーブル・IAMなどの説明をして頂きました。
ハンズオン: サーバ1台構成から立ち上げ、web + DB の2台構成、LB + web×2 +DB の3台構成、最後にLB + web×2 +DB×2のDBサーバ冗長化構成を作成するという流れでした。最後のDB冗長化構成は、時間が余った人のオプションという扱いでした。 LBにはAWSのサービスであるロードバランサーを使用し、DBにはRDSをMySQLで使用しています。RDSについて
RDSの導入のインセンティブが主に冗長化構成だったので、それに関して書きます。RDSは、マルチAZ配置のon/offの切り替えで、Master/Slave構築を行ってくれます（ホットスタンバイ）。セミナーでお聞きした特徴は以下の通りです。感想
弊社のようなスタートアップではまだインフラ専任のエンジニアがいないため、Act/SbyのDBサーバの運用構築作業や、障害時にフェイルオーバーし原因を特定して切り戻す作業など、これらの作業を滞りなく行うのは厳しいと言わざるを得ないので、RDSを導入するメリットがかなり高いです。ハンズオンで分かりましたが、RDSのインスタンスの作成もEC2インスタンスの要領で簡単に出来ました。疑問・課題
フェールオーバーした後、落ちた方のサーバの復旧はどうするのか聞き忘れました。調べないと。最後に
無料にも関わらず非常に分かりやすいハンズオンでした。スタッフのみなさん本当にありがとうございました。
シェル変数の末尾の文字を削除する
シェル変数の末尾の文字を削除する
シェルスクリプトを書く際、変数の末尾についた余分な記号を取りたいとき、以下のように行っていた（以下、"bananapencilbook"という文字列から"book"を削除する）。OSはCentOS、シェルはbashです。
$ echo ${testvar}
bananapencilbook
$ echo ${testvar} | sed -e 's/book$//g'
bananapencil
上の方法は末尾の文字列以外にも適用できるので楽なのだが、他に何かないか探していたところ、 同じことが以下のようにできるらしい。
$ echo ${testvar%book}
bananapencil
%以下の文字列に後方一致するものを削除するという機能なのだが、他にも便利な記法があるようで、 以下にまとまっている。
あるものは使いましょう。とりあえずsedで何とかしちゃうのダメですね。
