https://mayah.jp/ Recent content on MAYAH Hugo -- gohugo.io ja Thu, 28 Oct 2021 00:00:00 +0900 https://mayah.jp/posts/2021/10/coding-test/ Thu, 28 Oct 2021 00:00:00 +0900 https://mayah.jp/posts/2021/10/coding-test/ 先日、某VC投資先の方々に対して、「ソフトウェアエンジニアの採用時にコーディングテストをやりたいがどうしたら良いか？」ということについて語ってきたので、こちらにもエッセンスをまとめたいと思います。 コーディングテストの目的 なぜ我々はコーディングテストをやるのでしょうか？ もちろん、第一目的はソフトウェアエンジニアの採用候補者のスキルを見極めるためです。 過去に、経歴も良さそう、技術的な議論もスムーズにできる、なのにコードが書けない候補者に、私は何度か出会っています。「コードが書けない」のレベルは、（ある程度易しい）論理をプログラムに翻訳できず、まともな if 文が書けないというレベルを言っています。熟練者でもド・モルガンの法則をうっかり間違えるぐらいはあると思いますが、そういう話ではありません。コードが書けない候補者は、そもそも条件が書き下せません。このような候補者を雇ってはいけません。でも、経歴が良く、議論もスムーズなので、第一印象はとても良いです。しかし、コードは書けない。コーディングテストを実施することが、このような候補者を見分ける簡単な方法です。 ところで、コーディングテストの副作用として、自社の技術力を候補者に一定示すことになります。このコーディングテストに通った人しか採用されてないなら、自社メンバーに一定の技術力が見込めると採用候補者に思ってもらうことができます。また、コーディング面接の形式でコーディングテストを行う場合、技術議論によって、こちらのレベル（高いも低いも）を示すことになります。良い候補者にとっては、面接自体が魅力づけになり得ます。コーディングテストをやっていないという理由で選考を辞退する候補者の話もしばしば耳にします。 自社で見極めたいスキルを洗い出しましょう コーディングテストで見極められるスキルには、例えば以下のようなものがあります。何を重視するかを自社で考えてください。 知識・経験 プログラミング言語・周辺環境 フレームワーク アルゴリズムやデータ構造 セキュリティ 能力 システム設計能力 コーディングの速さ コーディングの正確さ チーム開発の態度 適切なコメントを書くか？ 変数名・関数名は意味がわかるものをつけているか？ 問題に向き合う態度 問題の解を考える前に、問題をきちんと理解することに努めるか？　いきあたりばっかりか？ 議論に向き合う態度 議論になった時に、正しい着地点を見つけようとするか？　自分の意見を通そうとするか？ コーディングテストは、あくまで「ワークサンプルテスト」であるべきです。すなわち、自社での仕事を擬似的な環境で行ってもらうものです。自社であまり使わないような知識を重視して聞くべきではありません。自社で大事だと考えているスキルを問うようにします。チーム開発が大事だと考えているならばチーム開発の態度を問うべきです。コーディングテストというとアルゴリズムの試験をすれば良いと思ってしまいがちですが、難しいアルゴリズムを理解していることが重要な会社ならそうするべきですし、使わないならばそこまで重視するべきではありません。もちろん、アルゴリズムとデータ構造の最低限の知識・経験は全てのソフトウェアエンジニアがしっておくべき知識ですから、候補者に求めて良いとは思います。 コーディングテストの形式 採用において重視するスキルを洗い出したら、形式を決定します。 コーディングテストは、大きくわけて３つの形式が考えられます。 宿題形式 試験形式 面接形式 自社で、採用候補者の何を測りたいのかを中心に、自社で可能な形式かを合わせて形式を決定します。場合によっては複数の組み合わせ (宿題 → 面接) にします。 宿題形式 宿題形式は、期間を設けて、課題を解いてもらい、提出する形式です。 pros 多少難しい問題、込み入った問題が出題できます。 コメントの書き方、変数の命名法なども見れます。 git の履歴などを提出してもらうこともできます。 cons 不正が稀にあります。 実際の回答時間がわかりません。 想定外の回答をされても修正することができません。 技術的な議論はできません。 試験形式 オンラインで問題を解答・提出してもらう形式です。 https://mayah.jp/posts/2021/09/knowledge-work/ Tue, 28 Sep 2021 21:40:00 +0900 https://mayah.jp/posts/2021/09/knowledge-work/ 2020年2月にほぼ個人会社である lambdabox Inc を立ち上げ、2020年4月に @asanokoji らと株式会社ナレッジワークという BtoB SaaS の会社を立ち上げました。 lambdabox Inc の方は今特に述べることがないので（お仕事は受けております）、株式会社ナレッジワークの現在について少々述べようと思います。 株式会社ナレッジワークは当初7人で創業しましたが、今は14人まで拡大しています。プロダクトを作っている人間 (プロダクトマネージャー、ソフトウェアエンジニア、デザイナー、他) と売っている人間（BizDev、セールス、他) とで 2:1 ぐらいの割合です。他、コーポレート系も少々いますね。人数としては当初から2倍になったので、ちょっとは大きくなったなあという感想です。副業という形でお手伝いいただいている方もいくらかおります。 できる喜びが巡る日々を届ける まずそもそも何をやっている会社なのかという話ですが、ここまでプロダクトはステルスでやってきており、まだしばらくステルスが続く見込みで、多くを語ることはできません。今語れることは、会社のビジョンとして「できる喜びが巡る日々を届ける」というビジョンを掲げており、事業ドメインを「ワークエクスペリエンス領域のイネーブルメント」、すなわち、普段の仕事がよりできるようになるためのプロダクトを提供すること、と設定していることぐらいです。労働は苦役なりという思想から抜け出し、仕事が少しできるようなる→仕事が少し楽しくなる→楽しいからもっとできるようになる→もっと楽しくなる……というループを回せるようにしたいと思っています。 このあたり、自分の原体験からも来ている部分もあり、昔から（高校生ぐらいから）どうやったら何かが「できる」ようになるかということばっかり考えていました。大体は、適切な道筋が示されていないことと、示されたとしてもそれが正しいのか自信が持てないために前に踏み出しづらいことに起因すると思っています。最初の一歩は常に難しいものです。自分はたまたま適切な道筋を見つけ、その道筋の一歩目も上手くいった結果、ある程度までいろんなことができるようになったと考えています。自分だけがたまたまできたということには全く再現性がないので、多くの人に自分なりの道筋を見つけてもらい、最初の「できる」を獲得し、結果自分の力で前に進んでいけるようになってほしいと考えています。 プロダクトと今の会社の状態 イネーブルメントを構成する要素はいくつかあると考えており、ナレッジワークではそれをプロダクトに落として提供しようとしています。プロダクトでは、コアとなる領域の MVP (Minimal Viable Product) をまず作ってお客様からフィードバックをもらって改善しつつ、そちらの手応えが見えた段階でさらに周辺領域の MVP 開発を複数進めてきました。 コアとなる部分は一定の手応えを得ています。自分は現実主義なので多少割り引いてみていますが、一部の経営者であればこの結果であればアクセルをベタ踏みしたくなってもおかしくないでしょう。 一方で周辺領域は、良さそうな兆しが見えたもの、まだまだ作り込みが必要なもの、何をやったらいいのかわかっていないものなどが混在している状態です。まだまだやるべきことが山積みですが、プロダクトマネージャー、ソフトウェアエンジニア、はては BizDev も足りていないため、ある領域を少し良くしてはフィードバックをお願いし、そのフィードバックを Biz が得て新しい仮説をたてている間に別の領域の開発をしているみたいな状態になっています。もう少し人がいればそれだけ仮説検証が回せるのに……と思っています。 プロダクトのコアに関しては、設計を初期にそこそこちゃんとやったおかげで、どんどん変わる要件に対しても内部のモデルはそんなに破綻せずにここまで来れました。当初からみると機能は非常に増えたのですが、特に破綻なく吸収できています。見通せなかった仕様変更もないわけではないですが、些細な変更ですんでいます。 開発はめちゃくちゃアクティブで、patch (Pull Request) の数がこの１年半で 9000 ぐらいになりました。ソフトウェアエンジニアの人数を期間でならすと大体４〜５人程度でやってきたので、適当にならすと 9000 (PRs) / 18 (months) / 5 (people) = 100 で、一人平均毎月 100 個ぐらいの patch を書いている計算です。営業日が月 20 日あるとすると毎日 5 つぐらいですかね。メンバーは残業も大してしてないので（月10~20時間程度）、結構な生産性が出せていると思っています。そもそもイネーブルメントの会社なので、メンバーをイネーブルメントさせないといけないわけで、そこは今のところはまあまあ上手く行っていると思っています。 メンバーを募集しています というわけでメンバーを募集しています。作りたいものが山積みで、0→1も1→10もどちらもあるフェーズです（10→100以降はまだないんだけど、これから作りたいと思っています）。 いわゆるスタートアップ企業は玉石混交で、玉なのか石なのかがわからないのがスタートアップ界隈を考えている応募者の悩みの１つだと思います。だから、キャピタルゲインを求める人は当たった時の取り分が大きなシードステージへ行き、ある程度安定を保ちつつ挑戦したい人は、当たりそうな名前が知られてきたミドル〜レイターステージ以降あたりを目指しているのではないかと勝手に思っています。ナレッジワークはシードよりであり、今の段階では当たった時の取り分もまあまあ大きくて、そして結構当たりそうな感じ（自画自賛）もあるので、実は結構お得感のあるフェーズではないかと考えています。実際ストックオプションも全員にかなり厚めに配布しているつもりで、そして、早く参加していただければそれだけ多く出せます（出せる量に上限があり、どうしても頭割りになっちゃうので人数が増えれば増えるだけ少なくはなります）。 ご興味を持たれた方は、リクルートページ からご応募いただくか、もしくは @mayahjp まで DM をください（DM は開放しています）。 https://mayah.jp/posts/2019/07/competitive-programming/ Thu, 25 Jul 2019 12:00:00 +0900 https://mayah.jp/posts/2019/07/competitive-programming/ 一定時間内に題意を満たすようなプログラムを、よりたくさん、より高速に書くことを競うプログラミングコンテスト、およびその形式のことはしばしば「競技プログラミング」と呼ばれています。今となっては当たり前となった言葉ですが、私が現役でこのような競技に参加していた頃 (2005年まで) はそのような言葉はなく、単に「プログラミングコンテスト」と呼ばれていました。 さて、競技プログラミングという言葉はいつ生まれたのでしょうか？　一部では “competitive programming” の訳語であると思われていますが、実はそうでもないのです。 自分の体験談を少し振り返ると、私が YUHA で競技プログラミングに関連する同人誌的なものを書き始めた 2008 年夏 (C74) には、「競技プログラミング」という言葉はまだ広くは知られてはおらず、同人誌中でも競技プログラミングという言葉は使われていませんでした。2010 年夏 (C78) に発行した同人誌からタイトルに「競技プログラミング」という言葉が使われ始めています。この頃売り子も自分がやっていましたが、「競技プログラミング」という言葉は全く浸透しておらず、興味を持ってもらった人に「競技プログラミング」とは何かを一から説明するような状況でした。ただ、「競技」という言葉はキャッチーだったようで、2010 年冬 (C79) に発行するものからは「競技」という言葉を前面に出したことを覚えています。それでも浸透度は低く、数年は「競技プログラミング」という言葉の説明が必要でした。2019 年現在「競技プログラミング」という言葉は十分に浸透していると思われ、もうプログラマ向けには説明はほとんど必要がないと思われることを考えると、隔世の感がします。 さて、twitter で [2008 年 12 月 31 までの期間で競技プログラミングという言葉を検索してみる](https://twitter.com/search?q=競技プログラミング until%3A2008-12-31)と、その言葉が使われ始めた萌芽はあるものの、出てくるツイート数も少なく、まだ一部でしか浸透していないことがわかります。Google Trend で検索してみても、2004, 2005年になぜか突発的に「競技プログラミング」という言葉がトレンドに現れてはいるものの、2007年頃から継続的に現れ始めた言葉であることがわかります。 twitter のこれらの発言 1 2 をきっかけに「競技プログラミング」という単語のルーツを追ってみた結果、どうやら「東京大学競技プログラミングクラブ」という東大の勉強会が存在したことがわかりました。そしてそのクラブ名の名付け親である @ymatsux により、彼の思いつきが発端であるということがわかりました。 それであれば、自分は卒業しているため 2007 年にその言葉を知らず、一方後輩からその言葉を知ったおかげで広く知られる前から使い始めたということで、納得ができます。 なお、@nya3jp のツイートによると、「競技プログラミングクラブ」が発足したメーリングリストの一通目は 2007 年 3 月 30 日ということなので、この日が公の「競技プログラミング」発祥の日なのかもしれませんね。これから毎年祝いましょう。(追記: どうやら発足はもう少し前に遡れるようです。)なお、英語の “competitive programming” ですが、Google scholar によると、2007 年よりも前からなくはなかったようです。この PDF によると、1999 年にはそのような講義 (CS3233 Competitive Programming in July 1999) があったことが示されています。ただ、ここから日本語の「競技プログラミング」が訳されたというよりは、独立に同じ言葉が生まれたと考えるのが適切ではないか、と考えています。 以下は 2019-07-28 にした追記です。 https://mayah.jp/posts/2019/07/reincarnation/ Wed, 24 Jul 2019 20:00:00 +0900 https://mayah.jp/posts/2019/07/reincarnation/ 主に友人知人向けへの周知です。2019 年 3 月末で G を退職しています。 何か新しいことをやろうと思って水面下で様々準備していたのですが、事業を 0 から起こすというのは経営のスキルも足らずなかなか難しいなと攻めあぐねていたところ、前前職 (W) の上司の紹介で VISITS technologies の CTO 職をやってほしいという話になり、社長と話してみるとやりたかった事業ドメインに近かったため、引受けてみることにしました (万が一事業に失敗したらどこか拾ってください)。 いわゆる退職エントリはドラフトを長々と書いてみたのですが、書いた結果あんまり公にすることではないなと思ってお蔵入りにしました。積もる話は直接聞いてください。 現在丸の内勤務になったので、主に丸の内近辺の方(わかる範囲だとPFNとかTDとか)、遊んでください。ただ、G の頃より異常に忙しいので（これがスタートアップか）、なかなか時間取れないかもしれません。 こちらからは以上です。 https://mayah.jp/posts/2017/06/resolve-path/ Mon, 05 Jun 2017 23:15:00 +0900 https://mayah.jp/posts/2017/06/resolve-path/ 今、分散コンパイラのキャッシュを作るようなお仕事をやっています。キャッシュを作るときには、キャッシュヒット率を上げるためにファイル名はなるべく正規化して持ちたいと思うことがしばしばあります。 コンパイラですと、-I で指定されたインクルードディレクトリ名とインクルードファイルを join してパスを得ることがあります。インクルードディレクトリやファイルが ../ を含んでいることは多分にあり、もし、../などを解決して絶対パス名にして保持できると、その後の扱いが楽にあります。例えば、パス名として /a/b/../c が与えられたとき、/a/c の形で保持できると少し嬉しいわけです。ファイルにアクセスすると遅いため、できればパス名だけでこのような正規化ができると嬉しいわけです。 さて、このような正規化をしてもいいのでしょうか。ダメだとするとどういう例があるでしょうか。 ダメそうな例として、b がどこかの directory への symlink である場合が考えられます。例えば /s/t への symlink であったとします。/a/b/../c を symlink を辿って解決すると、/s/c になり、/a/c とは違う場所を指しています。 実際、gcc で次のような ファイル構成および内容のとき、 a/b s/t への symlink a/c.h #define KOTORI 100 s/c.h #define KOTORI 200 s/t 空ディレクトリ test.h #include <a/b/../c.h> test.cc #include <stdio.h> #include <test.h> int main() { printf("%d\n", KOTORI); return 0; } gcc -I. test.c として出来上がった実行ファイルは何を出力するでしょうか。symlink を解決していれば 200 が、解決されてなければ 100 が表示されるはずです。 $ gcc -I. https://mayah.jp/posts/2017/01/seccon-talk/ Sun, 29 Jan 2017 23:19:00 +0900 https://mayah.jp/posts/2017/01/seccon-talk/ 王様達のヴァイキングの技術監修役としてSECCON 2016 東京大会でちょっとしゃべってました。 まさか花が飾られているとは……。 普通 IT 系の勉強会だと技術がわかっている人が多いので、その人たち向けの前提知識で話します。今回もそんな感じでいいかなって思っていたのですが、当日どうも女性が結構登録しているらしいと聞いて、これは考えを改めねばと思いました。IT 系の勉強会では残念ながら女性は多くても数人です（女子向けは除く）。ということは、これは技術がわかっている人と、おそらく技術にはそんなに詳しくはないがマンガに詳しい人たちが混ざっている……となるわけです。 両方の人たちを満足させなければならないので、技術的な話とそうでない小ネタ（主に設定）を半々ぐらいのバランスで挟むことにしました。両方の人に満足していただけたのかどうかはわかりませんが、当日最初らへんのしゃべりで反応があった数人にターゲットを絞って、まあ彼・彼女らが満足してればよかろうというスタンスでしゃべっていて、最後までわりと満足そうな顔をしていたので良かったのだと思います。 https://mayah.jp/posts/2017/01/seccon/ Mon, 16 Jan 2017 00:00:01 +0900 https://mayah.jp/posts/2017/01/seccon/ 王様達のヴァイキングの技術監修役として SECCON 2016 東京大会でちょっとしゃべることになりました。2017年1月28日13:00-14:00に東京電機大学だそうで。 SECCON 2016 決勝大会 セキュリティに関してはどう考えても来場者の方がレベルが高いと思いますが、漫画の屋台骨を支える役にはなんとか立っていると思っています。 https://mayah.jp/article/2017/commit_message/ Sun, 15 Jan 2017 23:00:00 +0900 https://mayah.jp/article/2017/commit_message/ ここ5年ほど pre commit review があるような環境(主に chromium とか)で働いてきたので、コミットメッセージの書き方を自分なりにまとめておきます。 コミットメッセージで伝えたいことはパッチのコンテキストである コミットメッセージはコードレビュー依頼であるという態度で記述します(受け売り)。そのため、コードレビュー者がパッチのコンテキストを理解できるように記述するべきです。なにをやっているのか分からないパッチを渡されるより、これはこういう理由でこういう変更をやっているパッチだということを伝えてからパッチを見たほうが、パッチの理解も速いでしょう。レビュー者にパッチのコンテキストを理解してもらえれば、コードレビュー速度が上がったり、コードのミスが見つけてもらいやすくなるという利点があります。 コミットメッセージの基本的なフォーマット コミットメッセージには一般的に使われる基本的なフォーマットがあり、それにそって記述します。 １行目 １行目はパッチのタイトルのようなものです。なるべく50文字以内で、何をしたのかや改良点を簡潔に書きます。git log --oneline ではここだけ出て来るので、何をやっているのかを簡潔に書きます。ぼくは tig を使って履歴を良く見ていますが、tig でも１行目が git log --oneline と同じように出ます。 例 Implement something to improve stability Add something Remove something 50文字を超えない程度なら、to improve stability のように、理由を入れることもあります。 個人的には Fix xxx とか Modify xxx とかはほとんど書きません。自明なので。もっと内容のあることを書きたいからです。 最初は大文字、ピリオドはなし、ということになっているようですので、(最近は)それを守っています。 あとぼくは基本的に英語で書きますが、日本人だけしかいないなら日本語でもいいと思います。OSS にしたいのなら、日本人としては残念ですが英語が標準語になってしまっているので、英語で書いてください。まともな高卒ぐらいの英語力があれば伝わるものは書けると思います。 ２行目 ２行目は空行です。 ツール類に１行目をタイトルだと認識してもらうため、必ず空行です。 ３行目以降 ここからが本番です。まず、このパッチが解こうとしている問題が何なのかを述べるようにします。つまり、このパッチがなかったら、どういうまずいことが起こるのかをレビュー者に伝えます。 このパッチに対応するチケットに問題が詳細に書いてあっても、「このパッチで」解こうとしている問題を述べるようにします。レビュー者がチケットを丁寧に読んでくれると思ってはいけません。チケットに書かれている問題は少し複雑で、いくつかのパッチを積み重ねて解決できるものもあるでしょう。レビュー者には、その問題のどこを解こうとしているのかは（コードを読まなければ）わかりません。コミットメッセージはコードを読む前に読んでもらうもの、という前提なので、コードを読まないと理解できないようなことは原則的には書きません。 例 If parameter `id` is not provided, this function could raise an Exception, and it's not handled at all. https://mayah.jp/article/2016/x86intrin/ Thu, 01 Dec 2016 00:00:00 +0900 https://mayah.jp/article/2016/x86intrin/ これは rust advent calendar 2016 (2) の 1日目の記事です。 SIMD とは SIMD (シムディー) とは、Single Instruction, Multiple Data の略で、１つの命令で(同じ種類の)演算を複数のデータに対して同時に行なうことを言います。 例えば、SSE2 には PADDW という命令があります。これはワード単位、すなわち、2byte 単位で加算を行なうという命令です。SSE では、16byte の幅を持つ xmm レジスタを用いて命令を発行することができます。この 16byte 幅のレジスタは、16x1byte, 8x2byte, 4x4byte, 2x8byte のように複数のデータをまとめたものとみなすことができます。PADDW 命令を xmm レジスタに対して発行すれば、2byte 単位の加算を一命令で 8 つ同時に行なうことができます。普通の CPU 命令は 1 つの命令に対して 1 つのデータしか演算を行わないので、単純には 8 倍速で加算が行えることになります。したがって、同じ演算を大量のデータに対して行なうときには、SIMD 命令を用いると高速に計算を行なうことができます。 rust で simd 演算 rust で SIMD 演算を行なうには、simd crate を使うのが今の所メジャーです。 一方、2016年11月現在、simd crate には AVX2 命令があまり実装されておらず、また SSE 命令にも実装されていないものがそこそこあります。筆者はちょうどこれらの命令が必要であったこと、および C/C++ において SIMD 命令を利用できる x86intrinsic 命令たちに慣れていたことから、rust で x86intrinsic と同様の関数群を持つ x86intrin crate を実装しました。現状 AVX2 まで、ごく一部の命令とMMX命令を除いて実装しています。一応私が必要な機能は全部揃ったので現状は満足しています。 https://mayah.jp/posts/2016/blas/ Sun, 17 Jan 2016 19:00:00 +0900 https://mayah.jp/posts/2016/blas/ ちょっと行列演算をしたかったので適当にコードを書き散らしていたのですが、速度が必要な演算であるために既成のライブラリを使うこととしました。今回は行列乗算ができれば良いのでBLASを生で使ってもそんなに問題ありません。BLASの中でも高速な実装であるOpenBLASを使い、適当に書いたコードと速度の比較をしてみます。 結論から言うと、OpenBLASの速さを舐めてました。まさか50倍の速度差がでるとは。 比較に用いたマシンは、MacBook Pro 2013 Late 13 inch (2.4 GHz Intel Core i5) です。 インストール Macの場合はbrewで。LinuxでもOpenBLASのパッケージはたいていのディストリビューションにはあると思います。 $ brew install homebrew/science/openblas Matrix クラス 1024 × 1024の大きさの実正方行列の掛け算をします。以下N = 1024とします。 const int N = 1024; 適当にMatrixクラスを定義します。精度はそこそこで良いので今回はfloatを使います。 class Matrix { public: Matrix(int row_size, int col_size) : row_size_(row_size), col_size_(col_size), data_(new float[row_size * col_size]) {} float& operator()(int row, int col) {　return data_[row * col_size_ + col]; } const float& operator()(int row, int col) const { return data_[row * col_size_ + col]; } float* data() { return data_. https://mayah.jp/article/2015/puyoai/ Tue, 10 Nov 2015 00:00:00 +0000 https://mayah.jp/article/2015/puyoai/ 実機で動作するぷよぷよAIというものをしばらく有志で作っておりました。プロジェクトはgithub.com/puyoaiで公開しています。 これに関連するイベントを今までいくつか開いています。 ACぷよぷよ通 第１回 人類 vs AI 対抗戦 また、先日行なわれたゲームプログラミングワークショップ 2015 (GPW-15)というワークショップで招待講演としてぷよぷよAI 人類打倒に向けてというタイトルで発表しました。スライドはリンク先の slideshare にアップロードしてあります。 https://mayah.jp/article/2014/kingsviking/ Thu, 14 Aug 2014 03:59:36 +0000 https://mayah.jp/article/2014/kingsviking/ なぜこんな仕事を？ 簡単に言うと、深見先生に頼まれたから、です。 もともと、競技プログラミングのマンガを描こうという話が2005年ぐらいからありました。しかし、詳細を詰めるのが難しく、一度ネームもできたものの掲載には至りませんでした(注: 私が描いたのではありません)。このときの色々な縁で深見先生とは親しくなりました(注: 競技プログラミングマンガと深見先生は直接は関係ありません)。深見先生に王様達のヴァイキングの話がきたときに、せっかくだから我々とやりたいということで話が回ってきたものです。 ただ、話が回ってきたときには6話ぐらいは話が固まっていて、また、もともとの監修は sotarok と ozarn だけに回っていました。今がそうでないとは言いませんが、最初の頃はもっと起業ものっぽい雰囲気を醸し出していたでしょう？ 深見先生が協力として入ることになった後に、旧知の仲である我々にも回ってきました。そのときはちょっと画像を提供するぐらいの話でしたし、そのつもりでいました。また、もっと監修は人がいました。具体的には、YUHAのメンバーと、Gokuriのメンバー、などです。だから、そんなに負担にならないと考えました。ただ、徐々に監修は人を減らしていきました。これはそこまで仕事がなくなったというのが大きいのと、あまり多人数いても意見だけが出てまとまらないためです。人が減ったとはいえ、あまり負担は変わっていません。マンガを読んで育ってきたので、一作関われるというのも良い機会だな、と思って楽しんで協力しています。 何をやっているのか？ 技術的詳細を考えることです。 基本的に、話はさだやす先生が作ります。それを受けて、事件などを深見先生が作ります。しかし、そこには技術的な詳細は書かれていません。そこで、例えば「ハッキングをする」と書かれてある部分の技術的な詳細を考え、仮のセリフをいくつか挟む形にまで落とし、その詳細を平易な日本語でさだやす先生、深見先生、および担当の山内さんに説明します。なるべく、話も読者に分かりやすい展開になるように僕は心がけています。テクニカルには別の手段を使ったほうが良い技術でも、今後の展開および、マンガとしての要請のために別の技術を敢えて用いることもあります。これは詳しい人からはツッコまれますが、それは覚悟の上です。また、マンガの上では詳細はかけません。かいても難しすぎるだけだからです。 ハッキングの技術的難易度を調整するのは難しいのですが、私が見ている分に関しては、最低でも「理論的にはできる」話にしてあります。ほとんどの場合、それを実際にやったことがある人を聞いたことがあるものを採用しています。Windows のバイナリパッチを作った話なんかは、実際にそういう人がいるという話を聞いたので、じゃあいいだろうということで通してあります。また、過去に似たようなハッキング事例があれば、それを参考に技術的詳細を詰めたりします。大体5割ぐらいの技術的詳細は僕が決めていると思いますが、週に数時間程度の時間でだいたいなんとかなっています。 https://mayah.jp/about/ Tue, 12 Aug 2014 00:00:00 +0000 https://mayah.jp/about/ English version? See LinkedIn/ 英語版は LinkedInへ。 書いたもの、作ったものは Publicationsをご覧ください。 その他の活動場所 twitter @mayahjp twitter @mayah_puyo github (mayah) Linked In (Shinya Kawanaka) 競技プログラミングサークル YUHA SIG2D スキル プログラミング言語 2014年8月現在。 C/C++ Java OCaml Scala ECMAScript/JavaScript Ruby go Python scheme Objective C 他にも、Haskell, D, SML, Prolog, Concurrent Clean, ……などを書いてきましたが、5,000行にみたないものは省略します。 なんだかんだ言ってC++を一番書いています。最も好きなのはOCamlです。ほかは Java, Scalaあたりを一番使ってきたと思います。 仕事ではC++とかgoを書いていることが多いです。JavaScriptも必要に応じて結構書きます。 プログラミングコンテスト ICPCあたりに出場することに、過去お熱でした。我々が現役の頃は、今と違って国内のICPCはやや平和な感じでしたが、世界には通用しませんでした。我々の下の代あたりから、半分がICPC OB/OG会のせいで半分はIOIのせいだと思うのですが、急激に強くなっていった印象があります。 ACM-ICPC 2004-2005 World Finals, Shanghai, China: (Gokuri) ACM-ICPC 2004-2005 Asia Regional, Manilla, Phillippin: 1st place (Gokuri-squeeze) ACM-ICPC 2004-2005 Domestic: 1st place (Gokuri-squeeze) ACM-ICPC 2003-2004 Asia Regional, Aizu: 5th place (Gokuri) ACM-ICPC 2003-2004 Asia Regional, Korea: 16th place (Gokuri) ACM-ICPC 2003-2004 Domestic: 1st place (Gokuri) ICFPプログラミングコンテストも過去2年に一回ぐらい色々出場していますが、わりと成績は忘れています。これは、どちらかというとお祭りです。 https://mayah.jp/publications/ Mon, 11 Aug 2014 00:00:00 +0000 https://mayah.jp/publications/ 本 / 電子書籍 アルゴリズムを学ぼう ちょっと初版は誤植が多くて死にたいので、誤植が取れた2版を探してください。 続・アルゴリズムを学ぼう アルゴリズムマスターによる競技プログラミング入門 同人誌の商業化。 同人活動の一環として発行した本は、同人サークルYUHAの発行物をごらんください。 そのほか、SIG2Dにも寄稿しています。 ソフトウェア 作ったもののうち、ある程度面白そうなものを。 ぷよぷよ AI VCAのぷよ通を、画像解析してAIが考え、マイコンが操作する、というもの。 partake.in イベント開催支援サイト 最中限 (iPhone App) 監修 王様達のヴァイキング 技術的な部分を詰める仕事。 Papers Shinya Kawanaka, Yevgen Borodin, Jeffrey P. Bigham, Daren Lunn, Takagi Hironobu, Chieko Asakawa: Accessibility commons: a metadata infrastructure for web accessibility. In Proceedings of the 10th international ACM SIGACCESS Conference on Computers and Accessibility (Halifax, Nova Scotia, Canada, October 13 - 15, 2008). https://mayah.jp/article/2011/sourcecode-balancesheet/ Wed, 09 Feb 2011 00:00:00 +0000 https://mayah.jp/article/2011/sourcecode-balancesheet/ バランスシートには、資産、負債、純資産の項目があり、資産＝負債＋純資産が常に成り立ちます。さて、いまここにあるソースコードを資産だと思いましょう。すると、それは負債と純資産からなっている、ということになります。 では、ソースコードにおいて、負債や純資産とは何でしょう。 負債は後で返さなければならないものです。借りっぱなしにしておくと、利子が発生します。ソースコード上でこれに対応するのは、汚いコード、ゴミコード、やっつけ仕事のコードです。これは、とりあえずソフトウェアを動かすには必要なことがあります。借金のおかげで急場をしのげて助かった、そういう経験がある人もいるでしょう。ですが、負債なので、あとで返済しなければなりません。世の中には、技術的負債という単語があります。まさにそういうことです。 ここで少し注目したいのは、コードにも利率が存在することです。本当のゴミコードは、ヤミ金の如く利率が高く、真っ先に返済しなければなりません。後で問題になるかもしれないけど、まあしばらくは問題が起きないだろうというコードもあって、こちらは利率が低いので後回しでも構いませんし、実際に後回しにされます。 純資産とは何でしょう。これは、問題が起きにくいコード、きれいなコード、よくテストされたコード、などとなります。ここで面白いのは、純資産にも利子が存在することです。純資産が溜まっていくと、その部分のコードは問題がおきにくく、それに依存したコードの開発が加速します。これは非常に良いことで、こういうコードをたくさん積み重ねていくことで、企業にとっての価値になるでしょう。 純資産の方には、技術的負債のような単語を見つけることができませんでした。何か良い言葉、ありますか？ https://mayah.jp/article/2010/ocaml-basic-syntax-master/ Mon, 01 Nov 2010 00:00:00 +0000 https://mayah.jp/article/2010/ocaml-basic-syntax-master/ OCamlとは OCaml は Haskell とは違って純粋でない関数型言語です。ML (Meta Language) という言語ファミリーの方言の一つで、フランスの INRIA という研究所で開発されています。速度を稼ぐために命令型のように書こうと思えば書けるし、遅延評価もデフォルトではしません。その分、実用的なアプリケーションが書きやすくなっています。 他の言語をある程度知っている人は、これを読めば OCaml のとりあえずの基礎をマスターして OCaml を書くことができるようになります。他の関数型言語の知識は仮定していませんが、C/C++ ぐらいの知識があれば読めると思います。元の Perl 基礎文法最速マスターではリファレンスぽい作りですが、チュートリアルぽくなってしまいました。 なお、読んでいると分かりますが、色々とめんどくさいことが多いように感じます。しかし、これをちゃんと書くと、コンパイルに通るだけでかなりの数のバグがつぶれてくれているという恩恵を受けられます。我慢して使うといいことがあります。はじめは我慢してみてください。 この文章には不足やバグがいっぱいあると思いますので是非指摘してください。 他の最速マスター系は はてな的プログラミング言語人気ランキング あたりを見てください。 基礎 OCaml はコンパイルして実行することも対話型インタプリタで実行することもできますが、ここでは対話型インタプリタで実行します。対話型インタプリタは ocaml コマンドで起動します。 とりあえず、適当に値や式を打ち込み、;; を入力するとそのまま評価されて出力されます。 ごらんの通り、型と値が表示されます。1.0 は float 型になっていますが、OCaml の float は C の double と同じです。C の float に相当する型は、標準にはありません。 print 系で表示をするには、print_int などのように型を付けるか、Printf.printf を使います。 ここで、1- : unit = () の様に表示されているのは、1 は print_int によって表示された部分で、- : unit = () は OCaml のインタプリタによって表示された部分です。OCaml では全ての式は値を持ちますが、特に意味のない値として、() という値が定義されています。これは unit という型を持ちますが、void みたいなものだと思ってしばらくはかまいません。 なお、コメントは、(* コメント *) のように (* *) でくくります。コメントはネストができるので、(* (* some *) *) も正当なコメントです。 https://mayah.jp/article/2009/acm-icpc-preliminary/ Thu, 31 Dec 2009 00:00:00 +0000 https://mayah.jp/article/2009/acm-icpc-preliminary/ 凡例 難易度は☆５段階で表しています。★は☆半分を表します。 ☆　：非常に易しい。全員が解いてほしい問題。 ☆☆　：易しい。アジア地区予選に進む為には絶対に解かなければならない。 ☆☆☆　：標準。アジア地区予選に進む為にはこのクラスの問題を１つは解けなければならない。 ☆☆☆☆　：難しい。上位に食い込む為には解かなければならない。 ☆☆☆☆☆：大変難しい。上位陣でも難しい。 解法・アルゴリズムでは、キーとなるアルゴリズム名を書いています。ad-hoc と書いてあるものは、その場その場で実装して解いていく問題を表しています。 ソースは、私が解いたソースへのリンクを張っています。 公式の output や PKU での問題と解答を比較していますが、解答が提供されていない問題もあるため、正答と比較出来ない場合があります。その場合備考に “Not Verified” と書いてあり、ソースの正当性は担保できません。間違っている恐れもあります。また、他の人が解を既に公開している場合、その解との比較を行って正解と見なした場合、その解へのリンクを張っています。また、PKU やプログラム・プロムナードへのリンクも、あれば張っています。公式の output があるものは PKU は通してないので、PKU だと TLE になる可能性があります。 1998 年 日本地区予選が始まった年。今から見ると簡単な問題のみで構成されています。それでもみんな解けていません。 1999 年 問題が5題に。今から見るとそれほど難しい問題は出ていません。 正答例がないため、Naoyuki Tamura さんの解答と比較しています。 2000 年 前年よりは少し難しくなっていますが、まだそれでも今よりは簡単でしょう。E はやや問題文が理解しにくい。 この年の問題も正答例がないため、Naoyuki Tamura さんの解答と比較しています。 2001 年 前年と同程度の難しさ。 正答例が提供されていないため、東工大 Wiki の正答例と比較しています。 2002 年 幾何問題が少し難しいですが、今のチームのレベルならおそらく全部解かれてしまうでしょう。A-D は今なら 80 分ぐらいで処理されてしまうかも。 東工大 Wiki, ACM-ICPC OB/OG の会に投稿されたソースと比較。C, D は未比較のため間違っているかもしれません。 2003 年 E とそれ以外の難易度にかなり差があります。４問正解チームがかなりあり、全問正解は１チーム (Gokuri、自分のチーム)。E は探索ですが、ヒューリスティクスが必要なところが難しくなっています。最小全域木のアルゴリズムを知らないと、この年は苦しい戦いになったでしょう。 https://mayah.jp/article/2008/code/ Wed, 29 Oct 2008 00:00:00 +0000 https://mayah.jp/article/2008/code/ 次の3つのブログエントリがありました。 プログラミングテクニックのまとめ 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント 優秀なプログラマは空気を読んで空気を描く 美しいプログラムの書き方についてですが、これをネタに何を考えながらコードを書くべきかについて議論します。 槍玉に挙がっているのは、次の３か条です。 変数のスコープは小さく抑える Do Not Repeat Yourself (DRYの原則) 同じコードは2度書くな 言語を極めよ 何人かは、それは「ケースバイケース」であると主張しましたし、それは間違っていません。しかし、ケースバイケースだと言うのは簡単ですが、それでは言われた方は何をしていいかわからず、結局そこから何も学ぶことができません。 そこで、このエントリでは、1つの指針を与えます。考えなければならないことを減らせるように書くということです。 変数のスコープは小さく抑える 変数のスコープを小さくすると、考えなければならないことを減らせます。変数が、そのスコープの中にしかないことは分かっているので、他を見る必要がないからです。 しかし、わざわざグローバルに参照できるところに変数をおくことで、考えなければならないことを減らせることもあります。もし、プログラムの様々な場所で、その変数に依存するような動作をするならば、きっとそれはグローバルにおくべきなのです。例えば、まれに変更される設定変数などが良い例です。ここで、グローバル変数と言っているのではなく、グローバルに参照できる変数と言っていることに注意してください。グローバル変数かもしれませんし、シングルトンの様なものかもしれません。 言語のいろんなパラダイム、例えば関数型言語やオブジェクト指向も、それぞれのやりかたで考えることを減らすのに成功しています。関数型言語は変数の書き換えを許さないことが多いですが、これは一度定義されてしまえばそれ以降変更されている箇所を探す必要がないという点で考えるべきことが少なくなっています。オブジェクト指向も、変数を変更できるのはオブジェクトのメソッドを通してのみ、ということになるためそのクラスのみを見ればよくなります。 Do Not Repeat Yourself (DRYの原則) 同じコードは2度書くな これも、結局は考えることを減らすのに他なりません。しかし、これはいつ考えるかを減らすものです。 コピペコードは、その場で考えることを減らしています。しかし、後に変更をする場合には苦しむでしょう。これは思考を先送りにしていると考えることができます。これは、技術的負債に対応すると考えることができます。 同じコードを2度書かないようにするのは、今は苦しいかもしれません。しかし、上手く設計されたコードは純資産であり、将来考えるべきことを減らしてくれるでしょう。 言語を極めよ これも、考えることを減らすことにほかなりません。言語はある程度極めて、息を吸うように記述できるぐらいでなければなりません。わざわざあれはどうかくんだっけ？　と言語の機能を探すようでは、そちらに気を取られるばかりで必要なことを考える時間に支障がでるからです。 もちろん、極めるのは言語だけではだめで、アルゴリズムなどに関してもある程度は何も見ずに書けるようになっておく必要があります。 プログラムを書く以上、少なくとも一つの汎用言語をかなりの水準で極めておくべきです。できるだけモダンな奴が望ましいでしょう。関数型言語をおすすめしますが、C++でもJavaでも構いません。しかし、少なくとも一つの言語をきわめて置けば、新しい言語を学ぶときにも非常に役に立ちます。新しい言語のこの機能は、前にやった言語のあの機能とおなじ、というように覚えるべきことが少なくなっていくからです。 まとめ 将来無駄に考えなければならないようにならないかを今ちょっとだけ考えてからコードを書くのです。そして、余計なことを考えないでもよいように、考えなければならないことを減らすための投資をしましょう。それには言語の習得、アルゴリズムの習得など、様々な勉強が必要です。頑張りましょう。 https://mayah.jp/article/2008/domestic2008/ Thu, 10 Jul 2008 00:00:00 +0000 https://mayah.jp/article/2008/domestic2008/ 国内予選総評 2008 年度の国内予選は７月４日にインターネット上で行われ、およそ２５０チームが参加しました。試合時間は３時間。予選突破するためには、３問を素早く正解するか４問を解く必要がありました。例年３問解けばまずアジア地区予選に進出できていたことからすると、やや問題が例年より易しかったにせよ、選手のレベルが上昇しています。また、全問正解が３チームあり、上位層のレベルもあがっています。 以下、各問題を解説していきます。それぞれの問題に対して、難易度／目標時間／必要能力（実装力・数学力・知識）を示した後、問題の概要、そして問題の解説を行っています。 難易度は ☆ の数（最高５つ）で表しています。★は☆半分を表しています。 ☆の問題は、これを解けないようではもっと基礎的な部分を練習する必要があるような問題を表しています。 ☆☆の問題はアジア地区予選に出場するためには絶対に解かなければならない問題です。 ☆☆☆の問題がすべて解ければアジア地区予選に大学トップであればまず出場可能であるレベルを表しています。 ☆☆☆☆の問題は、上位を狙うならばぜひ解いてほしい問題です。 ☆☆☆☆☆は、まず時間内には解けない問題を表しています。 問題を解く目標時間は、問題を読み始めてからどれぐらいの時間で正解を出してほしいかと表しています。この目標時間は３段階に分けており、上位チーム／中位チーム／下位チーム向けの目標時間を記述しています。 問題を解く必要能力は、実装／数学／知識／応用の４つに分けて示しています。実装は実装のタフさを、数学は数学的知識を、知識はアルゴリズムの知識を、応用は必要とされるひらめきの力や基本的なアルゴリズムを適用することの難しさなどを表しています。 問題概要は、問題の概要を簡単にまとめて記述しています。 それでは、各問題の解説に入ります。おおよそ易しい問題ほど丁寧に解説してあり、問題に取り組む人のレベルに沿って解説してあるつもりです。 問題セットは、公式サイトから入手できます。 問題Ａ Equal Total Scores 難易：☆（大変易しい） 目標：７分／１０分／１５分 能力：実装１／数学１／知識１／応用１ 概要：太郎と花子に手札がそれぞれ n, m 枚与えられる。手札には点数がついており、太郎と花子の手札を一枚ずつ交換して二人の点数を等しくしたい。どの手札を交換すればよいか？　複数の交換方法がある場合、交換した手札の合計点が少なくなるものを選べ。 例年問題 A は非常に易しい問題が出題されます。これが一瞬で解けないようでは国内予選通過はままなりません。おおよその傾向ですが、問題 A は問題文に書いてあることをそのまま実装すれば良いようになっています。もし、問題 A が解けないようであれば、まず「どのようにすれば二人の手札の合計点を等しくなるようにできるか」を日本語で書き下してみることから始めましょう。 今回の場合、次のようになります。 太郎と花子の手札を読み込む それぞれの合計点を出す 太郎から手札を一枚、花子から手札を一枚選んで交換する 交換したときの太郎と花子の合計点を求める 等しければ解の候補。今まで解が出てなければそれを解とし、解が出ていれば交換した手札の合計が前に出た解よりか小さいかを確認し、小さければ解とする 選ぶ手札がなくなるまで 3 に戻って繰り返し 解が見つかれば解を表示。なければ -1 を表示。 まずこの作業をせずにプログラムを書こうとすると、問題 A が解けない様な初心者のうちは何を書いているのかわからなくなるでしょう。 問題 A がすらすらと解ける様になるまでは、まずこの作業をしてからそれをプログラムに直すようにしましょう。 では、これをプログラムに直していきます。ここでは STL を用いた C++ のコードを使って例示します。 まず、問題を読んでいる間に、手の空いた人がテンプレートコードを打ち込みます。 テンプレートを打ち込んで問題を理解したら実装の開始です。ICPC では入力／計算／出力がきれいに分かれることが多いので、私はいつも main 内で入力／出力を行い、計算部分は solve という名前の関数を作ってそこで計算を行っていました。ここでもそのように実装していきます。 https://mayah.jp/article/2008/db/ Tue, 01 Jan 2008 00:00:00 +0000 https://mayah.jp/article/2008/db/ MySQL コンソールでの接続の仕方 ユーザー A でデータベース B に接続する場合。 -p は、パスワードによる制限がかかってない場合は不要です。 ユーザーの作り方 データベース A に全ての権限がある、ローカルホストからアクセスできるユーザー B を、パスワード C で作ります。データベース A はまだ作られていなくても、このユーザー B は作ることができます。 データベースの作り方 データベース A を作ります。データベースを作る権限のあるユーザーでなければなりません。 PostgreSQL コンソールでの接続の仕方 ユーザー A でデータベース B に接続する場合。 MySQL と似ているが、細かいオプションは違います。psql は、ディストリビューションなどによっては、バージョンが指定された psql83 などという名前になっている可能性があります。 Postgres の管理は、ユーザー postgres になって行うのが普通です。 ユーザーの作り方 シェルから行ないます。権限を持ったユーザー (postgres 等) になって操作する必要があります。ユーザー A をパスワード付きで作りたい場合、次の様にします。 このとき、管理者権限を与えるかなどが対話的に聞かれます。 もしユーザー postgres から接続できるのにここで作ったユーザーから接続できない場合、postgres の設定がおかしい可能性が高いので注意します。具体的には、パスワード認証を受け付けない様な設定になっているかもことが多いです。pg_hba.conf (具体的には /etc/postgresql/8.3/main/pg_hba.conf など) を参照して、パスワードを受け付ける設定かどうかを確認します。 #1 の様に設定されている場合、パスワード認証がなされていません。#2 のように書き換えます。 データベースの作り方 データベース B を作るには、シェルから次の様に入力します。 ORACLE コンソールでの接続の仕方 ユーザー A 、パスワード B で SID C に接続する場合、次のようにします。 https://mayah.jp/article/2007/japan2007/ Thu, 01 Nov 2007 00:00:00 +0000 https://mayah.jp/article/2007/japan2007/ 2007 年アジア地区予選日本大会総評 2007 年は試合時間５時間で、出題された問題セットは簡単な問題から難しい問題までバランスがよく取れたセットであり、実力が十分に反映されるセットでした。このとき京大の echizen がこのセットを９問解き、海外からの強豪もはねのけて見事優勝しました。このセットで９問解かれるととしか言いようがないですね。 問題セットは、公式サイトから入手できます。 Problem A: And Then There Was One 難易： ☆（易しい） 目標：１５分／２０分／２５分 能力：実装２／数学１／知識２／応用１ 概要：石が n 個円上に並んでおり、時計回りに 1, 2, …, n と名前を付ける。はじめに m 番目の石を取り、次にそこから時計回りに k 個の間隔をあけて石を取っていった場合、最後まで残るのは何番目の石か？ 一番易しい肩ならしの為の問題。日本地区予選では問題 A に一番易しい問題が基本的にくるので、さっさと解いて調子にのりたいところです。 ある程度アルゴリズムに詳しい人であれば、これがヨセフス数を求める問題の応用問題であることに気がつくと思いますが、n がそんなに大きくないのでヨセフス数を求めるアルゴリズムを知らなくても実際にシミュレーションして求めることも可能です。 シミュレーションしようと思ったら、まずそれが「可能であるかどうか」を問題の条件から読み取る必要が有ります。本番では実行時間３分の間に解を出さなければなりません。あまりにも時間のかかるアルゴリズムは例えそれが正しい解を出力するものであったとしても不正解扱いされてしまいます。従って、まず時間に間に合うかを考える必要が有ります。 今回の問題の場合、石を vector か list で表し、実際に取り除いていけば良いでしょう。vector で表すと、次の k 番目の石を見つけるのは足し算と剰余演算で O(1) で出来ますが、取り除いたあとでつめる作業が O(n) かかります。list で表すと k 番目の石を見つける作業は O(n) かかりますが (O(k) でないのは実際には k mod n 進めれば十分だから)、取り除く作業は O(1) ですみます。どちらも計算量の観点からするとそんなに差はなさそうです。そういう場合は迷わず vector を選びしょう。その方が概して計算量の定数部分が小さいので高速に動く上、またコードも楽に記述できるからです。 Problem B: Prime Gap 難易： ☆（易しい） 目標：１５分／２０分／２５分 能力：実装２／数学１／知識２／応用１ 概要：連続した素数 p, p + n の間の合成数の列 p + 1, p + 2, …, p + n - 1 を、長さ n の prime gap と呼ぶとき、与えられた整数 (1299709 以下) を含むような prime gap の長さを出力せよ。 素数の列挙は、2008 年の国内でも出てきましたが、エラトステネスのふるいで OK。 https://mayah.jp/article/2007/nico/ Tue, 02 Jan 2007 00:00:00 +0000 https://mayah.jp/article/2007/nico/ 何ですか？ ニコニコ動画のコメントをフィルタするためのツールです。Java で書かれており、プロキシとして動作するため、OS を選ばず動作します。 何ができますか？ 今のところ次のことが可能です。 コメントの ID を(アプリケーション内に)表示 NG ID で指定されたユーザーのコメントを取り除く NG Word が含まれたコメントを取り除く NG ID を他人と共有 注意してほしいのは、あくまで NicoFilter はプロキシとして動作するため、一度プロキシを通り抜けたコメントは取り除けないことです。この場合キャッシュを無効にしてページの再読み込みを行ってみてください。 とりあえずの機能として上のものを実装しましたが、Proxomitron で可能なことがほとんどです。しかし、Proxomitron は正規表現+αぐらいしか出来ないので、将来的にはなんとか。と思ったけど、JavaScript でかなりどーとでもなりますね…JavaScript では出来ず、プロキシとして実装することに面白いことがあると良いのですが。 使い方 Java 1.5 で書かれているため、JRE (Java Runtime Environment) を要求します。たいていの方は既に JRE 1.5 をインストールしていることとは思いますが、インストールしてない場合はこのへんから JRE をダウンロードして下さい。 zip を展開する ダウンロードしてきた zip ファイルを展開します。 Proxy 立ち上げ nicofilter.jar をダブルクリックして NicoFilter を立ち上げます。 ブラウザ設定 ブラウザに、NicoFilter 経由でウェブにアクセスするように設定させます。NicoFilter はポート 8080 番を使用しますので、そこを通すようにします。 [ツール] -> [インターネットオプション…] -> 接続 を選んで下さい。「設定を自動的に検出する」のチェックボックスを off にし、「LAN にプロキシサーバーを使用する」を on にします。 同じページの「詳細設定…」をクリックし、HTTP の部分だけアドレスを localhost、ポートを 8080 にします。それ以外は空白にしてください。「全てのプロトコルに同じプロキシを利用する」はチェックをはずしてください。 https://mayah.jp/article/2007/cell/ Mon, 01 Jan 2007 00:00:00 +0000 https://mayah.jp/article/2007/cell/ ppu-gcc と spu-gcc デフォルトでは、ppu-gcc は 64bit (LP64) でコンパイルされ、spu-gcc は 32bit (ILP32) でコンパイルされてしまうようです。PPU, SPU 間で struct を交換しようとする場合は、型の大きさが違うので注意を要します。 video mode PS3 上で FC5 を動かす場合、BENQ の HDMI displya にはビデオモード 133 が最適なようなので、/etc/kboot.conf に次のように書いておくと良いでしょう。 https://mayah.jp/article/2006/make/ Mon, 02 Jan 2006 00:00:00 +0000 https://mayah.jp/article/2006/make/ make とは make は、決められた規則に従って必要なコマンドを自動的に実行してくれるツールです。もともとは C 言語のコンパイル・リンクを行うために作られましたが、現在ではソフトウェアのインストールや一時ファイルの消去など、様々な場面で使われています。 make は、更新時刻を見て必要なファイルのコンパイルだけを行ってくれるなど、ソフトウェアの生産性を大幅に向上させることが可能です。 make を使うためにすることは、Makefile と呼ばれる設定ファイルを書くことだけです。Makefile を書けば、後は makeと叩くだけで必要なことが全て行なわれます。 最初の Makefile まず簡単な Makefile の書き方を説明します。ここでは、prog1.c, prog2.c という C 言語のソースと、ライブラリ libm.a を使って、実行ファイル prog を作ることを考えましょう。Makefile を使わないならば、次のようにしてコンパイルをするでしょう。 毎回これを入力してコンパイル・リンクをするのはそんなに大変ではないかもしれません。しかし、ファイルの数が 100 個あったらどうでしょう？　100 個もあるとコンパイルだけでも時間がかかってしまいます。分割コンパイルをするために何度もgcc -c prog39.c等と入力するのは大変です。そんなときこそ make の出番です。 上の例をコンパイル・リンクするために Makefile 必要な記述は次のとおりです。注意するべきは、インデントが必要なことと、インデント には TAB 文字を使わなければならないことです。 それぞれのエントリは、コロンの左のターゲット名、コロンの右にある依存関係、そして TAB 文字から始まる、ターゲットを作成するためのコマンドからなっています。 makeと叩くと、まず最初に現れるターゲットを作成しようとします。つまり、この例だと prog です。prog : prog1.o prog2.oは、prog には prog1.o, prog2.o という依存関係があるという意味で、これは prog を作るためには prog1.o と prog2.o が必要であるということを示しています。そこでまず prog1.o と prog2.o というターゲットを作ることを試みます。それが出来たとしたら、gcc -o prog prog1.o prog2.o によって、prog が作られます。 https://mayah.jp/article/2006/bixid/ Sun, 01 Jan 2006 00:00:00 +0000 https://mayah.jp/article/2006/bixid/ biXid is a programming language for mutual conversion between XML docuements. Paper Abstract Often, independent organizations define and advocate different XML formats for a similar purpose and, as a result, application programs need to mutually convert between such formats. Existing XML transformation languages, such as XSLT and XDuce, are unsatisfactory for this purpose since we would have to write, e.g., two programs for the forward and the backward transformations in case of two formats, incur high developing and maintenance costs. https://mayah.jp/article/2005/jshark/ Sat, 01 Jan 2005 00:00:00 +0000 https://mayah.jp/article/2005/jshark/ SHARK SHARK は、ペンで文字を入力するためのインタフェースの一つです。キーボードの上をペンでなぞることによって、文字を入力することが出来ます。 内部に辞書を持っており、ある程度雑に書いても適当に補正されるのが特長です。 JSHARK JSHARK は、ペンで日本語を入力するためのインタフェースで、SHARK のアイデアをもとに作られました。SHARK 同様、キーボードの上をペンでなぞることによって日本語を入力します。 日本語は文字数が多いので、一文字一文字割り当てているとキーの数が多くなってしまいます。そのため、同じキーに２つの文字を割り当て、それをシフトさせる動作を導入することで、ある程度問題を解決しました。 入力方法 アプリケーションをを立ち上げるとキーボードが表示されます。 この状態で、たとえば「あきしののみや」と入力するには、次のようにペンを動かしてください。 基本的には角度が急激に変わっているところを検出し、そのキーの左上の文字をキーボードエミュレーションにより入力します。 キーの右下の文字を入力するには、次のように、キーの上でまるを書いて、線を交差させてください。たとえば、「ぎりしゃ」と入力するには…… 右クリックでコンテキストメニューをだすと、次の設定が出来ます。 なお、入力中に間違えたと思ったときは、「今のなし！」上でペンを離せば、入力はなかったことになります。 ダウンロード Windows XP 以降で動作します。Windows 2000 でも動くかもしれませんがテストしていません。 ソースのコンパイルには boost が必要です。ここではあんまり使ってませんけど。 バイナリ + MFC DLL(mfc71.dll, msvcr71.dll) ソース一式 (VS.NET 2003, C++ で記述) ライセンスは modified BSD とします。著作権は放棄しませんが、あなたが変更して利用するのは自由です。 参考：NetBSD のライセンスと再配布について TODO キー配列を考えた方がよい。五十音はひどい。 同じ文字が連続で入力しにくい (SHARK2 のように空白部分があるといいかも？) シフトの感度が良すぎるのをなんとかする 頻度ファイルの形式、頻度の見方 実は入力文字の長さ N に対して、動作が O(exp(N)) かかる！ (手抜き仕様) CTRL とか Shift とか。ファンクションキーとか。 入力した後に「今のなし！」したい (by いろんな人) 頻度に関しては、漢字まで入れてやるとより精度が出るらしいが、ちょっとこのアプリケーションの範囲を超えますね。 参考文献 ソフトウェアキーボード(基本的な作り方のヒントを得た) SHARK2 Pen https://mayah.jp/article/2004/ruby/ Fri, 02 Jan 2004 00:00:00 +0000 https://mayah.jp/article/2004/ruby/ C/C++, Java は使える、大学で ML とか Scheme もやった、そろそろスクリプト言語を覚えたい、という人向けに、 一時間で Ruby がある程度 (日常的な処理が少しは出来る程度) 使える様になるまでをまとめます。他のスクリプト言語の知識は仮定しません。 このページでは、例示による学習を期待しています。 すなわち、例と結果を与えられることでその意味を理解するということです。 これが出来ないと一時間で使えるようになるのは厳しい。 オブジェクト指向、正規表現と聞いて一つでも意味が分からない人は別のところで勉強してください。 速習を目指しているので、細かいところは全部割愛しています。 とりあえず使えるようになった後にちゃんとした入門書を読んでください。 とりあえず動かす (10 分) Ruby はインストールされているものとします。とりあえず rubyと叩いて起動。 $ ruby 出力できなければ話にならないので、まず出力を覚えます。 puts, printぐらいを覚えておけば良いでしょう。 前者は勝手に改行し、後者はしません。 print "fugahoge\n" puts "fugahoge" [EOF] fugahoge fugahoge ruby と叩いて得られるものは対話実行環境ではないので、明示的に EOF を送らないと実行されません。 それは面倒なので irbと叩いて interactive ruby を起動します。 irb(main):001:0> puts "fugahoge" fugahoge => nil これで interactive に結果を得られます。 => 以下は式を評価した結果が返ります。この場合 nil が返っています。 >の前はプロンプトですが、 ここでごちゃごちゃ書くのは面倒なので以降では省略します。 puts, print以外に pも覚えましょう。Ruby では任意のものはオブジェクトであり、pはその中身を見るための関数です。 > p "fugahoge" "fugahoge" => nil 文字列はそのまま文字列が返される、と。 https://mayah.jp/article/2004/continuation/ Thu, 01 Jan 2004 00:00:00 +0000 https://mayah.jp/article/2004/continuation/ coroutine とは ここでは coroutine を「実行の途中でリターンでき、さらにそこ(実行の途中)から再開することが出来る何か」の意味で使用します。適当な疑似言語で書くと次の通り。関数の途中でのリターンを suspend(), 途中からの再開を resume() で表すことにします。 ここでは、これを scheme の call/cc を用いて表すことを目指します。 call/cc とは call/cc とは、call-with-current-continuation という scheme の関数で、「現在の継続(current continuation)を生成し、それを関数に渡してその関数を実行する」ものです。読者の殆どは「継続」についてよく知っているかもしれませんが、基本的な概念を以下に説明します。 継続とは何か 「継続」とは、「式の評価の途中のある時点で、現在までの値を使ってそのあとしなければならないこと」を意味します。例を挙げましょう。((lambda (x) (+ 5 (* x x))) 10)を考えます。これは、次の様に評価されます。 さて、(a) の時点でその後に評価しなければならないことはなんでしょう。おわかりかと思いますが、得られた値 100 を使って、(+ 5 100)を実行すること i.e. 得られた値に 5 を足すことです。 ここで、得られた値を xとし、これを関数に渡すことにすれば、5 を足すことは (lambda (x) (+ 5 x))と表現できます。上の関数を全てこの形に、即ち得られた値を引数として関数を呼び出す形にすると、次のように書けます。わかりやすいように分解して書きましょう。 もう少し簡単な例を考えると； さて、この式が (b (c d))を評価した後の継続は何ですか？　あとしなければならないこと「継続」は、その値 xを使って、(a x)を実行すること、すなわち、(lambda (x) (a x))だと言えるでしょう。 call/cc 以上の概念が分かれば、scheme の call/cc を理解することもそう難しくは無いでしょう。 (call/cc func)は、現在の継続 cont を生成し、これを引数として (func cont)を実行します。例えば、次の通り。 https://mayah.jp/article/2003/musicpad/ Wed, 01 Jan 2003 00:00:00 +0000 https://mayah.jp/article/2003/musicpad/ The Music Notepad とは？ The Music Notepad は、Brown Universityで開発された、手書きで楽譜を書く事の出来るシステムです。 今回、大学でこれに似たシステムを作ってみるということをやってみました。結構面白いと個人的には思っているので、公開してみます。 お断りしておかなければならないこととして、私は音楽に関しては本当に素人であり、学校で習った程度の知識しかありません。日常的に楽器を弾いたり、歌を歌っている訳ではありません。楽譜の書き方も誤りがかなりあると思われます。そんなときは……笑って許して下さい。或いは、メールでお知らせ下さい。 出来ること・出来ない事 まず、出来ることと出来ないことを明らかにしておきます。私の実装では、出来る事はほんの一握りで、とても基本的なことしか出来ません。Java のキホンすら忘れていましたし、instanceof を初めて知ったとか、そういうとても駄目駄目な状態から、実質 50 時間程度で Java を覚えながらの実装です。今から考えると異常に時間がかかってますね。本当に基本的なことしか出来ません。 まず、出来ることは次の通りです。 音符・休符の入力 (全音符から三十二分音符まで) beam (音符をつなげること) シャープ・ナチュラル・フラットを付ける、符点を付ける 消去 出来てもよさそうですが、次のことは出来ません。(そんなに難しいことではないので、時間があれば出来る様になったでしょうが) 小節線をひくこと 連符 一度 beam したあと、部分的に音の長さを変えること 楽譜のフォーマット・保存 音符の移動・コピー・ペースト ジェスチャー一覧 以下にジェスチャーの一覧を示します。それぞれについて説明をします。 実際に動かして遊んでみる 動かして遊んでみたい人は、ダウンロードへ。applet にしようと思ったのですが、何故か上手く動かなかったもので。appletviewer でなら動いたのに。 尚、Play はおまけで、まともな演奏が出来るわけではありません。かなりヨタヨタした演奏になります。三十分程度でおまけ的につけたものなので、あんまり期待しないで下さい。Java の version は 1.4 以降がオススメです。古いと javax.sound.* が使えなくて落ちるので。また、Play 中は他の動作をしないで下さい。これは仕様です (?) (考慮してないという意味では仕様なのだろうが。) また、なんか表示されないなー、というときは repaint ボタンを何回か押してみるのが大人の対応です。Java の初期化順を考慮してなかったので、しばしば最初が表示されません。つーか、知らなかったのな、初期化順序なんか。 ダウンロード もうちょっとまともにして動かしたいという人には、ソースコード (Java) を提供します。テキトーに製作しているので、ライセンスは NYSL とします。3000 行に満たないくらいの小さなものですが、相当読みにくいと思います。万が一読むのなら、Score.java から読む事をオススメします。 ソース及びバイナリのダウンロード (104KB) https://mayah.jp/article/2002/gprologgc/ Thu, 03 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/gprologgc/ gprolog の残念な実装 prolog というプログラミング言語を使ったことのある人は，恐らくかなり少ないでしょう。prolog は、backtrack を言語として自然に持っていて、パズルを解くなどのことは、C 等の所謂手続き型言語に比べて、簡単に書くことの出来る言語です。コンピュータ関係に従事している人は、常識の一つとして知っておいても損はありません。 prolog の一つの処理系に、gprolog という、GNU の prolog 処理系があります。これを大学で演習に利用することになったのですが、少し複雑な再帰を書くと、すぐにメモリを大幅に使ってしまい、GLOBAL stack overflow で処理系ごと落ちてしまうということが良く有ります。 実は、gprolog は、GC の実装があまり良くありません。gprolog のソースを読んでみると分かりますが、実際に GC が起こる場合は、unification が fail し、backtrack が起こったときだけです。従って、いかにして backtrack を起こすか、ということが重要になります。また、gprolog は、末尾再帰を実装しておらず、これも、メモリを大幅に使ってしまう一つの要因となります。 以下の節で、gprolog で有効に GC を起こし、gprolog を快適に利用する方法を紹介します。(prolog 自体を有効に使いたい人には、gprolog はお勧めしません。SWI-prolog などを使うのが良いでしょう。) 失敗駆動ループ 先程も述べた様に、gprolog でメモリを解放するには、fail し、backtrack することが必要です。従って、失敗駆動ループを使えば、メモリを有効に使うことが可能です。 失敗駆動ループとは、fail し、backtrack することによって loop させる方法で、一般に次のように定義された述語 repeatを使って loop させます。 一般に、次の様な方法で用いることが多い様です。 規定回数 loop させたい場合は、for を使った loop にするのが良いでしょう。 ただ、これらの方法は、作り方を多少考える必要があるため、今まで手続き型や、関数型言語に慣れている人には少々使いにくい方法かもしれません。 findall gprolod で depth first search を失敗駆動ループを使わずに書くと、Memory がいくらあっても足りません。しかし、findall を使うと、簡単に GC を起こすことが出来、メモリを節約することが出来ます。 例えば次のような述語を考えます(かなり適当に書いてます。メンバチェックも省略してますし。)。これは、Start から End への経路を探しているものですが、どこにも fail がないため、GC が起こりません。not_member や next で failする可能性はあります。しかし、Start から End を見つけるまでに述語を呼び出し、それで起こった unification によって使われたメモリは、解放されません。 https://mayah.jp/article/2002/reversi/ Thu, 03 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/reversi/ もともと大学の課題なので、データ構造等は結構適当に定められてしまっています。私が実際に書いたのは、yuha.pl のみ。 tplace.pl tplace.pl は、reversi の実装のための、簡単な gprolog のプログラムです。今回は、これを用いて reversi を実装することにします。以下、tplace.pl を簡単に説明し、それを使った簡単な思考ルーチンの実装である mak.pl を用いて、対戦させるところまでを一通り見ていきましょう。 ここでは、reversi の盤面を、次の様なリストで表します。 tplace.pl には、次のようなサービス関数(?)が含まれています。 mak.pl は、reversi の思考ルーチンのとても簡単な実装で、盤面に点数を付け、それが最も高いところに置くというものです。いくつか置ける場所がある場合は、もっとも石の数が多くなるところに置く様になっています。これは、実装をみてもらえば、すぐに理解出来るでしょう。 付属の othello.pl による、mak.pl 同士の対戦方法を示しておきます。まず、othello.pl を次の様に起動します。othello.pl の結果保存 directory を適切に変更してから起動して下さい。 次に、別のコンソール等で、次の様に mak.pl を起動します。 これで mak 同士が対戦している筈です。 negascout alpha-beta pruning については大体の人が分かっていることとして、ここでは、alpha-beta pruning の亜種である、negascout という枝狩り方法について、簡単に説明しておきましょう。 negascout では、alpha-beta pruning の前に、scout (偵察) を行うことで、枝刈りの回数を減らそうと試みます。この scout には、null window search が使われます。null window search は、alpha, beta の値をそれぞれ (alpha, alpha + 1) とすることで、必ず失敗する探索を行い、実際の alpha-beta pruning の範囲を絞り込むことを目的とします。null window search では、制約条件が (alpha, alpha + 1) ととてもきついため、沢山の枝刈りが行われ、この探索は早く終了します。 https://mayah.jp/article/2002/xhtml11/idea/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/xhtml11/idea/ WWW がどのようにして作られたのか、そしてネットワークがどのようなものであるべきかについての簡単な説明をします。 また、HTML とはどのようなものであるか、そして HTML 文書とはどのようなものであるべきかについての簡単な説明をします。 情報の共有 現代では多数の書籍や論文が発表され、大量の情報が流れる情報洪水の時代となっています。我々が実際に利用する情報は、その中の少数しか有りません。しかし、我々の処理能力を遥かにこえて情報が流され続け、実際に利用したい情報 (金) と、どうでもいい情報 (砂粒) が混じってしまっています。 その中から、本当に欲しい情報 (金) を見分ける作業は結構大変なものです。本屋に行って欲しい本を探し出すのに苦労した経験はあるでしょう？　今日我々が探さなければならない空間は、本屋の比ではありません。或る意味、全世界に広がってしまっています。 そして、本当に欲しい情報を見つけ出しても、その中に書かれてあることをさらに発展させようとイメージを膨らませると、その膨らんだイメージの情報を探し出すために、また膨大な探索空間を探らなくてはなりません。このような関連情報が、ある方面だけに偏って存在していれば、その近くを探せばなんとかなるかもしれませんが、実際そうなっているわけではないのです。古代の美術を研究しようとしても、それだけで古代史やら美術の手法やら、我々の求める「金」は、様々な方面に分散して存在していることが分かります。 より便利に情報を得る為には、関連はあるが分散している情報を連想方式で扱う必要性が生じてきます。即ち、情報と情報をリンク (関連づけ) し、連想的に他の情報を探し出せるようにすることです。情報と情報がリンクされた文書のことを、ハイパーテキストと呼んでいます。 1989 年、ティム・バーナーズリーは、CERN (欧州合同原子核研究機構) 内部の情報システムとして、ネットワークを使ったハイパーテキストシステムの導入を提案しました。CERN では、様々な種類のコンピュータが異なる文書システムを使っていたため、そのままでは情報の共有が困難でした。それを乗り越えるためにティム・バーナーズリーが考えた手法が、WWWと呼ばれる、共通の規則に則って情報を交換する仕組みだったのです。 WWW の標準化と W3C WWW を普及させる上で、ティム・バーナーズリーは、ユニバーサルという概念が重要であると考えました。つまり、一つの情報空間の中に全てをまとめ、全ての情報を等しく扱うということです。すなわち、全ての文書が等しく簡単にリンクできなければなりません。 記憶に新しいブラウザ戦争(Netscape と、Internet Explorer のシェア争い)によって、HTML 文書を閲覧するためのブラウザは、独自の拡張をし続けていきました。その結果、あるブラウザでは正常に表示されるが、別のブラウザでは崩れて表示されるという困ったことが頻繁に起こる様になりました。今日でも、IEで見てくださいとか、Netscape で見てくださいと書かれたサイトにお目にかかることが屡々あります。また、特定のブラウザのみでしか動作しないスクリプトが使われて、他のプラウザでは見ることの出来ないウェブページも存在します。これらは、ブラウザ戦争が残した一つの負の遺産であります。 このブラウザ戦争によって、WWW からユニバーサルという概念が消えつつありました。ティム・バーナーズリーは、WWW にユニバーサルという概念を取り戻し、そしてそれを維持していこうと 1994 年に、W3Cを設立します。W3C では、日々標準化に関する議論が行われ、その結果としての勧告 (Recommendation)は、WWW のユニバーサルという概念を支えるための基盤として機能しています。 HTML の標準へ W3C では、WWW の発展の為に様々な仕様を制定し、それを勧告していますが、その中に一貫した方法で情報を表現するXMLや HTMLがあります。XML は、マークアップ (文章にタグと呼ばれるものを用いて意味づけを行うこと) の取り決めのみを示すにとどまり、そこからの応用(アプリケーション)として様々な言語 (例えば、XSL, SVG, MathML, XHTML) が策定されています。 この文書では、XML がどういうものであるかをまず簡単に学び、その発展として、XML を用いて定義された XHTML で情報共有を行うことを目指します。現在、XHTML には XHTML1.0 や XHTML1.1 がありますが、ここでは、より厳密で柔軟性の高い、XHTML1.1 を用いたマークアップの方法を学んでいくことにしましょう。現在では XHTML2.0 が議論されていますが、これは今までの HTML から大幅に変わったものになりそうです。従って、普及までには時間がかかると思われます。ここではあまり触れませんが、W3C でなく、ISO からも、HTML 4. https://mayah.jp/article/2002/xhtml11/strict/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/xhtml11/strict/ HTML 文書制作 正しい HTML 文書を書くには、やはり実践が多少必要です。ここでは、簡単な HTML 文書を作成してみることで、今までの知識を整理して、実際に HTML 文書を書ける力を養います。 今回は、スタジオジブリの紹介を書いてみることにしましょう。権利関係の都合上、画像は使用しませんが、日本人にはなじみ深い内容であると思います。 最後に出来上がった HTML 文書には、様々な HTML の記述に関するコメントを散りばめています。是非、参考にして下さい。 文章を用意する 一番最初ですので、文章はこちらで用意してそれをマークアップしてみることにします。 文章は、dhibli.txtに用意しましたので、適宜参照して下さい。 骨組みの必要な部分を書き換える XHTML 1.1 で用意した骨組みの、必要な部分を書き換えます。 タイトルと、文字コード、address 要素の内容などを書き換えます。 大見出し ひな型に、文書の大見出しである h1 要素をまず追加しましょう。 本文の追加 次に、本文を追加します。段落は、p 要素としてマークアップし、見出しは、h2 等でマークアップします。 文書の関連づけと meta 要素の追加 次に meta 要素と link 要素で、文書のメタ情報と関連を表しましょう。 完成 以上で基本的な部分は完成しました。これでも十分実用に耐えますが、もう少し色々なものを付け足した、完成品を用意しました。ここには、記述に関するコメントも含まれているので、是非参考にして下さい。 完成品 https://mayah.jp/article/2002/ctrl-caps-windows-xp/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/ctrl-caps-windows-xp/ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout の中に、Scandode Map を作成し、変更したい物理キーの Scancode と、変更後の Scancode を並べて書き込むだけです。但し、Win2k, XP のみ対応です。 以下に例を。これを適当なファイルに保存して、拡張子 .reg をつけて、それを double click すれば大丈夫です。 https://mayah.jp/article/2002/xhtml11/xhtml/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/xhtml11/xhtml/ ユニバーサルな情報発進のために、正しい XHTML1.1 による文書作成方法を学びます。 ユニバーサルな HTML へ向けて これから、XHTML1.1 による文書制作を学んでいくわけですが、HTML の理念でもお話したように、情報を発進する手段としての HTML は、なるべく環境に依存しないものでなければなりません。もし、HTML 文書の中に、レイアウトに関する情報を含めてしまったとしましょう。もし、これを「携帯電話のブラウザ」と、「パソコンのブラウザ」の両方で利用したいと考えた場合、あなたはどうするでしょうか。携帯電話のブラウザでは、出来ることは限られています。それに合わせて制作すると、パソコンのブラウザでは表示が寂しくなってしまうかも知れません。また、パソコンのブラウザに合わせて制作すると、こんどは携帯電話のブラウザでは見るに見られない表示になってしまうでしょう。結局、同じ内容でレイアウトを変えたものを二つも作ることになります。これでは、とても環境に依存しない情報とは言えません。 書構造のみを記した HTML 文書であれば、各ブラウザが，それぞれの画面環境等に合わせた、適当なレイアウトをしてくれます。例えば、「見出し」と指定した要素であれば、あるブラウザでは大きな文字で、しかも太字で表示されてそれが見出しであることを示してくれるでしょうし、あるものはセンタリングすることによって、それが見出しであることを示してくれることが期待できます。 自分でレイアウトを指定したい場合は、HTML 文書に加えて、「スタイルシート」を用意して対応していくことになります。このスタイルシートは、当方で既にいくつか用意してあります。しかし、現実的には屡々レイアウトと構造を切り離しにくいものも存在します。それらについての対処法もこの文書では提示しています。 HTML の骨組み それでは、徐々に HTML 文書を構成していきます。例を見ながら、どこがどのようになってなければならないかを押さえましょう。 XML ひとめぐりでも述べたように、XHTML1.1 は、XML のアプリケーション(XML を基に作られたもの、XML の応用言語) ですから、XML の文法に従わなくてはいけません。従って、文書の先頭に XML 宣言を書くようにします。また、使えるタグの種類も、DTD によって指定されていますから、必ずドキュメントタイプ宣言をしなくてはなりません。ドキュメントタイプ宣言の無い XHTML1.1 というのはありえません。 XHTML1.1 では、ルート要素として html要素を持ち、そのなかに head要素と body要素がこの順に一つずつ現れます。head 要素には、タイトルや、文書のメタ情報、他の文書との関係などの、直接ウェブページとしては表示されないものを書くことになります。文書として題名は必須です。すなわち、head 要素の中には、文書の題名を表す title要素が一つ現れなければなりません。body 要素には、直接ウェブページとして表示される内容を書くことになります。 また、html 要素には、属性として「名前空間 (xmlns)」と「言語情報 (xml:lang)」を持たせます。名前空間は、XHTML1.1 では一意に xmlns=“http://www.w3.org/1999/xhtml"と書きます。言語情報は、日本語の場合は、xml:lang=“ja”と書いておきます。 body 要素の内容に、文書の制作者等の情報を示す、address要素を加えます。制作年月日や、制作者等の copyright 情報を書いておきます。 以上のものに加えて、meta 要素で文字コードも指定しておきます。ほとんどのブラウザでは、XML 宣言の文字コードや html 要素の xml:lang 属性は解釈されず、ここで指定した文字コードが解釈されます。所謂文字化けを防ぐ為にも必須です。また、MIME タイプの指定もここで一応行えます。XHTML1.1 では、MIME タイプとして application/xhtml+xmlが推奨されているので、そのように書いておきます。 meta 要素の記述は少々ややこしいので、とりあえず、次の様に記述することを覚えて下さい。文字コードは、各自のものを指定して下さい。 さて、以上のことを全て考慮して書いた XHTML1.1 文書の骨組みは、次の様なものになります。XML では、要素名の大文字小文字を区別します。要素名は、全て小文字で書かなければなりません。 https://mayah.jp/article/2002/xhtml11/xml/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/xhtml11/xml/ XML の簡単な例 HTML 文書の制作を始める前に、XML に就いて少し学んでおきましょう。XHTML は、XML を基礎に設計されていますので、XML の書き方がそのまま通用します。 ここでは、実際に XML の例を見てみることによって、どのようにして意味づけが行われるのかを覗いてみることにしましょう。XML は簡単な文法で成り立っていますから、実際の例を見れば感じが掴めることと思います。(ここでは、heading は見出し、p, em, はそれぞれ段落・強調、ol, li は、リスト、リストの中身というくらいの意味で考えて下さい。) いかがでしょう。これを見るだけでも、少しは XML が分かったような気にならないでしょうか。或いは、多少なりとも、規則が推測できるような気がしませんか？　殆どの人は、<document>の様に < >で囲まれた部分に、何か意味があることが推測できたはずです。 次の節から、XML の文法に就いて実際に学んでいきます。 XML の文法 上記の XML 文書は、大きく分けると次の２つから成り立っています。 XML 宣言 XML インスタンス ここでは、それぞれについて簡単な説明を加えますが、特に XML インスタンスについて説明します。 XML 宣言 先程の XML 文書の例を見てください。一番最初に次のような記述があります。 この記述は、この文書が XML によって記述されているということを示すためのもので、XML 宣言と呼ばれます。 XML 宣言は、この文書が XML によって書かれているということを宣言し、同時に、この文書の XML のバージョンや、使われている文字コードを指定するためのものです。version=“1.0”が XML のバージョンを表し、encoding=“EUC-JP”でこの文書が EUC-JP という文字コードで書かれていることを示します。ここは、自分が使っている文字コードを記述してください。自分の文字コードが Shift_JIS ならば、encoding=“Shift_JIS”と、iso-2022-jp ならば、encoding=“iso-2022-jp”と記述しなければなりません。encoding 属性は、例えば HTTP のヘッダ等に適切な文字コードが指定されている場合等、省略可能なこともあります。しかし、ローカルで閲覧する際等、そのような文字コードの情報を得られるのは、(本文から推測する場合を除いて) XML 宣言くらいしかありません。基本的には省略出来ないものと考えておけば、まず間違いありません。 この XML 宣言自体が省略可能なこともありますが、やはり基本的には省略出来ないものとして考えておけば良いでしょう。 XML 宣言の encoding 属性の内容に関わらず、ヘッダによる宣言が優先される。 text/xml で送られた場合、文字コードセット宣言がヘッダで省略された場合は、XML 宣言の内容に関わらず、常に US-ASCII と見倣さなければならない。 application/xml で文字コードセット宣言がヘッダで省略された場合は、XML 宣言の内容に従う。 ウェブ上で文書をやりとりする際にはこれらのことが問題になって来るかも知れませんが、殆どの場合は気にする必要は有りません。encoding 属性をきちんと書くことを心がけておけば、大抵大丈夫であると思われます。 https://mayah.jp/article/2002/xhtml11/reference/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/xhtml11/reference/ 参考文献 世の中には沢山の HTML 解説本が出ていますが、正しい情報発進のための HTML を解説している良い参考書は本当に少数しかありません。 HTML のリファレンスは、次にあげる本が評価が高いようです。 参考サイト 世の中にはやはり沢山の「ホームページ入門」が存在しますが、W3Cの意図に沿った解説をしているものは少ないようです。 ISO-HTML ISO が定めた HTMLというものがあり、通称 ISO-HTML と呼ばれます。ISO-HTML は、W3C が規定した HTML よりもかなり厳格なものですが、そこには、HTML 文書は、より多くのクライアントで閲覧可能な、環境に依存しない文書でなければならないという信念が全面に押し出されています。 XHTML を利用することにしても、ISO-HTML の仕様を参考に文書をマークアップすることは環境に依存しない HTML 文書の制作の方向に向かうものとなります。その結果出来上がった HTML 文書は、再利用性やアクセシビリティの観点からみても好ましいものになることでしょう。 https://mayah.jp/article/2002/xhtml11/ Tue, 01 Jan 2002 00:00:00 +0000 https://mayah.jp/article/2002/xhtml11/ この記事はすでに古くなっています。2014年現在、XHTML1.1ではなく、HTML5を使うべきです。この文書は、HTML の仕様をなるべく守りながらも、現実的にはどのようにマークアップをしていくかということに対して、一つの指針を示したものです。 前提知識として、PC 一般の使い方、ウェブの用語の知識を仮定します。技術には詳しくなくても構いませんが、用語を聞いて意味が分かるということを前提にしています。 目次