builderscon2018にスピーカーとして参加した #builderscon

"Envoy externals and ideas" というタイトルでbuildersconで発表しました。(資料は最下部にあります。)

発表の中でも少し触れたのですが、"Lyft's Envoy: From Monolith to Service Mesh" という、今回のゲストスピーカーであるMattさんのプレゼンテーションをYouTubeで見てEnvoyのことを知ったのが去年の後半で、知れば知るほど、まあ、もう本当に色んな意味で衝撃を受けました。エンジニアとしてのもの凄いレベルの違いを実感するとともに、でも逆に、こういう世界があるんだな〜っと認知することが出来てグッと視野が広げられた感じと、こういうのをしっかり理解出来るようになりたいな〜というワクワク感とかとか。

そして、buildersconにそのMattさんが来るんだ〜!ということを知った瞬間に、これは積極的に参加しないとな〜という思いが高まり、こんなでかいイベントに出たことはないし、しかも有料イベント、、ってことでだいぶ迷ったけど、やっぱやらずに後悔するのはダメだよな〜の気持ちでCFPを出したら、採択していただき、発表に至りました。

蓋を開けてみると、service mesh界隈は今のトレンドなこともあって、Mattさんの発表以外にも、cookpadさんのEnvoy導入事例、Istioのcontributorの方の発表、Lyftのエンジニアの方の分散トレーシングの話と、濃い〜セッションが何個も採択されていて、自分の内容は相当に入門編なんで大丈夫かな〜、、、とめっちゃ不安でしたが、満員入場禁止には及ばなかったけど一通り席は埋まって(70〜80人くらい?)、twitter上で数件ではありますが、ポジティブな感想を見つけて一安心。どんなフィードバックが来るのか / そもそもフィードバックが集まってるのか、、ってあたりはまだちょこっと不安だけど、もうどうしようもないので、もらったフィードバックを次に繋げるのみ。




service meshの諸々、まだ一般的な認知が低い感あるので、今後、Envoy / service meshってどんなもんなんだろう?って気になった人の目に触れるといいな〜と思ったりしています。


そして、何よりの楽しみだった憧れのMattさんのプレゼンは最前列のスピーカーに一番近い席で拝聴し、 終わった後には挨拶をさせていただき写真を撮ってもらい(プレゼン終わった後に目の前で知り合いの方との話が始まって、タイミングを伺ってずっとそこに座ってたので、こいつは何なんだろう?思われていたと可能性は濃厚w、)、その後のランチの時も厚かましくも近くの席に突撃し、もうちょい話ができました。ちょうど部屋を出た所でスピーカー用のお弁当ってのが用意されていて、それのお陰で今ちょっと質問していい?って突撃しやすかったので、それがスピーカーになった1番の特典だったかもしれない。ホント夢のような時間でした。


最後になりますが、このイベントを企画/運営してくださった方々に本当に感謝感謝です。ありがとうございました!
豪華なゲストスピーカー(Mattさん以外にもすんごいゲストスピーカーがいっぱいで、どうやって集めるんですか!?っていうのを主催の方に聞こうと思っていたけど、すっかり忘れていた)、スピーカーズディーナーというイベント(他のスピーカーの人たちってこんな知り合い同士なん!?ってやや圧倒されましたが、それなりに色んな人と話せた気がする)に、当日の運営/懇親会と、至れり尽せりで本当に楽しかったです。


以下、資料等のリンクです。

CFP兼セッションの情報ページ
builderscon.io

発表資料
speakerdeck.com

資料内で言及しているリンク一覧
qiita.com

EnvoyConのCFPを出した

↓のイベントの存在を知り、いても立ってもいられず、アメリカ行ったこともないけどCFPを出してみた。
Announcing EnvoyCon! CFP due August 24 – Envoy Proxy
自分の思いを込めて結構頑張って書いたけど、採択されないとそのままお蔵入りになってしまうんか〜という所で、何か勿体ない気がしたので、記録がてらここに貼り付けておく。

Please provide a title for your proposal:

C++ newbie's try to enjoy Envoy source code

Please provide a detailed, focused description on what this session will cover

I want to share my try to understand Envoy source code as a pure newbie in C++, starting from "Hello World!"
After I was really impressed by the presentation "Lyft's Envoy: From Monolith to Service Mesh", I started learning C++ and reading Envoy source code.
Envoy includes so many functionalities to operate microservices and I think learning about it deeply is really a good thing in the long run.
Not only that, for most people, I feel that recent "infrustructure" and "SRE" thing is about building blocks using Iaas services and other managed services. I'm one of them and I think it's a right approach in most cases. But at the same time, I feel missing something.
And going dive into Envoy remindied me of excitement of learning new programinng language and understanding the system in source code level instead of using some black boxed service.
I'll talk about my motivation and my path for learning C++ in detail.

Benefits to the Ecosystem:

Service mesh and Envoy is already a tremendous trend and this trend would continue for a while. And as GKE supported Istio, it would become something more and more people can use easily if you understand the basic concept.
But as I write in the presentation description, I feel that just building blocks in architechting and creating systems miss something. Excitement and pleasure of actually building something? I don't know the proper word. But I feel so anyway.
If Envoy community aggressively provide something to support learning about Envoy internals, which even C++ newbie can understand and enjoy, I think that'll make some difference from many other open source projects. I hope my presentation triggeres something and I can contribute that kind of thing.

だいぶ盛ってしまった感はあるけれどw、初めてにしてはよく書けたんじゃないかなーという自画自賛
このCFPについては来月の後半に結果が来るらしいので、一旦それ待ち。受かっても落ちても何か次のアクションを考えよう。

Envoyというソフトウェアの存在を知って、レベルの違いに度肝を抜かれたけど、レベルの違いに気づけるようになったんだというプラス思考 & 30代も後半にさしかかってきたけれど、自分もまだまだエンジニアの一線でやれる感覚はあるし、そういう世界のレベルに少しでも近づきたいなーと色々と試行錯誤中。
単純な話だけれども、サッカーのW杯で日本の試合に感動し、またそのスタメンのほとんどが海外リーグの選手だったのをみて、本当に強くそう思った。頑張ろう。

カイゼンジャーニーを読んだ

アジャイルとか開発組織どうするか〜みたいな話はしばらく遠ざかっていたけど、最近、"マネージャー"という役職につき、ちょっとそっちの方に注力する必要が出てきたので、今、流行りのカイゼンジャーニーを読みました。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

さて、カイゼンジャーニーですが、評判通り、とても良かったです。
1人で始めたカイゼンが全社を変えたぜ〜!みたいな現実感のないシンデレラストーリーではなく、実際にはカイゼンしきれないままプロジェクトを移っちゃったりしつつも、その中で色んな人と出会いつつ成長していって段々とやれることを広げていくという、現実の世界に近い (著者の方の体験や実際にあったケースをモデルにしてる?) 気がして、引き込まれるように読めました。

個人的に1番いいな〜と思ったのは、物語の文脈に乗せて、色んな形式のMTG方法とかファシリテーションの方法が紹介されている事。
"マネージャー"という事で、場自体のセッティング / ファシリテーションをする場面が増えてきてますが、そういう経験はあまりなくて引き出しも全くないので、これがめっちゃ大変。。
単純に方法だけ紹介されていても中々腹落ちしないだろうし、また逆にこんな時はどんな方法がいいんだろう?って疑問に思ってもそれをどういう単語でググればいいんだろう、、ってなりますが、この本の中ではMTG/ディスカッションの方法が物語のコンテキストと一緒に紹介されているので、自分のチームの中で今はこういう感じのことをしっかり議論したいな〜という時に、本の中の似たような場面を思い出して、そこで紹介されているディスカッションの方法を参照すればいい。
インセプションデッキ、むきなおり、リーダーズ・インテグレーション、ハンガーフライトの場作り等々。ちょっと油断するとどんどんチームって停滞してしまうんだなーと感じるものの、引き出しが少なすぎてどうしたもんかな〜という状態だったけど、大きなヒントをもらった感じなので、今後、色々試していこう。


ちょっと話は変わって、この本のスコープからは外れるけど、自分が納得できて健全と思える方法でモノをしっかりとまっとうと思える方法で作れるってのはもちろん大事なんだけど、そもそも、そこがゴールなんだっけ?っていう疑問が最近自分の中で強く燻っている。
アメリカのスタートアップとかを見てると、日本では考えづらいようなスピードで組織をスケールして最新の技術を取り入れつつも、プロダクトも進化を続けている所がいっぱいあるのに、色んな組織で発生しているあるあるな問題に同じように苦しんで解決してバンザーイってだけで、そういった所に肩を並べるプロダクト/開発組織って作れるのか!?その辺はクリアした上で、もっと上のレベルの戦いが繰り広げられている世界もあるのではないか? っていう疑問というか、思いというか。

その中で、最近の自分にとって身近な問題として、"マネージャー"って何なんだろう??/どういう存在になるべきなんだろう??ってのがある。"技術分かってるマネージャーに指揮されたい vs マネージャーはマネジメントに集中すべき問題" に、 "エンジニアのキャリアパスがマネージャーしかない問題"、"そもそもマネージャーって何(プロダクト / プロジェクト / チーム...)をマネージする存在なの?問題" 等々。こういったモノをしっかりに向き合って解決していく必要がありそうだと思う一方で、こういうあるあるな問題に事前に上手く対策することもできない組織が、良いエンジニアリングをして、プロダクトを他社より上手に改善し続けられるのか?って思ったり。
ガーンといくアメリカのスタートアップは、こういうあるあるな問題に対して、それなりの解を持っていて、事前に備えているからこそ、ガーンといけるんじゃないかな〜と思ったり。

こういうのを解決するために、組織体制とか開発手法の分野で膨大に学ぶべき/実践すべきことはありそうな予感がしつつ、正直こういう部分に時間を取られることがストレスに感じる部分もあり、有限な時間の中で自分が注力したいのは、エンジニアリングのことをキャッチアップし続けて、しっかりと現場に携わった形でエンジニアとしてのキャリアを積んでいく所で、こういった組織とか開発手法の分野はそこに注力したい人がやるのがベターのでは?と思ったり。。一方でその考え自体が、実は自分の変化を恐れて今までの延長線上で仕事をしたいという甘えでは?みたいな思いも頭をよぎ流こともあり、、、ほんと最近は思考がぐちゃぐちゃw
40という年齢はキャリアの中の1つ大きな節目らしいですが、まだ数年あるものの、そこに向けて色々と考えたくなる年頃なのかな〜。

ここまでの思考のぐちゃぐちゃ感は、久しくなかった感じで、こっから自分がどういう選択をして、どういうキャリアを築いていくにしても、数ヶ月後/数年後に振り返ってみたら面白いかな〜と思って、久々のブログに書いておいた。

子育てエンジニアとジョギング

この記事は 子育てエンジニア Advent Calendar 2016 - Qiita の7日目です。
僕自身は3人の娘(7歳、4歳、3ヶ月)の父で、ジョギング暦は1年程度ですが、もっと早く始めておけば良かったな〜と感じていて、もしかしたら他の子育てエンジニア/将来の子育てエンジニアの人にも参考になるかもしれないと思い、記事を書いてみました。

子育てエンジニアにジョギングがおすすめな理由

短時間でできる

大体、ランニング時間が30分〜60分程度。開始前の着替えと終了後のシャワーを入れても60分〜90分で全行程が終了。奥さん/旦那さんと子供を置いて、仕事帰りや休みの日に定期的にジムやボルダリングに行くのが難しくても、これくらいの時間であれば、確保できるのではないでしょうか?また、朝早くや子供が寝てからちょっと走りに行ったりもできます。
また、先日、日曜日のハーフマラソンの大会に出場したのですが、朝10時頃のスタートで12時頃にはゴールなので、その後はしっかりと家族と過ごせますし、また、河川敷で開かれた大会で、天気も良かったためか、家族連れで来ている人もちらほらと見かけました。

1人になる時間を持つことによるリフレッシュ

仕事から帰って見る子供の顔はとても愛おしいものですが、休日の間ずっと一緒にいると、その気持ちを保つのが難しい時があります。そんな時、ちょっと1人で外で走ることはとてもいいリフレッシュになって、愛おしさを取り戻すことができます。

自分の成長を感じることができる

子供ができると、自分の勉強にあてることのできる時間は減ってしまうし、色々とインターラプトされて集中を削がれることも多くなります。そうすると、自分の成長が阻害されている気持ちになり、ストレスがたまってしまうことがあります。しかし、外で1人で走っている間は、誰にも邪魔されることはないし、また、特に最初の頃は走ることのできる距離やペースが目に見えて伸びやすく、自分の成長を感じることができ、そういった面でのストレスの解消につながります。

食事が楽しくなる

日常的に体を動かすようになると、食事の量が増えて、食べる物にも少し気を使うようになります。そうすると、日々の食事の重要性が増し、スーパーでちょっといい食材を買って料理して食べるだけで、とっても幸せな気持ちになるので、小さな子供がいて、しょっちゅう遠くにお出掛けするのがしんどい子育て期にはとってもいいです。

村上春樹も走っている

「走ることについて〜」は僕がジョギングを始めることになった大きなきっかけでした。ジョギングしたらこんないいことがありますよ!って書いてるわけではなく、彼がどんなことを思いながら日々走っているかが淡々と書かれているエッセイなのですが、不思議とめちゃくちゃやる気になりました。また、65歳を超えても一線の小説家として日々机に向かって創作を続けている彼が、ランニングを日課としていて、それを仕事のクオリティを保つために必要と感じているということは、エンジニアとして一線で仕事を続けていくにあたっても、何か繋がるところがあるに違いない!と勝手に感じていて、ボクの中ではモチベーションの一つとなっています。



読んだ本とか

そんなに色々と読んだわけではないですが、面白かった/役に立った本の紹介。

EAT & RUN

めちゃくちゃすごいウルトラマラソンランナーの人の自伝。書名でぐぐるといっぱいこの本の素晴らしさが書かれた書評が出てくるので、詳細は割愛しますが、とても読み応えがあって面白い本でした。
基本は自伝なのですが、所々に走り方に関するコラムがあって、その中の一つで走る時は足を身体の真下につけるべしみたいなことが書いてあり、僕にはそれがぴったりと合って、それを意識するようになって以来、足の痛みに悩まされることがなくなり、そういう意味でもとても役に立った一冊でした。

EAT&RUN

EAT&RUN

マラソンは毎日走っても完走できない

走る以上は、ただのfun runではなく、何らかの進歩が欲しいという人にはオススメ。さくっと読める新書サイズにぎゅっと色んなエッセンスがまとめられているし、監督としての実績が凄すぎる人なので言葉に重みもあります。インターバル走は辛いけど、、確かに成長する感はあるw。

谷川真里が案内するご当地マラソン

パラパラ読むのに楽しい一冊。日本のマラソン大会事情について全然知らなかったけど、1年を通じて日本全国で様々な大会が行われているので、この時期に〇〇に旅行がてら大会に参加しつつ、XXを観光したら楽しそうだな〜、、、と色々と妄想が進みました。まだ、遠くの大会に参加したことはありませんが、小さな夢を見れる一冊でした。

村上さんのところ

先述の通り、「走ることについて〜」に大きな影響は受けたのですが、そのちょっと前まで村上春樹さんのことは完全に読まず嫌いでした。この企画(村上春樹がメールで送られてきた質問にひたすら日々答えていく)がネット上で行われていた時に、時々はてぶでエントリーが上がってきて、彼の文章をちょくちょくと読む様になり、そうすると自分の中の勝手なイメージと全然違う人で、文章も面白くて、最終的にこの本を買って完読したことが、今にして思うと、僕がジョギングを始めた大元のきっかけとなりました。なので、特に村上春樹を読まず嫌いしている人におすすめです(笑)。

村上さんのところ コンプリート版

村上さんのところ コンプリート版


Let's enjoy being a parent, engineering and jogging :)

CourseraのMachine Learning Foundations: A Case Study Approachを受講 & 修了した

couseraのコース、人生初修了!
https://www.coursera.org/learn/ml-foundations
https://www.coursera.org/account/accomplishments/certificate/4VN5VC73889M
履修して良かったな〜と思えるコースだった割には、このコースを始める前に色々とぐぐった時には日本語の情報は見付けられなかったので、メモなど。

Why I choose this course?

  • 機械学習の盛り上がり。
    • この分野のspecialistにはなれなそうだけど、面白そうだし、ある程度の素養を付けておきたい。
    • deep learning, neutral networkの概念が理解できてない。 最低限の理論が分かってライブラリがあれば使える程度には理解したい。
  • これ系は色んな本に手を出したけど、なかなか最後まで続かない。。
    • 進捗が見えやすくてshareもできるmoocの中で色々と比較検討し、このコースに辿り着いた。
  • Coursera内ではこっちのコースの方がmajorっぽく、日本語の修了ブログも散見されたけど、Syllabusを見るに今の自分のスキルで、これを1人で修了するのは厳しそう。
  • ↑のコースが全11週なのに対し、これは全6週。何とかいけそう!?
  • 実際にはこのコースは↓のSpecializationの最初のコースで、このコースで最初にさらっと色んな分析手法の概要を説明して、各手法の詳細については後続のコースで詳細を学ぶ形。
  • 使用している言語がpythonなので、とっつきやすそう & 業務とかに転用しやすそう。

実際始めてみて、最初のほうであれっと思ったのは、quizの回答をsubmitするだけでも、$79の有料コースに登録する必要あり。(昔は違ったような) ちょっと迷ったのですが、分かりやすいフィードバックがないと、本読んでるのと同じ感じになって心が折れそうな気がしたのと、week1とweek2のquizの手前までで、先生の雰囲気がいい感じで、続けられそうな気がしたので、week2のquizのタイミングから、えいやっと有料コースに登録して履修していました。Stanfordのほうは11週で$49に対し、こっちは6週で$79なので、相当な割高感は否めませんが。。

How was it?

  • どっちの先生も声がクリアで、そんなに早く喋らないので英語は結構聞き取りやすかった。
    • 今の所、日本語の字幕は存在しない。
  • 数学的知識は(良くも悪くも)あまり必要なし。
    • 各手法の概念や触りの数式がlecutureで説明されて、それを実現する部分は細かいロジックはすっ飛ばしてgraphlabの関数を利用。
    • 細かいロジックの話は後続のコースでフォローされる模様。
  • 細かい所は飛ばしつつも、ちゃんと動く物がoutputとしてできるし、自分の知識レベルだと、いきなり一つずつ深入りされてしまうと、容易に居場所を見失ってしまうので、このアプローチは自分にとってはすごく良かった!
  • graphlab すごい
    • ちょっとしたレコメンド機能とかはほんとサクッと作れてしまう時代なんだな〜と。
    • ただし、このコースに出てくるのは単一マシン上で走るロジックばかりで、scaleしなそう。scale outついてはこのコースでは触れられず。
    • 後続コースの紹介で、map-reduceに触れるそうなので、scale outのさせ方についてはそこで説明がありそう。
  • ipython notebook すごい
  • week2 以降の課題は、レクチャーの内容をちょっとだけひねった感じ。別途hintもあるので、それに従ってやっていけばOK。
  • 第6週 (deep learning) だけ、ぐっと難易度が高めに感じた。
    • 他の週以上に、色んな難しいことはすっ飛ばされてはいるんだけど、逆にすっ飛ばされすぎてて何をやってるかよく分からずで、他の手法と同じ時間内にまとめること自体に無理があるように感じた。
    • Capstone までたどり着いて、もう少し理解できるようになりたい。。

次の"Machine Learning: Regression" も修了してブログ書くぞ!きっと。少し間を空けてから。。

postgresqlの "terminating connection due to conflict with recovery" に対応するためのパラメータ

FATAL: terminating connection due to conflict with recovery というエラーについて前書いてたけど、
PostgreSQLのFATAL: terminating connection due to conflict with recovery - seikoudoku2000のブログ
今更ながらに2015のRDS postgresqlのsessionを見てたら、2014の時よりしっかりと説明がされてたので、更新 & 自分の文字での情報を増やしてみた。
AWS re:Invent 2015 | (DAT402) Amazon RDS PostgreSQL: Lessons Learned & New Features - YouTube

この問題は、以下の3つのパラメータで対応可能。

  • vacuum_defer_cleanup_age
    • vacuumで消された行をどれくらいの間残しておくか。ただし、設定が時間単位ではなく、transaction数単位で、設定が難しいのであまり使われていない。
  • max_standby_streaming_delay
    • slaveで実行中のqueryが必要とする行がvacuum対象となっている時、replication streamingの実行を中断し、queryの実行を優先させる際の最大のdelayの許容時間。
      • 大きく設定すれば、queryは流れやすくなるが、delayが大きくなる可能性がある。
    • 全sessionの累積なので、全てのtransactionでその挙動が保証されるわけではない。(ここはちょっと意味が聞き取りきれず、ドキュメントでも記載を見つけれなかった。要確認。)
    • primaryの挙動に影響を与えないという点で、安心感があって人気がある。
  • hot_standby_feedback
    • slaveからprimaryに実行中のqueryの情報を定期的に送信し、primaryはその情報を元に必要とされているrowをvacuumしないようにする。
    • slave上のqueryはほぼ走りきるが、vacuumをブロックするので、disk容量が膨らむ可能性がある。
    • プレゼンしてる人のおすすめ

さらなる詳細は貼付けた動画+公式ドキュメントへ。


2016/05/12 追記。
あれこれと調べていたら、max_standby_streaming_delay が上手く動かない場合に関する、こんな記述を見つけた。`cumulative delay`ってのを上手く訳せないが、connection単位でのdelayではなく、流れているqueryの累計になるから、運が悪いとqueryはcancelされちゃうよってことかな。
https://books.google.co.jp/books?id=RmpGCgAAQBAJ&pg=PA100&lpg=PA100&dq=max_standby_streaming_delay+cumulative&source=bl&ots=RdP2-O09Yf&sig=8t_Ktyk7l-UxXql9j2wuNjOVzKg&hl=ja&sa=X&ved=0ahUKEwjjtI3Kg9TMAhWlqqYKHaZrA7kQ6AEIIDAB#v=onepage&q=max_standby_streaming_delay%20cumulative&f=false
```
These settings cover a cumulative delay.
That is, if there are ten queries pending, they don't get 30 seconds each to delay replication.
So a query might run for 10 milliseconds and got cancelled because it was unlucky to be at the end of the delay, causing the user to wonder what happened.
```

docomoからmineoにMNPした

2年に1回の携帯キャリア見直しタイム。
digno(ISW11K)を買った - seikoudoku2000のブログ
iPhone5s を買った #docomo #mnp - seikoudoku2000のブログ


前回の時に、こう書いていてけど、今はMNPキャッシュバックの規制やMVNOの台頭など、ほんと変わったもんだなと。

2年後のMNP事情はどうなっているんだろうな〜。今の競争の形は健全ではないと散々言われているて自分もそう思うし、ケータイ買いたいだけなのに訳の分からんコンテンツにとりあえず登録させられて速攻で解約してと、せっかく新しい端末を買っているのに買い物していて気持ちよくないし、、と前回同様、再び残念な気持ちを味わうことになったので、いい方向に変わっているといいな〜。


今回は諸々検討の結果、mineoにMNPした。回線切替の待ち時間中なう。今回の手続きは実店舗に足を運ぶことなくオンラインで完結したし、価格設定もシンプルで速攻で解約しないといけない変なオプションはないし、2年毎縛りもなく、1年利用すると、以降は違約金が発生しなくなるなどなど、前回と比べると、大分すっきりした気分の契約体験だな〜と思います。
なお、ここ経由でmineoの契約をすると1000円分のamazonポイントが貰えます (ボクもw)
mineo.jp


以下、今回の結論に至った流れ。

3大キャリア vs MVNO -> MVNO

  • あまり詳しくない親族がスマフォの機種変更の際、薦められるがままに、タブレット契約 + オプション漬けな契約していて、全然使ってないのに合計すると結構な額のお金を支払っていて、何かもう、ほんと嫌になった。
    • (勿論、 違法じゃないんだろうけど、明らかに使わないものを、よく分かってない人に売りつけるってのが残念すぎる。しかも本家のdocomoショップで。)
  • 前回買ったiphone 5sがまだまだ使えそう。
    • キャリアの2年契約は2年ごとに端末を買えて月々割を貰う前提で成り立ってる気がするので、端末を変えなくていいなら、よりmvnoがお得。
    • docomoiphoneの端末の保険が無くなるのがちょっと痛いけど、何かあった際はMVNOで提供されている2万円台のAndroidでも十分かなと。もしくはその前にiphone SEがもう一段階の値下げに期待。

MVNOの概要の把握、キャリアの絞り込み -> DMM か mineo

容量と高速/低速切替のポイントを満たしている事、その他、諸々のメディアからボクの中の刷り込まれたイメージでDMMかmineoに絞り込み。

DMMとmineoの比較 -> mineo

  • DMMの利点
  • mineoの利点
    • androidlover.netを見ている感じ、回線速度はDMMより安定していそう。
    • 回線の高速/低速 の切替で、DMMは低速時に3日間で366MBでさらに速度制限が入るのに対して、mineoは低速時の利用には制限がない。
    • パケットギフトや、パケットタンクなど、これまでに無いサービスを展開していて、とても力を入れている感じがある。
    • 価格.com 経由だと、3,000円のamazon point。
  • その他のポイント、考えたこと
    • DMMだと利用料金の10%が一ヶ月期間限定ポイントになるけど、それを無理に使おうと時間をとられたり、無駄な買い物をしたりしてしまいそうだし、使わないと、それはそれで損した気分になりそう。
    • mineoはパケットギフトの制度を利用して、パケットがヤフオクやらメルカリでやり取りされている。ボクが見た時点では300円/GBくらいの相場。万が一、足りなくなったらそれを購入することもできるが、勿論DMMのように確実にゲットできるわけではない。また、あまり使わなかった月は、逆に売る事もできそう。(規約上OKなことなのかは要確認。)

どっちも一長一短で決め手がなく、最後の最後まで迷って、エイってmineoに決めてしまった感じ。

そして、ここ経由でmineoの契約をすると1000円分のamazonポイントが貰えます(2回目)!ただし、前述の通り、価格.com経由だと、3,000ポイントだったので、そのキャンペーンが続いていたら、どう考えてもそっちがお得w
mineo.jp