Skip to content

Nunjucks + gulp で静的 HTML をモジュール化する

Nunjucks + gulp で静的 HTML をモジュール化する published on Nunjucks + gulp で静的 HTML をモジュール化する へのコメントはまだありません

やりたいこと

概要

静的 HTML を複数ページ作成するときに、共通部分(ヘッダーとかフッターとか)をコピペしたくない。

「PHP とか使って include とかすればいいじゃん」

ていう意見もあるんだけど、動作確認に web サーバー立てるの面倒だし、単なる HTML で済むなら HTMLで 完結させたい。

細かい背景

gulp-ect を使って、やりたいことは大体実現出来ていたんだけど、以下の2つの理由により、別の方法に切り替えたいと思った。

  • ECTgulp-ect も最終更新日が3年前
  • ファイルのパスを埋め込む(後述)、というののやり方が分からなかったし出来なさそう

やったこと(TL;DR)

さきに結論だけ書いておくと、

  • Nunjucks というテンプレートエンジンの記法で、ファイルを作成
  • gulp-nunjucks-render という gulp のプラグインを使って、HTML を出力
    • gulp-data という微妙な名前のも併用

という方法で実現した。

Continue reading Nunjucks + gulp で静的 HTML をモジュール化する

Scala とか Play の Future と ExecutionContext について

Scala とか Play の Future と ExecutionContext について published on Scala とか Play の Future と ExecutionContext について へのコメントはまだありません

背景

Scala や Play! framework で Future 使うときに、ExecutionContext を渡せと言われる。よく分からない場合は、とりあえず

import scala.concurrent.ExecutionContext.Implicits.global

とやっておけば、とりあえずコンパイルは通るんだけど、よく分からずにやっている人も多いと思う(ノ)。

今回は、そっから先の話。

Continue reading Scala とか Play の Future と ExecutionContext について

Scala の並列コレクションが直列でしか動かないと思ったら・・・

Scala の並列コレクションが直列でしか動かないと思ったら・・・ published on Scala の並列コレクションが直列でしか動かないと思ったら・・・ へのコメントはまだありません

追記

やっぱり、並列コレクションを使うのはやめて、Future 使って、Execution Context とかをちゃんと設定する方法にした。

が、一応、以下の内容はそのまま残しておく。

並列コレクションを使う動機

今、いろんな API からデータを取ってきて、それらを検索可能にするっていう(元々は自分用の)サービスをちょこちょこ作っている。(興味のある方は以下のリンクより使ってみて、是非フィードバックを下さいませ↓)

Track Down Anything on GitHub, Slack or Google Drive | Commet

いろんな API からデータを取ってくるので、直列で実行すると、どっか1箇所の API が不調だったりしてレスポンスが遅いと、それに引きずられてしまうので、並列化しようと思った。

コード

元々のコードは、大雑把にはこんな感じ。

SomeDatabase.findAllApiEndpointsToCall.foreach { apiCall =>
  apiCall.execute
}

これを並列化しようとして、以下のコードにした。

# par をつけた
SomeDatabase.findAllApiEndpointsToCall.par.foreach { apiCall =>
  apiCall.execute
}

ログをみると、

02:08:35.008 [ForkJoinPool-3-worker-5] INFO xxxxx

という感じで、別スレッドで動くようになったようだけど、スレッド名が常に同じ=1つのスレッドしか使われていないらしい。

以下のドキュメントを見ると、設定変更出来るらしいので、やってみた。

Parallel Collections – Configuring Parallel Collections – Scala Documentation

val apiCalls = SomeDatabase.findAllApiEndpointsToCall.par

# TaskSupport なるものを作成して、コレクションのプロパティにセット
val taskSupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(4)) # 4並列
apiCalls.tasksupport = taskSupport

apiCalls.foreach { apiCall =>
  apiCall.execute
}

これで、とりあえず並列で処理されるようになった。

Continue reading Scala の並列コレクションが直列でしか動かないと思ったら・・・

Commet

Slack の App Directory に掲載してもらった

Slack の App Directory に掲載してもらった published on Slack の App Directory に掲載してもらった へのコメントはまだありません

サービスを Slack App Directory で一般公開した

結構前からちょこちょこ開発してたものの、時間がなくて半分自分+知り合い専用になっていたサービスを、一念発起して一般公開することにした。

で、今回、Slack の App Directory に載せてもらったので、その手順とかを簡単に情報共有する。

どんなサービスか

GitHub, Slack, Google Drive 等のサービスから API 経由でデータを取ってきて、一括で検索できるようにするというもの。興味のある方は以下からどうぞ。

Continue reading Slack の App Directory に掲載してもらった

[書評] SPRINT 最速仕事術

[書評] SPRINT 最速仕事術 published on [書評] SPRINT 最速仕事術 へのコメントはまだありません

おおまかにどんな本か

Sprint とはGoogle Venturesで使われているプロトタイピング、課題検証のための方法で、それを説明したのが本書。

日本語のサブタイトルが「最速仕事術」なのは分かりにくい。英語の Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days の方がそのままズバリでわかりやすい。

主な対象読者は、新規事業をやっている人だろうけど、それ以外の人にも参考になる部分がありそう。

内容

月〜金までの1週間で、目標設定、アイディア出し、テストする案の決定、プロトタイプ作成、ユーザーテストまでを行う。

  • 月曜:長期目標の決定、課題のマップ作成
  • 火曜:ソリューションを各自で考える
  • 水曜:ベストな案を決定し、ストーリーボードを作成
  • 木曜:プロトタイプの作成
  • 金曜:ユーザーテスト、インタビュー

事前準備のプロセスもあるので、実際には5日+αがかかるが、それくらいの短期間でアイディアを試して、実際にその方向で進めるか、やめるかを決定する。みたいな感じ。

火曜は、「TUESDAY: 思考を発散させる」という見出しがついていて、ブレインストーミングとかを思い出す人もいるかと思うけど、本書では「はじめに」の一番最初、そして火曜日の章でも、ブレインストーミングを否定している。

月〜金曜日のすべてのプロセスについて、細かい手順について説明されているので、可能であれば最初はするのが良さそう。

思ったこと

Lean Startup とかで、仮説検証のサイクルを短くすることの重要性は一般に認知されてきたと思うけど、それを極限まで効率化した方法で、有用そうだなと思った。

じゃ、まずはそのまま実践しよう、となるかというと、なかなか難しいと思った。個人的な事情で言うと、本書はある程度の人的・資金的リソースがあることが前提となっているので、個人事業主だったり零細企業だとそのまま実践するのが難しいと感じた。ただ、出来るところから取り入れていけばいいし、実際にいくつか取り入れてみたところ、それなりに効果は出ているように感じた。

なお、月〜金曜日の各手順は、いろいろ試行錯誤したうえで出てきたベストプラクティスと思われる。他の本などで書かれている内容をもう少し洗練させた方法だったり、そういうのが結構たくさんある。個人的には、木・金の内容は、比較的既視感があった一方、月〜水の内容は色々と新しい発見があった。

全般的に良い本だと思うし、おすすめできる。

将棋

自然言語処理系機械学習サービスの日本語対応状況

自然言語処理系機械学習サービスの日本語対応状況 published on 自然言語処理系機械学習サービスの日本語対応状況 へのコメントはまだありません

やりたいこと

やりたいことがあまり具体的になってないけど、機械学習を使った自然言語処理をやりたい。大雑把には、日本語のテキストを入力して、それを分類したり、書き手の感情や性格とかを判別したり、そんなの。

最終的には全部自分で実装したいけど、当面は、既存のもので使えそうなのがあればそれを使おうと思う。

調べたもの

以下のものを調べた。

注意事項

ただ、すべてのものを調べた訳ではない。

  • 自然言語処理関連のもののみ
  • 個人的に興味がないものは調べていない
  • 終了予定のサービスなども調べていない

あと、API として最初からすぐに使えるようになっているものと、トレーニングしなければいけないものなどが混じっている。

誤り等があった場合は、ご指摘等頂ければ、訂正等を行う予定。

Continue reading 自然言語処理系機械学習サービスの日本語対応状況

[書評]ビジネスモデル・ナビゲーター

[書評]ビジネスモデル・ナビゲーター published on [書評]ビジネスモデル・ナビゲーター へのコメントはまだありません

久々の書評。

プログラマー向けに簡単に説明すると、ビジネスモデル版デザインパターン。

それだけだとあんまりなので、もう少し詳しく書く。知ってる人にとっては当たり前なんだけど、イノベーションが全く新規のアイディアであるってのはかなりのレアケースで、実際には既存の考え方の組み合わせだったりすることがかなり多い。本書では、成功企業のビジネスモデルを55種類のパターンとして分類している。

イノベーションを科学的に考えるというのは、関わっているチームゼロイチでもやっていることなので、興味深く読んだ。

PART 1 で、これらのパターンを使ってどうやってビジネスモデルを変革していくかの方法について述べていて、PART 2で実際の55パターンを説明している。

55のパターンは、知っているものも多いけど、説明されてあーなるほどってのもあったり、Pay Per Use と Performance-based Contracting のように、同じだと思っていたのに本質的には違っていたり、というのがあったり、新たな発見は結構ある。

最初に「ビジネスモデル版デザインパターン」って書いたけど、プログラムのデザインパターンと同じで、知っているだけだと意味は無くて、実践を通じて理解を深めていく必要があるのかな、という気がしている。

ということで、「あ、このパターンは使えるかも」ってのは、早速自分の仕事にも取り入れている。さて、結果はどうでるか。

自宅警備員

自宅警備員の仕事術

自宅警備員の仕事術 published on 自宅警備員の仕事術 へのコメントはまだありません

自宅警備員歴が結構長くなったけど、こんな感じで仕事してるってノウハウみたいなのを公開してみる。「こんなやり方もオススメ」みたいなフィードバックがあるといいなーってのが書こうと思ったキッカケなので、皆様のオススメの仕事術も教えて下さいませ。

毎日やってる事

日報

大体朝に書いてる。忙しくてもなるべく書くようにしているので、ここ最近は、ほぼ毎日書けていると思う。

内容、ポイントは以下の通り。

Continue reading 自宅警備員の仕事術

Java (Scala) で言語判定

Java (Scala) で言語判定 published on Java (Scala) で言語判定 へのコメントはまだありません

やりたい事

  • Java (Scala) で、ある文字列が何語(日本語、英語、など)なのかを判別する
  • 入力文字列は以下の2通り
    • ユーザーから入力された検索文字列(1単語、数文字〜数単語、数十文字)
    • 検索対象となる文章(数十単語〜数十ページ程度)
  • 対応する言語
    • 当初は日本語と英語
    • 今後は5言語程度

なぜこれをやりたいかは、以下のエントリーを参照。

Elasticsearch多言語化その2 – K blog

Continue reading Java (Scala) で言語判定

Elasticsearch の nested 型のハイライト

Elasticsearch の nested 型のハイライト published on Elasticsearch の nested 型のハイライト へのコメントはまだありません

本投稿は、一つ前の「Elasticsearch多言語化その2」の補足。

ゴール

やりたい事は、以下のようなフィールドに対する検索結果のハイライトをすること。

  • nested 型で、中身は複数の “attachment” 型
  • attachment 型の “content” フィールドには、content.{ja,en,…} というサブフィールドを作成し、各言語毎の analyzer で処理する

マッピング定義は以下の通り。(elastic4s の DSL をそのままコピペしたが、まぁ大体理解してもらえるかと。)

val messageMapping = mapping("message").fields(
  "title_v3" typed StringType fields(
    "en" typed StringType analyzer "english",
    "ja" typed StringType analyzer "ja_kuromoji_neologd",
  ),
  "body_v3" typed StringType fields(
    "en" typed StringType analyzer "english",
    "ja" typed StringType analyzer "ja_kuromoji_neologd",
  ),
  "attached_files_v3" nested (
    "attached_file" typed AttachmentType fields (
      "content" typed StringType fields(
        "en" typed StringType analyzer "english" termVector ("with_positions_offsets") store (true),
        "ja" typed StringType analyzer "ja_kuromoji_neologd" termVector ("with_positions_offsets") store (true),
      )
    )
  ) includeInRoot (true)
)

環境は以下の通り

  • Elasticsearch 2.3.5
  • Elasticsearch Mapper Attachments プラグインを使用
  • elastic4s というライブラリ経由で Scala から使用

TL; DR

先に結論を書いておくと、以下の2つがうまくいった。

  • nested 型のフィールドに include_in_root を指定し、検索時には通常のクエリーを実行
  • 通常の nested 型のフィールドに対し、nested query を実行し、inner hits でハイライト対象フィールドを指定

どちらの場合も、 “term_vector”: “with_positions_offsets” と “store”: “true” は、attached_file.content.{ja,en} につける。

上手く行かなかったのは以下の方法。

  • nested query を実行し、highlight query でも nested query を実行

以下、詳細に説明していく。

Continue reading Elasticsearch の nested 型のハイライト