読者です 読者をやめる 読者になる 読者になる

verbalize

文章書く練習.適当でいいから色々書きたい.

HoloLensを軽く触ってみた印象

日記 デバイス

https://compass-ssl.surface.com/assets/f5/2a/f52a1f76-0640-4a37-a650-51b0902f8427.jpg?n=Buy_Panel_1920.jpg

大学の授業でオムニバス形式の授業があり、そこでたまたまHoloLensを触る機会があったので少し思ったことを書く。

ただ実際には授業中の講師の方の5分程度のデモを見て、授業後に3分ほど自分で体験しただけなので、ちゃんとコンテンツに触れられたわけではない。

まず最初の印象として、見た目がかなりスタイリッシュなデバイスで驚いた。単体で見ると結構かっこいい。またHoloLens自体にはWindowsが乗っており、CPUなどもデバイス本体に属しているのでケーブルでつなぐことなく単体で動作するらしい。ますます軽快なイメージを持った。ただその見た目とは裏腹に地味に重かったので長時間の使用は疲れるかなと思った。

装着すると、半透明のディスプレイがありガラス越しに周りが見えるようになっている。VRではなくMR(Mixed Reality)が体験できるデバイスなんだな、とその時理解した(恥ずかしい)。ディスプレイには、ARで空間上にメニューやオブジェクトが表示されており、中央にはカーソルが存在している。カーソルは顔が向いている方向(視線方向)に対応しているらしく、このカーソルを対象に合わせつつ、およそ自分の視界に入るくらいの範囲で「手でものをつまむ」ような仕草をするとクリックが実行できる。

実際にWebブラウザが表示されていたのでクリックしてページ遷移をしてみた。で、体験した内容はたったそれだけで、空間には他にもオブジェクトがあったのだけれど触る時間がなかった。今度触る機会があったらゲームとかやってみたい。

それで授業を受けてとても驚いたのが、とにかく周りが「HoloLensで何かが変わる」という雰囲気だったこと。たしかにHoloLensが将来的に眼鏡くらいのサイズになれば、電脳コイルみたいな世界ができて凄そうという想像はできるけれど、今日触った感じだと衝撃みたいなものは特になかった。唯一感じたのはその操作インターフェースのやりにくさで、頭部を動かしてカーソルを動かすというのは単に自分が見たい方向を見る以上に細かい動作が必要なので、ストレスフルに感じた。クリック動作もあまり感度が良くなくて違和感があった。

また家に向かいながら、今の主流なゲーム機や急速に普及したスマホを見ても、現状のHoloLensのような操作インターフェースではあまり日常的な普及はできないのでは、と思った。というのも、ゲーム機のコントローラーにしても、スマホのタッチディスプレイにしても、操作には物理的な接触とフィードバックがある。これは多分快適な操作に重要なのではと思う。HoloLensのインターフェースでは、そこに「人がものをつまむ」というメタファーを感じることはできても、やはり宙を掴む感じがするというか、違和感があると思った。

ただ、普及して慣れれば問題ないみたいな話かもしれないので、実際のところはよくわからない。もうちょっと色々考えなら今後の動向をチェックしたいなと思った。あと周りの人にも色々何を思ったか聞いてみようと思った。

ということで今回はHoloLensを触れてナウい感じの授業だったのでよかった。

「ヘルシープログラマ」を読んだ感想

ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack

ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack

感想

本書はプログラミングを職業とする人が、一日中座り続けるという習慣から慢性的に運動不足に陥ることの危険性や、よく引き起こす疾患の事例とその対策について説明している。一方、タイトルから匂い立つ"プログラマは如何にして健康になれるか“というような方法論だけにとどまらず、単にプログラマとしてより良いパフォーマンスを発揮するためにどのように身体と付き合うべきかということも書いてある。

私は大学の図書館でたまたま本書を見つけ、また最近ではタイピングによって右手首に負担をかけていることを認識していたので手に取ったが、本書の前半で述べられている

  • 「習慣」そのものについて
  • 脳と身体の関係について
  • プログラマがよく引き起こす疾患について

などのトピックは、今現在なんらかの疾患に陥っている人や、いかにも不健康な見た目をした職業的プログラマだけでなく、デスクワークを日常的にする人なら誰が読んでもためになると感じたのでおすすめしたいと思った。

特に私の印象に残っているのは、ウォーキングが脳にもたらす効果について説明した2章である。1章で既に脳と身体のつながりについて触れられ、物理的な健康が頭脳に対して直接的にメリットをもたらすことが強調されている。そして2章では、フェルマーの最終定理に8年間注力し、実際にその証明を成し遂げたAndrew Wilesを例に、作業の前後にウォーキング(エクササイズ)を行うことで集中力、記憶力、創造力を高めることができると述べられている。

これは、プログラマがコードを夜遅くまでハックしたり、最新の技術書を読んだりすることと同様に、ウォーキングが我々の能力を強化するための最高の方法の一つであることを示している。

それ以外にも、習慣のメカニズムやスタンディングデスクの真実を知ることも出来る。これらは多くの人々が関心のある一般的なトピックだと思う。最後に、本書で紹介されていた健康のユニットテストに対する自分の状況をメモして、今後も意識したいと思う。

健康のユニットテスト

  • 踊り場まで階段を上がると息が切れるか
  • 1時間以上立ち上がることなく座り続けることが、日常的にあるか
  • 昨年、仕事に差し支えるほどの腰痛、首痛、肩痛、手首痛が生じたことがあるか
  • 先週、コンピュータの画面を見た時に、ドライアイ、目の充血や炎症、あるいは目の焦点を合わせづらくなったことがあったか
  • 先月、苦しくなるほど食べすぎたことが複数階あったか
  • 今日、直射日光に当たった時間は10分以下だったか
  • 過去5年間に、虫歯の数は増えたか
  • 見をかがめて靴紐を結ぶのは苦しいか
  • 過去5年間でズボンのサイズが明らかに大きくなったか

目次

1章 変化を起こそう
2章 健康のブートストラップ
3章 椅子よさらば?
4章 アジャイルなダイエット
5章 頭痛と眼精疲労の対策
6章 腰痛への対策
7章 手首痛への対策
8章 実践的なエクササイズ
9章 個室の外で考えよう
10章 健康のリファクタリング
11章 チームを作ろう
12章 進め、健康なプログラマ

追記

メモ。

習慣とは

MITのマウス(ねずみ)を用いた実験により習慣にはいかのような3要素があることが受け入れられ始めている。

  • キュー(きっかけ)
  • ルーチン(決まった作業)
  • 報酬

すなわち習慣とは以上のような要素をみたすものであるとも言える。よって何か新しい習慣を“始める”ときには以上の要素を考慮して活動を規定する必要がある。一方習慣を“変える“コツは、上記の三要素の内(習慣を変えるために)ルーチンを変更した時、キューと報酬はそのままに保つことである。よって変えようとする習慣のキューと報酬を特定することが大切。

座っていることと立っていること

座って作業することが健康に良くないことと同じように、誤解を恐れずに言えば、立って作業することも健康に良くないと本書では述べられている。これはAlan Hedge博士の研究結果を基にした主張であるが、立ちっぱなしによって循環系に負荷が加わるため、アテローム製軽動脈硬化症、静脈瘤、血餅を発症するリスクが高まると言われている。

しかし、スタンディングデスクを用いて作業を行うことにより、1時間あたりの消費カロリーを50キロカロリーを増やすことができるというメリットがある。これは座っていることに比べるとあなたの体重を保つことに貢献する。

眼精疲労を軽減する方法

パソコンを見続ける上で眼精疲労は避けられない問題。特に眼鏡やコンタクトを着用している人は少なくとも1年に一回定期検診に行くことは必須である。その上で普段から心がけると良いのは以下である。

  • ディスプレイとの距離を50cmから1mに調整すること
  • 室内の明るさとディスプレイの明るさの差を小さくすること
  • 可能であればブルーライトをカットすること
  • 20分毎に遠く(6メートル先)のものを見ること
  • 同じく20分毎にゆっくりまばたきをして目の乾燥を防ぐこと

手首痛を軽減する方法

まず注意したいのは「一日7時間以上タイピングをする人でも、一般的な場合に比べて毛根間症候群(手首痛の疾患)を発症する傾向は特に強くない」ということである。よっておそらく手首痛になるような悪習慣(姿勢、タイピングなど)を持っていること自体が原因であると考えることが出来る。

手首痛を改善するためのエクササイズにはジャズハンズシャドウパペットエジプト人ショルダーシュラッグといったものが本書では紹介されている(内容は割愛)。

個人的な対策として、自分は右手首に痛みを感じているので、右手のタイピング動作を見直す。特に、右手範囲の上段(( ) 0 - ^ ¥)と下段(, . / _)はプログラミングでよく使うにも関わらずタイプが苦手な場所なので、正しい方法でタイプをするようにする。

昨年買った睡眠に関わるアイテムの感想メモ

こんばんは。だらだら書いていたら新年が明けてしまいました。あけましておめでとうございます。

本記事では今年買った少しテックな2つのアイテ厶について感想をメモします。

Mi Band 2(Xiaomi)

公式サイト

一つ目はXiaomiが出しているスマートウォッチ、Mi Band 2です。Mi Band 2はMi Bandの後継機で、LEDディスプレイを搭載しています。主な機能としてはデジタル時計、睡眠計測、心拍数計測、歩数計測、そしてスマホ通知との連動です。

購入の動機は、この値段で睡眠計測機能が使えるという点です。またMi Band 2になってディスプレイが搭載されたことによりセンサーだけでなく腕時計として使えるようになったのも大きかったです。

購入したのは10月なのでおよそ2ヶ月間利用したのですが、これという欠点はほとんどなく、サイズも小さいし、軽いし、充電は平気で5日間位持つので、値段を考えると素晴らしい商品だと思います。

睡眠計測

まず、一番気になっていた睡眠計測の機能ですが、就寝・起床ともにかなり正確に時間を記録してくれるので驚きました。計測した結果はXiaomiの公式アプリで確認でき、Deep Sleep時間とLight Sleep時間も計測してくれます。Deep Sleepの時間はどの程度正確なのかはわかりませんが、一応自分の睡眠の質の目安となります。私は毎日7〜8時間位寝ますが、Deep Sleepは2〜3時間で推移しています。この部分はどのくらい信頼できる数値なのか、個人差はあるのか、などがわかると良いなと思います。SNSとかないのかな笑。

一方、この機能の欠点はこれを手に装着して寝なければいけないことです。私の場合、最初から付属しているシリコンのバンドを使っているため、毛布に引っかかったり布団に押し付けながら寝ると手に跡ができたりして、気になります。少なくとも気持ちよくはないので邪魔だなと思うシーンが多々あるのが難点ですね。

というわけで、睡眠計測はまぁまぁ使えています。最近は機械学習とかloTとか叫ばれていて、ライフログを溜めること自体が面白いのですが、ちょっと面倒くさい面もあります。計測したデータは今のところ、月ごとの平均睡眠時間を見て「寝すぎたなぁ」とか「寝るor起きるの遅いなぁ」と思う程度ですが、改めて見てみるとやはり自分の生活習慣が如実に表れていると感じます。なので「来月から早起きしよう」とか「夜寝る前はブルーライトシャットアウトしよう」といった生活習慣を変える試みと併せて使うと数字でフィードバックが返ってくるので嬉しいと思います。アプリからデータを見てもいいですが、csvでエクスポートできるのでもっとちゃんと分析も出来ると思います。

時計

Mi Band 2は普通に時計として使えます(使っています)。ただLEDディスプレイなのでずっと点いているわけではなく時間で消灯します。そのため腕のひねりを検知して時計を確認したタイミングで点灯するようになっています。ただ微妙にタイミングが遅く少し気になります。また、文字も小さいので、時計としては及第点という感じです。

またアラーム機能もあります。本体が振動して知らせてくれます。ただあんまり強い振動ではないので起きられない上、バッテリーの寿命を減らす原因になるみたいなので普段はあまり使いません。意外に便利なシーンが電車移動で30分くらい寝るかというときです。音じゃなく振動なので使いやすいです。

歩数計

歩数計としても使えます。一日の目標を設定して達成すると知らせてくれます。座りがちなので是非みなさんも意識的に歩きましょう笑

防水

またMi Band 2はiPhone7と同じIP67の防水性能があります。お風呂ぐらいなら付けたまま入れます。最初はわざわざ付けて入るか?と思っていましたが、寒くなってきてからシャワーに入る時間が長くなってきたので時間を意識できるように付けて入るようになりました。こういう少し便利なところが気に入っています。

スマートフォン連携

私はほとんど使っていませんがスマートフォンの通知を振動とともにMi Band 2のディスプレイに表示することもできます。ただ任意の文字情報を表示することはできないため、ただ通知がきたとわかるだけです。

特によく使っているのはAndroidのスマートロックです。スマートロックは特定の場所、時間、またはデバイスとの接続の有無によってパスコードなしでホーム画面にアクセスできる機能です。Mi Band 2を使ってスマートロックを設定すると、Mi Bandが接続されている間はパスコードを打たなくて良くなり、かつスマホを紛失したりした場合などにはロックを有効にできます。最近ではスマホは財布と同じくらい重要なものになってきていて、クレジットカード番号などセンシティブな情報を保持しているデバイスです。iPhoneのように指紋認証があればいいですが普段のパスコード入力が面倒くさい人には重宝すると思います。


mornin'(Robit)

公式サイト

もう一つは家のカーテンを自動開閉してくれる魔法のようなアイテム、目覚ましカーテン mornin'です。家のカーテンに取り付けてスマートフォンで設定するだけで、特定の時刻にカーテンを開閉してくれるアイテムです。

このアイテムも睡眠に関わるハックアイテムで、「朝すっきり目覚めるコツは? 超多忙、不規則な生活…それでも結果を出す人の快眠戦略」という記事をきっかけに知りました。朝すっきりと起きる方法としてしばしば「朝日を浴びること」が挙げられていますが、それを自動カーテンという如何にも近未来的な方法で促してくれるということで、そのアイデアに感銘して購入しました笑 なんといっても既存の普通のカーテンに取り付けられるというのがすごいですよね。

morninの仕組みはカーテンレールについているランナーとランナーの間(下図参考)にmorninを設置することで、特定の時刻にmorninのローラが作動、左右に動きカーテンを引っ張って開閉します。左右に動く幅と作動時刻はスマホで設定できます。

f:id:bonhito:20170101002512j:plain:w300

今は手元にmorninがないのであれですが、スマホアプリのUIはこんな感じ(公式サイトより)。

mornin スマホアプリUI

買ってから現在までの1ヶ月くらい使いました。感想としては、自分は部屋が東向きなので晴れていると朝日がガンガン入ってきてとても気持ち良いです。ただ朝日を浴びるっていうのは何度か実践したことがありますが、すぐ目が覚めるという感じではないですよね。朝起きる習慣をつけるのに補助的に使えそうな感じです。

morninを使ってよかったことは意外なところにもあり、それは夜遅く帰ってきてもカーテンが自動で閉まってくれていることです。部屋が通りに面しているので気持ち安心です。また長期休暇のときに部屋を開けていても自動で動くので防犯的にも良いです。

欠点もいくつかありますが、特に致命的なのがmorninを設置したら基本的に手でカーテンを開け閉めできなくなくなること。自分は購入してから知ったのですがこの点はもっと強調すべきと思いました。またスピードによってはそこそこの動作音がします。買ってすぐは動作音で目が覚めてました笑。 スマホで動作スピードは変更できるので調整は可能です。慣れると大丈夫です。

最後にもう一つ、morninは開閉しているうちに微妙にどちらかに少しずつ寄っていってしまいます。環境の差はあれど皆さんもほとんど同じだと思うのですが、閉める方向に寄っていきます。原因は開ける時の抵抗が大きいく、同じ動作時間で動作しても距離が微妙に短くなるからでしょうね。できれば開けるときと閉めるときで動作時間を別に設定できればなぁなんて思っています。

さいごに

実はこの記事を書いてから両方とも睡眠に関わるアイテムだということに気付きました。ということなので2017年は早寝早起きしたいです…。 私はApple Watchのような高価なものは買えないですが、今回紹介したようなアイテムを使ってみて十分魅力的な商品は転がっているなぁと感じました。来年も良い商品があれば買いたいです。

参考

Rubyの文法のミニメモ

Railsでサービス作ってみたは良いものの、Rubyに関する理解が結構おろそかになっている。なので、今回は基本的だけど未だに理解できていない部分を簡単にまとめる。

Rubyはすべてがオブジェクト

Rubyに入門すると一度は耳にする「Ruby完全にオブジェクト指向的な言語である」という文言。入門したときはあまり深く考えていなかったので、よく考えると「いやいやPythonにだってクラスはあるんだからオブジェクト指向は使えるじゃん」とか思っていた。Pythonオブジェクト指向は後付けのものだということを聞いたことがあるので、まぁそんな程度の違いだろうという曖昧な理解だった。

しかし、改めて調べてみてRubyが完全にオブジェクト指向的であることが簡単にわかる例があったので書いておく。

# Rubyが完全にオブジェクト指向的であるというということは
# 1などの定値もオブジェクトになっているということ
p 1.class # => Fixnum

# 1がオブジェクトならmethodを持っているよね
p 1.methods # => [:%, :&, :*, :+, ・・・]

# +というメソッドがあるなら足し算はこう書ける
p 1.+(1) #=> 2

# 数字がオブジェクトのおかげでこういうRubyらしい書き方ができる
10.times {|i| print i} # => 0123456789

なるほど。これで前よりは少し理解が進んだ。

シンボルとハッシュ

Rubyにはシンボルという型がある。:(変数名)で定義でき、注意点は

:symbol == :"symbol" # => true

となること。

このシンボルであるが、よくハッシュで使われる。ハッシュはkeyとvalueで構成され、一般的にkeyは文字列で定義される。

しかし、keyを文字列として扱うと、valueを参照(keyの識別)する際にコストの高い文字列処理を行わなければならなくなる。ここでシンボルである。

端的にいうと、シンボルは任意の名前をつけることの出来る整数である。例えば:symbolというシンボルはなんらかの整数と紐付けられており、常に一定となっている。よってシンボルをkeyとすることで、文字列処理を行わなければ行けなかったところを、コストの低い整数処理に置き換えることが出来る。

わかりやすい例として、以下のようなコードを実行してみると、同じ文字列でも異なるオブジェクトidとなることがわかる。異なるオブジェクトなのだから当然といえば当然である。

a = "test"
b = "test"
a.equal?(b) # => false 

一方、シンボルはオブジェクトによらない。

a = :test
b = :test
a.equal?(b) # => true

ネットで調べると「Rubyのシンボルは文字列の皮を被った整数だ」という表現がされていて、的確だなと思った。文字列を内容のためではなく、一種の固有な識別子として使うコードを書こうとしているときにはシンボルのほうが適切である。

また、ここからは余談だが、Ruby1.9以降では

numbers = {"one" => 1, "two" => 2, "three" => 3}
numbers["one"] # => 1

numbers = {:one => 1, two => 2, three => 3}
numbers[:one] # => 1

のような標準的な記法に加え、

numbers = {one: 1, two: 2, three: 3}

という省略記法がある。この省略記法では自動的にkeyがシンボルになるので注意が必要である。

do, {}, () の使い分け

特にイテレータを使う時の使い分けが混同する。 例えば、

10.times {|i| p i}

10.times do |i|
  p i 
end

は同じ動きをする。一般的にはブロックの中身が1行のときは{}が、複数行となるときはdoが習慣的に使われるので覚えておく。ちなみにdo{はメソッド呼び出しと同じ行にあれば良いので、

# do endを一行で
10.times do |i| p i end

# {}を複数行で
10.times { |i|
  p i
}

と逆の形で書いても特にエラーにならないことも覚えておく。

また、doに関しては

text = File.open("./test.txt") do |f|
  filesize = f.stat.size
  f.read
end

のような形で使われることも度々あるが、単に最後に評価した値がtextに入るだけなので驚く必要はない。ブロックで区切られているので分かりやすいといえばそうかもしれない。

最後に、RSpecを使っていて、(){}を同様の役割で使っていて少し混乱した例があった。

specify { expect(1+1).to eq(2) }
specify { expect{1+1}.to eq(2) }

上記の2つはexpectの括弧が異なっているが同じ動作をする。なんなんだこれはと思い調べると、Procオブジェクトというものであることがわかった。

簡単に言うと、Procオブジェクトはブロック({|i| p i }など)をオブジェクト化したものである。深く理解したわけではないが雰囲気をつかむには以下のサイトが役に立った(古いけど)。

d.hatena.ne.jp

ではブロック(またはProcオブジェクト)を引数として渡すと何が嬉しいのか。これは推測だが、おそらく関数の引数に関数を渡すことが出来るという点でメリットがあるのだと思う。ついでに気づいたのだけれど、Rubyはすべてがオブジェクトであると言いつつも、ブロックや関数はオブジェクトではない気がする。だからこそ関数そのものをオブジェクト化できるProcにメリットがあるのではなかろうか。

上記のRSpecの例だと、おそらくexpect(1+1)では、expect(2)と同様の動作していて、expect{1+1}はそのまま{1+1}というブロックがexpect内で評価されて実行されるようにexpectが作られているのだと思う。

Procは要勉強。

改行して良いところ

これもあるあるだけど、書いていて長くなってしまった文を途中で改行したくなることがある。ただ、どこでなら改行していいのかわからなくなる。

基本的に改行は文の終端と判断されるので、改行する前の部分のみで評価が成立しまう文は改行できない(\でエスケープしてやる必要がある)。一方、評価が継続されるような場合は改行しても問題ない。例えば、

numbers = {
  one: 1
  two: 2
  three: 3
}

は問題ない。ただこれは結局わかりやすいルールとはいえなくて、慣れが必要だなと思う。

所感

まだ知っている言語が少ないせいかもしれないが、Ruby10.times10.uptoはとても見やすくて好き。do endPythonのインデントに比べるとネストが深くなった時に幾分見やすいように感じる。

ただRuby本当に独特なルールも多くて、メソッドの括弧を省略できるのが慣れない。というのも、サンプルコードをコピペしたりしていると、メソッドに対してそれがメソッドだと認識せずに使っていたりすることがある。 例えば

# uptoはメソッドで10が引数。前後の括弧は省略されている
1.upto 10 do |x|
    p x
end

# よってこういうことをするとエラーになる
1.upto 10 {|x| p x}

のように、エラーが出て初めて気づく例がある。また、括弧がないせいでメソッドと変数がパッと見分けられなかったりもする。メリットとしては、括弧を省略できると打つのが楽になる。括弧がないので引数の変更も楽になる。それぐらいかな…。

あとついでに、関数内で最後に評価された値が自動的に返されるのも慣れない。返り値を変えるために関数の最後で変数を呼ぶだけの行があったりすると苦笑してしまう。returnと書いたほうが良いと思う。

今後新たに気付きがあればまた書きたいなと思う。

プログラミング言語 Ruby

プログラミング言語 Ruby

Fashion Shop Mapというwebサービスをつくった

タイトルの通りwebサービス作りました。またしてもGoogle Mapを使ってしまった。

www.fashion-shop-map.com

サービス概要

今回作ったものは、ファッションのショップの位置情報を検索することができるサービスです。これを使うことで、複数のショップの位置を同時に地図にプロットして見ることができます。

ユーザーの操作はとてもシンプルで、検索したいショップと都道府県を選択してボタンを押すと、選択された都道府県内にある店舗が地図上にマッピングされます。

機能としてはシングルページのwebサイトに近いくらいシンプルです。現在は主にセレクトショップを取り扱っており、以下のようなショップが登録されています。

ロゴ 名前 ロゴ 名前
f:id:bonhito:20161124230822p:plain BEAMS f:id:bonhito:20161124230835p:plain UNITED ARROWS
f:id:bonhito:20161125005139p:plain UNITED ARROWS BEAUTY&YOUTH f:id:bonhito:20161124230852p:plain UNITED ARROWS green label relaxing
f:id:bonhito:20161125005211p:plain URBAN RESEARCH f:id:bonhito:20161125005216p:plain URBAN RESEARCH DOORS
f:id:bonhito:20161125005220p:plain SHIPS f:id:bonhito:20161125005311p:plain EDIFICE
f:id:bonhito:20161125005319p:plain 417 EDIFICE f:id:bonhito:20161125005224p:plain JOURNAL STANDARD
f:id:bonhito:20161125005228p:plain coen f:id:bonhito:20161125005233p:plain A.P.C.
f:id:bonhito:20161125005237p:plain BShop f:id:bonhito:20161125005242p:plain SENSE OF PLACE by URBAN RESEARCH
f:id:bonhito:20161125005246p:plain HARE f:id:bonhito:20161125005252p:plain RAGEBLUE
f:id:bonhito:20161125005257p:plain GLOBAL WORK f:id:bonhito:20161125005345p:plain FREAK'S STORE

モチベーション

まず服が好きなので、それに関わるサービスを作りたいなと思っていました。

一番コアな動機としては、いろんなショップがどこにあるのかもっと手軽に見たい!と普段から感じていたことでした。私が服を見ようと思ったら、まず一覧性のあるWebで見て、その後チェックした服を実際に見に行きたいなと思うのですが、大体

「よっしゃ、週末服見に行こう。できれば1か所でビームスユナイテッドアローズとアーバンリサーチは見たいよな」

という流れ(あくまで例ですが)になります。しかしこの時、現状だとそれらのショップがどこにあるのか、Google Mapや各ショップの公式ページを見て一つずつ探さななければなりません。

この体験からGoogle MapはAND検索に弱いなと感じ、ファッションに特化した地図を作ろうと思いました。これはサイトのaboutページにも簡単に書いています。

最後にもう一つ理由があり、比較的取り扱うエンティティがシンプルだったことがあります。フレームワークを使って動的なアプリケーションを作るのはほとんど初めてだったので、DB設計が難しそうなSNSなどは考えていませんでした。

開発の話

このサービスはRuby on RailsGoogle Map、Bootstrap、jQueryを用いて作成しました。デプロイはherokuなのでスリープしてしまうと最初のページ読み込みが遅いです。

制作を始めてから現在までおよそ2ヵ月くらい経過しています。後ほど触れますが時間をかけてすぎてしまったのは反省点の一つです。

流れとしてはまず、9月末にRubyRailsに同時に入門しました。Railsおすすめのチュートリアル集で紹介されているものの内、短めのものを4つくらいこなすとすぐに流れがつかめました。夏のインターンMVCの考え方をつかんでいたのも良かったなと思っています。

その後この開発に着手し、毎日1〜3コミットずつくらいのペースで進めていきました。

サーバーサイド

本サービスは一見、位置を検索したいショップ毎にGoogle Mapで検索をかけ、結果を重ねただけのように見えますが、実際にはちゃんとデータを集めてDBに収め、そこから引っ張ってプロットしています。その理由としては、

  • そもそも店舗の情報を集める適当なAPIはない

  • ユーザーの検索のたびにGoogle Map APIを使うとすぐに制限を食らってしまう

  • Google Map自体の検索を使ってしまうと取り出したい・表示したい情報をコントロールできない

などがありました(若干うろ覚え)。なので、とにかくショップの店舗情報を集めるべく一つずつ公式ショップからスクレイピングすることにしました。

今gitのcommit logを確認すると、作り始めてからチュートリアルで学んだことをこれに当てはめながら開発を進め、サイトのシステム的な部分に関してはDBの設計と合わせても10/6に終わっていました。スクレイピングのやり方もそのあたりで並行して学びました。

なのでこれ以降はフロントエンドの開発と並行して毎日少しずつスクレイピングし、取扱ショップを増やしていきました。

フロントエンド

サーバーサイドが一段落ついてから画面の実装に取り掛かりました。試作時点での画面はこんな感じで全くデザインが当たっていませんでした(サービス名すらも違う)。

f:id:bonhito:20161125002121p:plain

そして現在のこの画面になるまでにおそらく約1ヶ月くらいはかかったと思います。まぁちょうどその頃から開発にかける時間も少なくなってしまったのも一つ原因なのですが。

f:id:bonhito:20161122160642p:plain

当初はモノクロな検索画面と地図表示画面の2つしか作っていませんでしたが、そこからBootstrapを導入し、検索条件部のドロップダウン・検索条件ラベル・地図表示画面を実装し、そのあと地図の横のリストや当サイトについてのページ、お問い合わせのページなどを作りました。このあたりではまだサーバーサイドからもらう情報が足りなかったりして、サーバーサイドのコーディングのやり直しだとか、DB設計のやり直し(カラムの追加)とかもあり手戻りが多かった気がします。

そして、シェアボタンとGoogle Analyticsなども付けました。デザインの改良はその都度その都度行いました。振り返ってみると、なにか新しいものを追加する度にcssの調整が必要だったり、jsを書かなければいけなかったり、小さなバグを潰したりと大変でした。また、最後になってから付け焼刃的にレスポンシブデザインを実装したり、前回のエントリで書いたようにロゴの使用の問題にぶつかったり、使っていた画像が実は改変禁止の素材だったりと、もうとにかく自分でバグを作り込むケースが非常に多く目立ちました

今回の開発を通じてもっともっと知識を付けなければなぁと思いました。それにしてもフロントエンド地獄って感じでした。まじで時間食われた…笑

インフラ

簡単で無料なのでherokuにしました。ルートドメインが使えないとは知らずにドメインを取得してしまい悲しい気持ちになりました。

できればシェルログインできるサーバーを借りてちゃんとデプロイしたいのですが、railsアプリはWEBrickなるwebサーバを使っておりなんだかめんどくさそうだったのでとりあえずまたの機会にしました。

振り返り

発見

  • フロントエンドは大変

    自分の実力不足でもありますが、シンプルだからと高を括って設計などをまったくせずに着手してしまったのが原因。振り返ると、機能やページを追加する度にスタイルが崩れたり、違うデバイスでサービスを使ってみて初めておかしい所に気づいたりと、fixのコミットが頻繁に入っていました。現在もなおモバイルに対するデザイン方法がわからない上、Chrome以外のブラウザでテストしたりもしていないので、フロントエンド開発自体に対する理解を深める必要があると感じました。

  • プロトタイプは仕様や設計を明確にする上で効果的

    今回プロトタイプを1つ作ってから開発を始めたのですが、これは純粋に良かったです。ただプロトタイプをどの程度の粒度(大きさ、正確さ)で作るべきか、あるいはどのような点に注目しながら作るべきなのかが明確でなく、設計のブラッシュアップが十分に行われませんでした。

  • MVPで公開した方が良い

    よく言われている(?)かとは思いますが、MVP(Minimum Viable Product: 必要最低限機能)で公開したほうが良いなと思いました。ただ、ユーザーが初めてサービスを目にした時にあの機能この機能があれば素通りせずに止まってくれるのでは無いかと考えてしまうので難しい。これについてもリーンに関わる書籍などを読んで意図するところをきちんと理解したい。

  • CRUDの内のREAD操作のみをユーザーに提供するサービスは、セキュリティ的に比較的楽

    不安ではありますが、とりあえずセンシティブな情報はあまりないので大丈夫かなと思っています。

特に良かったこと

  • 好きなテーマでサービスを作ったこと

    楽しかった。

  • こうしてある程度作りきってエントリを書いていること、それ自体

  • git使ったこと

    今回記事を書くときにも試作時点の状態にパッと戻せたり、草生やして満足感が得られました。あとherokuと連携してデプロイもできます。

    f:id:bonhito:20161125004027p:plain

  • todoリスト的なものにカンバンアプリ(Wekan — open-source kanban)を使ったこと

    一人だと効果は薄いですが、インターンで教えてもらったので見える化はせっせとやっていました。

特に悪かったところ

  • テストを書いてない

    勉強します…。

  • 著作権、素材の商用利用などをちゃんと確認していない

    わりと論外。今回は見落としがあったがいつも確認する癖をつける。曖昧な部分はある程度調べ、具体的な根拠を持って(すくなくとも個人的に)理解・解釈をする。

  • railsのデフォルトのsqliteをdbとして使っていたらデプロイでコケた

    はじめてのデプロイでデータのmysql移行とかその他config関係の設定とかで時間かかってしまいました。デプロイまで見据えた方がよい(?)

  • サービス(アイデア)は考えた時点で文書化するべき

    サービス開発している途中で、「あれ、もしかしてこれってGoogle Mapのマイマップで良くないか」とか「Google Places API使えば一発じゃないのか」とか思いついてアイデンティティが揺らぎかけた。どの当たりに差別化のポイントがあるのか整理し、文書でまとめつつ、関係する技術要素は最初に徹底的に調べるべきでした。

今後のTODO

  • 宣伝と集客

    せっかく作ったのでチャレンジする。

  • スマホ(モバイル)ページを改良する

    画面狭いと本当に難しい。モバイルファーストを最初から実践したかった。

  • 取扱いショップを増やす

    ウィメンズのショップをもっと増やしたい。あと、中には公式サイトの店舗検索がjsで動くようになっているところがあるので、seleniumを用いたjs対応のスクレイピングも挑戦したい。

  • 適当な頻度で最新の店舗情報を取得するクローラを作る

    Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

    Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

  • セレクトショップのサブブランドに対応する

    現在もいくつか対応していますが…。このあたりは難しいところです。

  • 店舗に関して提供する情報をもっとリッチに

    今のままだとGoogle Mapで単体検索した場合に比べ、提供する情報が貧相です。例えばショップのブログのurlだとか、取扱がメンズ/ウィメンズのみの店舗があったりするのでその旨をに表示するとか…。ファッションサイトに特化したなりの情報が出せると良いです。気が遠くなります。

  • 同位置のデパートのプロットを工夫する

    開発でかなりはまった要素として、同じデパートに入っている複数のショップは位置情報が全く同一で、プロットすると毎回上書きされて最後にプロットしたものしか見えなくなるというものがありました。現在はマーカーをプロットする時にすでにそこにマーカーがあれば一定幅位置を横にずらすようにしているのですが、これだと不正確な位置になってしまいます。正確かつわかりやすく表現する方法を模索したいです。

さいごに

railsに対する知識はあまり増えなかったのですが、Web開発の基本的な流れが確認できた。開発はとても楽しかった。またコードを継続的に書く習慣ができたので、これからも継続していきたい。

amzn.asia

ロゴの利用について少し調べて学んだこと

はじめに

今作っているちんけなwebサービスがほとんど出来上がって久しいきたのですが、よし公開するかと思った矢先、「サービスにメーカーのロゴが使われているってまずいのではないか」という疑問が湧き、何故今まで気づかなかったのかと愕然としました。

情報系の学部に通っていると知的財産権に関わる授業を受けますが、そういう系の授業は大体「睡眠薬がまかれたのではないか」という有様なので、内容についてはあまり記憶がないです笑。ただ、授業のおかげでそういうセンサーが少しでも芽生えたかもしれないことは良いことだと思います。

とにかく、いくらミニマムなサービスだとしても作り手としては留意すべき点だし、今後にも役立つだろうと思い少しだけ調べたので、簡単にまとめようと思います。

ロゴに関わる権利とは

私は最初、著作権が問題になるのではないかと思いました。ところが、調べてみるとどうやら商標法なるものが問題となるようでした。商標法とは、名の通り商標登録されたものを保護するための法であり、まさにロゴのことでした。

そもそも、商標法より先に例えばマクドナルドのページの利用規約などを見てみると、

5 . 知的財産権について

当サービスのすべてのコンテンツ(著作物、肖像、キャラクター、その他の一切の情報)は、当社もしくは、その委託先等が著作権等の知的財産権、使用権、その他の権利を有しています。著作権法で認められている範囲を超えての使用はお控え下さい。

6 . 禁止事項

当サービスのご利用にあたり、利用者は以下の行為を行わないものとします。違反した場合には、当サービスの利用を予告なくお断りさせていただく場合がありますので、あらかじめご了承下さい。

(中略)

(2) 特許権実用新案権、商標権、意匠権著作権著作隣接権、肖像権、トレードシークレット、プライバシー、その他他者の権利、財産を侵害する行為、または侵害するおそれのある行為。

というような記載があります。これらはどのサイトでも必ずある記載で、「ア、オワタな」と一瞬思ったのですが、もう少し調べることにしました。

商標としての使用であるか否かが重要

調べ続けるうちに、弁護士・弁理士の方にアドバイスをもらえるQ&Aサイトのページがいくつかヒットしました。眺めていると「ロゴの使用が『商標としての使用』に該当しなければ問題ない」というような書き込みを発見。

詳しく調べると、「自他商品識別機能、出所表示機能等を有するような使用の仕方でなければその商標権を侵害しているとはいえない」ということがわかりました。

これを私の理解でざっくりいうと、商標法の侵害に当たるのは「他者が登録した商標を用いて、自分のサービス(商品)に付し、商標(めじるし)として使うこと」だと言えます。よって、ロゴを用いてサービスを作ったとしても、それが明らかにそのメーカーについて言及した記述や説明に過ぎないという場合は問題にならないということです。良かった…。

ロゴの著作権は?

とりあえず、明らかに商標法に抵触していることはなさそうだということがわかりましたが、それでは著作権はどうなのかと思ったのでこれも調べました。調べるとすぐにこんな記事が。

www.nikkeibp.co.jp

これによると、

著作権は、「感情または思想を創作的に表現したもの」で「文芸・学術・美術・音楽」に発生する権利で、著作物を創作した時点で著作者に自動的に発生するとされています。

(中略)

次に、商標について考えてみます。商標とは、シンボルマーク、ロゴタイプロゴマーク、キャラクター、特徴的な商品のデザイン、看板など、企業の商品やサービスを他社と区別するためのもので、「企業の業務上の信用」を視覚化したものだととらえられています。商標法により、商標権の保護対象となるもので、商標権が登録され設定されている期間、専有的にこれを使用することができます。

「商標」には種類があり、扱いが異なります。アルファベットなどの文字で構成されるロゴタイプロゴマークは、基本的に著作権は認められていません(「Asahiロゴマーク事件」)。ただし、商標のうち「シンボルマーク」にはその美的表現の程度により著作権が発生する場合があり、「キャラクター」には著作権が発生するとされています。熊本県のキャラクター「くまモン」は、著作権を買い上げた県が著作権使用料を無料にしたことで、さまざまな商品に展開されました(使用には県の許可が必要です)。

と書かれており、基本的には商標は著作権では保護できないため気にする必要はないようです。ただ、ロゴにキャラクターが載っている場合は注意が必要みたいですね。そんなに多いケースではないと思うのでひとまず安心です。

さいごに

商標について気になったので調べてみました。結果、ちゃんと商標法の条文を読んだわけではありませんが「どうやら問題なさそうだ」ぐらいはわかりました。

また、もし近い将来一エンジニアとして会社に勤めることになれば、真摯に取り組まなければならないテーマだということも感じました。これからも個人的に何かを作るときには、想像力を働かせて、少しでもその場で調べる癖を習慣にしていければと思いましたまる

参考

find | xargs grep を知る

はじめに

今回は頻繁につかうのに理解していないスクリプトがあるのでそれについて簡単に書こうと思います。そのスクリプトがコレです。

find . -name "*.py" -print0 | xargs -0 grep -i "pync"

どんなことをするスクリプトかご存知ですか?

これはカレントディレクトリ以下にあるファイル*.pyの中からpyncという単語を含むものをリストアップするワンライナーです。すなわちこういうことです。

find . -name "<検索対象のファイルネーム>" -print0 | xargs -0 grep -i "<探したい単語>"

前から何度か使っていたものの、たまにしか使わないしすぐ忘れるだろうということで、すぐにシェルスクリプトファイルで保存し「ブラックボックス化」していました。最近になって特に多用するようになってきたのでちゃんと理解しようと思います。

解読

まず、パイプの左側のfindの部分について。

find . -name "<検索対象のファイルネーム>" -print0

言わずもがなfind .でカレントディレクトリ以下の全てのディレクトリ・ファイルを列挙します。よくファイルを探す時に使いますね。

そして -name "*.<拡張子>"とすることで検索対象のファイルを限定します。ファイルをたくさん持つディレクトリを検索するのであれば時間を短縮できます。加えてこれを使わずに実行すると、サブディレクトリもリストアップされてしまい、パイプ以降に渡されるとエラーを起こします。結果が見づらくなるのでそれを防止する効果もありますね。

最後に-print0ですがこれは全く使ったことのないオプションだったのでmanで見てみると、

-print0
 This primary always evaluates to true. It prints the pathname of the current file to standard output, followed by an ASCII NUL character (character code 0).

とあります。簡単に訳すと「この引数は常に真と評価されます。ファイルのパスをASCIIのnull文字(0)を付けて標準出力に出力します。」という感じでしょうか。

f:id:bonhito:20161026000730p:plain

実際に↑のようなディレクトリで-print0を付けた場合とそうでない場合を比べてみます。

実行結果
-print0なし f:id:bonhito:20161026000830p:plain
-print0あり f:id:bonhito:20161026000836p:plain

-print0してもただつながってるようにしかみえませんが、hexdumpすると確認できます。

実行結果
-print0なし f:id:bonhito:20161026103848p:plain:w500
-print0あり f:id:bonhito:20161026103849p:plain:w500

そして後半のxargs以降。

xargs -0 grep -i "<探したい単語>"

xargsはこれも言わずもがなリダイレクトされた標準出力を次のコマンドの引数として渡すコマンドです。今回は次のgrepに渡します。ただ-0はなんだろうということでmanを見ると

-0      Change xargs to expect NUL (``\0'') characters as separators, instead of spaces and newlines.  This is expected to be used in concert with the -print0 function in find(1).

なるほど、find-print0とペアなのだとわかります。これは高速化のためでしょうか。調べてみると全く違いました。実際使うとうまくいかないので気づくのですが、xargsスペースまたは改行で区切って順にgrepの引数に渡してしまうので空白を含むファイルでNo such file or directoryのエラーがでてしまいます。

kaworu.jpn.org

最後にgrep -iですが、同様にmanを見ると

-i, --ignore-case
             Perform case insensitive matching.  By default, grep is case sensitive.

case insentive matchingとは大文字小文字を無視するということですね。

まとめ

当たり前ですが特別トリッキーなことはしていないので理解できて良かったです。大筋の流れとしてfindで列挙したファイル内の文字列に対してgrepを実行するのだなというのもより強くインプットできました。また、最後にgrepを実行するので最初に述べたようにディレクトリが渡されるのはまずいというわけですね。

ただそれでも毎回打つのはやはり面倒くさいので、結局

# find word
alias findword='find . -type f -print0 | xargs -0 grep -i $1'

と.zshrcに追記。実際のケースでは比較的小さな作業用ディレクトリを検索することが多いので-nameで限定はせずに-type fでファイルのみを全て出力させています。

めでたしめでたし👏🏼 。かなりざっくり書いたので間違いや表現に問題があれば気軽にコメントいただけると嬉しいです。

英語のお勉強メモ

単語 意味
evaluate to "expression A evaluates to value B" なら、「式 A は値 B として評価される」という意味。
followed by "HAPPEN AFTER" : to happen or do something after something else