IT всякое
Cпустя три недели после выхода на работу, мой новый программист пишет такой же код, как и трое моих других опытных разработчиков, которые на том же проекте около года. В свою очередь эти трое создают единую архитектуру, дают одинаковые названия сущностям и пишут чистый код, что сильно упрощает проведение code review и облегчает всем понимание кода.
Скоро выйдет релиз 1.18 в котором появятся долгожданные дженерики. Они позволят сделать универсальные методы. Я написал пару примеров для себя. Может быть они будут интересны кому-нибудь ещё.
Эксперименты с созданием редактора диаграмм на Blazor Webassembly (Blazor WebAssembly: Drag and Drop в SVG, Blazor WebAssembly: соединительные линии в SVG) показали что технология не годится для интенсивных манипуляций с DOM.
То что будут проседания было известно заранее: WebAssembly не имеет доступа к DOM, любые изменения только через вызовы JavaScript. Задержки оказались такими большими, что перетаскивание на мобильном тормозило уже после добавления третьей фигуры.
Брокер сообщений RabbitMQ уже давно активно используется в микросервисах. Он используется, когда требуется асинхронная обработка сообщений от клиентов или при аналогичном межсервисном взаимодействии.
Практически нет языка, под который не была бы сделана соответствующая клиентская библиотека. Для Go такой библиотекой является github.com/streadway/amqp (далее по тексту библиотека amqp). Она имеет широкий функционал, можно подключаться к RabbitMQ, создавать каналы, настраивать очереди и exchange. Не хватает только самой малости – реконектов. А именно автоматических реконнектов при потери связи.
Поиск в Google показывает, что есть много различных решений. На проекте, где я работаю, мы создали ещё парочку. Но не найденные в сети, не уже созданные не устраивали по ряду причин:
Привет, друзья!
В этой статье я покажу вам, как создать полноценный сервис для аутентификации и авторизации (далее — просто сервис) с помощью Auth0.
Auth0 — это платформа, предоставляющая готовые решения для разработки сервисов любого уровня сложности. Auth0 поддерживается командой, стоящей за разработкой JWT (JSON Web Token/веб-токен в формате JSON). Это вселяет определенную уверенность в безопасности Auth0-сервисов.
Бесплатная версия Auth0 позволяет регистрировать до 7000 пользователей.
В этой статье я писал о том, что такое JWT, и как разработать собственный сервис с нуля.
Знакомство с Auth0 можно начать отсюда.
Исходный код Auth0 SDK, который мы будем использовать для разработки приложения, можно найти здесь.
Исходный код проекта, который мы будем разрабатывать, находится здесь.
В статье я расскажу только о самых основных возможностях, предоставляемых Auth0.
В примерах и на скриншотах ниже вы увидите реальные чувствительные данные/sensitive data. Это не означает, что вы сможете их использовать. После публикации статьи сервис будет удален.
Поиск работы в американских компаниях, особенно с прицелом на будущий переезд – это всегда актуальная тема. Я сам живу в США уже более пяти лет, прошел все стадии профессиональной эмиграции, запустил здесь не один бизнес и нанял немало людей.
В этой статье я собрал материалы для тех, кто задумывается о поиске сначала удаленной работы в США, а затем и о переезде. В тексте есть описания виз, списки компаний, нанимающих на remote, инструменты для подготовки к собеседованиям. Надеюсь, будет полезно!
Есть настоящие профи по управлению проектами или те гении, которые придумывают изящные решения для заказчика. Однако почти в каждом, даже самом многообещающем проекте рано или поздно возникают проблемы. Иногда эти проблемы принимают монструозные масштабы, и команда проекта уже не может справиться с ними самостоятельно. И я тот самый человек, который их решает. Как я это делаю - тема отдельной статьи. Почему практически каждый раз получается? Ответ прост: всегда полезен взгляд со стороны. Однако наступил момент, когда этого оказалось мало. Я вляпался в настоящий факап, и единственным выходом из него были переговоры.
Признаюсь честно, у меня как у программиста, хоть и не настоящего, есть недоверие к «no-code» решениям. То есть тем, которые не требуют программирования, где всё можно делать через drag-and-drop и клики мышкой. Но после полугода разработки собственного «no-code» ETL сервиса с визуализацией данных я изменил отношение к этому классу продуктов, начал ими пользоваться и даже получать пользу, экономя время на рутинных операциях по анализу данных из логов, баз данных и файлов.
В этой заметке я предложу несколько вариантов загрузки и парсинга данных из сервисов и по URL с «материализацией» в SQL базу, покажу как за пару минут собрать свой информер с отправкой в Telegram, Slack или на email. И всё это произойдет без единой строчки кода (потому что в сервисе TABLUM.IO этот код уже кто-то написал ;-). «Алхимия данных» начинается под катом.
Напишем вместе HTTP-сервис на golang с нуля? Я уверен, что это довольно несложно. Для тех, кто каждую неделю этим занимается, моя статья не будет особенно интересна, но я все равно рекомендую взглянуть и оценить, возможно, ваши комментарии спасут кому-то жизнь. А может кое-какие из моих рассуждений спасут вашу.
Эта статья будет полезна тем, кто некоторое время назад начал осваивать язык программирования golang и уже достиг того момента, когда может попробовать окунуться в полный цикл разработки микросервисов на этом языке. Также она подойдет тем, кто решил сменить профильный язык, и по каким-то причинам его выбор пал на golang. Я не буду останавливаться на очевидных вещах вроде конструкций языка, парадигм конкурентности и прочего, но уделю время архитектуре приложения и постараюсь заострить внимание на моментах, в которых разработчик может допустить ошибку.
Это первая часть. Первые шаги в нашем нелегком пути. И в этой статье мы попробуем достичь следующих целей:
Сегодня рассмотрю архитектурный паттерн CQRS и его возможное место в вашей архитектуре. Также осуществим его реализацию на языке golang.
Привет, меня зовут Костя Кардаманов, я работаю в отделе технологий разработки Яндекса. Обычно такой же фразой я приветствую и кандидатов на собеседовании. А сегодня я хотел бы рассказать вам, как и зачем мы проводим интервью по дизайну систем с бэкенд-разработчиками. Сразу скажу: для фронтендеров, мобильных разработчиков и ML-инженеров подобный тип собеседований применим слабо, так что эти специальности мы здесь обсуждать не будем. 
На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):
Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc?
Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.
Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.
Изначально проект назывался Road-To-Barcelona, позже стал Road-To-Berlin (отсюда встречающиеся на скриншотах R2B), а в итоге и вовсе был назван xRide.
Основная идея проекта была в следующем: вместо того чтобы иметь централизованный сервис проката автомобилей или скутеров (речь пойдет о скутерах aka электро-мотоциклах, а не kickscooter/самокатах) мы хотели сделать платформу для децентрализованной аренды. О сложностях с которыми мы столкнулись уже писали ранее.
Изначально проект ориентировался на автомобили, но из-за сроков, крайне долгих общений с производителями и огромного количества ограничений по безопасности, для пилота были выбраны электрические скутеры.
Пользователь устанавливал iOS или Android приложение на телефон, подходил к понравившемуся ему скутеру, после чего телефон и скутер устанавливали peer-to-peer соединение, происходил обмен ETH и пользователь мог начать поездку включив скутер через телефон. По завершении поездки так же можно было провести оплату поездки за счет Ethereum из кошелька пользователя на телефоне.
Помимо скутеров пользователь видел в приложении "умные зарядки", посетив которую пользователь мог сам сменить текущую батарею, если она разрядилась.
Так в целом и выглядел наш пилот, запущенный в сентябре прошлого года в двух городах Германии: Бонн и Берлин.
И вот, однажды, в Бонне, ранним утром наша команда поддержки (находящаяся в локации для поддержания скутеров в работоспособном состоянии) была поднята по тревоге: один из скутеров бесследно исчез.
Как его найти и вернуть?
В этой статье я расскажу об этом, но для начала — о том как мы построили нашу собственную IoT платформу и как мы осуществляли мониторинг над ней.
Удалёнка в хорошей зарубежной компании — крутая штука. Сидя даже где-то далеко в провинции, можно зарабатывать большие деньги: от $3,000 в месяц на средненькой позиции в неизвестной компании до $186,000 в год на позиции senior programmer в Basecamp.
Работая из дома, вы можете развиваться в международной среде: заводить полезные знакомства и практиковать английский с людьми со всего света. При этом семья и друзья по-прежнему рядом. А если в будущем вы захотите переехать за границу, у вас уже будет релевантный опыт и критически важные навыки коммуникации.
У меня получилось так же: спустя почти два года тимлидерства в американской компании, я уехал в другую страну — но по-прежнему считаю удалёнку «за доллары» очень крутым вариантом занятости, по многим пунктам даже существенно лучше переезда за границу.
С вами Громов, и в первой статье из цикла я помогу вам оценить свои шансы устроиться разработчиком в хорошую компанию, где основной язык — английский.