プログラマでありたい

おっさんになっても、プログラマでありつづけたい

獺祭の適正価格に関する雑感

 もの凄く炎上しそうなので躊躇してますが、言いたいことが沢山あるのでつらつらと書いてみます。

日本酒と酒蔵を巡る現状


 まず予備知識として、日本酒を取り巻く状況を確認します。日本酒の国内出荷量のピークは1970年ごろで170万klで、現在はその1/3くらいの60万klまで減っている。造り手である酒蔵も減っていて、3,000以上あった酒蔵も今では1,400件程度になっています。この数字だけ見ていると、見事に市場は縮小しています。一方で興味深い数字もあります。特定名称酒とされる吟醸酒、純米酒の出荷量は堅調です。一番高い純米吟醸酒については、逆に増えています。
 ここの数字を見ていると色々と面白い物が見えてくるのですが、年間5,000kl以上の大規模生産者は15社あって、その15社が日本酒出荷の半分を担っています。そしてその生産の大半が、特定名称酒以外(≒安い酒)です。逆に規模が小さい生産者ほど特定名称酒の出荷割合が高いです。
 つまりは、小さい所ほど高級化路線の模索をしているのが垣間見れます。と言うより、生産量が少ないので付加価値高い物を売っていくしか生きていけないのでしょう。

f:id:dkfj:20171212003029p:plain

出典 
清酒製造業の概況(平成28年度調査分)日本酒をめぐる状況 - 農林水産省
清酒製造業者数の推移

獺祭の広告


広告の目的については、獺祭の旭酒造の社長インタビューの記事があるので、そちらをご参照ください。目的としては希望小売価格と取扱店を知らしめるという事のようです。キャッチーなコピーはどうかと思いますが、かなりの反響だったのでマーケティングとして成功なのではないでしょうか。

日本酒「獺祭」の蔵元、旭酒造が「高く買わないでください」と呼びかける新聞広告を掲載。広告に込めた思いを聞いた。

適正価格とは?


togetter.com

 この件で個人的にずっと引っかかってるのが、適正価格って何という話です。私は学生時代は経済学部だったので基本的には需要と供給が価格を決定するというシンプルな考え方が根底にあります。また、社会に出てから様々な商品の販売戦略、マーケティングを横で見てきて、価格を決めるという事の難しさも知っているつもりです。一方で個人的な体験として、買い手がいる価格に収斂していくという事も感じています。
 10年以上前にアメリカのグループ会社で働いていました。その時は結構暇だったので、eBayで買って日本のヤフオクで売るというせどり的な事を興味本位で幾つかの商品でやってました。その結果、商品の知名度(市場規模)で2つの傾向があることが解りました。知名度が高いものは、仕入れの価格帯もほぼ同じで常に商品がある代わりに、一定の手数料分をつけた値段でしか売れない。Fire Kingのマグカップやらポラロイドカメラがこのパターンです。Fire Kingはだいたい2,000円くらいで買ってヤフオクで4,000円くらいで売れるという感じです。倍で売れても送料やら手数料で利益は殆ど出ないです。買ってる方も、雑貨屋さんが仕入れとして買ってるケースが多く、店頭では8,000円くらいで売られていたようです。話を聞いてみると、手間を考えると別に儲かるものではないが、定期的に入荷する事でそれ目当てのお客さんが来るので入れているという感じのようでした。ちなみに知名度が低いものは必要とした人が探して買うと言うものが多く値段とはあまり関係なく売れました。
 話をFire Kingのマグカップに戻すと、元々は数百円だったものがアンティーク化されて一万円近い値段になった訳です。また、それぞれの工程で倍々の値段になっても売れます。結局、買う人がその値段に納得して買っているのであれば、何でも良いのじゃないと考えています。モラルの問題では無いと思います。もちろんお酒の場合は保存状態で品質劣化して造り手としては悩ましい問題なのは解ります。また、ニンテンドースイッチのように転売屋が買い占めるというのも望ましくないでしょう。ただ高くても良いから買いたいという人に、知恵と手間かけて商売している人がいても良いのではと思ってます。

ところ変われば値段も変わる



 少し話変わりますが、レストランでボトルのワインを注文した場合、小売店の店頭価格に対してどれくらいの価格差があるかご存知ですか?どのような店舗形態かによっても大きく変わりますが、一般的には3〜5倍という価格設定が多いです。つまり、レストランで3,000〜5,000円で売っているワインは、酒屋で1,000円のワインです。メニューで5,000円という値段をみるとかなりの高級ワインに感じるかもしれませんが、ごくごく一般的なワインです。で、この値段が高いと感じるか、安いと感じるか。単純にワインだけで考えると高く感じるでしょうが、店側の言い分としては買い付けや保管料、サーブするサービス料、そもそもの店舗の運営費を載せた金額になっています。また、料理とあわせる付加価値という面もあります。
 あるいは、アメリカの寿司屋では、十四代とか一本あたり恐らく2〜3万円の価格設定で出されていました。高いところだと、10万円近いところもあったんじゃないかなと思います。それでも、日本酒好きなアメリカ人はこれが旨いんだよといって喜んで飲んでいました。逆に、現地のスーパーで1,000円くらいで売ってたワインが、日本の小売店だと2,000〜3,000円くらいというのもザラにあります。ところ変われば値段も変わるのです。獺祭を高値で売っているお店も、売れる値段で売っているのです。

売り手は、売ってしまった商品に対しては願望を伝えることしか出来ない。



 そもそも売ってしまった後には、売り手ができることって殆どないのですよね。今回の広告も、それがよく解っているので、お願いという形になっているんでしょう。私も、何冊か本書いていて或いはアプリとか出したことがあって、受けてがどう受け取るかで非常にやるせない思いをすることもありあmす。

 例えば、Amazonのレビューで★1のやつ。

内容はOK、Kindle版のデータ形式はクソ

 それは著者の私でもどうしようも出来ないのだよと強く主張したいのですが、買い手としては総体としてのサービスなので上記のようなサービスになります。これに対して怒ってもどうしようもないです。或いは、想定の読者層と違う人がよんで、難しすぎるとか初歩的すぎるとか。言いたいことも色々でてきますが、甘んじて受け止めるしかないのです。

そもそも日本酒って安すぎない



 どうでもよい愚痴をつらつら書いていましたが、もうひとつ。ワインを普段飲んでいる身としては、日本酒って相対的に安いなと感じています。もちろん輸入しているものと、生産国で買っているという違いがあるものの、同じ価格帯で比べると日本酒の方がクオリティ高いものが多いように感じます。また、上限もせいぜい数万円くらいです。もっと10万、20万するような日本酒が出ても良いのではないでしょうか?そういう意味で、ブランド戦略が非常に上手くいっている獺祭については、もう少し強気な価格設定したほうが良いんじゃないのと思っておりました。
 Twitterで教えてもらったのですが、元サッカー選手の中田さんが海外で高級路線の日本酒を出しているようです。このような取り組み、国内国外問わずにもっとあっても良いのではないかなと思います。

forbesjapan.com

どんな日本酒が好きなの?



 最近はそれほど飲んでいないのですが、私は日本酒も結構好きです。大吟醸のようなスッキリしたものではなく、純米のような雑味が多いものが好きですね。冬はぬる燗くらいでちょっと温めたくらいが良いですね。銘柄は特定のこれというのは無いですが、七本槍とか而今とか好きでしたね。(而今も今は、プレミア酒になっているとか)

f:id:dkfj:20171212122228j:plain

まとめ



 需給だけで考える奴は馬鹿だろという反応に対して、何考えているかを書き出してみた次第でございます。しかし、別に当事者ではないので、これ以上特に思うところはありません。一方で、酒蔵やっていた親類が5年ほど前に廃業していて、もったいないなぁという思いはずっとあります。

コンテナ化とサーバーレス、2つのトレンドに対する雑感

 日本からre:Inventを眺めていた雑感です。速報で2つほど新サービスに対しての感想をまとめていますが、今回は全体的なトレンドに対して今考えている事です。今回は1行じゃないですよ。

サービス展開の方向は、全方位的


 サービスの展開方向としては、去年と変わらないような気がします。他のクラウド(Google, Azure)に対して弱かった部分をきっちりキャッチアップし、伸びている分野(AI・機械学習)のラインナップを増やしていく。そして、サードパーティが提供している機能に対して、一定以上の規模が出てくると(買収 or 自社開発で)サービス化する。いわゆるサードパーティ殺し。
 そんな中で提供されているサービスの作り方/インフラ的な部分を見てみると、コンテナとサーバレス(lambda)を使った物が多いです。AWS自身がコンテナとサーバレスを活用することで、開発を加速しサービスをスケールしやすくしていることが見て取れます。

2015年のWerner VogelsのKeynoteを振り返る


 そんな光景をみていると思い出すのが、2015年のWerner VogelsのKeynoteです。『自由』をテーマにビジネス/エンジニアが何から開放されるのかを語っていました。注目は、その中の一枚のスライドです。

f:id:dkfj:20171203062754p:plain

AWS re:Invent 2015 Keynote | Werner Vogels - YouTube
www.youtube.com

 AWSの中心的な存在である仮想マシン(ec2)に対して、コンテナとfunctions(≒Lambda,サーバレス)を並べています。当時のトレンドとしては、コンテナに対する理解はだいぶ進んでいたものの、functionsに対しては何じゃそれというのが大半でした。そんな情勢なのに、コンテナだけでなくfunctionsについても同列に置くのかと驚いていました。
 次の2枚の写真は、Google Trendsでみる検索数の推移です。検索語については変えていますが、コンテナの方が当時でも優勢です。

f:id:dkfj:20171203063749p:plainf:id:dkfj:20171203064110p:plain

 その後をみていると、特にIoT関連のサービスが顕著なのですが、サービスがLambda連携で作られているモノ/拡張される物が多数出てきています。ユーザーにはfunctionsを使わせるという方向です。で、このコンテナとfunctionsですが、別に対立的な関係になっている訳ではないのです。
 AWSが作ってるLambdaも(Dockerじゃないけど)コンテナをベースに作られています。そして、そのコンテナもEC2などの仮想サーバをベースに提供されています。つまり、個々のトレンドは一足飛びで突然出てきている訳ではなく、連綿と続くサービスの積み重ねの上で提供されているということです。ということで、クラウド・プロバイダという点では、AWS, Google, Azure以外の所の台頭は難しいんでしょうね。例外的には、中国という独自の環境で育ったAlibabaがありますが。

それでは、ユーザーはどうするか?


 じゃぁ今後ユーザーはシステムをどうやって作っていけば良いのでしょうか?何でもサーバーレス・何でもコンテナって考えると、たぶん失敗します。結論的には、月並みな言葉ですが、適材適所で作っていきましょうとなります。
 まずサーバーレスですが、作る上での制約が厳しいです。 API Gateway・Lambdaを始め、AWS側の制約に則って作る必要があります。だってAWSのルールですから。一方で、システム構築/サービス展開する上で、この制約に則って作ることは良いものが出来る可能性は高いです。何故ならば、AWSが今まで作ってきたもののベストプラクティスを元にしているからです。その為、非機能要件のような汎用的に求められるものについては、サーバレスの仕組みにデフォルトで組み込まれています。だからサーバーレスで作れないか検討してみましょう。それが駄目だったら、コンテナか普通の仮想マシンを検討するのが良いです。
 次にコンテナ。これも新規に作るシステムだったら、仮想マシンじゃなくてコンテナから検討した方が良いと思います。一方で、過去のシステムをコンテナ化しようとすると、作った人を恨みたくなるとかいろいろ闇が出てくるので止めた方が良いかもしれないです。逆にこれから作るシステムでコンテナ化できないようなものは、たいていの場合はアーキテクチャなり設計を見直した方がよいです。システムが密結合になり過ぎているということでしょう。
 一方で、システム/サービスの肝となる部分については、サーバーレス・コンテナに縛られずにゼロベースで考えるべきです。プラットフォームの制約のためにサービスの性質を変えるというのは、恐らく間違っている可能性が高いです。

コンテナ化とサーバーレス化が進んだ後の世界


 ついでにコンテナ化とサーバレス化が進んだ後はどうなるのだろうと、ちょっと考えてみましょう。恐らくマルチクラウド化が進むと思います。コンテナ・サーバーレスともシステム/アプリケーションの可搬性を高めます。そうなると、AWSで動かしてたシステムをGoogleやAzureに持っていくことが簡単になります。当然、逆も然りです。
 可搬性が高いのであれば、より有利なクラウドを選ぶようになります。例えば、re:Inventの発表前では、AWSはKubernetesベースのサービスは提供されていませんでした。そこで、コンテナ関係はGoogleのクラウドを利用するという選択肢があり、実際AWSをメインに使っていてコンテナ部分だけGoogleで動かしているという話も結構聞きます。

マルチクラウド化になると複数のクラウドを使えなければいけないのか?


 じゃぁみんなが複数のクラウドを使いこなさないと駄目なのでしょうか。これはNoだと思います。まず、企業としては規模次第です。大規模な会社でシステムも多く多数のエンジニアがいる場合は、適材適所でクラウドを使い分ければよいと思います。一方で少人数のエンジニアチームで複数のクラウドを使いこなすというのは、よっぽどの精鋭チームでしか出来ないと思います。また、個人にフォーカスしてみると全部のクラウドに精通するということは、時間的な制約で恐らく難しいでしょう。複数のクラウドのマスターだよって人は是非手をあげてください。今だと引く手あまたです。
 マルチクラウドの話に戻すと、恐らくデータの集積の基本となるクラウドと、それを元に部分的に複数のクラウドを使っていくという形が増えていくのではないでしょうか。今だとデータをS3に集めて、AI部分のみ別のクラウド使って、またADだけAzure使ってという所は結構あるかもしれません。基本となるクラウドが1つあれば、後は良いとこ取りできるよというのがマルチクラウドだと思います。

まとめ


 毎年、re:Inventで発表されるサービスを見るたびに、この先どこで食っていこうかなと思います。ここ2〜3年は、コンテナ・サーバーレスの知見があれば食っていくことには困らないでしょう。一方で、正味のシステム構築部分自体は小さくなってきます。昔から言われていますが、SIer的なピラミッド構造の産業は難しくなってくるでしょうね。また、発注側の情報システム部門も厳しくなると思います。だって、クラウドに着いて行くのが難しいんだもん。

シリーズ
AWSの新サービス群に対する一行所感
(続)AWSの新サービス群に対する一行所感

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

(続)AWSの新サービス群に対する一行所感

 昨日のAWSの新サービス群に対する一行所感に続き、二回目です。タイトル通り一行じゃないのは、書いてる時の気分の問題です。

AWS Serverless Application Repository


Serverlessアプリケーション版のGithub。SAM形式で作ってたら公開可能。限定公開とか一般公開とか出来る 。とりあえず9割の人が利用者側にまわるサービスかな。

aws.amazon.com

AWS Cloud9


2016年にAWSに買収されたオンラインIDEのCloud9。1年の雌伏の時を経てAWSのサービスとして登場。ペアプロとかも出来る。ちなみにCloud nineというのは、至福という意味

aws.amazon.com

Amazon EC2用スプレッドプレイスメントグループ


 従来のプレイスメントグループに、機能拡張。今までは、ネットワーク的に近くという目的だったが、今度は物理的に別の筐体にという指定。耐障害性があがるが、Multi-AZ構成と性能計算をちゃんとやってればいらないのではという気も。一方で、デフォルトで指定されててもいいかも。

aws.amazon.com

インターリージョンVPCピアリング


 リージョンまたいでのVPCピアリングが可能に。先月発表されたDX Gatewayと併せて、どう使うかよーく考えよう。
※ほぼ執筆完了した本で、企業のネットワーク設計をどうすべきかという話をあーだこーだ書いてて前提が変わったので困ってる

aws.amazon.com

AWS WAFのマネージドルール


WAFの設定をTrend Microのような専門の会社から買うことが出来る仕組み。当然、定義の自動アップデート機能付き。セキュリティ会社的には嬉しいだろうが、AWSへの従属性高まるので手放しでは喜べないだろうなぁ

aws.amazon.com

T2 Unlimited


 バースト特性のあるt2インスタンス。問題は、バースト期間を過ぎると極端に性能が落ち、バーストしている時は例外なく負荷高い時なので、切れると死ぬということ。それをお金で解決するのがT2 Unlimited

aws.amazon.com

API GatewayのVPCサポート


ようやく来たAPI GatewayのVPC対応。今まで何度お客さんに、何でVPC内で使えないのと聞かれたことか。

Amazon API Gateway でプライベート VPC とのエンドポイント統合をサポート

まとめ


 EFSやSQSのFIFOキュー、結局東京リージョンに来なかったね。

シリーズ
AWSの新サービス群に対する一行所感
コンテナ化とサーバーレス、2つのトレンドに対する雑感

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

AWSの新サービス群に対する一行所感

 今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。

AWS AppSync

 モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか?

2017/12/3 追記
中の人曰く、次のような役割分担とのこと

AWSの新サービス群に対する一行所感 - プログラマでありたい

ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それってCognito Syncでやりたかったことじゃないのかな?”

2017/12/03 12:21
b.hatena.ne.jp


aws.amazon.com

Amazon GuardDuty

 初見の印象は、TrendMicroを殺しに来るサービス。一方で、TrendMicroの方もLauch Partnerとして、Amazon GuardDuty and Deep Securityを出してきている。庇を貸して母屋を取らないようにギリギリのところで勝負している印象。

aws.amazon.com

Amazon EC2 Bare Metal

 生のハードウェアを貸しますよという昔のSoftLayerのようなサービス。目的は2つあって、全ての仮想化サーバーをAWSで取り込めるようにするのと、ガチGPU勢とかハードウェアリソースを100%使いたい人に対応だと思う。これ普及したら、なんちゃってプライベートクラウドはなくなるだろうね。

aws.amazon.com

Amazon MQ

 Apache Active MQのPaaS版。既存のMQ入れている所に対して、そのまま移行できますよというサービス。IBMとかを殺しにいっているのかな。SQSを既に使っている人は、そのままSQSで良いでしょう。ところで、FIFOキューは日本に来ないの?

aws.amazon.com

AWS Fargate

 仮想サーバじゃなくてコンテナを直接起動するサービス。もう世の中、コンテナだよね。中の人曰く、イベント・ドリブン的なサービスは、Lambda。ロングランなバッチなどにはFargate。

aws.amazon.com

Amazon Aurora Serverless

 もうちょっと名前の付け方考えた方がよいのではというのが、Aurora Serverless。Lambda等のサーバレスアーキテクチャと親和性が高いAuroraという訳ではない。単純に個々のインスタンスを意識せず良い塩梅にコントロールしてくれるというサービス。PaaSのAuroraが、SaaSのAuroraになったようなイメージ。

aws.amazon.com

Amazon Neptune

 フルマネージドなグラフDBサービス。これ、裏でAuroraの技術使っているのではという気もする。いずれにせよ、NoSQLも自前でインストールして使う時代ではなくなったのだろう。

aws.amazon.com

Amazon DynamoDBにGlobal TablesとOn-Demand Backup追加

 Global Tablesは、AzureのCosmoDB、Google Spannerを意識した機能かな。バックアップ/リストアは、ようやく来たのかという感じ

aws.amazon.com

Amazon Elastic Container Service for Kubernetes

 予想通りECSのKubernetes対応が発表。去年のがっかり感が、ようやく解消。略称がEKSというところに、Amazonのプライドと苦悩が垣間見れる。

aws.amazon.com

S3 Select と Glacier Select

 Simple Storage Serviceという名前に関わらず、恐ろしく多機能になっているS3。Select文でオブジェクトの一部のデータが抽出が可能に。Athenaとかの開発の副産物でしょうな。

aws.amazon.com

Amazon Rekognition Video

 映像の認識処理のサービス。ぜったいDMMのAPIとつないでみる奴でてくるで

aws.amazon.com

Amazon SageMaker

 機械学習のライフサイクルをサポートするサービス。これもサードパーティー殺しだな

aws.amazon.com

Amazon Transcribe

 音声⇒テキスト変換。初回Launchは、英語・スペイン語のみ。きっとすぐに、日本語に対応してくれるでしょう。

aws.amazon.com

Amazon Kinesis Video Streams

 大量のセンサーデータをKinesisが扱うように、ビデオ画像もKinesisで扱えるようになった。先述のRekognition Videoのようなものと組み合わせて、防犯カメラからの映像をリアルタイムで異常検知というようなことができるようになるんでしょうね。

aws.amazon.com

Amazon Translate

 リアルタイム翻訳サービス。APIが提供されるだろうからプロダクトに組み込みやすいだろうが、精度の点でGoogleに勝てるのだろうか?

aws.amazon.com

IoTサービス群

 怒涛のIoT関係サービスのリリース。これで、ほぼほぼ出揃った?

 AWS IoT Device Defender IoT版のDeepSecurityみたいな感じ?

aws.amazon.com

 AWS IoT Device Management IoTの個々の機器の管理。やっぱり必要だよね

aws.amazon.com

 AWS IoT Analytics IoTの分析サービス。AWSは分析サービスをいろいろ出してるけど、どれもイマイチ感は拭えない。。。

aws.amazon.com

 Amazon FreeRTOS IoT用のOSまで作っちゃいました。

aws.amazon.com

AWS Systems Manager

 EC2 System Managerを更にラップしたようなサービス。複数のEC2やRDS,S3をグルーピングしてくれる。もうちょっと拡張してIAMの権限管理とかもできれば、本番・開発環境のために複数アカウントとかする必要なくなるのだけどなぁ

aws.amazon.com

Amazon Time Sync Service

 とどのつまりが、NTPサービス。やっと出してくれたのかという反面、なんで今までなかったのか。

aws.amazon.com

Amazon Comprehend

 自然言語処理。Mecab以来目立って進化していないような気がするので、何気に嬉しいし使い所が沢山ありそう。自然言語処理ってなんぞやと言う人は、文章中から特定のキーワードを引っこ抜くとか単語単位に分解するサービス程度に認識してればO.K.

aws.amazon.com

まとめ

 まとめきれません。

続き
(続)AWSの新サービス群に対する一行所感
コンテナ化とサーバーレス、2つのトレンドに対する雑感



Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

公文が出しているNEW スタディ将棋のUIが素晴らしい

 息子が幼稚園の年長になってきて、いろいろな事に興味を持つようになってきました。そして知人に公文が出している将棋盤が良いよと聞いたので、試しに買って将棋を教えてみました。これが中々素晴らしいので紹介します。

NEW スタディ将棋 (リニューアル)

NEW スタディ将棋 (リニューアル)

NEW スタディ将棋



 NEW スタディ将棋は、名前の通り将棋の動かし方を学べるようになっています。その最大の特徴は駒を見れば解るように、駒の動けるところが、一つ一つの駒に書いてある点です。幼稚園児でも1〜2回教えると、ほぼ駒の動きが解るようになっています。実際、並べて見たところと、成った所は次のような感じです。
f:id:dkfj:20170620011657j:plain
f:id:dkfj:20170620011749j:plain

優れたデザイン



 NEW スタディ将棋を使ってみて、優れたデザインというのはこういうものだなと実感しました。従来の子供向きの将棋盤だと、駒の動かし方をマンガ形式の説明書で解説するといったものだと思います。それを駒自身に書くという大胆な手法で、説明書を不要にしている点が素晴らしいです。システムを作る身としては、このデザイン・UIの考え方は大切にしていきたいです。
 ちなみに駒や盤自体の素材は、それほど良いものではありません。盤は合板ですし、駒も何となくささくれている感じです。しかし、小さい子が使うと考えれば充分でしょう。合板なので軽くて良いです。

感想というか悩みどころ



 ということで、息子がすっかり将棋好きになりました。一度始めると何局もやれと言ってきて、中々時間の確保が大変です。あと、私が勝つと怒るので、どうやって息子に勝たせられるように強くするか悩みどころです。どうしたら良いのでしょうね?

NEW スタディ将棋 (リニューアル)

NEW スタディ将棋 (リニューアル)

触って覚えるサーバレス入門!!『サーバーレス シングルページ アプリケーション』

 監訳者の@yoshidashingoさんにサーバーレス シングルページ アプリケーションを頂きました。ありがとうございます。

f:id:dkfj:20170620015140j:plain

 

本書の内容



 本書の内容としては、名前の通りサーバーレスでシングルページアプリケーションを構築する方法がテーマとなっています。ただどちらかと言うと、シングルページ アプリケーションはおまけで、サーバーレスのAPIを作ることがメインとなっています。機能説明だけでなく実際に手を動かしながら覚えていくというスタイルで、その為に200ページ弱と薄めの本となっています。サクッと読めて、それでも一通りの事はカバーしているという中々よい構成です。

Cognito,DynamoDB,Lambda+API Gateway



 サーバーレスの中心として、本書ではCognito,DynamoDB,Lambda+API Gatewayの4つを中心に扱っています。基本的な使い方からチップス的なものまで扱っています。それぞれ20〜30ページくらいで説明しているので、分量的に多くなく適量なのではないでしょうか。
 例えばDynamoDBの章では、DynamoDBの歴史から強い整合性と結果整合性、インデックスの話など基本的な機能の説明から、DynamoDBへのアクセス許可に際してのIAMのポリシーの設定など具体的なことまで記述されています。この中でConditionの項目で置換変数を使ってCognito IDを使って自分のデータのみしか参照/更新できないような制限など、一般的に頭を悩ます部分についてもサラッと答えを書いているのが好感です。

サーバーレスのセキュリティ&スケールアップ



 この本で特に良いなぁと思った所が、7章の『サーバーレスのセキュリティ』と8章の『スケールアップする』です。サーバーレスの構築事例や運用実績は、まだまだ世の中に出てきているものが少ないです。そうなると構築する際に困るのが、どのようなセキュリティ施策・運用の想定をすればよいか解らないということです。そういった意味で、独立した章としてそれぞれを扱っているのは素晴らしいです。
 セキュリティについては、サーバーレスの施策というよりAWSの基本的な設定であったりJavaScript側の施策であったりと、まだまだ書き足すところは多いかもしれません。それでも、クエリインジェクション・クロスサイトリクエストフォージェリ・DDoSと代表的な攻撃に対する対処方法が書かれています。
 スケールアップの所でフフフとなったのが、S3のアクセス集計。S3のログを元にシェル芸を駆使していました。『S3Webトラフィックを解析する』というタイトル見て、Google Analytics使えという内容かと思ったのですがAWSオンリーで行くという心意気を感じました。ちなみにこんな感じです。

$ aws --profile admin s3 sync s3:learnjs-logging.benrady.com/ logs
$ cat logs/* | cut -d ' ' -f 13 | sort | uniq -c

 どうせならawkコマンドをだして紛らわしくしたら良いのではと思いながら読んでいたのですが、後ろの方でしっかり出てきました。

$ cat logs/* | awk '{ print $3 }' | gr ':' ' ' | \
  awk '{ print $2 ":" $3}" | sort | uniq -c

 シェル芸好きとしては、満足です。ただ現実的な運用では、Google Analyticsをお勧めします。
それ以外にも、バージョニングを利用したキャッシュコントロールなどがあり一読をお勧めします。

感想



 非常に読みやすくて、サーバーレスとは何ぞやと知りたい人にはお勧めの一冊です。が、個人的には非常に悔しい一冊です。実は、この本の原書の発売が2016年6月14日です。私も『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』という本を出しており、テーマも発売時期もほぼ同じでした。ただ主題をシングルページ アプリケーションではなくモバイルアプリにしました。書名もサーバーレスかクラウドネイティブか悩んだ末に、クラウドネイティブにしました。後はあれもこれもと欲張り、KinesisやMachine Learning, AWS IoT, Mobile Hubなど詰め込みすぎました。結果700ページ超の分厚さになり、知る人ぞ知るというマニア向けの本となってしまいました。この本を読んで、改めて対象を絞り込むことが大切だなぁと実感しました。良い本です。

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス


以下、目次です。

目次


本書への推薦の言葉
監訳者まえがき
はじめに
目次

1章 シンプルにはじめる
1.1 サーバーレスWebアプリケーション
1.2 ワークスペースを使う
1.3 Amazon S3にデプロイする
1.4 はじめてのデプロイ

2章 ハッシュイベントによるビューのルーティング
2.1 テストしやすいルータを設計する
2.2 ルータ関数
2.3 ルートを追加する
2.4 ビューパラメータを追加する
2.5 アプリケーションをロードする
2.6 再びデプロイする

3章 シングルページアプリケーションに必要なもの
3.1 ビューを作成する
3.2 データモデルを定義する
3.3 ユーザー入力を処理する
3.4 アプリケーションシェルを作成する
3.5 カスタムイベントを使う
3.6 再びデプロイする

4章 Amazon CognitoによるIdentity as a Service
4.1 外部のアイデンティティプロバイダに接続する
4.2 アイデンティティプールを作成する
4.3 Googleアイデンティティを取得する
4.4 AWS認証情報をリクエストする
4.5 プロファイルビューを作成する
4.6 再びデプロイする

5章 DynamoDBにデータを格納する
5.1 DynamoDBと連携する
5.2 テーブルを作成する
5.3 DynamoDBへのアクセス許可
5.4 ドキュメントを保存する
5.5 ドキュメントを取得する
5.6 データアクセスと検証
5.7 再びデプロイする

6章 Lambdaを使って(マイクロ)サービスを作る
6.1 AWS Lambdaを理解する
6.2 まずデプロイする
6.3 Lambda関数を書く
6.4 Lambda関数を呼び出す
6.5 Amazon API Gatewayを使う
6.6 再びデプロイする

7章 サーバーレスのセキュリティ
7.1 AWSアカウントをセキュアにする
7.2 クエリインジェクション攻撃
7.3 クロスサイトスクリプティング攻撃
7.4 クロスサイトリクエストフォージェリ
7.5 盗聴とトランスポート層のセキュリティ
7.6 サービス拒否(DoS)攻撃
7.7 再びデプロイする

8章 スケールアップする
8.1 Webサービスを監視する
8.2 S3Webトラフィックを解析する
8.3 成長に合わせて最適化する
8.4 クラウドのコスト
8.5 再びデプロイする(何度も、何度も)

付録A Node.jsのインストール
A.1 Node.jsランタイムをインストールする
A.2 複数のNode.jsバージョンを管理する

付録B ドメイン名を割り当てる

参考文献

不確実性コーンの話

 アジャイル界隈では割と知られているのですが、見積もりが何故ずれるかという説明の1つに不確実性コーンというものがあります。ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには4倍くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて誤差は収束に向かうという話です。

f:id:dkfj:20170518115300p:plain

引用:プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか:ITpro


 この不確実性コーンですが、個人的には次のように解釈しています。

  • プロジェクト開始時には、全ての情報が揃うことはないので見積もりには誤差が生じる
  • 全ての情報を集めてからプロジェクトを始めるのは現実的ではない。
  • ブレを小さくするには、出来るだけ対象となる範囲を小さくする。(タスクを細かい単位に分解する)

 個々の仕事の処理能力が高いのに、何故か仕事が遅い人というのがたまにいます。そんな人を見てると、自分が持っているタスク全部の見積もりを最初にやってから、個々の仕事に取り掛かろうとする傾向が多いように思えます。不確実性が多い段階の見積もりはブレが大きいとともに、見積もり自体も大変で労力が必要です。
 それを回避するにはどうしたら良いのか?目の前の優先度の高い1つのタスクだけに向き合えばよいのです。優先度が高いということは、基本的には不確実が少ないです。悩む余地がないので、実質的な仕事をしている時間が増えるのでサクサクと進みます。結局仕事の早い遅いって、実質的な作業にどれだけ時間をさいているかというところなのではないでしょうか?

See Also:
仕事を分解する。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?