TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #721 · 26.12

Почему я люблю языки с сильной системой типов, проверяемой статическим анализом кода — хорошо написанная программа является своей собственной спецификацией и позволяет выражать через язык программирования законы существования предметной области. Когда-то давно я писал на ActionScript. Там была система типов, но вот десериализация JSON'ов по-умолчанию была в какой-то общий Object, к полям которого нужно было обращаться ["по_строковому_имени"]. В один момент мне потребовалось написать что-то на C#, который я совсем не знал, я стал гуглить, как десериализовать JSON, и с удивлением обнаружил кучу советов заранее объявить класс со всеми нужными полями и десериализовать в него. "Какой ужас!", — подумал я тогда, — "Это же дико неудобно! А если я не знаю полей JSON? А если их много? Отвратительный язык!" Теперь то я прекрасно понимаю, что JSON это контракт, и что правильная десериализация только такая и должна быть, и что в хорошем API в одном поле никогда не бывает данных принципиально разных типов, и так далее. Нет, если вы набиваете вечерами пет-проект или сидите бессонную ночь на хакатоне, нет ничего плохого в том, чтобы взять простой язык с динамическими типами вроде JavaScript или Python, не требующий описывать данные. Но вот в энтерпрайзе, особенно когда над одним проектом работает много людей (а бывает это очень часто) — хорошее использование системы типов убережёт разработчиков от огромного количества ошибок, будет бить их по рукам, когда они пытаются сделать что-то не то, и будет подсказывать, когда они не уверены в чём-то. С помощью статической типизации можно на уровне кода обозначить правила, по которым ведёт себя предметная область вашей программы в реальном мире. Разработчику не только будет сложно их нарушить, но он ещё и станет узнавать какие-то вещи, которые мог не знать раньше. Например, если мы делаем медицинскую CRM, и больница заводит новых пациентов только тогда, когда знает их группу крови, мы можем объявить тип "Пациент" (или, если точнее, "Карта пациента") и запретить создавать экземпляры этого типа, не передав в конструктор группу крови (которая, в свою очередь, тоже является типом, вероятнее всего ValueObject'ом). Если новый программист пришёл в проект, он, во-первых, не сможет записать в БД некорректную карту пациента. Понятно, мы не учитываем случаи, когда новый программист переделывает модели предметной области — это будет хорошо видно на кодревью. А, во-вторых, даже если ему никто не сказал, что пациенты должны быть с группой крови, он узнает это из кода. И уже будет понимать, что в тех процессах реальной жизни, которые он описывает кодом, карта пациента создаётся только при наличии группы крови. А, значит, нужно искать какой-то способ сначала эту группу крови получить, и только потом создавать карту. Программирование моделирует реальный процесс. В настоящей работе даже на языках с типами, конечно, без должного контроля можно написать что угодно. Нужна управленческая воля, компетентность руководства, понимание опасности техдолга, в идеале отдельные должности для архитекторов, опытные лиды и старшие разработчики. Но когда всё это есть, можно отсекать много проблем ещё на старте и проще погружать новичков. #dev

Hashtags

Резултати

Намерени 1 подобни публикации

Търсене: #momepy

当前筛选 #momepy清除筛选
О городах и данных

@datainthecity · Post #178 · 27.11.2023 г., 12:55

#momepy#landuse Сейчас по работе решаю задачу выделения в городе разных функциональных зон, а также разделения города на кварталы в зависимости от их уровня экономического развития. Это довольно популярная проблема, когда сервис нацелен на определенную аудиторию, а в регионе структура населения неоднородна. Я решаю задачу для столицы Нигерии - Лагоса, где по данным World Bank наблюдается чуть ли не самый большой в мире индекс неравенства: трущобы, где люди до сих пор выбрасывают отходы в реку, перемежаются с районами вилл самых богатых людей Африки. Соответственно, мне нужно как минимум научиться отличать первые от вторых, а еще желателно выделять "средний" класс, а также зоны коммерческого и индустриального использования Из данных: - building footprints (от microsoft и со спутников) - дорожный граф из OpenStreetMap - POIs ( у нас есть скрепер с Google Maps, но можно и из OSM) - население из HDX по квадратам на 1км - Скоры на основе переписи населении по уровню покрытия связью и экономическому уровню, рассчитанные на электоральные районы Как видите никаких мобильных данных или данных о тратах по картам, которые бы хорошо помогли ответить на вопрос об экономической активности населения, нет. Поэтому решать задачу придется полагаясь на гипотезу о различии морфологии бедных, средних и богатых районов. Для этого я использую python библиотеку momepy, где автор Martin Fleishman собрал все возможные метрики, связанные с описанием расположения зданий в районе. Вот тут можно найти ноутбук с его воркшопа. В комменты поста кинули еще вот такой пример работы с библиотекой. Все что нужно для работы с библиотекой - это building footprints, код на загрузку улиц за вас уже написан😊 Прикладываю вам для вдохновения красивую картинку, где дома раскрашены по показателю intensity. Дальше возникает вопрос, что делать с получившимися метриками? Как определить порог, по которому можно отличить районы. С одной стороны для такого города как Лагос вопрос звучит несложно: в трущобах застройка явно плотнее, чем в богатых районах, а улицы там явно рисовал не urban planner. С другой стороны, а в моем случае требуется точность близкая к единице - ошибиться и предложить клиенту развивать сервис в районах, где нет электричества будет стоить компании как минимум репутации. Кроме того, вопрос land use это не решает Найти правильный ответ на вопрос мне еще предстоит, а пока делюсь текущими вариантами и источниками В качестве вдохновения для экспериментов взяла 3 статьи: 1. Статья про выделение трущоб для Найроби (как раз на основе momepy). Тут авторы предлагают обойтись без таргета и сделать иерархическую кластеризацию на основе метрик зданий. Идея хорошая, вопрос в невозможности оценить точность и нет ответа про land use 2. Свежая статья про выделение функциональных зон в 2х районах Сингапура. Авторы решают задачу на основе плотности POI из разных категорий (KDE) и кластеризации. В моем случае частично решает проблему 3. Статья про выделение трущоб в Джакарте на основе Remote Sensing и анализа Street Views. Для меня эта статья интересна возможностью переиспользовать отвалидированные модели, выученные на одной стране, для другой. Риск здесь - различия в морфологии трущоб. Как будут результаты обязательно поделюсь получившимся решением, а пока держите красивую картинку Лагоса на основе метрики intensity из momepy