あさ寝坊 @知床 Asanebou @Shiretoko のレビュー

２月のことになりますが、北海道に行った時にお世話になった「あさ寝坊」という宿に行った時のレビューを嫁が書いていたので、Gengoを使って翻訳してみました。
残念ながら、投稿済みのレビューを編集するには色々とステップが必要ということで、ちょっと面倒なので、ここに貼付けてるだけです。

2020年にオリンピックがあったり、日本を観光大国にしようという国の取り組みをちらほらニュースで聞いたりするので、こういった日本語で閉じてしまっている情報がもうちょっと気軽に広まっていくといいんじゃないかな〜と。


original (Japanese)
http://www.tripadvisor.jp/ShowUserReviews-g1114386-d1145454-r197967690-Asanebou-Teshikaga_cho_Kawakami_gun_Hokkaido.html

The inn holds very fun memories from when I was single, and we stayed there as a family with our 4-year-old and 1-year-old children.
The price of the food was very cheap considering the portion and taste, and in a way unbalanced, and my husband who loves food was very satisfied!
Before leaving, they granted our audacious request to play in the snow, even though we didn't have any snow gear, and we parents played with sleds too for the first time in decades! The children were really laughing and it was a very fun time.
Their 6th grade daughter played with us, and when we were going home, I was able to feel the growth in our 4 year-old daughter who held herself from crying when saying goodbye.

f:id:seikoudoku2000:20140630133829j:plain

母の日

２週間前になりますが、母の日の手紙を子供に準備させたのですが、文字を書けるようになったことに感動したのでここに記録。"いつもありがとう" の部分は母の日らしさを演出するためにこっちから書くように指示してしまったけど、好きに書かせれば良かったな〜とちょっと反省 w
f:id:seikoudoku2000:20140529165701j:plain

ちなみに英訳(by Gengo) するとこんな感じになるそうで。こういうとっかかりから英語学習を始めのもありか？

You know, you know what, this is a flower. So please take good care of it. Thank you always




カーネーションは猫に荒らされ、すぐにダメになってしまった。
f:id:seikoudoku2000:20140529170344j:plain

RDBMSとMongoDB

丁度、MongoDBのことが社内で色々と話題になっている時に、タイムリーにこの記事がでてきて、自分的に凄くささったのでメモ。
Open database life: ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

データベース設計ができない/できなかった/する時間が取れない、といった人たちや、Shardingのためのロジックを書くのがめんどくさい、といった人たちを中心に好まれるデータベースです。Facebookでも、子会社の中にMongoDBを使っているところがあります。
　MongoDBを使うか、RDBMSを使うかという議論は、よく「先に楽をして後で苦労するか、先に苦労して後で楽をするか」という表現にたとえられます。「技術的負債」を語る上で良いモデルケースと言えるでしょう。
　稼働までなら、MongoDBの方が、正規化が必須なRDBMSより楽です。その一方で、設計を放棄したツケは、後々になってデータ整合性問題、(重複値の多発による)データ量増加、それによるコスト増といった様々な負債となって現れます。裏の実装はMyISAMと大して変わらないので、データ量がメモリに乗らないくらいの規模になってくると、InnoDBよりも急激なペースで参照・更新性能とも悪化します。典型的な「技術的負債」のパターンと言えるのではないでしょうか。

英訳 (by Gengo)

The debate about whether to use MongoDB or RDBMS is often described as being analogous to the expression, “To play now and work later, or work now and play later”. I believe that the situation we find here is a suitable model for talking about “technical debt”.
If we were only to consider the matter up to the point of operation, then MongoDB is the easier option because it does not require normalization like RDBMS does. On the other hand, the cost of abandoning design will surface later on in the form of various burdens such as the problem of data consistency, and (due to the frequent occurrence of duplicates) rises in data quantity and cost. The underlying implementation is not much different from MyISAM, so if data cannot fit into memory, both the referencing and updating performances will decline at a pace more rapid than InnoDB. It can be said that this is a classic pattern of “technical debt”.


MongoDBの売りとして、"スキーマレス"によるイニシャルコストの低さという所がフォーカスされているようですが、一方でNoSQL系の誕生の背景としては、Webシステムの拡大に伴う、ストレージの"スケールアウト"の必要性という所があったはずで、自分は後者の印象のほうが強かったので、ユースケースが真逆でチグハグだな〜と感じました。

  • スキーマレス
    • テーブル定義しなくてもデータを格納できる。
      • サービスをさくっと始める所にフォーカス
  • スケールアウト
    • スケーラビリティを維持するためACIDからBASEへ (下に参考スライド有り)
      • サービスがでっかくなった時に必要な概念
      • 一貫性を犠牲にしてもスケーラビリティを手に入れたい時

しかも、スケールアウトという、後で楽するための所に強いプロダクトなのに、スキーマレスの設計によるツケで、後で苦労するプロダクトとされているのも聞いてて残念な感じ。


ただ、一方で、例えば、世界的に使われててボクも大好きなfoursquareはMongoDBを使っていたり、アメーバもMongoの採用事例で色々とスライドを見かけるので、MongoDBがフィットするユースケース/使い方というのも確実に存在していて、そういうユースケースがもうちょっと抽象度を挙げてキャッチーな言葉でまとめられるようになると、違う見え方がするのかな〜と思ったり。
Mongo on Hadoop | Foursquare Engineering Blog
AmebaのMongoDB活用事例


あと、これは自分で色々想像してて気になった所で、スキーマレスでさくっと始められるというのは長所として挙げられますが、運用して2,3年経った時にどんな感じになってるのかな〜？と。スキーマ定義のドキュメントが無いとかはまあよくある話だと思いますが、RDBMSであれば、DDL引っ張ってくれば、最低限の情報とその定義に基づくレコードが格納されているという状態は保証されますが、スキーマレスだと、DDL無いし、Modelクラスがコードに定義されていたとしても、そのModelクラス自体が変遷したりしているわけで、運用の仕方によっては、むかーしの予期しないレコードでバグが出るとか、migrationが超大変とかありそうだな〜と勝手に想像しました。この辺は使ってる人に、どうやってるのか話を聞いてみたい。


ACID, BASE, CAP定理に関しては、この資料が凄くまとまってて勉強になりました。


これ絡みで最近読んだ本

データベースの限界性能を引き出す技術　?NoSQLに飛びつく前に知っておきたい原理と最新テクニック

データベースの限界性能を引き出す技術　?NoSQLに飛びつく前に知っておきたい原理と最新テクニック

Software Design (ソフトウェア デザイン) 2014年 03月号 [雑誌]

Software Design (ソフトウェア デザイン) 2014年 03月号 [雑誌]

iPhone5s を買った #docomo #mnp

前に携帯を買ってから丁度２年。
digno(ISW11K)を買った - seikoudoku2000のブログ
auにMNP発行の電話をしたら、「auで端末を選んでいただければ30000ポイント差し上げることもできます」みたいな話をされたけど、それでもやっぱりMNPのほうが割安なのは否めないので、そのまま手続きを進めた。
今回はdocomoに出戻り。iPhone5sの32GB。MNP一括で9800円。

端末選びにあたっては、特にapple信者という訳でもなく、どっちかというとandroidにしたかったけど、端末性能と価格とを比べるとどうみても一番お買い得かなと。android端末は実質0円はあったけど、一括0円はほとんど無かった。rebuild.fmで5sが絶賛されていたのも頭に残ってた。
Rebuild: 20: iPhone 5s (Kenn Ejima, Hakuro Matsuda)
日本はiOSのシェアが世界的に見ると異常に高いという記事やらを見たりするけど、一番安くて性能いいんだから、そりゃそうだよな〜と。
emobileのNexus5も気になったけど、emobile + softbankの電波ってのがどんなもんか分からないので、無難なdocomoをチョイス。try wimaxならぬ、try emobileみたいのがあったらいいな〜と思った。


２年前と比べると、全体的にキャッシュバックは少なくなった印象(３台以上で契約すれば、、みたいのは結構あった)だけど、iPhoneは月々サポートが大きいので結局ほぼトントンな感じ。というか、のりかえ割なるものを考えると、今回のほうがお得かも！？

前回 (au ISW11K)

端末: 0円
キャッシュバック: -45,000円
月々割り: -1050円 * 24ヶ月 = -25,200円
⇒ -70,200円

今回 (docomo iPhone5s)

端末: 9,800円
月々サポート -2,940円 * 24ヶ月 = -70,560円
のりかえ割 -780円 * 24ヶ月 = -18,240円
⇒ -79,000円


マシンの大幅なスペックアップもあり、満足感は相当高いです。すげーさくさく動くし、LTEなためか回線状態もau時代よりいいし、カメラが超いい感じww。色々使っていきたいと思います。


２年前に書いたエントリーを今回の乗り換えの時に読み返してみると、意外に役立った&当時の状況を結構鮮明に思い出せて役立ったので、今回のも書いてみた。
２年後のMNP事情はどうなっているんだろうな〜。今の競争の形は健全ではないと散々言われているて自分もそう思うし、ケータイ買いたいだけなのに訳の分からんコンテンツにとりあえず登録させられて速攻で解約してと、せっかく新しい端末を買っているのに買い物していて気持ちよくないし、、と前回同様、再び残念な気持ちを味わうことになったので、いい方向に変わっているといいな〜。

JAWS DAYS 2014に行ってきた #jawsdays

去年に引き続き、JAWS DAYSに参加。
JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug - seikoudoku2000のブログ

Gengo session

前回はほんとただただ圧倒されてスゲースゲー言ってただけな思い出がありますが、今は仕事でもバリバリと使ってたり、会社で横に座ってる人が発表したり(自分もspeakerに名前があるけど、資料手伝っただけw)と、１年で色々と変わったな〜と少ししみじみ。


発表のほうは自社のサーバ構成の変化を赤裸々に語った内容で、皆に興味持ってもらえるかな〜とちょっとドキドキでしたが、好意的なフィードバックを見付けてほっと一安心。(資料は後日アップされるはず。)
包括的に自分たちのシステムの変化を振り返るというのは中々無いことなので、自分たち的にも良い機会だったな〜と。来年の今頃はどんな感じの構成になってるかな〜。



Immutable Infrastructure

全体としては、やはり今が旬のImutable Infrastructureの話が面白かったです。
Chef=冪等性というイメージですが、あるレシピがまっさらなサーバに対してはキレイに動くけど、既存のサーバに流し直すとエラーになることがちょいちょい（設定ファイル名変えたり、cookbookのバージョン上げたりした時とか）あって、冪等性とは？と思い悩んだり、自分たちがChefを上手く使えていないのかな〜とモヤモヤしていた所が、少しすっきりしました。ビバ、Immutable!!
ただ、blue-green deploymentはお洒落だし挑戦したい所ではあるけど、一日何回/何十回もデプロイしているような所がそれやると、サーバ準備してる間に次の来ちゃうよな〜とか、インスタンス代ほぼ倍払ってんのかな？みたいな所がちょっと気になりました。今度バリバリやってる人と話す機会があったら聞いて見たい所です。
Immutable Infrastructure #jawsdays // Speaker Deck
SpecInfra at JAWS DAYS 2014 // Speaker Deck

others

あと、目から鱗感でいくとこの発表が一番だったかなと。
What makes AWS invincible? from JAWS Days 2014
AWSの設定変更時のテストは無意識のうちにマニュアルでやってたし、CLI使いこなせるようもっと勉強しないとな〜くらいは思ってた自分からすると、完全に一段も二段の上の視点からの問題提起で刺激的でした。プレゼンのストーリーや資料も凄い良くて勉強になりました。
Miles Wardさんのその場での回答によると、AWSの設定変更のテストにはこれが使えるそうです。
AWS-Compatible Private Cloud | Compatibility Features | Eucalyptus
全然知らなかったツールなので今度調べてみねば。



関係者の皆様お疲れ様でした&ありがとうございました！
今から来年が楽しみ！！

"How Google Tests Software"を読んでる

まだ読み途中だけど、本の中の↓の言葉で、何か自分の中でつながった感じがあったのでメモ。

"quality in not important until the software is important"


レガシーコード問題

どの現場にもレガシーコード問題だったり、何でこうやって作っちゃったの？みたいな話は転がっている気がして、トータルのコストを考えれば絶対にキレイに作るべきと考えてたけど、それは自分が担当したことのあるソフトウェアが新たに開発者を必要とするくらい世に必要とされたからで、そもそも品質なんて気にされることも無く、消えていったソフトウェアやサービスもいっぱいあるんだよな〜と。
冷静に考えてみると当たり前だけど、何か目から鱗の感じがあった。

20%ルール

Googleで有名になった20%ルールってのは、エンジニアのモチベーションアップのためのちょっとお洒落な取り組くらいに思ってたけど、実はとても合理的なモノじゃないかなと感じた。
20%ルール無しで(有象無象の色んな会議を経て、、)、ほんとのプロジェクトばかりになってしまうと、テストや運用の工数を含めてかっちりと決めねばならずやることが増えるけど、そもそもそのソフトウェアが重要かどうかってのが判断がつく前に、そこまで突っ込むこと自体がリスクだし、打てる数が少なくなってしまう。
20%ルールでソフトウェアの多産多死の状態を作りつつ、重要になったソフトウェアに対してはクオリティを保証するためのテストの準備やデプロイの自動化等をきっちりと行ってソフトウェアのデリバリーのスピードを早める。この両輪が大事なのかなと思った。


CIとかInfrastructure as Codeとか、内側のループの話は最近旬で、自分もどっちかというとそういう方面の話のほうが好きだけど、テストが無かろうがコードが汚かろうがスケーラビリティが無かろうが、外側のループを懸命にまわしながら、ユーザに必要とされるサービスやソフトウェアを作り上げたこと自体に敬意を払いながら、仕事に取り組んでいくべきと思ったのでした。


"quality in not important until the software is important"

大事な言葉なので２回書いておいた。


How Google Tests Software

How Google Tests Software


テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

macの開発環境整備 その２ (pythonまわり)

前回の続き。
macの開発環境整備 その１ - seikoudoku2000のブログ
今回はpython周りの所を中心に。python始めたてですが。

  • pyenv
    • yyuu/pyenv · GitHub
    • Readme が充実していて読み応えがある。
    • 前はpythonbrewなるものを入れた覚えがあったけど、deprecatedって書いてて、pyenvを使ってくださいと書いていた。 




ln -s "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" /usr/local/bin/subl