本当のプログラミング初心者にElixirを教えたことで得た学び - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 知っている人から知らないものをさしいれでいただきました。 ところで、みなさんは完全ですか? はじめに 知人が唐突に「これからElixirやっていくぞ」という気持ちになったため、Elixirのもくもくと勉強する会を秋葉原で定期的にやることになった。今回は第一回目であったため、以前に会をやっていたルームシェアでやることにした。 その中で、ウェブ媒体のライターをしつつ、のちのちはプログラマになりたいという若人がいたために、Elixir最速基礎文法をあらかじめ目を通しておいて、そのあとの課題としてProject Eulerの最初の10問程度をできるだけ自分で問いてみるということを提案してりたりした。他の人は、直接HTMLなどが表示できるほうがいいのではないか、という提案があったりしたのだが、個人的にはまず「分岐」「反復」といった考え方になれたほうがいいし、最初の10問程度はそれで済む程
『オープン・デザイン』は、むしろプログラマが読むべき本だった - Line 1: Error: Invalid Blog('by Esehara' )
今日の十六茶 試してガッテン方式で入れている。 はじめに オライリー社から2013年に発売された『オープン・デザイン』という本は、率直に言ってしまえば、如何にもデザイナー向けの思弁的な議論のアンソロジーとなっている。それらは、直接的には技術的な洞察を与えるものではないだろうし、また同様に、それが直接的に業務に使えるものかといったらそうでもない。 そうではないのにも関わらず、この本は、プログラマにとって重要な本であることは間違いないと、僕は確信している。逆説的なことではあるが、この本が技術書でないからこそ、あまりにも無視され続けた本であると思うのだが、だからこそ、今読むべき本であると思う。 プログラマはデザインが下手であるという現実を直視する もちろん、デザインという言葉は多義的な言葉であることは間違いない。まず指摘できることは、日本語の場合、デザインという言葉は「設計」という言葉ではなく、
イケてないRubyのコードのリファクタリングって奴をSmallTalkでやってみる - Line 1: Error: Invalid Blog('by Esehara' )
本日の料理 コードも豚肉も煮こむに限る はじめに Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その１ - Ruby on Railsのビシバシはぁはぁ日記というブログの記事がどうもバズっていて、色んな方面からつっこみが入っていたりする。また、別にこれはオーバーエンジニアリングだから、この程度のコードでもいいのではないか、という指摘も挙がっている。 自分ならどうするかというとこういう感じかな。要するに条件に合う注文を足し算したいだけなので、条件に合う注文を足し算しようよ、という。https://t.co/HEhsO5q2nr— Rui Ueyama (@rui314) 2016年7月17日 コードを書く人によって「これが良いアプローチだ」というのは千差万別であることは間違いない。元の記事を読む限り、これはどうもRubyの特殊事情な
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' )
近況 打ち捨てられた過去について 要旨 この記事を興味深く読む一方で、やはり違和感を覚える人も多くいるようで、自分もその一人だった。恐らく、この違和感は、「抽象化」が「具体性を奪取していくもの」といったような対立項として述べられているからだ、というように思われる。しかし、果たして具体性無しに「抽象化」することが有益なことなのだろうか。それが一つの違和感のように思われる。 本文 プログラミングの世界には、YAGNI原則(You ain't gonna need it)というものがある。また、YAGNIという言葉を使わなくても、「過度な汎用化が足を引っ張る失敗例」というのは、プログラマとしての心構えを書いた本の中で、ちらほらと自嘲気味に述べられることがある。 僕も、一度そのような失敗例を見たことがあるけれど、なぜこういう失敗が起こるのか。確かにデザインパターンで組み立てられたアーキテクチャは「
Rubyで実行可能な遺書 - Line 1: Error: Invalid Blog('by Esehara' )
近況 はじめに 恥の多い生涯を送って来ました。 自分には、人間の生活というものが、検討つかないのです。 このような身分の人間が、稀代の文豪と比較されるのも痴がましいのですが、自分は時折、まるで「太宰治のやうだ」と比喩ーーもしかすると揶揄なのかもしれませぬがーーされることが多くありました。 今日は舶来の行事であるところのエイプリルフウルが行われ、企業が浮かれ気分で犬にも与えられぬようなサイトを立ち上げるのが流行るので御座います。自分は、性根が心の底から腐っており、「ふん、莫迦々々しい」などと不貞寝し、一晩明けました。 「おれはどうしたのだろう？」と自分は思いました。というのも、自分の部屋、少し小さすぎるが見慣れた部屋が、どうもイツモの感じではありません。テーブルの上には、マックブックの他に、睡眠薬であるカルモチンがコロコロと転がっているではありませんか。自分はレヰルズで生計を立てるルビヰスト
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き
在宅勤務始めました - Line 1: Error: Invalid Blog('by Esehara' )
この記事について この記事はHeartRails Advent Calendar3日目の筈でした。 趣旨 HeartRailsに入社した。そこで、リモートを通じて受託開発などを行っている。ちょうど1ヶ月ほど経ったので、リモートワークに関しての所感をメモしておこうというのが今回の記事の趣旨。 なぜリモートワークをやろうと考えたの? 割と働き方で体調を崩すことが多くあったので、「これは自分の働き方を見直さないとマズイな」と思い、あまり一般的な働き方に囚われず、自分にあった働き方を見つけようと思ったのがきっかけ。そうなると、現状として二つの働き方があって、「リモートワーク」か、あるいは「短時間勤務」になるかなと考えたので、そのあたりを中心に見直した結果、HeartRailsの働き方がマッチしているかなと思ったので、そういう経路で働き始めたという経路。 リモートワークを中心にすることに関して不安は
自分がプログラマになったときに、Webアプリケーション開発の独習で学びにくかったところをまとめる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。 確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。 この記事で扱う「Webアプリケーション開発
東亜飯店で飯を食べた - Line 1: Error: Invalid Blog('by Esehara' )
誕生日ということもあり、かねてから行きたかった東亜飯店で飯を食うことにした。 イベントを立てて、行きたい人を募り、実際に飯を食いに行った。 結論からすると、上の写真を撮らせてくれたし、中華屋としても美味しく、また値段も手頃であり、飲み食いしているときに、ちゃんとお皿を定期的に片付けてくれたりなど、変なチェーン居酒屋を利用するよりも、かなり良い店だった。そこらへんのレポートを書こうと思う。 東亜飯店は実在するの? 実在します。食べログにも、店情報がある。ここに書いてない情報としては、ランチは11:00～15:00の間、夜は18:00～22:30の間で開店していることが多いようだ。 で、この画像なんなの? 東亜飯店とは? と思う人もいるだろうから、東亜飯店がこれほどまでに有名になった経緯は、このエントリに詳しい。こちらにも念のため、画像を張り付けておく。 別にIT系(特にWeb系)でこの画像が
迫り来る「forおじさん」と呼ばれる時代 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今となっては、プログラマにとってなんとなく理解して利用できることが当たり前になりつつあるオブジェクト指向ですが、しかし、それこそ今から数年前には、この「オブジェクト指向」というのは、いわばおじさん達が変な方針を打ち出したりして「え、それ変な実装方針じゃねえの」というツッコミが入ったりしていました(ちなみにそのあたりの雰囲気については、この記事を読むと分かりやすいでしょう)。 もちろん、これはこれなりにメリットがあるのかもしれませんが、しかしそれはまた別のオブジェクト指向を利用したモデリングと比較してのことであって、「これだけでいい」と考える人はいないでしょう。 原則: だってそのほうが開発しやすいから まず最初に原則を考える必要があります。まずひとつに、必ずしもオブジェクト指向が正しいモデリングの方法ではないこと。少なくとも自分が思うに、オブジェクト指向を使うべき理由というのは、
スタートアップで働くプログラマが、非プログラマの皆さんにお願いしたいこと - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。 たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあとい
「組織的負債」というものを考えてみる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 現在、自分はスタートアップをお手伝いしている。そして、現在はどんどんユーザーをスケールさせようということで、士気が上がっている。エンジニアも入れたい。そのような前向きな雰囲気になっていて、とても心地良いのだけれど、ただ、その上で、今クリティカルになっているのは、伝達経路であったり、あるいは振っているタスクが適切に配られずにいびつになっている状態があるよねということを、戦略の人と話したりする。 周りを見渡してみると、実はこの問題は自分たちだけの問題ではなく、ベンチャーによくある問題であることに気がついた。例えば急成長しているベンチャーにおいて、評価制度が適切ではなかったり、あるいは他に適性がある人間がちゃんと配分されていなかったりすることがある。そのことによって、優秀なエンジニアが流出したり、あるいはプロジェクトの失敗率が上がったりする。 これらの問題を、個人の問題として片付けるこ
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
GitHubで個人的に書いているClojureの本について告知します - Line 1: Error: Invalid Blog('by Esehara' )
良い子のみんな、元気にしているかな? そんな良い子のみんなに、いま自分がぽちぽちと書いているClojureの本を公開しておくよ！お金はとらないよ！無料だ！ Clojure日和 (GitHubレポジトリ) クリスマスくらいに公開すると粋かなと思ったので、このタイミングで公開するよ。とはいえ、まだまだ充実していないし、少し見直すと間違っているところがかなりあるけど、そこは怖いお兄さんたちのマサカリを期待しているよ！ 意図 意図としては簡単で、基本的にあるプログラミング言語の学びやすさというのは、そのドキュメント量に比例する。残念なことに、Clojureの体系的な本の翻訳は、殆どがペンディングされている。もちろん、日本では電子書籍を含めて、Clojureの本は三冊あるけれども、しかし基礎的な本を十分に解説しているとはいい難い状態だ。それは、僕が始めてClojureを知った二年前よりは、だいぶ状況
重要なのはオブジェクト指向じゃないと思うんだよ - Line 1: Error: Invalid Blog('by Esehara' )
最近になって、オブジェクト指向がよくわからないという御仁とご一緒することになった。別段、それ自体が悪いことではない。確かに、その人の書いた、以前のコードというのはめちゃくちゃであった。当然のことながらif文は何十にも繰り返されているし、その中でネストが3つにも4つにも増えていくという恐るべきコードだ。そして、どうやら僕の前に、教えてくれた人がいるらしく、その人に「オブジェクト指向というのを教えてもらったから、もう少し上手く書けるようにになっている筈だ」ということを言っていた。 僕はそのことに、特段ケチをつけたいとは思わない。誰だって無知から始まる。僕もオブジェクト指向にとんちんかんなことを言って恥をかくことがある（もしかしたらこれからもね！）。無知が恥なのではなく、学ばない姿勢が恥なわけだから、僕はそういうのはいいなあ、と素直に思える。しかし、どうも僕は引っ掛かっていることがある。それをメ
一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )
とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基本的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシを食う数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ
むしろ数式が苦手だけど統計を勉強したいという人はRをやるといいかもしれない - Line 1: Error: Invalid Blog('by Esehara' )
はじめに なぜか唐突にRブームが俺の中でやってきてしまってどうしようもないので、Rの本を注文しまくってたりしていたら、下のような本の山が出来てしまいました。 これらの本を付箋でペタペタしながら読み進めていくうちに、段々とRというのはどういう言語で、どういう風に勉強するといいのか、という方針が固まってきたので、ここにメモをしておきます。 Rとはどのような言語か 一言で、しかも乱暴に言ってしまうならば「統計に特化したPHP」というのが一番雰囲気を伝えられるかもしれない。いや、PHPの悪評は知っているし、ガチでRをやっている人にとっては嫌がられることもわかっているけど、あえてそういう説明が、あくまで入り口としてはわかりやすいのではないかと。 どういうことかというのを言い訳します。 自分が読んだ感じだと、統計というのは、「何らかのデータ」と「分析するためのツールとしての数式」と「その数式が意図する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
