サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
mdgw.hateblo.jp
MathMLに非対応のブラウザでも、MathMLを含むページを表示可能にする軽量のJavaScriptプログラムを作成してみました。 MathMLは数式をXML形式で表現するため、数式を画像として用意する場合とは異なり、細かな修正やプログラムからの操作に便利です。数式を含んだページを作成する際にはぜひとも利用したいところなのですが、対応しているブラウザを利用する、もしくはプラグインを組み込まないと表示されないのがネックになります。ただ10年くらい前はMozillaくらいしか対応ブラウザがなかったのですが、最近はHTML5の一部に含まれることもあって、ネイティブに対応しているブラウザが増えてきています。 また最近はMathJaxというライブラリがあり、これを利用するとMathMLに非対応のブラウザでも数式を表示することができます。実行結果も非常に美しい表示になり、MathML対応ライブラリの
最近になってjQueryの使い方を覚えたので、忘れないうちに何かを作りたいなぁと思っていたところ、ちょうどGoogle CGI API for Japanese Inputというのが公開されたので、これを使ったソフトウェアキーボードを作ってみました。 実用性は低いですが、所要時間1〜1.5日くらいでとりあえず動くようになりました。実物はこちら。 最初はiPadでフリック入力ができると面白いんじゃないかと思って作り始めたのですが、フリック入力だとUIを作るのが面倒技術的に悩ましい点があったので、単純な五十音キーから入力になっています。*1これはこれで、少しだけ新鮮な感覚が味わえるのではないかなと思っています。(追記:結局フリック入力を実現しました。) 技術的に特別なことは何もないのですが、1点だけ、iPadに対応させるための工夫として、テキストフィールドにフォーカスされた際にblurを呼び出
Scala exercise 6: Tackling the Wicket hierarchy mismatch problemという記事に触発されて、同様の手法をJavaで再現してみました。 Wicketでネストされたコンポーネントを扱う場合、HTMLテンプレートに比べてJava側は見通しが悪くなりがちだと思います。元記事ではScalaを利用した解決方法が示されているわけですが、私が理解した範囲ではポイントは下記の2点のようです。 コンポーネントの階層構造と同じになるようにソースコードをインデント(構造化)する。 追加対象を常にctxという同じ変数名にすることでHTMLの構造変化があってもどこにでもコピペ移動ができる。 実際にこの手法で書かれたソースコードを見るとなかなか悪くなさそうです。ただ残念ながらScalaは今ひとつ使い方が分からないので、元記事のScala exerciseという
Wicketでコンポーネントを追加する場所を指定する場合、通常は該当するタグにwicket:idという属性を付与する必要があるのですが、代わりにHTMLのID(class)属性を利用可能とするライブラリを作成してみました。 Wicketでコンポーネントを追加する場所を指定する場合、該当するタグにwicket:idという属性を付けます。XHTMLを利用している場合はこの方式でも良いのですが、XHTML亡き今HTML5が主流になってくると、wicket:という独自namespaceの属性は浮いた感じになってしまいます。またCSSやjQueryを頻繁に使い出すと、idやclass属性を付与することが多くなるため、wicket:idを改めて付けるのも面倒になります。 このライブラリを利用すると、wicket:idを付与することなくWicketを利用することが可能となります。等の専用タグを利用しない
以前Wicketを使っていた際は、データベースの操作にHibernate(JPA)を利用していたのですが、今一つ気に入らない部分がありました。下記のような部分です。 設定をXMLファイルで書かないといけない。 テーブル定義とマッピング定義を分離できない。 カラム名等をテキストリテラルで指定する必要がある。 別のO/R Mappingライブラリも探してみたのですが、プリプロセッサでの処理が必要となったり、機能的にいろいろと制限があったり、今一つしっくりとくるものがありませんでした。 JDBCを直接使ったりDbUtils等を利用する方法も考えられるのですが、SQLを書かなければいけない、DBごとの差違の吸収が大変になる等の別の問題が出てきてしまいます。 そこで、これらの不満点を解消するために、データベース操作用のライブラリを自作してみました。ライブラリ開発の方針は下記のようなものです。 Jav
JCEでDiffie-Hellman鍵交換を行う方法を調べた時のメモ*1。内容はAとBが秘密鍵を交換するシンプルなものです。 最初にAがベースとなる素数等のパラメータを生成します。AlgorithmParameterGeneratorを使わずに、AlgorithmParametersのinit()にDHAlgorithmParameterSpecを直接生成して渡しても良いような気もしますが試していません。それとビットサイズの1024はJCEのデフォルトサイズに書いてあった数字をそのまま使っています。 AlgorithmParameterGenerator algoParamGenerator = AlgorithmParameterGenerator.getInstance("DH"); algoParamGenerator.init(1024); AlgorithmParameters
前回に引き続きCentOS 5でのXenに関するネタです。今回実現したいのは、例えばdomUのIPアドレスが192.168.1.2だった場合、それ以外のIPを利用して送受信するのを防ぐことです。これはdomUのroot権限を持ったユーザが、IPアドレスを詐称して通信する場合などを想定しています。そのためdom0側で通信を制限する方法を考えます。 以下の例では、domU側のeth0をvif1.0としてブリッジに接続している場合を想定しています。またdomUのIPアドレスは192.168.1.2とします。 この設定を実現する方法として、ここではブリッジの入出力部分であるvif1.0を出入りするパケットについて、IPアドレスが許可されたものかどうかを確認するようにします。 iptablesでブリッジのフィルタリングをする場合、physdevモジュールを利用することができます。そこでphysdev
virt-install でCentOS 5をテキストモードでインストールすると、LVMのVG名がVolGroup00に固定されてしまいます。VGが同じだと後で悲しい状況になることが多いので、インストール後に変更しておいた方が無難です。変更する方法はいくつかあると思うのですが、今回は全てをdom0側から実施する方法を調べてみました。 最初にdomUがインストールされているパーティションを kpartx で認識させ、vgrenameでVG名を変更します。 # kpartx -a /dev/VG_xen00_00/vm00 # vgrename VolGroup00 new_VG_name VG名の変更自体はこれで完了です。ただこのままでは、VolGroup00を参照している部分があるためdomUを起動することができません。そこでdomUの領域をdom0側でマウントしてVolGroup00を参
お知り合いのページを見て初めて知ったのですが、Apacheは標準ではパス部分に %2F(/をエスケープしたもの) を含むURLに対して404を返すそうです。 このままだと、最近流行り(?)の "/" でパラメータを区切る場合に、"/" 自体を値に含めることができません。そこでApacheの設定で、AllowEncodedSlashes を On にすると、URL中に %2F も使用できるようになります。 というのがメインな部分なのですが、その中で、 ところで、RFCとか規則上って、「/」をURL encodeして「%2F」にしても良いのか? それともしてはいけないのか。これがよく分からん。 AllowEncodedSlashes ディレクティブにはまる。 という疑問が書かれていたので、RFCでどうなっているのかちょっとだけ調べてみました。 3.2.3 URI Comparison Char
JavaRebel 1.1M2 の変更点に Springでも動くようになったという記述を発見して、ちょうど良い機会だったので、前から気になっていた Wicket + Spring (wicket-spring-annot) な環境での問題に対処してみました。 Now you can develop Spring with JavaRebel (tested!) JavaRebel Devel Changelog この記述だけでは何をすれば良いのかさっぱりですが、BLOGの方にIntegrating JavaRebel with Springというタイムリーな記事が追加されてました。Spring自体にApplicationContextを更新する機能が用意されているので、Beanが見つからない場合に実行すれば良いみたいです。こんな機能があるとは知りませんでした。 ((AbstractRefr
AESのCTRモードはストリーム暗号が実現できたり、推奨されるモードに入っていたりする割にはCBCモードと違って情報が少ないのですが、IETFのドラフトにTLSの場合の話があったので、それを調べてみた時の各章ごとのメモです。 AES Counter Mode Cipher Suites for TLS and DTLS [draft-ietf-tls-ctr-01] 1. Introduction AES-CTRモードの利点がいろいろ書かれている。 AES-CBCと比べて17〜32バイトお得になる。16バイト分はIVを明示的に送信する必要がなく*1、残りの1〜16バイト分はパディングが必要ないため。 暗号データにランダムアクセスが可能となる。UDPを使ったDTLS*2の時に到着順を気にしなくてよくなる。 ランダムアクセス可能という性質を利用して処理の並列化が可能となる。 一つの暗号アルゴリ
AES-CTRの時に出てきたDTLSについて調べてみた。DTLSはRFC4347になっているようなので、それを読んでみた時の各章ごとのメモ(意訳?)です。 RFC 4347 Datagram Transport Layer Security 1. Introduction TLSは広く普及しているけどTCPのような信頼性があるチャンネル上でしか使えない。しかし最近ではSIPやゲームのようにUDPを使うことも多くなってきた。このようなケースでは今一つな選択肢しかない。一つ目はIPsecだが、これは使える用途が限られている。二つ目は自分で作ることだが、セキュリティのことを考えると大変でありTLSのように楽ではない。 そのためdatagramでもTLSのようなものがあるのが望ましい。ここではDTLSというTLSに似せて作ったプロトコルについて記載する。 2. Usage Model カーネルの変
はてなブックマークとかで話題になっていたこのコード int main( void ) { int *n; *n = 5; printf( "%d\n", *n ); ... C/C++のポインタの機能--参照渡しのような処理 一見すると普通(?)のコードですが、初期化されていないnを使っているので危険ってやつですね。これだけだと単なる間違いなのですが、説明文も含めてポインタを理解していないのがバレて話題になったということのようです。 何でこういう間違いになってしまったのか、理由と思わしきものがちゃんと書いてあって、 このときnには代入された値を記憶した場所(アドレス)が自動的に代入される C/C++のポインタの機能--参照渡しのような処理 という勘違いが原因のようです。偶然動いた場合は確かにそのように見えるので、原理を無視すればその通り(?)な気がしますが、残念ながら値を代入する前と後でn
Bouncy CastleのOpenPGP用ライブラリ(bcpg)を使ってOpenPGP鍵を操作する方法のメモです。以前の日記にsecring.gpgを読み込んで利用する方法がありますので、今回はそれ以外の操作が対象です。 PGPSecretKeyを生成する public PGPSecretKey generateSecretKey() { // JCEでの一般的な鍵生成 KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA", "BC"); keyPairGenerator.initialize(2048); KeyPair keyPair = keyPairGenerator.generateKeyPair(); // PGPSecretKeyの生成 return new PGPSecretKey(
鍵生成のついでにJavaから利用する方法のメモ 自力で読み込みプログラムを作成すると大変なので、Bouncy Castleのライブラリを利用します。必要なjarファイルはbcprovとbcpgの二つになります。 最初にGnuPGの鍵が保存されているsecring.gpgを読み込みます。読み込まれた結果はPGPSecretKeyRingに格納されます。 FileInputStream is = new FileInputStream("secring.gpg"); PGPSecretKeyRing keyRing = new PGPSecretKeyRing(is); is.close(); PGPSecretKeyRingは主鍵と副鍵からなる複数のPGPSecretKeyの集合になっています。getSecretKeys()で全ての鍵を取り出すことができます。またgetSecretKey()
UPnPを使ってルータの外向けIPアドレスを取得する方法のメモ ルータのIPアドレスを取得するには、最初にネットワーク内のルータを見つけ出す必要があります。UPnPではSSDP(Simple Service Discovery Protocol)というプロトコルを利用してネットワーク内のデバイスの探索を行います。 SSDPで探索を行うには、マルチキャストを使ってこのような感じのHTTPリクエストを投げてやります。 M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 3 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 送信先は239.255.255.250のポート1900と決まっているようです。またST:には探索する情報の種類を指定します
Wicketが生成するアドレスは標準だとこんな感じで非常に見た目がよろしくないです。 http://localhost:8080/app/?wicket:bookmarkablePage=page.HomePageこんな時はmountBookmarkablePage()を使って特定のパスにページをマッピングすることですっきりします。 mountBookmarkablePage("/home", HomePage.class); 生成されるアドレスはこんな感じです。 http://localhost:8080/app/home一見するとこれで解決なのですが、mountBookmarkablePage()では、パラメータが必要な場合に微妙な問題が残ります。パラメータを指定した場合のアドレスはこんな感じです。 http://localhost:8080/app/home/id/user01/me
このページを最初にブックマークしてみませんか?
『mdgw.hateblo.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く