2017年1月7日土曜日

2017年の抱負

ここ数年、書いていると思うので、今年も書いてみようと思う。


ふりかえり

去年の抱負は、

  • Rust習得
  • 英語力アップ
  • Emberの使い方を忘れない程度に活用する
だった。すっかり忘れていたけど。

Rustについてはあまりできていないけど、meet upや勉強会には何回か参加した。去年でだいぶRustを始めやすい環境が整ってきたし、国内でも使っている企業がちらほら出てきているので、今年は去年以上に普及していくんじゃないかと思う。アドベントカレンダーも2つ埋まるほどだったし、どんどん勢い付いてると思う。


英語力アップについては、転職して主に欧米諸国出身のエンジニアとペアプログラミングしていた。きちんと家で復習とかよかったんだけど、そういうはせず、ただ毎日テキトーに会話してたと思う。多少は上がったと信じたい。

一つ気がついたのは、字幕(英語含む)がない状況で、相手が何をいっているのか理解しないといけない時に、理解できていないと認識することが多かったこと。映画を字幕なしで見るのは無理だけど、それと似たような感じで、相手によってはリスニングテストのようにハキハキとは喋らない。生の英語、言葉とはそういうものだと思った。しかしそれは一方的にそうでない場合も多いので、わからない時はきちんと聞くという仕事の基本は忘れちゃいけないと思った。


Emberについては、転職してからほぼRailsエンジニアとして働いていたので、それほど触る機会はなかった。むしろ古い仕様も含めていろいろ忘れたと思うので、再出発しやすいんじゃないかと思う。


目標(1) 年収維持

いきなり金の話かよって感じだけど、今年からフリーランスになった。社員でいるのに比べれば、不安定になるので、とりあえず年収は落とさないよう、今の生活レベルを維持しつつ、頑張っていきたいというのは1年目の目標。ずっとフリーランスでいようとか、会社化しようとかは考えていなくて、エンジニアとして生きて行く中で、フリーランスという選択肢もありだと思ってなってみた。フリーである以上、自分次第でどうにでもなるという、仕事や生活において自由と責任の割合がさらに占めるようになったので、自己管理等怠らないようにしたい。ありがたいことに、この契約が破棄されない限りは今年一年は大きな出費が頻発しない限りは生きていけるというお仕事をいただいているので、残りの時間使い方も有意義にしたい。


目標(2)サービスのリリース

勉強、趣味、セルフブランディング?がてら、作ってみたいサービスがあるので、ものすごくスローペースで進めている。でも今年から自分の割り振りしだいで、さらに時間を割けるようになったので、今年前半、遅くても春にはプライベートアルファくらいにはしたい。年内にはリリースして、収益化もできたらいいなとか思うけど、それはそれで継続していくことが大事になっていくので、まずはサービスを作ってリリースするというプロセスを自分一人で体験し、そこで得たノウハウを他でもいかしていきたい。


目標(3)コミット

フリーランスとして、しばらくは複数の会社と契約し仕事させていただくことにはなるので、いただく報酬の分きちんとコミットしたい。商売上手ではないと思うので、まずは一つ一つきちんとこなして、信頼と次の依頼を勝ち取れるようにしていきたい。商売上手になることも目標ではあるし、エンジニア以外の面でも成長していきたい。


おまけ

毎年ブログを書こうと思ってはいるんだけど全然書かない。でも今年はだいぶ前に取ったMediumのアカウントがあるので、そちらで技術的なメモ代わりのものを書いていこうと思ってる。英語用のアカウントも作ろうかな...

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