トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|
2025|01|02|03|04|05|06|07|

ToDo:


2010-03-25

_ 直訳危険

http://shinh.skr.jp/h/?TyokuyakuKiken

なんか他にも色々あった気がするんだよなー

(01:37)

本日のツッコミ(全4件) [ツッコミを入れる]

_ naruse [とりあえずぱっと思い浮かんだのはhad better to doとか]

_ aki [坊主頭の人を指して skin head って言うと、 人種差別主義者呼ばわりした事になりかねなかったり。]

_ shinh [had better は had better do で to はいらんとかでしたっけ。あんま見ないのでごくごく最近..]

_ naruse [おお、たしかに、訂正どうもです]


2010-03-24

_ Wikiスパム

はじめてのひきのなぞなぞ認証が突破された上に Hiki 記法でちゃんとリンクをはってあった。 ええとどうやったんだろう…

(19:36)


2010-03-21

_ 時間の無駄

(05:05)


2010-03-20

_ 時間の無駄2

なにかどうでもいい数列の規則性を当てるとか

  1. 1, 2, 4, 6, 10, 12, 16, 18, ?, ...
  2. 1, 2, 4, 8, 16, 23, 28, 38, ?, ...
  3. 1, 2, 3, 5, 7, 10, 12, 14, 17, 19, 22, 25, ?, ...
  4. 1, 2, 2, 4, 2, 4, 2, 4, ?, ...
  5. 0, 1, 1, 2, 1, 2, 1, 3, 2, ?, ...
  6. S, O, G, M, E, ?, H, Y, S, S, T, M, ...
  7. 1, 2, 3, ?, 4, 4, 2, 2, 2, 2, 3, ...
  8. http://www.contestcen.com/series.htm

(15:18)

_ Clojure

なんか let の括弧が一つ少ないと教えてもらった。

hmhm

http://d.hatena.ne.jp/leque/20091121/p1

(23:32)


2010-03-19

_ C++ にひさびさに噛まれた

#include <stdio.h>
#include <string>

using namespace std;

class Text {
public:
    Text(string s) : s_(s) {}

    virtual char firstCharacter() /* const */ {
        return s_[0];
    }
protected:
    string s_;
};

class AnotherText : public Text {
public:
    AnotherText(string s) : Text(s) {}

    virtual char firstCharacter() {
        return s_[1];
    }
};

int main() {
    Text* text = new AnotherText("foo");
    // o
    printf("%c\n", text->firstCharacter());
}

とかあって、 firstCharacter って const だろと思って Text の方だけにつけたら挙動が変わった。

30分ほど気付かなかった

(01:16)


2010-03-18

_ 円まーく

https://bugs.webkit.org/show_bug.cgi?id=24906

これが一見ややこしそうだけど一見以上にややこしくて困る。

たまに頭がおかしくなるのでまとめておこうと思う。

  • 表示
    • バックスラッシュは Windows でかつ EUC-JP や Shift_JIS など、要は日本語エンコーディングのサイトだと、日本語フォントが使われるため、バックスラッシュが円マークに見えている。あと、日本語フォントが明示的に指定されていればやはり当然円マークに見える。
    • Apple の人はそれらは円マークとして表示したいと主張している。
    • 僕の個人的な感覚ではこんなことはやらんでいいと思う。がまぁ理解はできる。
    • ここを認めるせいでややこしくなるわけだけど。
    • 表示する文字列は RenderText とかいうクラスの中に変換された状態で保存されてて、まぁオリジナルの文字列は DOM node の方に入っている。変換した状態で保存しておかないと毎度変換すると遅いし。
  • コピー
    • バックスラッシュ書いてあるところからコピーしたらバックスラッシュのまんまがいいと思うどう考えても
  • ページ内検索
    • バックスラッシュが円マークで表示されてる物体は、円マークで検索した時に検索されるべき
    • 何故なら Mac の日本語キーボードは円マークの文字コードが直接出るから
    • 僕としてはバックスラッシュだろうが円マークだろうがどっちで検索してもどっちも出るといいと思う

で、やるべきこととしては

  • 表示の方は求められてる通りにやるとする
  • コピーする時は DOM node の方に入ってるテキストを使う…のはダメ
  • 何故なら text-transform:capitalize とかしてる時は変換後のを使わないといけないから
  • text-transform があってかつバックスラッシュ→円とかしてる場合はコピー時にその場で変換
  • ところでコピーは適当にいじるとページ内検索が壊れる
  • コピーに使われてるコードはそこらじゅうでバックスラッシュ→円の変換をやってるので全部いじらないといけない
  • 例えば普通の文章と text control の中とかで違う
  • あとペースト先によっても変わる。 contentEditable だとなんか違う
  • ページ内検索の方は、検索するキーも検索対象の文章も両方とも円マークをバックスラッシュに変換してしまえばいいんだと思う。たぶん。これもなんか大変そう。後回し。

(02:59)

本日のツッコミ(全5件) [ツッコミを入れる]

_ 成瀬 [お疲れ様です。。。 &lt;p style="text-transform:capitalize"&gt;a\&a..]

_ 成瀬 [おっと無効か、まぁそうだよな <p style="text-transform:capitalize">a\&#x5..]

_ shinh [capitalize は次のパッチはたぶん適当に対処します。 A円円円 ただしコピー時は A\\円 とかになればいい..]

_ 成瀬 [それでよいと思います。パッチ見て驚きましたが、表示直前でだけ変換すればいいような話でもないんですね。 しかし。これ..]

_ shinh [フォント変えろは同意なのですがまぁそういうわけにもいかなさそうですね。円がバックスラッシュに…はまぁ現実的には誰も文..]


2010-03-17

_ zsh 4.3.2-dev-1

i@u ~> grep function() /tmp/*
i@u ~> grep
grep:4: permission denied: /tmp/fcgiruby.kwskk.socket-0

ちょい前に古い zsh だとこんなことになると教えてもらった。

最近のやつだとこんなことにならないので、バグだったってことだろうなー

(02:13)


2010-03-16


2010-03-15

_ -san suffix

なんだろう。 -san suffix とかそのへんについて聞かれたのが既に4度目な気がする。 なんかどっかに簡潔にまとまってないものか。

これはまぁ基本路線としてはいいと思う。

http://en.wikipedia.org/wiki/Japanese_name#Speaking_to_and_of_others

ただ死ぬほどたくさんの例外があることと、あと

This faux pas, however, is readily excused for foreigners.

はちょっときつい感じがあるかなぁ。 たぶん許すとかそういう次元じゃなくて、 ほとんどの人は外人にどう呼ばれても気にもしない気がする。

このへんはまぁ普通に考えて読む気が起きないけど、 いい感じに複雑だということは伝わる気がする。

http://en.wikipedia.org/wiki/Japanese_titles

http://en.wikipedia.org/wiki/Japanese_pronouns

(04:05)


2010-03-12

_ 風邪

風邪ばかりひいてる。 月3日ペースなのでそろそろ週休3日に近い気がする。

僕の中でバファリンは至高の薬であり 一方パブロンは全くきかないのだけど、 早めのパブロンとか言う宣伝は、 効かなかった場合は早く飲まなかったからだよプギャーと言い訳でき、 たいした風邪じゃなくてさっさと治った場合は さすが早めパブロンというような感じで 良い宣伝なのじゃないのだろうかと

そういうどうでもいいことばかりを考える

(19:06)

_ 引数

なんか昔はよかったんだろうけど、 最近では

grep fuga **/*

とかするとすぐに argument list too long とか言われてしまう。

find . -exec grep fuga {} \;

はあまり好きでなくて、 何故なら grep が何度も起動するんだろうなーとか思うから。

思うに標準入力からファイル名の一覧を得て それぞれに対してコマンドを実行していくような機能を 全ての unix コマンドがそなえるべきなんじゃないだろうか。

例えば適当に -= とかを使うとして、

find . | grep fuga -=

とかそういう。

スクリプト言語におかれましては 適当に -P とか -N でそういう処理をして欲しい。

ちょうど Ruby では $= は obsolete だし Perl の $= もいらんだろーということで $= に今読んでるファイル名とかが勝手に入ってくれると良い。 あ、いや、 $<.filename と $ARGV でいいのか。

特に Windows の文化圏とかで

command @filename

とかしたら filename の中身から1行ずつ読み込んで それを引数とするみたいなのがあるけど、 そっちの方がいい気がした。

find . | grep fuga @-

で標準入力からファイル名を読む感じで

(19:19)

本日のツッコミ(全7件) [ツッコミを入れる]

Before...

_ kosaki [xargs知らなかったとか絶対予想できない。ひっかけ問題ヒドイ]

_ shinh [xargs 自体は知ってたんですが find . -exec command {} \; みたいに何度も comma..]

_ nya [最近の GNU の find では -exec hoge {} + で xargs 同様の分割をしてくれるみたいです..]

_ IKeJI [どうでもいいですが、Rubyだとファイル名の取得はARGF.filenameとかかと。]

_ shinh [> 最近の GNU find そんなものがあるんですね… \; より短いし普段はそっち使ってれば良さげですね。 ..]


2025年
7月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
1.naruse(2014-05-24 03:05) 2.shinh(2014-05-24 03:05) 3.aki(2014-05-24 03:05)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h