トップ «前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|

ToDo:


2008-09-10

_ ゴルフ場カルトクイズ

ゴルフ場に投稿され、溜まっているコードの量はどのくらいでしょうか

1. 70kB 2. 700kB 3. 7MB 4. 70MB

(22:25)

_ そいや

http://blog.tarotaro.org/archives/216

発表者は寝巻きにサンダルで来ていた(ように見えたが違うらしい)。

にわらった。 確かに寝てる時も着てるので間違ってはいないし。

(22:29)


2008-09-09

_ RealLib

http://d.hatena.ne.jp/hzkr/20080909#p1

ふえー。 数式の形で覚えとくとかなのかなぁ。 ある程度の normalize みたいなのは途中でやるのかな

(09:03)


2008-09-08

_ そいや

http://idm.s9.xrea.com/ratio/2008/09/03/000797.html

での yugui さんのゴルフについての記述は良いなぁ。 探索空間がムダに広いからパズルや リファレンスをひくきっかけとしてうんぬんというような。

あとなんか最近主張してるゴルフというか キモいコード家で書く利点として、 キモいコードというか ちょっとかっこつけたような表現を ちょっと使ってみたくなるような 気持ちが発散されて、 会社では普通のコードを生産できるというような。

GoF 読んだばかりの人がやたらデザパタとか使ってみたくなるとかいうような話。

条件演算子とかも仕事では使いたくないんだよな。

int* p;
p ? *p : 0

とかならいいけど、

char* p;
p && *p ? p : ""

あたりからあやしくなってきて、 どのあたりが読み手がいらつき始める境界かよくわからんので、 最初っから全く使わんでもいいんじゃねとか思っちゃうんだよな。

そいやあとは || も微妙な時があって、

assert(!strict_check_mode || ptr != NULL);

みたいなヤツ。

if (strict_check_mode) {
  assert(ptr != NULL);
}

の方がわかりやすい、と主観的には感じる。 カバレージ測定しやすいという副次効果もあるかも。

まぁそのへんが主観でしかないってのはそうなんだけど、 ただまぁ後者を積極的に読みにくい、 って感じる人はそんなに多くないだろうなぁとか思うと、 読みにくいと感じる人がそれなりにいるであろう前者は 避けたくなるよなぁとか。

一方、家で書いてるコードは普通のコードでも

while (*rp) --**rp++;

とか平然とあって、まぁ発散できてるなー的な

(00:35)

_ BAMBOO麻雀

http://risky-safety.org/~zinnia/d/2008/09/#20080906-t0-h1-p0

を見てやってみた。 面白いなぁ。

こんなルールでも九連ってなかなか出ないんだなぁ… とだらだらやってたら出た。うれしい

(01:40)


2008-09-06

_ Perlの功績

http://www.kt.rim.or.jp/~kbk/zakkicho/08/zakkicho0809a.html#D20080903-4

正規表現まわりだと =~ とかはちゃうのかな。 自信まったくなし。

あと s///ge はゴルフ的な観点から神

あれ、あと $` $' $& $+ $1 $2 ... も Perl 出身とか? これもまったく自信なし

(05:22)

_ hello.grass 493B

http://golf.shinh.org/p.rb?hello+world#Grass

うし。 ちなみにまめさんのは見ないで頑張った

(14:39)


2008-09-03

_ そいや

mircbot っていうアカウント取ろうとしたら、 既にいて驚いたんだけど、 どんなヤツかと見てみたら 取ったのは俺で、まぁおどろいた

http://twitter.com/mircbot

(11:18)


2008-09-02

_ したら負け

http://d.hatena.ne.jp/ku-ma-me/20080901/p2

  • Perl: use strict したら負け
  • OCaml: for や while を使ったら負け
  • C++: friend は負けっぽい(使うけど)
  • XXX: 使ったら負け(お好きな言語をどうぞ)

あとは C を吐くコンパイラは負けた気分とか、 色々あるなぁ

(01:11)

_ make

http://twitter.com/emasaka/statuses/906494269

すばらしい指摘だとおもった。

ああそうそう kati はとうぜんそいう意味

http://shinh.skr.jp/koneta/#kati

(18:55)

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

_ ku-ma-me [Haskell: 無名関数書いたら負け]

_ hi_saito [awk でアクション使ったら負け。]

_ niha [goruby: brute force したら負け]


2008-08-31

_ えるえる

あつかましく Larry のサインもらた! もう俺はそれで全て良い。

何度か語ってると思うけど実はそんなに語ってないかもしれないけど、 僕はそんなに好きなプログラム書籍とかそんなに語れないんだけど、 いわゆるラクダ本は大好きな本で、 すっぽすっぽのプログラミング言語 C++ とかと 同じ程度には影響とかはある気がするんだ。 まぁ僕は本に影響されるとか今一つピンときてないのであやしいけど。

サインもらった記念に Perl をベタボメする。

Perl っていうのはこう、変態言語愛好会にとっての LISP と 考えても全く問題ないと思う。 ヤツらはこう10年先を行ってると考えてよく、 LL とか好きな子がこんなハッキーなことやったぜ!! っていうのは、 「あーそれ Perl が 3000年前に通った道」 みたいなこと言われてもおかしくない程度には すごいというのを認識してからの方が安心かもしれないのです。

例えば今日とか Perl Golf というのを Web ベースで… とかほげほげ司会のかたがおっしゃってたけど、 あれはたぶんウソで、当初は newsgroup で行なわれてたんだと思う。 newsgroup とかいう時代からゴルフやってた連中なわけですよ。 知らんけど。

まぁゴルフのこととか書くとまたそんな話か的な感があるけど、 Perl で実行できる詩を書く perl poem とか、 Acme::* とか、 JAPH とか、 ほげほげとか、ふがふがとか、

…と書きたかったんだけど、ぶっちゃけあんま Perl とか知らんな。 まぁそいう子はとにかく Perl を学ぶべきなんです。たぶん。

でまぁラクダ本も Larry がそいうの好きなんだなぁ という感じがすごくするのでこう良いのですよ。

用心しろよ、 emacs さん。言語を内蔵するのは、君だけの専売特許じゃないよ :-)

とか、まぁこうなんというかこいうのいいね。

だいぶ前に書いたこのへんの頭おかしい話とかも 別に秘奥義とかじゃなくて単にラクダ本に書いてあったわけだし

http://d.hatena.ne.jp/shinichiro_h/20071107#1194442793

(00:49)

_ title

http://d.hatena.ne.jp/takkaw/20080830/p2

ちなみに Python にも capitalize もあります。 (is)?(upper|lower|title) とさらに capitalize がある、というのが現状らしく、 Python は大文字小文字変換界の雄と言っても良いのではないかと思います。 iscapitalize が何故ないのか、それを考えて余生を過ごそうかと思います。

(00:55)

_ isakr

で、今日の呑み会で、 isakr みたいなのがあるといいんじゃないかということなので さっそく作ってみました!

class String
  def akr?
    # must not be capitalized
    return false unless self[/^[a-z]/]
    # there should be continuous upcases
    return false unless self[/[A-Z][A-Z]/]
    return true
  end
end

puts "defLATE: #{'defLATE'.akr?}"
puts "deflate: #{'deflate'.akr?}"
puts "Deflate: #{'Deflate'.akr?}"
puts "dEflate: #{'dEflate'.akr?}"
puts "DEFLATE: #{'DEFLATE'.akr?}"
puts "deFLate: #{'deFLate'.akr?}"

実行結果:

defLATE: true
deflate: false
Deflate: false
dEflate: false
DEFLATE: false
deFLate: true

とりあえず現実の例が一つしか無いので、 仕様策定が難しそうですね…!

(01:04)

_ String#akr

akr? があるなら実装はかんたん

class String
  def akr
    akrize = proc{|s|s.split('').map{|_|rand<0.5 ? _.upcase : _.downcase} * ''}
    until (s = akrize[self]).akr?
    end
    s
  end
end

10.times{puts 'deflate'.akr}

実行例

dEFlate
deFLaTe
dEFlaTE
dEFlAte
dEFLATE
dEFLatE
deflATE
dEFLATe
dEFlAtE
dEflATe

いかにもいやなかんじのものが

(01:09)

_

昔見た時は deflate 違ったような気がするなぁ… とか思ってぐぐったらやはり別の事例を発見した。 うん僕が見た時は DeFLaTe だったような気がする。

というわけで先程のコードには重大なバグがあるので プロダクションでは使わないようにおねがいします

(02:01)

_ そういえば

ほげほげより C++ の方が中二病としてはほげほげな気が するというような気がする的指摘。

たしかにほげほげは中二病そのものだと思うけど、 C++ はこうやりたくなることはわかるなぁ うん実際にはそんなに書かないんだけどね、

というあなた

は中二病なので問題ないというような。 いやそういう話だったか

(23:44)


2008-08-30

_

基調講演 Larry Wall か!

それはいかんといかん

(02:54)


2008-08-27

_ LL Golf Hole #5

sed だと普通のカウントの方が大変というのが面白かった。

http://ja.doukaku.org/comment/7374/

(01:10)

_ continuous build

http://ruby.shinh.org/

なんとなくこんなの作った。

(23:08)


2008-08-26

_ LL Golf #3

書いてみた。 cal + awk がいいんじゃないかなぁ。

http://ja.doukaku.org/comment/7367/

eval `date '+y=%Y;m=$((%-m+(%e>13)))'`

とかトリッキーな感じでいいなぁとか思いました。

(23:13)

_ LL Golf #4

Perl の得意分野だよなぁ。

http://ja.doukaku.org/comment/7370/

(23:35)

_ LL Golf #5

Perl でさっくりと。

http://ja.doukaku.org/comment/7372/

(23:56)


2025年
1月
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.niha(2014-05-24 05:24) 2.hi_saito(2014-05-24 05:24) 3.ku-ma-me(2014-05-24 05:24)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h