ssig33.com - DeNA TechCon 2018 『『Nintendo みまもり Switch』を支える技術』 の内容紹介と感想
そういうわけで https://techcon.dena.com/ にいってきました。 表題の発表は、撮影および SNS での内容共有の禁止ということになっていたので、内容を個人サイトで共有致します。その場にいなかった方でこの記事を読んだ方であればこの記事およびその内容を SNS で共有することは一切禁じられないかと思いますのでよろしくお願いします。 発表者 DeNA 堀、平賀 任天堂 名前メモし忘れた 公開されたスケジュールでは堀および平賀による発表ということになっていたが、任天堂の何者かが急遽参加したということだった。おそらく技術者ではなく広報の人。 サービス紹介 (任天堂の人) サービス内容については検索すれば分かることを普通にしゃべり、クッパがサービスを使うあの動画を流すだけ。(ssig33 の感想: なにしにきたんだコイツ) 開発体制 (堀) 任天堂は企画、ディレクション、 Sw
ssig33.com - Github Flow と組織
github という公的なインフラを使うために必要なこと - アンカテ を盛大に dis っとかなきゃなという気持ちになった。 Pull Request ベースの開発 階層型組織構造 は特に対立するものではないですし、階層型がいいのかフラットがいいのかは場合場合によるでしょう。階層型でばりばりに管理するような開発チームでも ディレクターが issue を起案する 開発リーダーとディレクターがプロダクトマネージャーなどを交えてスケジュールを決定する 開発リーダーがその issue を閉じる Pull Request を作る人とそれをレビューする人を決定しスケジュールを伝達する 所定のタイミングでリリース権限を持っている人がマージボタンを押す みたいなカチカチした運用でいろいろやっていけると思いますし、これでも Github Flow というか Pull Request ベースの開発の恩恵を十
ssig33.com - 2ch のアレ
robots.txt は法律上以下のようになってます。 無視してクロールしてもいいけど、無視してクロールした結果を公開するのはダメ つまり新 2ch では以下のようなサイトが法律上 NG になります API キーをアプリから解析して新 API 勝手に使ったりクロールしたりして過去ログ公開するようなサイト 上記のような仕組みで旧 2ch っぽいインターフェイスを提供するプロキシサイト 上記のような仕組みで動作する Web アプリケーション型 2ch クライアント OK なのは以下の行為です スクレイピングして動作するデスクトップ、携帯電話向けのクライアントを開発、配布する 無論、これらのクライアントが常軌を逸した動作をして、結果 2ch のサービス継続を妨害するようなことがあれば、 2ch は民事、刑事で適切な対応を取ることができるでしょう。この場合参考になるのは librahack 事件で
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
ssig33.com - インターネットが面白くなくなった
インターネットが面白くなくなっただとか、アニメが面白くなくなっただとか、金を使うような面白いものがなくなっただとか、そういうことを言う人がだいたい常にいます。 そういう現象を一言で表す言葉があって「老い」と言います。 老いは誰にでも来るものですしそれはしょうがないです。アニメは面白いですし、インターネットで意味不明な面白いことやってる人は今でもたくさんいます。 さて老いてなんで意欲が減退するかというと、筋力が落ちるからです。筋力が落ちると精神力も落ちてわざわざインターネットしたりアニメみたりする気も無くなってきますから、筋肉を鍛えよう。 back to index of texts Site Search
ssig33.com - 歯の思い出
それはそうとして。折った直後はあっ折れたーみたいな感じで、驚きがまずあった。痛みはあまりなかったが、いずれ激しく痛むこと予想されたので、痛み止めを買って 20 錠全部飲んだ。 その日は徳之島からの帰国日だったので、とりあえず子宝空港というサイケな名前の空港に行って、鹿児島空港でトランジットして帰国した。痛み止めが効いていたので羽田空港ではラーメンを食べた。歯が折れていて、食べづらい。 その日のうちに歯医者を予約する。かねてから通っている歯医者で、予約を取りづらいのだけど腕は信用している。歯が折れたというのは緊急事態なので、無理やり枠を作ってくれた。 翌日、朝起きると口がもうとにかく異常に痛い。意識がもうろうとしたまま、遠くにある歯医者に行く。歯医者で歯の様子をみるためにたたかれると激痛で叫ぶ。 X 線写真を撮るために口に入れられる何かが痛い。 この日はどういう治療したかよく覚えてないんだけ
ssig33.com - アメリカのプログラマの賃金に関して
サンフランシスコやニューヨークの家賃、スタジオ(日本で言うところのワンルーム)で月 2000 ドルとかする。家族と一緒に住める家とか月 3000 ドルは最低かかる。 家賃だけで年間 250-400 万円は持っていかれるという話になる。 Dropbox のあるテキサス州オースティンとかだとこの 1/3 なんだけど。 前に IT とか全然関係ない話でダラスに住もうとしたんだけど、家賃高すぎて結局断念した。 あと有名な問題が保険で、保険会社が指定する病院でしか診療受けられないしょぼい方の HMO というタイプの保険でも月 150 ドルかかる。年間 20 万円で家族が 4 人いたら保険だけで年間 80 万円は見ておこうという話になる。 医療に関して有名なもう一つの問題は「歯の治療の保険請求が異常に難しい」という問題で、アメリカに移住した知人が歯医者で保険適用された事例見たときない。虫歯になったら日
ssig33.com - ファイルダウンロード自動化を含むスクレイピング
なんのこっちゃという感じですが、具体的にやりたいことは以下の通り Amazon の コンテンツと端末の管理 から購入した Kindle 書籍を自動ダウンロード 何故こんなことをしたいかというと、 Kindle 本は DRM をクラックする確実な手段があります。 DRM をクラックすることは違法ですが、 Amazon という企業が消滅した時に、購入した本が読めなくなるのは困ります。 Amazon が消滅するときは世紀末のような社会でしょうから、 DRM のクラック程度の犯罪が問題になることは無いでしょう。 AZW3 をローカルに保存しておけば、その時がくれば DRM をクラックすればいいということになります。 以上の考えは半分本気、半分はまあスクレイピングしづらそうなものがあればやってみたい、というだけです。 JavaScript を含まないページのスクレイピングはどうとでもなります。 Ja
ssig33.com - 一般番組まで含めて録画しまくる
アニメだけだと http://karia.hatenablog.jp/entry/2014/10/28/044718 でいいと思うんですが、 Fast'N Loud などを見たいのでディスカバリーチャンネルとナショジオの新番組は全部録画するだとか、ジャニーズタレント出演番組全部録画したいだとか、 Twitter で follow してる人達の発言ひろって録画したいとかなると foltia では生きていけません。 うちの場合 うちの場合は合計 3 台の PC でまわっています ストレージサーバー兼アプリケーションサーバー 55TB のハードディスクがぶらさがっていて、 KVM な仮想マシンや、多数の Docker コンテナが動いています 録画機 チューナーが合計 3 個 12 チューナーついててひたすら録画する エンコーダー Intel Quick Sync Video でエンコードする ス
ssig33.com - Jenkins で Rails アプリを docker build する話
Rails アプリを Docker で稼動させる際に、 Gemfile と Gemfile.lock を先に ADD して bundle install してからアプリケーション全体を ADD することで、 bundle install の結果をキャッシュする手法はよく知られています。 ADD Gemfile /app/Gemfile.lock ADD Gemfile /app/Gemfile WORKDIR /apps RUN bundle -j4 ADD . /app こういうやつ。 ところがこの手法は Jenkins のように毎回リポジトリが clean にチェックアウトされる環境では全く無効です。 何故なら、 Docker は ADD するファイルが更新されているかどうかを、ファイルの中身そのものではなく、タイムスタンプなどのメタデータで確認しているからです。 git checko
ssig33.com - Docker を個人が使う時の注意点
Docker が何かとかそういう話は全部抜きにして書きます。 Docker においてよくある運用は どっかにプライベートなレジストリを立てる ローカルかなんかでビルドしたコンテナをそこにプッシュする 実際の実行環境ではそれを pull してきて起動 という感じではないかと思います。 3. の後にリバースプロキシだのなんだのいろいろ設定しないといけませんから、それは各種自動化フレームワークが用いられます。 ここまではいいのですが、問題は 2 です。 Docker は 2 をやるごとにほぼフルの Linux 環境をネットワーク経由でアップロードするということになります。これが案外バカにならなくて、測定してみたところこの二週間でこれでのアップロードの合計は 350GB ほどになっていました。 もうちょっと激しくなるとプロバイダの設定する帯域規制だったり強制解約要件にひっかかってしまいますし、単純
ssig33.com - はてなブログの話
とかあんましたくないんだけど、 はてなにはもともと超気持ち悪い人達と普通の人達と技術者がいた その昔いろんな言語がまともにシンタックスハイライトされるのははてなだけだった 超気持ち悪い人達と技術者が目立っていた 技術者のかなりの数が Qiita とかにいった 超気持ち悪い人達だけが残った 結果はてなに気持ち悪い人が増えたように見えるが実は増えたわけではない ということなのではないかと思っている、これを検証する為にははてなでの技術系エントリのホットエントリ数が減っているかどうかを検証していく必要がある、面倒なのでやりたくない、以上です。 back to index of texts Site Search
%E8%87%AA%E5%AE%85%E3%81%A7%E5%A4%A7%E5%AE%B9%E9%87%8F%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%92%E9%81%8B%E7%94%A8%E3%81%99%E3%82%8B
前回 RAID に関するちょっとした話を書きましたが個人が巨大なストレージを運用するにあたって得られたノウハウをだいたい全部書いておきます。 そもそもメリットあるのか？ メリットはあります。金です。 Google Drive は安いですが、それでも 1TB 月 1000 円です。しかし運用にかなり制限がでます。柔軟に使える Amazon Web Service ならその 3 倍+転送量課金です。 16TB だと月 5 万円もかかってしまいます。ちなみにもっとも柔軟に使える EBS だと 16TB で 83000 円ぐらいです。 Google Compute Engine の低冗長性ストレージは S3 より少し安かった気はするけど別にとても安いわけではなかったと思う(よく覚えていないし調べるのがめんどくさい)。 50TB のストレージを Google Drive でごまかしごまかし運用したと
ssig33.com - WD Green を mdadm で使う
Western Digital の GREEN シリーズの HDD は大変に安価なことで知られていますが、エラー訂正のために無反応になることがあるために RAID の構築には使わないようにとメーカーから警告されていることはよく知られています。 ですがまあそんなことは知ったこっちゃないわ金ないし WD GREEN で RAID 組むわみたいな風に考える人もいることでしょう。 私もその一人で、現在 26 台の HDD を用いて mdadm と LVM を用いて 54TB のアレイを構築して 24 時間 365 日稼働させています。ちなみに現在空き容量は 14TB ほどで 40TB のデータを自宅にためていることになります。 システムが現在の構成を取るようになってから 3 年ほどは経過しており、その間増設に増設を重ねて、全体としては安定して稼働しているといえます(個人のサーバーおよび録画システム
ssig33.com - Heroku の利用規約をちゃんと読んだ結果意外だったこと
機械的にアプリ作りまくるのは OK 最近 CI 実行毎に Heroku にアプリ作るみたいな蛮行をしている これに関してはいずれ記事をどっかに書く bot に Heroku に大量にアプリを作らせても怒られないということが分かったので、アプリケーションの QA において革命が起きるということが最近分かってきました。 僕と同じ目的を目指して専門にやってる PaaS があったりするんだけど今一なので Heroku で蛮行を働くとよい結果になるという感じです。 Heroku の懐の広さに我々は感謝しなければならない。 あと「PaaS 屋が技術調査の為に Heroku 使ったら問答無用で BAN」とか書いてあって面白かった。 back to index of texts Site Search
ssig33.com - 旅と在宅勤務
2 年間以上在宅勤務しています。会社から借りた MacBook Air はとっくにぶっ壊れて適当に放置されています。 2 年間のうち自宅にいた日数が 365 日に達しているかどうか分からないレベルで旅行その他をしてきました。 生産性は確実に落ちます 家でそれなりの机と椅子もしくは無印ダメソファで仕事をする場合の生産性は非常に高いものです 一方アジアのよくわからん所や不安定な衛星回線しかない飛行機や船の上で仕事をする場合生産性はそこまで高くありません そのようにまあムラは出るのですがそこまで含めて自分の生産能力だと会社に認めてもらえるかどうかという問題になってきます。 あとまあそういうふざけたことをしてるのを同僚に認めてもらえるかどうか。 環境にロックインされます 好き勝手どっかいきつつクリティカルな責任は会社に背負ってもらいつつ 500 万とか 600 万とか貰ってみたいなことが出来る環境
ssig33.com - Rails アプリでのビューキャッシュ戦略
キャッシュでレンダリングコストケチっていかないといけないようなことになってる時点でビジネスとして成立してないので撤退を検討したほうがいいと思う。 殆どスタティックな記事を配信して動的な部分は JS でやるとかあるけど、結局それってサーバー代を使わないかわりに膨大なエンジニアリングコストを使うことになる。意味ない。 予想外の形でサービスがヒットした結果酷い状態のコードをなんとか飛ばし続けないといけないこともあってその場合はとりあえずキャッシュを導入して時間かせぎをしつつビューをまともにしていくとかそんなことになると思う。けどその場合そこに「戦略」なんてものがあることはなくてひたすら泥縄的な対処が繰り広げられる。 何か問題がある時にとりあえずキャッシュで本質的な解決が得られるということはないので、データ構造を直していくとか、よい CPU を買うとかもっと本質的な解決法が重要。重ねて言いますがよ
ssig33.com - 戦争
みなさんが頑張って書いた JavaScript によってサイトが使いやすくなっていることは殆ど無い 殆ど無いというだけであるにはあるし、自分が JavaScript を書けないからといって書いている人をバカにするのはやめろ という感じの対立軸があります。殺し合いをしている人達がいます。黙ってコード書くか直ちに自殺しろと思う次第ですのでコードを書きます。 back to index of texts Site Search
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ssig33.com - アレです
ssig33.com - プロダクトに深い理解を示してくれる人を採用したい