і ще одна думка про те як змінюється розробка під впливом АІшки. знаєте, багато років тому (ЗА ЧАСІВ ДАВНІХ БОГІВ ТА ЦАРІВ) ми йшли програміровать потому шо нам подобалось програміровать. знаєте, оцей самий кайф від написання класів, методів, використання красівих патернів та як елегантно код потім працює. Подобалось думати над проблемою та її вирішенням. В цей час ти уявляв себе якимось магом якийсь шото там колдує а потім ВІОЛА і появляється магія запуску та робочого коду. Дуже цікаво було це робити і люди йшли в програмірованіе в першу чергу за цим. ну а потім канешно уже гроші, тьолки, яхти та спорт-кари. Але була одна найтупіша та найнеприємніша частина роботи — це розбиратись у чужомі гамні. Дивитись на нього, читати, пробувати на смак, нюхати а потім писати полайт коменти шо та як виправити. Не думаю шо комусь взагалі це колись подобалось як частина процесу( ізвращенци каншно є але не всі). і от в чому найбільший мінус-вайб зараз так в тому шо тепер 90% твоєї роботи — це читання чужого аішного гамна. Так, інколи АІшка генерить досить хороший код, якшо надати весь контекст, правила, архітектуру, гарно описати що хочеш та надати всі конвенції коду.АЛЕ БЛЯХА ПРОПАЛА МАГІЯ СТВОРЕННЯ КОДУ. тепер ми по суті нічим не відрізняємось від рабочих на заводі. Магія коду пропала, залишивши лиш звичайну механіку дій. і це сумно...
короче я хз шо там далі буде але АІшка настіки уже інтеграувалась у життя і всі процеси під це адаптувались шо становиться ДУЖЕ СТРАШНО навіть. сьогодні у мене була простїо єбейше-велика задача. треба було заінтродьюсити нове розширення для дужеееееее великої фічі з мільйоном бізнес правил і купи складної логіки, змінами в архітектурі, в апі контарктах, і відслідкувати це дуже обережно шоб був план змін шооб легенько це потім представити девам і запланувати роадмапу імплементації. по ітогу цей бласт-радіус зайняв близько 30 файлів які треба було апдейтити(апдейти там не 2-3 рядки помінять а прям нормально так переписувати), і ще 10 юзер сторей які треба було створити нових, плюс заапдейтити громаднку ерд. вопщім - це все заняло у мене сьогдні майже весь день. токен-юзедж просто улетів в космос АЛЕ я от тепер це оцінюю уже весь той обсяг роботи шо я зробив (відсотків 80 писала саме текст АІшка а я гайдив її шо мені треба та ревьював) АЛЕ АЛЕ АЛЕ - оцінюючи обсяг роботи — я б без неї цю херню робив не десь тиждень блять мені здається мінімум і стопудов десь би лажанув у завісімостях. короче гайз та герлс - стає страшно наскіки уже голка АІшки в нашому мозгу стирчить.
🇺🇦 Друзі, до вашої уваги добірка каналів, які можуть стати вам в нагоді. Підписуйтесь! ▪️Податки та бухгалтерія | WeDoITBM — актуальні новини про податки фізичних осіб для тих, хто отримує додаткові або іноземні доходи, ФОП, ТОВ - від провідних спецілістів WEDOITBM▪️dev.ua — канал з новинами IT сфери. Тут історії айтішників, правда про те, як IT-бізнес переживає війну та новини про українські розробки.▪️Finance.ua — все найцікавіше про фінансову сторону технологій: ШІ, стартапи, Big Tech і digital. Автори доступно й без води розповідають про гроші, інвестиції та економіку.▪️Нейрокомедія - канал, де автор ділиться всіма потрібними нейронками для роботи.▪️Python - флагманський канал з програмування на Python. Вивчаємо найпопулярнішу мову програмування разом.▪️Твій старт в IT — тут ЕКСКЛЮЗИВНІ вакансії для джунів, БЕЗКОШТОВНІ курси (які зазвичай платні) та найсвіжіші AI-сервіси, що дають перевагу тим, хто почав раніше.▪️Hayat Estate— блог про нерухомість у 20 країнах: як обрати житло для себе та інвестування з дохідністю 6-11% річних. Огляди ЖК, стратегії, дольовi iнвестицiї вiд $28k та готельна нерухомiсть вiд 1/8 частки
АІ та "заміна людей". Нижче буде логнрід про АІшку та нас, інженерів. Короч, я чось почав думати шо багато людей не розуміють про шо йдеться мова коли кажуть шо "АІ замінить людей". Тут суть не в тому шо умовно прийде твій бос-начальник і скаже шо тепер то шо писав ти замість тебе буде писати АІ. Зовсім не. Це не так буде працювати. Вас звільнять через те шо для вас просто нема тасок та роботи. А чому нема тасок та роботи? Тому шо при переході на аджентік девелопмент міняється швидкість виконання задач. От уявіть - у вас є команда із 4 бекендерів, 3 фронтів, дізайнера, БА архітекта та менеджера. Олд-мані-стайл розробки це шикарно всі на чіле кнопають шось собі, тасочки в жире мувають а ПМчік питає нушотам. все в кайфу. Перші ітерації коли прийшла ШІшика — ібули по суті це — АІ каже - я друкую швидше. І всі бачили - ну тіпа даа але ти ще гамно ШІшика, я зннаю краще тебе, казали деви. Другі ітерації були такі тіпа ну шось таки є але я все ще круче. Треті - воно почало робити прототипи але вони банально навіть не запускались. Куча галюцинацій, куча багів, куча невідповідностей. В якийсь момент велика частина інженерів перестала пробувати тому шо зловили оцей байас до ШІшки шо воно завжди видає дікуху. Але пупупуууу час іде і пацани з опенаІ та антропіка не зря мільйони свої получають. В якійсь з ітерацій той же клод код почав видавати уже дуже доволі такі структуровані результати. писати апки без багів, які запускаються, які виконують вимоги, знаходити дірки в апках, фіксити баги та в цілому допомагати в роботі як помічник уже а не як джуніор. це все предисторія. Так от тепер найголовніше — як та чому вас звільнять? Все просто — при пришвидшенні виконанні задач то шо робило 4 інженера зараз буде робити 1 максимум 2. Бізнес же не зможе настільки швидшко генерувати ідеї, фічі та задачи. В якийсь момент у вашої команди просто скорость деліверінгу стане вище за скорость поставки. Виникне ботлнек у вигяді Продакт Овнера чи Клієнта які скажуть шо пацани задач нема — нам треба ті шо заделіверили протестувати на юзерах реальних та отримати фідбек. Власне постане питання а нашо нам тримати стіки людей які простоюють. ПО суті треба один матрьорий лід який буде ревьювати та оркуструвати і другий такий самий оркестратор. Тех ЛІд нікуди не дінеться бо треба людана з дуже вузьким і глибоким досвідом шоб відсікати дікуху яку ШІшка все ще робить інколи. А другий - це прото свободні руки шоб робили також задачі бо один лід не витягне. Ось і відублось зменшення ресурсів.Деякі ж ролі трансформуються. Ті ж БА — навіщо архітектору пояснювати то що він надізайнив повторно якшо у нього уже є повністью весь контекст у його АІ агенті і він просто може зделегувати це шоб створити всі артіфакти БА автоматично. Плюс не треба буде перевіряти чи вірно зрозумів БА контекст і чи вірно все напсиав - також - прибирається оцей вейст комунікацій шо для бізнеса тільки плюс. Тому архітектори стануть ще ближще до бізнеса і до команд. і приймуть роль БА. Аналогічно по дизайну — тепер не треба буде один дизайнер під кожен проєкт — треба матьорий дізйн лід який буде вести 4-5-6 проєктів і ревьювати після прототипування або пітримувати існуючю дізайн систему. Мені здається тільки мануальні тестувальникі у більшменш безцепі зараз бо тут чисто механічна робота з проклікування та придумування едж кейсів — її поки не бачу як пришвидчити прям суттєво. Так, звісно є буст у напсианні тестів, доки якоїсь але це 10-20%, не 3-5 разів як у девелопменті. Чи дам я якусь пораду? Відкладати гроші 😄 Але якшо без жартів то це — не боятись трансофрмуватись у своїй ролі та брати нові задачі на себе. Якшо ви БА - вивчайте дизайн та проєктний менеджмент. Якшо ви ПМ вивчайте БА, та дизайн. Якшо ви девелопер - вивчайте паралельний трек - бек вчить фронт, фронт вчить бек. Якшо ви куа - вчіть шо там БА робить та дизайнери. Якшо ви ЕМ - час згадати як писати код . Якшо ви архітектор - розберайтесь в артефактах БА та дизайнера, а можливо і прийде час шо і знову придеться писати код.
понеділковий-песимістичний пост або чому нам всім трошечки хана і ринок буде переформатований значно. зараз АІ настільки несеться і настільки скорость розробки збільшується що ботленеком уже стають продакт овнери та архітектори. звідси випливає друга штука - що в такому обсязі як зараз, інженерні команди уже стають непотрібні. адже то шо раніше могли робити 3 інженера - зараз робить один. це прям уже підтверджені кейси з реальних багатьох команд. продуктивність зростає колосально. і тобто, здавалось би, круто шо швидше деліверимо більше кайфу але фічі імлементяться настільки швидко що бізнес не встигає досліджувати ринок, юзерів та потреби. а деліверити фічі раді фічей без дослідження ідея завжди так собі. саме тому стіки інженерів як було раніше уже не треба буде ринку. компаніям треба буде доволі сіньорний оператор-АІ який зможе якісно поревьювати код нагенерований АІшкою, дати рекомендації та продовжити роботу. В свою чергу арзітектори все більше зміщаються в сторону продакт овнерства та бізнес контексту і, я думаю, навіть в сторону інженірінг-менеджменту. Через це позиція "я архітектор рісую діаграмки і на команду мені пофігу" теж скоро трошки зміниться на "я даю технічний контекст та управляю командою". Взагалі дуже страшно та водночас цікаво зараз відбувається все. Компанії гіганти на декілька кроків попереду серед великий відсоток ерлі-адаптерів ніж аутсорс та маленькі продукти які не хочуть нести зміни в собі. Моя порада — макимізувати використання АІ але при цьому максимізувати свої ТЕХНІЧНІ навички. бо абізян-клацальщіков буде все більше а технічно грамотиних спеців - все менше. виживуть гібріди
Ох уж ці проксі. Як раз і назавжди запомніть де який.Forward proxy - це твій старший кент, який ходить за тебе у магаз по півасік бо тобі ще нема 21. Магази "бачать" кента, а не тебе.Reverse proxy - це твій кент, який вирішує, куди повести поліцаїв коли за тобою приїхали шоб був час сіганути через чорний вихід.До хати приходять люди з автоматами і кажуть: "Ми до тебе!". На вході стоїть кент і сам вирішує, куди їх вести: у кухню, вітальню, чи в іншу кімнату(де тебе нема). Непрохані гості навіть можуть не знати, скільки там кімнат і що всередині.Forward proxy- на боці клієнта (або "перед" клієнтами в їхній мережі) - клієнт явно звертається до проксі, і проксі робить запит вперед у зовнішній світReverse proxy- на боці сервера (або "перед" серверами).- клієнт звертається до домену сервісу, але фактично потрапляє на reverse proxy; той пересилає запит назад, у внутрішній контур до серверів.Тепер коли на собесе спитають різницю між проксіями завжди згадуй ти по півко ти від поліцаїв тікати хочеш.
👨💻 Нова ера тест-дизайну та оновлення в ISTQB Advanced Test AnalystЦього року сталася офіційна трансформація погляду на test design techniques! І досить несподівано, що опублікували її в рамках сертифікації ISTQB - Advanced Test Analyst 4.0, бо останні концептуальні зміни були від пана Бейзера, коли більшість з нас ще ходила до школи чи навіть садочку.😮Враження про зміни Олександра Ковальова вже писала для вас в пості зі схемками, які викликали активний відгук читачів. А ми нарешті готові провести на цю тему детальний вебінар - бо вона того заслуговує:ISTQB Test Analyst 4.0: Нова ера Test DesignРозберемося з питаннями✅ Як змінилося бачення black box techniques і що тепер входить до трьох нових категорій?✅ Які техніки з’явилися вперше — CRUD, Metamorphic, Random testing [guided vs adaptive] і не тільки.✅ Як автоматизація дісталася до тест-дизайну і що таке model-based testing?✅ Що ще покриває нова версія Advanced Test Analyst 4.0 і чому її називають найглибшим оновленням за 25 років?✅ Чому defect prevention тепер у компетенціях тестувальника і до чого тут метрики?✅ Організаційні зміни сертифікації: став іспит легшим чи складнішим? Що робити тим, хто вже складав?Організаційне:⏰ 11 грудня (четвер) 19:00 за Києвом🎞Проводиться онлайн, запис відправимо всім зареєстрованим учасникам💫 Участь безкоштовна➡️ДЕТАЛІ ТА РЕЄСТРАЦІЯВелкам пересилати цей анонс своїм колегам та знайомим тестувальникам, щоб було потім з ким все обговорити