ボクココ

熱海で開発するブログ

WiMAXかLTEかひかり回線かの選択

スマホ代が高い」これはあらゆる人にとって共通の悩みかと思う。月々7000-8000円かかるような方も見受けられる。これをどうすれば安く利用できるのか。そこが今回のテーマだ。

家のひかり回線 + LTE

これが最もよくあるパターンで手軽な分、お金がかかるケース。確かに家のひかり回線を引いけば家にいる誰もがそれを使ってネットを使うことができるし、それぞれLTEでパケット使い放題にしていればそれぞれのスマホでネット通信ができる。

LTEテザリング

テザリングというLTE回線を使ってPCやタブレットに接続するサービスがある。これを使えば家のひかり回線をつながなくても、それぞれが持つスマホのみで各自がネットを楽しむことができる。

ただこれには一つ問題がある。それが「通信制限」だ。テザリングの通信は制限がかかっていて、これが動画とか見てるとすぐに到達してしまうくらいの低い制限であるのが問題。気安く見たい動画が見れないというのはほとんどの人にとって痛いことではないだろうか。

WiMAXスマホ従量課金

WiMAXを使えばスマホLTEを使う必要がなくなるので、スマホ代は月3000円程度に抑えることができる。それに加えてWiMAXの料金を支払うことになるが、これはLTEテザリングとは違い制限なしで接続できる。これが最大のメリットだ。

そのため一人暮らしの方はWiMAXを使うべき。家族間でしょっちゅうネットを使う人だけWiMAXを持たせるみたいなことで節約することも可能だ。

WiMAXはサポートで選ぶ

WiMAXスマホ同様、多種多様なキャンペーンで各社が競い合っている。では何で選ぶべきかというと「サポート」だと思っている。

例えば解約時期など、小さい文字位でちらっと書いてあって大変重要なことはWebだとわかりにくいが、口頭で話せばサポートの方が重点的に説明してくれる。これを気にしないでいると解約したい時に違約金で1万円以上の料金を支払わないといけなくなってしまう。

他にもキャンペーンと言ってキャッシュバックがあったとき、銀行口座の登録依頼のメールが10ヶ月以上先に登録したメールアドレスに送ってくる場合もある。これら全てサポートに電話すればちゃんと説明してくれる。

おすすめ WiMAX

サポートでの一番のオススメは NiftyWiMAXだ。料金もお手頃ながら、電話サポートで会員登録からWiMAX申し込みまでやってくれる。これは大変ありがたい。私自身もサポートの良さでNiftyを使い続けている。他のWiMAXサービスに比べてシンプルな印象を受ける。もちろん電話だけして申し込みは自分でしっかりやることも可能だ。


料金で選ぶならGMO。キャンペーンの割引額がかなり高くて基本料も安い。ただキャンペーンは10ヶ月後とかそこらに登録したメールアドレスから口座登録しないといけない。 忘れると振り込みされないといったことがあるので、しっかりとスケジュールに登録しておこう。


また今後に注目したいのが Yahoo!モバイルルーター。この業界は特に変化が激しいので、前良かったのが一転して他に良いサービスができたりする。比較はしっかりしないといけない。

プログラマでもオススメ! Prose で Jekyll の記事を管理する

Jekyll は "Transform your plain text into static websites and blogs."(単なるテキストを静的ウェブサイトやブログに変換するもの)。Jekyll の詳細は以前の記事を参照。

bit.ly

さて、Jekyllでセットアップが完了し、実際にブログなどを運営していこうと思うと以下のような課題に直面するだろう。

画像アップロードが面倒

画像アップロードに関しては構築した自分ですら面倒なので、他人にそれをやらせるのは気がひける。

ローカルで作っているなら、imagesディレクトリかなんかに画像を放り込んで、そのパスを記事内に書くことになるだろう。

Github Web上で編集するならGithub Issue でIssueを作ってそこに画像をドラッグアンドドロップしたのち、その画像 URLコピーをして貼り付けといった流れになるだろう。

こんなんではWordPressの方がいいと言われるに決まっている。

他の記事書く人がGithubに慣れていない

Jekyll は Github Pages の元で動くため、実際に運用で他の人に記事を書かせるときにGithubのUIに慣れてもらわなければならない。英語オンリーでブランチやコミットなどよくわからない単語の羅列を無視しつつ、記事を書いてもらう必要がある。初見だと気が引けてしまうだろう。

Jekyll のメタデータの書き方など、それも手取り足取り教えないとブログ記事を公開することができない。

Prose で解決!

f:id:cevid_cpp:20150326133555p:plain

Prose という Github をクライアントサイドで操れるOSSがある。裏でGithub API を叩きまくっている作りだ。

f:id:cevid_cpp:20150326133408p:plain

Proseを使えば、画像は記事編集のテキストエリアにドラッグアンドドロップするだけでアップロードできる!アップロード先はそのリポジトリ内の画像ディレクトリ内に自動でコミットされる。

さらにJekyllでわかりにくいメタデータもHTMLフォームとしてカスタマイズすることが可能なので、Jekyllを全く知らない人がJekyllでブログを運用していくことが可能だ。 Prose.io を使わせるってのは一つの手だけども、これだと英語しか使えない問題があるので、日本語訳をここに載せておく。

ja.json

ただ、これでもデフォルトは英語のままなので、デフォルトを英語にするにはコードをいじる必要がある。これはgrep検索して置換していくしかない。Prose.io は Backbone.js で書かれていて、ビルドにはGulpを用いている。このProseもForkしてGithub Pages で自分で公開すれば、カスタマイズしたProse.ioを外に出すことができる。その手順は以下が参考になる。

prose/CONTRIBUTING.md at master · prose/prose · GitHub

注意点: 画像アップロードに関して

proseの設定でmediaを指定しないと画像アップロードに失敗してしまう。これに対応するためには、Jekyll で運用しようとしているブログのGithubリポジトリ_prose.ymlを作成し、以下のように記述する。決してProseの方に_prose.ymlを作らないように注意していただきたい。これでハマった。。

prose:
  media: "assets"
  metadata:
    _posts:
      - name: "layout"
        field:
          element: "hidden"
          value: "blog"
      - name: "published"
        field:
          label: "記事を公開"
          element: "checkbox"
          value: "true"
      - name: "summary"
        field:
          element: "text"
          help: "記事概要"
      - name: "image"
        field:
          element: "text"
          help: "画像URL"
      - name: "link"
        field:
          element: "text"
          help: "外部URL"
      - name: "category"
        field:
          element: "hidden"
          value: "blog"

こんな感じのをプッシュすればいい感じに記事編集ができるようになるだろう。

Prose で 素敵なJekyllライフを。

Effective Ruby を読んで

以前から気になっていた "Effective Ruby" を読んだ。 Effective シリーズは中級〜上級向けプログラマーの読むべき本として親しまれている。

個人的にもっとも得意な言語はRubyだったので、このシリーズが出るのを楽しみにしていた("得意な"と変換しようとしたら"特異な"と変換されるくらいには使用している)。

中身のネタバレはもったいないので、この本を通じて自分が今まで見落としていた点を挙げてみようと思う。

nil 時の対応

array = hoge()
array.split('/')[1] 

NoMethodError: undefined method hoge for nil:NilClassRubyプログラマーなら何度も遭遇するであろうこのエラー。配列でnilっぽくしたい時は空の配列を用意してあげたいところだが、その変数にnilが返ってきてしまうとこの問題に出くわしてしまう。

例えばある変数があって、それに array.split('/')とさせるとしよう。ここでarray変数がnilなのか、そもそも配列なのか、よくわからない。ちゃんとコードを戻って読まないといけない。

この問題を解決する素晴らしい手段が本書には書かれている。一体何でしょう?

なんでもかんでもHash使いたい

@hash = {}

@hash[:hoge] = hoge
@hash[:fuga] = fuga
...

これはまさしく自分だった。Hashを使えばコードを簡潔に書くことができる。特にRailsアプリなどではViewに渡すインスタンス変数をHashに変換し、View側でそのHashを取得するような処理を書くことは多いのではないだろうか。

しかし、Hashはなんでもかんでもキーとして詰め込むことができるため、このキーが一体どの部分で入れられたものなのか、コードを読み直す必要が出てくる。また、存在しないキーが出てきてもnilを返すだけで、例外を投げないため間違っているかどうかの判断がつかない。

ではどうするのがEffectiveなのか。一体何でしょう?

reduce をマスターせよ

本書で唯一 特定のメソッドに対して複数ページを割いて解説しているメソッドがある。それが reduceだ。これをわかりやすいサンプルとともに、ただ合計値を出すだけでない他のreduceの使い方を示してくれている。これにより、今まで無駄に書いていたあの処理が実はreduceで書き換えられるということを理解できるだろう。

終わりに

ある程度Rubyに慣れ親しんだ方なら、 何かしらのGemを入れ、気になった時はそのGemのソースコードを読む機会が何度かあったと思う。基本的にはそこから学ぶことが大変多いのだけども、この本はそれらの知識・ノウハウをよくまとめられているという印象を受けた。

対象としてはパーフェクトRubyとか読んだ後なら普通に読めると思うけど、Effective Ruby の場合はそれなりにRubyコードを実際に書いて運用した経験をした後によむと、「あ、こういう書き方ができるのか!」という発見があって楽しく読めると思う。

Spree 最新版の日本語国際化ファイルを更新した

さて、前回の記事で CMS とかランディングページは Jekyll で作成できるようになった。次はECサイトもパパッと作れるようになっちゃう。

ECサイトOSS

ECサイトを自作するのに、EC-CUBE や Spree を利用することが多いかと思う。

www.ec-cube.net

spreecommerce.com

まぁ日本じゃ圧倒的にEC-CUBEの利用例が多いんだけど、PHPで書かれているってので即刻アウト。日本製ってのも開発具合に疑問を感じる。 Spree ならHerokuで動かせるし、海外のコミュニティによって激しく改良が続けられている。なんとRails で検索した時にGithubスター数でトップ5だ!!

世界的には Spree の方が標準だけど、 日本じゃEC-CUBE製のECサイトばっかだからここで差別化が狙えるんじゃないか。

Spree のインストール

今回は Spree の 3.0-stable バージョンを利用してECサイトの枠組みだけ軽く作ってみた。導入編。

rails new myec

cd myec

gem install spree_cmd

rbenv rehash

spree install -A

echo "gem 'spree_i18n', :github => 'spree/spree_i18n', branch: '3-0-stable'" >> Gemfile

bundle install

bundle exec rails g spree_i18n:install

vim config/application.rb
//  config.i18n.default_locale = :ja

be rails s

# localhost:3000/admin
# id:   spree@example.com
# pass:   spree123

とりあえずこれでなんとか動くんだけど、 admin 入ってすぐ分かるのは、

全てが i18n 対応してねー!

っていうこと。これ自分だけが使っていくならいいけど、今後誰かに運用お願いしたいときとか致命的すぎる。しゃーないから 3時間くらいかけて全部足りない分翻訳しましたよ。。

英語間違っている部分結構あるかと思うので、参考程度で使いたい方は使ってください。翻訳に自信がないので 本家にプルリクエストは送ってないです。

spree/config/locale/ja.yml

今後

Webpay は正式に Spree のサポートする gem を公開してくれているので、これを使ってみたい。

そして最終的には Heroku デプロイし、 SSL を通して独自ドメインで 試験的なECサイトを運営してみようと思う。そこで得られた知見などは適宜ブログに残していこうと思う。

間違いなく Jekyll より難しい。w

2,3 日でマスターできるようなものじゃないのでじっくり腰を据えてやっていこう。

Jekyll と Github Pages で CMS を構築する

http://jekyllrb.com/img/logo-2x.png

Jekyll の特徴

近頃、 Jekyll という静的サイトジェネレータを利用し始めている。言わばWordPressのようなCMSのような使い方が可能だが、それらとは全く違う点が データベースやプログラムを利用しない というところがある。記事とかは全て静的サイトとして作成するのでDBアクセスが発生しない。

これにより圧倒的なサイトアクセスのスピードと、DBを用意しないことによる運用コスト削減が可能だ。また Ruby で機能拡張もできるし、プラグインが豊富に提供されているので気軽に利用することができる。

さらに、Github Pages のサポートがあるので、 Githubレポジトリと記事を丸々プッシュすることで、それだけでブログが出来上がる! もちろんGithub Pages はカスタムドメインも対応しているので、独自ドメインCMSを構築することが可能だ。

記事作成などは自前で管理ページを持つ必要がない。それらは Web の Github 上で編集し、変更を反映すれば記事が動的に追加される。画像アップロードは Github Issue を使えばアップローダーとして利用することが可能だ。記事を書く人はGithubアカウントを作成してもらい、そのリポジトリにコミッターとして招待すればよい。

ここまで書いておいて恐縮だが、私はWordPressを使ったことがない。 PHPという時点でもう拒絶反応を起こす。代替を探していたら素晴らしいものに出会うことがた。そのためWPとの比較などはこのくらいしかできないし、WPの利点をそこまで理解していないことを承知していただきたい。

Jekyll の学習

以下のサイトだけで大枠は理解できる。大変参考になった。

Jekyllいつやるの?ジキやルの?今でしょ!

Jekyll テンプレート集

Jekyll Themes

Jekyll の使い方を学べば、これらテンプレートをたやすく利用することができるだろう。 Github 上で Fork し、 _config.xml を自分のブログ用に書き換えるだけで良い。

Github Pages での問題点

Github Pages では、 https://{account}.github.io/{repository} というURL構成になっている。Jekyll ではデフォルトではルートのindex.htmlがある想定なので、ローカルではうまくパスやURLが通っていても、Github Pages に上げたらパスが通っていないという現象に遭遇する。

そのため、ローカルでも本番でもどちらでも動くように設定を変える必要がある。

_config.yml の設定

_config.yml に baseurl をセットする。

baseurl: "/myblog"

ローカルではmyblogのようなサブディレクトリがなく、ルートで実行するので、以下のように指定する。

jekyll serve --baseurl ''

そして読み込むJavaScriptCSS、リンクなどを以下のように書き直せば良い。

<link rel="stylesheet" type="text/css" href="{{ site.baseurl }}/css/main.css">
<script type="text/javascript" src='{{ site.baseurl }}/js/jquery.min.js'></script>

~~~

<a href='{{ site.baseurl }}{{post.url}}'><h1 class='post-title'>{{post.title}}</h1></a>

Bootstrap テンプレートは使うべきではないと思う

最近のはてぶITカテゴリーにしょっちゅう出てくるデザイナー向けBootstrap テンプレート。ペラ1のサイトのコードとDEMOが付随しているので文言を変えるだけで簡単にクールなwebサイトを作ることができる。例えばこんなまとめサイト

商用も無料!Bootstrapをベースに最近のトレンドを取り入れた新作テンプレートのまとめ | コリス

読んだ人はきっと、「今後作るときはこういうのですぐ作れればいっか!」みたいな感じではてぶ登録するんだろうけど、実際にやってみた身としては逆に効率が悪くなった。なのでこういうのは使うべきではないと思っている。

その唯一の理由。

ちょっと変えるのが大変

最も大きな理由はこれ。自分でCSSを組み立ててないのでどんなCSS設計になっているかを理解するのに時間がかかり、逆に時間が取られるというオチ。 数ページ分くらいなら自分で一から組み立てていったほうが早かったという結論になりやすい。

DEMOページくいらいのCSSを組み立てられないような段階でテンプレートを選ぶようなら、まずはCSSを学び直したほうがいい。

「レスポンシブにデフォルトでなっている」というのはBootstrap テンプレートの一つの魅力だろう。ただ実際レスポンシブにするやり方を学んで見ればわかるけど、レスポンシブなページは思ったより単純で簡単に作ることができる。ただ手間が増えるだけのような感覚で作ることができる。 そのためあらゆる点において、これは1から作ったほうが早いしカスタマイズしやすくなる。

おすすめCSSフレームワーク

CSSフレームワークは積極的に使うべきだと思っている。定型的なCSSの記述は必ずあるもので、それらをまとめてくれているCSSフレームワークの存在は開発効率をあげる手助けになる。

特にレスポンシブ対応のCSSフレームワークは大変便利なので積極的に使いたいところだ。自分の場合はデザイナーありとデザイナーなしとでCSSフレームワークの選定を変えている。

デザイナーあり

Kube Web Framework

Kubeはとてもシンプルで最低限のCSSをまとめたフレームワーク。レスポンシブ対応だし、大変シンプルなCSS構成のためレイアウトを変えやすい。Twitter Bootstrap のボタンやフォームは特徴的で変えるのが割と大変だけど、Kubeならその労力が少なくて済む。

ということでデザイナーありのWebサイト制作の場合はこちらを利用している。

デザイナーなし

Bootflat

こちらはフラットデザインも兼ね揃えたCSSフレームワーク。自分でデザインもやっちゃうときはこっちを使うことが多い。色合いも良い感じだし何も考えなくても小綺麗なサイトを作ることができる。

この場合は機能性を重視し、ある程度型にはまったサイトでもいいと割り切って作ると開発効率がだいぶ上がる。

(おまけ) イベント向け

ハッカソンとかで手軽に凝った感のあるサイトを作りたい場合は以下を使ったこともある。

Material UI - Material Design React Components

カッコイイってのと最先端行ってる感があるのがいい。

$.material() みたいなメソッドを呼ぶだけでいいからお手軽に作ることができる。

Design Sprint Night に参加した

こんなイベントがあって、同僚に誘われたので参加した。

Design Sprint Night! 〜 先駆者たちから聞くDesign Sprint の実際 - connpass

ちょうどこの日、渋谷駅内にある伊東屋って所でペンとノートを新調したので、新しい気分でノートテイキングした。毎回ここで質の良いペンとノートを仕入れるようにしている。

Design Sprint とは

さて実のところ、このDesign Sprint という言葉、このイベントに参加するまで知らなかった。どうやら Google Ventures の方々がサービス開発する上での手法をまとめたものだそうで、Google の至るプロジェクトにも導入され始めているそうだ。今までは割とリーン・スタートアップ(Lean Startup)って言葉が流行りつつあったけど、それをより早くユーザーフィードバックがもらえるような仕組みのようだ。

特徴的な点を以下に記す。

時間制限による創造性

プロジェクトにおいて、もっとも創造性が発揮されるのはプロジェクト期限ギリギリの時、というのはみなさんの共通認識のようだ。そこでこの時間制限による創造性をDesign Sprintには取りれられている。

具体的には、まずDesign Sprintを始める際に5日後にユーザーインタビューをする、というスケジュールを先に入れてしまうそうだ。5人をそれぞれ30分スケジュールを押さえておく。そうするとそこの期限を変えることはできないからそれに向けて全力でアイディアが絞られるようになる。

素早く作って素早く失敗する

量と質、どっちにこだわると最終的にいいものができるか。これを実験したグループがあったようで、どっちがよかったかというと、それは「量」だったそうだ。なぜかというととりあえずたくさん作ってそのたくさん作っていく過程で改善点がどんどん見つかり、それを改良していくことができたから、というのだそう。

Design Sprintもプロトタイプをとにかくたくさん作ってユーザーインタビューに時間を割き、それで改善を続けていこうというプロセスであった。

問題設定

Design Sprint において重要なのは、何の課題を解決するのか、ということだ。その何の課題かの選択には細心の注意で決定されていく必要がある。

問題設定としては以下のような基準がある。

  • 今ある問題
  • 正しい問題
  • 小さすぎず、大きすぎない問題
  • いいフォーカス

問題の種類としてはHEARTと呼ばれる5種類がある。

  • Happiness
  • Engagement
  • Adoption
  • Retention
  • Task-Success

これらのうちの何を解決するのかを明確にしよう。

特徴的な流れ (個への集中)

Design Sprint の特徴として、"個人で考える"ことに重きを置いているようだ。例えばブレストでみんなで考えてみんなで結論を出した時、それは最終的には無難なアイディアでみんなの意見をそれなりに反映した中途半端なものになって、結局誰もあまり満足のいかない結果になってしまったことはないだろうか。

それをDesign Sprint は解決していて、個人が徹底的に考え抜いたアイディアを最終的にみんなで個々のアイディアを評価し、最もいいものを決定していくプロセスになっている。

それはまず課題設定からそうで、課題設定で各個人が考えたものを出し合い、そこで決めた一つを次の課題解決に持っていく。その一つの課題に対する解決方法もそれぞれ個人が考え直して、それをまたみんなで一つで決める。

そうした徹底した個人の考えの中で最もいいものを採択する、という流れにすることがDesign Sprint の特徴だ。たしかにこっちのほうが自由に書けるし理想を追い求められる気がしていいと思った。

所感

サービスとして考えなきゃいけないのは決まっている。それは どのユーザーの何の問題を解決するサービスなのか を徹底して考えることだ。これは一人でもできる。

一人でもそれが思いついてそれが本当に市場のニーズにマッチしていたらうまくいく可能性はある。

ただそれをより確実にするために、みんなで最良のものを選び、そしてユーザーインタビューを通して確信を深めていく。そんな要素がDesign Sprint には含まれている。

Design Sprint を実施すれば一回で思いついたアイディアを短い期間で改良を繰り返す。うまく回せられれば一人の思いつきとは比べ物にならないほどユーザーのニーズを反映したサービスが出来上がることだろう。

そうなるにはやはり訓練が必要だと思う。それに関しては今後 Design Sprint めいたことをやっていくことで、また報告できたら、と思っている。