Природа наделила нас одним мозгом и одной головой, следовательно, ни о какой одновременно работе не может быть и речи. Иногда можно пытаться делать продукт на основе текущей работы, но это всего лишь подгонка текущей работы под новую задачу на основании схожих решений.
Так делают сплошь и рядом. И зачастую начальство убеждено, что старый проект можно чуть доработать и впихнуть в новую систему. Это далеко не так. Если система разрабатывалась без учета дальнейшего расширения, то ни о какой доработке не может быть и речи - все нужно делать чуть ли не с нуля.
Но многие программисты, и не только, идут на поводу у начальства, ведь действительно, проще доработать, чем сделать с нуля. Человек по сути существо ленивое, а программисты особенно. Я знаю, я - программист. Дело в том, что пока пишешь одну программу, успеешь пройти не по одним граблям, и вспоминая это - теряешь энтузиазм в новом деле. Хочется сделать что то глобальное и быстро, чтобы успеть попробовать плоды.
Все мы забываем что повторение - мать учения. Повторяя проход по темже тропам и граблям мы учимся, и в следущий раз многие грабли мы оставим в стороне и не пройдем по совершенно не нужным поворотам.
Таким образом мы ускоряем производство и совершенствуем свои инструменты. В итоге мы получим тот инструмент, который очень долго нам прослужит. Допустим - программную библиотеку. Со временем переход от одной программы к другой будет занимать все меньше времени, т.к. вы будете использовать уже готовый инструмент.
Что же делать, если уже есть готовый инструмент, от другого производителя? Ну разумеется пользоваться, если он, инструмент, вас полностью устраивает. Многие программисты пользуются WinApi, и всем довольны, другие ориентированы на микроконтроллеры, и не могут использовать готовые инструменты от MS, однако могуть сделать свои, куда более совершенные, чем у MS. Почему более совершенные? Все просто - WinApi - универсальный интерфейс, который служит прослойкой между драйверами производителя железа и программой. Именно эта прослойка мешает процессору обрабатывать данные максимально эффективно. А удаление этой прослойки делает программу неработоспособной на железе другого компьютера. Конечно это немного неудачный пример, но всеже. Сделаете универсальную программу - потратите кучу времени и сил, да и размеры у нее будут не маленькие. Поэтому WinApi выход из положения.
С другой стороны стоит задача максимальной эффективности - микроконтроллеры, ограничены ресурсы, ограничено быстродействие, ограничена периферия. Тут уже не до прослоек, и тогда программист вынуждден писать свой инструмент.
Ну и от слов к делу. Не так давно - год назад, я в очередной раз переделывал проект под изменившиеся условия. Все бы ничего, но первоначально проект писал другой сотрудник, который уволился. Про чтение чужого кода, к томуже не оформленного, я писать не буду, это тема отдельного поста, а речь пойдет про процесс создания инструмента.
Итак первоначально требовалось максимально изменить программу, с целью упрощения внесения изменений. Все бы ничего, да вот изменить ее никак не получалось, идеи, заложенные в программу, канули в Лету, и не просматривались за тем ворохом "костылей", что маячили в коде.
Программа была полностью стерта и начат новый проект. По максимуму я старался не оглядываться на старые решения, не потому, что они не верные, а потому, что они не имели необходимой гибкости. Как итог - программа приобрела модульное строение, и не позволяла другим модулям делать аналогичную работу.
В качестве инструмента я разработал модуль периферии, модули терминалов, модуль отладки, и модуль файловой системы.
Все это является независимыми инструментами, и позволяет создавать программы из частей этих модулей. Плюс разрабатывая новый модуль я старался опираться на уже разработанные модули, что с одной стороны показывало универсальность принятых алгоритмов, а с другой позволяло искать ошибки. Да именно ошибки. Все части программ проверялись и тестировались на работу. И иногда ошибка в алгоритмах старого модуля выскакивала при тестировании нового модуля. При этом никак я не мог получить эту же ошибку при тестировании старого модуля. И тогда я ее исправлял. Иногда находились более эффективные решения уже написанных процедур, и тогда я менял эти процедуры. В результате получал сокращение размеров программы и увеличение КПД.
Как итог - теперь полученные программные модули могут применяться в других проектах, и могут редактироваться независимо друг от друга, при этом сохранилась эффективность программы.

Удивительно, но чаще всего именно фразы "Я хочу, я могу, я сделаю!" звучат в голове, когда работаешь над новым проектом, или делаешь старый. Дело в том, что такова природа человека, надо поверить в свои силы и продолжать работать.
На сколько важен результат? Если честно, то он важен заказчику, а разработчику важно, чтобы он в итоге соответствовал ожиданиям заказчика. При этом в ход не всегда идут честные действия. Иногда исполнитель вставляет "костыли", или делают имитаторы. Все зависит от сложности проекта, и от опыта исполнителя.
К сожалению сегодня мыслей нет, чтобы написать еще что то ценное. И могу обратиться к тем, кто это читает с объяснением такого долгого молчания.

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

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

Нет, не программировать. С чего начать построение программы? Миллионы опытных программистов ответят, что с алгоритма, миллионы дилетантов - что они ее и без алгоритма \"нарисуют\" за 5 минут. Да, я понимаю, что иногда бывает далеко не до алгоритма, иногда бывает далеко не до комментариев. Сроки поджимают, начальство орёт, заказчик бесится, ничего не работает, где уж тут выработать нормальный алгоритм программы? Да, бывает и аврал, и нехватка времени, но, как ни странно это звучит, Вы сэкономите больше времени, если потратите часть времени именно на написание алгоритма.
А вот теперь я поясню как это работает. Менее всего ошибки ожидаются в мелких программах, казалось бы, программа мелкая, функций мало, какие могут быть ошибки? только синтаксические. Но нет, то тут промахнулись с указателем, то там не очистили память, то начали обрабатывать данные, не дождавшись окончания получения, то сделали \"прыжок\" не туда. Этого всего можно было бы избежать, представь Вы себе итог работы программы.
Чем подробнее будет Ваш алгоритм, тем меньше ошибок Вы совершите. Нет, не потому, что алгоритм является псевдо-программой, а потому что Вы будете представлять то, как должна на самом деле работать программа. И малейшая ошибка будет сразу видна. Кроме того, когда Вы будете писать алгоритм, Вы заметите, как программа резко изменится, в отличие от того, как Вы представляли ее работу изначально.
Теперь поговорим о важности комментариев.
Вот еще, скажете Вы, ведь и так понятно, что тут к А прибавляется 2, а тут это записывается в структуру, и т.д. и т.п. Тогда я вправе спросить, а зачем тут к А прибавляется 2, и зачем нужна эта структура, что в ней хранится? Этих вопросов можно было бы избежать, будь у Вас комментарий к строчкам программы. Вы не поверите, что комментировать каждое действие программы, это намного важнее, чем давать понятные имена переменным. Через год Вы не сможете вспомнить как должна работать Ваша же программа, а этот код "спагетти", хоть и правильный, но жутко не понятный. Писать комментарий надо как до написания строчки программы, так и во время, и после написания строчки. Не порвется ли маленькая программа от обилия комментариев? Поверьте мне, она станет намного лучше.
Дело в том, что голый код, пусть и с именитыми, назовем их так, переменными не всегда такой прозрачный, как кажется на первый взгляд. Да, когда Вы пишете программу, Вам все ясно и понятно, но потом Вы забудете как пришли к тому или иному заключению, почему применили цикл, и почему у Вас объем называется весом, а измеряется в метрах? Четкий комментарий даст пояснение каждому "чиху" программы, а кроме того, когда Вы будете описывать действия программы, Вы сможете подумать, а должна ли программа совершать эти действия, или их можно было избежать? Правильно ли программа совершает действия? Должна ли она их вообще тут совершать? Вы не поверите, но очень много ошибок я нахожу именно когда пишу комментарии. Нельзя ли писать без ошибок? Можно, и это приветствуется, но возьмем ситуацию аврала и нехватки ресурсов, когда торопитесь, то Вы можете совершить ошибку так, или иначе.
Разумеется, я никого не заставляю писать программы грамотно, но неужели Вам самим не будет приятно, когда программа написана красиво?

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

Вот уже 3 года минуло, как я купил книгу "Взлом и настройка Linux" в которой, среди прочих полезных советов, я нашел описание настройки системы контроля версий. Изначально я даже не обратил на это внимания, но потом решил прочитать что это и с чем его едят.
Это оказалась очень полезная система, которая позволяла вести полный журнал изменений программы, или других документов, выводила отчет об этих изменениях и позволяла оперативно возвращать предыдущие версии документов, файлов, скриптов, программ итд.
И тогда я стал одержим этой идеей, но занятость и природная лень не позволили мне быстро разобраться в данной системе. И вот наконец свершилось, спустя три года я поставил Linux на виртуальную машину, да я не всегда работаю на живом железе, и начал копать мануалы по установке. К слову, Linux стал намного дружелюбнее к пользователям, теперь не надо вручную устанавливать недостающие библиотеки или связанные файлы, все делается само собой. Итак, я нашел мануал в сети, скачал, поставил и все завелось, правда пришлось поплясать с бубном, т.к. мне нужна была сетевая система, а почти все мануалы были рассчитаны на локальную систему. Счастье наступило.
Правда потом я решил, что локальная система под Windows была бы более уместна в домашних условиях, поэтому я снова полез рыть мануалы, и встретил потомка SVN (который является потомком CVS) - Bazaar. Сначала под Linux'ом, меня привлекло то, что в данной системе архив можно было создать парой команд, при том не надо было создавать новых папок и общих репозиториев. Немного поигравшись я залез на сайт производителя, к слову распространение бесплатное, и тут меня ждала еще одна маленькая радость, точнее не одна, куча документации, пусть и не на русском, но картинки и команды от языка мало зависят, и версия под Windows. Я ее установил и натравил на рабочий проект. Конечно сразу не получилось разобраться в оконном интерфейсе, в Linux все под удобной консолью, но я справился. Оконный интерфейс тоже довольно простой и удобный, а также поддерживает русский язык, но это выяснилось потом, т.к. настройки запрятаны там довольно глубоко.
Три дня я мучил проект, добавляя и удаляя записи, комментарии, файлы итд, и наконец решил проверить, а будет ли проект читаться на других операционных системах, ведь если мне надо создать программу для Linux, а удобный редактор с нужными шаблонами у меня есть только в творении фирмы Microsoft, или Apple, то как мне будет удобно с ним работать? Не долго думая я скопировал проект на флешку, к слову данные репозитория хранятся в той же папке, что и проект, поэтому при копировании они автоматически переносятся вместе с проектом, и подсунул ее виртуальной машине. Там даже не копировал данные на диск, просто запустил консоль в папке на флешке. Система тут же показала, что есть репозиторий в данной папке, что прошло 4 ревизии и какие были изменения (комментарии к ревизиям). Да все работало, но мне показалось мало, вдруг придется кого то учить, а вы попробуйте обучить консольным командам молодежь, она же не в состоянии воспринимать текстовый интерфейс.
Тогда я снова залез на сайт разработчиков, с целью проверить, есть ли такой же оконный интерфейс для Linux, что был на Windows. Как и следовало ожидать, он был. Пара команд в консоли и он уже установлен, хвала скоростному интернету. Запуск, интерфейс сразу запустился русский, что меня опять порадовало, наверное потому что язык системы по умолчанию был выбран русский, и окна программы ничем не отличались от версии программы в Windows. Все комментарии и вкладки были на русском языке без загогулин и крякозябрин.
Да, пока что я остановился на достигнутом, может позже я прикручу эту систему к сетевому интерфейсу, чтобы хранить все данные в сети, но пока что мне и этого достаточно.

На работе я учу молодняк программированию, основываясь на своем опыте. Да, бывают случаи, когда надо что-либо подсказать, и первое, на что я стараюсь обратить внимание молодежи, это то, что при программировании взаимодействия с тем или иным устройством, первым делом надо реализовывать функцию приёма, а не передачи.
Почему так?
Потому что передача большей частью зависит от подготовки данных, если правильно организовать подготовку данных, то после пересылки их в порт устройства об их судьбе можно не беспокоиться, ибо никак нельзя повлиять на пересылку.
А вот от приема зависит правильность восприятия программой поступивших данных. Тут потеря или пропуск хотябы одного байта может означать, что данные не расшифруются или будут обработаны не правильно. Функция приема всегда является самой трудоемкой функцией из всех, что приходится реализовывать, и не важно как в нее поступают данные, она должна успевать их обработать.
Разумеется после приема данных их надо разбить на части, найти ключи, парсинг, проверка итд, но основу закладывает именно функция приема. И она должна быть написана так, чтобы было невозможно придраться.
К функции приема иногда относят функции обработки после чтения, например функция составления списка, или функция поиска ключей. Такая функция программы должна быть реализована на основе полного анализа возможных посылок, которые могут поступить ей на вход, при этом зачастую заранее бывает неизвестно, что за данные поступают.
Безусловно, существуют некие договоренности по обмену данными между устройствами, но согласитесь, что глупо начинать считать контрольную сумму, не дождавшись конца посылки. Глупо, но не совсем, иногда это позволяет ускорить работу программы, если данные поступают в потоке, а контрольная сумма была передана заранее в шапке пакета. Но вот если пакет был разработан халтурно, или это устройство, работающее по старому протоколу, где не применялась шапка, то что тогда? Тогда ничего не остается, как сидеть и ждать, когда мы считаем конец посылки.
Заранее не всегда известно, где кончатся данные, в этом и заключается сложность функций приема. Они реализуются, если их продумывать тщательно.

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

Хотел назвать по другому, ну да ладно. Это снова сообщение, имеющее косвенное отношение к процессу создания программ.
Первое, что надо уяснить - что программист должен быть внимательным. Многие мои знакомые часто подмечают это. Работа программиста связана с мелочами, каждая "песчинка" имеет значение.
Второе, это память, надо успевать держать в уме многое, что имеет то, или иное отношение к проекту. Я довольно часто жалуюсь на плохую память, но она плохая только с моей точки зрения. На самом деле, недавно я проанализировал сколько я всего помню, касательно работы. А помню я, как выяснилось, многое.
Ну и третье, надо изучать всё, не только то, что относится к программированию, электронике, но и по биологии, психологии, математике, физике и можно продолжать до бесконечности.

Собрав это все в одном человеке, вы получите программиста, но вот пока у него не будет четвертой характеристики, это будет простой инженер. А четвертое - это опыт, это те грабли, на которые наступаешь во время работы, это те особенности про которые не пишут в книгах, это хитрости, которые приходится применять в работе.
Именно эти хитрости надо хранить в памяти, когда работаете над программой, именно их надо искать в литературе и подмечать со всей скрупулёзностью.

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

На сей раз постараюсь быть кратким.
Если программист работает над заданием, то он не всегда пишет программы, иногда он читает литературу, думает, рисует, или даже спит, утомившись. Да, мы отличаемся от киношных программеров, которые сидят в каморке 3х3 и строчат коды. На самом деле работа в компьютере, а также побочные программы это скорее следствия работы программиста. И зачастую начальство, после месяца (2х, 3х) работы начинает задавать вопросы характера: "а где результат?", после чего дает неделю, которую ты сам себе отвел на компоновку результата, просто начальство спросило раньше, и ты за эту неделю выдаешь. В результате начальство уверено, что тебя надо пнуть, чтобы получить результат.
Это обидно, особенно, когда начальник ничего в программировании не понимает. И я думаю, что пока на посты начальников будут брать блатных, такое будет продолжаться.

Разрабатывая функцию для работы с программой я проговариваю про себя или вслух алгоритм ее работы. Иногда комментирую вслух, при этом всегда стараюсь написать комментарий в программе. Но вот программа написана, я ее запускаю, и вижу, что происходит отключение программы с ошибкой.
Программа простейшая, и найти причину вылета не составило большого труда. Причину вылета программы, но вот что приводит к стечению подобных обстоятельств? Ведь по идее везде, где был хоть малейший намек на ошибку я поставил условия проверки.
Теперь объясню, что это за программа: для одного из проектов мне понадобилась очередь данных. Данные читаются из потока, и сохраняются в очередь. В одной записи может быть от 1 до 512-ти байт. Разумеется потом данные из очереди достаются и обрабатываются. Длина записи выбиралась случайно, а очередь состояла из случайных байт. Не ставилась задача обработки, только заполнение очереди. Главное, что надо было соблюсти - что хранилище было фиксированного размера, и не расширялось. Соответственно, если происходило переполнение, то программа вылетала с ошибкой (нельзя было допустить переполнения). Однако, если никто не забирал данные из очереди, надо было стирать более ранние записи, и дописывать новые. В идеале до конца очередь не должна была добраться, но судьба могла распорядиться иначе, и надо было проверить, что будет, если данные начнут поступать слишком часто.
Программа для проверки была написана на основе генератора случайных чисел, сначала я получал число байт, которые требовалось сохранить в очереди, а затем генерировал такое количество байт. Массивы для хранения я расположил так, чтобы они затирали друг друга в случае переполнения, чтобы сразу получить ошибку. А для получения длины я придумал следующий алгоритм: получаем один байт от 0 до 255, прибавляем к нему 1, получаем второй байт от 0 до 255 и прибавляем к первому. Итак мы имеем диапазон от 1 до 512-ти. Разумеется все переменные могут вместить этот диапазон. Да, забыл написать, что я работаю в основном в *NIX и решил не заморачиваться генерацией случайных чисел, а использовать файл /dev/urandom, читаем из него один байт в unsigned short, и не паримся. При прибавлении 1 в unsigned short нам хватит места, чтобы сохранить нужное число.
После чего читаем из того же файла необходимое число байт.
Разумеется я не мог знать, портятся данные или нет, ибо я не знал заранее последовательностей байт, поэтому ввел контрольные суммы в блоки данных, чтобы проверять целостность. Ну вот и все, ах да, чтобы читался именно один байт я ввел отделение мледшего байта по маске, чтобы не выбиться за число 255.
Программа вылетает с ошибкой. Понимаю, что затираются данные. Такое может быть, если прочитать более 512-ти байт, но такое невозможно. Проверяю в отладчике, действительно, длины иногда доходят до ~700 байт. Значит где то неправильно генерируется длина! Но там всего три действия, плюс отделение по маске. Я потратил 3 часа, чтобы проверить все возможные варианты, сомнений не было, ошибка именно в длине, но как такое возможно? неужели компилятор начудил? или оптимизатор удалил что то важное? Нет, наверняка была ошибка у меня. Еще раз: читаем первый байт, накладываем маску, прибавляем единицу, читаем второй байт, накладываем маску, прибавляем первый байт... Все правильно. Не работает.
И тут мой взгляд упал на наложение маски. Видимо я опечатался, когда писал программу, и вместо операции &= написал операцию ^=, а это не наложение маски, а инверсия. Но я проговаривал про себя "наложение маски", и особо не смотрел на знак операции. Таким образом я долго не мог заметить ошибку.
Теперь о том, что происходило: если я читал случайный байт = 255, и прибавлял к нему 1, то у меня 1 переносилась в старший разряд, а младший обнулялся. Затем операцией A^= 0x00FF (инверсия младшей части) я увеличивал первое число до 511-ти(0x01FF), и затем прибавлял другое случайное число до 255-ти. В итоге там получалось число больше 512-ти, что вызывало чтение за пределы буфера и затирание части переменных. Удивительно, но отца русской демократии не спасло удаление маскирования, после вычислений выяснилось, что без маски ошибка переполнения возникала на шаг после пресловутой суммы 255+1.

Череда ошибок была вызвана процессом чтения из файла, т.к. функция read() рассматривает любой блок данных, как массив, а читала она один байт, то она не трогала другой байт, в котором оставалась единица от предыдущей операции.
Проблема решилась простым обнулением в начала цикла обеих переменных. Маску я так и не вернул на место, она была лишней.
Однако ошибка именно в этом алгоритме меня не сильно расстраивала, я написал его только для отладки функции, и он бы все равно дольше этой отладки не прожил. Однако благодаря поиску ошибки я теперь знаю, что иногда самый легкий путь требует много большей внимательности, чем сложный, ведь напиши я функцию A = rand(), ничего бы не случилось, тут старший байт нулится самостоятельно. Такая вот детская ошибка, стоившая трех часов отладки. А все из-за оговорки, что мы накладываем маску, а скажи я, что мы делаем операцию &(И) я бы сразу заметил, что маска накладывается не правильно.

Нельзя человека с улицы выучить на программиста, хотя думаю, что и другим профессиям тоже это свойственно. Но могу говорить только за свою профессию. Нет, мы не уникальны, мы не особенные, просто это такой склад ума и характера. Это надо воспитывать в себе с детства.
Но я хотел написать не про это.
Зачастую программы можно писать несколькими способами, об этом молчат в книгах, но оно приходит с опытом. Выбор способа написания программы зависит от задачи, которую она (программа) должна решать, и от требований к этому решению. Я не буду тут писать, что компьютер, это железка, что не может ничего сделать без помощи человека.
Итак, есть задание - написать программу. Первая мысль - решить задачу в лоб. И сэкономим время, и знаний нам хватит. Но, при таком подходе может пострадать быстродействие, устойчивость, модернизация и прочие характеристики программы. Хотя задача будет решена полностью.
Можно ходить вокруг, да около, изучая разные методы, которыми можно написать программу. Тогда потеряете много времени, но это будет шедевр программных дел мастеров. Это то, к чему нужно стремиться, но что нельзя написать сразу.
Помимо прочего, когда у вас есть гигантский опыт написания подобных программ, вы не нуждаетесь в отлаживании отдельных элементов, но где же такому опыту взяться? Поэтому, помимо самой программы вы должны будете написать очень много мелких программ, чтобы проверить каждый элемент. Это тоже работа, требующая времени и сил. Про это часто забывают.
Далее нужно отметить, что программисты - люди ленивые и неохотно переделывают свои "шедевры". Но очень часто из-за подобных подходов страдает логика и быстродействие программ, т.к. вместо того, чтобы написать удобную функцию, программисты подстраивают программы под свои ранее написанные функции. Про это тоже не пишут в книгах, первое правило - не лениться, если ты написал функцию, то можешь написать ее еще раз, но в более удобной для программы форме.
Самое сложное - заставить себя работать над собой. Мы слишком заняты, чтобы переделывать уже сделанное, или написанное кем то до нас. И как бы оно не было красиво оформлено, мы не можем сказать как оно работает, пока это не изучим, но готовы до конца отстаивать собственный код.

Здоровая конкуренция никогда не повредит, когда кто то наступает вам на пятки надо прибавить ходу.
Разумеется одному человеку это не под силу, но ведь можно собрать команду единомышленников.
Если же вы преследуете кого то, то намного лучше оставаться в нескольких шагах позади, а не наступать на пятки. Это позволит вам обойти, вовремя среагировать и развернуться в тех местах, где оступились ваши конкуренты.
Однако самая большая ошибка - делать такой же продукт, пусть и дешевле или качественнее, но такой же. Понимаю, что общими усилиями можно создать рынок и рекламу, можно раскрутить товар, итд итп, но клонировать яйца это не дело. Хотя изобрести что то новое тоже довольно сложно.
Ну ладно, это болтология, я позволил себе отвлечься от мыслей о программировании. :)

Разумеется, я, как человек, полностью у себя на уме, но иногда чужое мнение мне мешает сосредоточиться. Например на недавнем совещании высказывалась критика, что программисты первым делом лезут обновлять программы. Ну да, мы, если подключаемся к системе, то первым делом меняем прошивку. На самом деле подключение нужно, чтобы проверить функционирование системы вообще. Но это прелюдия.
Итак, недавно в командировке у нас не работал блок на микроконтроллере. Причем мне клялись и божились, что все проверено, и все должно работать. Но нет, не работает. Разумеется виновата программа, которую глупые программисты неправильно написали. Ну да, полез я с тестером в провода, нашел кучу огрехов, но это не спасло отца русской демократии. В итоге, перепробовав все, я решил заменить программу, хотя по словам пользователей блок проходил через нашу лабораторию, и должен был быть прошит свежей программой. Но, подумал, чем черт не шутит. Заменил программу, все заработало. Оказывается, там была программа для сдачи в ОТК, и, разумеется, никто не проводил этот блок через нашу лабораторию. Вообще надо было начинать с прошивки на новую версию, но я почему то начал думать, что скажет начальство,опять будут выражаться, что программисты часто программы меняют. Вот и получил 6 часов мучения с полностью не работающим блоком.
Чтож, теперь напишу кляузу, что нельзя программистам запрещать менять программы.

Представим ситуацию, что мы взяли обычную лабораторную мышь и посадили ее в неизвестную для нее комнату. В комнате нет света.
Итак, что имеет мышь в наборе первоначальных данных:
1. Известно, что она сидит на полу, и что пол твердый с каким то покрытием.
2. Воздух, наполняющий комнату несет часть данных о ее содержимом.
3. Нет никакой опасности в том месте, где сейчас сидит мышь.

Так сидеть можно бесконечно, но никто не даст гарантии, что в паре метров нет наиболее безопасного места, таким образом комнату надо исследовать. Рассмотрим движения мыши:
Немного посидев на месте и разнюхав воздух, она делает первый шаг, но тут же возвращается назад, на место, где безопасно.Потом делает уже два шага, но снова возвращается на безопасное место. И так далее. В результате мышь разведывает комнату.
Работа программистов в целом очень похожа на описанные выше действия мыши - при работе с неизвестными (нигде не описанными) драйверами приходится идти вслепую, постепенно разнюхивая окрестности. В этом помогают дизассемблеры и примеры, но примеров может не быть, также помогает и элементарная логика, например функция Init вызывается раньше других, а Fini - в самом конце.

Писал я код долго и упорно, но по мере его написания понимал, что все дальше отдаляюсь от C и все больше приближаюсь к C++. Поэтому в один прекрасный момент я начал новый проект, где все было написано на C++. Но речь не об этом. В предыдущем посте я писал как реализовать классы на C, когда же я писал код на C++, я понял одну интересную вещь - как инициализировать константы внутри класса.
Для начала немного теории: При создании класса всегда вызывается конструктор, однако тело конструктора вызывается немного позже, сначала программа выделяет под него память, обнуляет и т.д. А потом присваивает эту память структуре класса. Где и хранятся ссылки на переменные. Замечательно, а если переменные это константы, как тогда их инициализировать? Все довольно просто - можно инициализировать память по смещению, где должна лежать константа, перед тем, как присвоить эту память структуре класса. Таким образом константа уже будет равна требуемому значению, а не нулю. После чего изменить ее показатель уже будет нельзя.
Но как же так, мы ведь только что его изменили. Да, изменили, ибо любая константа, это переменная у которой стоит запрет на изменение значения. А память она и есть память - если мы можем получить номер ячейки без обращения к переменной, то мы можем спокойно менять это значение. Разумеется, если мы уверены, что от этого изменения не станет хуже.
Таким образом получается, что конструктор - просто функция, которая выделяет память, инициализирует данные через смещения и присваивает эту память структуре класса. Все просто.

Казалось бы, ну какая разница между 13-ю и 34-я килобайтной программой, если делают они одно и тоже? Ну может я не прав, и в современных системах не требуется экономия памяти, но согласитесь, что приятно иногда посмотреть на код и увидеть четкую структуру, вместо разбросанных массивов, где расположена куча совершенно левых элементов. Разумеется уменьшение объема было достигнуто не только за счет перевода массивов в динамические, но и за счет исключения ненужных операций, а главное - увеличение производительности в разы, без преувеличения - просто удалил участки, где предыдущий программист ставил паузы, чтобы синхронизировать потоки.
Ну и в чем моя гордость - так это в применении классов там, где их быть не должно, назовем их псевдоклассами. Итак все началось два года назад, я анализировал чужую программу, написанную на C++ в Linux, исходников не было, но была программа IDA, и в ней был встроен Hex Rays. Конечно это дорого, но фирма платит, я доволен :). Итак я читал функции, а в глазах между делом мелькали одинаковые члены функций. И тут до меня дошло, или я где то вычитал, что первым элементом в функции, принадлежащей классу, является указатель на тип этого класса. Тогда я не придал этому значения. Но мысль засела глубоко. Написав не одну тысячу строчек кодов я начал осознавать, что большая часть вызовов функций происходят со структурами в параметрах, и если бы я писал на C++ то применил бы классы, чтобы не писать по десятку одинаковых функций для разных типов данных. Тут то мысль и дождалась своего часа. И я бросил все, создал новый проект (из старого оставил только обработчики) и решил попробовать создать простую структуру и ввести в нее элемент - функция, где первым членом служит указатель на класс, в котором эта функция прописана. Но указатель на функцию, это не есть сама функция, ее надо еще и объявить и написать, а главное - присвоить указателю ее адрес. Разумеется все было сделано вручную, но после шлифовок мне удалось создать нечто похожее на конструкторы. теперь оставалось проверить, будут ли две структуры вести себя подобно классам, если я буду обращаться к их функциям-членам? с замиранием сердца я компилировал этот несложный проект, на часах был третий час ночи, и наконец серое окошко исчезло, а в строке состояния появилось слово "готов" и 0 ошибок. Значит компилятор такое дозволяет, я поставил точку остановки в начале программы, чтобы пройти ее по шагам, это не сложно, в самой программе не было ни ветвлений, ни потоков. И я нажал сделать первый шаг, отладчик показал, что создалось 2 структуры с крякозябрами, следующий шаг - обнуление каждой структуры, теперь там везде были нули, и в том числе в указателях на функции. Далее - последовательный вызов сначала одного, а затем второго конструктора. Все прошло удачно все переменные и указатели на функции присвоились куда надо, и теперь оставалось последовательно вызвать функции - члены для каждой структуры.
Я нажал кнопку сделать шаг и увидел, что программа зашла куда надо, а в первом поле стоял указатель на первую структуру. Переменные изменились и я вышел из функции, Следующий шаг - аналогичное действие со второй структурой, и опять все прошло гладко.
В результате получился класс, который можно создавать динамически, или даже в массивах, и обрабатывать в нем данные. Глаза мои вспыхнули любознательным огнем. Тут же был написан простенький алгоритм отлаживаемой мною программы, и я начал писать структуры с данными. Лег спать я в 5 часов утра, что даже по моим мерка было слишком поздно, чтобы выспаться. Зато я лег спать счастливым, представляя, как днем запущу эту программу и все откроют рты, когда увидят всю простоту кода и реализации. Пока демонстрировал все это только избранным людям, код еще не дописан, глюков нет, но многих нужных функций не хватает. Слишком мало было времени на реализацию, плюс ко всему надо обдумывать почти каждый шаг и по мере необходимости корректировать функции, это вам не C++ где все делал компилятор, тут приходится все прописывать вручную но результат - сокращение исполняемого кода в 2 раза, того стоит.
Скорее всего подход не новый, но в книгах я про такое не читал. Пользуйтесь, я не против :)

Итак, я доделал тестовую плату и получил приемопередатчики из Китая. Мне осталось дело только за подключением и написанием кода. Жаль нет времени, а идей много. Ладно займусь этим где то в начале июня. Вообще мне эта учеба уже осточертела, хочется просто освободить время и доделать все дела. Но мне мешает именно учеба. Я жду экзаменов, чтобы поскорее их сдать, тогда у меня освободится время на мои мелочи. Надеюсь я сделаю этот приемопередатчик менее чем за месяц, там делать в принципе нечего, только код написать, да спаять. Алгоритм можно составить и в тетради.

Началось все с того, что мне потребовалось написать одну тестовую программку с таймерами. Задача тривиальная - как только получен сигнал, запустить таймер, по истечении которого передать сигнал назад. В двух процессах, в принципе ничего сложного. Работаю я в ОС QNX, и в принципе она меня всем устраивает, кроме своей справки, но об этом потом. Начал я было рыть справку, чтобы найти нужные реализации таймеров, но ни один вариант меня не устроил, время было позднее, и я пошел домой. Дома у меня нет этой ОС, но есть Linux, что в принципе для программиста почти не отличается от QNX. В общем я покопался в литературе и нашел нужную мне реализацию интервального таймера, все сделал, все работает, прикрутил к двум процессам, вообще все шикарно, без проблем, без тормозов и головной боли. На том и уснул. Утром отнес это все на работу, засунул в компилятор, и он все это съел, даже глазом не моргнув, я обрадовался, что отделался так легко... Как оказалось рано...
Попытка запустить код на машине с QNX оказалась полностью провальной. ничего не заработало. И проблема крылась именно в таймере. Я начал рыть документацию снова и обнаружил маленькую приписку, что в данной версии QNX виртуальные таймеры не реализованы. Вот как с такими бороться? В итоге я сделал все на реальном таймере, но пришлось поступиться тем, что нельзя будет вызывать некоторые функции, которые могут повлиять на сигнал таймера. Обидно, я хотел сделать все как у людей.
Так что кроссплатформенный код это палка о двух концах, даже если программа компилируется на целевой системе, это еще не гарантия работоспособности, там могут просто стоять заглушки на половину функций.

Довелось мне написать программу для QNX (хотя проблема справедлива и для *nix) с внешней библиотекой, и все бы ничего, да вот часть функций пряталась в стандартной системной dll. Те, кто пишут программы для *nix, знают, что *.so файлы можно подключать к программе по разному, это и динамическая загрузка вместе с программой, и линковка функций в программу, и вызов библиотеки из среды. Для последнего требуется меньше всего телодвижений, чем я и воспользовался. Программа заработала сразу, без проблем и видимых косяков. Они всплыли много позже.
Где то через 4 месяца потребовалось запустить мне эту программу хоть и с правами суперпользователя (chmod +s) но из под пользователя с урезанными правами. Сразу программа выдала ошибку, что не может загрузить эту подлинкованную библиотеку. Я проверил пути в LD_LIBRARY_PATH, но это ничего не дало. пользователь может заходить во все директории с библиотеками, и все библиотеки ему доступны для чтения и загрузки, проверил. Но при запуске программы упорно выводилось сообщение, что библиотека не найдена. По 10 раз я проверял права пользователя и программы, это крылось не там. В итоге я решил пойти по другому пути.
Сначала я тщетно попытался жестко прилинковать библиотеку к программе, но лыжи не поехали, может я что то не так делал, не знаю. Потом пошел по пути динамической прогузки перед вызовом функций, что, по моему предположению, должно было автоматом передать права суперпользователя библиотеке, при этом пользователь мог быть любым (конечно, это если программе даны привилегии суперпользователя).
В итоге последний вариант нормально запустился пользователем с более низкими правами, чем root. Так что не ленитесь, господа, это не самая лучшая черта, но и трудом рыть могилу себе тоже не стоит. Всего должно быть в меру.

Недавно в гостях довелось ремонтировать приставку, за всем этим действом смотрела девочка лет 8-ми.
Увидев главный контроллер приставки (самый большой) она сказала, что это как большой торговый центр, типа ашана, или подобного, а маленькие детали рядом с ним (прямоугольные резисторы и конденсаторы размера 0201) это машины на стоянке. Я ей показал на микросхему памяти (плоский прямоугольник), спросил, а что это, на что она сказала, что это крытая автостоянка.
Что ж, фантазия у нее развита, однако она была права в своих представлениях, стоянка, это действительно хранилище, детали, это своеобразный транспорт к контроллеру, а сам контроллер содержит в себе кучу хлама, как любой большой торговый центр.

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

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

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