東京電力パワーグリッド「停電情報」サイトです。「住所から検索」ページのご紹介です。
![TEPCO : 停電情報(HTML版)](https://cdn-ak-scissors.b.st-hatena.com/image/square/a280d8e94c6f3bfc7b69d77595fb63c519d0a015/height=288;version=1;width=512/http%3A%2F%2Fteideninfo.tepco.co.jp%2Fimages%2Fogp_image.jpg)
※この記事はChromeで見るのがおすすめです。 こんにちは。新規開発グループ ディレクター兼マークアップエンジニアの浜です。 スマホ連載の第4回目は、HTML5とCSS3という実装寄りの内容になります。とは言っても難しいコードはあまり出てきません。「HTML5とCSS3で何ができるのか」という事をメインに、知っておくと、構成書を作る時のアイディアベースになったりデザイナー・マークアップエンジニア(コーダー)と打ち合わせをする際に話しやすくなる内容をお送りします。 記事のアウトラインは以下です。 そもそも、HTML5とCSS3ってもう使えるの? HTML5とCSS3を使うメリットは? HTML5とCSS3で何ができるの? そもそも、HTML5とCSS3ってもう使えるの? 使えます。 (※ここから先は、その根拠について説明します。必要ない方は、次の章に飛んでしまっても構いません) 現在のスマ
About this specification This specification is like no other — it has been processed with you, the humble web developer, in mind. The focus of this specification is readability and ease of access. Unlike the full HTML Standard, this "developer's edition" removes information that only browser vendors need know. It is automatically produced from the full specification by our build tooling, and thus
Publickeyでは、現在策定中の電子書籍フォーマット「EPUB 3」の動向について積極的に伝えていますが、ここでちょっと立ち止まって、EPUB 3とは何か? という基本的な情報について簡単にまとめておこうと思います。 EPUBの仕様はオープンかつフリー EPUBとは、「電子出版」を意味する「Electronic Publication」からとった名称といわれていて、International Digital Publishing Forum(IDPF、国際電子出版フォーラム)が策定をすすめている電子書籍のファイルフォーマットです。ちなみにEPUBは「イーパブ」と読みます(EPUB 3はイーパブスリー)。また、表記は「ePub」と表記されることもありますが、最近は「EPUB」とすべて大文字で表記されることが多いようです(仕様書などでは「EPUB」と表記されています)。 イースト株式会社の
はじめに 2010年のはじめ、TwitterがApache CassandraというJavaで実装された分散型のデータストアシステムを採用しつつあるというニュースが話題を呼びました。このことでCassandraは、NoSQLと呼ばれるシステムの中で最も注目を集めるものの一つになったと言えるでしょう。 2010年7月の時点で、Twitterは、位置情報のデータストレージ、トップツイート(トップページに表示される人気ツイート一覧)などのリアルタイム分析、データマイニング処理など、多くの用途でCassandraを活用しています。また、Cassandraを生み出し、のちにApache Foundationに寄贈したFacebookでは、5億人規模・150Tバイト以上のデータ量を持つユーザメッセージの検索機能(Inbox Search)を、150ノードのCassandraクラスタで処理しています。
はじめに 複雑な仕様を整理する。テスト担当者の仕事の1つはこれです。 ソフトウェアが仕様通りに動くかどうかを確かめるのがテストの役目です。ですが、複雑な条件が絡み合った仕様をテストする場合には、まず仕様を把握し、理解しなければなりません。これがなかなか骨の折れる作業です。 もちろん、この悩みはテスト担当者に限ったことではなく、開発設計者にとっても同じように悩ましい問題でしょう。次から次へとクライアントから降ってくる、追加の要求を、すっきりと仕様に整理して、不具合のないシステムを作ることは決して簡単な仕事ではありません。 とりわけ、やってくる要求は既存のシステムの仕様とは無関係にやってきます。追加の仕様を設計、実装する際には、既存の仕様と整合性をとらなくてはなりません。「とりあえず」、で修正してみたものの、テストをしてみると、不具合が発覚。再度修正したら今度は別のところで不具合が発生…
この資料では,サプライヤと顧客がアジャイル開発契約を成立させる方法として,4つのモデルを検討します。やがて新しいモデルが登場すると思われますが,現時点で選択肢として存在するのは,概ねこの4つのオプションです。 固定的な契約を覆す 固定された金額,固定された期間,固定されたスコープを持った契約は,依然として IT 業界における契約の標準的ベンチマークであり続けています。この種の契約は,プロジェクトの初期段階で作業のスコープを定義可能である,という考えに基づきます。サプライヤ側はこれを基準として,何が必要か – というより,何人がどれだけの期間必要か – を決定し,金額を算出します。それが完了すれば契約書が正式に署名され,実施に移されます。 このようなモデルは,提供される対象が "もの" ,すなわち一定量の専門的ソフトウェアである,という解釈を基準としています。しかしカスタムソフトウェアを購入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く