Тогда все сольется в один большой элемент
front-page__section-promo-subinfo-title
против
front-page__section-promo_subinfo-title
или даже
front-page__section-promo_subinfo_title
Необходимость возникает когда title в блоке действительно не один, а делить все на микроблоки уже слишком
Я тоже в свое время прозрел на этот счет
Отдельно добавлю, что если все таки нужно положить элемент в элемент, то для этого можно использовать одинарное подчеркивание. В связи с этим и удобно использовать именно — как разделитель для модификатора:
note__sidebar_title--size_m
Можно вечно жить на мирах кораблях, двигающихся на скоростях 0.1c относительно друг друга. Благодаря этому пространство относительно кораблей будет сжато во много раз и межзвездные путешествия между друг другом будут занимать короткое время. Но, относительно звезд время будет идти очень быстро, что приведет к проматыванию жизни вселенной, хорошо это или плохо.
Понимаю что решение приходит в голову с первой попытки, просто никто не застрахован от ошибок по невнимательности, а именно они на доске как камнем высечены. Вот я попробую с первой попытки написать этот код в комментарии на js. А потом вставлю в интерпретатор. Получится — хорошо, не получится — ладно.
for (const i = 0; i < 100; ++i) {
if (i % 3 === 0) {
console.log('Fizz');
} else if (i % 5 === 0) {
console.log('Buzz');
} else if…
}
здесь я замечаю что что-то идет не туда, и начинаю зачеркивать на бумаге. А еще, ну какой const i? Конечно же let. Да и нумерация должна начаться с 1 а не 0. (Я потратил всего 15 секунд, не страшно)
Вторая попытка
for (let i = 1; i <= 100; ++i) {
let a = i % 3;
let b = i % 5;
if (a === 0 && b === 0) {
console.log('FizzBuzz');
} else if (a === 0) {
console.log('Fizz');
} else if (b === 0) {
console.log('Buzz');
} else {
console.log(i);
}
}
Пробуем…
Получилось.
Я напишу, но он не скомпилируется или неправильно отработает, и это абсолютно нормально. Мне не нужна ide, но нужно средство запуска для тестирования. С третьей, четвертой правки все будет отлично работать. Бумажка и доска не дает возможности отладить код.
Завтра бизнес логика изменится, и станет x > 5 && x < 10
Юнит-тест по прежнему зеленый, а ситуация с x >= 10 не оттестирована.
Я это не к определению white-box-а пишу, просто наблюдение.
А поддержка всего этого…
Наверное также, как вы поддерживаете свои проекты. Просто держите в голове архитектуру, знаете ключевые точки, знаете где нужно добавлять объекты и расширения для новых функций. Я использую классическую модель игровых циклов, когда есть дерево объектов, каждый кадр по ним проходит обновление, во время событий срабатывают триггеры. Сервер работает на 30 fps, клиент на 60 fps. Благодаря математически корректным формулам равноускоренного движения, при разных fps на сервере и клиенте объекты все равно двигаются синхронно независимо от dt.
Еще добавлю gist основного update(dt) сервера на C++. Он не дублируется на клиенте за ненадобностью, на клиент приходят постфактум физика и события, то есть на клиенте столкновения не обсчитываются.
https://gist.github.com/dmitriy-lodyanov/38cd8e42c7bef4889cdd752fc3459166
Могу скопировать тройку классов из клиент-серверной игры в github gist
Классы с сервера, используют C++ биндинги, синхронизируются с клиентом.
то есть весь C++ код дублируется js кодом, чтобы каждый кадр был синхронизирован, и обновлялся с сервера только при изменении ключевых параметров на сервере (нажали кнопку, пришел новый вектор движения, нажали на дверь, пришло событие открытие двери). Этот код моего проекта, я могу его публиковать, но не стану публиковать весь проект.
Код не претендует на идеальный, но он и не плохой, где-то хорошо, где-то не очень.
https://gist.github.com/dmitriy-lodyanov/d0559323986a6faaf78b93e272690766
https://gist.github.com/dmitriy-lodyanov/f17f7613197b75e2109d075e65b42f89
https://gist.github.com/dmitriy-lodyanov/d59b3301d6247fcc3ec5c52895820dc6
Врят ли пара классов даст представление о целом проекте. Это простая mmorpg в стиле dark souls, с видом сверху.
Спасибо, здорово.
Из той же серии, массивы предпочтительнее списков в играх для хранения объектов, потому что создание\удаление объектов на сцене редкая операция, а итерация по ним происходит каждый кадр понесколько раз.
Без сарказма, а расскажите чем будут отличаться свойства очереди и стека реализованные поверх массива? Поверх списка мне все понятно, а вот по массиву сходу не очевидно. При добавлении и удалении элементов будут постоянные реаллокации массива, что плохо, но возрастет скорость итерирования объектов (а очередь и стек не про итерирование).
Ну если на то пошло, сама реализация ассоциативного массива это дерево.
Я так понял пост просто перечисляет наиболее встречаемые сущности организации данных под общепринятыми наименованиями.
Мне хорошо и легко поддерживать, честно.
Я выбирал этот концепт не из позиции сначала легко а потом будет выкручиваться, а с позиции легко на всех этапах.
Но так то да, вкусовщина.
Одни проблемы от мира вещей
front-page__section-promo-subinfo-title
против
front-page__section-promo_subinfo-title
или даже
front-page__section-promo_subinfo_title
Необходимость возникает когда title в блоке действительно не один, а делить все на микроблоки уже слишком
Отдельно добавлю, что если все таки нужно положить элемент в элемент, то для этого можно использовать одинарное подчеркивание. В связи с этим и удобно использовать именно — как разделитель для модификатора:
note__sidebar_title--size_m
for (const i = 0; i < 100; ++i) {
if (i % 3 === 0) {
console.log('Fizz');
} else if (i % 5 === 0) {
console.log('Buzz');
} else if…
}
здесь я замечаю что что-то идет не туда, и начинаю зачеркивать на бумаге. А еще, ну какой const i? Конечно же let. Да и нумерация должна начаться с 1 а не 0. (Я потратил всего 15 секунд, не страшно)
Вторая попытка
for (let i = 1; i <= 100; ++i) {
let a = i % 3;
let b = i % 5;
if (a === 0 && b === 0) {
console.log('FizzBuzz');
} else if (a === 0) {
console.log('Fizz');
} else if (b === 0) {
console.log('Buzz');
} else {
console.log(i);
}
}
Пробуем…
Получилось.
Давно уже добавили, но сейчас решил зайти поблагодарить, это очень приятно когда разработчик вводит улучшения по отзывам :)
Юнит-тест по прежнему зеленый, а ситуация с x >= 10 не оттестирована.
Я это не к определению white-box-а пишу, просто наблюдение.
Наверное также, как вы поддерживаете свои проекты. Просто держите в голове архитектуру, знаете ключевые точки, знаете где нужно добавлять объекты и расширения для новых функций. Я использую классическую модель игровых циклов, когда есть дерево объектов, каждый кадр по ним проходит обновление, во время событий срабатывают триггеры. Сервер работает на 30 fps, клиент на 60 fps. Благодаря математически корректным формулам равноускоренного движения, при разных fps на сервере и клиенте объекты все равно двигаются синхронно независимо от dt.
https://gist.github.com/dmitriy-lodyanov/38cd8e42c7bef4889cdd752fc3459166
Классы с сервера, используют C++ биндинги, синхронизируются с клиентом.
то есть весь C++ код дублируется js кодом, чтобы каждый кадр был синхронизирован, и обновлялся с сервера только при изменении ключевых параметров на сервере (нажали кнопку, пришел новый вектор движения, нажали на дверь, пришло событие открытие двери). Этот код моего проекта, я могу его публиковать, но не стану публиковать весь проект.
Код не претендует на идеальный, но он и не плохой, где-то хорошо, где-то не очень.
https://gist.github.com/dmitriy-lodyanov/d0559323986a6faaf78b93e272690766
https://gist.github.com/dmitriy-lodyanov/f17f7613197b75e2109d075e65b42f89
https://gist.github.com/dmitriy-lodyanov/d59b3301d6247fcc3ec5c52895820dc6
Врят ли пара классов даст представление о целом проекте. Это простая mmorpg в стиле dark souls, с видом сверху.
Из той же серии, массивы предпочтительнее списков в играх для хранения объектов, потому что создание\удаление объектов на сцене редкая операция, а итерация по ним происходит каждый кадр понесколько раз.
Я так понял пост просто перечисляет наиболее встречаемые сущности организации данных под общепринятыми наименованиями.
Я выбирал этот концепт не из позиции сначала легко а потом будет выкручиваться, а с позиции легко на всех этапах.
Но так то да, вкусовщина.