「.NET」を含む日記 RSS

はてなキーワード: .NETとは

2017-04-26

DeNAホテル連れ込み事件推定無罪原則は?

http://bunshun.jp/articles/-/2280

http://b.hatena.ne.jp/entry/bunshun.jp/articles/-/2280

ブコメ、まるでX氏が真犯人であることを確定で凄まじい勢いで叩いている。

推定無罪原則は?

推定無罪原則ってちゃんと常識として共有されてるんだろうか

http://mubou.seesaa.net/article/449111781.html




おもっきし真逆ブコメしてるクズもいるし

http://fut573.com/compare/?url1=http%3A%2F%2Fbunshun.jp%2Farticles%2F-%2F2280&url2=http%3A%2F%2Fmubou.seesaa.net%2Farticle%2F449111781.html

http://fut573.com/compare/?url1=http%3A%2F%2Fbunshun.jp%2Farticles%2F-%2F2280&url2=https%3A%2F%2Fnews.yahoo.co.jp%2Fbyline%2Fshinodahiroyuki%2F20170422-00070193%2F

女子大生狂言かもしれんし、

実際行為はあったかもしれないが当時は完全同意女子大生が後で翻意したのかもしれない

ましてやこの訴え自体文字通り「週刊誌レベル」にすぎない

裁判もまだ始まっていないし、

何より肝心要のX氏側の弁明は一言もない

一方的女子大生当事者証言のみの不確定極まりない話

これでDeNA叩いてるバカどもって推定無罪とかどーでもいいってことですよね?

結局はてなで言われる推定無罪なんてダブスタにすぎない

自分に甘く他人に厳しい

ただそれだけ

偉そうなこと言ったって言った本人がまともに守りゃしないんだから

そりゃ世間はそんな言うこと聞くわけがねえ


くたびれはてこもひどかったなあ

言ってることが平気で正反対になる

それで平気なツラして社会正義を語る

ちゃんちゃらおかしいぜ

はてな正義は、所詮この程度

底が割れてるんだよ

マストドン現状

friends.nico

江添という人がtwitterにおける広瀬香美になっている。だいたいアニメアイコン

mstdn.jp

だいたいツイッターアニメアイコンのノリと同じ

mastodon.cloud

外国サーバーだが日本人(ほぼメンヘラ)が古参ぶって馴れ合ってる

pawoo.net

手遅れだが仕方がない

kinugasa.me

家入がもう飽きた

2017-04-24

「一番上に戻るボタン」付けてないブログ、やり方教えてやるから今すぐ付けろ。読みにくいんだよ【はてなカスタマイズ】 - Travel Banana

ttp://www.travelbanana.net/entry/backtotop

ブコメの反応を調べてみて、前向きなリアクションをしてる人たちが本当に実践しているかどうか調べた。

n****y 付けてみようかな!

→つけてない

m*******9 これやりたかってん。かえったらやるわーありがとう

→やってない

a*********i こんなにこの人を困らせてたとは。付けよう。

→ついてない

d******k 導入しま

→導入してない

t************m 導入してみます

→導入してない

ファーwwwwwwwwwwwwwww

2017-04-23

http://anond.hatelabo.jp/20170423012045

ローカルの流れが速くなってきたらインスタンス分離するんじゃない?2ちゃんねるニュース速報からVIP隔離したり嫌儲ができた時のように。

pawoo.netだったら18禁投稿許可するインスタンスとそうでないインスタンスで分離できるし、mstdn.jpなら関東関西みたいに分離できると思う。

分離するほど栄えてくれたらの話だけどな。

マストドンの現状

唐突流行り始めたマストドンの現状について記録しておく。

現在日本語がメインのインスタンスはmstdn.jp(ユーザ数85k、個人運営ドワンゴ入社)、pawoo.net(ユーザ数78k、pixiv運営)、friends.nico(ユーザ数10k、ドワンゴ運営)、の3つが主な勢力となっている。

マストドン分散SNSなんだからどこのインスタンスにいようと同じだろ」と思うかもしれないが、それは正しくない。というのも、「マストドンをどう使っていいのか」が、現状ではまだ誰にもわからいからだ。少なくとも現在は「ローカルタイムライン使用したチャットツール」としての使われ方をしているため、どのインスタンス所属するかで、かなり印象が違ってくる。

たとえばpawoo.netハイレベル変態集会所となっている。昨日の深夜、男の娘ママについて熱く語り合っていたのを見たときは、「人類は衰退しました」で妖精さんが数日にして文明を作り上げたシーンを思い出した。

friends.nicoは'90年代からインターネットにどっぷりだったようなおっさん寄合所となっている。年齢層が高めのためか治安がよく、ローカルタイムライン話題を追えるギリギリの速度のためコミュニケーションを取りやすく、少なくとも筆者は現状で一番居心地がいい。

mstdn.jpローカルタイムラインを追いきれないので見ていない。筆者はこの「ローカルタイムラインの速度」というのが今後のマストドン進化において重要な要素になってくるのではないかと思っている。

いまさらだ説明しておくと、マストドンにはホームローカルタイムライン連合タイムラインという概念があり、それぞれ違う役割を持っている。

ホーム自分発言フォローした人の発言等が表示される。Twitterと同じような使い方をするならここがメインになるだろう。

ローカルタイムライン所属するインスタンス内の公開発言がすべて流れる。現在friends.nicoユーザ数が1万人で、ギリギリ話題を追える速度なので、このあたりが閾値になりそうだ。

連合タイムラインはそのインスタンス連携しているインスタンスの公開発言が流れる。これはとてつもないスピードタイムラインが流れていくのでとうてい追い切れるものではない。しかもそれぞれのインスタンス文化圏が違うので話題もバラバラだし、それぞれのインスタンス独自用語独自実装があるので、他のインスタンスから見ると意味がわからないことも多々ある。

たとえばfriends.nicoで「〇〇さんの発言ニコりました!:nicoru:」と発言したときfriends.nico内では「ニコるお気に入り」という前提があり、:nicoru:が独自実装ニコニコマークに置換されるため、ちゃんと伝わるのだが、他のインスタンスからしてみれば、まず「ニコる」という用語がわからないし、:nicoru:マークも置換されないのである

このように、連合タイムラインはその超スピードあいまって正直あまり意味がないものになってしまっているのだが、筆者はこれはこれで必要機能だと思っている。ローカルタイムラインだけを見ているとその文化圏言語圏に閉じてしまいがちになるが、ふとした瞬間に連合タイムラインに切り替えると、そこにはいろんな文化圏があり、いろんな言語圏があることを思い知る。そのタイムラインをすべて追うことはできなくても、その人たちと直接コミュニケーションを取ることはなくても、たしかにそこにいる。たしかにどこかでつながっている。そういう感覚が常にある。ニュースグループIRCICQSkype掲示板SNSでも似たような感覚はあったが、それとも少し違う妙な感覚だ。

もちろん現状の「ローカルタイムライン使用したチャットツール」という使われ方は長続きするものではない。mstdn.jpを見てわかるように、ユーザ数が増加するとタイムラインの速度も急激になり、会話が成立しなくなるからだ。今後はTwitterよろしくフォローフォロワー関係性が重要になり、ホームタイムラインがメインになっていくかもしれない。その場合ローカルタイムライン現在連合タイムライン役割を果たすだろう。または何か違う別の方法スケールできるようになるかもしれない。その仕様がどのようなものかはわからないが、この唐突にあらわれた風雲児がどのような成長を果たすのか、しばらくは見守っていきたいと思う。

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ローマ?という日本語より表記が揃わない問題ある。

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

---

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

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

そういうのは対象外

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

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

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

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

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

---

テスト

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

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

---

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

2017-04-19

http://anond.hatelabo.jp/20170419134819

日本国内に限れば、mstdn.jp と pawoo.net が2大インスタンスで、

ここがトラフィックに掛かる費用負担し続けている限り、わりと長期に続きそうな気がする。

企業だけでの費用負担が難しくなって、インスタンス内外ユーザから課金で賄うモデルへ移行する可能性もありそう。


インスタンスが大きくなりすぎると、トラフィック問題で潰れるという教訓をもとに、

GNU socialのBitTorrentバージョンみたいなアプリを誰かが作って一気に普及する…のもありそう。

すごい! クロネコ屋さんはいっぱいサイト運営して7500万も稼いでるんだ!

収益報告】私がアフィリエイトで1年で稼いだ金額は7500万でした。

http://moonpower2020.net/2017/04/18/post-464/

7500万円も稼いでるなんてすげー!

どうやって稼いでるんだろう!!!気になるー!!!

http://bipblog.com/archives/5256843.html

1 名無しさん@おーぷん 2016/08/07(日)20:40:30 ID :lGf

ちなみにアフィ歴は2年ちょい

52 クロネコ屋@アフィリエイター 2016/08/07(日)21:08:01 ID :lGf

分かりにくいか名前入れとく。

ツイッターもこの名前でやってるけどアフィ垢だからバレてもいいや。

2ch降臨してた。コメ欄ボコボコにされてるけど。

※108 以下、VIPにかわりましてBIPがお送りしま2016年08月09日 16:40 ▼このコメントに返信

はてなid: moguhausu2だからググればサイト出てくる

http://b.hatena.ne.jp/moguhausu2/

プ ラ イ ベ ー ト モ ー ド

でもプロフは見えるんだ。

http://megalodon.jp/2017-0419-0002-19/s.hatena.ne.jp/moguhausu2/?via=201007

念のためクロネコ屋とmoguhausu2か同一人物かどうかは2chまとめコメントだけだとアレだったから調べた。

クロネコ屋(moonpower2020.net)とmoguhausu2(www.hazimetetensyoku.com)のAmazonアフィリエイトIDが同じ「moguhausu2011-22」だった。

あと以下のサイトも同じだった。

カップルの悩みまとめブログ ttp://kappuru.dreamlog.jp/

大人のための転職活動支援塾 ttp://www.hazimetetensyoku.com

モテる男のナンパマニュアル ttp://blog.livedoor.jp/moguhausu2-america/

健康管理法、彼女の作り方、ネットで稼ぐ方法まとめ、美肌、転職…アッ…(察し

日本ゲーム市場ガラパゴス - 仕事を辞めたい人のための後悔しない転職方法。3回の転職で私が学んだ長く働ける会社の探し方

ttp://rakunikasegu.hatenablog.com/entry/2015/12/14/143600

3回も転職してDODA転職成功させるなんてすごいなぁ!しかも今は役員で7500万も稼いでる!すごい!!

他にもアダルトサイトもいくつか運営してるっぽいし稼ぐのは大変なんだなぁと思いました!!!

あとモグハウスっていうIDだとかTwitterはNINJAKUSOKUSOだったりして、ひょっとしてヴァナ・ディール冒険者じゃないかなと思いました!!

2017-04-18

http://anond.hatelabo.jp/20170418161819

ユーザ数の多い mstdn.jp は、さくらインターネットスポンサーについたし、

pawoo.netpixiv がやってるから、しばらくは資金面心配不要だろうけど、実際どうなんだろう

2017-04-17

http://anond.hatelabo.jp/20170417174332

Twitterの致命的な欠点は、一企業運営なのでいつ無くなるか分からなかったこと。

そして、エロ絵の規制が厳しく、どんな条件で決まるのか分からないままにBANされてしまうことが多々あったこと。

その2点が解消するだけでも、人々はますとどんの誕生歓喜したのだった。


だが、実際に起こったことは、 pixiv という一企業が pawoo.netというインスタンス絵師を囲ってしまっただけなので、

pawoo.netがいつまで続くか分からない(膨大なトラフィックにかかる費用pixivがいつまで負担し続けられるか分からない)

インスタンスとの接続問題で、どこまで画像制限が加わるか未知数

という状況になってしまった。

2017-04-16

C#アプリ作って配ったら、.netインストール必要じゃん・・

delphiでやるか

2017-04-15

今日ますとどん

Pixiv社が、マストドンインスタンス pawoo.net を立ち上げる

エロ絵師登録殺到

TLがエロ絵で一杯になる。

海外インスタンスから、pawoo.net接続拒否へ。←イマココ

2017-04-07

http://anond.hatelabo.jp/20170407112743

意識低い企業研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。

働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。

C言語とかC++・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、

WindowsAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。

組み込みプログラミングではC言語はいまだに現役。お金普通に稼げると思うよ!次代のCOBOLと化しそうで怖いとこはあるけど。

Java・・・使える人が多いからあえて今から学習しなくてもいいような気がする。

文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有セオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。

セオリーとかあるかもしんないけど速度とか気に揉むまえに書いて測れ。たいていは杞憂か、あるいはCPUパワーで殴れるから

Go・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。

ライブラリ選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。

GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。

Goデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。

GoGUIつくるの?あんまり普通じゃない気がする。軽量プロセスうまみがそんなない(詳しい人に否定されそうだけど)

普通にC#(mono/.net)かwebアプリにするかで良くないか

ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。

20言語Hello World出来るより、1つの言語でいろんなアルゴリズムを知っている方がすごいと思う。

コミュ症がフランス語英語ドイツ語覚えても、使う機会がないとまったく価値がないと思う。

アルゴリズムは使うものだ書くものではない!!

広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。

twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。

一応著名なプログラマーTwitterフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像RTしてたりと、twitterはメインの情報収集としては利用してない。

twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いか自分からリプは送ったりはしない。

ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。

深さ優先探索とか理解できない。

コード写経しても覚えられないし、仕組みは理解したけど自力コードが書けない。

コードにする能力ってどうやって鍛えるのか知りたい。

アルゴリズムは使うものだ書くものではない!高階関数とかテンプレートプログラミングとかその辺勉強するといい。

あと計算制限時間内に終わるなら総当たりが最速で品質も高いぞ。

エディタサクラエディタからVimに変えた。

どうしてVimかというとプラグインが多いしIDEっぽくできるから

Vim使う一番の理由は補完が強いのが気に入ってるから

Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。

NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。

Vim知らない。Linux使うならVimemacs使えるだろみたいな雰囲気あるけど、GUIならgedit, CUIならnanoでいいよね。

パソコンスペックもどのくらいのものを用意したらいいのかわからない。

10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートからプログラミングに向いてないのかもしれない。

VirtualBox上のubuntuMySQLコンパイルすると2時間20分ぐらいかかった記憶がある。

CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。

スペックお金をかけることで時間節約ツール選択肢が増える

EclipseなどのIDEが支障なく使えるレベルスペックってどのくらいするんだろう。

ノートCore i3メモリ4GBにランクアップしたらいけるのかな。

他人がどんなスペックPCで何のツール使ってプログラミングしているか知りたい。

3年前のCore i7, SSD, 8GB。最近はもっぱらJupyter。

もっと早いPCが欲しいけど、年度末に買うのを忘れた。

Python・・・機械学習する上で避けて通れないけど、今のPCだと無理。

例題が豊富逆引き辞典みたいなサイトや本がほしい。

あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。

過大請求されるの怖いし、トラブルが起きた時に英語コミュニケーション出来ないから。

Pythonはいいぞ、機械学習だけじゃなく計算系はエクセルじゃなくてJupyter使う。でも周りはエクセルつかってる、勿体ない。

使ってないけど最先端研究では機械学習使って当たり前感があってそろそろヤバい

僕は中学生の頃、いじめにより心の余裕なんてなかったか勉強どころではなかったけどもっと英語勉強しておけばよかったと後悔している。

やっぱり子供の頃の生活環境って大事だなと思う。

今は英検3級に向けて勉強中。

APIドキュメント頑張って読もう。俺も頑張って読んでる。

何を学習したらいいのか本当にわかんない。

迷宮にいる感じ。

なんとなく、プログラミングじゃないほうがいい気がするなあ。

とりあえずバイトしてPC買わない?プログラミングバイトでもいいと思うよ。

働き方改革最前線からは以上です。

2017-04-02

はてブNGリスト

http://syon-feed-filter.herokuapp.com/

↑のURLに↓を突っ込むと快適。@syonxvに多々感謝

NGワード

スク水揚げ

散るろぐ

散るログ

ねとらぼ

香山リカ

クレジットカードの読みもの

夜中に前へ

日刊ゲンダイ

OMGmag

人生ゲームである

あれこれやそれこれ

ナンダサラリーマンblog

WIRED.jp

GIGAZINE

LITERAリテラ

Rinシンプル生活

Qiita

SHIJIN BLOG

イケダハヤト

カムログ

セフレ

なうた横丁

さんのツイート

月無ことのは

ピピピピピの爽やかな日記帳

はあちゅう

NG URL

jin115.com

yaraon-blog.com

hamusoku.com

blog.livedoor.jp/insidears

alfalfalfa.com

pokemon-matome.net

yusaani.com

www.だいちゃん.com

jyajyayome.hatenablog.com

hitamu.hatenablog.com

numbers2007.blog123.fc2.com

www.xn--n8jvce0l6c.com

gendai.ismedia.jp

delete-all.hatenablog.com

matomatome.jp

matome.naver.jp

www.sugatareiji.com

www.cardloanblog.com

levites.hatenablog.com

taiwanlover.hatenablog.com

www.lifehacker.jp

www.pojihiguma.com

himasoku.com

daisuke-tsuchiya.hatenablog.com

jbpress.ismedia.jp

ismedia.jp

premiumcyzo.com

www.yuiki1994.com

karaage.hatenadiary.jp

warorince.com

www.cloudsalon.net

toyokeizai.net

www.ishikawayulio.net

www.islog.jp

www.nagurigaki.com

www.mikinote.com

www.hahalife0.com

www.jyajyayome.com

www.ituore.com

fujipon.hatenablog.com

hrktksm.hatenablog.com

www.sankei.com

www.outward-matrix.com

brian.hatenablog.com

dabunmaker.hatenablog.com

wepli-dot2.hatenablog.com

kyoko-np.net

www.anizm.xyz

www.ex-ma.com

netgeek.biz

www.ringobiyori.com

coliss.com

www.nikkan-gendai.com

onew-web.net

www.kana-ri.com

pipipipipi-www.hatenablog.com

www.americakabu.com

www.rinsimpl.com

togetter.com

2017-03-29

http://anond.hatelabo.jp/20170329075555

$ ping srad.jp
PING srad.jp (202.221.179.40) 56(84) bytes of data.
^C
--- srad.jp ping statistics ---
89 packets transmitted, 0 received, 100% packet loss, time 88029ms
$ traceroute 202.221.179.40
traceroute to 202.221.179.40 (202.221.179.40), 30 hops max, 60 byte packets
 1  aterm.me (192.168.10.1)  0.941 ms  2.273 ms  2.994 ms
 2  aterm.me (192.168.179.1)  2.827 ms  5.360 ms  5.500 ms
3〜9 ry
10  tky006gate01a.IIJ.Net (58.138.84.130)  77.222 ms  76.498 ms  77.012 ms
11  210.138.110.30 (210.138.110.30)  65.348 ms  65.626 ms  65.774 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

2017-03-24

ブラック保育園問題

http://anond.hatelabo.jp/20170324110417

悪徳業者が保育に参入したせいでモラル崩壊が起きてるってね。

虐待不正告発した園長たちは、会社ぐるみパワハラ解雇退職に追い込まれしまう。

自治体待機児童を増やしたくないか悪徳業者に逆らえない。

まともな保育士はどんどん辞め、保育の現場が荒廃していく。

東洋経済」より

発覚!おぞましい「ブラック保育園」の実態

h ttp://toyokeizai.net/articles/-/161108

コメント欄にも証言が続々。

2017-03-22

違法サイトDropbooksの素性を追う

オーナーチェンジを装って削除依頼フォーム英文にしたりしている違法エロマンガアップロードサイトのdropbooksだが、同じものホスティングされているbestreams.netは、WaybackMachineだと2016/9/11付のアーカイブからdropbooksになっているがその前2016/07/02までは英語でXVIDEO動画あたりを流しているBESTREAMS(ロシア語英語)となっているので、間は開いているものの、同一グループ可能性が大きいと思う。空白の2カ月の間にドメイン譲渡でもない限りは外国人グループ日本人が加わっていると見るのが適切か。

[][]

けものフレンズ』が流行ったのはセリフがキャバ嬢トークから相手を全力で肯定して励ますのはキャバ嬢トークのもの

https://www.logsoku.com/r/2ch.sc/moeplus/1487541503/

2 : なまえないよぉ~[sage] 投稿日:2017/02/20(月) 07:04:58.71 ID:4kbFrI40.net [1/1回]

すごーいてお前らの嫌いな矢口の口癖じゃん

2017-03-21

障害者の父(59)がyoutuberになりたいと言い出した

Youtube毎日給料日

ttp://youtubeclub.net/


これをスマホの画面で見せられた

通勤できなくても稼げるから


36万円をドブに捨てようとしている

どうやって止めたら良いんだよ…

2017-03-19

ブログマーケッターよ、はてブスパムを教えるのは辞めないか

ブログマーケティングスクール互助会流行っているらしい。

今日はてブ150以上付いた下記サイトもおそらくブログセミナー塾生の「互助会」の仕業

ttp://oahair.info/100click-book/

上記サイト運営者がブックマークしているサイトを辿っていくと、2件を除いて似たようなテンプレートサイトだった。

●ttps://turkey888.com/

●ttps://life-design.support/

ttp://wonder-things.com/

●ttps://www.officebk.com/

●ttps://hiwatariakira.com/

ttp://cascolle.net/cc/

●ttps://homeo.club/

●ttps://www.gamitaka.com/

ttp://iphonedocomoss.com/

ttp://globalselller.com/

●ttps://ucon-blog.com/

ttp://hoshinoena-kaiun.com/

●ttps://urarakajp.com/

●ttps://yamazaki-takashi.net/

ttps://polonjan.info/

ちなみに左に付いている●は、

1.Twitterブログマーケッターと相互フォロー

2.Facebookブログマーケッターと友達

3.ブログスクールWordPressテーマ「Elephant」を使用

4.ブログスクールHP顔写真掲載

のいずれかに当てはまるサイト特に3,4は塾生確定。

WordPressテーマに24800円、セミナーに月額5000円払って教えてもらうのがスパム行為とか笑える。

はてなは早く対処してくれ。

2017-03-06

C#大丈夫なんだろうか

スマホアプリ発言語の話。

SwiftとかKotlinみたいな流行りの言語パイセン呼ばわりされてる姿が目に浮かぶんだけど。

パイセンちーっす!今時簡単にnull参照例外起こす言語とかレガシー過ぎて見てられねえっすよねwww」

プロパティメソッドパスカルケースwwwつか何すかその無駄な字下げwwww」

みたいな。

でもC# (roslyn) 他.NET関係の開発はGitHubをフルに使ってオープンに進められてて一番好感度持てる。

頑張れC#、お前がナンバーワンだ。

F#はよく知らないのでノーコメント

2017-03-03

[][][]金融界への就職に強い慶應義塾大学

早稲田大学、慶應義塾大学、徹底比較

慶應義塾大は金融関連の職種に強く、



【就活生必見】メガバンク(都銀)の頭取の学歴から見る学閥の状況

東大と一橋の学生が10人ほどいた。ほかの大学の内定者はいない。

就活貴族 いきなり料亭でお座敷遊び

帝大と商大が80円,早慶クラス75円,MARCHクラス70円

ttps://twitter.com/matsuura_rits/status/174811759293636608

帝大65円 早慶55円 その他私大50円

ttps://twitter.com/ssgt0808/status/471248359345254400

ttp://hoshinokanata.net/itochu_ceo_gakureki/

ttp://hoshinokanata.net/mitsuico_new_ceo/

ttp://hoshinokanata.net/mitsuico_ceo_gakureki/

ttps://twitter.com/kazu_fujisawa/status/700904776851017728

ttp://changi.2ch.net/test/read.cgi/job/1263870676/320

2016年、哀愁の貴公子!: エコノミスト誌の記事、「東大 VS 慶應」についての所感。

経済学の研究が強い大学―慶應はさほど強くない : 大学・学歴データまとめ―研究、就職、受験、世界ランク

2017-02-28

くけぇーっ!!

ゴディバのうざい動画広告ブロックしてやったぜふぇーい

api.primecaster.net

macchromeではてぶ開くと重くて固まるんだが

左下見ると

redir.adbutter.net

なる場所接続しようとしてコケてる?

同じ症状の人いますか?

2017-02-25

Google翻訳オープンソースプロジェクトに使うのはダメなのか?

免責: これは法律専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。

最近プログラマの間で

Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」

http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace

が、話題になってますね。

Ubuntu翻訳プロジェクトで発生したトラブルの話です。

この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSS翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます

ですが、プログラマの間で単にWeb翻訳OSSに使ってはいけないんだという認識が広まってるように見えます個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています

どういう話かというと、自分個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースライセンスで公開しています)

注意書き

念のため言っておきますが、これは元記事問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります

コミュニティ思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。

Google翻訳利用規約について

もとの記事のとおり、Excite翻訳利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。

ここでは、Google翻訳に焦点を当てた話をします。Google翻訳利用規約はどうか?というと、Google利用規約については翻訳結果の利用についての記載がありません。

https://www.google.com/intl/ja/policies/terms/

記載がないということは、使用してよいのか?使用してはいけないのか?いったいどちらなのでしょうか?

GPLコンパイラの例

機械翻訳権利問題と似た構造の話に、GPLGNU一般公衆ライセンス)で許諾されたコンパイラによってコンパイルした結果の利用があります

GPLの本文には、GPLプログラムの出力結果自体GPLのものを含む場合にのみその出力結果にGPL適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているか記載はありません。

これについては、コンパイラによるコンパイル結果に対して、コンパイラ著作者はなんら権利を持たないと考えるのが一般的です。

GNU自体もそういう見解を持っています

https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput

著作権法は人々があなたプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。

コンパイラ機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります

ウィキメディア財団見解

ウィキメディア財団法務チームは、Google翻訳した文書ウィキペディア内での利用についての見解を公開しています

https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations

これはアメリカ法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスコンテンツGoogle翻訳翻訳してウィキペディア使用してもGoogle著作権侵害する可能性はとても低い(very unlikely)と結論づけています

要点をまとめると以下の通りです。

ウィキメディア財団見解には含まれていませんがアメリカ法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。

Oracle vs GoogleJava API訴訟

これはAndroidAPIJavaAPIが流用されていることについて、OracleGoogle訴訟したものです。

これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコ地裁では著作権使用料支払いの対象にはならないという判決が下っています

(この裁判自体はまだ続いているようです)

フェアユース」というのは、アメリカ著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権侵害とはしないと考えるものです。

Google翻訳結果のOSSでの利用をこれに当てはめると

ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidJava APIの流用と比べても、さらにフェアな利用であるように見えます

さて、ここまではアメリカ法律での話でした。

(ちなみにGoogle利用規約には、「カリフォルニア州抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州法律適用されます。」と書かれています)

文化庁見解

今度は日本法律に基づく話です。

著作権情報センターサイトに、 コンピュータ創作物についての文化庁報告書記載されています

http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html

この報告書は、機械翻訳ユーザー機械翻訳システム使用するために行う原文の編集や出力の編集創作的寄与となりうることを認めている一方で、機械翻訳開発者翻訳物の著作者になるということについては否定的です。

なお、原文解析等のプログラム作成者及び汎用的な辞書データベース作成者は、一般的翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。

これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳技術は大幅に進歩しましたが、創造個性表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます

これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者著作物機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間二次著作物になるということになりそうです。

白に近いグレー

これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているか説明してきました。

では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。

グレーなものを作ることの良し悪し

だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。

著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。

有名なところでいうと、Monoが思いつきますAndroidDalvikJavaAPIを真似したものであるのと同じように、MonoMicrosoft.NETフレームワークを真似しています。つまりMonoについても訴訟リスクはあっただろうということです。

しかし、OracleGoogle対立したのとは対照的な道をMonoはたどります

2016年Monoプロジェクト運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoMicrosoft公認プロジェクトになったというわけです。

権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。

Ubuntu日本語化プロジェクトでの良し悪し

すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntu日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています

まずは質の問題です。現在Google翻訳などは、UI翻訳に向いていません。UIほとんどは、意味合い文脈依存する単語や短文です。UI翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。

Google翻訳などを使って一括で、訳語を割り当てても良いUI翻訳はできません。

UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 )

次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntu日本語化ローカライズであれば、すでに多くのユーザー使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります

そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。

まりクオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。

自分場合

はいえ、OSSには個々の事情があります。次は自分場合の話をしてみます

まずは質の話です。

自分プロジェクト場合Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティ翻訳が出力されており、自分ゼロから翻訳するよりも、原文を翻訳やす修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳使用しました。

次にリスクの話です。

OSS企業権利問題訴訟されるということはめったにありません。OSS公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。

訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSS大金が儲かったらGoogleから訴えられてしまう!どうしよう!と考えるのは、宝くじに当たったら強盗におそわれてしまう!どうしよう!と考えるのに似ています

まず宝くじは当たらないですし、宝くじが当たったらそのお金対策を行えば良いだけの話です。

実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立していますLinuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。

これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。

別の視点でのリスク

それにOSSにまた別の角度のリスクがあります

権利問題訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業うんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます

そういったこともまた、OSSリスクなわけです。

結局のところ、自分場合Google翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Google翻訳改善するためのデータを得られます

わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか?というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェア翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。

質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります

OSS翻訳者コミュニティ機械翻訳の利用についてそのプロジェクトで使って良いか方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合コミュニティ方針確認した上でやっていくしかないんだろうなあと思うところです。

ログイン ユーザー登録
ようこそ ゲスト さん