Там перечислен конкретный список документов, один из которых нужно приложить к заявлению. Например, если в ранее выданном паспорте или ВНЖ написано иначе, то можно написать заявление.
Просто ваше желание, или документы, которые не указаны в том списке (например водительское удостоверение, договор с работодателем или профиль на GitHub) - принимать заявление отказываются.
Может где-то такое и есть. У текущего работодателя собесы кандидатов с рынка это рутина, заниматься которой ни кто не горит желанием. Но человеческий фактор стараются свести к минимуму.
Инженеры, проводящие тех.интервью, это обычно и без того загруженные работой ребята. Поэтому их отдельно мотивируют мелкими корпоративными спасибками за extra mile. Что-то кому-то доказывать - зачем? Потратить выделенный час, чтобы погонять кандидата по стандартному чек-листу, а потом ещё сколько совесть позволит на фидбек - очко в карму и ты можешь опять заниматься своими делами.
По-моему из мира DDD у него на глобусе не хватает ещё двух важных вещей: Bound Сontext и Aggregation Root. Первое является ответом на вопрос где проходят границы полномочий между участниками? Второе определяет рамки единичной транзакции (действия).
Когда границы и действия определены, а бизнес-операция состоит из нескольких действий разных участников, то следующие вопросы:
каким образом они общаются между собой?
и как решать проблемные ситуации по пути?
Ответом будет тот или иной Integration Pattern - в этой книжке их 65, но мне кажется автор немного гнался за количеством).
Так или иначе, ивенты это один из возможных вариантов: сделал свою работу - сообщи. Ивент не содержит модели в буквальном смысле. Это просто сообщение с какими-то признаками этих моделей. Компонент нотификации получает не самого пользователя и его заказ, а лишь кусок данных про них. Таким образом пользователю ни куда выбегать (за пределы своего саб-домена) не нужно.
почему мы вообще делаем такое предположение об интервьювере?
Ой нет, как раз это вообще здесь не важно. Я вставил лишить для того, чтобы завершить картинку с начальником штаба.
Общее с интервью здесь: простой вопрос, ограниченное время и судьбоносные выводы. Ну и фейл с ответом, иначе было бы банально, а не смешно.
На техническом вы действительно начинаете диалог с интервьюером. Даже если в итоге не наберёте достаточно заветных очков, то проведёте время в приятной компании.
В армии у начальника штаба был прикол: остановить молодого солдата и спросить "сколько будет две вторых плюс две трети?". Ну и пока тот соображает, о чем вообще речь, пытаясь вспомнить какие-то формулы из школьной программы третьего класса, - вставить "солдат, ты 	 тупой?" Ну и показав тем самым, кто здесь умнее, перейти к сути вопроса.
Противоречивость анекдотичность таких ситуаций на собесах как раз и состоит в том, в самих задачах для кандидатов нет ни чего сложного - в рабочем потоке такое решается, что называется, на рефлексах. Но формально они заваливаются.
Его ощущения мне вполне понятны. Летом тоже не прошел собеседование в одну известную компанию на роль разработчика. Хотя в прошлом сделал для них несколько проектов. Так же завалился в лайф кодинге на довольно простых алгоритмических задачках. Проблема была не в IDE - я иногда пишу код даже с телефона. Но включиться в игру и соображать голова почему то отказывалась. Оставил как повод поугорать над собой и ситуацией.
Ни в чем. Просто HA это как правила личной гигиены для отдельно взятого гексагона, а не - организации взаимодействия в их системе. Там просто по дедукции получается, что для взаимодействия нужно что-то придумывать, но эти вопросы уже за рамками.
Мы делим свой код на блоки-гексагоны, которые общаются исключительно контрактами друг с другом.
Гексагоны не могу общаться непосредственно друг с другом, поскольку каждый гексагон выставляет наружу свои контракты (ports) на только одному ему понятном языке.
Учить языки друг друга в их мире запрещено - чтобы не было соблазна случайно обзавестись на стороне порочными связями или вредными зависимостями.
Чтобы как-то общаться, они отращивают снаружи себе адаптеры, которые переводят с одного языка на другой (возможно даже через третий, на котором принято передавать сообщения на расстояние). В итоге простое и приятное в принципе занятие - перекинуться со знакомым парой слов - превращается в бюрократический ад.
Идея выглядит жизнеспособнной, когда у вас гексагон наделен богатым внутренним миром и есть что охранять. Если же задача системы состоит в основном в передаче друг другу каких-нибудь отчётов, то вся логика уходит в адаптеры, а гексагон оказывается голым прокси-менеджером. Тогда у стороннего наблюдателя возникает резонный вопрос: и ради чего весь этот огород?
По-моему гексагональная архитектура это больше про контакты с внешним миром и зависимости. Вот здесь (адаптеры) дёргают нас (за primary ports), вот здесь (адаптеров) дергаем мы (через secondary ports) - и контракты (сами ports), которые всегда на нашей стороне (у гексагона).
Гексагон хранит ссылки на всех secondary adapters. Поэтому в теории может общаться с ними как угодно - архитектура не накладывает на внутренние устройство гексагона ограничений. Здесь решение остаётся за разработчиком.
Знать про гексагональную архитектуру полезно. Но это скорее архитектурный паттерн, чем конкретная архитектура, не смотря на название, чтобы использовать при разработке приложения.
Идея отделить логику приложения от остального мира выглядит заманчиво. Но PortsAndAdapters это слишком просто, чтобы быть правдой. Как повод лишний раз задуматься о том, чтобы вынести IO по максимуму наружу это ок. Но дальше все сводится к конвенциям, которые на практике нарушить ни чего не стоит, а поддерживать - сложно и дорого.
Архитектор ПО это наверное software architect, который занимается архитектурой собственно приложения - на уровне пакетов, модулей, компонентов, классов.
Следующий уровень systems architect. Он делает так, чтобы разные приложения и информационные системы в организации работали вместе.
Solution architect это мостик между бизнесом и решениями его бизнесовых проблем. Он строит свои решения уже на уровне capabilities организации (которые включают в себя не только айтишные функции). Стоит ли ему писать код? Ну ни кто не запрещает, но это действительно не его основная задача.
Пока вы не привели ни одного конкретного доказательства массовости такого явления, я об этом не думаю. :)
И что же обозначает это Ваше thread - "поток выполнения", "резьба", или "нить"? :)
Если вопрос про исходную метафору, то здесь рядом кидал картинку с проводами.
Сам же по себе термин это просто узнаваемый набор букв. "pthread_create", "from multiprocessing.pool import ThreadPool" - вы наверняка распознаете правильно, если знакомы с этой концепцией.
документации на русском Вы не делаете принципиально, и статей/книг тоже принципиально не пишете?
Документацию пишу на английском - я работаю в международной компании, у меня ребята в команде из разных стран. Поэтому тема как найти всем общий язык (Ubiquitous Language если хотите) в общем-то больная.
Ну то есть я на тему насильственной русификации терминологии смотрю как на идею, допустим, китаизации - давайте сделаем свой китайский айти-язык, чтобы кроме китайцев его больше ни кто не понимал. Зачем? :)
Комментарии пишу тут на русском, терминологию - по разному. В неформальной беседе - скорее на русском. Если что-то конкретное или хочу избежать неоднозначностей, то в зависимости от первоисточника - чаще на английском. Но из-за этого часто путаю в предложениях порядок слов, поэтому нередко правлю комменты.
По ситуации. "вставить ифу" например. Я не говорю "вставить если" когда нужно "вставить if" - какой смысл переводить, заставляя разработчика догадываться о чем вообще идёт речь и потом переводить обратно?
Если нужен именно русский в программировании, то переделывать нужно всё, включая сами языки программирования. Я бы на самом деле с интересом посмотрел на ЯП, который получил преимущества именно из особенностей русского языка (а не тупо кальку английского).
А сколько сможете перечислить технических терминов, которые изначально были русскоязычными (таких немало), и в том же виде были заимствованы "западными" странами?
Нормальный ход. Мне кажется, изначально это был ваш аргумент - вот сами и перечисляйте. =)
Я понимаю, что Вам тупо лень заниматься [само]образованием, а вот стремления придать этой лени объективное обоснование - не понимаю.
Сейчас в основном читаю техническую литературу на английском. Мотивация выучить язык появилась как раз из-за того, что во-первых переводов нужно ждать по десять лет, когда информация уже успевает устареть. А во вторых - продираться сквозь ошибки и отсебятину переводчиков действительно лень.
Бонусом появилась возможность общаться с коллегами во всех уголках земного шара. Я ни разу не сталкивался с неправильной трактовкой термина thread: индусы, китайцы, англичане, французы - все произносят со своим специфичным акцентом (и это ни кого не парит), но понимают одинаково (а это главное). Слово одинаково пишется и в литературе, и в документации и в коде. Нет ни каких проблем. Проблемы когда в коде: "pot = new Potok(); pot.begi()" - потому, что так учили. Такие обороты в самом деле мало кто поймет. В этом ваша цель?
Вы хорошо выглядите в свои за шестьдесят, судя по аватарке.
почему современные русские охотно и бездумно тащат в свой язык любые иностранные термины
Россия интернациональная страна, где умение разговаривать на языке собеседника всегда считалось за добродетель. Поэтому общеупотребимые слова часто заимствовали. Не нужно ремонтировать то, что хорошо работает.
немцы, французы и прочие никогда не увлекались заимствованием русскоязычных терминов,
Troika, vodka, samovar, balalaika, tsar, soviet, perestroika, nginx. Сделайте что-нибудь уникальное, полезное для АйТи и слово с радостью утащат.
Пока одни решают проблемы перевода - другие занимаются наукой и придумывают новые термины, так что переводчики не успевают переводить. По большому счету все все время при деле.
Была какое-то время в некоторых движках. Но выпили. Как думаете, почему?
Там перечислен конкретный список документов, один из которых нужно приложить к заявлению. Например, если в ранее выданном паспорте или ВНЖ написано иначе, то можно написать заявление.
Просто ваше желание, или документы, которые не указаны в том списке (например водительское удостоверение, договор с работодателем или профиль на GitHub) - принимать заявление отказываются.
Цель - нанять подходящего. Обычно идеальный кандидат на негорящий проект: немного не дотягивает по силлам, мало просит, желает развиваться.
Брать звезду на всю котлету зарплатой вилки - вам понты или ехать?
Может где-то такое и есть. У текущего работодателя собесы кандидатов с рынка это рутина, заниматься которой ни кто не горит желанием. Но человеческий фактор стараются свести к минимуму.
Инженеры, проводящие тех.интервью, это обычно и без того загруженные работой ребята. Поэтому их отдельно мотивируют мелкими корпоративными спасибками за extra mile. Что-то кому-то доказывать - зачем? Потратить выделенный час, чтобы погонять кандидата по стандартному чек-листу, а потом ещё сколько совесть позволит на фидбек - очко в карму и ты можешь опять заниматься своими делами.
По-моему из мира DDD у него на глобусе не хватает ещё двух важных вещей: Bound Сontext и Aggregation Root. Первое является ответом на вопрос где проходят границы полномочий между участниками? Второе определяет рамки единичной транзакции (действия).
Когда границы и действия определены, а бизнес-операция состоит из нескольких действий разных участников, то следующие вопросы:
каким образом они общаются между собой?
и как решать проблемные ситуации по пути?
Ответом будет тот или иной Integration Pattern - в этой книжке их 65, но мне кажется автор немного гнался за количеством).
Так или иначе, ивенты это один из возможных вариантов: сделал свою работу - сообщи. Ивент не содержит модели в буквальном смысле. Это просто сообщение с какими-то признаками этих моделей. Компонент нотификации получает не самого пользователя и его заказ, а лишь кусок данных про них. Таким образом пользователю ни куда выбегать (за пределы своего саб-домена) не нужно.
Неплохой обзор этой темы в трёх частях у https://vaadin.com/blog/ddd-part-1-strategic-domain-driven-design.
Эти вообще творят, что хотят. По своим новым правилам трансляции они записали мне имя так, как я ни когда в жизни бы не додумался.
Ой нет, как раз это вообще здесь не важно. Я вставил лишить для того, чтобы завершить картинку с начальником штаба.
Общее с интервью здесь: простой вопрос, ограниченное время и судьбоносные выводы. Ну и фейл с ответом, иначе было бы банально, а не смешно.
На техническом вы действительно начинаете диалог с интервьюером. Даже если в итоге не наберёте достаточно заветных очков, то проведёте время в приятной компании.
В армии у начальника штаба был прикол: остановить молодого солдата и спросить "сколько будет две вторых плюс две трети?". Ну и пока тот соображает, о чем вообще речь, пытаясь вспомнить какие-то формулы из школьной программы третьего класса, - вставить "солдат, ты 	 тупой?" Ну и показав тем самым, кто здесь умнее, перейти к сути вопроса.
Противоречивостьанекдотичность таких ситуаций на собесах как раз и состоит в том, в самих задачах для кандидатов нет ни чего сложного - в рабочем потоке такое решается, что называется, на рефлексах. Но формально они заваливаются.Его ощущения мне вполне понятны. Летом тоже не прошел собеседование в одну известную компанию на роль разработчика. Хотя в прошлом сделал для них несколько проектов. Так же завалился в лайф кодинге на довольно простых алгоритмических задачках. Проблема была не в IDE - я иногда пишу код даже с телефона. Но включиться в игру и соображать голова почему то отказывалась. Оставил как повод поугорать над собой и ситуацией.
Знать и уметь
какие-то базовые вещиэто не одно и то же. Как будто он на детском утреннике ни разу не был, где карапузы уделывают взрослых только так.Ни в чем. Просто HA это как правила личной гигиены для отдельно взятого гексагона, а не - организации взаимодействия в их системе. Там просто по дедукции получается, что для взаимодействия нужно что-то придумывать, но эти вопросы уже за рамками.
Гексагоны не могу общаться непосредственно друг с другом, поскольку каждый гексагон выставляет наружу свои контракты (ports) на только одному ему понятном языке.
Учить языки друг друга в их мире запрещено - чтобы не было соблазна случайно обзавестись на стороне порочными связями или вредными зависимостями.
Чтобы как-то общаться, они отращивают снаружи себе адаптеры, которые переводят с одного языка на другой (возможно даже через третий, на котором принято передавать сообщения на расстояние). В итоге простое и приятное в принципе занятие - перекинуться со знакомым парой слов - превращается в бюрократический ад.
Идея выглядит жизнеспособнной, когда у вас гексагон наделен богатым внутренним миром и есть что охранять. Если же задача системы состоит в основном в передаче друг другу каких-нибудь отчётов, то вся логика уходит в адаптеры, а гексагон оказывается голым прокси-менеджером. Тогда у стороннего наблюдателя возникает резонный вопрос: и ради чего весь этот огород?
По-моему гексагональная архитектура это больше про контакты с внешним миром и зависимости. Вот здесь (адаптеры) дёргают нас (за primary ports), вот здесь (адаптеров) дергаем мы (через secondary ports) - и контракты (сами ports), которые всегда на нашей стороне (у гексагона).
Гексагон хранит ссылки на всех secondary adapters. Поэтому в теории может общаться с ними как угодно - архитектура не накладывает на внутренние устройство гексагона ограничений. Здесь решение остаётся за разработчиком.
В DDD это обозначается другими словами:
Primary adapters -> Application layer
Secondary adapters -> Infrastructure layer
Hexagon -> Domain model layer
Знать про гексагональную архитектуру полезно. Но это скорее архитектурный паттерн, чем конкретная архитектура, не смотря на название, чтобы использовать при разработке приложения.
Ну сам термин Hexagonal Architecture за это время стал узнаваем и часто мелькает в связке с Domain Driving Design (DDD) и Onion Architecture. Самая монументальная статья на эту тему из тех, что мне попадались https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/.
Идея отделить логику приложения от остального мира выглядит заманчиво. Но PortsAndAdapters это слишком просто, чтобы быть правдой. Как повод лишний раз задуматься о том, чтобы вынести IO по максимуму наружу это ок. Но дальше все сводится к конвенциям, которые на практике нарушить ни чего не стоит, а поддерживать - сложно и дорого.
Архитектор ПО это наверное software architect, который занимается архитектурой собственно приложения - на уровне пакетов, модулей, компонентов, классов.
Следующий уровень systems architect. Он делает так, чтобы разные приложения и информационные системы в организации работали вместе.
Solution architect это мостик между бизнесом и решениями его бизнесовых проблем. Он строит свои решения уже на уровне capabilities организации (которые включают в себя не только айтишные функции). Стоит ли ему писать код? Ну ни кто не запрещает, но это действительно не его основная задача.
Пока вы не привели ни одного конкретного доказательства массовости такого явления, я об этом не думаю. :)
Если вопрос про исходную метафору, то здесь рядом кидал картинку с проводами.
Сам же по себе термин это просто узнаваемый набор букв. "pthread_create", "from multiprocessing.pool import ThreadPool" - вы наверняка распознаете правильно, если знакомы с этой концепцией.
Документацию пишу на английском - я работаю в международной компании, у меня ребята в команде из разных стран. Поэтому тема как найти всем общий язык (Ubiquitous Language если хотите) в общем-то больная.
Ну то есть я на тему насильственной русификации терминологии смотрю как на идею, допустим, китаизации - давайте сделаем свой китайский айти-язык, чтобы кроме китайцев его больше ни кто не понимал. Зачем? :)
Комментарии пишу тут на русском, терминологию - по разному. В неформальной беседе - скорее на русском. Если что-то конкретное или хочу избежать неоднозначностей, то в зависимости от первоисточника - чаще на английском. Но из-за этого часто путаю в предложениях порядок слов, поэтому нередко правлю комменты.
По ситуации. "вставить ифу" например. Я не говорю "вставить если" когда нужно "вставить if" - какой смысл переводить, заставляя разработчика догадываться о чем вообще идёт речь и потом переводить обратно?
Если нужен именно русский в программировании, то переделывать нужно всё, включая сами языки программирования. Я бы на самом деле с интересом посмотрел на ЯП, который получил преимущества именно из особенностей русского языка (а не тупо кальку английского).
Нормальный ход. Мне кажется, изначально это был ваш аргумент - вот сами и перечисляйте. =)
Сейчас в основном читаю техническую литературу на английском. Мотивация выучить язык появилась как раз из-за того, что во-первых переводов нужно ждать по десять лет, когда информация уже успевает устареть. А во вторых - продираться сквозь ошибки и отсебятину переводчиков действительно лень.
Бонусом появилась возможность общаться с коллегами во всех уголках земного шара. Я ни разу не сталкивался с неправильной трактовкой термина thread: индусы, китайцы, англичане, французы - все произносят со своим специфичным акцентом (и это ни кого не парит), но понимают одинаково (а это главное). Слово одинаково пишется и в литературе, и в документации и в коде. Нет ни каких проблем. Проблемы когда в коде: "pot = new Potok(); pot.begi()" - потому, что так учили. Такие обороты в самом деле мало кто поймет. В этом ваша цель?
Вы хорошо выглядите в свои за шестьдесят, судя по аватарке.
Россия интернациональная страна, где умение разговаривать на языке собеседника всегда считалось за добродетель. Поэтому общеупотребимые слова часто заимствовали. Не нужно ремонтировать то, что хорошо работает.
Troika, vodka, samovar, balalaika, tsar, soviet, perestroika, nginx. Сделайте что-нибудь уникальное, полезное для АйТи и слово с радостью утащат.
Пока одни решают проблемы перевода - другие занимаются наукой и придумывают новые термины, так что переводчики не успевают переводить. По большому счету все все время при деле.