はてなブックマーク

この記事はiOS2 Advent Calendar 2017の8日目の記事です。 私事で恐縮ですが数ヶ月前に株式会社Globeeという会社のCTOに就任しまして、今はabceed analyticsという教育系アプリを開発しています。前職ではHadoop系を活用したログ収集基盤やログ解析基盤を担当していたので分野的には割と大きく変わりました。 さて、弊社のような小規模なスタートアップでは開発速度が重視されるため、自動テストがどうしても疎かになりがちです。 しかし個人的には小規模なスタートアップであっても、いけると思ったプロダクトならテストコードは書くべきだと考えています。理由はシンプルで、テストコードを書いた方が長期的に見て開発速度が上がるからです。 というわけで今回は弊社開発のアプリに自動テストを導入した時の考え方について話します。「うちはこうしている」などのアドバイス・ツッコミがありま

Elasticsearch実運用時に個人的に気をつけている点をまとめました。 自分でも整理できていない部分がありますので、間違っている点・追加した方が良い点などありましたら教えていただけると非常に助かります。 目次 目次 インデックス・スキーマ設定 スキーマを事前に定義しておく _allの使用は必要な時のみ行う 部分一致検索をしないstringフィールドにはnot_analyzedをつける doc_value:trueをつける できるだけエイリアスを使う 必要に応じてルーティングを行う 本体の設定 ヒープメモリを適切に設定する スワップしないように設定 スプリットブレイン対策を行う field data cacheに上限を与える 検索高速化 Warmerを登録する queryとfilterを使い分ける filterのキャッシュ設定を使い分ける 必要無いフィールドは検索の際に取得しない イン

プログラムを書く時はできるだけ頭を使いたくないので、当然コードもできるだけ共通化して使いまわしたいわけです。 今まで自分はiOS開発ではクラス継承を使って処理の共通化を行っていたのですが、Swift2ではProtocol Extensionsを使って処理の共通化を行うのが良いらしいので、今回はそれについて調べてみました。 TL;DR クラス継承で処理を共通化していた時は仕様変更のたびに親クラスが肥大化したり、子クラスの挙動が親クラスに依存して分かりにくくなったりするのが辛かったが、Protocol Extensionsでは複数のProtocolを使って実装を共通化できるので見通しが良くなりそう 逆にSwift2でProtocol Extensionsよりクラス継承を使うべきケースを知りたい(誰か教えてください) Protocol Extensionsの概要 SwiftのProtocolとは

男もすなるTorch7といふものを、女もしてみむとてするなり。 まずはVagrant上にUbuntuを立てて開発環境を作ります。 Vagrant上ではGPUは使えませんが、あくまで体験版という事で。あと私は男です。 インストール〜開発環境構築まで UbuntuのVagrantを作成してログイン $ vagrant box add ubuntu-14.04 https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box $ vagrant init ubuntu-14.04 $ vagrant up $ vagrant ssh Torchのインストール 続いてTorchのインストールを行います。 不明点あればhttp://torch.ch/docs/ge

大規模バッチ処理が必要になったので、名前だけ聞いた事はあっても詳細を知らなかったApache Sparkについて簡単に調べました。 参考サイト http://spark.apache.org/talks/overview.pdf Apache Sparkってどんなものか見てみる（その１ - 夢とガラクタの集積場 Resilient Distributed Datasetsに関する論文まとめ（１章〜５章 - 夢とガラクタの集積場 spark_rdd.md · GitHub Apache Spark インメモリな分散データ処理プラットフォーム データをメモリに保持するため、ストレージから入力を受けストレージに出力するMapReduceと比較して、機械学習やグラフ描画などの同じデータを繰り返し用いるジョブに対して強い 初回ロード時は重くなるが、それ以降はメモリ上から読み込むためHadoopより速

ElasticSearchをしばらく運用してみて、いくつかノウハウがたまってきたので残しておきます。 Solrを使う事が多かったので最初は慣れなかったんですが、公式のドキュメントがSolrより充実しているしクエリがJsonベースで組みやすいので結構使いやすい気がしてきました。 今回はfield data cacheについてです。余裕ある人は公式サイト見た方が色々詳しいと思います。 https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-fielddata.html field data cacheとは ElasticSearchでは、各fieldのデータをメモリに載せることで検索を高速化しています。これをfield data cacheと呼びます。SortやAggregation(集計)を高

(3/15 : タイトル修正しました。wは小文字ですね、すみません・・・) PlayFrameworkが流行り始めてから割と経ちますので、そろそろ正式採用しようと考える方も多いのではないかと思います。 強力な静的型付けで守られたPlayは、ミッションクリティカルなシステムや数万行を超える大規模システムの構築に特に向いているような気がします。 また、Servletを使っていないのに加えてMVC構造がベースなので、今までRailsなどで開発をしていた人でもシームレスに移行できると思います。 しかし、忘れてはならないのがPlayのアーキテクチャが全ての処理が非同期で行われることを前提としているという事です。 ここを忘れてPlayをただの強力な静的型付けで守られたMVCフレームワークとだけ考えて開発を進めてしまうと、本番環境で稼動させた時にパフォーマンスが上がらずに困ることになるかもしれません。今

PlayFrameWorkはイベント駆動型を基本としているため、全ての処理は非同期で実行される事が前提となっています。 これによって単一スレッドで複数のリクエストを捌く事ができます。 非同期のHTTP呼び出しを実現するPlay WS APIを使って外部のWebサイトにアクセスするコードを例にして、非同期処理でクライアントからのリクエストがどう扱われるか見てみます。 非同期処理でのリクエスト挙動 非同期で外部Webサイトにアクセスするコントローラ public class TestController extends Controller { public static F.Promise<Result> nonBlockingUrlAccess() { final String uniqueId = UUID.randomUUID().toString(); Logger.debug("r

前回 でSparkの擬似分散環境構築とインタラクティブシェル上からのプログラム実行まで行ったので、今回はjarファイルからのプログラム実行を行います。 環境 CentOS6.6 CDH 5 IntelliJ IDEA 14 参考サイト http://qiita.com/imaifactory/items/823caa33639196f5459a http://kubotti.hatenablog.com/entry/2015/10/02/160104 Sparkアプリケーションの開発環境構築 SparkはIntelliJでの開発が推奨らしいので、今回はIntelliJを使います。IntelliJのインストール及びSBTプラグインのインストールは省略します。 SBTプロジェクト作成 File->New->Project SBTを選択 sbt-assemblyのインストール SparkでJAR

ElasticSearchの良く使うcurlコマンドをまとめました。良かったら使ってください。 コマンドの詳細な説明は書いていませんが、キーワードで調べればすぐ分かるかと思います。 データ投入系 スキーマの登録 curl -XPOST http://localhost:9200/testindex -d @mapper.json スキーマの追加 curl -XPUT 'http://localhost:9200/testindex/_mapping/test' -d ' { "properties" : { "huga" : { "type" : "long" }, "hoge" : { "type" : "string" } } }' スキーマの確認 http://localhost:9200/testindex/_mapping?pretty データの登録 curl -XPOST ht

諸事情でElasticSearchの事ばっかり書いてますが、Solrの方が好きです。 ElasticSearchのインデクシングを高速化するためにやった事を残しておきます。 基本的には↓に書いてあることばかりです。 Performance Considerations for Elasticsearch Indexing | Elastic データ投入方法 データの投入にはBulk APIを使います。 なお、公式では1つのbulk Importのサイズは5~15MBにすることを推奨しています。 curl -XPOST http://localhost:9200/_bulk --data-binary @databatch.json >/dev/null メモリ関係 ES_HEAP_SIZEに実メモリの半分程度を割り当て、mlockall:trueでElasticSearchのメモリがスワッ

プロ野球が開幕しました。ヤクルトスワローズが延長戦で勝利するという奇跡を目の当たりにしたので昨日からずっとニヤついています。 今回はSolr4.1からSolr5にデータ移行をした際に自分が少しはまった点を参考として残しておきます。 pint,sintは使えない 古いバージョンとの互換性を保つために残っていたpint,sintがSolr5.0では使えなくなりました。schema.xmlにその型が残っている場合は削除し、代わりにTrieIntFiled（普通のintで問題無い）を使いましょう。double,float,long,dateも同様です。 enablePositionIncrementsは使えない schema.xmlでのフィルター定義の際に、今までなら <filter class="solr.KuromojiPartOfSpeechStopFilterFactory" tags="

こんなしょうもない事で1時間ぐらいはまってました。 CentOS7で開発環境を作っていてphpMyAdminを外部からアクセス可能にしようと思い/etc/httpd/conf.d/phpMyAdmin.confを Order Deny,Allow #Deny from All Allow from All と変更してapacheを再起動したのですが、外部からアクセスすると「403 forbidden」と出てアクセスできませんでした。apacheのerror.logを見ても、client denied by server configuration: /usr/share/phpMyAdminとあるだけでした。 「phpMyAdmin forbidden」みたいなちょっと残念な検索ワードで調べてみたのですが、案の定「AllowOverride All や Order Allow,Denyを記

ユリ熊嵐面白いですよね。 CentOS7にSolr5.0を入れたので、その時の手順を残しておきます。 まず注意点として、Solr5.0ではJavaは1.7u55以上でないと正常に動きません。更にsolr.xmlの形式が変わっており、Solr4.3以前のものでは動かなくなっていることにも注意してください。 また、5.0ではSolrはスタンドアロンなサーバーアプリケーションとして動作します。今まで通りwar形式で出力してJettyやTomcat上で動かすことも一応できるようですが、推奨はされていません。 サービスインストールから起動確認まで Solr5.0ではinstall_solr_service.shがサービスインストールをやってくれるので、非常に簡単です。 yum install java-1.7.0-openjdk* java -version ※u55以上になっていることを確認 wg

ElasticSearchって日本語の情報少なくて辛いです。 今回はmlockall:trueの設定が効かなかった時のチェック項目を残しておきます。 mlockall:trueとは ElasticSearchは公式で「起動時にメモリを確保し、スワップしないようにする」という設定が推奨されています。 ※参照：Configuration まず起動時にメモリを確保するためには、/etc/sysconfig/elasticsearchでES_HEAP_SIZEを設定する必要があります。（公式では実メモリの半分程度、32GBを超えないようにと言ってます） そしてElasticSearchのメモリがスワップしないようにするために、/etc/elasticsearch/elasticsearch.ymlでbootstrap.mlockall: trueを記述する必要があります。 以上の設定をした後でel

沙村広明先生の漫画が好きなんですが、その中でも特に「ハルシオンランチ」が好きです。 ストーリーが良く出来ていて簡単に言うと女の子がゲロを吐いて世界が救われる話なんですが、その他にも読むとゲロを吐くことに対する躊躇いが無くなって、飲み過ぎた次の日でも復帰が早くなるというメリットもあります。 WEBサイトにアクセスした際に、広告が表示されてから本文が表示されるとげんなりします。というわけで広告コードを遅延読み込みさせようと思います。 bodyタグの終了直前に広告のスクリプトタグを配置するのが手軽で楽なのですが、その方法では結局window.onloadの発火が遅れてしまうので、Javascriptを多用するサイトだとあまり意味がありません。なので、今回はFriendly iFrameを使って遅延読み込みさせます。 Friendly iFrameとは、親と同一ドメインのiframeを動的に作成し