Видел такое в реальности. Коллега сделал задачу, другой коллега провёл ревью, тестировщик протестил, и ...сидят ждут команды. На следующем daily спрашивают у ПМа: "Когда выкатывать?" и получают ответ: "Вы разве это ещё не выкатили?"
Зачем ждать отдельной команды для задачи, которая прошла ревью и тестирование?
>Если б ПМ был помогучее, он бы на гитлабе сам тыкал разрешение деплоить на прод
Очень полезно, представляю, на каждый коммит, баг, исправление опечатки в проекте ПМ такой на весь офис "Ребята, вы получаете моё отдельное разрешение деплоя на прод, вперёд к победе!"
Фреймворк для корпоратов. Там, где достаточно простых обработчиков, мы делаем 100 слоев абстракций. В компаниях, где деньги просто распределяются, это классно. А в компаниях и проектах, где важен результат с хорошим кпд, nest избыточен.
Тоже делаю проект. Технически могу сделать всё. Но большинство времени уходит на аналитику. Что собственно нужно сделать и как этот пазл сложится в общую мозаику проекта.
В найме работа с неопределенностью тоже возрастает с увеличением опыта. Если в самом начале тебе приходит понятная задача, которую нужно просто сделать. То с увеличением грейда возникают те же самые вопросы "А что это? А зачем? А какая вообще проблема? А почему сейчас так работает?"
Про разбор аналогов тоже хорошо написано. Я как раз делаю проект потому что аналоги ужасные. И приходится пользоваться их проектами, чтобы посмотреть как НЕ нужно делать. Я прям заставляю себя)
Про сроки. У меня есть знакомый сеньор, который реально сеньор, а не сеньор-помидор. Он уже 3 года делает проект. Как я не посмотрю на его проект, вроде ничего особенного. Но 3 человека-года разработки это же как-то много? На самом деле сейчас сделать минимальный проект это пол года. Самый минимум. А если у вас много сущностей и связей между ними и вы хотите, чтобы это всё работало вместе и не разваливалось, то умножайте на 5/10/100.
Сейчас я бы перефразировал - "Есть первые 90% проекта и есть вторая бесконечная часть проекта".
В молодости я думал, почему менеджеры хотят сделать первый релиз как можно быстрее. Почему они так любят MVP. Может они хотят быстрее сделать основу, а вторые 90% проекта делать уже в свободном режиме? Нееет, эта вторая часть проекта просто бесконечна и никогда не заканчивается. Поэтому какой смысл пытаться сделать сразу 100%, если это физически невозможно.
Спасибо за статью. Публичная часть fingerprinting всегда отстаёт от современных способов. Поэтому когда Mozilla меняет canvas‑изображение, а Safari внедряет шум в показания аудио‑и Canvas‑API, я понимаю, что уже появились другие методы fingerprinting-а, а старые способы просто "сливают" под соусом борьбы за приватностью.
"на работе нагрузили новыми обязанностями" - то есть какой-то рандом (в России его называют дядя) крадет ваше нерабочее время по вечерам, чтобы вы занимались каким-то бесполезным для себя делом. Но при этом полезным для этого рандома.
Ничего личного, вам не нужно делать свой проект, выполняйте приказы рандомов по вечерам и по ночам.
На практике стараются выбирать shard key так, чтобы связанные запросы поступали на один шард. То есть ситуация, когда "без данных шарда запрос другими шардами не обслужится", исключается. Падение другого шарда на них никак не влияет т.к. такие адресные запросы маршрутизируются на один конкретный шард.
Кроссшардовые аналитические запросы действительно не выполнятся, но какой процент таких запросов? Также один шард может иметь реплики, которые подхватят работу в случае падения.
Я тоже не знаю, но что хранит OpenAI в базе, но думать "Если хотя бы один шард не работает, то запрос не выполняется" - это архитектурный провал.
Почему вы считаете, что "Если хотя бы один шард не работает, то запрос не выполняется"? Если запрос затрагивает только живые шарды, то он выполнится нормально.
Это она по себе судит?) За всё время этого ИИ "хайпа" заметил, что люди которые говорят о замене их на ИИ: - связаны с ИИ бизнесом (косвенно или напрямую) - ничего не представляют из себя в профессиональном плане Естественно, если я в соцсетях/комментариях увижу, что человек такое писал про себя, то никогда не буду с ним работать, потому что хочу работать с профессионалами.
Вы творческий человек походу, хм-хм. Я вообще не понял, что тут написано) Почему алиас у stations это s1? Почему не s? Почему у tree нет алиаса? Если делаете алиасы то пишите их стандартно и у всех stations s tree t
Видел такое в реальности. Коллега сделал задачу, другой коллега провёл ревью, тестировщик протестил, и ...сидят ждут команды. На следующем daily спрашивают у ПМа: "Когда выкатывать?" и получают ответ: "Вы разве это ещё не выкатили?"
Зачем ждать отдельной команды для задачи, которая прошла ревью и тестирование?
>Если б ПМ был помогучее, он бы на гитлабе сам тыкал разрешение деплоить на прод
Очень полезно, представляю, на каждый коммит, баг, исправление опечатки в проекте ПМ такой на весь офис "Ребята, вы получаете моё отдельное разрешение деплоя на прод, вперёд к победе!"
А что консилиум собирать на каждый коммит?
Возможно, тут нужно открыть окно, скоро лето и будет не так душно. Может сильно помочь.
Фреймворк для корпоратов. Там, где достаточно простых обработчиков, мы делаем 100 слоев абстракций. В компаниях, где деньги просто распределяются, это классно. А в компаниях и проектах, где важен результат с хорошим кпд, nest избыточен.
Тоже делаю проект. Технически могу сделать всё. Но большинство времени уходит на аналитику. Что собственно нужно сделать и как этот пазл сложится в общую мозаику проекта.
В найме работа с неопределенностью тоже возрастает с увеличением опыта. Если в самом начале тебе приходит понятная задача, которую нужно просто сделать. То с увеличением грейда возникают те же самые вопросы "А что это? А зачем? А какая вообще проблема? А почему сейчас так работает?"
Про разбор аналогов тоже хорошо написано. Я как раз делаю проект потому что аналоги ужасные. И приходится пользоваться их проектами, чтобы посмотреть как НЕ нужно делать. Я прям заставляю себя)
Про сроки. У меня есть знакомый сеньор, который реально сеньор, а не сеньор-помидор. Он уже 3 года делает проект. Как я не посмотрю на его проект, вроде ничего особенного. Но 3 человека-года разработки это же как-то много? На самом деле сейчас сделать минимальный проект это пол года. Самый минимум. А если у вас много сущностей и связей между ними и вы хотите, чтобы это всё работало вместе и не разваливалось, то умножайте на 5/10/100.
Сейчас я бы перефразировал - "Есть первые 90% проекта и есть вторая бесконечная часть проекта".
В молодости я думал, почему менеджеры хотят сделать первый релиз как можно быстрее. Почему они так любят MVP. Может они хотят быстрее сделать основу, а вторые 90% проекта делать уже в свободном режиме? Нееет, эта вторая часть проекта просто бесконечна и никогда не заканчивается. Поэтому какой смысл пытаться сделать сразу 100%, если это физически невозможно.
Спасибо за статью. Публичная часть fingerprinting всегда отстаёт от современных способов. Поэтому когда Mozilla меняет canvas‑изображение, а Safari внедряет шум в показания аудио‑и Canvas‑API, я понимаю, что уже появились другие методы fingerprinting-а, а старые способы просто "сливают" под соусом борьбы за приватностью.
То есть вы просто сдались?
"на работе нагрузили новыми обязанностями" - то есть какой-то рандом (в России его называют дядя) крадет ваше нерабочее время по вечерам, чтобы вы занимались каким-то бесполезным для себя делом. Но при этом полезным для этого рандома.
Ничего личного, вам не нужно делать свой проект, выполняйте приказы рандомов по вечерам и по ночам.
В смысле отупения? А как же AGI с новой версии модели?
Статистическое дополнение токенов текста это ведь 100% интеллект.
Перестала сходится? То есть она когда-то сходилась?)
Это всё промт виноват! ИИ не может делать ошибки!
Ппц потеря потерь, удалились диалоги с GPT, как теперь жить
На практике стараются выбирать shard key так, чтобы связанные запросы поступали на один шард. То есть ситуация, когда "без данных шарда запрос другими шардами не обслужится", исключается. Падение другого шарда на них никак не влияет т.к. такие адресные запросы маршрутизируются на один конкретный шард.
Кроссшардовые аналитические запросы действительно не выполнятся, но какой процент таких запросов? Также один шард может иметь реплики, которые подхватят работу в случае падения.
Я тоже не знаю, но что хранит OpenAI в базе, но думать
"Если хотя бы один шард не работает, то запрос не выполняется" - это архитектурный провал.
Почему вы считаете, что "Если хотя бы один шард не работает, то запрос не выполняется"?
Если запрос затрагивает только живые шарды, то он выполнится нормально.
о5 JS виноват, ух какой
Расскажите, какую задачу вы решали 3 месяца?
Это она по себе судит?)
За всё время этого ИИ "хайпа" заметил, что люди которые говорят о замене их на ИИ:
- связаны с ИИ бизнесом (косвенно или напрямую)
- ничего не представляют из себя в профессиональном плане
Естественно, если я в соцсетях/комментариях увижу, что человек такое писал про себя, то никогда не буду с ним работать, потому что хочу работать с профессионалами.
Опять сказки про AGI через месяц, год, 5 лет. А потом будет - какое AGI? Никто никому ничего не обещал. Зато на этот AGI скинулся деньгами целый мир.
Вы творческий человек походу, хм-хм.
Я вообще не понял, что тут написано)
Почему алиас у stations это s1? Почему не s? Почему у tree нет алиаса?
Если делаете алиасы то пишите их стандартно и у всех
stations s
tree t
Когда ты берешь что-то в кавычки, это обозначает цитату. Но такой цитаты в статье нет. Кто кого хочет обмануть?