AWS DevDay Tokyo 2018というイベントを開催します！ - Sweet Escape
タイトルの通りです。Amazon Web Services Japan主催で『AWS DevDay Tokyo 2018』というものが10月29日（月）〜11月2日（金）まで一週間に渡って開催されます。場所は目黒の駅前にあるAWSJオフィスが入っている目黒セントラルスクエアというビルです。 aws.amazon.com このイベントに自分は主に企画・コンテンツといった内容面で深く携わっているので今回はそのあたりを少しご紹介します。ちなみにどうでもいい情報ですが今回、僕は裏方に徹しているので自分のセッションはありません。 イベントの狙い 狙いというほどのものでもないですが、本イベントは毎年6月くらいに開催しているAWS Summit Tokyoという年次イベントの併催という形で昨年は開催されたものです。ちなみに開発者向けのイベント自体は2015年のAWS Summit Tokyoの新しい試み
デベロッパー志向なイベントにパワーアップ！ コンテンツオーナーが誘う「AWS Dev Day Tokyo 2017」の見どころ
AWS SummitとDev Day会場の位置関係 昨年までも「Developers Conference」を開催してきましたが、今年のAWS Dev Day Tokyo 2017（以下「Dev Day」）ではよりDeveloper志向を強め、実際に普段コードを書き、テストを書き、CI／CDを回しているような開発者の皆様がワクワクするような場を作ることを強く意識しています。また、当然DevとOpsは今や切っても切り離せないものであり、Infrastructure as Code、SREといったトピックのカッティングエッジな話も出てきますし、ディープラーニング、マイクロサービス、IoT、サーバレス、DDDの実践的な話まで、DevDevした内容で盛りだくさんです。 Dev Dayはぜひ開発者に来ていただきたい！ Dev Dayは、自身で手を動かし、コードを書いているエンジニアの皆様を対象として
Reproを使ってユーザテストしたら最高だった話 - Qiita
はじめに 自分で作ったサービスのユーザテストしてますか？ 私もユーザテストを数回実施しているのですが、ユーザテストする上で撮影機器の準備とか会議室の準備とか大変すぎて準備段階で疲れ果ててしまった経験があります そんな時良さげなサービスを教えてもらって実際に使った結果、かなり良さを感じたので紹介します ※モバイルアプリ向け 結論 : Repro超便利 アプリのスクリーンキャプチャ&フロントカメラ撮影の動画を作る機能を持っているので撮影機器いらず。 アプリ起動で録画開始->自動で動画を転送してくれてRepro上で見れるので動画データの共有はReproにinviteすればOK。SDカードから動画を取り出す必要ナシ。 つまり、スマートフォンと記録用ノートPCだけでユーザテスト出来る！！！１１！(出来ました) Reproの導入にあたって行った作業は↓だけ(iOS) Reproにユーザ登録 pod "
スタートアップならおさえておきたいAWS入門@TECH LAB PAAK 20160307
http://peatix.com/event/152608/ での登壇資料です。スタートアップでシステム作ろうとされている方はぜひ。
エンジニアのコスト意識が向上 ドワンゴがAWSを導入して変わったこと
AWSクラウドに関する導入事例などを学ぶカンファレンス「AWS Summit Tokyo 2015」に、ドワンゴのインフラエンジニアである関剛氏が登壇。LINEから引き継いだlivedoor Readerを、新たに「Live Dwango Reader」としてAWS環境で提供するまでを振り返りました。AWSをすることでどのようなメリット、デメリットがあったか、ドワンゴという組織がどのように変わっていったか、詳しく解説しました。 AWSを使うことでエンジニアの意識が変わってきた 関剛氏：皆さんこんにちは。ドワンゴから参りました関と申します。「ドワンゴがAWSを使ってみた」というタイトルで、40分ほど講演させていただきたいと思います。正直、ここの場に立つのはおこがましいといまでも思っておりまして、内容的にはテクニカルなことは、あまり正直ないです。 ただ、「ドワンゴがAWSを使って開発の部隊、あ
Pull Requestのレビューが辛くて会社をやめたい
私はプログラマに向いていないのかもしれない。 うちのチームではコミットをmasterブランチへマージする前に、Pull Requestを出してそれをリーダーや他の人がレビューすることになっている。（たぶんよくあるフロー？） そのPull Requestでもらうコメントを見ると死にたくなってくる。特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 レビューにおいてそういった強い言葉がときとして必要なことは理解している（そういえばこなものもあったなと思い出した http://cpplover.blogspot.jp/2013/07/linuxml.html ）。またそういったコメントを残す相手との仲が険悪なわけでもない。またよいと思ってくれたらしいところは褒めてくれたりLGTMしてくれたりもする。 だけどそれでも辛い。きつい言葉を向けられる
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 － Publickey
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 現在のシステム構築では、オープンソースのソフトウェアを使うことは当たり前になってきています。PostgreSQLはそうした中で主にエンタープライズ向けのデータベースとして着実に事例を増やしてきています。 その中で、PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」のセッション「NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？」で紹介しています。講演内容をダイジェストにしまし
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
DeNAのiOSエンジニア内で利用頻度の高いライブラリをランキング化してみました #iOS #DeNA｜CodeIQ MAGAZINE
DeNAで取り組んできた非ゲームの新規事業開発。その新規サービスの中で、iOS開発にフォーカスして、利用頻度の高かったライブラリやサービスをランキング形式でお届けします。 紹介してくれるのは、DeNAエンターテインメント事業本部でiOS/サーバ周りを担当している沖津貴智さんです！ by 馬場美由紀 （CodeIQ中の人） DeNAにおけるiOSアプリ開発 DeNA沖津です。DeNAでは、エンターテインメント事業本部という部署を新設し、非ゲームの新規事業開発に取り組んできました。 1年以上経過した現在、十数のサービスを開発し、リリース・運用を行ってきました。社内のGithub Enterprise上には、たくさんのプロジェクトのリポジトリが作成されており、エンジニア全員が自由に閲覧・プルリクエストを送れる環境にあります。 詳しくは、デブサミ2014「DeNAにおけるゲーム以外の新規事業の立ち
「Yahoo！グループ」終了 「システムの老朽化で継続困難」
ヤフーは、メーリングリスト（ML）や掲示板が利用できるコミュニティーサービス「Yahoo！グループ」を来年5月28日に終了すると発表した。 2004年2月に開始したサービスで、「システムの老朽化などにより、今後のサービス継続が困難と判断した」という。ユーザーには「多大なご迷惑をおかけいたしますことを深くおわび申し上げます」と謝罪している。 4月16日午後3時に、ページ上での閲覧を除くすべての機能を停止。過去のメッセージのダウンロード機能などを提供し、バックアップできるようにする。5月28日午後3時のサービス終了とともに、全コンテンツを消去する。 公開掲示板は、公開掲示板サービス「textream」への移行を案内。ML機能については、Yahoo！JAPAN内に移行できるサービスがないため、他社のMLに移行することを案内している。 関連記事 Yahoo！掲示板が全面刷新 「人格を持った匿名」で
テスト自動化の歴史と今後、良い／悪い事例～システムテスト自動化カンファレンス2013レポート
2013年12月1日、東京・外苑前のオラクル青山センターにて、テスト自動化研究会（STAR）が主催する「システムテスト自動化カンファレンス2013」が開催された。 STARによると、システムテストの自動化に特化したものとしては日本初の勉強会になるという。カンファンレンスでは多数の参加者が熱心に耳を傾けていた。その様子をレポートしよう。 テスト自動化を開発の“武器”にするための3つのポイント オープニングセッションにはSTARの近江久美子氏が登壇。「よりよいテスト自動化のためにちょっと考えてみませんか？」と題して講演を行った。 近江氏は最初に、テスト自動化のゴールについて「『効率化したい』『手動ではできないテストがしたい』など、目的は現場ごとに異なる」と述べ、「まずは何を目的にしているかを考え、それに合わせた実現手段を取るべきだ」とした。テスト自動化で可能となるものも多いが、そのために増える
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
Martin Fowler's Bliki in Japanese - ヘロヘロScrum
@@ -0,0 +1,79 @@ +http://martinfowler.com/bliki/FlaccidScrum.html + +2009/1/29 + +//There's a mess I've heard about with quite a few projects recently. It works out like this: + +多くのプロジェクトで混乱が起こっているようだ。 +次のようなことになっているらしい。 + +// * They want to use an agile process, and pick Scrum +// * They adopt the Scrum practices, and maybe even the principles +// * After a while progress is
開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage
なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」
プログラマではありませんが、プログラマの話をさせてください - mixi engineer blog
はじめまして。8キロのダイエットに成功しましたが、最近リバウンド気味の土戸と申します。 私は今、弊社イノベーション・センター案件である、Plannah(プランナー)のプロダクトマネージメントとマーケティングに携わっております。 先日我がチームの開発メンバーである衣川から、簡単にPlannahの紹介がありました。多くの方々に記事を読んで頂き、そしてPlannahに関心を持って頂き、大変感謝しております。本日は、Plannahの話は割愛させて頂き、ちょっとしたプログラマ話(?)をしたいと思います。 私はプログラミングを職業としているいわゆる"プログラマ"ではありません。ミクシィに新卒入社した2009年からしばらくは営業マンでしたし、その後も今に至るまでサービスディレクターとして勤めてきました。少しさかのぼって、小学校の頃は当時流行っていたGW-BASICでmud gameなどを作ってみたり、大
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【AWS Developers Meetup】RESTful APIをChaliceで紐解く
LOCAL学生部主催 学生オンラインイベント | LOCAL