Бесконечное ИТ


Kanal geosi va tili: Qozog‘iston, Ruscha


Бесконечное ИТ - ИТ новости, интересные ссылки на статьи по разработке и менеджменту.
Вопросы, предложения, комментарии @tirex_kz

Связанные каналы  |  Похожие каналы

Kanal geosi va tili
Qozog‘iston, Ruscha
Statistika
Postlar filtri


Старый код не умирает вам нужно его убить. - Grady Booch

На канале The Pragmatic Engineer вышло интервью с живой легендой Software архитектуры Grady Booch!

И на мой взгляд оно получилось мега крутым! Очень интересные рассуждения про историю развития архитектуры и программирования в целом, его мысли на текущее положение вещей и LLM/AI в целом. Кратко законспектировал как менялось история разработки именно в контексте архитектуры.

60-70 - Маинфреймы, компьютеры в лабораториях. Осознание разработки и языков программирования в целом.
70-80 - Появляются мини компьютеры, первое появление распределенных систем. Бурный рост терминалов и терминальных систем. Так появляется потребность понимания как будут связываться такие системы и как они будут работать.
1980 - 1990 - Восхождение ООП, Рождение Rational Software где участвовал Буч и Которую потом купит IBM. Рост темпов разработки корпоративного ПО и как следствие потребности в best practices.
90 - 00 - Рождение и бурный рост интернета, HTML, TCP/IP. В 94-95 в Rational Software создали UML. До середины 00 MS/IBM и прочие гиганты несут знамя корпоративной разработки в массы. Системы становятся еще сложнее.
00 - 10 - 2001 год создание Agile манифеста. Появляется альтернатива корпоративной разработке. Развитие XP практик.
10 - present - Первое появление Solution Architect как роли в cloud компаниях. Строительные блоки становятся крупнее, и появляется потребность продавать клиентам решения созданные из этих блоков.

Ну и пара фраз от Гради Буча которые очень зацепили.

Про Легаси:

"У всех есть легаси, Facebook, Google, даже у OpenAI есть легаси. Как только вы написали строчку кода она становится легаси. Старый код не умирает вам нужно его убить. Если у вас нет саморазрушающегося кода вам прийдется работать с легаси."

Про OpenAI/LLM Гради Буч очень критичен):

"They allow us to build global scale bu...it generator"

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

https://www.youtube.com/watch?v=u7WaC429YcU


Недавно озаботился вопросом, а как используются данные которые я ввожу в OpenAI/ChatGPT. Быстрый поиск дал ответы:

Как обстоит дело для обычных пользователей:

https://openai.com/policies/privacy-policy/

As noted above, we may use Content you provide us to improve our Services, for example to train the models that power ChatGPT.


Отправить запрет/исключение на использование своих данных можно здесь
https://privacy.openai.com/policies -> Make a Privacy request.

Для энтерпрайз пользователей и пользователей API все проще.

https://openai.com/enterprise-privacy/
By default, we do not use your business data for training our models.

- ChatGPT Team or ChatGPT Enterprise
We do not train our models on inputs and outputs through our API.

- OpenAI API Platform

Правда про fine-tuning models все таки есть нюанс.

Q: "Who can view stored API inputs, outputs, and fine-tuning data?"
A: Our access to API business data stored on our systems is limited to (1) authorized employees that require access for engineering support, investigating potential platform abuse, and legal compliance and (2) specialized third-party contractors who are bound by confidentiality and security obligations, solely to review for abuse and misuse.


В приватных беседах про мощь и силу LLM/AI мои друзья из software безопасности жалуются, что в порыве всеобщей эйфории от открывшихся возможностей все прогрессивное человечество стало направо и налево внедрять все инструменты где упомянуто AI, при этом напрочь забыв про безопасность. По последним постам могло показаться что и я так агитирую делать. Но нет, безопасность хоть и не мое второе имя но я стараюсь учитывать ее как могу/умею. Поэтому сегодня будет пост про Security в AI/LLM. И база которую всем стоит почитать это конечно-же OWASP. Сообщество OWASP уже имеет отдельный раздел genai.owasp.org где есть много всего интересного. Но первое что рекомендую это OWASP Top 10 for LLMs and Generative AI Apps.
Аналогично классическому OWASP это список базовых 10 уязвимостей с описанием их опасности и примерами атак. Признаю я знал только половину, очень интересное и полезное чтиво. Вообщем почитайте пожалуйста, пошарьте тем кто занимается внедрением.


Использование связки Data aggregation + LLM + vector database для агрегирования разных внутренних источников информации и предоставления пользователям интерфейса к ним, потихоньку переходит из разряда диковинки в разряд обычных помогающих инструментов. Uber запустили внутреннего бота который помогает on-call инженерам быстрее выдавать ответы из внутренних вики и прочих систем документации, в ответ на запросы.

https://www.uber.com/en-IN/blog/genie-ubers-gen-ai-on-call-copilot/


В блоге Sequoia Capital (крупный венчурный фонд) интересная статья с прогнозами по развитию AI сферы. По сути уже года два как формируется новый пласт продуктов сделанных поверх AI. Т.е. кодовая часть для сопровождения этого AI все равно нужна, архитектура тоже) В статье есть также небольшой экскурс в историю. Вообщем краней полезно почитать чтобы понимать куда развивается область Software Services. Картинка говорит сама за себя.

https://www.sequoiacap.com/article/generative-ais-act-o1/


Какой интересный код оказывается есть.

451 Unavailable For Legal Reasons
HTTP-код ответа 451 Unavailable For Legal Reasons указывает, что пользователь запросил ресурс, который недоступен по юридическим причинам, например веб-страница, заблокированная из-за судебных исков.

https://developer.mozilla.org/ru/docs/Web/HTTP/Status/451


Google выпустил свой summarization сервис (https://notebooklm.google.com/), куда вы можете загрузить разные источники данные и спрашивать их о содержании/работать с ними. Да я знаю, что таких сервисов уже тьма но сервис от google я не мог пропустить, и результаты конечно очень крутые.

Я залил туда всю книгу (около 18 мб) Solution Architect Handbook (на английском). И вот что получилось. Во-первых сразу после импорта интерфейс уже сгенерировал несколько контекстных вопросов которые были созданы именно исходя из содержания и что еще удивительнее они были на русском. Я выбрал первый (1).

"Каковы три ключевые роли, которые играют архитекторы решений в организации? "

Получил ответ с очень качественным переводом. Что круто сервис оставляет ссылки на оригинальный источник (цифры в ответах) чтобы вы могли перепроверить ответы исходя из которых он сгенерировал ответ для вас и это очень помогает в быстрой проверке всех фактов написанных AI.

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

Буквально пару дней туда добавили поддержку YouTube, и это просто песня. Например вот я загрузив видео узнал о новом инструменте который обсуждался в видео.

Вообщем я под приятным впечатлением. Последний скриншот пример summarization по видео и ответами по нему.


Хочу сегодня поделится с вами обзором новомодного CursorAI. Это такая IDE/Code editor которая очень плотно интегрируется с многими LLM/AI сервисами. Самая главная фишка это то, что сервис будет понимать полный контекст вашего проекта. И тут лучше посмотреть видео чтобы понять насколько это интересно выглядит в работе.

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

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

https://www.youtube.com/watch?v=gqUQbjsYZLQ


Хорошая вводная статья про B-trees и индексы БД в контексте MySql,  статья интерактивная/анимированая.

https://planetscale.com/blog/btrees-and-database-indexes


Замечательная статья от Kent Beck, статья компиляция его нескольких лет опыта коучинга в Facebook. Очень круто видеть подтверждения своим мыслям и размышлениям у реально крутых авторов.

- Longevity/diversity. Elite engineers stick with projects long enough to see the consequences of their decisions. Insight is best mined deep in maintenance. At the same time, elite engineers have enough diversity of projects to separate context-dependent lessons from more general ones.

- Success/failure. Elite engineers need to succeed enough to maintain confidence and initiative but they also need to fail enough to question themselves and their assumptions when doing so is valuable.

- Mentored/self-directed. Most elite engineers can point to one or more mentors who changed the trajectory of their career. Elite engineers are also self-directed learners, trusting their curiosity as a compass pointing towards future growth.

- Urgency/slack. Elite engineers work hard, but lots of folks work hard. Elite engineers have the habit of investing the margin in personal growth. When that odd hour or two isn’t likely to yield a great new feature, it can still yield useful learning.

https://tidyfirst.substack.com/p/the-impossibility-of-making-an-elite


Back pressure (Backpressure) - это такая техника управления потоком данных, когда клиент отправляет слишком много данных и сервер может ответить, "не могу все обработать" и клиент уменьшит скорость передачи.
Например rate-limiting по сути является одной из стратегий реализации Back pressure.

Чаще всего выделяют 3 основных.
- Игнорирование данных (определенная часть данных просто игнорируется, в данном случае умышленно, а не потому что сервер просто не успевает их вычитывать). Сюда можно включить rate-limit. Само собой не тогда когда rate-limit например ограничивает ваш тарифный план например а когда это реальный ограничитель рассчитанный исходя из мощности системы.
- Буферизация данных (Накапливаем пиковые волны данных и обрабатываем позже). Немного более затратный метод, какие волны будут? Как часто? Какого размера может быть волна?
- Контроль генератора данных (Сервер контролирует скорость клиента, ускоряет или замедляет его) Клиент получает ответ от сервера что ему слишком быстро и замедляется. Эта реализация требует поддержки на уровне вашей инфраструктуры/фреймворков. Те реализации про которые знаю Kafka producers/consumers, Redis, MongoDB, RxJava, Sping Webflux, скорее всего и другие RX библиотеки других языков программирования тоже, потому что этот концепт популярен в реактивном программировании.

Хорошая обзорная статья

Пример на java


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

https://drew.silcock.dev/blog/how-postgres-stores-data-on-disk/


figure 4 (50%).gif
21.7Mb
Очень интересное исследование от команды Google. Они провели 12 недельный эксперимент по внедрению обученной ML модели для комментирования пулл реквестов. Каких-то цифр не привели, но результаты интеграции и % принятия сгенерированных моделью рекомендаций в районе 40% очень впечатляет. На масштабе гугла это поможет сэкономить много часов времени на комментирование других ревьюверов.

https://research.google/blog/resolving-code-review-comments-with-ml/


Очень подробная статья от Notion как они переходили от монолитной postgresql к шардированию БД.

Сервис проработал первый 5 лет на одном инстансе БД и только в 2020/2021 году они перешли на шардирование. Подробно описан процесс выбора схемы шардирования, непосредственно переход.

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

https://www.notion.so/blog/sharding-postgres-at-notion


Несколько раз видел статьи про использование UUID в качестве ключа в postgresql, наконец-то добрался почитать. Вообщем кратко, если вам по какой-то причине пришлось использовать UUID в качестве PK то рассмотрите использование UUID v7, он показывает хороший прирост производительности в отдельных случаях. Дефолтный Java randomUUID выдает v4. Поэтому нужно будет подключение внешней библиотеки.

https://maciejwalkowiak.com/blog/postgres-uuid-primary-key/


Люблю такие статьи в стиле lessons learned и сам люблю говорить на эту тему. Правда в последнее время прихожу к мысли что некоторые советы даже если их прочитать и понять логику, просто не получится применить или прочувствовать/понять. В молодости всегда хочется доказать, что ты умнее/сильнее и у тебя другой путь. Ну это как родительское "одевай шапку зимой" чувствуешь только после того как пару раз сляжешь с серьезным воспалением чего-нибудь.
Но! Это не значит, что про это не надо говорить, такие статьи помогают структурировать и уложить в голове хотя бы то, через что уже точно прошел сам, а значит может появится доверие и к другим советам.

Вынес пару советов которые понравились, остальные читайте в оригинальной статье.

Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it. Build the thing in the simplest way you can, as fast as you can. You can improve it over time as needs demand.

The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over. I’ve lost track of all of the software I’ve delivered that isn’t running anywhere anymore. Some of that is because my career is 35 years long. But even some of the software I worked on five or ten years ago isn’t running anymore. This is another good reason to build small increments, just good enough, get them out there, and iterate from there. Anything more and you’ve overbuilt some software that isn’t going to run forever anyway.

https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/


Бывают такие статьи который читаешь и прямо перед глазами пробегают ситуации из прошлых проектов. Сегодня статья о 8 ошибках при переписывании проектов/систем. Автор собрал замечательный список. Чаще всего здесь идет речь о переписывании системы в которых вы не принимали участия при проектировании/написании. Выбрал несколько которые особо понравились и откликнулись, остальные читайте в оригинале.

- Планировать миграцию только когда новая система будет "почти готова" - при позднем планировании миграции могут реализоваться риски по несовпадению форматов, стандартов, объема данных. Что-то чего вы не сможете учесть или увидеть при планировании. Что тогда? Возможно откат на пару шагов назад. Что делать? Помнить что есть например паттерны Strangler Fig, Parallel Run они помогут спланировать миграцию с меньшими рисками.

- Недооценивать усилия. Чаще свойственно middle или начинающим senior разработчикам, они уже могут брать на себя много ответственности но еще не попадали в капканы легаси 🥲. Это когда одна хитрая строчка может стоить пары дней нервных клеток. Что делать? Оценивайте функциональность и объем системы, планируйте по этапам. По поводу планирования связаны две следующие ошибки

- Не спрашивать о функциональности системы, пытаться копировать ее 1:1 и Пытаться заменить всю систему целиком. Спланируйте что вы меняете и почему, возможно у системы есть стабильное ядро и его можно не трогать, или возможно нарекания вызывает только системы которую вполне можно изолировать?

- Оверинжиниринг. Наша любимая программисткая ошибка. Иногда старая система так задалбывает своей отсталостью, что хочется вложить в новую версию все самое свежее и новое. Будьте очень осторожны. История разработки программного обеспечения уже знает такие истории. Легендарный Фредерик Брукс сформулировал Second-System Effect. На смену небольшим и компактным системам приходят неповортливые и раздутые монстры.

Что еще почитать на эту тему?
Patterns of Legacy Displacement (Effective modernization of legacy software systems)

Оригинальная статья "The 8 biggest mistakes when rewriting software systems (that I have seen so far)"


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

https://progression.fyi/


Захожу сегодня на StackOverflow а там говорят что опять подумывают над открытим jobs раздела.

Напомню, раздел закрылся 31 марта 2022 года, почти сразу после продажи/покупки компании.

https://t.me/neverendingit/436


Хороший пример того, как команда Uber меняла хранилище для внутренней системы аналитики.
Что понравилось в статье:
Хороший анализ того, почему решили менять систему хранения данных, как пришли к миграции на нее, какие вопросы решали в процессе. Но самое главное это было очень хорошая оптимизация, внутреняя команда получила более быстрый сервис, а компания сокращение расходов.
Немного информации о внутренней системе Uber для хранения крашей - Healtime. Судя по всему это такой самодельный Sentry, участвует в логировании и мобильных и бекенд крашей.
В конце были интересные и честные выводы что решение не удовлетворяло всем запросам, но для некоторых нашли варианты решения а другие пока оставили для дальнейшего анализа. Скорость, удобство и цена решения в итоге перевесили.

Первая картинка - внутреняя система Healthline
Вторая - выгода от переезда с Elasticsearch на Apache Pinot

https://www.uber.com/blog/real-time-analytics-for-mobile-app-crashes/

20 ta oxirgi post ko‘rsatilgan.