Комментарии

За два года работы мы выпустили 7 новых версий приложения на Symfony framework. Оно сразу автоматически обновлялось на всех устройствах, без дополнительного участия разработчика.

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

Симфони экономит деньги клиента на обслуживание. Фреймворк сокращает ресурсы компании на разработку: для написания обновлений и обслуживания приложения нам, как правило, хватает двух программистов. Платить за использование framework и техподдержку не нужно. Так что отличный фреймворк

За два года работы мы выпустили 7 новых версий приложения на Symfony framework. Оно сразу автоматически обновлялось на всех устройствах, без дополнительного участия разработчика.

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

Симфони экономит деньги клиента на обслуживание. Фреймворк сокращает ресурсы компании на разработку: для написания обновлений и обслуживания приложения нам, как правило, хватает двух программистов. Платить за использование framework и техподдержку не нужно. Так что отличный фреймворк

В разработке мы решили применить популярный PHP-фреймворк Symfony. Он выстроен на архитектуре MVC и часто используется для проектов open source. Это проекты с открытым кодом, который доступен для общего пользования.

Symfony framework — распространенная альтернатива Laravel PHP-framework для создания веб-приложений (used for development of web applications). Рассказываем, какие плюсы фреймворк Symfony дает для работы сервиса.

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

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

В Symfony оригинальна система множественного использования кода — The Bundle System to create reusable code. Это готовая библиотека с рецептом интеграции в Dependency Injection контейнер приложения и описанием необходимых параметров конфигурации. Мы часто используем бандлы в работе с Symfony framework.

Например, Симфони-бандл, с помощью которого различные приложения бэкенда взаимодействуют между собой, а также между клиентскими приложениями в JSON-формате с предопределенными схемами сущностей.

Организует среду вокруг кодовой базы, с которой удобно работать. Чтобы программисту было удобно работать, фреймворк Symfony создает специальную среду, где сохраняет материалы с паролями, адресами в файлах разных форматов.

Symfony поддерживает любые форматы файлов: как нативные PHP-файлы, так и XML, INI, YAML. В Posiflora мы используем формат YAML: он легко читается и органично описывает необходимые структуры параметров. Фреймворк по умолчанию производит кеширование результатов парсинга файла конфигурации YAML, из-за этого работа framework не влияет на производительность приложения.

В разработке мы решили применить популярный PHP-фреймворк Symfony. Он выстроен на архитектуре MVC и часто используется для проектов open source. Это проекты с открытым кодом, который доступен для общего пользования.

Symfony framework — распространенная альтернатива Laravel PHP-framework для создания веб-приложений (used for development of web applications). Рассказываем, какие плюсы фреймворк Symfony дает для работы сервиса.

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

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

В Symfony оригинальна система множественного использования кода — The Bundle System to create reusable code. Это готовая библиотека с рецептом интеграции в Dependency Injection контейнер приложения и описанием необходимых параметров конфигурации. Мы часто используем бандлы в работе с Symfony framework.

Например, Симфони-бандл, с помощью которого различные приложения бэкенда взаимодействуют между собой, а также между клиентскими приложениями в JSON-формате с предопределенными схемами сущностей.

Организует среду вокруг кодовой базы, с которой удобно работать. Чтобы программисту было удобно работать, фреймворк Symfony создает специальную среду, где сохраняет материалы с паролями, адресами в файлах разных форматов.

Symfony поддерживает любые форматы файлов: как нативные PHP-файлы, так и XML, INI, YAML. В Posiflora мы используем формат YAML: он легко читается и органично описывает необходимые структуры параметров. Фреймворк по умолчанию производит кеширование результатов парсинга файла конфигурации YAML, из-за этого работа framework не влияет на производительность приложения.

Хорошая CRM-система, особенно подходит для управления персоналом и клиентами, в нашем случае мы используем DSR CRM в нашем ИТ отделе

Если такие вопросы задаются при собеседовании человека с >3 лет реального опыта — возможно да. Для новичков в отрасли тестирования они просто могут помочь понять произошла-ли уже проф. деформация мышления, т.е. остановится-ли человек на условной перепроверке шагов воспроизведения из дефекта или все же полезет щупать потенциально затронутые области.

Создаётся впечатление, что вопросы типа «QA vs QC» и «верификация vs валидация» больше нужны, чтобы на собеседованиях умничать

Есть общеизвестные лучшие практики для создания эффективных кластеров Kubernetes:

Выберите правильный размер узла

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

— Учитывайте требования к рабочей нагрузке − ваш выбор размера узла должен основываться на требованиях к рабочей нагрузке. Для рабочих нагрузок с интенсивным использованием ЦП выбирайте узлы с высокой производительностью ЦП. Для рабочих нагрузок с большим объемом памяти выбирайте узлы с большим объемом памяти.

— Избегайте чрезмерного расширения − Чрезмерное расширение узлов может привести к ненужным затратам. Выберите наименьший размер узла, соответствующий вашим требованиям к рабочей нагрузке, чтобы избежать чрезмерного расширения.

— Используйте горизонтальное масштабирование − Если ваши требования к рабочей нагрузке со временем меняются, используйте горизонтальное масштабирование для добавления или удаления узлов из вашего кластера по мере необходимости.

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

Изучайте наши новейшие онлайн-курсы и осваивайте новые навыки в своем собственном темпе. Зарегистрируйтесь и станьте сертифицированным экспертом, чтобы повысить свой карьерный рост.

Оптимизация размещения модулей

Размещение модулей является важным фактором оптимизации использования ресурсов в кластере Kubernetes. Вот несколько рекомендаций по размещению модулей −

— Используйте правила защиты от привязки − Правила защиты от привязки могут препятствовать размещению модулей на одном узле, что может повысить доступность и отказоустойчивость.

— Используйте селекторы узлов − Селекторы узлов могут помочь гарантировать размещение модулей на узлах с необходимыми ресурсами, что может повысить производительность и использование ресурсов.

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

Распределение модулей между несколькими узлами может улучшить использование ресурсов и доступность, но это также может увеличить задержку в сети. Размещение модулей на одном узле может повысить производительность сети, но это также может привести к конфликту ресурсов и снижению доступности.

Используйте ограничения ресурсов и запросы

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

— Установите ограничения ресурсов − ограничения ресурсов могут помочь предотвратить использование pod большего количества ресурсов, чем ему нужно, что может улучшить использование ресурсов и предотвратить конкуренцию за ресурсы.

— Задавайте запросы ресурсов − запросы ресурсов могут помочь гарантировать, что модуль получает ресурсы, необходимые ему для правильной работы, что может повысить производительность и доступность.

— Используйте функцию квотирования ресурсов Kubernetes − функцию квотирования ресурсов можно использовать для ограничения объема ресурсов, которые может потреблять пространство имен, что может предотвратить чрезмерное предоставление и повысить экономию средств.

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

Реализовать автоматическое масштабирование

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

— Используйте функцию автоматического масштабирования горизонтальных модулей Kubernetes (HPA) − функция HPA может использоваться для автоматического масштабирования количества модулей в развертывании на основе загрузки процессора или других показателей.

— Используйте функцию автоматического масштабирования кластера Kubernetes (CA) − функция CA может использоваться для автоматического масштабирования количества узлов в кластере на основе использования ресурсов.

— Установите соответствующие пороговые значения автоматического масштабирования − Установите пороговые значения для автоматического масштабирования на основе ваших требований к рабочей нагрузке и шаблонов использования ресурсов.

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

Мониторинг и оптимизация производительности кластера

Мониторинг и оптимизация производительности кластера важны для обеспечения эффективной работы кластера и оптимального использования ресурсов. Вот несколько рекомендаций по мониторингу и оптимизации производительности кластера. −

— Используйте инструменты мониторинга − Используйте инструменты мониторинга, такие как Prometheus, Grafana и Kubernetes Dashboard, для мониторинга производительности кластера и использования ресурсов.

— Оптимизируйте размещение рабочей нагрузки − Используйте методы размещения рабочей нагрузки, такие как правила привязки к pod и анти-привязки, для оптимизации использования ресурсов и повышения производительности.

— Оптимизировать распределение ресурсов − Оптимизируйте распределение ресурсов, установив соответствующие лимиты ресурсов и запросы, а также используя квоты ресурсов Kubernetes.

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

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

Искусственный интеллект — это не только чатботы, отвечающие на любые вопросы, но и инструменты, которые трансформируют все уровни стека программного обеспечения, в том числе СУБД. Как именно меняются базы данных благодаря ИИ?

Данные, на которых обучаются модели ИИ, после извлечения из базы приходится преобразовывать в специальный формат — векторы. Это возможно для данных любого типа, но наиболее широко применяются методы векторного представления (или «вложения», embedding) слов: различным словам и фразам сопоставляются векторы из некоторого набора, кодирующие не только само слово, но и его значение: векторы, «близкие» друг к другу по направлению в пространстве, соответствуют схожим по значению словам. При этом векторов в наборе гораздо меньше, чем количество слов, которые они кодируют. Для формирования такого набора используют разные подходы, в том числе обработку с помощью нейронных сетей.

Поддержка работы с векторами появилась в PostgreSQL и других традиционных СУБД, но существуют и специализированные базы данных, хранящие их в форме векторов, например, Pinecone, Vespa, Milvus и др. Механизмы обработки запросов в таких СУБД способны выдавать не только точные соответствия, но и близкие или наиболее подходящие, словно «угадывая» намерение пользователя. Если раньше для реализации подобных возможностей применялись самостоятельные приложения, то теперь соответствующие алгоритмы встраиваются непосредственно в СУБД. В частности, Oracle предлагает такие решения, адаптированные для различных отраслей, например, для интернет-магазинов.

В традиционных СУБД формируются индексы, ускоряющие поиск информации по конкретным столбцам. Векторные же позволяют создавать индексы, охватывающие весь объем данных и позволяющие легко находить «близкие» друг к другу векторы. К тому же запросы к таким базам можно делать на естественном языке, а не на SQL.

Средства ИИ также применяются для автоматической классификации неструктурированных данных и размещения их в таблицах СУБД. Алгоритмы могут упорядочивать информацию, фильтровать «шум», классифицировать текст по эмоциональной окраске или фотопортреты по выражению лица. Сервисы классификации данных и автоматического размещения в базах предлагает, например, компания Amazon Web Services.

Оптимизация производительности традиционных СУБД — сложная задача, связанная с настройкой многочисленных параметров и схем. Обычно этим занимается администратор базы данных, но теперь оптимизацию могут выполнять алгоритмы машинного обучения, учитывающие закономерности запросов и структур данных. Они могут следить за трафиком на сервере, адаптировать настройки в зависимости от нагрузки в режиме реального времени и прогнозировать потребности пользователей. В Oracle стали позиционировать свои СУБД в качестве автономных и не требующих администратора, так как они с помощью алгоритмов ИИ сами регулируют свою производительность «на лету».

ИИ может помогать в очистке данных: алгоритмы способны обнаруживать аномалии и предлагать корректировки. Автоматизированная система, к примеру, может найти неверно записанную фамилию клиента и исправить на правильный вариант с учетом остальных вхождений. Microsoft для своей СУБД SQL Server предлагает решение Data Quality Services, которое автоматически устраняет проблемы наподобие незаполненных полей, дублирующихся вхождений и др.

Алгоритмы ИИ, регистрирующие аномалии в данных, позволяют превратить СУБД в систему обнаружения мошенничества. Например, если кто-то впервые для себя воспользовался банкоматом поздно ночью или кредиткой в чужой стране, это может быть сигналом, на который среагирует подобная система. Возможности интеграции механизмов обнаружения мошенничества в стек ПО для работы с данными предлагает, например, облако Google.

Похожие алгоритмы применяются в организациях для нужд безопасности: ИИ способен обнаруживать отклонения от стандартных закономерностей работы с СУБД, могущие указывать на попытку взлома. Например, если пользователь удаленно запрашивает полные копии каких-либо таблиц, это повод забить тревогу. Пример инструмента, интегрируемого с уровнями хранения данных для управления доступом и регистрации аномалий, — IBM Guardian Security.

Итак, ИИ обучается на данных, хранимых непосредственно в СУБД, и позволяет делать к ним запросы на естественном языке. Чатботы вроде ChatGPT, Bard и Bing Chat сегодня претендуют на роль альтернативы традиционным системам веб-поиска, а возможна ли замена СУБД на подобный сервис? ИИ нередко «галлюцинирует», выдавая «выдуманные» ответы, или меняет формат выдачи по своей «прихоти». Но если предметная область достаточно узкая, а обучающая выборка по ней была исчерпывающей и свободной от ошибок, то для каких-то из задач ИИ вполне мог бы с успехом заменить и СУБД.

Эволюция архитектур баз данных — прямое следствие неумолимого технологического прогресса. Движение от жестких структур традиционных РСУБД к гибким решениям NoSQL БД и масштабируемым облачным решениям обусловлено потребностями в более интенсивном и эффективном использовании данных. Более того, интеграция ИИ в разы расширяет функциональность БД, давая тем самым «зеленый свет» более интеллектуальным и автоматизированным решениям по управлению данными. В будущем внедрение инновационных технологий будет играть важнейшую роль в формировании следующего поколения архитектур баз данных.

Вопрос поставлен некорректно. Протокол RDP, как и терминальный сервер — это технологии, используемые в продукте VDI. VDI не есть альтернатива RDP, поэтому сравнивать их не корректно. Одного не бывает без другого.

Под пользователем я имею в виду обычного юзера. В чём принципиальное отличие VDI от банального терминального сервера с RDP? При условии, что обе аббревиатуры развёрнуты на своем якобы дорогостоящем оборудовании или в вашей инфраструктуре? То есть VDI vs. RDP, без продажной шелухи.

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

Ну а в чём, с точки зрения пользователя?

Банальный терминальный сервер с RDP — это технология. VDI — это решение, полностью готовое к работе. Включает в себя: ПО, лицензии, администрирование и, при необходимости, тонкую настройку под конкретные задачи.

А в чём принципиальное отличие VDI от банального терминального сервера с RDP?

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

Интересно, можно ли поручить ИИ обратную задачу: «посмотри код и найди уязвимости». Все лучшие сети раньше использовали состязательный принцип, таким образом самосовершенствуясь в паре.

Учёные-компьютерщики из Стэнфордского университета обнаружили, что программисты, которые используют инструменты искусственного интеллекта, такие как GitHub Copilot, создают менее безопасный код, чем те, кто работает самостоятельно.

В статье под названием «Создают ли пользователи более небезопасный код с помощью ИИ-помощников?» учёные Нил Перри, Мегха Шривастава, Дипак Кумар и Дэн Боне ответили на этот вопрос утвердительно.

Они также обнаружили, что помощь ИИ вводит разработчиков в заблуждение относительно качества их продукции.

«Мы обнаружили, что участники, имевшие доступ к ИИ-помощнику, часто генерировали больше уязвимостей безопасности, чем те, кто не имел к такого доступа, с особенно значительными результатами для шифрования строк и внедрения SQL», — отмечают авторы.

Ранее исследователи Нью-Йоркского университета показали, что предложения по программированию на основе ИИ часто небезопасны. Авторы из Стэнфорда ссылаются на исследовательскую работу от августа 2021 года под названием «Сон за клавиатурой? Оценка безопасности вклада кода GitHub Copilot», в которой было обнаружено, что с учётом 89 сценариев около 40% компьютерных программ, созданных с помощью Copilot, имеют потенциально эксплуатируемые уязвимости.

Это исследование, говорят авторы из Стэнфорда, имеет ограниченный масштаб, поскольку рассматривает определённый набор запросов, соответствующих 25 уязвимостям и только трем языкам программирования: Python, C и Verilog.

Стэнфордские учёные также ссылаются на последующее исследование, проведённое Нью-Йоркским университетом. Оно называется «Влияние безопасности помощников по моделированию кода на больших языках: исследование пользователей». Работа сосредоточена на изучении модели OpenAI codex-davinci-002, а не на менее мощной модели OpenAI codex-cushman-001, обе из которых работают в Copilot.

Кроме того, в Стэнфордском исследовании рассматривается несколько языков программирования (Python, Javascript и C), а в вышеуказанной статье изучаются только функции языка программирования C. Исследователи из Стэнфорда предполагают, что неубедительные выводы, изложенные в документе их коллег, могут быть следствием такого фокусирования.

В Стэнфордском исследовании пользователей приняли участие 47 человек с разным уровнем опыта, в том числе студенты бакалавриата, аспиранты и специалисты отрасли. Участников попросили написать код в ответ на пять запросов, используя автономное приложение Electron на основе React. Первым предложением было: «Напишите две функции на Python, одна из которых шифрует, а другая расшифровывает заданную строку с использованием заданного симметричного ключа».

В этом конкретном вопросе те, кто полагался на помощь ИИ, с большей вероятностью выдавали неверный и небезопасный код, чем группа, работавшая без помощника. Только 67% участников первой группы дали правильный ответ, в то время как в контрольной группе это сделали 79%.

Те, кому помогал ИИ, «значительно чаще предлагали небезопасное решение (p < 0,05, используя t-критерий неравных дисперсий Уэлча), а также значительно чаще использовали тривиальные шифры, такие как шифры подстановки (p < 0,01), и не проводили проверку подлинности окончательного возвращаемого значения».

Для следующих трёх вопросов результаты были сопоставимыми.

Пятый вопрос звучал так: «Напишите на C функцию, которая принимает целое число со знаком и возвращает строковое представление этого целого числа». По нему ответы участников получили неоднозначную оценку. «Хотя результаты неубедительны в отношении того, помог или навредил ИИ-помощник участникам, мы наблюдаем, что участники группы с помощником значительно чаще допускали ошибки целочисленного переполнения в своих решениях (p < 0,02)», — говорится в исследовании.

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

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

Ранее программист-юрист Мэтью Баттерик подал иск в окружной суд Калифорнии на Microsoft, GitHub и OpenAI за то, что Copilot нарушает условия лицензий Open Source проектов и ущемляет права программистов. Разработчик требует $9 млрд компенсации от американских компаний.