2016年5月22日日曜日

SPAで作る理由

ちょっと前に友人と飲んでた時に、SPAで作る理由について話していたので、軽くまとめとこうと思う。

まずその前に、友人と自分についてだけど。友人は普通のWebサイト、ページを動的にサーバ側で生成し、頻繁に更新されないからキャッシュしとくと良いくらいのものを保守開発している。対して自分はAPIがあってそれをブラウザから操作できるようSPAをここ数年ずっと開発。といった感じで、認識のギャップ、「SPAの必要性がよく分からん」と「SPAが当たり前だろ!」というのがあった。


 

APIファースト / マルチデバイス?クライアント?

そもそもSPAの前提としてAPIがある。そしてAPIが必要な理由は、モバイルやCLI、各プログラミング言語向けのライブラリの開発など、プログラマブルWebという言葉があったと思うけど、結局プログラムで操作できる方が良い、もしくはその手段を提供しておかないとまずいケースがあることだと思う。

APIもWebアプリも必要な案件をRailsで考えると、通常のWebアプリを作りつつ、/apiディレクトリを掘って、/api以下はJSONだけを返すように開発することもできる。けれど、できればそれは分割したい。というのは、API はAPIに注力して、アプリはそのAPIを元に開発した方が、API自体のドッグフーディングもできるから。そういった理由から、自分はほんの一部だけAPIが必要なケースを除いて、APIありきなものは、APIファースト、プログラマブルであるべきと考えて、ブラウザはその真正面にいるのではなく、多数あるクライアントのプラットフォームの1つだと捉えている。ネイティブアプリも同じAPIを元に開発すると考えると、うまく分離してるように見えると思う。


SPAのメリット

APIがあることが前提で、APIのクライアントはネイティブアプリなどいろいろあり、ブラウザはその中の1つで、それをSPAで実装するのは、理解できると思う。それでもブラウザ向けの実装は、通常のWebアプリでもいいし、必ずしもSPAである必要もないのもまた事実。ではなぜSPAを選択のかを考えてみると、簡単にまとめて、これらのメリットがあるから、もしはある場合にだけ選んでるからかも。


  • 静的ファイルを返すだけで良い(あとはブラウザが頑張る)
  • 作り方を間違わなければ、初期描画と再描画が速いことが多い
  • ユーザから見て視覚的レスポンスが速いとUX的に吉
  • ページ遷移毎に無駄なHTTP通信が発生しないので、サーバもクライアントもwin/win
  • 通常のWebアプリでは、ページ遷移中にJavaScriptで制御できるものにはかなりの制限がある。ユーザの操作も次のページが描画されるまで受付けられない。SPAにはそういった制約がない。これもUX的に吉な機能を実装しやすい。

SPAでなくても、レスポンスが速ければ、最近のブラウザは描画スピードが驚異的だから、あまり差はないかもしれないし、コンテンツによってはクライアント側で全部描画するより、サーバ側で描画して、それを大多数のクライアントが参照する方が、世界的に電力消費量が減ってエコかもしれない、といったそういったのもあると思うので、いろいろと加味した上で、どういう構成にするのかは決めればいいと思う。サーバにかからなくなった負担がクライアント側に来るわけで、それが良いか悪いかはケースバイケースだし。


まとめ


ずっとSPAをやってきていたので、当たり前の感覚になっていて、それを急に言葉で説明するというのは難しいなと思ったので、今回頑張って言語化してみた。お互い違う前提で話をしてる間は話がかみ合わないってことがあるよね。

2016年5月10日火曜日

続・Rustを習得したい

前回の、Rustを習得したいから、だいぶ時間も経ったのと、「rust 用途」で検索すると、その記事が検索で上位に来てたらしく、ちょっと付け足したいことがあるので書いてみようと思う。


Rust1.0リリース前から現状(2016/05)の環境変化


まずは、日本語でも情報が追いやすくなった。



英語も情報は追いやすい。This week in Rustを筆頭に、This week in Rust Docsなど、週ごとにまとめがでてくる感じ。他にも@rustlangをフォローしたり、Redditやinternalsあたりを見とけばだいたいの情報が入ってくる。Rustのコミュニティは情報共有に意欲的で良いと思う。


開発環境のセットアップの簡単さとクロスコンパイル


Rustは6週間毎に最新の安定版がリリースされる。いろいろ省くけど、とにかく最新バージョンを使ったり、nightlyやbetaを落として使いたい場合に、multirustがあれば簡単に実現できる。rbenvやndenvなどを知っていれば、それのRust版という捉え方で大丈夫だと思う。

ただ、multirustはシェルスクリプトで書かれていて、Windowsではきちんと動作しないらしい。なので、Windowsサポートもターゲットに、rustupに移行予定。(この投稿で作者がThe future of multirust is rustup.rsと書いている。)


クロスコンパイルについては、公式ブログのRust in 2016で書かれていたように、コンパイル済みのlibstdをダウンロードできるようになってきていた気がする。この辺はまだちゃんと追ってないけど、本当に `cargo build --target=foo` だけでコンパイルできるようになればGo並みに楽だなーと期待している。そういえば、rust everywhereというのもあるのでリンクだけ貼っておく。


Ruby/Node.jsの拡張

そもそもRustをやろうとしたきっかけが、RubyのC拡張を書く時に、「C怖い」から始まっていて、同じような人がいたんだけど、それがたまたまYehuda Katzで、あれよあれよとRustで書いて実際にプロダクション(skylight)で使っちゃうし、コアメンバーにもなっちゃうし、そして時々イベントで発表するので情報が入るという状況だった。それとsteveklabnikもコアメンバーになって、今はもうやめたけどRust for Rubyistを書いたり、ドキュメント周りの整備からTRPLを執筆したり、イベントに登壇して発表したりして、追ってるだけで情報が入ってくる。Rubyistだから共感する部分もあるからかもしれないけど、彼の説明はわかりやすいと思う。

いきなり話が逸れたので戻すと、skylightを開発運営しているTildeはTurboRubyというのを試験的に作っていたけど、最近rustbridgeというGithub orgができて、helixという名前に変わった模様。nodeのもrustbridgeに入ったみたい。


他にも、ruby-sysRurumrustyというのがあるので、将来的にずっと開発されるものかどうかは知らないけど、とりあえずリンクだけ貼る。


そろそろ試さないとなー...でも必要に迫られる機会がないのよねぇ、今のところ、、、


Web

Are we web yet?を見れば、RustでWeb開発する場合にどういうツールやライブラリがあるかざっと知ることができる。が、RustはWeb開発用の言語というより、システムプログラミング言語なので、プロジェクトにあった選択をしたほうが良いし、Web開発用に豊富にライブラリがあるわけではないのが現状だと思う。サイドプロジェクトでちょろっと遊びたいよね。


その他


Rustはシステムプログラミング言語にしてRubyやJavaScriptのようにも書ける(全部ではない)素晴らしい言語で、比較的新しい言語に見られるパラダイムや独自のパラダイムがあり、それを知ることで他の言語のことも理解できたりして、勉強してみるのも良いと思う。全くのプログラミング初心者にはおすすめはしないけど、例えばSwiftのOptionalとか、Rustを知っていれば理解が早いといったところ。TypeScriptだってフィーリングで理解できる気がする。(乱暴)

それとまだプレゼンは英語が多いので、英語の勉強にもいいんじゃないかと思うので、自分が見た動画をいくつか紹介して今回は終わりたいと思います。



動画はまだ他にもあるけど、長いしいいかなと思って省いた。また何か情報があれば書こうと思う。

2016年1月9日土曜日

AppVeyorでgo buildしたものをデプロイする方法

artifactsまわりでハマったのでメモ

appveyor.yml

ssh/scp/sftpでアップする例


version: 1.0.{build}
os: Windows Server 2012 R2
clone_folder: c:\gopath\src\github.com\dopin\hoge
environment:
  GOPATH: C:\gopath
  GO15VENDOREXPERIMENT: 1
install:
  - set PATH=C:\gopath\bin;C:\msys64\mingw64\bin;%PATH%
  - go get github.com/kr/godep
  - godep restore
build_script:
  - cmd: go build -o hoge.exe cmd\hoge\main.go
after_build:
  - cmd: 7z a hoge.zip hoge.exe
test_script:
  - cmd: godep go test -v
deploy:
  provider: FTP
  protocol: sftp
  host: devml.blogspot.jp
  username: user
  folder: appveyor # /home/user/appveyor にアップロードされる
  password:
    secure: # https://ci.appveyor.com/tools/encrypt で生成
artifacts:
  - path: hoge.zip
    name: hoge

artifactsを指定しないと何も生成したことにならない

deployのartifactで頑張って指定してたけど、Neither artifacts nor application were uploaded.
と言われて全然できなかった。

正解はartifactsで指定。deployの方はartifactを省略すれば、artifactsで指定したものすべてが対象になるので、最終的に削除した。

ビルドはクロスコンパイルすることもできるから、そこでAppVeyorを使う意味はもしかするとないのかもしれないけど、テストついでにアップロードまでしてくれる方がいいじゃん!ということで。

crates.ioでreverse dependenciesを見る方法

そのcrateがどのcrateで使われているか

それがreverse dependency。何が嬉しいのかというと、そのcrateの実例サンプルコード一覧として参照できるということ。ドキュメントよりもサンプルコードで学ぶ質なので、すごくありがたい。


/reverse_depedenciesを付けるだけ

もしかするとどこか画面上にリンクがあるかもしれないけど、URLに直接入力すればOK

https://crates.io/crates/docopt/

の場合、

https://crates.io/crates/docopt/reverse_dependencies


助かる。助かる。

2016年1月2日土曜日

CircleCIでruby 2.3.0を使う方法

注意事項

この情報は2016年1月2日現在の情報です。CircleCIが環境を更新すれば情報が古くなっている可能性が高いです。


circle.ymlに普通に書いてもダメな場合の対処方法


rubyのバージョンを指定してもうまく指定できない時は、machineの項目にpreを追加して、rvmで明示的にrvm use 2.3.0を書きます。これによって、ruby-2.3.0がインストールされていない場合は、rvmがインストールしてくれます。

machine:
  pre:
    - rvm use 2.3.0
  ruby:
    version: ruby-2.3.0

いずれはpreの部分は不要になると思います。それまではこのワークアラウンドで。

ボッチオペレータを使いましょう! &.

ネーミングと英語で困った時に頼りにしているもの

コードは英語で書いていますか?

普段からコードは英語で書いている。変数名などを日本語ローマ字で書いたりはしないし、なるべく複数形単数形の使い分けも、それが自然であればやる。とはいってもネイティブじゃないし、たとえ日本語であってもネーミングは難しい。できればうまい人に任せたい。でも現実はそうはいかない。それがましてや英語でとなると、さらに難しくなる。というか基本的に生活にないものを取り入れるのは難しい。。


請求先という日本語英語変換の例


例えば今、ユーザやユーザのグループがあって、それがそれぞれ請求先情報を持てるとして、請求先を英語にするにはどうするかで悩んでいる。billing information、billing address、payment informationなどがあると思う。billing informationだと曖昧で、billing addressだと限定的すぎる気もして、さぁどうしようというところ。こういう時に頭のいいネイティブスピーカーがいると相談できるんだけど...


英語に困ったらcodic


英語が苦手なプログラマー向けにcodicというのがある、みたい。これをメモしたいがためにこの記事を書いているようなものだけど、実はまだ全然つかったことがない。これからお世話になるかも。


さっそく「請求先」で調べたら「request destination」と出た。よくわからないけど、そんな言い方するの?と疑問に思ったので今回はあてにしない方がいいかも。


とはいえ、codicはメソッド名や関数名に使うのは向いていると思う。動詞で始めるのが普通だけど、それがわからない人でもそれなりに良い名前に出会えるんじゃないかと思う。


辞書


Weblioとか英辞郎あたりも参考にするし、Googleで「請求先 英語」と調べもする。やっぱりbilling addressなどが出てくる。


オープンソース


ネーミングに限らず困った時はいつもオープンソースを頼りにしている。お金関係で目にしたことのあるものってあったっけ?と考えたら1つあった。balancedのコントロールパネルらしきものがOSSになっている。それがEmberで作られているので、モデルのディレクトリをざっと眺めてみる。が、ちょっと今回の件にピッタリまっちするものはなさそう。


そういえば、EC-Cubeもあった。ソースコードを見るのは初めてな気がするけど、この辺かな?Entity


DB設計例


他に参考にできるものあるかなーと思ったら、そういえばこんなサイトがあるのを思い出した。



どちらもDB設計の例を集めたサイト。ドンピシャなものは探せなかったけど、英語で困った時は参考になると思う。

余談だけど、SQLで困った時は、SQL Fiddleを使ってやり取りすると効率がいいかも。


終わりに


さて、結局billing addressに落ち着くかなぁ。。。ちょっと凝ったことをやるから、addressだと合わないかもしれない。まぁプロトタイプだし、進めてみて間違ってるかどうか確認するのもありかな。。うーんwww


2016年1月1日金曜日

2016年の抱負

やばい思い浮かばない

毎年そういうの書いてた気がして書こうと思い久しぶりにbloggerの投稿ボタンを押した。が、いいけど、今年の抱負が特に思い浮かばない。。。


継続

何か毎年新しいことに挑戦したい気持ちはあるけど、特に思い浮かばないので、まずは継続とかやり残したことを今年も引き続きやっていこうと思う。

  • Rust習得
  • 英語力アップ
  • Emberの使い方を忘れない程度に活用する
こんなところかな。


Rust


Rustについては、まだLifetimeのことをがいまいちよく分かってない。けど、やっぱり追っていて面白い。開発体制でいうと、 ビルドボットのHomu(まどマギのキャラ由来)とか、highfiveを使った自動化。仕様の策定にRUST RFCsでやり取りしている。これらを見ていて、自分の仕事にも流用できそうなので良い意味でパクっていきたい。

実用的かどうかは置いといて、RustでOSを作っている人もいれば(Redox)、intermezzOSというシステムプログラミング言語のコンセプトを教えるために取り組み始めた人たちもいるみたい。底レイヤーを知っておくことは強みになるし、intermezzOSには期待している。

Rubyの中にRustを埋め込んで高速化しちゃうTurboRubyにも期待している。


英語力アップ

TOEICを受ける機会があって755点は取れたけど、もっと海外のイベントとかの動画を理解できるようになりたいし、ミートアップで海外のエンジニアや国内在住で日本語より英語の方が話せる人と英語で話せるようになりたい。海外ドラマや映画も字幕なしくらいでいけるようになりたい。普段使わない単語とか単語帳を頑張っては覚えられないけど、betrayとかaccomplishとか、映画で覚えた単語もあるし、自分にはそういう学習方法が向いてるんだと思う。使うシチュエーションとストーリーとがリアルじゃないと覚えられない。英語に限らずそうだけど。最近は塊で覚える、捉えるようにしてる。


Ember


Emberは個人的に二周してるところがあって、古い仕様を忘れることと、新しい仕様に追いつくことを今後も継続しつつ、よくある初心者がはまるポイントみたいなのは、難なくこなして経験者として役に立てるくらいのレベルには達したい。


新規


書いてるうちに思いついたというか思い出したので書こう


WAI-ARIA


障害者差別禁止(解消)法が出て、民間企業は義務はなくても努力しようということだったと思うのと、2014年末くらいに買ったBootstrapベースのテーマがWAI-ARIAに対応していたのと、Bootstrap本体も4から、その他のフレームワークも対応しだしたので、きちんと扱えるようになりたい。

例えばタブとか、突然現れたり消えたりするものを、WAI-ARIAを使わずに作ってしまうと、パソコンになれた視覚障害者の人でもとても使いにくいものになってしまう。(その現れたタブとかを操作するためにtabキーを何回押してたどり着くのか、消したあと元いたところにカーソルが当たっているかとか考えると分かる。)GoogleドライブがWAI-ARIAに対応して比較的使えるようになったという声も聞いたので、2016年にこの動きの波及の妨げにならないよう、Webアプリをメインで開発している開発者として、最低限の知識を得ておこうと思ったし、必要なところでは使える準備はしておきたい。最近はWAI-ARIAのことがきちんとまとまった書籍等も日本語で読めるみたい。手に入れて良かったらこのブログでも紹介するかも。


その他


そういえば、去年からGoも触ってはいるけど、いまいち好きじゃない。けど、やっぱり便利な面もあるので、好き嫌いを乗り越えて、使えるようになりたい。

それとプロトタイピングツールがどんどん出てきているので、ある程度自分でデザインもできるようになりたい。


今年の目標はそんなところかな。