プログラマという職業は「ふつう」の人には厳しくないか - ukstudio
最近、実はプログラマという職業が「ふつう」の人には厳しいなーと思っていたりする。 業務外にコードを書いたり、技術書などを読むというのは素晴らしいことだと思う。けど、会社側がもし「業務時間外にコードを書いたり、技術書を読んだり、勉強会に参加しなさい」と言ったら、それは業務時間外労働と変わらないと思う。個人のたのしみとは別に会社側がそれらを求めたらそれは業務だ。 しかし、僕が思うにはそういう業務時間外に自主的に勉強をしないと、正直いってまともな品質なソフトウェアを作るのは難しい。 例えば良書と言われているものは結構な数あり、ある程度経験がありそれらの本を読んだことがある人は「プログラマならこの本は読んでおくべき」という本をいくつかあげたりもするだろう。けど、それらをいつ読むのか。業務時間内にそれらをじっくり読んだり、実際にコードを書いたりする時間があるところはないだろう。そうなると自分のプライ
UK STUDIO - ついったーBOT作者にお願いしたいこと
最近、行儀がわるいというか、ハッキリ言ってしまうと「鬱陶しいBOT」が増えた(前からかもだけど)気がするので個人的にBOTを作るときに気をつけてもらいたいことを書いておく。 言及に気を配って ついったーの仕様上、いつからかは知らないけど発言内容に「@自分のID」が含まれていると言及されたということでReplyに流れてくる。 それはまぁいいんだけど、BOTが必要以上にIDを含めているとそれだけでReplyがうまってしまう。特に「○○なう系BOT」がひどい。山手線とか色々あるけど渋谷なうBOTがひどい。 なにがひどいって一度「渋谷なう」と言ったら補足されて大体24時間ぐらいはそのBOTの発言に自分のIDが含まれて、誰かが「渋谷なう」と言う度に自分のReplyに流れてくる。そんな情報は求めていない。せめて@をはずしてほしい。 それと同じような理由で延々と特定のキーワードに対してReTweetする
RubyでDuckTyping
今日、知人に「DuckTypingのメリットが今一ピンとこない」と言われて実際にコード書いて説明をしたのだけれども、せっかくなのでエントリにまとめる。 DuckTypingとは、動的言語の柔軟性を表現する概念で以下の格言に由来する。 "If it walks like a duck and quacks like a duck, it must be a duck" （もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである） つまり、アヒルのように振る舞うものは、実際にそれが何であろうとアヒルと見なすということになる。 もうちょっと言語よりな言い方をするのであれば、あるオブジェクトどのクラスに属するか考慮せず、どのようなインターフェースを持つかに注目するのがDuckTyping。 DuckTypingにおいて重要なことは「明示的な型チェックを避ける」と言うことで、どう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
