タグ

2014年2月21日のブックマーク (6件)

  • 憤怒と侮蔑の話 - 神社

    技術的負債云々の話から、自分の失敗を思い出したので。 ある行動から人に悪意をぶつけるとき、もしくは吐き出してしまった後、ちょっと冷静になると、いつも憤怒と侮蔑を思い出すように心がけている。 つまるところ僕はその人に憤怒しているのか、それともその人を侮蔑しているのか、ということ。とにかく憤怒と侮蔑は明確に分けておかないといけない。大げさな言葉にしているのは、極端にしないと『どっちもかもしれない』なんていう曖昧な考えになるからで、ちゃんと分別するために大げさな言葉を使わないといけない。 憤怒しているというのはつまり怒っているので、それはもう腹を立てている。『こんなクソコード書きやがってちくしょう!あの野郎!』みたいな感じ。僕はよくこういう状態になる。自分にもなる。それはもうよく怒る。大体僕は短気なので、すぐに怒ってしまう。でも、元のコードを書いた人を侮蔑してはいけないので、怒っても怒っても、出

    憤怒と侮蔑の話 - 神社
  • UILabelに画像を表示する - Qiita

    UILabelにはNSAttributedStringが指定できるので画像も表示してみる。 NSAttributedStringで画像というとCoreTextあたりで場所を確保して自分で描画とか結構ややこしいんだけど、UILabelなどには結局使えない。その代わりNSTextAttachmentが付いたのでこれをつかって画像を表示してしまおうってお話。 こんな感じ 要はNSTextAttachmentを使ってNSAttributedStringに入れればよいというだけ。 かいつまんで書くと以下な感じ。 nsas+image.h @interface NSMutableAttributedString (atimg) -(void)insertImage:(UIImage*)image bounds:(CGRect)bounds atIndex:(NSUInteger)index; @end

    UILabelに画像を表示する - Qiita
  • Pow + nginx configuration aka give me back my 80 port!

  • How to use xmlns declarations with XPath in Nokogiri

    I'm using Nokogiri::XML to parse responses from Amazon SimpleDB. The response is something like: <SelectResponse xmlns="http://sdb.amazonaws.com/doc/2007-11-07/"> <SelectResult> <Item> <Attribute><Name>Foo</Name><Value>42</Value></Attribute> <Attribute><Name>Bar</Name><Value>XYZ</Value></Attribute> </Item> </SelectResult> </SelectResponse> If I just hand the response straight over to Nokogiri, all

    How to use xmlns declarations with XPath in Nokogiri
    a2ikm
    a2ikm 2014/02/21
    nokogiriでデフォルトのネームスペースのついたタグで検索する場合は“//xmlns:someTag”みたいに"xmlns:"を付ける(xmlnsがネームスペース名として扱われる)
  • rakeの作者 Jim Weirich氏、死去

    DHH氏のツイートにてrakeの作者、Jim Weirich氏が亡くなったというニュースを知りました。 So very sad to hear about the passing of Ruby legend Jim Weirich. He taught me and many others so much. He will be dearly missed. — DHH (@dhh) February 20, 2014 毎日のように使うオープンソースツールの作者が亡くなったというのを聞くのは非常に残念で、今後コンソールを叩く時にこの事が頭をよぎるような気がします。 昨年の夏のカンファレンスにてウクレレを披露した姿はとても楽しげで強く記憶に残っています。 R.I.P. 追記 一昨日まではGitHubにコミットをしておりログにコメントがあつまっているとのこと。 Jim Weirichが最期に

    rakeの作者 Jim Weirich氏、死去
  • DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場

    「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート(1, 2)を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か? 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複

    DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場