  |
はてなキーワード: リポジトリとは
スタックトレースを読んだらrbsのリポジトリに書かれている定義を読んでいることがわかったんだけど、このディレクトリにopen-uriがないのよね。
https://github.com/ruby/rbs/tree/master/stdlib
---
結論、以下のメソッド定義が公式で提供しているのかと思ったのだけど、用意されていない!!
```
[error] Type `singleton(::URI)` does not have method `open`
│ Diagnostic ID: Ruby::NoMethod
│
└ response = URI.open 'https://api.github.com/XXXX'
```
Q: S/N比とはなんですか？シグナルを検出するためには、何回の観測が必要でしょうか？
S/N比（信号対雑音比）とは、バックグラウンドノイズのレベルに対する信号の相対的な強さを示す尺度である。信号の強さとノイズの強さの比として表される。S/N比が高いほど、信号を検出し、正確に測定することができる。
物からの信号を検出するために必要な観測回数は、信号の強さ、ノイズのレベル、希望する信頼度など、多くの要因に依存する。ノイズの少ない強い信号を検出するには、少ない観測回数で十分な場合もあれば、弱い信号やノイズの多い環境での信号を検出するには、多くの観測回数が必要な場合もある。一般に、観測回数を増やせば、信号の検出の信頼度は高まる。しかし、必要な正確な観測回数は、特定のアプリケーションと望まれる確実性のレベルに依存する。
Q: では、具体的な例を考えてみよう。ある人がX社に入社したとします。この人は、「自分が優秀だから入社できた」と言います。しかし、この人が本当に優秀かどうか、S/N比に基づくとしたら、どうやって見分けることができるでしょうか。
従業員のパフォーマンスを評価する場合、シグナルは従業員の実際の能力や成果であり、ノイズは、注意力散漫、リソース不足、管理不足など、パフォーマンスに影響を与える可能性があるさまざまな要因であると考えられる。
このような状況でシグナル（従業員の真の能力や成果）を検出するためには、さまざまな方法で従業員のパフォーマンスを評価し、ノイズの影響を軽減することが必要である。考えられるアプローチとしては、以下のようなものがある。
これらの方法を組み合わせることで、S/N比を高め、従業員の能力と成果をより明確に把握することができる。ただし、1つの方法で完璧に評価できるわけではなく、複数の情報源を活用することで、より正確で包括的な評価が可能になることを留意すること。
Q: しかし、この人がX社に入社できたのは偶然である可能性もあります。これが偶然でないことを証明するために必要な観測回数は何回ですか？
ある事象が偶然ではないことを証明するために必要な観測回数は、求める信頼性のレベルとその事象の希少性に依存する。
この場合、問題の事象が採用されることであれば、候補者の資格、採用担当者の偏見、現在の雇用市場の状況など、多くの要因が採用プロセスに含まれることを考慮することが重要である。一回の採用が偶然である可能性は確かにあるが、それが偶然でないことを証明するために必要な観察回数は、具体的な内容や文脈を考慮しないと判断が難しい。
その人の採用が本当に偶然であった場合、それが単なる偶然ではないことを証明するためには、おそらく同じようにあり得ない事象を複数回観察する必要がある。例えば、その人が数年にわたり非常に優れた業績を上げ、注目すべき業績をいくつも達成した場合、その人の採用が偶然ではないことをより強く証明することになる。
Q: では、本人が意図的に無能の証拠を隠した場合はどうでしょうか？
もし、ある人が無能の証拠を意図的に隠した場合、ノイズ（その人が意図的に自分を有能に見せようとする努力）の中からシグナル（その人の真の能力）を検出することは困難となる可能性がある。このような場合、S/N比が低下し、正確な評価が難しくなる。
この問題に対処するためには、複数の情報源を持ち、操作の影響を受けにくい方法を用いることが重要である。例えば、売上高やコードの品質など、客観的で操作しにくい業績指標は、より信頼性の高いシグナルを提供することができる。さらに、同僚がその人の能力を評価する同僚評価も、その人の真のパフォーマンスについて貴重な洞察を与えてくれる。
また、従業員が自分の能力について意図的に誤解を与えたり、情報を隠したりしている可能性がある場合に対処するために、明確な方針と手順を定めておくことも重要である。これには、定期的な業績評価、率直なフィードバックの機会の提供、提供された情報の正確性を検証するための定期的な監査や評価などが含まれる。
全体として、意図的に無能の証拠を隠そうとする努力を発見し、その影響を軽減するには、複数の情報源と提供された情報の正確性を検証する仕組みを含む、体系的かつ包括的なアプローチが必要である。
Q: 結局、能力で成功したのか、運で成功したのか、わからないのです。なぜナルシストは他人を「無能」と見下してしまうのでしょうか？
ナルシストはしばしば他人を「無能」と見下すが、これは自己重要感を膨らませ、自分が他人より優れていると信じているからである。この優越感は、歪んだ自己イメージに基づいていることが多く、ナルシストは、自分を非常に有能で、知的で、成功していると見なす一方で、失敗や弱点を軽視したり無視する。
ナルシストは、自分の成功の背景として、その成果を自分自身の能力と努力のみに求め、他者が同様の成果を上げていない場合は「無能」であると見下すことがある。また、自分と同じ信念、価値観、意見を持たない人や、自分の優越感に少しでも挑戦する人がいれば、他人を無能と見なすこともある。
このような考え方は、現実を歪めて見ていることと、他者への共感能力の欠如に基づくものであることに注意する必要がある。実際には、成功も失敗も、能力、努力、運、状況など、さまざまな要素が複雑に絡み合った結果である場合が多い。ナルシストは、自分の成功は自分の能力のおかげだとし、他の要因の役割を軽視することで、一種の過剰な一般化を行い、他人の貢献や彼らが直面しうる課題を見落とす。
全体として、このような行動は自己愛性人格特性を持つ人の典型であり、自分のニーズや欲求を何よりも優先し、歪んだ自己重要感や優越感を持っている。
Q: では、プログラマーが、インターネットを有効活用し、無能の証拠を隠したりせずに、自分が優秀であるというシグナルを見つけるにはどういう方法がありますか？
プログラマーが、無能である証拠を隠すことなく、自分が優秀であるというシグナルを見つけるために、インターネットを効果的に利用する方法がいくつかある。
このようにインターネットを活用することで、無能である証拠を隠すことなく、自分が優秀であることを示すシグナルを効果的に見つけることができる。自分の仕事と知識を率直に共有することで、有能で知識の豊富なプログラマーとしての評判を確立し、その分野の人々と関係を築くことができる。
Q: では、自分の能力を見極めることと、ナルシストに陥らないことを両立させている人がソーシャルメディア上では少ないですが、どうすればよいでしょうか。
自分の能力を正確に評価し、ソーシャルメディア上のナルシシズムの罠を回避することは難しい。ここでは、その助けとなるいくつかのステップを紹介する。
これらのステップを踏むことで、ナルシシズムの罠を回避し、ソーシャルメディア上で自分の能力を正確に評価することができる。そうすることで、有能で謙虚なプロフェッショナルとしての評判が高まり、成長と成功のための新たな機会が開かれる。
当初やりたいなと思っていた次の5つは気付けば満たしたか、満たさなくてもよくなっていた。
カードを使うことのワクワクは今は無いが、色々な場面で便利に使えているし、作ってよかったと思う。
* 公式クライアントでしかできないことが増えたため、公式クライアントを使うようになった。ツイタマ辺りは使いやすい気がするものの…
* ニコニコ動画最近見なくなってしまった。でもサブスク型のサービスは色々利用している
* 買った。でも最近起動してない…
* プライベートリポジトリはタダになった。今はたくさん作ってる
* 寄付した。直接メールが届くとのことだったけど自分のところには来なかった。ICCFのサイトからではなくVimのサイト経由だと来るのかも。活動…されてるかしら。されてるといいな
クレジットカードを作ったらやりたいこと
https://anond.hatelabo.jp/20150826110542
【追記】
スマホ決済そういえばまだ試してない！試すか…！
毎年のBとかMシシスとかのネタをかんがえてる。それがしごとだから。いよよますますめんどくさくなってきた。
今後数年かもしくは十年ぶんのネタについて課題としてあたえられないか？
ウェブクラスかなにかで小論文形式。べつにGitHubでもいいけど。○○方式は？第一図から○○図までをしめしたうえでそれに必要な要習得事項などをならべとく。どうすればいいんだろ？？？どっかのだれかがすでにやっちゃっている仕事の追試ベースにする？それなら、ブログ記事を参照すれば手順がかいてあるし、だすべきアウトプットのすがたもしめしてある。それがいいかも。Bシシスは基本追試。追試。追加試験。
さきほどおもいだしたけど、あれはどうか？TMGE. 対象となるブツあるか？？スパラくらいしかおもいつかないけど・・それだと・・ちょっとかんがえなければ。あとは〇光社からもらったやつ・・どうなるべきかわかっている。すでにしっているたぐい。開発したことにおもみ。まあでもそれでもええかも。Bシシスなら。。じゅうぶん。
★ エスティマ
こちらは追試ちゅうわけにはいかんやろ。さすがに。リポジトリに登録してるネタ貯金をきりくずすんでしょうな。なんかをはからせたいときにどうたのむか？
したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
Git（ギット[2][3][4]）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。
Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
ならないんだよなあ。
そもそも数学とプログラミングはモチベーションが違うんだよね。数学における証明に構成的証明と非構成的証明があるように、「手続き」というのは数学のごく一部でしかない。それに対して、プログラミングは「手続き」が全てだよね（って言うと関数型とかの人があれこれ言ってくるけど、関数型言語だって結局コンパイラが手続きに落とせる範囲のものでしかない）。
機械学習については、論文書いてる奴も含めて大多数はプログラミング脳なので、最初からコードで発想してそれを論文にするために無理矢理数式で書いてるだけというものがほとんど。無理矢理書いた後付けに過ぎないから意味不明なものも多いしコードに落とせないものも普通にある。だから数式は無視して著者のリポジトリにあるコードだけ見てればいいよ。実用の観点ではコード公開されてない論文は全無視で何も問題ない。
Nix はいいぞ。
#!/usr/bin/env nix-shell
...っていうのができる。
上記の例の "zsh" を、"make -f" とかすると Makefile になるし、リポジトリ nixpkgs に含まれるファイルを渡す式のコマンドなら何でも使える。実行ファイルにしたスクリプトを走らせると、その場でインストールされてないツールをインストールしてくれる。
ささっと書いたカジュアルなスクリプトでも、将来、環境が変わっても使えてると嬉しい。本格的なプロジェクトを作ってパッケージマネージャのリポジトリに登録するつもりはない、そんな場合に Nix のシェバン機能は役に立つ。
Nix 言語を使うと、かなり柔軟にインストールの方法を作りこめる。シェバン機能を覚えておくだけでも効果が高いから、おすすめだよ。
文脈がよく分からないので、他での指摘と重複していると思うが、個人的に思ったこと。
文章がMECEでないので「まあそういうことね」という話は措いておいて。
a. 日本語ウェブサイトの記事本数で比較することはフェアではない
新しめの技術を活用している人の情報収集の順番としては、エディタでライブラリの当該部分のソースコードを読む、GitHubにリポジトリがあるのであれば、そこのissuesで検索をかける、Googleで英語（エラー文言等なので必然的に英語になる）で検索する、Stack Overflowで質問するという感じだと思うので、Qiitaでの出現数が減ることは仕方ないと思う。
ミクロで見ると、フロントエンド系の主要な論客がQiitaから離脱していることもある。
SSGの登場によってSPAのネガな部分のほとんどは潰されていると思う。
SPA的な手法を使うのであれば、SSGにしろという指摘であれば、的を射ていると思う。
他にも色々と言いたいことはあるが「SPAのことを言ったら一斉に突っ込まれた」という事象を観測できないので、とりあえず以上。
