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を見せない という要求に
APIデザインの極意 - ✘╹◡╹✘
APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の
全てが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
Ruby Patterns - ✘╹◡╹✘
この記事には、Rubyを書いているときに「これは言語化されたり公式化されたりしていないけれど基本的には必ずこのパターンに則ってプログラムを書いているな」ということをふと思い出したときにやってきてそのパターンを書く。多分3パターンぐらいで終わると思う。ウケが良ければ思い出す確率が高くなると思う。題材さえあれば何も考えずに書けるので、これを書くコストは全然高くない。 名前が"?"で終わるメソッドは必ずtrueまたはfalseのどちらかを返す trueとfalse以外(例えばnil)が返る可能性がある場合は、必ず式の先頭に!!を付けてtrueかfalseになるようにしてる。 このパターンを守ることがとても大事だという風には全く考えていないけど、もしhas_user?がuserを返すとして、has_user?という名前のメソッドがUserオブジェクトを返すというのは一体どういう意味を持っているのだ
DRY原則とテストの可読性 - ✘╹◡╹✘
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
