シリーズ判定 「Kyoto.なんか #2」というイベントで、amakanにおける書籍のシリーズ判定方法について話しました シリーズ判定最適化前線 シリーズ判定最前線 スタイル amakanのUIを変更した amakanにstylelintを導入した Docker amakanをDocker化した感想 amakanの本番環境をDockerに移行した amakanの開発環境をDockerに移行した SaaS amakan new relic 2017-03-19 amakanのCIをShippableに移行した Ruby amakanでRuby 2.3.3を使うようにした amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した Rails amakanをRails 5に移行した amakanをUnicornからPumaに移行した amakanのroutes.rb
説明用の図 例として、amakan anime のトップページ https://anime.amakan.net/ の構造を挙げながら説明する。(ところで amakan anime は今月中に完成予定のサービスで実験的に公開している状態なので、まだまだ至らないところが多々あります…) 登場するコンポーネント一覧 React.Component クラスを継承したクラスをコンポーネントと呼ぶ。主に登場するコンポーネントは以下の通り。 Header Layout Router VideoPrograms Router コンポーネント 最上位のコンポーネントとして、Router コンポーネントが存在する。このコンポーネントを利用して、ページごとにどのコンポーネントを表示すべきかを分岐させる。amakan anime のトップページでは VideoPrograms コンポーネントを描画し、amaka
Amazon Product Advertising API とは Product Advertising API は、Amazon の商品情報や関連コンテンツをプログラムを通してアクセスできるサービスを提供することで、Web 開発者の皆様が、ご自分の Web サイトでAmazon の商品を紹介することによる紹介料の獲得を可能とします。 https://affiliate.amazon.co.jp/gp/advertising/api/detail/main.html 要は、Amazon のアソシエイトを使って商品を宣伝する目的で、Amazon の商品情報を API 経由で操作することができるサービスが提供されている。この記事は、この API を Ruby から利用するためのライブラリをつくっているという話。 GitHub ソースコードは GitHub で管理されている。ライブラリの AP
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に移行した - ✘╹◡╹✘ amakanの本番環境をDockerに移行した - ✘╹◡╹✘ amakanをDocker化した感想 - ✘╹◡╹✘ CircleCIからShippableに移行した amakanをDocker化した感想 - ✘╹◡╹✘ で触れた「CIのビルドに時間が掛かるよう
https://amakan.net/ のこの辺の改善の続き。 amakanをUnicornからPumaに移行した - ✘╹◡╹✘ amakanでyarnを使うようにした - ✘╹◡╹✘ amakanでRuby 2.3.3を使うようにした - ✘╹◡╹✘ amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した - ✘╹◡╹✘ react_on_rails amakan ではサーバサイドで React.js で記述したコードを使ってHTMLを生成していて、このために react_on_rails というライブラリを使っている。このライブラリの最新バージョンが v5 から v6 に上がっていたので、まず v6 を使うように変更を加えた。 v5 までは、サーバサイドとクライアントサイドで別々の Webpack の設定ファイルを用意するような設計になっていたが。しかし
次のようなコードを書いて、 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の周辺環境は大変で、何をやるに
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を見せない という要求に
https://syncbeats.herokuapp.com/ ※利用者も減ってきたということで、現在は公開を停止しています。 syncbeats というのを作ってみました。端的に言うとSoundCloudの曲をみんなで同時再生する君 です。部屋をつくってSoundCloudのURLを適当に突っ込むと順番に再生してくれて、あとから部屋に入ってきた人も同じ位置から再生されるというやつ。試しに曲を入れてリロードしてみると、途中から再生されるのが分かる。曲が無くなると、新しい曲が追加されるのを待ち受ける状態になる。たまに壊れるんでリロードすると治る。SlackやTwitterで部屋のURLを共有して一緒に聴くみたいな使い方がいいんじゃないでしょうか。 背景 前にシェアハウスに居たときにたまにリビングで音楽掛けることがあったんだけど、SoundCloudだとその場限りのセットリストつくるのも難し
変更前 これはクライアントサイドのアプリケーションの例で、Modelの背後でWeb APIやonpopstate/pushStateを利用しており、Modelが太くなってる様子。 HTTP History | ^ | ^ | | | | v | v | .---- View <-- M o d e l <-- Intent <--. | | `----------------> DOM -------------------' 変更後 Web APIもonpopstate/pushStateもアプリケーションの外側にあり、DOMと同レイヤに存在するものであると位置づける。アプリケーションの外界とのやりとりを行う、ビジネスロジックを含まないアダプタを、ドライバーと呼んで抽象化する。ドライバーには入力を受け取る機能と出力を購読させられる機能がある。いまつくってるアプリでは以下の2つのドライバー
最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、本体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある
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風のデザインを
帰宅後に r7kamura/fluct の開発をちょっと進めて、AWS Lambdaの関数でHTTPリクエストのパスとかリクエストボディの内容とかを取れるようにした。文字で説明しただけでは意味が分からないだろうと思いデモを用意しましたのでこちらをご覧ください。 https://os92ef4zmf.execute-api.us-east-1.amazonaws.com/production/echo us-east (バージニア) のAmazon API Gatewayにos92ef4zmfというIDのREST APIを作成してあって、これのproduction環境にGET /echoというエンドポイントを用意している。このエンドポイントは内部でAWS Lambda上に作成したshow_echoという関数を実行するように設定されていて、show_echoはAPI Gatewayから受け取っ
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
https://github.com/r7kamura/api-gateway-lambda-example Amazon API GatewayとAmazon Lambdaを一緒に管理できるようなツールをつくろうとしてて、とりあえずサンプルアプリをつくりながら徐々にツールに切り出していこうという方針でやってみている。 . |-- README.md |-- functions | |-- function1 | | |-- package.json | | `-- src | | `-- index.js | `-- function2 | |-- package.json | `-- src | `-- index.js |-- gulpfile.js `-- package.json サンプルアプリは手短に言うと上のようなファイル構成になっていて、作成したいAmazon Lambda
https://github.com/r7kamura/aws-signer-v4 Amazon API GatewayのREST APIを利用したかったんだけど、Node.js用のaws-sdkにはまだその機能が入っていないこともあり、自分で認証するためのライブラリを書いた。リクエストのメソッド、URL、ヘッダ、ボディ、AWSのAccessKeyID、SecretAccessKey、リージョンを、決められた手順に従って加工し、Authorizationリクエストヘッダに入れることで認証が通るようになる。その決められた手順を実装した。詳しい仕様は AWS Signature version 4 のページに記載されているがほとんどの人間は読む必要は無い。自分でこのロジックを実装したいなら、JavaScriptの場合は aws-sdk-js/lib//signers/v4.js にAWSのSD
ChefやAnsible、Puppet、Itamaeなどの構成管理ツールをあまり使ったことがなく、勉強のためにServerkitというのをつくってみたので、現状こういう感じでやってみましたというのを書き残しておく。作り手の気持ちになればこそわかるものがあるだろうと思う。 ところで去年も似たような記事を書いた。 概要 Serverkitというのは、前述した通りChefやAnsibleのような構成管理ツール。マシンの理想的な状態をレシピと呼ばれるファイルに定義しておき、現在のマシンの状態と比較してその差分を埋めるためのもの。Rubyで書かれていて、手元にversion 2.0.0以上のRubyと、Serverkit、それからServerkitが利用している幾つかのライブラリが入っていれば動作する。Serverkitを動かすマシンと同じマシン、もしくはSSHで接続できるマシンに対して実行できる。
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 作者: 秋山浩一出版社/メーカー: 日科技連出版社発売日: 2010/10メディア: 単行本購入: 7人 クリック: 153回この商品を含むブログ (19件) を見る 『知識ゼロから学ぶソフトウェアテスト』読んだ - ✘╹◡╹✘ を書いたところ、知り合いのテストエンジニアにこれオススメだよと勧めてもらい『ソフトウェアテスト技法ドリル』を読んだ。読みながら、どこでテストを書くのを満足すれば良いのか、このトレードオフはどんな条件下でどういう状態になるのか、テストについて常に信じられるものは何なのか、ということを考えていた。 なんでテスト書いてるのか まあ四年前の本なのでググればレビューも沢山出てくるしとりあえず本のことは置いといて、テスト書くときにいかに雑な仕事してるかという話でもしたい。日々コードを書いていると、たまに「なんでテスト書い
デザインの骨格 作者: 山中俊治出版社/メーカー: 日経BP社発売日: 2011/01/25メディア: 単行本購入: 5人 クリック: 161回この商品を含むブログ (30件) を見る 年末に読もうと、幾つか会社から本を持って帰ってきていた。その内の一冊、山中俊治の「デザインの骨格」というブログを再構成して書籍化した『デザインの骨格」を読んだ。元々がブログに書かれていたものということで、平易で、専門的過ぎず、諸所に解説もあり、読みやすい内容。自分もこういう文体で文章が書けたら良いなと思うところがあった。 過程の思考 本の中では、著者がこれまでに経験したデザインの過程において、どんなストーリーがあったか、どんなことを考えていたか、ということが綴られている。自分にも、日々ものをつくる上で考えていることが山のようにある。それこそ、文字に起こせば書かれるプログラムの何十倍もの思考がそこにある。きっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
