Nagoya.Testing in Tokyo ソフトウェアテストを強いられている人達の話 で発表したスライドです。ただ7割くらいは口頭での説明なので、参加した人の思い出し用です。
Nagoya.Testing in Tokyo ソフトウェアテストを強いられている人達の話 で発表したスライドです。ただ7割くらいは口頭での説明なので、参加した人の思い出し用です。
趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability(信頼性) Availability(可用性) Serviceability(保守性) Integrity(保全性) Security(機密性) 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
はじめに 私も今月で35才になりプログラマーとしての定年を迎えました。 そこで、これまでの経験でこんな兆候があるとシステム開発がトラブルになるかもというポイントをまとめたいと思います。 前提 なお、私が経験してきたことは以下のようにSIer的な案件が多いです。 立場は、プログラマ、リーダ、PM、コンサル、育成様々です。 また、今はSIerに所属してはいませんが、近しいところにはいます。 規模として10人程度をワンチームとして、場合によって複数チームで構成されるもの 企業向けシステム Java 中心 環境差異の軽視 概要 色々な理由で開発環境と本番環境が違うケースがある 例えば、開発と本番で次のようなものが異なる。 OSが Windows - Linux サーバが 一台 - 分散構成 DBが H2 - Oracle ネットワークが、HTTP - HTTPS Spring-bootを使っていて
今日は自分がエンジニアからプロダクトマネージャーと言う役割を担うことになったときの話をします。FiNC Developer Advent Calendar 2016 11日目の記事です。 最近日本のソフトウェア界隈でもよく聞くようになったPM=Product Managerという職種ですが、エンジニアから実際どうやってジョブチェンジしていくの?って話はあまり聞いたことがないので書いてみます。 「プロダクトマネージャー(PM)とは」を知る事前準備プロダクトマネージャーとしてやることやってみてわかったこと1.「プロダクトマネージャーとは」を知るまずは王道に、その職種の役割を理解しましょう。 最初に言っておくと、この定義は実際の現場によってある程度かわることが多いようです。ですがまずはメジャーなPMの役割を知っておきましょう。 結論自分の解釈では、プロダクトマネージャーは「ユーザーに製品の価値を
はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が
Bazelの特徴2:ビルドによってディレクトリを汚染しない Bazelでは、ソースコードやテストデータなどが格納されているディレクトリとは別のディレクトリでビルドやテストなどを行う仕組みになっている。makeコマンドでは意図的に設定や操作を行わない限りソースコードと生成物が同じディレクトリに混在する事態になることが多いが、Bazelではこういった問題が発生しない。 また、ビルドやテストはデフォルトではサンドボックス化された環境で行われるため、ビルドやテストがそれを実行しているシステムに影響を及ぼす可能性が最小限に抑えられている。 Bazelの特徴3:並列ビルド 大規模なソフトウェアではビルド対象が増えるため、ビルドにかかる時間も増える傾向がある。Bazelでは生成物どうしの依存性を自動的に把握し、可能な限り並列でビルドを実行する仕組みになっている。これにより、ビルド時間の短縮が期待できる。
トレタ アドベントカレンダー3日目担当の増井です。 最近、新しいサービスリリースに少し関わることがあり、そこに向けてオススメした開発で役に立つサービスをここでもまとめてみることにしました。 私が、実際にトレタやキタヨンを作るときに使ったサービスを中心に上げています。特に使った方がいいサービスには [必須]を書いてみました。 他にもオススメのサービスがあったら、コメントで教えていただけると嬉しいです! BrowserStack [必須] https://www.browserstack.com http://qiita.com/tags/BrowserStack 言うなら"Browser as a service"。色々なブラウザをリモートで操作してWebの動作確認をしたり、指定したURLのスクリーンショットを多種多様なブラウザで撮ってきてくれるサービス。 Chrome Extensionを
こんにちは! 株式会社LITALICO CTOの岸田崇志です。 記念すべき『LITALICO Engineers Advent Calendar 2016』1日目の記事となります! LITALICOでは現在『教育×テクノロジー』での可能性を広げるべく、チャレンジを広げています。 今回は、サービスを組み立てる話をしたいと思います。 1.はじめに タイプ別にみる失敗パターン 2.基本を理解しよう! AARRR - Pirate Metrics(海賊モデル) 3. サービスのコンセプトを設計しよう リーンキャンバスを知る リーンキャンバスについて リーンキャンバスの使い方 (おまけ)KPIを設定しよう まとめ 5.次回は… 1.はじめに サービスを立ち上げの現場では戸惑うことが多いと思います。 特に初めての場合ははなおさらです。 サービスの企画を初めてやるときに、 どうやっていいかわからない。
2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域(間接的にでも売上に寄与する) 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
今日の夜、トレタの増井さん(@masuidrive)さんと会って晩御飯を食べました。下らない話や日本企業の海外進出の話などをする中で、B2Bサービスがカスタマイズを受け入れるというのがどういうことなのか、という話が大変面白かったので、許可を得た上でブログ記事にさせてもらいました。 B2Bとは、Business to Businessの略語であり、企業が主に企業に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指す言葉です。対義語がB2C(Business to Consumer)で、企業が主に個人に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指します。B2Bビジネスの場合は契約1口あたりの金額が大きくなる傾向があり、逆にB2Cビジネスは1口あたりの金額はさほど大きくないのが普通です。 自分も昔の会社でB2Bを経験したことがあるのですが、B2Bをやる上で1つ大
はじめに Ruby on Railsを代表とするフルスタックフレームワークを利用すれば、 手軽にWebサービスの構築を始める事ができます。 しかし、3年あるいはそれ以上続くWebサービスを構築する際は、フルスタックフレームワークを採用するかどうかは慎重に検討する必要があるでしょう。 ケースバイケースではありますが、マイクロサービスの考え方をフレームワーク・ライブラリ構成に応用すると メリットがある可能性があります。 フルスタックフレームワークのデメリット フルスタックフレームワークは、学習コストが高いですが、Webサービス構築に必要なほとんどあらゆる機能を提供しています。 人気のフレームワークであれば、コミュニティも活発なので、わからないこともググれば解決することがほとんどでしょう。 では、フルスタックフレームワークのデメリットとはなんでしょうか? ロックインされる 一番大きなデメリットと
久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。 【Web系最高って言うけど本当なの?】SIから転職したエンジニア達に聞いてみた - paiza開発日誌 まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。 最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。 イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割 http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf 上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。 大体1
JSONTest.com is a testing platform for services utilizing JavaScript Object Notation (JSON). To use, make a request to servicename.jsontest.com, where servicename is the name of a service listed below. We also support a number of parameters, such as callback, allowing you to test Javascript and other web applications. For example, try this: http://ip.jsontest.com/?callback=showMyIP Services IP Add
昨日は、娘達とクッキーを作ってて、余った白身でラングドシャクッキーを作って美味しかった。ども。椎葉です。 F-team, L-team 牛尾さんの記事にF-team、L-teamってあるんだけど、これ、今僕のいるチームでやってることだー。って思った。Microsoftさんの最先端のチームと同じ思想に辿り着いてたってことで、なんか嬉しいなー。 simplearchitect.hatenablog.com Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。 だいたいは同じなんだけど、ちょっと違う部分があるのでそれをメモしておく。以前からの流れでOps TeamとDev Teamって呼んでるんだけど、今流行りのDevOpsとは関係ないので注意ね。 Ops Team
2016/9/27 スタートアップRails勉強会発表資料 About @takashi Increments アプリケーションエンジニア 主にQiita:Team担当 最近入社した 最近 Incrementsの開発チームが大事にしていること HRTを大切にしたコミュニケーション 作業は意識的に自動化する 属人性を極限まで排除する 重要な価値に集中する Qiitaにおけるリモートワーク開発プロセス HRTを大切にしたコミュニケーション Humility(謙遜), Respect(尊敬), Trust(信頼) リモートワークにおいてHRTとは? オンラインコミュニケーションは誤解を招きやすい (本当に)意図せず冷たく接しているように伝わる そこで なにげないレビューに を添えるだけで雰囲気が良くなる (けど普段喋れないこともあるので)月1回はオフラインで集まるようにしている 作業は意識的に自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く