2016年4月19日にシナップ社内で開催されたアクセシビリティ勉強会で使用したスライドです。Read less
前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((
1. はじめに 先日、某セキュリティ系の勉強会で「AIにWebアプリケーション診断をさせてみる」と題し、Webアプリケーション診断(以下、Webアプリ診断)を行う人工知能(以下、診断AI)のデモを行ったところ、意外にも好評でしたので、本Blogで少し深堀したいと思います。 なお、本Blogでは機械学習アルゴリズムにも触れますが、これらの詳細な解説は行っておりません。機械学習アルゴリズムの詳細については、「6.参考文献」に示した書籍やWebサイトで解説されておりますので、そちらでご確認いただければ幸いです。 それでは、診断AIの概要について解説を始めます。 2. 最終目標 以下の動作を実現できる「診断AI」を目指して開発を進めています。 「人間の診断員と同じように、診断対象のWebアプリをクローリングしながら診断を行い、発見した脆弱性を開発者、または、サイトオーナに報告することができる。」
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム(16年の歴史があります)の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。(リアルにセッション終了後、1時間くらい胃痛がズキズキしてました) 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
「プログラミングを学ぼうと瞬間最大風速的に意識は高くなるものの、一人でいると気がついたら一日ソシャゲして夕方頃に『また今日も勉強できなかった』と自己嫌悪。」モチベーションが続かない時の対策をはじめ、学び方、学べる環境の作り方をまとめています。
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね!また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
CSS SANS は、WEB上でデザイン・文字組をするためのプログラミング言語 CSS でつくられたフォント。 WEBの歴史・進化を映し出し、時代に合わせて形を変える、これまでにないフォントです。 CSS SANS is the font created by CSS, the programming language for web designing and typesetting. It is an unprecedented font that reflects history and evolution of the Web, and even changes its own shape. フォントの成り立ちHow the font is madeCSS でできることは、WEBページのレイアウトを整えたり、文字組・文字間の調整をしたりなど、様々。 ただひとつ、「文字自体をデザイン
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。Read less
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの?」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
Original:Design Engineering(2014-11-25)by Jonathan Snook JavaScriptだけがフロントエンド開発ではない。それはデザインとディベロップメントの技術が人種のるつぼのように融合したものである。それはアクセシブルなUIを実装するためであり、Web標準を受け入れるものである。 — Matt Hill Shopify Adminの開発に関して言えば、最近まで2つの専門職、つまりデザイナーとエンジニアを受け入れていた。今では3つめの専門職がある、しかしながらそれが確かなものとして認識されるまで時間がかかった、フロントエンドデベロッパーである。フロントエンドデベロッパーのスキルはデザインとエンジニアリング両方にまたがっている。これまでクオリティの高いフロントエンドコードをフロントエンドデベロッパーの助けもなしに書けるデザイナーを雇えて、私たち
それって本当にオリジナル? レスポンシブ?フラット?ビデオをつかった背景?CSSアニメーション?ゴーストボタン?いろいろな『トレンド』を見て勉強している間に、すべて導入されている 14ドルのテンプレートをすぐに手に入れることができます。 CMS を活用して情報が更新しやすいレストランサイトを構築したい?専用の WordPress テーマを使えばすぐに完成します。英語だからダメと思うかもしれませんが、UI のローカライズが簡単できるように工夫されているので、使うことを諦めることはありません。 制作者の視点で語られる『オリジナルのデザイン』には、ひとつの矛盾があると思います。最新のデザイン動向を追いかけ、それを実践することが良いデザインに繋がると考えることがありますが、トレンドになる表現はすぐにコモディティ化されていきます。オリジナルを求めているつもりが、誰でも使えるものをゼロから手作りにして
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー 一部読者から高い評価をいただき,絶版となりながら中古市場でプレミア価格がついていた拙著「みんなのPython Webアプリ編」のHTML版をお送りします。Pythonを使って,Webアプリを開発するための方法を,基本的な事柄から積み重ね式に解説した書籍をHTMLにしたのが本コンテンツです。 編集部のご厚意で作ってもらった配布用PDFをベースに作っています(PDF作成だけでなく,出版契約の解除など必要な手続きを快く受けて頂いた担当様にはとても感謝しております)。構成などは著書をベースにしていますが,HTML化する過程で少し手直ししてあります。特にPython 2.7で動かないサンプルコー
Web APIの設計、開発、運用についての解説書。APIは設計次第で使いづらいものになってしまうだけでなく公開後の保守運用も難しくなってしまいます。そのためAPIを美しく設計することがとても重要です。本書では「設計の美しいAPIは、使いやすい、変更しやすい、頑強である、恥ずかしくない」という考えのもと、APIをどのように設計し運用すればより効果的なのか、ありがちな罠や落とし穴を避けるにはどういう点に気をつけなければいけないのかを明らかにします。ターゲットは、URIにアクセスするとXMLやJSONなどのデータが返ってくるシンプルなタイプ――XML over HTTP方式やJSON over HTTP方式――のAPIです。読者は、Web API設計の考え方と手法を知ることができます。 はじめに 1章 Web APIとは何か 1.1 Web APIの重要性 1.1.1 APIでの利用を前提とした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く