スクリーンキャプチャやそれらを共有するツールはいろいろ出ては消えの状態で、どれを使うのがいいのかという話になると難しいかと思います。 スクリーンキャプチャを撮りたい状況には概ね3くらいあって 単純にファイルとして保存したい チームメンバーや友人等に共有したい（URL もしくはファイル送信） スライド作成時などで、スクリーンキャプチャをスライドに貼り付けたい こんな感じ。全部に応えるツールというのはなかなか難しいのだが、どれか1つずつに効くツールはあっても、コレに加えてスクリーンキャストまで面倒みてくれるものとなると中々難しい。 ということで僕はこんな感じで環境を作りました。 Monosnap + Amazon S3 + Fastly Monosnap というのはこのツール Monosnap Farminers Limitedグラフィック&デザイン無料 こいつ、何が優秀かというとこういうこと

今年も @mirakui と @sora_h と一緒に ISUCON5 に出場して、準優勝しました。 やったこと 時間は投入した時間。 12:00 : API リクエストを送る先の services が DB に入ってるけど大した数でもない(7つ)ので、全部アプリケーションにハードコードした。 これはのちにリクエストにプロキシを挟む時にコード変更だけでよくなったので地味に効いた。なお、これによる高速化はあんまりしなかった(そりゃそうだ)。 13:16 : API リクエストへのパラメータを保存している subscriptions の保管先を DB から Redis へ変更。 DB 問い合わせへの高速化というより、 JSON 形式から MessagePack 形式での保存になったことの方が重要な気がしてる ま、これも大した効果は出てない。 initialize でバグったら話にならないから、

NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま

1人でよいコードを書くのは、3人でよいコードを書くことの3倍難しい。悪いコードを書くときに説得する人間が 1/3 でよいので、つまり自分に向かって『まぁいいじゃん今回は』と言えば事が済む。続けているといつの間にか引き返せないところまできていて、適当に書いた個人プロジェクトは設計的破綻を起こし、コーディング規約もなにもあったもんじゃないという破滅が待っている。 ということで、1人でよいコードを書くために。今回は Rails プロダクトを1人で書くとして。 rubocop コーディング規約と、あまりに長すぎるメソッドやあまりに長いクラス定義などを見つけてくれる。全てに従うと厳しすぎて死ぬので、適宜各チェッカを無効にするのがよい。 僕はこんな感じの設定で使っている。 AllCops: Includes: - Rakefile - Gemfile - config.ru Excludes: - b

そういやまだ新しい経験だから覚えてるし、 golang を勉強していった過程を書いておく。 正しさとかは気にせず、動くものが出来るまでがむしゃらに。 Hello, world まで 特にひねりはない。 homebrew は便利だ。 $ brew install go $ cd ~ $ mkdir -p go/src/hello_world $ export GOPATH=${HOME}/go $ cd go/src/hello_world $ cat main.go package main import "fmt" func main() { fmt.Println("hello, world") } $ go run main.go hello, world 手軽。 入門、そして組み込みパッケージを使う http://golang.org/pkg/ に組み込みパッケージの一覧があるので

How to じゃなくて、何かの言語を学ぶ、もしくはあるパラダイムにチャレンジするとき、に僕がよく使うサンプルアプリケーションとして、ファイルアップローダというのがあり、それの仕様をまとめておこうと思い至っただけです。 ちょっと研修資料っぽい感じになっちゃったけど、まぁいいか。 アプリケーションの概要 非ログイン型のファイルアップローダです。ファイルの保持先は S3 や Disk 、 DB への Blob などいくつかの選択肢が提供されます。 HTTP のフォームからファイルがアップロードされ、リストで表示されるだけの簡単なアプリケーションです。 ファイルには有効期限があり、それを過ぎるとダウンロードできなくなる、かつリストにも表示されなくなります(保存先の実ファイルも削除されていることが望ましいです)。 また、ファイルにはプライベートモードがあります。プライベートモードのファイルはリスト

今日は Rails での『関連モデル』の名前について考える。 構造としてはこんな感じ。 ・ルーム(Room)に所属するユーザー(User) ・ルーム(Room)での管理者権限を持つユーザー(User) どちらの関連も N:N の関連。いわゆる has_may な感じ。 で、こういう時の命名って Room モデルと User モデルだから RoomUser とか UserRoom とかっていうモデルやテーブルを作りがちなのだけれど、今回は同様の形態の関連が2つあるのでちょっと微妙な事になりそう。 っていうか、まずもって RoomUser モデルってなんだよ。なんのモデルだよそれ。って感じなので名前を考える。 ルーム(Room)に所属するユーザー(User) 関連モデルのデータは大抵2つのフィールドを持っている。 Migration あたりから抜き出すと t.references :room

この辺見て、いつも思ってること。 プログラミングはアプリを作ることの手段なのか - 銀の人のメモ帳 プログラミングはそれ自体が目的であっていい - mizchi log プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 プログラミングは手段です。僕にとっては。 「動けばいいコード」は糞コードだ でしょうね。としか言い様がないです。 あえて例え話にして、プログラミングを車の運転だとします。プログラマは運転手です。 でまぁ、アプリを作るってのが伊豆の旅館に行くことだとしましょう。この時、僕の運転する目的は伊豆に行くことです。間違っても運転することは目的じゃないです。なので別に運転に特に気を使うことはありません。 そこに突然 F1 ドライバーがやってきて、『お前のカーブの曲がり方は下手くそだ』とか『もっといいルート選択がある』とか『こんな運転の仕方じゃガソリン代がもったいな

追記 まじで鳩さんのスライドでDCIについて理解したつもりになるの危険だからやめた方がいいです。せめて d.hatena.ne.jp/digitalsoul/20… を読みましょう。DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイムです— Naoto Takai (@takai) December 27, 2012 ということで、以下の内容はすべて間違いである可能性が高いです。 元記事 Data - Context - Interaction いわゆる DCI が最近の人気らしい。 DCI そのものの説明をこのエントリでする気はないので、 Sapporo Ruby Kaigi の角谷さんのプレゼンなどを見るとよい。 Rails の場合、 Data はまぁ ActiveRecord / Mongoid などのいわゆる MVC におけるモデル、であっていると思う。これに

ネタバレに相次ぐネタバレを行うエントリなので、ヱヴァンゲリオン Q を未視聴の方はお気をつけ下さい。 前回までのあらすじ 襲来する第10仕様書、他セクションから突如やって来た真希波・マリ・イラストリアスはスタンドプレーで応戦するものの、一度は敗北。裏コード(アセンブリ組み込み)による自滅的なコーディングを試みるもやはり敗北する。 綾波レイはその生命(クビ)を引きかけに仕様書に対する自爆(変更提案)を試みるも、直前で聞き入れられず、あえなく撃沈。動けなくなっていたところを仕様書に取り込まれてしまう。 その頃、脱走兵である碇シンジは自らの意思を持って現場に復帰。PM 碇ゲンドウへの直訴を果たし、見事戦線復帰を果たす。動かなくなった Windows XP 初号機は再起動により稼働開始。ありえないパフォーマンスにより、神が降りてきたかのようなコーディングを見せ、見事仕様書を打ち倒し、綾波レイを救い

働いてますか。労働はご褒美です。どうも、ロージーです。 案外放っておくとタスクがどんどん溜まったりするし、何よりプロジェクトの走り始めの時期とか、洗いだしたらすごい大量のタスクが山積みになって「うげげ」って気分になりますよね。 基本的にはエンジニア向けの話なのですが、まぁタスクを Trac で管理したり Redmine で管理したりすると、基本的にマイルストーンとプライオリティぐらいしか「なにからやるべきか」という指標にならなくて、どうしたものか悩んでしまいます。 その日の朝に棚卸して選定すべきなんですが、まぁそういうときに使う、こんな評価軸もあるんだよ、ということで、僕自身の備忘録です。 1. 4つの『空気感』 まず、タスクを積んだ時点、いわば「これやらなきゃな」とした時点での、そのタスクに対する自分の空気感をラベル分けします。 カンタン フツウ ムズカシイ ダルイ 上の4つです。カンタ

こんにちは、20時から予定がありました。遅刻しそうです。 さて、ということでさっくり話をすると、「ペアプロってやったことないな」ってところからスタートです。 ペアプロするのって難しい 難しいんです。何が難しいって、相手が居ない。居ないんですよ相手が。家庭内ペアプロとかやってる夫婦を1組知ってますが、そんなん普通ねーよ。アホか。 そして会社でペアプロするのは違うんです。違う、そうじゃない。会社でペアプロするのはいい。いいんだ。でも俺は趣味のコードとかを友達ときゃっきゃうふふしながら書きたい。 だからペアプロするのは難しい。勉強会にいって「どうもーはじめましてロージーですー」と自己紹介してその直後に「ということでペアプロしませんか？」とでも聞いたらその場で Twitter に勉強会にホモがいるとか言われて ID 晒されて大炎上ですよ。リスキーすぎる。 ということで簡単に、とりあえず俺は友達とペ

こんばんは！暑い！ ということで今日はgitのすごく便利なエイリアスを作りました。 Git-助けて https://github.com/rosylilly/git-tasukete という、超便利コマンド集です。 使い方はホームディレクトリあたりにクローンしてきて、パスを通しておくだけです。 するとあら不思議、ターミナルに $ git 助けて と打つだけで、助かりたい時の場合がリストで出てきます。 後はそのうち、目的の状況のモノをターミナルにコピペするだけです。ほらね $ git mergeを取り消したい はい、マージが取り消せました。よかったよかったー！ こんな困った場合にも対応してください！というのはGitHubのissueか、コメント欄にて受け付けてます！

白金動物園は ISUCON 9 本選において優勝しました。言葉になりません https://t.co/Zhy9tzsA2M— Issei Naruta (@mirakui) October 5, 2019 感無量です。 やったことは GitHub 上ですべて公開されています。 github.com いつものことですが、メンバーが何をしていたのか細かいことまでは知りません。 自分の記憶 [10:23:27] 862fe59 : Fix initialize MySQL file MySQL のイニシャライズ実行ファイルのユーザーを root に変更。各位の手元で動かすときに楽させるため。 メンバーの手元の MySQL がどういう設定になっているのかは大体知ってるし。 [10:27:33] 2c68bf1 : Change database user 同上事情。こちらはアプリ側。 [10:40