東京大学では、学生や教職員が利用するPCや各種サービス一式を教育用計算機システム（ECCS）と呼んでおり、これを4年一度リプレースしています。2016年度はその更新時期にあたり、今回も入札の結果、クライアントマシンにはMacが選ばれました。東大では、2004年以来3期12年に渡ってMacが導入されてきましたが、、今回（ECCS2016）もこれが継承されたことで4年後の2020年3月（2019年度）までは引き続きMacが使われることになります。このあたりは、前回の取材記事で詳しく紹介しているので、文末に張ったリンクから関連記事をチェックしてください。 東大での取材で個人的にかなり気になったのが、もう変態といっていいほど特殊なMac。電源ボタンを押してもすんなりとOS Xが起動するわけではありません。Macハードウェア上で、UEFI（Unified Extensible Firmware In

こんにちは、成田（@mirakui）です。今日はみんな大好き ImageMagick チューニングのお話です。 2016/5/13 に公開された、いわゆる ImageTragick と呼ばれる脆弱性では、 policy.xml というファイルを更新するという workaround が紹介されていたのは記憶に新しいと思います。 この policy.xml は、今回の workaround のようにファイルタイプを制限するだけではなく、画像の縦横ピクセル数、利用するメモリやディスクのサイズなどを制限することができます。 Web サービスなどでユーザのアップロードした画像を ImageMagick で変換する場合、このようなリソース制限を適切に行うべきでしょう。 そこで今回は policy.xml によるリソース制限方法を紹介します。 前提 特に明記しない限り、2016/05/14 現在の 6

ISUCON6の出題者の1人の@catatsuyです。 GW直前の4/28、本年度入社の新卒エンジニア全員と社内のエンジニアほぼ全員が参加するイベントとして社内ISUCONを開催しました。 同じく出題者の1人である@edvakfの記事でも書いたように、今年のISUCON6では株式会社はてなさんと弊社で共同出題する予定です。 inside.pixiv.net 今回は弊社のISUCON6出題チームの4人で開催した社内ISUCONの様子を紹介します。 社内ISUCON 時間は12:30から19:00まで行いました。営業日に会社のエンジニアのほとんどが参加するイベントなので、午後を割り当てる形にするぐらいが良いのではないでしょうか。今回は新卒研修の一環としての側面があったので、新卒エンジニアにはISUCON事前ハンズオンとしてこのような内容の講義を行いました。 初期実装 初期実装の言語は『Ruby

We are excited to announce Amazon EC2 X1 instances. X1 instances extend the elasticity, simplicity, and cost savings of the AWS cloud to enterprise-grade applications with large dataset requirements. X1 instances are ideal for running in-memory databases like SAP HANA, big data processing engines like Apache Spark or Presto, and high performance computing (HPC) applications. X1 instances are certi

弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊社特有の部分は一部省いています。） ああ、なんという長い旅だったろう。この会社で５年間もセキュリティを担当していたよ（諸々の失敗は許してくれ） 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、

新人研修担当の長田です。 今年も新人研修の締めとして社内ISUCONを行いました。 昨年はプログラミング基礎の講師をやったのですが、 今年はその実績を買われて(?)社内ISUCONの出題を担当することになりました。 過去のISUCON準備の様子を傍から見ていた身としては、 準備を始める前から「とにかく大変そうだ・・・」というイメージを持っていました。 問題を作りこむ以上、どうしてもISUCON当日ぎりぎりまでかかってしまうのでしょう。 ぎりぎりになるのはまあ準備する人が頑張ればいいとして、 ぎりぎりになった結果競技自体の進行が危ぶまれるのは避けたい！ ということで、いくつか効率化という名の妥協策をとることにしました。 効率化できるところは？ 毎回新規に出題するのはしんどい！ 社内ISUCONは過去2回実施していますが、 どちらも新規に高速化対象のWebアプリケーションを作成していました。