「変数」を含む日記 RSS

はてなキーワード: 変数とは

2017-06-26

地獄の社内SE

社内SEになった。

仕事を辞めて主夫業に勤しんでいたら、知り合いから声がかかった。

1人で社内システムを作ってきたおじいさんがあと数年で定年になるから

引き継げないかとのこと。

メインのシステムベンダー委託してて、そのおじいさんが作っているのは、

メインシステムデータを加工して2次利用しているものほとんどとのことだった。

社内SEはなんとなく楽そうなイメージがあったので、就職した。

言語エクセルVBAとVB.NET 1.0。

中身を見るとどちらもかなりやばい

VBA編

ウォッチウインドウを知らないのか、変数はすべてセルに入れてる。

 変数名はすべてRANGE("A1").valueみたいな感じで全く意味が分からない。

・処理遷移がおかしい。

 セルに1を入れる。そのセルchangeイベントで処理が動くとか。

 SHIFT+F2が無力化されてる。

・なるべくワークシート関数で処理してる

 データベースからとってきたデータを丸ごとワークシートにコピーして

 if,vlookup,match関数を駆使して帳票にしたり、CSVにしてる。

 データ100件制限があったり、1関数を直すときは100行コピーしないといけない。

 画面中に埋め尽くされたワークシート関数をみて途方に暮れる。

・format関数を知らない。

 8桁の日付をとりたいときyear、month、day関数がワークシートにあり、

 その下の行で月の二けた判定、日の二けた判定のif関数で頭の0をつけ

 3行目でconcatenateしている

タイマー起動

 毎朝100本ぐらいのマクロが動いてる。

 タイマー起動なので、毎日セットしないといけない。(タスクスケジューラーを知らない)

 がんがんエラーが発生するので、マクロ設定をエラー処理対象外エラーで中断にしないと動かない。

・遅い

 textboxのchangeイベントでDBからデータ取得処理を入れているので、データが多くなると1文字打つごとに数分待つ状態

 exitイベントを知らないらしい

 DBの更新処理でもテーブル全件とってきて、ループしながらキーが一致するのを探して更新

そんなつっこみどころしかないEXCELマクロが200本以上ある。

VB編

・.NET1.0

 windows7や8に無理やり.netframework1.0を入れて動かしてる。

 顧客PCにも入れてる

オブジェクト名は代えない

 変えられることを知らないのかもしれない

 textbox100とか存在してる。

 EXCEL同様変数は隠しtextboxに入れてる。

設定ファイルおかし

 1.0なのでconfigがないのはしょうがないが、設定ファイルは固定パステキスト

 行数で管理

・WAITがいっぱいある

 試しに取ったら動かない

・DBを最後まで回すとき

 例外が発生するまでまわす。

変数関数スコープ管理

 ない。基本グローバル

クラス

 ない。

ネスト

 ない。

おじいさんが20年にわたって深夜残業休日出勤を厭わず作ってきた、地獄の社内システム担当になったらしい。

2017-06-21

変数名に枠を付ける記法ってはてな表記でどうやって書くの

http://help.hatenablog.com/entry/markup/syntaxhighlight

変数名に枠がついてあるようなやつ

ソースコード自体の話ではなく、[html][ruby][css]のように並んでるところの表記

2017-06-18

https://anond.hatelabo.jp/20170618103253

Javascriptは死んでほしいと思っているので詳しくないんだがgzipかける前提ならミニファイソフト変数をi,ii,iii,iiii,iiiiiみたいにするんだろうか・・・

(もちろんするとしても通信経路で最も小さくなるようにするかテーブル作るときに最も小さくなるようするかオプションで選べるとは思うが)

34歳男性年収800万未婚東京在住だけど結婚できない

結婚したい。

ふと同じ条件の男性がどれくらいいるかと思って調べてみた。

式が間違っていても知らん。

30-34歳の全国男性人口は365万人、勝手に割る5して34歳は73万人

34歳で年収800万は4%らしいので約2.9万人

30-34歳で未婚は46.5%なので1.35万人

東京の全国の人口に占める割合10.60%なので0.14万人

まり、34歳で年収800万で未婚で東京住みは1400人。

見た目は普通以上。

最後あいまい変数だけど、1400人全員が結婚したいとする場合、もう少し絞られるだろう。

それでも結婚できない。彼女だってもう2年もいない。

いや上の計算なんて何の意味もないのはわかってるんだけど、なんか自分価値をひねり出したくて。

けっこーいい物件だと思うんだけどなー。

あーあ、結婚したいなー。

2017-06-17

自転車によく乗る人は、自動車依存者よりも歩行者よりも健康寿命が長く、長生きだという研究結果。

自転車通勤 ガン・心疾患リスクが大幅減少=イギリス研究

http://www.epochtimes.jp/2017/05/27201.html

あなたはどんな方法通勤していますか? 自転車通勤すれば、ガンと心疾患リスクを抑えられるという報告があります

 スコットランドグラスゴー大学(University of Glasgow)の研究チームは、イギリスバイオバンクUK Biobank)に保存されている26万人分を超える膨大なデータ分析しました。

彼らの通勤方法を調べ、その後5年間にわたり、ガンや心疾患の有無、また死亡したケースなどの追跡調査を行いました。

 それによると、自転車通勤者は、電車や車に比べてガンに罹るリスクは45%少なく、心疾患の場合は46%、また早期死亡リスクは41%少ないことが分かりました。

 心臓血管医学研究所ジェーソンギル(Jason Gill)博士は、「通勤の一部だけでも自転車を利用すれば、大幅に疾患リスクを抑えられる。

通勤の全行程を自転車にすれば、心疾患やガンになるリスク、また死亡するリスクを40%以上減らすことができる」と話しています

 一方、徒歩で通勤する場合は、ある程度の心疾患の予防に役立ちますが、ガンや他の死亡原因を減らす効果はないと科学者は話しています

徒歩通勤者は週平均6マイル(約10 キロ)歩くのに対し、自転車を利用する者は週平均30マイル(48キロ)走ることから、徒歩は距離が短いために効果が薄いと指摘しています

 同研究は先月、ブリティッシュメディカルジャーナルBMJ)に掲載されました。

翻訳編集豊山

自転車通勤者は徒歩通勤者よりも自動車通勤者よりも電車通勤者よりも全死因死亡リスクが低い/BMJ医師医療従事者向け医学情報医療ニュースならケアネット

https://www.carenet.com/news/journal/carenet/43895

自転車通勤は心血管疾患(CVD)・がん・全死因死亡のリスク低下と、徒歩通勤はCVDのリスク低下とそれぞれ関連していることが、

英国グラスゴー大学Carlos A Celis-Morales氏らによる、前向きコホート研究の結果、明らかにされた。

徒歩通勤自転車通勤は、日常身体活動を高めることができる方法として推奨されている。

先行研究メタ解析(被験者17万3,146例)において、有害な心血管転帰リスク低下と関連することが報告されていたが、同報告の結果は、

代謝性エンドポイント(高血圧糖尿病脳卒中、冠動脈心疾患、CVDなどの発生)の範囲が不均一で徒歩通勤自転車通勤かの区別がなされておらず、限定的ものであった。

BMJ2017年4月19日掲載の報告。

26万3,450例を前向きに追跡

 研究グループ検討は、2007年4月2010年12月英国内22地点から英国バイオバンク参加者26万3,450例(うち女性52%、平均年齢52.6歳)を対象に行われた。

仕事場までの通勤手段(非アクティブ自転車、徒歩、混在)を曝露変数として用い、主要アウトカム(致死的・非致死的CVDおよびがん、CVD死、がん死亡、全死因死亡)の発生について評価した。

 結果、追跡期間中央値5.0年(四分位範囲:4.3~5.5)の死亡発生は2,430例で、うちCVD関連死496例、がん関連死1,126例であった。また、がん発生は3,748例、CVD発生は1,110例であった。

自転車通勤は、全死因死亡、がん発生・死亡、CVD発生・死亡とも有意に低下

 最大限補正モデルにおいて非アクティブ群と比較して、自転車通勤群は、

全死因死亡(ハザード比[HR]:0.59、95%信頼区間[CI]:0.42~0.83、p=0.002)、がん発生(0.55、0.44~0.69、p<0.001)、およびがん死亡(0.60、0.40~0.90、p=0.01)のリスク有意に低かった。

同様に自転車通勤を含む混在群も、全死因死亡(0.76、0.58~1.00、p<0.05)、がん発生(0.64、0.45~0.91、p=0.01)、およびがん死亡(0.68、0.57~0.81、p<0.001)のリスク有意に低かった。

 CVD発生のリスクについてみると、自転車通勤群(0.54、0.33~0.88、p=0.01)、徒歩通勤群(0.73、0.54~0.99、p=0.04)ともに有意な低下が認められた。

CVD死についても、自転車通勤群(0.48、0.25~0.92、p=0.03)、徒歩通勤群(0.64、0.45~0.91、p=0.01)ともに有意な低下が認められた。

 一方で、徒歩通勤群は、全死因死亡(1.03、0.84~1.26、p=0.78)、がん関連アウトカム(がん発生:0.93、0.81~1.07、p=0.30、がん死亡:1.10、0.86~1.41、p=0.45)について、

統計学的有意な関連はみられなかった。徒歩通勤を含む混在群も、測定アウトカムのいずれについても顕著な関連はみられなかった。

 これらの結果を踏まえて著者は、「アクティブ通勤を促進・支援するイニシアティブによって、死亡リスクを減らし、重大慢性疾患の負荷を減らせるだろう」とまとめている。

ケアネット

原著論文こち

Celis-Morales CA, et al. BMJ. 2017;357:j1456.

http://pmc.carenet.com/?pmid=28424154&keiro=journal

自転車通勤は(徒歩通勤自動車通勤電車通勤よりも)死亡リスクを低下させる:日経メディカル

http://medical.nikkeibp.co.jp/leaf/mem/pub/hotnews/bmj/201705/551297.html

英国の大規模コホートで車や電車通勤よりも有意に減少

人々の運動量世界的に減少傾向にある。英Glasgow大学Carlos A Celis-Morales氏らは、

中高年の英国人通勤方法と心血管疾患、癌、総死亡の関係を明らかにするために住民ベースの前向きコホート研究を行った。

得られた結果は、自転車通勤健康利益を示し、徒歩通勤も心血管疾患の発症と死亡リスクを軽減していたと報告した。

データBMJ電子版に2017年4月19日掲載された。

ログインして全文を読む>

2017-06-12

javascriptわかりません

for文の書き方とか変数の書き方までわかったところで実践と離れすぎてる

jQueryとかreactとかどうやって勉強すんねん

2017-06-11

http://anond.hatelabo.jp/20170611144739

役所以外は既に西暦ベースでの処理が普通なので全然手間でもなんでもない。年号変数弄るだけってのが殆ど

役所関係ハードコーディングしてあったり、ペーパーの書類を全部差し替えなければならないので非常に煩雑

日本の大部分=お役所 ならそれで正しい

2017-06-03

http://anond.hatelabo.jp/20170602200844

その相手さんは別のトラックバック

内閣支持率 = f(a,b)

>a:与党イメージ,b:野党イメージ ※ただし2変数aとbは独立である

言及してるから内閣支持率自民党支持率は分けて考えてるやろ。

というか、自分意見に自信があるならトラックバックを消して隠れるような真似はしなさんな。

2017-06-02

http://anond.hatelabo.jp/20170602162158

何故かページを消されちゃいましたのでこっちにレスしますが、まぁ、なるほど。

「他の内閣よりよさそうだから」を「他の内閣より経済対策に期待が持てるから」に持って行かれると五十歩百歩な気もしてきちゃいますが、

確かに私の主張も拡大解釈だったかもしれないですね。その点は失礼しました。

因みに、独立事象云々は次のように解釈して頂けますと幸いです。

内閣支持率 = f(a,b)

a:与党イメージ,b:野党イメージ ※ただし2変数aとbは独立である

故に当然、内閣支持率変数a,bに従属しています

まぁ厳密には「c:与党の他の総理候補議員イメージ」とかも追加すべきだとは思いますが、直前に政権交代がありましたし簡易式ということで。

2017-05-28

プログラミングを始めたい人に立ちはだかる壁

プログラミング教育重要性が指摘される昨今ですが、皆様いかがお過ごしでしょうか?

プログラミングを始めたいと思っていても、何から始めたらいいかからない方も多いと思います。そうした人たちがどこでつまづくのか考えてみました。

まず、普通の人がプログラム作ってみたいと考えたとき想像する普通プログラムは、きっとウィンドウがあってその中に写真文字があるようなものでしょう。

しかし、これらは大変高度なプログラムです。全くプログラミングをしたことがない人がいきなり作るのにはハードルが高すぎると思います

じゃあ、ハードルが高くないプログラムというのはどういったものかという話ですが、それはWindowsコマンドプロンプトMacターミナルといった、テキストだけの環境で動くプログラムです。

でも、プログラミングをしたことがない人にとっては、コマンドプロンプトターミナルの方こそ難しそうなイメージが付きまとっていることでしょう。

このギャップが、プログラミングを始めたい人に立ちはだかる壁なのではと思うのです。

そもそもテキストだけの環境で動くプログラムのほうが簡単だ、という話にピンとこない方も多いと思いますので、1から100まで表示するプログラムを例に説明します。

まずテキストだけの環境だと、変数iが1から100までの間iを表示してからiに1を足すことを繰り返す、というだけで作れます

けれども『普通の』環境だと、まずウィンドウを表示し次にウィンドウの中に文字を表示するスペースを用意してそれから変数iが1から100までの間iを表示してからiに1を足すことを繰り返す、ということをする必要があります

このウィンドウを用意するという手間が案外難しい。最近は開発環境も充実してきてかつてよりは確実に楽になっているとは思いますが、それでもいきなりここから始めるのは覚えることが多すぎて挫折の原因になるのではと思います

なので、一見難しそうに見えるコマンドプロンプトターミナルを使ったほうが、プログラミング最初のとっかかりにはいいのではないかと思うのです。

これは私自身がターミナルから覚えたという体験から出た考えなので、もっと他のアプローチからプログラミングを覚えた人や、こうしたアプローチで結局うまくいかなかったという人の話など、トラバしていただければ幸いだなぁ、と思います

2017-05-26

28大学院既卒博士童貞無職職歴ゼロ地蔵になる。

都内某社へプログラマ採用面接に赴く。就職斡旋から紹介された中小企業である。おれはプログラミング経験が皆無だったか採用されることはまず無いだろうと考えていたが先ずは課題を解いてみろと斡旋屋は云う。食事睡眠時間とその他日常の雑事を犠牲にして一ヶ月ほどで解き終わる。完了した旨を斡旋屋に報告するとあれよという間に面談の日取りを決めてきた。当日、朝からぱらついていた雨は、正午前には止み、蒸し暑い晴天へと変わっていた。都内オフィスを訪れたおれは、こじんまりとした会議室に通された。ひとりのおとこが入ってきて、ここで一番えらいエンジニアだと名乗った。面接開始である。こちらが名乗ったのだからお前も自己紹介しろおとこが云うのでおれも名を名乗り、用意してきた志望動機キャリアヴィジョンをよどみなく述べた。斡旋屋と打ち合わせした通りの模範的な回答であるしか面接官氏はそれが気に入らないらしくおれ自身アピールになっていないと云う。大学で学んだことを活かして社会に貢献できるように――「それはみんなそう考えてるよね(笑)」「改めて聞きますがうちに入社してどうしたいですか?」3分ほど沈黙。「あっもういいです」おれは完全に萎縮してしまっていた。おとこは手元のVAIOディスプレイケーブルにつなぎこのループ文の計算量オーダは幾らかと問うた。壁面にはおれが解いた課題プログラムが映しだされている。しかし、おれは自分で書いたはずの10行ほどのfor文がどうしてうまく動いているのか、さっぱり思い出せない。仕方がないので一から考え直す。1ループ目の変数はこうなって2ループ目がこうで……ああ紙と鉛筆さえあれば。5分ほど沈黙が続くと、こんな初歩的な質問にも答えられないとは思ってもみなかった面接官氏がおれを煽る。「きみ計算量詳しいんじゃなかったの(笑)自己紹介ときにP≠NP問題に興味がありますなどとうっかり漏らしてしまったのが運の尽きだった。それで余計に焦ってしまう。quick sortを使っているのにO(n)で解けるなどと云う妄言を口走る。頭大丈夫かこいつと云うおとこの顔。緊張は極限に達し、丸暗記してきた想定問答通りの内容を喋ることでせいいっぱいになる。このあたりから面接官氏の露骨な「アホと喋ってる時間が勿体ないんだよね」オーラを感じはじめる。今までプログラム行書いた?課題以外に勉強したことは?研究以外の活動は?本は何冊読んだ?使える言語は幾つ?インターン経験は?ないです。ないです。事前に考えてきた逆質問2つをもって、やたらと早いタイミングでの面接終了となった。おれは逃げ帰るように会社をあとにし、駅へと向かった。おれは自分が某大学大学院博士課程を修了したのだとつい先程まで思い込んでいたのだが実は無職ニートの単なる妄想に過ぎなかったのではないか。あれだけ苦労した研究の日々もすべて夢のまた夢だったのではなかったか大学名誉を傷つけないようニセ学位返上するべきではないのか。優良企業の貴重な業務時間を奪ってしまった罪を償うべきではないのか。半泣き。死にたい。傘忘れた。

http://anond.hatelabo.jp/20170523021920

2017-05-22

医学自転車通勤者は、自動車、徒歩の者より健康長寿

http://anond.hatelabo.jp/20170522214454

自転車通勤者は徒歩通勤者より全死因死亡リスクが低い/BMJ医師医療従事者向け医学情報医療ニュースならケアネット

https://www.carenet.com/news/journal/carenet/43895

自転車通勤は心血管疾患(CVD)・がん・全死因死亡のリスク低下と、徒歩通勤はCVDのリスク低下とそれぞれ関連していることが、

英国グラスゴー大学Carlos A Celis-Morales氏らによる、前向きコホート研究の結果、明らかにされた。

徒歩通勤自転車通勤は、日常身体活動を高めることができる方法として推奨されている。

先行研究メタ解析(被験者17万3,146例)において、有害な心血管転帰リスク低下と関連することが報告されていたが、同報告の結果は、

代謝性エンドポイント(高血圧糖尿病脳卒中、冠動脈心疾患、CVDなどの発生)の範囲が不均一で徒歩通勤自転車通勤かの区別がなされておらず、限定的ものであった。

BMJ2017年4月19日掲載の報告。

26万3,450例を前向きに追跡

 研究グループ検討は、2007年4月2010年12月英国内22地点から英国バイオバンク参加者26万3,450例(うち女性52%、平均年齢52.6歳)を対象に行われた。

仕事場までの通勤手段(非アクティブ自転車、徒歩、混在)を曝露変数として用い、主要アウトカム(致死的・非致死的CVDおよびがん、CVD死、がん死亡、全死因死亡)の発生について評価した。

 結果、追跡期間中央値5.0年(四分位範囲:4.3~5.5)の死亡発生は2,430例で、うちCVD関連死496例、がん関連死1,126例であった。また、がん発生は3,748例、CVD発生は1,110例であった。

自転車通勤は、全死因死亡、がん発生・死亡、CVD発生・死亡とも有意に低下

 最大限補正モデルにおいて非アクティブ群と比較して、自転車通勤群は、

全死因死亡(ハザード比[HR]:0.59、95%信頼区間[CI]:0.42~0.83、p=0.002)、がん発生(0.55、0.44~0.69、p<0.001)、およびがん死亡(0.60、0.40~0.90、p=0.01)のリスク有意に低かった。

同様に自転車通勤を含む混在群も、全死因死亡(0.76、0.58~1.00、p<0.05)、がん発生(0.64、0.45~0.91、p=0.01)、およびがん死亡(0.68、0.57~0.81、p<0.001)のリスク有意に低かった。

 CVD発生のリスクについてみると、自転車通勤群(0.54、0.33~0.88、p=0.01)、徒歩通勤群(0.73、0.54~0.99、p=0.04)ともに有意な低下が認められた。

CVD死についても、自転車通勤群(0.48、0.25~0.92、p=0.03)、徒歩通勤群(0.64、0.45~0.91、p=0.01)ともに有意な低下が認められた。

 一方で、徒歩通勤群は、全死因死亡(1.03、0.84~1.26、p=0.78)、がん関連アウトカム(がん発生:0.93、0.81~1.07、p=0.30、がん死亡:1.10、0.86~1.41、p=0.45)について、

統計学的有意な関連はみられなかった。徒歩通勤を含む混在群も、測定アウトカムのいずれについても顕著な関連はみられなかった。

 これらの結果を踏まえて著者は、「アクティブ通勤を促進・支援するイニシアティブによって、死亡リスクを減らし、重大慢性疾患の負荷を減らせるだろう」とまとめている。

ケアネット

原著論文はこちら

Celis-Morales CA, et al. BMJ. 2017;357:j1456.

http://pmc.carenet.com/?pmid=28424154&keiro=journal

2017-05-20

プログラムコピー当たり前なのになんで画像だと文句言う人多いんだ

自分サイト写真イラストなど画像をまとめに貼られたとか、編集して使われたとか文句言ってる人をそこそこ見る気がしま

私がはてブを見ることが多くなったからか、ここ最近プログラム関係ブログに書いてるのもよく見かけます

プログラムだと当たり前のように個人ブログやQAサイトのものコピーして、そのまま使ったり必要に応じて書き換えて使ったりだと思います

プログラムだと公開する方も使ってもらうことを意識してる人が多くて、OSSなどフリーのものを作ったりしてるひとも多いようです

プログラム書いて公開する人には自分でつくったのをみてもらいたい、使ってもらいたいと感じる人が多くて、画像を公開する人は、他人自分のものを使うのを気に入らないって心の狭い人が多いのでしょうか?

プログラムだってライセンスはなになにだ、っていう話も見るので画像には権利が生じて、プログラムはそんなのない、ってことはないかと思います

法的にどっちにだけ権利があるとか扱いが違うことがないなら、どちらも人が時間を書けて作ったものなのになぜこんな違うんだろう?

ところで、私個人としてはネットに流れてるのは全部フリーの共有財産でいいのに、って思ってるくらいなので自分が書いたソースコードや作った画像が誰かに使われることに文句うつもりはないです

勝手に使おうが、まとめに載せようが、クローンサイト作ろうが、好きにどうぞってくらい

どちらかというと、大量にあるコンテンツの中で使ってもらえた、まとめに載ったとか嬉しい方だと思う

あ、もちろんお金が生じてるものコピーのせいで売れなくなったみたいのは別です

お金とるわけでもなく個人サイトで公開してるようなものについてです

---

追記

トラバについて

みんなプログラマ視点意見ですね

はてなだとプログラマ的な人が多そうですし、納得です

仕事プログラムいたことないか?ですが、あります

一応今の本業です

仕事ではありえないって言ってる人もいますが、そうでもないです

普通にコピペで使われてるのはよくあります

お堅い会社で社内からQAサイト個人ブログアクセス禁止されてるほどのところとかだとないのかもしれませんね

やりたいことそのままのをQAサイトで見つけたらそれをコピペとか

始めて使うもので使い方をググったときに良いサンプルを書いてたブログがあったからそれをコピペして改変して使ってるとか

ヒドイところでは、QAサイトにそのままのコード上げて修正してもらったのをそのまま使うのも・・・ですね

私の周りだと、Stackoverflowの回答のサンプルコードを一度も使ったことない人は少ないんじゃないでしょうか・・・


ただ、今回言いたいのは仕事で扱う系じゃないです

画像をまとめに上げられたくらいで怒ってる人に対して、公開したプログラム変数名かえたくらいで別ブログで公開されたりgithubにおいてるプロジェクト(1人規模のものでも)で使われてたりです

「○○のやり方」とか「○○はこう使うのがいい」とかブログで書いてたとして、同じ内容が別ブログにもあるなんて結構見かける光景です

(参考にする側からすれば複数のところで書いてたほうが信頼できるのでありがたいですけど)

2017-05-10

東大医学部・面会交流論文不正の有無の審議中

東大医学部の面会交流論文が、話題となっている。http://www.scirp.org/journal/PaperInformation.aspx?PaperID=74779&#abstract

DVを行ったとされる父親との面会交流を行っている子どものほうが、行っていない子どもよりも、ひきこもり抑うつなど、精神問題、行動上の問題を抱えやすい、という論文である

この論文は、フローレンス駒崎弘樹氏が3月末にそのブログで、面会交流によって子どもの心が壊される、という彼の主張を裏付ける「エビデンス」として紹介したことを皮切りに http://blogos.com/article/215491/4月末に行われた「当事者の声を国会へ」と題する衆議院第一会館での院内集会や、「「国連人権勧告の実現を!」実行委員会」による「第20回学習会 ハーグ条約と親子断絶防止法案http://jinkenkankokujitsugen.blogspot.jp 等でも取り上げられたようであり、さら5月5日には産経新聞にも紹介された。

まり、これは、現在国会議員らによって提出が検討されている「親子断絶防止法」の策定を左右しうる重要論文である

日本では、別居親と子どもの面会交流は、家庭裁判所が間にはい場合、月1〜2回、4時間程度できれば良い方で、高葛藤や面会拒否が強い場合は月1回に2時間未満のことが多いと思われる (参考: http://oyakonet.org/documents/report_h2308.pdf )。DVがあったとされる父親であれば、その頻度・時間さらに減少するだろうし、FPICのような第三者機関の補助を得て行うことがほとんどで、面会交流時にDVあるいはそれに近いような行為をすることは稀であると考えられる。父親子どもを愛おしく思い会うでのあるから、短い時間の中ではその子どもを喜ばせようとすることが多いであろう。そのような状況で父親に会うだけで、本当に子どもひきこもり抑うつ危険性が高まるというような因果関係が本当にあり得るのだろうか?

そこで、研究論文を読むことのできる有識者にこの論文を読んで学術的に評価してもらった。そうしたところ、この論文は、きちんとした学術研究レベルに達していないひどい代物であるようだ、ということがわかってきた。

そのポイントは以下のようなものである

1. 僅かなサンプル数で、混交要因が統制されていないどころか、記述もない

研究対象としている母親の数がわずか38名、面会交流を行っている子どもの数が19名、面会交流を行っていない子どもの数が30名と、この種の簡易なアンケート形式研究としてはNが圧倒的に少ない。混交要因の統制が全くなされていないどころか、群毎の基礎的統計記載すらない。各群の基礎的な数値(Demographic characteristics)が両群でまとめて書かれてしまっていて、分けて記載されていないのである。つまり母親学歴収入精神疾患罹患統計値、離婚の有無、別居からの経過年数、子どもへのDVの有無・程度などが、各群で分けて記載されていない。加えて、両親間の葛藤の強さ、裁判調停審判などの有無、なども混交要因として示されるべきであろう。これらの混交要因候補指標のうちいくつかについては、この程度の少ないNであれば、各群で偏りが出てしまうことのほうがむしろ普通である本来、これらは分けて記載すべきなのに分けてないということは、これらのどれかで差が存在してしまっているので、それを意図的隠蔽している可能性もかなりある推定される。対象被験者集団は非常にヘテロ集団で、僅かなサンプル数しか取得していないにも関わらず、これらの指標について群ごとに示していないようなものは、まともな調査研究と言えるレベルのものではない。

2. 極めて僅かな回数の面会交流

「面会交流を行っている子ども」が父親と面会交流を行っている頻度の平均が、なんと僅か平均2.2回/年。Nもたったの19名。そのSDが2.2でレンジが0.5回~6.5回/年。年間2.2回というのは半年に一回しか会わないということであり、年間0.5回の面会交流というのは2年で一回しか会わなかったということ。しかも、この研究では、DVをしていたとされる父親との引き離しからの平均年数が6.9年も経っているのである。仮になんらかのDVがあったとして、引き離し後に7年もたったあとの、そのような僅かな回数の面会交流が、引きこもり抑うつリスク統計的有意に上げることは、常識的に極めて考えにくい。

3. 回答者バイアス可能

この研究は、質問紙を使ったアンケート形式のもの。回答を行ったのは子ども本人ではなく、DVを受けたと称している母親最近のことであるので、当然、親子断絶防止法のことも知っている母親が多いであろう。回答者研究の(政治的な)目的を知った上でバイアスのかかった回答をしている可能性があり、そのような可能性を排除するような工夫が全くなされていない。

4. 恣意的被験者抽出可能

方法によると、リクルートされた69名の母親のうち、8名が「精神疾患罹患している」という理由で除外されている。除外されていない回答者の中にも精神問題がある人がいるようであるが、除外の明確な基準は何か?都合の良い恣意的な除外なのでは?また、回答した60人のうち、22人が、「質問に全部回答できていなかった」という理由で除外されている。合わせると実に35%もの被験者が除外されているのである。このような被験者数がごく僅かの調査において、全ての質問に回答しなかった、という理由のみで除外することが許容されるのか?この研究では、各質問について統計解析を行っているのみで、それらの統計を行う上で、「質問に全部回答する」ということは全く必要とは言えない。つまり、除外する必要がない人を多数除外しているのである。これは、後付で、そのように除外することによって「有意差」が得られるからではないのか?

5. 標準的ピアレビューがなされていない可能性が大

このジャーナルを出している出版社はいわゆるpredatory open access publisherに分類されている。以前、過去にどこかで発表された論文をたくさん集めて無断で掲載していたことをNature誌に報道されたこともあったり、意図的にでたらめな論文作成投稿された論文掲載してしまったり、無断で研究者編集長として掲載していたり、という前歴のある「ならずもの出版社」の一つ。 https://en.wikipedia.org/wiki/Scientific_Research_Publishing 当該の論文掲載しているOpen Journal of Nursingも編集長を調べると、教育しか行っていないような大学教員であり、責任著者としてはこの10年で1報しか論文を出していないような人である。このジャーナルは、医学生物学文献の権威あるデータベースPubMedにも、もちろん掲載されていない。この出版社ジャーナルではまともな査読がなされていない可能性がかなりあり、筆者らの所属大学を筆頭とする多くの日本大学が、この出版社をうまく利用してしまっている事実が指摘されている。https://science.srad.jp/story/15/12/07/0554222/

上記の各ポイントは他の標準的査読が行われている科学雑誌では指摘されるのが当然であり、普通はこのままでは受理はされない。であるからこそ、このような出版社ジャーナルから発表している可能性が高い。

----

以上のような深刻な問題を抱えている論文であるため、その有識者は、この論文の著者にデータの開示や、群毎の基礎的統計提示を求めるなどの連絡を責任著者に対し行った。当初、責任著者からは何の返事も得られず、そのため、その責任著者の所属学科長にも連絡を行った。それでも何の返事も得られなかったため、所属大学の「科学研究における行動規範に係る不正行為に関する窓口(本部)」に通報を行った。

その通報根拠は以下のようなものである

文部科学省の「研究活動における不正行為への対応等に関するガイドライン

http://www.mext.go.jp/b_menu/houdou/26/08/__icsFiles/afieldfile/2014/08/26/1351568_02_1.pdf

は、研究機関

研究者に対して一定期間研究データを保存し、必要場合に開示することを義務付ける規程を整備し、その適切かつ実効的な運用を行うこと」

義務付けている。

そして、当該論文の筆者らの所属大学

国立大学法人東京大学における研究活動上の不正行為の防止に関する規則

http://www.u-tokyo.ac.jp/gen01/reiki_int/reiki_honbun/au07410491.html

には

研究者は、研究活動正当性証明手段を確保するとともに、第三者による検証可能性担保するため、文書、数値データ画像等の研究資料及び実験試料、標本等の有体物(以下「研究資料等」という。)を別に定めるところにより適切に保存し、開示の必要性及び相当性が認められる場合には、これを開示するものとする。」

とある

当該論文は、国の立法に影響を及ぼすことを目的として各所で用いられているのであり、データとその解釈科学的に正当な疑義が提出されており、また開示しない特別理由もない以上、データ開示の必要性があるのは疑いがないところであろう。

まり、この定義によると、再三のデータ開示の求めにも応じず拒否し続ける責任著者らが、この規則違反しているとみなすこともできるであろう。つまり、この規則によれば、この論文の著者らは、ある種の不正行為を行っている可能性があることになるのである

この通報後、窓口担当者らは、本件について医学部長らと議論し、その結果、この論文責任著者はその有識者に回答のメールを送付した。しかしながら、その回答には、

倫理委員会承認された研究手続きを逸脱することになるのでデータは開示できない、

・混交要因の候補変数について両群で比較した結果、有意差はなかった(実際の統計値の提示は全く無し)、

・その他は、科学者コミュニティーオープン議論すべきなので、当該Journalにletters to the editorとして質問せよ、

との主旨の内容があるのみで、リクエストや指摘の重要ポイントについては、実質的な回答は全く得られなかった。

その有識者は、4月26日にその論文ウェブサイト上のコメント欄に上記ポイントについて書き込みをした上、議論を行うよう著者にメールにて依頼を行ったが、著者らからは、5月9日現在、何の返事や回答も得られていないとのこと。

http://www.scirp.org/journal/PaperInformation.aspx?PaperID=74779&#abstract

著者らの誠実な回答と、著者らの所属大学による速やかで適切な対応が期待される。

その有識者は、こんなことを言っていた。

科学の基本は「エビデンス」ではないのか?そしてその「エビデンス」とは、データのもののことではないのか?そのデータがなぜ有識者にすら提示できないのか?連結不可能匿名化されたデータであれば提示はできるであろうし、すくなくとも重要な混交要因候補について各群ごとの統計数値のテーブルくらいは提示すべきではないのか?

データ不在で第三者による検証ができないような「科学」は、もはや「科学」とはいえないのではないか。それは控えめに言って疑似科学さらに言えば、科学の名を借りたカルトである。そんなものに、国の立法が影響を受けること、そして多くの人々の生活が影響されることがあってはならない。」

・・・・・

以下、5月15日追記。

千田有紀教授より、

ブログ文章を読む限り、分析妥当性をめぐる疑問のように思われました。そういうことを、「不正」などと言ってはいけないと思います。」

との指摘をツイッター上でいただいた。 

しかし、このブログで指摘した不正可能性は「分析妥当性」についてではない。指摘したのは、リクエストに応じてデータを開示しないことについての不正可能である

論文著者らの大学の「不正行為の防止に関する規則」に

研究者は、研究活動正当性証明手段を確保するとともに、第三者による検証可能性担保するため、文書、数値データ画像等の研究資料及び実験試料、標本等の有体物(以下「研究資料等」という。)を別に定めるところにより適切に保存し、開示の必要性及び相当性が認められる場合には、これを開示するものとする。」

とあり、これに違反しているのではないか、という指摘である。この点、ご留意いただきたい。

・・・・・

以下、5月29日追記。

本日付け、中日新聞朝刊でも、当該研究が紹介された。

東京大学大学院研究グループが面会交流による子どもへの影響などを初めて調査した結果だ。」

「面会交流子どもにとって良いことだと言われるが、DVがあった別居親との面会では、こどもたちは長期にわたり悪影響を受けている。」

などと、面会交流子どもに悪影響を与えたと因果関係として紹介されている。

しかしながら、当該研究は単なる相関を調べた調査であり、しかも上記のように混交要因についてきちんと吟味されておらず、(仮にデータのものが正しかった場合でも)因果関係については主張することは極めて不適切である。相関と因果関係区別をしないという、基本的な誤りをおかしているといえる。

以下、6月28日追記。

春名氏による当該の論文サイト上での回答を受け、親⼦ネット中部共同親権法制運動の会、親⼦断絶防⽌法全国連絡会などが連名で、東京大学の窓口に不正疑惑の申立を正式に行った。

「全国連絡会は構成団体及び杉山弁護士石垣臨床心理士と連名で「春名めぐみ 東京大学大学院医学研究科准教授」の論文に対する下記申し立てを同⼤学科学研究⾏動規範委員会に対して行いました。」

東京大学による責任ある調査と回答が期待される。

2017-05-03

ビット演算を使いたがる人

速いとかメモリ無駄がないとかでやたらとビット演算を使いたがる人がいる

速さとかメモリ使用量にこだわる場所じゃないかふつう変数使ったほうがわかりやすくないですか?

っていうと

これくらい誰でもわかるでしょ

っていわれる

2017-04-25

http://anond.hatelabo.jp/20170425115251

おれは俺もそう思う。

変数の中に何入れても成り立つからこそ言ってるのにって。

2017-04-24

隣の席の人が怖い

新しいプロジェクトで隣の席になった人の独り言が怖い。

プログラミングブツブツ言うのは全く気にならないんだけど、時折「死ねよこのコード書いたやつ」とか言い出す。

挙句には変数名をfuckにしたり引数にfuckを渡したりコマンドラインにfuckって書いたりしている。

変数のfuckは気付いたら普通になってるけどこんなにイライラしながら仕事してハゲないんだろうか?

2017-04-22

http://anond.hatelabo.jp/20170421230333

基本英語(つーか半角英数)のプログラムの中で

変数名とか関数名とかを全角の日本語統一すると、

全角文字アイキャッチになって、可読性が上がって良さそう。

漢字カナ交じりの日本語ってすごく速読に向いてるよね。

英語の本を流し読みしたいときに、すごくそう思う。

変態言語として、全角で書くと変数名として解釈されるとか、

そういう仕様言語があってもいいと思う。

http://anond.hatelabo.jp/20170421230333

増田変数名・関数名・カラム名について語り合いたいし、語り合っているので

ひまわりなど日本語で書けるプログラム言語はある」とドヤってるブクマカ勢は反省して

http://anond.hatelabo.jp/20170421230333

今、仕事をしてるシステムは、DBテーブルカラム漢字になっていてすごくわかりやすい。

SQLとか、

SELECT 
  商品名, 
  商品略称, 
  仕入値, 
  売価 
FROM 
  商品マスタ 
WHERE 
  仕入日 >= '2017-04-01' 

みたいな感じ。

DBからとってきた値をいれる変数も同じように日本語にしたらめちゃくちゃよくなりそうだけど、残念ながら既存ソースがそうなってないから俺もソースのほうはローマ字で書いてる。

http://anond.hatelabo.jp/20170421230333

判る。俺もたまに、日本語でいいんじゃね、って思うよ。

日本語にしたいのは、業務固有の用語だね。各人がバラバラに英訳されて、何だこれ?ってならなくて済むからね。

対応表を作りゃいいのかも知れないけど、作ったり参照したりメンテする手間を考えるとさぁ。

で、俺も考えるだけで実際には日本語変数名なんて使わないんだが、使わない理由は、みんなやってないから、だね。

誰かが勇気を持って踏み出してくれりゃいいのに。

テストコード日本語使ってる実感だと…

テストコードシナリオ名とか振る舞い名は日本語で書いてる。

プログラム部分とテスト部分がはっきり区別できるし、テストコードがそのまま要件定義になって便利。

ただ、他の変数とかメソッド名は、英語の方が良さげな気がする。

日本語で書いたテストコードを読んでる実感からすると、文章的に読むのはいいけど、構造把握するのにはめんどくさそうな印象。

http://anond.hatelabo.jp/20170421230333

C++/Perl/Rubyゴミ

分かったのは言語の多機能さというのは、一点水準さえ満たしていれば、それ以上足しても生産性寄与しないという事

自分しか使わない、最初書くときに限れば書きやすいと思うこともあるが、それ以上に保守性を落とす

ライブラリを利用したり他人コードを読む機会の方が多い昨今マイナス要素でしかない

perlスローガンだかに "There's More Than One Way To Do It." というのがあるらしいが、読む側からするとたまったもんじゃない

演算子オーバーロードされてるかも?モンキーパッチされてないかな?等々あれこれ想定しなきゃいけないのが苦痛しかない

スラムダンク流川が沢北を抜いたのも

パス選択肢を見せた事で沢北が集中できなくなってしまたか

それほど選択肢が多いということはストレスになる

Rubyゴミ

DSL(笑)が良いと思ってるのは最初だけで、最終的に負債しかならない糞コード

統計機械学習系のライブラリが皆無で先細りのイメージしかいかRailsと一緒に心中ください

Perlゴミ

リスト評価スカラー評価とか意味わかんねーくくりもtie変数アイディアは糞中の糞

Perl6にいたってはわけわかんねー演算子オンパレードで悪いところをさらに悪くした感じ

C++ゴミ

テンプレートマクロboostも何もかもダメ意味不明

オーバーロードされまくりコードなんてどっから読んでいいかわかんねーよ

こんな意味不明なことを覚えていられるほど人生長くない

結局PythonとかGo言語現実的な解で黒魔術のある言語なんて意味ない要らない使わない

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん