Как стать автором
Обновить
25
0
Овчинников Василий @lol4ever

Пользователь

Отправить сообщение
Неужели тойота начала делать симпотишные машинки?
А вообще, про разработку этого рафика давно известно было/
Два вопроса остаются открытыми. Первые: где заряжаться? И второй, главный вопрос: ЧТО ДЕЛАТЬ С ПЕЧКОЙ? %)
Старый-добрый-любимый COM.
Очень удобная штука много для чего (например, для универсального интерфейса расширений функционала; не делать же его на экспортных функциях — тогда до свидания Шарп).
Который лежит в базе половины системы винды.
На котором написано немеряно АПИ.

За что его забыли? За некроссплатформенность?

С другой стороны, это — все равно костыли. Реализация кома проста как банан, а фреймворк при этом даже проще — как шкурка от банана. Но иногда старые-добрые костыли приходится доставать =)
Да. Ох как верно это. Конечно, это только одна грань, но это очень верно. Закономерность такого исхода печальна, но неизбежна: любая компания с бессменным долговременным составом руководства к этому придет и приходит. Застой и неспособность воспринимать риски.
И это очень актуально и у нас.
«За это время мы успеем добежать до канадской границы!»
Нет, по «успеть» подразумевалось время между написанием чудовища и просмотром кода вышестоящими товарищами. Вот в это время надо успеть уволиться и как раз двинуть к канадской границе =)
Иначе уволят так и так, только предварительно сделают такое, что глаза будут как у совы, натянутой на глобус =)
Почитал оригинал. Забавно в целом, дальше — больше. И да, некоторые пакости, которые банальное code review не отловит нашлись. Правда, автор до совсем тяжелых гадостей не дошел, но, в принципе, если собрать все его советы и успеть их попользовать сразу, то нужный эффект будет достигнут.
Открывая статью думал, что напишут что-то интересное. Не написали.

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

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

Ну и да, #define TRUE <выражение> тоже имеет право на жизнь, правда лишь в том случае, если надо просто нагадить.
Что-то подозрительно напоминает обрисовку фотки обычного плюшевого ёжика, у меня такой дома обретается
Товарищи! Давайте не будем политизировать участие ребят в конкурсе. Они (по собственному опыту участия в всевозможных научных конференциях) туда попали и выигрывают скорее вопреки, чем благодаря и стране и ВУЗу. И, я думаю, основные мысли у них о контроллерах, пайках, развитии этого проекта, собственном будущем. А честь страны? Не знаю, появятся — может сам расскажут.
То, что не смотря на фактическое отсутствие присутствия страны в проекте, она все же пользуется ее плодами — вопрос нехороший и гадкий, не надо его к ребятам лепить

Казалось бы, причем здесь .NET?
Проблема протоколов есть везде и всегда.
Кроме того, хотелось бы высказать небольшую мысль на тему сообщений, которые здесь помечены, как Debug:
В ряде случаев, такие сообщения хорошо позволяют обнаружить место возникновения ошибки. Пример: после каждой успешной операции выдается сообщение такого класса (но, естественно, чтобы логи не разрастались до неприятных размеров, стоит, все же, этот режим сделать отключаемым). Потом внезапно вылезает Error. Все, разработчик по последовательности сообщений однозначно определяет место ошибки и ее характер, плюс, при правильной записи предыдущих сообщений, имеет уже много данных для дебага.

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

А во-вторых, если код ОЧЕНЬ большой, то времени на написание таких сообщений тратится существенно больше, чем на организацию вот такого вот поэтапного протоколирования
Боже. Исходники. Атласу. Атласу. Исходники. Не, руки у них, большей частью, золотые, но, опять же, большей частью, и штаны им требуются с рукавами. Хотя, исключения есть.
Это уже подробности, для которых свое время. Сначала таки написал их в этой статье, а потом потер — для начала данная информация перебор.
А подписи все равно, какой набор байт подписывается — хоть бы и видео, хоть аудио, хоть вообще дамп памяти.
Про юридические особенности работы с ЭЦП теперь могу точно сказать: через две статьи
Будет, через 2 статьи. Пока, так сказать, некоторая разминка и введение в курс дела.
В принципе, почему бы и нет. Останавливает только то, что статей на эту тему — непочатый край, да и популяризовать их все же достаточно сложно, но можно попытаться, мысль интересная.
Но, естественно, не в данном цикле
Добавил две иллюстрации с википедии для асимметричного и комбинированного вариантов, в дальнейшем заменю на несколько другие. С симметричным же шифрованием все только хуже, так как любая картинка там — углубление в суть, что, на мой взгляд, не очень нужно.
Вопрос хороший, но на него прямо сейчас отвечать я не могу. Со всеми этими паспортами все очень сложно, причем настолько, что заслуживает отдельной статьи
Согласен.
Собственно, повторюсь про отрывание рук по самую задницу, потому что из плеч такие золотые руки расти не могут =)
А давайте разведем холивар про строгое сравнивание вещественных?
Еще как можно их сравнивать, только очень, очень осторожно и с пониманием дела
Все бы хорошо в данной схеме resources on demand, но есть одно маленькое экономическое но.

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

Основной почвой для конкурирования становится ценообразование.

Чтобы снизить цену максимально, необходимо, чтобы в цену за единицу машинного времени минимально была включена цена простоя. Для этого надо сделать что? Максимально приблизить график распределения нагрузки к графику равномерного распределения.

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

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

Что, в свою очередь, приводит нас к мысли о монополизации. И, как следствие, диктовке весьма произвольных цен.

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

Задница?
Статья хорошая, но, по большому-то счету, к х64 имеет ну очень опосредованное отношение.
Да, эти баги стопудово вылезут при попытке компилять в х64.
Но эти же баги вероятнее всего вылезут при просто попытке модифицировать программу. Так что, ИМХО, статья больше относится к разряду «не делайте так ни-ког-да».

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

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

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность