取次って今後どうなるんだろうな...
取次というビジネスは実質的には流通コストの圧縮によって成り立っているとおもうのだけど、そのインフラがアマゾンなどの事業者によって代替可能になってしまっている。
情報の電子化にしても、そっちのほうが手軽だからとか慣れているからっていうことではなくて、流通のコストがかからないっていうのがデカい
美術における様式という概念、すっかり古びて不要になったものとおもっていたけど、さまざまな文化事象における style の統一こそが様式という概念の意味するところだったわけで、これ現代では各企業がブランドデザインの名においてやろうとしていることそのものだな。
(ゴシックとかバロックとか、そいういうのは建築やら彫刻やら文学やらの各表現媒体を横断して表明される特徴的な様式 style があるとされる)
いやこの古びた概念を復活させたいなんてことではないんだけども、むしろ、現在の企業がやっていることから省みると、19世紀末から20世紀初頭にかけて様式論が発達するのは、そのとき「様式」概念で捉えようとしていたのが国家の様式とか民族の様式とかだったわけで、当時は国家や民族とは、(ある意味では現代の企業のように)ブランディングしていくべきものと捉えられていたわけだ。
20c初頭に、ドイツでデザインの議論が発達するのは、第一次大戦前夜にドイツが植民地を拡大して販路開拓しようとしていたからだけど、そこで「ドイツ的な様式」が求められていた。ドイツというのは一個の企業のようなものとして了解されていたわけだ。それにたいする反発こそがバウハウスだったとおもうが。
杉本俊太氏は「様式」から「造形」に問題が変化したと論じるけど、そうではない。様式という問題はあきらかに残存していて、デザイン言語とかの領域で具体的な実践になっている。
様式の担い手が国家とか民族とかだと思われていたが、「ゲルマン的本性」みたいな話になると、それはもうデザインの問題ではない。デザインとは構築されたものなのだから、ゲルマン的本性がデザインされてしまうとそれは人工物だということになる(人工物だが)。
「様式」というものが、徹頭徹尾人工物なのだという了解がなければ、それはデザインの対象にならない。コーポレートアイデンティティとかは人工物と見なされても誰も悩まなかったが(企業の人口性なんて誰でもわかるし)、国家が人工物だってバレてしまうと国家は困ってしまう。「民族」も同じように人工物のくせに人工物ではないと振る舞わなければならない概念だ。
このアカウントは、notestockで公開設定になっていません。
@pokarim 電子取次という業態じたいは今もありますね
https://www.jepa.or.jp/ebookpedia/201511_2714/
裁量労働、裁量がありすぎて無労働でも賃金が発生するようになってほしい。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@pokarim 自分も実態がよくわかっていないのですが、取次ビジネスが危機的なので取次がわとしてはやらざるを得ない状況だが、基本的には不要な存在には見えます。電子取次が出てきたことで、取次ビジネスの再定義をしようとしているように見えるのですが、従来の取次に比べると付加価値を生み出す基盤は脆弱だと感じます。
このアカウントは、notestockで公開設定になっていません。
ソースコードへのコメントはプログラム構造に沿った形の記述しかできないので「過去にぜんぜん違う構造だったコードについての評価と解説のログ」みたいなのは残せない。そういう点でやっぱりソースコードそれ自体はあくまで(日々変化する環境の中に身を置くプロジェクトの) スナップショットでしかなくて、時間という構造に沿ったコメントとしてのコミットログは代替できない価値を持っているように思う
コミットログ、実際の作業経路とは異なった形で再構築することがけっこうある。インデントを揃えるのは単独のコミットで、そのあとにコードの修正を別コミットでやるとか。diff としての見易さにそって再構築する。
私も基本的に feature ブランチみたいなのはどんどん rebase/fixup/edit していって、意味的に小さくまとまったきれいなコミット群として再構築してから merge するようにしている。こうすることでブランチ全体のレビューを個々のコミットのレビューへと分割できるようになる (もちろんその際分割が適正か、悪意がないかは別途疑う必要はあるが)
「コードを読む」ということと「差分を読む」ということで、ピックアップしたい情報の性質がかなり違っているとおもう。コードを読むときにはコード間の関連とか論理的な仕組みとか読んでるとおもうけど、差分を読むときに読みたいのはビジネス的な経緯なんじゃないかな。
とはいえ、ヒストリがもう少しコードベースと統合された感じになっていてほしいというのもわかるにはわかるんだよなぁ。現状いろいろなものがソースコードに対してメタな存在でありすぎる (典型的には ticket tracking system のチケット)
わかるけど、ソースコードから見るとビジネスとかなんとか、いろいろソースコード外部の存在なのは間違いなくて、コード表現が必要ないものもたくさんある。コード上には変化があらわれないが、ビジネスとしては位置付けが変わっており、コードから読みとられるべき意味が変わってしまうこともあるとおもう。
プーチン、あいかわらず西側の責にしているけど、敵を外部に設定することで結束を強調するのってけっこう古典的だな。
内部の結束があまりに脆いことを露呈した事件だとおもったけど...。
https://www.bbc.com/japanese/66017202
戦争、敵を作りだすことによって、内的な分裂に統一をもたらすのが目的になることが多いな...
このアカウントは、notestockで公開設定になっていません。
発生した不具合の調査レポートを書くの、
物語の謎解き回を書いてるみたいで結構楽しいんだよね
他人が仕込んだバグだからｗ
