『マンガでわかる！関数型プログラミング』という漫画を連載することになるようです - Line 1: Error: Invalid Blog('by Esehara' )
近況 ふとした瞬間に虚しくなることがある いきさつ 今年、秀和システムから関数型プログラミングに関する本が出て、良くも悪くも、その本が注目を集めることになってしまいました。そんな中で色々な人が反応していましたし、自分もこのようなかたちで感想を書きました。 一方で、このような本を書かれるくらいであるならば、自分で真っ当な本を書けばいいわけだし、技術書を書くことなんて、そんな敷居の高いことではないというカウンターもあり、個人的にはそれも最もだなあ、という印象がありました。その中で自分なりに関数型プログラミングについて理解したことを元にQiitaに駄文をアップしたりしていました。間違ってたら、誰かが訂正してくれるだろうし、そのほうが自分にとって勉強になるだろう、と思うので。 ですが、「関数型プログラミング」というのは「なんだか難しい」という印象を覚えるのも事実のようです。実際に、最新の『Soft
アナグラムを素数の積で求めると簡単(ではないけど)判定できるよって話 - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 つくりおきはじめました。 はじめに 元々は 永和システムマネジメントの技術面接で出された問題らしい。こく難しく言えば「ある文字列」(この文字の集合をAとすると)と「ある文字列」(この文字の集合をBとする)とした場合、このAとBの文字の集合が一緒であるかどうかをどのように判定するか、という問題らしい。もうすこし簡単に言えば、Bの文字列はAの文字列かどうかをどのように判定するかということである。 この問題の解き方は簡単で、先に言ってしまえば次のようになる: def anagram(s1, s2) s1.chars.sort == s2.chars.sort end これは、順序を考慮しない集合の場合、同じ要素が一対一になっていればいいということなわけだから、とてもシンプルでわかりやすい解答である。ただ、元のエントリが「Scheme」で書かれているので、Redditの日本語Lispコ
日報: Vue.jsを三日間ほど触ってみての感想 - Line 1: Error: Invalid Blog('by Esehara' )
今日の寿司 寿司をViewと考えた場合に、寿司を食べたときに、寿司が減ったことを皿に反映させたいという話です。 はじめに ある事情によって、知人のお手伝いをすることになった。で、そのお手伝いで、できそうなのがフロントエンドだったので、これを機会にフロントエントの知識をアップデートするのも悪くないよなーと思って、Vue.jsを触りはじめている。 当然ながら、自分の趣味プロダクトだったら、いきなり入れて「なるほどね」と納得して終了でいいんだけれども、今回はお手伝いということもあったので、それなりに導入するメリットみたいなものが必要になるだろうし、実際に触ってみてどうなのよ、というフィードバック必要だよね、みたいな気持ちになったので、そのあたりを書いておく。 リアクティヴ・コンポーネントについて 今回のお手伝いが、漠然とした概念で伸べるならば「管理画面のフロントエンド実装」ということになる。管理
Word2Vec + MeCabで「ボケる」ための単語候補をピックアップするやつをやってみる - Line 1: Error: Invalid Blog('by Esehara' )
近況 はじめに 最近、ちょっと大喜利を始めていて、如何に面白いことを言えるのか、ということを考えたりしているんだけど、考えてみれば、自分は少しプログラミングができるし、むしろ形態素解析や自然言語処理という観点から「質問」と「ボケ」を考えてみると面白いかもしれない、と思って、力技でそういうことをやってみた次第。 今回の方針 とはいえ、何となく「質問に対して上手いボケを返してほしいな」ということであるならば、それこそ単語のランダム検出でもいいという話になってしまうので、ある程度仮説を立てて実装する。今回の仮説としては、「ある文が連想する知識の、派生する知識がその文と結びつけられた場合、人は上手いと思うのではないか」ということだ。 どういうことか。 例えば、謎かけの場合、「Aとときまして、Bととく。その心はCです」と言った際に、一見無関係の文(あるいは単語)が、Cという意味づけによって接続するこ
何故、「そのプログラミング言語」で関数型プログラミングをするのが難しいのか - Line 1: Error: Invalid Blog('by Esehara' )
近況 未来が脅す右手の指 ナイフが滑る左手首 朦朧と過ぎる日曜日 消えた秒針 数えた生久伸 このままでいいのか 俺はお前は 迷路の中 IT'S MY WORLD ――『KOKORO WARP』SHAKKAZOMBIE 問題 多くの人々にとって、既存の慣れ親しんだプログラミング言語で、最新のスタイルを身に着けたいと思うのが人の常だと思う。今宵、流行りのスタイルと言えば、恐らく「関数型プログラミング」になると思う。 混乱を避けるために、ここで一つ定義をする。ここで言う「関数型プログラミング」の定義とは、「副作用を出来るだけ避け、関数の連続によって書くプログラミング手法」という風にする。そして、このときの「関数」とは、「ある入力に対して、一定の出力を返すもの」という風に定義することが出来る。 さて、ここで二つの主題がある。まずひとつに、「副作用を出来るだけ避ける」という点と、「関数の連続によって
在宅勤務始めました - Line 1: Error: Invalid Blog('by Esehara' )
この記事について この記事はHeartRails Advent Calendar3日目の筈でした。 趣旨 HeartRailsに入社した。そこで、リモートを通じて受託開発などを行っている。ちょうど1ヶ月ほど経ったので、リモートワークに関しての所感をメモしておこうというのが今回の記事の趣旨。 なぜリモートワークをやろうと考えたの? 割と働き方で体調を崩すことが多くあったので、「これは自分の働き方を見直さないとマズイな」と思い、あまり一般的な働き方に囚われず、自分にあった働き方を見つけようと思ったのがきっかけ。そうなると、現状として二つの働き方があって、「リモートワーク」か、あるいは「短時間勤務」になるかなと考えたので、そのあたりを中心に見直した結果、HeartRailsの働き方がマッチしているかなと思ったので、そういう経路で働き始めたという経路。 リモートワークを中心にすることに関して不安は
バブルソートよりも非効率なソートアルゴリズムを探して ―― ストゥージソートとスローソート - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 恐らく、プログラマの中で配列内の要素を整列させたりするソートにお世話にならなかった人、というのは余り考えられないのではないでしょうか。しかし、とはいえ、大抵はソートを自前で実装せず、組み込み関数であったり、あるいは何らかのライブラリで済ませることが殆どだと思う。 車輪の再発明というよりも、バグとか、自分が考慮していなかった挙動などを避けるために、自前でソートを組むことは余りないのですが、とはいえ、自分なりにソートを実装して見ると、それがどういう特徴を持ったソートであるか、というのがわかりますし、また、ソートというのはいったいどういう操作で実現されるのかという洞察が深まってくるなあ、という実感があったりする。 なので、今回はあるソート二つについての話を書くのが趣旨です。 最高のアルゴリズムはある、だが最悪のアルゴリズムは何か 一口にソートといったところで、ソート自体にも銀の弾丸があ
迫り来る「forおじさん」と呼ばれる時代 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今となっては、プログラマにとってなんとなく理解して利用できることが当たり前になりつつあるオブジェクト指向ですが、しかし、それこそ今から数年前には、この「オブジェクト指向」というのは、いわばおじさん達が変な方針を打ち出したりして「え、それ変な実装方針じゃねえの」というツッコミが入ったりしていました(ちなみにそのあたりの雰囲気については、この記事を読むと分かりやすいでしょう)。 もちろん、これはこれなりにメリットがあるのかもしれませんが、しかしそれはまた別のオブジェクト指向を利用したモデリングと比較してのことであって、「これだけでいい」と考える人はいないでしょう。 原則: だってそのほうが開発しやすいから まず最初に原則を考える必要があります。まずひとつに、必ずしもオブジェクト指向が正しいモデリングの方法ではないこと。少なくとも自分が思うに、オブジェクト指向を使うべき理由というのは、
一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )
とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基本的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシを食う数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ
git logで生産性は可視化できるのか、Rでグラフを作って調べてみる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに──行数管理とgit commit ここ最近に、「プログラマー」の生産性を何かしら指標化する必要があるのではないか、という指摘がありましたが、確かにそういう側面もある一方で、「プログラム」という行為が、実は言われるほど簡単ではなく、何らかの形で指標にしようとすると難しくなるという問題があるかと思われます。 自分は直接ぶちあたったことはないのですが、たまに悪習として語られる指標の一つとして、「ステップ数」が上げられるでしょう。確かに、多くの人々が指摘しているように、ステップ数の問題は、下のような意味で問題があると言えるでしょう。 「機能」は、コードに直された場合、一行にも百行にもなるが、単純ステップ計算数で数えた場合、後者のほうが生産的と捉えられてしまう コードを手直ししていく作業として、リファクタリングする側面は、ステップの総体を変えないが、コードの綺麗さは、その後の生産性を変えて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
