2016年11月26日(土)プロダクトオーナー祭り2016にて。 「なぜあなたのチームのプロダクトは太ってしまうのか 〜プロダクトマネジメントをかじったエンジニアが感じたLess is moreの極意〜」。
なぜあなたのチームの プロダクトは太ってしまうのか #postudy
2016年11月26日(土)プロダクトオーナー祭り2016にて。 「なぜあなたのチームのプロダクトは太ってしまうのか 〜プロダクトマネジメントをかじったエンジニアが感じたLess is moreの極意〜」。
バグをどのように見つけるか
秋のJavaScript祭 in mixi 〜秋のJavaScript収穫祭〜 2016-10-15 https://javascript-fes.doorkeeper.jp/events/52089
他人と自分を比べないこと - WETな備忘録
今にいたるまでずっと、他人と自分を比べて、そして自分が優れていたときの優越感と、自分が劣っていたときの劣等感を、そういう臆病な自尊心を、原動力に生きてきたように思う。 しかし今は、少しずつだが、他人と自分を比べない方法を見つけつつある気がする。 自分の原動力が自尊心であることに気づき始めたのは2年前の夏だったようだ。 まさにこの数日後、僕は当時所属していた会社から、今の会社に転職することになる。社員数は、1500人から、15人になり、エンジニアは5人に満たなかった。 win as a team, win as a result プログラミングに触れてからまだ3年経っていなかった僕は、スタートアップのエンジニアである彼らの高い技術力についていくのに必死だったし、居場所を自覚するために業務にいち早く貢献したかった。 そういうとき、自分の評価を気にするあまり能力を偽って（強がって？）大きく見せる
テスターの“フィーリング”を研ぎ澄ませ ─JaSST Tokyo 2015基調講演レポート | gihyo.jp
この記事は、日本中のテストエンジニアが集う冬のイベント、JaSST’15 Tokyo（ソフトウェアテストシンポジウム 2015 東京）のレポートです。マイケル・ボルトン氏の基調講演を中心に報告します。13回めとなるJaSST Tokyoは2月20、21日に東洋大学白山キャンパスで開催されました。 私はJaSSTには2004年から不定期にスピーカーとして参加していますが、今年は聴講者として参加しました。私が参加したJaSSTの中でも一、二を争う楽しいイベントとなりました。 満員となった基調講演会場 ASTERと学びの機会 JaSSTはASTER（ソフトウェアテスト技術振興協会）が主催しています。ASTERはテストに関わる人々の地位の向上、学習の機会の提供を目的にさまざまな活動をしています。ASTERの主な活動は、JSTQBの運営、各地方での教育の支援、シンポジウムの開催、テスト開発方法論な
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
土木の世界からインターネット業界に転身した女性として思うこと - Qiita
こんにちは、okaneyaです。 大学・大学院では土木工学を専攻し、この春卒業してインターネットサービスの会社に就職しました。この組み合わせは珍しいようなので、こちらの世界に来て戸惑ったことや考えたことについて書いてみようと思います。 「一旦リリースしてみよう」の文化に当惑した インターネット業界に来て一番当惑したのが、「完成形じゃなくても、一旦世に出してみる」ことができる点です。 橋やダムを「強度が不安だけどとりあえず作ってみようか〜」と言って作ることは絶対に許されません。人が死にます。然るべき手順を踏んで、多くの組織や人が関わって、綿密な計画の上にようやく着工のGOサインが出ます。 一方自分が今関わっているwebサービスは、最初から完璧に作り込まなくても仮説を検証するのに十分なだけのものがあればとりあえずリリースすることができます。まずは最小機能のサービスを作って、人に使ってもらって反
エターナらないゲーム開発
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
とちぎテストの会議03 - とちぎテストの会議
コンテンツ委員長係よりみなさまへ おひさしぶりです。2年ぶりのとてかのお誘いです。 思い返してみると…TDDの炎上を端に重い場と強いメッセージを発した2010年、ソフトウェアを開発するみなさんの日常を讃え合った2012年。回を重ねるごとに、とてかはみなさんを那須へお招きするサロンのような場になりつつあり、たいへん嬉しく思っています。 さて2014年は、みなさんの身近にある「いかす！」を交換します。クールだけど熱く、人間くさくてかっこいい。そんな「いかす！」に気づき活かす力 = いかしビリティ*1。みなさんと一緒にたくさんの「いかす！」に触れ、いかしビリティを高めましょう。 開催要項 日時 2014-10-04 13:00〜17:00 会場 宇都宮大学UUプラザ 主催 とちぎテストの会議実行委員会 プログラム 11:15 開場 11:30 "ソフトウェアテスト293の鉄則"読書会 & スポン
JavaScriptフロントエンド開発の昨今
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
シリコンバレーの英語: 英語でのバグレポートの書き方
3月 21, 2012タイムラインに流れてきたこのリンク先の記事を見て下記の内容を書き込んだところ、いくつか反応を頂きました。せっかくなので、英語でのバグレポートの書き方について簡単にまとめてみます。ポイントは「英語に頼らずに英語を書く」です。 英語でのバグレポートが難しいという人は、日本語でもレポートが書けてない可能性を考えるべき。フォーマットに従って「現状の動作」「期待される動作」を書いて、後は再現ステップと再現環境を書けば、英語が理由で伝わらないということはあまり無いと思う。バグレポートの文章の大半は固有名詞だし。 3月 21, 2012「問題となっている現状の動作」「期待される動作」「再現手順」を意識して書く 「バグレポートを読む」という意識でいる場合、読み手が期待するのはこの3点だと思います。逆に、この部分が書かれていれば、コミュニケーションを成立させることができます。 「現状の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
History of WaterFall
프로그래머로 부터 배우는 코딩 기술 (プログラマから学ぶコーディングテクニック)