Добрый день, коллеги по цеху! Я бы хотел уточнить один вопрос. Как вы считаете, крокодил — он больше длинный, чем зелёный, или наоборот? Я, честное слово, с большим непониманием читаю все эти истории о тупых менеджерах/бухгалтерах/секретарях и мудрых и благородных админах/программистах.
Начнём с начала, чтобы картина моего повествования выглядела полнее.
Решили вы открыть своё дело. Поздравляю вас с этим судьбоносным решением! Завертелось, денежки капают, всё хорошо. Но в определённый момент вы сталкиваетесь с дефицитом собственного времени. Вы нанимаете помощника, которому делегируете часть своих полномочий. Это первый и важнейший этап понимания того, что вы не бог и везде одновременно вам находиться, увы, не дано.
Идём дальше. Ваша фирма растёт, вы не справляетесь уже не только с основным профилем работ, но даже с документооборотом. Вы нанимаете секретаря. На первых порах для вас важнее, чтобы ваш помощник делал рутинную работу, занимающую основное время. Но вот к вам начинают обращаться представители серьёзных организаций, и вы сажаете в секретарское кресло девушку модельной внешности. А тихая ли она и исполнительная — тут уж решать вам.
Задумайтесь, дорогие коллеги, как выглядит ваше поведение со стороны. Ведь вы нанимались решать определённые задачи, как, кстати, и те, кого вы считаете тупыми.
Не нравится решение управленца? Так он тоже персонал. Ему тоже поставили задачу. Пытайтесь координировать усилия. Не вышло с управленцем — пишите начальству. Начальство не оценило вашей инициативы? Что ж, возможно, вы не видите всей картины.
Вы бы лучше организовали производство, ведь вы специалист? Требуйте перевода в управленцы. Уверен, начальство оценит ваши незаурядные таланты.
Надоело спорить с бухгалтерами/секретарями? Попробуйте в обед угостить их печенькой и ещё раз спросить, что именно и как не получается. Поверьте, в большинстве случаев это работает. Не вышло? Пишите начальству!
Запомните: добрым словом и письмом начальнику можно добиться большего, чем просто добрым словом.
Странное дело: вроде не первый день работают человеки и вполне заслуженно занимают немалый сектор среди нуждающихся и в антивирусной защите и в средствах бэкапов, а лепят такие пуськи, что за голову хватаешься (если кто не догадался: речь о жёлтой компании на букву «S»). Пересказывать всю эпопею сражения с продуктами этого производителя за всего-то два с небольшим года тесного общения с оными не буду, хотя, если добавить немного экшна, вполне сойдёт за трэшовый приключенческий роман в двух-трёх томах. Расскажу только о текущей каке с маком.
Если удалить один из подчинённых серверов с управляющего, добавить его обратно невозможно. Даже если переустановить.
Удалить ненужный бэкап возможности нет. Хотя не совсем правильно: удалить-то можно, но исчезают они только из списка имеющихся точек восстановления, на винте по-прежнему занимают место. А удалить их вручную хоть и сложно, но можно, однако чревато поломкой хранилища.
Если на хранилище закончилось место, выдаётся предупреждение. Заметьте: не ядрёный панический алерт, вопящий во все стороны, что бэкапить некуда, а маленькое незаметное предупреждение, которое очень легко вообще не заметить. При этом машинка пытается-таки забэкапиться на хранилище, которое забито, со скоростью, которая не спеша стремится к нулю. Но и это бы ладно, но остальные машины, которые должны бэкапиться на это же хранилище, не выдают вообще никаких сообщений — они тупо становятся в очередь и ждут. Более того, они готовы ждать вечно. Когда в понедельник я увидел, что на хранилке в ночь с пятницы на субботу закончилось место, заметил очередь из 16 заданий, терпеливо ожидающих освобождения места, из всего 7 ежесуточных, ссылающихся на эту хранилку, а в каждом задании от 2 до 20 машин.
Программа для создания бэкапов, работающая с VMware не первый год, не может забэкапить отдельную VMDK-шку, если машина состоит из нескольких. И ещё один сюрприз: виртуалка не может быть забэкаплена, если в машине есть VMDK больше 2 ТБ (чё-чё?).
Управляющий сервер не может забэкапить сам себя.
Про то, что не работают некоторые заявленные плюшки и феньки, можно не говорить — про это и так слишком много сказано, — зато есть несколько совершенно бесполезных, но, определённо, привлекающих внимание (привет маркетологам?).
Короче, суть ясна, а мораль… Морали нет, просто пожаловался, вы уж извините.
Коллеги! Выбирайте технологии. Выбирайте так, чтобы потом не жаловаться, что приходится поддерживать за кем-то код «не очень красивого цвета», который ещё и пахнет соответственно.
Поделюсь немного своим опытом. Я веб-разработчик, программист, в основном бэкэнд.
До относительно недавних пор я работал преимущественно с широко известной в России CMS, отличающейся агрессивным маркетингом (вплоть до упоминания жёлтой программы в своём названии), низким порогом вхождения и широкими возможностями нарушения архитектуры. Точно так же, как и многие любители чистого и красивого кода, плакал кровью, глядя на некоторые конструкции, особенно написанные «золотыми сертифицированными партнёрами», осилившими эпический труд «PHP за 24 часа для чайников». Компонент (почти аналог контроллера в традиционных системах), который не содержит логики, а только подключает тот или иной шаблон в зависимости от входного параметра — нормально! А вся логика в шаблоне. Вплоть до обращения к БД. Да, прямыми SQL-запросами, несмотря на то, что система имеет хоть и своеобразный, но всё же ORM. А что? В учебниках для начинающих же действительно есть такие примеры, и возможность обратиться в БД прямо из HTML-файла преподносится как преимущество и неоспоримое достоинство PHP. Но ладно. Сами авторы системы тоже не ангелы. Кто-то про классы жаловался? Так вот, классы — это, по мнению авторов замечательной (без иронии) CMS, всего лишь способ логически объединить несколько функций. Большинство методов класса статические. Но в некоторых случаях нужно создавать объект класса, который будет использован только для вызова одного метода, и нигде и никогда больше. Такое своеобразное видение ООП.
Беда? Однозначно беда. Копаться в таком быдлокоде — приятного мало. Надо было что-то делать. Я изучил альтернативы и остановился на приятном фреймворке Django, с помощью которого теперь и разрабатываю сайты. Возможно, вы не поверите, но проблема чужого кода исчезла. Во-первых, оформление кода. Оно всегда и у всех одинаковое. Синтаксис языка Python предъявляет жёсткие требования. Питоновская идеология также гласит, что для решения задачи должен быть один очевидный способ. В Django эта идея поддерживается. И это помогает, экономит время и нервы. Кто бы ни писал до меня, я заранее знаю, где искать нужный код, даже если проект впервые вижу.
Порог вхождения намного выше. То есть нельзя, просмотрев один 15-минутный видеоурок, сразу начать клепать «визиточки». Нужно иметь некоторую базовую подготовку и потратить время на изучение. Это отсекает случайных людей: средний уровень разработчика на Django намного выше, чем средний уровень широко рекламируемых решений с низким порогом вхождения. А значит, и качество кода выше.
И ещё один бонус, который не сразу очевиден: повышается качество заказчиков. Довольно легко убедить в преимуществах своего предложения заказчика, которому важен результат, нацеленного на долгосрочное сотрудничество. И практически невозможно склонить на свою сторону тех, чья главная цель — снять с себя ответственность: всяких менеджеров по просиживанию штанов.
В общем, я для себя нашёл инструмент, который помогает работать эффективно и с удовольствием, а не страдать от кривых решений. Ищите и вы. Пробуйте, изучайте. Хороших инструментов много. Спрос на качественную работу есть. А кому надо подешевле, и чтобы легко найти какого-нибудь неудачника нам на замену, те пусть жуют свой кактус сами: не в наших интересах таких поддерживать.
Автор истории о бесчеловечных методах производства юзверей в промышленных масштабах даже не подозревает, насколько он ошибается.
В подростковом возрасте во мне проснулся интерес к миру IT: учебная программа трудностей в освоении не вызывала, а унять пытливый ум больно уж хотелось. Дома компьютера до 2008 года не было, поэтому на помощь пришёл мой ныне покоящийся с миром SE Z530i. Сначала это были мобильные форумы, потом первые попытки сваять Java-приложение на само́м телефоне (да, умельцы с одного сайта сделали портативную связку «компилятор — преверификатор — упаковщик), потом я вычитал в учебнике по ИКТ про основы HTML-разметки. Первые опыты создания страничек на телефоне были успешнее, чем программирование, и я загорелся желанием двигаться в этом направлении. В школе от нечего делать на этих самых уроках по ИКТ я ваял простые странички, правда, мои старания кроме меня самого тогда никто не оценил. Я всё ждал, когда учительница даст заветное задание из книжки, а я мастерски выполню его и представлю ей. Фигушки. Седьмой, восьмой, девятый класс заканчивался, мы изредка писали простенькие программки на Паскале, при этом не трогая злосчастные учебники. Лишь изредка мы конспектировали материал по алгебре логики, по тому, сколько бит в байте и байт в килобайте. Каждый год я исправно сдавал и брал новые учебники про пресловутому ИКТ, узнавая оттуда про протокол HTTP, про создание десктопных приложений на MS Visual Basic. Руки чесались сделать что-нибудь полезное, но вот даже с появившимся тогда компьютером мне не представлялось возможности достать несчастный Visual Basic. Учебники целый год проводили у меня в столе, иногда я перечитывал их от скуки. В 10 классе я даже, рискнув нарваться на немилость одноклассников, спросил у учительницы, почему мы не по учебникам учимся, а занимаемся ерундой вроде рисования звёздочек в Фотошопе, на что получил невнятный ответ, что программу так построили, что поделать. В 11 классе уроков ИКТ вообще как таковых не было, на них все готовились к ЕГЭ по своим предметам, только лишь мы с одноклассником решали тестовые задания по этому экзамену.
В чём суть столь расплывчатого повествования? Если бы в школах действительно почаще открывали эти самые учебники по ИКТ, в которых пусть даже запросы на кириллице, а реляционные СУБД управляют внезапно реляционными же БД (в компьютерных классах практику не на бумаге выполняют, поэтому опыт и осознание неточностей всегда появляется), то наверняка сайт не пестрил бы историями о бухгалтерах, которые не умеют читать сообщения на экране, или о клиентах техподдержки провайдера, которые не в состоянии найти ярлык запуска сконфигурированного соединения. Так что если на учебнике написано: «Рекомендовано Министерством образования и науки Российской Федерации», может, стоит прислушаться к рекомендации?
Когда человек, умеющий читать документацию, ставит на ноутбук Линукс — выходит удивительно скучно. Он читает доки, потом запускает установщик, создаёт фиксированные разделы небольшого раздела под рут,
/bin
,
/usr
и
/var
, а оставшиеся сотни гигов отдаёт под
/home
. Ещё он читал доки на USB и знает, что ток на одну пару разъёмов не может превышать пол-ампера, поэтому дополнительный «хвост» от носимого жёсткого диска нужно втыкать в разъём из другой пары, желательно — подальше. В результате всё работает именно так, как хотелось с самого начала, и никакой байки из этого не получается.
Казалось бы, филология — наука о слове. И специалист в ней должен со словом дружить и уметь читать доки, благо сейчас в сети их более чем достаточно. Тогда и не будет историй про админскую ауру, появляющихся лишь от незнания рекомендованных умными людьми настроек и методов.
Прочитал тут про страдания одного программиста. Слёзы наворачиваются. Хочу в этот санаторий, там, где функция в 400 строк — предел безобразий. Видимо, у всех болевой порог разный, а у меня болевые рецепторы на заднице стёрлись давно. Итак, что у меня.
Есть программы на Фортране. Язык весёлый. Констант в нём нет, а параметры в программу передаются исключительно по ссылке. То есть вызов
call subr(1)
на самом деле передаёт в подпрограмму адрес переменной, в которой лежит единица. Значение переменной в подпрограмме можно изменить. Так я узнал, что в любой фортрановской программе есть как минимум четыре единицы (и четыре нуля, кстати), в общем случае не равные между собой. То, что
print *, 0
выдаст именно «0», не гарантируется.
Есть программы на Паскале. Все пользовательские типы там именуются по простой схеме: Т1, T2, T3, T4… T55. Что вы, конечно же, есть распечатанный документ, где эти типы подробно описаны, для чего и как, но его потеряли. А переменные экономили, поэтому в разные моменты времени переменная используется для вычисления и хранения совершенно различных по смыслу значений. Поэтому называют их А1, А2, А3. Это не обфускатор. Люди реально так писали.
И, наконец, любимый С++. Реальная программа, которая лет десять назад неплохо продавалась по всему миру. Там есть три функции. Первые две содержат 45 и 35 тысяч строк. Раньше это была одна функция, но Visual C++ отказался компилировать файл больше 65К строк, и автор разбил функцию на две. Третья функция поменьше — 20 тысяч. Практически все 20 тысяч строк запиханы в отрисовку окна. Инициализация программы, парсинг DXF-файла с картой Земли, расчёт всякой астрономической фигни и, собственно, отрисовка.
Есть ещё 16 файлов машинно-генерённого С++ по мегабайту каждый, которые иногда приходится править вручную.
Могу продолжить, но мне уже грустно. А вы над 300 строками плачете…
Секретка в кнопке включения — это хорошо и правильно. Вот только «но» тут не одно.
Корпуса современных аппаратов редко рассчитаны на установку дополнительных элементов, а особо «продвинутые» совмещают кнопку включения питания с чем-то ещё, превращая два контакта в многожильный шлейф.
Удобство использования под вопросом. Вживлять магнит для геркона в кольцо или постоянно носить его в кармане, доставая всякий раз? А в случае утери что делать? В общем, не айс.
Кто и за какую мзду будет вшивать эту «секретку» в телефон, особенно с учётом пункта 1? Где гарантия, что местные Левши и Кулибины сделают всё по уму, а не как левая пятка прикажет? Да и стоимость работ (с учётом специфики) вряд ли обрадует, что резко понижает рентабельность.
Но при правильной реализации такая закладка может сослужить добрую службу. Проверено лично.
В результате работы Homo Rukozhopus (я менял себе разбитое стекло) мой телефон приобрёл особенность: кнопку включения нужно было давить очень сильно (лучше — часовой отвёрткой или зубами). После настройки софта для переназначения клавиш и покупки китайского чехла (без чётко пропечатанных кнопок) плюсы стали очевидными:
резко упало количество желающих поиграться: «Не включа-ается!»;
на блокпостах (при проверке документов там частенько требуют и телефоны) «сломанный» аппарат ни у кого не вызывает вопросов;
если вытащить батарею, без опыта включить телефон очень непросто. Точнее, почти невозможно. Пару раз спасало.
Есть, конечно, и минус такого решения: софт таки тянет батарею и занимает память. Но 5 мегабайт при гигабайте ОЗУ погоды не делают, правда? Да и это точно дешевле, чем покупать новую запчасть.
Вряд ли кто-то станет рубить дерево молотком. То есть по скудоумию, конечно, может попробовать, но ведь не получится.
Точно так же неудобно рубить дерево обухом топора. Тут вообще почти парадокс. Инструмент-то подходящий. Смотрит такой (ну, назовём его эникеем) на топор, на картинки из мануала — всё ж подходит. Вот дерево, вот инструмент для рубки деревьев, а оно не рубит. Никак. А почему? Да потому, что дерево рубят другой стороной топора.
Мало того, что наш герой рубит деревья молотком или обухом топора, так он ещё и сразу бежит к ближайшему пригорку и с него поднимает крик о том, что вот, дескать, купил молоток, а он не рубит. «Тоже мне кузнец, — говорит герой, — делает молотки, которыми рубить деревья вообще невозможно». Мол, я хотел срубить дерево молотком, а как? Не получается! А про топоры вообще говорить не приходится. И, главное, негодяй такой, совести хватает рассказывать, что топорами хорошо деревья рубить. Да ничего подобного! Купили мы на фирму два топора, я обухом бил-бил по дереву — ничего! Без толку! Лучше бы резиновым фаллоимитатором колотил — больше пользы было бы. Осталось ощущение, будто кузнец лично надо мной надругался.
То ли дело — лобзик из набора «Сделай сам»! Да, долго, да, неудобно, да, ломается постоянно, но ведь работает же! А сломанную пилку я сам заменить могу. В прошлом месяце такую сосну им спилил — закачаешься.
Понаделали, понимаешь, гламурных топоров с блестящими лезвиями, ходят лесорубы, понтуются ими. Нет, чтобы с лобзиками ходили. Да, а кузнец знаете сколько за свои топоры просит? Совести нет совсем! За гламурные блестящие топоры, которыми я не могу ни одного дерева срубить, такие деньжищи!
Я надеюсь, аллегорию все поняли? Разъяснять не нужно, потому что, во-первых, потеряется весь смысл, а во-вторых, тем, кто не понял, разъяснять и не нужно.
Делаем большой интересный серверный проект. В прошлом месяце начальство внезапно постановило: нужно, чтобы сервер умел вставать на паузу! Ну, и ТЗ, как он это должен делать. В частности, перед уходом на паузу сервер должен успеть обработать и выдать все принятые пакеты. Архитектура многопоточная: сетевой поток, занимающийся как отправкой, так и приёмом пакетов, UI-поток, принимающий и обрабатывающий пользовательские команды, SQLworkers, UtilityWorkers и куча рабочих потоков.
Все потоки умеют обмениваться данными только через очередь сообщений. Поэтому, как только добавлено новое сообщение в очередь, поток снимается с паузы, шлёт запрос потоку UI — надо ли ему становиться на паузу, потом обрабатывает сообщение и нормально работает, пока не придёт пакет с подтверждением паузы. Но ТЗ есть, так что мы его тупо реализуем, не особо задумываясь.
Реализовали, отправили тестировщикам. На следующий день пришёл ответ.
Я был сильно озадачен результатом применения паузы под серьёзной нагрузкой. Сперва поток UI рассылает всем приказ встать на паузу, затем сам становится на паузу. NetWorker моментально становится на паузу: он очень быстро всё принимает и отправляет. Воркеры так же быстро становятся на паузу, а вот один из SQLworkers при обработке запросов
INSERT/UPDATE [имя очень тяжёлой таблицы]
может очень долго ждать ответа от БД. И как только он его получит, он сделает запись в лог об этом, разбудив поток UtilityWorker, потом кидает результат в общий пул сообщений, разбудив пул воркеров, потом этот пакет будит NetWorker. В то же время поток UIworker не пробуждается от запроса в очередь сообщений.
В итоге мы получаем полностью рабочий сервис со спящим потоком UIworker, разбудить который может только пользователь… Который сделать этого не может, ибо спящий UIworker не обрабатывает поступающие команды.
«Секретка» — штука, знакомая многим водителям. Конечно, применять её вместо сигнализации может лишь очень отчаянный человек, но в дополнение — очень эффективно.
А почему же этот приём неведом владельцам смартфонов? Даже простой геркон последовательно с кнопкой разблокировки обескуражит процентов 70 воришек, а это не так уж мало. Ну вот, один секрет — больше не секрет, но можно других напридумывать сколько угодно.
Если бы не одно «но». Гарантийный аппарат установка «секретки» лишит гарантии, а послегарантийные воришек интересуют в меньшей степени.
