週報 2023/01/15 古典に通ずると文章がうまくなる, 納得したことだけに従う - しゅみは人間の分析です
近況 連休の終わりの日、休みが終わることへの現実逃避としてDyson Sphere Programをはじめた。昨年のゴールデンウィークにもしていた。休暇を食いつぶす自傷行為である。 工場を作る道具を作る工場 これは道具屋筋と呼んでいる工場群である。工場を作るための道具を生産しているから道具屋筋だ。 Factorioをはじめとする自動化ゲームはコンベアを引き回して工場を作る。しかしコンベアを引くのはめんどくさい。どの自動化ゲームも中盤に無線輸送システムが使えるようになる。かわいいドローンたちが物資を積んで、工場の間を飛び回ってくれるのだ。Dyson Sphere Programにも、新たな種類のドローンが追加され上図のような工場を作る工場を作れるようになった。 月曜日にはじめたので、当然まだクリアしていない。労働の日常に戻ってもまだやっている。休暇で生活位相が二時間ズレたこともあり、生活はガ
分業は悪だがやめると食えなくなる問題 - しゅみは人間の分析です
engineer-lab.findy-code.io こんな記事があって、「分業化するWeb開発の違和感」といういい言葉がでてきた。その通り、この世の不気味さ、不安さはぜんぶ分業のせいである。私は本気でそう思っている。 分業はいいことだ。全体の効率があがる。特に個人が食糧生産から解放されたことは大きい。ほんの少しの人たちが食糧を作ってくれるおかげで他の人たちは別の仕事ができる。こんなすばらしいことはない。今や都市生活者は全世界人口の半数を超える。分業のおかげで職業を選び都市で暮らすという選択ができるのだ。 分業はわるいことだ。個人の経験が分断され、コミュニケーションが成立しなくなる。隣の島で働いている人たちが何をしているのかわからない。同じ社内でも職種が違うと話が通じないことがある。前提がどこから違うのかわからない。こんなにもわからないのに、なぜか会社は利益をあげて決算報告書を提出している
生活は簡単に変わらない - しゅみは人間の分析です
インターネットで生活術指南の記事を見ることは多い。しかし生活というものはそう簡単に変えられない。私も以前は「こういう工夫をしたら料理が楽になるよ」という記事を書いたことはある。だが今では少し考えが変わっている。 死の悲しさと生活が変わることのストレス 身の回りの人が死ぬということについて深く考えてみたことがある。知人や家族が死ぬとひどくショックを受けるものである。人じゃなくてもペットや植物でも良い。しかし、ほとんど喋ったことのないような遠い親戚が死んだ時は悲しくはならない。 この違いはどこから生じるのだろうと考えたとき、生活を共にするものに死なれたかどうかがポイントだと思った。生活の中に他者が組み込まれていて、その他者が死ぬと生活が変わる。この生活の変化によって人はストレスを受けるのだ。一般的には心に穴が空いたとか、その人がいないことに直面させられる、とか表現すると思う。死による他者の不在
栄養とは何か？は未だ不明である - しゅみは人間の分析です
ライティングの哲学を読んでいたらおもしろいブログを発見した。 ライティングの哲学 書けない悩みのための執筆論 (星海社 e-SHINSHO) 作者:千葉雅也,山内朋樹,読書猿,瀬下翔太 講談社 Amazon という、千葉雅也先生の発言。 インターネット上の記事か何かだろうなと思って検索したら、それらしきブログを見つけた。 ameblo.jp 「食事摂取基準に基づいて」とありますが、食事摂取基準の歴史を見れば、変節の歴史そのものであることがわかります。忘れていけないことは、私たちが生きていくうえで必要な栄養素の種類も量もだれもわかっていないということです。今、わかっている範囲ではという前提条件を忘れてはいけません。そして、私たちは常に富士山の８合目にいるという錯覚に陥りがちだということです。１００年経ってみたら、実は一合目にも着いていなかったという可能性があります。 ここですね。これは事実で
スマホとSNSに切り刻まれている - しゅみは人間の分析です
先日、放送大学の人格心理学という科目の教科書を読んだ。人格とは何か、という問題を多面的に考える科目だ。本題は人格全般を心理学することなのだが、この教科書の最後の章に興味深い指摘があった。 電子メディアによって私たちの日常生活は、二重の意味で分断される。ひとつは時間軸の方向に、もうひとつは空間内においてである。時間軸での分断とは、次のような事象である。たとえば、モバイル端末を通して、複数の友人から頻繁にメッセージがやってくる。私たちはそれに即座に反応し返信することが一般的となっている。異なる人々との関係は、異なる対人的状況である。そのたびに私たちは「自分」を切り替え、自分の置かれる文脈（コンテクスト）を切り替えざるをえない。 （中略） 私たち連続性のある一貫した状況の中ではなく、切れ切れになった状況の中を生き抜いていかねばならなくなっている。これは、私たち人間がこれまで体験したことのなかった
自分はなにもできないと思い込む前にやること - しゅみは人間の分析です
「能力のあるなしではなく、自分の認識とじっさいに発揮できる能力の齟齬が小さいのが肝要におもいまう」 という発言をしたので、詳しく説明します。 無限にすごい人が観察できるインターネット時代の悩み 自分は何もできないのではないかという悩みがあります。身の回りの人や、インターネットでみえる有名人と比べて、自分は何もできないと考える人は多いです。しかし、本当になにもできないのでしょうか？ これは嘘です。なにもできないわけではありません。できることとできないことがあるはずです。重要なのは、全体の印象で何もできないと決めつけるのではなく、できることとできないことをはっきりさせることです。自分にはできないと思うことは主観ですが、具体的な行動それぞれについては客観的にできる / できないを考えられます。 具体的なスキルについて考えてゆく 例えば、炊飯器でご飯を炊ける、味噌汁が作れる、野菜炒めが作れる、カレ
■ - しゅみは人間の分析です
srknr.hatenablog.com これを読んで気づいたのが以下。 ソフトウェア開発に代表される知的労働者は生産手段が労働者に属しているので、構造的に資本家に対して強いのだなぁ。 — ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年5月21日 資本家に属さない上に成果物が複製可能な生産手段たしかに革命的で、意識が高くなるのも理解できた。しかし、競争という観点では必ず組織が必要になるのでほげですね。 — ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年5月21日 同時に属人化は回避しえないという結論も導かれます。 — ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年5月21日 AppStoreの上位が企業によるアプリケーションで占められているように、いくら生産手段が労働者に属しているとはいえ、分業と豊富なリソースでの殴り合いに個人は勝てな
DDDを読んでる途中でのネットワークシステム設計雑感 - しゅみは人間の分析です
フロントエンドGUIの設計について考えていたら設計沼にはまり背骨となる思想を求めてDDDを読んでいる状況です。 フロントエンドを含めたネットワークシステム全般の設計についての雑感。 RDBのテーブルの抽象としてORMで対応するモデルはドメインモデルではない RDBの制約のうえでの最適な構造と、ドメインモデルの構造は必ずしも一致しない 取れる対処はORMを介さず直接クエリを書いてドメインモデルに変換するか、ORMを使ったうえでテーブル抽象のモデルの上にドメインモデルを組み立てるか サーバはAPIに特化してしまえば、サーバ側にドメインモデルは必要ないか？ 複数のレコードにまたがるトランザクションが必要なケースがあり、整合性の検証をする上でドメインモデルが必要になる REST API特化にしてドメインを薄くできるかは要件依存になる クライアント（ネイティブ含む）の環境でドメインモデルは？ GUI
データ構造とアルゴリズム - しゅみは人間の分析です
アルバイトも含めてプログラマとしてはそこそこ経験を積んだが、年々データ構造とアルゴリズムの偉大さを噛みしめるばかり。とはいえまだデータ構造とアルゴリズムを理解した！といえるほどメンタルモデルができてないので、その理由についてはうまく言語化することができない。 計算機科学をやる学科では最初の頃にこの分野を習うのだけど、コードを書いた経験が少ないうちはなかなか有り難みが理解できなかった。習うより使わないとわからん度が高い領域ではあると思う。 私はインターネットを使ったシステムを作る屋さんだからだとは思うが、超難しいアルゴリズムを駆使して実装なんてことはほとんどなくて、実際にはデータ構造の定義で難しい問題がシュッと解けることが多い。 つまり実務であてはめるとモデル設計の時点で多くの問題を解決できるともいえる。ではあるのだけど、我々は想像力が足りないのである時点での局所最適なモデル設計をしてしまっ
さいきんReact, Reduxでやっている設計 - しゅみは人間の分析です
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
フロントエンドGUIの状態の整理 - しゅみは人間の分析です
昨日の🍺のあとに考えていた雑感。フロントエンドから見たGUIの状態を個人の主観をもとに整理しています。 背景 複雑なJavaScriptアプリケーションを考えながら作る話 と id:Pasta-K がReact + Canvasで色々やっていた話 などなど。 Reactなどの現代フロントエンドはたいへんしんどいGUIであるという前提もあります。 GUIの状態の種類 人間 諸悪の根源。 だいたいこいつが状態を変更してくる。バリデーションが必要なのもこいつのせい。 わかりやすいUIを提供しないと人間が弱る。 View Viewの中の状態。UI上の選択状態とか。 Viewに状態を持ちたくない宗派としては、できれば非永続化層（メインのビジネスロジックと状態を持った層）か永続化層（DB）にすべての状態を持っていて欲しいが、パフォーマンス上の問題でthis.stateに状態を持つことはありえる。Re
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
