kimutanskのブックマーク / 2016年2月20日

kimutansk id:kimutansk

2016年2月20日のブックマーク (7件)

#cmdevio2016 (レポート: B-1) Scala: Mobile Backend on AWS | DevelopersIO
Scala: Mobile Backend on AWS cmdevio2016のB-1で、Scalaとモバイルバックエンドのお話をさせていただきました。レポートスライド解説 Scala: Mobile Backend on AWSということで、実際にScalaをモバイルバックエンドAPIを開発して感じたことや、AWSネイティブ重視の弊社においてScalaを採用したモチベーションを解説しています。アジェンダ Scalaのoverview Scalaを使ったモバイルバックエンドAPI なぜAWSネイティブの時代にScalaが必要か How to 説得 your client in "Scala使います!" Scalaを採用した理由や、AWSリソースと密結合でScalaを使ってみたこと、Scalaを採用すると決めたことを上司や顧客にどう伝えるべきかなどをお話させていただきました。なお
kimutansk 2016/02/20
ScalaでLambdaで書くのは相性良さそう／MicroServiceは突き詰めればFunction／「Scalaは関数型もできるOOP言語」は個人的な使い方＆感覚にはしっくりくる感じですね。

scala

aws
リンク
#cmdevio2016 (レポート：La-3) 実務で使うAWS Lambda | DevelopersIO
丹内です。Lambdaについて大部屋で話しました。このセッションがLambdaの実務導入につながれば幸いです。もちろん、弊社へご相談いただければお手伝いします！
kimutansk 2016/02/20
ビジネスロジック以外の基盤的な処理を移行するのがやはり最初としては行いやすいですか。アプリを丸々入れ替えはインパクト大きいですがやはり難しそう

aws

lambda
リンク
Apache Kylinについて #hcj2016
懇親会LTのスライドです。 http://hadoop.apache.jp/hcj2016-program/
kimutansk 2016/02/20
類似ユーザからの類似クエリに対する最適化がプレビルドで解消するものの、カーディナリティの大きさに弱いOLAPエンジン、といった感じですかね。

Kylin
リンク
#cmdevio2016 (レポート: A-3) 「マイクロWebアプリケーション」というテーマでお話しました | DevelopersIO
よく訓練されたアップル信者、都元です。本日、技術イベントDevelopers.IO 2016が開催されており、A-3枠において「マイクロWebアプリケーション」というテーマでお話させて頂きました。お足元の悪い中、多くの方にご来場いただきまして、あらためて御礼申し上げます。概要マイクロサービスとしてバックエンドをHTTPで疎結合に繋ぐアーキテクチャに注目が集まっています。そのようにバックエンドで実装した機能を直接ユーザに届けるコンポーネントである「Webアプリケーション」も、コントロールしやすい小さな単位でマイクロコンポーネントとして実装していく、そんな試みをご紹介します。スライドさらっと解説約1年前のDevelopers.IO 2015では、クラスメソッドのAWSドッグフーディングと題しまして、弊社が自社開発をしている「クラスメソッド・メンバーズポータル」（略してCMP）というシ
kimutansk 2016/02/20
あとはサービスディスカバリ（アイコンやリンクのような付随情報も含む）が可能な機構がそろえば、まさにMicroWebアプリ作るとメインが勝手に認識する方式になる、と

microservices

OAuth
リンク
Amazon Aurora
Amazon Auroraというクラウド上のRDBMSサービスがある。2015年の7月末にGAロウンチしたばかりのサービスだが、世界各国のユーザに非常に好評のようだ。 https://aws.amazon.com/rds/aurora/ Auroraをどう見るか、でクラウドの受け入れ度合いや現状の把握に使えると個人的には感じている。個人としてはAuroraほど画期的なサービスはDBでは今までなかったし、RDBMSの歴史の新しい1歩として認識している。ただあまりのシームレスさ、移行容易性、利用の簡便さに凄さに逆に気づきにくい状況がおきている。結果としてマーケティング的なムーブメントにはなりにくい状況で、個人としてはむしろそれが望ましいとも思っている。静かに深く世の中を変えていく、そんなサービスだ。ちなみにグローバルではOracleやSQL Serverからの移行が後を絶たない。理由の多くは、
kimutansk 2016/02/20
「パフォーマンスが数倍というのも利用者には嬉しいが、正直全く本質的ではない。」と。垂直統合的にクラウドの文脈で再構築した所が本質とは今は思っていますが。さて・・

RDBMS

Aurora
リンク
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
Developers Summit 2016【19-D-3】の登壇資料です。 http://event.shoeisha.jp/devsumi/20160218/session/1047/
kimutansk 2016/02/20
実際の所難しい、勉強会で公開できないレベルの技術的内容は内製するしかないという流れになってるんですかね。実際その方がよさそうです。

システム開発
リンク
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。なのに、
kimutansk 2016/02/20
実行状況確認手段用意、異常時アラート、DryRun、復旧手順／冪等性確保、環境差分考慮、一時ディレクトリの扱い、リソース管理と依存制御、どれも重要ですね。

バッチ処理

設計
リンク
- 2016年2月21日
- 2016年2月20日
- 2016年2月19日