1. Форма кредитной карты

Клёвая форма кредитной карты с гладкими и приятными микровзаимодействиями. Включает форматирование чисел, проверку и автоматическое определение типа карты. Она построена на Vue.js, а также полностью адаптивная. (Посмотреть можно здесь.)



credit-card-form

Чему научитесь:

• Обрабатывать и валидировать формы
• Обрабатывать события (например, при изменении полей)
• Разберетесь как отображать и размещать элементы на странице, особенно данные кредитной карты, которая поверх формы

Казалось бы, какой пост может быть о CSS Flexbox в 2019 году? Верстальщики уже несколько лет активно используют данную технологию, и все тайны должны быть разгаданы.

Однако, недавно у меня возникло стойкое ощущение, что нужно поделиться одним нетривиальным и, на мой взгляд, полезным приёмом, связанным с flexbox. Написать пост побудил тот факт, что ни один знакомый (из учеников, верстальщиков и просто людей, близких к web), не смог решить задачку, связанную с flexbox, хотя на это нужно всего 4-6 строк.

О пользе продуктового мышления сейчас можно услышать из каждого утюга. Действительно, оно необходимо не только менеджерам продуктов, но и всей команде. Тогда мы действительно будем делать качественный продукт, который обладает максимальной ценностью для нашего клиента.
Однако мало где можно прочесть, что это и в чем проявляется.

Ниже хочу изложить свое видение этого процесса.

На одном из митапов у меня спросили: «Как можно протестировать есть у меня продуктовое мышление или нет?» И я подумал, что статью можно рассматривать как диагностический инструмент. Читая каждый пункт, постарайся честно ответить на вопрос: «Есть это у меня или еще есть над чем поработать?»

Наверно, многие задумывались над тем, как можно реализовать свои знания в готовом продукте. Кто-то больше, кто-то меньше потратил на это времени. Хочу поделиться с сообществом своим опытом и видением, как это надо делать правильно, но не всегда получается.

MassTransit это open source библиотека, разработанная на языке C# для .NET платформы, упрощающая работу с шиной данных, которая используется при построении распределенных приложений и реализации SOA (service oriented architecture).

В качестве message broker могут выступать RabbitMq, Azure Service Bus или In-Memory менеджер (в случае с In-Memory область видимости ограничивается процессом, в котором проинициализирован экземпляр).

В этой статье будет рассказано как с помощью Masstransit и Quartz настроить шедулер для отправки сообщений в шину. Шина это абстракция слабой связи между тем кто посылает сообщения и тем кто подписывается на них через шину. Посылатель и приниматель сообщений знают только тип сообщения(это интерфейс), но не знают ничего друг о друге.

Однажды перед нами встала задача автоматизировать различные workflow в крупной компании. Для нас это значило соединить воедино на момент старта порядка 10 систем. Причем связать всё надо было асинхронно, масштабируемо, надежно.

Упрощённо процесс можно описать как последовательность действий в разных системах, которую нельзя автоматизировать полностью, поскольку она требует человеческого участия. Например, для выбора определенных действий или элементарного согласования, которое необходимо для перехода на следующий этап процесса.

Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.

Продолжая серию статей о новшествах в С#7, акцентирую внимание на, пожалуй, главных нововведениях — Pattern matching и Record type(Примерный перевод «регистрируемые типы»). Эти функционалы дополняют друг друга, поэтому лучше рассказывать о них вместе.

Состояние — поведенческий шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния. Классическая реализация предполагает создание базового абстрактного класса или интерфейса, содержащего все методы и по одному классу на каждое возможно состояние. Шаблон представляет собой частный случай рекомендации «заменяйте условные операторы полиморфизмом».

Казалось бы, все по книжке, но есть нюанс. Как правильно реализовать методы не релевантные для данного состояния? Например, как удалить товар из пустой корзины или оплатить пустую корзину? Обычно каждый state-класс реализует только релевантные методы, а в остальных случаях выбрасывает InvalidOperationException.

Нарушение принципа подстановки Лисков на лицо. Yaron Minsky предложил альтернативный подход: сделайте недопустимые состояния непредставимыми (make illegal states unrepresentable). Это дает возможность перенести проверку ошибок со времени исполнения на время компиляции. Однако control flow в этом случае будет организован на основе сопоставления с образцом, а не с помощью полиморфизма. К счастью, частичная поддержка pattern matching появилась в C#7.

Я намеревался написать 1/2 достойного поста в блоге об операторах F #, но потом я подумал, и, честно говоря, я не мог видеть слишком много достоинств в простом повторении того, что уже свободно доступно на MSDN, где перечисляются ВСЕ операторы F#.

При работе с любым языком вам, скорее всего, нужно будет отформатировать текст, и F# ничем не отличается.

Поскольку F# является языком .NET, мы всегда можем использовать Console.WriteLine (..) и String.Format (..), где мы можем использовать любой из обычных форматеров, которые вы использовали в своем обычном коде .NET.

Однако F# также поддерживает более похожий на синтаксис метод C, который доступен в модуле Core.Printf. Одна функция внутри него может использоваться вместо использования класса Console.WriteLine (..) .NET.

Как многие из вас знают, я парень из C#. Поэтому, если я просто хочу что-то попробовать, я обычно просто открываю LINQPad и пробую что-то там. Если всё разрастается и мне нужно больше контроля над экспериментами, я откажусь от LINQPad и разверну приложение ConsoleApplication в Visual Studio. Оба эти подхода работают нормально, но было бы неплохо, если бы существовала какая-то среда, в которой вы могли бы попробовать что-то внутри самой Visual Studio, даже не создавая новый проект.

К счастью, в F# это есть.

Мы в компании DIRECTUM занимаемся разработкой ECM-системы DirectumRX. Основным элементом модуля Workflow для ECM-системы является движок. Он отвечает за изменение состояния экземпляра процесса (инстанса) по ходу жизненного цикла. Перед тем, как начать разрабатывать модуль Workflow, стоит решить: взять готовый движок или написать свой. Изначально мы пошли по первому варианту. Мы взяли движок Windows Workflow Foundation (WF), и в целом он нас устраивал. Но со временем мы поняли, что нам нужен свой движок. Как это случилось, и что из этого вышло, расскажу ниже.

Платформа .NET предоставляет множество готовых примитивов синхронизации и потокобезопасных коллекций. Если при разработке приложения нужно реализовать, например, потокобезопасный кэш или очередь запросов — обычно используются эти готовые решения, иногда сразу несколько. В отдельных случаях это приводит к проблемам с производительностью: долгим ожиданием на блокировках, избыточному потреблению памяти и долгим сборкам мусора.

Эти проблемы можно решить, если учесть, что стандартные решения сделаны достаточно общими — они могут иметь избыточный в наших сценариях оверхед. Соответственно, можно написать, например, собственную эффективную потокобезопасную коллекцию для конкретного случая.

Под катом — видео и расшифровка моего доклада с конференции DotNext, где я разбираю несколько примеров, когда использование средств из стандартной библиотеки .NET (Task.Delay, SemaphoreSlim, ConcurrentDictionary) привело к просадкам производительности, и предлагаю решения, заточенные под конкретные задачи и лишённые этих недостатков.

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

Все эти системы отличали большие масштабы: их создавали сотни разработчиков — или они использовали их в своих разработках — и сегодня они бьются в сердцах систем, которыми ежедневно пользуются миллионы людей. Причем, эти проекты создавались не с нуля. Система платежей должна была заменить две другие существующие платежные системы, используемые десятками других систем и дюжинами команд, и все это — без какого-либо ущерба для бизнеса. Переписывание приложения Uber было проектом, над которым одновременно работало несколько сотен инженеров — он включал в себя портирование всей существующей функциональности на новую архитектуру.

Каждый раз перед собесом я говорю себе: "Спокойно, не нужно ничего выдумывать, доучивать и врать, твоих знаний и опыта достаточно для того, что бы работать у них. Ты усилишь любую команду, тебе есть что предложить, а пробелы в твоих знаниях — приемлемы. Если бы они знали о твоих навыках всё, что знаешь ты, они бы точно тебя взяли". Но когда начинается собеседование, я всегда перестаю в это верить. Все два часа интервью я хожу как по минному полю, что бы не дай бог не спалиться, что я чего-то не знаю.

Мое мнение, что WebAssembly будущее интернета. Данная технология на текущий момент уже интегрирована в большинство современных браузерах (а точнее в их движках) на ПК и мобильных устройствах. В таких браузерах как Chrome, Edge, Firefox, и WebKit.

В данной статье я опишу как начать разработку сайта WebAssembly в Visual Studio. Статья подойдет для тех, кто хотел бы понять, как начать разрабатывать SPA приложения без использования JavaScript, зная только asp.net mvc, c#, верстку html и css.

На момент выхода статьи фреймворк NetCore 3 находится в стадии RC1, а Blazor имеет версию 3.0.0-preview9.19457.4. Релиз NetCore 3 запланирован на сентябрь 2019. Что относительно Blazor то его релиз обещают позднее в ноябре 2019 года, скорее всего после релиза NetCore 3.1

Оглавление:

• I Установка
• II Создание проекта WebAssembly из шаблона
• III Структура решения
• IV Запуск и отладка WebAssembly blazor
• V Размеры файлов и linker
• VI Публикация и LazyLoading, библиотеки элементов
• VII Выводы

Необходимое вступление

Я не гарантирую, что изложенные здесь трактовки общепринятых терминов и принципов совпадают с тем, что изложили в солидных научных статьях калифорнийские профессора во второй половине прошлого века. Я не гарантирую, что мои трактовки полностью разделялись или разделяются большинством IT-профессионалов в отрасли или научной среде. Я даже не гарантирую, что мои трактовки помогут вам на собеседовании, хоть и предполагаю, что будут небесполезны.

Но я гарантирую, что если отсутствие всякого понимания заменить моими трактовками и начать их применять, то код вами написанный будет проще сопровождать и изменять. Так же я прекрасно понимаю, что в комментариях мной написанное будут яростно дополнять, что позволит выправить совсем уж вопиющие упущения и нестыковки.

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Привет, Хабр!

С помощью YouTube можно ощутимо и сравнительно быстро улучшить английский.
Понимание на слух как минимум. Истина не нова, но мало кто смотрит английский YouTube, потому что легко потеряться в бесконечности каналов. Но для вас я собрал самые стоящие каналы!

Добавляйте в закладки и подписывайтесь на меня!
Дальше вас ждет много крутых статей.

Поучить английский

AJ Hoge. На его канале есть всё: от базовых слов до размышлений о важности языка тела в общении. Чувак пилит видосы уже много лет, материальчик накопился.

EngVid. Если бы можно было выбрать что-то одно для улучшения английского, то это оно. Разные преподы и тематики, постоянное обновление, бездонный ресурс. Ещё сайт одноимённый крутой, с удобной навигацией — можно найти очень узкую тему по интересам.

Пять лет назад меня осенила идея. Я решил смоделировать ни много ни мало мировую экономику, для того чтобы точно знать какую динамику ожидать от акций, облигаций, курсов валют и т.д. Была только одна маленькая проблемка, модели всего этого не существует. И хуже того, экономисты десятки лет спорят, какая из их куцых эконометрических моделей хотя бы приблизительно верно описывает эти сложнейшие процессы. Поэтому, вместо попыток натянуть выдуманную (и конечно безумно упрощенную) модель на многоликую реальность я вступил на концептуально иной путь – моделировать агентов на микроуровне, чтобы они в изнуряющей борьбе за выживание, путем проб и ошибок приходили к равновесному состоянию, которое на макроуровне выражается в динамике цен, ставок и т.д.

Результат моих исследований описан ниже. Для визуализации записал движение агентов и каждый пиксель в этом видео, скрывает за собой нейросеть, т.е. мозг агента, бьющегося за выживание в конкуренции с подобными себе в жестоком мире наживы и чистогана.


Зачем это вообще нужно легко понять, например, по актуальным сейчас спорам вокруг «торговых войн». Одни (в основном профессиональные экономисты) говорят, что тарифы вредят в конечном итоге экономике в целом. Другие же думают, что страна окажется в выигрыше.

Проверить и доказать на фактах тут ничего нельзя, ведь никто не может поставить эксперимент при прочих равных на одной и той же экономике. Тогда как описанный ниже метод позволяет контролировать условия и получить доказательство наличия или отсутствия выгод того или иного решения.