1. Стоит только приготовиться сфотографировать какой-нибудь цветочек, как тут же поднимается порывистый ветер.
2. Как только ветер стихает, Солнце прячется за облаками.
3. Самые непредсказуемые ветер и облачность случаются тогда, когда ты оставляешь дома штатив и цепляешь на камеру свой самый тяжелый объектив.
;)
Никогда не был знатоком тонкостей C++. Поэтому время от времени оказываюсь в затруднительном положении, пытаясь разобраться с накопившимися в голове тараканамибарьерами и ограничениями, вступающими в противоречие с тем, что хочется сделать.
Вот, например, почему-то у меня отложилось в мозгах, что стандарт C++03 не гарантировал что std::string хранит свое содержимое внутри себя как непрерывную последовательность байт. Т.е. грубо говоря, не следовало перезаписывать содержимое строки, например, таким образом: memcpy(&s[0],some_data,s.size()), где s -- это экземпляр std::string (достаточной емкости).
Обоснованием этого ограничения для меня было услышанное где-то когда-то предположение, что за стандартизированным интерфейсом basic_string может скрываться совершенно нетривиальная реализация, которая не хранит содержимое строки в виде непрерывной последовательности символов (например, используя ROPE-структуры). И что вроде как в природе существуют реализации STL, в которых basic_string как раз на основе ROPE и построены.
Но, насколько я могу судить, в C++11 жестко зафиксировали требование, что basic_string должно хранить свое содержимое в виде одной непрерывной последовательности:
The elements of a basic_string are stored contiguously, that is, for a basic_string s, &*(s.begin() + n) == &*s.begin() + n for any n in [0, s.size()), or, equivalently, a pointer to s[0] can be passed to functions that expect a pointer to the first element of a CharT[] array.
А это означает, что теперь можно смело перезаписывать содержимое std::string через memcpy, если предварительно позаботится о достаточном размере std::string. Ну или как в моем случае, использовать внутренний буфер std::string для приемника во время чтения содержимого строки из бинарного потока (без необходимости использования промежуточных буферов, как в случае с C++03).
Что не может не радовать. В конце-концов, C++ язык для околосистемного программирования и четкая фиксация того, как стандартные классы должны хранить свое содержимое (в частности для basic_string и vector) сильно облегчает работу с битиками и байтиками.
Навеяно вот этой темой на которую я бог весть каким образом попал. Но читать было забавно :)
Чтобы писать нормальный код, писать код нужно долго, годами, постоянно обучаясь на своих и чужих ошибках. Если есть возможность работать над своим кодом в течении десятилетия или нескольких -- еще лучше. Ничто так не вразумляет, как претензии к собственному, а не к чужому, коду. Я вот, например, сейчас рефакторю свой код образца 2002-го года. Есть что исправлять и есть за что самому себе надрать уши. Причем к тому времени у меня уже был опыт разработки программ порядка 12-ти лет (и 8-мь лет стажа как профессионального программиста).
Ну а в чем же проблема? Проблема в том, что я научился нормально программировать где-то к 37-38 годам, т.е. потратив на это занятие порядка 20 лет.
И есть у меня подозрение, что, по крайней мере, на просторах бывшего Союза, мало кто спокойно отнесется к такой перспективе. А именно: стать хорошим разработчиком ПО к сорока годам.
Разработка ПО -- это вообще очень молодая индустрия. В том смысле, что очень много в ней молодых людей. И временами кажется, что основную движуху создают именно они. Что, в принципе, понятно. Для молодежи азами становится то, что программисты предыдущих поколений осваивали в течении 10-15 лет. Мозги, опять же, у молодых, работают намного лучше и быстрее, схватывают они все на лету, не тратя время на перестройку устоявшихся в головах стариков стереотипов. Решимости и самоуверенности у них больше, желания махать шашкой хоть отбавляй, гормонов амбиций и энтузиазма столько, что перспектива стать ведущим программистом к сорока годам выглядит для них даже не насмешкой, а серьезным оскорблением. Как же, ведь к сорока каждый из них будет миллионером, владельцем собственного бизнеса или, на худой конец, вице-президентом большущей корпорации :) Фокус в том, что каждый не будет. Проверено ;)
PS. Кстати, бывают программисты, которые способны производить только говнокод. Их мало, к счастью. Но бывают.
Читаю сейчас книгу Ицхака Адизеса "Управление жизненным циклом корпорации". Понравилась одна рассказанная там притча:
Прохожий спрашивает у троих строителей о том, что они делают.
Первый отвечает: "Я кладу кирпичи".
Второй: "Я возвожу стену".
Третий: "Я строю храм, в котором люди будут общаться с Богом".
Очень хорошая притча. Показывает, чему придется научиться переходя с роли исполнителя на роль руководителя. Нужно будет научиться видеть конечную цель иначе -- так, как ее видит третий строитель: в целом.
Кстати, разучиться, наверное, уже будет сложно. Мозги перестраиваются. Тяжело перестроится и соредоточиться на "кладке кирпичей", постоянно будет тянуть к более глобальным вещам... ;)
PS. Очень хреново, когда конечную цель не может обозначить даже самый-присамый топ-менеджмент. Поскольку "зарабатывать деньги" или "приносить прибыль" -- это не цель, даже для владельцев бизнеса. Потому, что делать это можно совершенно разными способами, включая противозаконные. И если уж владельцы бизнеса вложились почему-то не в переработку нефтепродуктов, а в производство ПО, то должна быть какая-то цель именно в этом направлении. Если же такой цели нет, то у всех руководителей в такой ситуации будет всего одна цель: протирать штаны, перекладывать бумажки и получать оклад управлять ресурсами, т.е. класть те самые кирпичи, вместо строительства храма или, хотя бы, стены.
В октябре 2012 я написал пост о поиске инструмента для ведения списка текущих дел. В комментариях дали ссылки на три инструмента:
Попробовал только ToDoList. Понял, что он не для моего менталитета. Ну или же не для моего тогдашнего режима работы. Очень быстро список текущих задач в ToDoList стал настолько большим, что я уже не мог его просто так обозреть. А потом еще начали цвета задач меняться (кажется, чем меньше времени оставалось до окончания задачи, тем в более "тревожный" цвет она окрашивалась), причем красный цвет стал заметно преобладать. И это, с непривычки, сильно напрягало.
Однако, вскоре выяснилось, что многие задачи просто обречены на "протухание" и в этом нет ничего страшного. В ТОП-менеджмент тогда набрали слишком много новых людей, каждый из них генерировал какой-то свой поток активности в стиле "давай-давай, сегодня быстренько бежим сюда". Понятно, что прямо сегодня "туда" добежать не удавалось, поэтому появлялась задача о том, чтобы добежать "туда" к такой-то дате. Но очень скоро приходила новая вводная о том, что кроме "туда", нужно бы прямо сегодня добежать "сюда". А задача по добеганию "туда" не то, чтобы официально отменяется, просто об этом "на верху" уже не думают.
Вот и получалось, что реально актуальных задач, по которым нужно было либо предпринимать конкретные действия самому, либо же постоянно их контролировать, оказывалось не так уж и много. Обстоятельства, связанные с некоторыми из них, постоянно менялись. Так что сформулированная одним образом задача в процессе своего исполнения либо несколько раз меняла формулировки, либо же уточнялась некоторыми деталями, которые нужно было фиксировать.
Искать способ поддерживать все это в ToDoList или в каком-то другом инструменте я не стал. А выработал свой, очень простой подход к контролю за своими действиями.
Суть способа состояла в том, чтобы разделить дела на самые важные/неотложные и все остальные. Для всех остальных я просто назначал даты контроля в Google Calendar. Например, "Узнать статус такой-то задачи у такого-то сотрудника" +, если нужно, некоторые пояснения, чего именно я жду и/или что нужно будет делать затем. В нужный момент на почту приходило уведомление и я смотрел, что можно сделать с этой памяткой. Либо пойти и проконтролировать. Либо отложить на какое-то время (если я знаю о ее текущем статусе). Либо просто забыть о ней, как об очередной "протухшей" из-за изменившихся обстоятельств.
Самые же важные задачи, которые нужно было делать именно мне, да еще в настоящий момент, я записывал на обычных листах писчей бумаги формата A4. Например, "Решить вопрос с зарплатой такого-то" или "Подготовить объяснения по инциденту такому-то". Причем, записывая дела, я старался оставлять достаточно пустого места между ними, чтобы туда можно было вписать еще две-три строки с пояснениями, заметками или дополнительной информацией. Когда задача завершалась, я просто зачеркивал ее на листочке. Если текущий листок заканчивался, я брал еще один.
Обычно все мои текущие самые важные задачи умещались на двух страницах формата A4. Иногда на трех. Обычно это происходило когда на каждом из листов оказывалось по 2-3 зачеркнутых задачи. В этом случае, чтобы не путаться в заметках, я переписывал список на новых страницах (обычно не весь, а только "выжившие" задачи с самых "старых" страничек). В итоге, у меня опять оказывалось 1-2 страницы, практически полностью заполненные только актуальными задачами. Понимаю, что для пользователей ноутбуков, планшетов и смартфонов это ручное переписывание выглядит совершенно нетехнологично. Однако для меня это работало. Либо я просто лучше запоминаю информацию визуально, либо же за счет регулярного повторения посредством переписывания. В любом случае, когда я стал поступать именно так, я стал лучше помнить, на чем мне нужно сосредотачиваться прежде всего (а имея под своим началом такое непростое хозяйство, как тогдашний гомельский филиал Интервэйла, это было не просто).
Зафиксированный на бумаге список дел я постоянно держал перед глазами на своем рабочем столе. Для этого я помещал его между краем стола и ноутбуком. Таким образом он оказывался у меня между рук и стоило мне опустить глаза от экрана на стол, я сразу видел список своих задач с различными пометками и пояснениями.
Вот такой вот примитивный, но очень эффективный, как оказалось, способ. Для меня он реально работал. А все остальное, что я упоминал в списке желаемых возможностей в прошлом октябре -- вроде диаграмм Гантта, иерархическая детализация и провязывание зависимостей и пр. -- оказалось либо совершенно не нужным, либо совершенно не работоспособным.
