週報 2024/05/12 京都食堂の謎メニューの魅力 - しゅみは人間の分析です
5/4（土） なんとなく朝マクドにする。モバイルオーダーをして手ぶらで店に向かった。何も持たずに歩くとフォームが綺麗になるのを思いだした。かばんもスマホも持たずに散歩をするのが理想。なかなかそういう機会はないのだけども。 マフィンを食べて朝のメニューは水気があることに気づいた。昼夜はコーラと飲むように作られているが、朝はまともらしい。水気のあるハンバーガーを食べたいときはモスなどにしなければならない。朝はマクドナルドでもいい。 食後コーヒーを煎れる。先日の「コーヒー装備が云々」の記事を思いだして円錐ドリッパーを使ってみたらたしかに味が変わった。ドリッパーの形状やペーパーの材質で味が変わるなんてコーヒーは困った趣味である。 🍵🍵🍵 今日も物置の片づけ。腰を痛めながらゴミを集めて袋に詰めた。 収納は衣装ケースがよい。抽斗でスタックできるやつ。現代の箪笥なのだな。 これまでバンカーズボック
週報 2022/02/06 コードレビューはコミットを新しい順に読むとわかりやすい説, アファンタジア被験者に応募した - しゅみは人間の分析です
近況 ワクチン接種3回目 近所の病院でモデルナが捨てるほど余っていると聞いたので打ちに行った。ワクチンを捨てるなんてとんでもないことだ。手元にはまだ接種券が来ていなかったが、2回目の接種証明書があれば打てるそうなので打つことにした。そういえば1回目と2回目もこうやって急に決まった気がする。 前回はファイザーだったのだが今回はモデルナになった。副反応がきついという噂は聞いていたのでしっかり準備をしたが、それでもつらい思いをした。一番つらかったのは悪寒で眠れなかったことだ。手足は冷え体は震えていたのに、頭は半分寝ているので対処ができない。そのまま数時間過ごしたのちに、なんとか起き上がってたくさん着込んだり薬を飲んだりしたら、やっと眠れた。 熱は最高で38.2度ぐらいまで上昇したが、熱が上がってからは割と楽だった。大事なのはしっかり食べてしっかり寝ることだと思う。我々の体は物理法則に従っており、
シン・エヴァンゲリオンの主題と示された答えについて - しゅみは人間の分析です
エヴァは「不気味な他者」がテーマだった。親子喧嘩のシーンが核心。ゲンドウは他者が嫌いで彼には本とピアノしかなかった。漫画および地上波版でもゲンドウは他者とはわかり合えないと言っている。このポイントは一貫しており、昔から設定があったのだろう。 今回の映画でシンジは何を手に入れて変わったのだろうか。Qの終盤でシンジは大事な他者、カヲルくんを目の前で失った。そして黒波の死で何かを取り戻した。これは何だろうか。もしかすると、母からの愛なのかもしれない。綾波シリーズとして設計され仕組まれているとはいえ、レイは母＝ユイに近い存在で無償の愛を与えてくれる。とはいえ、なぜそれでシンジは自らの弱さを認められるようになったのか。「自分の弱さを認める強さ」を得たからシンジはゲンドウに勝てたのだ。この点がまだ言語化しきれない。いや、そもそも愛とは「自分の弱さを認める強さ」と関係があるのかもしれない。ゲンドウを電車
2019年ふりかえり - しゅみは人間の分析です
同人誌を生産する生活 同人誌制作が生活の中心だった。妻が同人活動を始め、それに振り回された一年といえる。妻はもともと絵を描く人だったが、ある日突然漫画も描くようになった。配偶者とはいえ、ひとの趣味なので始めは放置していた。だが、どうも雲行きが怪しい。スケジュールが破綻していたのだ。新刊が落ちるかもしれない、そんな状況で2019年を迎えた。年末年始の休暇をすべて費やし、私はスケジュール管理とアシスタントをすることになった。妻は1日に4ページの作画をこなし、私がベタとトーンを塗る。正月も休むことなく作業をし、締切前日には当然のように徹夜をした。 同人誌を作るのは文化祭の準備と似ている。あらゆる手段を使って完成させ、イベントで頒布しないといけない。本を用意できたら対面販売の喜びが得られる。インターネットで得られるただの数字とは違って、目の前の人が本を買ってくれるのだ。狭いスペースに何時間もいるの
会話で情報が増えるとうれしい - しゅみは人間の分析です
オープンクエスチョンで言われるような、よい質問は、（会話の場の？参与者たちの？）情報*1を増やしてゆく性質をもつ。会話は情報をやりとりするものであり、情報が増えると目的*2が達成される。会話、とくに雑談をするときにはいかに情報を増やすか考えながら発話すると良いのかもしれない。その一つの手段が自己開示や開かれた質問でもある。はい／いいえで答えられる質問はむしろ情報量が減っている。曖昧な状態から一つの状態に収束しているから。たしかに知識は増えているが、自己開示を促す質問よりは、情報量の増える会話ではない。 発話が多ければそれでよいのだろうか？ 当然そんなことはない。長広舌は嫌われるし私も嫌いだ。やりがちだが。なぜ駄目なのか。長い発話を理解するのは認知的にたいへんだからだ。理解できなくなった時点で、それ以降の発話は聞き流される。つまり、伝わらない発話は相手の情報を増やさないために、会話の目的が損
なぜソフトウェアエンジニアの私が哲学をやるのか - しゅみは人間の分析です
なぜなのか。それは、哲学が役に立つから。ちょっとわけがわからないと思うので、順を追って説明します。 ソフトウェアエンジニアは何をしているのでしょうか。まずはこの問いからです。ソフトウェアエンジニアは、計算機科学、つまりソフトウェアの設計と実装そして運用の技術で仕事をします。主な用途は自動化されスケールするシステムの構築です。ではこのシステム、ソフトウェアエンジニアがつくるシステムは何のためのものなのか。たいていは実社会の問題を解決するために作られます。会計システムであれば、会計の効率化、自動で計算や仕分けをしてくれたり、ですよね。ソフトウェアエンジニアは実社会の問題をソフトウェアによる自動化の力を借りて解決します。ここまでは簡単ですね。 それでは、彼らは何を作っているのかみていきましょう。実社会の問題を解決するシステムとは何なのか。これは具体化するときりがないものですが、いくつかの特徴があ
Reactのstateに何を入れるべきか問題 - しゅみは人間の分析です
暫定の結論 ドメインモデルをコンポーネントとして表現する場合は、Viewの外*1に状態を持ち、propsとして状態を流し込む ドメインモデルの表現ではない状態（UIとしての中間状態）はstateとしてコンポーネントの内部に隠蔽して保持する UI上の操作で、別のコンポーネントの状態が変わってほしいときは、ドメインモデル同士のインタラクションで解決できないか立ち止まって考えてみる 異なるコンポーネントのstate同士を連携させたいときは、それらがドメインモデルとしてくくり出せないか考えてみる 60fpsの世界を実装したことはないのでその辺は対象外です。 いかにも当たり前っぽい結論になりましたね。また何か思いついたら日記にしていきます。 考えたときの思考をシリアライズしたもの UIの状態とデータの状態に大きくは分けたくなる どちらにもまたがるケースが出てくる リストの順序 決めの問題として、デー
003437
忘年した 今年何したかなんも覚えてない 勉強量は例年並みだったような気がする Primitive Technologyの動画を観ている 泥と木だけで鉄を精錬するのテンションあがる ちゃんと灰などをいれて還元反応を促進している chromecastを購入 テレビとオーディオシステムで動画見るの快適 無線デバイスは最高 自転車の乗り方レベルがあがった ジムで受けている姿勢指導で、「常にドローインしろ」と言われた ドローインしまくったら体幹が締まって足がよく回るようになった 椅子の座り方 姿勢指導 尾てい骨の下にものを挟むと、尾てい骨が後ろに倒れなくなる 尾てい骨は立てるようにしないと腰が曲がるぞ 宝石の国 おもしろくて全部読んだ 原作もおもしろいけど、アニメの演出がよすぎることもわかった 腕を失ったらちゃんと人物の重心が変わってるっぽい？ ふるさと納税 まだなんもしてない 去年買ったそうめんが
チームとフレームワークについて - しゅみは人間の分析です
フレームワークとは 設計思想の観点を大事にして考えると、フレームワークとは設計思想の柔軟性を犠牲に、チーム内の設計思想を調整・統一するコストを下げる働きを持つ仕組みである。 便利機能を抽象化して車輪としたライブラリと異なる点は思想の強制性である。 設計思想がないとき 共通認識となる思想がないシステムをチームで作るときは、何を実装するにしても設計・実装の方針が合わないことがある。 例えばReact + Reduxを使って状態をどこで管理するかというありふれたテーマですら、実装する内容によって状態の持ち方で議論になる。*1 たしかに議論を繰り返してチーム内での認識を徐々に揃えていけば最小のコミュニケーションコストで「いい感じ」に開発していくことは可能なのだけども、この時にできあがっているのは属人化された暗黙知でできたチームである。当然チームとしてのスケーラビリティなんてものはない。 例えばDD
DDDを読んでる途中でのネットワークシステム設計雑感 - しゅみは人間の分析です
フロントエンドGUIの設計について考えていたら設計沼にはまり背骨となる思想を求めてDDDを読んでいる状況です。 フロントエンドを含めたネットワークシステム全般の設計についての雑感。 RDBのテーブルの抽象としてORMで対応するモデルはドメインモデルではない RDBの制約のうえでの最適な構造と、ドメインモデルの構造は必ずしも一致しない 取れる対処はORMを介さず直接クエリを書いてドメインモデルに変換するか、ORMを使ったうえでテーブル抽象のモデルの上にドメインモデルを組み立てるか サーバはAPIに特化してしまえば、サーバ側にドメインモデルは必要ないか？ 複数のレコードにまたがるトランザクションが必要なケースがあり、整合性の検証をする上でドメインモデルが必要になる REST API特化にしてドメインを薄くできるかは要件依存になる クライアント（ネイティブ含む）の環境でドメインモデルは？ GUI
さいきんReact, Reduxでやっている設計 - しゅみは人間の分析です
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
ReactでもDOMの木構造はつらいよ問題 - しゅみは人間の分析です
nippo.wikihub.io r7kamura Commented on 2016-09-01 何も考えずにReact, Redux使うような気はするのだけど、Reduxを使わない場合は各位どうやってState管理してるんでしょうか？ 親コンポーネントがstateとメンバ関数を持っており、子コンポーネントはpropsかcontext経由でその値を参照しながら描画とイベントバインディングを行っています。 日報で疑問を書いたら、id:r7kamuraさんが答えてくれた。 immutable.Recordに状態とロジック押し込んでそいつをContainer Componentのthis.stateに入れておく設計とか。 — 下京区 (@non_117) 2016年9月1日 facebookが想定してるのはこの用途かな。 DOMサブツリー間で状態の共有が発生するか、設計段階で予見するの難しそう
なぜReactなのか - しゅみは人間の分析です
なぜReactなのか React, Cyclejs, Reduxを学んだ上でこれらの技術が何を解決したのかまとめてみる。発想はオリジナルではなく、今まで私が読んだ記事から拝借した解釈などが含まれている。たぶんReact, Fluxを学んだ人にとっては当たり前の感覚を言語化しているだけの内容となる。 TL;DR Q: なぜReactなのか A: フロントエンドが自由度の高いGUIアプリケーションになった。既存の手法では自由度の高いGUI実装を人間にわかりやすく管理することが難しくなった。 自由度の高いGUIな世界 自由度(複雑さ)の低い時代ではrender済みのDOMの上にDOMを操作する(jQueryによる)UIを載せる設計でも十分だった 現代のwebフロントエンドではVisual StudioやXcodeで作るネイティブGUIと同等の複雑さを求められる時代になっている jQueryだけで
ゆゆ式を無限に楽しみたかった話 〜 ゆゆ式 Advent Calendar 2014 20日目 〜 - しゅみは人間の分析です
ある日のこと、後輩たちがこんなことを言いました。 「ゆゆ式のコマをランダムに並びかえたら無限にゆゆ式が楽しめるのでは？」 真面目に計算してみると、10の15乗くらいの組み合わせができることがわかりました。 この記事ゆゆ式アドベントカレンダー20日目は、そんな無限にゆゆ式をたのしむためのシステムを真面目に作ってみた話をします。 コマの切り出し 漫画のコマを並び替えるためには、コマがバラバラな画像として存在していなければなりません。 なので、まずは自炊で電子化された書籍をコマの線にそって切り出していく処理を自動化することにしました。 上の図がふつうの4コマの1ページですね。これの枠線を識別して、1ページから8枚のコマを取り出してくる方法を考えます。 ハフ変換で直線検出 OpenCVという画像処理のライブラリに直線を検出するツールがあったので、まずこれを試してみました。 が、結果はこのとおり。
Kinect v2で人間の3Dスキャンとポイントクラウドでの描画をする 〜KMC／OUCCアドベントカレンダー2014 13日目〜 - しゅみは人間の分析です
皆さん進捗どうですか？ KMC2回生の non117 です。私はダメです。 こちらはKMCアドベントカレンダー2014およびOUCC Advent Calendar 2014の13日目の記事となります。 はじめに 元々は古巣であるOUCCのアドベントカレンダーとKMCのアドベントカレンダーを同じ日に同じ記事で寄稿し、記事を節約することを目論んでいました。 しかし、気がついたらカレンダーが埋まってたため泣く泣く別々の記事を書くことにしました。 新しくネタを用意するのも面倒なので、OUCCアドベントカレンダーで書いたKinect v2すごいよ！という記事の続きを書きます。 ※追記 なんとOUCCアドベントカレンダーの13日目が空いてたので、目標が達成されてしまいました。 関連研究 OUCCアドベントカレンダーではKinect v2がいかにモーションキャプチャとして優れているかという内容でした。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
