Ещё как развивается. Западный белый человек создает что-то новое. Через несколько лет Китай копирует и демпингует цену. Белому человеку опять приходится придумывать что-то новое. И так по кругу.
Роли распределены очень точно. Китай не занимается разработкой, а делает только копирование и удешевление. Белый человек не занимается оптимизацией и срезанием костов т.к. это сделает Китай.
Полиция установила, что Аднан вёл образ жизни, значительно превосходящий тот, который можно было ожидать от его заявленных профессий: репетитор и водитель службы доставки Amazon.
Хорошо писать бэкенд на JS/TS, конструктор new URL() ведёт себя одинаково и в браузере, и на бэке при разборе урлов. И в разных движках (Bun vs Node/Deno).
Соц. сети уже давно отдаляются от реального мира. Трафик от ботов давно больше половины. Лучше с реальными людьми общаться или в закрытых каналах сидеть. Пока люди ещё остались)
Видел такое в реальности. Коллега сделал задачу, другой коллега провёл ревью, тестировщик протестил, и ...сидят ждут команды. На следующем daily спрашивают у ПМа: "Когда выкатывать?" и получают ответ: "Вы разве это ещё не выкатили?"
Зачем ждать отдельной команды для задачи, которая прошла ревью и тестирование?
>Если б ПМ был помогучее, он бы на гитлабе сам тыкал разрешение деплоить на прод
Очень полезно, представляю, на каждый коммит, баг, исправление опечатки в проекте ПМ такой на весь офис "Ребята, вы получаете моё отдельное разрешение деплоя на прод, вперёд к победе!"
Фреймворк для корпоратов. Там, где достаточно простых обработчиков, мы делаем 100 слоев абстракций. В компаниях, где деньги просто распределяются, это классно. А в компаниях и проектах, где важен результат с хорошим кпд, nest избыточен.
Тоже делаю проект. Технически могу сделать всё. Но большинство времени уходит на аналитику. Что собственно нужно сделать и как этот пазл сложится в общую мозаику проекта.
В найме работа с неопределенностью тоже возрастает с увеличением опыта. Если в самом начале тебе приходит понятная задача, которую нужно просто сделать. То с увеличением грейда возникают те же самые вопросы "А что это? А зачем? А какая вообще проблема? А почему сейчас так работает?"
Про разбор аналогов тоже хорошо написано. Я как раз делаю проект потому что аналоги ужасные. И приходится пользоваться их проектами, чтобы посмотреть как НЕ нужно делать. Я прям заставляю себя)
Про сроки. У меня есть знакомый сеньор, который реально сеньор, а не сеньор-помидор. Он уже 3 года делает проект. Как я не посмотрю на его проект, вроде ничего особенного. Но 3 человека-года разработки это же как-то много? На самом деле сейчас сделать минимальный проект это пол года. Самый минимум. А если у вас много сущностей и связей между ними и вы хотите, чтобы это всё работало вместе и не разваливалось, то умножайте на 5/10/100.
Сейчас я бы перефразировал - "Есть первые 90% проекта и есть вторая бесконечная часть проекта".
В молодости я думал, почему менеджеры хотят сделать первый релиз как можно быстрее. Почему они так любят MVP. Может они хотят быстрее сделать основу, а вторые 90% проекта делать уже в свободном режиме? Нееет, эта вторая часть проекта просто бесконечна и никогда не заканчивается. Поэтому какой смысл пытаться сделать сразу 100%, если это физически невозможно.
Спасибо за статью. Публичная часть fingerprinting всегда отстаёт от современных способов. Поэтому когда Mozilla меняет canvas‑изображение, а Safari внедряет шум в показания аудио‑и Canvas‑API, я понимаю, что уже появились другие методы fingerprinting-а, а старые способы просто "сливают" под соусом борьбы за приватностью.
"на работе нагрузили новыми обязанностями" - то есть какой-то рандом (в России его называют дядя) крадет ваше нерабочее время по вечерам, чтобы вы занимались каким-то бесполезным для себя делом. Но при этом полезным для этого рандома.
Ничего личного, вам не нужно делать свой проект, выполняйте приказы рандомов по вечерам и по ночам.
На практике стараются выбирать shard key так, чтобы связанные запросы поступали на один шард. То есть ситуация, когда "без данных шарда запрос другими шардами не обслужится", исключается. Падение другого шарда на них никак не влияет т.к. такие адресные запросы маршрутизируются на один конкретный шард.
Кроссшардовые аналитические запросы действительно не выполнятся, но какой процент таких запросов? Также один шард может иметь реплики, которые подхватят работу в случае падения.
Я тоже не знаю, но что хранит OpenAI в базе, но думать "Если хотя бы один шард не работает, то запрос не выполняется" - это архитектурный провал.
Почему вы считаете, что "Если хотя бы один шард не работает, то запрос не выполняется"? Если запрос затрагивает только живые шарды, то он выполнится нормально.
Ещё как развивается. Западный белый человек создает что-то новое. Через несколько лет Китай копирует и демпингует цену. Белому человеку опять приходится придумывать что-то новое. И так по кругу.
Роли распределены очень точно. Китай не занимается разработкой, а делает только копирование и удешевление. Белый человек не занимается оптимизацией и срезанием костов т.к. это сделает Китай.
Помню мой друг в детстве говорил, что книги без картинок не читает)
Теперь лавандовый раф нельзя покупать будет?
Хорошо писать бэкенд на JS/TS, конструктор new URL() ведёт себя одинаково и в браузере, и на бэке при разборе урлов. И в разных движках (Bun vs Node/Deno).
Ребята, с которыми я общался в универе или на работах, были норм челами, поэтому...
Соц. сети уже давно отдаляются от реального мира. Трафик от ботов давно больше половины. Лучше с реальными людьми общаться или в закрытых каналах сидеть. Пока люди ещё остались)
Видел такое в реальности. Коллега сделал задачу, другой коллега провёл ревью, тестировщик протестил, и ...сидят ждут команды. На следующем 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 в базе, но думать
"Если хотя бы один шард не работает, то запрос не выполняется" - это архитектурный провал.
Почему вы считаете, что "Если хотя бы один шард не работает, то запрос не выполняется"?
Если запрос затрагивает только живые шарды, то он выполнится нормально.