本当のプログラミング初心者にElixirを教えたことで得た学び - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 知っている人から知らないものをさしいれでいただきました。 ところで、みなさんは完全ですか? はじめに 知人が唐突に「これからElixirやっていくぞ」という気持ちになったため、Elixirのもくもくと勉強する会を秋葉原で定期的にやることになった。今回は第一回目であったため、以前に会をやっていたルームシェアでやることにした。 その中で、ウェブ媒体のライターをしつつ、のちのちはプログラマになりたいという若人がいたために、Elixir最速基礎文法をあらかじめ目を通しておいて、そのあとの課題としてProject Eulerの最初の10問程度をできるだけ自分で問いてみるということを提案してりたりした。他の人は、直接HTMLなどが表示できるほうがいいのではないか、という提案があったりしたのだが、個人的にはまず「分岐」「反復」といった考え方になれたほうがいいし、最初の10問程度はそれで済む程
ジャンケンみたいに三すくみになるサイコロについて - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 mograg garage【ART SPACE /GALLERY】の展示で買った郡司侑祐という方の作品です。 はじめに 普通、サイコロと言うと、1から6までの数字が書いてあるものだ。イカサマのサイコロでは無い限り、お互いの出た目を比較すると、だいたい半々の確率になる筈だろう。しかし、これではゲーム性があまりにもない。そこで、サイコロの目を改造し、あるサイコロAと、あるサイコロB、あるサイコロCの出目がそれぞれジャンケンのように、三すくみになるようなサイコロが作れるという話が実はある。 オンライン上では、英語になるけれども、この記事で概要を知ることができる。また、実物は海外だとグランド・イリュージョン社が販売している。 側面が二つ2のサイコロと、見えている側面全部が4であるサイコロが見える。 さて、このサイコロを実際に自分達の手で作ってみることは非常に楽しいことであるのは間違いな
『オープン・デザイン』は、むしろプログラマが読むべき本だった - Line 1: Error: Invalid Blog('by Esehara' )
今日の十六茶 試してガッテン方式で入れている。 はじめに オライリー社から2013年に発売された『オープン・デザイン』という本は、率直に言ってしまえば、如何にもデザイナー向けの思弁的な議論のアンソロジーとなっている。それらは、直接的には技術的な洞察を与えるものではないだろうし、また同様に、それが直接的に業務に使えるものかといったらそうでもない。 そうではないのにも関わらず、この本は、プログラマにとって重要な本であることは間違いないと、僕は確信している。逆説的なことではあるが、この本が技術書でないからこそ、あまりにも無視され続けた本であると思うのだが、だからこそ、今読むべき本であると思う。 プログラマはデザインが下手であるという現実を直視する もちろん、デザインという言葉は多義的な言葉であることは間違いない。まず指摘できることは、日本語の場合、デザインという言葉は「設計」という言葉ではなく、
Jupyter Notebook + RISE でスライド作ってトークしてきたというお話 - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 Cookdo麻婆豆腐と手作り麻婆豆腐の自炊戦争が行なわれてから十数年たつが、正直Cookdoの麻婆豆腐の味は忘れてしまった。とはいえ、あらためてCookdoで作る気にはならんなー、ということで、丸善屋の麻婆豆腐の素を手にいれて作った。 メリットとしては、素には挽肉も入っているので、挽肉を炒めるという工程、同様に量にあわせて豆板醤を混ぜあわせるといった行為をしなくてもいいという部分にある。しかし、辛口を買ってきたつもりが、意外と辛くなく、がっかりするということもある。辛めの麻婆豆腐が好きであるならば、自炊したほうがいいのかもしれないな、というのが現状の結論である。 概要 Jupyter Notebookという、ブラウザ上で使えるREPL環境がある。これを使うと、RubyやPythonのコード結果を書き残しながら操作できるという利点がある。またこのJupyter Notebookに
YAPC8oji用に80枚まで作ったけど、没になったスライド 「プログラミング言語処理入門以前」 を公開します - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 はじめました。 没になったスライド プログラミング言語処理入門 (YAP(achimon)C::Asia Hachioji 2016 没スライド) from Esehara Shigeo 理由 YAPC8ojiでトークをすることになったので、登壇初心者のみなさんへというページを読んでいたら、「同僚や友人やぬいぐるみなど相手に練習するのは良いことです。」という、いいことが書かれていた。なので、友人にスライドを発表した結果、そのフィードバックとして 話題がとっちらかりすぎていて、話についていけない 今、何が主題になっているのかよくわからない ただいろんな言語を知っていることを自慢したいだけでは 30分で90枚は、お前は時間というのをナメている という、極めて理知的なフィードバックを頂いた。で、今回はちゃんとした成果物があるわけだから、それが動く様子をきちんと紹介したほうがいいのでは
Racket(Lisp)で簡単なラムダ簡約機作った - Line 1: Error: Invalid Blog('by Esehara' )
街の風景 はじめに こないだ、知人の「会」という曖昧なことが行なわれ、そこに参加していたら、酔っぱらったtakano32さんが「Rubyでラムダ簡約機作っていて、これ凄く革新的だと思うんですけど、誰もスターを付けてくれないんですよ」とクダを巻いていだ。見てみると、やっていることはとても楽しそうで、ただ最終コミットが5年前なのが惜しく、よし、どうせなら自分でも簡単なラムダ簡約機を作ってみようと思ったのが今回の記事の経緯である。 ラムダってそもそも何よ 過去のブログにも書いだけれども、改めて説明するならば、無名の関数というのが良いだろうか。例えば、ある変数をそのまま返す関数として、を定義できる。しかし、これが使い捨てである場合、関数に対してわざわざ名前を付けていくのは苦難である(プログラミングでも良くあることだと思う)。だから、「名前の付いた関数」から「関数」を切りはなし、関数それ自体をあらわ
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き
カリー化、部分適用、クロージャという間違いやすい三種についての簡単なメモ書き - Line 1: Error: Invalid Blog('by Esehara' )
追記 カリー化を間違えてカーリー化という表記をしていたのを修正しました。 そもそもカリー化とは何か 複数の引数を取る関数は、一つの引数を取る、関数を返す関数の連続として表現できるということ、と言葉で表現しても抽象的すぎるので、ちょっと式で表してみる。 まず初めにラムダの導入 例として、ある整数に対してプラス1する関数を定義する。このような関数は、として表現できる。 ここでこの関数はplusoneという名前を与えられているが、このx + 1という関数そのものを表現するような記法があると便利だろう。そこで、をそのような記法として定義する。 この記法を用いることにより、上記のはとして表現できるようになる。つまり、関数それ自体を表す記法を導入することによって、関数の名前と、関数それ自体を区別することができるようになる。 カリー化 このような考え方が便利なのは、関数を返す関数というものを表現できるよ
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
