100日書かないと、市民になれないんだっけ? 市民にならないと、一部行動が制限されるので、タイピングの練習がてら、100日続けてみることにします。 ちなみに、この文書は月配列4-698で打ってます。 ミスタイプばかりでイライラします。 こないだまで、新JIS(もどき)で打ってたのでその癖が出て余計にミスタイプばかりです。(「う」や「っ」や「て」の位置が混乱しています。 ここまで打つのに10分かかってるんじゃないでしょうか? いつ飽きるかわからないのに、我ながら愚かなことです。
JAXAの小惑星探査機「はやぶさ」(MUSES-C)に対する、今のあなたの「想い」を教えてください。
最近はiPhone効果でMacが注目されている。近くのビックカメラもアップル売り場が拡大されている。ぼくも前の日記*1で書いたように、AppleKeyboad(MB869J/A)を見かけてデザインにほれ込んで衝動買いしてしまった人です。 最初は親指シフトで使おうとは思ってなくて、普通のWindows用キーボードとしてつかってました。もともとマックのキーボードなのでWindows環境では認識しないキーとかあったり(とくにdelキーがないのは違和感ある)して、「ドライバないのか!」って話になる。 ぐぐってみると、ぼくと同じような動機でキーボード買って同じように困ってる人がいる模様なのはわかった。でも、フリーで完全解決ってわけにはいかないことがわかり、キーバインドだけフリーソフトで変更して使ってました*2。ところが最近、長文の日記書くことがおおく、ローマ字うちだと疲れるなー、親指シフトしたら少し
これは12/4から開始されている"Dvorak Advent Calendar"というイベントのリレー記事のひとつです。 12/25担当分の記事です。 2010年12月1日から25日まで、毎日違う人が 全然普及しないDvorak配列にまつわるブログ記事を書く企画です。 http://atnd.org/events/10849 あなたはQWERTYを捨ててまで、Dvorakにするべきなのか。 これは、この企画に対する反抗じゃないですよ?笑 さて、Dvorakを広めたい私が、なぜこの質問をするかといえば。 「そこまでやる必要があるの?」という言葉を耳にするからである。 広めるためには、以下を示さなければいけない。 布教対象 導入コスト 導入によって得られるリターン 汎用性 リターンや、QWERTYとの干渉、日本語入力に関する調整は他に取り上げている記事がたくさんあるためあえて私はそれを補完する
SSDが少しずつエンタープライズマーケットで存在感を示し始めています。 Computerworld.jpの5月6日付けの記事「エンタープライズSSDの市場規模、今後5年で50倍に」では、このSSDの市場規模が急成長することを予想するアナリストのレポートを紹介しています。 【Objective Analysis調査】エンタープライズSSDの市場規模、今後5年で50倍に : ストレージ革命 - Computerworld.jp データセンターの省電力化のためにもSSD 記事によると、米国の市場調査会社Objective Analysisが4月に発表したレポートで、2015年までにエンタープライズSSDの市場規模が2009年の17倍近く、約40億ドルに迫り、出荷台数も400万台以上に増加するだろうと予測しているそうです。 その理由として、「HDDからSSDにリプレースすることで、IT支出を大幅に
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか? オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました(参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」)。 ホワイトペーパーでは、HDDの代わり
(過去:「様々な配列」と「その特徴に対する○△×」を表として作り、その特徴群に対して「自分にとっては必要」と「自分にとっては不要」って書いてから○△×を色分けチェックしていくと、「どの配列と自分とが、インピーダンスマッチングの取れた組み合わせなのか」について、なんか見えてくるのかも。) ……↑にもある、昨日の話の続き。 azukiさんとmikadoさんから頂いたコメントを読んでいたら、こーゆー分類も必要かも……と思ったので、ざっくり書いてみました。 行段かな系を使おうとする人にとっては「行段構造という名の補助輪に対して、どの程度依存できるか」ってのが、打鍵数よりも重要そうだ……って考えて、上図では打鍵数を含めず【定義数×行段補助率】ってグラフにしてみた。 どうせ「拡張定義化でも、縮小定義化でも関係なく」新配列系では打鍵数を減らす方向に調節してる……のだから、これのほうがより実情に近いんじゃ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く