  |
はてなキーワード: インスタンスとは
この人が言いたいことは分かりすぎるくらい分かる。自分の配属先は割とモダンでイケイケな感じ(詳細は末尾※)だったけど、元記事の人と同じくつらい境遇にいる同期もいたので。
自分の場合は配属先の居心地が良かったものの、当時の会社全体に対するイメージは「現状維持してるだけの会社」って感じで、将来は暗いなと思ってた。
自由で進歩主義的な感じになった。まず、服装が自由になった。社員の自立性を尊重したいという社長の意思をビデオメッセージで聞いた時、私は心の中で拍手した。スーツを着るのは、会社からモノ扱いされてる感じがしてキラいだったから。
そして、ジョブ型が導入されて、給与は年齢ではなく職責に基づくようになった。これで、年齢だけで年功序列ピラミッドの上位に居座ってる非管理職は実質降格になったらしい。ジョブ型の関連で社内異動・マッチングの仕組みも導入され、目指すキャリアを実現しやすくなった。自分の部署にも年に数人社内異動でやってくる。
あと、エンゲージメントスコアが計測されるようになった。これは、従業員がどれだけ楽しく働いているかというメトリクスであり、四半期ごとのアンケート調査によって計測される。この値はマネージャーの評価に直結するから、マネージャーはチームの働きやすさを改善するためにチームとディスカッションして具体的なアクションを取るようになった。
このディスカッションは結構良くて、意味がわからんルールを廃止したり、新しいツールを導入したり、フルリモートの中でコミュニケーションを図るためのアイデアを出し合ったり、結構有意義な時間になってる。
という具合で、富士通は時田社長の強力なリーダーシップのもと改革を断行しており、現場レベルでもその改革の効果を感じている。4年前に比べて富士通の株価は2倍以上になったが、市場の受け止め方も私の感覚と一致している。
まだまだレガシーな部分はあるし、SI中心のビジネスモデルに未来はあるのかなど色々思うところはあるけど、これからも改善していくだろうなという感覚はある。
いろんな考えを持った社員がいると思うけど
以上、一社員の声でした。
---
(※)
もとの記事では Git 使ってないとかマシンが貧弱とか色々書かれてたけど、完全に配属ガチャだなぁ...と思った
私の配属先では、GitOps し、CI/CD し、スクラム開発し...と(社内では)比較的モダンな開発をやってたり、業務時間に社外のカンファレンスを聴講しにいったり、勉強会があったり、クラウドの GPU インスタンスで遊んでよかったり...と、元記事の方とは真逆の環境だった。
元記事の人が言いたいことは分かりすぎるくらい分かる。自分の配属先は割とモダンでイケイケな感じ(詳細は末尾※)だったけど、元記事の人と同じくつらい境遇にいる同期もいたので。
自分の場合は配属先の居心地が良かったものの、当時の会社全体に対するイメージは「現状維持してるだけの会社」って感じで、将来は暗いなと思ってた。
経営層が自由で進歩主義的な感じになった。まず、服装が自由になった。社員の自立性を尊重したいという社長の意思をビデオメッセージで聞いた時、私は心の中で拍手した。スーツを着るのは、会社からモノ扱いされてる感じがしてキラいだったから。
年齢だけで年功序列ピラミッドの上位に居座ってる非管理職は実質降格になった。ジョブ型の関連で社内異動・マッチングの仕組みも導入され、目指すキャリアを実現しやすくなった。自分の部署にも年に数人社内異動でやってくる。
これは、従業員がどれだけ楽しく働いているかというメトリクスであり、半期ごとのアンケート調査によって計測される。このスコアはマネージャーの評価にも関わるらしく、マネージャーはチームの働きやすさを改善するためにチームとディスカッションして具体的なアクションを取るようになった。
このディスカッションは結構良くて、意味がわからんルールを廃止したり、新しいツールを導入したり、フルリモートの中でコミュニケーションを図るためのアイデアを出し合ったり、結構有意義な時間になってる。
富士通は時田社長の強力なリーダーシップのもと改革を断行しており、現場レベルでもその改革の効果を感じている。4年前に比べて富士通の株価は2倍以上になったが、市場の受け止め方は妥当だと感じる。
一方、まだまだレガシーな部分はあり、部署によっては元記事同然のところもあるだろうし、改革は道半ばだとは思う。
いろんな考えを持った社員がおり、私のこの投稿も生存バイアスがかかってるんだけど、一社員の声として。
(※) もとの記事では Git 使ってないとかマシンが貧弱とか色々書かれてたけど、完全に配属ガチャだなぁ...と思った
私の配属先では、Git を使い、CI/CD し、k8s でマイクロサービスしたり、スクラム開発し...と(社内では)比較的モダンな開発をやってたり、業務時間に社外のカンファレンスを聴講しにいったり、勉強会があったり、クラウドの GPU インスタンスで遊んでよかったり...と、元記事の方とは真逆の環境だった。
Twitter時代にトランス差別運動を見聞きするのがキツくなって以来、半年以上Mastodon系の個人インスタンスとかに籠ってて最近のX情勢を知るための取っ掛かりもないので誰か教えて欲しい。
と言う辺りなんだが、他に何か目立った話ってある？
ちなみにMastodonとかで起きた面白話って言うと、正直 Misskey.io ぐらいしか追い掛けてないんだが、
と言うぐらい。
マストドンは、現在利用可能な多くの Twitter 代替手段の 1 つです (他には、Threads や Bluesky などを聞いたことがあるかもしれません)。私はマストドンを使い始めていますが、非常に楽しんでいます。ここでは、あなたも試してみることに興味があるかもしれない理由のリストを示します (そしてサインアップ (ttps://mastodon.social/) することでそうすることができます)。
1. 広告は無いほうがいい
マストドンは広告収入によって支えられていないため、有料広告や宣伝広告がタイムラインに強制的に表示されることはありません。
マストドンには、フィルター(特定の単語を含む投稿を非表示にする)、一時的なミュート(ユーザーからのコンテンツを一定時間「一時停止」できる)、自分のコンテンツを見ながら人々から「ブースト」（「リツイート」に相当）を非表示にする機能、（見たくない人や交流したくない人に対する）無制限のブロックがあります。そしてツイッターのような「アルゴリズム」はありません。アルゴリズムというのは、あなたが興味を持ちそうなものに基づいて、他の誰かがあなたのタイムラインにコンテンツを押し込んでいるのです。
3. 分散化
しばしば予測不可能な所有者の気まぐれに左右される他の多くのソーシャル メディア プラットフォーム (Twitter などを参照) とは異なり、Mastodon が構築されているプロトコルは分散化されており、コンテンツを制御する単一の個人や団体は存在しません。
プロモートされたコンテンツをタイムラインにプッシュするためのアルゴリズムや金銭的インセンティブがないため (上記の項目#1と#2を参照)、ユーザーが慣れ親しんでいるような、エンゲージメントを促進するために設計されたノンストップの「怒りを煽る行為 https://gizmodo.com/10-internet-rage-baiting-techniques-to-know-about-1850615967 」ははるかに少なくなります。
5. あなたのコンテンツに実際に興味を持っている人々のフォローを構築できる
ソーシャルメディアでフォロワーを増やすのは難しいことを知っています。あなたがソーシャルメディアの「群衆」のために「パフォーマンス」するのが好きなタイプでない場合、さらに困難です。Mastodonではありのままでいられます。
全体として、マストドンでの会話は、LinkedIn を含む他のソーシャル メディア プラットフォームよりもはるかに礼儀正しく、思慮深いものであることがわかりました。ランダムに返信に現れてあなたに怒鳴ることなく、微妙な議論をすることは実際には可能です。そして、そのような行為に関与したくない場合は、その人をミュートまたはブロックするツールがあります。
主にボランティアのコミュニティメンバーによってモデレートされているにもかかわらず、マストドンのコンテンツモデレーションは非常によく行われています。これは、 TwitterやBluesky でさえ現在起こっていることとはまったく対照的です。マストドンでは「コミュニティを守る」ことが最優先事項です。
Twitter (現在、特定の機能を利用するには月額料金が必要です) や他のソーシャル メディア プラットフォーム (広告主と共有されるユーザー データの形で料金が発生します) とは異なり、Mastodon のすべての機能を使用するのに月額料金は必要ありません (いつでも好きなときに投稿を編集できることも含まれます)。サーバー (「インスタンス」とも呼ばれます) を管理している人への寄付は、もちろん推奨されますが、必須ではありません。
色々試してはいるけど、ここに永住しよう、と思えるところは見つかっていない。
リアクションが豊富で、FF外でもリアクションする文化なのは楽しい。
ハッシュタグの文化があまりなく、検索機能も弱めなので（多分）、ある事柄について言及するノートを探そうとしても難しい。
費用と手間をかけて運営していただいてることには感謝しかないが、運営が変な方向に走りそうな時に是正する力が働くかは、やや不安。
中学生を描いたイラスト（非NSFW）に「ハイエース」のリアクションがたくさんついたりする空気はちょっときつい。
Misskeyのアカウントで個別のユーザーはいくつかフォローしているが、全体の雰囲気は知らない。
いま入ってるサーバーは、①なんでも話せる少人数の内輪のものと②特定ジャンルの大規模なもの複数。
なんでも話せる比較的規模の大きなところがあれば入りたいが、探しきれてない。
良さそうだが、個人運営なので、より大規模になってきた時にどうなるかの不安はある。
はてなハイクの後継。
雰囲気は良さそう。
私の環境だと、注目のキーワードを一瞬しか見ることができず、全投稿のTL的なものを眺めるしかできない。
（使い方が間違ってるのかもしれない）
Twitterの代替の地位を確立して非キラキラ系アカウントもたくさんいるようになったら、試してみたい。
（現状どうなのかはよく知らない。）
気に入ってはいる。
当たり前だが、元記事がないとコメントできず、日常的なつぶやきができないので物足りない。
増田よりは個を出したいし、はてなブログよりは気楽に書きたい。
知り合いもまだたくさん残っているので、しばらくは使い続けるつもり。
ただ、今後、サービスが悪化する気しかしないので、引越し先は確保しておきたい。
いつまで経ってもリリースされない、というネタすら古びてきた感のある幻のSNS。
※参考
オタクはいつまでもTwitterにしがみついてる場合ではない。分散型SNSにアカウントを作れ。現状は特にActivityPubに対応する分散型SNSだ。MisskeyでもMastodonでもいい。自分に合うサーバーに入れ。ノリが合うサーバーが見つからないならお一人様インスタンスを立てろ。もう何ならWordPressで個人サイト作ってActivityPub関係プラグイン入れるでもいい。
というのもThreadsはActivityPubと互換性を持たせる予定だからだ。
「Threads」では、分散型（非中央集権型）のソーシャル・ネットワーキング用のプロトコルである「ActivityPub」と互換性をもたせる予定。メタとして初めてオープンなSNSプロトコルとの互換性を想定したアプリになるという。
これにより、MastodonやWordPressなどActivityPubプロトコルをサポートするほかのアプリと相互運用できるようになる。公式では「ほとんどのSNSで不可能な、新しいタイプの接続が可能になる」としている。ほかのアプリでは、TumblrなどがActivityPubをサポートする意向を示しているという。
互換性があるアプリを使っていれば、Threadsのアカウントがなくとも、Threadsユーザーをフォローし交流できるようにする。
あわせて利用をやめる人に向けて投稿した内容をほかのサービスで使えるよう、コンテンツを転送するオプションの提供も計画されている。
公式ブログは「メールやWebを管理するプロトコルに似た分散型のアプローチがオンラインプラットフォームの将来に、重要な役割を果たすと信じている」とつづる。
つまりThreadsに推しコンテンツの公式アカウントが出来た場合、Misskey等のオタク向けインスタンスに住みながら公式アカウントをリモートフォローして公式の投稿を拡散する、みたいなことが今後出来る。
オタクはドブ川に沈みながら、公式は比較的キラキラした別の場所に住める。
公式アカウントだけでなく、他の分散型SNSにいる全ての自分がフォローした好むアカウントの投稿が口を開けてるだけでホームTL流れ込んでくる。
現状のTwitterが今から分散型に乗っかるとは思えない。ていうか後から乗っかれる金が無い。逆にメタは後からでもActivityPubだけじゃなく他の分散型プロトコルにだって（そっちがでかくなれば）乗っかってくる……と思われる。
公式が分散型SNSにアカウントを作った時、Twitterから余計な一言を足してそのリンクを張るのか？ いいや分散型SNSのアカウントから一次情報の公式の投稿をそのまま拡散すべきだ。公式アカウントの投稿を正しく拡散できるのは、分散型SNSにアカウントを持つオタクなのだ。そういうわけでどこでもいいから分散型SNSに席を作るべきだ。最近は流入が多く、良いサーバーは新規登録停止してる場合も多い。
同じTwitterという場所に公式アカウントや関係者が居ながらエロBL二次創作の話がワンクッション無く流れてくる、そういう状況が嫌だと思う人は居るはずだ。その状況を今より軽減出来るのが分散型SNSなのだ。
サンは森で、私はタタラ場で暮らす。その場合、サンが森で投稿した絵を見るにはまず森に行くしかなかったが、分散型SNSではサンが森で投稿した絵がタタラ場で見れるし、タタラ場の人達に広めることも素早く出来るのだ。あとサンが自分で森以外のところに投稿する手間も省ける。
でもTwitter民は分散型SNSについて、キモいねー、ほらこんなこわいところもあるんだよー、Twitterがやっぱいいよねーって言い続けてる。なんでだよ。
「分散型って投稿を消そうと思っても完全に消せないんでしょ？」
→それはTwitterでも同じだ。魚拓を取られたりアーカイブ化されたり自動でTwitterの画像を無断転載しまくってるサイトがある状況で、Twitterの投稿は自分が削除すれば全部削除されるなんて幻想である。オープンなネットに公開した時点であらゆるものは取り消せないし自分の意志と関係なくネットに流れ続ける。Twitterであろうがどこであろうがそう思って投稿するべきだ。あとは投稿する際に連合に流さない設定にすればそのあたりの不満は多少は軽減されるかも。もちろん完全ではないけど。
→それはMisskeyのioサーバー限定のノリだ。別のサーバーに行け。オタク向けのMisskeyなら他ににじみす.moeやお絵かきすきーなどがある。Misskeyとはソフトウェアのことで単一のSNSのことではない。カスタム絵文字はサーバーによって登録されているものは全く違うし、サーバーの空気もそれぞれ違う。ローカルTLやソーシャルTLが無いサーバーもある。サーバーごとの雰囲気はハイライトを見るなどすれば掴みやすいはずだ（ログインしなくてもhttps://サーバードメイン/exploreのアドレスで見れる）。Misskeyのカスタム絵文字がギラギラしてて疲れるならCSS追加でカラムごと非表示にする（GitHub - kanade/misskey-css: Misskey用カスタムCSS）こともできるが、Mastodonに行くといいだろう。Pawooサーバーは企業が運営しているので個人サーバーよりはいくらか安心出来るかもしれない。合うところが無いと思ったなら自分しかいないインスタンスを立てればいい。単なるhtmlの個人サイトを作るよりもいい。どの連合サーバーでも、お一人様サーバーだとしても、他のサーバーや他のシステムにいる人をリモートフォローし合える、それが分散型なのだ。
「Twitterは色んなジャンル違いの人の話やドブみてぇな投稿やオタクの日常等が雑多に見れる、それはTwitterにしかない」
→そういう状況は分散型SNSのほうがよほど構築しやすい。構築しなくても日本人が多い分散型SNSの殆どのローカルTLはジャンル違いのオタクの話と日常とドブみてぇな投稿が雑多に流れている。Twitterにしか無いものがあるとするなら現状の日本人ユーザー数と日本企業日本行政アカウント数ぐらいなもので、後は寧ろマイナスだ。
→それはそう。Twitterにしか無いものといえば日本人ユーザー数と日本企業日本行政アカウント数だけだと言ったが、それこそが肝心要だと言われればその通りでしかない。
そんなわけでみんなでどこでもいいから分散型に行け。ていうかオタク向け企業は出来ればスレッズ等の大手にアカウント作って、オタクはミスキーやマストドンに行ってくれ。フォロワーがそれぞれのサーバーやシステムに散らばっていたとしてもフォローし合える、それが分散型の強みだから。いっせーので全員が同じSNSに移動することは無いだろうが、いっせーのでそれぞれに合う分散型SNSに移動することは可能なはずだ。
そして上記の記事にあるように、分散型SNSは別サーバーやシステム等にアカウントをうつす等の機能が実装される可能性が高い（ミスキーなどは実験版ではあるが既に実装している）。投稿やフォロワーを引き継いで他の場所に引っ越すことが出来る。Twitter上での長年の繋がりを断ちたくないという人は多いと思うが、分散型SNSに席を置いておけば今後は「そのSNSが気に入らなかったらフォロワーと投稿を引き継いで別の場所に引っ越す」が可能になるのである。
分散型SNSが主流になればTwitter以上の便利とゆるい繋がりと棲み分けが我々に待っているはずだ。そして時代の潮目は分散型SNSに来ているのである。とりあえずアカウント作って公式をリモートフォローする準備をしておけ。
「Threadsまだ分散型対応してないんでしょ？ 対応してからでもよくね？」
→……まあ……正直そうかも……
フォローしてない発言がタイムラインに流れてくるのは、ちいかわが何をフォローしたらいいかわからず「何も流れてこなくてつまんなーい」って離脱するからやぞ
っていうか分散型SNSもインスタンスによってはグローバルタイムラインっぽいものが存在する世界だから、フォロー外のものはバンバン流れてくるぞ
misskey.ioの話なんだが、Twitterからの流入は続いていて、現在は新規登録を停止。
でこの招待コードは600円以上支援で、かつ人数限定している。
https://twitter.com/misskey_io/status/1675506713959751683?s=19
そうなると当然の流れではあるが、その招待コードを転売する奴が現れる。
https://twitter.com/misskey_io/status/1675513960194535425?s=19
いやいやいやいや…
そこまでしてmisskey.ioに入りたいのか？
そんな事するより他の過疎インスタンスに入って、io鯖の人フォローした方がよくない？
現状、トラフィック多いときは本当に繋がらないし、それより過疎な汎用サーバーにでも行って他方が言い気がする。
でもそういうのには人居ないだろうって？
確かにそうだろうけど、それでも6番手ぐらいの奴まで新規解放辞めて招待制にするぐらいには流入しちゃってる。
https://join.misskey.page/ja-JP/instances
ぶっちゃけ、分散型SNSだから、一鯖辺りの受け入れにはどうやったって限界がくる。
最大手は諦めて次の鯖に登録、それが出来なきゃその次とやってかないといよいよ先がなくなるよ。
Twitter民全員が同じ鯖に入ることは出来ないんだ。
Twitterでフォローしてる誰々が行かないから自分も行かないなんてやってたら、結局この手の転売屋の餌食になるだけだよ。
そんなこと言ってる奴に限って裏で次のSNS選定終わってたりするんだろうけど。
4. 条件式と分岐
https://www.python.jp/train/if_condition/index.html
以下、気になったところ。
コンピュータのプログラムは、どんなに複雑そうにみえるプログラムでも、細かく分解すれば次の3つの単純な構造の組み合わせで構成されています。
3. 条件が満たされている間、処理を繰り返す 反復処理
重要なことがサラッと書かれている。
これは一般的に「構造化プログラミング」と呼ばれている考え方のことだ。
構造化プログラミング（こうぞうかプログラミング、英: structured programming）は、コンピュータプログラムの処理手順の明瞭化、平易化、判読性向上を目的にしたプログラミング手法である。
一般的には順接、分岐、反復の三種の制御構造（control structures）によって処理の流れを記述することと認識されている。
制御構造は制御構文、構造化文（structured statement）、制御フロー文（control flow statement）とも呼ばれる。
また、プログラムを任意に分割した部分プログラム（サブルーチンとコードブロック）の階層的な組み合わせによるプログラムの構造化も指している。
このプログラミング手法の普及に貢献したのは、1968年の計算機科学者エドガー・ダイクストラによるACM機関紙への投書「Go To Statement Considered Harmful」と言われている。
プログラムを構成する要素は、(1)データと(2)処理であり、構造化プログラミングは、このうちの(2)処理に関する話という位置付けになる。
手続型プログラミング（命令型プログラミングの一種）では、処理を
後で学ぶ関数型プログラミングでも、この３つと同じことができる動作が登場する。
参考までに手続型と関数型の基本動作について、対応関係を押さえておこう。
| 手続型 | 関数型 | 動作 |
| 順接 | 合成 | 処理をつなげていく |
| 分岐 | パターンマッチ | 処理を場合分けする |
| 反復 | 再帰 | 処理を繰り返す |
構造化プログラミングの仕組みは、文字でゴチャゴチャ説明されるよりも、目で図解を見た方が早いと思う。
Googleの画像検索で「構造化プログラミング」を検索して、分かりやすそうな図解を探してみよう。
https://monoist.itmedia.co.jp/mn/articles/1008/17/news092.html
↑ちなみに、図解で出てくる流れ図みたいなのは「フローチャート図」と呼ばれていて、プログラムの構造を紙に書くときよく使われる書式である。
値を比べる方法が紹介されている。
はてなアノニマスダイアリー（通称：増田）で記事を書く時、一部の文字はエスケープされて元々の文字を表示できない。
& → &
< → <
> → >
| 演算子 | 条件 |
| a < b | a は b より小さい |
| a <= b | a は b と等しいか小さい |
| a > b | a は b より大きい |
| a >= b | a は b と等しいか大きい |
| a == b | a と b は等しい |
| a != b | a と b は等しくない |
真か偽かを示すデータの種類として、ブール型という新しい型が紹介されていた。
ブーリアン型（ブーリアンがた、英: Boolean datatype）は、真理値の「真 = true」と「偽 = false」という2値をとるデータ型である。
ブーリアン、ブール型、論理型（logical datatype）などともいう。
2種類の値を持つ列挙型とも、2進で1ケタすなわち1ビットの整数型とも、見ることもできる。
また、各種ブール演算を行うことができ、論理積 (AND、&、*)、論理和 (OR、|、+)、排他的論理和 (XOR、NEQV、^)、同値 (EQV、=、==)、非同値 (NEQV、<>、!=)、否定 (NOT、~、!) などの操作が可能である。
ブール代数（ブールだいすう、英: boolean algebra）またはブール束（ブールそく、英: boolean lattice）とは、ジョージ・ブールが19世紀中頃に考案した代数系の一つである。
ブール代数の研究は束の理論が築かれるひとつの契機ともなった。
ブール論理の演算はブール代数の一例であり、現実の応用例としては、組み合わせ回路（論理回路）はブール代数の式で表現できる。
cf. 「Boolean」の翻訳を「論理型」とすべき3の理由 – Kenchant
https://senooken.jp/post/2016/03/21/2571/
プログラミング言語やHTMLのようなマークアップ言語などプログラミングに関する文書を呼んでいるとboolean（ブーリアン）という単語に出くわす。
Booleanとは真（True）と偽（False）という2値をとるデータ型のことである。
情報元によって、このBooleanの翻訳や呼び方が異なっている。以下のように呼ばれたり訳され、最後に「型」や「値」がついたりつかなかったりする。
このBooleanの呼び方としてどの訳し方がよいか気になったので調べた。
その理由は以下3点だ。
文字列同士の比較では、人間の感覚とはことなった比較結果となる場合があるので注意してください。
一般的には、半角の数字やアルファベットの比較は、次のような結果になり、安心して利用できます。
1. 数字は、文字の0が最小、9が最大(0 < 1 < 2 < ... < 9)
2. アルファベットでは、a が最小、z が最大 (a < b < c < ... < z)
3. 大文字は小文字より小さい (A < a, B < b, ...)
文字列の大小の比較に、ユニコードという文字一覧表を使っており、その文字コードの大小で比較しているという種明かしをしないと意味が分からないと思う。
種明かしをしていない、という意味で、この説明もあまり良くないと思った。
cf. python 文字列の比較 | Hello, Pygineer
文字列 (str のインスタンス) の比較は、文字の Unicode のコードポイントの数としての値 (組み込み関数 ord() の返り値) を使った辞書式順序で行われます。
抽象文字のレベルで (つまり、人間にとって直感的な方法で) 文字列を比較するには unicodedata.normalize() を使ってください。
文字列の比較は、一致か不一致かを調べる場合が多いと思うので、大小の比較はあまり気にしなくても良いような気がする。
if 条件式:
処理1
処理2
...
Pythonの書き方を特徴付けている１つが、この「インデント記法」
if 文の書き方
条件式の後ろに、: 記号が必要ですので、忘れないように気をつけてください。
if 条件式: の次の行から、条件式が True となった場合に実行する処理を記述します。
インデント
条件が満たされたときに実行する処理は、行の先頭に スペース文字 を 4文字 入力してから記述します。
if a == 100:
処理1
処理2
処理3
^^^^
関数型プログラミング言語「Haskell」でも、Pythonのインデントと似た「レイアウトルール」「オフサイドルール」という記法が用意されている。
https://www.tohoho-web.com/ex/haskell.html#layout
Python の様にインデントを用いることで、{ ... } ブロックの { と } を省略することができます。
main = do
話を戻すと、Pythonではインデント（字下げ）が文法的に意味を持っており、省略できないということ。
Pythonでは、１つのブロック（コードの塊）をインデントの位置で束ねている。
他のプログラミング言語では、ブロックの開始と終了を表す記号（「{」と「}」など）がよく使われたりするけど、Pythonはその代わりにインデントを使う。
外見は見やすくなるけど、逆に言えばインデントを間違えたら、コードの意味が変わってくるので、長所と短所を両方併せ持った記法とも考えられる。
元々、Pythonは教育用途の言語としたスタートした歴史があるので、可読性を重視しており、誰が書いてもある程度同じようなコードになることが求められている。
その要求に対する答えの１つが、インデント記法ということだったのだろう。
関数型プログラミングの考え方を参考にする場合、if文を使った関数はelse節を省略しないで、Trueの場合でもFalseの場合でも、必ず戻り値を返すように設計しておいた方が良いと思う。
ifも文ではなく式として見るならば、評価した結果を必ず返すようにしておく必要がある。
（副作用の有無に関わらず）TrueでもFalseでも、必ず値を返すようにしておけば、戻り値なし（void）を避けられる。
これは後々、例外処理の書き方などで効いてくるので、Pythonでもif文でelse節を省略しないで書けないか？考える習慣を身につけておきたい。
特になし。
特になし。
無学無才のポンコツが、1か月でプログラミングを習得できるか？実験してみます。
Kyoto University Research Information Repository: プログラミング演習 Python 2021
https://repository.kulib.kyoto-u.ac.jp/dspace/handle/2433/265459
です。
図目次
表目次
プログラム目次
演習目次
0.3 文科系がんばれ
0.4 本書の構成について
0.5 本書での表記
0.6 コピペに注意
0.7 2020 年度版からの変更
謝辞
1.1 この章の目的
1.3 コンピュータの仕組み
1.4 プログラミング言語
1.6 さまざまな応用
1.7 プログラミングの学び方
1.9 プログラムの「どこ」を作るか
参考文献
2.3 準備
2.4 IDLE の起動
2.7 Anaconda Prompt での作業フォルダの設定
2.9 拡張子の表示
参考文献
3.5 代入演算子
3.8 例題：平方根を求める
3.9 割り算に注意
参考文献
4.3 リストとは
4.4 リストの生成
4.5 メソッド
4.7 負の添え字とスライス
4.8 リストへの追加，結合
4.9 リストの代入と複製
4.14 タプルと辞書
5.2 for 文による繰り返し処理
5.3 while 文による繰り返し
5.4 if 文による分岐
5.10 力試し
7.5 返り値
7.6 前章の例題から
8.2 モジュール
8.3 Turtle ―由緒正しき亀さん
8.5 使ってみよう
8.7 複数のタートルを動かす
8.8 作品作りのためのヒント
8.9 Turtle Demo
参考文献
9.5 tkinter の例題(tkdemo-2term.py)
9.8 lambda （λ）表現を使った Call Back 関数の記述
参考文献
12.4 まずは動かしてみよう
12.6 例題１ 波の近似
13.2 プログラムを開発するということ
13.6 力試し
14.2 import 時の別名
14.3 NumPy
14.4 Matplotlib
14.5 pandas
14.6 課題
参考文献
15.2 振り返り
15.3 守破離
15.5 モジュール等の追加
15.6 本書で紹介しなかった話題
15.7 感謝と恩返し―学んだことをどう活かすのか
16.2 ファイル名に注意
世間一般的に読みにくいコードというと、コメントついてないとか
名前が狂ってるというのは、
JSONParserとか言いながらJSONが関係していないクラスとか、
getUserみたいなメソッド名なのに引数としてuserを渡すとかそういうやつ。
JSONParserクラスの名前を付けた奴は、中のコードからすると、
どうもネストした連想配列のことをJSONだと思っていたらしい。
ネストした連想配列から個別の値を取得するのがJSONParserだった。
文字列を受け取って、ネストした連想配列を返すparserメソッドが
あるクラスであればJSONParserという名前で合っている。
getUserはuserIdフィールドだけ値を設定したUserインスタンスを
書いた奴は、データベースから値を取得するのをgetだと思っていたのだろう。
https://arxiv.org/pdf/2305.00833.pdf
Learning to Reason and Memorize with Self-Notes
大規模な言語モデルは、限られたコンテキスト メモリと多段階の推論に苦労することが示されています。
モデルが自己メモを取ることを可能にすることにより、これらの問題の両方を解決するための簡単な方法を提案します。
最近のスクラッチパッド アプローチとは異なり、モデルはいつでも入力コンテキストから逸脱して明示的に考えることができます。
これにより、モデルはコンテキストを読み取りながら情報を想起し、オンザフライで推論を実行できるため、メモリが拡張され、複数ステップの推論が可能になります。
複数のタスクに関する私たちの実験は、推論時に自己メモを取ることにより、トレーニング設定からより長く複雑なインスタンスに私たちの方法がうまく一般化できることを示しています.
1. イントロダクション
Transformers (Vaswani et al., 2017) および同様のバリアントは、シーケンスベースのタスクで印象的な結果を示しています
特に、GPT-3 (Brown et al., 2020) などの大規模な言語モデル (LM) はトランスフォーマーを使用し、質問応答 (QA) などのさまざまな NLP タスクを解決できます。
LM を QA タスクに使用すると、図 1 (上) に示すように、事実情報と質問を含むコンテキスト プロンプトが与えられ、モデルが直接回答を生成します。 ただし、この自己回帰の「ワンステップ」アプローチは、複数ステップの推論タスクと格闘します (Austin et al., 2021; Press et al., 2022a; Creswell et al., 2023)。 これは、バニラ LM が各トークンに対して固定された計算を行い、現在のコンテキストに応じてさらに「考える」オプションがないという事実から生じると主張します。 (2021) 図 1 (中央) に示すように、モデルが質問に答える前に推論トークンを生成できるようにするスクラッチパッドの使用を提案しましたが、完全なコンテキストと質問を読み取った後です。 同様に、一連の思考を促す方法 (Wei et al., 2022; Zelikman*Equal Contributor 1Meta AI. への対応: JackLanchantin <jacklanchantin@meta.com>, Sainbayar Sukhbaatar<sainbar@meta.com>.et al., 2022; Huang et al., 2022) は、モデルをプッシュして、一度に 1 ステップずつ答えを説明し、より首尾一貫した最終的な答えに導きます。 非線形タスク (Fan et al., 2020)、LSTM (Hochreiter and Schmidhuber, 1997) などの再帰型先行モデルが十分に備えられているもの。 Fan et al., 2020; Ju et al., 2022; Hutchins et al., 2022)、しかし、それでも与えられたプロンプトに対して一定量の計算を使用します。 推論と状態追跡メモリがより扱いやすくなります。 私たちの方法である「Self-Notes」により、LM はオンザフライでコンテキスト プロンプトから逸脱し、明示的な推論トークンを生成できます。 図 1 (下) に示すように、スクラッチパッドとは異なり、モデルは生成されたトークンを入力コンテキストとインターリーブできます。 このようなセルフ ノートは、明示的な中間推論ステップと状態追跡用のメモリの両方として機能します。 具体的には、推論ステップで 2 つの事実を組み合わせる必要がある場合、結果として得られる推論をセルフ ノートに書き込んで、将来の推論に使用することができます。したがって、中間推論ステップとして機能します。 たとえば、「アリスは箱を持っています」と「アリスは公園にいます」が与えられた場合、「箱は公園にある」と推測してそれを自己メモに書き、将来のステートメント「鍵は in the box」で「鍵は公園にある」と結論付ける。 さらに、コンテキストをトラバースしながらモデルがエンティティの最新の状態を新しいトークンとして書き込むことができるため、SelfNote はワーキング メモリの形式として機能できます。 たとえば、プログラミング環境では、最初に x=5 を想定し、次に x を 1 ずつ増やします。モデルが x=6 をセルフ ノートとして正しく記述していると仮定すると、元の x=5 ステートメントをそのコンテキストから安全に削除できます。 モデルが x の値について問い合わせられた場合、モデルは既に答えを持っています。
私たちの提案した方法と、スクラッチパッド (Nye et al., 2021)、思考の連鎖 (Wei et al., 2022)、または内部独白 (Huang et al., 2022) などの以前の研究との主な違いは、モデルを許可することです。 各コンテキストステートメントを順番に読み取るときに、複数のメモを明示的に書き出す。 InarXiv:2305.00833v1 [cs.LG] 2023 年 5 月 1 日図 1: (上) ベースライン バニラ LM は、コンテキスト (C) と質問 (Q) が与えられると、回答 (A) を直接生成します。 (中央)スクラッチパッドを使用すると、モデルは質問に答える前に中間推論トークンを生成できますが、コンテキストが表示された後です。 (下) 私たちの Self-Notes メソッドにより、モデルはいつでも推論してメモを取るために入力コンテキストから逸脱することができます。言い換えれば、私たちのアプローチは、将来の推論に役立つ可能性のある情報でコンテキストを補強するスクラッチパッドのインライン形式です。 私たちはこれを、人間が読む方法と同様に、明示的に述べられていない情報を推測するための行間の読み取り (および書き込み) の形式と見なします (van den Broek et al., 2009)。 以前の方法では、モデルが完全なコンテキストを読み取った後に反芻することができ、読み取っている間ではなく、最後に大量の推論を行うように強制されます。
さらに、そのようなポストコンテキスト推論は、推論が開始される前に以前のコンテキストトークンがモデルのコンテキストウィンドウからすでに出ている可能性があるため、メモリとして機能できません。 たとえば、数週間または数か月の対話履歴を持つインテリジェント エージェントを考えてみましょう。 直観的には、最初から考え直すことなく、以前の対話で行った推論ステップを使用できることは理にかなっています。自己メモを生成するようにモデルに教えるために、トレーニング中に、入力の一部としてグラウンド トゥルース自己メモを言語モデルに提供することを検討します。 コンテクスト。 推論中に、トレーニング中に学習した特別なトークンを生成する場合、モデルはコンテキストから逸脱し、SelfNote を生成できます。モデルが Self-Note の生成を完了すると、元のコンテキスト トークンが引き続き供給されます。 これにより、モデルは最後だけでなく、入力トークンの処理中にメモリを推論および作成できます。 また、Self-Notes をトレーニングするための半教師ありおよび教師なしの方法も提案します。多段階の推論と状態追跡を評価するように設計された 5 つのテキスト データセットでこの方法をテストします。 , 2020; Anil et al., 2022)、および 2 つの現実世界のチェス ゲーム タスク (Toshniwal et al., 2022)。 私たちの方法は、明示的なメモ取りを行わない微調整された言語モデルとスクラッチパッドのベースラインの両方よりも優れています.2. 方法シーケンス内の次のトークンを予測する自己回帰変換モデル M を考えてみましょう
死んだペド絵描きたちが新天地でイキイキと女児がイキイキする絵を貼っていて素晴らしい。
Twitterでは軽いお色気絵を数日に一回のペースで淡々と投稿するだけの絵描きマシーンみたいになってしまった人が、ここでは肌色だらけの絵を連投して「こういうのだいしゅきv」と人間の感情を取り戻している。
Twitterはアメリカのインターネッツだからアメリカの道徳の基準によりロリショタ描いたら凍らされるのは仕方が無いと諦めていたが、それでも架空の女児がアヘ顔ダブルピース妊娠アクメする絵を描いただけであり誰かに客観的な被害を与えたわけでもないのに、なんでアカウント永久停止されるんじゃという憤りは消えなかった。
Misskeyは開発者も、たぶん最大のインスタンスのioのオーナーも「エッチOK」な姿勢なのが心強い。
Twitterの路上のあちこちで殴り合いの喧嘩が起こってる雰囲気がつらくなってきてMisskey始めてみたらとてもよい。
Misskey.ioにアカウント作って初めて投稿したら秒で「レターパックで現金送れ」ってリアクション届いた。なんなんだここは。
ものすごい勢いで流れていくローカルタイムラインを眺めていると、自分も気軽に誰にでもリアクションしていいことがわかった。「素敵」「偉業」「ﾍﾞｲｸﾄﾞﾓﾁｮﾁｮ」とか色々とにかく押してみる。とても楽しい。
おやすみとノートすれば知らない誰かから「おやすみすきー！」と返ってくる。
この人たちも、Twitterで血みどろのレスバトルに疲れてやってきたのだろうか？
NSFWという閲覧制限の基準もとても明確で快適。「職場では見ない方がいいものは隠す」、この単純な決まりがこれほどストレスを減らすとは思わなかった。広告も少ないし、開発の方は本当にスーパー偉業。わずかながら寄付した。
Twitterに疲れたそこのあなた、Misskey始めよう。とりあえず最大インスタンスのMisskey.ioでいいと思います。レターパックで現金送れはすべて詐欺です。
ずっと忘れていた。
いや、脳の奥に生乾きのかさぶたのようなものがじっとりとこびりついて、ふとした時に思い出したりはしていた。
なぜだか、それが昨日になって出てきた
百子はJava言語の技術者だった。いや、技術者か分からないがJavaを学ぶ25歳の若い女性だった。
当時Java言語はJ2EEの登場により大きな注目を集めており、エンタープライズ用途で稼働していた業務系アプリケーションをWEBベースのJavaアプリケーションへのリプレースする事が大きな需要を生んでおり、VBやDelphi又はバックエンドとしてのCOBOL等で活躍していたエンジニアは技術転換を求められていた
現在も大して変わらんないかもしれないが、業務系エンジニアにコンピューターサイエンスを学んだ者は少なかった。
文系出身で(数学としての)関数や代数もちゃんと理解しているのか怪しいような者も数多く居り、当然ながらオブジェクト指向言語に戸惑う者も多かった。自分がそうだった。
当時の技術コミュニティはいくつかはあったが、古くからあったがどれも敷居が高かった。
fj.comp.lang.* (ネットニュース:現在と意味が異なる)は正当な技術者も多かったが初心者が書き込める雰囲気が無かったり過疎っていた。ニフティーサーブやPC-VAN等のパソコン通信(当時既にサービス名が変わっていたかもしれないがみんな昔の名前で読んでいた)をベースにしたものは歴史があったが、老害が偉そうにしているフォーラムも多く、やがて廃れていった。
そうした中で初心者も熟練者も和気あいあいと活発な議論が行われていたのが、JavaHouseというメーリングリストのコミュニティだった。
主催者は現在インターネットセキュリティの大物左翼として時折世間をビビらせまくっている、ひろみちゅ先生こと高木浩光氏。当時既に産総研の研究者になっていたとはいえ、あくまで個人が手弁当で運用していた。無料で誰でも自由に入退会ができるコミュニティであり、他に行き場のなさを感じた初心者のJavaエンジニアたちにとって大きな心の拠り所となった。
でも百子が注目された事があったのだ。
当時は適切な印刷用の整形ソリューションが無く比較的頻繁に挙がっていた話題で、
百子も同様に苦しんでいた
するような方法が、現時点ではり一ゾナブル
かとも思います。
ドラえもんのようなひらがなとカタカナを組み合わせたチャーミングな文体でその焦りを徹底的かつ高度に表現していた。
しかしこの議論中に問題が起こる。JavaHouseに障害が発生しメールが配信されない事象が発生したのだ。
NFSで他のサーバーにマウントしていたが不要と思われたNFSサーバーのデータを一部で参照していたため処理が行えなかった、応急的に対応したが根本対応を後日行うと管理者の高木浩光は告げた。
しかし、議論が途切れた事を不安に思った百子は高木浩光に直接確認を行った。返事は帰ってこなかった。
＞ This Message was undeliverable due to the following reason:
＞ The user(s) account is temporarily over quota.
というエラーで戻ってきました。
いろいろとご心配のようでしたので（その内容については書きませんが）、迅
速にお返事を差し上げる必要を感じておりますが、上記の通りでは、連絡の取
り様がありませんので、やむを得ず、お返事を差し上げた事実をここで示させ
ていただきます。
まるで百子に非があるかのように。
恥ずかしさと悔しさで真っ赤となった泣き顔の百子を想像することは難しくない。
次はインスタンス生成時のコストに関する伝統的な議論であったが、
その流れで議論とは関係が無かったが百子はやりとりのマナーについて言及した。
議論をしていた者たちは本質的では無い指摘に形式的な謝罪をしたが、
高木浩光だ
そんな慣習はありませんよ。
きっと百子は憤然たる思いを抱えたに違いなかった
最後に決定的な事が起こる
先日の障害の復旧のためメンテナンスのためサービスを停止すると高木浩光が予告した。
百子はさんざん煮え湯を飲まされてきた高木に対して
以下ちゃちゃです。
全サービスが利用不可というのは、大変なことでしょうに。
以上、ちゃちゃでした。
挙げ句Javaコミュニティを自分で立ち上げてみてはどうかと言う者まで現れた。
か弱く繊細で思いやりのある儚き百子が、このような嘲りに耐えるのは致命的な苦痛だったに違いない。
百子は精一杯の力でJava界の将来についてその想いを書き綴った
私が恐れているのは、恐怖の日が襲い、対応の行動が遅すぎる前に
協議を行って欲しい、ということです。
別れは突然訪れた
「百子の夫です」
技術コミュニティに相応しない短い件名の投稿は衝撃的なものであった
私の妻百子は１１日に進行性癌に伴う急性心不全で永眠いたしました
25才でした
医師の診断をもらったとき私たちに残された時間は１ヶ月というものでした
毎日が恐怖でした。、
なんという事だ！こんな悲劇があってよかろうはずがない！
しかもあのプりントアウトの話をしていたときには余命を悟っていたのか。
自分は打ちのめされた
そしてさらに衝撃的な事が続く
百子は先週からふさぎがちになっていました
聞くとブー様とうまくいっていないのではないかということでした
百子はずいぶん前からたびたび高木という男の名を出してひとりでジャバなる
パソコンを動かし一人で全部やってのけているのだと絶賛しておりました
おのれ高木さんめ！いや、ぶー様め！
百子の心に闇で満たしたという事か。
悔しくてウイスキーをストレートで何倍も痛飲し、この辛い出来事を忘れるように努めた。
自分はアプリケーションのプログラミングをする事もすっかりなくなっていた。
数年に１度くらいフッと湧き上がってくる事があったが、すぐに忘れようとした。
しかし、昨日はなぜ、菊池百子を思い出したのかずっと考えていた。
ずっと、ずっと
愛していたんだと思う、百子を。
直接会ったことはないし、見たこともない、投稿の文面の文字でしか見ていない、直接のメッセージのやりとりもしていない、だけど確かに自分は百子を愛していた。
雅人よりもずっと。
ぶー様よりもきっと。
Rest in peace, I love you.
https://web.archive.org/web/20091027013532/http://java-house.jp/ml/archive/j-h-b/052276.html#body
