Написав уже не одну статью про Veeam Academy, мы решили приоткрыть немного внутренней кухни и предлагаем вашему вниманию несколько примеров на C#, которые мы разбираем с нашими студентами. При их составлении мы отталкивались от того, что наша аудитория — это начинающие разработчики, но и опытным программистам тоже может быть интересно заглянуть под кат. Наша цель — показать, насколько глубока кроличья нора, параллельно объясняя особенности внутреннего устройства C#.

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

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

Как оптимизировать обработку изображений в рантайме, когда необходимо создать 6 изображений, каждое из которых состоит из последовательно наложенных 15-16 PNG, не получив OutOfMemoryException по дороге?

Продолжаем говорить о самых обсуждаемых на Hacker News открытых проектах. Сегодня рассказываем о решениях для работы с репозиториями и блокчейнами.

Предыдущие части:

• Инструменты для управления облаком
• Сервисы для работы с логами и базами данных

Добрый день! Сегодня достаточно часто по TV и каналам на youtube можно увидеть эксперименты по “определению уровня интеллекта” у населения. Суть их заключается в том, что взрослым людям задают вопрос из школьной программы. Обычно такие “эксперименты” набирают множество просмотров и большое количество лайков. Можно видеть большое количество комментариев под ними с обсуждениями деградации населения. На мой взгляд, в таком подходе спрятана одна серьезная психологическая ловушка. Давайте попробуем разложить все по полочкам, провести расследование и выяснить так ли это.

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

Для этого я постарался на более-менее живых примерах объяснить базовые понятия ООП (класс, объект, интерфейс, абстракция, инкапсуляция, наследование и полиморфизм).

Первая часть посвящена классам, объектам и интерфейсам.
Вторая часть, представленная ниже, иллюстрирует инкапсуляцию, полиморфизм и наследование

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

Как быть тому, кто работает один? На что ориентироваться, стремясь выстроить чёткий и эффективный рабочий процесс? Каким принципам и правилам следовать? Предлагаем вместе поискать ответы на эти вопросы.

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



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

Улучшаем внешний вид

1. Material Theme & Icons

Это прямо зверь в темах VS Code. Я думаю, что материальная тема наиболее близка к написанию ручкой на бумаге в редакторе (особенно при использовании неконтрастной темы). Ваш редактор выглядит практически гладко, переходя от встроенных инструментов к текстовому редактору.

Представьте себе эпическую тему в сочетании с эпическими иконами. Material Theme Icons — отличная альтернатива для замены значков VSCode по умолчанию. Большой каталог иконок плавно вписывается в тему, делая ее красивее. Это поможет легко найти файлы в проводнике.

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

Хорошие примеры доступных сайтов у Пенсионного Фонда и Госуслуг. Чтобы ваш ресурс стал доступным, такой масштабной работы, как для ПФР, не требуется. Достаточно применить три принципа, добавить в закладки два сайта с подробной документацией по разработке доступных сайтов и немного адаптировать рабочий процесс под новую парадигму. В результате ваши ресурсы перейдут на новую ступень: будут доступными и удобными для людей с ограниченными возможностями.

О том, как быстро и эффективно разрабатывать доступные ресурсы сегодняшняя расшифровка доклада Сергея Кригера на Frontend Conf.

В этот раз дело начиналось после закрытия методов audio в методе execute.

Я решил посмотреть, как получают музыку сайты, которые предоставляют возможность ее скачать. Меня заинтересовал сайт vrit.me.

Я залез во вкладку network и увидел интересный запрос:


То есть, можно подделать POST запрос к этому сайту, и использовать его, как API для музыки vk, что я сразу и реализовал:

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



В этом руководстве, которое рассчитано на начинающих разработчиков, имеющих знания в области HTML, JavaScript и CSS, будут рассмотрены основы React и самые распространённые ошибки, с которыми может столкнуться программист, пользующийся данной библиотекой.

Недавно сайт Fog Creek взял у меня интервью, и один из вопросов был связан с моими любимыми книгами по программированию, кодированию и разработке программ. Мне этот вопрос запомнился потому, что я давно себя считаю заядлым книжным ботаником. Книжный ботаник я потому, что безумно люблю книги о науке, компьютерах и программировании. Каждые несколько месяцев я уделяю день или два исследованию недавно изданной литературы и покупке наиболее понравившихся экземпляров. Я мог бы вечно разговаривать о своих любимых книгах. Ведь у меня их так много.

Меня настолько заинтересовал вопрос о книгах, что я решил начать новую серию статей на своём сайте catonmat о моих топ-100 книгах о программировании, программном обеспечении, науке, физике, математике и компьютерах. В каждой статье я буду размещать по пять книг, ведь разбивать огромное задачи на маленькие подзадачи — это самый простой способ их решать (GTD — get things done).

Взгляните на мою книжную полку, чтобы убедиться, что я настоящий ботаник:

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

Материал, перевод которого мы публикуем сегодня, посвящён рассказу о внутренних механизмах замыканий и о том, как они работают в JavaScript-программах.

Сегодня, в переводе седьмой части руководства по Node.js, мы поговорим об асинхронном программировании, рассмотрим такие вопросы, как использование коллбэков, промисов и конструкции async/await, обсудим работу с событиями.

Предлагаю вашему вниманию перевод очень крутой статьи по анимации интерфейса.
The ultimate guide to proper use of animation in UX автора Taras Skytskyi.



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

Привет всем!

Сегодня вашему вниманию предлагается перевод по-своему незаменимой статьи, которая поможет вам правильно подойти даже к самому коварному и нетривиальному ТЗ, которого вы на первый взгляд в упор не понимаете. Главное — не сдаваться и толково формулировать вопросы. Господин Джастин Фуллер из «Бэнк оф Америка» любезно излагает, как это правильно делается.



Приятного чтения!

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

Еще в далеком 1976 швейцарский ученый Никлаус Вирт написал книгу Алгоритмы + структуры данных = программы.

40+ лет спустя это уравнение все еще верно. И если вы самоучка и надолго в программировании пробегитесь по статье, можно по диагонали. Можно код кофе.

Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

Примечание переводчика: эту замечательную статью не перевели для Хабра ни в начале года, ни позднее. При том что она действительно полезная и заслуживает внимания. Поэтому, несмотря на то, что почти ⅔ 18-го года уже прожиты, я всё-таки решилась на перевод. Заодно сравнила прогнозы с реальностью, о чём оставила комментарии по тексту.

Внимание: под катом много тяжёлых гифок и красоты!

У разработчика, который впервые столкнулся с генерированием электронных писем, практически нет шансов написать приложение, которое будет делать это корректно. Около 40 % писем, генерируемых корпоративными приложениями, имеют те или иные нарушения стандартов, и, как следствие, проблемы с доставкой и отображением. На это есть причины: электронная почта технически гораздо сложнее, чем веб, работа почты регулируется несколькими сотнями стандартов и несчетным количеством общепринятых (и не очень) практик, а почтовые клиенты отличаются разнообразием и непредсказуемостью. Тестирование может заметно улучшить ситуацию, но материалов, посвященных тестированию почты, практически нет.

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

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов