Category: дизайн

Category was added automatically. Read all entries about "дизайн".

И про голанг

https://www.facebook.com/alexclear/posts/10206939303546236 (извините за говно-фейсбук)

>"Go это новый PHP. Сделаем дизайн языка говно потому что ничего не умеем, оправдания придумаем постфактум (мы уважаемые чуваки, стояли рядом когда Си разрабатывали, поэтому слушайте нас мы знаем как правильно). Авторы PHP вон честно писали в рассылке, что "дизайн языка такой, потому что мы в процессе учились писать парсеры и вообще не настоящие сварщики")."

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

Язык сделанный тупыми для тупых - можно выбирать для прода без опасения, что не взлетит или что коллеги не осилят.

И о врагах рода человеческого.

"System.IndexOutOfRangeException: Could not find specified column in results."
Я чего-то в этой жизни не понимаю, но конкретно в этом месте дотнета живут черви и змеи.
Я ни разу не видел, чтобы в исключении показали данные, которые привели к вызову исключения - имя поля там, индекс и диапазон, за пределы которого он вышел и прочее такое.

Это что, в каких-то книжках по дизайну исключений специально написано: "никогда не показывайте точные данные, а то при эксплуатации смогут понять, что они сделали не так и исправить"?

Дотнет UI

За то время, которое уходит на исправление мелкого визуального бага в дотнетовском UI layout (без дизайнера, у меня UI генерируется) в серверном back-end на clojure можно реализовать весь анализ метаданных JDBC и генерацию CRUD запросов к таблицам из них.
Дичь какая-то. При этом баг в принципе не мешает работать с программой, является заведомо менее критичным чем все остальные задачи. Но мелкие косяки UI бесят настолько, что желание вообще этот проект открывать пропадает.
Например, неравномерное расположение текста (текст не помещался в метку, рендерер при этом смещал текст на пару пикселей вверх) или несимметричное расположение поля ввода и названия из справочника для него (размер строки грида для layout был на 2 пикселя больше нужного и textbox при этом не меняет свой размер (игнорируя DockStyle), а label - меняет).

Или еще одно безумие: MenuStrip у которого высота меняется в зависимости от того, есть ли в нем Separator. При этом меню не статическое - оно генерируется исходя из текущей открытой закладки и поэтому переключение между закладками вызывало прыгание всего layout.
Ну это чисто визуальные баги, а еще ж горы юзабилити-багов - то фокус ввода не туда попадет и лишнюю кнопку нажать надо, то горячие клавиши для меню не всегда работают, то еще что.
И, блин, привычные методы починки - медитация на код, логи и структуры данных в этом случае не помогают - потому что моего кода там 10% от кода самого дотнета, который или недоступен или нечитабелен, а все вызовы происходят в контексте обработчиков сообщений винды с дикими стек-трейсами вида "ProcessVoodooItems->DoCallVoodooMethod->DoCallVoodooMethodInternal->GetCanCallVoodooMethod->OurOwnVoodooMethodHandler".
Вместо этого отладчик и пиксель-хантинг, слава богу, хоть в коде а не в дизайнере форм.

Что у нас в FP есть в плане анализа предметки

и синтеза дизайна системы?
Тут народ вопросом задается: http://guamoka.livejournal.com/1047171.html

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