はてなブックマーク

2018-11-22 を最終出社日としてクックパッド株式会社を退職しました。 アルバイトを含めると、2015-04-16 入社なので、3年9ヶ月ほどいたことになります。 ひとつの節目ということで退職エントリを書いておこうと思います。 在籍中にやったこと 大きく分けると以下の2つです。 クックパッド料理教室の開発 決済基盤の開発・運用 クックパッド料理教室の開発 クックパッド料理教室というサービスをつくっていました。*1 時期によって増減するんですが、だいたいエンジニアが5人くらい、デザイナー・ディレクター・サポート・マーケティング・営業などの人たちを含めて20人くらいのチームでした。 この時期には、技術的なことだけでなく《サービスをつくる》ということについて、めちゃくちゃ多くのことを学ばせてもらいました。 間違いなく、この時の経験が s-dev talks を立ち上げるモチベーションになっ

表題の通り。 Rails でよくある class HogesController < ApplicationController before_action :set_hoge, only: %i[show] def show end private def set_hoge @hoge = Hoge.find(params[:id]) end end みたいなのっているの？ という話。 set_* がつらい理由 暗黙的に副作用があることが行なわれている インスタンス変数の初期化と代入という重大な副作用がしれっと暗黙的に行なわれている。 暗黙的な順序依存性が発生しがち はじめはシンプルに before_action :set_hoge とかしていても、機能追加などをしていくうちに before_action :set_hoge before_action :set_fuga before_

Cookpad TechConf 2018 の突発 LT で話した内容をもう少しちゃんと書いてみます。 アドホックなタスクの必要性 日々、サービスを運用しているとアドホックなデータの変更や処理の再実行などが必要になります。 典型的には以下のようなケースです。 データマイグレーション サポート対応 不具合対応 その他もろもろ ここではこのようなアドホックなタスクを oneshot task と呼ぶことにします。 oneshot task をスクリプトとして書く oneshot task をスクリプトとして書くといくつかのメリットが得られます。 似たようなことをする方法はいくつかありますが、それらの方法と比べたときの主なメリットは次のようなものです。 vs. 管理画面 管理画面をポチポチすれば対応できるものによっても場合によってはスクリプトを書く価値があります。 大量のデータを処理する必要があ

スピードとスピード感は違うし、素早くつくることと雑につくることも違う。 我々の仕事がコードを書くことではなく問題を解決することである以上、どんなに素早くつくるとしても誰のどんな問題を解決するのかは常に意識していなければならない。 その点について深く考えずに思いつきで「A すれば B できるようになる」というものをつくるのは素早いのではなく雑なものづくりだと思っている。 そもそも「〜できる」ということにはあまり価値がないと思っていて、「〜するようになる」「〜してしまうようになる」というように行動が変わるところまで意識的に持っていかなければならないと考えている。 *1 面と向かって他者の行動を変えるのだってめちゃくちゃ大変なのに、インターネット越しに画面だけでユーザーの行動を変えるということがそんなに簡単にできるはずがない。 だから、画面の向こうにいる人に対して何かしらのアクションを引き起こさ

タイトルの通りで、 Growing Rails Applications in Practiceを読みました。 Fat controllerやFat modelに代表されるように、少し気を抜くとカオスになりがちなRailsアプリケーションの整理方法についての本です。 表紙とか目次も含めてPDFで88ページしかなくて比較的読みやすかったです。*1 全体的な構成 章立ては次のようになっています。 Introduction Beautiful controllers Relearning ActiveRecord User interactions without a database Dealing with fat models A home for interaction-specific code Extracting service objects Organizing large c

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

Rubyで一様な乱数が欲しければRandomやSecureRandomを使えば良いと思うのですが、「偏った乱数」が欲しいこともあると思います。 イメージとしてはゲームのパラメータとかですかね。 例えば、あるダンジョンで出てくる敵のレベルを20-30の間でランダムに決めたいときに、全てのレベルの敵が均等に出てくるとちょっと困ると思います。ここでやりたいことは 基本的にはLv25くらいの敵が出現 たまにLv20やLv30の敵も出して緩急をつける みたいな感じです。 ゲームに限らず、「ある程度まとまっている一方で適度に散っている数字」が欲しいケースは結構あると思うので、そういったときに使えるgemを作ってみました。 方針 今までは得た乱数のべき乗をとったりして重みを付けていた。 得られる乱数の分布が砲弾型になって美しくない。 どういう分布が良いんだ？ 釣り鐘型が良いと思う。 それって正規分布じゃ

問題 Local require 'net/ftp' ftp = Net::FTP.new("example.com") ftp.login("username", "password") ftp.list # => Array[String] 期待通りに動きます。 EC2 require 'net/ftp' ftp = Net::FTP.new("example.com") ftp.login("username", "password") ftp.list # => Errno::EPIPE: Broken pipe このコードは正常に動作せず、例外を投げます。 Note: PASVモード require 'net/ftp' ftp = Net::FTP.new("exmample.com") ftp.passive = true # Use passive mode ftp.logi

DBに制約を張る このようなテーブルがあったとします。 CREATE TABLE products( id serial NOT NULL, code varchar NOT NULL, price integer NOT NULL CHECK (price > 0), CONSTRAINT pk_products PRIMARY KEY (id) ); 各カラムにNOT NULL制約 priceにCHECK制約 という2点を除けば、rails g migrationで作られるものと同じだと思います。 このテーブルにおいて、 ActiveRecord::Base.transaction do CSV.foreach(csv_path) do |row| code, price = row[0], row[1] Product.create!(code: code, price: price

やりたいこと 分母に0が来る可能性がある除算をRubyで書くときに、すっきり書きたい。 考えるケース 店（Shop）がそれぞれ複数の在庫（Stock）を持っているシンプルなケースを考える。イメージとしては下のような感じ。 class Shop has_many :stocks end class Stock attr_accessor :price end このケースで店舗にある在庫の平均価格を求めるメソッドShop#average_priceを定義する。ただし、在庫が1つもないときは0を返す。*1 1. 素直に書いてみる class Shop def average_price stocks.size > 0 ? stocks.map(&:price).reduce(0, :+) / stocks.size : 0 end end 世の中の多くのコードはこのパターンで書かれている気がする

発端 以前から iTunes に不満があったが、Music.app になってからいよいよ耐え難くなってきたので Music.app を捨てたくなった。 不満な点はいくつかあるけど、大きいところは以下の2つ。 検索が使いにくくなった iTunes Store や Apple Music を使わせようという意図が強すぎて鬱陶しい 検索結果をランダム再生できなくなった iTunes Store の多言語対応が良い感じに動いてくれない OS の言語設定がに複数言語を指定していると、どちらか一方を優先する En を第一言語にすると一部邦楽が英題・ローマ字表記になる（「天体観測」→「Tenntaikansoku」） Ja を第一言語にすると一部洋楽がカタカナ表記になる（「Queen」→「クイーン」） 原語表記してほしい 自分は何が欲しいのか iTunes/Music.app への不満を裏返すような形に

GmailのAPIに関する情報がほとんどなかったので、ざくっと書き残しておきます。 前提条件 access_tokenは取得している 公式クライアント（google/google-api-ruby-client · GitHub）を使う サンプルコード require "google/api_client" # メッセージの準備 message = Mail.new message.to = "example@example.com" message.subject = "こんにちは、Gmail! " # UTF-8使えます。 message.body = "Create draft via Gmail API. テストですよ、テスト。" # APIクライアントの準備 client = Google::APIClient.new(application_name: "app_name")

きっかけ こんなツイートがRTで流れてきた。 Java技術者です、って求職してきた人にする質問の一問目は 「なぜフィールドはprivateにしてgetter/setterプロパティを書くべきなのだと思いますか？」 がいいのではないかと思い始めた。— ゆば大好き (@yuba) 2014, 9月 26 そのとき思ったこと 「変数をプライベートにして、それに対してアクセサを定義する」っていうのはちょっと違う気がする。— S.Osa (@osa522) 2014, 9月 26 「外部に公開するインターフェイスを決定して、そのために必要な変数をプライベートで保持する」っていう感じ。— S.Osa (@osa522) 2014, 9月 26 変数ありきなのではなく、インターフェイスありき。 インスタンスが持っている変数は実装の詳細であって、そのインスタンスのメソッドを呼び出す側からするとどうでも良い

SlackとSkypeを比較してみます。 HipChatやChatWorkじゃなく、Skypeとの比較です。 一応、それぞれの公式サイトを貼っておきます。 Slack: Be less busy Skype | お友達やご家族への無料通話 比較項目一覧 料金 広告 ルーム メンション ファイル送信 検索 日本語メニュー ネイティブアプリ 他サービス連携 アーキテクチャ 通話 これから、これらの項目について見ていきます。 料金 Slack 無料から。 ただし、無料のプランだと検索できるメッセージが直近10000メッセージに限られるなどの制約がある。 有料プランは$6.67/user/monthから。 Skype 基本的に無料。 広告 Slack なし。 無料プランでも広告は表示されない。 Skype あり。 一部の広告は閉じることができるが、しばらくすると復活する。 表示領域を削ってくるので

クックパッド 5-day インターンシップ こんなんです。 動機 主な動機は2つありました。 1. cookpad覗いてみたい 普段、主にRubyを書いている人間からするとクックパッドは非常に気になる企業の一つなので、選考過程だけでも覗いてみたいという感じでした。 受かるとは思ってませんでした。 2. もし受かったらRailsのコードレビューとかしてくれるかも？ 募集要項に スマホアプリ開発 チームで開発 言語不問 と書かれていたので、もし受かった場合にはネイティブアプリを別の人にお願いして、自分はサーバサイドをRailsで書くつもりでいました。 そして、そのコードをレビューしてもらったりベストプラクティス知れたりしたらいいな、みたいな。 あと、r7kamuraさんにお会いしてみたかった。 選考を通ってから 中の人「1チームは技術職1人+総合職1人です」 俺「……( ﾟдﾟ)」 自分でネイ

問題 RubyでUTF-8からWindows-31J（Shift_JIS）に文字コードを変換すると、正常に変換できそうであるにもかかわらず、実際には変換が行えず例外が投げられる文字があります。 "\u{301C}" # => "〜" "\u{301C}".encode(Encoding::Windows_31J) # => Encoding::UndefinedConversionError: U+301C from UTF-8 to Windows-31J 原因 原因については UTF-8 → cp932(Shift_JIS)変換表 - fudist あたりがわかりやすいです。 例外が投げられる文字はたとえば以下の様なものがあります。*1 文字コード（UTF-8） 文字 備考 U+00A2 ¢ セント記号（通貨） U+00A3 £ ポンド記号（通貨） U+00AC ¬ NOT記号 U+2

作ったもの JANコードを便利に扱うためのgemを作りました。 JANコードっていうのはバーコードに使われているこんなやつです。 国際的にはEANコードと呼ばれていたりします。 JANコードとは│JANコード登録│ 一般財団法人流通システム開発センター ean | RubyGems.org | your community gem host は既に存在しているんですが、イマイチな感じだったので自分で作りました。 インストール s-osa/jan · GitHub に置いてあります。 いつも通り、 gem 'jan' $ bundle か $ gem install jan してください。 使い方 基本 JANコードが正しいかチェックします。*1 jan = Jan.new("4901277241126") jan.valid? # => true Jan::Validator.valida

はじめに このエントリは僕の平凡な考えを淡々と書いたものです。過度な期待はしないでください。 あと、部屋は明るくしてディスプレイから30センチは離れて見やがってください。 物理削除したくない！ 外部キー制約を張っていない場合 削除したレコードを参照しているレコードがエラーを吐く 外部キー制約を張っている場合 参照されているレコードは削除できない カスケードで削除すると影響範囲が大きい レコードがあったという事実は記録しておきたい 事実は消えない 論理削除もしたくない！ 削除するときにdeletedフラグなどを立てる あらゆるクエリにWHERE deteled = falseとか入ってきて汚い 物事は「削除」されるのではない 注文は削除されるのではなくキャンセルされる 従業員は削除されるのではなく解雇される じゃあ、どうするの？ 大雑把に書いてきましたが、このあたりのことが データの削除は非

DB設計についてググっていると、「サロゲートキーは使うべきではない」や「複合キーは使うべきではない」といったDBのキーに関する論争をよく見かけます。 それらを見ていると、多くの議論で「これって対比の軸がズレてないか？」と思いました。 正しい対比 正しいと思う対比とそのざくっとした意味。 自然キー vs 代替キー 自然キー（Natural key） キーそのものに意味が含まれているキー。 都道府県を含むテーブルprefecturesがあったとして、都道府県名prefectures.nameは自然キー。 代替キー（Surrogate key）*1 キーそのものには意味が含まれていないキー。 前述のprefecturesの例で言えば、システム内部のみで使用されている都道府県コードprefectures.codeは代替キー。*2 単一キー vs 複合キー 単純キー（Simple key） 単一のカ

PostgreSQLを使ったわりと大きめのデータベースを設計することになったので、ER図を作成するツールについて調べました。 自分のために調べたことのメモなので「MySQLは？」とか訊かれても基本的にわかりません。 対象とするツール GUI Database Design Tools - PostgreSQL wiki 上記サイトで挙げられている17種類のツールを対象に比較を行います。 *1 条件 以下の観点で評価します。 必須要件 無料版がある Windows/Mac版が両方ある*2 PostgreSQLにフォワードエンジニアリング（SQLを生成）できる 欲しい機能 リバースエンジニアリング（SQLからERを生成） 他のツール（Eclipseとか）に依存しない テーブルやカラム、インデックスにコメントをつけられる それらのコメントにマルチバイト文字が使える PDF、PNGへ書き出すことが