Просто цікаві ресурси #1
#tools #curious
Сьогодні вже середа. Щоб зробити її трохи легшою та більш цікавою, ділюся деякими корисними ресурсами.
Для усіх, хто шукає безкоштовне: сайт, де можна пошукати OSS інструменти на будь-який смак
Для тих, хто полюбляє читати: короткі історії, згенеровані AI алгоритмами
Для junior інженерів (та й не тільки): величезна стаття про те, що таке API, як його тестувати та про деякі існуючі інструменти
А що цікавого Ви нещодавно знайшли або дізналися? Давайте ділитися в коментарях!
#tools #curious
Сьогодні вже середа. Щоб зробити її трохи легшою та більш цікавою, ділюся деякими корисними ресурсами.
Для усіх, хто шукає безкоштовне: сайт, де можна пошукати OSS інструменти на будь-який смак
Для тих, хто полюбляє читати: короткі історії, згенеровані AI алгоритмами
Для junior інженерів (та й не тільки): величезна стаття про те, що таке API, як його тестувати та про деякі існуючі інструменти
А що цікавого Ви нещодавно знайшли або дізналися? Давайте ділитися в коментарях!
freestuff.dev
Free tools and services for Developer
List of free stuff for developer by developer to use. This is a collective list of useful services for developer you can use for your next MVP or prototpying your idea.
👍16
EARLY COMPUTER ART IN THE 50’S & 60’S
#curious #engineering
Сьогодні пропоную трохи відпочити та подивитись на еволюцію комп'ютерного арту - починаючи з дев'ятнадцятого століття та дотепер.
А ще, можна заповнити зарплатну анкету від DOU. Це допоможе трохи краще зрозуміти, чи актуальна у вас ЗП чи ні.
#curious #engineering
Сьогодні пропоную трохи відпочити та подивитись на еволюцію комп'ютерного арту - починаючи з дев'ятнадцятого століття та дотепер.
А ще, можна заповнити зарплатну анкету від DOU. Це допоможе трохи краще зрозуміти, чи актуальна у вас ЗП чи ні.
Amy Goodchild
Early Computer Art in the 50’s & 60’s — Amy Goodchild
A deep dive on the early days of creative computing coming to life. Punch cards, plotters, light pens and lots more.
👍7❤1
Про ще один вид ручної праці та засоби його покращення
#ai #curious
Всім доброго ранку понеділка. За вікном в мене дощ, але це ніяк не привід зменшувати допитливість до світу технологій та тестування.
AI зараз усюди. Але щоб цей інтелект працював, йому треба навчатися на даних. В ідеалі - підготовлених.
Деякі компанії користуються послугами аутсорсерів щоб проаналізувати та розмітити дані вручну. Потім ці оброблені дані вже використовують для тренування AI моделей.
Але деякі аутсорсери пішли далі та застосували "автоматизацію" ...
#ai #curious
Всім доброго ранку понеділка. За вікном в мене дощ, але це ніяк не привід зменшувати допитливість до світу технологій та тестування.
AI зараз усюди. Але щоб цей інтелект працював, йому треба навчатися на даних. В ідеалі - підготовлених.
Деякі компанії користуються послугами аутсорсерів щоб проаналізувати та розмітити дані вручну. Потім ці оброблені дані вже використовують для тренування AI моделей.
Але деякі аутсорсери пішли далі та застосували "автоматизацію" ...
MIT Technology Review
The people paid to train AI are outsourcing their work… to AI
It’s a practice that could introduce further errors into already error-prone models.
❤11
Про причинно-наслідкові помилки
#testing #curious #fallacies #thinking
Причинно-наслідкові помилки (causal fallacy) виникають, коли хтось бере дві окремі незв'язані між собою події та визначає, що одна подія викликає іншу.
Наприклад, ви помітили, що ваші UI автотести дуже повільні. Ви почали думати, у чому ж можуть бути причини цього.
Після читання розумних людей в чатах та на форумах, місцеві "експерти" одразу допомогли визначити проблему: Ваші автотести повільні, бо ви користуєтесь повільним Python, замість інших, більш швидких мов програмування.
Ви приймаєте цей висновок та йдете переписувати усі двадцять тисяч тестів знову - втретє за останні роки.
Але щоб такої помилки уникнути - треба лишень глибше досліджувати проблеми та докопуватись до суті проблеми (а причини може бути в недостатньо оптимізованому коді із купою sleep() або копіпасти)
Дуже легко прийняти "очевидну" відповідь та побудувати хибні причинно-наслідкові зв'язки. Особливо, коли дві події дійсно можна пов'язати між собою. Якщо ви хочете побачити більше подібних помилок у кореляції двох подій - зацініть ресурс Spurious Correlations.
#testing #curious #fallacies #thinking
Причинно-наслідкові помилки (causal fallacy) виникають, коли хтось бере дві окремі незв'язані між собою події та визначає, що одна подія викликає іншу.
Наприклад, ви помітили, що ваші UI автотести дуже повільні. Ви почали думати, у чому ж можуть бути причини цього.
Після читання розумних людей в чатах та на форумах, місцеві "експерти" одразу допомогли визначити проблему: Ваші автотести повільні, бо ви користуєтесь повільним Python, замість інших, більш швидких мов програмування.
Ви приймаєте цей висновок та йдете переписувати усі двадцять тисяч тестів знову - втретє за останні роки.
Але щоб такої помилки уникнути - треба лишень глибше досліджувати проблеми та докопуватись до суті проблеми (а причини може бути в недостатньо оптимізованому коді із купою sleep() або копіпасти)
Дуже легко прийняти "очевидну" відповідь та побудувати хибні причинно-наслідкові зв'язки. Особливо, коли дві події дійсно можна пов'язати між собою. Якщо ви хочете побачити більше подібних помилок у кореляції двох подій - зацініть ресурс Spurious Correlations.
Tylervigen
Spurious Correlations
Correlation is not causation: thousands of charts of real data showing actual correlations between ridiculous variables.
👍18👏2
Security Certification Roadmap
#curious #security
В світі тестування люди постійно холіварять - чи потрібно отримувати якісь сертифікати (на кшталт ISTQB) чи можна обійтись без них? А який сертифікат найкращий? А що він дає? А чи обов'язково мати такий?
Для порівняння - подивіться на роадмап сертифікатів в світі security та оцініть масштаби та кількість.
Багато компаній вимагають наявність декількох сертифікатів одразу.
А ще - там для кожного курсу наведена вартість ... Та порівняйте з 100-200$ за тестувальницькі сертифікати.
#curious #security
В світі тестування люди постійно холіварять - чи потрібно отримувати якісь сертифікати (на кшталт ISTQB) чи можна обійтись без них? А який сертифікат найкращий? А що він дає? А чи обов'язково мати такий?
Для порівняння - подивіться на роадмап сертифікатів в світі security та оцініть масштаби та кількість.
Багато компаній вимагають наявність декількох сертифікатів одразу.
А ще - там для кожного курсу наведена вартість ... Та порівняйте з 100-200$ за тестувальницькі сертифікати.
Paul Jerimy Media
Security Certification Roadmap - Paul Jerimy Media
IT Security Certification Roadmap charting security implementation, architecture, management, analysis, offensive, and defensive operation certifications.
❤13
Про помилку незворотніх витрат a.k.a Sunk-Cost Fallacy
#testing #curious #fallacies #thinking
Помилки можуть виникати усюди. Найчастіше ми маємо справу з помилками в софті або якихось хардварних частинах. (Або у ваших автотестах ...)
Але чи існують помилки у тому, як ми мислимо? Виявляється, що так. Це помилки у логіці мислення. Ми робимо такі помилки навіть не помічаючи цього.
У цьому циклі дописів, я спробую коротко розповісти про такі помилки із прикладами з тестування та автоматизації. Декілька днів тому я вже розповідав про causal fallacy.
Що таке sunk-cost fallacy?
Сьогодні настав час для наступної помилки - sunk-cost fallacy або помилки незворотніх витрат.
Уявімо ситуацію. Хтось у минулому прийняв рішення. Через деякий час виявилося, що рішення було неправильним. Але оскільки на це рішення було витрачено вже багато часу, зусиль та грошей - людина (або команда чи компанія) продовжують працювати над цим хибним рішенням. Та ще й відмовляються його переглядати.
Приклади:
- менеджмент вважав, що автоматизація - то "легко" та купив усім ліцензії на відому та рекламовану low-code / no-code тулзу. Через деякий час виявилося, що тести дуже важко підтримувати та вони швидко ламаються після кожної зміни на фронтенді. Але гроші на річну ліцензію вже були витрачені, тому тестувальникам треба працювати з цими інструментами "через силу"
- те ж саме стосується будь-яких нових інструментів чи підходів (BDD, shift-left and right, etc) Особливо, коли інструменти "спускають зверху". Рішення вже "прийняті" або "нічого не знаю, клієнт так хоче!" або "це модний фреймворк, на ньому усі круті інженери пишуть - це майбутнє!"
Як запобігти цій помилці?
- Приймайте зважені рішення з порівнянням наявних альтернатив
- Розробляйте proof of concept будь-яких нових інструментів
- Думайте не тільки про плюси, а й про час на підтримку, переписування, інтеграцію нового у інфраструктуру
- Постійно оцінюйте прийняті рішення та не бійтеся відмовлятися від хибних та неефективних (навіть якщо сил та грошей було витрачено багато)
#testing #curious #fallacies #thinking
Помилки можуть виникати усюди. Найчастіше ми маємо справу з помилками в софті або якихось хардварних частинах. (Або у ваших автотестах ...)
Але чи існують помилки у тому, як ми мислимо? Виявляється, що так. Це помилки у логіці мислення. Ми робимо такі помилки навіть не помічаючи цього.
У цьому циклі дописів, я спробую коротко розповісти про такі помилки із прикладами з тестування та автоматизації. Декілька днів тому я вже розповідав про causal fallacy.
Що таке sunk-cost fallacy?
Сьогодні настав час для наступної помилки - sunk-cost fallacy або помилки незворотніх витрат.
Уявімо ситуацію. Хтось у минулому прийняв рішення. Через деякий час виявилося, що рішення було неправильним. Але оскільки на це рішення було витрачено вже багато часу, зусиль та грошей - людина (або команда чи компанія) продовжують працювати над цим хибним рішенням. Та ще й відмовляються його переглядати.
Приклади:
- менеджмент вважав, що автоматизація - то "легко" та купив усім ліцензії на відому та рекламовану low-code / no-code тулзу. Через деякий час виявилося, що тести дуже важко підтримувати та вони швидко ламаються після кожної зміни на фронтенді. Але гроші на річну ліцензію вже були витрачені, тому тестувальникам треба працювати з цими інструментами "через силу"
- те ж саме стосується будь-яких нових інструментів чи підходів (BDD, shift-left and right, etc) Особливо, коли інструменти "спускають зверху". Рішення вже "прийняті" або "нічого не знаю, клієнт так хоче!" або "це модний фреймворк, на ньому усі круті інженери пишуть - це майбутнє!"
Як запобігти цій помилці?
- Приймайте зважені рішення з порівнянням наявних альтернатив
- Розробляйте proof of concept будь-яких нових інструментів
- Думайте не тільки про плюси, а й про час на підтримку, переписування, інтеграцію нового у інфраструктуру
- Постійно оцінюйте прийняті рішення та не бійтеся відмовлятися від хибних та неефективних (навіть якщо сил та грошей було витрачено багато)
Telegram
Test Engineering Notes
Про причинно-наслідкові помилки
#testing #curious #fallacies #thinking
Причинно-наслідкові помилки (causal fallacy) виникають, коли хтось бере дві окремі незв'язані між собою події та визначає, що одна подія викликає іншу.
Наприклад, ви помітили, що ваші…
#testing #curious #fallacies #thinking
Причинно-наслідкові помилки (causal fallacy) виникають, коли хтось бере дві окремі незв'язані між собою події та визначає, що одна подія викликає іншу.
Наприклад, ви помітили, що ваші…
👍20
Помилка більшості a.k.a. Bandwagon Fallacy
#testing #curious #fallacies #thinking
Продовжуємо розбиратись з помилками в логіці та як вони можуть впливати на роботу інженера.
Що таке bandwagon fallacy?
Суть цієї помилки полягає в тому, що ми приймаємо рішення базуючись тільки на факті, що так робить більшість людей в індустрії. При цьому, ми не думаємо, а чи підходить це рішення для нашої конкретної ситуації.
Приклади
- AI та ChatGPT зараз на хайпі - саме тому треба його не просто вивчати, але й пхати усюди де тільки можна!
- Багато хто застосовує low-code або no-code інструменти - тому й вам потрібно почати!
- Усі пишуть автотести (шифтують вліво чи право, вивчають JS чи якийсь конкретний фреймворк) - тому й вам потрібно вивчати та застосовувати саме ці мови та підходи!
- Усі навкруги пишуть пишуть чек-лісти замість тест кейсів, тому й вам потрібно робити те саме!
- Усі міряють тестове покриття та ставлять не нижче 75-80-90% - тому й у вас на проєкті потрібно впроваджувати таке!
Як запобігти такій помилці?
- Вчити нове та розбиратися з хайповими технологіями завжди цікаво та корисно.
- Але до усілякого нового інструментарію потрібно ставитись скептично та перевіряти чи підходить воно саме вам та саме у цей момент часу. Кожен проєкт може відрізнятись та бути на різному етапі свого розвитку.
- Те що той чи інший підхід використовують “усі” - може означати, лишень, що про цей підхід зараз “модно писати та говорити”.
- Збирайте більше інформації, знайте слабкі та сильні сторони поточних інструментів та процесів та обережно пробуйте нове.
#testing #curious #fallacies #thinking
Продовжуємо розбиратись з помилками в логіці та як вони можуть впливати на роботу інженера.
Що таке bandwagon fallacy?
Суть цієї помилки полягає в тому, що ми приймаємо рішення базуючись тільки на факті, що так робить більшість людей в індустрії. При цьому, ми не думаємо, а чи підходить це рішення для нашої конкретної ситуації.
Приклади
- AI та ChatGPT зараз на хайпі - саме тому треба його не просто вивчати, але й пхати усюди де тільки можна!
- Багато хто застосовує low-code або no-code інструменти - тому й вам потрібно почати!
- Усі пишуть автотести (шифтують вліво чи право, вивчають JS чи якийсь конкретний фреймворк) - тому й вам потрібно вивчати та застосовувати саме ці мови та підходи!
- Усі навкруги пишуть пишуть чек-лісти замість тест кейсів, тому й вам потрібно робити те саме!
- Усі міряють тестове покриття та ставлять не нижче 75-80-90% - тому й у вас на проєкті потрібно впроваджувати таке!
Як запобігти такій помилці?
- Вчити нове та розбиратися з хайповими технологіями завжди цікаво та корисно.
- Але до усілякого нового інструментарію потрібно ставитись скептично та перевіряти чи підходить воно саме вам та саме у цей момент часу. Кожен проєкт може відрізнятись та бути на різному етапі свого розвитку.
- Те що той чи інший підхід використовують “усі” - може означати, лишень, що про цей підхід зараз “модно писати та говорити”.
- Збирайте більше інформації, знайте слабкі та сильні сторони поточних інструментів та процесів та обережно пробуйте нове.
👍28🔥6❤3🤡1