並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 541件

新着順 人気順

自動テストの検索結果41 - 80 件 / 541件

  • 結合テストと呼ぶのをやめた話 - asterisc

    はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類(small / medium / large)に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを

      結合テストと呼ぶのをやめた話 - asterisc
    • リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ

      結城です。 2021年9月13日から14日にかけて、東京都立大学の大学院生向け特別講義として「リーダブルコード演習」を実施しました。 演習の内容は、当社でこれまでにも行ってきているリーダブルコードワークショップを、プログラミング経験が比較的浅い・プログラミングの量がまだそれほど多くない方向けに調整した内容としました。 この記事では、実施した演習の概要と、今回意識した点を紹介します。 本文が長いため、目次を用意してみました。 発端 演習の構成 座学パート リーダブルなコードを書く意義について リーダブルコードを実践するためにまず取り組むべきこと 実際の現場での「コードがリーダブルでなくなってしまった」「リーダブルになるよう改めた」実践例 最初の実装 リーダブルでなくなった実装 リーダブルさを取り戻すための改修 コードがリーダブルでなくなっていってしまう要因 壊すのが怖くて、見て見ぬフリ 恐怖

        リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ
      • 「技術的負債」への処方箋と「2つのDX」 - Qiita

        はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回:技術的負債はなぜ生じるか。 第2回:ソフトウエア開発を「制御」する意外な処方箋 第3回:技術的負債への取り組みはなぜ「2つのDX」につながるのか。 第1回:技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債(あるいはレガシーシステム)はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り

          「技術的負債」への処方箋と「2つのDX」 - Qiita
        • デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ

          クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか?今まではどのようにやっているのかを自分達でもうまく説明できなかっ

            デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
          • マイクロサービスはもう十分 | プロダクト・サービス | POSTD

            モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠

              マイクロサービスはもう十分 | プロダクト・サービス | POSTD
            • ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

              この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

                ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
              • 糞コードは直すな。 - Qiita

                とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである!!絶対に直すべき!! という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話 透明性高め料金値下げを」という記事もあるように世の中の携帯電話の料金プランはかなり複雑です。例えば、auだと「auでんき」といった電気料金とパックされた電話料金プランがあります。また、「auスマートバリュー」といったプランもあり、家のインターネット回線をa

                  糞コードは直すな。 - Qiita
                • 分散テスト実行システムRRRSpecをリリースしました - クックパッド開発者ブログ

                  技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの

                    分散テスト実行システムRRRSpecをリリースしました - クックパッド開発者ブログ
                  • 答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」(その1)。ソフトウェア品質シンポジウム2022

                    答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」(その1)。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略(2022秋版)が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ

                      答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」(その1)。ソフトウェア品質シンポジウム2022
                    • Selenium何とかっていうツールがやたら色々あるのはどういうわけなのか | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム

                      ブラウザの画面テストを自動化するツール、Selenium。 大変便利なツールなのですが、Selenium RC、Selenium IDE、WebDriverなど色々な名前が出てきて、「なぜこんなややこしいことになっているんだろうか」と思ったことはありませんか? その理由を知るには、Seleniumの歴史について知る必要があります。 今回は、Seleniumの誕生から2013年5月現在に至るまでの歴史を振り返りながら、それぞれのツールがどのような位置付けのものなのか、見ていくことにしましょう。 ※ 歴史はいいからとりあえずSeleniumを使ってみたい、という方は、Selenium公式サイトからSelenium IDEをダウンロードすれば使えます。 Selenium Core Seleniumの原型は、米ThoughtWorks社で働いていたJason Huggins氏によって2004年に作

                        Selenium何とかっていうツールがやたら色々あるのはどういうわけなのか | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム
                      • Rust の最初のステップ - Training

                        利用が広がり人気が高まっている新しいプログラミング言語の習得に関心がありますか? ここから始めましょう。 Rust で高速で効果的なプログラムを構築するために必要な知識の基盤を築きましょう。 このラーニング パスの内容は次のとおりです。 Rust コードの最初の行を記述するために必要なツールをインストールする。 Rust の基本的な概念を学ぶ。 エラーを処理する方法を学ぶ。 Rust でメモリを管理する。 ジェネリック型と特性を使用する。 パッケージとクレート用のモジュールを設定する。 自動テストを記述して実行する。 コマンドライン プログラムを作成する。

                        • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

                          このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

                            【翻訳】テスト駆動開発の定義 - t-wadaのブログ
                          • オブジェクト指向プログラミング -- 1兆ドル規模の大失敗

                            CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今

                              オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
                            • テストの学習へようこそ!  |  web.dev

                              テストの学習へようこそ! コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必

                                テストの学習へようこそ!  |  web.dev
                              • 「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ

                                こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。

                                  「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
                                • 自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ

                                  こんにちは、技術広報のyayawowoです。 「自動化(オートメーション/Automation)」 今、この言葉を聞いて胸がときめいた方に必見です! 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します! イベント詳細はこちらをご確認ください! ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を

                                    自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ
                                  • 有志と #ソフトウェアテスト読書マップ を作りました! - ソフトウェアの品質を学びまくる

                                    2022年9月9日にこんなツイートをしたところ、 ソフトウェアテストの書籍・資料について、こういうマップを作ってみたい。「QA関連」でできるといいんだけど、縦軸が定まらない。 一番繰り返し読んでいるドリル本をサンプルにしてみたけど、テスト分析自体がすでに初級じゃない気もするから、色付けも難しい。うーん。 誰か一緒にやりません?w pic.twitter.com/R0lVJhcpkD— Kazu SUZUKI (@kz_suzuki) 2022年9月9日 「一緒にやってもいいよ~」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました! みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。 ということで、以下に公開します! docs.google.com 「閲覧者(コメント可)」というアクセス権を設定しています

                                      有志と #ソフトウェアテスト読書マップ を作りました! - ソフトウェアの品質を学びまくる
                                    • チーム開発においてGit初心者が踏みがちな地雷まとめ|TechRacho by BPS株式会社

                                      morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと

                                        チーム開発においてGit初心者が踏みがちな地雷まとめ|TechRacho by BPS株式会社
                                      • 今さら聞けない Immutable Infrastructure - 昼メシ物語

                                        Immutable (不変な) Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S

                                          今さら聞けない Immutable Infrastructure - 昼メシ物語
                                        • 【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita

                                          これってなんなの? 【ど素人状態=社会人になって初めてプログラミングを勉強したぜ!(特に新卒)】〜【Webエンジニアの3年生ぐらい】になるまでに読むと良い本まとめです。「どんな目的で学ぶか?」*「いつぐらいまでに読むといいか?」を段階的にまとめました。「これだけ読めばいい!」と、そんな簡単な話ではありませんが、「今いるレベルより少し上の人がどんなジャンルのことを学んでんだろ?」という方の参考になれば嬉しいです。過去の自分に向けてでもあります、自戒。これからWebエンジニアになる人、なって間もない人の参考になれば幸いですm(__)m ※続編 【Webエンジニアど素人】が【3〜4年生】くらいになったら読むといい本を目的別にまとめた ”Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本”の段階的まとめ(一部外部記事あり) ど素人の方々が手を動かしながら1〜6ヶ月以内に学ぼう! ◆どの

                                            【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita
                                          • DX意味わからん。「IT革命」と何が違うの?という話|広木大地(日本CTO協会理事/レクター取締役)

                                            はじめにこの記事は、Engineering Manager Advent Calendar 2020の24日目の記事す。 職種を越えた働き方を模索するWeb Engineerのtrebyさんと、技術を突き詰めたいiOS Developerのbanjunさんの二人のパーソナリティをつとめるpodcast「きのこるエフエム」でお話してきた今話題のキーワードDXについてのお話を再編して記事にしたものです。 実際のpodcastについては以下からどうぞ。 いつの間にか"DX"がデジタルトランスフォーメーションにとられてた。trebyさん(以下敬称略) これは、我々のマイブームというか、最近、「DXっていいよね?」っていうふうに私が謎掛けをしますと、banjunさんが、「DX、わからん!」というふうに返すんです。 banjunさん(以下敬称略) 「DXって何ですか?何がいいんですか?」っていう話です

                                              DX意味わからん。「IT革命」と何が違うの?という話|広木大地(日本CTO協会理事/レクター取締役)
                                            • はてなチーフエンジニアが聞く、サイボウズLiveのアジャイルな開発現場 - はてなニュース

                                              「ビジネス上のコミュニケーションを、メールの不便さから解放したい」という思いから2009年にサイボウズがスタートした無料コラボレーションツール「サイボウズLive」。その開発現場は、Webアプリケーション開発の流行をうまく取り入れたアジャイルなものでした。その様子を、はてなチーフエンジニアの大西康裕がインタビューしました。テーマは、プログラミング言語の選び方から、自動ビルドと自動テスト、リファクタリング、チーム内コミュニケーションなど。大西自身も「面白かった」と語る取材の様子をぜひお楽しみください。記事の最後ではプレゼントもご案内しています。ところでこの取材には、サイボウズ・ラボの竹迫良範氏が、なぜか大量のレッドブルを抱えて登場したのですが……。 http://live.cybozu.co.jp/ (※この記事はサイボウズ株式会社提供によるPR記事です。) 大西 はてなチーフエンジニアの大

                                                はてなチーフエンジニアが聞く、サイボウズLiveのアジャイルな開発現場 - はてなニュース
                                              • ソフトウェア設計についての原則や法則についてまとめてみた

                                                ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI(You ain't gonna need it.) YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の

                                                  ソフトウェア設計についての原則や法則についてまとめてみた
                                                • Python + Selenium で Chrome の自動操作を一通り(ログイン、ダウンロード、他)

                                                  はじめに Python + Selenium + Chrome で、要素の取得、クリックなどの UI系の操作、待機、ページ全体のスクリーンショットなど、一通り試してみます。 PhantomJS はもう更新されないということなので、ブラウザは Chrome にします。 この記事には、Selenium の API に関する情報と Chrome に特化した情報がありますが、前者の Selenium の使い方に関する情報は Firefox など別のブラウザでも使えます。 注意事項 ウェブの自動テストやスクレイピングで使われる技術です。特にスクレイピングでは、著作権の問題や、サーバー側の負荷、各種規約(会員としてログインする場合の会員規約等)やマナーなどを考慮する必要があります。 たとえば、Twitter など利用規約で明示的にスクレイピングが禁止されていることや、robot.txt などでクローリ

                                                    Python + Selenium で Chrome の自動操作を一通り(ログイン、ダウンロード、他)
                                                  • 自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み

                                                    長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています(経歴)。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に

                                                      自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
                                                    • 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り - ヴェルク - IT起業の記録

                                                      2022年4月11日にboardの有料登録社数が4000社を突破したので振り返りです。 boardの正式リリースは2014年8月20日なので、約7年半ほどで、推移はこんな感じでした。 1000社刻みで定点観測的に書いているので、過去の記事も貼っておきます。 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス(BPStudy発表時の補足) 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入3000社に行くまでの振り返り boardとは 見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の小規模な会社をメインターゲットとしています。 8年目にして初めてサービス紹介動画を作ったので貼っておきます。

                                                        受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り - ヴェルク - IT起業の記録
                                                      • 良質な情報が得れる!なかのひとが書くネット系企業公式テックブログまとめ45選 | nanapi [ナナピ]

                                                        はじめに インターネット業界で働く方や企業のWeb担当の方にとって、情報収集というのは日々の仕事の結果に繋がる貴重な活動のひとつですね。RSSリーダーやニュースアプリなど手段はさまざまですが、日々最新の情報に高いアンテナを貼っている方も多いかと思います。 その情報収集元のひとつとして、ネット企業のなかのひとが情報発信をしてくれている公式ブログなどなどは非常に参考になることが多かったりします。 ここでは、そんなインターネット業界で働く方や企業のWeb担当の方に参考になると思われるネット企業の公式テックブログをまとめてみました。ぜひご参考ください。 ネット系企業公式テックブログまとめ 「クックパッド開発者ブログ」(クックパッド株式会社) クックパッド開発者ブログ クックパッドのエンジニアがサイトの開発と運営について書き綴ります techlife.cookpad.com 「サイバーエージェント

                                                        • 【GWにおすすめ】サーバーレス開発部でおすすめされた技術書を17冊紹介します | DevelopersIO

                                                          今月入社したサーバーレス開発部の佐藤です。ジョインブログから初めての投稿です。 札幌オフィス勤務予定なのですが、札幌にサーバーレス開発部のメンバーがいないため、1ヶ月間、会社の文化になれるために東京の岩本町オフィスに出社しています。前職からの働きかたのギャップが激しいですが、毎日楽しく仕事をしています。 先日、サーバーレス開発部のSlackチャンネルで、おすすめの技術書を紹介してくれという雑なポストをしたところ、すごい勢いで技術書が流れてきたので、保存する意味も込めてブログにまとめてみました。 おすすめ理由については、サーバーレス開発部の方々に直接聞いたものを載せています。 おすすめされた技術書 Webを支える技術 Webを支える技術 おすすめ理由 当たり前に使っているWebやREST、HTMLなどベースとなる技術の歴史からふりかえっており単純に読み物として面白いです 普及している技術の思

                                                            【GWにおすすめ】サーバーレス開発部でおすすめされた技術書を17冊紹介します | DevelopersIO
                                                          • エンジニアの技術土台となる知識を得るための本の紹介 - Qiita

                                                            はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え

                                                              エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
                                                            • 【ハウツー】これはすごい! Web案件必須 Selenium - 人気急上昇中自動テストツール (1) 最近人気のSelenium | エンタープライズ | マイコミジャーナル

                                                              Webアプリケーションのテストツールに「Selenium」がある。SeleniumはJavaScriptとHTMLを使って、Webブラウザに自動でテストをさせようというもので、アジャイル開発におけるテストツールとして注目されている。 Seleniumとは SeleniumはWebアプリケーション用テストツール。JavaScript/DHTML/iframesをベースに構築されたテストツールで、Webブラウザから直接実行できるという特徴がある。要するに、目の前でWebブラウザが勝手にテスト工程を実施するわけである。見ていてなかなか気持ちがいい。対応しているプラットフォームやWebブラウザは多岐にわたる。代表的なプラットフォームは次のとおり。 Windows Internet Explorer 6.0 Mozilla Suite 1.6以上 Firefox 0.8?1.5 Seamonkey

                                                              • 新 GitHub Actions 入門 - 生産性向上ブログ

                                                                github.blog GitHub Actions の新バージョンが 8/8 に発表されました。 www.kaizenprogrammer.com 自分は過去にも旧バージョン時に GitHub Actions の入門記事を書いていたのですが、新バージョンがこれまでと大きく変わってしまっているので、この記事ではあらためて GitHub Actions についていろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは これまでの GitHub Actions とどこが変わったか コンセプト マルチプラットフォーム対応 HCL から YAML へ 料金 その他 GitHub Actions と Azure Pipelines 簡単な例 (Hello, World) ワークフローの設定 ワークフローとは ワークフローを実行するイベント ワークフロー

                                                                  新 GitHub Actions 入門 - 生産性向上ブログ
                                                                • 「それ、アジャイルできてへんのちゃいますか?」チェックリストの公開 - メソッド屋のブログ

                                                                  DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます!」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない

                                                                    「それ、アジャイルできてへんのちゃいますか?」チェックリストの公開 - メソッド屋のブログ
                                                                  • 大規模クラウドインフラ設計・構築案件の歩き方(AWS-28)がインフラエンジニアに刺さりまくりな内容だった | iret.media

                                                                    AWS Summit Japan 2024 Day1の「大規模クラウドインフラ設計・構築案件の歩き方」のセッションについてレポートです。 控えめに言っても満足度の高いセッションでした。 大規模なクラウドインフラの設計構築運用に関わる方なら首がもげるくらい頷きが多い内容であり、アーカイブが公開された際はもう一度見たいと思うほど…。 セッションの内容には「設計書の一覧サンプル」や、「アプリ/インフラチームの責任分界」といった界隈でも関心が高い内容に触れられています。 考え方のひとつとして参考にしていきたい内容がモリモリでしたので、シェアさせていただきます。 セッション概要 大規模クラウドインフラ設計・構築案件の歩き方 Level 300: 中級者向け スピーカー: アマゾン ウェブ サービス ジャパン合同会社 仲谷 岳志 様 クラウド技術のコモディティ化により、エンタープライズ分野では近年、A

                                                                      大規模クラウドインフラ設計・構築案件の歩き方(AWS-28)がインフラエンジニアに刺さりまくりな内容だった | iret.media
                                                                    • 達人出版会:技術系電子出版・電子書籍

                                                                      探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 Blenderでアニメ絵キャラクターを作ろう!トゥーンレンダリングの巻 夏森轄 サイバーセキュリティの教科書 Thomas Kranz(著), Smoky(訳), IPUSIRON(監訳) ゲーム作りで楽しく学ぶ オブジェクト指向のきほん 森 巧尚 ブランドスイッチの法則 田中 宏樹 Blenderでアニメ絵キャラクターを作ろう!モデリングの巻 夏森轄 R/RStudioでやさしく学ぶプログラミングとデータ分析 掌田津耶

                                                                        達人出版会:技術系電子出版・電子書籍
                                                                      • 超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                                        「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました(これまでの記事一覧)。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか? 1週間? 1ヶ月? 1年? 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに

                                                                          超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
                                                                        • 「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について

                                                                          (2022年9月26日追記) 本件に関する、セルフチェックページとお問合せ窓口の提供を終了いたしました。 この度は、お客さまをはじめ多くの関係者の皆様に多大なるご迷惑とご心配をおかけしましたことを、深くお詫び申し上げます。 株式会社メルカリは、当社が利用している外部のコードカバレッジツール※「Codecov」に対する第三者からの不正アクセスにより、当社のソースコードの一部および一部顧客情報(フリマアプリ「メルカリ」で2013年8月5日〜2014年1月20日に実行された売上金の顧客口座への振込みに関連した情報17,085件、2015年11月〜2018年1月の間におけるカスタマーサービス対応に関連した情報217件、2013年5月に実施したイベントに関連した情報6件、「メルカリ」および「メルペイ」の一部取引先等に関する情報7,966件、当社子会社を含む一部従業員に関する情報2,615件)が外部流

                                                                            「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について
                                                                          • 2014年に読んだ技術書で良かったもの - うさぎ組

                                                                            概要 新刊にかぎらず、今年読んでいて「あー、良書だなー」って思ったものをあげています。これ、ダメじゃないの?とか、あー、やっぱりこれいいよねっていうコメントもらえると嬉しいです。 基本は、.NETにおけるWeb APIやFW開発でQA * POな人が思う良書です。今年は技術書より論文、言語仕様書、実装を読んでいることが多かったので、去年の半分の30冊くらいしか読んでいないかな。 開発チーム系 エッセンシャル スクラム 作者: Kenneth S. Rubin出版社/メーカー: 翔泳社発売日: 2014/08/01メディア: Kindle版この商品を含むブログを見る スクラムなんとなくわかっているんですけど、自分以外の状況よくわからんしなー、進め方変じゃないかなぁっていうときに、読むとめっちゃ参考になります。 組織パターン 作者: James O. Coplien,Neil B. Harri

                                                                              2014年に読んだ技術書で良かったもの - うさぎ組
                                                                            • テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING

                                                                              テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET(Software Engineer in Test)です。「SETタスクフォース」(以下「SETチーム」と表記)のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET(Software Engineer in Test)の伊藤 宏幸(Hiroyuki Ito)です。 2018年6月27日(水)に、電気通信大学の西 康晴さん(以下「にしさん」と表記)をお招きして、「

                                                                                テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING
                                                                              • 「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba

                                                                                4/26 に発売されます! 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます!チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー!」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を

                                                                                  「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba
                                                                                • 「仕事のコード」を残す際のチェックリスト|Uchio Kondo

                                                                                  最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記@2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に

                                                                                    「仕事のコード」を残す際のチェックリスト|Uchio Kondo