Skip to content
国際化

Elasticsearch多言語化その2

Elasticsearch多言語化その2 published on Elasticsearch多言語化その2 への2件のコメント

本投稿は、Elastic stack (Elasticsearch) Advent Calendar 2016 の2日目の記事かつ、以前書いた以下の投稿の続編。

背景等

以前書いた内容と重なる部分もあるが、背景等について説明しておく。

Elasticsearch を、各種開発者向けサービスの横串検索用に使用

GitHub, Slack, Google Drive 等のデータを API 経由で取ってきて、Elasticsearch に入れて、それを横串・一括検索出来るようなツールを作っている。元々は内部向けのツールだったが、ぼちぼち体裁等が整って来たので、現在β版的な感じでひっそり公開中。(今年中にはちゃんと公開したい。)

詳細はこちら → GitHub も、Slack も、まとめて検索 | Commet

検索対象の特性は、メイン言語+英語 or 英語のみ

開発チームまたはプロジェクトが1つの大きな単位で、そのチーム・プロジェクトで使っている GitHub のレポジトリ、Slack のチャンネル、Google Drive のフォルダを指定すると、その配下のデータが Commet 上に取り込まれる。

私の(そして、想定しているターゲット)のユースケースとしては、オフショアを利用していたり、メンバーが多国籍だったりする場合もあるが、使われている言語は、基本的には以下のどちらか。

  • メインとして使われている言語(日本語等)+英語
  • 英語オンリー

環境

  • Elasticsearch 2.3.5
  • elastic4s というライブラリ経由で Scala から使用

Continue reading Elasticsearch多言語化その2

PCの前でアイスを持ってるおっさん

おっさんにとってリモートワークで良かった事

おっさんにとってリモートワークで良かった事 published on おっさんにとってリモートワークで良かった事 へのコメントはまだありません

最近リモートワークが大分普及してきて、メリット・デメリットも色々言われていると思う。他のところで言われてるのと同じような事を書いても仕方ないので、最近気づいた点を1つ書こうと思う。(短文、のはず)

スペック的なもの

  • 40代男性
  • 完全リモートになって、2年位
  • フリーランス
  • 開発がメインの仕事で、パターンは2通り
    • 他社の開発プロジェクトに入って、一開発者として働く
    • プロジェクトを丸々受けて、PL兼開発者として他のフリーの開発者と進める

顔が見えなくて、一呼吸置けるのが良い

見出しだけで内容が分かる人もいるかもしれないけど、少し書いておく。

リモートだと、ビデオチャットで打ち合わせをする時以外は顔を直接合わせる必要がないので、ちょっとムッとくるような事があっても、相手に悟られることもないし、ちょっとお茶でも飲んで落ち着いてから返信することも出来るので、無用な摩擦が減って、個人的には向いている働き方だと思う。

(多分)割と正直な性格なので、何かあるとすぐに顔に出るし、リモートじゃなければ、何か自分の意見と違う事があったらムキになって反論しているかもしれない。

Continue reading おっさんにとってリモートワークで良かった事

stop-arret

Elasticsearch多言語化その1

Elasticsearch多言語化その1 published on Elasticsearch多言語化その1 へのコメントはまだありません

英語でもそこそこの検索結果が出て欲しい

以前、Elasticsearch の analyzer 関連の投稿を書いた。

Elasticsearch の analyzer 関連の設定で知ってることを全て書く

Elasticsearch を何に使っているかなどは、詳しくはそちらを参照してもらうとして、ポイントだけ抜粋しておく。

  • GitHub, Slack, Google Drive, ChatWork, Backlog などからAPI経由でデータを取ってきて、インデックスを作成
  • 言語は、日本語がメインだけど、海外の人とのやりとりや、英語のwebページ(StackOverflowとか)からのコピペもあるので、英語もある程度使われている。

現状は、日本語にのみ対応した設定だけど、英語もそこそこ使われているので、英語の検索結果もそれなりの精度になって欲しい、というのが今回の話。

やったこと: 英語の stemmer を filter として追加

先に結論を書いておくと、使用している analyzer に、”english” と “possessive_english” という2つの stemmer を filter のところに追加した。

設定方法などは、詳しくは以下のページを参照。

Stemmer Token Filter | Elasticsearch Reference [5.0] | Elastic

Continue reading Elasticsearch多言語化その1

国際化

i18n: 言語リソース名の命名規則

i18n: 言語リソース名の命名規則 published on i18n: 言語リソース名の命名規則 へのコメントはまだありません

テキストを多言語化する方法は大まかに2パターン

サイト・webサービスなどのテキストを多言語する方法はいくつかあって、詳細はググってもらうとして、(分類の仕方も色々あるけど)大雑把に以下の2つに分けられると思う。

  • gettext のように、ソースファイルに含まれる翻訳元言語(英語が多い)のテキストを _() や __() といった関数で囲んで、それを抽出して他言語のリソースを作成する
  • Java の ResourceBundle のように、任意の識別子(キー)と多言語対応が必要なテキスト(値)のペアからなるエントリーを含んだリソースファイルを各言語毎に作成し、それを使用する

(言葉で説明すると分かりにくいので、上の説明でピンとこない方は gettext, Java ResourceBundle などで検索してほしい。)

で、今回は後者に関して、キーの命名規則を自分達はこうしてるっていう話を書く。

ネットであまりベストプラクティス的なのが見当たらなかったので、とりあえず今やってる方法を晒して、他の人からの意見とかをもらって改善出来れば良いなあという意図。

Continue reading i18n: 言語リソース名の命名規則

Elasticsearch の analyzer 関連の設定で知ってることを全て書く

Elasticsearch の analyzer 関連の設定で知ってることを全て書く published on Elasticsearch の analyzer 関連の設定で知ってることを全て書く へのコメントはまだありません

詳しい人から見れば大した内容じゃないと思うけど、調べたり試行錯誤した結果をまとめる。(間違いなどがあれば、ご指摘頂けるとありがたいです。)

Elasticsearch を何に使っているか

他サービス → API/webhook → 自サーバーの Elasticsearch

以前触れたと思うけど、開発プロジェクトのデータを全部1箇所にまとめて検索出来るようにしていて、そこで Elasticsearch を使っている。

自分の仕事内容としては、時間の4割位を受託開発にあてている。受託開発では、お客様や発注元の開発ベンダーに合わせて色んなツールを使わざるを得なくて、具体的には ChatWork, Backlog, Google Drive とかを使うことが結構多い。それに対して、自分達の開発チーム内部では自分達用のSlackチームがあるし、それ以外にも別のツールを使ってたりしているので、色んなところに情報が分散しがち。

なので、各ツールのAPI(あるいはwebhook)経由で自分達のサーバーにデータを送って、それを Elasticsearch に流し込んでいる。

検索対象

元データの種類は以下の通り。

  • テキスト
    • GitHub/Bitbucket/Backlog の issue (チケット), PR での議論
    • Slack, ChatWork の会話
    • wiki ページ
  • ファイル
    • Backlog のファイル置き場にあるファイル
    • Google Drive のファイル
    • Slack に貼られたファイル

言語は、日本語がメインだけど、海外の人とのやりとりや、英語のwebページ(StackOverflowとか)からのコピペもあるので、英語もある程度使われている。

Continue reading Elasticsearch の analyzer 関連の設定で知ってることを全て書く

API

色んなWebサービスのAPIを使ってみて

色んなWebサービスのAPIを使ってみて published on 色んなWebサービスのAPIを使ってみて へのコメントはまだありません

背景: 沢山のWebサービスのAPIを使ってる

色んなサービスのデータを集めて、横串検索出来るようにしてる

GitHub (issue, PR のコメント, wiki ページ), Slack, Google Drive etc. のデータをAPI経由で集めてきて、横串検索出来るようなサービスを作ってる。

こちら → Commet

経緯はこんな感じ。

  • こんなサービスあったら便利かも。作ってみよう。
  • とりあえず出来た。うん。そこそこ便利。
  • デザインとかできてないけど、ブログで軽く告知してみよう。→ 特に反応無し。
  • まぁ、誰も使ってくれなくても、最悪自分で使ってるし、ちょこちょこ改善して、適当なタイミングでもう一度宣伝しよう
  • 自分で使いつつ、色々修正(長い時間が経過・・・)
  • いい加減、デザインとか綺麗にして、一般公開しよう。← イマココ

ということで、もう少し体裁を整えてから、ちょっと宣伝とかしてみようと思ってる。

が、今回の本題は、技術的な話。

当然、色んなAPIを使ってる

色んなサービスからデータを集めるので、当然、色んな API を使わなければならない。現在、以下のサービスのAPIを使って、データを取ってきている。

  • GitHub (issue, PR, wiki)
  • Slack
  • Bitbucket (issue, wiki)
  • ChatWork
  • Backlog (issue, PR, file)
  • Google (Drive, Gmail)
  • Facebook (グループ)

(その他、webhook 経由で Redmine にも対応しているけど、詳細は省略。)

これだけ色々使ってみると、それぞれの API の癖や、長所・短所などが見えてくるので、そういう事について書いてみる。

Continue reading 色んなWebサービスのAPIを使ってみて

SQL Server 2000 から 2014 に移行

SQL Server 2000 から 2014 に移行 published on SQL Server 2000 から 2014 に移行 へのコメントはまだありません

経緯

以前、Windows Server 2003 上で SQL Server 2000 が動くシステムの構築に関わっていたのだが、Microsoft のサポート切れのため、Windows Server 2012 + SQL Server 2014 に移行することになった。最近は開発の仕事がメインなので、こうしたサーバー構築系の仕事はしてなかったんだけど、元システムの構築に関わった手前、断るのも悪いし、受けることにした。

移行方法概要

基礎知識

SQL Server 2000 から直接移行のパスが用意されているのは SQL Server 2008 R2 まで。SQL Server 2014 などは、一度 2008 R2 以前のバージョンを挟まなければいけない。

Windows も同様で、Windows Server 2003 から Windows Server 2012 に直接アップグレードすることはできず、一度 Windows Server 2008 を挟むか、新規インストールを行う必要がある。

移行対象

移行すべき情報は以下の通り。

  • データベース(ユーザーが作成したもの)
    • テーブル
    • ストアドプロシージャ
    • etc.
  • アカウント情報

移行方法概略説明

データベースの移行に関しては、以下の2通り。

  • データベースのバックアップ&復元を利用する
  • スクリプトとして出力し、移行先でそれを実行

アカウント情報に関しては、こちらの KB246133 にあるように、移行元でストアドプロシージャによりアカウント情報をテキストとして出力して、それを移行先で実行する。ただし、この方法だけではうまくいかなかった。

Continue reading SQL Server 2000 から 2014 に移行

リモート勤務に使えそうなツール10選(2016年版)

リモート勤務に使えそうなツール10選(2016年版) published on リモート勤務に使えそうなツール10選(2016年版) への2件のコメント

以前、リモート勤務に使えそうなツール10選という記事を書いたところ、そこそこ「いいね」やらブクマやらをもらったが、あれから2年近く経って内容が古くなっているので、2016年版を書くことにした。

選定方針は以下の通り。

  • Dropbox や Skype のような、誰でも知っている・使っているものは除外
  • リモートワークに特化している訳でもないものも含む
  • 一般的にどうこうより、自分のワークスタイル・開発スタイルに向いているもの・必要な物を選ぶ

背景

個人的な話

2014年時点では、リモートワークをメインになりつつあったものの、まだやり始めた段階という状況だったが、2016年5月現在は、完全にリモートワークだけの生活になった。1ヶ月に1〜2回程度は対面で打ち合わせとかもするけど、それ以外は、気分転換でたまにカフェに行くのを除くと、全部自宅からの作業となった。

仕事の内容は、ある会社の開発のお手伝いが半分位、残りの半分を受託開発やら自分の作りたいものの開発とかをやっている。その「残りの半分」の仕事は、他のフリーの開発者とかと一緒にチームを組んで進めているが、他の開発者も全てリモート勤務でやっている。

世間的な話

2014年の記事で予想した通り(?)、その後、リモート勤務を認める会社がIT関連に限らず増えてきて、色んなノウハウが世の中に出てきたと思う。ツールに関しても色々情報が出てきたので、本記事もそうしたものの1つと思ってもらえればと。

では本題。

Continue reading リモート勤務に使えそうなツール10選(2016年版)

remote work

マネジメント側から見たリモートワーク、そして新しい働き方

マネジメント側から見たリモートワーク、そして新しい働き方 published on マネジメント側から見たリモートワーク、そして新しい働き方 へのコメントはまだありません

この記事は、リモートワーク Advent Calendar 2015の6日目の記事です。

12/7が投稿日になっていますが、日本のIT業界では翌日の午前9時までは前日の日付なので良しとしましょう。

今回、過去5日間の記事と、これからの皆さんが書く予定の記事のタイトルを拝見し、それらとは少し違った内容のことを書いたほうが価値があるだろうと思い、タイトルのような内容で書こうと思います。

ここで言う「マネジメント」とは、PM等のいわゆるマネージャーの仕事だけでなく、経営者などのトップマネジメントも含んだ用語として使用しています。

12/11追記:書ききれなかった内容を追記しました。

目次

  • 自己紹介
    • 基本情報
    • リモートワークをやり始めることになった背景
    • どんな仕事をしているか
  • 会社でやっていること
    • リモートワークを世に広めるのがゴール
    • 開発(一括、時間)、自社ソフト・サービス
    • チームメンバーは副業(パートタイム)中心
  • 働く側にとってのリモートワークについても軽くおさらい
  • マネジメント側にとってのリモートワーク
    • 経費削減と多様な人材活用はメリット
    • 自分達自身及び顧客の変化が必要
    • コミュニケーションの課題?→強みに変える
    • マネジメント側のデメリット
    • 向いている人
  • リモートワーク+副業=最強説?
    • 働く側は、お金も経験も得られる(時間があれば)
    • 企業側にも実は色んなメリットがある
  • リモートワークのベストプラクティスを簡単に
    • ツール
    • やってること
  • 書籍等の参考情報

後ろに行くほど細かい話になります。

なんか、目次を考えているうちに、本文が非常に長くなりそうな気がしてきました。というのも、これをテーマにブログ記事を書こうと前から考えていて、今回たまたまAdvent Calendarを人から教えてもらって参加申し込みをしたという経緯なので。もしかしたら、複数回に分けるかもしれません・・・

自己紹介

基本情報

まずは自己紹介から。後がつかえてるのでサラッと行きます。

  • 40前後の男性、既婚、1歳児の父
  • ソフトウェア開発(web系スタートアップ〜SIer)、運用、SE(プリセールスとか)、技術コンサルなど、雑多な経験
  • 一人法人。他のフリーランス開発者などとチームを組んで仕事をしています

リモートワークをやり始めることになった背景

子供が出来たのがきっかけです。

出産の数年前からフリーランスエンジニアでしたが、お客さんのところに行って仕事をすることが多く、それを減らしていきたいなぁと漠然と希望は持っていましたが、仕事はあるだろうか?とかが心配で、あまり実行には移せていませんでした。

ただ、妊娠が分かってからは、出産後に妻に子育てを任せっきりにするのは悪いと思い、徐々に客先での仕事を減らしていき、出産直後は週1日、数カ月後には完全にゼロになりました。

どんな仕事をしているか

以下の3つをしています。

  • ソフトウェアエンジニアとして、他社の開発のお手伝い
  • PM兼プログラマとして、他の開発者とソフト開発
  • チーム・ゼロイチというプロジェクトのCTOとして、サービス・アプリ開発の全般を統括

形式上、上の2つが一人法人が会社として受けている仕事で、3つ目は会社とはあまり関係ないサイドプロジェクトです。サイドプロジェクトをやる意味についても後述します。

他社(仮にA社とします)の開発のお手伝いの仕事は(当然)リモートワークなのですが、今回の本題とは違うので、簡単に触れるだけにしておきます。

  • 社員100人未満
  • 開発拠点は国内2箇所に分散
  • 社員は不定期でリモートワークをしている模様。完全にリモートなのは、(多分)外注の私一人だけ
  • 朝会等、随時ビデオチャットでコミュニケーション

2日目のnaoさんが書いているのと同様、自社の仕事だけだと現状ではキャッシュフローが安定しなくて精神安定上良くないので、こちらの仕事をしています。完全にリモートでやらせてもらって助かっています。

自社の仕事は、次に詳しく書きます。また、3番めのチーム・ゼロイチに関しても後ろのほうで少し触れます。

Continue reading マネジメント側から見たリモートワーク、そして新しい働き方

石巻ハッカソンに参加してきた

石巻ハッカソンに参加してきた published on 石巻ハッカソンに参加してきた への2件のコメント

7/24(金)〜7/26(日)にかけて、石巻で開催されたハッカソンに参加してきました。帰宅してブログ書くまでがハッカソンらしいので、簡単にブログにまとめました。

石巻?ハッカソン?

石巻市とは:宮城県第2の都市。でも、地元の人からは、広域合併で人口が2番目になっただけ、という声も。

ハッカソンとは:プログラマーとかデザイナーとかが集まって、その場で即席でチームを組んで、期間内(1日〜数日が多い)に何かプログラムを作り上げるイベント。詳しくはWikipediaでもみてほしい。

参加した理由

  1. 普段使わない新しい技術とかを試してみるいい機会だと思った
  2. 関東圏以外のエンジニア、特にフリーのエンジニアと交流を持ちたかった

1に関して:仕事だと納期の関係とかもあり、割と慣れた技術を使うことが多いので、こういうイベントの時に使ったことない技術を試してみるというのは、まぁまぁよくやってる。

2に関して:自分自身はフリーのエンジニアで、最近は以下のテーマを掲げて、周りのフリーのエンジニア数名でリモート開発のチームを作って仕事をしてます。

  • リモート開発チームに最適化した開発プロセスの確立
  • それをサポートするツールの開発

なので、リモートで仕事をするというニーズが強いと思われる、東京から離れた地域のエンジニアの方々とつながりを作りたいと思った、というのが2つ目の理由。

とはいえ、石巻出身の高橋さんが、石巻ハッカソンに興味はあるもののぼっち参加は嫌だし一緒に出ない?と誘ってくれたのが直接のきっかけ。

お断り

あまり写真とか撮ってないので(新幹線を除く)、文章ばっかですみません。

Continue reading 石巻ハッカソンに参加してきた