оце людей канешно стрігерів ноут за 6к. раніше були сири по 500гривень, потім штани за 100 гривень, далі куа за 8к і тепер, виходе, шо новий мемасик буде — ноут по 6к :)

як на мене то якшо любиш працювати в компорті та проводиш за робочим місцем більше ніж 8 годин то треба облаштовувати з комфорттом все.
я би додав ще про ергономічну мишку та монік — це ще плюс 3-5к мишка(я юзаю вертикальну від логітек), і думаю мінімум 10к монік може бути(у мене асер на 27 діагональ найдешевше шо можно було найти під адаптацію мака)

мікрофон — в еру онлайн конференцій та онлайн прісейлів — це взагалі маст хев для спікерів. бо мене аж тіліпає коли спікера чутко як з унітазу. це не професіоналізм. і тут Роману громадний плюс ща те зо дбає про слухачів. Сам такий же і купив собі мікрофона того щоб чутно адекватно було мене.

а взагалі канешно дивно шо публіка так токсично сприймає те що хтось може купити ноут за 6к.

по-перше, тут не привʼязано до інтерфейса перші приклади.
по-друге , тут, якщо б ти прочитав, то побачив би, шо є також приклади АПІ тестів.
по-третє, якшо знову ти б прочитав трішки, то побачив би, шо тут не тільки про тестування є приклади взагалі.
ну, і по-четверте, нащо залишати токсичні коментарі-претензії які не несуть ніякого змісту чи фідбеку адже апріорі є хибними? наче немає більше чого писати :)

у нас в організації я зробив темплейт під стек технологій. тобто умовно є один великий фреймворк який підтримує наприклад стек джава і все около нього. і там вже є і логуваня, і репортінг, і адаптори під ui, під рест, під графкуель та під базу даних, ну і звісно все структуровано, з можилвостями запуска тестів під різними конфігами, та рідмі файл як цим користуватися. з прикладами використання кожного адаптора а також yml файлом як це все розгорнути на CI.
коли новий проєкт заходе — то людина просто видаляє зайві модулі і приклади використання, підналаштовує необхідні парамтери проєкта(урли і оце все) і все по суті. займає від 4 до 12 годин це все.

Привіт. цікавить цей пункт:

Створення і налаштування проєкту — 40 годин

а можеш детільніше розкрити чому так багато часу на це витрачаєш?
зазвичай же у кожної організації є вже певний набор темплейтів під кожну технологію і розгортання повинно займати максимум декілька годин.

отут без обрізки скрінщотів, та ще й зі звуком :) www.youtube.com/...​z1H72a2YlupiqNIMEQcMrtCJg

ухти. дуже радий шо спобобалося :) дякую =)

цікаво вийшло) дякую за статті ці :)

а є вже тули котрі аналізують чи текст написаний ШІ чи ні :)

це чатгпт відповів)))

To sell flights through a Global Distribution System (GDS), you need to be a travel agent or a travel agency with a valid GDS contract. The steps to sell flights through a GDS are as follows:

Obtain a valid GDS contract: Choose a GDS provider (e.g. Amadeus, Sabre, Galileo, etc.) and sign up for a contract to access their platform.

Learn to use the GDS platform: Get trained on how to use the GDS platform to search for flights, compare options, and book travel itineraries.

Access flight inventory: Connect to the airlines’ systems through the GDS to access their flight inventory and pricing information.

Search for flights: Use the GDS platform to search for flights based on the desired travel dates, routes, and number of passengers.

Compare options and make a booking: Compare the flight options and select the most suitable flight for the client. Then make the booking and issue the ticket.

Confirm the booking: Confirm the booking with the airline and send the itinerary to the client.

Note: The specific process may vary based on the GDS you are using and the type of ticket you are selling.

взагалі неможна продакшн код або дані давати йому)) за таке можна і штраф отримати величезний тому краще такого не робити

я от доречі починаю думати про те шо а чи не приведе нас колись чатгпт в якусь ідеократію :D
бо коли людина задає якесь питання стандартним способом — то вона починає розмірковувати над ним і виявляти в себе області які треба додатково довчити і таким чином закриває ці області і навчається. а коли задає питання чатугпт то одразу отримує відповідь. і процесс самого навчання зникає. а мозок наш же працює не так — -йому шоби щось запамєятати треба якісь ефорти. цікаво як далі це буде і чи не буде від цього у довгострокових перспективах більше зла ніж користі

звеселило)) дякую))

дуже класний подкаст! спікери молодці!

дякую за огляд книжки!

вибачте, але це софістика чистої води. ви робите заздалегідь хибні твердження і на основі їх розвиваєте свої думки як вам здається «логічно». тут навіть розвивати і критикувати немає сенсу такі коменти :D
це все одно що сказати — програмісти не треба бо ШІ все напише сам просто треба вірно загуглити запити. ну і далі ці думки розвивати по аналогії з вашими :D
розробники не потрібні, тестувальники не потрібні. треба тільки ШІ

ну ви ж розумієте якшо підход такий шо «мопед не мій я просто обʼяву скинув» то там і всі процеси компанії такі. якшо ви цікавитесь проєктом, командою та компанією а вам не відповідають на це — то це ВЕЛИЧЕЗНИЙ червоний флажок. в адекватних компаніях тобі про це завжди розкажуть, а якшо так виявилось що той то тебе співбесідує не може відповісти то зроблять додаткове інтервєю з проджект менеджером того проєкта куди тебе співбесідують. виключення з питаннь про проєкт може бути тільки коли тееб беруть не під проєкт конкретний а взагалі в штаб. тоді 2-3 питання відпаюать. а решта все ще актуальна завжди.

крута підбірка! дякую!

Трішки підкорегую вас. В суті/цілі/визначенні скраму полягає ідея того, що БУДЬ-ЯКУ ЗАДАЧУ може виконати БУДЬ-ЯКИЙ ЧЛЕН ДЕВЕЛОПМЕНТ ТІМИ( немає ніяких фронт бек куа девопс мобайл і тд.). У скрамі є тільки 3 ролі — девелопер, скрам майстер та продакт овенр.
Можете ознайомитися з офіційним документом scrumguides.org/...​rum-guide.html#developers там в принципі все розписано про ролі і обовʼязки :) а також про те як відбувається планування ітерації та як розподілення задач відбувається. інакше ви отримуєте не чистий скрам, а його варіації-мутації(як хороші так і погані) :)

Цікаво було б побачити якісь приклади. Бо мені на думку спадає хіба що пиляння якогось MVP

абсолютно ні. Наприклад, розробка складного ембедед, розробка SDK-рішень, розробка бібліотек, розробка тулів по міграціям баз даних і т.д. в світі айті ДУЖЕ багато того де краще тестування віддати на роль розробника ніж залучати тестувальника котрий буде заважати :)
в тестуванні є навіть принцип , один з основних, що тестування залежить ВІД КОНТЕКСТУ. тому тестування повинно бути, АЛЕ НЕ ЗАВЖДИ тестувальник в теперішному розумінні повинен бути на проєкті.

як раз можна перевірити чи не обманює вас рекрутер :)