Google Chromeのヘッドレスモードが新しく。別になっていた実装を統合し、ヘッドフルと完全互換に Google Chromeの開発チームは、Google Chromeをユーザーインターフェイス画面なしで利用できるヘッドレスモードの実装が新しくなったことを明らかにしました。 Chrome’s Headless mode just got a whole lot better! We made Headless more useful for developers by bringing it closer to Chrome’s regular “headful” mode. https://t.co/FhAblWvJQj pic.twitter.com/tJHV0j9fc7 — Chrome Developers (@ChromiumDev) February 22, 2023 ヘ
非エンジニアに無念コードがなぜダメなのかを説明するメタファー - Yamashiro0217の日記
非エンジニアに無念コードがなぜダメなのかを説明するメタファーを考えてみた。 目的は、無念コード・設計・環境・フローがあると、 いかに生産性が落ち、ビジネスがうまくいかないか、 プログラマーの心が病むかを、 なるべくエンジニアリングの用語を使わないで説明すること。 他にいいメタファーあったら、ブクマやらコメントやら、ブログ別書くなどして、 世界を幸せにしてもらいたい。 メタファー エンジニアリングとは部屋の掃除と一緒である ストーリー導入 あなたは、ある日、引越しを決意しシェアハウスに引越しました。 引越した先のシェアハウスのリビングは、 それはもう汚い。 散らかり放題、生ゴミ、壁の汚れ。 さぁ。どうしましょう。 さらに引っ越すという手段もありますが、 あなたは、リビングの掃除を試みるのでした。 ストーリー2 片付けをしていたある日、あなたは、 「リビングの中に、俺の鍵（機能や、コードなど）
サーバ管理ツールのエージェント みたいなソフトウェアをインストールしやすくするために、rpm / deb パッケージを作りたい。 しかし、rpm / deb パッケージ化するためには、それぞれ CentOS(RedHat)、Debian(Ubuntu) 環境でパッケージ化することになる。 社内ではこれまでパッケージ化の専用ホストがいて、そこで spec ファイルや init スクリプトを置いて rpmbuild コマンドとか debuild コマンドを叩いてパッケージを作成していた。 さらに、アプリケーションエンジニアからインフラエンジニアに依頼するという形をとっていた。 この方法の問題点として、以下の3つがある。 spec ファイルや init スクリプトなどをプロジェクトの Git リポジトリで管理しづらい。つまり、レビューとかがやりにくい。 リリースフローを自動化しづらい。具体的には
この記事はソフトウェアテストのカレンダー | Advent Calendar 2022 - Qiitaの23日目です。 毎年のことながら「何を書こう・・・」と悩んでいてTwitterに助けを求めたところ、@teyamaguさんからネタをいただきました（ありがとうございます） 案1：今年読んだ中で最も役に立ったor読んで良かった本 案2：今年で見た中で最もイケていた自動テストシステム とかどうでしょうか？ — teyamagu (@teyamagu) December 6, 2022 最も役に立った、だとなかなか決めかねる部分があり、「読んでよかった本」をつらつらと書いていこうかと思います。 私が2022年に読んだというだけで、今年発売された本には限らない点ご注意ください。また、熟読した本ばかりではなく、ポイント読みやざっと流し読みした本も含めます。（意志薄弱 The BDD Books -
皆さんこんにちは。fluctにてfluct SSPという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 依存パッケージの更新、どうしてますか？ 今や数多くの言語でパッケージマネージャが提供されており、みなさんも日常的にコミュニティによるパッケージエコシステムを活用していることと思います。 ですが、この依存パッケージの更新については、どのようにしていますか？ セキュリティfixなどを除き、以下のようなことになっていることが多いのではないでしょうか？ チームの「いい人」が頑張って更新し続ける その人の謎の情熱が消えると更新されなくなってしまう たまに気がついたら頑張る 「いい人」が頑張るタイプの亜種 気が付かなかったら更新されない 更新はリスクなので塩漬けにする プロダクトは定期的に作り直す前提 CIでテストを回し続けているのに更新しないなんて……とモヤ
概要 JavaScriptでDOMを作ってるサイトをPythonを使ってスクレイピングしたので、手順をメモ。 大雑把には、ScrapyとSeleniumを組み合わせてやった。 Scrapy Scrapyは、クローラーを実装するためのフレームワーク。 クローラーをSpiderのサブクラス、スクレイピングした情報をItemのサブクラス、スクレイピングした情報に対する処理をPipelineのサブクラス、という風にフレームワークが決めたインターフェースを満たすクラスとしてクローラーを実装する。 scrapyというコマンドが提供されてて、このコマンドを使って、作ったクローラーの一覧を見たり、クローラーを起動したりできる。 Seleniumは、ブラウザをプログラムから制御するためのツール（でいいのかな？）。Pythonも含めたいろんな言語で使える。 よくWebサイト/アプリの自動テスト文脈でよく出てく
変更容易性と理解容易性を支える自動テスト（2024/02版） / Automated Test Knowledge from Savanna 202402 YAPC::Hiroshima edition
YAPC::Hiroshima 2024
4月に発売された「WEB+DB PRESS Vol.134」で特集1「実践API設計」を執筆していますが、そこから部分的に紹介します（目次は、こちらです）。 第1章「優れたAPI仕様とは何か --- よくある問題と記述すべき事柄」の冒頭で次のように述べています。 今日、多くの企業がWeb サービスとしてさまざまなサービスを提供しています。Webサービスは、iOS、Android、ブラウザといったフロントエンドと、それらに対して機能を提供するバックエンドサービスから構成されます。バックエンドサービスが提供するさまざまな機能はAPI （Application Programming Interface）として定義され、フロントエンドから呼び出されます。フロントエンドは、バックエンドサービスが提供する機能を使ってユーザーへ提供する機能を実現します。 定義されたAPI を介することで、フロントエン
マイクロソフト、開発環境をクラウドPCとしてデスクトップ仮想化経由で利用できる「Dev Box」のパブリックプレビューを開始
マイクロソフト、開発環境をクラウドPCとしてデスクトップ仮想化経由で利用できる「Dev Box」のパブリックプレビューを開始 マイクロソフトは、開発環境をクラウドPCとして丸ごと仮想環境で用意し、デスクトップ仮想化経由で利用できる「Dev Box」のパブリックプレビュー開始を発表しました。 Dev Boxは今年の5月に行われた開発者向けイベント「Microsoft Build 2022」で発表され、プライベートプレビューとなっていました。 参考：［速報］マイクロソフト、開発環境をまるごとクラウドPCとして用意できる「Dev Box」を発表。Microsoft Build 2022 最近ではアプリケーションの開発環境は、コードエディタおよび文法チェックやフォーマッタなどの拡張機能、ソースコード管理ツールとの連携、ビルドツールや自動テスト環境などをはじめとするさまざまなツールによって構成されて
はじめに 本記事はMartin Fowler氏のBlog記事を日本語訳したものです。 なお、訳は2014/11/09時点のもので、オリジナル記事中のコラムは訳せていません。コラムの訳に関しては、暇や反応を見ながらぼちぼちやろうと思います。 訳に対する指摘・ご意見などありましたらtwitter(@kimito_k)でお願いします。 補足 Martin Fowler氏に連絡をとったところ、主著者はJames Lewisであるとのことでしたのでタイトルを変更しました。(2014/11/13) Microservices "マイクロサービスアーキテクチャ"という専門用語は、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせ(suite)として設計する特定の方法を指すものとして、ここ数年で急速に認知されています。このアーキテクチャスタイルに対する正確な定義はありませんが、ビジネス遂
マイクロサービス（microservices）という言葉をご存知でしょうか？ 今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。 マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
昨年までは毎月買った本やマンガとそれらに対する一言コメントをブログで書いていたんだけど今年はそれをやらずに来てしまったので今年かった本で良かったものをいくつかピックアップして紹介する。 実際にはもっと数多く買ってるし、買っただけで読んでいないものも多い。2023年に買った本はマンガも合わせて合計で366冊、そのうちマンガ以外は151冊だった。 なお、対象は自分で買った書籍だけ。つまり献本とかでいただいたものはこの対象に加えていません。 ちなみにいずれの本もすべて電子書籍で購入している。全体ではAmazonのKindleを中心に一部オライリーのeBookなんだけど、選んだものはすべてKindleで買ったものだった。 というわけで紹介していく。 AWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか フロントエンド開発のためのセキュリティ入門 知
現在、Shibuya.js が開催中です！Ustream で http://www.ustream.tv/channel/shibuyajs にて放送されています。これから、このブログの内容をしゃべります！ 今回「テスト」がテーマなうえ、Shibuya.js は「役に立つ話担当」「ネタ担当」に分かれていて、僕は「ネタ担当」なんですが（笑）、いつも通りネタです。でも、遠い未来の役立つネタです！ きっかけは、id:t-wada さんに、GUIの自動テスト関係の質問をしたら、凄くいいことを教えてもらいました。 全てのテストはサンプリングテストである （少し表現違ったらごめんなさい）話の流れで、部屋を移動しなくていけなくて、たしか、それしか話ができなかったのですが、要するに、サンプリングテストである以上、全ての入力パターンをテストすることは不可能であり、できることは、限られたコストの中で、効率よく
小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本
ITエンジニアの働き方を尊重し、技術的な成長を促進する開発組織に求められるものとは？ ──ユーザベースの取り組みに見る - はてなニュース
ITエンジニアが働く環境を選ぶ際に「技術的な成長が期待できるかどうか？」はとても重要な指標です。技術的な裁量が大きいことや学習機会が用意されていることだけでなく、チーム編成や評価といった仕組みの部分にまでエンジニアを尊重した文化が浸透していれば、その企業は極めて働きやすいと言えるでしょう。 エンジニアが尊重される文化を醸成する仕組み作りの事例として、ペアプログラミングによる知見の共有を推し進め、プロダクトに導入する技術選択にもかなりの自由を持たせているユーザベースに、エンジニアを支える開発組織と企業文化について聞きました。 今回は、スペシャリストとしてFellowの肩書きを持つ矢野勉さん（上記画像左下）と、入社2年目の廣岡佑哉さん（左上）にそれぞれの働き方を語ってもらい、CTOの林尚之さん（右上）には組織としての考え方をうかがいました（※取材はWeb会議ツールでリモート実施しました）。 ※
ＳＩ屋とかゲーム業界について考えてみた。 実はＳＩ産業のクラウド化と、ゲーム業界のソーシャルゲーム化は システムがネットの向こう側から提供されるという共通点以上に、共通点があると考えるからだ。 そしてその動きは、任天堂の「連結決算を開示して以来始めての赤字」や、 「DeNAによるベイスターズ買収」に見られるように、急激な業界構造の変容を生み出している。 キーワードは技術力ＶＳマネジメントだ。 まずはＳＩ業界の話から始めよう。 案件プライムを取ってこれるような大手システムインテグレータでの システムエンジニアの最終的なキャリアパスは、ＰＭである。 システムインテグレータは若手を、ＰＭにいたるまでのキャリアパスへと 導くための初歩的なプログラミング経験や、運用技術の実務経験を積ませていく。 その成長過程で重視され、身につけることを求められているのは、技術力よりもマネジメント能力と業務知識だ。
タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって
はじめに 面接時に役に立つ、Terraformにおける実践的な基礎知識やベストプラクティスを学べる問題集を作ってみました。 面接形式なので、サンプルコードの記述が少なく、わかりにくい部分もあるかと思いますが、Terraformの基本的な概念の整理にお役立ていただけます。ぜひ面接の準備や知識の確認にご活用ください。 注意事項 本問題集はTerraformのv1.5.xを基準に作成されています。 本問題集は、Terraformにおける実践的な基礎知識やベストプラクティスなどを学ぶための問題集であり、全ての問題が実際の企業採用面接時に出題されるとは限りません。また筆者の現在所属する組織の採用活動とは一切関係ありません。 本問題集では、Terraformの全ての基礎知識やベストプラクティスが網羅されているわけではありません。また特定のprovider（AWS等）に特化したものでもありません。特定の
プログラミング、三大胡散臭い開発手法
・自動テスト ・ペアプログラミング あとは何だろ アジャイルは胡散臭いんだけど、メリットデメリットが理解しやすい方だと思う 追記：語弊があるな、自動テストは重要だ。TDD、XP界隈と言ったほうがいいか 追記：胡散臭いのと、不要ってのはちょい違う。必要でも胡散臭さは放てる。過大評価が近い。あと、複数人でやる方法論で胡散臭さが出がち。
メールソフト「Thunderbird」では、ソフトウェアの品質向上のために開発チーム内で日常的に自動テストが実行されています。その理由や手法についてThunderbirdの開発チームが解説しています。 Automated Testing: How We Catch Thunderbird Bugs Before You Do https://blog.thunderbird.net/2024/04/automated-testing-how-we-catch-thunderbird-bugs-before-you-do/ ◆自動テストの目的とメリット Thunderbird開発プロジェクトではコードの変更によるバグの発生を最小限に抑えるために「自動テスト」が重視されています。開発チームによると、、Thunderbirdのコードや機能に変更が加えられるたびに、Windows、macOS、Li
「開発スピードをあげろ！」と言われる事は多々ある。 実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず！」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。 開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。 例えば、「仕様決め」の問題点は 仕様が決まらず、MTGの時間が長い 仕様を決める人がいない 誰かに確認する事が多い 開
matarillo.com: UIパターン
UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、
Goodpatch Advent Calendar 2016 13日目の記事です！ わたしはGoodpatchでProttというプロトタイピングツールのWebフロントエンドの開発を担当しています。 Prottでは、プロトタイプの再生に関する修正をしたあとは必ず全動作を網羅したテスト用プロジェクトでの動作確認を行っています。 ただ、すべての環境や条件を揃えた上でのテストにはなかなかの工数がかかってしまっていました。 この記事では、オールペア法という手法とPICTというCLIツールを使用してテスト工数を半分以下に削減した方法を紹介します。 単純に全組み合わせ 推奨環境としているOSやブラウザと3種類の再生モードを組み合わせると、テストすべき組み合わせは全部で20パターンになります。 （プレビューモードとプレゼンテーションモードは対PC、スタンドアロンモードは対モバイルのモードです。） - Ma
Engineering Manager Advent Calendar 2023 15日目の記事です。 KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。 体系的な話は HIGH OUTPUT MANAGEMENT や エンジニアリング組織論への招待、エンジニアリングマネージャーのしごと といった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。 KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP Engineering Managerをやめた - Konifar's WIP 先に書いておくと、綺麗にうまくいった / いっているという話は
Playwrightの公式ドキュメントに「Best Practices」というページがあったので翻訳してみました。 原文： Best Practices | Playwright 目次 目次イントロダクションテスト哲学ユーザから見えるふるまいをテストするテストはできるだけ分離するサードパーティの依存関係をテストしないデータベースを使ったテストベストプラクティスロケータを使うメソッドチェーンとフィルタリングの使用XPath や CSS セレクタよりもユーザー向けの属性値を優先するロケータの生成codegen を使ってロケータを生成するVS Code 拡張機能を使用してロケーターを生成するウェブファーストのアサーションを使う手動でアサーションを使わないデバッグの設定ローカル環境でデバッグするCIでのデバッグPlaywrightのツールを使うすべてのブラウザでテストPlaywrig
リファクタリングは、設計やコードを綺麗に保つという普遍的に求められる活動の一要素です。常識的な習慣として推進すべき活動です。 ただ、有効性の理解を得られないままリファクタリングを行って物議を醸す場面も存在します（例えばここのはてなブックマーク等で巻き起こった議論などです）。 実際、リファクタリングは、以降の保守作業をサポートしてこそ価値がでるものであり、考えなしにいつでも一律実施すればよいというものではありません。リファクタリングの対象やチームの状況によって、リファクタリングをすべきかどうか、線引きがされます。 このリファクタリングをすべきかどうかの基準ですが、一言でまとめると「妥当な保守性の実現を、妥当な費用対効果で実現できるか」になります。今回はこの基準を構成する「妥当な保守性の実現」と「妥当な費用対効果」について、それぞれ解説します。 リファクタリングで妥当な保守性を実現できるかの基
はじめに HTML5でのアプリケーション開発は、エンタープライズ向けアプリケーションでも当たり前のようになってきました。これはSalesforceにおけるアプリケーション開発でも同じです。 Salesforceでのアプリケーション開発はVisualforce/Apexで行うというのが数年ほど続いてきたので、HTML5つまりJavaScriptを主体とするアプリケーション開発にはなれていないベンダーも多数あるかと思います。自分は創業当時からJavaScriptでのSPA(Single Page Application)をメインプロダクトに据えた会社を運営しており、Salesforceのパートナーとしても長いことやっていますので、このあたりのノウハウは比較的多い方です。そのためこのエントリはそれなりに説得力を持ってお届けできるとは思います。 真っ先に行うべきこと もしあなたがSalesforc
ダウンロード このドキュメントはバージョン1.0 (hg)のためのものです。まだリリースされていません。 Mercurialリポジトリのコードを利用するか、Python Package Indexにあるリリースバージョンを探してください。 疑問? 意見? Googleグループへの参加: もしくは、FreeNodeの#python-docsチャンネルへどうぞ 何か気づいたことがあれば、issue trackerを使用して通知することもできます。 Sphinxは知的で美しいドキュメントを簡単に作れるようにするツールです。Georg Brandlによって開発され、BSDライセンスのもとで公開されています。 このツールはもともと、新しいPythonのドキュメントの変換のために作られました。そして、今までに数々のPythonや、他の言語で開発されているプロジェクトに対して、すばらしいドキュメンテーシ
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
「Xcode Cloud」、Appleが発表。クラウド上でXcodeを自動的にビルド、テスト、App Storeへデリバリ。GitHubなどと連携
Xcode Cloudは、Gitベースのソースコード管理ツール、ビルドツール、テストツールなどを統合したAppleが提供するCI/CDを実現するサービス。 GitHub、GitHub Enterprise、GitLab、Bitbucket Cloudなどと連携し、コードをクラウド上で自動的にビルドします。 自動テストの設定により、複数のプラットフォーム上でのテストを並行実行。
自己流JavaScriptを書いていた人がAngularJSのユニットテストで躓いた点 - 2015-07-10 - ククログ
結城です。 最近、AngularJSを使ったWebアプリ開発のプロジェクトに参加する事になり、とりあえず一通りの事は把握しておかなければと思って公式のチュートリアル（英語）を実践してみたのですが、JavaScriptの経験が浅い人だとハマらなさそうだけれども、中途半端に経験があったせいでドハマり、という場面に遭遇してしまいました。 恥ずかしい話ですが、せっかくなので同じように躓いている人（もしいれば）のために、分かった事や理解のポイントを書き記しておこうと思います。 この記事の対象読者は、以下のような状況にある人です。 フレームワークを使わないJavaScript（例えば、jQueryを使ったJavaScript程度）は書いた事がある。 自動テスト（特に、ユニットテスト）は書いた事がある。 AngularJSを始めたばかりである。 依存性注入という概念は理解できるが、実際にどう使うかはあま
マイクロサービスアーキテクチャにおけるサービス分割の難しさ - RAKUS Developers Blog | ラクス エンジニアブログ
大阪オフィスの移転を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。 今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果（の一部）についてご紹介します。 かみせんプロジェクトとは ミッション 目標 社内システムのマイクロサービス化 社内システムの概要 かみせんプロジェクト開始前 2018 年 9 月現在 マイクロサービスの結果整合性 課題感 検証内容 検証結果（得られた知見） サービスの分割は難しい 結果整合性の担保は難しい 最後に かみせんプロジェクトとは かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。 ミッション 『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』 目標 具体的には以下の実現のための技術検証や知見獲得を、社内システムの
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
iPhone／Android含むブラウザ自動テストの最終兵器Selenium WebDriverとは
Webアプリケーションのテスト自動化をサポートするツール「Selenium WebDriver」は2011年にリリースされました。 Selenium WebDriverは広範なWebブラウザのサポートを行っていた「Selenium1（Selenium RC）」と高速軽量で汎用的なWebブラウザエミュレータの機能を持つ「WebDriver」を統合したものです。 本稿では、Selenium WebDriverを簡単に試してみたい方や自動テストの実施を検討している方のために、前後編に分けて紹介します。Selenium WebDriverの特徴を整理するとともに、Selenium WebDriverを利用したWebアプリケーションに対する簡単な自動テストの実装、実施手法について解説します。 本稿で使用する用語の説明 Selenium WebDriver Selenium WebDriverはSel
マンガでわかる ソフトウェア開発 データ分析 データ分析事始め データ分析FAQ (参考)アジャイルメトリクスFAQ 1 独立行政法人情報処理推進機構 超合本版38編 データ分析事始め 目次 データ分析基礎編 01 データ分析ってなんなの？ データ分析 02 信頼幅の線、気になる 信頼幅 03 箱ひげ図のひげ、かわゆくない 箱ひげ図 04 散布図はぜんぜんばらばら 散布図と箱ひげ図 05 どれが本命なの？ 中央値と平均値 分析データ観察編 01 生産性は性癖が出る？ 生産性 02 バグを愛したソース 信頼性（不具合密度） 03 改修・保守が好き過ぎる 開発プロダクトの種別 04 規模はアンバランスでアンビバレント ソフトウェア規模 05 開発期間は短くて長くて短い 開発期間（工期） 06 ウォーターフォールってつおい？ ウォーターフォール型開発 07 ここはツールでしょ 開発ツール 08
Rustの実用性が理解できる図を作成してみた 〜C/C++/Java/JS/Python/Go/TS/Elixirとの比較〜
エディタ支援 言語の公式がエディタ支援(LSP等)を提供しているかを示しています。 自動テスト 言語の公式が自動テスト(ユニットテスト等)を備えているかを示しています。 リンタ 言語の公式がリンタを提供しているかを示しています。 ビルドシステム 言語の公式がビルドシステムを提供しているかを示しています。 パッケージマネージャ 言語の公式がパッケージマネージャを提供しているかを示しています。 フォーマッタ 言語の公式がフォーマッタを提供しているかを示しています。 手続き型 言語のプログラミングパラダイムが手続き型プログラミングを強くサポートしているかどうかを示しています。 オブジェクト指向 言語のプログラミングパラダイムがオブジェクト指向プログラミングを強くサポートしているかどうかを示しています。 関数型 言語のプログラミングパラダイムが関数型プログラミングを強くサポートしているかどうかを示
PHPUnit と Selenium2 を使ってブラウザベースの自動テストを実行するための最初の一歩的な何かを発表してきた - 雑文発散(2013-03-09)
▼ [PHP][Selenium] PHPUnit と Selenium2 を使ってブラウザベースの自動テストを実行するための最初の一歩的な何かを発表してきた 「（CakePHPとか）PHPのテストについての勉強会」で「PHPUnit + Selenium2 First Step Guide」と題した発表をしてきた。 「First Step Guide」としたのは、これを見ながら「Selenium 環境を整備して、簡単な PHPUnit コードを書く」ところまで実行できるようにしたかったため。 本当は発表よりもハンズオン的にやってみたかった話ではある。 発表資料 https://speakerdeck.com/suzuki/phpunit-plus-selenium2-first-step-guide サンプルコード https://github.com/suzuki/phpunit-se
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Chromeのヘッドレスモードが新しく。別になっていた実装を統合し、ヘッドフルと完全互換に
Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ
2022年に読んで「良い」と思ったソフトウェアテスト関連本 - テストウフ
毎週のように依存パッケージを上げ続ける努力 - CARTA TECH BLOG
PythonでJavaScriptを使ったWebサイトをスクレイピングする - Qiita
実践API設計: 柴田 芳樹 (Yoshiki Shibata)
James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題
マイクロサービス（microservices）とは何か – recompile.net
2023年に読んで良かった技術書など10冊 - Sweet Escape
JavaScriptでソフトウェアの正しさを数学的厳密に証明してみた - yukobaのブログ
Sprint Planning をやめた話 - スタディサプリ Product Team Blog
SIerが技術力を求めているという誤解 - SCHWARZGEIST
Terraform面接質問集を作ってみた - Qiita
オープンソースのメーラー「Thunderbird」の開発チームが「バグを減らす開発手法」を解説
開発スピードをあげるには - パルカワ2
PICTでテストケースの組み合わせ爆発にさよならを - エンジニアをリングする
マネジメントとしての意思決定振り返り - Konifar's WIP
Playwrightのベストプラクティスを翻訳してみた
リファクタリングすべきか・してよいかの判断基準 - 千里霧中
モダンJavaScriptアプリケーション開発 in Salesforce - Qiita
Overview — Sphinx v1.0 (hg) documentation
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」 | POSTD
IPAマンガでわかるソフトウェア開発データ分析38編.pdf