• Анализ сишного Hello World
    +3
    Так тут всё вполне просто, никаких наворотов.
  • Лопнул ли пузырь машинного обучения, или начало новой зари
    0
    В 2008-2012 стоимость массовых математических операций упала в 100 раз и затем ещё продолжала падать, из-за их реализации в GPU.
    Плюс ещё 10 лет на типовую раскачку рынка.
    По-моему, этих факторов достаточно, чтобы обосновать и хайп, и его завершение.
    Теперь же отработали все первые последствия технологического прогресса, и началась нормальная работа.
  • Авторы GandCrab прекращают работу: они уверяют, что украли достаточно
    0
    Если они не врут, что сумели легализовать доходы, то они этого достигли?
    А методов для этого достаточно много…
  • Заблуждения программистов о Unix-времени
    0
    Нет, «время Unix» может быть указано с какой угодно точностью, например:

    $ python3                                          
    Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
    [GCC 8.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import time
    >>> print(time.time(), time.time())
    1559375816.5301785 1559375816.5301788
    


    между вызовами, как видим, прошло около 300 наносекунд, и это видно в представлении (в double).

    В Posix давно clock_gettime() обещает в пределе наносекундную точность, а в последних версиях есть вызовы для времён файлов такой же точности.
  • Заблуждения программистов о Unix-времени
    0
    Когда эту «совместимость со старыми зонами» по умолчанию устанавливают чуть более, чем все, это не совместимость, это и есть основной вариант: то, что называется UTC в Unix и Unix-like, это тот вариант, в котором вставных секунд (или, наоборот, забранных секунд, если бы такое вводили) нет и не будет. Глава Posix, посвящённая расчёту времени, устанавливает формулы, которые ничего не знают про вставные секунды, и это важнее формального факта применения термина «UTC».
    То же на практике касается и Windows (и т.наз. NT time в ней), хотя стандарта на это нет.

    Конечно, безумец может установить себе таймзону типа right/UTC, но при этом у него сломается всё, что можно.

    Кому нужно реально учитывать вставные секунды — увы, ему придётся применять особые технологии счёта времени.
  • Уроки украинского
    +3
    > и эти вот яры — склоны оврагов, берега рек, особенно направленные в южном направлении

    Идея понятна, но этимологические словари говорят, что это заимствование из тюрских языков, где идентичное слово и имеет видимые корни. Я таки рекомендую смотреть в словари перед выдвижением подобных гипотез :)

    > А ещё наша «яркость» вполне может как то в эту компанию входить. Да и «ярость» вполне может быть (разве Солнце, особенно весной, не яростное?).

    Тут, да, однокоренные — и общий смысл восстанавливается примерно как «сила, страсть, огонь».
  • Возможности Python 3, достойные того, чтобы ими пользовались
    +2
    > Без print не работает

    Конечно, если пробел впереди воткнуть — работать не будет.

    >>> 3 == "10"
    False
    >>>  3 == "10"
      File "<stdin>", line 1
        3 == "10"
        ^
    IndentationError: unexpected indent
    


    только print тут ни при чём.
  • Уроки украинского
    +1
    > некий «Капустин Яр»

    В данном случае это наверняка «овраг», мужского рода, и это не только Западная, это вся Украина. К «яр» в смысле «весна» оно просто омоним.
    В Киеве разных яров куча (Бабий Яр — печально знаменитый, Репьяхов, Кучмин, Божков, Афанасьевский, Хрещатый, Цимбалов — это только с ходу из тех, что сохранились как-то в топонимике).

    «Яр» как «весна» известно по древнерусскому, но сейчас это просто поэтический атавизм (или как ещё назвать намеренное восстановление вымершего слова? хотя, возможно, в горских диалектах оно сохранилось, тут мне словари молчат)
  • Знакомство с Python для камрадов, переросших «язык A vs. язык B» и другие предрассудки
    0
    $venv/bin/pip install
  • Что делать при сбое оперативной памяти. Анамнез и методы лечения
    0
    Когда у меня в основном рабочие сервера были на FreeBSD, лучшим рецептом было запустить make world в цикле. Круга 4 прошло => память достаточно целая. GCC ну очень активно гонял данные в памяти.
    По эффективности это было сравнимо с где-то неделей memtest86.
    Под другими Unix системами можно просто собирать GCC или Clang по кругу с тем же результатом.
  • Знакомство с Python для камрадов, переросших «язык A vs. язык B» и другие предрассудки
    0
    > например:

    В C/аналогах можно к каждой } ставить комментарии (типа "// for(i)"), в некоторых стилях это даже рекомендуется.
    Для Питона я аналогично ставлю (если иначе слишком тяжело читается) "#end" с уточнением, что именно закрылось.

  • Знакомство с Python для камрадов, переросших «язык A vs. язык B» и другие предрассудки
    0
    В языках с явными {} по этим самым {} можно переходить на противоположный знак (в vim по умолчанию это клавиша %). В Python такого нет, нужны другие средства навигации. Если читатель глазами не видит, то некоторые задачи сильно усложняются. Например, пусть есть конструкция if — elif — … — else на много веток. Как перейти на следующий elif?
    Меня в обычной работе спасает плагин indentwise — в нём по ]= переходит, если есть следующий, иначе остаётся на месте. Но для PyCharm уже такого нет (есть collapse block, но это другое; свёртка и в vim есть, её тоже использую, но очень часто нужно видеть и что творится в таком блоке).
    Самое путаное в таком — это случай, когда закрывается сразу несколько блоков — тогда это не видно в точке закрытия. Там, где это важно для чтения, я добавляю явную строку "#end" на каждый такой блок.
    (Всё это, разумеется, если нет возможности ужать функции до размера, который можно окинуть одним взглядом. Но у меня сейчас обстановка, увы, именно такая.)
  • Знакомство с Python для камрадов, переросших «язык A vs. язык B» и другие предрассудки
    0
    Строгостью типизации. В Перле она слишком слабая, многие ошибки проходят незамеченными.
    Ещё в Перле разрыв между стилями «для одного экрана» и «для большого проекта», то, что отлично идёт в первом, надо перерабатывать на второй (ссылки на списки вместо явных списков — самый простой пример).
  • Нужно ли чистить строки в JavaScript?
    –1
    Утрируете.

    Статическая типизация не нужна, достаточно, чтобы генерация stray undefined вообще не выполнилась, тогда и это «Cannot read property 'f' of undefined» не возникнет.
    Я не идеализирую тот же Питон, но количество таких WTF в нём в разы меньше именно за счёт того, что есть возможности избежать появления всех подобных null и undefined как можно раньше, а заодно просто не пускать складывать паровозы с апельсинами. Примерно то же, да, даёт TypeScript — но не сам по себе JavaScript.

    Статическая типизация или хотя бы высококачественный статический анализ с учётом type hints и автовыводом, где возможен и хинты не заданы — да, ещё лучше. Я подсчитал недавно, что наш толстый проект на Python по сравнению с тем, что он был бы написан на Java или аналоге, требует раза в 2 больше времени разработки просто за счёт того, что проблемы типизации ловятся на компиляции (а при правильном использовании IDE будет ещё больше разницы). Если что-то ещё более современное — эффект был бы ещё выше.
  • Популярные заблуждения про радиационную стойкость микросхем
    0
    > Итак, вам нужно запустить в космос полмиллиарда реле. Ваши действия?

    Не более десятка — обесточить и включить заново (или не включать) проблемный модуль.
    Ну ладно, сотню.
    Ампера не будет, нужно явно меньше.
    В остальном понял и согласен.
  • Нужно ли чистить строки в JavaScript?
    –1
    > А возвращать undefined на несуществующий ключ объекта это и вовсе полностью валидная логика, что с ней не так? о_О

    Валидная логика — это когда самый умолчательный вариант операции самый защищённый от ошибок — например, даёт исключение.
    Альтернативы могут быть, но они именно что альтернативы.

    Это была первая из причин, почему я когда-то сбежал с Перла на Питон: когда a.b при несуществующем b даёт исключение, а если нужно что-то вернуть по умолчанию — то есть синтаксис типа a.get(b, 0) — это в разы удобнее, чем писать явно if not exists $a->['b'] на каждую проверку, где надо защититься от кривизны.

    > Имхо, это мелочи, которые не доставляют никаких проблем.

    Это мнение опровергается первыми двумя днями отладки типа «а какого чёрта оно не работает?», когда в отчаянии начинаешь расставлять такие проверки на валидность доступа и корректность аргументов операций чуть более, чем везде.
  • Популярные заблуждения про радиационную стойкость микросхем
    0
    > Память продолжает работать нормально, но радиация записывает в некоторые биты неверные значения, которые надо найти и исправить.

    «Записывает» это в смысле «один раз изменила» или «там повреждение, из-за которого они будут неверными теперь навсегда»? Если один раз — то для RAID есть методы типа «перечитать, исправить и записать начисто».
    Если навсегда — ну или как вы в соседнем комментарии писали — «размазывать» хранение одного байта/слова по физически далёким участкам (сработает разве что для памяти; для CPU, шинных модулей, логики периферии и т.п. — уже не поможет), или достаточное дублирование, арбитраж, и помечать неисправным целый компонент.

    > и слабым звеном станет этот аналоговый сумматор. Или следующий за его выходом логический вентиль.

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

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

    Вот и интересно, почему тут именно минимизация помогает, а не максимизация (при которой даже суперчастица ну выбьет нафиг кусок элемента, но остальное будет работать). Это против очевидной логики, а, значит, какой-то ещё фактор в ней не учитывается.
  • Популярные заблуждения про радиационную стойкость микросхем
    0
    > Там решается проблема отказов, а не сбоев.

    Прошу расшифровать терминологию. Отказ — это постоянный переход в нерабочее состояние? Это не было ясно из исходного сообщения.
    В таком случае такое же управление с исключением нерабочих компонентов вполне пригодно (а если есть запасные — тем более). Я не говорю «оптимально», но пригодно должно быть.
    А против проблемы отключения целого модуля из-за минимального отказа вполне поможет дробление этих модулей (до разумного, конечно).

    > и блок арбитража — не исключение. Поэтому он должен быть не столько тупым, сколько маленьким,

    Эээ… если он маленький, то вероятность попадания, да, ниже, а вот последствия — выше.
    На мой чайниковский взгляд — тут надо было бы сделать на той же технологии хоть миллион логических блоков впараллель, но затем аналоговый сумматор результатов и аналоговое их применение — на технике вплоть до сантиметровых размеров :) Или просто логику на грубых дискретных элементах размерами в миллиметры.

    Понятно, что это взгляд со стороны, и погружённый в это специалист предложит как-то иначе.
  • Популярные заблуждения про радиационную стойкость микросхем
    0
    Скорее что-то такого рода (заметьте, это ещё не в космосе, но проблема уже стоит).
    Или вообще дублирование полных компонентов с исключением и перезапуском сбойнувшего. Но в таком варианте всегда вопрос «а судьи кто?» — блок арбитража должен быть тупым как пробка.
  • Нужно ли чистить строки в JavaScript?
    +1
    > На самом деле нет, скажу совершенно непопулярное мнение: да, js очень гибкий, и я считаю это плюсом. В моём опыте было море случаев, когда это спасало. Чаще в целях отладки, конечно (например, чтобы посмотреть, что делает библиотека на канвасе, не копаясь долго в её коде, можно руками переопределить прототип CanvasRenderingContext2D, встроив туда логгирование)

    В Python доступна такая же гибкость. Но бессмысленные действия типа {} + [] он не допускает, автоматической конверсии с потерей важных данных не делает, undefined на несуществующий ключ объекта по умолчанию не возвращает.
  • Почему WhatsApp никогда не станет безопасным
    0
    > Не тешьте себя иллюзиями. С предыдущими версиями Андроида мобильники ещё будут работать 5-7 лет.

    Я бы тешил как раз иллюзиями, что они будут работать это время. На самом деле пришлось вполне топовую модель лет 4 назад перенести в резерв, потому что 8GB встроенного флэша это сейчас, мягко говоря, ничего, а на SD оно не хочет переносить то, что я прошу.
    Ну и физическое умирание устройств — факт, особенно при нынешнем качестве.
    Если у вас 7 лет работает без замены — ооочень повезло.

    > За 7 лет, что у меня есть ведроид никаких вопросов он мне не задавал.

    Ну а начиная с 6.0 задаёт.

    > У вас там поверх Андроида можно накатить иОС!?

    Наверно, нет, хотя я не пробовал. Я уже не помню контекста, в котором надо именно «поверх андроида», разговор слишком далеко ушёл.

    > Вы знаете сколько придётся копить учителю на иОС при зарплате грязными 18 тыс. рублей и квартплате 8 тысяч?

    Я не знаю ваших реалий и даже точного курса денег. У нас вон Зеленский обещал учителям по 4 килобакса. Кто знает, может, и реализует… если доживём…
  • Почему WhatsApp никогда не станет безопасным
    0
    > Далеко не у всех Андроид 6 (у меня например).

    Новые устройства идут под новыми версиями. Старые постепенно дохнут.

    > Далеко не все (скажем, 95% пользователей) понятия не имеют как это делать.

    Вы пробовали сами смотреть, что происходит? Оно таки чаще всего запрашивает полномочия раздельно и надо всего лишь уметь прочитать и нажать «да» или «нет».
    Я понимаю, что есть такие, для кого и это сложно…

    > Итого: какие есть АЛЬТЕРНАТИВЫ Андроиду на МОБИЛЬНОМ телефоне?

    Ну, очевидно, iOS :) Но это уже не моя тема, так что умолкаю.
  • Почему WhatsApp никогда не станет безопасным
    0
    Начиная с Android 6:
    1) Можно регулировать разрешения
    2) По полиси приложения обязаны мягко запрашивать разрешения и обосновывать своё желание (хотя то, что я вижу — назойливое раз в несколько дней «ну разрешите мне!»)
    3) Для многих действий предписано использовать штатные механизмы — типа не «дай доступ к камере!» а «есть штатный intent сделать фотку, зови его».
    В дальнейших это утяжелялось (причём, возможно, чрезмерно — см. этот шумный постинг).

    Разумеется, есть ещё такие приложения, что «всё или ничего!», но им всё сложнее попасть в магазин.
  • Математики обнаружили идеальный способ перемножения чисел
    0
    Посмотрите на GMP. Там есть регулярно пересчитываемые для разных процессоров границы применения методов, чтобы функция сразу выбрала подходящий согласно длинам сомножителей.
    Вот, например, для Zen серии в 64 битах при переходе меньшим сомножителем границы 22 лимба (лимб тут будет 64 бита => то есть длина 1408 бит) происходит переключение от «schoolbook» (квадратичное умножение всего на всё) к, чуть упрощая, методу Карацубы (записан как TOOM22; метод Карацубы является частным случаем Тоома-Кука; ТК это вообще не конкретный метод, а метаметод, который можно «заземлять» в неограниченное множество алгоритмов). Дальше до 460 лимбов (29440 бит) идут разные варианты ТК, но с этой границы включают Шонхаге-Штрассена.
    Для других линий процессоров константы будут другими, но общая картина сохраняется где-то на том же уровне.
    Более дорогие и тяжёлые методы вроде Фюрера там не применяются, видно, решили, что выделки не стоит (реально при таких свойствах процессоров он начал выигрывать бы где-то от миллиона бит).
  • Математики обнаружили идеальный способ перемножения чисел
    +1
    Вещественные числа давно уже делят, например, Голдшмидтом, и квадратный корень аналогично — с тех времён, как научились рассчитывать погрешность при таких вычислениях. Но в остальном — последствия такие же по сути, да, как для Ньютона (по ссылке — 1 цикл для single, 2 для double, 3 для extended).
  • Математики обнаружили идеальный способ перемножения чисел
    0
    > Кстати, а есть подвижки по алгоритмам деления больших чисел?

    Похоже, пока всё плохо. Если смотреть на GMP, по-прежнему основным рабочим методом остаётся итеративное деление на округлённый делитель, хотя его делают через обратное умножение, экономя на собственно процессорном делении.
  • Математики обнаружили идеальный способ перемножения чисел
    +1
    Ну вот странно, что сравнивают с методом Карацубы, а не Тоома-Кука.
    Последний требует O(n^(1+ε)), и это ε можно уменьшать как угодно (ценой роста коэффициента), и по сравнению с O(n*log(n)) это по-прежнему несравнимо. Хотя на практике переходят к Ш-Ш на числах от нескольких десятков килобит…
  • Топ 20 ошибок при работе с многопоточностью на С++ и способы избежать их
    0
    Это понятно, но заметно непрактично.
    Если вы *ether_send пометите как volatile, то компилятор может переставить запись остального после его записи — потому что не видит никакой связи между сторонними эффектами и тем, что не имеет таких эффектов. Значит, надо помечать как volatile формирование дескриптора пакета, а это уже убивает все возможные оптимизации в этом формировании. Остаётся только порядок операций из-за зависимостей данных.
    А явный барьер решает эту проблему дёшево и эффективно.
  • Семь неожиданных переменных Bash
    –4
    Хранение истории в bash (точнее, в общем readline) действительно ужасно.
    Это как раз то место, куда напрашивается применить sqlite :)
  • Почему у нас осталось так мало от раннего интернета?
    +9
    > А вот чертежи Да Винчи и его изобретений имеют огромную ценность и никому в голову не придет никогда их уничтожить.

    И какая именно у них ценность? Он придумал что-то, что мы не можем придумать с современным техническим уровнем? Ничего такого нет, всё или изобретено и реализовано, или было бы ну может на пару лет позже придумано, не имея прототипа.
    Мы можем гордиться гениальным итальянским провидцем, но интерес тут чисто исторический и там, где история науки известна из десятков источников.

    А вот каждое «как готовить похлебку в каменной печи» может представлять другой язык, которого ещё не знали, имена, про которые не слышали, легенды, и прочая и прочая. Да, ценность будут иметь 0.1% от всех находок, но, например, несколько раз одна-единственная двуязычная надпись помогала расшифровывать древние языки. Тоже история, да, но разнообразнее.
  • Поймай меня, если сможешь
    0
    > И всё это со слов одной стороны…

    Я был с обеих сторон (хотя не в том варианте, как во второй статье — я не был секретным ревизором). Разумеется, на практике я бы выслушал обе стороны, но мы-то обсуждаем художественный вымысел? А в нём достаточно зацепок, чтобы определить степень достоверности изложенного.
    А про сочинение про позицию второй стороны (запощенную пару часов назад) я уже высказался, повторяться не буду.

    > Ну да ладно, мне все равно, кому какой урок нужен — такой и выучит.

    Именно так.
  • Поймай меня, если сможешь
    +1
    Если держаться в рамках жёстких условий «переменных столько же, сколько уравнений, определитель ненулевой, изменения коэффициентов слабо влияют на корни» — то да, банально. Но на практике могут быть заметные усложнения:
    1. Уравнений больше, чем переменных; все одновременно удовлетворить нельзя, ищется решение, которое их оптимально удовлетворяет для некоторого критерия. Например, метод наименьших квадратов — ищет решение, чтобы сумма квадратов разностей между левыми и правыми частями была минимальна.
    2. Малые возмущения коэффициентов резко меняют корни уравнения — задача практически приближается к понятию «некорректной» (это абстракция, когда вообще нельзя сделать ограничение изменение x от изменения A каким-то конечным числом; но и слишком большое конечное число тоже может быть непригодным для практики). В этом случае вводится (разными методами) зона неопределённости корней и корни «притягиваются» к каким-то желательным значениям в пределах этой зоны.
    3. Определитель опасно близок к нулю — так, что погрешности вычислений или задания коэффициентов могут его довести до 0. К этому можно прийти даже от банального переноса уравнения 4-го порядка на разностную схему. Частично эта ситуация пересекается с предыдущими.

    Цитата в тему:

    — Что есть заинтересованное… — начал Роман, но Эдик перебил его.
    — Неужели Печать? — спросил он с ужасом.
    — Да, — сказал Роман. — Увы.
    — Большая?
    — Очень большая, — сказал Роман.
    — Ты такой еще не нюхал, — добавил Витька.
    — И круглая?
    — Зверски круглая, — сказал Роман. — Никаких шансов.
    — Но позвольте, — сказал Эдик, с видимым усилием стараясь подавить растерянность. — Если, скажем… скажем, оквадратить? Скажем… э-э… преобразование Киврина — Оппенгеймера?..
    Роман покачал головой.
    — Определитель Жемайтиса равен нулю.
    — Ты хочешь сказать — близок к нулю?
    Витька неприятно заржал.
    — А то бы без тебя не догадались, — сказал он. — Равен, товарищ Амперян! Равен!

    так вот, в обычной практике определитель таки чаще близок к нулю, чем равен, и АБС это знали :)
  • Поймай меня, если сможешь
    0
    > Весь прикол в том, что сработала именно эта ссылка на ГК с проведением аналогии задачи в трекере с гражданским договором, в котором содержание толкуется буквально, при этом совершенно не учитываются разного рода умолчания. Так как до этого в трекер попадала всякого рода муть, сопровождаемая в процессе уточнения задачи фразой «ну это же всем понятно».

    Хм, понятно, спасибо. Сохраню себе в копилку. Во всех моих случаях такой метод только напугал бы, а у вас явно другая специфика :)
  • Поймай меня, если сможешь. Версия менеджера
    +4
    «Мёртвые души», том 2. Можно было бы долго раскрывать фантастичность такого персонажа, но классик всё сказал за меня.
  • Поймай меня, если сможешь
    0
    > И сомнения эти возникли потому что так написал один из вахтеров???

    Потому что так написал автор. Я не имею причины априори считать его вахтёром.

    > В данном случае, по описанию, действия «вахтера» более похожи на саботаж. Насколько я понял, обратная связь, как раз-то и была…

    Если над наноменеджером заслуженно смеётся весь завод (сказано прямым текстом), какая обратная связь?

    > Но в силу обьективных причин начальник владеет/должен владеть большей информацией и не всегда она может быть доступна всем.

    Ну вот тут это явно не выполнялось.
  • Поймай меня, если сможешь
    0
    > В конце концов этот менеджер был предусмотрен процессом.

    У меня есть сильнейшие сомнения, что то, что там происходило, соответствует слову «процесс» хоть в каком-то его понимании.
    Вот на попытку прикидки этого процесса методом установки экспериментального компонента — подходит значительно лучше.

    > Нихрена себе… Синдром вахтера в АйТи…

    Синдром вахтёра, как видим по описанию, как раз у менеджера.

    > тебя не устраивает — заявление-чемодан-свой бизнес-свой кредит под залог квартиры-свои(правильные) методы управления…

    Вообще-то даже в тоталитарной армии есть обратная связь. Вы же отказываете ей в праве на существование. Почему «чемодан-вокзал» не применим в этом случае и к вам?
  • Поймай меня, если сможешь
    0
    > Лично я не представляю себе работы без трекера. Для личных проектов использую облачный сервис www.jetbrains.com/youtrack

    Ну это уже вопрос выбора конкретного трекера — сколько я их уже перевидел, а вообще их десятки. RT (старый, но работает), youtrack (у нас сейчас для девелопмента), JIRA (классика энтерпрайза), Wrike (невменяемый ужас, JIRA и то лучше; но шумно рекламируется), Trello, OTRS, Bugzilla, GNATS, Redmine — это только то, что сам использовал. Да, список неровный — Trello это вообще канбан-доска, OTRS хорош для поддержки сторонних пользователей, но не своих, и так далее… можно было выбрать любое из них.
    Но всё-таки главное тут то, что в результате упираемся в два вопроса — кому это нужно (реально) и сколько это будет стоить? Кто будет составлять заявки, зная, что 90-95% пользователей просто не в состоянии толком описать проблему? Обычно в таких условиях это превращается в трекер времени, а не трекер заявок/тикетов/etc. — просто средство для составления форм отчётов о проделанной работе. Полноценный трекер описанного типа становится нужен, когда несколько участников им пользуются по правилам, а не только один — то есть тут нужны или как минимум 2-3 исполнителя и тот наноменеджер, или исполнитель (лирический герой), начальник и внутренние юзера (которые обучены составлять заявки). Но если начальник этим не будет пользоваться, то вся такая работа — в топку.

    > написал для экономистов небольшую инструкцию по работе в трекере

    Посмотрел. Я не экономист, но считаю нужным выразить сомнение, что первая часть со ссылкой на ГК что-то даст полезное ;)
    А вот то, что явно нужно было бы — это несколько типовых образцовых примеров — что нажимать, как заполнять, какие типовые формулировки и т.п., чтобы было легче ориентироваться в результате (фантазия конкретных юзеров может улететь при заполнении в такую голубую даль, что фиг поймёте, какое это вообще отношение имеет к задачам фирмы). Или на ваших таки подобный вариант подействовал? Если да — это какое-то локальное чудо.
  • Поймай меня, если сможешь
    0
    > 1. Программист даже не задумывается о приеме на работу себе помощника, который для начала мог бы тупо перезагрузить сервер, если что зависнет.

    Если там, как описано, на весь город три что-то понимающих человека, то, может, и найти такого помощника уже нельзя — достаточно квалифицированный человек уже захочет больше, чем могут давать?
    Хотя я бы в этом случае озадачил подписанием кросс-договоров с теми же «Лёхой» и «Серёгой» — что если что, то коллеги подстраховывают (а он — их). Но, может, и это не получится, из-за специфики работы тех людей.

    Я несколько лет проработал в деградирующей фирме — когда приходил, вокруг были титаны мысли, когда уходил — мы еле-еле находили хоть как-то вменяемых людей. И это в столичном городе. Да, платили слишком мало. Не думаю, что у «лирического героя» есть возможность доставать деньги из воздуха.

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

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

    Трекер — вопрос интересный — что-то вроде RT ставится реально на коленке и вполне себе работает — но опять же под это нужен хоть мелкий, но серверок. Не в курсе насчёт платных сервисов такого рода за относительные копейки, по идее такие есть (за океаном, наверно, не подходят), и им же опять же всех учить, начиная с бухгалтеров… сложно.

    > Ну и напоследок про документацию. Ее просто нет.
    > А это означает, что после ухода программиста все нужно сносить под ноль и ставить все новое. Без вариантов.

    НЕТ. Всё уже написанное должно работать, и переписывать нельзя, вот это точно «без вариантов». Но дай бог чтобы 1 программист из 10 был способен, разбирая код, тут же писать внятные комментарии о том, что он понял, как оно работает и почему. Увы, слабо реально (не знаю почему — я как раз пишу).
  • Поймай меня, если сможешь
    0
    > То есть я, как человек, который бегает как волк и ищет заказы, чтоб прокормить и себя, и программиста и бухгалтера, токаря, электрика…

    А почему вы себя сравниваете при этом всём не с директором из этого рассказа, а с этим наноменеджером?
  • Поймай меня, если сможешь
    0
    Затем, что при строгой системе подчинения любой подобный вопрос должен пройти по иерархии — даже если известно на 147%, что будет отказ. Уже после отказа можно пытаться идти через голову начальника (понимая возможную отдачу от такого действия). При нестрогой — всё равно желательно.
    А если она не работает и реально все ходят через голову — значит, надо что-то менять.