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
Web ComponentsのWebブラウザ別動作を調べてみた
Web Componentsでは、標準技術として幅広いWebブラウザで利用可能とすべく、Polyfillという名の「未対応Webブラウザ向け実装」が開発され、すでに利用可能です。このPolyfillを使うことで、Chromeだけでなく、Firefox、Opera、そしてIEでもWeb Componentsを動作させることができます。 では、実際どこまでPolyfillでWeb Componentsが動作するのでしょうか？Polyfillとして適用するのは、もちろん platform.jsです。これを使って、複数のWebブラウザで動作検証をちょっとしてみようと思います。試してみたのは、以下の3つです。 基本的なWeb Componentsの動作確認 HTMLElement#createShadowRoot()の動作確認 Shadow DOMのCSSスコープ それぞれ見ていきましょう。 基本的
AngularJSにてMaterial Designサポートの開発が進められているようです
先日行われたGoogle I/Oで華々しいデビューを飾ったMaterial Design。Appleのフラットデザインをさらに推し進めて、視覚効果がリッチになったり、情報を読んでいく際のナビゲーションが規定されていたり、さらに当たり前のようにレスポンシブな仕上がりになっていましたね。個人的な印象は「とにかく派手！見た目重視フィードバック重視！」でした。操作した際の楽しさが考えられてるって感じましたが、皆さんはどう思いましたか？ 基本的なUI部品の視覚効果を見て、「あ、さっそく使ってみたい！」って思いますよね。特に、ずっとBootstrapを使ってきた開発者は、Material Designに乗り換えたい！Polymerやってみたい！って思ったことでしょう。僕もそのうちの一人です。さらにPolymerによってWeb Componentsの波はすぐそこまで来ているので、早く自分のものにしておき
ミクシィ社を退職しました
3年と10ヶ月ちょい勤務したミクシィ社を退職しました。正確には今月末までですが、余ってた有給休暇を2週間ほど使うので、最終出社日としては先週の金曜日でした。 「退社」というか「退職」というかを調べていたのですが、「退職」という方が正確っぽいですね。退社だと「勤務を終えて家に帰ったこと」も意味として含まれるらしいです。確かに「退社願」は書かずに「退職願」を書きますよね。つまりはそういうことです。 入社からずっと一貫して「mixi Platform」の構築に従事してきました。 mixi Developer Centerに載っている内容が、僕がやってきた全てと思っていただければ大丈夫です。無事にソーシャルゲーム、ソーシャルアプリという市場を作り出すことはできたかな、と思います。今では他社の勢いがすごいですけど、そういった他社の方々とも手を取り合って大きな市場の形成に寄与できたと思ってます。200
僕が考えたChrome拡張機能を作るときのデザインパターン
最近いくつかのChrome拡張機能を作っていて、すでに数千人のユーザを獲得できているものが出てきてたりします。 Image collector extension goo.gl URL Shortener extension mixi Check button extension Semantic inspector これだけ作ってると、何となく自分でのChrome拡張機能を作り出す際のデザインパターン・・・っていう大それたものじゃないけど、ようはテンプレが確立されてきます。全く褒められない書き方をしているかもしれませんが、ここでそのテンプレ達を晒しておこうかな、と思います。 manifest.json まずはChrome拡張機能の要であるマニフェストファイルです。これは誰が書いてもさほど変わらない記述内容となるでしょう。 { "manifest_version": 2, "name":
JExcelApiの使い方
「 Excelファイル生成ライブラリ調査！」で取り上げたJExcelApi，さっそく実際に使ってみた。なかなかいい感じなので，基本的な使い方をここに残しておこう。 まずは， JExcelApiのプロジェクトページから， jexcelapi_2_5_3.zipファイルを入手し，適当な場所に展開する。その中のjxl.jarファイルがJExcelApi本体である。これをクラスパスに通せば，使用準備は完了だ。 さて，さっそくコーディングの方法に入ろう。トピックごとにコードを紹介する。 【ワークブックの新規作成】 WorkbookSettings ws = new WorkbookSettings(); ws.setLocale(new Locale(“ja”, “JP”); ws.setEncoding(“Windows-31J”); OutputStream os = …; WritableWo
Wicket勉強会を行いました
先日の8月10日，java-ja主催の「 第一回チキチキ そろそろ Wicket について一言いっとくか」，つまりWicket勉強会が開催された。 今回も，yoshioriさんの書道から始まった。 スピーカーは5人の予定だったのだが，仕事の都合で2名が時間までにかけつけることができず。一人は実務でWicketを使っている方だったので，非常に残念だった。 トップバッターはonkさん。Wicketの基本的な紹介とデモが主な内容だった。とはいえ，nekopさんやyone098さんからのするどい質問などにより，かなり細かな動作原理まで取り上げられる結果となった。 次は，カスタムコンポーネントの作り方をyoshioriさんにプレゼンしてもらう。実は，この題目は僕がお願いしたものである。ちょっと専門的だったので，作成の手軽さは何となく伝わったとは思うが，詳細についてはWicket未経験者にとっては難し
DIコンテナの設定ファイル書くの？書かないの？
DIコンテナの設定情報，つまり「オブジェクトの依存関係」や「オブジェクトの設定内容」について，規約重視で暗黙のものとするか，ファイルに記述することで形式のものとするかは，個々人によって主張が異なるようである。何が何でも設定ファイルを書かない，あるいは，何が何でも設定ファイルを書く，といった「原理主義者」も多く，多くの場合は彼らの説明に「コンテキスト」が含まれない。よって，主張を聞いても，実際に何らかのDIコンテナを使う際をイメージした場合，その主張に沿う部分と沿わない部分が僕個人の中で発生し，完全に主張を受け入れられないことがよくある。 結局のところ「DIコンテナをどう使うか」（＝上記で言ったコンテキスト）によって，暗黙知とするか形式知とするかを判断しなければならないと思っている。 DIコンテナの適用パターンとして代表的なものは，「View，Business Logic，Dao」といった3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サンドボックスで遊びましょう！