な @wideangle @NStyles ここ数日で自分が目にしたのが「削除依頼されても消さないもんね!」とか「こいつらばかだー」とか「反論をつぶやいたので自分のつぶやきまとめました!」とかそんなんばっかりでゲンナリですね。なんでそうなるかなっていう。 2010-02-22 03:57:45
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム
id:noitseuq氏が「アニメ!アニメ!がブクマされにくいのは何でかね」とつぶやいてましたが、たぶん単純な話だと思います。 アニメ!アニメ! サイトのHTMLのtitle要素の設計が、サイトをブックマークする閲覧者のことを全く考慮していない非常に不親切なものだから、ではないでしょうか。これは「アニメ!アニメ!」に限った話ではないですが、ちょっとした配慮の無さのために、アクセス数が増えるチャンスを大いに損ねている気がします。 ■なぜ、ブックマークされにくいのか 『アニメ!アニメ!』 の場合、例えばニュース・カテゴリの記事のHTMLのtitle要素は、全て固定で「アニメのニュースと情報」という文言になっています。どんなタイトルの記事でも、全て「アニメのニュースと情報」です。記事個別のタイトルが表示されないのです。 これでは、ブラウザにブックマークするにせよ、ソーシャルブックマークサービスに
筆者は新たなキーワードが登場したとき、マーケティング的な要素をぬぐい取り、できるだけ技術そのものを見ようと努めている。その視点で2009年の話題のキーワード「クラウドコンピューティング」を見てみると、「クラウド」とひとくくりで呼んでいるものに実体はないように思う。 ここでは、米Amazon Web Services(米Amazon.com)の「Amazon EC2」、米Salesforce.comの「Force.com」、米Googleの「Google App Engine」、米Microsoftの「Azure」の順で、技術の本質や押さえどころを書いてみたい。 Amazon EC2→自動化されたホスティング・サービス Amazon EC2は、インターネットを介して仮想サーバーを貸し出すサービスである。CPUやメモリー、ディスクなどのスペックが決まっている仮想サーバーを選択すると、数分程度の
Javaではpublic, protected, default, privateという4種類の可視性がある。 Javaを始めてしばらくの間、この4つの使い分けがよくできていなかった。 「外から呼ぶならpublic、呼ばないならprivate」時代 当時から、なるべく可視性は下げた方が良い(オブジェクト指向は「隠す技術」である → 継承とコンポジット - 都元ダイスケ IT-PRESS参照)ということは理解していたので、「外から呼ぶならpublic、呼ばないならprivate」という指針からスタートした。 上記に加えて「継承先からしか呼ばないならprotected」時代 Template Methodパターンを覚えた頃の話。この時代が一番長かった。 そして残ったひとつ、default(package-private)の使い方が全く分からなかった時代でもある。色々使おうと頑張ってみたが、pa
Webコミュニティとかを作っているロケットスタートという会社の代表取締役をやっています。いつもがんばっています。 たいした話題じゃないので、校正もたいしてせずにダラダラかいてみます。 nanapiというサイトをやっているのですが、そこの一つの機能として、記事にたいして「いいね!(良い評価)」「きょとん(悪い評価)」というのがつけられるのですね。 で、nanapiだと、いいねは誰でもできる、という形にしています。IPで連打は規制していますが、日を変えればできちゃいます。 逆に「きょとん」はログインしないと出来ないようにしています。ネガティブな評価をしたいと思った時は、ある程度のステップをふめば可能、だけどログイン時のニックネームが出るくらいのリスクはとってね、という設計です。 で、ネットに詳しい人とかからは「これは公平じゃないんじゃないか」と言われたりしていますが、公平ってなんですか
ミクシィは青少年保護策の一環として11月4日から、18歳未満の未成年ユーザーは、「マイミクシィ」「マイミクシィのマイミクシィ」以外のユーザーのページを閲覧できなくする。日記、写真、動画、レビュー検索もできなくする。 18歳以上のユーザーの未成年へのアクセスも制限。「マイミクシィ」「マイミクシィのマイミクシィ」以外の未成年ユーザーのページを閲覧できなくする。 mixiでは従来から、未成年ユーザーはコミュニティの閲覧・投稿や友人検索機能が利用できないなど、青少年保護のための利用制限を設けている。 関連記事 警視庁、mixiやモバゲーなどに年齢確認厳格化を要請 警視庁は、「mixi」や「モバゲータウン」など多数の会員を抱える8社に対し、年齢確認の厳格化などで子供が有害情報を閲覧できない措置を取るよう協力を依頼した。 mixiが2ちゃんねる化? 「身内しか見ない」と“誤った安心感” 京教大事件に絡
MVC とは、もともとの出自は Smalltalk で、対話型のアプリケーションを作成するためのアーキテクチャのことでした。 Smalltalk なんて知らない人多いでしょうに、普通のプログラミングの話題でこうも顔をピョコピョコ出すのが、なんというか、憂いヤツです。そんな何かと気になるアイツこと、Smalltalk の MVC について、抜群にわかりやすいこちらの梅沢さんの記事をおすすめしておきます。 Happy Squeaking!! -オブジェクト指向再入門- [第五回:デザインパターン事始め] さて、こちらから引用して、MVC の M、V、C がそれぞれどんなモノかというと、 処理を受け持つ部分は、Modelと呼ばれます。アプリケーションで必要となる実際のデータを保持しており、業務に特化した処理を実行します。(中略) Modelの状態を表示する部分はViewになります。ビットマップデ
週末 twitter で二つの大企業を巻き込んだ騒動が起こった。ここでは au2009 問題と呼ぶことにしよう。一言で言うと二つの企業が twitter 上でのプロモーション用に使ったハッシュタグ(つぶやきに含めると検索キーにできる特定の書式のキーワード)が衝突したという問題なのだが、単なる企業間の利害衝突ではなく twitter コミュニティを巻き込んだ「炎上」とも言える騒動になった。 ここまではいいのだが(?)、多くの人がこの騒動に言及するつぶやきの中で当該ハッシュタグ(#au2009)を書いてしまったため、このハッシュによる検索結果は au2009 問題関連のつぶやきで埋め尽くされ、結果として当該ハッシュタグは双方にとって使い物にならない状態になってしまった。 騒動の流れ 具体的なやりとりに関してはハッシュタグ「#au2009」競合問題に見るKDDI広報の対応の不手際さ - さまざま
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
The 2024 election is likely to be the first in which faked audio and video of candidates is a serious factor. As campaigns warm up, voters should be aware: voice…
原文(投稿日:2009/07/21)へのリンク 「確実にRIAに失敗するための10の方法」というプレゼンで、EffectiveUI社の社長であるAnthony Franco氏は、RIAプロジェクトに失敗したい人に送る10のアドバイスを紹介した。また、SAP AG社のGerd Waloszek氏は、「ひどいユーザインタフェースのための18のゴールデンルール」を書いた。 以下がFranco氏の挙げた10のアンチアドバイスであり、なぜ避けるべきなのか、代わりに何をすべきなのかを説明している。 失敗したいのなら、エンドユーザを理解するな。 – ITプロジェクトの70%はユーザの受け入れに失敗する。 失敗したいのなら、開発者は優れた設計判断をすると信頼せよ。 開発者は、完了した機能の数によって進捗管理されるため、まずい設計判断をしがちだ。プロジェクトの締切りに遅れそうになると、開発者はエンドユーザの
現在、私のプロジェクトでデータベースの識別子(ID)毎にクラスを作成するという意見が浮上しています。 例えば、顧客テーブルの顧客ID、商品テーブルの商品IDがあるとして、DB上はNUMBER型だとします。 この場合、java側ではlongで実装するのが一般的だと思われますが、CustomerIDというクラスを作成するという考えです。(longをラップしている感じです) logn型の場合は、商品IDを指定しなければいけない箇所で、誤って顧客IDを指定する可能性があるので、よりタイプセーフに実装できるのがメリットだと思われます。 システムで使用するテーブル数は20個程度でIDは7種類程度しかありません。 なのでクラスを作成しても実装負荷が高くなることも特にありません。 個人的には、この設計はやりすぎだと思うのですが、みなさまはどう思いますでしょうか? また、同様の設計を過去に経験した人は、やっ
上段id:yukatti:20051121:p1の続き。 ということで、アイデアに書かれていた却下理由「設定画面の選択肢は極力シンプルにしたいため、却下します*」は表層の理由で(これはこれで却下理由として重要だとは思う)、実際は ステルスモードを作るのは避けたい。 簡単でシンプルな仕組みこそ使いやすい。 信用度の問題もあり?(パブリックユーザがコメントを書いていれば必ず見え、書いていなければ空欄になる、という確からしさ) idを明らかにしたパブリックモードではてなブックマークを使うユーザにブックマーク開発者が求めているのは「そのエントリーにどんなコメントをつけたか」を見せることであり、「何をブックマークし、どうタギングしたか」を見せることよりもコメントの方が価値が高く判断基準として優先される。 他人のブックマークを見る/他人にブックマークを見せる際には、コメントが主であり「何をブックマーク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く