There are 999 reasons to become levi niner. Find yours at levi9.com/jobs
×Закрыть

Уйти нельзя остаться

Всем привет. Возможно кто-то с таким сталкивался, прошу ответить на ряд вопросов:

Входные данные:
Jun PHP

стаж: чуть больше года

С наибольших достижений — могу развести процесс в мультипоточность, и не отвалить их.

Последний месяц на работе не то, что ничего не клеится, а именно НИЧЕГО. Всё, чтобы не делал, получается слишком медленно, и порой вылазЮт неприятные баги.

Сначала не предавал этому особого внимания, ведь лучше факапа, только 2 факапа, но в последнее время нервишки начинают сдавать конкретно.

Мне не всё равно на свой проф. уровень. Занимаюсь регулярно, но написанное выше на работе доходит до того, что
1) страшно кодить, тк каждое решение и каждая строка — кусок говна
2) стыдно. Очень стыдно. Особенно перед ПМ и тимлидом.
Перед лидом, потому что у него в подчинении такой манки-кодер, перед ПМ, потому что дедлайн последних заданий срывается стабильно на 3-4 дня.
Через пару дней ЗП, как для меня приличная 10-15к(НДА, выберите любую цифру из диапазона), но после каждого следующего косяка, чуствую, что надо бы за такое скинуть зп до половины.
Постоянно в стресе, постоянно стыдно за любой шаг, но никто палкой с фирмы не гонит.
Сам работаю почти всё время с Yii2, в свободное время немного расшарился с Symf.
Если и переходить, то явно не с Yii2 в Yii2.
Вопрос 1: Что лучше: плюнуть на всё, и уйти с работы, или остаться, и что-то порешать здес?
Вопрос 2: нужны ли фирмам разрабы, которые знают тот же Yii, и слабы в Symf/Lara? Ведь перейти на новый фреймворк — максимум неделя.
Я не могу обратится к друзьям, потому что часть из них слишком уважаемая, чтобы втягивать их в подобный мусор, часть торчки.

Upd 10.07 Спасибо за советы, и подсказки. Как раз этого и не хватало. Прошу прощение, если пост получился в стиле «супер нытье». В момент его написания всё было действительно очень плохо.

Отдельно персонально спасибо:

  • Konstantin Strukov
  • Sergey Lysak
  • Павлік
По общему совету со следующей недели беру отпуск на 10 рабочих дней.

Ещё раз спасибо, буду ещё более качественно развиватся, и работать над своим психосостоянием.

Надеюсь, это начало happy end-a
LinkedIn

Лучшие комментарии пропустить

Перед лидом, потому что у него в подчинении такой манки-кодер, перед ПМ, потому что дедлайн последних заданий срывается стабильно на 3-4 дня.
Через пару дней ЗП, как для меня приличная 10-15к(НДА, выберите любую цифру из диапазона), но после каждого следующего косяка, чуствую, что надо бы за такое скинуть зп до половины.
Постоянно в стресе, постоянно стыдно за любой шаг, но никто палкой с фирмы не гонит.

Ну и набредил ты.

Во-первых, не ошибается тот, кто ничего не делает.
Во-вторых, для разраба, а тем более джуна нормально ставить сильно оптимистичные оценки сроков, учесть это задача менеджера.
Третье, с какого бодуна снижать тебе зарплату, если ты работаешь в рамках своих возможностей. А вот задача менеджера просто учитывать твои возможности и получать от тебя максимум работы в рамках твоих возможностей.

Так, что перестань быть инфантильным ребенком и просто работай, как работаешь, учись и старайся. И забудь об подобном бредовом стрессе — это исключительно твоя подростковая дурь.

взять 2 недели отпуска отдохнуть от компа.
собрать бюджет на пару месяцев поиска работы, если уволят
после отпуска продолжить разбираться в причинах проблемы — из-за нервов, или проект такой, или кармой накрыло, или руки кривые.

Так это же нормально. Ты дошел до стадии критического осмысления действительности. Следующее что тебе надо сделать это
1. таки перестать так сильно волноваться
2. ну и таки подумать «а что б такого сделать что бы количество и северити факапов уменьшить».
Это всего лишь нормальный этап развития и твоя дорожка к профессиональному росту.

От тимлида фидбек есть по этим всем факапам? И если есть, то какой?

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

****ш дальше. все получится. это нормальный процесс. проси ревьювить код и указывать на огрехи. 1 год стажа — не тот срок на котором будешь хороший код писать

1) страшно кодить, тк каждое решение и каждая строка — кусок говна
2) стыдно. Очень стыдно. Особенно перед ПМ и тимлидом.

Это нормально. У вас код-ревью на проекте есть?
Тимлид или кто-нибудь старший менторит тебя?

стаж: чуть больше года

И это нормально. Инженер в профессии взрослеет 7 лет.

потому что дедлайн последних заданий срывается стабильно на 3-4 дня.

А как у остальных в команде? Может там дедлайны кто-то дикие выставляет.

Что лучше: плюнуть на всё, и уйти с работы, или остаться,

Не сдавайся.

Я не могу обратится к друзьям, потому что часть из них слишком уважаемая, чтобы втягивать их в подобный мусор

Это точно друзья?

часть торчки.

А с этими зачем дружить?

1) dou.ua/...​rums/topic/27755/#1620920
2) ну, так мб совпало, что у меня солидная часть друзей(3 из 4) солидная(начальники в своих отделах, или просто челики с доходом 1к$+). С другой стороны чел, который получает их недельную ЗП. Не уверен, что столь высоких людей можно таким как я грузить, в остальном проблем нет, отпИвание никто не отменял)

челики с доходом 1к$+

Не знав що свіжоспечені мідли це солідні люди

начальники в своих отделах, или просто челики с доходом 1к$+)

Ох и важная колбаса, прям не подступишься :D

Вопрос 2: нужны ли фирмам разрабы, которые знают тот же Yii, и слабы в Symf/Lara?

Как недавно искавшие бекендера на Yii2 по всему СНГ могу сказать что — есть :)

на основании собеседований типичная печальная картина
— слабое знание языка программирования php. такие вот чудеса — код пишет, а языка не знает :)
— незнание, непонимание идеологии Yii2 несмотря на стаж работы с ним. кажется по причине что работа была как с Wordpress — добавил расширение, сгенерил код Gii — и опа, «шеф, все готово!»
— никакие, то есть полностью нулевые знания SQL. перефразируя насмешки над соискателями знакомых фронтендщиков «jQuery да, знаю. JavaScript... слышал конечно, но не пользовался» —
«ActiveQuery да, знаю. SQL... слышал конечно, но не пользовался.»

И поэтому вот это:

Ведь перейти на новый фреймворк — максимум неделя.

боооольшой самообман.
если год и больше работы с одним фреймворком не превращаются сами по себе в его знание, то уж на новый за неделю перейти? уверены что сможете?

Если речь о Symfony то там требования к знанию языка программирования php будут еще жестче.
Ларка да, с Yii2 на нее лечге перейти, чем на Symfony

но за неделю перейти...

ну, если там не дебри с выяснением, как устроена токенизация в конкретном инструменте, то собес как собес.
Про переход: я не говорил перейти аки ас. Перейти — понять как сделать банальный crud, и понять, как устроенна внутренняя архитектура. Для этого недели вполне достаточно

Для этого недели вполне достаточно

ну вам конечно видней.
не мне с моими 20+ годами в программировании давать вам советы
у вас стаж пока круче моего :D

Простите, я не хотел хамить. Это сугубо с собственного жизненнорго опыта взята цифра и величина углубления

я и не воспринимаю это как хамство :)

это естественно для джуна, не понимать шутки о
«Изучи С++ за 21 день»

Это сугубо с собственного жизненнорго опыта

да, именно это я и признаю
что у вас жизненного опыта больше чем у меня.
пока больше.

потом, если будете правильно развиваться — поймете :)

все нормально.

«Сам придумав, сам переймаюся»

Всё, чтобы не делал, получается слишком медленно, и порой вылазЮт неприятные баги.

Слишком медленно по сравнению с чем?
Бывали такие компании, в которых тебе лид с потолка говорил когда должно быть готово, и это действительно может ввести в состояние боязни провала новичков.

Все-таки сколько не критиковали Agile, а счастливы те, кто работает по нему. По крайней мере там я могу сам нарисовать себе effort time и аргументировать и лиду и кому угодно почему так, если будут вопросы

в среднем, на таску, которуя я раньше ещё не делал(не банальный crud) уходит 0,5-2 дня. Одну из своих тасок я так же, на глаз накинул «максимум дня 3». Как бы не так, сидел дней 8, пока она дошла до уровня, что не стыдно показать.
Agile нет, только таск трекер

Перед лидом, потому что у него в подчинении такой манки-кодер, перед ПМ, потому что дедлайн последних заданий срывается стабильно на 3-4 дня.
Через пару дней ЗП, как для меня приличная 10-15к(НДА, выберите любую цифру из диапазона), но после каждого следующего косяка, чуствую, что надо бы за такое скинуть зп до половины.
Постоянно в стресе, постоянно стыдно за любой шаг, но никто палкой с фирмы не гонит.

Ну и набредил ты.

Во-первых, не ошибается тот, кто ничего не делает.
Во-вторых, для разраба, а тем более джуна нормально ставить сильно оптимистичные оценки сроков, учесть это задача менеджера.
Третье, с какого бодуна снижать тебе зарплату, если ты работаешь в рамках своих возможностей. А вот задача менеджера просто учитывать твои возможности и получать от тебя максимум работы в рамках твоих возможностей.

Так, что перестань быть инфантильным ребенком и просто работай, как работаешь, учись и старайся. И забудь об подобном бредовом стрессе — это исключительно твоя подростковая дурь.

Вопрос 1: Что лучше: плюнуть на всё, и уйти с работы, или остаться, и что-то порешать здес?

Уйти с работы куда? Если на другую работу, то весьма вероятно, что проблемы пойдут следом. Переформулируй проблему в задачу и реши её.

Вопрос 2: нужны ли фирмам разрабы, которые знают тот же Yii, и слабы в Symf/Lara? Ведь перейти на новый фреймворк — максимум неделя.

Ответ — фирмам нужны разработчики. Насчет недели на фреймворк... Спишем на джунство.

Простите, скорее всего мы недопоняли друг друга в плане изучения фрейма. Для меня это понятие включает в себя понимание того, как банально накатить круд, и немного базовой архитектуры. Тоесть не мастер с настройками всего и вся, а уже хотя бы со знаниями, достаточными, чтобы сделать тестовое задание как на первую работу

ще в тему
dou.ua/forums/topic/27782
я техлид 31 год, есть семья, зп в пару сотен не дотягивающая до 5к (овертаймами дотягивающая, конечно, но это не считается). Опыт в отрасли 10 лет как раз в этом году, профильный вуз миллионника за плечами, есть семья и небольшой спиногрыз. Есть довольно большая квартира в центре областного центра, машина дискавери трехлетка, объездил многие страны, короче я на той вершине, которую продают неофитам курсы, другие разрабы и наконец галеры с ДОУ. И я хочу выпилиться.

Дам не хочет он, просто тупо троллит.

Хочет-хочет. А когда это случится [с помощью членов команды], будет чёткое доказательство что сам, что хотел, что страдал и маялся бедолага.

Во Львове кто-то застрелился, так членов команды вызывали на допрос.

стаж: чуть больше года

стаж 20 років, всє сімтоми на літцо ©....

1) страшно кодить, тк каждое решение и каждая строка — кусок говна
2) стыдно. Очень стыдно. Особенно

іногда хочєццо бросіть прохфесію, по понімаю, шо больше нічєго нє умєю.

Вопрос 1: Что лучше: плюнуть на всё, и уйти с работы, или остаться, и что-то порешать здес?
Вопрос 2: нужны ли фирмам разрабы, которые знают тот же Yii, и слабы в Symf/Lara? Ведь перейти на новый фреймворк — максимум неделя.

мой совєт... зарабатуй первий лімон $$$ та свалюй з йопаного ойті подальше

выглядит как «комплекс студента», скорее всего внешне принесенный (любят у нас в такое загнать) хотя может и свой собственный, вырощенный так сказать изнутри

если внеший — ну там пм ставит дурные сроки, лид постоянно находит новые и новые «проблемы» — то учится отбиваться и-или ростить self esteem например , углубляя знания
если внутрениий, то тоже самое, плюс наверное немного agile — как минимум исходить из знания, что любой код рождается дерьмом и только эволюция, ревью и тесты с релизами делают что то более менее удачное (и то не всегда)
ну и читать про антипаттерны, analysis paralysis даже опытных накрывает иногда

п.с. ну и наверное yii не лучший фреймворк, сталкивался с yii1 — он меня в депрессию вгонял неудобством и словоблудием в простых вещах

мен, это же хорошо) хуже было бы, абы ты бездумно кодил «на синтаксисе», вообще не думая, изредка доучивая новые операторы или конструкции, если тебе свой код не нравится — это нормально)
а если не знаешь, как код писать — ну уже давно же мудрые люди сказали — или пиши максимально просто или первый пришедший в голову вариант. Дальше впрягается принцип 80/20 — если есть что-то неидеальное, но рабочее, то это на 80% то, что нужно было.
«Работает? — Не трогай», это вот тебе ещё со стороны админов привет.
что делать? — а почему бы и не перейти с Юи2 на Юи2? Как раз может будет тот же фреймворк, но для других задач, проектов, другой обвес, другие апи, возможно, наоборот полезно будет посмотреть с другой стороны.

И всё? Поздравляю, пик Даннинга-Крюгера пройден. Утраивай дозу кофе, и начинай учить теперь уже по-настоящему.

Тебе сказать на чём основной тупик? Протупить с индексами на базе данных. Вот тут уж будет реально медленно. А то что у тебя медленно код пишется — так привыкай, ты ж не думал что тут всё простенько работает и нам денег за так платят? В том-то и дело, что всё что написано «для программистов» — работает ЧЕРЕЗ ЖОПУ, потому что считается что вы сами можете всё доделать, допилить, найти как обойти грабельки, и т.д, и т.п, и вообще не борзейте рабы и гребите.

Кстати, я на PHP по сей день не умею разводить процесс в мультипоточность. Разумеется если речь не идёт о запуске процессов внутри операционки, то там с мультипотоком вообще задница — удержать это всё в рамках HighLoad лимитов. А вот в пэхе... я не встречал вменяемого способа засыпания потоков, чтобы потом за ними следить, и соответственно отстреливать, мусор убирать... мне всю жизнь казалось что на PHP сие вообще табу, демонов-то рожать.

ахах, да согласен с вами, был такой опыт)))
кофа с сахаром?

А чё, уже легализовали? Я конечно только за, но на работе ну нах, код на PHP и без того жуть.

С цикламатом. С сахаром двойной эспрессо из робусты не выпьешь :)

Протупить с индексами на базе данных. Вот тут уж будет реально медленно.

Какое медленно?! В сральник выебут под крики ааааа ебать все горит причем очень быстро.

Поверь, я встречал базы с таблицами на десятки миллионов строк и неиндексными сканированиями. Думаешь выипали? Ага, жди. Наклонировали «решения» на несколько проектов, и удивлялись почему расходы на хостинг растут и третий раз переезжать приходится.

Фулскан на десятки миллионов строк? Ну такое бывает, если действительно втыканули запилить индекс, но он же работать будет бесконечность. Если это массовая операция она банально выжрет ресурсы цпу очень быстро и база начнет бросать в приложение таймауты.

Ага. И так полтора года. И вынуждены были брать сервак, у которого вся таблица целиком в оперативу помещается. А веселее всего то, что там каждый третий запрос — INSERT.

Когда я допилил эту гадость, у меня что-то около 10000 строк эта табличка занимала, с ежесуточным скриптом обслуживания. В дальнейшем избавились и от неё. А запрашиваемое поле, внезапно, оказалось Primary key — автор предыдущей версии вообще не знал что это такое, и везде лепил автогенерируемое поле для этой цели.

Зато тесты проходили на ура, никто там не парился за время.

я обычно говорю — спасибо мужикам, если бы не они, у меня и не было бы работы с 2х-4х рейтом

У меня сейчас в проекте таблички около 100м каждая(partion естественно).
Так mysql без force index иногда делает full scan, причем случайно. Пришлось гвоздями прибивать.
А postgres не справляется с входящим потоком insert/update(другой механизм транзакций).
Бывает по всякому.

А в чём вообще сакральный смысл partition делать? Я насколько слышу, то механизм сырой, то есть самое вкусненькое из него не достать — а именно, нет быстрой оптимизации этих самых партиций в процессе регулярного обслуживания. И я бы не стал утверждать что это технически достижимо без миллионов обсуждений, никуда не приводящих.

На частые insert я давно уже ложил болт, благо есть TokuDB движок и он хер знает сколько лет как стабилен. Правда ForeignKey к нему так и не прекрутили, честно не пойму почему, видать гонка за показателями. Правда это тот самый случай, когда убедился на собственном опыте в малой бесполезности подобных ограничений на уровне базы — не более чем священная корова, которую давно пора было зарезать.

Так что мой совет, накинь TokuDB на тестовую базу, убедись что работает. Только маленькое предупреждение: TokuDB делит индекс на множество файлов. И если таких таблиц много, может понадобиться поменять стандартный лимит на открытие одновременно большого количества файлов. По дефолту Мускул ставит 1024. И как только ты хочешь слить дамп, он пытается открыть все индексы сразу, и в этот лимит упирается. Нахер он там вообще нужен сказать не могу, тоже видать священная телятина.

Смысл есть.
У меня основная нагрузка — update по primary key
если сделать по нему partition например по mod 10 и запустить 10 отдельных потоков выбирающих из rabbitmq данные, то производительность базы увеличивается приблизительно в 9 раз.
Просто каждый из потоков не трогает индексы другого потока.

У меня mariadb. В ней tokudb вроде obsolete и индексы и так делятся. Но все равно partition работает сильно быстрее, чем поделенный индекс.

Обслуживание выполняется кусочками по 5к primary key, отдельно и в ночное время.
Активный сет используемый в течении часа — 30-40m записей. Там особо ничего не придумаешь. Либо вынести его кусками в отдельные таблицы, либо partition. В памяти даже приблизительно не помещается, доступ практически случайный.

Основная нагрузка-то не апдейт поля, а апдейт индексов. И вот что-то мне с трудом верится, что ВСЕ индексы тоже раздельные по партишенам. Тогда при селекте запрос должен лететь на все 10 индексов??

Так и есть. фактически это отдельные таблицы с отдельными индексами и выполняется union. Если у вас в запросе не фигирирует partition key. Если он есть(а в данном случае он есть), то по partition key выполняется поиск таблицы, потом выполняется в ней запрос.
Естественно, не должно быть апдейтов на partitin key, это вызывает delete/insert в другую таблицу.

АГА, ДОШЛО. То есть индекс всё-таки ЕСТЬ, и partition key желательно прямо подсовывать в запросе? ИЛИ ЖЕ достаточно условия в условии WHERE и он сам подхватит ключ?

Ну с апдейтами как раз понятно, они теоретически допустимы (это радует), но в продакшене это не должно быть частых запросов. Ну что ж, тогда кошерный механизм, надо воспользоваться. Потому что раньше приходилось делать то ж самое вручную.

А так, типичный случай: 2 партишена, в первом со старыми данными изменения маловероятны, а во втором, новом — много счастья по инсертам и апдейтам. И соответственно ночью прокатать апдейт формального поля, по которому они делились. Потому что ALTER TABLE просто ради переброски данных боюсь будет весьма затратен, и всё-таки это TABLE LOCK.

Есть хеш-функция которая по partition key выдает табличку. Если в вашем запросе есть partition field, то будет выбраны только те таблички, которые подходят. Если нет — выполнится по всем. Он сам анализирует, вам не надо менять запросы.
А дальше как в обычное innodb c innodb_file_per_table — индексы в каждой таблице отдельные и свои.
Фактически это автоматическая подстановка имени таблицы.
Insert без partition_field, естественно, невозможен. Всунет в ту таблицу, которая подходит под условие разделения/хеш функцию.
А если по запросу вы не можете выяснить partition, то будет выборка по всем и union, но это все равно в большинстве случаев быстрее, ибо каждый конкретный индекс в малой табличке обходится быстрее. У вас получается K *log(N/K), тоесть вроде как больше в теории, но по сути меньше на практике, ибо меньше требования к нужной для обхода памяти — меньше тянуть в ядро. Если и на практике дольше — значит неправильно выбрали partition key.

у меня в продакшене на каждые 5 апдейтов одна операция другого типа. потому и не катит постгрес. По разному бывает.
Если у вас вероятность запроса по последней partition больше — то только ее ключи будут в памяти целиком.

непонятно зачем ночью чтото прокатывать. если у вас данные разделения не серийные, у вас просто будет на 10 таблиц их псевдо-случайно раскидывать.

Update по partition key выполняться вообще не должен никогда. Это будет эквивалентно delete+insert.

Партиции ещё очень удобны для всяких логов и прочих данных которые нужно постоянно чистить. Когда в день добавляется 10М+ записей, а хранить нужно, например, за последнюю неделю или 30 дней.

Простой delete и работать будет не быстро даже по индексу, и место только помечается свободным, дефрагментация таблицы.
А truncate partition идеальное решение в этом случае — быстро, ничего не лочится кроме очищаемой партиции и место сразу освобождается.

Не знал за truncate partition. Интересная опция.

А насчёт простого delete я бы не был так уверен, что он сильно медленный. Пойми правильно, фрагментация для таблиц как бы в принципе не страшна. Но вот перестройка индекса — таки да, мерзость. А уж если репликация подвязалась...

Убивает документация об этих самых партициях — никакой логики в объяснении особенностей индексирования, хер пойми какие последствия вылезут на селекте. Я так понимаю, что партиции на таблице вызывают партицию индекса, и соответственно уже SELECT будет тупить, опрашивая не 1 скажем индекс, а 30 за раз. Так ли это?

К тому же я не нашёл механизма автосоздания партиций. Самому надо писать ALTER TABLE в цикле обслуживания, имея тормоза всей сопутствующей перестройкой индексов?

Delete реально очень не быстро работает, когда например из таблицы в 200М+ записей нужно удалить скажем 30М. А так затранкейтил партицию(и) и всё очень быстро.

Партиции физически хранятся в отдельных файлах. В идеале при выборках конечно лучше если в условии есть ключ партиционирования, но и без этого выборки по другим ключам быстро работают, хотя замеры специально не делал.

По поводу обслуживания, здесь уже зависит от того что нужно в конкретной задаче, так как видов разбиения есть несколько. Если партиция — это дата, то нужно самому следить, но просто добавление новой быстрая операция. Я чаще их использую по типу capped collections из монги — 31 или 12 партиция по количеству дней в месяце или месяцев в году и для быстрой подчистки старых данных.

Нуу, Монго совсем другой разговор, она родилась уже с идеей сплайса. А вот для жёстко структурированной таблицы... весьма ограниченная зона применения.

Монго фигня. Попробуйте aerospike :) Реально задержки 1-5мс, а у монго — до 200-300.

Простой delete в таблице 100м+ выполняется по 1 секунде на каждые 5к записей.
У меня даже скриптик есть, который удаляет записи из таблицы подбирая окно удаления так, чтоб выполнение не превышало 1секунды.
А если оно превышает, то репликация(даже многопоточная) ждет выполнения запроса.
Вот удаляете вы 1млн записей, это гдето 200секунд в лучшем случае. У вас репликация уходит на 200секунд±.

Это как раз понятно, преимущества железобетонны.

А вот INSERT так понимаю трогает ВСЕ индексы как минимум на чтение. Апдейт тем более.

Я бы понял, ЕСЛИ БЫ разделение на партиции шло ИСКЛЮЧИТЕЛЬНО по индексу, по ОБЩЕМУ разумеется индексу, вероятно тоже разделённому [не факт, должны быть обе опции], но имеющему общую часть. Но внеиндексное деление — это адище, с которым ни один оптимизатор не справится.

Как результат, ВСЕ индексы должны быть хорошо так кешированы, и эта дрянь может откушать нехило оперативы. Я понимаю, что есть задачи, где так и должно быть. Но это явно не логирование, где рассчитывали честно складывать в кучку и не думать лишнего.

База данных это не таблицы. Это индексы и ещё раз индексы, и только скорость их работы на самом деле критична. ИЛИ ЖЕ возможны костыли, где в вопросах INSERT ты можешь прямо тыкать рылом в партицию (хинт или форс)? Хотя опять же, всё равно костыли.

Я не понимаю ПОЧЕМУ нельзя резать данные по ключам, в смысле по первому полю любого ключа? Этого предостережения в документации я не понимаю, как при этом теряется преимущество, и что с этим не так? Или уже починили? Предполагаю что процедура проверки уникальности как-то тупит, но это только догадки.

Неа, инсерт тоже выполнятеся в ту partition, которая подходит по partition index. а дальше индексы в каждой независимы.
Там не так. Там есть функция — хеш(или четко заданная вами функция) которая не трогая индекса по вашему значению выясняет, в какую partition данный запрос идет. Если не выясняет — выполняет по всем и делает union.
Вы не правы про логирование. У вас в оперативку подгружается только используемый индекс. Для логирования это индекс в ПОСЛЕДНЕМ partition. Простейший случай — по дате добавления на каждые Х дней(unixtimestamp/(60*60*24*X)).
По ключам автоматом(без partition) нельзя, ибо неизвестно базе какое расстояние между значениями ключа у вас в таблице.

Да, костыль в виде запроса вместо таблицы по partition есть, он его нет смысла применять обычно. Планнер работает четко в данном случае.

В принципе понятно, спасибо за консультацию, попробую как сие шустрит для моих типичных задач.

Думаешь выипали?

Закешировать!
и на беке
и Варниш поставить!
и все дела :)

ооооо, знакомая песня, почему-то разрабы стремятся везде кэш воткнуть вместо того чтобы посмотреть планы и статистики базы

Особенно весело когда этот кеш настраивать не умеют.

бггг, одну кучку говна подпереть другой кучкой.
сам так сделал как-то, стыдно вспоминать.

одну кучку говна подпереть другой кучкой

скорее аккуратно подсыпать штоп не сильно протекала ))

что-то мне подсказывает, что конторка твоя неоч. к джуну (да и иногда к мидлу, лол) обычно приставляется помидор, который ревьювит его и правильно, позитивно стимулирует расти над собой. как давно бывший джун, которого беспощадно ревьювили и как помидор, который сейчас сам ревьювит, ответсвенно заявляю, что это работает.

по поводу «перейти на новый фреймворк — максимум неделя» в случае yii -> smf не сработает, я вот прямо сейчас в очень большом и серьезном © проекте вижу мидлов / синьоров yii / lrv -> smf, которые долго и упорно не могут понять, что entity — это не active record, и никакую логику туда лепить низзя.

ощущать себя г*ном и дебилом — это норма ©. я лично проходил такой же точно этап. все проходили. пока не гонят с конторы — работай. погонят — ищи контору в первую очередь такую, где в обязательном порядке делают код ревью.

книжки и курсы всякие — это хорошо, но практика — наше все. попробуй ради прикола написать свой контейнер, с тестами к нему. еще одним способом начать лучше писать на пехепе может стать... изучение еще одного языка (только не js).

и это, завязывай с установкой

что часть из них слишком уважаемая

то, что они важно надувают щеки или занимают высокие должности не делает их существами высшего порядка; скажу даже больше — возможно, вся эта недосягаемая уважаемость у тебя в воображении — ты возьми да и спроси, может они и помогут. чего ты боишься? you only live once.

что entity — это не active record

и тут про анемичные модели гг

ну, какбы , ORM vs AR, странно, вроде бы идея проста как 5 копеек, как/что/кчему, всё ж в самой Doctrine написано. Единственное, всё таки нужны люди на вакансии(по вашему мнению), которые разобрались в одном фрейме, и паралельно изучают другой?

ну, какбы , ORM vs AR, странно, вроде бы идея проста как 5 копеек, как/что/кчему, всё ж в самой Doctrine написано.

знание идеи на уровне — поговорить за пивом или на форуме, редко коррелирует с навыком правильного применения этой идеи
Doctrine/Hibernate требуют на практике очень другого подхода в применении, чем AR.
Можно даже сказать что AR учит плохому.

на практике, народ и AR плохо умеет готовить, и хорошо если понимает в конце концов, и пишет честные статьи на хабре
«Почему разработка на Yii2 превращается в ад»

ну а тот кто считает что все просто — пока и не работал вообще :)
ни с AR/Eloquent ни с Doctrine/Hibernate
поэтому ему и все просто — кажется :)

— На проекті є code review?
— Тести пишуться?
— Задачі достатньо типові чи здаються вам непідйомними?
— Отримуєте від ліда зворотній зв’язок: що було зроблено не так і як можна було зробити задачу «правильно»?
— чи велика у вас команда? Чи часто звучить слово «факап» на мітингах/ретроспективах?

1) dou.ua/...​rums/topic/27755/#1620914
2) Да, но по большим праздникам. Сейчас и без них хватает работы
3) Постоянно поднимаются
4) Если только сам подойду, с предложением «я написал решение, но, кажется мне, что это дичь, и можно было попроще/получше, но при этом, пока что не понимаю, где именно моя „гениальная идея“ дала трещину»
5) было 3 разраба. Последний месяц 2

В такому разі якщо лід не слідкує за якістю коду на етапі коли це ще може бути «дешево» виправлено, а ПМ не бачить в цьому проблем, то проблема не в вас, як мінімум не повністю в вас.

Якби у вас була команда чоловік 10-15, то можна було б припустити, що банально на вас може не вистачити часу. Можливо тім-лід спеціально так робить щоб показати наскільки крутий і незамінний на проекті (нажаль буває і так).

Самокритика до певної міри — хороша штука. Але слід розуміти, що проект лежить не тільки на ваших плечах.

Спробуйте не дововодити ситуацію до факапів просто озвучуючи свої думки щодо виконуваної задачі — «Я використаю такий підхід тому, що я бачу в ньому такі переваги: ...». Це можна робити усно або писати коменти в таск-трекері.
Якщо заперечень і коментарів від команди немає, то реалізуєте як задумали.

было 3 разраба. Последний месяц 2

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

Да, но по большим праздникам. Сейчас и без них хватает работы

У вас нет отдельного человека для тестирования? Все очень плохо;

У нас есть тестировщик, но он мануал

Я не могу обратится к друзьям, потому что часть из них слишком уважаемая, чтобы втягивать их в подобный мусор, часть торчки.

хм. Вы нашли правильное место

Вы нашли правильное место

Угу, тут полно уважаемых торчков )

Это норма. На ошибках учатся.

Так это же нормально. Ты дошел до стадии критического осмысления действительности. Следующее что тебе надо сделать это
1. таки перестать так сильно волноваться
2. ну и таки подумать «а что б такого сделать что бы количество и северити факапов уменьшить».
Это всего лишь нормальный этап развития и твоя дорожка к профессиональному росту.

А.. да. Внизу тоже Денис хорошо пишет. В отпуск тоже надо.

Последний месяц на работе не то, что ничего не клеится, а именно НИЧЕГО.

Теперь уже выгорание не за 6 лет, а за год?
Предлагаю данный топик на рассмотрение прекрасной редакции.

24 дня для вайті
3 місяці для стати мідлом
Ще 4 для становлення сеньйором
Ще 2 піднятися до архітекта
Попрацювати 2 місяці
Створити тему «17 летний техлид: мы живём не туда, на вершине IT ничего нет, только мысли о скором выпиле»

От тимлида фидбек есть по этим всем факапам? И если есть, то какой?

хороший вопрос, ждем овтета

нихт. Код ревью проходит очень редко. В основном ревьювит когда сам вызываюсь(ну или ревьювит постоянно, но ничего не говорит(а вдруг)) )). Последние полгода(мы просили с мидлом его) на стабильный код-ревью процесс в 1/N времени мы договорится не смогли.
P.S при этом всём не могу сказать, что прям код не смотрят. Смотрят, но чаще, когда выливаем на прод,чтоб ничего там не отвалить.
P.P.S тим лид достаточно крутой, и в остальном я много чего благодаря ему усвоил

Тогда это факап тимлида. И решение внезапно меняется на УХОДИТЬ.

нихт. Код ревью проходит очень редко.
P.P.S тим лид достаточно крутой

Не. Тимлид — именно как лид — очень так себе (это если дипломатично). Возможно он и прекрасный спец, но в таком случае он просто не на своем месте в данный момент времени.

Решение одно — беги оттуда, да побыстрее.

Не, можно (да и нужно, в общем-то) попытаться сначала поговорить с тимлидом, объяснить что ты паришься по поводу своей производительности и качества кода, спросить что он по этому поводу думает и все такое. Попросить более активного и регулярного фидбека, наконец (ведь на самом деле проблема вовсе не в качестве твоей работы, а в полному отсутствии обратной связи — психология, сука такая). Может и сработает, хз. Но вероятность этого не очень велика, как мне представляется — если бы тимлид понимал важность коммуникации, он бы и сам не допустил этого вакуума в котором ты варишься. Возможно он покивает головой и на недельку-две ситуация придет в норму, но вряд ли изменения будут системными — через пару месяцев ты опять взвоешь...

Решение одно — беги оттуда, да побыстрее.

учитывая что джунов на рынке рвут на части — очень правильный совет :)

через пару месяцев ты опять взвоешь...

поиска работы, и опять не тех тимлидов :)

а если серьезно, то по фотографии лечение — бежать можно ставить только если
— тимлид мудак. вот просто очевидный мудак. не чел с своими тараканами в голове, и не очень на своем месте, а просто — мудак. — однозначно — надо сваливать
— зарплату оставили как на испытательном сроке. вечные какие-то отмазки на «вы же говорили что через месяц повысите до ...». и при этом — все больше требований перерабатывать.
— затхлость. всего — офиса, команды, технологий, бизнеса заказчика или компании. определяются просто — «нюхом» :) ее тяжело передать словами, в форуме, но острый запах «плесени» — чувствуется без подсказок.

а в остальных случаях бооольшой вопрос — стоит ли джуну — бежать со СВОИМИ проблемами в другое место, где опа — ЕГО проблемы тоже как-то никто не горит решать :)

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

Еще возможный вариант — начать читать книги по архитектуре:
* Gang of Four
* Pattern Oriented Software Architecture
* Martin Fowler
Возможно, в процессе чтения окажется, что проект настолько криво написан, что ему уже никто не поможет.
Возможно, в процессе захочется переквалифицироваться на другой язык.

ваш вариант хорош. Но, в проекте беды нет. Сами паттерны(около 50% из банды) уже или юзал, или могу с лёту накинуть код по заданной идее. Проект написан хорошо, есть места где можно улучшить, улучшаем)
Пыха сейчас слишком хороша(в свете 7.4, 8), и сменить язык просто чтобы сменить язык, — такое. Мне важнее фундаменталы,и то, как система работает в принципе.

Перестань себе накручувати, якщо є подібні думки то значить є можливість стати кращим

взять 2 недели отпуска отдохнуть от компа.
собрать бюджет на пару месяцев поиска работы, если уволят
после отпуска продолжить разбираться в причинах проблемы — из-за нервов, или проект такой, или кармой накрыло, или руки кривые.

Почти правильно. Взять 2 недели отпуска больничного и ломануться искать новую галеру.

для чого, невже до весла прикований?

Подписаться на комментарии