  |
はてなキーワード: VIEWとは
前提として私は腐女子の絵描き。都内住みの地の利を生かして自ジャンルのオンリーと大型オールは全て参加してる。
そこでぺらいけど毎回新刊1冊は出してる。
毎月締め切り、毎月原稿、そんなことしてたらpixivだとかに作品上げる事もできない。支部のマイページはサンプルだらけ、viewの1割はlikeがつく程度の零細。
絵が旨いってわけでもないのに気に入ってくれてる人がいるのはありがたい。
だけどね、毎回ね、なんで同人誌書いてるんだろうってよくなる。
根本は自分が書きたくて書いてるんだけど、でもよく冷静になる。
自分が書きたいのは少年マンガで、でもジャンルとして求められてるのは少女マンガ。
自ジャンルでそこそこ活動しているからか、同ジャンルの友人が少なからずできてきた気はする。
とはいえそのほぼ全員がランカーだったりするので、自分に対し「ただのすり寄りなのでは？」って嫌悪する事も多い。
そんなのが色々重なってなんで新刊だしてんだろって毎回毎回嫌になってきてる。
じゃぁ書かなきゃいいじゃんって話なんだけど私は書かないと死ぬ人間で、この話は書きたいってのがたくさんある。
読者が待っていてくれるから！とかそんな作家先生目線な事は言わない。そういう意味でいうなら私という読者が待ってるから早くかけとは思うけど。
評価されたくない、誰にも読んでもらわなくていいと言ったら嘘になる。
誰かに読んで欲しいならそんなのさっさと流行りの話を書けばいいだけってのはわかってるし。
ジャンル的にもう読者は固定で新規開拓なんて人も少なくなってる。
なんなんだろなぁ、私は何をしたいんだろうなぁ。
作家様！って持ち上げられたいのかなぁ、自ジャンルの友達を増やしたいのかなぁ。
他人の声が一切聞こえない場所で、仙人のように霞だけを食って生きていきたい。
テレビなどで出てくる、手元の温度計で今38度です。昔に比べて気温が～とか、温暖化の影響が～とか言ってるのは、まさにストローマン論法ですよね。
あと30年前はエアコンがあまり普及してなかった～って話題なのに、「昔」が100年前だったりとかも…
そもそも「手元の」としている時点で、測定方法や地点が違うので比較できないでしょうし、「全地点の中の最高温度」などを表示して、他の地点も同じ温度のように印象付けたりしているわけです。
気温はどこで、どのように計測しているのですか
気温の観測は、風通しや日当たりの良い場所で、電気式温度計を用いて、芝生の上１．５mの位置で観測することを標準としています。
ようするに、（温度を上げるために）直射日光に当てたり、地面に近い場所で測ったような気温は、比較に使えないということです。
東京 日最高気温の月平均値（℃）
～
～
日最高気温の月平均値で見ると、多少変動はあるけど、そんなに上がってないですよね？
38度、39度というような数字は明らかに測定異常なレンジですし、100年位前と比べてみても、3度上がったとか4度上がったなんて言えないわけで。
（あえて日最高気温ではなく日平均気温を使って、100年位前の一番気温が低い年（1905年8月：22.2度）と、最近の一番気温が高い年（2010年8月：29.6度）だけを抜き出せば、○○度上がったという部分は、それっぽく印象付けることはできます…たぶん。）
ほんと何でだ
そのView縦横比まずいだろとか
それ実装できねーよとか
最大文字数のこと考えてないとか
単色過ぎて全体変な感じになってるとか
なんていうかなー
システムのこと考えてないんだよなー
デバイス差とか、親Viewのサイズとか、バージョンとか、得手不得手とか、システムにはいろいろ制約があるから
世の中にはガイドライン（お約束）がいっぱいあるんだがそういうの知らないんだよなー
納品してそのまま実装したらまずいことになるのは分かると思うんだが
そういう経験ないんだろうか
うーん
場所によっては「前は居たけどもうデザイナー居ないよ」みたいなこともある
さもありなん
ディレクターやお客さんの方がまだ分かってる
まともな人どこらへんに生息してるんだ？
うーん、医学研究者と名乗るなら身元を明かすべきだし、明かせないならわざわざ医学研究者といってマウンティングすべきではない。
内容も雑なので、身元を明かすと恥になるということか。
本当に医師ならば、患者さんらとまともに対話せずに、勝手に心情を決めつけることがアウトだと知れ。
副反応患者さんらの中には、安易な「心因性」判断により精神科に回されてむしろ悪化し、神経内科で免疫学的治療を受けてやっと改善しつつある方々もいる。
直接診たことがないのは何の言い訳にもならない。むしろ、医師として恥じるべき行為だと知れ。
またSNSで患者らに「暴言」を吐いている医師らの発言は「SNSなどではなかなか伝わりにくかったり」などというレベルではない。普通に「暴言」であり、ドクターハラスメントに相当する。
https://twitter.com/JprLb/status/1007923287261761536
こういう発言を矮小化する行為は患者さんに対する「攻撃」と同じだと知れ。
Scientific reports論文のretractに対して記者会見が開かれたのは、Scientific reports編集部側のコメントが無意味だったからだ。
Scientific reports誌の主張は、HPVワクチンの影響をみる際に百日咳毒素を投与するのは適切ではない、というものだったが、百日咳毒素は自己免疫性脳炎モデルでは標準的に使うものであり、マウスモデルとして考えた場合にまったく不当なものではない。そもそも専門家による査読は通っていたのであり、その分野の専門家は問題とみなしていない。
ちなみにデータとしては百日咳毒素を使わない場合のものも出ており、その場合も麻痺が観察されている。
ワクチンの投与量が多すぎるという主張をする人もいるようだが、単純な体重比で比較するという誤りを犯している。動物等価用量で換算すれば、毒性試験で用いられる量以下であることがわかる。これらは会見でも述べられていたと思うが。
また同様の報告はまったく別のグループからも出ているため、再現性はあるとみていいだろう。
名古屋レポートでは症状の重篤度を考慮していない。問題は生活困難なレベルの重篤な副反応なわけだが、軽い頭痛も、生活困難なレベルの頭痛も一緒くたにして「同様の症状」というのは詐欺的であろう。
名古屋レポートの問題点については多くの指摘があるので、読んでおくとよいだろう。
http://www.yakugai.gr.jp/topics/topic.php?id=906
勧奨中止後に激減しているのはHANSでみられるような重篤な症状を示す患者であって、「トートロジー的に減る」というのは不誠実な詭弁である。専門医が示すような重篤な症状がHPVワクチンと無関係に存在するのか？
誰もその存在を示していない。
https://www.jmedj.co.jp/journal/paper/detail.php?id=7027
HPVワクチン（ガーダシル）治験での生理食塩水によるデータは存在し、一部は以下のように公開されている。
にも関わらず、製品の添付文書ではアジュバントのデータしか出さずに比較している。それが批判されているわけだが、おわかりだろうか。NATROMもこれを理解していないか、隠している。
ガーダシルの場合、先ほどの治験サイトをみても深刻な有害事象には怪我や流産、早産は含まれていない。
池田としえ氏については詳しく見ていないが、HPVワクチン推進派の医師からデマを流されているとのことだ。
https://twitter.com/toshi2133/status/802739074029133825
素人ゆえに間違った発言もあるかもしれないが、単に事実を指摘すればいいのであって、推進派の医師らのこういう異常行為はワクチンのみならず、医の信頼を崩壊させる。本当の反ワクチン、反医療とはこういう医師らのことだろう。
村中璃子氏についてはすでにさんざん指摘があるように、発言の信頼性がゼロである。
関わらない方がよいであろう。
https://anond.hatelabo.jp/20160624124427
吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。
何でも薄暗いじめじめした所で手斧を投げられていた事だけは記憶している。
しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。
・・・・
まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた
Webサービスを中々時間が取れず作るのを諦めていたのだけど、
僕自身、プログラミングを生業とする職業では無く、学生時代も特にプログラミングついて何か
始めたのが昨年末の大晦日ちょい前なので、約5ヶ月掛かり、当初想定していた期間より
かなりの時間が掛かってしまい、反省点等含めその辺の事を書けたらなと思います。
■やりたい事（実装した事）
・ゲームユーザー同士を繋げるマッチングサイト（出会い系ではないよ。）
・タグをつける
構成を書いた方が良いと思うので
以下になります。
■構成
--------------------------------------------
FW：Flask 1.0.2
ORM：SQLAlchemy 1.2.7
その他ツール等：Let's Encrypt/fail2ban/等々
--------------------------------------------
ほぼ、既存のベーシックなサーバーサイド側の制御のみです。（jsで非同期通信はしてます）
変えるのもなと思い、取り敢えず上記です。
■選定理由
Railsの名前を良く聞くのでRuby on Rails触ったのですが、
Railsには馴染めなかった（扱えなかった）ので
何かマイクロFWの方が良いのだろうと、Sinatraいこうか思いましたが
Railsの印象が強く残った為、Rubyは止めてPythonに移りました。
今度は初っ端からマイクロFWが良いだろうとFlaskのサンプルを試すと
比較的プログラミング初学者でも扱いやすく覚える事も少ないので、PythonとFlask
の組み合わせで決定。
（気軽にプログラムを書け、自分がイメージしている処理や制御を素直に実現できる点が
書いていて気持ちが良いです。まぁ分からない所も有りますが、そう思わせてくれる点
が良いです。モチベーション的に）
NginxとuWSGIの組み合わせはFlaskで検索すると一番でてくるのでこれに決定。
SQLite3 はマイクロFWだから軽めのDBでたぶん大丈夫だと思ったのでこれに決定
■開発概要
・まずPythonの開発環境を整えようとなり、WindowsにVagrantをインストールして
仮想マシンの環境構築。ゲストOSの中にPyenv等を入れPython環境構築
・上記構築後に取り敢えず小さなサンプルから作ろうとなり、簡単なCRUDをFlaskで行える様にしました。
これができた時は嬉しかったです
・上記が出来てから、本番の開発に移りCRUDをベースにひたすら肉付けていく
→ユーザー登録機能作成/ログイン機能作成/ユーザー情報表示/編集機能/チケット作成/及び編集/バリデーション
・細かいViewの調整とスマホ用のViewも作成（レスポンシブルでは無いので）
・本番用のさくらVPSに環境構築とセキュリティ用のツール導入とLet's Encryptでhttps化
■悩んだ点/反省点
・悩んだのがタグ機能周りになるとどうすればよいか、かなり悩みました。
結論を言うとToxi法を使用しましたのですがここにたどり着き、理解するのに結構時間がとられました。
また、実装したらしたで、今度はそのタグ機能を検索するとなると検索ワードが1つとは限らないので
クエリーを動的に生成する必要が有り、これも実装するのにかなり時間が掛かりました。
SQL文だけならば比較的すぐに検索でヒットしますが、それをSQLAlchemyでどう実現すれば良いか分からず
かなり時間が掛かりました。DB設計やSQLAlchemyの文法に自信は無いですねぇ。。
・1次情報のリファレンスからは情報得ることがほとんど出来ず（たまにはできたが）、
Stack OverflowとQiitaと個人ブログが無ければこのサイトできなかったので
■総評
・5ヶ月と時間が掛かりまた反省点も多々有るが、とりあえずサービス公開まで
もっていけた事が嬉しいです。ただただ嬉しい。
・FlaskとSQLAlchemyの情報が日本語が少ないので公式リファレンスとStack Overflowを
行ったり来たりしたおかげで英語アレルギーがそこまで無くなった。
■成果物
オンラインゲーマー向け（e-sports）のマッチングサイトになります。
名前が安直で小学生が5秒で考えたような名前ですが、安直で気に入っています。
作った理由は、僕はBF1が好きなのでオペレーションキャンペーンと言うモードを
やろうとしたのですが、時間帯が悪いのか過疎なか分からないが全然マッチングしないのですよ。
やりたいのにマッチングしないので出来ないどうしよう、と。
また、昔セールでFarCry3をかなり昔に購入した時（既に4が発売済み）にCO-OPモードが全然マッチしない事が有り
旬が過ぎたオンラインゲームは中々マッチしなくてほぼシングルモードしか出来ない事は割とあると思うんです。
今だとBF4もかなり人数がいない状態なので特定マップのみとか。
なのでオンラインゲームでマルチプレイやCo-opで人を集めたい時、PUBGやFORTNITE等バトロワゲームのスクワッドを
募集する時、オンラインゲームの大会（e-sports）を開きたい時に利用して貰えると嬉しいです。
主に想定ユーザーと考えているのは、FPS/TPS/RTS/MOBA等のPCゲーマーをメインに考えていますがCS機やTCGでも
使って貰えると嬉しいです。
あとViewがレスポンシブでは無く、PC用とスマホ用しかなくタブレット用の中サイズのViewが無いのでご了承下さい。
遊んでも良いよという奇特な方がいましたら当該サイト内でコメント頂けると幸いです
・BF1（PC版）
それでは長々とありがとうございました。
・・・・
日月を切り落し、天地を粉韲して不可思議の無職に入る。吾輩は死ぬ。
ありがたいありがたい。
It's a bit like the crossroads of the sea, isn't it?
Then people leave here to go all over the world, huh?
Probably.
It's kind of amazing, isn't it?
In two days, we're leaving here. But this view will remain the same, right?
Of course, will.
We'll go to Antarctica, and come back to home, but boats will still come here every day, and the city will be full of people, going to school, working their jobs, hanging out with their friends, They'll all keep living their lives..
It' the same in our home country.
School's still being held, They're probably having dinner right about now.
In places we've never seen, locations we've never been, so many people are living so many kinds of lives, every day, without stopping. That's amazing!
Even though it's common sense, but we know you're getting at.
質問なんだが
よくyoutubeと比較して議論してる人がいるけど、大きな違いがある
youtubeでは製作者は無償でコンテンツをyoutubeに提供し、youtube側は広告料の一部を製作者払う。
漫画出版は多くの場合、出版社が作者に原稿料を支払って作者が出版社にコンテンツを提供し雑誌連載、その後コミックスとして出版した本の売り上げから印税を作者に払う。
広告料のみで雑誌売り上げと単行本売り上げ両方を賄わなきゃならないことになる
出版社の利益を確保しつつそれをview数で割るということになると作者の元には今よりもずっと少ないお金しか入ってこなくなる。
Quick Tutorial for Pyramid は公式のチュートリアル
https://docs.pylonsproject.org/projects/pyramid/en/latest/quick_tutorial/index.html
$ $VENV/bin/cookiecutter gh:Pylons/pyramid-cookiecutter-starter --checkout 1.9-branch
として、プロンプトの問いに答えるとサンプル的なアプリができる。
ghはgithubか。
引数で指定できるテンプレートは https://github.com/Pylons?q=pyramid-cookiecutter
sqlalchemyを使うものは分かるけど、zodbって何？
アプリは以下のようにして起動する。
$ env/bin/pserve development.ini --reload
このpserveというPythonモジュールでアプリ動かしたりする。
超単純なPyramidアプリを作って、WSGIのイメージをつかむ。
app.py を書き写して動かしたらHello Worldが動いた。
viewとURLの紐付けはconfig.add_routeしてconfig.add_viewする。add_viewしてからadd_routeしても大丈夫だった。
viewにはrequestが渡される。requestに色々入ってそう。
waitressは知らないけど、serveでHTTPサーバ作ってWSGIアプリを公開できるのかな？
print('Incoming request')
...instead of:
print 'Incoming request'
Inernal Server Errorになった。アプリのほうではValueErrorでresponseを返すようにと怒られていた。text/plainとか返すには何かしないとダメっぽい。
print(xyz)してみろ、ということかな。1と同じくInernal Server Errorになって、コンソールにはNameErrorが出た。
CGIかな？
そういう時は日本語ドキュメントを読む。作者とやりとりしたりして、不明点が解決している可能性があるからだ。
OSSのドキュメントは基本的に有志がボランティアでやっていることは承知している。
でも、英語が苦手なんだったら、翻訳作業に関わってはいけない。
試しに、適当なページを見てみる
https://jp.vuejs.org/v2/guide/single-file-components.html
「多くの Vue プロジェクトでは、グローバルコンポーネントは、new Vue({ el: '#container '}) の後に各ページの body においてコンテナ要素をターゲットにすることに続いて、Vue.component を使用して定義されています。」
↑
どういうことだろう？
原文はこうだ。
「In many Vue projects, global components will be defined using Vue.component, followed by new Vue({ el: '#container' }) to target a container element in the body of every page.」
つまり、グローバルコンポーネントは「new Vue({ el: '#container '}) 」の後で「Vue.component」を使って定義されることが多いと言っている。「to target a container element in the body of every page.」は意味不明だが、ここはこういう定義の仕方をする目的をさしていると思う。
「これは view を拡張するだけに利用された小さな中規模プロジェクトにおいてはとても有効です。 あなたのフロントエンドで JavaScript 全体を操作するようなもっと複雑なプロジェクトでは、これらの点において不利益になることは明白です。」
「小さな中規模プロジェクト」「あなたのフロントエンド」とはなんだろう、書いた段階でおかしいと思わないのだろうか。機械翻訳をするなら、日本語ドキュメントを用意しておく意味はない。
原文はこうだ
「This can work very well for small to medium-sized projects, where JavaScript is only used to enhance certain views. In more complex projects however, or when your frontend is entirely driven by JavaScript, these disadvantages become apparent:」
↓
「JavaScriptが特定の表示の拡張だけに使用されるような小規模〜中規模のプロジェクトにおいて、この方法はとても有効です。しかし、もっと複雑なプロジェクトや、フロントエンド全体をJavaScriptで制御する場合、この方法では次のような問題があります。」
ForkしてPull Requestするのもだるい。
こういうのが大量にあるから。
二次であれ一次であれ、自分の作ったキャラクター、世界観だけを、特定の二次創作の特定の狭い部分だけを書き続ける人がいる。
自分は、そうならないようにしてきた。狭い部分だけをずっと続けていると、その内それしか書けなくなってしまうのではないかと恐れた。新しいことをできなくなってしまうのではないかと恐れた。
自分は、自分の作ったキャラクターを愛さないようにした。そうして、出来るだけ一つの事に固執しないようにした。
そうなった原因としては、ある時書いた一次小説が偶々ヒットしたことが原因だった。今までそうview数とか増えなかったのに、多いときは1日10万pvを記録する事さえもあった。
自分はその時、人気が出たからと言って引き延ばしたりはしない事を決めた。その作品の人気に自分が固執する事を恐れた。それが最初だったと思う。
それまでは、人気が出なくとも、自分の好きなままに書き続けていたと思う。人気は欲しかったけれど、好きな気持ちで書き続けていたと思う。自分の作品を、周りの目をそう気にする事なく愛していたと思う。
今は、愛していない。結局、その人気が出た作品は引き延ばす事なくさっぱり元の構想通りに終わらせたけれど、その作品に引きずられはしなかったものの、人気には引きずられた。
どうやったら人気が出るのか、考えるようになった。新しい作品が人気が出なかったらポイと簡単に捨てるようになった。自分の作品を愛さなくなった。人気が出なかったときの事を恐れて、自己防衛するようになった。
今は、その、特定の事柄を書き続けている人を、純粋に周りの目もそう気にせず、人気も気にせずそれを愛して書き続けている人の事を、とてもうらやましく思う。
自分はもう、戻れない。
人気が出る事を目指して、自分の作品を愛さずに、頑張り続けている。
間違った道に入ってしまった感じが否めない。
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Button btClick = findViewById(R.id.btCalc);
CalcListener listener = new CalcListener();
btClick.setOnClickListener(listener);
}
private class CalcListener implements View.OnClickListener {
@Override
public void onClick (View view) {
EditText input1 = findViewById(R.id.etInput1);
EditText input2 = findViewById(R.id.etInput2);
TextView output = findViewById(R.id.tvOutput);
String input1str = input1.getText().toString();
Integer input1int = Integer.parseInt(input1str);
String input2str = input2.getText().toString();
Integer input2int = Integer.parseInt(input2str);
output.setText(input1int + input2int + "です" );
}
}
}
Integer.parseInt()を見つけるのが最大の難所であった