プログラミングがわからない彼に、すこしだけプログラミングがわかっている自分が言えること - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 こういう記事を書いてドヤ顔をするような人間は、大抵本人が思っているより能力にたけているわけでは無いという法則が、どこかの民族の諺としてあるとかないとか。 はじめに 石田祐希というブロガーの方が、起業をしたのはいいけれども、プログラミングがわからなくて、書籍が欲しいというエントリを書いている。 この一件に関しては、自分は特に言うこともなく(自分もレールから外れたが、文才の無い自分がその経路を書いても凡庸になるだけだと思って書いていない)、ただ傍観していただけだが、プログラミングのことだったら、自分の知識が無くても教えられることがあるだろう、とは思ったので、彼自身がこれを参考にするかどうかは兎も角として、せっかくなので書いてみようと思う。 ちなみに、記事の性質上、Web系に偏っていることをお断りしておく。 読みたい記事 まず最初に、プログラミングとは何だろうということを考えたときに
シャッフルしたカードを順番にならべていったら、その並び順と同じ数が出てこない確率はどれくらいだろうか - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 メンチカツサンドを汚なく作る方法。 トレーズというゲーム、そしてその問題 トレーズ(treize)というゲームがある。このゲームの名前はフランス語で13を表している。このゲームは、ジョーカーを抜いた52枚のトランプを使って遊ぶ。 まず、トランプを良くシャッフルする。そのトランプのカードに1から順番を付けながらめくっていく。このとき、順番と同じ番号が出た場合は勝利し、次のプレイヤーに残りのトランプを渡す。当然ながら、順番とカードの数が一致しないときもある。このとき、プレイヤーは負けということになる。 そこで、このカードゲームにならって、我々は13枚のカードを用意することにしよう。そして、このカードを順番を付けながらめくっていった場合、果して順番と一致しない数しか出ない確率はどれほどになるだろうか。さらに、もしこのカードの枚数を2倍に増やした場合、勝つ確率は上がるだろうか。それとも
運気を上げるために魔方陣を作る(初級編) - Line 1: Error: Invalid Blog('by Esehara' )
今日の寿司 中身が気になる御歳頃。 はじめに 最近運気が悪く、悪夢も良くみるようになったので、これは邪気を払う必要がある。なので、そういうのに使えそうなものと言えば何か考えたら、魔方陣ではないか、ということを考えていた。 昔の夢は何だったか思い出すと、科学者か魔法使いになりたかった思い出があり、極まったプログラマというのはWizardと呼ばれる。さすがに、自分がそのレベルに達しているとは思えないが、どうせだし、魔法陣くらいは作れるようになりたいと思ったので、今回のエントリを書く。以下、『魔方陣の世界』という参考書(エントリの最後に記述する)を元に書く。 魔方陣とはなにか とはいえ、魔方陣とは何かについて、最初に書いておかないといけない。魔方陣とは、1から始まる連続した異なる自然数を碁盤の目状に並べて、それぞれの列、それぞれの行、そして対角線の数の和が一緒であるものを指す。具体的には、下のよ
『オープン・デザイン』は、むしろプログラマが読むべき本だった - Line 1: Error: Invalid Blog('by Esehara' )
今日の十六茶 試してガッテン方式で入れている。 はじめに オライリー社から2013年に発売された『オープン・デザイン』という本は、率直に言ってしまえば、如何にもデザイナー向けの思弁的な議論のアンソロジーとなっている。それらは、直接的には技術的な洞察を与えるものではないだろうし、また同様に、それが直接的に業務に使えるものかといったらそうでもない。 そうではないのにも関わらず、この本は、プログラマにとって重要な本であることは間違いないと、僕は確信している。逆説的なことではあるが、この本が技術書でないからこそ、あまりにも無視され続けた本であると思うのだが、だからこそ、今読むべき本であると思う。 プログラマはデザインが下手であるという現実を直視する もちろん、デザインという言葉は多義的な言葉であることは間違いない。まず指摘できることは、日本語の場合、デザインという言葉は「設計」という言葉ではなく、
ギャンブラーの錯覚は本当に錯覚なのかどうかをRubyで検証する - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 食べものに困ったときは、近くの肉屋でハムカツを買ってくればいい[要出典]。 お話 あるところに三人のギャンブラーがいた。この三人は仲が良く、今度カジノに繰りだそうということになった。そのカジノには、三つで一組のスロット台が存在していて、その三つのどれかが当たるような仕組みとなっていた。また、このカジノの売りは、それぞれのスロットを完全に操作せず、ランダムに当たりが出るようにしているということである。 ところで、ギャンブルにはオカルトというか、ある種の信念めいたものが、ギャンブラーにつきまとう。このギャンブラー三人は、それぞれ違った信念を持ちあわせていた。 まず一人目のギャンブラーは、「それぞれの台が完全にランダムに当たりが選ばれるとするならば、次にどの台を選択するかということを悩んでも仕方がない。なので、直感を信じて、台に座るのが正しい」 しかし、二人目のギャンブラーはこの意見
PythonからRubyに移行した人間の印象 - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 安物のねぎとろは、納豆と良くあう。 前提 はじめてのにき(2016-06-16) より。 このエントリの立ち位置について 元々はPythonを勉強していたのだけれども、仕事の関係上、Rubyを主軸にすることにした人間のエントリです。ちなみに、PythonとRubyの立ち位置には詳しくなく、主観を元に構成されているので、客観的な部分に関しては弱いことをお断りしておく。また、現時点での知識が2.7になっているので、3.5では多少違う点があるかもしれない。 なぜならPythonのほうが「わかりやすかった」から まず最初に、Pythonのほうが機械科学系の人に支持されやすい傾向としてあるのは、Pythonのライブラリ、例えばNumpyであったり、Scipy、または各種機械学習系のライブラリなどの影響が大きいのは間違いない。最近の機械学習ブームのせいなのか、Pythonも「エモい人(エモ
何故、「そのプログラミング言語」で関数型プログラミングをするのが難しいのか - Line 1: Error: Invalid Blog('by Esehara' )
近況 未来が脅す右手の指 ナイフが滑る左手首 朦朧と過ぎる日曜日 消えた秒針 数えた生久伸 このままでいいのか 俺はお前は 迷路の中 IT'S MY WORLD ――『KOKORO WARP』SHAKKAZOMBIE 問題 多くの人々にとって、既存の慣れ親しんだプログラミング言語で、最新のスタイルを身に着けたいと思うのが人の常だと思う。今宵、流行りのスタイルと言えば、恐らく「関数型プログラミング」になると思う。 混乱を避けるために、ここで一つ定義をする。ここで言う「関数型プログラミング」の定義とは、「副作用を出来るだけ避け、関数の連続によって書くプログラミング手法」という風にする。そして、このときの「関数」とは、「ある入力に対して、一定の出力を返すもの」という風に定義することが出来る。 さて、ここで二つの主題がある。まずひとつに、「副作用を出来るだけ避ける」という点と、「関数の連続によって
出社準備完了 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 21世紀になっても、まだ人類の課題として残されているのは、「出社」という概念だろう。IT業界だと、リモートワークも増えつつあるけれども、やはりまだ出社に縛られているというのが現状といったところだろう。 たいてい、出社のアンチパターンは二つあって、「そもそも朝起きられないから遅刻するパターン」と、「朝起きられるのだけれども、出社までに精神のブートが間に合わずに、遅刻するパターン」がある。このようなことを書いている僕は後者のパターンである。そこで、これの改善策に「出社へのモチベーションを高める」というのがあるというのに気がついた。出社へのモチベーションを高めるには、出社したくなるようなことをすればいい。そこで、「出社準備完了」の準備をするという方法を取ることにした。 出社準備完了の歴史 その前に、出社準備完了の歴史みたいなのを書いておかないといけない。 元々「出社準備完了」とは、to
今日のポエム: なぜ、その抽象化は失敗してしまうのか - Line 1: Error: Invalid Blog('by Esehara' )
近況 打ち捨てられた過去について 要旨 この記事を興味深く読む一方で、やはり違和感を覚える人も多くいるようで、自分もその一人だった。恐らく、この違和感は、「抽象化」が「具体性を奪取していくもの」といったような対立項として述べられているからだ、というように思われる。しかし、果たして具体性無しに「抽象化」することが有益なことなのだろうか。それが一つの違和感のように思われる。 本文 プログラミングの世界には、YAGNI原則(You ain't gonna need it)というものがある。また、YAGNIという言葉を使わなくても、「過度な汎用化が足を引っ張る失敗例」というのは、プログラマとしての心構えを書いた本の中で、ちらほらと自嘲気味に述べられることがある。 僕も、一度そのような失敗例を見たことがあるけれど、なぜこういう失敗が起こるのか。確かにデザインパターンで組み立てられたアーキテクチャは「
Rubyで実行可能な遺書 - Line 1: Error: Invalid Blog('by Esehara' )
近況 はじめに 恥の多い生涯を送って来ました。 自分には、人間の生活というものが、検討つかないのです。 このような身分の人間が、稀代の文豪と比較されるのも痴がましいのですが、自分は時折、まるで「太宰治のやうだ」と比喩ーーもしかすると揶揄なのかもしれませぬがーーされることが多くありました。 今日は舶来の行事であるところのエイプリルフウルが行われ、企業が浮かれ気分で犬にも与えられぬようなサイトを立ち上げるのが流行るので御座います。自分は、性根が心の底から腐っており、「ふん、莫迦々々しい」などと不貞寝し、一晩明けました。 「おれはどうしたのだろう？」と自分は思いました。というのも、自分の部屋、少し小さすぎるが見慣れた部屋が、どうもイツモの感じではありません。テーブルの上には、マックブックの他に、睡眠薬であるカルモチンがコロコロと転がっているではありませんか。自分はレヰルズで生計を立てるルビヰスト
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き
ifを使わず、エラーでFizzBuzzを実装してみよう - Line 1: Error: Invalid Blog('by Esehara' )
始めに FizzBuzz愛好家の皆さんこんにちは。野良FizzBuzz研究家の似非原です。 FizzBuzz研究というのは様々なジャンルがあります[要出典]。例えば、どれだけコードが短く書けるかに注力するCodeGolf派もいますが、一方でさまざまなFizzBuzzを書いて喜びとしている一派があり、それが自分だったりします(確認したところ、自分一人です)。FizzBuzzについては、もうことさら説明する必要もないかとは思いますが、もし知らない人は、適当にGoogleかなにかで検索してくれるとありがたいです。 中級FizzBuzzerの基本教養: if禁止 まず最初に、FizzBuzzの基礎教養として──つまり、FizzBuzz初心者からFizzBuzz中級者になる場合において──まずifを使わずに、どう分岐を表現するのか、というのがあるでしょう。例えばRubyにおいて、ifを使わずにFiz
自分がプログラマになったときに、Webアプリケーション開発の独習で学びにくかったところをまとめる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。 確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。 この記事で扱う「Webアプリケーション開発
Webサービスのプログラミングに必要なことのだいたいは、スクレイピングに学んだ - Line 1: Error: Invalid Blog('by Esehara' )
この記事を読み始める前に Rubyでやるんだったら、ちょうどそういう本が出ているから、その本買えばいいのではないでしょうか。 Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例 作者: るびきち,佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2014/08/25メディア: 大型本この商品を含むブログ (1件) を見る はじめに プログラミングを勉強し始めて、だいたい基礎的な文法を覚えたあとに、次に何をしようかな、と悩む人も結構多いみたいで、明確に「これを作りたい」という場合は、それを作ればいいとは思うんですけど、場合によっては、別段作りたいものが無く、漠然としたプログラミングをしたい、という熱意によって勉強しているという人もいるのではないかと思います。 で、もちろん「作りたいものがないのに、プログラミング勉強してどうするの」という意見もあるかとは思いますが、往
ORDER BY RAND()の代わりを実装する、あるいはMySQLでランダムにデータを取ってくる方法についてのメモ - Line 1: Error: Invalid Blog('by Esehara' )
こんにちは。相変わらずBookableというサービスをこつこつとやっているのですが、前回に「ORDER BY RAND()を使うと重くなる」という話を書いたところ、知人から「それやめろ」という斧であったり、あるいは他の方面からアドバイスを頂きました(Thanks グニャラくん！)。 なんでORDER BY RAND()がダメなの？という話は、ちょっと息抜きに翻訳したものがあるのですが、まず問題としてMySQLの乱数を生成するコストが高いという問題がある様子。少なくとも全件に対して乱数を発行するし、そして並び替えも発生してしまうので、とにかく非効率であると。だからその辺はMySQLにまかせるのではなく、それを呼び出すプログラム側にまかせたほうが圧倒的に効率がよくなるようです。 例えば、RANDでやると、下のように件数が増えるにつれて負荷が膨大になっていきます。 djangoの場合、元々のOM
ユーザーインターフェイスのリニューアルにおけるユーザーの覚えなおしコストについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに そういえば、最近はUbuntuからWindows 8を使いなおしている。なんでWindows 8をあえて使っているのかというと、それはいろいろな人が「使いにくい」と言っていたからだ。だから、その使いにくさを体験したいために、あえて使ってみているんだけど、その評判と違って普通に使いやすくなっていて驚いた。 少なくとも以前みたいな「スタートメニュー地獄（何かのアプリをインストールするたびにフォルダが増えていくアレ）」はなく、基本的にスタートのタイル画面からアプリにアクセスすることを考えると悪くない。そしてそのタイル画面にアプリを登録するのも簡単だ。また、それらのライブアプリを並べることが出来るので、デスクトップ画面で何かを作業しながら、スケジュールを入力するのも楽だ。それらの基本的にアプリにしても検索を中心にアクセスするという意味ではUbuntuのUnityで慣れているので、悪くはな
スタートアップで働くプログラマとして、非プログラマに対して気を付けなきゃいけないと感じていること - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 前回、非プログラマに対してプログラマに理解してほしいことというのを書いたら、なんかあとから伸びてきて、みんな思っていたことだったんだなーと思う反面、逆に一方通行に、プログラマだけが理解しろ！というのではなく、自分がプログラマとして働く上において、ちょっとだけ意識していることをあげておいたら、お互いにWin-Winかもね、と思う。そもそも、何かを要求するのに何も与えないというのも都合のいい話だろう。 もちろん、プログラマというのは一括りにできないし、前回の如く、当たり前にやっていることかもしれない。また「気を付けている」ということなので、気を付けている程度で本当はできていないかもしれない。 ただ、自分としては、非プログラマに対してこういうコミュニケーションが出来たら理想だなと思っている。そして、これはスタートアップの話である。すべての組織に適応できればベターだけど、そう簡単ではない
スタートアップで働くプログラマが、非プログラマの皆さんにお願いしたいこと - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。 たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあとい
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
重要なのはオブジェクト指向じゃないと思うんだよ - Line 1: Error: Invalid Blog('by Esehara' )
最近になって、オブジェクト指向がよくわからないという御仁とご一緒することになった。別段、それ自体が悪いことではない。確かに、その人の書いた、以前のコードというのはめちゃくちゃであった。当然のことながらif文は何十にも繰り返されているし、その中でネストが3つにも4つにも増えていくという恐るべきコードだ。そして、どうやら僕の前に、教えてくれた人がいるらしく、その人に「オブジェクト指向というのを教えてもらったから、もう少し上手く書けるようにになっている筈だ」ということを言っていた。 僕はそのことに、特段ケチをつけたいとは思わない。誰だって無知から始まる。僕もオブジェクト指向にとんちんかんなことを言って恥をかくことがある（もしかしたらこれからもね！）。無知が恥なのではなく、学ばない姿勢が恥なわけだから、僕はそういうのはいいなあ、と素直に思える。しかし、どうも僕は引っ掛かっていることがある。それをメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
