Category: философия

Category was added automatically. Read all entries about "философия".

404

пример квадратно-гнездовой деоптимизации

Самым интересным примером деоптимизации во имя упрощения я считаю отсутствие регистров в модели памяти практически всех языков программирования. Даже самые упоротые на производительности языки не хотят притаскивать в модель памяти регистры. Оптимизатор может их использовать (и использует!), но на уровне абстракции их нет. Если их принести в язык, наверное, есть моменты, когда можно будет сделать тоньшее и точнее. Изящнее.

Но нет. Мы выжигаем всю изящность и оставляем квадратно-гнездовое "все непустые переменные в памяти у всех объектов в памяти есть адрес" (я про условный C/Rust).

Этот переход - пример сильной абстракции, которая скрывает детали реализации. При том, что с низкоуровневой точки зрения язык пушит невероятное количество policy, с высокоуровневой язык почти целиком состоит из tool.

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

Посмотрите на все великие абстракции окружающего мира - файлы, tcp, переменные... Каждая из них выжигает за собой всё. И каждая из них велика. И посмотрите на анти-паттерны. Делает ли cron описание "выполнить по таймеру" проще? Делает ли Makefile хоть что-то проще?
404

и ещё рефакторинг

Важный milestone: getPath сократилась до 100 строк, а всё это покрыто 60+ тестами. Надо бы больше, но некоторые кейсы я просто не могу нормально написать без софтмоков, а их ещё делать. (О чём речь: я не могу использовать untitest.mock, потому что это python2, и не могу использовать mock, потому что ограничения проекта). Мне предложили делать тесты, которые skip, если нет модуля mock, но эту штуку ещё отдельно писать надо.

На горизонте строки 425-994, которые представляют из себя остаток getSVG (из которой я, собственно, getPath и несколько других функций и вытащил). Да-да, добрая такая функция на 500+ строк, которая всё ещё делает Почти Всё.

В целом, я ощущаю, что оно чуть-чуть из рук выскользает, потому что в новом коде довольно много тестами не покрыто, но хочется дальше деребанить getPath. Но надо-таки покрывать то, что уже надёргано. Цикломатическая сложность понизилась, и самое-самое время начинать заморачиваться с тестами всяких corner case'ов, потому что в них как раз баги и обитаются...

Вот, например, из вытащенного:

def toSpline(edge):
    bspline = edge.Curve.toBSpline(edge.FirstParameter, edge.LastParameter)
    if bspline.Degree > 3 or bspline.isRational():
        try:
            bspline = bspline.approximateBSpline(0.05, 50, 3, 'C0')
        except RuntimeError:
            print("Debug: unable to approximate bspline")
    return bspline


Мне нужны тесты на:
1) кривые с Degree > 3
2) isRational (насколько я понимаю, это кривая Безье, описывающаяся полиномом с дробной степенью)
3) На ситуацию, что кривую не аппроксимировать.

Понятно, что моки спасут отца русской демократии, но мне хотелось бы записать в тесты всё-таки настоящий результат - с такой самой кривой, у которой такие загогулины.
404

Архитектурно-философское, про best practice

Часто столкнувшись с слегка нестандартной задачей я испытываю замешательство, потому что не знаю и не могу найти никаких существующих практик для её решения.

Это можно было бы счесть всего лишь "не знаю как делать и не хочу заморачиваться", но внутри я ощущаю что-то более сложное.

Это что-то сложное - не желание изобрестать велосипед там, где его уже изобрели с одной стороны, и боязнь коммита на "создание архитектуры". Когда что-то делаешь в рамках практик, то в той или иной мере двигаешься по хорошо известной архитектуре. Часто желание не изобретать свои архитектуры звучит так: "так надо делать потому что так делать положено". Например, положено делать питоновые программы с setup.py. При использовании уже существующих практик не только заимствуется хорошая архитектура, но и часто "за бесплатно" (то есть без необходимости об этом думать специально) обеспечивается совместимость с чем-то, о чём ты даже и не знаешь в момент, когда делаешь.

Таким образом, когда оказываешься в ситуации, когда известной практики нет, ты о существовании практики не знаешь, или существующая практика не подоходит - короче, когда надо изобретать своё, в этот момент, чем больше опыта, тем острее он давит и говорит о том, какие последствия будут. Очень отдалённые и очень неприятные. Ощущение "и чем я думал, придумывая вот эту хрень?", повторяющееся несколько раз, оно очень дисциплирует.

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

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

Вот, яркий пример: ну откуда мимо пробегающий программист знает про систему /etc/nginx/sites-available/ и sites-enabled? Он идёт читать маны от nginx'а, после чего идёт и херачит всё в nginx.conf, а при переносе в продакшен сисадмины только за голову хватаются (иногда от сарказма иногда от того, что не уследили и оно пролезло в продакшен).

А ведь проблема не в том, что "программист глупый". А в том, что это устное предание. Едва ли не культурная традиция, которая витает меж сисадминами.

И в других областях то же самое - я иногда чувствую очень конкретный сарказм у программистов по мотивам написанного мною. И не потому что "плохие алгоритмы", а потому что я не соблюл очевидные (для них практики). А где я про них узнать могу-то?

Вотъ.
404

О Хикикиkekekekeмори

Проблема Хикикимори не нова. Не верите? Откройте школьный учебник по литературе. Найдите фамилию Гончарова. Да. Обломов. Классический NEET, Хикикимори. Живущий в домашней помойке, слабый, боящийся общения с людьми, апатично подчиняющийся пытающемуся вытащить его из жуткого хикки энергичному другу и так же сваливающися обратно. Вспомните NHK. И (если помните) хоть чуть-чуть Обломова. Ведь сюжет (с поправкой на время) почти совпадает. Те же безуспешные и вялые попытки вырваться из затягивающего уютного и безопасного одиночества. То же апатичное состояние.

Что же различает Хикимори и обломовщину? Ответ - интернет. Во времена обломова человек, запирающийся в доме в далеке от окружающих выпадал из жизни и общения. Это было дно, дно куда более глубокое, чем горьковское. Человек умирал в обществе. О нём забывали, его существование проходило неслышно и невидимо.

Что же мы видим в лице типичного хики? Всё, что есть у Обломова, плюс, имаджборды, ММОРПГ, форумы, чаты. Сублимация общения разной степени интерактивности, симуляция активной деятельности (ах, корейский манч по вырезанию бабок в клоке...), сублимация ответственности и социальной важности личности (да я ГМ самой крутой гильды на сервере, да я пауэр администратор веб2.0 ньюс проекта). Для особо продвинутых личностей возможность ощутить "настоящую социальную значимость" в лице опен-сорс программиста или автора в вики. Высочайшая доступность информации, развлечений, всех форм проведения досуга. При условии, что за компьютером. (Покупатель может выбрать любой цвет машины, при условии, что он будет чёрным (с) Генри Форд).

Именно в этом опасность хикки-состояния по сравнению с обломовщиной. Обломовщина - тупик. Хикки - магистральная дорога с указующими знаками.