SoftbankからMVNO（IIJ mio）に移った

はじめに

iPhone 3Gが出てからずっとSoftbankを使っていたのですが、一念発起してナンバーポータビリティをつかってMVNO（IIJ mio）に移りました。すでに書きつくされたことのようにも思いますが、自分もMVNOする前は色々と検索しまくったので、なんらかのお役に立てればと思い、顛末を書きます。

動機

そもそも移った動機は料金です。

• Softbankでは大体4,000円/月。端末を一括で買って月々の料金を低く抑えています。
• データ通信は5GB/月ぐらい。外出先でYoutubeを見ることはないので、大体これぐらいで収まる。
• 周りを見るとMVNOに移っていい評判しかしかなかったので、思い切って移ってみることに。

準備

Softbankのまま機種変するのが一番ラクで、色々と悩んでいたときにこんなDMが届いたので心がグラッと揺らぎましたが、2年縛りが解ける11月を迎えたので、えいや！ってな感じで移ることにしました。

事前準備としては、次のことをしました。

• キャリアのメールアドレスを使っている場合は、メールアドレスの変更を通知
• AmazonでIIJmio みおふぉん SIMカード 音声通話パックを購入
  • IIJのサイトから申し込んでもよいのですが、それだと3,000円かかってしまうので、事前にAmazonでパッケージを買った方が安いと思います。ちょうどキャンペーン中でデータ容量が増えるので買っておきました。

IIJmio みおふぉん SIMカード 音声通話パック ( バンドルクーポンキャンペーン中 4GB増量×3ヵ月間 ) FFP【Amazon.co.jp 限定】

MNP

MNP予約番号はSoftbankに電話。朝イチで電話しても相変わらず中々つながりませんが、じっと待つこと5分、繋がって会話するとMNP予約番号がSMSで届きます。

MNP予約番号を手に入れたらすぐさまIIJ mioのサイトから手続き。事前準備で購入しておいたパッケージを利用して手続きを進めます。手続きを終えると本人確認書類の提出が求められるので、運転免許証を撮影して指定したサイトにアップロードして終わり。審査には1日ぐらいかかるので、のんびり待ちましょう。

その後SIMの発送連絡が審査終了後の翌日。SIMを受け取ることができたのは審査終了後の翌々日でした。

この段階ではまだSoftbankの契約は生きている状況で、IIJに移るためにはもう一段階、手続きが必要となります。

シムフリー版携帯の入手

MNPの手続きをやっているのと同時にシムフリー版携帯を入手します。Apple教信者の自分はiPhone 7を選択。Apple Storeでオンラインで購入。翌日には届きました。

シムフリー版iPhoneは電源入れた後はアクチベーションが必要となります。自分は、まだ移行が済んでいないIIJ mioのSIMを入れました。これでもアクチベーションは通り、WiFiだけでの運用が可能です。

開通手続き

IIJからSIMが届いてから数日後、ようやく時間が取れたので開通手続きを行います。手続きは自動音声ガイダンスへの電話一本かけるだけです。電話をかけた後、Softbankの回線が切れ、少し時間が経ってからIIJ mioの回線が使えるようになりました。その間大体2時間。iPhoneのバックアップデータから復帰して再セットアップなどをしているといつの間にか使えるようになっていました。

運用

移行後、一週間ほど使ってみていますが特に不満点はありません。電話の受発信も問題はないし、データ通信にトラブルも特にありません。1日の使用データ量も大体150MBぐらいなので、プラン内に収まりそうです。

まとめ

思ったよりも簡単に移行できました。長々と待たされた挙句にたくさんの書類を読まされ気を抜くといろいろな契約を結ばされる店頭でのキャリア契約よりストレスフリーで移行できるのは良かったです。

大阪マラソン2016を走ってきた

2016年10月30日（日）に開催された大阪マラソン2016を走ってきました。

幸運なことに抽選に当たったので、参加することに。

connect.garmin.com

目標はサブ4。キロ5分半で30キロまでは走り、そこからは残った体力勝負ってな感じで入ったのですが、残り5キロぐらいから大体死んでました。

最後、気力を振り絞ったのですが、サブ4まであと一歩足りず...というか、わざわざ手に入れているものを自ら放棄している感じかも。

前日

ゼッケン受付が前々日と前日のみ。事前配送物はなく、ネットで手続きをするだけ...なんだけど特に通知も何もなく、たまたま覗いたWebページでネットでの手続きが必要なことに気がつきました。ちょっと不親切な気がします。

前日の土曜日に横浜から大阪に移動し、ゼッケンを受け取ったあとは早々にホテルに向かい、早々に就寝...しようとしたのですが、ちょうど日本シリーズをやっていたので、寝るに寝られず。結局23時ぐらいまで起きてしまいました。

当日（スタート前）

朝は5時ぐらいには起きて朝食。準備をして6時半にはチェックアウトして大阪城公園へ。すでに多くのランナーで電車が埋まりました。

荷物預け締切が8時。整列締切は8時40分。荷物預けはサクッとできたのですが、整列はトイレ渋滞と整列場所までの混雑がひどく、30分前に移動開始したのにギリギリセーフ。ここらは運営側の改善がほしいところ。

スタート

あたふたしたままスタート。スタート直後の渋滞もそんなに無く、キロ5分半のペースを掴む。このままいけるかなぁと思ったけど、どうしてもペースが上がってしまう。抑えよう抑えようとずっと心がけながら走る。

10キロあたり

5分半/kmを目安に走っていると、いきなり肩を叩かれる。何事？と思っていたらランステで見知った仲間が。ちょっと元気が出る。このままペースを維持しながら距離を刻む。

20キロ過ぎ

半分。ちょっと疲れている。いつの間にかランステの仲間とも離れ、途中で「サブ4目指している」という桧山のユニフォームを着たランナーと並走する。大阪という土地柄なのか、阪神のユニフォームを着た人を結構見かける。

30キロ過ぎ

時計を見るとちょうどいいペースで来ている。これからが辛いところ。体の調子がダイレクトに出てくる。

そんなさなか、右ふくらはぎがちょっと痛みだす。これまでになかった痛み。ちょっとやばさを感じる。

37キロ過ぎ

南海大橋あたりで右ふくらはぎが攣りそうになる。やばい...。ちょっと歩いて様子を見る。大丈夫そうなので、徐々に走ると痛みが出てくるポイントがあるのでほぼ早歩きな感じで前に進む。後5キロ。こんなに長かったっけ...

ゴール

そのまま痛みはあまり引かずにゴール。う〜ん、ちょっと悔いが残るタイムだしレースであった。ちょっと残念。

ゴール後

ゴール後は、ゆっくりと着替えをし、無料のマッサージを受ける。会場から大阪駅までの直行バスを予約していたのでそれに乗って帰る。このバスは完全予約制。自分は17時の便を予約していたんだけど、早めに行って聞いてみたら「空席があったらOKですよ」ということ。無事、空席が出て早めに帰ることに成功。その後はJRで新大阪まで行き、新幹線で横浜まで帰る。マッサージを受けた結果か、そこそこ普通に歩けて帰れた。

反省会

やっぱりというかいつも通りというか、35キロ過ぎが自分にとって勝負。辛い時にかんたんに心が折れてしまうのはどうやって鍛えたらいいんだろうと思うんだけど、やっぱり長い距離の練習なのかなぁ。

RubyWorld Conference 2016で喋ってきた

はじめに

2016年11月3日と4日に島根県松江市で開催されたRubyWorld Conference 2016で講演者として参加してきました。

RubyWorld Conferenceは、毎年島根県松江市で開催されるRubyのカンファレンスなのですが、出席者の半数ぐらいがスーツな人で占められる不思議なカンファレンスです。県知事と市長による挨拶があるカンファレンスはおそらくこれぐらいでしょう。

CFP

講演者としてRubyWorld Conferenceに行くためにはCFPを出して採択される必要があります。ここ数年の傾向を見ると、

• システムをRailsで構築しましたっていうのはすでに当たり前なので、採択される可能性は低い
• 去年ぐらいからmruby関係の採択率が高いような気がする
• 教育は一定の枠がある感じ
• 深い技術的な話はあまり求められていないようなきがする

みたいな感じ。今回は、参加しているOSS推進フォーラムアプリケーション部会でやっているmrubyの話をまとめてCFPとして出したら採択されました。

発表内容

半数以上がスーツな人で占められることと、mrubyに関してはET展などで「どうやって始めていいかわからない」っていう声を多く聞いたことから、mrubyでアプリケーションをどうやって作るかについて簡単に紹介することに時間を費やしました。

後で話を聞くと「分かりやすかったです」という声をたくさん聞いたので、狙いとしては成功だったように思います。

時間の関係上、

• mrbgemsの探し方（詳細版）
• mruby-cliについて
• Azure Web AppsでRailsアプリを動かす方法

については全く喋りませんでしたので、聞きたい人がいましたらお声がけください。

あと、資料は後ほどRubyWorld Conferenceの公式サイトにて公開される予定です。

テーマについて

今回は、mrubyを使ってセンサーデータを収集してAzureにデータを送信するって話をしたのですが、最初始めるときは色々と舐めてました。

• mrubyってほとんどCRubyと同じでしょ。同じアプリをちょっと編集すれば動くでしょ。
  • →う、動かない...
• mrbgemsってググれば適当に見つかるでしょ。
  • →見つかることは見つかるんだけど、どう書けばいいか分からない
• Raspberry Piでとりあえず動かしてみて、すぐさま組み込みにチャレンジだ
  • →組み込み、めっちゃ大変。半田付け難しい、メモリ足りない

実際にやってみるとその大変さが分かりました。

今回は、「CRubyでいいじゃん」ってな結果になったのですが、徐々にmrubyでしか出来ないようなものにもっていきたいので、徐々に突き止めてみようかなと思っています。

第70回 Yokohama.rb にてどう書くの問題にチャレンジした

はじめに

毎月第二土曜日ぐらいにYokohama.rbという地域Rubyコミュニティを開催しています。ここ最近、レシピブック読書会を @igrep さんと @nabetani さんに丸投げしていていました。

Rubyレシピブック 第3版 303の技

このままの状況、運営としてはイケてない！と感じ新しいコンテンツを探そうと思っていたところ、 @nabetani さんから「どう書く」のYokohama.rb版を提供して頂けることになり、早速試してみました。結局人様に頼りっきりで申し訳ないんですが...

@miyohide 問題用意しましょうか？（どたきゃんですいませんでした）

— 鍋谷 武典 (@Nabetani) 2016年6月12日

今回の問題

今回の問題は、Rails on Tiles yokohama.rb 2016.7.9 問題。

自分の戦略

ポイントは、画像で表現されているタイルをどのようにプログラムとして表現するか。ここがいろいろと悩みましたが、自分は「上辺のものはどこに移動するか」「左辺のものはどこに移動するか」...という形でHashで表現しました。こんな感じ。

Tiles = [
  {top: :left, left: :top, right: :down, down: :right},
  {top: :right, left: :down, right: :top, down: :left},
  {top: :down, left: :right, right: :left, down: :top},
  {top: :death, left: :death, right: :death, down: :death}
]

あとは、入力文字列をParseしてフィールドを作り、枠外もしくは行き先がdeathに行ったら処理終了という流れでベタに書きました。それが次のコード。

Yokohama.rb 70回で出題された問題の回答です。

わかりやすいコードを書くことを心掛けているので、多少長いのはしょうがないのですが、流石に長過ぎるのでもうちょっとあがいてみます。

他の人の答え

• @hamaknさん

70th Yokohama.rb どう書く http://nabetani.sakura.ne.jp ...

• @nabetaniさん

qiita.com

• @nomnelさん

nomnel.hatenablog.com

Togetter

togetter.com

次回は？

次回は8月第1週の8月6日開催予定です。

yokohamarb.doorkeeper.jp

TokyuRuby会議10でLTしてきた

概要

TokyuRuby会議10でLTしてきました。

ネタは、次のるびまシステムについて。

Markdownで書きたいというニーズは結構あるのですが、そこが本質ではなく、運用に疲れ始めたからというのが今回のLTのネタ元です。

進捗

で、肝心のシステム刷新ですが、手元では全記事の移行ができています。が、表示させてみるとレイアウトが崩れたり、Amazonの書影を取ってくるところが未実装だったりするのでなかなかリリースまでは程遠いかなと思っています。

TokyuRuby会議という場

TokyuRuby会議の一部の回はサントリーさんがスポンサーになっているということで、大量にビールが出てくるということで有名です。また、各人が自慢の料理を持ち込んできて「飯王」を決めるということもあって、料理に夢中な人もたくさん。後半ぐらいになると半分ぐらいの人は発表を聞いていないとのこと。たしかに自分の場合もそうでした。

そんな中、まじめな発表をするのはちょっと怖かったのですが、終わってみれば、多くの人に聞いていただき発表に対するご意見もたくさんいただきました。発表やってよかったと実感しました。

発表という機会

今回、発表するということで、できるだけ進捗を出したいと思い、どんどん開発が進みました。発表資料を作りながらの開発は大変でしたが、締め切りができるとそれがモチベーションになって開発が進むので、大変有意義だったです。また、機会があれば発表したいなと感じた一日でした。

最後に

当日は体調不良で発表直前まで休憩室で横になってました。いろんな人にご心配・ご迷惑をお掛けしました。ごめんなさい。

「Patterns of Enterprise Application Architecture」を読み終わった

「Patterns of Enterprise Application Architecture」を読み終わりました。

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

自分が読んだのは洋書版。途中から日本語版も合わせて。500ページ以上の洋書を読むのに1年2ヶ月かかりましたが、ようやく読み終わりました。ざっと感想を。

• ソフトウェアを書く人にとって「これ読んでないとモグリでしょ」感がある一冊。たしかに読んでいて、「あ、この言葉よく聞くわ」とか「このパターンあるある」って言うことが多かったです。

• （この本の）英語難しい。文の途中でいきなり例が出てきたり、辞書にない単語が沢山出てきたり、なかなか苦労。

• というわけで、読んでいて流石に意味が取れないのはまずいと思って日本語訳版を購入。購入時は電子書籍版が出てなくて、書籍版も出ていない状況だったので古本で。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

• 500ページ以上あるということで心折れそうだったんですが、1日2ページぐらいのペースで徐々に読み進めていくと、意外となんとかなった。

• ベストプラクティスでもないし、サンプルコード（JavaもしくはC#）がそのまま打てば動くようなものでもないです。というわけなので、「明日使えるコーディング例がここに」って感じではないです。

• 1回読んですべてを理解しようとしてはいけない気がします。一回目はさらっと全体を通して読んで、2回目3回目ぐらいでそれぞれのPatternの相互関係を読んでいくスタイルが良いかなと。となると、あと2回は読まないといけないのか。むぅ。

• 古い本なので、サンプルとして出ている内容がJ2EEとかEJBとか。時代背景を知っていると楽しく読めるような気がします。

• とはいえ、著者の先見性が所々に垣間見えたりするし、そんなに技術的な流行に流される内容ばかりではないです。コーディング技術よりも一歩下のレイヤーの部分が書かれています。その分、分かりにくいところはあるんだけれども、繰り返し読んでいけば分かってくる気がする（自分もそうありたい）。

• 紙に出力して単語を調べて文の区切りに斜線入れて読むのが自分には有っている洋書の読書スタイル。これ、iPad Pro + Apple Pencil だとちょっと変わるのかな？

というわけで、きちんと理解しているとは言いがたい「Patterns of Enterprise Application Architecture」。ちょっと間を空けて、また再読したい。

『組織にテストを書く文化を根付かせる戦略と戦術』を聞いて #jopf

はじめに

先日開催された『開発を活性化するためのポイントとテストに関する勉強会』にて、『組織にテストを書く文化を根付かせる戦略と戦術』のお話を聞いてきたので、そこでの内容と自分が所属している組織への適用について記してみます。

各種資料

発表資料

組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada

Togetter

togetter.com

感想

衝撃的だったのは、「テストを書く文化の醸成には2年ぐらいかかる」という言葉。

t_wada「文化の醸成は年単位の事業になる。だいたい2年ぐらいかかる。」 #jopf

— みよひで。オシャレ男子になりたい (@miyohide) 2016, 2月 16

一日二日でできるとは思っていないんですが、まさか年単位とは。

そのため、勢いで乗りきれるほど甘くはなく、戦略と戦術でもってテストを書く文化を醸成しましょうという話に続きます。

スライド10ページ目で引用されている『テストを書く時間がないのではなく、テストを書かないから時間がなくなるのだ』

t_wada「『テストを書く時間がないのではなく、テストを書かないから時間がなくなる。』James Grenning
」 #jopf

— みよひで。オシャレ男子になりたい (@miyohide) 2016, 2月 16

でさらっと、テストを書かない理由No.1に対する厳しい答えを提示し、戦術として「どこから手を付けるか」（スライド21ページ目）や、「テストでこだわりがちなところに対する警鐘」（スライド24ページ目）、「テストでのこだわりポイント」（スライド25ページ目）を例示されて、一つ一つが勉強になりました。

で、どうする

一番手っ取り早いのは、自分のテストスキルを上げることかなと思います。発表の中でも言われていましたが、「レガシードコード改善ガイド」を読んで用語や考え方を身につけ、

レガシーコード改善ガイド (Object Oriented SELECTION)

実際にテストを書いてみるというのを自分はやっています。

Ruby/Railsでは、『Read Everyday Rails - RSpecによるRailsテスト入門 | Leanpub』や『Rails 4 Test Prescriptions』などがよいように思います。

pragprog.com

後は、公開されているOSSには結構テストが書かれていないことが多いので、テストを追加するPull Requestを出すというのもいい勉強になるかなと思っています。

実際に組織に展開するというフェーズについては、それぞれ組織ごと・チームごとに異なるように思えます。私が言われたものでも、

• テストを書く時間がない
• テストを書くためのスキルがない
• テストコードの品質が担保できない
• それは（QA｜開発者）の仕事
• テストコードによって生産性が上がるといった定量的指標がない

などなど。あー言えばこー言う状態なので、真正面でぶつかってはダメで、地道に答えを用意するのが一番早いように思っています。

それか、トップを仲間につけてトップダウン式で強制させるというのもある組織形態では有効な気がします。

冒頭で書いた「文化の醸成は年単位の事業になる」という言葉を旨に、いろいろと試行錯誤するしか無いのかなと思っています。