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



Мы продолжаем цикл из 27 статей на основе его лекций:

01/02: «Понимание модели OSI» Часть 1 / Часть 2
03: «Понимание архитектуры Cisco»
04/05: «Основы коммутации или свитчей» Часть 1 / Часть 2
06: «Свитчи от Cisco»
07: «Область использования сетевых коммутаторов, ценность свитчей Cisco»
08/09: «Основы беспроводной локальной сети» Часть 1 / Часть 2
10: «Продукция в сфере беспроводных локальных сетей»
11: «Ценность беспроводных локальных сетей Cisco»
12: «Основы маршрутизации»
13: «Строение роутеров, платформы маршрутизации от Cisco»
14: «Ценность роутеров Cisco»
15/16: «Основы дата-центров» Часть 1 / Часть 2
17: «Оборудование для дата-центров»
18: «Ценность Cisco в дата-центрах»
19/20/21: «Основы телефонии» Часть 1 / Часть 2 / Часть 3
22: «Программные продукты для совместной работы от Cisco»
23: «Ценность продуктов для совместной работы от Cisco»
24: «Основы безопасности»
25: «Программные продукты Cisco для обеспечения безопасности»
26: «Ценность продуктов Cisco для обеспечения безопасности»
27: «Понимание архитектурных игр Cisco (обзор)»

И вот первая из них.

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

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

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

Предполагается, что студент должен страдать самостоятельно освоить ноты, путем многократного повторения. И вообще, если «ниасилил», значит у тебя нет Таланта — иди мести двор.

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

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

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

Приближается 2018 год, и технари — в частности веб-разработчики — должны отбросить многие старые методики и верования в сфере разработки защищённых PHP-приложений. Особенно это относится ко всем, кто не верит, что такие приложения вообще возможны.

Это руководство — дополнение к электронной книге PHP: The Right Way с сильным уклоном в безопасность, а не общие вопросы программирования на PHP (вроде стиля кода).

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

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

Важные замечания:

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

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

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

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

Тогда как это удаётся играм?

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

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

В этой работе мы сосредоточимся не на скорости, а на чётком объяснении концепций. Код примеров написан наиболее понятным образом, который не обязательно является самым эффективным для реализации алгоритмов. Есть множество способов реализации, я выбрал тот, который проще всего понять.

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

Генерация SVG из изображений может использоваться для Placeholder’ов.

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

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

В этом посте мы рассмотрим следующие темы:

• Обзор различных типов Placeholder’ов
• Placeholder на основе SVG (контуры, фигуры и силуэты)
• Автоматизация процесса.

Этот туториал посвящён эволюционным вычислениям, тому, как они работают и как реализовать их в своих проектах и играх. После прочтения статьи вы сможете овладеть мощью эволюции для поиска решений задач, решить которые вы не способны. В качестве примера в этом туториале будет показано, как эволюционные вычисления можно использовать для обучения простого существа ходьбе. Если вы хотите ощутить мощь эволюционных вычислений в браузере, оцените Genetic Algorithm Walkers.

Часть 1. Линейные структуры

Массив

Когда вам нужен один объект, вы создаёте один объект. Когда нужно несколько объектов, тогда есть несколько вариантов на выбор. Я видел, как многие новички в коде пишут что-то типа такого:

// Таблица рекордов
int score1 = 0;
int score2 = 0;
int score3 = 0;
int score4 = 0;
int score5 = 0;

Это даёт нам значение пяти рекордов. Этот способ неплохо работает, пока вам не потребуется пятьдесят или сто объектов. Вместо создания отдельных объектов можно использовать массив.

// Таблица рекордов
const int NUM_HIGH_SCORES = 5;
int highScore[NUM_HIGH_SCORES] = {0};

Будет создан буфер из 5 элементов, вот такой:



Заметьте, что индекс массива начинается с нуля. Если в массиве пять элементов, то они будут иметь индексы от нуля до четырёх.

Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.

Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.

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

Источник

Привет, Хабр! Представляю вашему вниманию перевод статьи Test Contra-variance

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

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

Предлагаю всем близким к фронтенду посмотреть доклады с прошедшего в августе митапа Frontend MIX. Приглашенные спикеры из Альфа-Лаборатории, Яндекс.Денег и Epam делятся нюансами мобильной оптимизации и выбора между Npm v5, Yarn или pnpm, а также секретами построения дизайн-системы на БЭМ и React.

Под катом вы найдете три видео.

XI Специфицируем требования

Требование — всего лишь временный посредник для решения проблемы реального мира.
«Фабрики разработки программ» [8]

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

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

В данной статье я не буду вам рассказывать о больших веб-фреймворках, таких как React, Angular, Vue и т.д… не будет в ней и перечня наиболее популярных текстовых редакторов – Atom, VS Code, Sublime… В данной статье я поделюсь с вами инструментами, которые, по моему мнению, могут сделать рабочий процесс веб-разработчиков более простым и быстрым.

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

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

IX Определение поведения системы.

В очень многих случаях поведение … только потому кажется смешным, что причины его, вполне разумные и основательные, скрыты от окружающих.
Франсуа де Ларошфуко

После того как мы определились с перечнем основных сценариев и сущностей предметной области, необходимо сопоставить их друг с другом.

Цель данной группы работ: на основании выявленных сущностей и процессов, разрабатываемого целевого продукта спроектировать поведение системы, распределив ее по классам.

Вступление

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

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

Привет.

Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.