SPLOUT BLOG - Part 65

夏のマストアイテム携帯扇風機

こんにちわ。
リエです。

連日猛暑日が続いておりますが、いかがお過ごしでしょうか。

まだまだ暑い日がずっと続きそうなので、この夏から私もハンディファンを利用しています。
日本でのハンディファンの火付け役はFrancfrancの「フレ 2WAY ハンディファン」が有名ですよね。

私もこのハンディファンにはすごく助けられています。
購入するまではハンディファンって風力弱いんじゃないの？と思っていましたが、風力が5段階あり小型ながらにしっかりと風を感じることができるので、もう手放せません。（回し者ではありません）しかも軽い！

Francfrancのハンディファンめっちゃいいで！と熱弁しまくってたら、母親と姉も購入していました。（まさかの家族でおソロ）

ハンディファンは各社によって色々タイプがあるのでどれにするのか悩みますよね。

中でも首掛け式の携帯扇風機は昨年はあまり見かけませんでしたが、今年は街でもチラホラ利用者を見かけるようになりました。
ハンズフリーで便利だと思いますがDJ扇風機と言われるようにDJ感があって私はまだ利用には抵抗感があります。。

利用している方を見ると未来感を感じちゃいます。

ハンディファンとSUN BARRIER100の最強ペアで暑い日々を乗り切りたいと思います。
追伸：SUN BARRIER100について気になった方は、ぜひこちらのブログを見てね☆
https://blog.splout.co.jp/8502/

大腸内視鏡検査を受けました

はじめに

会社の定期検診で便潜血陽性の判定が出てしまったので大腸の内視鏡検査を受けました。胃カメラは飲んだことがないので初内視鏡です。検査の準備も含めていろいろと珍しい体験だったのでそれを書いてみます。

検査の予約

要精密検査の判定を受けて、大腸の内視鏡検査を受けられる病院を探しました。都合よく徒歩10分くらいの近所に内視鏡検査が得意なお医者さんがいる内視鏡クリニックがあったので検査の予約をしました。大学病院で長く内視鏡検査を勤めてきた方だそうです。今どきは病院での検査もウェブで予約できるので便利ですね。

事前診察

検査の2日前までに事前の診察を受けて下さいとのことだったので、こちらもウェブで予約して診察を受けました。便潜血が出たこと、内視鏡検査は初めてであることなどを話し、検査までの流れの説明を受けてこの日は終わりです。

検査のときは腸内を空っぽにしておく必要があるため、検査前日の食事は食べていいもの悪いものの制限があるそうです。検査向けのレトルトパックの食事もありますがどうしますか？とのことだったのでそれをお願いしました。前日の昼食と夕食の2食分です。

検査食と当日用の下剤をもらって帰りました。

前日

前日に食べた検査食です。

昼食。普通に会社で仕事してたので職場の電子レンジで温めて食べました。

夕食

昼食も夕食もどっちもおいしかったです。もっと味気ない感じかと思ってました。量が少ないのはまあしょうがない。ちなみに前日の朝食は特に制限ありません。

夜9時以降は絶食ですが、お茶などの水分は飲んでも大丈夫です。錠剤の下剤を飲んで就寝。

当日の朝

朝8時から下剤の摂取開始。

これに水を入れて下剤を作ります。

水を2リットル入れたところ。透明になるまでよく振らないといけません。このうち1リットルを1時間半かけてゆっくり飲みます。15分おきにコップ1杯のペース。

この日のハイライトはこの下剤でした。なにしろ不味い。機械っぽい臭いと生臭さとが入り混じった何とも言えない風味でコップ1杯を飲むのも一苦労です。下剤は誤飲を防ぐために不味くしてあると聞いたことがありますが、何もここまでしなくてもという味でした。下剤の種類によってはスポーツドリンクと変わりないような味のものもあるらしいいんですが。

早い人は割とすぐ効き始めるようですが、自分の場合はちょうど1リットル飲み終えたくらいからお腹が下り始めました。徐々に出るものがゆるくなっていき、5回目くらいにはほぼ透明な水のようなのしか出なくなりました。

下剤を飲み始めてからここまでで約3時間半。朝から病院に行って専用の部屋で下剤を飲む選択肢もありましたが、家にしておいて良かったと思いました。いつもの環境で気を紛らわせながらでなかったら時間を持て余すところでした。

検査

昼の1時に病院に行き、受付を済ませたら検査着に着替えます。このころにはもうお腹の具合も収まってます。作務衣みたいな検査着のズボンの形が面白くて、お尻の部分にスリットが入っています。着たまま内視鏡を入れられるようになっているんですね。漠然とお尻丸出しをイメージしてたんですが、考えてみればそれはそうかという感じです。

検査室で横になってしばらく待っていると先生が入ってきて鎮静剤を打ってくれました。そこで指示通りに大きく深呼吸したら頭がふわぁっとなって後はうつらうつらしてる内に検査は終わってました。痛いも怖いも感じる暇は無し。というよりいつ入ってきていつ出ていったのかも覚えてません。

その後別室で1時間ほど休養して眠気が覚めてから検査結果の説明を受けました。ポリープを1個取った以外は異常なしで、腸内は綺麗なものだということでした。取ったポリープは検査に回されて、後日良性の判定をいただきました。

おわりに

今回の検査で大きな問題が見つからなかったので、この先少なくとも5年程度は大腸がんの心配は無いそうです。ただしポリープが出来てたら早めに取ってしまった方が良いので2年に1回くらいは内視鏡検査を受けましょうとのことでした。またあれを1リットル飲むのかと思うとげんなりしますが、自分の体のためにまた2年後もがんばって検査を受けようかと思います。

SolrのSQLインタフェースでdistinct

はじめに

前回の記事で、SQLで言うdistinctをSolrで実現する方法を採り上げましたが、実はSolrでは部分的にではありますがSQLをサポートしており、もっと直接的にdistinctを実現することができます。

SolrのSQLサポート

Solrでは/sqlハンドラでSQLによるリクエストを受け付けます。/sqlハンドラは暗黙の内に設定されているもので、利用者が特に設定をすることなく利用できます。

サポートしているのは SELECT のみです。以下の機能が使えます。

WHERE 句で Solr の検索式が書ける
ORDER BY句によるソート
LIMIT句による件数の指定
SELECT DISTINCT句
GROUP BY句による集約
HAVING句

SELECT DISTINCT

前回の記事の、スポーツ施設で対応できるスポーツの一覧を取得する例は以下のように書けます。

$ curl -s --data-urlencode 'stmt=SELECT sports, count(*) AS cnt FROM sportare GROUP BY sports LIMIT 10' http://localhost:8983/solr/sportare/sql
{
  "result-set":{
    "docs":[{
        "sports":"",
        "cnt":1}
      ,{
        "sports":"BMX",
        "cnt":5}
      ,{
        "sports":"アイスホッケー",
        "cnt":48}
      ,{
        "sports":"アメリカンフットボール",
        "cnt":32}
      ,{
        "sports":"アルペンスキー",
        "cnt":1}
      ,{
        "sports":"アーチェリー",
        "cnt":113}
      ,{
        "sports":"インディアカ",
        "cnt":16}
      ,{
        "sports":"インラインスケート",
        "cnt":10}
      ,{
        "sports":"ウィンドサーフィン",
        "cnt":1}
      ,{
        "sports":"エアロビクス",
        "cnt":262}
      ,{
        "EOF":true,
        "RESPONSE_TIME":155}]}}

試行錯誤中に、以下の問題を見付けました。

テーブル名(Solrではコレクション名)に’-‘が含まれているとSQLの文法エラーになる。これはコレクション名のエイリアスを設定すればなんとかなる。
LIMITで取得件数は指定できるが、OFFSETが指定できない。OFFSETを指定しても文法エラーにはならないものの、機能はしていないようです。

$ curl -s --data-urlencode 'stmt=SELECT sports, count(*) AS cnt FROM sportare GROUP BY sports LIMIT 10 OFFSET 5' http://localhost:8983/solr/sportare/sql
{
  "result-set":{
    "docs":[{
        "sports":"",
        "cnt":1}
      ,{
        "sports":"BMX",
        "cnt":5}
      ,{
        "sports":"アイスホッケー",
        "cnt":48}
      ,{
        "sports":"アメリカンフットボール",
        "cnt":32}
      ,{
        "sports":"アルペンスキー",
        "cnt":1}
      ,{
        "sports":"アーチェリー",
        "cnt":113}
      ,{
        "sports":"インディアカ",
        "cnt":16}
      ,{
        "sports":"インラインスケート",
        "cnt":10}
      ,{
        "sports":"ウィンドサーフィン",
        "cnt":1}
      ,{
        "sports":"エアロビクス",
        "cnt":262}
      ,{
        "EOF":true,
        "RESPONSE_TIME":168}]}}

おわりに

distinctつながりで、SolrのSQLサポートを調べてみました。distinctに限らず、制限事項がいろいろと存在するので使いどころが案外難しいという印象です。通常の検索処理でというよりもインデックスに対する統計処理などで使うのが良さそうです

オンライン決済stripeを触ってみた

ナイトプールでウェイウェイしてる夢を見ました。私の心は夏模様。
マエダです。

Webサービス開発しているとオンライン決済のニーズがでてきますよね。
そんな開発者の悩みを解決してくれるのがオンライン決済サービスstripe。

https://stripe.com/

“デベロッパー・ファースト”と謳っている通りで非常にかんたんなステップでシステムに決済機能を導入できます。

Ruby on Railsの場合

vi Gemfile

gem 'stripe'

bundle install –path vendor/bundle

あとはよしなに。

PHP Laravelの場合(定期決済)

composer update
composer require laravel/cashier

あとはよしなに。
https://readouble.com/laravel/5.5/ja/billing.html

全然その先説明してないじゃん！って思われたかと思いますがQiitaとかで日本語での情報も十分ありますので単発決済でもサブスクでも必要に応じて活用してみてください！

<参考>
公式ドキュメント：https://stripe.com/docs

サービス設計: Depth vs Width

こんにちは。開発担当のマットです。

開発はとても楽しい仕事で、人が考えたアイディアに命を吹き込むような仕事だと思っています。

開発者として作っているサービスを成功させたいという気持ちがあるので、サービス設計に問題があるかどうかを判断できるよう、そのサービスの設計を多くの観点から見ることがとても大事です。

そこで、サービス設計の新しい見方を紹介したいと思います。
それは、サービスの「Depth」(深さ)と「Width」(幅)。

それって一体何でしょうか？

何かのサービス（ウェブサイト、アプリ、ゲームなど）を設計する時、1番に考えなければならないことは利用いただくユーザーのことだと思います。
作ったサービスがユーザーのニーズに満たさない場合、サービスは目的を果たしません。

開発者としてそれはとても悲しいことなので、どうしても避けなければなりません。

そうならないように設計者がサービスにできるだけ多くの機能を入れようとすることがありますが、それは果たして正解なのでしょうか？

Widthとは？

ユーザーが何かの行動を取ることを「アクション」と呼びましょう。

検索バーにキワードを入れて、サイトを検索することが「アクション」。
ソーシャルメディアに写真を投稿することも「アクション」。
Bボタンを押したら、マ○オがジャンプすることも「アクション」です。

ユーザーがたくさんのことを体験できるように、設計者がユーザーに多くのアクションを与えることがよくあります。

「アクションを与える」=「自由を与える」=「良い」

と思いきや、100種類のアクションがあると、ユーザーがそれらを覚えないと使えないことが発生してしまいます。
Width = 「ユーザーが取れる行動」ですが
Width = 「複雑さ」とも言えます。

せっかくたくさんの機能を作っても、複雑すぎるとユーザーがサービスを使わなくなってしまいます。

では、Depthは何でしょう？

Widthが「ユーザーが取れる行動」だとしたら、Depthは「ユーザーが取った行動によって生み出せる結果の多様性」です。

少し、わかりにくいので、実際の例をあげたいと思います。
それは、どこの国の子供でも好きな「積み木」です。

「積み木」がサービスだとしたら、アクションは極めて少ない（積み木を拾う、積み木を置く）ですが、その簡単なルールで生み出せるものは無限に近いです。

デジタルのゲームでいうと、やっぱりMinecraftが思い浮かびますが、多くのMMOで自分のキャラクターを自分なりに成長させることができますし、多くのシミュレーションゲームでは自分の思う通りの街や国を作ることができます。

ウェブサイトとアプリでいうと、ソーシャルメディアが一番の例だと思います。
インターネットにテキストや画像ファイルを上げることがずっと昔からありましたが、「プロフィール作成」、「人をフォローする」、「友達に共有する」だけで、世界がぐっと変わりました。

行動の組み合わせで、ユーザーに面白いものを作りあげる力を与えることがDepthの特徴です。

では、どうしたらいい？

上記で、「Depth」=「良い」に対して「Width」= 「悪い」、だと解釈しやすいですが、必ずしもそうとは言えないと思います。

例えば、将棋と囲碁を比較すると、将棋のルールの方が複雑で「Width」はありますが・・・だから囲碁がより良いとは言えません。

Widthも適切に設計することが大事だと思います。

機能が少なすぎてWidthが足りない場合、ユーザーはすぐに飽きてしまいます。
逆に、機能がありすぎて複雑になると、ユーザーがすぐに諦めてしまいます。
Depthが足りなければ使っても面白いものではないので、すぐに使われなくなるでしょう。

つまり、サービスに機能をたくさんつけて複雑さを増やしすぎてしまうことがないよう、サービス設計者と開発者がもっと考えるべきではないかと思います。

なお、たくさんの機能をつけても、それがユーザーにとって楽しいまたは便利な結果に繋ぐことができない場合も考え直すべきではないかと思います。

今後、サービスを設計する際、上記の「Depth」と「Width」のレンズを通して、サービスの強弱を洗い出して、より良いサービスを作れるよう考えてみていきたいと思います。