E2Eテストにおける要素選択のベストプラクティス ｜Autify（オーティファイ）ブログ
こんにちは。Autifyの品質エバンジェリストの末村です。 もう5年前にもなりますが、なぜE2Eテストでidを使うべきではないのかという記事を書きました。この記事はありがたいことに長い間閲覧されており、弊社ブログの人気コンテンツの一つとなっています。 一方で、5年という歳月はソフトウェア開発のトレンドを変化させるには十分すぎるほどに長いです。テストツールの面では Playwright が新たな選択肢として加わった他、 testing-library によるアクセシビリティ属性を用いた要素探索が新たなベストプラクティスとして登場しています。 この記事では、E2Eテストにおける要素探索の考え方の変遷をおさらいしつつ、ベストプラクティスについて説明します。 要素選択の考え方まずは、要素選択の考え方についておさらいしておきましょう。要素選択とは、読んで字の如く、Webページ内の特定の要素を探すこと
ブラウザの履歴を操作して「戻る」ボタンで広告を出すやつについて – コーヒーサーバは香炉である
2023年後半頃から、ブラウザの「戻る」ボタンを押すと、訪問したおぼえのないページが表示されることが増えた。そういうページは大抵、記事風の広告やサイト内の記事へのリンクが大量に並ぶという構成になっている。 こんなレイアウトになってることが多い。 この手法はブラウザバック広告とかブラウザバックレコメンド (あるいはレコメンデーション) とか呼ばれており、国内外の複数のWeb広告会社がこれを提供しているようだ。 たとえば、こちらはGMOアドマーケティングの “TAXEL” が提供しているブラウザバックレコメンド。 【新たな収益・回遊源が誕生！】ブラウザバックレコメンド サイトから離れてしまうユーザーに対し、広告やレコメンド記事を表示させることで、収益化や内部回遊に繋げることを目的としているフォーマットになります。 ……というのがセールスポイントらしいのだが、サイトから離れる人は、サイトから離れ
競プロ出身者・機械学習出身者の問題コード
https://anond.hatelabo.jp/20240625191650 競プロ出身者だけじゃなく、機械学習出身者も問題コードが多い 印象の問題ではなく実際に下記のようなコードが多い 念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある 正常系しか意識していない一番多いのはコレで異常系の動作を全く意識していない 入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない 「エラーが出たらとにかくtry-catchしてログ吐いて終わり」 ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる 「ここの処理でエラーログが出てるから対処よろしく」 「対処しました！（握りつぶし）」 とか滅茶苦茶多い セキュリティに関する意識が低い異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い API作らせて
良いコードってどんなコードですか？という質問を受けたら何と答えるか - snoozer05's blog
技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。 最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期（それぞれRubyの会社で働いている）と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。 この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。 とても大事な疑問を見つけられたんだなあと思います。 「良さとは何か」ということに向き合う必要の
「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論
しのゆー𝕏酒くずエンジニア @shinoyu 元HN風嬢の男性 / 新宿で社長やってるソフトウェアエンジニア18年生 / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ110 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムはブロック(プライベートリスト使え) / 原則IT関連業のみフォロー https://t.co/zGFlbhGSDi しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することは
DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab
Table users { id integer [pk] first_name varchar last_name varchar email varchar [not null] password varchar [note: 'Hashed password'] created_at datetime [not null, default: `now()`] updated_at datetime Indexes { email [unique, name: "ui_users_email"] } Note: 'table: users' } 上記のテーブル定義を dbdiagram.io の左側のコード記載部分に張り付けると右側にプレビューが表示されます。 以下は dbdiagram.io でのプレビューをした時の表示です。(Noteの箇所は説明のため加工しています) (1) Ta
JavaScript で then を使うのは避けよう（await / async の初級者まとめ）
JavaScript において、特に苦手とする人が多い印象のある Promise ですが、await と async の文法が導入されたことで、Promise の仕様を深く理解しなくても非同期処理を自然に書けるようになってきたのではないかと思います。 極論ですが、JavaScript の非同期処理は async await new Promise のみで、（ほぼ）全て表現可能です。特別な理由がない限り then を使わないようにしましょう、ということを周知するのがこの記事の目的です。 なお本記事では Promise の rejected の状態についてほとんど解説しておりません。基本を理解したら、別記事でぜひ学んでみてください。 Promise とは？ Promise は、少し乱暴に説明すると「実行が終わっていないかもしれない何らかの関数」を包んだオブジェクトです。 普通の関数とは違って、
やはり俺の情報教科書はまちがっている。 - Qiita
目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには 2025 年入試から大学入試共通テストでも出題されるようになり、教科「情報」の重要性が高まっています。 これで 2030年に79万人不足すると言われる IT 人材 の問題が解決！…と言いたいところですが、先日も『課題感ある教科1位「情報」』という調査結果が
「UIの正しい背景色の決め方」を考えてみた
中学生を名乗れるのも残りわずかということで、記念に（記念に？）なにか残しておこうと思います。 本当はフロントエンド関連で書こうと思っていたのですが、半年近くコードを書いていなかったのと（言い訳）、そもそも僕の技術関連の知識のほとんどは既に知られていることばかりだと思ってしまった（勉強してください..）わけですが、UIならなんとか語れる気がします。 この記事について 僕がUIを作る際の感覚的なマイルールを言語化してみました。 この記事の内容は僕の蓄えてきた感覚だとか直感を基にして書いているので、一般的な考えと合わないところがあるかもしれません。そういうときはぜひコメントで指摘してください。 色の決め方 さて、本題です。UIを構成する要素は、余白、大きさ、構成、... とまあ様々です。そして「色」はこれらの中でもトップレベルで重要な要素ではないでしょうか。例えば、背景色の小さな違いでも画面全体
【PHP】PHPの開発環境、XAMPPの使い方 - Qiita
はじめに こんにちは! 中学2年生のWardHamamatsu67です! 今回は、プログラミング言語のPHPの開発環境であるXAMPPの使い方について説明したいと思います。 What's XAMPP?? XAMPPとは、先程も説明した通り、PHPの開発環境です。主にPHPのプログラムを実行するときに使います。たとえPHPのコードがきちんと書けていたとしても、XAMPPが正常に動いてなければ実行ができません。そのため、PHPをやる上で、XAMPPは必須なのです!! 使い方 先程、PHPをやる上でXAMPPは必須と言いましたが、XAMPPでやることは1つだけです。それはXAMPPにあるモジュールを動かすことです。やり方は、XAMPPを開いて、Actionsの下に「start」ボタンがあるのでそれを押します。しばらく待つとモジュールの色が緑色になります。そうなったら終わりです。以上!! おわりに
「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か？｜moutend
結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。
UIの色を変えただけで大量のクレームを頂戴してしまった話｜のなと
Webプロダクト開発をしていると様々な諸事情によりUI構成を変えたり機能を増やしたり減らしたりすることが多々あると思います。そんな時に避けられない事態として「UI変更に対するお怒りがユーザーからわんさか届いてしまう」ということがあります。今回はUI上の１要素の色を変えただけで虎の尾を盛大に踏んでしまった事件の話をしようと思います。差し当たりどういうUIをどう変えたのかを明示しておきます。変える前がこちら↓↓ beforeUIほんで変わった後がこちら↓↓ afterUIご覧の通り「作業カード」と呼ばれるコンポーネントの色を「緑＆黄」から「緑塗り＆緑枠線」に変更しました。「え、それだけ？」という声が聞こえてきそうですがそうなんです。それだけなのです。しかしここはレガシードメインのtoB SaaS。toB SaaSではUIの変更がユーザー業務への影響に直結するので軽微な変更を加えるのもハードルが
How To Center a Div
IntroductionFor a long time, centering an element within its parent was a surprisingly tricky thing to do. As CSS has evolved, we've been granted more and more tools we can use to solve this problem. These days, we're spoiled for choice! I decided to create this tutorial to help you understand the trade-offs between different approaches, and to give you an arsenal of strategies you can use, to han
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
useContext + useReducer の使いどころ - パンダのプログラミングブログ
TR;DR useContext は、階層の深いコンポーネントに state を渡す場面で使うと良い useReducer は、state の変更パターンが多い場面で使うと良い useContext + useReducer は、state を使うコンポーネントの階層が深い上に、前回の state を元に新しい状態を作る場面で使うと良い useContextだけを使うケース useContext は React の組み込みの Hooks の1つです。Provider でラップしたコンポーネントのツリーのどこからでも、同一の Context Object を参照できるようにする Hook です。 useContext は Context を通じて子や孫以下のコンポーネントで同一の JS オブジェクトを呼び出せる Hook です。これにより props のバケツリレー （Props Drill
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニア基礎 ウィルゲート2024年度エンジニア新卒研修
privateメソッドのテストって書かない方がいいんだっけ？
JASRAC、文化庁“AIと著作権”素案に意見。「法改正を含む議論を強く望む」
