エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘
最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、本体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある
Qiitaのトップページのフィードの設計 - ✘╹◡╹✘
@ainame user.articles.preload(:comments, :stocks_count) みたいにstocks_countのようなassociationを生やしており、stocks_countの内部実装はPreloaderが弄られていてIDだけ取ってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame これを抽象化するために、Article.has_many(:stocks, counter: true) みたいにすると、article.stocksとarticle.stocks_countがほぼ同じSQLで同時に定義されるようになってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame それを実現している実装がこれです / k0kubun/activerecord-precount https:
天下一bot武闘会で発表しました - ✘╹◡╹✘
「流行りの Chat Ops に隷属させられているチャット bot たちよ集え! おみくじ、雑談……まるで実務には役に立たないが粋な仕事をこなしてくれる bot たちの知られざる実態を紹介しあいます。」という主旨の会が行われ、Qiitanについて発表させてもらいました。非常にコンテキストの共有が難しいテーマの中、うまく意思疎通できたかどうかは分かりませんが、何か得るものがあったならば幸いです。Rubotyについての話もできると良かったですが、また機会があればそのうちどこかで話したいと思います。 発表で紹介したリンク http://github.com/r7kamura http://qiita.com/r7kamura r7kamura/ruboty r7kamura/ruboty-alias r7kamura/ruboty-cron r7kamura/ruboty-google_cale
『The Essential Web Design Handbook』読んだ - ✘╹◡╹✘
Rafal Tomalの書いた『The Essential Web Design Handbook』という本を読んだ。初心者のためにWebデザインの基本となる知識を広く紹介している。構成としては、筆者がWebデザインを行うときのプロセスをまず最初に紹介し、その各段階を追っていきながら、「この作業は無視されがちだけどこういう点で効率的だからやった方がいい」「これを考えるときにはこういう知識を使う。今回の例ではこうやって考えた」という具合に進んでいく。 プロセス 筆者が推奨するWebサイトのデザインプロセスは次の通り: 調査して計画をつくる 発想を膨らませる スタイルガイドをつくる ワイヤーフレームを組む モックアップをつくる コードを書く 調査と計画 調査するというのは、明確なクライアントがいる場合は要求を聞くことであったり、競合サイトの様子を調べてくることであったり、使えそうな資料を広範に
『藤村龍至 プロトタイピング-模型とつぶやき』読んだ - ✘╹◡╹✘
藤村龍至 プロトタイピング-模型とつぶやき (現代建築家コンセプト・シリーズVOL.19) 作者: 藤村龍至出版社/メーカー: LIXIL出版発売日: 2014/09/16メディア: ペーパーバックこの商品を含むブログ (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
キャメルケースやスネークケースの種類 - ✘╹◡╹✘
何かの命名規則の文脈で会話するとき等に知っていると便利に使えるでしょう。 camelCase, lowerCamelCase, PascalCaseと比較した場合のcamelCase CamelCase, UpperCamelCase, PascalCase chain-case, Chain-Case snake_case 追記1 SCREAMING_SNAKE_CASEというものもあるみたいです。 追記2 余談ですが、QiitaではCSSセレクタの命名規則としてBEMを採用しており、端的に言うと .bloCk_elemeNt-modifiEr というパターンを取っています。Qiitaでは各要素の命名規則としてlowerCamelCaseを採用しており、BlockとElementとを接続するために「_」を、BlockとModifierとを接続するために「-」を採用しています。よって、この
世界線を超える - ✘╹◡╹✘
開発環境のRailsは、監視対象のファイルが更新されるたびに定数空間を再生成する。ファイルを更新するたびに新たな世界線に遷移すると言っても良い。全ての定数が再読込される訳ではなく、Rails.configuration.autoload_paths に登録され、autoload経由で読み込まれた定数のみが対象になる。このとき、監視対象外の空間から、監視対象の定数を参照していたらどうなるか。例えばlibディレクトリをautoload_pathsに登録していたとして、libディレクトリ内で読み込まれるrack middlewareをRailsのrack middleware stackに追加していたらどうなるのだろうか。 2つの世界 現在の世界で同名の定数が新しく読み込まれようとしたとき、運が良ければ、この現象を検知する仕組みが働いて例外が発生する。しかし運が悪ければ、2つの同名の定数が同じ世
他のホストのコンテナに接続するパターン - ✘╹◡╹✘
他のホストのDockerコンテナには接続しづらい 1つのホストの上で複数のDockerコンテナを動かす場合、あるコンテナからあるコンテナに接続するためにはコンテナに付けた名前が利用できる。具体的には、コンテナの名前をもとにDockerが環境変数を提供してくれて、そこにアドレスとポート番号が入っている。しかし、複数のホストの上で複数のDockerコンテナを動かす場合、他のホストで動作しているコンテナに接続したいのであればこの方法は利用できない。単純に接続先のホストのアドレスとポート番号をコンテナ起動時に指定する方法もあるが、この方法では他のホストに接続する全てのコンテナに対して逐一指定する必要がある。 ホストごとにリバースプロキシを置く 他のホストのコンテナへ接続するためのリバースプロキシとなるコンテナを各ホストごとに設置する。これにより、他のホストのコンテナに接続したい場合でも、あたかもコ
ヘッドホン情報 - ✘╹◡╹✘
TL;DR コンテキストと気持ちが大事。 3つ持ってて使い分けてる 7年前にK701という有線のヘッドホンを買って、 それから5年後にMDR-DS7500という無線のヘッドホンを買って、どちらも便利に使い続けてる。 また、去年QC15というノイズキャンセリング機能付きのヘッドホンも買って、これは職場で使ってる。 あとiPhone付属のイヤフォンもシャカシャカした音がわりと好きでよく使う。 QC15は職場用 & 防寒用 他のヘッドホンは外部に音が漏れる構造なので家でしか使えない。 QC15は周りにあまり音が聴こえないので (静かな場所で大きい音を出せば隣の人にも知覚できる)、 職場でもまあ使える。それにノイズキャンセリング機能がとても優れているので、 頻繁に電話が鳴ったり目の前を人間がバタバタと走り回るような環境でもそこそこ落ち着くことが出来る。 ノイズキャンセリングのためだけに付けているこ
今週よく使ったalias - ✘╹◡╹✘
o Gitレポジトリ内のファイルを適当なアプリケーションで開く。雑なので分かりやすくて良い。 alias o='git ls-files | peco | xargs open' e あとこれもよく使った。手元のマシン内のレポジトリに移動する。 alias e='cd $(ghq list -p | peco)' p GHQ - r7km/sにも書いたけど、 o と e で「pecoを使って絞り込んだ結果を他のコマンドに渡す」という処理が被ってしまったので p を用意した。 p() { peco | while read LINE; do $@ $LINE; done } alias o='git ls-files | p open' alias e='ghq list -p | p cd'
全てが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
チャットで不在時に発言されたメッセージの扱い方 - ✘╹◡╹✘
HipChatやSlackで使われているXMPPにおける不在時に発言されたメッセージの扱われ方、 というきわめてニッチでゴキゲンな話題をお届けします。 Delayed Delivery XEP-0203という拡張仕様があり、 リアルタイムではなくあとから遅れてメッセージが送られる場合の仕様が定義されている。 あるユーザにメッセージを送ったが宛先のユーザがオフラインだった場合にサーバ側でメッセージを保存しておき、 ユーザがログインしたときに再送するという用途がある。また、チャットルームでの発言履歴機能などにも関係している。 例を見たほうが早そう。 <message from='romeo@montague.net/orchard' to='juliet@capulet.com' type='chat'> <body> Goodbye, cruel world </body> </messag
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
ElasticSearch Serverを読んだ - ✘╹◡╹✘
高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者: Ｒａｆａｌ Ｋｕｃ （ｌにストローク符号、ｃにアクサン・テギュ付く）,Ｍａｒｅｋ Ｒｏｇｏｚｉｎｓｋｉ （ｎにアクサン・テギュ付く）出版社/メーカー: KADOKAWA / アスキー・メディアワークス発売日: 2014/03/25メディア: Kindle版この商品を含むブログを見る 高速スケーラブル検索エンジン ElasticSearch Server という本を読んだ。読んだ理由は、タイミングが良かったから。効率的に学ぶのに丁度いい時機というものがあると思う。何かを学ぶのには動機と情報源が必要。動機が無ければ勉学は長続きしないし、無理矢理覚えようとしても楽しくない。Elasticsearchに対しては何か面白そうという気持ちを最近少しだけ感じていて、こういう気持ちが湧くのは貴重なことだから大
雑なレビュー - ✘╹◡╹✘
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
Ruby Patterns - ✘╹◡╹✘
この記事には、Rubyを書いているときに「これは言語化されたり公式化されたりしていないけれど基本的には必ずこのパターンに則ってプログラムを書いているな」ということをふと思い出したときにやってきてそのパターンを書く。多分3パターンぐらいで終わると思う。ウケが良ければ思い出す確率が高くなると思う。題材さえあれば何も考えずに書けるので、これを書くコストは全然高くない。 名前が"?"で終わるメソッドは必ずtrueまたはfalseのどちらかを返す trueとfalse以外(例えばnil)が返る可能性がある場合は、必ず式の先頭に!!を付けてtrueかfalseになるようにしてる。 このパターンを守ることがとても大事だという風には全く考えていないけど、もしhas_user?がuserを返すとして、has_user?という名前のメソッドがUserオブジェクトを返すというのは一体どういう意味を持っているのだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HipChatを今すぐ使うべきたった一つの理由 - ✘╹◡╹✘
freeeに完敗しました - ✘╹◡╹✘
