https://amakan.net/ のこの辺の改善の続き。 amakanをUnicornからPumaに移行した - ✘╹◡╹✘ amakanでyarnを使うようにした - ✘╹◡╹✘ amakanでRuby 2.3.3を使うようにした - ✘╹◡╹✘ amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した - ✘╹◡╹✘ amakanのフロントエンドを色々改善した - ✘╹◡╹✘ amakanをSidekiqに移行した - ✘╹◡╹✘ amakanの開発環境をDockerに移行した - ✘╹◡╹✘ 本番環境で使うDockerイメージ これまで開発環境でのみDockerを動かしていたが、本番環境でDockerを動かすには、本番環境で利用できるようなDockerイメージを用意する必要がある。そこでamakanでは、こういう方法を取った。 開発環境と本番環境で同

10 日ほど前から amakan books の再設計に着手しており、最近ようやく実装を終えた。いまデータ移行処理を実行している最中で、20時間ぐらい掛かるのでゆっくり待ちながらこの記事を書いている。変更理由についておさらいするという意味も含めて、変更内容と意思決定の背景について書き記しておく。 テーブルの変更 旧 DB スキーマ では以下のようなテーブル群を利用していた。 amazon_product_link amazon_product_responses author_product_list_memberships author_product_memberships authors evaluations product_links product_lists products 新 DB スキーマ では以下のようなテーブル群を利用するようになった。 book_authors b

ゼルダの伝説 一旦クリアしたのでゆっくり暇を見つけては少しずつやっている。ゼルダの伝説をクリアしてからというもの、個人開発の時間が無限にあるように思えてくる…。 amakan anime 自動で収集してきた作品画像の精度があまりにも低いので、利用者が自由に画像を差し替えられるようにした。懸念していた放送情報の取得部分などは、今のところ上手く動いている模様。サイドバーの領域に後でコンテンツを幾つか用意しようと思っていたのがまだ着手できていないので、暇を見つけて着手したい。 amakan books amakan anime の方そろそろ完成しそうなので、書籍の方に anime で得た DB 設計の知見を反映して、Kindle 版やシリーズ判定のデータ揺れを吸収する作業に取り掛かりたいと思う。 React amakan の React コンポーネント設計 - ✘╹◡╹✘ を書いた。 チーズタル

9mとsoramugiから、やっていきエフエム という名前でPodcastをやりませんかという話を承け、Podcastをやることになった。既にサイトが公開されていて、https://yatteiki.fm からアクセスできる。昨日できたばかりで準備中なところが幾つかあるが、サイトを開いて音を聴けるという点では最低限の体験は保証されている。 10月25日にSlackチームを立ち上げ 10月28日に練習でSkypeで通話 10月29日に1回目を収録 10月30日に公開用のサイトを作成 という流れで、発足から企画、収録、公開まで進み、この順調さには当の我々ですら驚かされた。 個人的には、雑談レベルの会話が淡々と展開されていくような、例えばカンファレンスの懇親会での会話を隣で聴いているような、あるいは飯屋での雑談を隣で聴いているような、更に言えばマックで隣の女子高生のガールズトークを聴いているよう

amakan での設計を例に、RailsでSingle-Page Applicationをつくるときの自分のやり方をまとめてみます。 Gem 「JavaScriptで書かれたReactのコンポーネントからHTMLを生成する」というのをRubyでやるために、RubyのV8エンジン実装であるmini_racerというGemを使う。この処理を楽に実行するために、react_on_railsというGemも使う。 gem "mini_racer" gem "react_on_rails" View body要素内のHTMLは全てReactで生成するので、layout以外にviewのテンプレートは存在しない。 Controller 初回リクエストの場合はHTMLを返す ページ遷移時に呼ばれるリクエストの場合はJSONを返す 外部サイトからブラウザバックで戻ってきたときにJSONを見せない という要求に

最近RubyとReact.jsをよく利用していて、Rubyで扱っている値をJSONとして表現したいケースが増えてきた。こういうのどうやっていますかと人に聞きたいので、自分はこうやっていますよというのを説明のためにまとめておくことにする。 概観 自分の場合、次のような方法で実装することが多い。 JSONとして表現したいオブジェクトをコンストラクタで受け取るクラスを定義する クラスに #as_json を定義して適当なHashを返すようにする Object#to_json が再帰的に #as_json を利用するようにする (ActiveSupportがやってくれる) コード 具体的には、以下のようなクラスをつくっている。これは最近つくっている掲示板での例で、Megaboard::Resources::Comment はコメントのJSON表現のためのクラスである。いわばコメントのJSON表現に

※当方iOSアプリ開発経験無し react-native、デモ見たときタップしたら画面上の数が増えるぐらいのアプリしかつくれなさそうという印象だったけど、いま丁度タップして読んだ数が増える程度のアプリつくりたいんで使いたい— 生産職 (@r7kamura) 2016年8月23日 とち狂ってreact-nativeのチュートリアルに沿ってインストールはじめてしまった、死にたい— 生産職 (@r7kamura) 2016年8月23日 殺してくれ 殺してくれ— 生産職 (@r7kamura) 2016年8月23日 アプリ完成した pic.twitter.com/bep81pzWAR— 生産職 (@r7kamura) 2016年8月23日 とりあえずバナナでも表示してみるか— 生産職 (@r7kamura) 2016年8月23日 なるほどなるほど pic.twitter.com/mgLilyL09

43型4Kディスプレイ注文したので決め手を書いとく - ✘╹◡╹✘ で書いてたやつが届いたので、様子を紹介します。はてなブログの貼り付け機能便利ですね。全然文章書かなくても貼り付けていくだけで何かが生成される。 購入したやつ Philips 43型ワイド液晶ディスプレイ (4K対応/IPSパネル/5年間フル保証) BDM4350UC/11 出版社/メーカー: Philips(フィリップス)発売日: 2016/04/15メディア: Personal Computersこの商品を含むブログを見る 他の検討候補 DOSHISHA 43型 4K液晶ディスプレイ D431US 出版社/メーカー: DOSHISHA発売日: 2015/10/20メディア: Personal Computersこの商品を含むブログを見る I-O DATA 40型ワイド液晶ディスプレイ (HDMI端子4K/60Hz・HDC

おおよそ間違いが幾つか含まれてそうな知見 HDMI 2.0 か Display Port で出力するとほぼ最高の状態で出力できる HDMI 2.0 で出力できるマシンは今のところ少ない (例えば最近のMacbook ProでもHDMI 1.4) Macbook Proでは代わりにDisplay Port経由で出力すると良い 4つの入力を受け取って1画面に4分割する機能を備えたディスプレイもある (PBP4in1というらしい) IPS液晶とVA液晶では基本的にはIPSのほうが視野角が優秀だが最近はそこまで顕著に違いはない 40型前後の4Kディスプレイは5万円から9万円ぐらいのものが多い TV寄り製品かPC寄り製品かでリモコンの有無や自動電源オフなどの使い勝手が異なる 注文したもの はい / 次の商品を購入しました：Philips(フィリップス) 『Philips 43型ワイド液晶ディスプレイ

前回の記事 あのWikiHubが天下Wiki武道会に参戦 - ✘╹◡╹✘ で触れたけど、先月から WikiHub というWikiをつくっていて、趣味程度ではじめたものの結構な勢いで開発が続いてる。 最近の変更点 ここ最近の新機能として、 SSL対応 GitHubアカウントでのログイン エクスポート機能 ページテンプレート機能 Markdownでチェックボックスつけられるやつ HipChat・Slack連携 Webhook 二段階認証 などを実装してみたりしていた。CHANGELOG - WikiHub Help に変更点を書いていってあるので、ここ見るともっと詳しい様子が分かって便利。今日これやったぞーっていうのまとめて公開しておくとがんばった感が出るので、WebサービスとかでもCHANGELOGを書いて公開していくのは良い取り組みだと思いました。よく考えたらやってない感も出るので諸刃の剣

公式キャラがバットを持った美樹さやかに似ている。

こんにちは、卓球ハウスアドベントカレンダー14日目です。前に住んでいた卓球ハウスというシェアハウスが12月で解散するので、先日シュッと京都に引っ越してきました。 シェアハウスは2013年の6月からやっていたので、2年半ぐらい住んでいたことになる。1月ぐらいに2人に声をかけて、そのあと3月ぐらいから住居を探してたので、準備云々を含めると大体3年ぐらい色々やっていた。人や家を探していたときの記憶が色濃く残っていて、振り返るとすぐそこにありそうなくらいつい最近のことのように思える。 3年というと、この辺りではちょうど人材の流れるスピードと同じぐらいで、実際入居してから職場が変わった人のほうが多いくらい。通勤環境が変わったり、身辺に大きな変化があったり、周辺環境に慣れてしまったり、また新しい変化への期待が込み上げてきたりということで、集まったときと同じくらいのノリで、まあ解散してみますかということ

https://github.com/r7kamura/ruboty RubotyというRuby製のChatterbotをつくった。 Herokuで動かす Herokuにデプロイすれば無料で動く。 Slackというチャットサービスで動かすならこういう感じ (部屋名とかは適宜変える): $ mkdir mybot $ cd mybot $ echo 'source "https://rubygems.org"' >> Gemfile $ echo 'gem "ruboty"' >> Gemfile $ echo 'gem "ruboty-slack"' >> Gemfile $ echo 'bot: bundle exec ruboty' >> Procfile $ bundle install $ git init $ git add . $ git commit -m "Initial

これまではどちらかと言うとDBやWeb APIみたいな開発作業が多かったけど、最近はHTML/CSSを触るようないわゆるWebデザイン的な作業をする機運が高まってきた。あんまりちゃんとやったことが無いために年始から色々と考えてて、まあその結実としてキャプチャ撮ると捗るという体験があったので書き残しておく。ちなみにキャプチャは無い。あとでデザイン変えたやつ公開したら過程を整理して紹介できると良いと思う。 過程を残すと意見をもらいやすい 『藤村龍至 プロトタイピング-模型とつぶやき』という本の中に、プロトタイプとして建築模型をつくっていく過程の話がある。与えられた条件を元にまず最もシンプルな状態から始め、課題を見つけながら少しずつ改善を加えていく様子が実例とともに紹介されている。この作業を反復しながら適用していくことで、模型の状態を都度更新していく。この方法には、設計者以外の人でも設計過程を見

「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド

華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく

REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい

同居人の発案により、大失職Nightというイベントが自宅で行われました。当日は東亜飯店から取り寄せられた貴重な料理を頂いたり、同居人の誕生日に送った冷凍マグロを解凍して寿司を握ったりしました。蓋を開けてみれば集まった退職者の人数は二桁にのぼり、人はいつか必ず職を失うのだ、いやいや、君はある重大な事実を見逃している、働かなければ職を失うこともないだろう、などとお互いの知見や感情を少しずつ交換しました。

朝早起きしたので、フルスクラッチから1日でCMSを作る シェルスクリプト高速開発手法入門 という本を買ってちょっと読んだ。 シェル芸人が考えていることをテキストに起こしながらシェルでいろいろ作る様子が描かれてる。 シェルスクリプトと言えば、今日たまたまこういうシェルスクリプトを見かけた。 https://github.com/flynn/slugbuilder/blob/master/builder/install-buildpack#L16 IFS='#' read x y <<< "$url" 環境変数IFSで組込みコマンド readの区切り文字を空白文字から "#" に変更しつつ (URLの中の"#"より前をx、後をyに入れたい)、変数urlを展開しながらヒアストリングで標準入力として与えている。 echo "$url" | read ... というふうにしなかったのは、 パイプに変

TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or