Pull to refresh
142
0
Алексей Сигов @OpenMinded

User

Send message
По мнению первого заместителя комитета Госдумы по информационной политике Леонида Левина, анонимайзеры используют люди, которые намереваются совершить какие-то незаконные действия, или те, кому есть что скрывать.

По-моему, тут все просто. Всем есть, что скрывать. У всех есть право скрывать информацию о себе. Даже если это информация о намерении совершить незаконное действие. Запрет на скрытие подобной информации граничит с нарушением права не свидетельствовать против себя.
В воксельных движках кубики используются только для хранения данных о структуре и форме объектов и для манипуляций с этими данными. Потому что манипулировать структурой кубиков проще для процессора, чем манипулировать сеткой полигонов. Но графический процессор не умеет работать с кубиками. Поэтому используются алгоритмы для создания сетки полигонов на основе кубиков. Подобная генерация поверхности делается не каждый кадр, а только при изменениях структуры объекта. При этом могут использоваться алгоритмы для сглаживания поверхности, чтобы кубики были не так очевидны.
Скриншот от novator
Интересное решение. Я бы оставил рамку только у активного элемента, убрал уголок и сделал рамку одного цвета с активным текстом.
Не Doom 3, но близко и тоже занятно.
Это как с квейком, до того, как там появился сlient prediction — у Кармака был быстрый интернет T1 и он все делал с расчетом на маленькие пинги до 200 мс. Так и тут, наверняка у Кармака стоял SSD, с которого все замечательно стримится.
Если вы такой параноик, то не используйте скайп.
Использую восьмерку дома где-то с полгода. Все взаимодействие с ОС сводится к запуску трех с половиной программ: IDE, браузер, игрушки и так по мелочи. Принципиальной разницы с семеркой в этом смысле не вижу. На изменения в интерфейсе реагирую нормально — как было пара кликов для типичных задач, так и осталось. Выучить новые три клика вместо старых — вполне посильная задача. «Настроил» под свои три программы стартовый экран.
Чем больше цель — тем сложнее по ней промахнуться.
Согласен, что для мейнтейнеров ядра Linux сложившийся процесс является довольно удобным. Но не все пользователи GIT — разработчики ядра и далеко не всегда для манипуляций с комитами есть такая веская причина, а не простое желание сделать красиво. Если бы заголовок у поста был «Зачем разработчики ядра Linux редактируют свои коммиты», то возможно было бы меньше недопонимания с моей стороны и со стороны других отписавшихся здесь.
Ревью делается для конечного результата, а не для диффов в каждом коммите. Поэтому не важно, сколько там коммитов и сколько раз один кусок кода переписывался в них. Время на ревью в таком случае зависит от общего количества изменений и их сложности, а не от количества коммитов. В историю всего репозитория почти не смотрю. Смотрю на историю изменения отдельных модулей и файлов, если есть какие-то проблемы и нужно понять, почему они возникли.
Бывают моменты, когда в коде натуральные КРОВЬ КИШКИ РАСЧЛЕНЕНКА на протяжении целого дня, а то и нескольких.
Такое может быть, если не задумываться об атомарных изменениях. Да, для этого нужно изменить подход к программированию, разбивать на мелкие задачи и фокусироваться на них. Но это реально и лично мне это не мешает, а наоборот — помогает сосредоточиться. До этого у меня тоже часто были подобные ситуации — делаю какие-то мелкие изменения, они тянут за собой все больше и больше кода и не успеешь обернуться, как вся система сломана и непонятно, за что хвататься, чтобы привести все в порядок. Я стараюсь до такого не доводить, фокусируясь на законченных коммитах и небольших не калечащих изменениях.

что мне написать в коммит месседж, когда я переключаю контекст, а из текущих изменений — одна измененная константа, скажем?
Писать, что изменена такая-то константа. Можно еще добавить — зачем. Это лучше, чем temp, wasd, 111 и прочие.

Плюс к этому правило «коммитить часто» порождает множество коммитов на каждую мелкую фичу, которые сильно захламляют историю.
Вот. Подобное мышление — это уже следствие того, что редактирование истории становится частью рабочего процесса. Как пользователь меркуриала могу сказать, что у меня нет такого понятия, как захламление истории. Для ее организации я использую ветки и таги. Мне без разницы, сколько у меня коммитов в ветках, в большинстве случаем меня интересуют только последние.
Иначе — это когда историю редактировать нельзя. В этом случае имеет смысл руководствоваться как минимум двумя правилами для коммитов: писать содержательное сообщение, которое описывает ключевые моменты, и делать коммит законченным, чтобы приложение хотя бы компилировалось. Эти условия не мешают коммитить часто и при этом, глядя на их историю, не возникает желания ее переписать.
Другими словами пользователи GIT редактируют историю «потому что могут».

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

При наличии настоящих именованных бранчей (как в DVCS на букву М) необходимости что-то делать с кучей мелких коммитов в одном бранче нет.
Другими словами у пользователей GIT нет именованных бранчей, поэтому для того, чтобы дерево коммитов оставалось читабельным, им приходится ужимать бранчи до одного коммита.

Information

Rating
Does not participate
Location
Могилевская обл., Беларусь
Date of birth
Registered
Activity