Abstract 概要 あの計測野郎が帰ってきた！次はパフォーマンスを改善していくぞ！buildersconに身体をビルドする話をする人がいないならば私がするしかない！筋トレと科学的知見でよりよいエンジニアライフを約束します。 解説 このセッションでは筋肉を成長させるための最新の知見の紹介。正しい手法の実践などを登壇者の実践をもとに解説していきます。また正しさを手助けする筋トレログアプリを制作し、その過程も解説します。 正直なところ、私は人に自慢できるほどのトレーニーではないため、他に適任がいるんじゃないか。というのが正直なところです。しかし、中学高校とそこまで運動をしてこなかった人間でも、継続して筋トレすることで平均値を超える筋量を得られるということをお伝えできると思います。 なぜやるか 質の高い生活を送り、より良いコードを書いていくためには運動、筋トレが欠かせないことは皆さんご存知だと

発表してきました。 まずは素晴らしいカンファレンスに感謝しかありません。 運営スタッフの方々、素晴らしいスピーカーの方々、自分のお話を聞きに来てくださった方々。スライドのチェックをしてくれた@ayumu83s、@rmanzoku 断酒してる間、飲み会に付き合ってくれた方々もありがとうございました（ こういう公式な形でスピーカーをやるのが初めてだったので、いろいろと不備があったと思いますが、皆さんに大いに笑いを提供できたと思うのでまずは及第点かな。と思っています。で、真面目な技術的な話についてはBlogなどで継続的に、データ分析やガジェットのレビューについてはnoteの方にまとめようと思っていますので引き続きよろしくお願いいたします。 で、ここからは自分のスライド等について、いろいろと補足をしていきたいと思います。 食べる時間改善について。 スライドで補足するのを忘れてしまったのですが、女性

Abstract 概要 本セッションでは体の調子をIoT的アプローチ、測定を容易にするアプリの制作、また市販のトラッキング製品などを駆使し測定とログ管理を行い、どうやっていくことで体の調子を上げ、パフォーマンスを向上させ、より良いエンジニアライフを送れるか？を追求、解説します。 問題提起 各位エンジニアの皆様に於かれましては、サーバーやアプリケーションのパフォーマンス計測に余念がないと思われます。しかしながら、最も肝心なパフォーマンス計測が抜けてはいないでしょうか？そうなによりも、自分自身の体のパフォーマンスのことがおろそかになっているのではないですか？ 考察 そもそも人間の体は原始時代からデザインされていて、プログラムを書くようには作られていないのではないか？。ではどのようなアプローチで改善していけばパフォーマンスが最大化されるのか？自らの体と巷にある健康に関する書籍、論文。そしてエンジ

こんにちは。スタディプラスでインフラ周りを担当している id:rmanzoku です。 先日、国内での発売が開始されたAWS IoT Enterprise Buttonを使ってオフィスの小さな改善を行ったのでご紹介します。 弊社の課題 弊社のオフィスは、ビルの4Fと6Fに分かれており、6Fは会議室となっております。 6Fは「なんとなく自分が最後だ」、という人が施錠しSlackにて報告していました。 （採用面接がある日は遅くなりがち） この報告は忘れやすいですし、毎日行うことから非常に手間です。 今回、この報告をIoTボタンを使って簡略化することにしました。 AWS IoT Enterprise Buttonとは 先日、国内で発売されたIoTボタンです。 以前、Amazon Dashボタンを見て、ハックを試みたエンジニアの方は多いはずです。 このIoTボタンでは、なんと、リンクしたAWS L

この記事は, ｢OSS紹介 Advent Calendar 2017｣です. qiita.com 昨日の記事は, id:mackee_w さんの｢Rin - Redshift data Importer by SQS messaging - のご紹介｣でした. qiita.com ここまでのあらすじ id:mackee_w さんに, ｢何か書いてよ!｣と言われたので, 最近見つけて｢最高!｣と思った, 小粒だけどぴりりと辛いMackerelのプラグインをご紹介します. Mackerelのプラグイン Mackerelですが, 最近サードパーティプラグインのインストール機能が公式から提供されたりと, プラグイン周りがめちゃくちゃ熱いですね. mackerel.io ただ単にmackerel-agentをインストールするだけだと, 基本的なメトリックスしか取得できませんが, そこにプラグインを利

Vimをお使いの皆さん、こんにちわ。 Vimを使って日本語のコメントやドキュメントを書かなきゃいけな人をいつも悩ますのが、IMEのモードの問題です。 (IMEオン, IMEオフ) x (挿入モード, コマンドモード, ビジュアルモード) の、この全6パターンを意識しながら操作するのは非常に間違いやすいです。特に日本語を挿入モードで書いたあと、コマンドモードに抜けるとよくIMEがオンになっていて、あうぅ。。とよくなってしまう。 KaoriYaさんのMacVimやGVimを使っている方は幸せです。 set imdisable という設定をvimrcに書く手があります。これで挿入モードから抜ける際、入る際に必ずIMEがオフになります。 問題は、コンソールやiTermなどからSSHを介してサーバー上のVimを使っている場合です。この設定が効きません。そりゃ普通はサーバー上にIMEはありませんので仕

先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

ユニットテストや受け入れテストは普及してきましたが、セキュリティテストは忘れがちです。 Webセキュリティの脆弱性問題は未だに出ており、それを減らすために脆弱性に関しても常にテストを行い、バグ（脆弱性）に立ち向かおうというお話です。 個人のノウハウや人力に頼らず、ツールやサービスを使いこなして開発の不安を和らげ、ビジネスロジックの開発に注力できるようにしましょう。 時間があれば、筆者が立ち上げた継続的セキュリティテストサービスの話として、世界中にサービスを展開する意味、そのために機能を加えず何を捨てることにしたのかなど、ビジネスを含めたサービス開発の話もできたらと思います。 トーク内容 セキュリティテストとは Webアプリケーションセキュリティ セキュリティテストツール セキュリティテストサービス CIと連携した継続的セキュリティテスト セキュリティテストで一番重要なこと 継続的セキュリテ

新年度あけましておめでとうございます。 そしてエイプリルフールおめでとうございます。 タイトルの通りですが、今年1月からTogetterを運営しているトゥギャッター株式会社に入社しておりました。3ヶ月の試用期間が無事終了しクビにならずに済んだようなので安心して入社エントリを公開できたということです（ですよね…？）。 サービスの事を少しでもご存知の方ならビックリされるお話だと思いますので、とりあえず何かしらまとめておこうと入社エントリーという形を取ってみました。 ざっくりした振り返りと決意表明 「弱小SIerに新卒で入社」 → 「ソフトウェア製品を自社で開発・販売するベンチャー」 → 「ソシャゲー制作会社」 を経て、ひょんな経緯からまた新しい世界に飛び込むことになりました。 運営当初から親しんできたサービスに直接関わることができていることは勿論、エイプリルフールネタの仕込みのバタバタもひっく

5時間モノの alter table が Lost connection to MySQL server during query したんだけど show processlist するとまだ動いてるっぽいから放置しとけば完遂するのかなと思ってるんだけど大丈夫だろうか、、、 2015-03-30 16:47:05 via Twitter for iPhone とりあえず show processlist してまだ動いてるっぽかったら、datadir 配下で #sql-xxxx_xxxxx.ibd な名前のファイルが育っているかどうか確認する。 タイムスタンプが更新されていればテンポラリテーブルへのデータコピーが生きてるということになるので、あとは show processlist を監視して終わるのを待てば良い。 で、終わったっぽかったら show create table を確認して変更が

前回までのあらすじ なぜ俺はクリスマスに一人でディズニーに行くという選択をしてしまったのか(前編) - ダメ人間軟膏 前回から今回までのあらすじ 飲み過ぎたのかちょっと気持ち悪くて早めに目が覚めて、体調悪そうやしもっかい寝ようと思ったけどドラクエ10のver2.4アップデートもうメンテ終わってそうやからそのまま起きてやって、途中ちょっと仕事する振りもしながらドラクエやって気がついたら良い時間になってたから慌てて向かったのであった。 ミキキー！！！ 今回はディズニーシー。ディズニーシーは今まで行ったことなくて一回行ってみたいと思ってたから普通に楽しみやった。一人やけど。 今回もとりあえず結論書くと、シーは雰囲気が好きな感じで良かったけどただただひたすら寒かった。マジ寒い。屋内のアトラクション的なとこ入れば良かったかもしれんけど。昨日と同じようにひたすら3周ぐらい歩いて見て周った。 あと昨日の

あらすじ 会社のイベントで運良くディズニーのチケットを手に入れたダメ人間。しかしそこに記載されていた文字は「ペア」。生粋のソロプレイヤーである彼は困惑する。しかし「ペア」の文字はまやかしだった。「ペア」=「ソロ×2」だったのである。 イベントを進行してくれていた941さんが聞く、 941さん「ペアチケット、誰と行くんですか？」 それに対する答えは一つ ダメ人間「え、あっ、一人で二回行きます！」 ディズニーペアチケット(一人分二枚)頂きましたが一人で二回行きます。よろしくお願いいたします。— ダメ人間 (@dameninngenn) 2014, 7月 31 一人焼肉をものともしない男のつらいソロプレイが今始まる あらすじ2 酔っぱらってたので指が滑ってハードモードを選択してしまった。 クリスマス・イヴとクリスマスの2daysで行くってきいた RT @dameninngenn: ディズニーペア

先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を

今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、

エンジニア1000人が参加したYAPC::Asia 2013の企画の話と #yapcasia 運営事務局長を４回やった振り返り という1万2000文字の目次付きポエムを書いてから３ヶ月ほど経ってしまったけど、宣言していたとおり運営としてやったことの全てを忘れる前に残しておく。読んでほしいけど１エントリにまとめたかった＆ざっと羅列するのですごーーーく長いですよ。目次すら長い。 イベント運営をしてみたい人の参考になれば幸い。 YAPC::Asiaとは何か YAPC::Asia 2013 運営の流れ YAPC::Asia 2013 運営の指揮のとりかた やったことの実例 - 2012反省点まとめ＆次回やりたいことのメモ - YAPC::Asia2013 キックオフメモ - スポンサー向け提案資料の作成 - フライヤーの作成 - 企画時点から手伝ってもらうコアスタッフにお願いしたこととタスク管理の

年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも

毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ