そんな職場さっさと逃げ出せ 外国人実習生のほうが相対的にマシなレベル

糸井 ヨシタケさんの絵本に、おじいちゃんが 死後の世界を創造するものがあるじゃないですか。 ヨシタケ 『このあとどうしちゃおう』ですね。 おじいちゃんが死んだあと、 天国がどうあってほしいかを書いた ノートが出てきた、っていう話。 糸井 さきほど抽象画が描けないという話がありましたけど、 この本も、ふんわりした天国のイメージが 出るかと思ったら、 まったく抽象じゃないですよね。 天国をぜんぶ具体物に小分けして、 神様もひとりずつ相談員になってて。 ヨシタケ まさにそうで、ぼくに 「極楽浄土！」みたいな絵は描けないんですよ。 そういうぼくが 「じゃあ、どういうことならできるんだ？」 とやってみた新しい逃げ道がこの本なんですね。 糸井 そうだ。そのとおりですね。 ヨシタケ 最終的に「ちょっとほかにない絵本だね」と 言っていただけてるのは、 王道を歩めてないからなんです。 糸井 ヨシタケさんの本

Rubyにおける良いスタイルとして、ブロック付きメソッドでリソースを自動管理するという手法がある。 この安全性を破壊してみよう。 前提知識 まず、確認として次を見てみよう。 1行目で開いたFileオブジェクトfは3行目で自動的にcloseされる。ブロック中の制御フローが多少複雑でも、例外が発生しても確実に3行目でcloseされる。 最近では他の様々なメジャーな言語が独特の構文で似た機能を提供しているから、10年前とは異なり特にRubyの目立つ機能というわけでもなくなったが、とにかくブロックによるリソース管理は良いものだ。 しかし、安全は不自由でもある。ブロック終了時点で確実にファイルを閉じてしまうため、File.openを呼んだメソッドが終了したあとでf.readを呼ぶことはできない。 def open_file(name) File.open(name) {|f| return f }

サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして

ツイートに位置情報を追加する 位置情報と一緒にツイートした場合、Twitterはその位置情報も保存します。 毎回ツイートする際に、位置情報を付加する/付加しないを選択することができ、いつでも過去の位置情報を全て削除することも可能です。 詳細はこちら

Roppongi.rb #3 Rails x Frontend-Tech

先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ