シリーズ判定最前線 - ✘╹◡╹✘
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
シリーズ判定最適化前線 - ✘╹◡╹✘
https://amakan.net/ では書籍のシリーズ判定に日夜取り組んでおり、ここで最近追加された変更を紹介します。 シリーズ判定とは 先にシリーズ判定の課題について説明しておくと、まず書籍タイトルからシリーズ名を抽出したいという問題があります。似たような本の集合を見つけるのは簡単ですが、集合に名前が付けられて、かつルールが明確であることが求められます。そこで、シリーズ名を集合の名前かつ検索キーワードとして利用することでこれを解決します。 また、巻ごとに表記揺れした書籍タイトルからも同じシリーズ名を抽出したいという問題があります。ミスった場合、同じシリーズ名が抽出されず、別のシリーズが作成され、複数のシリーズに分割されてしまうという問題があります。書籍名はバイトが表紙を見ながら手入力しているのではないかという精度なので、大体表記揺れしています。 以前 「Kyoto.なんか #2」とい
庭見た - ✘╹◡╹✘
急に庭の気持ちになったので、オフィス行かずに新宿御苑でコード書いてた。可愛い木がたくさんあるし、天気よくてあったかいし、いまつくってるやつめっちゃ便利だしとにかく最高。 自分はこういうまるくてぼってりした造形のものが好きなんですが、 日本庭園エリアにいくとそういうのがたくさん見られてとても良い。 歩きながら雑に撮ったので映りが悪いけどこういうのもある。 その他 はい、ここで急に仕事の話です。感覚的な話なのでいい例が上げられないけど、検索システムのことを考えているときにデザインのことも配慮しなければならないケースとか、その逆でクライアントサイドのJavaScriptの実装のことを考えているときにサーバ側で使ってるDBの設計について配慮しないといけないケースとか、そういうのに遭遇することがここ最近1年ぐらいの期間で増えてきた気がする。これデザイナー絶対わからんやろみたいなやつとか、この設計だと
SHIROBAKO Nightやりました - ✘╹◡╹✘
SHIROBAKO Night on Zusaar 土曜日にSHIROBAKO Nightというイベントをやりました。合間合間にドーナツ食べたり卓球したり宮森に電話を掛けたりしながら、11時から22時まで掛けてSHIROBAKO 全24話を見たあと、id:moznion が持ってきてくれた肉でつくった夜食を囲み、みなで感想を交換しながら良かったシーンを観直しました。以下は現場の様子です。 DDD どんどんドーナツの様子です。参加者の方々にドーナツをたくさんいただきました。 #shirobakonight pic.twitter.com/HhNhJIGqUe— アンデス山脈 (@r7kamura) 2015, 4月 4 プリン プリンもいただきました。主人公である宮森あおいの髪の色は、半人前感を出すためにプリンのような色合いにしたようです。 宮森 #shirobakonight pic.tw
『Webエンジニアが知っておきたいインフラの基本』読んだ - ✘╹◡╹✘
Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~ 作者: 馬場俊彰出版社/メーカー: マイナビ発売日: 2014/12/27メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 先週発売された『Webエンジニアが知っておきたいインフラの基本』を同僚にもらって読んだ。知っておくと便利なインフラの知識をまとめた本。8章構成で、1-4章は基本知識のおさらい、5-8章はより実運用に近い内容という構成になっている。 1章 Webサービスでのインフラの役割 2章 Webサービスを支えるインフラ技術の基礎知識 3章 Webサービスのサーバ構成ベストプラクティス 4章 Webサービスを始めるときのインフラ手配の基礎知識 5章 Webサービスの運用(1) システム監視の基本 6章 Webサービスの運用(2) ステータス モニタリング
リモートワークの地味な知見 - ✘╹◡╹✘
華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく
Netflix Meetup in Kyotoに参加した - ✘╹◡╹✘
いま2週間ほど社員全員リモートで開発してみようという感じでやっていて、まあ働きすぎてる人とかも居るんだけど、紅葉が綺麗な季節なので主に京都で転がってコード書いてる。先週までは暖かかったけど、そろそろ京都も寒くなってきたのでもう転がるのは無理そう。それで、昨日京都でNetflixMeetup in Kyotoというイベントが開催されたので参加してきた。 概観 Meetupでは、Learning Scala - O'Reilly Mediaの著者でもあるNetflixのJason氏の話を聴きながら、Netflixの主にAPI周りの開発方法を伺った。当日利用された発表資料は多分 Enterprise APIs With Ease - Scala Developers of Barcelona。参加者は20代から30代くらいの開発者が主で、あと何故か立命館大学出身の人が多かった。明日Infinit
世界線を超える - ✘╹◡╹✘
開発環境のRailsは、監視対象のファイルが更新されるたびに定数空間を再生成する。ファイルを更新するたびに新たな世界線に遷移すると言っても良い。全ての定数が再読込される訳ではなく、Rails.configuration.autoload_paths に登録され、autoload経由で読み込まれた定数のみが対象になる。このとき、監視対象外の空間から、監視対象の定数を参照していたらどうなるか。例えばlibディレクトリをautoload_pathsに登録していたとして、libディレクトリ内で読み込まれるrack middlewareをRailsのrack middleware stackに追加していたらどうなるのだろうか。 2つの世界 現在の世界で同名の定数が新しく読み込まれようとしたとき、運が良ければ、この現象を検知する仕組みが働いて例外が発生する。しかし運が悪ければ、2つの同名の定数が同じ世
年に1回ブログ作りたくなったときに考えること - ✘╹◡╹✘
最近HTML上の要素を直接編集できるようにするライブラリをつくってからというもの、どうしてブログの記事を編集するときに記事ページを直接編集できないんだろうとか、どうしてユーザに表示されるのと同じデザインを見ながら編集できないんだろう、プレビュー画面とテキストエリアを左右に並べて見比べているんだろう、とか色々な考えに取り憑かれてしまってやばい。 はてなブログやTumblrのテーマにJavaScriptを入れてAPI経由で編集したりできないか試してみたけど、APIを使うための認可用のトークンの発行が安全に行えないとか、異なるドメイン間で通信するのをブラウザが許していないので中継サーバを置くのがだるいとか、そういうことを見積もってみると結局コストが掛かり過ぎそうでぐったりしてた。ブログエンジンから作るみたいなことになると最高に大変そうなのでエディタ部分だけ取り替えたい。 ブログサービスをつくるの
他のホストのコンテナに接続するパターン - ✘╹◡╹✘
他のホストのDockerコンテナには接続しづらい 1つのホストの上で複数のDockerコンテナを動かす場合、あるコンテナからあるコンテナに接続するためにはコンテナに付けた名前が利用できる。具体的には、コンテナの名前をもとにDockerが環境変数を提供してくれて、そこにアドレスとポート番号が入っている。しかし、複数のホストの上で複数のDockerコンテナを動かす場合、他のホストで動作しているコンテナに接続したいのであればこの方法は利用できない。単純に接続先のホストのアドレスとポート番号をコンテナ起動時に指定する方法もあるが、この方法では他のホストに接続する全てのコンテナに対して逐一指定する必要がある。 ホストごとにリバースプロキシを置く 他のホストのコンテナへ接続するためのリバースプロキシとなるコンテナを各ホストごとに設置する。これにより、他のホストのコンテナに接続したい場合でも、あたかもコ
mackerel使ってみた - ✘╹◡╹✘
20分ほど前にmackerelに登録して、とりあえずuiureoさんの総資産情報をモニタリングしてみました。 Dashboardでserviceとroleを作成して表示されているAPI Keyを得たあと、curlでホストuiureoをつくって、総資産をPOSTします。 ホストは POST /api/v0/hosts で作成できます。 curl https://mackerel.io/api/v0/hosts \ -H "X-Api-Key: XXX" \ -H "Content-Type: application/json" \ -d '{"name":"uiureo","meta":{}}' データは POST /api/v0/ で投稿できます。 curl https://mackerel.io/api/v0/tsdb \ -H "X-Api-Key: XXX" \ -H "Conten
全てがJSONになる - ✘╹◡╹✘
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
カレーは料理初心者におすすめ - ✘╹◡╹✘
料理を覚えたいときに何から始めたらいいか分からなかったらカレーをつくるといいよって話。 暖かくなってきたので台所に立つことの抵抗感が減り、少しずつ自分の楽しめるペースで学びながら料理を覚えていこうという気持ちになってきた。寒暖の変化によって何かの動機が促進されるというのは面白い。寒暖の変化がモチベーションに影響するんだったら、日本のように中緯度で大陸の辺縁にあるような地域ではものづくりのモチベーションが湧きまくって技術大国として最高の生産性を発揮できるのでは。いや、冬になったら皆鬱状態になってしまって差し引きはゼロか。春には絶対に卒業したいとか言ってるわりに冬になると段々大学に行かなくなって大学教育の意義を唱え始める人間とかを何度も見てきた。 今週末はカレーとポトフをつくった。カレーはとにかく初心者に易しい。日本の家庭用のカレーの具材といえば、にんじんジャガイモたまねぎ肉ルーあたり。初心者
コンテンツの末尾 - ✘╹◡╹✘
面白いコンテンツが永遠に吸い続けられるよう、コンテンツの末尾には別の幾つかのコンテンツへのリンクが(できれば複数個)置かれていてほしい。 小説や漫画やブログ記事などの中でも読み応えのあるものを読んでいると、終盤の方に差し掛かるときに「そのコンテンツが終わってしまう悲しさ」を感じることがある。例えば10巻まで刊行されている作品を読んでいて、1巻から読み始めて10巻まで差し掛かってしまったとき、物悲しさを感じてしまう。こういうとき、似たような(未読の)作品に滑らかに遷移できるようになっていると、大きな幸福感に包まれる。 コンテンツを吸うという表現は、消費活動に対する一種のメタファーみたいなもの。勿論消費活動だけが幸福を感じる術ではない。同じ粒度の言葉を挙げるのは難しいけど、例えば創作は消費と同じように幸福を感じられる手段の一つだと考えられる。だけど消費活動は手軽で、難易度が低く、失敗が少なく、
避けたい話 - ✘╹◡╹✘
まあ結局はトレードオフだよねで終わる長い話 対案のない問題提起 解決済みの質問者を置き去りにしたコミュニケーション
技術力がないから - ✘╹◡╹✘
つらいことがあったときに上手くいく呪文です。 人に唱えてダメージを与えることも出来る。
Ruby Patterns - ✘╹◡╹✘
この記事には、Rubyを書いているときに「これは言語化されたり公式化されたりしていないけれど基本的には必ずこのパターンに則ってプログラムを書いているな」ということをふと思い出したときにやってきてそのパターンを書く。多分3パターンぐらいで終わると思う。ウケが良ければ思い出す確率が高くなると思う。題材さえあれば何も考えずに書けるので、これを書くコストは全然高くない。 名前が"?"で終わるメソッドは必ずtrueまたはfalseのどちらかを返す trueとfalse以外(例えばnil)が返る可能性がある場合は、必ず式の先頭に!!を付けてtrueかfalseになるようにしてる。 このパターンを守ることがとても大事だという風には全く考えていないけど、もしhas_user?がuserを返すとして、has_user?という名前のメソッドがUserオブジェクトを返すというのは一体どういう意味を持っているのだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
水路閣とか見た - ✘╹◡╹✘
Hubotの貴重な出社シーン - ✘╹◡╹✘
BOTにお互いを監視させる - ✘╹◡╹✘
