#сложность_разработки — Public Fediverse posts

Почему применение SaaS/IDaaS для аутентификации и авторизации наиболее эффективно, сравнение

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

https://habr.com/ru/articles/1013524/

#авторизация #аутентификация #keycloak #архитектура_приложений #архитектура_по #сравнение #сложность_разработки #idaas

Задача “Container With Most Water” 150 000$ от Amazon — мое не стандартное решение

💧 Условие задачи: «Аквариум» (Container With Most Water) Представим, что нам дан массив целых чисел — например: [1, 8, 6, 2, 5, 4, 8, 3, 7] Каждое число в этом массиве символизирует высоту вертикальной стенки — как будто это столбец, воткнутый вертикально в пол. Все столбцы стоят на одной горизонтальной линии, то есть на «полу» (ось x), и находятся на равном расстоянии друг от друга. 📦 Теперь представим, что между этими столбиками можно налить воду — как будто мы смотрим на 2D-аквариум сбоку. 🧠 Цель задачи Найти две такие стенки (столбцы), которые, если между ними налить воду (по нижней границе — полу), смогут удержать наибольшее количество воды. 💧 Объём воды между двумя столбцами рассчитывается так: • Высота воды ограничена меньшей из двух стенок — потому что вода не может быть выше, чем самая низкая из них (иначе вытечет). • Ширина — это расстояние между этими двумя столбцами (в индексах). объём = (индекс_правой − индекс_левой) × min(высота_левой, высота_правой) Массив: [1, 8, 6, 2, 5, 4, 8, 3, 7] Индексы: 0 1 2 3 4 5 6 7 8 Столбцы (высоты): вертикальные стенки Пол: горизонтальная база (ось x) Вода: заливается между двумя стенками и держится на уровне самой низкой из них. Забегая вперед скажу 2. Классическое решение и его недостатки Обычно задача решается методом двух указателей с линейной сложностью. Однако этот подход не всегда даёт глубокую интуицию выбора стенок. ⸻ 3. Предложенный подход Я ввожу понятие энергоэффективной оценки каждой стенки: При этом: • Если стенка ближе к центру, её расстояние меньше — значит штраф за “удалённость” ниже. • Высокая, но далёкая стенка будет “наказана” в оценке. • Выбираются две стенки с максимальными result, а затем между ними вычисляется реальный объём воды. ⸻ 4. Обоснование устойчивости (пример) При наличии сильно асимметричного массива (например, левые элементы — [1, 2, 1], правые — [9, 8, 9]), алгоритм всё равно выбирает правые высокие значения, потому что они превосходят штраф и сохраняют высокий итоговый результат. ✔ Это делает алгоритм устойчивым к локальным аномалиям и не требует явно жёстких условий или вложенных циклов. ⸻ 5. Заключение Предложенный алгоритм демонстрирует новый взгляд на задачу через призму “выгодности” стенки, объединяя геометрическую и энергетическую оценку. Он сохраняет линейную сложность, но обладает дополнительной устойчивостью и хорошей визуальной интерпретацией. Разница:

https://habr.com/ru/articles/941446/

#алгоритмы #алгоритм #алгоритмы_поиска #алгоритмы_сортировки #алгоритмическая_торговля #алгоритмы_поиска_пути #лучшее #лучшие_практики #сложность_алгоритма #сложность_разработки

[Перевод] Безумие быть разработчиком

Я часто об этом думаю, потому что это не похоже на большинство других профессий. Быть разработчиком — тяжело. С самого начала тебе уже нужно знать пару языков программирования и ещё несколько разных инструментов. Но этого недостаточно. Компании ожидают от тебя, что ты разбираешься именно в том фреймворке, который они используют у себя. Это может быть Rails, Django, Laravel или что-то ещё. Тебе также понадобится CSS. Его можно учить всю жизнь и всё равно не понять, почему ломается вёрстка, но минимально необходимый уровень освоить реально. Вряд ли получится обойтись без JavaScript. Может тебе повезёт, и нужно будет лишь иногда править jQuery в устаревшем приложении, которое нужно поддерживать. Но времена меняются.

https://habr.com/ru/articles/898356/

#разработка_приложений #сложность_разработки #карьера_программиста #специализация #разработка

[Перевод] Как избежать когнитивной перегрузки: способы оптимизации кода для разработчиков

По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку? Подробнее о том, с какими проблемами от высокой когнитивной нагрузки сталкиваются разработчики и какие решения помогут упростить понимание кода для последующей работы с ним читайте под катом. *Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

https://habr.com/ru/companies/ncloudtech/articles/818643/

#Когнитивная_нагрузка #програмирование #сложность_разработки #cognitive_complexity