Podcastのやっていきかた - ✘╹◡╹✘
9mとsoramugiから、やっていきエフエム という名前でPodcastをやりませんかという話を承け、Podcastをやることになった。既にサイトが公開されていて、https://yatteiki.fm からアクセスできる。昨日できたばかりで準備中なところが幾つかあるが、サイトを開いて音を聴けるという点では最低限の体験は保証されている。 10月25日にSlackチームを立ち上げ 10月28日に練習でSkypeで通話 10月29日に1回目を収録 10月30日に公開用のサイトを作成 という流れで、発足から企画、収録、公開まで進み、この順調さには当の我々ですら驚かされた。 個人的には、雑談レベルの会話が淡々と展開されていくような、例えばカンファレンスの懇親会での会話を隣で聴いているような、あるいは飯屋での雑談を隣で聴いているような、更に言えばマックで隣の女子高生のガールズトークを聴いているよう
最終掲示板戦争 - ✘╹◡╹✘
こんにちは、r7kamuraです。26年なにも考えずに生きてきて、レールに沿った人生を歩んできました。 さて、数日前からなんとなく気が触れてRuby on Railsで掲示板をつくってみている。上の画像はいまつくりかけのもの。CSS全部手で書いてみてるからまだ見てくれがかなりショボい。最初に手を動かしはじめたきっかけは、2007年頃に「Railsを使って15分で掲示板をつくってみよう！」という記事を見たのを思い出したのがきっかけ。いまのところ10時間ぐらい経過している。15分はちょっと無理そう。2016年にもなって10時間以上かけて掲示板つくってるのは皮肉すぎる事実。もはや何故掲示板をつくっていたのか分からなくなってきつつある。とりあえず濁り切らない内に考えていることを書いておく。最近なんで掲示板つくってんのって聞かれることが増えてきたので、そのときにこの記事のURL出せると多分便利。 掲
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
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
Immutable Infrastructureという考え方 - ✘╹◡╹✘
昼に起きて、溜まった家事を片付けながら、最近Immutable Infrastructureという言葉をよく聞くなと思って、語感と雰囲気から内容を考えてた。食器もまともに片付けられない人間はいるし、そういう人間はどう言っても変えられないし、最初から紙皿だけ使うようにした方が良いのかもしれない。元の状態にきちんと戻せとか文句付けるより、そもそも毎回全部捨てた方がいい。そうすることで、いつも同じ人間が片付ける羽目になるという属人性を排除することが出来る。要点は、ある種の人間を排除するのではなくて、どんな人間でもまともに生きていける社会にしようということ。紙皿のような技術が進化し、環境ごと簡単に破壊するような時代になってきたからこそ、こういう考えが生まれるようになった。
WebサイトのFeedのMIME types - ✘╹◡╹✘
主にapplication/xmlからapplication/rdf+xmlへの変遷について調べたことを書きます。 一方で、application/rss+xmlやapplication/atom+xmlについてはあまり触れません。 現在よく使われているもの application/atom+xml application/rss+xml application/rdf+xml application/xml application/rdf+xmlの仕様策定と登録 RFC3023において、XMLで記述されたRDFに対してはapplication/rdf+xmlを使うべきとされた。RDF/XMLの仕様書にて、RDF/XMLのMIME typeにはapplication/rdf+xmlを使うべきとされた。RFC3870において、application/rdf+xmlの登録についての仕様が公開さ
client-side javascript - ✘╹◡╹✘
JavaScriptのすごく初歩的なことでよくわからないので整理する。よくわかってなくてすごい恥ずかしい感じがするけど書いたら誰か何か教えてくれそうだし書く。client-sideのJavaScriptは、未だあまりよく分からずにもやもやしながら適当に書いてる。もやもや感が説明したいけどなかなか説明しづらい。 例 こういうタブをJavaScriptを使って実装する例を考える。タブをクリックすると、そのタブに切り替わるというやつ。 HTML CSS JavaScript Pattern 1 深く考えずに素朴に実装すると、こういう感じになる。clickイベントに与える無名functionの中に全部詰め込む。こういう風に書いてるJSのコードはよく見る。こういうの大量に書くのはすごい簡単だけど大量にこういうのが書かれてたら読むの辛い感じがする。 懸念 例えばこれまでRubyでコードを書いていたとき
DRY原則とテストの可読性 - ✘╹◡╹✘
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
HTML/CSS/JS製の小さなスライドツール『kyubey』をつくったよ - ✘╹◡╹✘
説明 タイトルはほとんど釣りです。奇跡も魔法もありません。最近よく勉強会をしているという話を前回のエントリで少ししましたが、プレゼンするのにいちいちKeynoteやPowerPointを開いていては骨が折れるし、参加出来なかったメンバーが後からWeb上でスライドを見たいということもあるので、自分でHTMLで手早くスライドを作るためにツールを作りました。jQueryやその他ライブラリが頑張って働いてくれたのでJS部分は実質100行弱のコード量でした。*1 kyubeyはjQueryを利用して作った小さなスライドツールです。作ったばかりなので機能はほとんどありませんが、小さいが故にコードの理解や拡張がしやすいかと思います。Githubに公開しているので良ければお使いください。ちなみに下記サンプルとソースコードを見て頂ければ大体理解出来るかと思います。機能要望があれば今後拡張していくつもりです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
