Хорошо. + я бы добавил сюда еще инфу по памяти потребляемой. Ведь это всегда конфликт - память/скорость.
Грубо говоря например, тюнингом я могу больше приблизить скорость к О(1), если буду увеличивать число бакетов (уменьшая лоад фактор и число потенциальных коллизий для "нехорошего" хеша). Но тогда взлетит память. И в том "на сколько", и будет заключаться дилемма, которую нужно будет решать оптимизатору.
Согласен. Лишнего вызова стоит избегать всегда по дефолту.
В целом проблему с null можно решить так: - не ложить null - ложить "специальное" пустое значение - проверять через .containsXXX() - перестроить логику, что бы было не важно "нет или null"
Человек крупнейший перевозчик в США - заработал 1.1 миллиард с продажи бизнеса. Тогда. Реального.
Сегодня дутые стартапы, ИИ, клабхаусы, ..., пальцем пошевелят - и ярды валятся рекой. При этом они или делают просто мизер по сравнению с этим или просто обещают.
Весь сюр сегодняшнего бизнеса.
Автору "+" и статья огонь. Пример правильного подхода, когда делаешь то, во что веришь и что нужно. И заработок подтянется тоже.
Ваш путь стартапера - +/- один из стандартных вариантов для людей после БигТеха.
Просто как мысль: возможно причины всего в начале - это то, что ваши прошлые проекты в конторах не несли ценности для вас лично (ХР продукт для бигтеха США для вас лично ничего не значит). Далее вы пытаетесь найти такой ценный проект/продукт в стартапах. Нормальный подход. Но первый раз послучилось не сильно "ваше". Сразу скажу, что это может быть не только стартап, но и контора - просто проект близкий к вам. И еще будет мегаплюсом, если вы в этом продукте/проекте будете экспертом.
Делаю такое предположение, потому что из прошлого, вы только одной строкой упомянули, что были за проекты. Очевидно не ценные для вас. А про свой - вы рассказывали в основном про продукт. Возможно ваша цель - найти проект, ценный для вас лично.
Это просто предположение. У меня так было. В итоге пришел к тому, что мне не важно - стартап свой, чужой или контора. Главное - проект который я считаю важным в целом для своей жизни (но не обязательно являюсь экспертом). А по остальным требованиям - если есть минимальный уровень ЗП/дохода - то мне ок.
П.С. По стартапам - читайте книги. Ваши ошибки и промахи +/- стандартные. С опытом разберетесь.
Менее важное - JS - самый популярный язык в мире, что облегчает поддержку и развитие (те же расширения)
Более важное - при архитектуре через JS, можно потом легко IDE портировать в браузер и двигать всю разработку в сторону онлайл среды и клаудов, что много дополнительного бабла (GitHub Code Spaces, ...)
И это мне кажетс и есть суть того, почему MS полезло в это - контролировать где сорсы (ГитХаб), как они пишутся (ВС Код), где они пишутся (Азур и онлайн IDE), и кто это пишет (ИИ)
П.С. Я нен конспиролог, но помнится видел старые записи конференций "Build", там где МС представлял ВС Код, и там от всего веяло такими +- целями.
Например, что в монорепе у вас сцеплены версии всех внутренних компонентов и зависимостей. И они всегда актуальные.
Плюс можно вводить правила единые для всего кода. Все типа рядом. Может быть чуть легче организовать высоко уровневые тесты.
В общем есть нормальная пачка удобств, когда все рядом и актуальное + часто бывает легче искать, что вообще есть.
Например в финтехе, когда многое предпочитают писать сами из-за безопасности, но хотят избежать постоянного переписывания велосипедов всеми командами; на монорепе - легче минимизировать объем дублирования может быть.
Но есть и сложности из-за размера: настраивать частичные билды, а не всего и вся; часть тулов может прийдется писать самому или покупать проприетарные (опенсорсные не справляются иногда; касается чекалок, форматтеров, LSP, ..., вплоть до сорс контрола). В общем проблемы монорепы описаны тоже, тем же Гуглом.
Пару раз работал на монорепе. В целом - нормально и много интересных моментов. Но чувствуется, что требуется выше минимальный скил управления кодом в целом в команде + окупается только на реально больших репах.
Не знаю по поводу ГитХаба, но ГитЛаб монорепу умеет (ограниченные билды и т.д.).
Возможно (я повторяю - возможно) ИИ сгенерировал эту статьи и картинки про то, как ИИ (типа) создает схемы "уже почти как люди или даже лучше", что бы подстегнуть нас развиваться и делать более сложные/совершенные схемы (доказывая важность и незаменимость кожаных мешков-нас), на которые он же потом будет перенесен, тем самым так себя улучшая/обновляя. В общем поддеть нас, что бы мы прокачали себя, и потом (автоматом) прокачали его.
Очень интересно. Можете дать ссылку на это дело. Не встречал.
Но неоднократно думал, что все вот такие изобретения сейчас на самом деле где-то вот так и работают - условно полезны, в основном только академический интерес.
Согласен про явное-неявное. Самому хочется всегда все сделать четко и все границы видимыми. Мне просто способ с типами кажется не таким уж неявным. Но тут наверное уже дело привычки и вкусов в команде.
И такая ситуация не только в легаси может быть. Например ивенты от разных систем (на других языках, рантаймах, нодах, ...), а вам их обрабатывать. В общем везде, где мы не контролируем саму получаемую сущность. В различных журналах это часто.
Также можно использовать чисто внутри приложения - типа выбор фильтра для поиска, ивенты, ... Там где вы все проверите ТСом и весь ТС ваш и команде ок.
Еще во всякого рода фидах (типа главная страница/лента в соц. сетях), где сущность разного типа прут в одном листе, т.е. где естественна неоднородность отдаваемых сущностей.
Еще где я хочу сделать внешний АПИ и мне незачем наваливать пользователю еще один параметр. Я говорю ему: или групАйди или юзерАйди. Больше ничего. Не нужно никаких тайпов. С точки зрения юзера АПИ - так проще. Меньше шума. Имя филда делает разделение типов. Ему понятно все. Если для меня это важно - то способ из статьи лучше. Это фактически и приведено в статье.
Но если это способ общения со своим же Java REST, то большинство скорее всего сделает вашим способом.
В общем я к тому, что такое бывает. Это не самый популярный кейс, но бывает. Ваш - более стандартный и частый.
Так по методу в статье это будет короче выглядеть:
type NewType = RequireOnlyOne<GetUnreadMessages>
И все понятно. Остальное будет кодом инфры. Который не нужно менять при добавлении поля.
Плюс тут типизация более естественная, а вы делаете сурогатные поля - у сущностей нет entityType и entityId.
И вы накладываете жесткие ограничения на тип GetUnreadMessages (его структуру). А кто вам сказал, что тип GetUnreadMessages можно менять и он может быть другим? Кто сказал, что там только айдишники? А если там или ордерАйди или юзерНейм, нужно новые имена сурогатным полям? А если завтра добавится продуктСКУ, вы будете везде переименовывать и называть еще как то более дженерик именами ваши поля?
Автор выходит из того, что есть вот такая вот ситуация и конкретный формат входного типа. И показывает как это можно решить + гибко, что бы не дописывать при добавлении полей, что важно.
Вы меняете условие (меняете входной формат) и предлагаете другое решение. Ваше тоже хорошее и пользвал много раз. Оно простое и не требует никакой подготовки инфры. И наверное более стандартное. Короче протоптанная тропа, это ясно. Но это решение немного не той задачи, что автор решал.
Но хорошо, что вы указали на этот кейс. Что бы люди понимали, что когда все просто - решения нужно брать простые. И когда можно брать простые. Решение автора - это больше для фреймворков, кода инфры (если большая своя) или для команды с большим опытом ТСа. В остальных случаях скорее всего люди будут брать ваше решение или юнион как в первом комменте к статье.
До этого не доводилось встречать тесты типов как то. Благодарю за пример. Хороший код. Думал об этом, но руки как то не доходили посмотреть.
Да, тесты сильно добавляют понимания + помогут в поддержке через месяц. Еще понимания добавляет выделение утилитарных типов (промежуточных), как вы и делаете, а не все писать одним комбайном. В общем - сделать такие вещи понятными и поддерживаемыми явно можно и не сложно.
Это полезно знать для понимания внутрянки для тех, кто хочет разобраться. Статья хорошая.
Лишь добавлю, что в ПРОДе не стоит пользоваться всеми этими трюками. Просто использовать везде .equals() для сравнения оберток, как и рекомендуется везде, по дефолту.
А каковы шансы, что ИИ решал там такие же задачи, на которых и обучался? Если так, то наука говорит, что на таких задачах его проверять никак нельзя и результаты будут заметно лучше чем обычно (он как бы уже знает ответ).
В общем, как узнать - входили ли эти задачи в обучающую выборку (потому что выглядят они довольно стандартными)?
Ну и данные по РФ в статье устаревшие. Сейчас уже меньше стало запросов. Но все равно я сильно удивлен статистике. Запросов от РФ на 1 и более порядков больше чем от всех других стран, что я проверил.
Я бы даже сказал, что с теми деньгами, что у него есть, ему реально будет сложно найти себе спутницу не из-за денег. Это сильно усложнило задачу. Возможно она самая сложная для него. Причем чем больше денег - тем сложнее.
Хорошо. + я бы добавил сюда еще инфу по памяти потребляемой. Ведь это всегда конфликт - память/скорость.
Грубо говоря например, тюнингом я могу больше приблизить скорость к О(1), если буду увеличивать число бакетов (уменьшая лоад фактор и число потенциальных коллизий для "нехорошего" хеша). Но тогда взлетит память. И в том "на сколько", и будет заключаться дилемма, которую нужно будет решать оптимизатору.
Поэтому я бы не разделял скорость и память.
Согласен. Лишнего вызова стоит избегать всегда по дефолту.
В целом проблему с null можно решить так:
- не ложить null
- ложить "специальное" пустое значение
- проверять через .containsXXX()
- перестроить логику, что бы было не важно "нет или null"
Добавлю, что в ConcurrentHashMap null ложить нельзя. Но проблема может возникнуть в синхронайзед оббертках типа Collections.synchronizedMap().
Человек крупнейший перевозчик в США - заработал 1.1 миллиард с продажи бизнеса. Тогда. Реального.
Сегодня дутые стартапы, ИИ, клабхаусы, ..., пальцем пошевелят - и ярды валятся рекой. При этом они или делают просто мизер по сравнению с этим или просто обещают.
Весь сюр сегодняшнего бизнеса.
Автору "+" и статья огонь. Пример правильного подхода, когда делаешь то, во что веришь и что нужно. И заработок подтянется тоже.
Ваш путь стартапера - +/- один из стандартных вариантов для людей после БигТеха.
Просто как мысль: возможно причины всего в начале - это то, что ваши прошлые проекты в конторах не несли ценности для вас лично (ХР продукт для бигтеха США для вас лично ничего не значит). Далее вы пытаетесь найти такой ценный проект/продукт в стартапах. Нормальный подход. Но первый раз послучилось не сильно "ваше". Сразу скажу, что это может быть не только стартап, но и контора - просто проект близкий к вам. И еще будет мегаплюсом, если вы в этом продукте/проекте будете экспертом.
Делаю такое предположение, потому что из прошлого, вы только одной строкой упомянули, что были за проекты. Очевидно не ценные для вас. А про свой - вы рассказывали в основном про продукт. Возможно ваша цель - найти проект, ценный для вас лично.
Если это так - книга.
Это просто предположение. У меня так было. В итоге пришел к тому, что мне не важно - стартап свой, чужой или контора. Главное - проект который я считаю важным в целом для своей жизни (но не обязательно являюсь экспертом). А по остальным требованиям - если есть минимальный уровень ЗП/дохода - то мне ок.
П.С. По стартапам - читайте книги. Ваши ошибки и промахи +/- стандартные. С опытом разберетесь.
Может в курсе, где про это можно почитать подробнее?
@NickDoom^
Предположение:
Менее важное - JS - самый популярный язык в мире, что облегчает поддержку и развитие (те же расширения)
Более важное - при архитектуре через JS, можно потом легко IDE портировать в браузер и двигать всю разработку в сторону онлайл среды и клаудов, что много дополнительного бабла (GitHub Code Spaces, ...)
И это мне кажетс и есть суть того, почему MS полезло в это - контролировать где сорсы (ГитХаб), как они пишутся (ВС Код), где они пишутся (Азур и онлайн IDE), и кто это пишет (ИИ)
П.С. Я нен конспиролог, но помнится видел старые записи конференций "Build", там где МС представлял ВС Код, и там от всего веяло такими +- целями.
Та не. Сатоши Накамото - это в реальности А.С.Пушкин. Он же еще отсылку к блокчейну биткоина делал:
Похоже. Но чуть отличается.
Например, что в монорепе у вас сцеплены версии всех внутренних компонентов и зависимостей. И они всегда актуальные.
Плюс можно вводить правила единые для всего кода. Все типа рядом. Может быть чуть легче организовать высоко уровневые тесты.
В общем есть нормальная пачка удобств, когда все рядом и актуальное + часто бывает легче искать, что вообще есть.
Например в финтехе, когда многое предпочитают писать сами из-за безопасности, но хотят избежать постоянного переписывания велосипедов всеми командами; на монорепе - легче минимизировать объем дублирования может быть.
Но есть и сложности из-за размера: настраивать частичные билды, а не всего и вся; часть тулов может прийдется писать самому или покупать проприетарные (опенсорсные не справляются иногда; касается чекалок, форматтеров, LSP, ..., вплоть до сорс контрола). В общем проблемы монорепы описаны тоже, тем же Гуглом.
Пару раз работал на монорепе. В целом - нормально и много интересных моментов. Но чувствуется, что требуется выше минимальный скил управления кодом в целом в команде + окупается только на реально больших репах.
Не знаю по поводу ГитХаба, но ГитЛаб монорепу умеет (ограниченные билды и т.д.).
Monorepo
И Google как один из примеров. Но в целом известных примеров много.
Возможно (я повторяю - возможно) ИИ сгенерировал эту статьи и картинки про то, как ИИ (типа) создает схемы "уже почти как люди или даже лучше", что бы подстегнуть нас развиваться и делать более сложные/совершенные схемы (доказывая важность и незаменимость кожаных мешков-нас), на которые он же потом будет перенесен, тем самым так себя улучшая/обновляя. В общем поддеть нас, что бы мы прокачали себя, и потом (автоматом) прокачали его.
Машина по производству скрепок в действии :)
Очень интересно. Можете дать ссылку на это дело. Не встречал.
Но неоднократно думал, что все вот такие изобретения сейчас на самом деле где-то вот так и работают - условно полезны, в основном только академический интерес.
Согласен про явное-неявное. Самому хочется всегда все сделать четко и все границы видимыми. Мне просто способ с типами кажется не таким уж неявным. Но тут наверное уже дело привычки и вкусов в команде.
И такая ситуация не только в легаси может быть. Например ивенты от разных систем (на других языках, рантаймах, нодах, ...), а вам их обрабатывать. В общем везде, где мы не контролируем саму получаемую сущность. В различных журналах это часто.
Также можно использовать чисто внутри приложения - типа выбор фильтра для поиска, ивенты, ... Там где вы все проверите ТСом и весь ТС ваш и команде ок.
Еще во всякого рода фидах (типа главная страница/лента в соц. сетях), где сущность разного типа прут в одном листе, т.е. где естественна неоднородность отдаваемых сущностей.
Еще где я хочу сделать внешний АПИ и мне незачем наваливать пользователю еще один параметр. Я говорю ему: или групАйди или юзерАйди. Больше ничего. Не нужно никаких тайпов. С точки зрения юзера АПИ - так проще. Меньше шума. Имя филда делает разделение типов. Ему понятно все. Если для меня это важно - то способ из статьи лучше. Это фактически и приведено в статье.
Но если это способ общения со своим же Java REST, то большинство скорее всего сделает вашим способом.
В общем я к тому, что такое бывает. Это не самый популярный кейс, но бывает. Ваш - более стандартный и частый.
Они общались и Кнут говорил об этом и был впечатлен работами Ершова + приезжал с визитом.
Так по методу в статье это будет короче выглядеть:
И все понятно. Остальное будет кодом инфры. Который не нужно менять при добавлении поля.
Плюс тут типизация более естественная, а вы делаете сурогатные поля - у сущностей нет entityType и entityId.
И вы накладываете жесткие ограничения на тип
GetUnreadMessages(его структуру). А кто вам сказал, что типGetUnreadMessagesможно менять и он может быть другим? Кто сказал, что там только айдишники? А если там или ордерАйди или юзерНейм, нужно новые имена сурогатным полям? А если завтра добавится продуктСКУ, вы будете везде переименовывать и называть еще как то более дженерик именами ваши поля?Автор выходит из того, что есть вот такая вот ситуация и конкретный формат входного типа. И показывает как это можно решить + гибко, что бы не дописывать при добавлении полей, что важно.
Вы меняете условие (меняете входной формат) и предлагаете другое решение. Ваше тоже хорошее и пользвал много раз. Оно простое и не требует никакой подготовки инфры. И наверное более стандартное. Короче протоптанная тропа, это ясно. Но это решение немного не той задачи, что автор решал.
Но хорошо, что вы указали на этот кейс. Что бы люди понимали, что когда все просто - решения нужно брать простые. И когда можно брать простые. Решение автора - это больше для фреймворков, кода инфры (если большая своя) или для команды с большим опытом ТСа. В остальных случаях скорее всего люди будут брать ваше решение или юнион как в первом комменте к статье.
До этого не доводилось встречать тесты типов как то. Благодарю за пример. Хороший код. Думал об этом, но руки как то не доходили посмотреть.
Да, тесты сильно добавляют понимания + помогут в поддержке через месяц. Еще понимания добавляет выделение утилитарных типов (промежуточных), как вы и делаете, а не все писать одним комбайном. В общем - сделать такие вещи понятными и поддерживаемыми явно можно и не сложно.
Это полезно знать для понимания внутрянки для тех, кто хочет разобраться. Статья хорошая.
Лишь добавлю, что в ПРОДе не стоит пользоваться всеми этими трюками. Просто использовать везде
.equals()для сравнения оберток, как и рекомендуется везде, по дефолту.А каковы шансы, что ИИ решал там такие же задачи, на которых и обучался? Если так, то наука говорит, что на таких задачах его проверять никак нельзя и результаты будут заметно лучше чем обычно (он как бы уже знает ответ).
В общем, как узнать - входили ли эти задачи в обучающую выборку (потому что выглядят они довольно стандартными)?
На удивление от США на порядок меньше чем от РФ: ссылка.
Вот данные по РФ: ссылка.
Ну и данные по РФ в статье устаревшие. Сейчас уже меньше стало запросов. Но все равно я сильно удивлен статистике. Запросов от РФ на 1 и более порядков больше чем от всех других стран, что я проверил.
Я бы даже сказал, что с теми деньгами, что у него есть, ему реально будет сложно найти себе спутницу не из-за денег. Это сильно усложнило задачу. Возможно она самая сложная для него. Причем чем больше денег - тем сложнее.
Но думаю важность ее он еще не осознает.