日報: とある企業に面接に行ってきた(1) - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 転職しようとする人のモノマネです 本文 シリーズもののように、連番は付けているが、これが続くかどうかはわからないが、感触からすれば続くだろうなと思ったので連番にしようと思った。 一般的に、最近の企業ならば、面接者にコードを書かせるかと思われる。とある企業では、事前に聞いていたテストだったので、ここで種あかしするのは野暮であり、と同時に一部には「とある企業」の「とある」が分かってしまうので、曖昧にぼかすのだけれども、基本的に自分はREPLに甘やかされていて、それで通らないコードを提出してしまった。 なので、今からでもいいから「そのソース書きなおさせろ」と殴りこみをかけたいものだが、良識を分きまえているつもりなので、それは知なかったが、動かないコードが、あとから動かないと気がついて、面接会場から出るというのは、本当に恥かしい経験で、穴があったら入りたいどころか、穴二つ分作りたい気分
日報: 治安の悪い「オッ」界隈について - Line 1: Error: Invalid Blog('by Esehara' )
「オッ」界隈とは何か 「オッ」界隈とは、簡単に言ってしまうならば、Twitter上で、何らかの発言や記事に対して「オッ」とだけ返す界隈が存在していることを指している。例えば、「お腹すいたな」という発言をすると、「オッ」とだけリプライが返ってくる、そういう界隈である。 本来ならば、そういう発言に関しては、お気に入りに入れてほんわかと見守るのが、インターネット上のマナーとなるわけだが、「いいね」とすることが、どちらかと言えば消極的な返事に対し、「オッ」と返すことは積極性を反映し、興味関心が非常に強いということを相手に伝え、繋がりが薄いと言われている現代社会に強い絆を作りだすと同時に「お前を見ている」というビックブラザー効果が期待できるということらしい。 上が、そのようなビックブラザー性を象徴する「オッ」界隈の画像である。 要するに「オッ」と言われたら「オッ」と返ってくるようなインターネット、こ
日報: 「0点を50点にする人」と「50点を100点に近づけていく人」 - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 プロトタイプとプロダクトの違いを視覚化したものです 雑談 今現在、プログラミングのリハビリもかねて、自分のできる範囲で知人のプロダクトを手伝っている。進捗的にはそこそこ理想的な進捗になっている。これはVue.jsのおかげであるのが殆どで、たぶん、普通にjQueryでスクラッチで書いたら、今の工数の5倍はかかっていたと思う。それだけ、UI周りの挙動をライブラリに丸投げできることは、とてもいいことである。そのあたりについては、過去のエントリに書いたので参考にしてもらえれば、と思う。 「日報」という題名が付いているときは、大抵は証拠の無いことを、自分が思ったままに書くエントリということになるんだけど、今回もそういったエントリになる。最近ちょっと思ったのは、いわゆるWeb系エンジニアと呼ばれる人達には、プロトタイプを作るのが得意な人と、プロダクトとしてリリースするのに品質を上げていくの
お金の総体が変わらない市場でやりとりしたら、貧富の差が生まれるか? - Line 1: Error: Invalid Blog('by Esehara' )
今日の風景 貧乏人に再分配された(半額になった)寿司の風景です はじめに 『ベットルームで群論を』という、みすず書房から出ている本の中に、「富が一定である閉鎖的なマーケットの中で、平等に富を持ったプレイヤーに対し、ランダムに得する人と損する人を決めていき、ある一定のステップを踏んだ結果、少数の金持ちと、多数の貧民の格差に分かれることになる」という話を載せていた。 この話に興味を持ったので、実際に、そういうモデルを作って、実際に閉鎖的なマーケットで各種のプレイヤーが損と得を繰り返していった結果、貧富の差が生まれるかどうかを実際に簡単なコードでシミュレーションしたいと思う。当然、このモデルは、実際の経済市場とは乖離したものであることは認めざるを得ないが、極端なモデルにも、何らかの示唆は、多分あると思う。 ルール とはいえ、ざっくりとこのようなことを書いたとして、そもそものルールが如何なるものか
運気を上げるために魔方陣を作る(初級編) - Line 1: Error: Invalid Blog('by Esehara' )
今日の寿司 中身が気になる御歳頃。 はじめに 最近運気が悪く、悪夢も良くみるようになったので、これは邪気を払う必要がある。なので、そういうのに使えそうなものと言えば何か考えたら、魔方陣ではないか、ということを考えていた。 昔の夢は何だったか思い出すと、科学者か魔法使いになりたかった思い出があり、極まったプログラマというのはWizardと呼ばれる。さすがに、自分がそのレベルに達しているとは思えないが、どうせだし、魔法陣くらいは作れるようになりたいと思ったので、今回のエントリを書く。以下、『魔方陣の世界』という参考書(エントリの最後に記述する)を元に書く。 魔方陣とはなにか とはいえ、魔方陣とは何かについて、最初に書いておかないといけない。魔方陣とは、1から始まる連続した異なる自然数を碁盤の目状に並べて、それぞれの列、それぞれの行、そして対角線の数の和が一緒であるものを指す。具体的には、下のよ
『オープン・デザイン』は、むしろプログラマが読むべき本だった - Line 1: Error: Invalid Blog('by Esehara' )
今日の十六茶 試してガッテン方式で入れている。 はじめに オライリー社から2013年に発売された『オープン・デザイン』という本は、率直に言ってしまえば、如何にもデザイナー向けの思弁的な議論のアンソロジーとなっている。それらは、直接的には技術的な洞察を与えるものではないだろうし、また同様に、それが直接的に業務に使えるものかといったらそうでもない。 そうではないのにも関わらず、この本は、プログラマにとって重要な本であることは間違いないと、僕は確信している。逆説的なことではあるが、この本が技術書でないからこそ、あまりにも無視され続けた本であると思うのだが、だからこそ、今読むべき本であると思う。 プログラマはデザインが下手であるという現実を直視する もちろん、デザインという言葉は多義的な言葉であることは間違いない。まず指摘できることは、日本語の場合、デザインという言葉は「設計」という言葉ではなく、
出社準備完了 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 21世紀になっても、まだ人類の課題として残されているのは、「出社」という概念だろう。IT業界だと、リモートワークも増えつつあるけれども、やはりまだ出社に縛られているというのが現状といったところだろう。 たいてい、出社のアンチパターンは二つあって、「そもそも朝起きられないから遅刻するパターン」と、「朝起きられるのだけれども、出社までに精神のブートが間に合わずに、遅刻するパターン」がある。このようなことを書いている僕は後者のパターンである。そこで、これの改善策に「出社へのモチベーションを高める」というのがあるというのに気がついた。出社へのモチベーションを高めるには、出社したくなるようなことをすればいい。そこで、「出社準備完了」の準備をするという方法を取ることにした。 出社準備完了の歴史 その前に、出社準備完了の歴史みたいなのを書いておかないといけない。 元々「出社準備完了」とは、to
プログラムにおける「関数」とは何かについて、自分なりのまとめ - Line 1: Error: Invalid Blog('by Esehara' )
近況 自宅サーバーが起動しなくなったため、中身に保管してある電子書籍のPDFが取り出せず、大量の知性が失われている。 要旨 以前に「関数型プログラミングの初心者」に向けて質問したときに、そもそも関数とはなにかについてわからなかったという質問があった。自分も、具体的に関数とはなにか、というと説明に困ることがある。そこで、今回のブログでは「関数」とは何かについて、自分なりにまとめたことを書く。 はじめに 知り合いの技術者は、「実は関数の考え方について、一年間くらい馴染めなかった」と言っていた。現在では、開発をバリバリやっているような人であり、自分も尊敬しているのだけれど、そういう人でも「関数」という考え方について、実はそれほど馴染めなかったということを聞いてビックリしたりしていた。 とはいえ、そういう風に「そうなのか」と納得している俺も、実際のところ、では「関数」とは何か、というのを説明できる
今日のポエム: なぜ、その抽象化は失敗してしまうのか - Line 1: Error: Invalid Blog('by Esehara' )
近況 打ち捨てられた過去について 要旨 この記事を興味深く読む一方で、やはり違和感を覚える人も多くいるようで、自分もその一人だった。恐らく、この違和感は、「抽象化」が「具体性を奪取していくもの」といったような対立項として述べられているからだ、というように思われる。しかし、果たして具体性無しに「抽象化」することが有益なことなのだろうか。それが一つの違和感のように思われる。 本文 プログラミングの世界には、YAGNI原則(You ain't gonna need it)というものがある。また、YAGNIという言葉を使わなくても、「過度な汎用化が足を引っ張る失敗例」というのは、プログラマとしての心構えを書いた本の中で、ちらほらと自嘲気味に述べられることがある。 僕も、一度そのような失敗例を見たことがあるけれど、なぜこういう失敗が起こるのか。確かにデザインパターンで組み立てられたアーキテクチャは「
ポモドーロ・テクニックを二ヶ月やってみた感想 - Line 1: Error: Invalid Blog('by Esehara' )
二ヶ月間ポモドーロテクニックをやってみての雑感 だいぶ知見が溜まってきたので、セーブがてら記事にしておく。 方法 要するに 25分、集中してそのタスクをやったら5分休む = 1Pomodoro 4Pomodoroやったら15分休む というのを繰り返すというだけだ。 実際の運用 確かにもう少し厳密なフローとしては、例えばTodoリストを作成したり、それに対しての見積もりをする、という方法もあるのだけど、自分はそういう網羅的なToDoを作成するのが苦手だったりする(むしろ作業中にどんどんToDoを積み上げていくという方法)のほうが好きだったりするので、そういう風にしている(最初から完璧にやろうとすると絶対無理なので)。 意外とやってみてよかったというのは、集中できたときのアクティビティを記録しておくという方法だ。要するに何時にポモドーロテクニックを集中できてやれたのか、というのを一つずつ記録し
『マンガでわかる！関数型プログラミング』という漫画を連載することになるようです - Line 1: Error: Invalid Blog('by Esehara' )
近況 ふとした瞬間に虚しくなることがある いきさつ 今年、秀和システムから関数型プログラミングに関する本が出て、良くも悪くも、その本が注目を集めることになってしまいました。そんな中で色々な人が反応していましたし、自分もこのようなかたちで感想を書きました。 一方で、このような本を書かれるくらいであるならば、自分で真っ当な本を書けばいいわけだし、技術書を書くことなんて、そんな敷居の高いことではないというカウンターもあり、個人的にはそれも最もだなあ、という印象がありました。その中で自分なりに関数型プログラミングについて理解したことを元にQiitaに駄文をアップしたりしていました。間違ってたら、誰かが訂正してくれるだろうし、そのほうが自分にとって勉強になるだろう、と思うので。 ですが、「関数型プログラミング」というのは「なんだか難しい」という印象を覚えるのも事実のようです。実際に、最新の『Soft
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - 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' )
はじめに 現在、自分は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
Webサービスのプログラミングに必要なことのだいたいは、スクレイピングに学んだ - Line 1: Error: Invalid Blog('by Esehara' )
この記事を読み始める前に Rubyでやるんだったら、ちょうどそういう本が出ているから、その本買えばいいのではないでしょうか。 Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例 作者: るびきち,佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2014/08/25メディア: 大型本この商品を含むブログ (1件) を見る はじめに プログラミングを勉強し始めて、だいたい基礎的な文法を覚えたあとに、次に何をしようかな、と悩む人も結構多いみたいで、明確に「これを作りたい」という場合は、それを作ればいいとは思うんですけど、場合によっては、別段作りたいものが無く、漠然としたプログラミングをしたい、という熱意によって勉強しているという人もいるのではないかと思います。 で、もちろん「作りたいものがないのに、プログラミング勉強してどうするの」という意見もあるかとは思いますが、往
バブルソートよりも非効率なソートアルゴリズムを探して ―― ストゥージソートとスローソート - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 恐らく、プログラマの中で配列内の要素を整列させたりするソートにお世話にならなかった人、というのは余り考えられないのではないでしょうか。しかし、とはいえ、大抵はソートを自前で実装せず、組み込み関数であったり、あるいは何らかのライブラリで済ませることが殆どだと思う。 車輪の再発明というよりも、バグとか、自分が考慮していなかった挙動などを避けるために、自前でソートを組むことは余りないのですが、とはいえ、自分なりにソートを実装して見ると、それがどういう特徴を持ったソートであるか、というのがわかりますし、また、ソートというのはいったいどういう操作で実現されるのかという洞察が深まってくるなあ、という実感があったりする。 なので、今回はあるソート二つについての話を書くのが趣旨です。 最高のアルゴリズムはある、だが最悪のアルゴリズムは何か 一口にソートといったところで、ソート自体にも銀の弾丸があ
スタートアップで働くプログラマが、非プログラマの皆さんにお願いしたいこと - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。 たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあとい
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
