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

Резултати

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

Търсене: #geotools

当前筛选 #geotools清除筛选

#geotools Еще один повод обратить внимание на мощный и понятный пользователю инструмент для пространственного анализа. Единственный язык, который нужно хоть чуть-чуть знать, чтобы работать с ним - это английский. Ссылка : https://geodacenter.github.io

Hashtags

О городах и данных

@datainthecity · Post #113 · 31.01.2022 г., 19:45

#geotools#geodata Интересную статью выдал мне medium под вечер понедельника и внес немного баланса во вселенную. В статье автор показывает, как с помощью несложных манипуляций с OSM и геотеггированными фото становится возможным слежка за Большим Братом. Именно так, на мой взгляд, и должны работать открытые данные - давать информацию о действиях властей, которую они сами открыто афишировать не планируют, тем самым позволяя обществу контролировать власти в ответ на их контроль. У меня только один вопрос: даже если выборка неполная, точно ли локации военных баз - эта та информация, которая должна быть в открытом доступе на OSM?🤔

#geotools#geodata Хорошим поводом отвлечься от рабочих геозадач и применить свои знания для решения актуальной городской проблемы стал хакатон сервиса аренды самокатов Whoosh , первый этап которого прошел в эти выходные. Организаторы сформулировали 3 темы : безопасность поездки, навигация и транспортная доступность. Наша команда решала задачу обеспечения безопасности. Мы предложили на основе данных об авариях с участием самокатов и исторических данных о скорости их передвижения создать карту, где все участки дорог в городе будут проранжированы по уровню их безопасности для езды на самокате. Это позволит сервису улучшить свои рекомендации маршрутов, а ДТ правильно выбирать зоны для ограничения скорости. Небольшие выводы по ходу работы: 1. Наиболее удобный формат работы с геоданными: собирать и обрабатывать в питоне (библиотеки geopandas, shapely), визуализировать - в web-сервисах, мой личный топ - Unfolded.AI. Про него лучше написать отдельно, скажу только, что его делали ребята из uber - авторы kepler.gl и h3, а потому он имеет в себе весь их функционал и даже болеьше. У участников, кто пользовался qgis, 6 млн строк историии поездок на самокате сильно висели и они мало, что успели сделать. 2. искали решения похожих задач зарубежом: нашли bike compatibility index ( например, но для самокатов ничего подобного пока не расечили, а они на волне популярности удже 3 года 3. Некоторые датасеты портала ОД Москвы обладают удивительным свойством : в их названии есть слово “ Карта“, при этом они не содержат геоданных, как например эта “Карта среднемесячной загруженности дорог с индексами загруженности” 4. Из-за небольшой погрешности коодинаты самокатов плохо привязываются к графу дорог, загруженному из OSM. Чтобы это сделать нужно сначала создать прямоугольный buffer вокруг линии 5. При построении модели прогноза аварийности, если не хотите получить вывод, что аварий больше там, где больше самокатов, используйте в качестве таргета вероятность аварии, а не абсолютное число) 6. Карта ДТП (https://dtp-stat.ru/) - замечательный источник полезных открыты данных о Москве 7. Не хватило открытых данных по скоростным ограничениям для автомобилей, а также по парковкам и зонам для самокатов. Еще мы мечтали о ширине тротуаров Первые выводы по самой задаче : 1. В Москве между числом аварий и уровнем пешеходности есть сильная прямая зависимость, то есть, чем больше может быть людей на улице, тем выше вероятность столкновения 2. В Москве наличие велодорожек никак не коррелирует с аварийностью, хотя в Европе установлено, что на велодорожки приходится самый низкий уровень аварий. Видимо, в Москве их длина настолько незначительна относительно всей длины дорог, что модель воспринимает их наличие и ширину, как погрешность 3. Вне центра Москвы почти все аварии на дорожных развязках. Кажется повод задуматься о наземных переходах. 3. Скутеры, благодаря встроенной системе gps и гибкости в выборе маршрутов , отличные источники данных для изучения поведения горожан на улице