自閉スペクトラム症（ASD）では性別違和感の訴えが比較的多く聞かれる。ASDには性差があり，男性は女性の3～9倍多く，より重症に現れるという特徴があり，神経発達症研究でもジェンダーアイデンティティやジェンダーディファレンスは注目を集めている。一方，性別不合/性別違和（GI/GD）の領域ではジェンダークリニックの受診者に神経発達症，とくにASDが多いことが報告されており，神経発達症，GI/GD，それぞれの領域で性別違和感を有する神経発達症の当事者をどのように支援できるか，最善の意思決定を支援するにはどのようにしたらよいのかということが長年の課題となっている。

Permalink | 記事への反応(1) | 09:45

■今更「未成年のLGBTは気の迷いかも」とか言っちゃっていいの？

そりゃ俺だってあんなもん中二のバリエーションの一種じゃね、って何となく感じてはいたよ

まあ30近くになって私アセクシャルかもとか言い出す女もいたりするけどさ

だからあんな変態殴ったら治る、社会主義になったら君のホモも治るみたいに考えてたのが昔のジジババなわけだろ

でもあの手の活動家の皆様とそれに連帯してたリべ様まで「ああいうのは生まれつきで"矯正"しようにも無理なんです！」ってクソ真面目な顔で言うものだからうっかり信じちゃったじゃん

「LGBT 当事者の自殺率が高い！」っていうのですら「そもそもメンヘラが自称してるからセーテキシコー以前に生きづらく死にやすいだけでした」って、そういうオチかもしれねえじゃん

じゃあ最初からちゃんとそう言えよ

なんなんだマジでよ

Permalink | 記事への反応(1) | 09:39

2022-09-25

■

ウルソデオキシコール酸の値上げがきつい

そろそろ従前の2倍くらいになりそう

ロシアから熊胆が手に入らなくなってんのかしらん

Permalink | 記事への反応(0) | 23:02

2021-12-09

■anond:20211209110453

福利厚生、ジョシコーセー、

今日も働く三度笠ぁー、

別にとりたて偉くない♪

Permalink | 記事への反応(0) | 11:07

2021-10-08

■anond:20211008161646

シコシコシコシコーっ！！

Permalink | 記事への反応(0) | 16:19

2021-07-10

■10年のキャリアが邪魔になってつらい

昔とある業界で働いてた。仮に飲食系としよう。

新卒で入社して10年いた。

バイトに毛の生えたような給料で、紆余曲折経てバイトレベルの雑務とかを束ねる人の補佐的ポジまで行ったが、待遇悪くて身体壊して辞めた。

で、今その業界及びそれに近い業界に対してシステム開発して納品する立場にいる。

いるんだが、その業界にいたころの常識が、今の開発チームに全然通じなくてしんどい。

例えるなら、「レジに入金するみたいな機能が欲しいと言われたんで、入金の機能を作りました！（お釣りが発生するケースは考えてないのでカネを吸い込むだけの機能）」みたいな感じ。

いや、確かに客は入金機能が欲しいと言ってたよ。言ってたけど、レジやるなら釣り銭の処理は考えとかなきゃダメじゃない？これ客にツッコまれるまでほっとくの？

せめて「これカネ吸い込むだけの機能ということでいっすかね」みたいな確認はしてこよ？？打ち合わせやったんやろ？？？

みたいな細かいことが、いろーーーんなところにある。

本当にカネ吸い込むだけの機能で良かった場合もあるが、「いやカネ吸い込むだけでええわけないやろ」ってなったケースもある。というか主観ではそっちのが多い。

しかしチームの基本姿勢としては、「特に要望されてなかったのでやってません」ばっかり。要望がそもそもあるのかないのかを確認しないでそれ。

ちゃんと確認しとかないので後出しみたいなかたちで改修要望出てきて、それで開発工数伸びて、納期間に合わなくなって既に2件ポシャってる。

そして自分はチーム内でそういう「特に要望されてなかったことを事前打ち合わせの段階でほじくって余計な仕事を増やすとんちんかんな非常識野郎」ポジで固まりつつある。

自分が良かれと思って何か言っても基本却下される。

単に却下されるだけならまだしも、あとから客に言われるので、自分の中で「だから言ったじゃん…」が溜まっていく。

なんていうか、つらい。いやつっっっら。

割と本当につらいわこれ。

これが例えば自分の技術的な不足であれば、IT新入りなんですつってボコられるのは覚悟の上で転職したので大したダメージはない。

しかし10年いて細かい業務フローのマニュアル全部取りまとめるみたいなこともしていた、その知識が完全に今の業務で仇になっていてきつい。

これが「あとから客に言われる」だけならまだいい。

関連法規に照らし合わせるとこの仕様まずいよね？？？みたいなのがちょいちょいポロポロ出てくるのだが、それに誰も危機感持ってないのが一番きつい。

10年で培った業界のコモンセンス−常識−が、「これマジまずいって、本当有り得ないレベルだって」と訴えてくるので、ついつい言い方がキツくなる。

で、チーム内でのウケも悪くなる。

この繰り返し。（テキシコー）

昨日ついに「何か意見しても『言い方が〜』とか言われるので、もう意見したくありませーん」ておふざけニュアンス混ぜつつ言うてもうたわ。

そうしたら、「仕事としてやってるんだから、その態度は〜〜」とくるわけだ。

いやまあ、そりゃそうだよね。はたから見たらワイ完全にめんどくさい察してちゃんだもんな。

しかし言っても言ってもまるで尊重されないのに意見し続けるのは普通にしんどい。

単に尊重されないだけならまだしも、「だから言ったじゃん」が発生するのが目に見えててしんどい。

言わなきゃ、「だから言ったじゃん」は発生しない。

あー、なんか、大学時代に勉強したやつで、こんな話あったな。

予言を誰も信じなくなる呪いにかかった姫君の話。

あのお姫様は立派だ。祖国の危機だったんで、狂人扱いされながら警告し続けていた。

中国の忠臣とかもそうだよな。厳しいこと言って嫌われるってしんどいのに、というか最悪斬首とかの時代なのに、言わなきゃダメだと思ったら首が飛ぶ覚悟でちゃんと言う。

偉いよ。

俺はもうダメだな。今こうして増田書いてて思ったが、普通に心折れてるわこれ。開放骨折だわ。

三十六計逃ぐるに如かず。逃亡計画を練らなくては。

Permalink | 記事への反応(2) | 05:34

2021-07-08

■Netflixでデザインあを見た

とても面白かった。どストライクでした。

なのでこんなタイプの動画が他にないか教えて。

Eテレのテキシコーは既に見ました。

Permalink | 記事への反応(0) | 23:26

2021-02-10

■anond:20210210140524

自分は逆にCMなんかでさんざん聴いた有名すぎる曲はなんか気恥ずかしくなって聴きづらかった。

　　　　というと、パッヘルベルのカノンとか、モーツァルトの小夜曲とか、ヴィヴァルディの春とか？

でも、意外とCMでもオヤ？と思うような曲が使われてたりするよ。プレトリウスのテルプシコーレがCMで使われてたのには驚いた。他にもバッハのフランス風序曲とか。

Permalink | 記事への反応(2) | 16:35

2021-02-06

■anond:20151004153135

テキシコーとWhy!?プログラミング

Permalink | 記事への反応(0) | 22:36

2020-12-02

■IT(?)に立ち向かうための心構えとか考え方

anond:20201130214610

いろいろ面白かったので、適当に回答する。

＞ 1.具体的な事が分からない

プログラミングで主にやる事は下記の2つ。
①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
これでやりたいことは分かる。分かるけれどこれでどうやって動画や音楽のエンコードをしたり
画像処理をしたりするソフトウェアになるのかというのがよく分からない。

とてつもなく複雑で冗長な処理によって実行されている。

複雑すぎて人間の直感で理解することは不可能だ。

わかりやすいので画像処理でいうと、数十万から数百万の画素（RGBAの24bitで表される数値）を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンをテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。

「まさかそんな事できるわけないだろ」というレベルの処理が実際に行われており、これまた直感的でない。

適当にリンクを挙げる。

だからそれをどう書くんだよ。という答えはコレ。有名なjpegの実装だ。

https://github.com/LuaDist/libjpeg

フレームワークだとかよく分からないものを持ってきて使ってくださいってなっている。

libjpeg というライブラリを書くことはできるだろうか？画像の圧縮の理論から考え始めることはできるか？

正直無理だ。自分はプログラマだがそんなに数学が得意ではなく、頑張ったとしても下手するとコレを作るのがライフワークになってしまい、他のことができなくなる。

例えばブラウザを0から作るとして、jpegの処理以外にも画像だけでpngとかgifとかwebpとか、その他もろもろとてつもない作業が必要になる。

「とてつもなくて想像もできないので流石に無理だろう？」

いや、でも、実際動いてるのよ。ここ何十年、コツコツと積み重ねて実現している。

「積み重ね」とはライブラリであったりフレームワークであったりOSであったりする。

だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。

「どういう風になっているのか」

多くの場合、內部の実装に関しては詳しく知る必要はない。

外部に向けたインターフェイスがどうなっているのかは理解する必要がある。「使う」ために必要だからだ。

この2つは分けて考えなければならない。

これでどうやってゲームを作ったり、検索エンジンを作ったりするんだとなってくる。

ちなみに、たとえばChromeのコアである Chromiumはのコードはコレだ。

https://chromium.googlesource.com/chromium/src

つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
これがもう滅茶苦茶イライラする。

「これで判定と繰り返しという基礎ができます」というのが基本的な理論（定理的なもの）で、その他に必然的だが唯一無二ではないベストプラクティスというものがある（法則的なもの）。

後者をうまく説明する入門書に出会っていないんだろうな。という印象。イライラはやめよう。つかれる。

ベストプラクティスはいろいろあるのだが「層の構造にする・レイヤーに分ける」というのは重要なアイデアだ。

libjpegというのはjpegの処理を行う「ライブラリ」だ。他のアプリケーション...たとえばブラウザはこのライブラリを「使う」。

ブラウザではjpeg 画像の圧縮展開というとてつもなく難しい処理を「libjpegの使い方」の理解までで済ませ、過去の蓄積であるlibjpegのコードを利用することで真の意味で0から実装しないようにしている。

この場合、libjpegが「低レベル・低レイヤー」の存在であり、中身については「使い方」つまり「仕様」の理解までしか行わないことで、実際に作りたいものを作れるようにしているわけだ。

「巨人の肩に乗る」とよく言われる。

つまり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。

完成しているプログラムは二例ほど挙げたがどうですかね？

複雑なことをする、特に低レイヤーのコードはとてつもなく難しい。

でも、とりあえずこんな感じのコードなら解るよね？

https://www.google.com/search?q=%E3%81%98%E3%82%83%E3%82%93%E3%81%91%E3%82%93%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0+javascript

こういうレベルから理解して、ちょっとずつ難しい処理を学んでいくしかない。

だから木材を渡されてこれで家を作れと言われるくらいハードルが高い。

ハードルは高いんですよ。実際。

なので、木材からだと難しいからプレハブのキット的なものを探すとか、ログハウスのカタログを読むとか、あるいは100人乗れる物置を買うのがいいかもしれない。そういうところから始める。

それらがフレームワークであったりライブラリであったりする。目的に合うものを探して、自分がやりたいことをどう実現するかとにかく考える。

「テキシコー」https://www.nhk.or.jp/school/sougou/texico/ で言われる通り、「小さく分けて考える」「手順の組み合わせを考える」「パターンを見つける」「大事なものだけ抜き出して考える」「頭の中で手順をたどる」をひたすら実行する。

ゲーム作りにはそういうアプリを使えば楽だからそれを使えという人もいる。Unity？だっけ。
でもそれはそれ。そうじゃなくてプログラミングでどうやってそれが作られているのかが分からない。

unityはコードが公開されているので、本当に読みたいなら。。

https://github.com/Unity-Technologies/UnityCsReference

なぜそこでオブジェクト指向になるのかが分からない。
オブジェクト指向は内部構造を知らなくても直感的に利用できる素晴らしいものだとは思う。

オブジェクト指向は一旦忘れよう。

オブジェクト指向の「隠蔽」というのは層の構造が持っている重要な要素ではあるけど、「低いレイヤーについて考えない」のが基本的な作戦だという理解の方が重要だ。

が、プログラミングでは、その内部構造を作らなきゃいけないのだからそれを知る必要がある。

前述の通り「できる限り作らない」んですよ。「使う」だけ。知るべきことを最小化する。

巨人の肩に乗り、車輪の再発明は基本的に避ける。

そして本当に作るべきものに関しては、利用する下のレイヤーのライブラリなりを探して・仕様を理解して、どう組み合わせてfor, if, あるいは計算させれば実現できるのかをひたすら考える。

じゃあ具体的に何を作りたいのかというと、英語のフリーソフトの言語表示を日本語に翻訳するソフト。

単に翻訳がしたいのか？表示に割り込む方法を知りたい？日本語に翻訳するのは実行時なのか開発時なのか？

要求される表示エリアが言語によって異なるために、デザイン調整が必要になる問題をどうするか？

解決したい問題をもっと分解したほうがいい。

分解が甘いので何をしたらいいか調べることができないんだと思う。

たまに便利なフリーソフトが海外版の時があるんだけれど、日本語化が出来ない事があるので、自分が自由に
日本語化できるようにできれば凄くストレスが減る。だからやりたいのだけれどそういうのがよく分からない。

ちなみに、アプリ内の文言というのはアプリの外部から変更できないように実装されている事が多いので、利用者が上書きする仕組みはかなり難しい。

AndroidなりiOSの仕様にもそのへんに割り込める機能はないはずなので、OSの開発に入っていく必要がある。結構大変だとおもう。

アプリの開発者が、そういう機能を備えた多言語化のためのライブラリを使うようになれば実現可能ではあるので、そっちの方向で頑張るのがおすすめだが、英語圏の開発者には多言語化のモチベーションが低いという基本的な問題はあるのよね。

この辺の「できる・できない・むずかしい」の判断は、いろいろな勉強をすると常識としてある程度みえてくる...気がする。

ついでに。ウェブサイトやウェブサービスの翻訳だとこういうサービスがあったりする。

https://wovn.io/ja/

ブラウザはページの描画処理のなかに割り込む余地が大きく取ってあるので、ブラウザのExtensionとかならできることがいくらかあるかもしれない。

＞ 2.説明が出来ても説明が出来ない

個人的に気に入らない話はOSのアップデートは使いやすくなるからとてもいい事だからすぐにやった方がいいと宣伝されている事。
セキュリティが高まりますというのが宣伝文句だけれど、これで大体老人たちやITの知識に疎い人は躓く。

まあ、半分は嘘だよね。古いものが残っていると先に進めないんだよ...。

現在のクライアント OSは、巨大なプラットフォームのパーツの一部として理解したほうが正しくて、古いパーツが残っているとツライんですよ。

そして「サービスを受けるための道具であって、あなたが何でも好きにできる機械ではないです」みたいな世界になりつつあって、ちょっと問題と言われてもいる。

これはかなり困った傾向なんだけど、全体としての流れはあんまり変わりそうにない。

またここでオブジェクト指向が出てくる。

オブジェクト指向好きですな...。ここではオブジェクト指向は特に気にしなくていいですよ。

だからパソコンはたまに不具合を引き起こすんですという説明が着地点になる。

とてつもなく複雑なことをやっているために、すべてのバグを潰すことはコストが高すぎてできないんですよね。

それよりバグは未来を先取りするコストと考えて、本質的に価値のある機能を増やしていくというのが基本的な方向になっている。

だからパソコンはたまに不具合を引き起こすんです。しゃーない。

しかし中途半端に理解している老人などは、そんなことじゃ分からん。自分に分かるように説明しろと言い出す。
説明は出来る。しかし相手はイライラするし理解されない。よって説明をしてはいけないという状況に追い込まれる。
ここでどうすればいいのだと理解不能に陥る。

まあ、説明って得てして難しいよ。しゃーない。

何故なら自分もOSのアップデートの不具合の原因というのが分からないから。
Microsoftが、Appleが、Googleがそうしているんですとしか言えない。

そのとおりです。

プログラムのソースコードのどこかにエラーがあるのだろうけれど、どこにあるのかなんて当然知らない。
そもそもソースコードを調べるのは違法なのでやれないし。

オープンソースのプロダクトなら原理的には調べられるけどね。Androidとかはオープンになってる。

https://android.googlesource.com/

だけどみんなそんなものを使っているし自分も使っている。正直こんなんでいいのか人類と思う事がある。

それを許容することで先に進んできているという事実は受け入れたほうがいいと思う。

「把握・理解可能な範囲」に留めていたら、数十年前のコンピュータの世界から抜け出せなかった。

deep learningの世界ではそれがより一層進むかも。この辺は詳しくないけど。

当然仕組みを理解している人はいるし、そんな人にとってみれば当然のことであっても、全ての中身を知っているわけではない。
どれだけ知っていても知らない事があるのがIT。理解しがたい。理解が出来ない。

ここでの「理解」についてはそのとおり。これはもう諦めるしかない。

＞ 3.自分は頭が悪い

これが常にある。IT関連は常に新しい情報が出てくるのでそれに送れると無知になってしまう。
なんでこんなことも分からないんだとか言われ放題で、IT系の企業に努めている人は常に新しい知識を入れられる
面倒くさがらない人が向いている。

「面倒くさがり」の方が問題に気づいて「頑張って面倒じゃなくする」ことができるので、プログラマにとっては美徳なんて言われますけどね。

同時にくじけないとか諦めない、しつこいみたいな素養は必要かも。

表計算ならいけるんじゃないかと思ったときがあるのだけれど「射影」とかいきなり意味不明な言葉が出てきて、

勉強しろ。

それから受験していない。だから持っているのはIT パスポートだけ。情けない。

応用まではとろうな。がんばれ。

＞ 4.最後に

USB-TypeCをTypeAに変換してはいけないとか最近まで知らなかった。

このへん自分も知らんですよ。べつに全部知っている必要はない。

面白いからたまに調べたりもするけど。

（追記: はてな記法の引用すらもさっきまで知らなかったしな！そんなもん）

更にレガシー、すなわち過去の遺産なるものについても理解ができない。古い物がずっと使われ続けているITの環境。
もう誰もメンテナンスが出来ないものが延々と使われているという事実。

層の構造をとっているということと関係があるんですが、仕様が変わると、その上に乗っているものを全部なおさないといけないんですよね。

なので「互換性」というのが非常に重要なのです。

でも革新のために互換性を捨てなければいけないケースも多い。このへんはハードでもソフトでも同じ。

そして、メンテのコストが上がっても使い続けたほうがトータルで安上がりという場合は、古いものが残ってしまう。

あるいは「（多少の問題はあっても）動いているものは変えるな」という経験則から意図的に残す場合もある。

西暦 2020年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、

いまは原始時代にいると思ってもらって構わないと思いますよ。

ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。

それなのに毎日理解のできないパソコンやスマートフォンを使っている。
オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。
自分の全く知らない場所でいけしゃあしゃあと演算を行い、そして結果を出す。それも大半が正しい結果で
利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。
そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械の奴隷のようだ。
本当に理解できない。辛い。