amakan の React コンポーネント設計 - ✘╹◡╹✘
説明用の図 例として、amakan anime のトップページ https://anime.amakan.net/ の構造を挙げながら説明する。(ところで amakan anime は今月中に完成予定のサービスで実験的に公開している状態なので、まだまだ至らないところが多々あります…) 登場するコンポーネント一覧 React.Component クラスを継承したクラスをコンポーネントと呼ぶ。主に登場するコンポーネントは以下の通り。 Header Layout Router VideoPrograms Router コンポーネント 最上位のコンポーネントとして、Router コンポーネントが存在する。このコンポーネントを利用して、ページごとにどのコンポーネントを表示すべきかを分岐させる。amakan anime のトップページでは VideoPrograms コンポーネントを描画し、amaka
amakanをUnicornからPumaに移行した - ✘╹◡╹✘
移行したぞ、というだけで特に技術的な知見の無い記事です。 移行の背景 https://amakan.net/ という、レビューの無いシンプルな読書管理サービスを2016年7月から運営している。 5ヶ月ほど運用している中で、利用してくれている人達に色々な意見をもらうことができて、これに対応して年末に時間を取って大きく改善しようとしている。しかし「年末に時間を取ってやろうとしていて...」という発言は明らかに危険信号で、高確率で「結局やれなかったよHAHAHA」ということになるのが目に見えている。そこで、年末に向けて小さな改善を徐々に積み重ねていくことで、モチベーションを高めつつ、新たに変更を加えることへの心理的障壁を無くそうと目論んでいる。今回はその一環として、amakanを動かすWebサーバをUnicornからPumaに変更することで、改善を図ることにした。 amakanの事情 amaka
katatema.js - ✘╹◡╹✘
次のようなコードを書いて、 import React from "react" export default () => <div>Hello!</div> 次のようなコマンドを叩くと、 katatema build 次のようなファイルが生成されるという、katatema というツールをつくった。 <!DOCTYPE html> <html> <head> </head> <body> <div>Hello!</div> </body> 最先端の消耗 前に キーボードショートカットをカスタマイズするブラウザ拡張 - ✘╹◡╹✘ で、こういうことを書いた。 id:moznion へ、寒い日が続きますがお元気ですか。ともあれChrome拡張を1つこさえれば、大の大人が寄ってたかってモダンと言い合う類のものが一通り学べるだろうと思います。 最近のJavaScriptの周辺環境は大変で、何をやるに
Ruby on Rails on React on SSR on SPA - ✘╹◡╹✘
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を見せない という要求に
汎用絵文字ライブラリ Somemoji - ✘╹◡╹✘
ここ最近絵文字で遊んでいて、Somemoji というライブラリをつくったので知見を共有します。 さまざまな絵文字セット 様々なプラットフォームのために、様々な組織が、様々な絵文字セット (絵文字画像の集合) を提供しています。 Apple emojidex EmojiOne Facebook Google HTC LG Microsoft Mozilla Samsung Twitter 大抵の絵文字セットはUnicodeのEmojiの仕様に則って実装されていて、このコードポイントに対応する絵文字画像はこれ、というように互換性があります。Unicode 6.0, Unicode 7.0, Unicode 8.0, ... とバージョンが増えるに従って定義されるEmojiの数も増えていっているので、それぞれの絵文字セットごとに対応具合はまちまちという状況ではあるものの、よく使う主要なものについ
掲示板のJavaScriptこういう風に最適化しました - ✘╹◡╹✘
最近Railsで掲示板つくってて、サボって後回しにしていたJavaScriptの最適化をやりました。 掲示板の構成 Webpackを使っている Reactを使っている Server-Side Renderingをやっている Railsを使っている Sprocketsを使っていない 作業内容 webpack-bundle-size-analyzerで容量の大きいpackageを調査 HTTPクライアントに利用していたjQueryを撤廃 HTTPクライアントにaxiosを採用 lodashを一部しか読み込まないように変更 moment.jsの不要なlocaleを読み込まないように設定 変更結果 これでminify後の容量が770KB→476KBに。gzip圧縮状態では202KB→125KB。 $(npm bin)/webpack --profile --json | webpack-bundl
モデルからJSON生成するときこうやってます2016 - ✘╹◡╹✘
最近RubyとReact.jsをよく利用していて、Rubyで扱っている値をJSONとして表現したいケースが増えてきた。こういうのどうやっていますかと人に聞きたいので、自分はこうやっていますよというのを説明のためにまとめておくことにする。 概観 自分の場合、次のような方法で実装することが多い。 JSONとして表現したいオブジェクトをコンストラクタで受け取るクラスを定義する クラスに #as_json を定義して適当なHashを返すようにする Object#to_json が再帰的に #as_json を利用するようにする (ActiveSupportがやってくれる) コード 具体的には、以下のようなクラスをつくっている。これは最近つくっている掲示板での例で、Megaboard::Resources::Comment はコメントのJSON表現のためのクラスである。いわばコメントのJSON表現に
最終掲示板戦争 - ✘╹◡╹✘
こんにちは、r7kamuraです。26年なにも考えずに生きてきて、レールに沿った人生を歩んできました。 さて、数日前からなんとなく気が触れてRuby on Railsで掲示板をつくってみている。上の画像はいまつくりかけのもの。CSS全部手で書いてみてるからまだ見てくれがかなりショボい。最初に手を動かしはじめたきっかけは、2007年頃に「Railsを使って15分で掲示板をつくってみよう！」という記事を見たのを思い出したのがきっかけ。いまのところ10時間ぐらい経過している。15分はちょっと無理そう。2016年にもなって10時間以上かけて掲示板つくってるのは皮肉すぎる事実。もはや何故掲示板をつくっていたのか分からなくなってきつつある。とりあえず濁り切らない内に考えていることを書いておく。最近なんで掲示板つくってんのって聞かれることが増えてきたので、そのときにこの記事のURL出せると多分便利。 掲
WikiHubの開発意外と続いてる - ✘╹◡╹✘
前回の記事 あのWikiHubが天下Wiki武道会に参戦 - ✘╹◡╹✘ で触れたけど、先月から WikiHub というWikiをつくっていて、趣味程度ではじめたものの結構な勢いで開発が続いてる。 最近の変更点 ここ最近の新機能として、 SSL対応 GitHubアカウントでのログイン エクスポート機能 ページテンプレート機能 Markdownでチェックボックスつけられるやつ HipChat・Slack連携 Webhook 二段階認証 などを実装してみたりしていた。CHANGELOG - WikiHub Help に変更点を書いていってあるので、ここ見るともっと詳しい様子が分かって便利。今日これやったぞーっていうのまとめて公開しておくとがんばった感が出るので、WebサービスとかでもCHANGELOGを書いて公開していくのは良い取り組みだと思いました。よく考えたらやってない感も出るので諸刃の剣
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:
UIコンポーネント集 Qiita:Coat - ✘╹◡╹✘
LTを聞いているという感覚でご覧ください。 Qiita:Coat Qiita用のUIコンポーネント集 GitHub用のUIコンポーネント集をForkしてつくりはじめた レポジトリ: https://github.com/increments/qiita-coat デモサイト: http://increments.github.io/qiita-coat/ 今週月曜からやってる これはcommit数 Qiita:Coatが必要に感じた背景 全ての開発者に共通する願い 高速に開発したい 秩序がほしい (a.k.a. 最低限度の品質の保証) 開発体制の情勢に起因する理由 開発人数が徐々に増えつつある 社員11人+アルバイト3人 四半期に1人ぐらい増えてる 50人が51人になるとかならともかく、5人が6人とかになると大きく変わる その他の理由 サポートサイトや採用サイトなどQiita風のデザインを
最近のAPI活動 - ✘╹◡╹✘
進捗 2015-07-27 API Gateway用にRubyでSwagger触るやつ書いた 2015-07-30 Node.jsの練習にHTTPクライアントつくった 2015-07-31 Node.jsでAWSのAPIで認証するやつ書いた 2015-08-02 Node.jsでAmazon API Gatewayのクライアント書いた 2015-08-03 Amazon API Gatewayに自動で定義するやつ 2015-08-04 Amazon Lambdaにまとめてアップロードするやつ 2015-08-05 SwaggerをAPI Gatewayに反映させるやつ 2015-08-06 LambdaとAPI Gatewayまとめて管理するやつ 2015-08-07 LambdaとAPI Gateway用のWAF 2015-08-08 fluctでAPI GatewayやLambdaと仲
fluctでAPI GatewayやLambdaと仲良くやる - ✘╹◡╹✘
https://github.com/r7kamura/fluct というのをつくってて、これを使ってAmazon API GatewayとAmazon Lambda上に簡単にWebアプリをつくれるようにしたいなあと思っている。そうなると、Amazon API GatewayとAmazon Lambdaが適したWebアプリをつくるにあたっては、サーバの用意や管理が要らず、簡単にWebアプリを公開でき、複数の検証環境を手軽に用意でき、エンドポイントごとに独立してデプロイでき、まあまあスケールし、24時間自分専用のサーバを動作させないぶんそれなりに安く、AWSと運命を共にできるといった環境が手に入る。 インストール fluctはNode.jsで書かれていて、npm経由でインストールできる。なぜNode.jsかと言うと、Amazon LambdaでNode.jsかJava 8しか動かないのでNo
APIクライアントを自動生成するやつ - ✘╹◡╹✘
Heroicsという、JSON Schemaを元にAPIクライアントのコードを自動生成するやつを見た。 Heroicsにはbin/heroics-generateというコマンドラインツールが付いていて、JSON Schemaを解析したあと、 client.erbというERBのテンプレートに解析結果のオブジェクトを渡した結果、client.rbという雑なファイルを生成する。 $ gem install heroics $ heroics-generate SuperAwesomeClient schema.json https://api.example.com > client.rb Heroicsから生成されるもの JSON Schemaからこんな感じで使えるやつを生成してくれる。 # client.rb client = SuperAwesomeClient.connect(api_k
Serverkitつくった - ✘╹◡╹✘
ChefやAnsible、Puppet、Itamaeなどの構成管理ツールをあまり使ったことがなく、勉強のためにServerkitというのをつくってみたので、現状こういう感じでやってみましたというのを書き残しておく。作り手の気持ちになればこそわかるものがあるだろうと思う。 ところで去年も似たような記事を書いた。 概要 Serverkitというのは、前述した通りChefやAnsibleのような構成管理ツール。マシンの理想的な状態をレシピと呼ばれるファイルに定義しておき、現在のマシンの状態と比較してその差分を埋めるためのもの。Rubyで書かれていて、手元にversion 2.0.0以上のRubyと、Serverkit、それからServerkitが利用している幾つかのライブラリが入っていれば動作する。Serverkitを動かすマシンと同じマシン、もしくはSSHで接続できるマシンに対して実行できる。
『ソフトウェアテスト技法ドリル』読んだ - ✘╹◡╹✘
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 作者: 秋山浩一出版社/メーカー: 日科技連出版社発売日: 2010/10メディア: 単行本購入: 7人 クリック: 153回この商品を含むブログ (19件) を見る 『知識ゼロから学ぶソフトウェアテスト』読んだ - ✘╹◡╹✘ を書いたところ、知り合いのテストエンジニアにこれオススメだよと勧めてもらい『ソフトウェアテスト技法ドリル』を読んだ。読みながら、どこでテストを書くのを満足すれば良いのか、このトレードオフはどんな条件下でどういう状態になるのか、テストについて常に信じられるものは何なのか、ということを考えていた。 なんでテスト書いてるのか まあ四年前の本なのでググればレビューも沢山出てくるしとりあえず本のことは置いといて、テスト書くときにいかに雑な仕事してるかという話でもしたい。日々コードを書いていると、たまに「なんでテスト書い
リモートワークの地味な知見 - ✘╹◡╹✘
華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
「オブジェクト指向でなぜつくるのか」を読んだ - ✘╹◡╹✘
オブジェクト指向でなぜつくるのか 第2版 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2014/03/05メディア: Kindle版この商品を含むブログ (2件) を見る TL;DR 多くの人の「この本を読むべきかどうか」という関心事に先に回答しておくと、「万人が読んでおいて損は無いとまでは言い切れないけれど、オブジェクト指向に興味があって元気もあるという奇特な人間は読んでも良い」です。 オブジェクト指向とは何か 平澤 章さんが書いた「オブジェクト指向でなぜつくるのか」という本を読みました。オブジェクト指向を「難しいソフトウェア開発を楽に行うための総合技術」と表現しながら、「オブジェクト指向とは何か」という問いに対して現実的な解を与えようという一貫した姿勢に親しみを覚えました。 保守や再利用を目的とした技術 目的という側面では「オブジェクト指向はソフトウェアの保守や再利用をしやす
他のホストのコンテナに接続するパターン - ✘╹◡╹✘
他のホストのDockerコンテナには接続しづらい 1つのホストの上で複数のDockerコンテナを動かす場合、あるコンテナからあるコンテナに接続するためにはコンテナに付けた名前が利用できる。具体的には、コンテナの名前をもとにDockerが環境変数を提供してくれて、そこにアドレスとポート番号が入っている。しかし、複数のホストの上で複数のDockerコンテナを動かす場合、他のホストで動作しているコンテナに接続したいのであればこの方法は利用できない。単純に接続先のホストのアドレスとポート番号をコンテナ起動時に指定する方法もあるが、この方法では他のホストに接続する全てのコンテナに対して逐一指定する必要がある。 ホストごとにリバースプロキシを置く 他のホストのコンテナへ接続するためのリバースプロキシとなるコンテナを各ホストごとに設置する。これにより、他のホストのコンテナに接続したい場合でも、あたかもコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
