Последние инновации в сфере ИИ, наиболее примечательными из которых стали проекты наподобие GPT-4, очевидно, могут иметь далеко идущие последствия для общества: от утопического избавления от монотонного труда до антиутопического ущерба для работы художников в капиталистическом обществе, а также до экзистенциальных угроз самому человечеству.

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

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

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

Я не планировал продолжать эту тему, но сейчас вижу, что кое в чем, статью надо дополнить. Это дополнение не будет повторять или расширять статью очередными мыслями и наблюдениями; все это в ней уже есть и добавить мне нечего. Просто, читая комментарии, я понял, что об одной детали я упомянул, но толком не рассказал. Из‑за чего у части комментаторов возникли сомнения в сегодняшней ценности книг, доступных мне в то время, когда я начинал карьеру программиста. Мне кажется, это не очень справедливо и хотя я, бесспорно, не объективен, но, тем не менее, решил немного об этом рассказать.

Я расскажу о тех книгах, что были мне доступны в 1987–1993 гг., т. е. тогда, когда я совмещал работу инженера с программированием. Конечно, я упомяну только те книги, что мне действительно помогли; полный список литературы слишком обширен и упоминание их всех больше походило бы библиотечный каталог, чего я делать не намерен. Условно эти книги можно отнести к одной из нижеследующих категорий. Итак — вот мой «золотой фонд».

Всем привет! Меня зовут Александр, в данное время я на фрилансе занимаюсь проектом по созданию очередного маркетплейса. В процессе работы мы столкнулись с далеко не новой проблемой организации хранения информации о товарах, имеющих различные характеристики и цену, зависящую от характеристик. На нашем проекте применяется принцип CQRS: запись осуществляется в Postgres, чтение происходит из OpenSearch, а данные между ними перемещаются по шине, реализованной на Kafka. Такой подход обусловил использование реляционной БД для решения несвойственной ей задачи.

Чтобы увидеть, почему эта задача не нак проста, как кажется с первого взгляда, представим, что в нашем каталоге есть футболки мужские всего с двумя атрибутами: цвет и размер. Мы хотим хранить товар с названием "Футболка Junior Developer", она представлена в синем, красном и зеленом цветах, и каждый цвет доступен в нескольких размерах. Добавляя немного сложности, представим, что цена конкретной футболки также варьируется в зависимости от цвета и размера. Как представить эту сущность в реляционной базе данных, с учетом того, что продавец футболки может в какой-то момент добавить новые атрибуты для своего товара, например, габариты упаковки для отправки (длина, ширина, высота)?

С одной стороны, можно использовать подход: Entity-Attribute-Value. Он позволяет гибко настраивать связи между сущностями, их атрибутами и значениями, сохраняя возможность динамического добавления новых атрибутов сущности. Однако у такого подхода есть свои недостатки. На них останавливаться не буду - в статье: "Замена EAV на JSONB в PostgreSQL" они приведены, также там есть сравнение по производительности и памяти EAV и JSONB.

В жизни каждого инженера-фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.

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

Поэтому сегодня предлагаю вам составить мне компанию – и мы вместе рассмотрим распространённые паттерны работы с данными приложений, а также разберёмся, как они соотносятся с фичами баз данных. Далее мы рассмотрим решения, которые могли бы стать альтернативами этим паттернам – например, как сделать в клиентской части оптимизированный стек базы данных, который позволил бы нам сосредоточиться на разработке приложения, а не на мелкой возне с данными.

Все началось в далеком уже 2016 году, когда Президент России поручил в срок до 1 декабря разработать и утвердить план мероприятий по внедрению технологий информационного моделирования в сфере строительства (BIM)...

Если вы когда-нибудь читали агитации, призывающие к изучению Haskell, наверняка вас убеждали, что в нём ну очень удобно обрабатывать ошибки, ведь там есть Монада Either.

Но это неправда. В хаскельных школах не рассказывают, как удобно(?) обрабатывать ошибки. А я расскажу.

Этот пост — список забавных и хитрых примеров на JavaScript. Это отличный язык. У него простой синтаксис, большая экосистема и, что гораздо важнее, огромное сообщество.

В то же время мы все знаем, что JavaScript довольно забавный язык, в котором есть хитрые вещи. Некоторые из них быстро превращают нашу повседневную работу в ад, а некоторые заставляют хохотать. В этом посте рассмотрим некоторые из них.

Документ бизнес-требований (BRD) является отправной точкой для любого программного проекта или бизнес-решения. Благодаря такому документу члены команды приходят к единому мнению о том, что нужно создать, зачем это делать и как этого добиться.

В этой статье изучаются основные положения документов бизнес-требований. В том числе, зачем он нужен, как эффективно его составить и многое другое. Мы также включили 5 самых удачных примеров BRD от известных компаний.

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

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

Если одной метафорой, то произошли первые испытания термоядерной бомбы. Специалисты с благоговейным ужасом и радостью смотрят на поднимающийся над планетою гриб. Остальное человечество живёт обычной жизнью, пока не зная, современниками какого события они являются. Мне нравилось изучение цифровых технологий, сильнее интересовала только работа человеческой психики и междисциплинарное знание, которое можно объединить под условным названием «общая теория информации». Эти увлечения позволили увидеть в смене цифр смену эпох. Постараюсь объяснить суть случившегося максимально доступно.

Аналитик-экономист Саша устроилась на новую работу, у неё не было навыков программирования. В описании вакансии умение писать код не требовалось. Программирование преследовало экономиста в школе и университете. Саша старательно отмахивалась от написания кода, но избежать кодинга не вышло. 

В Сашин первый день предыдущий сотрудник оставил три скрипта на Python для подготовки отчетности, уволился и сменил номер телефона. Ближайших срок сдачи отчетности – через месяц. Запуска кода было недостаточно для подготовки отчетов, нужно адаптировать скрипт под запрос руководителя. 

Статья описывает ошибки, которые совершила Саша при изучение Python, и пути исправления этих ошибок. Статья расскажет об экстремальном опыте погружения в программирование на Python: анализ данных и визуализацию. Вот как это было…

Какой язык программирования выбрать? Открываем серию статей об этом! Наши разработчики будут рассказывать об особенностях, применении, плюсах и минусах языков, которые используются в «Криптоните». Начинаем с Rust: опытом поделится Андрей Чесноков, ведущий системный программист.

Добавление собственного Spring Boot Banner в приложение, от ручного к автоматическому.

Баннер – это первое что мы видим при запуске приложения, который по умолчанию говорит нам, что приложение работает на Spring Boot определенной версии.

Но при желании, мы можем добавить свой собственный баннер, с полезной для нас информацией.

Когда человек раньше говорил что он контролирует весь мир, то его обычно помещали в соседнюю палату с Бонапартом Наполеоном. Надеюсь, что эти времена остались в прошлом и каждый желающий может анализировать геоданные всей земли и получать ответы на свои глобальные вопросы за минуты и секунды. Я опубликовал Openstreetmap_h3 — свой проект, который позволяет производить геоаналитику над данными из OpenStreetMap в PostGIS или в движке запросов, способном работать с Apache Arrow/Parquet.

Первым делом передаю привет хейтерам и скептикам. То что я разработал — действительно уникально и решает проблему преобразования и анализа геоданных используя обычные и привычные инструменты доступные каждому аналитику и датасаенс специалисту без бигдат, GPGPU, FPGA. То что выглядит сейчас простым в использовании и в коде — это мой личный проект в который я инвестировал свои отпуска, выходные, бессонные ночи и уйму личного времени за последние 3 года. Может быть я поделюсь и предысторией проекта и граблями по которым ходил, но сначала я все же опишу конечный результат.

Первый пост не претендует на монографию, начну с краткого обзора...

Привет, Хабр! Меня зовут Денис Захаров. Я занимаюсь разработкой веб приложений на протяжении уже 14 лет, но история будет не об этом. Расскажу о том, как и почему я создавал эргономичное рабочее место, которое в последствии превратилось в проект Easyworkstation. Эта штука уже несколько лет полностью заменяет мне и еще нескольким десяткам пользователей привычное компьютерное кресло и рабочий стол.

Под катом поведаю, как профессия, проблемы со спиной и любовь мастерить руками довели меня до увольнения с работы, покупки сварочного аппарата и отнюдь не простого пути создания того, что вы видите на картинке.

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

Поветрия

Я наблюдаю за развитием IT в течение приблизительно четверти века, и с каждым днём меня всё сильнее удручает происходящее.

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

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

Увы, новые вещи (коих не так чтобы вообще есть) всё чаще приносят с собой и очевидно деструктивные, будто навязываемые извне, паттерны.

В прошлом частота таких деструкций была невысокой, но выглядит так, что она нарастает по экспоненциальной кривой.

В этой статье я хотел бы поговорить о причинах происходящего.

Создал мини курс по программе для векторной графики Inkscape в 2022.

Разработал методические материалы для изучения темы «Кодирование и обработка графической и мультимедийной информации» в школьном курсе информатики.

«Векторные графические редакторы позволяют пользователю создавать и редактировать векторные изображения непосредственно на экране компьютера, а также сохранять их в различных векторных форматах, например, CDR, AI, EPS, WMF или SVG». «Inkscape - редактор векторной графики, аналогичный по своим возможностям таким программам, как Adobe Illustrator, Corel Draw и другим».

Экономический термин delinking впервые (насколько я смог отследить) использовал Самир Амин в работе 1984-го года Delinking: Towards a Polycentric World для обозначения процесса выхода из системы глобального разделения труда. По многочисленными (для нашего немногочисленного Lisp сообщества) просьбам сообщников делюсь своим частным рассуждением о потенциале Lisp-систем в условиях delinking-а с более широкой аудиторией. Это мнение из категории «просто подумалось на досуге», оно не является абсолютно объективной истиной, но, вероятно, может представлять некоторый интерес.