Prepared for API Meetup Tokyo #13 https://api-meetup.doorkeeper.jp/events/41135 昨今、APIアクセス認可のフレームワークとして "OAuth" 仕様を使うケースが一般的になっています。本セッションでは OAuth 適用のトレンドと今後について紹介します。Read less

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん

こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基本となる考え方はわかったものの、実践方法で

AWS Lambdaによるデータ処理理の⾃自動化とコモディティ化 @ビッグデータオールスターズ 2015.08.01Read less

Lead Technical Architect Fast Retailing Co., Ltd. Responsibilities: • Architecture • Infrastructure • Innovation Carrer: • Yahoo! JAPAN(6 Years) • Traveling in NZ(1 Year) • Fast Retailing(4 Years) Keito Fukuda 1. Challenges in Retail 2. Microservice Design 3. Global Operation Agenda 1. Challenges in Retail 2. Microservice Design 3. Global Operation Agenda Business Transformation Multi-Channel Omni

"Why Reactive Matters" 日本語版 2016/01/30 ScalaMatsuri 2016 by @okapies http://scalamatsuri.org/ Togetter まとめ: http://togetter.com/li/931864Read less

特定のS3のフォルダにしかアクセス権を与えたくない場合、 ポリシーを作成してIAMユーザーに付与し、そのユーザーからフォルダを参照しますが、 マネジメントコンソールから入るとトップページを表示する権限がないので以下のメッセージが表示され目的のフォルダにアクセスできません。 そのため今回は、S3のフォルダおよびそこにしかアクセス出来ないポリシーを作成し、そのポリシーを付与したIAMユーザーのクレンデンシャル情報を使ってCyberduckからアクセスする方法を紹介します。 手順 手順は以下になります。 フォルダの作成 ポリシーの作成 IAMユーザの作成 Cyberduckの設定 １．フォルダの作成 S3のコンソールから「バケットを作成」ボタンをクリックし、バケット名とリージョンを選択してバケットを作成します。 この時にバケット名の命名ルールに準じていないとバケットが作成出来ないので注意しましょ

2016/02/18 Developers Summit 2016 【18-E-5】 by @okapies http://event.shoeisha.jp/devsumi/20160218/Read less

アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発宣言ではチームの 4 つの価値と 12 の原則が概説されていますが、これは 20 年近く経った今でも有効でしょうか?詳細を見る スクラム In scrum, a product is built in a series of fixed-length iterations called sprints, giving agile teams a framework for shipping software on a regular cadence. Learn how the scrum methodology impacts traditional project management.

10. ドメイン層のオブジェクト • Plain Old Java Object – Not Plain Old Java Beans (getters/setters) • 業務の「関心事」を表現したオブジェクト – 業務で知りたいこと(誰が、いつ、なにを、なぜ、…) – 業務のルール（制約、しきい値、手順、…） – ルールが破られた時の業務ルール（制限、通知、…） • 業務サービスの実行役 – 「判断」の結果を返す – 「計算」の結果を返す – 「加工」の結果を返す – （基本データ型は返さない） 10 業務上の「判断」「計算」「加工」

分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped

2. 2/17 自己紹介 • やすけん( @yskn67 ) • ネット広告業界の新卒1年目エンジニア – 6月~9月: ダイナミックリターゲティング – 10月~ : CPA(Cost Per Action)最適化手法 • 大学院ではECサイトのユーザ行動分析 2016/1/16 50th Tokyo Web Mining 3. 3/17 アジェンダ • 話すこと – ネット広告の概要についての入門的な内容 • 話さないこと（話せないこと） – 機械学習等の詳細なアルゴリズム – 具体的な数値とか • 目次 – RTB(Real Time Bidding)について – RTBにおいて必要なアナリティクスタスク – ダイナミックリターゲティングについて 2016/1/16 50th Tokyo Web Mining 4. 4/17 ネット広告とは • インターネットに掲載されている広告の総

SmartNews Adsは独立した複数のサブシステムから構成されています。 エンジニアの幸福とビジネスのスピードを両立する、そんなシステムをどういう思想で作ったのかお話させていただきます!!Read less

アジャイルソフトウェア開発の奥義 第2部「アジャイル設計」の自分用まとめ。 アジャイル設計 アジャイルな設計 「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。 悪い設計 第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。 硬さ （設計変更が難しい） 脆さ （設計が壊れやすい） 移植性のなさ （再利用が難しい） 扱いにくさ（正しい設計をするのが困難なソフトウェア、面倒な開発環境） 不必要な複雑さ（"後で必要になるかもしれない"と考えて先行実装したコード） 不必要な繰り返し （コピペ） 不透明さ （目的や意図がわかりにくい） 原則 システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。 ただし無条件で原則に従うと「不必要な複雑さ」を招

EC2は柔軟だ EC2は、オンプレミスで作られた設計と同じように構成出来る柔軟性を持っています。 そのため、元々の設計によっては多少の変更は必要ですが、オンプレミス時代の設計でAWS環境を構築することが出来ます。 このようにオンプレミスの設計を持ち込む事でも、AWSへの移行メリットはあるかと思います。 例えば、サーバの調達が早くなる。スペックを柔軟に変えられるので単純に安くなった。夜は止めることでコストダウンが出来た。など。 これらも非常に大きなメリットで、より良いサービス提供が出来るでしょう。 ただ、、、もったいない！！！！！！！！ せっかくクラウドを利用しているので、使いこなさないともったいないです！ 使いこなすには発想の転換が必要となりますが、使いこなすことでより低コストでより柔軟な自動化などが図れます。 そろそろ次のステップに移りましょう！！ ということで、今後、もろもろ記載してい

1. Copyright © 2015 TIS Inc. All rights reserved. Scala関西Summit2015 Typesafe  Reactive  Platformで作る Reactive  System 2015.8.1 前出　祐吾 2. Copyright © 2015 TIS Inc. All rights reserved. 2 自己紹介 ■ @yugolf ■ 甲賀　　▶　京都　　　▶　東京 ! ■ TIS株式会社 ■ 生産革新本部　生産革新部　生産技術R&D室 ■ 社内向けエンジニアリング基盤の整備　▶▶

みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと

Developer Summit 2015 Autumn での講演資料です

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2