本当のプログラミング初心者にElixirを教えたことで得た学び - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 知っている人から知らないものをさしいれでいただきました。 ところで、みなさんは完全ですか? はじめに 知人が唐突に「これからElixirやっていくぞ」という気持ちになったため、Elixirのもくもくと勉強する会を秋葉原で定期的にやることになった。今回は第一回目であったため、以前に会をやっていたルームシェアでやることにした。 その中で、ウェブ媒体のライターをしつつ、のちのちはプログラマになりたいという若人がいたために、Elixir最速基礎文法をあらかじめ目を通しておいて、そのあとの課題としてProject Eulerの最初の10問程度をできるだけ自分で問いてみるということを提案してりたりした。他の人は、直接HTMLなどが表示できるほうがいいのではないか、という提案があったりしたのだが、個人的にはまず「分岐」「反復」といった考え方になれたほうがいいし、最初の10問程度はそれで済む程
日報: とある企業に面接に行ってきた(1) - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 転職しようとする人のモノマネです 本文 シリーズもののように、連番は付けているが、これが続くかどうかはわからないが、感触からすれば続くだろうなと思ったので連番にしようと思った。 一般的に、最近の企業ならば、面接者にコードを書かせるかと思われる。とある企業では、事前に聞いていたテストだったので、ここで種あかしするのは野暮であり、と同時に一部には「とある企業」の「とある」が分かってしまうので、曖昧にぼかすのだけれども、基本的に自分はREPLに甘やかされていて、それで通らないコードを提出してしまった。 なので、今からでもいいから「そのソース書きなおさせろ」と殴りこみをかけたいものだが、良識を分きまえているつもりなので、それは知なかったが、動かないコードが、あとから動かないと気がついて、面接会場から出るというのは、本当に恥かしい経験で、穴があったら入りたいどころか、穴二つ分作りたい気分
日報: 治安の悪い「オッ」界隈について - Line 1: Error: Invalid Blog('by Esehara' )
「オッ」界隈とは何か 「オッ」界隈とは、簡単に言ってしまうならば、Twitter上で、何らかの発言や記事に対して「オッ」とだけ返す界隈が存在していることを指している。例えば、「お腹すいたな」という発言をすると、「オッ」とだけリプライが返ってくる、そういう界隈である。 本来ならば、そういう発言に関しては、お気に入りに入れてほんわかと見守るのが、インターネット上のマナーとなるわけだが、「いいね」とすることが、どちらかと言えば消極的な返事に対し、「オッ」と返すことは積極性を反映し、興味関心が非常に強いということを相手に伝え、繋がりが薄いと言われている現代社会に強い絆を作りだすと同時に「お前を見ている」というビックブラザー効果が期待できるということらしい。 上が、そのようなビックブラザー性を象徴する「オッ」界隈の画像である。 要するに「オッ」と言われたら「オッ」と返ってくるようなインターネット、こ
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も「エモい人(エモ
隠れた名作タイル型ウィンドウマネージャー・i3wmのススメ - Line 1: Error: Invalid Blog('by Esehara' )
概要 Linuxのウィンドウマネージャーの系統として、ウィンドウを敷きつめるタイプの「タイル型ウィンドウマネージャー」というものが存在している。このi3wmは後発のウィンドウマネージャーなだけに、手が届く作りとなっているので、今回は振り返りついでに、i3wmの紹介と使い方を説明したいと思う。 はじめに 世の中には、ウィンドウを縦に並べておかないと気が済まない人がいる。かく言う自分もそうで、UbuntuやWindowsだと、ウィンドウを右端や左端に持っていけさえすれのば、画面半分に整列してくれる。しかし、整理の苦手な自分にとっては、常にウィンドウが整列してくれたほうが望ましい。 タイル型ウィンドウマネージャー そこで、タイル型ウィンドウマネージャーというものが出てくる。 Linux系だと、ウィンドウマネージャと呼ばれる、デスクトップ部分は自由に入れかえることができる。そして、タイル型ウィンド
プログラムにおける「関数」とは何かについて、自分なりのまとめ - Line 1: Error: Invalid Blog('by Esehara' )
近況 自宅サーバーが起動しなくなったため、中身に保管してある電子書籍のPDFが取り出せず、大量の知性が失われている。 要旨 以前に「関数型プログラミングの初心者」に向けて質問したときに、そもそも関数とはなにかについてわからなかったという質問があった。自分も、具体的に関数とはなにか、というと説明に困ることがある。そこで、今回のブログでは「関数」とは何かについて、自分なりにまとめたことを書く。 はじめに 知り合いの技術者は、「実は関数の考え方について、一年間くらい馴染めなかった」と言っていた。現在では、開発をバリバリやっているような人であり、自分も尊敬しているのだけれど、そういう人でも「関数」という考え方について、実はそれほど馴染めなかったということを聞いてビックリしたりしていた。 とはいえ、そういう風に「そうなのか」と納得している俺も、実際のところ、では「関数」とは何か、というのを説明できる
『マンガでわかる！関数型プログラミング』という漫画を連載することになるようです - Line 1: Error: Invalid Blog('by Esehara' )
近況 ふとした瞬間に虚しくなることがある いきさつ 今年、秀和システムから関数型プログラミングに関する本が出て、良くも悪くも、その本が注目を集めることになってしまいました。そんな中で色々な人が反応していましたし、自分もこのようなかたちで感想を書きました。 一方で、このような本を書かれるくらいであるならば、自分で真っ当な本を書けばいいわけだし、技術書を書くことなんて、そんな敷居の高いことではないというカウンターもあり、個人的にはそれも最もだなあ、という印象がありました。その中で自分なりに関数型プログラミングについて理解したことを元にQiitaに駄文をアップしたりしていました。間違ってたら、誰かが訂正してくれるだろうし、そのほうが自分にとって勉強になるだろう、と思うので。 ですが、「関数型プログラミング」というのは「なんだか難しい」という印象を覚えるのも事実のようです。実際に、最新の『Soft
Pythonのlambdaだけで、Schemeのcond(条件分岐)っぽいものを実装する長い道のり - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近はずっとScheme（いわゆるLispの方言）とかそういうのをいじっていたせいなのか、「あー、関数型っぽく考えてえなあ」という、いわゆる関二病（関数型言語を勉強して二ヶ月目にかかる病気）になってしまっていた。で、そういった「関数型」によくあるアプローチをPythonで書き直した場合は、どういう形になるのだろうか、と思ったので、興味がてら、幾つかのサンプルを書いてみる。最初に、condを実装してみようと思う。 ちなみに、同じようなことを過去に考えていた人はいたようで、fn.pyという名前で公開されていたりします。 実装 例えば、今から階乗を算出する関数を定義してみます。この場合、関数を定義するのに、lambdaだけしか使えない、という縛りをつけます。もちろん、既存の階乗を求める関数を使ってもいけない、とします。 まず、単純に関数のテンプレートを考えてみます。関数のテンプレートは
『説得とヤル気の科学』を読んで、やる気について考える - Line 1: Error: Invalid Blog('by Esehara' )
はじめに もともと、自分の根っこは怠惰であり、休日になっては「やる気がしないな」とか言いながら、家でゴロゴロしたりするのが常態化していたりする。なので、何かやる気を出すためのヒントとして、本書を読んだりしていた。 実際、この文章も、昨日くらいに「もうそろそろ何かエントリの一つでもあげようかな」と思って書こうとしたところ、一文も文章が進まなかったという諸事情もあるので、本読んでなんにも身についてねえじゃねえか、ということにもなりかねないので、ちゃんと記録に残しておこうと思った次第。 本書について この本の名前が『説得とヤル気の科学』と書いてあるとおり、そもそも本人（＝本を読んでいる人）が「やる気を出す」という側面だけではなく、マネージャーの人が、以下に自分たちがマネージしているメンバーに対して、如何にやる気を持ってやってもらうか。そしてそれを通じて如何に話を通すか、といった側面も含まれている
Word2Vec + MeCabで「ボケる」ための単語候補をピックアップするやつをやってみる - Line 1: Error: Invalid Blog('by Esehara' )
近況 はじめに 最近、ちょっと大喜利を始めていて、如何に面白いことを言えるのか、ということを考えたりしているんだけど、考えてみれば、自分は少しプログラミングができるし、むしろ形態素解析や自然言語処理という観点から「質問」と「ボケ」を考えてみると面白いかもしれない、と思って、力技でそういうことをやってみた次第。 今回の方針 とはいえ、何となく「質問に対して上手いボケを返してほしいな」ということであるならば、それこそ単語のランダム検出でもいいという話になってしまうので、ある程度仮説を立てて実装する。今回の仮説としては、「ある文が連想する知識の、派生する知識がその文と結びつけられた場合、人は上手いと思うのではないか」ということだ。 どういうことか。 例えば、謎かけの場合、「Aとときまして、Bととく。その心はCです」と言った際に、一見無関係の文(あるいは単語)が、Cという意味づけによって接続するこ
大学に入学します - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 退職エントリとか、入社エントリは大量に腐るほどあるけれど、入学エントリなんていうのはほとんどないと思うので、書いてみると面白そうだったので書いた。 入学する先は? 入学先は放送大学で、全科履修生として届けを出した。学部は教養学部の情報コースであり、単位としては、初歩的な数学からネットワーク、デジタル情報などを受講するつもりである。無事、満額を支払ったので、何も問題なければ、四月から大学生になっている筈である。満額といっても、一般的な大学ならばそんな問題はない額ではあるけれど、支払ってみると、結構痛い感じになった。 入学するまでの経路 自分の背景を説明すると、二流大学私立中退という経歴がある。で、紆余曲折がありながら、現在、プログラマとして三年ほど、見よう見真似で仕事をさせてもらっている。 しかし、仕事をすればするほど、あるいは技術的に面白いことをやろうとしたりすると、そもそも基礎
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き
「モノを作ること」について考えるベースになったものをだらっと紹介していく: 2015春 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに たぶん、自分はエンジニアというよりも、何かモノを作っていたいタイプであって、趣味でも作曲とか漫画とか、小説とかを書いたりしている。 元々、子供の頃は漫画家や小説家とかになりたかった人間で、何時の間にやらエンジニアというものを見よう見まねでやっては失敗したり怒られたりしているわけだし、たいした実績があるわけでもない。ただ、自分がWebサービスとかを作るということの裏側には、そういう「そもそもモノを作るってどういうことだろうか」ということが裏側にある。そして、そのことによって迷惑をかけることが何度かある。 そういうことを念頭に置いてもらうとして、ここで紹介するのは、自分が「モノを作るということはどういうことだろう」ということを考えるときのベースになったもの達だ。これらが血肉になっているとは到底自分の中では言い難い。それは自分の能力がそれを証明している。とはいえ、自分にとって血肉になら
クズのための手帳術: 全部まとめて書く - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 自分はクズという自覚があるのだけれど、クズなりに手帳の使い方について、運用方法を考えたところ、これがうまくいっている感じだったので、ここに共有しておく。 クズの条件 自分が考えるに、クズの条件とは、下の三つのようなことをよく起こすことを指す: 整理が苦手 すぐモノを忘れる やるべきことを先延ばしにする 実は、以前はちゃんとした手帳を買っていたのだが、たいていは三ヶ月くらい運用したら無くしてしまうというバカみたいなことをやってしまっていた。手帳を無くすと、スケジュールが真っ白になるため、はっきりいって意味がない。 そうなると、クラウド上の、例えばGoogleなんかのカレンダーを使えばいいじゃないかという話になるのだけれども、しかしクズの皆さんは思い当たる節があると思われるのだが、現状としてカレンダーにメモするのは面倒臭い。あとで予定を入れておこうと思っても、それ自体を忘れてしまうの
紙で日記を書いてみるのが結構良かったのでオススメしてみる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近やり始めたことの一つに、紙の日記を書くというものがある。とはいえ、一月から続けているもので、その理由としては、紙の日記を付けてみるのも面白いんじゃないかと思って、正月初めに買ったのがきっかけだった。で、はじめてみたのだけれど、意外や意外にも、これが結構長続きするものだった。 出来るだけダサい表紙のものを使いたかったので、下のような日記帳を使っている。 ポイントとしては、半ページか未開き。そして横書きというのにこだわっていた。普段違うことをやるんだから、縦書きでもよかったのだけれど、縦書きだと違和感を覚えるという、デジタル育ちの悲しい性なのか、横書きのものを選んでしまった。 紙の日記のいいところ 承認欲求が満たされない まず最初に、紙の日記は基本的に公開されない。自分のためだけのものである。読者は自分一人だ。自分一人なものだから好き勝手書ける。普段なら躊躇うようなことでもスラス
Project Eular 15: 正方形の道筋は幾つあるの? について - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 数学の問題をプログラミングで解こう! という趣旨の、プログラミング問題集であるところのProject Eularというサイトがあって、非常に初歩的なんだけど、解くのを面倒臭がって放置していた問題として、20 x 20の正方形の道筋はいくつあるの?という問題がある。久しぶりにやってみたら、スムーズに解けたので、嬉しくなったので、その辺りの話をメモしておこうと思う。処理系は以前と同じRacketで。 非効率な方法: 単純な再帰でやってみよう もちろん、この手の問題はしらみつぶしに調べていけば、その数の総数を調べることができる。考え方としては、問題の性質上、「右か下か」に行くことができる。そして、「問題の正方形の幅を超えてしまったら移動できない」という風な考え方ができるだろう。汚い図にすると下のような感じ: これを素朴に実装すると、下のようになる: (define X 3) (defi
オブジェクト指向について考えたいので、Lispでオブジェクトもどきみたいなものを実装してみる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近になって、「関数型とは何か」みたいな文章が増えている。それらの文章は玉石混交しているし、技術的ではない部分も多いので、自嘲の意味で「ポエム」と自ら呼んでいたりする。その関係もあってか、手元にある『On Lisp』と『実用Common Lisp』にある「Lispによるオブジェクト指向」に関する章を読んだりしていた。そこで、考えたことをメモしておく。 以下、利用している処理系はRacket languageを想定している。 Lispでオブジェクト指向っぽいものを作ってみる この項目はLispによってオブジェクト指向を作るための道筋みたいなものである。もし、Lispに興味が無ければ、一挙に飛ばしてもいい。 はじまり よく言われているように、「関数型」と呼ばれる言語の特徴として「副作用」をできるだけ排除する傾向にある、ということはできる。副作用とは、ある変数などにおいて変化を発生させ
『アンダースタンディング・コンピュテーション』第二章を読みながら、Lispのことを考えてみる - Line 1: Error: Invalid Blog('by Esehara' )
そういえば、AmazonのWishlistから『アンダースタンディング・コンピュテーション』を頂いて、少しずつRubyで本書のコードを書いたりしていたのだけど、自分の理解を書いておいたほうがいいかなと思って、セーブがてら、自分の理解をメモしておこうと思う。 『アンダースタンディング・コンピュテーション』について ポイントとしては、この本が基本的に「コンピューターがプログラミング言語を理解すること」というものを作る上に置いての簡略的な技術的トピックを、実際にRubyを使いながら動かしてみるということに主眼を置いていることがポイントだと思う。たぶん、そういう「何かを動かしながら理解する」という方法については、色々あると思うし、実際にそのトピックについては幅広いものがあって、それらを全て300ページで解説することは大変なことではあるし、実際、読者にとっても興味のトピックは様々あるだろうから、「そ
ポモドーロ・テクニックを二ヶ月やってみた感想 - Line 1: Error: Invalid Blog('by Esehara' )
二ヶ月間ポモドーロテクニックをやってみての雑感 だいぶ知見が溜まってきたので、セーブがてら記事にしておく。 方法 要するに 25分、集中してそのタスクをやったら5分休む = 1Pomodoro 4Pomodoroやったら15分休む というのを繰り返すというだけだ。 実際の運用 確かにもう少し厳密なフローとしては、例えばTodoリストを作成したり、それに対しての見積もりをする、という方法もあるのだけど、自分はそういう網羅的なToDoを作成するのが苦手だったりする(むしろ作業中にどんどんToDoを積み上げていくという方法)のほうが好きだったりするので、そういう風にしている(最初から完璧にやろうとすると絶対無理なので)。 意外とやってみてよかったというのは、集中できたときのアクティビティを記録しておくという方法だ。要するに何時にポモドーロテクニックを集中できてやれたのか、というのを一つずつ記録し
Racket + big-bangを使ってどうしようもないプログラムを書く方法 - Line 1: Error: Invalid Blog('by Esehara' )
この記事はLisp Advent Calender 13日目の筈でした。 はじめに: プログラミングの楽しみ さて、Lisp処理系と呼ばれるものには様々なものが存在します。その中で、そこそこに人気のある処理系であるRacketを使って、Lispと一緒に気軽に戯れてみよう！というのが今回の趣旨です。 まず最初に、プログラミングをする上での楽しみというのは一体何でしょうか。当たるようなサービスを作る? それとも仕事で効率化するようなものを作る? それとも、様々なアルゴリズムについての洞察を得たりする? どれも、プログラミングの楽しみであるのは間違いないし、否定することはできません。しかし、プログラミングの楽しみとは、別の意味では「ゴミみたいなプログラム」を書くことではないでしょうか。つまり、「どうしようもないプログラム」を作ってゲラゲラ笑うといったことです。 例えば、とある中級者のプログラマが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
