3.29 Sansan✕一休.com 勉強会での発表資料です
一休.com におけるフロントエンド開発 // Speaker Deck
3.29 Sansan✕一休.com 勉強会での発表資料です
僕が1週間でWebサービスを公開するまで - ぐだぐだ言ってないでコードを書けよ、ハゲ。
先日、FeedlyGraph を1週間で公開した。 photo credit: surfzone™ via photopin cc 公開までを振り返ってみる。 0日目 アイデア出し 僕は普段からこんなサービスが欲しいな〜というアイデアをメモに残すことにしている。 iCloud 便利。 今回はそこから規模感が合うものをチョイス。 1日目 アイデアの検証 問題を解決するサービスが世の中にあるかどうかを確認した。 今回は「Feedly の購読者数の推移を確認したい」が問題。 既にあった解決策に近いものは以下のとおり。 Feedly Insight Feedly Subscribers Checker 2 FeedlyやlivedoorReaderの購読者数をGrowthForecastにポストするRubyスクリプト作った 上から順に WordPress でないと使えない 今の購読者数しかわからな
wri.peのソースコードを公開しました。
schooで授業もやるし、まぁ隠しておく意味もないかなーと思ってので、wri.peのソースを公開する事にしました。 https://github.com/masuidrive/open-wripe 全部公開しているので、キーを適切にセットすれば自分で動かす事ができます。 元々、公開するつもりでは無かったので、ソースは読みやすくはなっていません（汗 pull-requestを貰えれば取り込みなども行いますので、興味のある方は直接投げてもらうか、Twitter/Facebookなどで声をかけてください。 4/1からwri.peの作り方を解説する授業を4週間schooで行いますので、興味のある方は聞いて頂けるとうれしいです。 増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの作り方〜サービスデザイン編 増井 雄一郎 先生 – 無料動画学習｜schoo（スクー） Webサービスのつくり方
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
プログラミングもクラウドへ―― 学習＆開発環境Webサービス23選まとめ
プログラミングもクラウドへ―― 学習＆開発環境Webサービス23選まとめ：安藤幸央のランダウン（67）（1/3 ページ） オンラインのプログラミング環境や、オンラインでコードを書いて学べる学習サイト9選、ビジュアル（子ども向け）プログミラングWeb環境5選を紹介する。 道具としての開発環境 今となっては昔のことですが、机の上でノートに鉛筆でソースコードを書いてプログラミングしていた時代がありました。現在のプログラミング環境から振り返ると、そういう作業はアルゴリズムを考え、頭で想像したコードを書き下ろしており、脳内エミュレーターのようなものだったのかもしれません。 最近のプログラミング環境は、規模も複雑さも肥大化しつつ、プログラミングに関する情報もツールも大変充実したものです（マイナーな環境の情報が少ないことや、新古の情報が混在している問題はありますが）。 Web上の情報も書籍も豊富で、自分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
s3pw.com
Tumblr
TechCrunch | Startup and Technology News
