Telegram statistics channel - @codica

Чому саме Cypress?Є безліч фреймворків для тестів у JS (Jest, Mocha, Playwright), але для end-to-end тестів сьогодні найбільше використовують Cypress. Це інструмент, який дозволяє симулювати поведінку реального користувача у браузері.Що робить Cypress зручним?🖥️ Тести у браузеріВи бачите на власні очі, як відкривається сторінка, заповнюється форма й клікаються кнопки. Це схоже на «живу» перевірку.🎛️ Візуальний інтерфейсНе просто консоль, а цілий UI: можна поставити паузу, прогорнути виконання крок за кроком і подивитись, де саме тест впав.📸 Скріншоти та відеоЯкщо тест ламається на CI, Cypress робить знімок екрану або відеозапис. Зручно для відлагодження.⚡ ГнучкістьОднаково добре працює з React, Vue, Angular та навіть з бекендом, якщо треба тестувати API.⏳ Автоматичне очікуванняНе потрібно писати sleep() – Cypress сам чекає, поки елемент з’явиться у DOM.Мінімальний приклад// cypress/e2e/login.cy.jsdescribe('Login flow', () => { it('користувач може увійти', () => { cy.visit('/login') cy.get('input[name=email]').type('[email protected]') cy.get('input[name=password]').type('Password1!') cy.contains('Sign in').click() cy.contains('Welcome').should('be.visible') })}) 🔍 У цьому прикладі Cypress «грає роль» користувача:- відкриває сторінку /login - вводить email і пароль,- клікає кнопку «Sign in»,- перевіряє, що на екрані з’явився текст «Welcome».✅ Можна сказати, що Cypress – це ваш інтерактивний робот-тестувальник, який клікає замість вас, і робить це без втоми та помилок.💬 А ви вже пробували Cypress у своїх проєктах, чи поки що користуєтесь тільки unit-тестами на Jest/Mocha?✨ Гарних вихідних, відпочиньте та набирайтеся сил!#codica_adviceTikTok | Instagram | Telegram

⚙️ CI на GitHub ActionsУ .github/workflows/ci.yml: ✅ Ruby + гем-кеш- uses: ruby/setup-ruby@v1я 👉 швидший білд.✅ Node.js (якщо є JS/yarn/webpacker)- uses: actions/setup-node@v3 ✅ Postgres як serviceБаза для тестів прямо в CI, без зовнішнього конекту.✅ Rubocop- run: bundle exec rubocop ✅ Тести (RSpec/Minitest)- run: bundle exec rspec ✅ Статус на PRGitHub → Settings → Branch protection → main → required 🚀 CD (деплой після CI)🔹 Heroku – простий деплой прямо з GitHub.🔹 Fly.io – сучасна альтернатива Heroku, дешевша.🔹 Render / Railway – автодеплой «з коробки».🔹 Docker – свій імідж деплоїмо через GitHub Actions. 📂 Готові приклади🔹Thoughtbot Rails Template → suspenders 🔹 Гайд від GitHub → docs 🔑 Практичні поради🔹 Ніколи не деплой без green CI.🔹 Блокуйте PR, якщо тести падають.🔹 Деплой – окремий workflow, не змішуй із тестами.🔹 CI повинен бігати < 5 хв (кешуй залежності, важке винось окремо).💡 ВисновокМінімальний CI/CD – це не «опція», а базова гігієна проєкту.Автоматизація не тільки рятує від «забув протестити», а й економить десятки годин усій команді.#codica_adviceTikTok | Instagram | Telegram

1. Основи Ruby📌 Що вивчати:- синтаксис- типи даних- цикли- методи- класи й модулі📚 Ресурси:👉 Ruby in Twenty Minutes 👉 The Odin Project: Ruby 👉 RubyMonk 2. Git і GitHub📌 Що вивчати:- git init, commit, push/pull- branches, merge, pull requests📚 Ресурси:👉 Git Handbook 👉 Learn Git Branching 3. RubyGems та середовище📌 Що вивчати:- Bundler- rbenv / rvm- pry, rake, irb📚 Ресурси:👉 Bundler Docs 👉 Awesome Ruby Gems 4. HTML/CSS + трохи JS📌 Що вивчати:- семантика HTML- Flexbox / Grid- форми- базовий JS📚 Ресурси:👉 Frontend roadmap 👉 MDN HTML/CSS 5. Ruby on Rails: Початок📌 Що вивчати:- MVC- ActiveRecord- routes- generators- CRUD- layouts, partials📚 Ресурси:👉 The Odin Project: Rails 👉 Rails Guides 6. Тестування📌 Що вивчати:- RSpec- FactoryBot- Capybara- unit vs integration tests📚 Ресурси:👉 Everyday Rails Testing with RSpec 👉 Better Specs 7. API та JSON📌 Що вивчати:- Rails API-only mode- serializers (ActiveModelSerializers / fast_jsonapi)- pagination📚 Ресурси:👉 Rails API Guide 8. JavaScript + Stimulus / Turbo📌 Що вивчати:- Stimulus.js- Turbo Frames / Streams (Hotwire)📚 Ресурси:👉 Hotwire Docs 👉 Stimulus Handbook 9. Аутентифікація та авторизація📌 Що вивчати:- Devise- OmniAuth- Pundit / CanCanCan📚 Ресурси:👉 Devise Docs 👉 Pundit 10. Практика🧪 Спробуй реалізувати:✅ блог✅ ToDo app✅ API для мобільного застосунку✅ систему авторизаціїДалі: Архітектура, продуктивність, бекграунд-джоби📌 Вивчи:- Sidekiq- Redis- кешування- Bullet gem📚 Читай:👉 Ruby Weekly 👉 Rails Bytes 👉 GoRails 🔗 Зберігай у закладки і ділися з колегами!#codica_adviceTikTok | Instagram | Telegram

1. “Тест працює тільки в мене на машині”❌ Погано:driver.find_element(css: '.button') – Але кнопка існує лише локальноЛокальний Chrome 120, локальна локаль, локальні баги. А на CI падає, як вежа Дженги в день дедлайну.✅ Добре:— перевіряй автотести в середовищі, наближеному до бойового— запускай у Docker або на CI/CD— уникай прив’язки до локальних шляхів, специфічних таймінгів і dev-only config’ів2. “wait(1)” вирішить усе❌ Погано:time.sleep(3)Іноді здається, що більше сну – більше стабільності. Насправді – це антистрес, а не тестування.✅ Добре:— використовуй explicit wait з умовами— мінімізуй sleep, бо в CI це 90% проблем3. “Крутий фреймворк, але без звітів”Тести запустились, щось там пролетіло, щось впало – а що саме? Невідомо.✅ Добре:— генеруй читабельні репорти (Allure, TestNG, HTML-звіти)— скриншоти на фейлах – маст хев4. “У нас є PageObject, але там 500 рядків”Page Object Pattern – супер. Але коли вся логіка тесту, бізнес-логіка, верстка і душа QA живе в одному класі – то це вже Spaghetti Object.✅ Добре:— тримай Page Object чистим— логіку – в окремі helper-и або step definition-и— тест має бути «що перевіряємо», а не «як усе клікати»5. “Автотести є – але їх ніхто не запускає”Тести написані, додані в репо… але з 2022 року не запускались. Або запускаються лише вручну “на реліз“.✅ Добре:— інтегруй з CI/CD: GitHub Actions, GitLab CI, Jenkins— запускай хоча б smoke тести на pull request📌 ВисновокАвтоматизація – це не про “писати тести“, а про робочу систему, яка регулярно щось перевіряє без вашої участі.Не будь тим, хто пише автотести тільки для галочки (і лише в README).#codica_adviceTikTok | Instagram | Telegram

Незмінні (Immutable):Integer – цілі числа: 42, -7Float – десяткові числа: 3.14, 0.001Symbol – унікальні імена: :user, :emailTrueClass, FalseClass, NilClass – логіка: true, false, nil📌 Приклад:x = 5y = xx += 1puts y # => 5 (x і y – окремі об'єкти) Змінні (Mutable):String – рядки: "hello", 'world'Array – масиви: [1, 2, 3]Hash – словники: {name: "Dima", role: "CEO"}Set – множини (через require 'set')📌 Приклад:arr = [1, 2, 3]arr << 4puts arr.inspect # => [1, 2, 3, 4] Цікаві нюанси:🔸 Рядки у Ruby – mutable за замовчуванням:str = "Hi"str << " there"puts str # => "Hi there" 🔸 Але символи :symbol – immutable. Памʼять економлять і швидше порівнюються::admin == :admin # => true (один обʼєкт)"admin" == "admin" # => true, але два різні рядки Чому це має значення?В Ruby багато магії, але якщо не памʼятаєш, що mutable – можеш собі ж копати баги 🕳️Правильно обираючи тип – економиш памʼять, пишеш безпечнішеА ще краще розумієш, чому одні об’єкти змінюються, а інші ні – без сюрпризів 💥⚡ Далі буде – типи даних у JavaScriptЗалишайся з нами 💬#codica_techTikTok | Instagram | Telegram

✅ ReactReact залишається королем фронтенду й у 2025. Його популярність лише зросла завдяки React Server Components і покращеній інтеграції з Next.js.✅ Vue.jsVue 3 уже став стандартом, а в 2025 з’явився Vue 3.4 із ще кращою продуктивністю та офіційною підтримкою Vite як рекомендованого білдера.✅ Angular Angular випустив версію 18 із новим компілятором та значно кращим DX (developer experience).✅ Svelte & SvelteKitSvelte продовжує завойовувати серця завдяки відсутності віртуального DOM і мініатюрним бандлам. У 2025 SvelteKit (фреймворк поверх Svelte) стабільно підтримується й розвивається.✅ Next.jsТак, це вже не просто «React», а цілий фреймворк з рендерингом на сервері, підтримкою React Server Components і Edge Functions. У 2025 – ще швидший.✅ Nuxt.jsФреймворк на базі Vue, чудовий для SSR та статичних сайтів. Nuxt 4 ще більше спростив роботу з TypeScript та серверними функціями.✅ QwikНовачок, який буквально злітає. Основна фішка – миттєвий старт сторінки завдяки розумній стратегії завантаження.✅ Solid.jsЩе один легковаговик, що перевершує React за продуктивністю й простотою, із реактивною моделлю даних.✅ RemixБрат Next.js, але з акцентом на веб-стандарти, форми та роботу без JavaScript там, де це можливо. Дуже гнучкий.Висновок:👉 Якщо потрібна стабільність – беріть React, Vue або Angular.👉 Якщо хочеться чогось нового й легшого – пробуйте Svelte, Solid чи Qwik.👉 Для серверного рендерингу й SEO – Next.js, Nuxt або Remix.Зберігайте собі й діліться з колегами.А якщо ви вже тестували щось із новенького в 2025 – діліться враженнями в коментарях 👇🚀 Успіхів і хай ваш код завжди буде красивим та швидким!TikTok | Instagram | Telegram

1. Основи JavaScript📌 Що вивчати:- синтаксис JS- змінні (var, let, const), типи даних- оператори, умовні конструкції, цикли- функції, стрілкові функції- області видимості та hoisting📚 Ресурси:👉 MDN: JavaScript Basics 👉 JavaScript.info 👉 Eloquent JavaScript (книга) 2. Git та GitHub📌 Що вивчати:- git init, add, commit, push/pull- гілки та злиття (merge)- pull requests📚 Ресурси:👉 Git Handbook👉 Learn Git Branching 3. HTML/CSS (обов’язково!)📌 Що вивчати:- семантичний HTML- Flexbox, Grid- адаптивність (media queries)- базовий дизайн форм📚 Ресурси:👉 MDN: HTML 👉 MDN: CSS 👉 Frontend Roadmap 4. DOM та події📌 Що вивчати:- вибір елементів DOM- зміна стилів та атрибутів- обробка подій- делегування подій📚 Ресурси:👉 MDN: Introduction to the DOM 👉 JavaScript.info: DOM 5. ES6+ і далі📌 Що вивчати:- шаблонні рядки, деструктуризація- spread/rest оператори- модулі (import/export)- async/await, проміси- класова модель📚 Ресурси:👉 MDN: ES6 guide 👉 JavaScript.info: Promises 6. Інструменти розробника📌 Що вивчати:- npm/yarn — менеджери пакетів- Babel — трансляція коду- Webpack / Vite — збірка проектів- ESLint / Prettier — лінтинг і форматування📚 Ресурси:👉 Node.js Docs 👉 NPM Docs 7. Фреймворки та бібліотеки📌 Що вивчати:- React.js — компоненти, стейт, хуки- Vue.js — шаблони, реактивність- Angular — модулі, компоненти, DI📚 Ресурси:👉 React Docs 👉 Vue.js Docs 👉 Angular Docs 8. Тестування📌 Що вивчати:- unit-тести з Jest- E2E тести з Cypress- мокінг, snapshot-тести📚 Ресурси:👉 Jest Docs 👉 Cypress Docs 9. API та JSON📌 Що вивчати:- робота з JSON- HTTP-запити (fetch, axios)- REST API📚 Ресурси:👉 MDN: Fetch API 👉 Axios 10. ПрактикаЩо зробити:✅ ToDo app✅ калькулятор✅ галерея з API✅ чат на WebSockets✅ SPA (single page app) на React/VueДалі: архітектура, продуктивність, CI/CD✅ оптимізація фронтенда✅ SSR (Next.js/Nuxt.js)✅ автоматизація збірок, деплой📌 Читай:👉 JavaScript Weekly 👉 Awesome JavaScript (GitHub) Зберігай у закладки й ділися з друзями! 💬#codica_adviceTikTok | Instagram | Telegram

🔹 Rubyist UA – максимально зрозумілий Ruby українськоюАвторські уроки, які крок за кроком допоможуть розібратись із Rails-проєктом.👉 Налаштування середовища та перший запуск проєкту 👉 Загальний принцип роботи сайту. Робота з VIEW 👉 HTML. Bootstrap. Assets. Робота з помилками 🔹 Rails-практика від CodicaХочеш створювати реальні проєкти на Rails? Тоді тобі сюди. Все показано наживо – бери й повторюй.👉 #1 Rails Туторіали | Встановлення та старт нового проєкту 👉 #2 Rails Туторіали | Створення моделей та міграцій 👉 #3 Rails Туторіали | Оновлення Rails та перший скрапер 👉 #4 Rails Туторіали | MVC Архітектура 🔹 Основи Ruby для новачківЧіткі пояснення, базові концепти, хороший стартовий матеріал для тих, хто тільки починає.👉 Основи Ruby 👉 Вступ до фреймворку Ruby on Rails 👉 Архітектурні шаблони. Сервіс, форма та декоратор 🔹 Як підготуватись до інтерв’ю на Ruby on RailsМаксим – Tech Lead, і Наталія – HR-директор з Codica, розповідають, як виглядає реальне технічне інтерв’ю для джуна, чого чекати й як себе підготувати.👉 Як джуну пройти технічне інтерв'ю Ruby on Rails 🔹 Вступ до Ruby: оглядова лекціяДопоможе скласти загальну картину й зорієнтуватись, куди рухатись далі.👉 Коротко про Ruby для джуніорів | EPAM University 🎬 Вмикай, практикуйся, ділись із друзями. Навіть з базовим Ruby вже можна будувати справжні проєкти. Гарного перегляду!TikTok | Instagram | Telegram

1. God Model — коли модель знає ВСЕМодель User у 700 рядків? Там і валідації, і бізнес-логіка, і парсинг Excel, і надсилання email’ів, і… сльози.❌ Антипатерн:class User < ApplicationRecord before_save :normalize_email def send_welcome_email; end def export_to_csv; end def soft_delete; end def hard_delete; end def resurrect; end # ще 53 методиend ✅ Краще:— винести бізнес-логіку в сервісні об'єкти— окремі обов'язки – в concerns— парсинг/експорт – в окремі класи2. Fat Controller — коли кожен екшн з душею (і сотнею рядків)OrdersController, де create – на 70 рядків, а update – на 130? Це вже не REST, це серіал.✅ Краще:— витягнути логіку в форм-обʼєкти— використовуй interactor’и, services, commands— before_action з умовами – ок, але без фанатизму3. Колбеки-лабіринти (before_save, after_commit, around_update)Якщо ти не впевнений, чому один і той самий рекорд тригерить три листи й два оновлення таблиць – ти, мабуть, десь переборщив із колбеками.❌ Проблема:— Колбеки приховані— Їх важко тестувати— Вони викликаються неочікувано✅ Рішення:— винось сторонні ефекти (email, push, інтеграції) у ActiveJob— використовуй Service objects, де логіка викликається явно, а не «десь там у фоні»4. Business Logic in Views (ERB має бути простим)Якщо в show.html.erb ти бачиш це:<% if current_user.admin? && order.status == 'pending' && Time.now < order.expires_at %> <%= link_to 'Approve Order', approve_order_path(order) %><% end %> …то ти бачиш антипатерн.✅ Краще:— логіку – в helpers або view models— мінімум умов у ERB, максимум змісту5. Overuse of default_scopeЦе ніби зручно: ти хочеш, щоб усюди is_active: true. Але потім ти хочеш зробити with_deleted… і нічого не працює.❌ Антипатерн:default_scope { where(is_active: true) } ❗ Чому погано:— default_scope автоматично додається у ВСІ запити – навіть у joins, includes, count— складно зрозуміти, чому певні дані «не приходять»✅ Краще:scope :active, -> { where(is_active: true) } Rails – це про швидкість. Але legacy приходить не вночі, воно починається з «та я просто тут один колбек додам».Вивчай свій код. Переписуй. Не соромся бути кращим, ніж був вчора.Хочеш частину 2 з антипатернами – напиши в коментарях 👇TikTok | Instagram | Telegram

1. “Після цього клікати – не обов’язково” (і забули протестити клік)Ніхто не любить повзати по кожній кнопці. Але от кнопка в стилі “Submit” без жодної дії і вже гаряче.❌ Погано:Протестували валідацію форми, але не перевірили, що кнопка взагалі щось робить після неї.✅ Добре:Завжди перевіряй поведінку після дій, навіть якщо “начебто вже все валідне”.2. “Все працює, бо я так кажу” (і нуль тест-кейсів)Тестувати “на око” – це класика. Але нагадаємо: “Looks good to me” – не тест-кейс.❌ Погано:Прийомка без документації, без кейсів, без чеклістів.✅ Добре:Базові кейси в Notion/Google Doc/QA Touch – це вже ок.Все, що можна автоматизуй або хоча б стандартизуй.3. “Тестував на Dev, на Staging ще не бачив”Сценарій: на деві все супер, на проді зламалась оплата. Бо в staging інші налаштування, а ти туди не заходив.❌ Погано:Перевірка тільки на одному середовищі.✅ Добре:Завжди уточнюй, на яких енвайронментах треба перевірити.Проганяй критичні кейси скрізь, де вони можуть відрізнятись.4. “Щось не працює, але я не зберіг скрін”Скриншот, відео, логи, дані – усе це важить більше, ніж “ну воно просто не працює“.❌ Погано:Репорт: “Помилка при логіні” без опису, даних та відтворення.✅ Добре:Додавай все: що робив, у якому браузері, які кроки, які очікування.Скрін – це добре, але ще краще відео з Loom.5. “Я думав, що це фіча” (і не спитав ні в кого)Нічого страшного, що користувач не може вийти з кабінету. Це ж фіча. Мабуть.❌ Погано:Здогадки замість уточнень.✅ Добре:Питай: у продактів, у тімлідів, у дизайнерів.Краще уточнити, ніж закрити баг, який закриє вам карму.QA – не про те, щоб знайти баг. А про те, щоб не пропустити критичне лайно в прод. Іноді дрібна неуважність створює більше проблем, ніж баг в коді.Тому тестуй ретельно, думай системно і бережи скріншоти ❤️#codica_adviceTikTok | Instagram | Telegram