タグ

2005年10月7日のブックマーク (12件)

  • 日本語文字コード

    フォームメール(mb_send_mail)php ジェネレーター オープンフォトライブラリー自由に画像を登録・紹介できます 文字コード(日語漢字コード表) 日語漢字コード表が、Shift-JIS、EUC-JP、JIS、UTF-8と複数存在する事から、 ホームページ作成・維持管理、データ収集をする上で、文字コードについての多くの諸問題が発生します。 その解決に少しでもお役に立てれば幸いです 文字コード表(実体) シフトJISコード表 Shift-JIS による一覧表 EUCコード表 EUC-JP による一覧表 JISコード表 JIS による一覧表 JIS X 0201 (1976) to Unicode 文字コード表 Shift-JIS による一覧表 JIS X 0208 (1990) to Unicode 漢字コード表 Shift-JIS による一覧表(UTF-8のコードはこちらにあり

    fourth
    fourth 2005/10/07
  • 愛国党総裁 赤尾敏 24時間密着取材!

    2月23日正午・銀座数寄屋橋交差点 「お前らは共産党のスパイだ!」 のっけから面くらった。 「お前らマスコミはみんな、共産党のスパイだ!!」 満90歳の老右翼は、かっと目をむきステッキを振り上げた。手渡そうとした私の名刺は、あわれにも昼休みどきの数寄屋橋の路上に放り捨てられた。 途方にくれながら、私は名刺を拾い上げた。いったい何がまずかったのだろう。 一週間ほど前、私は取材を申し込むために愛国党部に電話を入れた。電話口に出たしわがれ声は、愛国党総裁・赤尾敏その人だった。 「大喪の礼? その日はね、私らは数寄屋橋で労働者・庶民の手による独自の大喪の礼の集会を開くんです。取材? とにかく前日に数寄屋橋に来たらいい」 そして、2月23日。言われた通りに銀座の数寄屋橋に出向いた私は、日課の街頭演説のために現われた赤尾敏に挨拶をしたところ、いきなり「共産党のスパイ」にされてしまったので

  • FPN-ニュースコミュニティ- 自分で立てたスケジュールを守るコツ

    2.ビジネスリサーチの情報収集 デスクトップ調査 の基〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95%が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる というで初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 295 view 2.ビジネスリサーチの情報収集 日常的な情報収集・整理術(Feedly+Dropbox) 【 ビジネス 情報収集 と 情報整理 の基 】いま目の前にあるリサー

    FPN-ニュースコミュニティ- 自分で立てたスケジュールを守るコツ
    fourth
    fourth 2005/10/07
  • 今日の覚え書き Tickler's bunkum days: 「激しく使える」サイトの自分用まとめ

    open-arms.biz 2023 著作権. 不許複製 プライバシーポリシー

    fourth
    fourth 2005/10/07
  • ユーザビリティテストの時間配分

    テスト時間の40%が、不必要なことに使われ、無駄にされている。ユーザが対象インタフェースのデザインを使う様子を観察することに集中したほうが、遙かによい。 Time Budgets for Usability Sessions by Jakob Nielsen on September 12, 2005 ほとんどのデザインチームは、ユーザの実際行動を観察する時間を、十分取っていない。もちろんほとんどの企業がユーザテストを全く実施していないのが実状だが、実施している企業でも、行動を観察する時間を十分取っていないのだ。 理想は、1週間あたり1日(たとえば毎水曜日)を4人のユーザでテストを行う「ユーザテストの日」とすることだ。もちろん毎回新しいユーザを使う必要がある。各テストで新しいユーザを使うことは、テストユーザのリクルートにおけるガイドラインの1つだ。(実際には7つのガイドラインが、この話題に

    ユーザビリティテストの時間配分
  • フォーム vs. アプリケーション

    オンライン・フォームも2画面を超える分量になると、機能を滞りなく支援するには、よりインタラクティブなユーザ・エクスペリエンスを提供するアプリケーションに切り替えた方が良い場合が多くなる。 Forms vs. Applications by Jakob Nielsen on September 19, 2005 フォームが、コンピュータとの複雑なインタラクションを表す最良のメタファとなることは稀だ。にも関わらず、多くの大企業が、紙ベースのフォームを受け継いでいる。結果として、イントラネットには、ニーズに応えようとするオンライン・フォームが散乱している。アプリケーションを使えば、リアルな対話と格的なGUIで、そのニーズはもっと上手く満たされるというのに。 最近、ある人から1の電話があった。イントラネット用のフォームを見て、ユーザビリティ上の問題点を指摘して欲しいと言うのだ。単独のページにフ

    フォーム vs. アプリケーション
  • http://blog.livedoor.jp/chnet2/archives/50071050.html

  • 次世代ITオフィスにおけるコミュニケーション──現在の電話の問題点とそれに代わるもの

    次世代ITオフィスにおけるコミュニケーション──現在の電話の問題点とそれに代わるもの:次世代のITオフィス環境を考える(1/2 ページ) 電話は最も多くのオフィスで使われているコミュニケーション手法の1つだ。だが、この手法にははさまざまな問題点が潜んでいる。次世代ITオフィス環境にふさわしい電話のあり方とは。 多様化してきたオフィスにおけるコミュニケーション手段だが、現在でも依然として電話の利用がその多くを占めていることに変わりはない。次世代のオフィスにおけるITを活用したコミュニケーション手段はどのようなものになっていくのだろうか。 電話の不満点 仕事の道具としてのパソコンがオフィスで普及するにつれ、業務上のコミュニケーションの方法も多様化してきた。従来の電話やFAXに加え、電子メールの利用が一般的になってきた。従来はFAXでやり取りをしていた情報でも、電子メールを使うのが一般的になった

    次世代ITオフィスにおけるコミュニケーション──現在の電話の問題点とそれに代わるもの
  • http://www.hi-net.zaq.ne.jp/osaru/index.htm

    fourth
    fourth 2005/10/07
  • あなたは“将来”を選んでいますか?

    ITエンジニアプロジェクト・マネジャーになりたいと思うのは,生き残るための選択肢という側面が強いのではないか」,「日IT業界には,職種を変えていかないと収入が上がっていかないという構造がある」,「IT以外の業種への転向も視野に入れて将来像を模索中」----。 6月23日に欄でご報告させていただいた,全国のITエンジニアを対象とするスキル/キャリア実態調査の中間結果(関連記事)に対して,読者の方々から職種転換や転職にかかわるご意見を多数いただいた。 その後も調査を続け,ようやく最終結果がまとまったので,今回はこうしたキャリア設計の話題を中心に,興味深い結果をいつくか選んでご紹介したい。詳細は日経ITプロフェッショナル10月号の特集「2万人調査で浮き彫りになった,スキル 年収 キャリアの実態」にまとめたので,こちらも一読していただければ幸いである。 なおこの調査は,誌が参画するIT

    あなたは“将来”を選んでいますか?
    fourth
    fourth 2005/10/07
  • IT管理者が犯しがちな5つの過ち

    これほど長い間、さまざまなIT管理者が同じ過ちを繰り返すのを見つづけてくると、その過ちに共通のパターンがあることに否応なく気づかされる。よく見る5つの過ちと、その避け方のヒントを以下に記しておく。 過ち#1:事後対応のみで、事前対策なし IT管理者が犯す最大の過ちは、責務の果たし方が事後対応的であることだ。つまり、問題が起こってから対応に慌てふためく人が多く、早くから潜在的問題に気づき、事前に解決策を用意しておく人は少ない。IT管理者に特有のことではないが、IT部門の管理者が予防的措置を怠るとなると、致命的な過ちになりうる。 例えば、しっかりした予防意識を持っているIT管理者なら、事が起こってからその場でレスキュー計画をでっち上げたりせず、事前にちゃんと備えをしておくだろう。しかも、ハードウェア障害、自然災害、システム不調、その他、起こりうる危険の1つ1つに対応策を用意しておくに違いない。

    fourth
    fourth 2005/10/07
  • 凝集度と結合度:このコードのどこが悪いのか?:@IT

    前編「ソフトウェアの品質を数値化して確かめる」では結合度について少し触れましたが、今回は結合度とともにソフトウェア設計において古くから知られている凝集度についても紹介し、ソフトウェアメトリクスの解説をしていきます。 抽象的な話だけになってしまうと、具体的なイメージがつかみにくいので、実際のプログラムコードを示し、何が良くて、何が悪いのかを明確にしていきます。理論的な話も重要ですが、メトリクスの測定が実際にどう評価されるかを理解して、良いプログラムを作れるようになる手助けになれば幸いです。 それでは、メトリクスの詳細を見ていきます。 1. 凝集度と結合度 1.1. 凝集度とは? 凝集度とは、クラスやパッケージ内の機能要素と情報要素間の関連性の強さを表す指標です。互いに関連する機能や情報があちこちに分散していると、仕様変更が生じた場合の影響範囲が広くなってしまいます。これらの機能や情報が局所化

    凝集度と結合度:このコードのどこが悪いのか?:@IT
    fourth
    fourth 2005/10/07