百万遍あたりに最近できた良い飲食店の紹介
今年は百万遍あたりにいろいろ食べるお店が増えてよかった。特に本格中華料理店がいくつかできたのがうれしい。なぜか知らないけど中国人によるお店が突然増えた。一通り店巡りをして、良かった店を紹介する。
上等カレー
得正グループのカレー屋さん。ルーにいろいろ素材が煮込まれてて甘みと辛味が共存しておいしいカレーだ。値段も安くて、カツカレーが700円くらい。
夜のみ得正カレーうどんが提供されるようになった。大阪で食べた得正のカレーうどんとちょっとルーの味が違うきもするけど、すごくおいしい。出汁とカレーのコンビネーション、それに加えて甘い肉の佃煮が乗ってて一気に食べれてしまう。
方圓美味
本場の四川料理人による中華料理店。お値段もお手頃。ランチなら1000円以下で定食が食べれる。 メニューが豊富。鉄鍋で炒めた香ばしさがすごく出てて美味い。本格四川料理だけど、日本人に合わせてくれてて辛味は控えめで食べやすい。麻婆豆腐も安心して食べれる。
お昼は満席になってることも多い。お客さんにも中国人が多い。
火楓源
ここも中国人料に人による中華料理店。四川料理じゃないと思う、けどすごく辛い。一人で食べれる鍋もあるけどこれも辛いのが多い。
この店の隣に長江辺という中華料理店が昔からあるんだけど、そこと味がよく似てる。どちらも鍋のラインナップが充実していて、寒い日に辛くて熱い鍋を食べると最高。
テーブルは金色のテーブルクロスが掛かってて、メニューは壁一面にバックライトを付けたパネルになっててどハデ。コック帽をかぶった料理人が4人くらいいるけどそんなに働いてる感じはなくて、売上大丈夫かちょっと心配になる。この店も中国人の客が多い。
東北燒烤涮
これも火楓源の隣くらいにある中華料理店。田中里ノ前付近は華祥もあるし、おくだもあるし、上海バンドもあるしで、めちゃくちゃ飲食店の層が暑くなった。
この店は地下への階段を通って店に入るんだけど、外からでは中の様子がわからないのでちょっと入るのに勇気がいるが、中に入ると結構広い。ランチでは台湾ラーメンみたいなラーメンとか定食などが食べれる。
味は濃い目でかなり塩辛く感じた。個人的には火楓源のほうが好き。
麺家 あくた川
百万遍にできたラーメン屋。烏丸通のあくた川の系列店。よく行列ができてる。 ここのラーメンは個人的にかなり面白い。スープは一口目は臭いが強くて塩辛すぎると感じて、麺も単体では最初は太くてボソボソしていると感じるんだけど、麺とスープ一緒に味わうととたんに味わいが出てきてズルズルっと一杯食べてしまう。不思議な感覚だけど、満足度が高くて行列ができるのも頷ける。これは家系ラーメンっていうのかな？家系ラーメンを食べたことがないのでよくわからない。
ラズパイで音量検知して光るガジェット作った
ラズパイで大きい音量を検知すると、光って知らせるガジェットを作っていたんだけど、連休に仕上げよう、とがんばって、やっと完成した。
やりたかったことは、うちの子供たちが大声で騒いでしまったとき、自分たちでそれを気づけるようにすること。興奮して騒いでくると、自分の声の大きさに気づけなくなるじゃないですか。居酒屋でみなさん経験してますよね。
それで連日のようにマイクラしながら大声で騒ぐんだけど、大声を出してる自覚がないので親が指摘するのも気疲れする。なので、自分たちで気づけるように状況を見える化しよう、と思って作ってみた。一通りやりたかったのが完成した状態がこれです。
テレビの前で騒ぐと赤く光って知らせる仕組みできあがった！初ラズパイです。 pic.twitter.com/BFAJVUD8QK
— Yoshihiro Kameda (@kmdsbng) December 23, 2018
開発当初はラズパイのセットアップ方法とかもしらなかったので、どのラズパイを買えばいいのかというところから結構迷った。
初期の構想ではGrovePi+っていうパーツアダプターとGrovePi+用のマイク、LEDを付けて作ろうと思ったんだけど、ラズパイ経験者の矢野くんからUSBマイクとディスプレイ付けたほうがいいんじゃないかとアドバイスを受けて、その構成で作ることにした。
マイクはこれ。
500円くらいだけど十分な性能だった。
https://t.co/BKLxKkk465 この小型ディスプレイも買った。付属のHDMIアダプターでラズパイと接続する。特に設定など不要で画面が映る。タッチパネルを使うには、付属のソフトをラズパイにインストールする必要がある。
ディスプレイは買っておいてよかった。別途ディスプレイとつなげる必要がないし、これ自体が通知インターフェイスにもなる。ラズパイと合わせて10000円弱程度になってしまうが、なかったら開発は大変そう。
ラズパイ本体もどれを買っていいのかわからなかったので、矢野くんと相談してRaspberry Pi 3B+ っていうやつにした。RSコンポーネンツとElement14という2個の製造元があるが、Element14は品質が悪いってネットに書かれてたのでRSコンポーネンツの方を買った。https://t.co/h498R5hAnC
SDカードが相性悪いと、ラズパイが起動しないみたいな情報もあった。東芝製のSDカードなら大丈夫らしいので、東芝製の16GBのSDカードを買った。SDカードも4GBだとOSの容量が足りないので16GB以上くらいがいい。1000円くらいで買えた。https://t.co/oUwuINCCLw
ラズパイのOSは、本家サイトからダウンロードしてSDカードに書き込んでおく。この記事とかを参考にしてインストールした。https://t.co/IYONbjhwbL
ラズパイのOSにはpythonが初めから入ってるので、それを使ってプログラムを作った。はじめてのpythonだったけど、シンタックスちょっと違うなー、くらいで特につまづかずにプログラミングはできた。USBマイクから音量を取ってきて、それを画面にグラフとして描画する。画面への描画はpygameっていう2Dゲーム用のライブラリを使った。
pixe.laを使って、大音量を検知した回数を記録するようにもした。pixe.laはリリースされたときからぜひ使ってみたいと思ってたので、いい機会だった。curlだけでユーザー登録、グラフ作成、グラフ更新ができるのですごく便利ですね。
作ったプログラムはgithubに上げました。
これで子どもたちが自分自身で音量調節できるようになるといいんですけど。どうなるかしばらく様子を見てみます。
ユビキタス言語についての考えの整理
(この記事は、ユビキタス言語について、自分の考えを整理するために書いたものです。)
DDDは分類法の一つという側面がある。一番大きな分類は、境界づけられたコンテキストだ。境界づけられたコンテキストはある業務領域に対応する分類の枠だ。ECサイトなら商品発送で一つのコンテキスト、請求処理で一つのコンテキスト、くらいの単位だ。
コンテキストは名前空間として働く。ドメインの用語はコンテキストの内部だけで有効だ。コンテキストを越えると同じ言葉であっても別の概念として扱わないといけない。
例えば発送処理と請求処理でコンテキストを分けているとして、それぞれのコンテキストで「顧客」という用語を使っていても、それらは別の概念だとみなさないといけない。
それぞれのコンテキストの顧客は共通のこともあるけど、業務が異なるので違う振る舞いを期待する。そういうのは別の概念として分ける。実装時にはそれぞれのクラスはそれぞれのコンテキストの中に別のクラスとして実装する。
このようにコンテキストの内部でだけ有効な用語を関係者みんなで使いましょう、それをユビキタス言語と呼びましょう、というのがユビキタス言語だ。
ユビキタス言語をうまく作用させるには、みんな(開発者もドメインエキスパートも)がユビキタス言語に則った用語を使うこと、ドメインモデルにもユビキタス言語を使った名前付けにすることが必要だ。
同じ言葉を使ってコミュニケーションすることで、ドメインを効率的に学習していくことができる。ドメインについての質問をユビキタス言語を使って行うことで、共通の言葉を使って概念を整理していくことができる。
それらのドメインの概念は、そのままプログラムでも表現する。そのために、パッケージ名、クラス名、メソッド名にもユビキタス言語をそのまま使用する。会話している言葉と同じ言葉を使ってプログラムを名前付けするために、翻訳しながらプログラムを読み取る必要がなくなる。
(コンテキストの中の)ドメインモデルの分類にはユビキタス言語を使うことになる。クラス名にはユビキタス言語で定義された用語が使われるし、用語間の関係はパッケージでグルーピングされる。パッケージの名前にもユビキタス言語で定義された用語が使われることもある。
ドメインモデルをユビキタス言語で分類するためには、ある用語がドメインの中のある一つの概念と結びついてないといけない。そうでないと曖昧な責務になってしまうだろう。あとはある用語が2つ以上の意味に使われているといけない。
ユビキタス言語これらの性質を満たしているというのが、DDDがうまく動くはず、という根拠になっていると思う。
なぜ ユニークな概念に紐づくユビキタス言語を作ることが可能かというと、それで実際の業務が回っているから、というのが根拠になっているのではないかと思う。業務を回しているということは、曖昧な用語を使ってコミュニケーションロスが発生していないはずなのだ。
例えば新しく田中さんが職場に入ってきて、すでに田中さんがいた場合、田中博、田中太のような感じで、自動的にユニークで誤解のない呼び名が生まれるはずなのだ。業務で扱っている言葉であれば、それが誤解を生むような用語であれば業務が回らないようになってしまう。
業務を回しているということは、そのような事態は発生しないということを保証している。なので、ドメインエキスパートと開発者の間で共有できるユビキタス言語を作ることが可能なのだ。
目標を共有する、ということについて考えたこと
今日のEffective DevOps読書会で、チーム間で目標を共有することの重要性という話が出てきた。チーム間で目標とすることがずれていると協調して作業することができない、という文脈だ。
なぜ目標がずれてしまうのか？それはそれぞれの視点が違うからだという意見が出た。
例として開発者とテスターの視点の違いで考えてみると、開発者は素早く機能をリリースすることが目標になるが、テスターは機能にバグがないことを保証することに価値を置くため、素早く機能をリリースすることには価値を見出さない、といった感じだ。
視点の違いによって目標にズレが出てしまう、という意見は本質をとらえていると思う。これはチーム間だけでなく、経営層と開発チームで目標を共有できていない理由にも適用できるし、同じ職種であっても、人によって視点は違うので、おそらく目標もずれているだろう、と推測できる。
視点の違いを乗り越えて目標を共有するために、目標を明文化、見える化することが重要なはずだ。個々の視点、価値観がぴったり揃うことはないだろうが、それでも共有できる部分について目標を共有することは可能なはずだ。
ところで目標を共有できているというはどういう状態だろうか。 個人的に目標の共有には「なぜその状態を目指すのか」というWhyに答える情報が必要だと思っている。
もう一つ必要なのは「勝利条件の設定」だと思っている。 たとえばカードゲームだと相手のHPを0にしたり、デッキを空にする、などの複数の勝利条件が設定されているし、Civでも文化勝利や制覇勝利など複数の勝利条件がある。勝利条件を定義し、どの勝利条件を目指すかということを共有しないといけない。文化勝利を目指すのと制覇勝利を目指すのでは戦略そのものが変わってくるだろう。
実際の開発案件であれば、ユーザーが業務をこなせる機能を1か月以内にリリースすること、とか、課金ユーザー数を半年以内に1万人、2年以内に10万人を達成する、などだ。ビジネスとして開発をするなら、そのビジネスが存続できるための条件が必ずあるはずだ。それを明文化しておくべきだ。
Whyと勝利条件。これらが必要な理由は、スタッフ、チームが自主的に動けるようにするためだ。これらの情報がなければ、どのように動けば効率的に目標を達成できるかを決められないだろう。
インセプションデッキで最初に決めることは「なぜ我々はここにいるのか」だ。Whyに答えることが目標を定義する第一歩なのだと思う。
直感に頼る
ロジカルシンキングは好きなんだけど、意図的に「論理的に正しい」手段より、直感でうまくいきそうな手段を採用することがままある。こうしたほうが間違った意思決定を避けることができると思うからだ。
たとえば「今マンションを買ったほうがめっちゃお得！」みたいなセールストークを受けた時などにこういう感覚を働かせている。 こういうセールストークをする人は、矛盾の無いように理論武装してるので、その場で論理的矛盾を着くことはできないこともありうる。
そういう時に論理的な正しさをよりどころにしていると、毎回マンションとかホーム家電とか新しいスマホとかを買わないといけなくなってしまうが、それはコスパの悪く、満足度の低い意思決定になるだろう。
なぜ論理的に正しい(そうに見える)結論を採用し続けると、正しくない意思決定に陥ってしまうのだろうか？おそらく前提に見落としがあったり論理展開に瑕疵があったりするのだろう。前提に全く見落としがないということを保証するのはほとんどのケースでできないので、間違った意思決定に繋がりうる。
おそらく論理的思考は、ある仮説の正しさを短時間で確度を高く評価したい時には向いているが、正しそうに見える論理が本当に間違ってないかを検証するのには向いてない。長期的な未来予測はほとんど当たらない。それは実は重要な前提の考慮漏れがあるからなのだろう。
それでも僕たちは日々意思決定をする必要がある。 僕はその確度を高めるためには論理的思考ではなく、直感に頼るほうが良いと考えている。そのほうが質の良い意思決定につながると考えている。
「マンションを買ったほうがいいという意見は正しそうに見えるけど、実際に運用することを考えるとローン返すことや、抵当権設定の処理や、住宅ローン利率の変動や地震などの災害や、考えないといけないことが増えて面倒そうなんで買わない。」というような感覚だ。
ある一面だけ見ると正しそうに見えるけど、それが本当にワークするのか？ということを想像することで、「論理的に正しそうに見えるけど間違った意思決定をしてしまってどうしようもなくなる」という事態を避けられることが多いと感じる。
必要な前提を洗い出して、論理に瑕疵がないなら、論理的に正しいことは必ず正しい。けど、現実的な計算時間で、すべての前提を漏れなく考慮することは不可能だ。それができるって言う人は、単に前提見落とししてることを意識外に出してるだけなのだ。直感に頼る理由はコスパがいいということにつきる。
直感に頼るという戦略を採用するなら、直感を鍛えることが重要であるという結論に行き着く。 直感とは超能力ではなく、経験から導き出されるパターンマッチ能力のことだと考えている。
人間のパターンマッチ能力は優れているので、論理的な根拠は示せなくても「ヤバそう」などの感覚として感じることができる。
なので、「ヤバそう」と感じること、そう感じた時にそれを言語化して、パターン化することを意識している。 僕にとってはテレビゲームはこの感覚を鍛えるのに役立ってると感じている。
Tower Defenseやローグライクが大好きなんですが、これらのゲームはヤバそうな雰囲気を察知することや、正しい意思決定をし続けることを要求するゲームです。 これらのジャンルのゲームをするのは直感を鍛えるのにオススメです。
バリデーションするタイミングについて迷った
バリデーションを行う場面について、判断に迷うケースがあった。多数のアイテムの中から購入するアイテムを複数選ぶのだが、制限のビジネスルールがいくつかあるとする。
購入の手順は、アイテムをカートに入れていって、その後カートの内容を購入する、という一般的なカート方式。 制約には「過去に購入したアイテムは二度と購入できない(できるアイテムもある)」「特定のアイテムを購入したことがないと購入できないアイテム」「特定条件アイテムの上限数」などがある。
バリデーションを行う場面は3つある。アイテム一覧をロードする時、アイテムをカートに入れる場面、カートを購入する場面。 まずカートを購入する場面では、すべての制約を満たしているか、確実にチェックしないといけない。ここはmust。
カートにアイテムを追加するときにもバリデーションを行うことができる。そもそも追加できないアイテムは、この時点で購入できないとエラーを出してやれば、ユーザはカート購入より前に制約に気づくことができる。ここでチェックすることはそんなに難しくない。
ロード時に制約を反映させるのは、データ数と実現方法によっては難しい。 「そもそも購入対象外のアイテムは、ユーザーに見せるアイテム一覧に表示させない」というようなことをするのは、結構難易度が上がる。
RDBMSなどのストレージから抽出する際に、SQLで制約を表現しないといけないとすると、いくつか問題が出てくる。まずSQLが複雑になって、可読性が下がり、抽出に時間がかかりうる。
indexの使えない制約をかける必要が出ると、抽出時間は条件やデータ数に左右されてしまうようになり、「どんなケースでも現実的な時間内で処理が完了するか？」を判断するのが難しくなってしまう。
カート追加時、カート購入時と別の場所に同じバリデーションを実装するのも、メンテ性やチェックの難易度を上げる。
ただ、ロードするアイテムをページングして表示しているなら、SQLにビジネスロジックを実装せざるを得ない。
ページングしていなくて、表示件数がそんなに多くないなら、カート追加時と同じバリデーションをロードする各アイテムにも適用してから結果を返すという設計もありうる。今回はこのケースに当てはまったので、この方針を採用することにした。(バリデーションに失敗したものを結果から除外した。)
ロード時にバリデーションを行う別の実現方法としては、データロード自体は行うが、カートに追加できないアイテムは、追加ボタンを無効にするという手法もある。この方法ならページングしていても、SQLでビジネスロジックを実装しなくても対応できそう。
ニューロンのスピードで文章を書く
会社のメンバーと、アウトプットを増やす方法について相談していたところ、文章を推敲することがアウトプットを少なくしているのではないか、という仮説に行き着いた。
ではどうすればいいかを考えてみたところ、推敲できないようにして文章を書いてみればいいのではないか、という話になった。Twitterへの投稿なら定量的にできているので、それをまとまった文章を書くときにもやってみればいいのではないか、というアイデアだ。
これはなかなか効果があるかもしれない、と思う。やりなおしが効くから手直ししたくなってなかなか書けなくなるので、やり直しができない環境であれば、多くの量を書けるようになるかもしれない。
そもそもアウトプットを増やす、というのが量さえ書けばよいのか？という話もあるが、個人的には質のことを考えず、考えていることをどんどんアウトプットできればそれでいいのではないかと思う。
物事を整理して書くコンテンツにもちろん価値があるが、そこからはライブ性や躍動感が失われてしまう副作用もあると感じる。うまくまとめられていない感覚や予想といったものを文章化するとき、それをうまくまとめようとすると表現できなくなってしまうことがあると思う。
そういった不確かなことや、小さな気付きといったものをアウトプットしていきたいのだ。そのためにはアウトプットにエネルギーがかかるようではいけない。身近な誰かに話をするように、ごく小さい労力でアウトプットできないといけないはずだ。
また、文章のリズムというのもそこから生まれてくるのではないかと思う。これはまだ仮説だけど、推敲を重ねた文章からはリズム感が失われてしまうと感じる。すばやく、ニューロンのスピードで読めるような文章を書くことができるか、という実験にもしたい。
そういったわけで、Twitterに書き込んで文章を書く、ということを早速試してみている。 一つ心配なのは、推敲せずに書いた文章に、ネガティブな心情が反映されてしまわないか、ということだ。まあそこは試しにやってみて、まずかったらまた考えようかなと思ってる。
