Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Co-Founder в Artellence
  • Генерація текстів: перевіряємо прогрес AI-моделі від GPT до ChatGPT

    Це проблема ... але мені здається гугл адаптується.

    Якщо чесно, з англомовним контентом такої проблеми поки немає. А російською гуглити сенсу все-рівно немає. І це при тому, що англомовний NLP розвинений на порядок краще.

    GPT саме по собі не добре і не зле. Можна генерити як і шлак в блоги, так і голосові помічники чи пошуковики за «сенсом», а не за ключовими словами.

    Шлакові блоги успішно генеруються і без GPT.

    Якщо вашими словами, ми рухаємось до точки, де репутація буде мати все більшу і більшу вагу.

  • Генерація текстів: перевіряємо прогрес AI-моделі від GPT до ChatGPT

    Немає проблеми це робити вже сьогодні. І нейромереж не потрібно. І в тому ж російському сегменті інтернету це роблять вже давно.
    До того ж «перефразувати текст» — це трохи простіша задача, ніж GPT.

    А щодо GPT ... ну пререробить він статтю, чомусь навчиться. Використає якусь написану ідею в якомусь тексті. Це принципово не змінить нічого.

    Думаєте, що те, що зараз роблять сотні людей переписуючи статті, GPT зробить краще? Хз чи краще... але легше зробить. Тільки ось той текст вже буде описувати «щось своє». І якщо оригінальний автор чогось вартий, то перероблена копія буде не коштувати нічого.

    Ось ви оберете ... хз ... почитати Кормена (чи Гарі Потера, залежить від смаку) в оригіналі, чи в GPT перекладі?

  • Еволюція Spring бінів

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

  • Еволюція Spring бінів

    побачить сам при першому ж запуску

    Там точно все при запуску вилізе? Циклічна залежність в якомусь per-request контексті?

    А про який перфоманс йде мова?

    DI буває різний.

    Частина — це запуск — як раз ті дві секунди про які ви говорите.
    Тут ... хз .. в Андроїді це важливо, в демоні на сервері не дуже.

    Частина — це всякі, наприклад, «per-request» контексти. В Dagger-і всі зв’язування відбуваються в коді і компілюються компілятором. У вас ж тут працює reflection.

    Частина — це всякі аналоги context.get(ApiClient.class). Хоч я і вважаю, що це антипаттерн, але таке буває потрібно. Тут у вас всередині щось аля HashMap з reflection, в Dagger — просто виклик методу.

    Звісно, оце все може виглядати як економія на сірниках. Але цих сірників багато. Якщо чесно, нам не доводилось зіштовхуватись з вузькими місцями саме в цих місцях. Але коли ми обирали DI, це стало суттєвим аргументом.

  • Еволюція Spring бінів

    І чим ваш велосипед краще

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

    Порівнювати тут не дуже коректно ... порівнювати можна було б, якщо б те все дописати по людськи ... але поки цього немає :(

    select for update by criteria

    Ви вірно копаєте, але проблеми бувають не лише в таких запитах. Нажаль.

    хоча все ж таки розумієте, що атомарність похерена і

    Тут як сказати ... якщо це
    INSERT INTO Accounting(debit, credt,amount) ... UPDATE Account SET balance=balance+:amount
    то, звісно, це робиться в одній БД транзакції — без варіантів.
    Якщо ж при цьому, перед цим робиться 10 запитів до «словникових» таблиць ... то не проблема і зробити їх поза транзакцією.
    (Доречі, а у вашому підході, такі UPDATE-и взагалі моживі (аля a=a+1)?)

    Інколи, занадто велика «строгість» вимог до БД виливається в занадто багато проблем з підтримкою такої БД.

    це автоматичний «перекладач» з мови ООП на реляційну БД

    Напевно, десь тут наші погляди і розходяться...
    Ви хочете мати гарне ООП і гарну базу. І щоб ORM все зробила.
    Я ж кажу, що в загальному, такий ORM занадто важкий та неповороткий. Ще й додає складності, якої і без нього вистачає. І він не може використати всі можливісті, які доступні в цій БД. А інколи, такі можливості дуже потрібні стають.

    Тому, коли я думаю про ORM, то бачу перед собою інструмент, що дозволяє працювати з базою легко та типізовано (data/dao-класи), але при цьому робота ведеться саме з базою даних, мовою бази даних і сутностями, які в ній є. А не з віддаленою ООП моделю, що побудована на інших принципах.

    Це бізнес-логіка, яку треба протестувати.

    Думаю, що саме в цьому аспекті у вас це може виглядати трохи гарніше. В моєму випадку це виглядало б якось так

    try (var conn = cpds.getConnection()){
       Model model = SqlQuery.create(conn, "SELECT * FROM Model WHERE id=:id")
         .arg("id",5).query(Model.class);
    
       model.updateAnswer(42);
    
       new SqlSimpleUpdate(conn, "Model", "id=:id")
        .arg("id", 5)
        .setFromObject(model, "answer", "ultimateAnswerFound")
        .execute();
    }
    
    Це не ідеальний код, але ... зверніть увагу
    — замість * я можу вибрати лише ті поля, що портібні.
    — Update тут контрольований, в тому сенсі, що явно вказано які поля можуть оновитись, а які точно ні (мінусом є те, що вони завжди попадають в UPDATE запит, але як на мене — не велика біда, якщо там не 20 полів)
    — Model — можна так само покрити тестами як і у вас вище (хоча тут це не одне і те ж саме).

    Звісно, якщо у вас не одна модель, а граф — то все стає навантаженіше (той update буде в транзакції (але не обов’язково), більше моделей, тощо).

    Для таких задач, ваш підхід буде мати більше магії, а мій більше спілкування з базою.
    — У вас в фокусі бізнес-логіка, ООП та тести, а база якось робереться. В мене ж запити та транзакції є частиною логіки роботи.
    — У вас тестується модель без бази, в моєму випадку, більша частина вимагає щоб БД була.
    — Коли у вас проблема з базою, ви ... хз .. колупаєте анотації і йдете до DevOps? Я ж шукаю проблеми, читаю explain-и, переписую запити, доставляю індекси, будую кеші, тощо.
    — У вас «save» — і ви не знаєте, що там відбувається (поки весь код до того не прочитаєте). В мене ж відбуваєтся лише те, що явно написано.

    Поправте мене, якщо я не правий, але мені здається, що аналіз EXPLAIN-ів у вашому випадку — це щось дуже не природне. Хоча, скоріш всього для різного роду «report»-ів ви, як і всі, пишете великі SQL з купою вкладених JOIN-ів, GROUP-ів та UNION-ів ... там від EXPLAIN-а вас ORM не врятує точно:)

  • Еволюція Spring бінів

    Чи він став перед транзакцією і тепер у вас дві транзакції ?

    Якщо закешований — то береться з кешу. Але в цілому, так ... «дві транзакції» ... setAutoCommit(true). select+update+select+update в одній транзакції робить більше локів бази ніж все окремо.

    Від довгих транзакцій можуть конекшени в пулі вичерпатись, але БД від цього не помре.

    По різному.
    Якщо транзакція (в термінах БД) відкрита, поки робиться ... хай http виклик — це один випадок.
    Якщо транзакція з купою SQL запитів, що повільні — інший.
    В першому випадку, як ви написали, в пулі не стане з’єднаннь ... якщо сама база витримає, то додаток точно помре.

    В другому випадку, ... потік запитів залишається тим самим, але час виконання кожного запиту стає більшим. Відповідно, кількість тих, що виконуються одночасно теж збільшуєтсья. Що збільшує навантаження на IO ще й робить його більш хаотичним, що ще збільшує тривалість запитів (не тільки цих, а й всіх інших) і так далі ... тому й кожу про «лавиноподібність».

  • Еволюція Spring бінів

    Можна приклад помилки, будь ласка?

    [Dagger/MissingBinding] Test.A cannot be provided without an @Inject constructor or an @Provides-annotated method.
    Такого типу, наприклад. В цілому, всі, що пов’язані з DI ... щось не знайдено, десь циклічна залежність, тощо.

    Це такий забавний приклад

    Якщо я вірно зрозумів, то Dagger в одну стрічку не зможе ... треба буде або Inject-и розставляти, або Module робити для цієї бібліотеки.

    Доречі, в Lombok, наче ж можна
    projectlombok.org/...​nstructor#onConstructor(

    порівнювати DI фреймворки — це вкусовщина, якщо немає якихось сильно специфічних вимог

    В цілому, згоден з вами. В моєму випадку вибір на Dagger впав із-за наступних причин:
    1. Він достатній для задач, що на нього покладаються.
    2. Результат його роботи практично не відрізняється від вручну написаного коду (по performance-у).
    3. Кругом працює строга типізація ... немає чогось типу context.get(MyClass.class) ... з dagger-ом аналог буде context.getMyClass() ... відповідно, context. покаже, що там є, а чого немає. (Хоча, насправді, ми стараємось уникати випадків, коли такі контексти треба прокидати всередину класів)

  • Генерація текстів: перевіряємо прогрес AI-моделі від GPT до ChatGPT

    Тут уже идут разговоры на HN о конце веба и превращении его в отстойник автоматически сгенерированного мусора

    Не знаю, що є HN :) Але ви пропустили, напевно, деякі події останніх років 5. Російська частина інтернету вже наглухо заспамлена статтями, метою яких є залучити пошуковий трафік і затримати увагу на подовше (ну і показати рекламу).

    І для цього не треба було GPT, рекламний трафік успішно фінансував армію людей, які аби як генерували реферати під пошукові запити. Як ви розумієте, корисної інформації там майже немає.

    Цій планеті вже давно пора якость навчитись відрізняти корисний контент від сміття ... при цьому не те щоб важливо, його генерить людина чи нейронна мережа.

  • Генерація текстів: перевіряємо прогрес AI-моделі від GPT до ChatGPT

    Авторське право є корисним лише до тієї міри, поки залишається стимул «бути автором». Але не більше.

    Якщо ж авторським правом забороняти «статистичний аналіз тексту чи зображення» — то вже більше «патентний тролінг» — що не приносить користі людству.

  • Еволюція Spring бінів

    I головний її недолік в тому, що без стороннього етапу обробки ваш код не є корректним взагалі.

    Скажу вам, що це не відчувається. Запускаєте білд і весь згенерований код індексується IDE. До того ж, «не коректним» часто виявляється лише одна стрічка у всьому проекті.

    спрінгу воно зроблене не для DI, a для AOP

    Про AOP згоден. Тут він унікальний. В мене лиш є невпевненість в тому, чи така реалізація є «добром» чи «злом». Але це тема для окремої дискусії.

    Так само він вам пише, що такий-то компонент вимагається, але відсутній в контексті

    Dagger це робить в compile time. Я мав на увазі помилки, коли в трейсі є код, що робить inject.

    Жодного разу мені не потрібно було дізнаватись «звідки відбувся інжект».

    Не те, щоб це часто треба, але один раз допомогло знайти помилку:)

    В цілому, декларативність має плюси та мінуси. Плюс — що не треба про це думати. Мінус — якщо все таки треба, то заглянути під капот є проблемою. Тому й в sql придумали explain. Dagger так само працює декларативно, але при цьому, його логіка в людинозрозумілому і компільованому тексті доступна в один клік.

  • На своєму прикладі: як організувати енергонезалежну квартиру на випадок блекауту

    Так, я теж про це думав таким чином. Виходить, що суть в тому, щоб на вхід двигуна потрапляло достатньо кисню. Тобто, треба уникати підмішування вихлопу на вхід.

    СО як і CO2 є важчими газами, ніж O2, тому будуть стелитися вниз, але це за умови однакової температури. Але на вихлопі, газ теплий, тому він піде вверх, поки не охолоне.

    Тобто, якщо, умовний балкон розміщений так, що вихлоп не встигне розсіюватись до того як він охолоне, він почне стилитися по підлозі та потрапляти на вхід генератора ... теоретично:)

    Підтримав: Sviatoslav Ruchko
  • Генерація текстів: перевіряємо прогрес AI-моделі від GPT до ChatGPT

    Цінність авторського права переоцінена.

  • Еволюція Spring бінів

    Я погано висловився ... на рівні апп. На рівні бази було більше на порядок. Нажаль точного профілю навантаження не згадаю.

  • Еволюція Spring бінів

    1 транзакції раз на 2-3 секунди

    Я вже шкодую, що щось подібне написав :) Ще раз... запитів до бази там було більше. І були ще фонові процеси, тощо. Я не пам’ятаю вже точно профіль навантаження.

    Суть в тому, що від стану «все лежить» до «все мурчить» достатньо було акуратно прописати запити без зайвих артефактів (як, наприклад, select в транзакції)

    (Жодного foreign key, тригера та подібних речей там не було)

    Та й, взагалі ... хоч то й зовсім інша історія, але неакуратний select запросто може вирости від 0.1сек до 10сек, коли кількість даних по трохи росте. Навіть на сучасному залізі. І коли під навантаженням таке відбувається, все лавиноподібно дохне. Десь це вирішується додавання індексу, десь force index-ом, десь кешуванням, тощо. І повна абстракція від бази тут не допомагає.

  • Еволюція Spring бінів

    Одна операція на декілька секунд ... під час її обробки відбувалося багато чого і сама ця операція могла секунд 10 щось робити (api, sql, тощо).
    Суть не в цьому.

    Станом на сьогодні, бази працюють швидше (nvme замість hdd, пам’яті більше), але тоді, коли відбувалась описана історія, ssd лише появлялись в нас на ринку, а про nvme ще ніхто не чув. HDD та 16G RAM на базу і додаток було в сумі. База росла по трохи за рахунок «історії», але як добиралась до десь 5 гіг, старі дані видаляли і ставало легше.

    і йти їб@ть адмінів/девопсів

    Вони допоможуть, але не на довго. Софт, який пише в базу «графами об’єктів», завжди буде хотіти більше.
    Вічно ресурси докидати не вийде (але, часто, вічно і не треба, правда).
    Та й не допоможе воно, скоріш всього.

    мускуль взагалі хєровенька бд

    Але, схоже, друга за популярністю в світі (www.statista.com/...​abase-management-systems). Хоча в моїй «бульбашці» — перша, а за нею mongodb.

    Можливо, у ваших задачах, це все сенсу немає і у вас база до 1Gb, де саме оці всі «графові записи» тільки і треба робити і вся складність там. В мене такої задачі на Java не було. Update, зазвичай, одна таблиця (+, можливо, якісь «логи»).

  • Еволюція Spring бінів

    В нас, напевно, дійсно, таки різний досвід.

    Самописний фреймворк ... в моєму випадку, це, вважайте, що пряма робота з JDBC, але без boilerplate-а і з мапером. Ті частини, які покриті тестами, тестуються з mock-базою.
    Але, оскільки, для моделей використовуються прості data-класи (без parent-a, public поля, тощо), то код, який залежить від них, але не пише/читає базу, можна природнім чином відокремлювати і запускати/тестувати без бази. Не завжди так виходить ... crud так не виходить, але все ж.

    model.updateBy(change)

    Я вірно розумію, що change — у вас є чимось схожеми на паттен Command, тільки без undo?
    Якщо так, тоді стає зрозуміліше, чому вам підійшов hibernate :)

    З мого досвіду, пригадую проект, який, для спрощення, скажем, продавав квитки на вистави (там було не лише це, але все ж).
    База MySql — не те, щоб багато могла пробачити. І коли кількість транзакцій доходила до однієї в декілька секунд (транзакція — це багатоетапний процес — багато запитів на різні шлюзи/бази/тощо), починалися проблеми — база просто не витягувала.

    MySql, схоже лочить записи в таблиці не по рядкам, а по блокам рядків, і тому легко попасти на deadlock (редагуючі різні записи) і потрібно робити retry.

    Вирішилось все тим, що в транзакціях залишали лише те, що необхідно має бути атомарним (зазвичай 1-2-3 update/insert-а), частину запитів «закешували», майже всі select-и поза транзакціями, а деякі навіть з хаками аля FORCE INDEX (не те, що це добре, але все ж). Консистентність деяких речей почала базуватися на логіці виконання операції, а не на транзакціях. Наприклад, треба зробити A, B та C. Стараємось зробити A та B ідемпотентними, а C в транзакції — відповідно, якщо C злетить і буде retry, то повтор A та B не призведе до проблеми.

    Я намагаюсь уявити подібну роботу на hibernate і розумію, що посивіти можна раніше, ніж розвантажити базу.

    Які у вас типові задачі, що hibernate так гарно заходить? Які навантаження?

  • Еволюція Spring бінів

    Воно працює так, але трохи не так. Код генерується, але не так як з SOAP колись :)
    Генерація коду відбувається на етапі компіляції, цей процес інтегрується в maven/gradle.
    Тобто немає жодного натяку чи шансу його потім правити руками.

    Тобто, вам ніколи, толком, туди лізти не треба.

    Але при цьому, весь DI чесний та прозорий, без магії аля доступу до private полів, генерування проксі класів, які існують лише в runtime, тощо. Коли вивалюється stacktrace, там все чітко і зрозуміло. Ви можете дебагером пройти крізь якийсь Provider, якщо треба, і в IDE не «зламається мозок»: ви очевидним чином дебагером зайдете в згенерований код, побачите як, в якому порядку і звідки відбувся inject і пройдете до провайдера з проблемою ... як кажуть, «без розривів».

    Мені складно знайти випадок, коли це є мінусом. Розмір проекту значення не має.

    Якщо ви шукаєте мінуси, знайти їх можна. Є випадки, коли guava (думаю, що spring теж, але важко сказати), можуть за-inject-ити так, як dagger не зможе. Reflection, таки, сила + ці бібліотеки, часом «переписують» код класів в runtime. Dagger цього не робить, але тут вже питання добре це чи погано розраховувати на такі фічі.

  • Еволюція Spring бінів

    Важливо не лише startup time. Dagger працює як генератор коду, який, хоч і не витвір мистецтва, але можеа читати, коли треба.

    IDE його підтягує і працює навігація по коду.

    Купа помилок перейдуть з run time в compile time.

    Стектрейси, які проходять через DI є відносно нормальними.

    Всі зв’язування відбуваються в compile time, що не завжди лише startup.

    Підтримав: Valeriy Shvets
  • Еволюція Spring бінів

    Стосовно DI, написав в сусідньому коментарі: використовуєм dagger.

    І головна фіча Хібернейта

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

    Якщо робиться update до бази, то в коді недвузначним і очевидним чином має бути видно що саме оновлюється і як (які таблиці і які поля). А у вашому випадку ще й, як мінімум, select зайвий робиться.

    Якщо ж декілька таблиць — то тим більше. Має значення порядок запитів, які з них в яких транзакціях виконуються; що робити, якщо треба робити ролбек. Одна транзакція — часто достатньо, але якщо вона містить багато сутностей, дуже легко напоротись на проблеми з локами.

  • Еволюція Spring бінів

    Для DI використовую Dagger. Величезним плюсом є те, що все працює без reflection-а.

← Сtrl 123456...29 Ctrl →