PHP навіть не заслужив уваги? Шкода :(
Навіть і не знаю з якого боку це 1й етап :) У мене виявився фінальним. Мав сетап в 2 моніка, геймерске зручне крісло, освітлення, тв з аудіо інсталом 7.2 (ресивер піонер та досить потужна акустика).
Потім, з переїздами довелось все починати з нуля. Знову стіл, правда 1 монік, звук, геймерський стул, підставка зручна, звук простіше за столом.
А я працюю тупо або на дивані (бо в комнаті yamaha з магнатами), або в ліжку з одним ноутом (тоді музика в навушниках). Сідаю за стіл лише коли треба 2й монітор для деяких тасок.
Ось такий даунгрейд... чи ні...
Може тому, що так краще відпочивається після важких тренувань..
Не перечитувати код? Дічь.
За собою перечитувати уважно треба. Не те що за Ботом, або ще кимось. Там х3 увага має бути
Круті подарунки: одіялко в’язане велике стилізоване з лого (прям свіжак подарунок на др), також досі юзаю одяг і павербанк, рюкзак.
Цікаво було б дізнатись, чи не було у вас проблем з реплікацією. Якщо були, як вирішувалось. Маючи однопоточну реплікацію на одну БД в мускулі при частих Update/Insert/Delete слейви тупо не встигають жерти логи і опрацьовувати. Це може бути тема ще однієї статті :)
Ну з зростанням пам’яті тут спірно. Якщо у вас order або group тепер не частині індексу, у вас буде tmp table. Разом з зростанням виконання часу запиту виростає кількість коннектів які роблять цю операцію. Народжується купа tmp таблиць в пам’яті і OOM Killer приходить. І тут виходить що не тільки довгі query, а order та group by. Звичано, пам’ять росте по описсаній вами причині. Да і запит можна класифікувати як неоптимізований ))) Але причина може стати не розробник, і не останні релізи. А реліз рік тому, і просто зростання таблиці. Оптимізатор вирішить юзати інший індекс. Шукається швидко, звичайно. Але не дуже приємна штука.
Я б у перелік причин ще додав зміну обраних індексів, якщо не юзати force index. Були цікаві історії, коли mysql вирішував не юзати індекс, або юзати інший. Там відразу починались і тупняки, і ріст конекшенів, і все що завгодно. На практиці за багато років 2 рази натрапив.
Багато описаного є в мускулі, клікхаусі, постгрес.
With в клікхаусі взагалі спасіння, коли репорти в grafana збираються.
Чого не вистачило в google big query, так це limit N by .....
А вгазалі, дякую автору. Деякі штуки взяв на примітку. Як раз останній тиждень довелось трішки big query покрутити з looker студією, замість щоденних БД і Grafana.
Цікаве питання. Це як ніби спочатку обрати викрутку, шуруповерт або молоток, навчитись ним працювати, а потім думати чи подобається і що з цим можна зробити. Ну і обирати по пораді і легкості навчання. ))
Та можна ще форками погратись і зібрати відповіді. Але тут обережно треба гратись.
Я ловив багато раз неіснуючі функції або бібліотеки. Помилкові алгоритми розрахунку в NDCG на Python, вибачення та зміни з ще більшими помилками.
Що цікаво, новий чат без історії і коректний алгоритм видало.
Я юзав саме чат ГоПоТи.
Копілот стоїть в IDE. Як в штормі так і в адроїд студії. В більшості гарно підказує та доповнює. Але інколи також може неіснуючі ф-ції генерити.
Нормальні — книги читають. Якщо вже потрапили у громадський транспорт :) у 2022му
10 лет содержания людей за счет бюджета, которого и так у страны нет совсем.
А будучи в Европе сейчас ребята без военного опыта (от них в Украине пользы 0) работают под украинскими ФОПами или вообще на полном трудовом договоре и отчисляют налоги.
Что лучше: 10 лет содержать, призвать бесполезные массы или не мешать людям работать для оплаты налогов и потом привоза заработанного в Украину?
То есть, систему тренели на исходниках с багами, которые с кучей минорных версий постоянно правятся и пополняются новыми костылями, магией и багами? Это будет почетный Senior Bug Generator.
Не буду спорить. Я его только краем глаза видел.
Но фотошоп в браузере, полагаю, тоже от десктопа очень сильно будет отличаться.
Так они VS Code выпустили. IDE в браузере
Хотелось бы «больше статьи». Не просто «не оставляйте технически долг», а если оставляете, то запилите TODO или FIXME. А почему не стоит оставлять технический долг? Пример, когда это существенно вылезет боком и т.п.
Кроме DRY еще можно рассмотреть и случаи, когда копи-паст оправдан. А то начинаются 28уровневые абстракции для избежания копи-паста одной функции )). А потом, когда один из объектов не требует эту функцию — костыли. Это из личного опыта ))) Иногда копи-паст функции (по сути, повторение себя, которое противоречит Don’t Repeat Yourself) лучше сделать, чем городить непонятно что.
На счет развития, то вообще отдельная тема. «Сделайте что-то еще» так себе совет. Минимум, нужно понимать свои пробелы и там работать. У кого-то это может быть БД, у кого-то вопросы по работе сетей, кто-то ограничился 4мя паттернами и т.п. А кому-то полезно кроме «молотка» познакомится еще с другими инструментами. Ибо «если у тебя в руках молоток, всё вокруг начинает казаться гвоздями». И потом все задачи начинают решаться только с помощью узкого круга знакомых инструментов (к примеру, логи с меткой времени в реляционку + костыли по ротации, а можно было вполне юзануть TSDB. ПыСы.: просто пример). Но в то же время с акцентом, что зоопарк технологий не стоит разводить.
И всё равно сервис временами падает и глючит. Не помогли вам ваши новые костылики и велосипедики.
Когда-то давно, что-то подобное пыталось запуститься, но что-то пошло не так. Вам желаю успехов, надеюсь все получится. Тут многое зависит от магазинов — хотят ли они вот так париться и отписывать предложения в кабинет Юзверя :)
Ну казати «зроби добре і не роби погано» для LLM це не інструкція. Людина тоже могла б захтіти переписати все під8.4-8.5, а як то старий лєгасі на старому PHP, там роботи було б більше, ніж поряд заново написати ))) Просто інструкції треба більш точні, як на мене.