デブサミ2014で「エンジニアだからできる自由な生き方」の話をしてきました。
昨年の後半から、「エンジニアとしての生き方」のような話をする事があり、ずっと継続して考えてきました。 先日も「一生、エンジニアであり続けるために必要なこと(レポート)」という講演をしたのですが、実はその時点でもまだ自分で分からない部分がありました。 自分が「自由に生きたい」と思っている事は分かっていたのですが、「なぜ自由でいたいのか」という説明がうまくできなかったのです。自由は手段であり、得た自由を使って何をしたいのか、それが説明できませんでした。 漠然とは感じるんだけど、説明できないもどかしさをずっと感じていたのですが、デブサミの数日前、こんなツイートを見つけてやっと自分で納得できました。 @ukedchat @gapingvoid There’s one more image to this that you’re missing… creativity. @ElsiumEd pic.
無料パフォーマンステスト | 負荷テスト
これまで、負荷テストの実行には専門知識と実行環境の準備に多くのコストが必要でした。社会からWebサービスの性能に関する不具合をゼロにするために、簡単、無料、圧倒的な負荷テストサービスを提供します。 ユーザビリティ サーバの応答速度は常に変化し、利用者の直帰率に大きく影響を与えます。サーバの応答速度を可視化し、日々計測することで、すみやかに問題個所を発見できます。 性能測定 サーバの性能不足により、せっかくの営業機会を失うサイトが多く存在します。サーバの性能を正しく把握することで、予測される負荷に応じたサーバの増強ができます。 負荷チェッカー／カレンダーを利用したテスト（ジョブ）の予約や、グラフィカルな結果画面を準備しており、初心者の方にも大変使いやすいサービス。インスタントテスト／URLを入力するだけで、すぐに負荷テストを行うことができます。シナリオテスト／ログインが必要なページや複数のペ
「取材記事は発表前に確認させてください」という広報担当者が「時代遅れ」では全くない理由(片岡英彦) - 個人 - Yahoo!ニュース
私は比較的、商品販促においては「攻めの広報」を行ってきた。一方で「広報」は「攻め」ばかりでは成り立たないことを良く知っている。 また、「広報」という仕事を愛するがゆえに、「広報」の仕事を表面的にしか理解していない人の発言を目にすると無性に悲しく、残念な思いになる。 特に下記のような意見が「残念」である。 特に大きな企業だと、インタビューをする際に「広報確認」が必須だったりするんですよね。「インタビューするのはいいですが、まずはできあがった原稿を見せてください。あと画像素材もすべて。広報に確認します」的な。これがライターとしては非常にだるい。先方に何の悪気はなくても、げんなりします。（略）どんだけ警戒しているんですか…と。冷静に考えると、それはインタビューを受ける社員に対しても失礼なわけです。要するに「こいつはまずいことを喋ってしまうかもしれないから、一応広報でも確認しておくか」ということで
Abbreviations and acronyms dictionary: Find definitions for over 4,219,000 abbreviations, acronyms, and initialisms
Find abbreviation word in meaning location Examples: NFL, NASA, PSP, HIPAA ,random Word(s) in meaning: chat "global warming" Postal codes: USA: 81657, Canada: T5A 0A7 Find out what any acronym, abbreviation, or initialism stands for With more than 1,000,000 human-edited definitions, Acronym Finder is the world's largest and most comprehensive dictionary of acronyms, abbreviations, and initialisms.
presto_executor_and_coordinator.md
presto_executor_and_coordinator.md Presto source code reading #1 This document is created for Presto Source Code Reading #1. http://atnd.org/events/47149 Target: trunk code, Feb 10th, 2014 Main Topic: Coordinator and Executor ./presto-main/src/main/java/com/facebook/presto/executions http://www.slideshare.net/frsyuki/hadoop-source-code-reading-15-in-japan-presto/10 NOTE All source code noted here
ベイジアンネットワークを使ったウェブ侵入検知
はじめに 私たちが提供しているSaaS型のWAFサービス、Scutum（スキュータム）では、より高精度な攻撃検知を実現するために、ベイジアンネットワークの技術を利用しています。今回は「ウェブセキュリティ」「不正検知」「異常検知」「攻撃検知」といった観点から、ベイジアンネットワークについて解説します。 ベイジアンネットワークとは？ ウィキペディアによると、ベイジアンネットワークは次のようなものです。 ベイジアンネットワーク（英: Bayesian network）は、因果関係を確率により記述するグラフィカルモデルの1つで、複雑な因果関係の推論を有向グラフ構造により表すとともに、個々の変数の関係を条件つき確率で表す確率推論のモデルである。 非常に的を射た説明ですが、「わかっている人にはわかるし、わかっていない人にはわからない」という感じもするかもしれません。基本からしっかり理解したいという場合
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
第1章 なぜ「継続的Webサービス改善」が必要なのか～変化に対応し、10年後も生き残るWebサービスのために | gihyo.jp
継続的Webサービス改善ガイド 第1章なぜ「継続的Webサービス改善」が必要なのか～変化に対応し、10年後も生き残るWebサービスのために 特集のはじめに 本特集は「継続的Webサービス改善」と題し、Webサービスの継続的な改善について、そもそもそれがなぜ必要なのか、どのような改善が必要なのか、それをどう実践していくのかという3点について、特集執筆陣が勤務するpaperboy&co.（以下、ペパボ）での実際の取り組みを題材に解説していきます。 Webサービスを改善するには、技術的な取り組みはもちろん、開発投資とそのリターンという経営的な観点、チームビルディングなどの開発プロセス、ビジネスメトリクスへの注視など、考慮するべきことがたくさんあります。多様な職種からなる執筆陣による本特集は、きっと読者のみなさんのお役に立てることと確信します。 10年という節目 ペパボは今年で設立10周年を迎えま
第2章 開発環境の改善～技術的負債の返済と、レガシーコードの仕様化テスト | gihyo.jp
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
第3章 パフォーマンスの改善～現状を可視化し、トップダウン／ボトムアップでアプローチする | gihyo.jp
パフォーマンス面での変化 Webサービスが成長するにつれ、パフォーマンス改善を行わなければならない局面が必ず立ち現れてきます。より複雑な要求に基づく機能の追加、アクセス数の増加、データ量の増大などによるものです。本章では、筆者の勤務先であるpaperboy&co.（以下、ペパボ）での取り組みを紹介します。 まずはじめにパフォーマンス改善とは何か、どのように改善するのかという基本的な考え方について説明し、次にその考え方に基づいて取り組んだ実践の詳細について述べます。 ブクログのパブー ブクログのパブー （以下、パブー）は、ペパボの子会社であるブクログが運営する電子書籍作成・販売プラットフォームです（図1）。このサイト1つで電子書籍の作成から販売、さらには外部の電子書籍ストアへの出版すらも可能な、まさに「プラットフォーム」と言うべきサービスを提供しています。 図1 ブクログのパブー 電子
第23回 Perlアプリケーションのテストと高速なCI環境構築術（2） | gihyo.jp
前回の（1）はこちらから。 PerlアプリケーションのCI 前回の（1）までで、Perlアプリケーションのテストとその実行に関して基本的な内容を紹介しました。アプリケーション開発にあたっては多くのテストが書かれると思いますが、都度すべてのテストを実行するのは手間がかかりますし忘れてしまうこともあるでしょう。同じことを繰り返すのであればCI環境を作り、テストを自動的／継続的に実行するのが確実です。 Ukigumo::Serverによるテスト実行結果の可視化 Ukigumoはtokuhiromさんが作ったCIを支援するWebアプリケーションです。Ukigumo::Serverはテスト実行結果をPOSTすることで、一覧化してWebブラウザから見ることができるアプリケーションです。 Ukigumo::Serverの導入はcpanmで簡単に行えます。導入と起動は次のように行います。
第23回 Perlアプリケーションのテストと高速なCI環境構築術（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回はmyfinderこと久森達郎さんで、テーマは「Perlアプリケーションのテストと高速なCI環境構築術」です。テストに利用するさまざまなモジュールから、CI（Continuous Integration、継続的インテグレーション）環境の構築、そして増えたテストを高速に実行する枠組みの構築までを紹介します。 なお本稿のサンプルコードは、本誌サポートサイトから入手できます。 テストの目的 まずはテストを行う目的を整理します。 コードを壊していないことを確認する 1人で開発するものであれば、どんな状況であれ責任を負うのは自分だけですが、チームや組織が複数にまたがる場合にはテストが重要になります。プロダクトが大きくなるにつれ、自分の開発によって想定外の機能にも影響を与えることが多くなります。逆にほかの開発者が行ったコミットによって
大規模障害から1年余り、あの企業が「その後」を語った
「この度は取材をお受けしましたが、どう対応したらよいか。今でも迷いがあります」。担当者は取材の冒頭で、心境をこう吐露した。 記者は取材のためレンタルサーバー事業を手掛けるファーストサーバ（本社：大阪市）を訪れた。1年半ほど前に、顧客企業が利用していたサーバー約5700台のデータをほぼ消失させる大規模障害を起こした事業者だ。 今回の取材は、過去に失敗を経験した複数の企業や公的団体に申し込んだ。目的は、「IT運用の失敗から技術者がどう学び、再発防止に取り組むべきか」をまとめる企画記事を執筆するためだ。 中でもファーストサーバは、運用のプロであるべきITベンダーが、一部とはいえ現場担当者のずさんな運用作業を見逃していた実態が明るみになり、個人としても大きな衝撃を受けた。失敗を経てどう体制を立て直したのか、大いに興味があった。 「非技術者」にも分かる再発防止策を：ファーストサーバ 簡単に、ファース
稼働率 => 月間ダウンタイム計算ツール
SLA (Service-level agreement、サービス水準合意、サービス保証制度）に記載されている稼働率から保証対象外の月間ダウンタイムを計算します。 稼働割合% 少数点桁まで表示 単位 SLAの例（調査日 2014/02/13) ※最新の数字、詳しい条件、言葉の定義などは各サービスのサイトで確認してください。減額もここでは返金と記載しています。 Amazon EC2 月間使用可能時間割合 99.0% 以上 99.95％ 未満 → 利用料金 10% 返金 月間使用可能時間割合 99.0％ 未満 → 利用料金 30% 返金 Amazon S3 月間使用可能時間割合 99.0% 以上 99.9％ 未満 → 利用料金 10% 返金 月間使用可能時間割合 99.0％ 未満 → 利用料金 25% 返金 Google App Engine 月間のサーバー稼働率 99.00% 以上 99.9
Carton考2014 | おそらくはそれさえも平凡な日々
こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 本番環境と同じアーキテクチャ 本番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
執筆とイベント主催(と業務と育児)を同時にやってみてわかったこと - PolyPeaceLight
今回、D3の本を執筆しつつ、CROSSというイベントを主催しつつ、通常の業務のリーダー(という平社員)をしつつ、2児の父として振る舞った末、完全にオーバーキャパで各所に迷惑をかけてしまいました。 書籍の進行が延び延びになって共著者・出版社に迷惑をお掛けしました CROSSの進捗管理とかチェックが甘々になって各担当者と登壇者と協賛各位にご迷惑をお掛けしました 足りない能力を時間で補ったしわ寄せが業務にいき、パフォーマンスが出なくご迷惑をお掛けしました 家族旅行中も執筆をしてるは、土日の夜は家にいないわ、平日は朝も夜もいないわで、妻と子どもたちに申し訳ありませんでした 謝って「これで終わりー」というのはただの批判防止の言葉でナンセンスなので原因と再発防止策を考えてみます。 問題と原因 オーバーキャパシティ ほぼすべての原因がこれになります。能力不足というと思考停止のようで良くないとは思いますが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.jippahitokarage.com/entry/2014/02/20/050020
【14-B-2】グリーを支えるデータ分析基盤の過去と現在（橋本泰一〔グリー〕）