Сделал в компании доклад о применении ИИ в архитектуре, давайте и вам расскажу.
Фокус в использовании подхода architecture as code: абсолютно все архитектурные артефакты у нас это тексты. С обычной документацией понятно, это и так некоторый набор текстовых файлов, чаще всего в макрдауне. Для них мы применяем структурный шаблон Arc42 — список из 12 пунктов, по которым нужно распределить информацию о проектируемой системе.
Структурный шаблон, во-первых, хорошо известен нейронкам, и они сразу понимают, о чём речь. Во-вторых, можно кинуться в модель бизнес-требованиям и очень быстро создать некий первоначальный набросок, от которого вы дальше уже пляшете, уточняя по пунктам и исправляя ошибки ИИ. Ну и, в-третьих, готовая структура с ящиками, по которым нужно всё раскладывать, это гораздо лучше, чем свалка ADR'ок, как это нередко бывает в компаниях.
Со схемами и диаграммами ещё интереснее. Берём инструменты со своими DSL-языками, такие, как Structurizr и PlantUML. Вся схема или диаграмма целиком определяется текстовым файлом. Можно применять Git со всеми его преимуществами. А для нейронок это родная среда: вы, как человек, смотрите на схему глазами, но нейронка работает с её DSL-файлом. Навскидку тут прирост эффективности даже больше, чем в программировании, потому что DSL это просто синтаксис, без смыслового наполнения, человеку его можно вообще не знать. Ты пишешь промпты, а смотришь уже на картинку, сгенерированную схему, и следующим промптом указываешь, где какие правки сделать. Нейронке при этом не приходится думать про потоки, асинхронность, типы данных, она просто правит текст как текст, поскольку у DSL нет поведения.
Тут как раз наиболее видна разница между рутинной и интеллектуальной частью работы. Как именно будет выглядеть схема, продумывает архитектор. Если доверить это нейронке, даже мощной, будет полно ошибок, неоптимальностей, неучтённых нюансов среды и так далее. Но вот само по себе написание синтаксиса — имба.
#dev@clockstackwheels
• Нашел интересный ресурс, который содержит информацию об основных веб-уязвимостях. Особенность данной платформы в том, что каждый из перечисленных методов можно выполнить самостоятельно, следуя подсказкам и примерам. А еще каждый пример является интерактивным, поэтому вам будет легче воспринимать материал и практиковаться. Содержание следующее:
➡SQL Injection;
➡Cross-Site Scripting;
➡Command Execution;
➡Clickjacking;
➡Cross-Site Request Forgery;
➡Directory Traversal;
➡Reflected XSS;
➡DOM-based XSS;
➡File Upload Vulnerabilities;
➡Broken Access Control;
➡Open Redirects;
➡Unencrypted Communication;
➡User Enumeration;
➡Information Leakage;
➡Password Mismanagement;
➡Privilege Escalation;
➡Session Fixation;
➡Weak Session IDs;
➡XML Bombs;
➡XML External Entities;
➡Denial of Service Attacks;
➡Email Spoofing;
➡Malvertising;
➡Lax Security Settings;
➡Toxic Dependencies;
➡Logging and Monitoring;
➡Buffer Overflows;
➡Server-Side Request Forgery;
➡Host Header Poisoning;
➡Insecure Design;
➡Mass Assignment;
➡Prototype Pollution;
➡Regex Injection;
➡Remote Code Execution;
➡Cross-Site Script Inclusion;
➡Downgrade Attacks;
➡DNS Poisoning;
➡SSL Stripping;
➡Subdomain Squatting.
➡️https://www.hacksplaining.com/lessons
#web
🔴 Уязвимости аутентификации | Безопасность web приложений.
• В этом ролике подробно описаны механизмы аутентификации, чем опасны их уязвимости и как можно их защитить. Также автор рассказывает, как работают механизмы аутентификации и разбирает на примерах прохождение лаб на платформе — https://portswigger.net/web-security
• 0:00 — уязвимости аутентификации;
• 0:22 — аутентификация это / типы аутентификации;
• 1:30 — как возникают уязвимости / последствия уязвимостей;
• 2:16 — как используются уязвимости на практике / Лаба 1;
• 6:18 — как используются уязвимости на практике / Лаба 2;
• 8:45 — как защитить механизмы аутентификации;
• 10:32 — где проходить лаборатории.
➡️https://youtu.be/lWYJ1vD9OEM
#web