php-developer
Hello world!
Представляю вашему вниманию первую часть большой шпаргалки по Rust.
Другой формат, который может показаться вам более удобным.
Обратите внимание: шпаргалка рассчитана на людей, которые хорошо знают любой современный язык программирования, а не на тех, кто только начинает кодить 😉
Также настоятельно рекомендуется хотя бы по диагонали прочитать замечательный Учебник по Rust (на русском языке).
Самое страшное слово для инноватора или очень уж упёртого студента, который проходит практику у вас в компании: «Зачем?»
Знаете почему? Потому что в 80% случаев ответа вам на этот вопрос не дадут. Давайте разберёмся, причём здесь Оккам и что ему от нас нужно.
Задание: необходимо прочитать Micro QR Code версии М3, содержащий кодовое слово, состоящее из цифр (на примере – 777777777777777777 (18 цифр) и максимальном кодовом расстоянии (23 цифры) – 77777777777777777777777; почему выбрано именно такое количество цифр будет также расшифровано) на основе алгоритма, приведенного в ГОСТ Р ИСО/МЭК 18004-2015 (п. 7.4.3, пример 2). Аналогично версии М2 данный режим невозможно прочитать стандартными ресурсами мобильных устройств, производимых GAFAM (как оказалось, свободно распространяемые библиотеки страшно глючат, поэтому Ассоциация отказалась и от этого режима)
Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач.
Если спросить любого начинающего исследователя этой темы «А зачем нам оценка?», он скажет, что постоянно задают вопрос «Когда вы выполните эту задачу?», на который и надо ответить с помощью этой оценки. А что, если сам вопрос задан неверно?
Это перевод вступления из электронной книги - документа.
Авторы утверждают что:
В этой главе вы увидите, как можно удовлетворить некоторые из распространенных требований корпоративных приложений (приложений для бизнеса), таких как низкая стоимость (простота) сопровождения и тестируемость, применяя слабосвязанный дизайн для вашего приложения. Вы увидите очень простую иллюстрацию этого подхода в примерах кода, которые показывают два разных способа реализации зависимости между классами ManagementController и TenantStore. Вы также увидите, как принципы объектно-ориентированного программирования SOLID связаны с теми же проблемами (имеются ввиду проблемы стоимости сопровождения = исправления ошибок + возможности расширения функциональности и тестируемости).
Если у вас несколько лет опыта программирования на языке C, то, вероятно, вы гораздо более уверены в своих знаниях этого языка, чем если бы вы провели столько же времени, работая с C++ или Java. И язык C, и его стандартная библиотека довольно близки к к минимально возможному размеру.
Текущая наиболее часто используемая версия языка, c99, принесла много новых возможностей, многие из которых совершенно неизвестны большинству программистов на C (в более старых спецификациях, очевидно, тоже есть свои темные уголки).
Восхваляемая многими многозадачность не работает. Хватаясь за несколько дел сразу, мы в итоге не доделываем до конца ни одного. И наоборот, погрузившись в одно дело полностью и не отвлекаясь на посторонние раздражители, мы значительно повышаем нашу продуктивность. Осознанно фокусируя ограниченные ресурсы своего внимания на чём-то одном, мы глубже концентрируемся и мыслим более ясно.
Мы рассмотрим некоторые приёмы для погружения в состояние сверхконцентрации, о котором рассказывает Крис Бейли в своей книге «Гиперфокус». Они пригодятся всем, кто занимается сложной умственной работой, например, написанием кода, тестированием, разработкой архитектуры приложений и созданием уникальных алгоритмов.
Когда-то давно я мечтал стать программистом. Еще со средних класов школы начал ездить на олимпиады по программированию, писал игровые моды и просто нереально кайфовал от того, что делал. Начинал еще с Turbo Pascal, потом С, потом скриптовые языки, в универе математическое моделирование на С++ и matlab. Только в универе пришлось на теор.физике тусоваться, ибо не прошел по балах на программирование, но да ладно. Спустя 3 года я все таки решил кинуть физику, так как просто не видел денег в этой сфере в своей стране, и получил все таки первую долгожданном ИТ. Это была серверная разработка на Python.
С тех пор прошло уже 6 лет. Не могу сказать, что я сверх нерд и мое мнение авторитетное - но какой-то опыт в своей сфере все таки имею. Повидать успел с десяток различных компаний - от крупнейших в СНГ и крупных на диком западе, до мелких стартапов ( не думайте, что я во всех них успел поработать - это тема отдельная). Это печально...
Это список вопросов на которые должен уметь ответить тот кто хочет программировать микроконтроллеры и заниматься разработкой электроники. Вопросы в частности взяты из технических собеседований при устройстве на работу в разные компании. Постарался отобрать только самые приближенные к практике вопросы, которые можно выделить после 11 лет insider(ского) опыта.
Если вы знаете адекватные, сложные и интересные вопросы по теме разработки на MCU, то пишите их в комментариях.
Привет! Мы в QIWI довольно давно применяем микросервисную архитектуру, но ее понимание не всегда было одинаковым: оно менялось со временем и эволюционировало. Наши первые микросервисы были достаточно большие по объему, но сейчас мы создаем сервисы гораздо меньшего размера с более узкой и ограниченной зоной ответственности.
Часто такой сервис отвечает за конкретную небольшую фичу в нашем продукте (или вообще за часть фичи), или же за часть какого-то большого процесса. Нам такой подход нравится, поскольку микросервисы имеют независимые жизненные и релизные циклы, мы можем релизить фичи независимо друг от друга. Кроме того, различные команды могут работать в рамках одного продукта параллельно над разными фичами, не мешая друг другу и не сталкиваясь лбами. Это даёт нам возможность независимо масштабировать микросервисы и гораздо быстрее проверять гипотезы. В общем, плюсов много.
Сейчас будет «Но», правда?
Но в системе, которая состоит из большого количества маленьких взаимодействующих компонентов, становится критически важным такое качество, как наблюдаемость. Нам нужны как некие высокоуровневые метрики, показатели, чтобы видеть, как система живет в целом, так и для каждого компонента, для каждого нашего микросервиса —нужно видеть его текущие рабочие показатели и получать уведомления, если эти показатели выходят за пределы нормы. Поскольку новые фичи мы делаем часто, то и новые микросервисы мы разрабатываем часто, получилось так, что настройка дашбордов и конфигурация алертов превратились в такую рутину, которая отнимает существенную часть времени. Так что всё это хотелось бы автоматизировать.
— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.
Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».
Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…
И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.
Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.
Minio это простое, быстрое и совместимое с AWS S3 хранилище объектов. Minio создан для размещения неструктурированных данных, таких как фотографии, видеозаписи, файлы журналов, резервные копии. В minio также поддерживается распределенный режим (distributed mode), который предоставляет возможность подключения к одному серверу хранения объектов множества дисков, в том числе расположенных на разных машинах.
Цель этого поста настроить minio так чтобы каждый юзер мог работать только со своим bucket.
14 марта в Слёрм стартует курс «Безопасность проекта: аутентификация в Keycloak». Мы пообщались с его автором Виктором Поповым, техлидом DevOps-команды дирекции больших данных в X5 Group. Он рассказал, какие задачи помогает решать инструмент и кто его выбирает — стартапы или энтерпрайз. А также поделился мнением о перспективах Keycloak и о том, даёт ли умение работать с ним карьерные преимущества.
Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.
В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.
Довольно очевидно, что junior-разработчику и тимлиду требуется сильно различающийся набор навыков. И если в случае hard skills всё уже миллион раз проанализировано и посчитано, то о необходимом наборе soft skills в зависимости от должности мы можем только понимать на уровне ощущений и здравого смысла.
Более того, в нашей индустрии не принято говорить после собеседования, что кандидату отказано из-за его уровня soft skills, хотя мы даже не пытаемся конкретизировать, что конкретно в нём нас не устраивает. Вы наверняка слышали или сами употребляли фразы вроде «просто человек странный», «почему-то не нравится» или «чувствуем, что он не вольется в команду». Но почему? Что на самом деле с ним не так?
Я решил провести собственное исследование гибких навыков и сегодня хочу поделиться результатами. Расскажу, какие навыки важны на каждом из уровней разработчика — от джуниора до руководителя. А также, как их можно проверить на собеседовании и эффективно развить внутри компании.
