Яндекс продолжает набор на оплачиваемую летнюю стажировку.
Важно: отлично проявившие себя стажеры получат шанс перейти в штат!
Направления: фронтенд- и бэкенд-разработка, машинное обучение, аналитика, мобильная разработка и другие — ознакомиться с ними можно здесь.
Особый формат стажировки — Deep Dive в Яндекс.Маркете.
Сколько длится: от трех до 6 месяцев.
Где: в Москве, Санкт-Петербурге, Екатеринбурге, Нижнем Новгороде, Новосибирске, Сочи, Симферополе и Минске.
Если вы из другого города — Яндекс оплатит дорогу и проживание в Москве.
Что нужно уметь: ждут отличного знания базовых алгоритмов и уверенных навыков программирования на одном из языков.
Как проходит отбор: зависит от направления, но в большинстве случаев нужно будет выполнить тестовое задание, пройти два-три технических интервью, а затем выбрать команду.
Подавайте заявку до 31 мая: https://clck.ru/TgiBN
Важно: отлично проявившие себя стажеры получат шанс перейти в штат!
Направления: фронтенд- и бэкенд-разработка, машинное обучение, аналитика, мобильная разработка и другие — ознакомиться с ними можно здесь.
Особый формат стажировки — Deep Dive в Яндекс.Маркете.
Сколько длится: от трех до 6 месяцев.
Где: в Москве, Санкт-Петербурге, Екатеринбурге, Нижнем Новгороде, Новосибирске, Сочи, Симферополе и Минске.
Если вы из другого города — Яндекс оплатит дорогу и проживание в Москве.
Что нужно уметь: ждут отличного знания базовых алгоритмов и уверенных навыков программирования на одном из языков.
Как проходит отбор: зависит от направления, но в большинстве случаев нужно будет выполнить тестовое задание, пройти два-три технических интервью, а затем выбрать команду.
Подавайте заявку до 31 мая: https://clck.ru/TgiBN
Young&&Yandex ― старт карьеры в Яндексе
Экосистема стажировок и образовательных проектов — можно попробовать себя в IT, прокачать навыки и начать работать в Яндексе
Стоит ли публиковать в этот канал аудио вариант видосов с S0ER TALKS?
Anonymous Poll
51%
Да
16%
Нет
33%
На твое усмотрение
Некоторые интересные моменты, которые стоит зафиксировать из книги Бугаенко "Elegant Objects":
- Не используйте "er" в имени классов (runner, doer и т.д.)
- "Тонкие конструкторы класса" - только инициализации, без логики
- Мелкие классы, лучше крупных (при рефакторинге объединять проще чем делить)
- Не используйте "er" в имени классов (runner, doer и т.д.)
- "Тонкие конструкторы класса" - только инициализации, без логики
- Мелкие классы, лучше крупных (при рефакторинге объединять проще чем делить)
- Максимум 5 публичных методов в классе (помните про комбинатоную сложность, чем больше публичных методов, тем больше комбинаций между классами, использующих эти методы)
- Не используйте статические методы
- Не используйте синглтоны
- Избегайте NULL
- Не используйте статические методы
- Не используйте синглтоны
- Избегайте NULL
С остальными советами не согласен, некоторые нужно доработать, некоторые просто странные.
Интересное обсуждение случилось в дискорде по поводу правила "не используйте -er в именах классов". И тут, видимо, нужны какие-то развернутые пояснения, но лучше чем автор, этого никто не сделает, поэтому посмотрите объяснения у Егора - https://www.yegor256.com/2015/03/09/objects-end-with-er.html
Yegor Bugayenko
Don't Create Objects That End With -ER
Object names that end with -er are indicators of a flawed design in terms of object thinking and should be avoided.
👍2
Ну а мое отношение такое - я считаю, что паттерны (например, Observer) и "поведение" могут быть реализованы через класс, но нужно быть осторожным, так как лучше придерживаться максимально "чистого" ООП и создавать объекты, которые действительно являются объектами, а не абстрактной логикой.
Рома Труфанов написал хороший пост в тему:
Trufanov Roman — Сегодня, в 13:18
Вброшу немного своего мнения xD
Вообще про суффиксы все сказанное кажется немного вырванным из контекста.
Тут нужно строго зафиксировать несколько моментов.
- Мы говорим про ООП, то бишь про объекты и их взаимодействия.
- Также нужно учитывать возможность языка программирования.
- И также нужно учитывать контекст в котором приходится работать.
Если говорить чуть точнее, то нету ничего плохого в использовании каких бы то не было суффиксов. Как по мне, основная проблема это неправильно подобранная абстракция. К примеру если у нас в коде есть класс с названием Manager, то совсем непонятно что это за менеджер такой. Это может быть роль, тогда в таком названии нету ничего особенного. Также это может быть название какой то сущности, о которой говорит заказчик, тут надуманно конечно, но к примеру менеджер = система, которая управляет заказами. А вот что недопустимо, это придумывать класс Менеджер, которого нету в бизнес домене совсем. Ну к примеру у нас есть какая то логика и где же ее нужно разместить, вот и придумывают Менеджеров, Процессеров и прочие -еров.
Что касается использования названий паттернов, то также не обязательно писать суффикс (Adapter, Factroy и т.д.). Помним, что паттерн это не цель, а это то, что уже проявляется в коде. К паттерну приходят либо во время проектирования, когда понимают, что взаимодействие объектов похоже на определенный паттерн. Либо во время рефакторинга, когда получившаяся структура начинает быть похожа на опять определенный паттерн. Вот не разу не было качественного решения, где бы брали и стали пытаться насильно достичь использования конкретных паттернов. Это всегда связано с решаемой задачей и текущей ситуацией в коде.
Trufanov Roman — Сегодня, в 13:18
Вброшу немного своего мнения xD
Вообще про суффиксы все сказанное кажется немного вырванным из контекста.
Тут нужно строго зафиксировать несколько моментов.
- Мы говорим про ООП, то бишь про объекты и их взаимодействия.
- Также нужно учитывать возможность языка программирования.
- И также нужно учитывать контекст в котором приходится работать.
Если говорить чуть точнее, то нету ничего плохого в использовании каких бы то не было суффиксов. Как по мне, основная проблема это неправильно подобранная абстракция. К примеру если у нас в коде есть класс с названием Manager, то совсем непонятно что это за менеджер такой. Это может быть роль, тогда в таком названии нету ничего особенного. Также это может быть название какой то сущности, о которой говорит заказчик, тут надуманно конечно, но к примеру менеджер = система, которая управляет заказами. А вот что недопустимо, это придумывать класс Менеджер, которого нету в бизнес домене совсем. Ну к примеру у нас есть какая то логика и где же ее нужно разместить, вот и придумывают Менеджеров, Процессеров и прочие -еров.
Что касается использования названий паттернов, то также не обязательно писать суффикс (Adapter, Factroy и т.д.). Помним, что паттерн это не цель, а это то, что уже проявляется в коде. К паттерну приходят либо во время проектирования, когда понимают, что взаимодействие объектов похоже на определенный паттерн. Либо во время рефакторинга, когда получившаяся структура начинает быть похожа на опять определенный паттерн. Вот не разу не было качественного решения, где бы брали и стали пытаться насильно достичь использования конкретных паттернов. Это всегда связано с решаемой задачей и текущей ситуацией в коде.
На прошлых выходных участвовал в митапе по обсуждению архитектуры,
такое ощущение, что все специально делают одни и те же ошибки.
такое ощущение, что все специально делают одни и те же ошибки.
Список проблем, который я делал для архитектурных стримов, по прежнему актуален:
1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2 неформализованные требования и ограничения;
3 отсутствие метрик качества и контроля;
4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10 не фиксируется технический долг и он обычно уже большой;
11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12 Отсутствие тестирования, рефакторинга и прочих техник;
13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2 неформализованные требования и ограничения;
3 отсутствие метрик качества и контроля;
4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10 не фиксируется технический долг и он обычно уже большой;
11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12 Отсутствие тестирования, рефакторинга и прочих техник;
13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
👍2
Полный текст конспекта на эту тему - https://s0er.ru/codelabs/arch_stream_1/index.html?index=..%2F..index#4
Два основных элемента:
Аутентификация - проверка того кем является пользователь, т.е. по сути проверка личности
Авторизация - проверка того, что пользователь может сделать
Аутентификация - проверка того кем является пользователь, т.е. по сути проверка личности
Авторизация - проверка того, что пользователь может сделать
Вспомогательные процессы:
- аудит - это логировние данных, позволяющих восстановить порядок действий, которые выполнил пользователь. Используется для расследования нештатных ситуаций
- шифрование - основной способ сокрытия данных от доступа третьих лиц
- лимитирование - лимиты, как правило основаны на ограничении доступа к ресурсам. Но бывает и лимиты времени. Это позволяет противостоять атакам "грубой силы", когда у атакующего есть огромные вычислительные ресурсы.
- аудит - это логировние данных, позволяющих восстановить порядок действий, которые выполнил пользователь. Используется для расследования нештатных ситуаций
- шифрование - основной способ сокрытия данных от доступа третьих лиц
- лимитирование - лимиты, как правило основаны на ограничении доступа к ресурсам. Но бывает и лимиты времени. Это позволяет противостоять атакам "грубой силы", когда у атакующего есть огромные вычислительные ресурсы.