Increments社を退職します
昨年の5月からIncrements社でQiitaの開発に従事していましたが、今月末をもってIncrements社を退職します。在籍期間は10ヶ月。今日が最終出社日です。 Incrementsでは、Qiitaの機能追加開発を主に担当していました。Qiita Blogには、僕がリリースしてきた機能が掲載されています。 yoichiroがIncrementsにJOINしました - Qiita Blog Email Markupに対応しました - Qiita Blog 外部リンクへの属性が変わります - Qiita Blog (僕が実作業者) Qiita Organizationで組織の紹介などを書ける「About」の提供を開始しました - Qiita Blog details,summary要素に対応し、投稿内で指定箇所を折りたためるようになりました - Qiita Blog 「Qiita Ad
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
ハッカソンというイベントの目的とは何だったのか
おそらく僕がハッカソンを主催しだしたのは、2007年頃です。その時は、ハッカソンという言葉自体がまだほとんど知られていなくて、本当に珍しいことを始めたって感じだったのを記憶してます。そしてそれから8年以上が経過して、ハッカソンという言葉は広く認知されたのと同時に、その言葉が指すイベントがどのようなものなのかが「人によって認識が違う」状況となってしまいました。もちろん、好きに定義して良いことなんだけど、そもそも僕がハッカソンをデベロッパーコミュニティとやり始めたときにどんな認識でいたのか、今一度ここで再確認しておきたいな、と。 下記の内容は、ここで当時一緒にハッカソンを主催していた方々との会話から、僕が個人的に改めて当時の認識を言葉にしてみた文章です。 ハッカソンの目的 まず、ハッカソンの本来の目的がなんだったのか、ですが、これは以下でした。 普段の仕事では作らない/作れない何かを「試しで」
options_form_collection_for_selectの初期選択が効かない
アプリケーションでは，データベース内に格納された各種マスタの一覧から１つ選択する，という行為が良く行われる。Webアプリケーションにおいて，マスタの内容を一覧表示する際は，selectタグとoptionタグの組み合わせが多く使われる。Ruby on Railsのactionpackに含まれるaction_viewヘルパーには，あるモデルの集合からoptionタグのセットを生成してくれる便利な機能が提供されている。それが，options_from_collection_for_selectメソッドである。 options_from_collection_for_selectメソッド(やたらと長い)の基本的な使い方として，例えばnameとuser_idという両方とも文字列の属性を持つUserクラスのインスタンスの集合@usersがあったとき， とすることで，name属性を表示文字列に，user
Javaのgetter,setterメソッドは（特に）GUI部品のための規格だった話
こんな記事があった。 「 getter/setterとはなんだったのか」- プログラマーの脳みそ JavaBeansはGUIなどで再利用可能なコンポーネントを提供する際の規格のようなもので(僕もあまり詳しくない)2000年ぐらいにGUIのコンポーネントを作るときに意識したような、どうでもよかったような、イマイチ恩恵が実感できなかった代物だった JBuilder2とか3の頃のJava開発といえば、AWTやSwingといったGUIアプリケーションを作ることがまだ当たり前だった時代。「部品」といえば、GUI部品のことを指していました。GUI部品といえば、ペタペタツールの存在を忘れてはなりません。当時のJava IDEは、こぞってVisual Basicの開発環境に追いつけ追い越せという状況だったんです。 それらのIDEが目指したもの、それは「コーディングなしでGUI画面を作れるようにすること」で
App Linksの技術文書を和訳してみました
App Linksの技術文書を和訳してみました Written on May 12, 2014. Posted in Web Technologies 4月20日に行われたFacebookの開発者向けイベント「F8」にて、App Linksという新しい仕様が発表されました。これは、今までのWebでのページ間リンクのように、スマートフォンアプリ間の「ディープリンク」を可能にするための標準的な手続きになるべく発表されたものです。具体的な仕様について、さっそく和訳をしてみました。これだけ読んでもちょっと理解するのが難しいのですが、参考になると幸いです。 原文は、 http://applinks.org/documentation/です。 App Linksの公開 App Linkメタデータの公開は、あなたのコンテンツ内にタグを数行追加するだけという単純さです。あなたのコンテンツにリンクするアプリ
僕が考えたRuby on RailsとDojo toolkitで作るWebアプリのデザインパターン
今年の前半、ある限定した範囲で使うツールを以下の構成で作ってました。 Ruby 1.9.3 Rails 3.2 Dojo toolkit 1.7 Railsで何かを作るのが久々だったこと、 Erlangで最初作ったものをRubyベースでPortingすること、という背景があったのですが、実際に僕がRubyベースで書き直したときの書き方が結構満足いくものだったので、それをここで紹介してみたいと思います。もちろん、ドメインモデルへの考え方、RESTfulなWebアプリケーションの作り方、MVCモデルの適用、などなど「Railsならこうするだろ」というものがありますが、 「 広く一般に言われているセオリーは一切気にせず自分が作りやすい組み方をする」 という至極自己中心的な考えを持って確立されたのが以下に説明することになります。 すっごく違和感を持つ人も多いと思いますが、「こんな作り方もできるんだ
text/uri-listリソースの書式
普段よく使っているMIME Typeとして、例えばtext/plain、text/html、application/json、image/jpegといったものは見たことがあると思います。HTTPで情報のやり取りをする際にはこういったものが良く使われると思いますが、Web Intentsとなるともう少し細かく、そしてバリエーションが効いたMIME Typeが使われるようになると予想されます。 例えば、 webintents.orgのページでは、text/uri-listという見慣れないMIME Typeが良く出てきます。Drag&Dropを実装したことのある人は、もしかしたら知っているかもしれません。このtext/uri-listの仕様は、 RFC 2483 - URI Resolution Services Necessary for URN Resolutionのセクション5にて説明され
最近のセマンティックウェブとSEOな関係
最近では多くのWebサイトでFacebook LikeボタンやGoogle +1ボタン、それにmixiチェックボタンを見るようになりました。それらのボタンを押すと、各サービスで登録された知り合いに情報が伝播されます。すでに説明するまでもなく、このソーシャルなシェア行為は普及しているわけですが、これはWebコンテンツをソーシャルネットワーキングサービスにて消費するという「Webのソーシャル化」の第一歩（半歩程度かもしれないけど）と位置づけられています。 基本的にはWebサイトの内容を特に変更しなくても、上記のボタン群をそのWebページ上で配置することは可能です。しかし、その結果シェアされる情報（これはフィードという形でユーザに表示されます）は、残念ながらかなりショボい内容となってしまうことでしょう。つまり、ボタンが押され、各サービスがそのWebページ内の情報を覗き見る際に、「このWebサイト
updated_atを自動でセットしないようにする方法
データベースに格納される情報は，「作成日時」や「更新日時」を付与することが多い。ActiveRecordでは，作成日時や更新日時について，暗黙的にセットする機構が標準で備わっている。例えば， class CreateEmployees < ActiveRecord::Migration def self.up create_table :employees do |t| ・・・ t.column :created_at, :timestamp t.column :updated_at, :timestamp end end ・・・ end というように表を作成しておけば，created_atにinsertされたときの作成日時が，updated_atにはupdateがかかる度にその時の日時が更新日時としてセットされる。プログラマが改めて「emp.updated_at = Time.now」な
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Account Linking "Implementing Account Linking"の日本語訳です
母校にて3年生向けに講演をしてきました