フォントは自由に変えられる。だから絵文字で何かを伝えるのはナンセンス。そんなことも分からなかったのか、Googleよ。
Unicodeに絵文字が多数追加されたことは、以前から批判していたのだが、やはりというか何と言うか、しょっぱい問題が起こりつつある。 macOS SierraやiOS 10でピストル絵文字🔫が水鉄砲に変わることで起こる問題。 | AAPL Ch. 絵文字はフォント次第で形が変わる。故にフォントが変わればニュアンスも変わる。自分と相手、あるいは今使っている機種と将来使う機種が同じフォントを使っているとは限らない。だからフォントを変更することで様々な問題が起きるわけである。 根本的な問題＝性質が異なるものを混ぜてしまった文字と絵は本質的に性質が違う。 文字はその見た目ではなく、文字を組み合わせた単語、単語を並べた文章によって意味を持つ。フォントが違っても、見た目の違いはあれど、文章そのものの意味は変わらない。どのようなフォントで読んでも意味は通じるのである。 ところが、絵文字はそうは行かない
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Linuxに行く！」という方へLinuxユーザーとして言っておきたいこと
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Macに行く！」という方へMacユーザーとして言っておきたいこと という記事を見かけたので、Linuxデスクトップユーザーからも一言だけ言っておく。 結論から。 「悪いことは言わないからやめておけ！」 以前、いますぐWindowsを捨ててデスクトップでGNU/Linuxを使う10+の理由というエントリを書いたことがあるので、使っちゃいけないみたいなことを書くと、「おいおい、いまさら何言ってんだよ」と思われる方も居るかも知れない。だが、以前のエントリの主旨は「GNUのWindows移植版であるCygwinを使うぐらいだったらGNU/Linuxはいかが？」という提案をするためのものであり、いわばCygwinを使うようなIT技術者向けのメッセージである。Cygwinが必要だということは、UNIXライクなツール群を必要とす
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
GNUプロジェクト30周年おめでとう！
我らがリチャード・ストールマン氏（以下、敬称略）がGNUプロジェクトを孤軍奮闘ながら発起してから30年を迎えた。30年前と言えばWindowsすら無かった頃であり、コンピュータの世界は今とは全く異なっていただろう。「だろう」というのは筆者が当時まだ子供であり、その頃の業界について伝聞でしか知らないからである。 GNUプロジェクトは言うまでもなく、自由なソフトウェアによるオペレーティングシステムを作ろうという一大プロジェクトである。今のようにインターネットもなく、容易に支援も得られそうにない中で、独りでOSを創りあげようなどと起ち上がるのは如何に無謀なことであったか。しかし、その無謀のおかげで今日のソフトウェア業界の姿があるのは間違いない。 今日はGNUプロジェクトの重要さについて、改めて語ろうと思う。 GNUなくして今のインターネットは無かった これまで、GNUプロジェクトが果たしてきた役
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
