『Web API: The Good Parts』読んだ - ✘╹◡╹✘
『Web API: The Good Parts』を読んだ。贈ってくれた人達ありがとうございます。 Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (2件) を見る 目次 詳細はO'Reillyのページにて。 1章 Web APIとは何か 2章 エンドポイントの設計とリクエストの形式 3章 レスポンスデータの設計 4章 HTTPの仕様を最大限利用する 5章 設計変更をしやすいWeb APIを作る 6章 堅牢なWeb APIを作る 所感 Web API、よく知らない場合はとりあえず作りやすい方法で作っていこうという気持ちになりやすい。しかし、Web APIは後から変更するのが比較的難しいものなので、つらいものを使い続ける羽目になりやすい。また一貫性が重要視されやすいので
WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0062 号 バックナンバー Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist Magazine 0058 号 RubyKai
Webサービス開発の変遷と現在
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記
ウェブサービス，UI変えると，改悪とか，元に戻してとか，そういう意見が出る． サービス提供する側の立場では，新しいUIのほうが使いやすかったり，機能が増えたり，収益が増えたりするので，新しい方を多くの人に提供することに価値がある．使いやすいかとか，儲かるかとかは，リリースまでに調べておく必要があり，リリースの結果使いにくくなったり収益減ったりしたら，失敗ということになる． 一方で，ユーザーの立場からすると，前の方がずっと使ってて愛着があったとか，新しい方を覚えるのは手間とか，確かにという感じはする．また，ウェブサービスは最終的にユーザーの手元のブラウザで表示されて動くので，映画の結末が気に入らないから変えたいといった要望よりは，受け入れやすい．データ構造についての，サーバー側の処理についてのユーザーからの要望というのはあまりなくて，このボタンがどうみたいな，UIの要望が多いと思う． 全部置
ジモティーを支える技術 | 株式会社ジモティー
Hashです。ミームの人と呼ばれていた時期が俺にもありました。現在、株式会社ジモティーでエンジニアをやってます。公私ともにidで呼ばれ、本名を忘れがちなのが最近の悩みですが、別に悩んでいません。 ジモティーのエンジニアは5人で、基本的にまんべんなく仕事をやるもののある程度得意不得意があって、僕はインフラというかサーバの世話をすることが多いです（諸般の事情により名刺にはインターフェイスエンジニアと記載されているのですが…）。 そこで今回は「ジモティーを支える技術」と題して、ジモティーの使っている技術をざっくり紹介したいと思います。まぁタイトル使いたかっただけじゃね感あります。 Rails3 Ruby on Rails 3でWebアプリケーションを開発しています。 ウェブサービスとして見たときジモティーはいわば今風の「掲示板」で、トリッキーな作りは少ないためRailsとの相性は良いのではない
Webデザイナーが知っておきたいアプリの知識〜もしもアプリのデザインを頼まれたら？〜
ABC 2016 Springで発表した「Androidアプリ実装アンチパターン」の暫定資料だよ あとで、発表時に喋った内容をテキストで追加したものをアップロードするよ
WEBサイトを発注してみた。
アニメやゲームのキャラクター情報をまとめてるサイトがないから作りたいなぁって 思ってたんだけどhtmlは初歩しか分からないしプログラミングもできないので構想するだけで作れなかった。 ゼロから4ヶ月でWEBサービスをリリースした人の記事を見つけて｢自分にもできるかな！｣なんて思い挑戦してみたけど理解できず挫折･･･orz WEBサービスを個人で作ってる人達が羨ましいです。 それでもWEBサイトを作りたかったので制作会社に発注してみようと思い立った。 ただのキャラクターのデータベースだけではつまらないのでコミュニティ要素なども付けて ネットで見つけた制作会社に見積もってもらうと下記のようになった。 合計1,483,125円 以前、SNS｢ウェブカレ｣のサイト制作費が1千万円で安く仕上がった(潰れたけど･･･)という話があったから なんとなく3～400万くらいかかるんじゃないかなと不安だったんだ
社内向けWebサービス開発のススメ - kotas.tech
社内向けWebサービス「ニコニコプロデュース」 例えば、コードレビューをしている時に誰かが鋭いツッコミを入れてくれた時。 例えば、社内のチャットで、ふと誰かが名言を書き込んだ時。 そんな「もっと評価されるべき」を、「評価」する手段が欲しい。 そんな思いから、社内向け Web サービス「ニコニコプロデュース」を作りました。 画面はこんな感じです。 使い方は簡単で、「だれうま」とか「GJ」とか思ったらポイントをあげる。それだけです。もらったポイントの使い道は特にありません。 こんな感じで、趣味としてちょこちょこ社内向けサービスを作ったり、簡単なツールを作ったりしているので、その魅力について語りたいと思います。 作っている間 なにせ自分で1から企画して自分で全て実装するので、作っている間はとても楽しいです。 「こういうページがあってー、こういう UI でポイントをつけれてー・・・あ、ユーザー認証
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ） 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変
ウェブサービスをスタートアップするための勉強会に参加しませんか？ - IT戦記
僕たちの勉強会は、まだ始まったばかりだ…ビシッ!! m9( ・`ω・´) はじめに 皆様、最近ちょっとずつ寒かったり暑かったりしますがお元気でしょうか？ 僕は秋の花粉症でぐだぐだですが、元気です。 突然ですが 最近、「UT Startup Gym」（UT スタートアップジム）という「ウェブサービスの企画、開発」の勉強会をやっています。 ずっと知り合いの中だけでやっていたのですが。 最近、一区切りつき、もっとこの勉強会に多くの人に参加して欲しいなと思いブログを書くことにしました＞＜ みなさんは ウェブサービスを作りたいなって思ったことありませんか？ 僕はよくあります。 「なんで、〇〇みたいなサービスってないんだろーなー」とか、「もっと、こういうサービスを作ってみたいなー」とか そういうとき、自分ですぐにそのウェブサービスを作り上げることが出来たらなあと思います でも そうは言っても、なかなか
「IT業界」なんて、ないんだよ
このエントリは、新卒準備カレンダー 2011春のためのもので、@shuji_w6e さんの「実践する、コツコツと、少しづつ」の次のエントリになります。 おまえ誰よ? 高橋征義と申します。プログラマです。プログラミングはかれこれ30年近くやってますが、まともに書けるようになったのは20年近くたってからです。人間続ければ何とかなることもあるんですね（ならないこともあります）。 修士の１年のとき、高校時代の友人から「インターネットのベンチャー会社作るんだけど一緒に働かない？」と言われ、あまり何も考えずに修了後その会社に参加しました。1996年、Webが流行り始めたころのことです。 そこから一度転職をはさみ、10年以上Web業界の隅っこの方で開発仕事に励んでいたのですが、昨年３月に退職、６月に電子書籍の制作と販売を行う「株式会社達人出版会」という会社を設立して、今はそこの代表取締役です。いやまあ社
はてなに入社しました (id:y_yanbeからid:yanbeへ) - yanbe's blog
id:y_yanbe改めid:yanbeです。今年の4月から株式会社はてなにエンジニアとして入社しました。私をオフラインで知っている方々には、去年の後半ぐらいから来年度の進路を聞かれるたびに曖昧な返答をして不義理を重ねてしまい申し訳なかったのですが、ようやくご報告できるタイミングとなりました。 自己紹介と短い経緯 idが変わったので、多くの方にとっては誰この人？という感じだと思います。なので、改めて自己紹介をしたいと思います。 id:yanbeはウェブ上ではこの辺で活動してきました。 http://qrcode.sourceforge.jp/ http://yanbe.org/ http://d.hatena.ne.jp/y_yanbe/ http://subtech.g.hatena.ne.jp/y_yanbe/ http://twitter.com/yanbe はてな以外ではだいたいy
ソーシャル素人がソーシャル系ビジネスをやりながら学んだこと - ひがやすを技術ブログ
2010になって、私は感じました。ITの流れが変わった。 これからの主役は、エンタープライズではない、ソーシャル系のビジネスだと。 勘違いしないで欲しいのは、エンタープライズ系のビジネスがだめだと言っているわけではないということです。今という瞬間なら、エンタープライズ系のビジネスは重要でしょう。 しかし、儲からないし、未来はない。 これが下記のエントリにつながってきます。 SI業界からはさっさと抜けだしたほうがいい http://d.hatena.ne.jp/higayasuo/20110111/1294718077 サービスを考える人と、プログラムをする人は、求められているスキルが違うから、両方をやるのは難しいんじゃないというような、眠たいコメントもあったけど、誰もができるようなことをしてたんじゃ、それは金になりません。 誰もができないことができるから金になる。人と差別化できなければ、そ
変化するIT企業とエンジニアの関係 - developer’s delight
ここ数年で、ウェブサービスやアプリケーションを開発するエンジニアをとりまく状況は、劇的に変わったと言えるのではないでしょうか。主要なウェブサービスのデータや機能はAPIごしに利用可能になり、アプリケーションフレームワークやOSSなどの道具が多くそろい、いわゆるクラウド系のサービスのおかげで個人でインフラを用意する必要は無くなり、サービスを開発、公開する敷居がぐっと下げられました。また、AppStoreなどのプラットフォームの登場で、エンジニアは思いついたアイディアをすぐに世の中に問い、さらにそこで収益を得ることまで可能になっています。このような状況が、エンジニアと所属企業の関係を大きく変えつつあるのではないかと最近感じています。企業や組織というのは、本質的には個人で成し遂げることが難しい目標を達成すために存在するのだと思います。しかし仮に同じことが個人でもできる、むしろ会社でやるより個人で
なぜMongoDBなのか - Masatomo Nakano Blog
ここを見てもらってる人に、「MongoDBって何がいいの？」と改めて聞かれてしまって、ああ、そっか、そういうこと書いてなかったな、と思ったので、なぜ自分がMongoDBに興味を持っているのか、ということを書いてみた。いざ自分の思いを書いてみたらRails中心の話になってしまったけど、モダンなフレームワークならそんなに話は変わらないのかな、と思っている。 そもそものきっかけは、ここ半年間くらいRuby on Rails(以下RoR)で開発していることにある。 ここ半年弱ほどRoRで開発をして、それなりに満足しているのだけど、ActiveRecordに関しては色々とひっかかるところがあった。 「ActiveRecordがRoRの素晴らしいところそのものだ」と評価している人もいるが、自分の中では逆で、ActiveRecordはRoRの中でもかなりいまいちな部分。 いや、ActiveRecordと
Web 開発者の責任 (翻訳): Days on the Moon
John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。 Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。 ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。 ブラウザを支援する解決策
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hypermedia: The Missing Element to Building Adaptable Web APIs in Rails
クライアントの要望にこたえるWebサービス開発 ～「らせん型ワークフロー」のススメ～
Admiral