@cogload · Post #118 · 09.11.2023 г., 07:02
Буду потихоньку тизерить личный проект. Покажу процесс и что в итоге получилось На видео собираю данные 👩💻 #hoith
Hashtags
TGINSIGHT SIMILAR POSTS
Изходен канал @clockstackwheels · Post #721 · 26.12
Почему я люблю языки с сильной системой типов, проверяемой статическим анализом кода — хорошо написанная программа является своей собственной спецификацией и позволяет выражать через язык программирования законы существования предметной области. Когда-то давно я писал на ActionScript. Там была система типов, но вот десериализация JSON'ов по-умолчанию была в какой-то общий Object, к полям которого нужно было обращаться ["по_строковому_имени"]. В один момент мне потребовалось написать что-то на C#, который я совсем не знал, я стал гуглить, как десериализовать JSON, и с удивлением обнаружил кучу советов заранее объявить класс со всеми нужными полями и десериализовать в него. "Какой ужас!", — подумал я тогда, — "Это же дико неудобно! А если я не знаю полей JSON? А если их много? Отвратительный язык!" Теперь то я прекрасно понимаю, что JSON это контракт, и что правильная десериализация только такая и должна быть, и что в хорошем API в одном поле никогда не бывает данных принципиально разных типов, и так далее. Нет, если вы набиваете вечерами пет-проект или сидите бессонную ночь на хакатоне, нет ничего плохого в том, чтобы взять простой язык с динамическими типами вроде JavaScript или Python, не требующий описывать данные. Но вот в энтерпрайзе, особенно когда над одним проектом работает много людей (а бывает это очень часто) — хорошее использование системы типов убережёт разработчиков от огромного количества ошибок, будет бить их по рукам, когда они пытаются сделать что-то не то, и будет подсказывать, когда они не уверены в чём-то. С помощью статической типизации можно на уровне кода обозначить правила, по которым ведёт себя предметная область вашей программы в реальном мире. Разработчику не только будет сложно их нарушить, но он ещё и станет узнавать какие-то вещи, которые мог не знать раньше. Например, если мы делаем медицинскую CRM, и больница заводит новых пациентов только тогда, когда знает их группу крови, мы можем объявить тип "Пациент" (или, если точнее, "Карта пациента") и запретить создавать экземпляры этого типа, не передав в конструктор группу крови (которая, в свою очередь, тоже является типом, вероятнее всего ValueObject'ом). Если новый программист пришёл в проект, он, во-первых, не сможет записать в БД некорректную карту пациента. Понятно, мы не учитываем случаи, когда новый программист переделывает модели предметной области — это будет хорошо видно на кодревью. А, во-вторых, даже если ему никто не сказал, что пациенты должны быть с группой крови, он узнает это из кода. И уже будет понимать, что в тех процессах реальной жизни, которые он описывает кодом, карта пациента создаётся только при наличии группы крови. А, значит, нужно искать какой-то способ сначала эту группу крови получить, и только потом создавать карту. Программирование моделирует реальный процесс. В настоящей работе даже на языках с типами, конечно, без должного контроля можно написать что угодно. Нужна управленческая воля, компетентность руководства, понимание опасности техдолга, в идеале отдельные должности для архитекторов, опытные лиды и старшие разработчики. Но когда всё это есть, можно отсекать много проблем ещё на старте и проще погружать новичков. #dev
Hashtags
Търсене: #hoith
@cogload · Post #118 · 09.11.2023 г., 07:02
Буду потихоньку тизерить личный проект. Покажу процесс и что в итоге получилось На видео собираю данные 👩💻 #hoith
Hashtags
@cogload · Post #125 · 20.11.2023 г., 07:36
Как я влюбился в картографию Хочу поделится проектом, который в свое время зажег во мне интерес к картографии и представлению информации. https://nakarte.me/#m=15/46.46893/8.10358&l=O/Si&r=46.798562/8.231974/Switzerland ↑ Сначала откройте ссылку и полистайте карту Все началось с заметки в блоге Эдварда Тафти про топографический атлас Швейцарсих Альп. На примере этой карты, он объясняет принципы хорошей визуализации: Общие принципы - Фокус на содержании. - Высокое разрешение. - Каждый элемент имеет несет в себе информацию, нет элементов «для красоты». - Видно картину в целом, а детали вписаны в контекст и доступны при необходимости. Детали - Объекты органично вписаны в рельеф, нет нужды во всплывающих окнах. По соседним деталям можно понять размеры рядом стоящих. - Контрастные контурные линии проявляют топографический рельеф гор. Подписи рядом с ними и на пиках сообщают количественную информацию. Цвет - Низкий контраст не создает визуального шума. - Интуитивные цвета, основанные на объектах из природы — белый снег, черные скалы, голубая вода, зеленая растительность. Типографика - Строгая иерархия шрифтов и их насыщенности (см. дополнение в коментах). - Размер шрифта соответствует масштабу объекта — чем больше объект, тем больше шрифт. Почему это круто? Все это вместе создает эффект проявления информации Когда я впервые увидел эту анимацию плавно двигающейся карты — я словил ощущение эйфории и расфокуса — информация как будто сама заливалась мне в глаза и я её моментально понимал. С тех пор, я искал и пробовал делать штуки, которые бы повторили это ощущение. У Тани Мисютиной из лаборатории данных как раз недавно вышла заметка про этот эффект. Очень советую почитать. Ещё Таня рассказывала как книжки Тафти повлияли на неё и вдохновили начать заниматься визуализацией данных. #hoith#любопытство
Hashtags
@cogload · Post #126 · 06.12.2023 г., 17:24
Почему карта возможно не лучший каркас для визуализации данных Продолжаю рассказывать про персональный проект. Как вы могли догадаться речь пойдет про карту. Любые данные — это косвенное отражение того что происходит в реальном мире. Даже спутниковое фото может искажать реальное положение вещей. Что уж говорить о численной статистике, которая была собрана людьми в неидеальных условиях за большой период времени. Если в данных есть графа с местоположением, это не значит что карта — подходящий способ визуализации. Есть даже мем про то что все карты Европы выглядят одинаково Данные никогда не находятся в вакууме и закономерность в статистике может отражать не то, что пытались измерить. Почему же в моем случае карта подходит? Я пытаюсь визуализировать возраст домов. Минимальная частица тут — год, когда были возведены стены фасада (год постройки). В городе домов много, и общие закономерности можно оценить по столбчатой диаграмме — года выстроить по порядку, а высотой столбика показать количество домов построенных в этом году. Но чтобы действительно проявить суть информации — какие исторические слои сохранились до наших дней и как они соотносятся с моим текущим пониманием местности — эти данные нужно нанести на карту города. То есть нужно задать ключевой вопрос: помогает ли визуализация найти новые знания в общем массиве данных, или просто показывает то, что я мог увидеть и в таблице? На выходных я буду рассказывать про проект на Новисадском Митапе. Запись уже закрыта, но если вы в Сербии или поблизости — можете написать организаторам, иногда люди не успевают попасть и открываются свободные места. #hoith#maps
@cogload · Post #128 · 10.12.2023 г., 10:46
Карта возраста домов — ссылки Онлайн версия карты домов Томска. По нажатию открывается карточка дома с доступной информацией https://kontikimaps.ru/how-old/tomsk?p=h-tom Мой рассказ о процессе создания карты https://kontikimaps.ru/how-old/tomsk/process?p Карты других городов https://kontikimaps.ru/how-old/cities?p=h-menu Пост Никиты Славина на Хабре с которого все началось https://habr.com/ru/articles/504216/ Рассказ Александра Качкаева о карте Пензы и написании фреймворка для сбора данных https://kontikimaps.ru/how-old/penza/process?p=h-pnz Сайт издательства Кон Тики https://kontikimaps.ru #hoith#maps#сделал