Новый график на Moiva.io с данными от #StateOfJS
Автор популярных ежегодных отчетов #StateOfJS и #StateOfCSS Sacha Greif (он же автор VulcanJS и Sidebar) обратился ко мне с идей включить данные отчета на Moiva.io.
Я ответил "Конечно!"
Автор популярных ежегодных отчетов #StateOfJS и #StateOfCSS Sacha Greif (он же автор VulcanJS и Sidebar) обратился ко мне с идей включить данные отчета на Moiva.io.
Я ответил "Конечно!"
Всем привет! Меня зовут Вова, я фронтендер в Тинькофф. Сейчас перед нашей командой стоит задача редизайна функциональности на пересечении нескольких продуктов. Данная ситуация заставила нас задуматься во-первых о DDD, а во-вторых о гибкости наших решений, применяемых при разработке, и достичь этого нам помогли принципы SOLID, а точнее OCP и Dependency Inversion (не путать с Dependency Injection), о чем и хочется дальше поговорить.
На текущий момент я работаю в компании Мегафон тим лидом фронта. С начала этого года мы в команде Мегафона разрабатываем собственную платформу Интернета вещей. И так как, в таком процессе нагрузка на бек-энд разработчиков стала колоссальная, а фронт не так активно задействован, внутри отдела было принято решение отдать всю веб-часть в руки моей команды. Очевидно, что мы взяли NodeJs, и занялись построением серверной архитектуры и тд.
Для корректного доступа до собранных с устройств данных, естественно, нужна была авторизация, что бы понимать, кто и что может получить/сделать.
Мы все используем опенсорсные продукты, но немногие решаются туда законтрибьютить. Помимо банальной лени, есть и более серьёзные причины: сложность или корявость самих проектов, а также боязнь показать миру свой код.
На осеннем TechTrain Андрей Солнцев (asolntsev) и Артем Ерошенко (eroshenkoam) показали на примере Allure и Selenide, как справиться с техническими и психологическими трудностями. Прямо во время доклада они сделали изменения в опенсорсных проектах.
Под катом — расшифровка их доклада и видео с фестиваля. Далее повествование будет от лица спикеров.
Одним из проектов над которыми мне пришлось недавно поработать, стало создание складской системы для распознавания складируемых деталей. Проблема достаточно простая для понимания: на промышленном складе кладовщики, особенно новые, при поступлении новой партии, зачастую не могут с ходу понять что за детали поступили, и куда их нужно отнести.
Данная статья является сборкой-компиляцией нескольких (основано на первой) статей, как результат моих изучений по теме jwt аутентификации в джанге со всем вытекающим. Так и не удалось (по крайней мере в рунете) найти нормальную статью, в которой рассказывается от этапа создания проекта, startproject, прикручивание jwt аутентификации.
PS. Это перевод моей статьи на английском. Давно я не писал на Хабре. Сразу прощу прощения, много на русском не пишу. Не скажу что у меня и английский шикарный. Но к сожалению проживание за рубежом ухудшает мой русский и медленно развивает английский.
Если вы пользуетесь AWS Athena для анализа логов, то часто хочется найти источник IP адресов. К сожалению AWS Athena не предоставляет этого из коробки. К счастью MaxMind предоставляет базы данных GeoIP таблиц, которые позволяют вычислить местоположение по IP адресам. Есть платная и бесплатная версия.
В этой статье я покажу как создать AWS Lambda функцию, которая каждую неделю будет скачивать последнюю базу данных с MaxMind на S3. Эту базу данных можно использовать в AWS Athena для написания SQL запросов для анализа, например, веб логов.
А помните ли вы свой первый мобильный телефон? Для меня это была Nokia 3310, неубиваемая «трубка», неустанно радовавшая меня скудным набором развлечений в виде игры в змейку, WAP и чудесных монофонических рингтонов. За последние тридцать лет индустрия шагнула далеко вперед. И это ещё мягко сказано: мобильные чипы приближаются по производительности к современным компьютерам, а две самые популярные на текущий момент системы — Android и iOS — предоставляют практически безграничные возможности для создания приложений на любой вкус.
Оплата по NFC, заказ такси буквально за пару свайпов, и даже тот же Instagram настолько плотно вошли в нашу жизнь, что необходимость создания мобильного клиента для своего бизнеса теперь уже не вызывает вопросов. Стандартом разработки в этом случае принято считать нативные приложения. Они работают плавно, имеют привычный пользователям UI и UX, а также доступ к разнообразным аппаратным возможностям смартфона и его операционной системы. Из основных недостатков этого подхода можно отметить необходимость иметь в штате выделенных iOS- и Android-разработчиков, возникновение сложностей в организации тестирования, и более длительный, по сравнению с web, релизный цикл. Нельзя забывать и про сегментацию: часть пользователей предпочитает оставаться на старых версиях приложения, старых версиях iOS и Android, обожают свои старые телефоны. Поэтому ненайденный в релизе баг, просочившись в сторы, напоминает землетрясение с долгим афтершоком.
Если у вас уже есть команда опытных мобильных разработчиков и налажен CI, то кажется, что выбор очевиден. Но зачастую бывают ситуации, когда время запуска функциональности в прод играет решающую роль, а постоянные обновления не идут на пользу репутации приложения. Хотя бы раз в жизни, каждый из нас брал кредит, или, по крайней мере, всерьез задумывался об этом. Обычно этот процесс включает в себя заполнение анкеты. Представим, что такая анкета есть у вас на сайте и в мобильном приложении. И вот банк решил освободить зарплатных клиентов от половины полей — это, безусловно, прекрасно, но влечет за собой изменения на сайте, а также в iOS- и Android-приложениях. Учитывая нашу асинхронность релизных циклов, а также возможность появления багов при обновлении, возникает риск получить три разные анкеты на неопределенный срок. А если подобные изменения нужно вносить часто?
Хочу рассказать о том, как мы оптимизировали наш оркестратор микросервисов.
Потому что в случае с такого рода сервисами наш любимый подход "пихаем в базу - строим индексы" не работает. Как минимум потому что базы нет).
В статье расскажу про общие подходы к оптимизации оркестраторов, что и как мы пробовали, как переходили с блокирующего RestTemplate на неблокирующий WebClient.
Как пытались подружить его с CompletableFuture, как положили прод, как нашли проблему, и какие сделали из всего этого выводы.
Забегая вперёд, могу сказать, что переход на неблокирующий веб-клиент для нашего оркестратора, в разы увеличил производительность, а ещё, если думаете использовать WebClient совместно с CompletableFuture, то лучше не надо имеет смысл кое-что проверить.
После прочтения статьи "Как готовить Cake, используя только Frosting" мне пришла в голову мысль: "Какой большой проект для такого простого процесса сборки".
Представляю Getting Started по другой системе сборки, основанной на C# — Nuke.
Привет, хабровчане. Сегодня я хочу осветить и обсудить тему локализации (L10N) и интернационализации (I18N). В интернете и, в том числе и на Хабре уже есть полезные и интересные статьи, но часто они дают более-менее общую информацию о подходах, без углубленной информации о том, что и как можно проверить. Я бы хотел с вами поделиться своим опытом, просуммировать кое что из статей, которые вы можете найти в интернете, а также постараюсь описать большой checklist с самыми распространёнными кейсами как для локализации, так и для интернационализации. В чеклистах я буду стараться упоминать только те проверки, которые вы можете сделать сами, без (глубоких) знаний языка новой для вас локали.