yutakat さんはインスタンス mstdn.techdrive.top のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。もしお持ちでないなら こちら からサインアップできます。

#老害 の戯言ですけど、個人的にいま習得したい文章技術は「文脈次第でどうとでも取れる文章を故意に繰り返し使う、ただし意味はどれも全く違う」ですかね。

典型的なのは今はなき笑っていいともの「そうですね」とかですが、映画とかでもセリフ量が限られてることもあり、別の人に同じセリフを別の文脈で言わせたりすると効果的に前提の変化を伝えられたりします。

欠点としては有効なシーンが限られていて、文語体の技術的な文章ではめったに使えないテクニックなので残念というかなんで俺それを覚えようと思った?

「きっちりとした文章」って要するに継承元のテンプレートクラスがあって、そこに埋められてるだけですよ。
起承転結でも序破急でもいいけど、そこにはあまりバリエーションがない。

そういう意味ではプログラミングに似ているとも言うけど、プログラミングと文章表現を同一視できる人はなかなかお目にかからない。

あとね、すっごく重要なんだけど

「一度使った単語はよほど汎用性があるものか、無いと絶対に意味が通じないか、重要なので2度言いましたじゃない限り使わない」

これだけですごい効きます。
要するに人間の知覚効果に対するハッキングではあるんですが、繰り返しのないことで文章に深みが出る感じがするんです。

重要な単語も、並べて使うのではなく、各段落に散りばめるのがいいです。

昨日のAlphaZeroの話は、Aivs人間というより、AIを実装するにおいて抽象化された既存の人間行動の知見から人間が学ぶというもので、プログラミングの背後にある哲学のようなものの話ですね。

例えばCivilizationは歴史をもとに作られたゲームですが、この「たかがゲーム」からはSid Mayerやその後継者たちが歴史から学んだ知見があり、その知見を通じて歴史のメタな意義を学ぶことができます。

なお、Civilizationの利用に当たってはその中毒性に十分留意し、重篤な副作用があることを了解の上、人生を棒に振る覚悟でプレイしてください。
使用されたことによって生じた不利益(衰弱死、離婚、解雇、人間の屑と蔑まれる)等について、当方は一切の責任を負いかねます。

Repository Patternねえ。
Interfaceを使って実装を隠蔽し、Lookupで柔軟な切り替えを可能にする、というロジックはたしかに美しい。
反面、実装を隠蔽するためのテクニックを駆使したり(コード書くだけなら楽しい)過剰なレイヤを作ってしまうので性能面やメンテナンスでは不利。

大半のケースにおいて結局必要なのは固定されたI/Fと1つの実装にすぎないので、それって要するにヘッダさえあればよくね?という話になってしまうと思うんですが。

C言語偉大だわ。

--
Scalaで最強のRepositoryパターンを実装する ~①howとwhatの分離~

qiita.com/YuitoSato/items/730a

#老害 が勝手に思索メモを書き散らかしますが

AlphaZeroの「探索木を通じて自己学習する」というのは人間にとっても非常に有用な手法だ、ということに思い当たっています。

といいますが脳は自動的に自分が得た結果をもとに自己学習するので、単純に優良な探索アルゴリズムを身につけ、それに従って探索するという訓練で、探索じゃない直感部分のアウトプットを改善できるよね、という。

問題はどうやって過学習を避けるか、優秀な探索木を学ぶか。

っていうか人間の自己学習アルゴリズムを解析してAIに適用してるわけだから、有用で当たり前ですね、サーセン。

一つのプロジェクトを完遂するにあたって、要求されるコード品質というのは大きく異なる、というのは個人的な実感ですし、みなさんもそうでしょう。
カーネル的なコードやI/F定義は堅牢である必要があるし、モジュール的なコードは柔軟かつ定形な必要があるし、モジュール間結合的なコードはすり合わせのやり指すさが重要だし、ユーザーの手に触れる部分は頻繁に書き換わるし、要件が頻繁に変わるときに吸収できる層がないといけません。

とか適当に書きなぐってみたけど、こんなの理解してプロジェクト動かせるの神だけですよね。

超絶厳しいことを言いますが、アーキテクチャに責任を持てる立場にある以上、誰かにタスクがアサインされた時点で、出来上がってくるコードのイメージができてないと駄目です。
新人君をアサインしたなら、完成品のコードはコピペで仕上がっていても当たり前なのです。誰にアサインしても自分の好みのコードなんて絶対出てきません。

レビューで指摘できるレベルって、結局
・想定に足りない部分
・想定にプラスアルファできる程度
・想定ではできないけど、できてないと困る例外処理とか

でしかないのですから、最低限考慮が足りてない部分とかサボってる部分以外は「このコードにどんなスパイスを入れれば最低限食えるようになるか」という視点が必然的に必要になります。

そのへんはコストとの兼ね合いなのですが、当然「ここは金をかけてでも堅牢に」とか「ここは比較的重要じゃないから」とかそういうトリアージもふくめた考えがtech leadという地位には求められると思っています。

PG35歳定年って要するに大企業正社員の年功序列から導き出される定理なので、ぶっちゃけ提唱され始めた当時(30−40年前)ですらフリーランスや中小企業には関係なかった。

IT業界においては概ね大企業病になるほど発展する前にバブルで年功序列の定着は夢と消えたので、実際にPG35だか40歳定年ってあまり定着しなかったと思う。
とはいえ、定着しないことによりブラック化が進行して米国に大きく遅れを取ったわけでどっちが良かったとは言えないけど。

コード書かないと禁断症状、はもうとっくに克服したな。すべてを諦めたとも言う。

Qiitaの利用規約、9条2項に「ユーザーは、当社に対し、投稿内容について、無償にて利用(複製、複写、改変、第三者への再許諾その他のあらゆる利用を含む。)する権利を許諾するものとします。」とあるので、基本的になんでもありな権利をすでにQiitaに付与するのが前提としてる。コンテンツサービス業者としてはこんなもの。

こんなものの良し悪しについてはここでは論じない。

いまでも一般教養の一部です。
--
15年目のVim

postd.cc/vim3/

あー、pinafore + このmstdnインスタンスだと投稿はできない!(JSのエラーが出るけど理由は知らない。バージョンが古い?

Mastodonクライアントだけど、軽くていいわ!(そんなに話題の流れるインスタンスにいないことから目を背けつつ

--
pinafore.social/

珍しくMastodon急成長という明るい?話題。ある意味正しい使われ方というか。
--
セックスワーカーのためのSNS「Switter」が急成長

itmedia.co.jp/news/articles/18

ああそうか、twitterの議論の何が嫌いって、(短いから)結局みんな結論しか書かないので、言いたいこと言っておしまいになりやすいところか。

Togetterやモーメントは確かにサマライズとして優れているんだけど、システムとして自動化統合されてない点がマイナスポイントかな。
まとめサイトがキュレーターの意志で歪むように、結局良い総括ではなく、編集そのものが生む悪癖から逃れられてないというか。

ああそうか、過去ログのマージはproof of work形式というか、発言者に仕事を課せばいいのか。メモ書き保管に使わせてもらいます。

- アカウント登録制(表示上は匿名可能)チャンネル制
- ユーザはポイントを消費して発言ができる。ないと発言すらできない。
- 同様にポイントを消費してブランチを切れる。親のブランチから新ブランチは1発言として見れる。
- ポイント回復には「サマライズ協力」が必要。過去ログから重要と思える部分を探してそこを「マーク」する。
- 経過時間ーマーク数に応じて、過去発言はどんどん小さくなり、最終的にはアーカイブされてしまい見えなくなる。発言としてのブランチは独自の計算方法をもつ(発言数が多いと大きく見えるとか)が、やはり見えなくなってアーカイブされる。

・・・すごい承認欲求にまみれたチャットになりそうだが、我ながらかなりslashcodeに影響を受けてるな。

あれ送っちゃった。

マイクロブログは刹那的なIRCでもなければ、重厚な「お題」があるブログやらスレッド掲示板とも違う、中途半端なポジションがあって、それはそれでいいと思うのです。ただ雑に書き殴られるだけではコミュニティは発展しないし、一方的なspammingではない「参加」の意義=何らかのフィードバックがないと、やはり養閑古鳥場まっしぐらではないでしょうか。

私自身の思索は常に「マイクロブログやIRCのような軽さを失わず、一方で重い手法に負けない程度に良い結論を導き出せる方法とは何か」という難しい妥協点に向いているので。

Twitterは例外的なすごい発展だったと思いますが、普通のマイクロブログにはやはり共有ブックマークみたいな何かがいるんじゃないかな、と。

@ms2sato まあ雑談なら雑談で重くないほうがいいわけで、そうするとIRCだかSlackだかみたいなものがいいよね、で済んでしまうと思うんですよ。

スレッド型が生きるかというと単純なスレッド型が死屍累々なのは私もよく知っていて、マインドマップ的な放射状のツリー型モデルから発展するとしても、見せ方を大きく変革しないと駄目だろうな、というふうには思います。

久々にこの議論を思い返して今思いついたのは、2つの技術的なアプローチをもとにしたもので、

1.ブランチ式
 言い方を変えれば「gitのcommit logみたいな掲示板を作ろうぜ」という話でもあります。
 twitterのin-reply-toも似たような話でもあるのですが、やはり個人のやりとりを見るためで、複数人が入っていくものではあまりない。
 いっそ明示的にブランチ切っちゃうUIにすればどうですかね?そうしたトピックに特化した会話ができます。

2.過去ログの「マージ」
 DBの世界で有名なアルゴリズムにLSM木があります。最初はいろんなデータがいろんな場所に混在していても、直近でない古いデータは「マージ」することでアーカイブ化し、格納効率(と検索効率)を高めるものです。ブランチ型掲示板における過去ログのマージとはつまり「今北3行」的要約じゃないかなと。
 機械的要約は可能としても、実際に要約ってどうするんですかね。StackOverflowやslashdotはモデレーションがその役を果たしますが。