Из технических заданий:
— Реализовать экспорт документов в FAIL. Формат в аттаче.
— Исправить опечатку на форме поиска: заменить «поск» на «писк».
Всего историй: 896
Из технических заданий:
— Реализовать экспорт документов в FAIL. Формат в аттаче.
— Исправить опечатку на форме поиска: заменить «поск» на «писк».
Давно это было. Наехал на меня начальник: мол, вы что-то делаете-делаете, а ни хрена не видно. Ну, я в сердцах слил статистику из репозитория, построил графики и всякие аппроксимации методом наименьших квадратов и малость охренел сам.
Написание проекта можно рассматривать как переходный процесс из состояния 0 (ничего нет) в состояние 1 (проект готов). Из курса ТАУ я ещё помнил дифуры второго порядка для затухающих колебаний, но увидеть такой график, разглядывая динамику количества строк в проекте, не ожидал. Шутки ради по той же схеме проанализировал коммиты всех подчинённых — картина та же, хоть и менее явная. Потом поднял статистику фиксации багов и нашёл аналог длины свободного пробега молекулы в газе.
В общем, так.
1. Достаточно большой софтверный проект как макросистема описывается с достаточной точностью дифуром второго порядка (затухающие колебания в вязкой среде), то есть двумя числами. Каждый программист может быть описан теми же двумя числами. Примерный смысл на бытовом уровне: как быстро человек пишет код и как быстро он правит баги.
2. Коэффициент затухания («вязкость», сопротивление изменениям) у всего софтверного проекта больше, чем у любой его подсистемы или у отдельного программиста. Период колебаний у программера практически всегда равен двум суткам: залил — все потестили — залил фикс. Как минимум 20% строк первоначального коммита будут поправлены — тоже интересная константа.
3. Совместно работающие программисты подчиняются правилу сложения источников белого шума: суммарная эффективность равна корню из их числа.
4. Время фикса бага пренебрежимо мало по сравнению со временем его жизни. Чтобы нарваться на баг, надо тестить. Никакие другие методы, увы, не помогут. Время жизни бага растёт экспоненциально в зависимости от количества пофикшенных.
Вот так. Рассчитав всего два числа, я могу сказать, когда мы закончим отлаживать проект, оценить эффективность любого программера и прикинуть количество багов в проекте, исходя из частоты подачи рекламаций. Но, что самое печальное, это константы. Я не могу повлиять на них точно так же, как не могу изменить ускорение свободного падения. Поэтому знания эти бесполезны.
Разбираюсь с одной программой, которая должна работать на нескольких ПК. Естественно, не хочется на каждом её устанавливать, потом обновлять и т. д. Заглядываю в реестр и тихо стекаю по стулу.
[HKEY_LOCAL_MACHINE\SOFTWARE\%company_name%\%product_name%]
"Version"="a.b.c.d"
"InstallDir"="d:\\games\\%product_name%"
"InstallPath"="d:\\games\\%product_name%"
"Dir"="d:\\games\\%product_name%"
"Path"="d:\\games\\%product_name%"
"language"="English"
То ли на этом у программиста кончилась фантазия, то ли к каждой конкретной строке обращаются участки кода, разработчики которых никогда так и не установят контакта.
Вот вечно ругают программеров: дескать, руки кривые, не знают ни черта…
Крупная контора, свои админы, свои разрабы. После очередного эпик-фейла самописного софта админами, как всегда, выдвигаются претензии к качеству программной поделки. Начальник разработчиков отвечает на голубом глазу:
— Качество софта обеспечивают не разработчики (это глубочайшее заблуждение), а процесс его производства. Уровень качества продукта — это одно из требований к нему, которое влияет на его стоимость, и не более того.
Преподаю на кафедре высшей математики в одном уральском вузе, заодно учу информатике детишек в лицее при этом университете. В девятом классе с детьми мучаем Паскаль — одно веселье.
Девочка-отличница (как меня заверила классная руководительница) пишет программу с оператором IF и вдруг подзывает меня к себе: не работает, мол. Смотрю.
if a=5 then do <...>
Далее — ещё несколько строк, а затем многократное повторение строчки then do <...> один в один.
— Зачем так часто?
— Чтобы компьютер не забыл!
Сижу на одном программистском форуме, помогаю студентам решать задачи на Паскале. Я честно не знаю, что бы я делал без этих дорогих индусов. Наверное, умер бы от скуки. Вот последняя жемчужина.
Необходимо создать текстовый файл, содержащий исходную программу, а также подсчитать длину созданного файла. С созданием файла вопросов не возникает, а вот как подсчитать длину? На ум пришло только:
{Podschet dlini}
Reset(f1);
kol:=0;
while not eof(f1) do begin
readln(f1,l);
For i1:=1 to length(l) do if (l[i]='a')or(l[i]='A') or (l[i]='b')or(l[i]='B')
or(l[i]='c')or(l[i]='C')or(l[i]=' ')or(l[i]='d')or(l[i]='D')
or(l[i]='e')or (l[i]='E') or(l[i]='f') or(l[i]='F')
or (l[i]='g')or (l[i]='G') or (l[i]='h')or(l[i]='H')
or(l[i]='i')or(l[i]='I')or(l[i]='J')or(l[i]='j')
or(l[i]='k')or(l[i]='K')or(l[i]='l')or(l[i]='L')
or (l[i]='m')or (l[i]='M')or(l[i]='n')or(l[i]='N')
or (l[i]='o')or(l[i]='O')or(l[i]='p')or(l[i]='P')
or(l[i]='q')or(l[i]='Q')or (l[i]='r')or (l[i]='R')
or(l[i]='S')or(l[i]='s')or(l[i]='t')or(l[i]='T')
or(l[i]='v')or(l[i]='V') or(l[i]='w')or(l[i]='W')
or(l[i]='u')or(l[i]='U')or(l[i]='x')or(l[i]='X')
or(l[i]='y')or(l[i]='Y')or (l[i]='z')or(l[i]='Z') then
kol:=kol+1;
end;
WriteLn('kol=',kol);
Правильно ли? И каким ещё образом можно подсчитать длину?
Однажды пришлось мне настраивать SMS-уведомления сотрудникам компании о предстоящих мероприятиях. Ну, как обычно: делаю выборку телефонов и имён из БД, перебираю массив и отсылаю сообщение: «%name%, напоминаем вам, что…» Вследствие того, что у одного пользователя может быть больше одного телефонного номера, сделал ещё один перебор массива с номерами внутри массива с сотрудниками. Поставил LIMIT 1 в SQL-запросе, проверил на себе — всё работает. Убрал лимит и запустил скрипт.
Заподозрил
Устроился я, будучи ещё молодым и наивным, в одну мелкооптовую фармацевтическую контору сисадмином-эникейщиком. Конторка была аж из пяти человек, хоть и являлась филиалом крупной московской фирмы. Начальником был человек импульсивный — очень стремился доказать, что он совсем не хуже головного отделения, и даже завёл свой IT-отдел в виде меня. Себя он считал очень подкованным в компьютерном деле, поэтому начальственная фантазия била через край.
Однажды шефа посетила мегамысль: увеличение производительности труда менеджеров путём разработки для них специализированного ПО. «Можешь?» — спросил он у меня. «Могу, — ответил я и добавил: — Если ТЗ будет».
День в муках рождался документ, и вот настал торжественный момент передачи задания исполнителю. Я развернул лист и увидел там самое краткое ТЗ в мире:
Программисту написать программу.
—
— Секундочку… Ваш Мягкомогилкин уже жив.
— А если я своего Мастдайного сегодня похороню, я его потом смогу воскресить? А то он у меня один остался. Жалко
— Хороняй, завтра воскреснет.
—
— Дай почитать, как он ругается.
— Зря ты документ подписала. Теперь до понедельника не вернём.
— Жаль. Он был хорошим пациентом, верным больным и так хотел жить в свои 102 года. И, главное, у меня уже не осталось тестовых пациентов. А новых создавать уже фантазия кончилась.
— Тоже мне проблема. Клонируй кого-нибудь, имя-отчество местами поменяй — и готово.
— Вы заманали каждый день Неродилкина хоронить! Я
Тестирование системы оперативного мониторинга смертности. У врачей своё кладбище, у админов — своё.
На днях к сестре ездил комп реанимировать. Пока лифт ждал, услышал, как детишки лет десяти обсуждают, на кого лучше учиться. Один говорит: «Я на программиста пойду, лохов обманывать буду».