athome-developer’s blog

不動産情報サービスのアットホームの開発者が発信するブログ

Tango搭載端末も届きました

こんにちは、情報システム部の高野です。
前回のHoloLensに続きTango搭載端末Lenovo Phab 2 Proが届きました。
dblog.athome.co.jp


今回は、管理部署から箱が開けられた状態で納品されたので開封の儀は無しです(笑)


まず大きいです。片手での操作は私の手の大きさでは無理でした。
f:id:taktak1974:20170213181939j:plain



まだ開発は着手できていないので何ができるかはあまり分かってませんが

床に花を咲かせたり
f:id:taktak1974:20170213181230p:plain


天井に太陽を浮かべたり
f:id:taktak1974:20170213181300p:plain

メジャーで測ったり
f:id:taktak1974:20170213181335p:plain

このようなことができました。
長さが測れるのはすごいですね。

テーブル越しに花を見るとこんな感じでした。
f:id:taktak1974:20170213181421p:plain
本当は全てテーブルの影に入ってないとおかしいのですが
一部見えちゃってますね。

スクリーンショットだとHoloLensと変わらないように見えますけど
実際はこうなります。*1
f:id:taktak1974:20170213181536j:plain

HoloLensよりはお手軽ですが、没入感は少ないって感じですね。


一緒に開発してみたい方は下記からエントリーをどうぞ
athome-inc.jp

*1:HoloLensのスクリーンショットは、また今度アップする予定です

Atlassian製品導入してます!

はじめまして、情報システム部の服部と申します。

当ブログとAtlassian製品のAdministratorをしております。

突然ですが、我が社では開発業務全般にAtlassian製品を導入しておりまして、Atlassian製品導入のご支援を頂いているリックソフト株式会社様のホームページに事例紹介として取り上げて頂きました。

www.ricksoft.jp

ってな事を社内SNSで話題にしたら、技術評論社さんのサイトトップのおすすめ記事にも載ってるよ!という情報をもらったので、早速エビデンスを採取してしまいました(笑)

f:id:athome-administrator:20170214133250p:plain

どんな風に使っているか、詳しくは記事をご覧頂ければと思います。

あまり若手のネタが続かないので、発作的に投稿してしまった・・・

Atlassian製品に関する情報もご提供できればと思いますので、当ブログを今後共よろしくお願いします。

アットホームオンラインシステム その3

情報システム部の豊田です。

前回、私が投稿させていただいた「アットホームオンラインシステム その2」の続きです。

  • 「アットホームオンラインシステム」とは、アットホームが加盟する不動産店に対して過去に提供していた、物件情報を業者間に公開するためのシステムです。

「ウェブ版のオンラインシステムって作れるか?」と肩を叩かれ、「とりあえずやってみます」と回答しましたが、何から始めればいいのかさっぱりわかりません。ただ、どういったシステムになるのかはイメージを持っていないと作れないことはわかっていたので、どういった機能が必要で、その為の画面はこんな感じだろうなというのをひたすら頭の中で考えていました。

一週間も経過したころ、考えたものが頭の中に納まり切らなくなりました。合わせて上司への進捗報告ができないことに気づいたのですが、頭の中にあるイメージを報告書的な体裁で書こうとしても何もかけず、「はて、どうしたものか・・・」と途方に暮れました。頭の中に納まりきらない構想が消えて行ってしまう前にアウトプットしないと「一週間、ウンウン唸ってた人」もしくは「ぼうっとしてた人」になってしまいます。

そんな時間が過ぎていき、最後には色々と面倒になってきました。「面倒な事=やりたくないこと」ですからね。そこで「自分が今したいこと」は何なのかを考えたところ、「自分が考えたものを見てみたい、作ってみたい」ということに気づきました。なので設計書だ報告書だというのは横にどけて、とにかく目に見える形にする為にモックアップを作ることにしました。これなら成果もわかり易いし、報告もし易い、改善点などもアドバイスをもらいやすい。ウェブサイト開発でのモックアップ作成は今となってはよくある話ではありますが、当時、社内ではそういったこともわからない状態でしたので最初にみんなに見せた時は「もう出来たのか」「動くのか」「検索結果がおかしいぞ」とか話が飛躍して少し困りました。ちなみに「モックアップ」という言葉はクルマのスタイリング設計や携帯電話ショップに展示してあるサンプルに対して使うものの印象が強く、当時は「紙芝居」と呼んでいました。

そこから先は、デザインの調整やモックでわかる範囲のUIの調整などを行いながら、システムの全体像やデータフロー図を描いたりして関係者と情報の共有を図って進めていきました。最初は自分で実装するつもりでしたので少しだけperlでプロトタイプっぽいものを作ったりしたのですが、それなりの規模の開発でしたので詳細設計から先は協力ベンダーさんにお願いすることになりました。少し残念だったのと、とてもほっとしたことを思い出します。

さて、開発が進み、実際に動くものが出来上がりつつある頃に一つの洗礼を受けました。今までは情報システム部内での調整でしたので、「ウェブアプリケーションとはこういうもの」というある程度の共通認識がありましたが、部外へ情報が出だした途端にWindows版のオンラインと比較されて「使いにくい」「なんで前と同じように作らなかったのか」「こんなの売れない」といった声が上がり、途方に暮れました。

インターネットが普及し始めたとはいえ、まだまだプライベートでインターネットに接続できる環境を持つ人はまれな時代です。ウェブのサービスに慣れていない人も多いことから、こうなってしまうのは仕方がないのですが、説明のしようもなく、説得することもできず、無視するわけにもいかずといった状況に陥りました。

印象に残っている指摘としては

Windowsのネイティブアプリケーションとは画面と操作感がまったく異なること。

・前の画面に遷移するのに「戻る」ボタンを使うこと。

・多重ログインを抑止する為「ログアウト」ボタンを設置したこと。

・ブラウザをフルスクリーンで使いたい人が多く、環境によって余白の大きさが変わること。(帳票印刷をブラウザの印刷で行っていた弊害)

アプリケーションはとても原始的なフレームワークというかテンプレートエンジンのようなものを使ってC言語で作りました。当時のJavaScriptはブラウザの種類による互換性の問題から利用はあまり推奨されていないこともあって、UIのあまり細かい制御は行わなかったという背景もありました。このようなネガティブな評価ばかりの状況からどうやって抜け出したのかというと、対応できる部分は対応してウェブそのものの原理的な部分は時間が解決してくれたという当たり前のステップで進んでいきました。この時に世の中に商品が生み出されるのは大変な事だと気づき、巷に溢れる様々な製品に対してとてもやさしくなりました。合わせて多少度胸が付いたような気がします。

オンラインシステムがウェブブラウザ版になってもっとも変化した部分は、従来はFAXで受信してから閲覧していたファクトシート(不動産会社の店頭に掲示してあるもの、間取り図や価格・賃料などを掲載した図面)が、パソコンの画面で閲覧できるようになったことでした。ユーザの方々にはFAXを待たなくてもすぐに閲覧できると評判は上々でした。画像フォーマットはPDFを採用。舞台裏では従来の紙のファクトシートを電子化する業務フローに手を入れたり、電子ファイルの保存領域を大幅に拡張したりとバタバタしました。その中でも印象に残っているのは、ユーザにはPDFを閲覧する為のAdobe社のAcrobat Readerのインストールをお願いすることになるのですが、「アクロバットリーダーがインストールできない!うごかない!」と言った声が想像以上に多く、当社のカスタマー窓口や営業スタッフは右往左往することとなりました。その状況が落ち着くまでは「PDFを採用したのは間違いだったのだろうか・・・」と何度も不安に陥りました。

また、PDFで閲覧できるようになったのでFAX送信のニーズは減ると思っていたのですがまったく変わりませんでした。不動産会社では、まとめてFAXのリクエストを出しておき、FAXが届くまでの間に他の業務を進めたり、外出したりして、あとでまとめて閲覧するというケースが多かったからです。これはすぐに閲覧したい状況ばかりではないということを知った時でもありました。(インターネットへはダイアルアップ接続であり、常時接続は夢のまた夢だった背景もあったと思います)

このような状況の中、無事にウェブ版オンラインシステムは順調にユーザを増やしていき、Windows版からのリプレイスも進み無事にインターネットの波に乗ることができました。ちなみにウェブ版オンラインシステムは「アットホームオンラインウェブ」という商品名となり、「アットホームオンラインシステム」という名前はついに途絶えることとなりました。

さて、なんとかインターネットの波に乗れたように思われた当社ですが、インターネットのおかげで様々な情報が瞬時に手に入る環境となったと同時に「自らが情報を発信する」時代の到来でもありました。 従来は当社の営業スタッフが不動産店舗を訪れて不動産情報をお預かりして、ファクトシートを制作し、他の不動産店舗にお届けするという流れが主でしたが、不動産業を営む当社の加盟店さん自らがウェブブラウザから不動産情報を登録し、その情報を当社のネットワークに公開するという「情報発信チャンネル」を新たに設ける事となりました。これは当社にとってもターニングポイントでした。

このシステムはビジネス面では様々な議論を呼び、物議を醸し出しましたが、開発面でもかなり苦労しました。この苦労というのは技術的な障壁ではなく、仕様策定においてリファレンスとなるものがほぼない状況からの設計だったので、かなり自由に設計し、思いの丈をひたすらつぎ込んで考えたものだったので開発者冥利に尽きる時間を過ごせたのですが、商品仕様を社内関係者に説明する段階になって他に類似商品もないために、設計の意図するところがうまく伝わらずに様々なご意見をいただくことになりました。

例えば、「不動産情報を登録した状態ではどこにも公開されておらず、『どこそこへ公開する』という操作を行わないと他の利用者からは検索されない」という構造はかなり違和感があったようで「登録したらすぐに公開されるように」という声をもらいましたが、ここは多くの人に何度も説明・説得して納得してもらいました。これはまだユルい方で、いちばん辛かったのは「新しい概念や機能に付ける名称」でした。「わかりづらい」というのはごもっともなのですが、何しろ一般的な名称も見当たらず、「日本語にするとクドい」「英語にすると聞きなれない」といった状況に陥って半泣きでした。どうやって切り抜けたのかと言えば、良いアイデアがあれば採用し、誰も答えを持っていないものはそのままという至極当たり前の方法で切り抜けました。この時に決めた名称は淘汰されたものもありますが、今でも生き残っていて社内の会話で普通に使われているものもあります。このプロダクトは「アットホームリスティングウェブ」という名前でリリースされ、多くの人にご利用いただきました。ちなみにこの「リスティング」という表現に決まるまでもずいぶんと時間を要しましたね。。。

不動産業者間をつなぐ「オンラインウェブ」、情報ネットワークへ発信する「リスティングウェブ」ができたところで、当社と当社ご利用のネットワーク加盟店をつなぐ「メンバーズウェブ」というサイトも出来上がり、しばらくはこれらの「なんとかウェブ三兄弟」でインターネットの海を渡っていきました。

順調に利用店数も増えていき、それに合わせて多くのお客様の声が集まるようになり、だいたい3か月に一度くらいのペースでアップデートを繰り返していきました。今思うとかなりのんびりしていますが、3サイトを同じチームで面倒を見ていたので一か月ごとに対象プロダクトが変わっていくようなイメージでした。こんな調子で途中何度か大きなトラブルを経験したりしましたが数年が経過した頃、3サイト間を使った機能の要望が多く出るようになり、そもそも3つ分かれていること自体が疑問視されるようになってきました。

では3つのサイトをくっつけたものに作り直せばいいかといえば、それは「手段」です。ご利用いただいているユーザのみなさまを筆頭に当社にとってもより良きツールとなる為の「目的」が必要となります。この目的が曖昧だとわざわざ時間とお金を使って作り直す為の理由がなくなりますので、会社もお金を出してくれません。

この「なんとかウェブ三兄弟」が、そう遠くない未来に陳腐化するのは目に見えていましたが、どのようにもう一段レベルアップして生まれ変わるのかの検討が必要になりました。これらのウェブサイトはシステム開発部門から生まれた経緯もあったので、まずはシステム開発サイドにて議論しましたが、どこかがしっくりきません。システム開発の目線になってしまうか、画面などのうわべだけをリニューアルしたような案になってしまいます。次に一部の営業部門のスタッフを巻き込むことで、使う人側の目線の要素が入ってくるようになりましたが、どこか定期改修っぽい変化でしかないか、技術的障壁をとてもクリアできそうにない実現不可能なアイデアなどで、次世代のオンラインシステムと呼ぶにはインパクトが足りない状況でした。

ここからが実に長かった。まずは「オンラインシステム」を起点とした考えは一向に進まずに放置気味になっているところへ、ある売り上げの下がっている地域に対しての事業としてのテコ入れを考えるプロジェクトチームが立ち上がることとなりました。そこに対して商品そのものから土地柄などの様々な視点から売り上げが下がった理由、お客様から期待されていることは何かといった現状分析を行い、その中の一つの施策として「なんとかウェブ三兄弟」のリニューアルがあるという位置付けとなりました。これによって「なぜその機能が必要なのか」という当たり前のことが明確になりました。ここまで辿り着くのに1年以上の時間を使いましたが、そこからシステム開発プロジェクトとして立ち上がりましたので、さらに開発期間を必要としました。

以上の背景を持って生まれたのが、現在の主力商品である「ATBB」です。

プロジェクトは何度も倒れかけ、相当なお金と時間を使い、生みの苦しみを嫌というほど味わいましたが、この開発のおかげで「自分が考え付くことなんてたかが知れている」「多くの仲間のアイデアと協力や努力があったから出来上がった商品」ということを実感できました。そして、「一人でできないことをみんなでやるから会社なんだ」ということを理解して今に至ります。

こういった経験ができるのも当社の社風なのかもしれません。

以上で3回に渡った「アットホームオンラインシステム」のエントリを終わりにいたします。読んでいただく方に何かを伝えようなんて大胆なことを思っていたわけでもなく、楽しく読ませる文章でもなく、思いつくままにダラダラと書かせてもらいました。最後まで読んでくださってありがとうございました。書いてる本人にはうれしかった事、悲しかった事、悔しかった事、頭に来た事など様々なことを思い出しましたが、自分でもよく覚えてるなとちょっと感心しました(笑)。 記憶を元に書いていますので、事実と異なる場合があるかもしれませんのでご了承ください。

さて、次の改革もそろそろですかね(ん?)

HoloLensが届きました

こんにちは、情報システム部の高野です。

タイトルの通り、弊社にもHoloLens届きました。
ということで開封の儀的なエントリーです。

まず箱
ゲームみたいな箱ですね
f:id:taktak1974:20170126163553j:plain


箱を開けるとこんなオブジェクトが
f:id:taktak1974:20170126163709j:plain


この妙なオブジェクトの中にすべて入ってます。
f:id:taktak1974:20170126163748j:plain


そして本体
f:id:taktak1974:20170126185012j:plain


まだ具体的なアイデアは無いですし
現状のHoloLensでは、弊社サービスとしてなにかをリリースするのは難しいですが
来るべき時に備えて触ってみようかと思ってます。
※ちなみに初日はセットアップだけでクタクタでした。


一緒に開発してみたい方は下記からエントリーをどうぞ
athome-inc.jp

Xamarinを始めてみようかと思います

こんにちは! 情報システム部の高野です。
微妙なタイトルなのは、弊社のモバイルアプリをXamarin化していくぞって決めたわけじゃなく
Xamarinでも行けるか検証し始めたのでこんなタイトルなのです。
ちゃんとXamarinで作ることが決まれば「Xamarin始めました」になりますね。

ということで既存のiOSアプリ、Androidアプリと同様のものをXamarinで作り始めています。
まだまだ慣れていないので悪戦苦闘中です。

iOSアプリをビルドするにもデバッグするにもmacOSが必要ってことで
会社で買ってもらいました。


Mac Book Pro late 2016、13インチのTouch Barなしモデルです。*1
ポートがUSB-Cしかないのは結構きびしいですね。
あと個人的には、キーストロークが浅すぎてつらい。

なにはともあれXamarinがんばろう!

*1:MBPの写真撮って載せようと思ったけど全然いい写真が撮れない

ASP.NET Coreのパフォーマンス検証

こんにちは! 情報システム部の高野です。
前回、予告した通りASP.NET Coreのパフォーマンス検証をしました。
dblog.athome.co.jp

検証環境
  1. IISにAspNetCoreModuleを使ってホスト
  2. IISからKestrelへリバースプロキシ
  3. WindowsのNginxからKestrelへリバースプロキシ
  4. CentOSのNginxからKestrelへリバースプロキシ

の4種類です。

OSは、
Windows 2016 server
CentOS7.2
です。

.NET Coreのバージョンは1.0.1です。

チューニングは基本的になにもせずデフォルト値でなにが速いのかを検証します。
リバースプロキシしている3つは、Webサーバとアプリケーションは同サーバで実行しています。
CentOSの方は、Kestrelもサービス化して常駐するようにしました。
Windowsのリバースプロキシしている方は、サービス化がちょっと面倒だったので
コンソールから起動している状態です。

負荷

tsungというツールで1秒ごとに100ユーザずつ増やしながら
1ユーザが10リクエストするようにして1分間流します。

検証項目

tsungの結果とASP.NET Core、各Webサーバのログから出しています。
ASP.NET Coreのログは、NLogを使い
Asyncにしてバッファリングもしてログの書き出しがパフォーマンスになるべく影響のないようにしてあります。

検証するプログラムは、下記のただ文字列を返すだけのものです。

public class PerfTestController : Controller
{
    public string Greeting()
    {
        return "Hello World!";
    }
}
結果

各ログの平均値

tsung Webログ APログ
01.IISホスト 1.81 ms 1ms 0.14ms
02.IISリバプロ 5,310ms 5,260ms 1.54ms
03.Win+Nginx 530ms 832ms 1.63ms
04.CentOS+Nginx 1.90ms 0.74ms 0.09ms

Windowsでのリバースプロキシが間違ってるんじゃないってくらい遅いです。
特にWindowsのNginxの方は、Webサーバのログの方がtsungより大きくなっているので
明らかにおかしいのですが、何回やってもこのような結果になりました。
Webサーバのログを見てもIISにホストした場合やCentOS+Nginxに比べて
1秒間に半分ほどしかリクエストを捌けてません。

なんで同じようにリバースプロキシしているのにWindowsの方が圧倒的に遅いのか
納得いかなかったので
CentOSの方もサービス化せずにコンソールで起動して検証をしてみました。

tsung Webログ APログ
CentOS+Nginx 11,1640ms 5,572ms 757ms

やっぱりコンソールで起動するとかなり遅くなりました。*1

まとめ

この結果だけを見るとASP.NET Coreを動かすのは
ちゃんとサービス化して動かした方が良いってことですね。
まあ上でも書いた通りWindowsでサービス化するのはちょっと面倒なので
IISにAspNetCoreModuleを入れてホストするか
Linuxでリバースプロキシするのが良さそうです。

今回は、文字列を返すだけのAPIで検証してみたのですが
今度は普通にありそうなユースケースで検証してみたいと思います。

*1:上記は、dotnet run -c Release で起動した結果ですがpublishしてから dotnet sample.dllで起動しても同様の結果になりました。

CentOS7でASP.NET Coreを動かす

こんにちは、情報システム部の高野です。
.Net CoreをLinuxで動かす事例は、Ubuntuが多いのですが
弊社は基本的にRed Hat Enterprise Linuxを利用しているので
検証も同様にRed Hat Enterprise Linuxで行うべく
CentOS上にASP.NET Coreの環境を構築したのですが
結構、はまったので手順を残しておきます。*1

環境

CentOS7.2
dotnet Core1.0.1
nginx 1.10.2

dotnetのセットアップ

.NET - Powerful Open Source Development
ここに書いてある通りにやれば動かすことはできました。
Webのプロジェクトを作成してdotnet runをすればWebサイトも普通に動くはずです。
※この時点ではkestrelをターミナルで実行して動かしてます。

nginxのセットアップ

軽く動作を確認するだけならkestrelだけでも問題ないのですが
ちゃんと運用する際には、nginxなどのWebサーバが必要になります。

yumでnginxをインストールします。

> sudo yum install http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
> sudo yum install --enablerepo=nginx nginx

設定ファイルを修正します。
/etc/nginx/conf.d/default.confをテキストエディタで開き下記のように修正します。
※locationの部分だけです

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    location / {
        proxy_pass http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
   ・・・
}


SELinuxを停止します。
(本番環境では停止せずにちゃんと設定してください)

> sudo setenforce 0

※再起動後も停止したままにするなら /etc/selinux/config を書き換えます。

nginxを起動します

> sudo systemctl start nginx.service
> sudo systemctl enable nginx.service

2行目は、再起動時もnginxが起動するようにするためのものなので
必要に応じて実行してください。

dotnet runでkestrelを実行します。
curlでもブラウザでもいいので80番ポートにアクセスします。
作成したWebサイトが表示されればリバースプロキシの設定は完了です。

kestrelをバックグラウンドで実行する

このままだとターミナルを閉じるとWebサイトが利用できなくなってしまうので
バックグラウンドでkestrelを実行するようにします。

Publish to a Linux Production Environment
当初はこちらにあるようにSuperVisorを使って常駐化しようとしたのですが
CentOS7では、どうやらSuperVisorなどをインストールしなくても常駐化が簡単にできるようなので
そちらのやり方で実行しました。

/etc/systemd/systemにkestrel.serviceというファイルを作成します。
(ファイル名は、任意なのでkestrelでなくても良いです)

[Unit]
Description=kestrel server
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/dotnet /home/hoge/sampleApp/SampleApp.dll
WorkingDirectory=/home/hoge/sampleApp
KillMode=process
Restart=always
User=hoge
Group=hoge

[Install]
WantedBy=multi-user.target

ExecStartとWorkingDirectoryは任意のパスです。
dotnet publishでデプロイしたディレクトリを指定します。*2

あとは、nginx同様起動します

> sudo systemctl start kestrel.service
> sudo systemctl enable kestrel.service


これでターミナルを閉じても再起動後でもWebサイトにアクセスできます。
分かってしまえば結構簡単ですね

*1:現在、AzureでもRHELは選択できるのですが、つい癖でCentOSを選択してしまいました

*2:通常のテンプレートだとdotnet publishをするときにnpm等が必要になります