Вы процитировали вопрос. Вопрос риторический и вы его не опровергли. Санкции введены НЕ компаниями. То есть компании НЕ могут распоряжаться СВОИМ имуществом по СВОЕМУ усмотрению.
Тут беда в том, что производитель не США. Производитель, например, Интел. И Интел хочет продавать. Это цель бизнеса - побольше заработать денег. Значит надо больше продать. А ему не дают. Иначе на него самого наложат санкции, а то и вовсе отожмут. А если Интел сам решит, что не хочет продавать, скажем, Украинцам, то на него опять же надавят.
Никуда санкции не исчезнут. Кто вам это сказал? Были какие то документы, подтверждающие ваши слова? Или хотя бы публичные заявления? Санкции это инструмент давления, а не защиты. Если бы у нас были иные отношения с США, то санкции сейчас обрушились бы на Украину, а не на нас. И причины бы нашлись, уверяю.
Вы мыслите слишком широко, а тем временем РЖД решает тут свои проблемы, а не человечества в целом. И если им удастся давить в 2 раза меньше народу - это уже хорошо и все не зря )
Ну вот, человек говорит, что не вынуждены и не идут. :)
Это так не работает. Если есть парк, там обязательно будут шуметь. Наивно полагаться на благоразумие. Надо проектировать так, чтобы предотвратить подобные вещи.
Вы тут вместе с другими цепляетесь за детали и зачем то пытаетесь увести разговор от главной мысли. Парк - место отдыха. Люди не всегда отдыхают тихо. Парки не надо строить возле домов.
Ну то есть я не могу выйти в поле и проораться? Шум, чтобы он стал вне закона, должен сначала кому то помешать, а потом уже будут разбираться, имел ли право этот шум тут быть. Шум в парке в конкретном случае вне закона, потому что там жилой дом под боком. Но какого черта он там делает? Застройщик в данном случае нехороший человек. Сделал парк, в котором нельзя вечером поорать песни под гитару. Зачем нужен такой парк?
Закон делит. И да, шуметь нельзя именно в жилой зоне. Если, например, где-то за городом идет стройка и мешает жильцам ближайших районов, то этот шум будет вне закона. Но я имел ввиду не совсем это. Парки, обычно, не располагаются вблизи жилых домов. Поэтому люди просто развлекаются в парках. Иногда шумно. Люди редко создают такой шум, чтобы мешать жильцам ближайших районов и люди к этому привыкли. Привыкли к тому, что в парках можно петь, кричать и тд. И то что парк сделали рядом с жилым домом это недоработка застройщика. Людей в этом я бы винить не стал.
О, кстати, я вот, как программист, сам решу, каким маршрутом мне добраться от кровати до компьютерного кресла и никакие продуманные пространства этому не помешают )))
Не вижу ни одной сложности связанной с линией. Чем плоха линия? Не нужны все эти развязки, стрелки, перделки. Есть поезд и он просто едет. Единственная его задача - не догнать поезд впереди.
Зато из плюсов линии - ее проще защитить от окружающей среды. Если все спланировать правильно, а не как обычно, внутри не будет жарко и не потребуется куча кондиционеров. Вот там стены зеркальные. Они будут отражать большую часть тепла. А в круглом или квадратном городе как это сделать?
В том и дело, что это не инкубатор. Вы спокойно можете покинуть город не стоя в пробках и на светофорах. Вы так же можете иметь машину, но за пределами этого города. Если все будет так как написано, то в пределах города машина и не нужна. А если захочется на рыбалку в Финляндию, то это явно за чертой города. А за чертой города вы можете иметь машину
Ну про это разговора не было. Был про шум под окном и фейерверки на НГ под окном. Вот второе плохо и незаконно. А по поводу первого спорно. Люди отдыхают в парке, а не во дворе дома.
Ну про фейерверки да, это перебор. Но выпустить накопившиеся за неделю эмоции песнями под гитару... В этом то что плохого? Молодежь не виновата, что парк развернули у кого то под окнами.
так там же садитесь на поезд и катитесь на курорт в конце линии. Максимум 30 минут (с учетом остановок). А если уж так сильно надоели местные пейзажи, то за городом вас может ждать ваш автомобиль :) Город же не подразумевается изолированным.
Не обязательно продираться. Есть OpenApi который позволяет вести документацию в отрыве от кода. Более того, есть генераторы для DTO, которые позволяют сгенерировать их на основе OpenApi документации (с комментариями). Далее техлид или один из разработчиков ядра должен разработать связку структуры запроса с механизмами запросов. И все. Обычному разработчику не потребуется даже вникать в эти структуры и документацию. Вы просто при создании круда передаете запрос в нужный сервис и он работает.
Это не язык, это соглашение о формате данных. Язык запросов — это, например, graphql.
Я не так выразился. Я к тому, что чего его изобретать то? Фактически это будет структура на том ЯП, который используется на бэке. То есть не важно, что придет, json или sql, оно будет парситься в эту структуру. А дальше уже эта структура будет преобразовываться в запрос к хранилищу.
То есть фактически, автор предложил поменять шило на мыло, вот только минусы от этой замены, озвученные в моем комменте выше, не перекрыть, имея доступные инструменты. Придется изобретать инфраструктуру.
Ах да. Еще я бы отнес к минусам отсутствие поддержки маппинга contentType: application\sql многими современными фреймворками. А значит я не смогу в методе контроллера указать тип данных аргумента. Более того, если я это сделаю, я либо буду навсегда привязан к sql, либо придется изготавливать функционал, подобный graphql, который позволит связать мои методы принимающие sql запросы с MVC фреймворком.
А плюсы от этого всего весьма туманны.
Я разрабатывал свою систему запросов на подобие graphql, она была лишена некоторых недостатков оного (в том числе связанных с производительностью), но была связана с EntityFramework (dotnet). Я так и не смог отделить ее, оставив лишь привязку IQueryable, чтобы можно было работать с любым ORM, но зато не пришлось мастерить оснастку для интеграции с MVC.
Вы говорите, что json заставляет нас изобретать свой язык запросов
Вот здесь уже каждый должен унюхать, что этот код попахивает.
Почему? Потому что здесь мы, в сущности, изобретаем собственный язык запросов. А изобретение собственного языка, согласитесь – это уже крайняя мера.
Но это не так. Язык уже изобретен (json). Все, что нам нужно, это прикрутить структуру, на подобие вашей для SQL.
К тому же всякие там OpenAPI умеют работать с json и xml, но не умеют с sql. А значит, у вас будет проблема с документированием.
Да и фронты не скажут вам спасибо за SQL в запросах. У них объекты ЯП и есть json. Но придется парсить в SQL. К тому же у них будет чувство тревоги из-за того, что они будут ждать когда и ответ им начнет приходить соответствующий :)
Вы процитировали вопрос. Вопрос риторический и вы его не опровергли. Санкции введены НЕ компаниями. То есть компании НЕ могут распоряжаться СВОИМ имуществом по СВОЕМУ усмотрению.
Никто своим трудом не распоряжается. Компании так же в минусе от санкций.
Тут беда в том, что производитель не США. Производитель, например, Интел. И Интел хочет продавать. Это цель бизнеса - побольше заработать денег. Значит надо больше продать. А ему не дают. Иначе на него самого наложат санкции, а то и вовсе отожмут. А если Интел сам решит, что не хочет продавать, скажем, Украинцам, то на него опять же надавят.
Нет такого города Кенигсберг. Есть Калининград.
Никуда санкции не исчезнут. Кто вам это сказал? Были какие то документы, подтверждающие ваши слова? Или хотя бы публичные заявления? Санкции это инструмент давления, а не защиты. Если бы у нас были иные отношения с США, то санкции сейчас обрушились бы на Украину, а не на нас. И причины бы нашлись, уверяю.
Вы мыслите слишком широко, а тем временем РЖД решает тут свои проблемы, а не человечества в целом. И если им удастся давить в 2 раза меньше народу - это уже хорошо и все не зря )
А вот это грубо. Фу!
Ну если наложить на них санкции с целью бойкота не получится, то придется таки к ним притираться )
Ну вот, человек говорит, что не вынуждены и не идут. :)
Это так не работает. Если есть парк, там обязательно будут шуметь. Наивно полагаться на благоразумие. Надо проектировать так, чтобы предотвратить подобные вещи.
Вы тут вместе с другими цепляетесь за детали и зачем то пытаетесь увести разговор от главной мысли. Парк - место отдыха. Люди не всегда отдыхают тихо. Парки не надо строить возле домов.
Ну то есть я не могу выйти в поле и проораться? Шум, чтобы он стал вне закона, должен сначала кому то помешать, а потом уже будут разбираться, имел ли право этот шум тут быть. Шум в парке в конкретном случае вне закона, потому что там жилой дом под боком. Но какого черта он там делает? Застройщик в данном случае нехороший человек. Сделал парк, в котором нельзя вечером поорать песни под гитару. Зачем нужен такой парк?
Закон делит. И да, шуметь нельзя именно в жилой зоне. Если, например, где-то за городом идет стройка и мешает жильцам ближайших районов, то этот шум будет вне закона. Но я имел ввиду не совсем это. Парки, обычно, не располагаются вблизи жилых домов. Поэтому люди просто развлекаются в парках. Иногда шумно. Люди редко создают такой шум, чтобы мешать жильцам ближайших районов и люди к этому привыкли. Привыкли к тому, что в парках можно петь, кричать и тд. И то что парк сделали рядом с жилым домом это недоработка застройщика. Людей в этом я бы винить не стал.
О, кстати, я вот, как программист, сам решу, каким маршрутом мне добраться от кровати до компьютерного кресла и никакие продуманные пространства этому не помешают )))
Не вижу ни одной сложности связанной с линией. Чем плоха линия? Не нужны все эти развязки, стрелки, перделки. Есть поезд и он просто едет. Единственная его задача - не догнать поезд впереди.
Зато из плюсов линии - ее проще защитить от окружающей среды. Если все спланировать правильно, а не как обычно, внутри не будет жарко и не потребуется куча кондиционеров. Вот там стены зеркальные. Они будут отражать большую часть тепла. А в круглом или квадратном городе как это сделать?
В том и дело, что это не инкубатор. Вы спокойно можете покинуть город не стоя в пробках и на светофорах. Вы так же можете иметь машину, но за пределами этого города. Если все будет так как написано, то в пределах города машина и не нужна. А если захочется на рыбалку в Финляндию, то это явно за чертой города. А за чертой города вы можете иметь машину
Ну про это разговора не было. Был про шум под окном и фейерверки на НГ под окном. Вот второе плохо и незаконно. А по поводу первого спорно. Люди отдыхают в парке, а не во дворе дома.
Ну про фейерверки да, это перебор. Но выпустить накопившиеся за неделю эмоции песнями под гитару... В этом то что плохого? Молодежь не виновата, что парк развернули у кого то под окнами.
так там же садитесь на поезд и катитесь на курорт в конце линии. Максимум 30 минут (с учетом остановок). А если уж так сильно надоели местные пейзажи, то за городом вас может ждать ваш автомобиль :)
Город же не подразумевается изолированным.
Не обязательно продираться. Есть OpenApi который позволяет вести документацию в отрыве от кода. Более того, есть генераторы для DTO, которые позволяют сгенерировать их на основе OpenApi документации (с комментариями). Далее техлид или один из разработчиков ядра должен разработать связку структуры запроса с механизмами запросов. И все. Обычному разработчику не потребуется даже вникать в эти структуры и документацию. Вы просто при создании круда передаете запрос в нужный сервис и он работает.
Я не так выразился. Я к тому, что чего его изобретать то? Фактически это будет структура на том ЯП, который используется на бэке. То есть не важно, что придет, json или sql, оно будет парситься в эту структуру. А дальше уже эта структура будет преобразовываться в запрос к хранилищу.
То есть фактически, автор предложил поменять шило на мыло, вот только минусы от этой замены, озвученные в моем комменте выше, не перекрыть, имея доступные инструменты. Придется изобретать инфраструктуру.
Ах да. Еще я бы отнес к минусам отсутствие поддержки маппинга contentType: application\sql многими современными фреймворками. А значит я не смогу в методе контроллера указать тип данных аргумента. Более того, если я это сделаю, я либо буду навсегда привязан к sql, либо придется изготавливать функционал, подобный graphql, который позволит связать мои методы принимающие sql запросы с MVC фреймворком.
А плюсы от этого всего весьма туманны.
Я разрабатывал свою систему запросов на подобие graphql, она была лишена некоторых недостатков оного (в том числе связанных с производительностью), но была связана с EntityFramework (dotnet). Я так и не смог отделить ее, оставив лишь привязку IQueryable, чтобы можно было работать с любым ORM, но зато не пришлось мастерить оснастку для интеграции с MVC.
Вы говорите, что json заставляет нас изобретать свой язык запросов
Но это не так. Язык уже изобретен (json). Все, что нам нужно, это прикрутить структуру, на подобие вашей для SQL.
К тому же всякие там OpenAPI умеют работать с json и xml, но не умеют с sql. А значит, у вас будет проблема с документированием.
Да и фронты не скажут вам спасибо за SQL в запросах. У них объекты ЯП и есть json. Но придется парсить в SQL. К тому же у них будет чувство тревоги из-за того, что они будут ждать когда и ответ им начнет приходить соответствующий :)