Привет! На связи Кристина, фронтенд-разработчик в отделе рекламных спецпроектов KTS.

Наша команда создает визуально эффектные проекты, цель которых — привлечь внимание пользователей. Мы постоянно экспериментируем с разными технологиями и подходами, и вот, наконец, добрались до 3D-анимаций. Недавно я начала изучать Three.js и хочу поделиться своим опытом.

В сети есть множество статей и уроков по Three.js для начинающих, но большинство из них — это теоретический материал. Я же хочу показать, как создавать 3D-анимации на практике. Эта статья будет первой в цикле о разработке простой игры, в которой нужно строить башню из блоков.

Для успешного прохождения туториала достаточно владеть JavaScript и ООП. Каждый этап сопровождается ссылкой на codepen с комментариями в коде. А в конце вас ждет играбельный codepen-блок: вы можете сразу посмотреть на промежуточный результат, в котором уже реализована базовая игровая механика. В статье же я пошагово разберу, как к этому результату прийти.

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

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

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

Но действительно ли это так? И что вообще значит «запустить»?

Ведь все так и делают)

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

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

Интро

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

Естественно, читаю не все (сорри, но темы, которые уже знакомы, проходят только поверхностный фильтр адекватности), однако часто встречается и то, что привлекает внимание и заставляет прочитать полностью и делать для себя заметки. Еще реже появляются статьи, которые прямо хочется прокомментировать или тем более перевести. В этот раз мне попалась отличная, но платная, статья The dark side of User Research: How cognitive biases taint results, которую не только захотелось перевести, но и дополнить собственными комментариями и ссылками.

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

К моим словам прошу относиться со здоровой долей скепсиса, ибо я не нейтив-спикер, а просто ИТшный переводчик-редактор (пусть даже и с 20-летним опытом).

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

Эту памятку или «дорожную карту» я опубликовал в своем телеграм-канале несколько месяцев назад, многократно её обкатал на проектах, и убедился в ее применимости — поэтому вешаю ниже.

Шагов в этой памятке 5:

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

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

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

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

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

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

Во времена, когда .NET был закрытой технологией только для Windows, за ним и языком C# закрепилась репутация платформы, которая отлично подходит для решения бизнес-задач, но непригодна для соревновательного программирования и написания высокопроизводительного кода.

Часто приходится слышать, что "шарпы медленные", особенно в контексте алгоритмических задач, например с timus.online и codeforces.com. И, увы, не только слышать, но и сталкиваться с реальными проблемами, связанными с особенностями платформы, получая Wrong Answer, Runtime Error, Memory Limit, Time Limit при корректном алгоритме.

Большинство этих проблем кроется в особенностях консольного ввода и вывода. Да и часто куда проще написать cin >> nили sc.nextInt(), чем int.Parse(Console.ReadLine()) или Console.ReadLine().Split().Select(int.Parse).ToArray(), из-за чего выбор падает на другой язык.

Далее я расскажу о распространённых проблемах с консольным вводом-выводом в .NET, и о том, как сделать ввод быстрым и удобным.

Когда я узнал об этом подходе, то первым ощущением было чувство, что меня где-то обманывают - или это какая-то ошибка и заблуждение, или от меня что-то скрывали все предыдущие годы обучения. Метод выглядел эффективным и удивительно простым в применении, но при этом я никогда не слышал о нём раньше. Как такое могло случиться?

Когда я говорю о простоте, то это не фигура речи. Если бы вы сидели напротив меня я уверен, что за 15 минут я научил бы ЛЮБОГО из вас. Ни знаний физики, ни знания математики не требуется. Это похоже на магию. Вы делаете простые операции с натуральными числами и ... в конце получаете все необходимые параметры схемы. В этом сила, красота и, возможно, проклятие этого подхода.

Если бы вы сидели напротив меня... но вы не сидите, и не так-то просто изложить всё это письменно. Я постарался. Если у меня получилось, то через 20 - 30 минут вы сможете рассчитать ЛЮБОЙ пассивный четырёхполюсник с линейными элементами.

Итак, засекаем время.

Некоторые IDE и текстовые редакторы парсят исходный файл целиком при каждом изменении, что может тормозить на больших файлах, а некоторые делают это построчно с помощью регулярных выражений, что тоже тормозит и не даёт качественной подсветки кода, т.к. теряется контекст. Для решения этих проблем в недрах GitHub был создан tree-sitter - инкрементальный парсер, который используют всё больше и больше проектов. Давайте разбираться зачем и почему.

В статье я хотел бы поделиться своим опытом написания инсталлятора для Windows с использованием инструмента Windows Installer XML Toolset (далее - Wix). К сожалению, несмотря на всю мощь данного инструмента, его использование сильно осложняется куцей документацией, старенькими кукбуками, вялыми ветками форумов и вытеснением .msi и .exe пакетов контейнеризацией. Однако, сегодня продолжают активно развиваться и создаваться программные продукты требующие развертывания на виндовой машине с использованием традиционных установочных пакетов.

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

Сегодня я хотел бы рассказать о генерации идеального лабиринта - алгоритмом Эллера. Статья подойдёт всем любителям алгоритмов.

Привет, Хабр! В свободное от работы время по вечерам мне нравится воплощать в жизнь свои сумасшедшие идеи. В один из таких вечеров родилась мысль реализовать компилятор кода в машину Тьюринга. Осознав всю тщетность бытия сложность реализации, было принято решение начать с чего-то более простого – симулятора простенького процессора со своим собственным ассемблером, в котором команды выполнялись бы с помощью различных состояний машины Тьюринга, а данные хранились бы на одной ленте. В конечном итоге удалось осуществить практически первоначальную задумку, а именно получить одну единственную машину Тьюринга, способную выполнять скомпилированную из NASM подобного ассемблера программу без какого-либо внешнего взаимодействия.

14 февраля 2022 года GitHub объявила о старте нативной поддержки диаграмм Mermaid.js в README-файлах GitHub. Нововведение помогло быстрее и эффективнее оформлять блок-схемы и графики для документации. До этого диаграммы вставлялись в виде изображений и если содержимое менялось, то надо было сначала нарисовать новое изображение, а потом вставлять его. Сейчас же можно просто исправить несколько строк в коде и система сгенерирует новый график.

Проблема традиционных цветовых пространств

RGB

• градиент красного — это цвета #000, #100, #200, #FEE, #FFFи т.д.;
• градиент зеленого — это цвета #000, #010, #020и т.д.;
• градиент синего — это цвета #000, #001, #002и т.д.;
• градиент желтого — это цвета #000, #110, #220и т.д.;
• градиент голубого — это цвета #000, #011, #022и т.д.;
• градиент пурпурного — это цвета #000, #101, #202и т.д.

• Яркость цветов увеличивается неравномерно: чем оттенок ближе к белому цвету, тем изменение яркости меньше;
• Яркость разных цветов различается: синий намного темнее остальных;
• Насыщенность также неравномерна: синий и красный выглядят «ненасыщенными» в правой части градиента.

Можно читать и не понимать, можно читать и понимать, а можно читать и понимать даже то, что не написано. Всё зависит от того, как, в какой форме и с каким настроением автор создал текст, передал ли он смысл, поделился ли ценной информацией или крутой историей. Ежедневно на Хабре выходит около 60-70 статей, не считая новостей — какие-то набирают десятки тысяч просмотров, какие-то еле дотягивают до тысячи. Иногда причины очевидны, а иногда даже мы, опытная команда Хабра, теряемся в догадках, что же не понравилось (или понравилось) читателям. Анализ чужих и собственных публикаций подтолкнул меня к этому лонгриду. Читать — не перечитать.

Здравствуйте, меня зовут Дмитрий Карловский и я… прилетел к вам на турбо-реактивном самолёте. Основная суть реактивного двигателя изображена на картинке.

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

Это — текстовая расшифровка выступления на SECON.Weekend Frontend'21. Вы можете посмотреть видео запись, прочитать как статью, либо открыть в интерфейсе проведения презентаций.