Как стать автором
Обновить
33
-2
Александр Пряхин @el_kex

Tech Unit Lead

Отправить сообщение

В конфронтации удаленка vs офис победителем будет вариант "не навязывать сотруднику формат присутствия", если работа идет нормально.

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

Большинство на Joomla-сайтах не занимаются вопросами безопасности вообще

Это же не делает материал сам по себе сложным :) Вы рассказываете о базовых вещах.

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

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

А сложность материала тут точно определена правильно? Настройка плагина в CMS - это явно материал уровня Tutorial для тех, кто недавно узнал, что такое header.

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

Если бы вы добавили ссылку на мой профиль в соцсети, то получили бы ровно тот же результат

Что для начала не так уж и плохо, если нет опыта сочинения специфических cover letters. Получается некий скелет, который можно уже под себя допилить. К сожалению, большинство результатов требует доработки высокоточным напильником.

Но вот замечание про отличия 3 и 4 версий вполне валидное. Спасибо! Надо будет по подписке потестировать.

то есть в выборе "запрограммировать за 1 час в знакомой среде" или "выучить новую систему no code и запрограммировать за 10 минут" вы предпочитаете второй вариант?

Допустим, у Вас есть стартап, которому надо рассылать триггерные письма по своим пользователям. В стартапе есть 1-2 программиста с очередью задач. Благодаря no code можно выделить более дорогостоящий ресурс на более приоритетные задачи, а триггерную рассылку сделать через систему no-code.

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

Если мы говорим про более крупные проекты и команды, то выбор уже не столь очевиден, да. Но все сводится к математике расходов и доходов.

то есть писать проект пять недель, например, чтобы потом начать с нуля писать на конкретном языке?

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

Если no code предоставляет всё то же самое

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

Да, языки программирования гибки, но не стоит забывать стоимость этой самой разработки по отношению к доходам.

Разумеется. Но есть решения, где дальше «крестиков за ноликом» и не нужно. Понятно, что есть ряд систем, которые вырастают в потребность полноценного кода. Но так бывает не всегда.

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

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

Без проблем) Я заодно решил сам себя перепроверить в тексте, так как с утверждением о разнице полностью согласен.

Да, тег тут огульно поставлен, поправлю. В статье вроде бы знака равенства я не указывал :)

Простите, но исследование просто рисует те цифры, которые захотелось нарисовать.

Статья называется "зарплаты IT-управленцев", но география исследования достаточно узкая. В ней архитектор может и получает больше, чем CIO. Но давайте говорить по-честному - распределение доходов в РФ по гео не носит характер гауссовского.

Отсюда мы получаем, что название статьи не очень-то соответствует содержанию.

Также в статистике из 2500 респондентов совершенно непонятно, сколько было опрошено тимлидов, а сколько - директоров.

Нисколько не отрицаю, что архитекторы и лиды важны. Но вот достоверность результатов исследования вызывает вопросы.

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

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

Тут еще вопрос подачи информации же :)

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

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

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

Классная статья! Спасибо! Видно, что проделана большая работа.

Мы переехали на mysqlnd — изменился режим работы с буферизированными запросами. Сделали большой запрос — и это при получении может вызвать переполнение памяти. Выключите и получайте большие объёмы данных из соединения постепенно.

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

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

В целом, ответ на вопрос есть в комментарии @acordell

Если запросов не очень большое количество, то и выигрыш призрачен. Но вот если говорить о большом объёме инстансов, то уйма ресурсов будет уходить на инициализацию соединения. То есть, мы не запускаем, скажем 100 инстансов, в каждом из которых пилим N потоков через Singleton - ситуация тут, когда, скажем, через fastCGI в Python летит 100*N запросов на получение данных.

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

Спасибо за статью! Понимаю, что она сосредоточена именно на применении механизма очередей, но вот история с тем, что от монолита отпиливается по одному handler-y, имеет риск с другой стороны.

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

Поэтому упускать этот аспект, говоря о распиле монолитов, кажется рискованным.

Относительно утечек памяти в генераторах вот, что сумел накопать

https://github.com/php/php-src/issues/9750 - в случае, если цикл, обращающийся к генерируемым результатам останавливается через break, то случается утечка. Но это уже пофиксили. Судя по всему, это даже в 8.0 влили.

Более древние упоминания (типа 5.х) я тут не рассматривал, так как там и без утечек хватает проблем :)

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

Да, тут зависит от решаемой задачи. Контейнеры тут будут выполнять задачу изоляции процессов и стандартизации сред исполнения. Конечно, если надо прям вот упаковать и доставить без доступа к хосту, то volume не прокатит.

Спасибо! Но в таком случае не проще исходники вольюмом пробросить?

Хорошо! Но вот что тут стоит поправить с точки зрения контейнеров

  1. хранение кредов.

environment:
 PGADMIN_DEFAULT_EMAIL: admin.com
 PGADMIN_DEFAULT_PASSWORD: root

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

  1. Относительно Pgadmin: все таки админские интерфейсы для БД - ну такое. Ведь всегда можно подключиться нативным клиентом, который проще завернуть во внутреннюю сетку.

  2. Не уверен, что контейнер node собирается оптимально. Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код. Точно нельзя это упаковать в один шаг копирования?

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность

Специализация

Chief Technology Officer (CTO)
Lead
Project management
Building a team
People management
Development management
Agile
Scrum
Project planning
Organization of business processes
Optimization of business processes
Automation of processes