Спасибо. Основной вопрос, общаются ли они между собой или только с главой проекта. Так же интересно, надо ли уметь общаться, чтобы общаться с главой проекта.
Хотелось бы призвать людей которые критикуют какую-то практику на собеседованиях описать, как должно проходит собеседование с их точки зрения, и, желательно, каким именно опытом подкреплена их точка зрения (хотя бы это чисто теоретическая конструкция или испытано на людях и, желательно, сколько раз).
Тут хотелось бы ссылку на то как художники реально работают над одной картиной. Разрезают ли они холст на квадраты общаются и так далее — или метафора ничего не имеет общего с реальностью?
В моей практике программисты даже если они работают над задачами не связанными друг с другом периодически общаются для решения вопросов — один знает как искать утечки памяти, другой особенности какого-нибудь модуля и им придется обмениваться опытом. Еще иногда надо новичков обучать, иногда кто-то уходит в отпуск и хорошо, чтобы кто-то знал особенности того, что он сделал и так далее.
Ну я про это и говорю. Условно, если у вас порт (в терминах паттерна "hexagonal architecture") на уровне linq — то вы должны реализовать весь linq если надо присоединиться к чему-то другому. Если у вас репозиторий то там вы собираете только те запросы, которые реально используются вашим приложением — соответственно другая реализация должна реализовать только их.
В Tecture с одной стороны вы собираете используемое подмножество запросов, но в неудобной для подмены формы — вроде статических методов. Кстати, вы не задумывались сделать их instance методами? Типа не extension метод который вызывает запрос, а extension-метод, который инстанциирует репозиторий, который вызывает запрос или как-то еще.
Методические рекомендации к использованию вашей архитектуры требует вынесения всех запросов в слой query или допустимо фигачить мимо этого слоя?
Я тут не понимаю как связано второе и первое. Я, например, не впадаю в ступор каждый раз когда надо идти к зубному, но это не то, что мне хочется делать.
Я, правда, сам таких вопросов не задаю, но не понимаю отчего тут впадать в ступор. Резюме повторять необязательно, можно рассказать упрощенную версию адаптированную под конкретного человека. Боссу более общую технарю более подробную.
Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя.
Технический скилл это разве не часть его? По этой фразе такому конструктору логично было бы рассказать как раз какой именно технический скилл, каким опытом он подтвержден, какие задачи он умеет решать и любит, какие не любит и так далее.
Я думаю, на разных работах нужны разные люди. Возможно, есть какие-то места где нужны ультрагики и кто-то настолько в этом совершенен, что ему приставят секретаря-переводчика для общения с окружающими.
Где-то надо чтобы программист был аналитиком и сам понимал нужды пользователей.
Основная масса где-то посредине — не нужны не ультратехнические ни ультрасофтскиллы, но какая-то удобная смесь.
Затачиваясь же на технические фишки вместо (в жертву) коммуникативных
Тут вопрос, обязательно ли это "в жертву". Получая коммуникационные навыки можно открыть некоторые пути к получению технических скиллов от окружающих и некоторую энергию для получения скиллов другими способами (условно повысить качество отдыха в компании, например).
А мне показалось наоборот. В чистой архитектуре приложение не знает про то, что под ним, здесь оно имеет некоторое знание. Я бы даже сказал, что основная мысль автора, что для развесистой энтерпрайз аппликухи чистая архитектура недостижима и он предлагает некоторый практичный компромисс.
Например, бизнес код у автора работает с linq напрямую или посредством слоя "запросов" которые находятся в extension методах. В отличии от репозитория слой запросов нельзя подменить на другой (он в статических методах) в результате прикладной код зависит от linq.
Т.е. чтобы реализовать какой-то новый механизм хранения без изменения бизнес кода фактически надо реализовать некий эмулятор реляционки поверх (вместо того, чтобы реализовать только слой запросов к какому-то, возможно, более простому API).
Написано, да. Только вот без уточнения, что это поможет только при отсутствии направленной атаки на данную систему — это, мягко говоря, некорректно.
А почему вы считаете, что поможет только при отсутствии направленной атаки? При направленной атаке у 100% хакеров понимание неясности займет 0% ресурсов?
Т.е. если оператор опечатался в email или если админ неправильно настроил почтовый сервер или провайдер почтового сервиса потребовал другой протокол работы действия один и те же? Исправляем адрес базе?
Operators — <> уже заняты под редирект, выкрутились так
Escape Character — ` потому что \ в винде уже занято под разделитель файловых путей, а шелл предназначен во многом для работы с файлами
If Requires Curly Brackets — не знаю почему. Могу только добавить, что часто есть coding convention чтобы фигурные скобки ставили всегда, для читабельности.
Function Definitions — это достаточно часто в скриптовых языках потому, что определение функции это фактически команда добавить функцию в скоуп. Это можно сделать другой командой:
new-item -Name hello -Value { "Hello" }
Function Calls — думаю, так сделано чтобы легко определять свои команды и работать в привычном синтаксисе без лишних символов.
Script Syntax Check — автор текста, судя по всему, не знает, что такое поверка синтаксиса — он написал синтаксически правильный код.
Lack of Mandatory Variable Declarations — тут я согласен, неплохо бы включать строгий режим который этого не допускает.
Scope of Variables — это, наверное, средство предыдущего пункта. Если есть наследование областей видимости, то как отличать доступ к переменной из глобальной области к доступу из локальной с таким же именем — вот и решили, что если есть локальное присваивание это определение новой переменной. Никакого копирования, кстати, не происходит, это совершенно новая переменная. В питоне поступили по другому — для доступа к шлобальному контексту — ключевое слово global, но в функции контекст наследутся но изменять просто нельзя.
Словом, человек с опытом больших статических языков программирования применяет свои привычки к шеллу.
Шелл — это весьма специфический скриптоый язык. Вероятно так сделали, чтобы было привычнее админам, которые работали с cmd, command.com, bash и т.д.
Можете для сравнения посмотреть, на попытку сделать шелл на основе питона — ipython — там, например, чтобы вызвать исполнимый файл надо писать! перед командой
Спасибо. Основной вопрос, общаются ли они между собой или только с главой проекта. Так же интересно, надо ли уметь общаться, чтобы общаться с главой проекта.
Хотелось бы призвать людей которые критикуют какую-то практику на собеседованиях описать, как должно проходит собеседование с их точки зрения, и, желательно, каким именно опытом подкреплена их точка зрения (хотя бы это чисто теоретическая конструкция или испытано на людях и, желательно, сколько раз).
Тут хотелось бы ссылку на то как художники реально работают над одной картиной. Разрезают ли они холст на квадраты общаются и так далее — или метафора ничего не имеет общего с реальностью?
В моей практике программисты даже если они работают над задачами не связанными друг с другом периодически общаются для решения вопросов — один знает как искать утечки памяти, другой особенности какого-нибудь модуля и им придется обмениваться опытом. Еще иногда надо новичков обучать, иногда кто-то уходит в отпуск и хорошо, чтобы кто-то знал особенности того, что он сделал и так далее.
А еще код ревью
Как это устроено у вас?
А почему вайтбоард? Вроде про вайтбоард никто не говорил.
Речь идет обо всех технарях или о каком-то конкретном ;)?
Ну я про это и говорю. Условно, если у вас порт (в терминах паттерна "hexagonal architecture") на уровне linq — то вы должны реализовать весь linq если надо присоединиться к чему-то другому. Если у вас репозиторий то там вы собираете только те запросы, которые реально используются вашим приложением — соответственно другая реализация должна реализовать только их.
В Tecture с одной стороны вы собираете используемое подмножество запросов, но в неудобной для подмены формы — вроде статических методов. Кстати, вы не задумывались сделать их instance методами? Типа не extension метод который вызывает запрос, а extension-метод, который инстанциирует репозиторий, который вызывает запрос или как-то еще.
Методические рекомендации к использованию вашей архитектуры требует вынесения всех запросов в слой query или допустимо фигачить мимо этого слоя?
Я тут не понимаю как связано второе и первое. Я, например, не впадаю в ступор каждый раз когда надо идти к зубному, но это не то, что мне хочется делать.
Я, правда, сам таких вопросов не задаю, но не понимаю отчего тут впадать в ступор. Резюме повторять необязательно, можно рассказать упрощенную версию адаптированную под конкретного человека. Боссу более общую технарю более подробную.
Технический скилл это разве не часть его? По этой фразе такому конструктору логично было бы рассказать как раз какой именно технический скилл, каким опытом он подтвержден, какие задачи он умеет решать и любит, какие не любит и так далее.
Я думаю, на разных работах нужны разные люди. Возможно, есть какие-то места где нужны ультрагики и кто-то настолько в этом совершенен, что ему приставят секретаря-переводчика для общения с окружающими.
Где-то надо чтобы программист был аналитиком и сам понимал нужды пользователей.
Основная масса где-то посредине — не нужны не ультратехнические ни ультрасофтскиллы, но какая-то удобная смесь.
Тут вопрос, обязательно ли это "в жертву". Получая коммуникационные навыки можно открыть некоторые пути к получению технических скиллов от окружающих и некоторую энергию для получения скиллов другими способами (условно повысить качество отдыха в компании, например).
А мне показалось наоборот. В чистой архитектуре приложение не знает про то, что под ним, здесь оно имеет некоторое знание. Я бы даже сказал, что основная мысль автора, что для развесистой энтерпрайз аппликухи чистая архитектура недостижима и он предлагает некоторый практичный компромисс.
Например, бизнес код у автора работает с linq напрямую или посредством слоя "запросов" которые находятся в extension методах. В отличии от репозитория слой запросов нельзя подменить на другой (он в статических методах) в результате прикладной код зависит от linq.
Т.е. чтобы реализовать какой-то новый механизм хранения без изменения бизнес кода фактически надо реализовать некий эмулятор реляционки поверх (вместо того, чтобы реализовать только слой запросов к какому-то, возможно, более простому API).
Еще PWA работает в песочнице — не может повредить компьютеру. Т.е. безопасность веб приложений + своя иконка тема, окно, офлайн и так далее.
А почему вы считаете, что поможет только при отсутствии направленной атаки? При направленной атаке у 100% хакеров понимание неясности займет 0% ресурсов?
Я предлагаю обобщить более корректно. В общем случае что-то делать. Потому, что использовать другой канал связи не всегда возможно или рационально.
Т.е. если оператор опечатался в email или если админ неправильно настроил почтовый сервер или провайдер почтового сервиса потребовал другой протокол работы действия один и те же? Исправляем адрес базе?
http://crockford.com/javascript/javascript.html
Operators — <> уже заняты под редирект, выкрутились так
Escape Character — ` потому что \ в винде уже занято под разделитель файловых путей, а шелл предназначен во многом для работы с файлами
If Requires Curly Brackets — не знаю почему. Могу только добавить, что часто есть coding convention чтобы фигурные скобки ставили всегда, для читабельности.
Function Definitions — это достаточно часто в скриптовых языках потому, что определение функции это фактически команда добавить функцию в скоуп. Это можно сделать другой командой:
Function Calls — думаю, так сделано чтобы легко определять свои команды и работать в привычном синтаксисе без лишних символов.
Script Syntax Check — автор текста, судя по всему, не знает, что такое поверка синтаксиса — он написал синтаксически правильный код.
Lack of Mandatory Variable Declarations — тут я согласен, неплохо бы включать строгий режим который этого не допускает.
Scope of Variables — это, наверное, средство предыдущего пункта. Если есть наследование областей видимости, то как отличать доступ к переменной из глобальной области к доступу из локальной с таким же именем — вот и решили, что если есть локальное присваивание это определение новой переменной. Никакого копирования, кстати, не происходит, это совершенно новая переменная. В питоне поступили по другому — для доступа к шлобальному контексту — ключевое слово global, но в функции контекст наследутся но изменять просто нельзя.
Словом, человек с опытом больших статических языков программирования применяет свои привычки к шеллу.
Шелл — это весьма специфический скриптоый язык. Вероятно так сделали, чтобы было привычнее админам, которые работали с cmd, command.com, bash и т.д.
Можете для сравнения посмотреть, на попытку сделать шелл на основе питона — ipython — там, например, чтобы вызвать исполнимый файл надо писать! перед командой
Они не шеллы. Шелл был cmd. И синтаксис похож на него.
А как вы это узнали?
Да, поэтому когда надо перелезать участок забора рефакторят.