MastodonをAWSでシュッと動かすやつ - ✘╹◡╹✘
Mastodon を AWS で動かしたい人のために、https://github.com/r7kamura/mastodon-terraform というのをつくった。簡単に動かすという目的以外に、Mastodon を AWS で動かすために必要な設定をコードで表現することで、どういうインフラが必要になるのかを共有しようというねらいもある。 使い方 https://github.com/r7kamura/mastodon-terraform を fork する CircleCI と連携する 適当な環境変数を与えてビルドする マストドン動く ✌(‘ω'✌ )三✌('ω’)✌三(✌'ω')✌ 別に必ず fork しないといけない訳ではなくて、copy して使ったり terraform module として参照したりしても良い。 構築される環境 ┌---------------┐ | Web B
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の周辺環境は大変で、何をやるに
モデルからJSON生成するときこうやってます2016 - ✘╹◡╹✘
最近RubyとReact.jsをよく利用していて、Rubyで扱っている値をJSONとして表現したいケースが増えてきた。こういうのどうやっていますかと人に聞きたいので、自分はこうやっていますよというのを説明のためにまとめておくことにする。 概観 自分の場合、次のような方法で実装することが多い。 JSONとして表現したいオブジェクトをコンストラクタで受け取るクラスを定義する クラスに #as_json を定義して適当なHashを返すようにする Object#to_json が再帰的に #as_json を利用するようにする (ActiveSupportがやってくれる) コード 具体的には、以下のようなクラスをつくっている。これは最近つくっている掲示板での例で、Megaboard::Resources::Comment はコメントのJSON表現のためのクラスである。いわばコメントのJSON表現に
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:
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
Amazon Lambdaにまとめてアップロードするやつ - ✘╹◡╹✘
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
ストリーム表現とその変換 - ✘╹◡╹✘
データをストリームとして表現する方法と、ストリームを変換する方法を紹介する。 ストリームはメッセージが流れる川である Pub/Subメッセージングモデルでメッセージを流すためのオブジェクトのことをストリームと呼ぶことにする。ストリームにはメッセージをPublishでき、またメッセージを受け取ったときの処理をSubscribeできる。例えばキーボードからの入力をPublishして、内容をコンソールに出力するような処理をSubscribeできる。 kamo.jsでストリームを表現する ストリームについて説明するために、kamo.jsというストリームを表現するためのライブラリをつくった。kamo.jsは、ストリームを作成するためのkamo.Streamというコンストラクタ関数を提供する。このコンストラクタ関数から作成されたオブジェクトは、publishとsubscribeというメソッド(※プロパ
APIデザインの極意 - ✘╹◡╹✘
APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の
シェル芸 - ✘╹◡╹✘
朝早起きしたので、フルスクラッチから1日でCMSを作る シェルスクリプト高速開発手法入門 という本を買ってちょっと読んだ。 シェル芸人が考えていることをテキストに起こしながらシェルでいろいろ作る様子が描かれてる。 シェルスクリプトと言えば、今日たまたまこういうシェルスクリプトを見かけた。 https://github.com/flynn/slugbuilder/blob/master/builder/install-buildpack#L16 IFS='#' read x y <<< "$url" 環境変数IFSで組込みコマンド readの区切り文字を空白文字から "#" に変更しつつ (URLの中の"#"より前をx、後をyに入れたい)、変数urlを展開しながらヒアストリングで標準入力として与えている。 echo "$url" | read ... というふうにしなかったのは、 パイプに変
scheman diff - ✘╹◡╹✘
https://github.com/r7kamura/scheman 旅行を兼ねて沖縄に開発合宿に来ているので、1日目の成果を書き出しておく。 目的 Webアプリの開発フローで次のような状態を実現したい。 DBの変更のたびに変更用のSQLやMigrationファイルを人間が書かなくて良い migrationファイルを書く代わりに人間はスキーマを編集する スキーマはSQLで記述できる (DSLの使用を強制されない) SQL以外の言語でも記述できる (DSLを使用しても良い) 方針 次のような実装を試みた。 SQLを構文解析してスキーマデータに変換する (解析器は事前に実装済み) 適用すべきSQLを2つのスキーマデータの差分から自動で計算する SQL以外の解析器も作成可能に scheman diff scheman diffというコマンドを実装した。 これは変更前後の二つのスキーマの差分を標
Give me JSON, plz - ✘╹◡╹✘
https://github.com/r7kamura/plz 13日の金曜日ということで、JSON Schemaを読み込んで動作するCLI HTTP Clientをつくった。 手元にschema.jsonかschema.ymlがあればそこに定義されてるコマンドが使える。 $ gem install plz $ curl tqchain.herokuapp.com > schema.json $ plz list user サンプルで tqchain.herokuapp.com というAPIサーバをHerokuに置いてみてる。 schema.jsonを返すAPIも生やしているので、それを手元に持ってきてplzでAPIを叩いている。 APIサーバの実装はここ https://github.com/r7kamura/tqchain
全てが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
AngularJS 勉強 方法 - ✘╹◡╹✘
急にAngularJSを覚える必要があったので教材を調べて勉強した。 Code SchoolにShaping up with AngularJSという無料で受けられる5章構成の講座があるのでこれをやった。AngularJSの歌があるのでこれだけリピートして聴いてたら大体覚えられると思う。Web上のかなりよく出来たIDEで試したりプレビューしたりできるので結構面白かった。120分ぐらい集中してやれば5章終わった。 講座終わったら何するか 他に動画形式のコンテンツも2時間分ぐらいあるので、講座終わったあとそれ見るのもおすすめ。おっさんがぐだぐだ言いながらAngularJS使ってアプリを開発していく様子が見られる。講座の最後でこういうの見ると良いっていう紹介があるのでそれ漁るのも良さそう。あとは日本語圏で情報得たいならQiitaのAngularJSタグが付いてる投稿一覧とかをざっと見るとかすると
ElasticSearch Serverを読んだ - ✘╹◡╹✘
高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者: Ｒａｆａｌ Ｋｕｃ （ｌにストローク符号、ｃにアクサン・テギュ付く）,Ｍａｒｅｋ Ｒｏｇｏｚｉｎｓｋｉ （ｎにアクサン・テギュ付く）出版社/メーカー: KADOKAWA / アスキー・メディアワークス発売日: 2014/03/25メディア: Kindle版この商品を含むブログを見る 高速スケーラブル検索エンジン ElasticSearch Server という本を読んだ。読んだ理由は、タイミングが良かったから。効率的に学ぶのに丁度いい時機というものがあると思う。何かを学ぶのには動機と情報源が必要。動機が無ければ勉学は長続きしないし、無理矢理覚えようとしても楽しくない。Elasticsearchに対しては何か面白そうという気持ちを最近少しだけ感じていて、こういう気持ちが湧くのは貴重なことだから大
雑なレビュー - ✘╹◡╹✘
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon API Gatewayに自動で定義するやつ - ✘╹◡╹✘