雨穴：Kさん、お久しぶりです。お時間とっていただいてありがとうございます。 Kさん：いえいえ、雨穴さん。ところで送ってもらった間取り図のことですが… 雨穴：はい。一階に謎の空間があるんですが、これについて何かわかりますか？ Kさん：うーん…一つ言えるのは、これが意図的に作られたものだということですね。 雨穴：意図的に…ですか？ Kさん：この空間は本来必要のない二枚の壁によって作られているんです。 Kさん：台所に接した二枚の壁。これがなければ「謎の空間」は生まれないし、台所も広くなります。 雨穴：なるほど。なぜ作ったんでしょうか？ Kさん：もしかして、最初はここを収納スペースかなにかにする予定だったんじゃないですかね？ Kさん：たとえばリビング側に扉を作ればクローゼットとして使えるし、台所側に作れば食器棚になる。 だけど途中で気が変わったか、費用が足りなくなったかで扉を取り付ける前に断念した

はじめに2020年10月11日「はてな匿名ダイアリー」に「音楽情報の共有サービスを作ったので使ってみてほしい」という記事を投稿しました。このnoteの記事は、その増田を読了した人に向けて書いています。 まず、匿名ダイアリーに投稿したことに対しトラバやブコメで「noteでやれ」「増田よりnoteに同じ内容を載せた方がいいかもしれない 今はnoteだったら片っ端から検索で引っかかるから…」と指摘を受け、急ぎnoteを作成しました。 たくさんのコメントがもらえて本当に嬉しくて、それらへの反応を追記トラバで綴っていこうとしたのですが「これはタイトルに[PR]ってつけなくてもええの？」「増田で宣伝すんな」「宣伝を増田でするのは戦略としてアリだと思うけどあんまり広まると嫌だな」などのブコメのように「はてな匿名ダイアリー」というスペースをこのように一定の便益が期待できる形で利用することを不快に思う方がい

一押しiOSウィジェット：NASAの｢今日の一枚｣を写すヤツ2020.10.11 20:0010,966 ヤマダユウス型 すこし宇宙が身近になる。 iOS 14のリリースから数週間が経ちましたが、いまだにウィジェットを使う理由がわかりません。でも、アプリ開発者のMark Hamblyは、NASAの天体写真を表示するという極めてシンプルなウィジェットを開発したことで、私の貴重なホーム画面の一部を占有することに成功しています。 無料の｢APOD Astronomy Pics and Widget｣アプリ（いまのところ広告も含まれていない）は、iOS14に対応したiPhone、iPadで入手可能。ユーザーはこのウィジェットを2×2、4×4、2×4の3つのサイズで配置することができます。このアプリができることはシンプルで、毎日自動で現在のAstronomy Picture of the Day（毎

2020年8月26日（水）、Findyが主催するエンジニア向けイベント「アジャイル開発最前線〜メルカリ、LINE、クオカードのエンジニア組織を徹底解剖！〜」がオンライン上にて開催されました。 新型コロナウイルスの影響により、私たちの働き方は大きく変化しました。こうした状況の中で、より良い製品を作り出すためには、単に働き方を変えるだけでなく、多様な働き方に適した組織体制やコミュニケーション、さらにはツール選定など、エンジニア組織や開発手法自体も、時代に合わせて考える必要があります。 今回は、長きに渡ってアジャイル開発を進めてきたゲストの方々をお呼びし、アジャイル開発のこれまでと直近の変化、今後のあり方について語っていただきました。その内容を、前編のパネルディスカッションパートと、後編のQ＆Aパートに分けてお届けします。 前編はこちらから ■登壇者プロフィール 鎌田 正浩／LINE株式会社 [

8年前からゴミ清掃員の仕事を始めたお笑いコンビ「マシンガンズ」の滝沢秀一さん(44)。2018年には清掃員の日常を綴った著書「このゴミは収集できません」を上梓し、漫画などの関連書籍を含め10万部以上を売り上げるヒット作に。先月には新刊「やっぱり、このゴミは収集できません」を出しました。新型コロナウイルス禍における清掃員の現実。そして、自身を支える先輩芸人からの言葉。今の思いを赤裸々に吐露しました。 「ゴミはうそをつかない」　清掃員の仕事を始めて8年になるんですけど、仕事を始めたきっかけは妻の妊娠でした。出産するんでとにかくお金が要ると。ただ、当時からお笑いの仕事もあんまりなかったので、アルバイトをしてお金を作ろうとなったんです。 その時、僕が36歳。アルバイトの募集要項を見ると、年齢制限が「35歳まで」となっているものが多くて、アルバイトを探すにしても、これだけ見っかんないんだと愕然として

Railsにおける app/ とは app/はRailsのアプリケーション用ディレクトリで、普通のRailsアプリケーションでは、この下にmodels,controllers,viewsを含めた様々なディレクトリが作られます。 基本的には新しいディレクトリを追加する必要はないのですが、アプリケーションが複雑になると、Railsを拡張するべくここにアプリケーション固有のディレクトリを作って、その下に関連するファイルを置くことがあります。 中には、servicesやserializersのように、多くのRailsアプリケーションで見られるものもあれば、完全にアプリケーション独自のものが作られることもあります。また、アプリケーションによっては独自のディレクトリは一切作らないものもあれば、大量に作るものもあります。それぞれアプリケーションの開発方針によるものです。 本記事では、比較的有名なOSSの

エンジニアの辛い仕事を消す本かも（多分） 2014年の秋にリクルートに転職してから何社か経て今も自社サービスのエンジニアとして働いてるマンです. リクルートに入ったとき, そしてその後の転職先*1などなどで, 社内外問わずのコミュニケーションの辛さ. 社内調整, 顧客折衝etc... コードじゃなくて, ドキュメントを書く仕事の辛さ. プレゼンテーション・説明そのもの. 技術わかんない上司に説明(ry*2 みたいな経験をたくさんしました&これはエンジニアをやってたら誰でも直面する事態かなと思います, 自社サービス企業だろうがSIer/受託開発の企業だろうが. そもそも, 昔の調査にもそんな雰囲気ありますし, おそらく今もさほど変わらないでしょう. ...ということを, 前回のブログの執筆中および反響で改めて思い*3, そういえば自分はこの辺, 元々ITコンサルタント*4だった時に学んだこと

本書は、顧客に価値を届けるプロダクトを作り出すプロダクトマネジメントについて学ぶ本です。プロダクトマネジメントを理解することで、企業がビジネス目標を達成しながら、顧客の課題を解決する方法を解説します。はじめにプロダクトマネージャーの役割と責任を定義し、優れた意思決定を促す戦略の立て方を紹介します。実験と最適化によって作るべきプロダクトを決めるプロセスを解説し、最後にプロダクト主導の組織を支えるための文化や方針を紹介します。 市場で競争力を維持するには、組織はアウトプットよりもアウトカム（成果）に焦点を当てた顧客中心の方針を採用する必要があります。アウトプットを重視してしまう企業は、顧客のニーズではなくスケジュールを優先し不要な機能をリリースする「ビルドトラップ」に陥ります。 このビルドトラップを避け、顧客の課題にフォーカスするプロダクトマネジメントの原則を解説する本書は、規模の大小を問わず