映画『100日間生きたワニ』において、公開前から「レビューサイトでの荒らし」がはびこり、「予約システムで遊ぶ迷惑行為」までもが横行した。前者は（後述もするが）作品への誠実な批評をも貶めるものでもあるし、後者は限りなく犯罪に近い。言語道断な愚かしい行為であることは言うまでもない。 それだけに限らず、『100日間生きたワニ』への異常なバッシングムード、いや「事実がどうあれ叩きやすいものを叩いて嘲笑するネットいじめ」に、これほどまで多くの人が平気で加担したことに、大いに失望した。そして、この問題を通じて、ネットいじめの問題、そして批判（批評）との違いについて論じるのは、とても有意義なことであると思う。以下より、その理由を記していこう。 そもそものバッシングの対象が間違っている Twitterで爆発的な人気を得た原作『100日後に死ぬワニ』は、最悪のタイミングで無節操なプロモーション展開をしたため

へだる @hedalu244 【拡散希望】 なんか割れそうだったので Aの身長は150cm Bの身長は155cm Cの身長は160cm Dの身長は165cm Eの身長は170cm この5人の中で、Cの次に背が高い人は 2019-05-07 22:09:07

宿泊事業本部フロントエンドエンジニアの宇都宮です。 2018年度下期は、一休.comホテルリストページ スマホ版の速度改善に取り組んできました。その結果、ページのデザインはそのまま、機能面はリッチにしつつ、プロジェクト開始前の約2倍のスピードでページが表示されるようになりました。 本記事では、高速化のためにどのような施策を行ったのか紹介します。 なお、Webサイトの高速化手法については、ホテル詳細ページ高速化プロジェクトを実施した際にも記事を書いています。これらの記事で紹介している手法（たとえば、Imgixによる画像最適化等）については、記述を省略しています。あわせてご覧ください。 一休.comスマホサイトのパフォーマンス改善（概要編） - 一休.com Developers Blog 一休.comスマホサイトのパフォーマンス改善（JavaScript編） - 一休.com Develop

こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する

結論から言うと，そもそもなんでマイニングしたらあかんのかというのは結構曖昧なんだよな。電気容量の話も一つにはあるわけだけど(熊野寮は電気容量が小さく，しょっちゅうブレーカーが落ちる)、じゃあ電気容量に余裕があったらマイニングしてもいいのかというと、俺は駄目だと思う。本質的には電力を不当に消費していることにキレてるわけだ。なぜなら、まずそれは俺が払った金がOくんの懐に入っているということにほかならないし、光熱費は大学に半分負担してもらっているので、間接的に国民の血税から盗みを働いているということだからだ。 ここが難しいところで、じゃあお前の部屋にあるPS4が消費する電力についてはどう思ってんのという話になる。いやいやこれはマイニングと違って金を儲けてるわけじゃないんです、と言うかもしれないが、じゃあお前が寮の電力で起動したPCで在宅のプログラミングのバイトをやって貰ってる金についてはどう思う

私はGo言語が気に入っていますし、多くの場面で使用します。現にこのブログもGoで書いています。Goは便利な言語ですが、優れた言語とは言えません。つまり、悪くはないけれど、十分ではないということです。 満足できない言語を使用する際は注意が必要です。注意を怠ると、その言語を次の20年間使い続ける羽目になるかもしれないからです。 私のGoに対する主な不満を本文にまとめました。既に何度も指摘されていることも含まれていますが、中にはこれまでほとんど話題になっていない指摘もあります。 これから列挙する全ての課題には既に解決策があることを示すため、私が優良な言語と考えるRustやHaskellと比較して説明します。 汎用プログラミング 課題 誰でもさまざまな事柄に幅広く対応できるコードを記述したいと考えます。例えば数のリストの合計を求めるために定義した関数が、小数、整数、またその他の合計を求められるもの

この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

東大で開催された、姫野カオルコ『彼女は頭が悪いから』ブックトークに参加しました。正直、あまりにもモヤモヤする展開で、まるでこの空間自体が「彼女は頭が悪いから」のテーマを再現しているようでした。 今回のブックトークでは、2016年に起きた東大生による強制わいせつ事件に着想を得たフィクション小説『彼女は頭が悪いから』の内容から、以下のようなテーマで話す場だと告知されていたので足を運びました。（以下、告知文章より引用） ・性の尊厳、セクシュアル・コンセントとは？（性暴力事件の再発防止のために何が必要か） ・「学歴社会」と性差別について ・「東大」というブランドとの付き合い方、向き合い方感想としては、もっと上記の内容に沿った話をしてほしかったです。イベントを企画された林香里教授が開会の挨拶で、 「東大にとって、ジェンダーや性暴力の話題に関して外の空気に触れることは大事。どうしてこういうことが起こる

2018-12-01 Tags: Engineer ここ数日、とあるIT系企業グループのエンジニアの退職者エントリ（同時多発）がエンジニア界隈で話題でした。 一連のブログやらツイッターやらを眺めていると、 「ソフトウェアエンジニアとして仕事をしているのに支給されるPCが驚くほど低スペック」 「ググれない、github見れない、それでどうやって仕事できるというのか」 といったことに話題が集まりやすいようです。（他の視点ももちろんあるけれど） 発端となったらしい、6年勤めたNTTを退職しましたというブログにも、 給料 絶望的な社内環境（主にテクノロジー面での） という2つの理由が書かれています。 年収はさておき、2については、セキュリティを意識しすぎた厳しい制限と、（ブログ筆者の環境のことではないようですが）PCのスペック不足について言及されています。 しかし、件のソフトウェアエンジニア（研究

Vue Fes Japan 2018 の 1年間単体テストを書き続けた現場から送る Vue Component のテスト https://vuefes.jp/

インターネッツでは毎日がエキサイティングである。これを見て、たしかに〜わかることもある〜と思った。 「コミュ障エンジニア」の他の特徴として、Slackやプルリク等での文章のやりとりにおいて「断定形/詰問形/命令形が非常に多い」というのがありまして、「違います/〜しましたか/〜してください」みたいな、ビジネスマナーを理解できてない稚拙な言葉遣いをしてしまう傾向が見受けられますねｗ(^.^;)— 勝又健太@テック系Youtuber (@poly_soft) October 20, 2018 たぶん嫌な気持ちになることが何度もあって、ひとしきり考えてからちょっと尖った言葉を選んだのだろう。コミュ障かどうか、稚拙かどうかは置いておいて、たしかに「ちょっと言い方変えた方がいいのになー」と思う人はいるよね。そういう人とのコミュニケーションに慣れていないと、気をつかってしまったりイライラしたりしてちょっ

[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関

先日、Twitterに関連するサービスが炎上していました。簡単にこの件を述べると、Twitterに投稿されたイラストを機械的に収集し、それらをまとめてWebサイトを構築するというサービスに対し、“絵師”と呼ばれるイラスト制作者たちが反発したという問題です。 機械的に収集されたイラストの表示方法は、Twitterの規約的には問題はありません。しかし、「規約上他のサイトにAPI経由で表示される」ということを了承してサービスを利用している方が、ルール上正しく利用しているWebサービスを“マナー違反”だと糾弾して火がついていきました。詳しくはねとらぼの記事をどうぞ。 「勝手に転載しないで！」イラストまとめサービス「Buhitter」が大炎上 → Twitterは「規約上問題ない」（ねとらぼ） 法律とルールも難しい線引きですが、ルールとマナーの線引きはもっと込み入った問題になりがちです。ネットでは古

mzpです。こんにちは。 今回、Misocaを辞めて転職する決断をした。そのため、これがこのブログへの最後の投稿となる。なので、Misocaへの感謝を述べつつ退職の報告としたいと思う。 🏢出会い 新卒で自動車メーカーの系列会社に入社し社内SEをしていたが、やりたいこととのギャップを感じはじめたので転職活動をはじめた。 その中で、以前から知っていたMisoca(当時の社名はスタンドファーム)に話を聞きにいった。 自分が自社サービスに興味があったことと、Misocaも資金調達に成功し人を増やすタイミングだったことがうまくマッチし、入社を決めた。 こう書くとちゃんと活動したように見えるが、実際は退職を宣言したあと、何人かの知人とご飯を食べていたら話が進んでいたので運要素が大きい。 資金調達に成功してうんぬんは最近知った。 当時のメモには選んだ理由に以下のものが書かれている。 なぜスタンドファー

あと仕入れは基本クレカなんだけどこれについてくるポイントがまたオイシイ 月100万とか買い物するとマイルガンガン溜まるから旅行常にタダだぞ

仮想通貨（暗号通貨）のトレードや情報収拾をはじめる人に向けて、役立つリンク集を作りました。 2016年からこの業界をウォッチしてるのでそれなりの網羅性はあります。 DEG(デグ) ぜひ役立ててね。 ぼくのツイッターアカウントもフォローよろしくです... 仮想通貨市場全体の情報や各通貨の情報仮想通貨全体の時価総額や、各通貨の情報を収集するサイトたちです。 全体的な動向から自分の関心のある通貨やジャンルなどを分析できます。 CoinMarketCap 仮想通貨のトレードや情報収集をしている人がほぼ全て知ってるであろうサイトです。 このサイト内でよく使われるページは以下の3つ。 仮想通貨の時価総額→Global Charts各通貨の時価総額ランキング→Cryptocurrency Market Capitalizationsトークン限定の時価総額ランキング→Token Market Capita

先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回