Into the Horizon

programming, photography, and daily log

株式会社ラブグラフを退職した

株式会社ラブグラフを退職した。

この記事では、入社してから2年間の個人的な振り返りを書き記しておく。 この記事がスタートアップでのエンジニアのキャリアに興味がある人の参考になれば幸いである。また、ラブグラフに興味を持ってもらえれば嬉しい。

DeNAを退職

まずは前職の話から。情報系の大学院を卒業した後、研究を続けるか少し迷いつつも、Web系の自由な雰囲気と優秀な人間に惹かれ、ディー・エヌ・エーに入社した。 入社してからはブラウザのソーシャルゲームの運用エンジニアに配属された。必要に応じて企画や分析をやったりもした。

2年ほど働いた後、エンジニアとしての成長が感じられなくなったため、部署の異動を考え始めた。会社自体は好きだったし良い評価も貰っていたので、転職は考えていなかったが、キャリアについて考えるいい機会と捉え、転職活動の真似事を始めた。その一環で話を聞いた会社の1つがラブグラフで、結局ラブグラフに就職を決めた。

ラブグラフにジョインした理由

f:id:nullnull7:20180831123949j:plain
去年撮影したカップルさんとアシスタントさん

ラブグラフに決めた理由は3つで、「スキルアップ」「写真の世界に携われること」そして「ビジョン」だった。

スキルアップについては、1人で一通りのWebサービス開発を行う経験や、開発以外にも手広く担当するだろうスタートアップの環境に興味があった。 写真については、当時はただの趣味だったが日頃から写真の話をしながら仕事できるような環境は魅力的だった。ちなみに、この記事で使っている写真は全て自分の写真である。

最後のビジョンについては、純粋に良いなと思えるサービスだったのでジョインした。

ラブグラフは出張撮影のスタートアップで、「幸せな瞬間を、もっと世界に。」というビジョンのもと、カップルさんやご家族の幸せな瞬間を切り取って写真やイラストにするサービスを提供している。 この会社は本当にこのビジョンを達成するための会社であって、それ以上でもそれ以下でもない会社がこの会社である。

どちらかというと自分は「幸せ」とかいうキラキラしたキーワードからは遠いところの住人なのだが、それでも、代表の駒下が楽しそうな目で幸せな世界について語っていて、そのビジョンに共感した優秀なメンバーや全国のカメラマンが集まっていて、そして色んなお客様がサービスを好きだと言ってくれていて、そんな世界観が良いなと思ってしまったし、これを作る手伝いをするかと思ってしまった。

代表の駒下について一言説明しておくと、本当にアホなくらいひたすら同じ未来について語る人で(というか多分アホである)、しかし魅力的で幸せな世界観を語る人である。

ということで、良いと思ってしまった世界を実現するため、ジョインすることを決めた。フルタイムのメンバーとしては当時の5人目だった。

入社後の感想としては、「スキルアップ」「写真」「ビジョン」の3つは概ね期待通り満たした。1人で開発含め何でもやる力は身についたし、写真の話をするのも楽しいし、今でもやはり自信を持って良いと言えるサービスである。

ちなみに言うと年収は7割弱に下がった。十分な資金のないスタートアップにしては、むしろかなり頑張ってくれた額はもらったので、特に不満はなかった。

1年目:何もないところから、仕組みを作っていく

f:id:nullnull7:20180831124016j:plain
2016年8月の引っ越し時に撮影

ジョインして初めに感じたことは、「仕組みがない」だった。

定例は朝会のみ、案件の責任者は曖昧、仕様は存在せず、開発案件は誰かが「欲しい」と言ったものをissueに書きためエンジニアの判断で実装していくだけ。 色んなものが個々人の力量によって進められていた(初期のスタートアップはそんなものだと思うし、それで良いと思う)。

先人達により色んなものが仕組み化されていた前職と比べ、立派な高層ビルの中から何もない平野に移動したような感覚を覚え、スタートアップにきたなと感じた。


そんな中で自分がやったことは、スタートアップのスピード感と現状のメンバーでやれることを考えつつ、組織の拡大にあわせ、少しずつ仕組みを作ってチームとしてサービスを作っていくことだった。

開発メンバーとしてはPMの役割を緩く担い、週2で開発定例を始めて、案件の優先度管理や進捗管理、振り返り、中長期計画の策定などを行なった。

また、途中からマーケティングやCS、カメラマンのマネジメントなどのチームにも顔を出して、プレイヤーとして改善を行いつつ、定例を開き、目標を決め振り返りのフォーマットを定めて、チームがチームとしてサービスを改善していけるような仕組みを考えていった。

…と言えれば格好良かったが、実際のところはなかなか難しかったというのが事実で、初めての分野でプレイヤーとして結果を出すのも難しければ、マネージャーとしても力不足を痛感した。 とはいえとにかく色んなところに顔を出して改善を回し、もちろん開発も進めて、という日々を過ごした。


ちなみに自分自身がカメラマンでもあるので、カメラマンとしてサービスを使い撮影に赴き、納品機能その他の管理画面をドッグフーディングしたり、撮影の間にゲストにヒアリングをして改善ポイントを探ったりもしていた。「エンジニアが一番のユーザであるべき」とは前職で学んだマインドだが、これについてはこれ以上なく体現したと思っている。

2年目:会社経営の難しさ

f:id:nullnull7:20180831124151j:plain
2017年8月の経営合宿

会社にジョインして1年が経ち、インターン生や業務委託も含めると20人以上の規模になったころ、創業期から携わっていた優秀なエンジニアが一人辞め、エンジニアが1人となった。

穴は大きく、自分は開発に集中してカバーしようと思っていた矢先、その3ヶ月後にビジネス面を支えてくれていたCOOが辞めた。

開発とビジネスの両輪が会社から離れ、危機感を感じ、経営会議に参加させてもらい、会社経営についても考える日々が始まった。


そこで感じたことは、月並みだが、実際にやるのと口を出すだけではこうも違うのかということだった。自分が経営について語るのは烏滸がましいが、この1年で感じたことを簡単にここにまとめてみる。

選択と集中 : やりたいことは現状の経営資源でやれることよりも常に少し多めになりがちだ。どんなに気をつけていても、振り返ってみるとやはりもっとコアな事業に集中すべきだったと思うことが多々あった。経営資源を集中させるための明確な経営戦略の重要さを痛感した。

Get Things Done : やるべきことが決まればあとはやるだけなのだが、やりきるのはなかなか難しい。やろうと言ったことが何の障害もなくできることなんて稀だが、その上でもそれをやりきることができるかは、会社が前に進んでいけるかを決める重要な要素である。"Get Things Done" とは前COOがよく言っていた言葉で、今でも好きな言葉だ。

大切なのは人 : スタートアップの膨大な量のタスクを上手く実行するのは、結局人だ。優秀な人が増えれば全てが進むし、人が足りていない状態であれこれ言って雰囲気が悪くなっても仕方ない。今のメンバーが活躍できないのは本当に最悪だ。事業について考えるのは大切だが、事業を作る人をどう採用/育成するかはもっと重要だと思う。(そして更に言えば、名もないスタートアップにジョインしようと思わせる魅力的なビジョンが最重要だ。)

プロダクトを磨く : なまじ入社当初からサービスの基本部分は完成されていたため、ビジネス側はプロダクトの磨き込みよりも、分かりやすく効果の出るマーケティングに力を入れがちだった。プロダクトの理想像を腰を据えて考えたいと感じていた頃、現CPOの吉村がジョインし、PMとして素晴らしくここをまとめあげてくれた。よく言われることだが、プロダクトが完成されていない状況でマーケティングを頑張っても穴の空いたバケツで水を掬っているようなもので、短期的なKPIに捉われずプロダクト改善の優先度をあげるべきだった。

優れた問いは優れた答えに勝る : これは学んだことではなく、人生で常に大切にしている考えだが、経営の上でもやはり必要な考え方だ。問題をいかにうまく解決するかは大切だが、そもそもどんな問題を解くのかの方が遥かに重要で、会議中によく突っ込みをいれていた。この辺の話は社内のメンバーにもよく伝えていた話で、退職日に類似の話をしてくれる人が多かったので書いてみた。

開発の話

ビジネス側のことをメインに書いてしまったが、もちろん業務のメインはエンジニアとしての仕事で、開発をしていた。特にエンジニアが1人になってからは、全ての開発に関わる課題を自分1人の力で解決しなければならず、なかなか大変だった。ただWebサービスに関わる一通りの要素をそれなりのレベルでできる自負が持てたのはよかったし、また外部の副業エンジニアや技術顧問からも、技術レベル高くやっていると言ってもらえてよかった。

また、経営陣に参加し始めたころから、肩書きとしてはリードエンジニアとなり、開発組織を作るというミッションが明確に与えられた。すなわち、採用とマネジメントにも責任を持つことになった。

採用については難しく、結果としては自分が正社員エンジニアを採用することはできなかった。採用に銀の弾丸はないのだからやるべきことを地道にしっかりとやっていくべきだったというのが大きな反省だが、愚痴をこぼすと、地道な努力もそれはそれでしていたし、技術ドリブンでもない小さなスタートアップに良いエンジニアを呼び込むのはなかなか厳しく、エンジニア採用はやはり難しいとも思う。何人かの優秀な候補者の人に「成澤さんがいるのが魅力的」と言ってもらえたのはやはり嬉しかったし、これからもそう在りたい。(ちなみに現在は自分以外に正社員エンジニアが在籍している)

マネジメントについては、正社員以外だと、時期も期間もバラバラだが副業を計10人、フルタイムの業務委託を計3人、インターン生を計4人採用して開発チームを作っていた。エンジニア1人は諸々辛いので彼らに大分助けられつつ(本当に感謝してます。ありがとう)、とはいえ結局ボトルネックとなるのは1人しかいない正社員で、正社員採用を頑張らないと仕方ないという気持ちだった。インターン生がすくすくと成長してくれたのは個人的には嬉しかったことで、自分も学生時代のインターン先(PFN社)では大変お世話になったので、自社でも同じことができていたら嬉しい。

ラブグラフを退職

ここまで述べておいて何なんだとは思うが、ラブグラフを退職した。

サービスは未だに良いものだと思っているし、もっとサービスを伸ばしたかったし、残していくエンジニアやチームメンバー、そしてカメラマン達には本当に申し訳ない気持ちで一杯だが、ビジョンに幸せを掲げている以上、自身の幸せについても真面目に考えなければいけないと思った。長い間迷っていたが、最近は事業も順調に伸びているのと、色々あって、結局このタイミングで辞めることにした。退職理由はここでは詳しく書かない。

自分が言っても説得力がないかもしれないが、ラブグラフに興味をもってくれた人はぜひ話を聞きにいってもらえると嬉しい。全職種で社員を募集中だ。多分このリンクから応募できる


ということで退職するが、2年間でお世話になったたくさんの方々、今まで温かい目で見守っていただき本当にありがとうございました。そして、全国のラブグラファー、イラストレーターさん、そして社内のメンバー、特に開発チーム、特にあんみつとゆきな、そして駒下、改めてお疲れさまでした。これからも頑張って!

f:id:nullnull7:20180831124604j:plain
最終日のオフィス。人が増えた…というより、物が増えたような写真になってしまったが、とにかく大分会社らしくなったのかなと思う。


これからどうするか

次に何をするかというと、しばらくはフリーランスのエンジニアとして、時間とお金に余裕をもってゆっくりと好きな技術を磨く予定である。フリーランスを長く続けるつもりは今のところなく、1年ほどしたらまたどこかに就職すると思う。

おかげさまで年内の予定は既に埋まっているのだが、副業的な参加や、年明けからの参加は可能かもしれないので、よければ声がけいただけると嬉しい。スキルとしてはWebアプリケーション開発全般(特にRubyOnRails/Vue.js/AWS)に対応できる。

また、この記事の通りスタートアップで一通りの役割はこなしたのと、学生時代は言語処理をやっていたので、この辺のスキルとマッチするようなお仕事も募集中である。言語処理については学生時代に第一著者で海外のトップカンファレンスに通した経験がある。この分野では当時国内最年少だった。

興味ある方は下記ポートフォリオページをぜひ。

katsumanarisawa.me

pdfの履歴書はこちら。

https://katsumanarisawa.me/resume201809.pdf

終わりに

ここまで読んでもらえる人が何人いるのか分からないが、スタートアップのキャリアの参考になっていれば嬉しい。また、ラブグラフに興味を持っていてもらえれば嬉しい。

自分に何かあれば、以下よりお気軽にご連絡ください。恵比寿、中目黒、渋谷あたりであればいつでも行けると思う。

twitter.com

ウィッシュリスト

定番のウィッシュリストの代わりに、ラブグラフをプレゼントとして贈ることができる素敵なギフトサービスがあるので、そのリンクをのせておく。大切な友人へのプレゼントにどうぞ。特に結婚前の友人カップルなどにオススメである。

lovegraph.me

Chainerを使って写真を新海誠さん風イラストに画風変換する

この記事はChainer Advent Calendar 2016の14日目の記事になります。

概要

こちらのツイートの研究について、詳しくお話します。

この記事では、上記の最終的な出力に至るまでに試したことを紹介します。

使用した手法の詳しい説明には触れず、結果の出力画像をメインに紹介するので、機械学習に詳しくない方でも楽しく読んでいただけるかなと思います。

はじめに

2014年に公開されたGatys et al 2014の論文を皮切りに、ディープラーニングを使った画風変換のアルゴリズムが一時期世間を賑わせていました。この論文を元に実装された(と思われる)アプリのPrismaは結構なヒットになっていた印象です。画風変換をご存知ない方は、こちらの記事をご覧ください。 画風を変換するアルゴリズム | Preferred Research

元論文やPrismaではゴッホの画風変換に取り組んでいましたが、この記事ではもっと皆さんに身近な例と言える、漫画やゲーム・アニメ風のイラストへの画風変換に取り組んだ結果をご紹介します。

もしも上手くいけば、将来的にはイラストレーターさんやアニメーターさんの作業をお手伝いする(参考:prosthetic knowledge)ことが考えられます。

実験手法

mattyaさん、yusuketomotoさんが公開している素晴らしいライブラリを使わせて頂きました。 自分で書いたコードは実験を楽に進めるためのシェルスクリプトくらいです。

使用されている手法についてここでは詳しく述べませんが、それぞれのページでわかりやすい解説記事がのっていますので、興味がある方はそちらを参考にどうぞ。

実験

冒頭で紹介した出力例に辿りつくまでに試したことを紹介します。

実験1

まず、何も考えずchainer-goghを使います。

  • ライブラリ:chainer-gogh
  • 環境:g2.2xlargeインスタンスGPUメモリ1GB)
  • パラメータ:ほぼデフォルト(widthを~600px)
入力画像 出力画像
https://gyazo.com/e234610d885d37982d5e7b5dbcb14add https://gyazo.com/294fea35d8315c57ea71d1e93031fe58
https://gyazo.com/0c613e0d9263803bba9a4ab5a3a3273d https://gyazo.com/2b37b195862252941ccafff25f0c70f9
https://gyazo.com/3dbd18914ed4a1ee076e04e4d92dac26 https://gyazo.com/5e8bf9b8a048c1234aef5510f84caabc

解像感はありませんが、なんとなく良い感じです。

この時点で、以下がわかりました。

  • 出力のサイズに応じてGPUのメモリが消費される
    • 1GBのメモリでは出力は横幅600pxが限界
    • 出力サイズが大きいほど、鮮明な画像になる
  • 使用モデルはvggがもっとも良い。ただし出力には時間がかかる
  • 1回の試行にかかる時間は出力横幅600px, 2000回イテレートで2時間程度

実験2

解像感を出すのにあたり、単純にGPUのメモリがボトルネックであったため、良いGPUにして再チャレンジします。

また、色々とパラメータを変更して実験を行い、最適なパラメータに調整しました。

  • ライブラリ:chainer-gogh
  • 環境:高火力サーバ(GPUメモリ4GB)
  • パラメータ:vgg w1200 i2000 lam0.05
入力画像 出力画像
https://gyazo.com/ba0220765e5993a74d78adfd25bcfdc9 https://gyazo.com/517ff497177648bfe21cac0330ebf1a3

だいぶ良くなりました。しかしまだ作品にするには解像感が足りません。

実験3

解像感をあげるためには出力サイズをより大きくしたいところですが、 これ以上はGPUメモリの関係で出力サイズを大きくすることができません。

そこで、画像を16分割した状態で、それぞれに対して画風変換を行い、最後にそれを結合させることにしました

また、この際 スタイル画像も入力画像それぞれ専用に用意し、それぞれに含まれる要素を揃えます。 これを行わないと、例えば草むらしかない右下の断片の画像に桜のスタイル画像をあててしまい、草むらがピンク色になったりしてしまいます。
綺麗に仕上げるために、この処理を行うのが大きなポイントでした。

入力画像 出力画像
https://gyazo.com/8ff18aefccaee2a0fb280bda968c66cd https://gyazo.com/761b242b46db6c5b782a7a4bebadcd60

これを少し手動で補正したものが、冒頭で紹介した例になります。
かなり綺麗に画風変換できたのではないかと思います。

実験4 ポートレート写真の変換

ここからは失敗例を紹介します。まず、人の写真の画風変換を試したものから。

入力画像 出力画像
https://gyazo.com/03e17862d46ad9aa9aa28065d156f9d5 https://gyazo.com/407783421e9a2fe0f20a4cc053dbbaed
https://gyazo.com/dfe9476f82b0218f27158c84466c5826 https://gyazo.com/9813b9d42fd637d66a3d0a9ea5ec5023

……なかなか難しいですね(モデルさんごめんなさい)。

以下のユキちゃん先生のような画像を目指していたのですが、雰囲気を大雑把にコピーするのは結構上手くいっても、 アニメの人の顔のようにそもそも入力画像と形が違うもの(特に目)は、今回の手法にはあっていなさそうです

ただし、実験3でやったように分割してスタイル画像を最適化したり、解像感をあげればもっと良くなるかもしれません。(ここは時間が足りず実験できませんでした)

参考:ユキちゃん先生(引用元:「言の葉の庭」)

https://gyazo.com/9e31656dfabac8cb3a8b7de5297b9aa1

実験5 chainer-fast-neuralstyle

chainer-fast-neuralstyle の出力結果です。

学習にはMicrosoft COCO datasetを使いました。

入力画像 出力画像
https://gyazo.com/e234610d885d37982d5e7b5dbcb14add https://gyazo.com/99430261712e2fe32b174391b5c38d70
https://gyazo.com/71411e684104773d5fb4b7ad396abc09 https://gyazo.com/4df678a2e20f6627723138c9b4dd968a
https://gyazo.com/48e5509ad811e7788af9a9418202dc20 https://gyazo.com/4ab4fae3aee5718e6f3b1d1cb813361d

解像感が素晴らしいですね。
こちらの手法は、一度学習を終えれば出力を作成する際にはほぼメモリを使わないので、出力画像を生成する際にメモリがボトルネックにならず、出力画像の解像度をあげやすいです。(ちなみに学習には15時間ほどかかっています)

しかし、全体がピンクになったり青くなったり、のっぺりとした印象です。
これは今回使った訓練画像が、実際に入力する画像とかけはなれたものが多かったためだと考えられます。
桜と関係のないただの室内画像などを、桜のスタイル画像にできるだけ近づけて変換しようと学習してしまい、何でもかんでもピンク色にしてしまうような学習をしてしまった と考えられます。

逆に言えば、訓練画像を変えたり学習の仕方を工夫すれば改善が見込めそうです。

実験6 動画への応用

chainer-fast-neuralstyleは今まで紹介していたchainer-goghの手法とは違い、一度学習すれば高速に変換ができるため、動画への応用が可能です。

うまくいけばまさしく新海誠さん風のアニメが作れるはず!

雨の中新宿御苑で動画を撮影し、画風変換をしてみました。果たしてその結果は…


新宿 - 言の葉の庭風

………。

ちょっと現状のクオリティだと厳しいですね。

動画への応用は盛んに行われてるので、チラつきを抑えたりするもう少しいいやり方があるかもしれません。

https://www.youtube.com/watch?v=Khuj4ASldmU

https://research.googleblog.com/2016/10/supercharging-style-transfer.html?m=1

https://twitter.com/elluba/status/805730357215686656

まとめ

画風変換アルゴリズムを用いて、実用レベルで写真をアニメ風のイラストに変換できることがわかりました。

しかし、記事中はあまり述べていませんが、今回の実験を行うにあたり 入力画像とスタイル画像の組み合わせはかなり時間をかけてセレクトしており、現状だと汎用的に使える手法とは言いづらい状態です
例えば、上記の電車の例では、元写真に桜と草むらと電車と人が写っているために、スタイル画像にもこれらの要素が写っているものを上手くセレクトする必要がありました。

今後やってみたいことは以下になります。

  • 更に様々な入力画像について変換を行い、サンプルを集める
  • 入力画像を要素ごとにレイヤーに分割し、レイヤーそれぞれにあったスタイル画像を選び、レイヤごとに画風変換を行う
    • 例えば上の例で言えば、桜の花びら部分のみのレイヤと、電車のレイヤと、草むらのレイヤに分割するなど。
    • これにより、例えば桜のスタイルが草にあたってしまうことがなくなる
    • また適したスタイル画像を準備しやすくなりそう。(今までは桜と草むらと電車っぽいものが写っているスタイル画像を用意しなければいけなかったが、それぞれの要素が写っているスタイル画像を別々に用意すれば良いだけになる)
  • chainer-fast-neuralstyle の訓練画像を変えて学習してみる
  • 他にも色々手法が出ているので、試してみる

やりたいことは色々あるので、一緒に活動したい方いればぜひお声がけください。

おわりに

こんなにお手軽に最先端の研究を味わえるライブラリを提供していただいたPFIさん、mattyaさん、yusuketomotoさん、どうもありがとうございました。ec2インスタンスを使った際、sshログインしてからわずか3コマンドで実験環境が整って感動しました。
また無償トライアルでハイスペックなサーバを貸していただいたさくらの高火力チームの方々、ありがとうございました。

rails + backbone.js + create.jsでブラウザゲーム制作 (3)

f:id:nullnull7:20150322211409g:plain

基本的な機能が出来上がって、ストーリー書いたり素材集めたり演出頑張ったり…と開発以外の部分に時間かかるようになってきたため、製作に一区切りつけることにしました。

目的だったフロントエンドの勉強は、大分手を動かしてアウトプットできた。しばらくインプット期間に入りたいなと思います。

作るのは楽しいので、1年後くらいに公開できるレベルにしたいなあ…とうっすら考えながら、一旦開発スピード落とそうと思います。


とはいえ、せっかく作ったものが日の目を見ないのは若干寂しいので、デザインはまだまだなのでちょっと恥ずかしいですがほんの一部だけ動画晒しておきます。

続きを読む

Backboneのモデルについて&スマホ用CSSのメモ

相変わらず勉強のためゲーム製作中です。(前回:Ruby on Rails + Backbone.js でゲーム製作中 - nullnull7の日記

進捗は

  • backboneの土台の部分は書き終わり。あとはゴリゴリとイベント書いていく
  • jsのアニメーションのライブラリを調査した
    • tmlib.js辺りがお手頃そう。
    • enchant.jsはtmlibより学習サイト充実してるが若干遅かったりな印象
    • create.jsやpixi.jsは性能良いがちょっと高機能すぎる印象
    • smart.jsはお手軽で使ってみたいがさすがにシンプルすぎる印象
  • デザイン見直した
    • デザイン決まらず死ぬほど時間かかっている。。。
    • デザインも頑張りたいところだけど、時間かけてできるものでもないので、見切りをつける必要。といつも思う(ができない
  • 開発環境を整えたりいろいろ。
  • 今はhtml/cssを書いてる途中

今日はbackboneの感想とcssのメモ晒しておきます。

続きを読む

Ruby on Rails + Backbone.js でゲーム製作中

  • 一本ゲーム作る経験が欲しいなー
  • なんか新しい言語触りたいなー

という思いから、Rails + Backbone.js でゲーム製作中です。ruby触るの初、jsとかフロントエンドを真面目に勉強するのも初。ってことでいい勉強になってます。

どんなゲームかーとかいう話は出来上がったときにする(いつ来るのかw)として、ruby触ってみた感想。

感想
  • 超基本的な文法を1時間くらいさらーっとやって、あとはdotinstallでRuby on Rails入門見たら、あとは適宜ググりながら開発進められるレベルになった。サクサク進めて良い
  • 超ざっくりとした感覚だとPerlPythonの中間って感じ。do, then, end辺りを書くのが非常にウザいけど、それ以外はスッキリ書けていいなーと思う。
    • Pythonでwebアプリを真面目に作ったことないからあれだが、Python数値計算とかの学術用途向け、RubyはWebアプリ向けな印象(偏見です)
  • Railsはモダンだなあ…。rails gとかrailsコマンドが色々いいなーと思った。
    • 最近業務で使っているのが一昔前のPerlフレームワークなのでますます…ゲフンゲフン
    • scaffoldしたら何もせずともウェブサイト出来上がって吹いたw
  • backboneとの連携もbackbone-on-rails というgemがあって導入しやすかった。

とりあえず今困ってることとしては、rails server で立ち上げたサーバーがコード書き換えてもたまにリロードしてくれないこと。ちょっとググっても解決しなかった。 railsがどう動いてるのか何も把握せずただただレールの上にのって開発してるので、そのうち真面目に勉強する必要ありそう。

開発状況

今の開発状況は、APIサーバー側(Rails)がなんとなく終わってきたところ。API側はあとは魔法詠唱のロジック周りとかステータス異常とかスキルによる命中率変化とか…まあ細かい内容。

直近やったことは、そろそろいちいちcurl叩いてデバッグするのも辛くなってきたので、先にフロント側を実装してデバッグしやすくしよう〜と思いフロント側の実装を初めて、その前に絵コンテできてねーわと思い絵コンテを書こうとし、ついつい拘りたくなってデザインに凝ろうとし、しかしデザインセンス無いので全くできあがらずグダグダ……という感じでしたw デザインのセンスと技術が欲しい。。

年内にひとまず動くもの作って、1~2月にデザイン詰めたり細かい仕様の実装を進めたいなー。

サーバー上のファイルをSublimeLinter 他

週末にsublimeと戯れたので、その結果をメモ。

サーバー上のファイルをsublimelinter

PerlのSublimeLinterについては前に記事を書きました(ちなみにinclude_dirsについて追記しました)が、サーバー上のファイルをマウントして作業とかしてると、実際に実行するperlはサーバー上のperlなので、ローカルにもサーバー上で使うモジュールと同じものがないとuseエラーが起きてしまいます。 ローカルにもサーバー上と同じ環境を作れれば問題ないのですが、まあそれも面倒ですよね。ということで、サーバー上の環境でlintをかけるようにしてみました。

続きを読む

初めての一眼レフカメラ選び・交換レンズ選び(正しいレンズ沼へのハマり方)

順当にレンズ沼にはまってきているnullnullですこんにちは。

今日は自分がどうやってレンズ沼にはまっていったかについて。

かなり正しく(?)カメラ・レンズ沼にハマったので、カメラ選び・レンズ選びの参考になるかも

続きを読む