Здесь интересны были бы аналоги из реальной жизни. Например, с кулинарными рецептами. И почему мамины пирожки не такие как у бабушки, хотя делают вроде все одинаково: одна цель, одна задача, один рецепт с одним и тем же набором действий.
Если деплой ограничивается docker, можно на целевой машинке выставить порт dockerd наружу и указать джобе для деплоя DOCKER_HOST (технически docker это ведь тоже клиент и сервер). Плюс в том, что на минималках все это настраивается за 5 секунд. Вопросы безопасности для такого решения хорошо описаны в сети и можно городить любой огород в зависимости от ваших потребностей.
Либо, раз у вас gitlab, то можно запустить gitlab-runner на машинках куда собираетесь деплоить - он подтянет артефакты. Остальное решается скриптом для джобы в десяток строчек на bash (и gomplate если нравятся гошные шаблоны).
Ну или по классике: Ansible, Terraform и т.п.
Писать свое может быть полезно, если надо например потренировать команду, чтобы ребята лучше разобрались в нюансах предметной области или языке. Но делать законченное продакшн решение это проект и это дорого, если подходить к вопросу серьезно. Вы это ни когда не окупите. Пользуйтесь готовым.
Реакт завоевал популярность не в последнюю очередь благодаря грамотному техномаркетингу. Пока вы в каждой теме продолжаете позиционировать себя путем противопоставления всем остальным, все остальные вас закономерно будут продолжать ненавидеть).
PHP не содержал HTML как часть языка. По сути это была надстройка для интерполяции строк, где не было ни какой возможности проверить корректность результата. JSX это всё-таки немного другое, при желании он даже тайпчекается статически.
Роман с профессией: как он случается? ... образ жизни привлекает, возникает фантазия о будущей профессии.
По-моему путь к айти больше похож на дорогу в алкоголики, чем в психологи или артисты. Я имею ввиду ту часть, кто пришел в айти по любви к занятию. Ух ты, он с утра до ночи сидит за монитором с красными глазами, не знает во что одет, и не может связать пары слов когда разговор не о компьютерах - хочу быть таким же. Ну да.
Почему любимая работа не даст вам того, чего вы на самом деле от нее ждете
В теории, все будет хорошо, если не впадать в крайности. Проблемы начинаются тогда, когда она даёт этого даже больше, чем вы способны переварить без вреда для собственного здоровья и окружающих.
Проблема в том, что ReST это архитектура, а не протокол. Поэтому протокол можно сделать каким угодно, если он не противоречит её принципам и шести ограничениям. Из-за этого вероятность найти готовый инструмент под конкретные требования стремится к нулю - всегда приходится адаптировать.
Есть зоопарк из различных RFC, которые в разное время составляли под разные задачи. Попытки систематизировать и формализовать, скажем так, "web-ориентированный ReST" уже были - с четким алгоритмом в какой ситуации какой HTTP status code должен возвращаться. Например, такую работу проделали в Webmachine для Erlang, описав флоу в виде flow-диаграммы, машины состояний и тестов (мне также встречались порты для других языков). Но в массы это не пошло, а жаль - возможно мир стал бы гораздо проще.
Какого-то единообразия среди фреймворков и технологий нет. Каждый реализует протокол вмеру собственных предпочтений. Наименьший общим знаменателем становится OpenAPI (бывший Swagger). Но он определяет только формат, оставляя протокольную часть за рамками. Остальное решается на уровне соглашений, принятых в конкретной организации.
как вы сказали, на устаревших базвордах луковичной архитектуры и контейнеров.
Я ни где не говорил, что это устарело. Скорее развилось и стало рутиной. А вот подходы к работе с PII поменялись радикально из-за необходимости соблюдать кучу юридических церемоний. В вашем решении данные не классифицируются, свободно передаваясь между компонентами. Поэтому с предложенной архитектурой бизнес влетит на мешок денег после первого же compliance report. Чтобы этого не произошло, такие требования нужно закладывать сразу. Попробуйте, вы сразу увидите как это заставит перекроить всю архитектуру.
Поэтому, если нет желания показывать свои навыки в проектировании конкретно приложений для обработки PII, для демо сейчас выбирают что-то более нейтральное, типа API прогноза погоды, котировок валют или подобное. Это будет в разы проще.
Что касается тестов, то писать их до или после это тактика. Главное, чтобы в конце они появились. :) Ну и линтер с тайпчекером прикрутить к CI вроде уже не экзотика.
Честно говоря двоякое чувство. С одной стороны интригующий выбор темы (с персональными данными, коммуникацией с госами), а с другой - реализация с массой недосказанностей. По сути я думал это статья к студенческой работе или тестовому заданию перспективного джуниора, пока не заглянул в профиль автора.
Софт без задефайненных non-functional requirements, quality attributes и код без тестов это прототип. На этом уровне техническая задача обычно сводится к тому, чтобы решение лишь бы хоть как-то работало. Работает? - вы молодец. Но дальше в отсутствии требований об архитектуре сервиса говорить нет смысла потому, что архитектура выбирается исходя из требований. Вы же понимаете, что допустим для достижения availablity 99.9 и 99.999 у вас будут два принципиально разных архитектурных решения и разницей по сложности и стоимости примерно на один-два порядка.
Но проблема даже не в этом. Принимая ФИО, паспортные данные и т.п., с точки зрения законодательства вы становитесь оператором персональных данных, со всеми вытекающими требованиями - к хранению, обработке и передаче. Я не увидел даже намека. Вы хотели отзыв: десять лет тому назад это выглядело бы даже неплохо (все эти базворды типа onion architecture, DI и т.п.). Но в 2023 предложенное решение - детский сад штаны на лямках - в решении уровня лида хочется все же видеть больше осмысленности.
http://kb.mozillazine.org/Chrome_URLs это древнючее наследие со времён XUL - оригинального UI движка на котором раньше работал браузер от Mozilla. Словом "chrome" там называют любые элементы браузера, кроме собственно содержимого web страницы. Отсюда одноименная адресация.
Всё это появилось гораздо раньше Google Chrome, и не имеет к нему отношения (скорее уж Google скосплеил название). about: появился позже, чтобы отвязаться от конкретной технологии.
Регеспы по сути это нотация для компактной записи грамматик. Писать структурированный и документированный код это ацкая мука, когда перед вами лишь командная строка). В общем я не спорю, тут все сводится к банальному - инструмент под задачу.
Это перевод, автор вряд-ли ответит). Вообще он преподаватель, изучил подход к теме в хаскеле и решил сделать так же питоне. Это решение не для продакшна.
Просто, если вы сможете реализовать принцип на другом языке, который может для этого не особо и предназначен, значит вы разобрались в теме, а не просто заучили мануал. Заодно это помогает лучше понять сильные и слабые стороны, а так же границы применимости того или иного подхода.
HashiCorp вроде заблокировали свои ресурсы для некоторых стран, сразу после начала конфликта. Интересно, как местные организации продолжают использовать Terraform, или ищут альтернативные варианты?
Собеседование стоит начинать с простых вопросов, на которые собеседнику будет легко ответить. Это снимает стресс и создаёт позитивную атмосферу. Тут злую шутку играет разница культур.
Например, американцы любят говорить от первого лица и о себе, какие они молодцы и вообще классные ребята. В этом есть что-то немного детское. Как будто ребенок рассказывает своим родителям какой он герой, когда сделает что-то хорошее, и они все вместе приходят в умиление. Говорить о себе в позитивном ключе это приятная тема. Поэтому такой вопрос в начале собеседования звучит органично.
В восточной Европе ценится скромность. Рассказывать про себя хорошее - хвастаться, это некультурно. Можно рассказать про фейлы - т.е. покаяться. Это будет одобряемо, но кто хочет каяться незнакомым людям на первой же встрече? Единственное разумное объяснение - в таком предложении есть какой-то подвох. Поэтому просьба рассказать о себе имеет прямо противоположный эффект, вызывая у собеседника с порога шок и истерику (пусть даже внутреннюю).
На собеседовании смотрим знания, а навыки и умения - на испытательном сроке. Идея приятная, но выходит дороговато, причем для обоих сторон.
Разница между хорошим замечанием к коду и собственноручно написанным, как здесь между комментарием и статьёй. Допустим моим и вашей. Связать между собой пару предложений или сочинить текст на несколько страниц - согласитесь, разница по сложности колоссальна.
Разработка это борьба со сложностью. Мне уже несколько раз попадались сотрудники, которые красиво критикуют как синьоры, особенно если укажешь место. А сделать потом не могут - ведь количество деталей, которые прихится учитывать на практике, измеряется числами совсем другого порядка и требует колоссальной дисциплины.
Бизнес боится профсоюзов как огня. Поэтому допускаю что они могут запускать компании по дискредитации любых идеей сотрудников как-то между собой объединяться, чтобы отстаивать свои права. У текущего работодателя тоже нет профсоюзов, предыдущие попытки организовать были грамотно слиты.
Вообще большие компании давно поняли, что если у сотрудника появляется возможность делегировать неудобную для себя деятельность кому-то другому, то они охотно этим пользуются. Например, кому нравится доказывать начальству преимущества очередного фреймворка или затевать разговор о повышении зарплаты с боссом? Тут на сцену выходят деврелы, которые охотно берут на себя эту функцию поговорить. Говорить о чужих проблемах же проще, тем более если язык растет из правильного места. Это даже работает, по началу.
В чем подвох? Что не тренируется - то не развивается. Персонал утрачивает навыки и больше не поднимает неудобные темы. Деврел отвечает лишь за нескучные мероприятия и пока он раздает клавиатуры аж за 15 тыщ, разработчики делают свою скучную работу за прежнюю зряплату, ради чего их собственно и нанимали.
Постснгшная аудитория всегда стремилась рассказать тем, кто пытается что-то делать, как они были неправы. Не обращайте внимания. Надеюсь вы сможете найти своего работодателя по профилю (или они вас).
Просто выходя на мировой рынок, вы начинаете конкурировать с такими же соискателями уже со всего мира. Это гораздо более жёсткая конкуренция, чем у себя дома.
Раньше можно было быть востребованным специалистом будучи самоучкой. Сейчас такие соискатели воспринимаются скорее как персонажи из мира фольклора. Нет, умение подковать условную блоху до сих пор вызывает восторг, но в целом платежеспособной индустрии нужно совсем другое. Сейчас разаботка ПО это конвейер.
Здесь интересны были бы аналоги из реальной жизни. Например, с кулинарными рецептами. И почему мамины пирожки не такие как у бабушки, хотя делают вроде все одинаково: одна цель, одна задача, один рецепт с одним и тем же![]()
набором действий.
Если деплой ограничивается docker, можно на целевой машинке выставить порт dockerd наружу и указать джобе для деплоя DOCKER_HOST (технически docker это ведь тоже клиент и сервер). Плюс в том, что на минималках все это настраивается за 5 секунд. Вопросы безопасности для такого решения хорошо описаны в сети и можно городить любой огород в зависимости от ваших потребностей.
Либо, раз у вас gitlab, то можно запустить gitlab-runner на машинках куда собираетесь деплоить - он подтянет артефакты. Остальное решается скриптом для джобы в десяток строчек на bash (и gomplate если нравятся гошные шаблоны).
Ну или по классике: Ansible, Terraform и т.п.
Писать свое может быть полезно, если надо например потренировать команду, чтобы ребята лучше разобрались в нюансах предметной области или языке. Но делать законченное продакшн решение это проект и это дорого, если подходить к вопросу серьезно. Вы это ни когда не окупите. Пользуйтесь готовым.
Реакт завоевал популярность не в последнюю очередь благодаря грамотному техномаркетингу. Пока вы в каждой теме продолжаете позиционировать себя путем противопоставления всем остальным, все остальные вас закономерно будут продолжать ненавидеть).
PHP не содержал HTML как часть языка. По сути это была надстройка для интерполяции строк, где не было ни какой возможности проверить корректность результата. JSX это всё-таки немного другое, при желании он даже тайпчекается статически.
По-моему путь к айти больше похож на дорогу в алкоголики, чем в психологи или артисты. Я имею ввиду ту часть, кто пришел в айти по любви к занятию. Ух ты, он с утра до ночи сидит за монитором с красными глазами, не знает во что одет, и не может связать пары слов когда разговор не о компьютерах - хочу быть таким же. Ну да.
В теории, все будет хорошо, если не впадать в крайности. Проблемы начинаются тогда, когда она даёт этого даже больше, чем вы способны переварить без вреда для собственного здоровья и окружающих.
При обрыве соединения клиент сможет докачивать только недостающие данные или будет грузить все по новой?
Проблема в том, что ReST это архитектура, а не протокол. Поэтому протокол можно сделать каким угодно, если он не противоречит её принципам и шести ограничениям. Из-за этого вероятность найти готовый инструмент под конкретные требования стремится к нулю - всегда приходится адаптировать.
Есть зоопарк из различных RFC, которые в разное время составляли под разные задачи. Попытки систематизировать и формализовать, скажем так, "web-ориентированный ReST" уже были - с четким алгоритмом в какой ситуации какой HTTP status code должен возвращаться. Например, такую работу проделали в Webmachine для Erlang, описав флоу в виде flow-диаграммы, машины состояний и тестов (мне также встречались порты для других языков). Но в массы это не пошло, а жаль - возможно мир стал бы гораздо проще.
Какого-то единообразия среди фреймворков и технологий нет. Каждый реализует протокол вмеру собственных предпочтений. Наименьший общим знаменателем становится OpenAPI (бывший Swagger). Но он определяет только формат, оставляя протокольную часть за рамками. Остальное решается на уровне соглашений, принятых в конкретной организации.
Я ни где не говорил, что это устарело. Скорее развилось и стало рутиной. А вот подходы к работе с PII поменялись радикально из-за необходимости соблюдать кучу юридических церемоний. В вашем решении данные не классифицируются, свободно передаваясь между компонентами. Поэтому с предложенной архитектурой бизнес влетит на мешок денег после первого же compliance report. Чтобы этого не произошло, такие требования нужно закладывать сразу. Попробуйте, вы сразу увидите как это заставит перекроить всю архитектуру.
Поэтому, если нет желания показывать свои навыки в проектировании конкретно приложений для обработки PII, для демо сейчас выбирают что-то более нейтральное, типа API прогноза погоды, котировок валют или подобное. Это будет в разы проще.
Что касается тестов, то писать их до или после это тактика. Главное, чтобы в конце они появились. :) Ну и линтер с тайпчекером прикрутить к CI вроде уже не экзотика.
Честно говоря двоякое чувство. С одной стороны интригующий выбор темы (с персональными данными, коммуникацией с госами), а с другой - реализация с массой недосказанностей. По сути я думал это статья к студенческой работе или тестовому заданию перспективного джуниора, пока не заглянул в профиль автора.
Софт без задефайненных non-functional requirements, quality attributes и код без тестов это прототип. На этом уровне техническая задача обычно сводится к тому, чтобы решение лишь бы хоть как-то работало. Работает? - вы молодец. Но дальше в отсутствии требований об архитектуре сервиса говорить нет смысла потому, что архитектура выбирается исходя из требований. Вы же понимаете, что допустим для достижения availablity 99.9 и 99.999 у вас будут два принципиально разных архитектурных решения и разницей по сложности и стоимости примерно на один-два порядка.
Но проблема даже не в этом. Принимая ФИО, паспортные данные и т.п., с точки зрения законодательства вы становитесь оператором персональных данных, со всеми вытекающими требованиями - к хранению, обработке и передаче. Я не увидел даже намека. Вы хотели отзыв: десять лет тому назад это выглядело бы даже неплохо (все эти базворды типа onion architecture, DI и т.п.). Но в 2023 предложенное решение - детский сад штаны на лямках - в решении уровня лида хочется все же видеть больше осмысленности.
http://kb.mozillazine.org/Chrome_URLs это древнючее наследие со времён XUL - оригинального UI движка на котором раньше работал браузер от Mozilla. Словом "chrome" там называют любые элементы браузера, кроме собственно содержимого web страницы. Отсюда одноименная адресация.
Всё это появилось гораздо раньше Google Chrome, и не имеет к нему отношения (скорее уж Google скосплеил название). about: появился позже, чтобы отвязаться от конкретной технологии.
Регеспы по сути это нотация для компактной записи грамматик. Писать структурированный и документированный код это ацкая мука, когда перед вами лишь командная строка). В общем я не спорю, тут все сводится к банальному - инструмент под задачу.
Это перевод, автор вряд-ли ответит). Вообще он преподаватель, изучил подход к теме в хаскеле и решил сделать так же питоне. Это решение не для продакшна.
Просто, если вы сможете реализовать принцип на другом языке, который может для этого не особо и предназначен, значит вы разобрались в теме, а не просто заучили мануал. Заодно это помогает лучше понять сильные и слабые стороны, а так же границы применимости того или иного подхода.
HashiCorp вроде заблокировали свои ресурсы для некоторых стран, сразу после начала конфликта. Интересно, как местные организации продолжают использовать Terraform, или ищут альтернативные варианты?
Мастерство заменим тщеславием. Рефлексию опыта сведём к самоедству. Возникла трудность - понизим самооценку. Глупости какие-то, не надо так делать.
Собеседование стоит начинать с простых вопросов, на которые собеседнику будет легко ответить. Это снимает стресс и создаёт позитивную атмосферу. Тут злую шутку играет разница культур.
Например, американцы любят говорить от первого лица и о себе, какие они молодцы и вообще классные ребята. В этом есть что-то немного детское. Как будто ребенок рассказывает своим родителям какой он герой, когда сделает что-то хорошее, и они все вместе приходят в умиление. Говорить о себе в позитивном ключе это приятная тема. Поэтому такой вопрос в начале собеседования звучит органично.
В восточной Европе ценится скромность. Рассказывать про себя хорошее - хвастаться, это некультурно. Можно рассказать про фейлы - т.е. покаяться. Это будет одобряемо, но кто хочет каяться незнакомым людям на первой же встрече? Единственное разумное объяснение - в таком предложении есть какой-то подвох. Поэтому просьба рассказать о себе имеет прямо противоположный эффект, вызывая у собеседника с порога шок и истерику (пусть даже внутреннюю).
На собеседовании смотрим знания, а навыки и умения - на испытательном сроке. Идея приятная, но выходит дороговато, причем для обоих сторон.
Разница между хорошим замечанием к коду и собственноручно написанным, как здесь между комментарием и статьёй. Допустим моим и вашей. Связать между собой пару предложений или сочинить текст на несколько страниц - согласитесь, разница по сложности колоссальна.
Разработка это борьба со сложностью. Мне уже несколько раз попадались сотрудники, которые красиво критикуют как синьоры, особенно если укажешь место. А сделать потом не могут - ведь количество деталей, которые прихится учитывать на практике, измеряется числами совсем другого порядка и требует колоссальной дисциплины.
Бизнес боится профсоюзов как огня. Поэтому допускаю что они могут запускать компании по дискредитации любых идеей сотрудников как-то между собой объединяться, чтобы отстаивать свои права. У текущего работодателя тоже нет профсоюзов, предыдущие попытки организовать были грамотно слиты.
Похоже на аниматоров только для программистов.
Вообще большие компании давно поняли, что если у сотрудника появляется возможность делегировать неудобную для себя деятельность кому-то другому, то они охотно этим пользуются. Например, кому нравится доказывать начальству преимущества очередного фреймворка или затевать разговор о повышении зарплаты с боссом? Тут на сцену выходят деврелы, которые охотно берут на себя эту функцию поговорить. Говорить о чужих проблемах же проще, тем более если язык растет из правильного места. Это даже работает, по началу.
В чем подвох? Что не тренируется - то не развивается. Персонал утрачивает навыки и больше не поднимает неудобные темы. Деврел отвечает лишь за нескучные мероприятия и пока он раздает клавиатуры аж за 15 тыщ, разработчики делают свою скучную работу за прежнюю зряплату, ради чего их собственно и нанимали.
Постснгшная аудитория всегда стремилась рассказать тем, кто пытается что-то делать, как они были неправы. Не обращайте внимания. Надеюсь вы сможете найти своего работодателя по профилю (или они вас).
Просто выходя на мировой рынок, вы начинаете конкурировать с такими же соискателями уже со всего мира. Это гораздо более жёсткая конкуренция, чем у себя дома.
Раньше можно было быть востребованным специалистом будучи самоучкой. Сейчас такие соискатели воспринимаются скорее как персонажи из мира фольклора. Нет, умение подковать условную блоху до сих пор вызывает восторг, но в целом платежеспособной индустрии нужно совсем другое. Сейчас разаботка ПО это конвейер.