С нотками смернтной казни за растрату. Тоталитаризм и смертные казни - это штуки которые одна без другой существовать не могут. Везде хорошо, но если присмотреться...
Тоже самое выше пишу. Микроэлектронику в мире двигают потребители. Спрос рождает предложение. Спрос на внутреннем рынке - это оборонка и все. Туда качаются деньги налогоплатильщиков, согласны они или нет. А в итоге налогоплательщик получает "эфимерный" профит в виде "борьбы с соседями", но не новенький компьютер или какую ни будь конкуренцию на мировом рынке.
А зачем? Потребительский рынок тоже схлопывается, покупательная способность будет только уменьшаться. Зачем обычному человеку процессор, простите, если этот процессор будет стоять в каком ни будь устройстве, которое этот человек никогда в жизни не увидит? Я понимаю примерно рынок этих процессоров, но этот рынок совсем не потребительской электроники. Собственно что должно стать двигателем индустрии? Просто вкачивание бабок в оборонку от которой обычному человеку не холодно не жарко?
Вопрос был в том: насколько зарубежные компании готовы нанимать именно внутри рынка РФ, то есть, как это работало - есть аутсорс компания в РФ, являющайся прослойкой для программиста из РФ. И насколько повысились риски сотрудничества зарубежного заказчика с такой прослойкой. Речь в моем вопросе не шла об иммиграции.
По-подробней пожалуйста. Если функция использует хук, да, она хранит состояние за пределами функции, (не помню как этот менеджер данных называется в реакте), но буду признателен за развёрнутый ответ: «а что кроме этого».
Адинис заинтересовал меня тоже, достаточно лёгок в понимании, базовые моменты представлены в доке. Пока это выглядит как достойная замена Laravel из мира JS. Спасибо что пишете о нем для русскоговорящего сообщества.
В планы лида входит развитие членов команды. По крайней мере у нас это было так. Мы с коллегами простраивали планы, да и зная слабые стороны разработчика, задачи подбирали чтобы прокачивать отсутствующие знания. Поэтому и говорю, что опыт какой-то негативный, потому что у меня много примеров, когда лиды развивали навыки команды (не в рамках спринта, а на постоянной основе).
С моей точки зрения, религия - это не обязательно какая либо конкретная имплементация (христианская церковь). Ведь потребность верить во что-то никуда не исчезает. Если одна имплементация отваливается (или ее насильно пытаются убрать), она замещается другой. Поэтому предположение "Нет ни каких оснований полагать, что с религией как-то луше, чем без нее" с моей точки зрения не совсем корректно. Более корректней будет звучать (опять таки с моей точки зрения): "Нет ни каких оснований полагать, что с текущей общепринятной религией будет как-то луше, чем с другой".
Добрый день, с удовольствием прочитал статью, с не меньшим удовольствием прочитал комментарии. Я себя относил (-шу) к атеистам, но понимаю, что потребность в вере во что-либо присутствует, а с годами только нарастает. Эту потребность в какой-то мере закрывает наука. Но сама по себе наука настолько объёмна и разбита на специализации, что приводит к тому что на неё необходимо тратить большое количество времени. Это банально неудобно. Поэтому я начал понимать религиозных людей, у которых есть более компактная и более целостная (не путать с точная) картина мира, упакованная в религию.
Насколько я понимаю и могу сравнивать, религия - это грубый инструмент, который позволяет на базовом уровне получить правила функционирования общества (межличностные отношения) и место человека в этой системе, с множеством упрощений и допущений, а наука - это микроскоп, позволяющий рассмотреть мир в мельчайших деталях (не зацикливаясь на человеке). Собственно тогда эти два инструмента созданы с разными целям (частично пересекающимися) и могут совершенно спокойно существовать параллельно. С моей точки зрения.
В чистой теории каждому человеку при обращении к терапевту должны быть чётко расписаны правила здорового образа жизни, диета, режим физических нагрузок, сна и отдыха.
Здесь мы снимаем с себя ответственность за свое здоровье и вручаем его государству. Теперь наша ответсвенность контролировать госсударство, чтобы оно заботилось о нашем здоровье. А мы делаем это?
Это помимо назначения необходимого лечения и обследований. И самое главное, чтобы пациент эти рекомендации принял и регулярно выполнял.
Если пациент не выражает желания выполнять рекомендации - нужно его заставить регулярно их выполнять? Напрмер, есть операционная система Windows, и она может порекомендовать что то сделать, но важно, чтобы решение принял пользователь. Потому что случается, что операционная система решила обновиться, а пользователь находится в середине процесса монтирования видео.
Если резюмировать мой посыл, то мы сами в ответе за собственное здоровье. И если мы не идем в спортзал, то ни один врач не возьмет нас за ручку и не поведет в спортзал. Это просто прочитать, но трудно осознать.
А что насчет терапевта? Терапевт - это системный модуль. И я согласен, что этот системный модуль должен пропогандировать здоровый образ жизни.
Так как мед-система достаточно сложная, то уже нет единственного ответственного, есть набор врачей, которые перенаправляют человека друг к дружке по мере решения проблемы. Ответственность за ваше лечение несет организация, которая взялась вас лечить.
Часто для экономии ресурсов (времени и денег) код, берущий и трансформирующий данные из базы, пишется сразу в функции, которая их должна вернуть фронту (прям буквально все без разбиения: запрос в базу, перебор данных и трансформация, склеивание с данными из другого запроса, формирование JSON-ответа). И это тоже не плохой вариант, если требования снаружи минимальны, API не должен эволюционировать, и затраты на архитектуру не окупятся в перспективе. Как пример: какой ни будь промо-сайт с убер-фичей (показать рейтинги в режиме реального времени) для единичного заказчика под ключ (утрировано).
Интересная мысль возникла по поводу:
В общем, это один из возможных инструментов, который кому-то подойдёт, а кому-то нет.
Нас везде учат, что нужно все разделять, писать красиво. Создается табу на написание плохого кода (без разбиения на слои, например). И разработчики могут попадать в эту ловушку, потому что: существует стереотип что необходимо писать обязательно гибкий код (так пишут во всех книжках); разработчик не видит задачу целиком (поэтому не может выбрать стратегию - писать "на коленке" или "по-взрослому"); мы не знаем что потребуется завтра (увы, но иногда легче выкинуть и написать с нуля "по-взрослому", но не все готовы выбросить кучу написанного на коленке кода).
Фронты могут проектировать, но только свою точку зрения на API - здесь нет ничего плохого. Потому что в реальности есть возможность отдавать дублирующиеся данные по нескольким эндпоинтам и удовлетворить потребности фронта.
Но часто для экономии ресурсов (времени и денег) код, берущий и трансформирующий данные из базы, пишется сразу в функции, которая их должна вернуть фронту (прям буквально все без разбиения: запрос в базу, перебор данных и трансформация, склеивание с данными из другого запроса, формирование JSON-ответа). И это тоже не плохой вариант, если требования снаружи минимальны, API не должен эволюционировать, и затраты на архитектуру не окупятся в перспективе. Как пример: какой ни будь промо-сайт с убер-фичей (показать рейтинги в режиме реального времени) для единичного заказчика под ключ (утрировано).
Проблемы начинаются когда появляется следующий эндпоинт с похожими данными и похожими трансформациями. Тогда разработчик делает: либо дублирование, либо начинает препираться с требованиями, либо заводит вопрос о рефакторинге. Тот вариант, который выберет разработчик - напрямую зависит от опыта и желания развиваться.
И из личного опыта: все негативные эмоции разработчики испытывают, когда одна из сторон не прислушивается и делает все "как правильно" с ее точки зрения (а точнее "как умеет"). Иногда доходило до смешного, когда не удавалось договориться о типах данных на уровне прямитивов.
Другими словами - это наличие слоя бизнес-логики (слоя сервисов + БД) и слоя API (контроллеры + трансформеры, которые дергают и склеивают данные из разных сервсов).
Поддерживаю, есть слой где сущности и бизнес-правила живут независимо от окружения. И тогда создавать слои-интерфейсы доступа (API) поверх - можно сколько угодно. Единственное здесь - абстракции имеют свою цену, которая не отбивается на маленьком масштабе (там да, лучше "как получится").
Проблемы конечно на уровне согласования контрактов есть, безусловно, но чаще видел что архитектура строится криво (неправильныо наполненные сущности или лишние слои для гибкости которая в некоторых местах не нужна, уехавшая в другие места ответственность). Лечить апи безусловно можно и нужно - все что помогает взаимодействию - это хорошо, но все же это похоже на лечение симптомов (исключительно мое мнение). Спасибо за пост!
С нотками смернтной казни за растрату. Тоталитаризм и смертные казни - это штуки которые одна без другой существовать не могут. Везде хорошо, но если присмотреться...
Тоже самое выше пишу. Микроэлектронику в мире двигают потребители. Спрос рождает предложение. Спрос на внутреннем рынке - это оборонка и все. Туда качаются деньги налогоплатильщиков, согласны они или нет. А в итоге налогоплательщик получает "эфимерный" профит в виде "борьбы с соседями", но не новенький компьютер или какую ни будь конкуренцию на мировом рынке.
А зачем? Потребительский рынок тоже схлопывается, покупательная способность будет только уменьшаться. Зачем обычному человеку процессор, простите, если этот процессор будет стоять в каком ни будь устройстве, которое этот человек никогда в жизни не увидит? Я понимаю примерно рынок этих процессоров, но этот рынок совсем не потребительской электроники. Собственно что должно стать двигателем индустрии? Просто вкачивание бабок в оборонку от которой обычному человеку не холодно не жарко?
А разве импортозамещение - это не cancel-культура? Просто называется по-другому.
Вопрос был в том: насколько зарубежные компании готовы нанимать именно внутри рынка РФ, то есть, как это работало - есть аутсорс компания в РФ, являющайся прослойкой для программиста из РФ. И насколько повысились риски сотрудничества зарубежного заказчика с такой прослойкой. Речь в моем вопросе не шла об иммиграции.
Вопрос в том: насколько зарубежные компании готовы рисковать, нанимая из РФ?
Это субъективно? Или как то тестировалось. Выглядит как недоказанная гипотеза.
По-подробней пожалуйста. Если функция использует хук, да, она хранит состояние за пределами функции, (не помню как этот менеджер данных называется в реакте), но буду признателен за развёрнутый ответ: «а что кроме этого».
Прочтение статьи о схеме это уже профилактика.
Адинис заинтересовал меня тоже, достаточно лёгок в понимании, базовые моменты представлены в доке. Пока это выглядит как достойная замена Laravel из мира JS. Спасибо что пишете о нем для русскоговорящего сообщества.
В планы лида входит развитие членов команды. По крайней мере у нас это было так. Мы с коллегами простраивали планы, да и зная слабые стороны разработчика, задачи подбирали чтобы прокачивать отсутствующие знания. Поэтому и говорю, что опыт какой-то негативный, потому что у меня много примеров, когда лиды развивали навыки команды (не в рамках спринта, а на постоянной основе).
Какой-то у вас сугубо негативный опыт.
С моей точки зрения, религия - это не обязательно какая либо конкретная имплементация (христианская церковь). Ведь потребность верить во что-то никуда не исчезает. Если одна имплементация отваливается (или ее насильно пытаются убрать), она замещается другой. Поэтому предположение "Нет ни каких оснований полагать, что с религией как-то луше, чем без нее" с моей точки зрения не совсем корректно. Более корректней будет звучать (опять таки с моей точки зрения): "Нет ни каких оснований полагать, что с текущей общепринятной религией будет как-то луше, чем с другой".
Добрый день, с удовольствием прочитал статью, с не меньшим удовольствием прочитал комментарии. Я себя относил (-шу) к атеистам, но понимаю, что потребность в вере во что-либо присутствует, а с годами только нарастает. Эту потребность в какой-то мере закрывает наука. Но сама по себе наука настолько объёмна и разбита на специализации, что приводит к тому что на неё необходимо тратить большое количество времени. Это банально неудобно. Поэтому я начал понимать религиозных людей, у которых есть более компактная и более целостная (не путать с точная) картина мира, упакованная в религию.
Насколько я понимаю и могу сравнивать, религия - это грубый инструмент, который позволяет на базовом уровне получить правила функционирования общества (межличностные отношения) и место человека в этой системе, с множеством упрощений и допущений, а наука - это микроскоп, позволяющий рассмотреть мир в мельчайших деталях (не зацикливаясь на человеке). Собственно тогда эти два инструмента созданы с разными целям (частично пересекающимися) и могут совершенно спокойно существовать параллельно. С моей точки зрения.
Здесь мы снимаем с себя ответственность за свое здоровье и вручаем его государству. Теперь наша ответсвенность контролировать госсударство, чтобы оно заботилось о нашем здоровье. А мы делаем это?
Если пациент не выражает желания выполнять рекомендации - нужно его заставить регулярно их выполнять? Напрмер, есть операционная система Windows, и она может порекомендовать что то сделать, но важно, чтобы решение принял пользователь. Потому что случается, что операционная система решила обновиться, а пользователь находится в середине процесса монтирования видео.
Если резюмировать мой посыл, то мы сами в ответе за собственное здоровье. И если мы не идем в спортзал, то ни один врач не возьмет нас за ручку и не поведет в спортзал. Это просто прочитать, но трудно осознать.
А что насчет терапевта? Терапевт - это системный модуль. И я согласен, что этот системный модуль должен пропогандировать здоровый образ жизни.
Так как мед-система достаточно сложная, то уже нет единственного ответственного, есть набор врачей, которые перенаправляют человека друг к дружке по мере решения проблемы. Ответственность за ваше лечение несет организация, которая взялась вас лечить.
Я про масштаб проекта. Вкратце:
Интересная мысль возникла по поводу:
Нас везде учат, что нужно все разделять, писать красиво. Создается табу на написание плохого кода (без разбиения на слои, например). И разработчики могут попадать в эту ловушку, потому что: существует стереотип что необходимо писать обязательно гибкий код (так пишут во всех книжках); разработчик не видит задачу целиком (поэтому не может выбрать стратегию - писать "на коленке" или "по-взрослому"); мы не знаем что потребуется завтра (увы, но иногда легче выкинуть и написать с нуля "по-взрослому", но не все готовы выбросить кучу написанного на коленке кода).
Фронты могут проектировать, но только свою точку зрения на API - здесь нет ничего плохого. Потому что в реальности есть возможность отдавать дублирующиеся данные по нескольким эндпоинтам и удовлетворить потребности фронта.
Но часто для экономии ресурсов (времени и денег) код, берущий и трансформирующий данные из базы, пишется сразу в функции, которая их должна вернуть фронту (прям буквально все без разбиения: запрос в базу, перебор данных и трансформация, склеивание с данными из другого запроса, формирование JSON-ответа). И это тоже не плохой вариант, если требования снаружи минимальны, API не должен эволюционировать, и затраты на архитектуру не окупятся в перспективе. Как пример: какой ни будь промо-сайт с убер-фичей (показать рейтинги в режиме реального времени) для единичного заказчика под ключ (утрировано).
Проблемы начинаются когда появляется следующий эндпоинт с похожими данными и похожими трансформациями. Тогда разработчик делает: либо дублирование, либо начинает препираться с требованиями, либо заводит вопрос о рефакторинге. Тот вариант, который выберет разработчик - напрямую зависит от опыта и желания развиваться.
И из личного опыта: все негативные эмоции разработчики испытывают, когда одна из сторон не прислушивается и делает все "как правильно" с ее точки зрения (а точнее "как умеет"). Иногда доходило до смешного, когда не удавалось договориться о типах данных на уровне прямитивов.
Другими словами - это наличие слоя бизнес-логики (слоя сервисов + БД) и слоя API (контроллеры + трансформеры, которые дергают и склеивают данные из разных сервсов).
Поддерживаю, есть слой где сущности и бизнес-правила живут независимо от окружения. И тогда создавать слои-интерфейсы доступа (API) поверх - можно сколько угодно. Единственное здесь - абстракции имеют свою цену, которая не отбивается на маленьком масштабе (там да, лучше "как получится").
Проблемы конечно на уровне согласования контрактов есть, безусловно, но чаще видел что архитектура строится криво (неправильныо наполненные сущности или лишние слои для гибкости которая в некоторых местах не нужна, уехавшая в другие места ответственность). Лечить апи безусловно можно и нужно - все что помогает взаимодействию - это хорошо, но все же это похоже на лечение симптомов (исключительно мое мнение). Спасибо за пост!