ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - 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' )
二ヶ月間ポモドーロテクニックをやってみての雑感 だいぶ知見が溜まってきたので、セーブがてら記事にしておく。 方法 要するに 25分、集中してそのタスクをやったら5分休む = 1Pomodoro 4Pomodoroやったら15分休む というのを繰り返すというだけだ。 実際の運用 確かにもう少し厳密なフローとしては、例えばTodoリストを作成したり、それに対しての見積もりをする、という方法もあるのだけど、自分はそういう網羅的なToDoを作成するのが苦手だったりする(むしろ作業中にどんどんToDoを積み上げていくという方法)のほうが好きだったりするので、そういう風にしている(最初から完璧にやろうとすると絶対無理なので)。 意外とやってみてよかったというのは、集中できたときのアクティビティを記録しておくという方法だ。要するに何時にポモドーロテクニックを集中できてやれたのか、というのを一つずつ記録し
在宅勤務始めました - Line 1: Error: Invalid Blog('by Esehara' )
この記事について この記事はHeartRails Advent Calendar3日目の筈でした。 趣旨 HeartRailsに入社した。そこで、リモートを通じて受託開発などを行っている。ちょうど1ヶ月ほど経ったので、リモートワークに関しての所感をメモしておこうというのが今回の記事の趣旨。 なぜリモートワークをやろうと考えたの? 割と働き方で体調を崩すことが多くあったので、「これは自分の働き方を見直さないとマズイな」と思い、あまり一般的な働き方に囚われず、自分にあった働き方を見つけようと思ったのがきっかけ。そうなると、現状として二つの働き方があって、「リモートワーク」か、あるいは「短時間勤務」になるかなと考えたので、そのあたりを中心に見直した結果、HeartRailsの働き方がマッチしているかなと思ったので、そういう経路で働き始めたという経路。 リモートワークを中心にすることに関して不安は
プログラミングの学びはじめこそ、どんどん文章で残して公開しておいたほうがいいかもしれないという話 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 現在、自分はPythonから暫く離れてRubyを勉強している。現在のスキルとしては、gemがなんとか書け(これについては、後ほど報告)Railsでアプリケーションも書けるようになったというレベルだ。つまり、Rubyで軽量なアプリケーションならば、自力で作成できるくらいには、なんとか書けるようになった。 よちよち歩きでRubyを歩き始めたという現状として、では実際にRubyはどういう風な挙動をしているのか、というのを理解して、Rubyでのコーディング精度を高めないといけないなーというのは実感しつつある。ただ、同時にこういうときこそ、勉強メモをどんどん書いて勉強していくチャンスだなと思ったりもした。 なぜ学びはじめに文章を残しておいたほうがいいのか 学びはじめは、発見がたくさんある Rubyをいじっていてもそうだけど、慣れないものというのは、慣れないが故に、学ぶことがたくさんある。「
自分がプログラマになったときに、Webアプリケーション開発の独習で学びにくかったところをまとめる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。 確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。 この記事で扱う「Webアプリケーション開発
Pythonを退職します - Line 1: Error: Invalid Blog('by Esehara' )
Pythonが嫌いになったの? Pythonについて嫌気が差したとか、Pythonが嫌いになったわけではありません。これからも一番好きな言語は恐らくPythonですし、実際のところ、機会があればPythonは書こうと思います。ですので、決して言語としてPythonが嫌いになったわけではありません。 そもそも、職業プログラマとして、ちゃんとしたオブジェクト志向を教えてくれたのはPythonでした。Pythonは、その言語仕様からして、出来るだけ簡潔かつ、綺麗に書けるし、Pythonについて深く知れば、プログラミングとはどういうことなのかについて、詳しく知れるほどの、わかりやすい言語であることは事実ですし、初心者向け言語として、Pythonは強く押したいという気持ちは今も変わりませんし、ずっとPythonならびにそのコミュニティに関して感謝の気持ちはずっと忘れないでしょう。 また、近年ではPy
東亜飯店で飯を食べた - Line 1: Error: Invalid Blog('by Esehara' )
誕生日ということもあり、かねてから行きたかった東亜飯店で飯を食うことにした。 イベントを立てて、行きたい人を募り、実際に飯を食いに行った。 結論からすると、上の写真を撮らせてくれたし、中華屋としても美味しく、また値段も手頃であり、飲み食いしているときに、ちゃんとお皿を定期的に片付けてくれたりなど、変なチェーン居酒屋を利用するよりも、かなり良い店だった。そこらへんのレポートを書こうと思う。 東亜飯店は実在するの? 実在します。食べログにも、店情報がある。ここに書いてない情報としては、ランチは11:00～15:00の間、夜は18:00～22:30の間で開店していることが多いようだ。 で、この画像なんなの? 東亜飯店とは? と思う人もいるだろうから、東亜飯店がこれほどまでに有名になった経緯は、このエントリに詳しい。こちらにも念のため、画像を張り付けておく。 別にIT系(特にWeb系)でこの画像が
Webサービスのプログラミングに必要なことのだいたいは、スクレイピングに学んだ - Line 1: Error: Invalid Blog('by Esehara' )
この記事を読み始める前に Rubyでやるんだったら、ちょうどそういう本が出ているから、その本買えばいいのではないでしょうか。 Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例 作者: るびきち,佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2014/08/25メディア: 大型本この商品を含むブログ (1件) を見る はじめに プログラミングを勉強し始めて、だいたい基礎的な文法を覚えたあとに、次に何をしようかな、と悩む人も結構多いみたいで、明確に「これを作りたい」という場合は、それを作ればいいとは思うんですけど、場合によっては、別段作りたいものが無く、漠然としたプログラミングをしたい、という熱意によって勉強しているという人もいるのではないかと思います。 で、もちろん「作りたいものがないのに、プログラミング勉強してどうするの」という意見もあるかとは思いますが、往
バブルソートよりも非効率なソートアルゴリズムを探して ―― ストゥージソートとスローソート - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 恐らく、プログラマの中で配列内の要素を整列させたりするソートにお世話にならなかった人、というのは余り考えられないのではないでしょうか。しかし、とはいえ、大抵はソートを自前で実装せず、組み込み関数であったり、あるいは何らかのライブラリで済ませることが殆どだと思う。 車輪の再発明というよりも、バグとか、自分が考慮していなかった挙動などを避けるために、自前でソートを組むことは余りないのですが、とはいえ、自分なりにソートを実装して見ると、それがどういう特徴を持ったソートであるか、というのがわかりますし、また、ソートというのはいったいどういう操作で実現されるのかという洞察が深まってくるなあ、という実感があったりする。 なので、今回はあるソート二つについての話を書くのが趣旨です。 最高のアルゴリズムはある、だが最悪のアルゴリズムは何か 一口にソートといったところで、ソート自体にも銀の弾丸があ
迫り来る「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' )
ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。 元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュ
一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )
とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基本的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシを食う数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ
本を読むコツとしての「わからないところは飛ばす」 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 一時期、自分は一週間に三冊の本を消化することを目標にしていたことがあった。 もちろん、それで本の内容を理解したとはとても言いがたいとは思うし、今はほぼやっていない。しかしそういう多読スタイルを続けていると、不思議なことに、おぼろげながらに「型」というものが出来てくる。どのようなアプローチで本に取り組むべきなのか、ということがだいたいわかってくる気になる。 今回はその話をメモしておこうと思う。 追記 ちょっと誤解を生みやすいみたいなので、ここで補足します。 これから語られることは、どちらかというと「ちょっと難しい本を少しずつ砕きながら読む」という形なので、例えば小説であったり、簡単なエッセイとか、そういう本の読み方として期待するとちょっと違うという印象になるかもしれないです。 上のような記事を期待されたかたは、恐らくがっかりすると思うので、追記しました。 最初から全部理解してやろう
むしろ数式が苦手だけど統計を勉強したいという人はRをやるといいかもしれない - Line 1: Error: Invalid Blog('by Esehara' )
はじめに なぜか唐突にRブームが俺の中でやってきてしまってどうしようもないので、Rの本を注文しまくってたりしていたら、下のような本の山が出来てしまいました。 これらの本を付箋でペタペタしながら読み進めていくうちに、段々とRというのはどういう言語で、どういう風に勉強するといいのか、という方針が固まってきたので、ここにメモをしておきます。 Rとはどのような言語か 一言で、しかも乱暴に言ってしまうならば「統計に特化したPHP」というのが一番雰囲気を伝えられるかもしれない。いや、PHPの悪評は知っているし、ガチでRをやっている人にとっては嫌がられることもわかっているけど、あえてそういう説明が、あくまで入り口としてはわかりやすいのではないかと。 どういうことかというのを言い訳します。 自分が読んだ感じだと、統計というのは、「何らかのデータ」と「分析するためのツールとしての数式」と「その数式が意図する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
