モバイルアプリサービス部＠モバイルバックエンドグループの五十嵐です。 これから何回かに分けてherの使い方を書いていこうと思います。 remiprev/her: Her is an ORM (Object Relational Mapper) that maps REST resources to Ruby objects. It is designed to build applications that are powered by a RESTful API instead of a database. 概要 herはActiveRecordのように振る舞うRESTfulAPIのORMです。 今回は、herを使ってOAuth2.0のClientCredentialsGrantのアクセストークンを利用するAPIにアクセスしてみます。 環境 Ruby: 2.2.4p230 Rails:

はじめに 自分が使っているAWS環境のセキュリティに問題がないかと心配になることはないでしょうか？私はよくあります。そこでCIS Amazon Web Service Foundations Benchmark というAWSのセキュリティのガイドラインに沿って使っているAWSアカウントのセキュリティの状況をチェックしてみました。チェック項目は全部で52あります。内容を一通り確認したところ知らなかったAWSのセキュリティの機能やノウハウを知ることができ、見ただけでもとても勉強になりました。簡単にチェックする方法も併せて紹介しますのでぜひ使っているAWS環境でチェックしてみてください。 1 IAM 1.1 rootアカウントを利用しない rootアカウントは強力な権限を持つため、rootアカウントを利用せずIAMユーザーを利用してください。通常運用でrootアカウントが利用されていないか確認し

大阪でサーバーレスの話をしてきました クラスメソッドの開発を知る！大阪勉強会 第7回 これから始めるサーバーレス！〜最新サービス使いこなし術〜で スピーカーとして登壇しました。参加率が非常に高く、多くの方にご参加いただきました。誠にありがとうございました！ 本記事では、勉強会でお話しした「目的別、サーバーレスアーキテクチャの教科書！これのときはこう！」の発表資料を公開します。 発表資料 内容 本セッションでは、これからサーバーレスを始める人向けに、サーバーレスとは何か？という話から、具体的にどのようなアーキテクチャを構築するのか？というお話しをさせていただきました。 サーバーレスアーキテクチャパターン 本セッションでは、サーバーレスアーキテクチャのパターンを20種類ご紹介しました。サーバーレスと言えるアーキテクチャは20種類では語りきれないほど沢山ありますが、今回は独断と偏見で選んでみまし

緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた

これらについて、例をあげながら解説すると、以下のようになります。 名義尺度 都道府県コード 各都道府県には便宜的に数値が割り振られているが、その数値に対する演算はできない 1 + 2 = 3 (北海道 + 青森 = 岩手)、や (1 + 3) / 2 = 2 ((北海道 + 岩手) / 青森 = 青森)とはならない 順序尺度 商品の星による5段階評価 星3より星4の方がいい評価であるが、星を1段階上げる(下げる)のに明確な基準はない 星3と星4の差 と 星2と星3　で差をつけるときに、どちらも同じ星1分の差があるとは限らない 間隔尺度 気温(セルシウス温度など) 差を求めることはできるが倍は半分といった計算は成り立たない 10℃と11℃の差と11℃と12℃の差はどちらも1℃で同じだが10℃と20℃では2倍気温が高いわけではない 比例尺度 絶対温度 差の他に比率の計算もできる(0を原点として

画像作るのって面倒ですよね。最近はRetinaディスプレイの対応で解像度別に画像を作らなければならない機会もあると思います。個人的にはできるだけ画像は使いたくない。少し前に登場したWebアイコンフォントっていうテクニックがありますが、これを自作するのはかなり面倒です。そんなわけで少し前から話題になっていたWebアイコンフォントを詰め合わせたCSS「Font Awesome」を使ってみることにしました。 Webアイコンフォントを自作した時の記事も過去に書いているのでよければこちらもどうぞ。 【前編：フォント作成】アイコンをWebフォント化してリクエスト数の削減とRetina Displayに一発対応 【後編：Webフォント化】アイコンをWebフォント化してリクエスト数の削減とRetina Displayに一発対応 注意 今回は継承したり、Classを書き換えたりできるSCSS版を使ってみたい

はじめに K-means法やk近傍法等のクラスタリングで用いられる距離については、クラスタリングする対象によっては距離として私達が普段馴染んでいるユークリッド距離以外の距離を用いるとうまくいくケースがあります。（Mahout イン・アクション） 私達が普段馴染んでいるユークリッド距離と書きましたが、このユークリッド距離は2つのベクトル \( \boldsymbol{x}, \boldsymbol{y} \) が与えられたとき、次のように定義されます。 [latex] d_{\text{euclid}}(\boldsymbol{x}, \boldsymbol{y}) = \sqrt{\sum^n_{i = 1} (x_i - y_i)^2} [/latex] この距離という概念は数学的には類似度を測る尺度として抽象化され、2つのベクトルを引数としてとり実数を返却する関数 \( d\) は下記

本記事は当初SVNとGitの比較として「ブランチを用いた開発フロー」のメリット・デメリットについて記載していましたが、 「SVNでもブランチを利用できること」「分散型という言葉に対する記載の誤り」についてご指摘をいただきました。 そのため、ブランチを利用した開発フローに対して感じたことを焦点に記事を修正しております。誤った情報を記載していたこと、SVNに対して誤ったイメージをもつ可能性のある記載をしていたことに対し、深くお詫び申し上げます。 Gitをまともに使い始めて約二ヶ月がたちました。 特に、「ブランチをきる」「修正する」「レビューする」「マージする」という、おそらくGitで想定されている開発フローに沿っての開発はクラスメソッドに入社してからが初めてです。 6月に入社する以前は、開発用のソースコード管理には主にSVNを利用し、1つのバージョンの流れに全ての修正をコミットしていくフローで

渡辺です。 2017/04/19開催(日本時間:2017/04/20)の『AWS Summit in San Francisco』で発表された新サービス『AWS CodeStar』についてお知らせします。 一言で言えば、CodeCommit, CodePipeline, CodeBuild, CodeDeployとそれらに付随する実行環境を一撃で構築・管理できます（2017年4月の時点で、東京リージョンでは利用できません）。 実行環境もカバーする最強のスキャホールド AWS CodeStarが何者か、一言で言えば、一時期に流行ったスキャホールドの類です。 Ruby on Railsが登場した時、コマンドひとつでウェブアプリケーションの雛形ができることに衝撃を覚えた人は多いでしょう。 ベース部分をスキャホールド（足組）として作り、肉付けをしていくというスタイルが流行ったかと思います。 AWS

RailsでJSONを返すAPIアプリケーションを３週間ぐらい試行錯誤しながら作成しています。少しですがノウハウも溜まってきたのでここにまとめておこうと思います。 今回のアプリケーションの構成は大体次のようになっています。 RailsはAPIサーバ（一般公開するAPIではなくSPA(シングルページアプリケーション)のサーバとしてJSONを返却する。HTMLは返却しない） クライアントサイドはAngularJSで画面遷移、Viewの描画まで管理する DBはMySql、Session管理はRedis（まだローカル開発なのであまり関係無い） チームはサーバサイド、クライアントサイドで完全に分担して二人で作成しています（自分はサーバサイド担当）。 このブログエントリーでは次のことを書きます。 APIのルーティングの設定(JSONのみ返すようにする方法) Session管理（CSRFトークンの受け渡

非同期処理を行う方法にAsyncTaskを使う方法があります。 AsyncTaskを使うとThreadやRunnableを意識することなく、 メインスレッドとは別のスレッドで処理を行うことができます。 非同期処理中であってもメインスレッドでの処理が可能です。 非同期処理を行う際、Handlerクラスを使って画面更新処理を行うと 少しコードが煩雑になってしまいますが、 AsyncTaskクラスを使うとそのような事がなく、 非同期処理と画面更新処理を行うことができます。 ■AsyncTaskに用意されている主なメソッド onPreExecute() doInBackgroundメソッドの実行前にメインスレッドで実行されます。 非同期処理前に何か処理を行いたい時などに使うことができます。 doInBackground() メインスレッドとは別のスレッドで実行されます。 非同期で処理したい内容を記

コードフォーマッタを共有しよう スペースの位置や空行の行数、インデントのスペース数などは人によって好みが分かれるところです。 ですがチームで開発している以上、それらを統一しなければプロジェクトのコードは一貫性のないバラバラなものになってしまいます。 そのような コーディング規約 はプロジェクト開始の早い段階でよく話し合って決めておくのが吉でしょう。 今回はこのようなコーディング規約をコードフォーマッタに設定し、プロジェクトで共有する方法をご紹介します。 コードフォーマッタの設定方法 Android Studio -> Preferences... -> Editor -> Code Style を選択します。 Scheme の初期値は Default となっています。 これは Android Studio デフォルトのコードフォーマッタです。 まずはこれを元にしてカスタムの Scheme

待望のカンバンが標準搭載された GitHub のカンファレンス「Universe 2016」にて、待望のカンバン機能が追加されることが発表されました！「Project」という機能名で、すべての GitHub リポジトリで利用できるようになっています。 A whole new GitHub Universe: announcing new tools, forums, and features 機能の概要は次の通りです。 Code, Issue, PullRequest をリストできる ワークフローに合わせたカラムを設定し、ソートすることができる カードはドラッグアンドドロップで自由に移動できる Waffle.io と ZenHub がパートナーとなって開発している GitHub のリポジトリベースのタスク管理といえば Waffle.io や ZenHub が有名ですが、これらのサービスの開

負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観

Android 3.0 (Honeycomb) から導入されたActionBarですが、このActionBarの左端にアイコン(下図参照)があります。 これは「HomeButton」と呼ばれているようです。 今回はこのHomeButtonの制御・カスタマイズ方法について書きたいと思います。 HomeButtonのアイコン画像の変更 HomeButtonのアイコン画像の変更はActivity毎で変更することができます。 AndroidManifest.xml内の対象のactivity要素の android:logo プロパティに 使用したいアイコンのリソースをセットします。 また、application要素の android:logo プロパティにセットすると、 activity要素で宣言されていない場合にそのアイコンがHomeButtonのアイコンとして使用されます。 AndroidMan

はじめに アプリケーションに異常はつきものです。 今回は、いわゆる「異常系」をコーディングするときに使える一つの考え方を紹介します。 アプリケーションに起こる「異常」を3種類に大別し、それぞれの特性から対応を考えていきます。 Note これは、ただ単に私が普段使っている考え方で、原典となる書物等は存在しません。ご承知おきください。 本記事は「ポエム特集」カテゴリの記事です。 本記事のコードサンプルにはScalaとJavaを用いていますが、とても短い単純なサンプルしか含まれませんので、これらの言語に慣れていない方でも問題なく読めると思います。 目次 失敗って何だろう 異常について 1. 要求する異常 2. 予期する異常 3. 予期しない異常 まとめ 失敗って何だろう 「失敗」と聞いて、まず何を思い浮かべますか？　料理中に塩と砂糖を間違えたこととか、過去に失言してしまったこととか、人それぞれ色

第2回目の Elasticsearch 入門は「データスキーマ設計のいろは」です。 設計と言うほどでもないのですが、例えば RDB で検索にフォーカスした設計や、他の検索エンジンも経験していると、これまでの制限や習慣で Elasticsearch の特徴を生かせない設計をしてしまう事があるので、このテーマにしてみました。 それではインデックスするためのデータ構造を Elasticsearch でどのように設計するのか解説したいと思います。 設計フローまで変えてしまう画期的なドキュメント指向型検索エンジン Elastic 社のホームページを見てみると Elasticsearch の特徴の１つとして「Document-Oriented」と言う記載があります。直訳すると「ドキュメント指向」です。 簡単に説明すると 現実世界の複雑なデータをJSONドキュメントにしてインデックスするだけで、デフォル

アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか？　上手くいく／上手くいかない取り組みの違いはどこなのか？　そもそもそれは本当にやるべきか？　組織とエンジニアの関係、評価はどのようにすれば良いのか？　といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく