今日の風景 つくりおきはじめました。 はじめに 元々は 永和システムマネジメントの技術面接で出された問題らしい。こく難しく言えば「ある文字列」(この文字の集合をAとすると)と「ある文字列」(この文字の集合をBとする)とした場合、このAとBの文字の集合が一緒であるかどうかをどのように判定するか、という問題らしい。もうすこし簡単に言えば、Bの文字列はAの文字列かどうかをどのように判定するかということである。 この問題の解き方は簡単で、先に言ってしまえば次のようになる: def anagram(s1, s2) s1.chars.sort == s2.chars.sort end これは、順序を考慮しない集合の場合、同じ要素が一対一になっていればいいということなわけだから、とてもシンプルでわかりやすい解答である。ただ、元のエントリが「Scheme」で書かれているので、Redditの日本語Lispコ

近況 打ち捨てられた過去について 要旨 この記事を興味深く読む一方で、やはり違和感を覚える人も多くいるようで、自分もその一人だった。恐らく、この違和感は、「抽象化」が「具体性を奪取していくもの」といったような対立項として述べられているからだ、というように思われる。しかし、果たして具体性無しに「抽象化」することが有益なことなのだろうか。それが一つの違和感のように思われる。 本文 プログラミングの世界には、YAGNI原則(You ain't gonna need it)というものがある。また、YAGNIという言葉を使わなくても、「過度な汎用化が足を引っ張る失敗例」というのは、プログラマとしての心構えを書いた本の中で、ちらほらと自嘲気味に述べられることがある。 僕も、一度そのような失敗例を見たことがあるけれど、なぜこういう失敗が起こるのか。確かにデザインパターンで組み立てられたアーキテクチャは「

はじめに 自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。 たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあとい