То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле)
Вы точно ко мне обращаетесь?)
Я здесь говорю лишь о том, что вариант «все сломать, а потом построить свой новый прекрасный мир» ничуть не лучше чем загнивать в старом болоте.
А так то всякое в жизни бывает.
Я и на месте Сережи был, и на месте Коли, и на месте Жанны, и на месте генерала, и не одно внедрение видел, и пару крупных сам делал. Вот по разному бывает. И не помню ни одного случая когда бы «сломать а там построим лучше» приводило бы к хорошему результату. Обычно хорошо получается только первая часть плана.
Выделить полтора землекопа, которые будут заниматься нормализацией базы, и только ей. Оценку их работы проводить с аутсорса, чтобы не было соблазна использовать их в общих авралах отдела. Нет, использовать конечно, но слегка, и именно в авралах а не в работе за бухов.
Да, нормализация поверх текущей. Долнительные поля, которые пока не используются. Дополнительные отчеты, находящие дубли (которые в текущем раздрае некритичны) и т.п.
Потом те же полтора землекопа постепенно сдвигают родную структуру в сторону «храним нормализованно, но отображаем через врапер чтобы старый апи работал». Ловим проблемы реального бизнеса, несостыковки.
Параллельно пишем новую структуру, новый клиентский код.
Начинаем пилотное внедрение где часть функций в новой платформе, а старое в старой. Обязательно не забыть плюшки для рядовых сотрудников, чтобы они увидели что им удобнее работать по новому. Желательно «ненужных» не увольнять, а придумать как они принесут дополнительную прибыль, вместо убытков.
Еще на этапе нормализации на каждом шаге делаем кучу отчетов чтобы находить проблемные места и показывать ТОПам реальную прибыль/экономию. Аккуратно обойдя все те места которые если не обойдешь, то саботаж убьет весь проект. (Никогда не задумывались почему бизнес-аналитики обычно таскают большой физический диктофон? Его удобно демонстративно включать и выключать… «не для протокола»).
И тогда да. Можно говорить о техническом долге.
Меж тем 1С v7.7 до сих пор существует.
Я очень хорошо помню, как одно время работал манагером в одной корпорации.
Основное направление было расходники и прочая химия от одного западного бренда, чье название было у корпорации в названии (по лицензии), но и тендеры на оборудование и прочие особо выгодные вещи тоже были, и не на последних местах.
Помню как позвонил кто-то. Секретарь назвал вслух название организации, и весь оупенспейс" начал активно махать руками, мол только не на меня. Ну понятное дело я сказал чтобы переключили на меня (хотя это и совсем не моя задача была, но «человек же ждет...»). В общем это была какая-то больница. Им полгода назад поставили оборудование по тендеру. И они уже несколько месяцев не могли получить весь пакет документов. Их главбух (а это была она) очень переживала (мягко, очень мягко говорю), ведь у них пришла проверка из КРУ, а документов нет.
Я ее конечно заверил что сделаю все возможное, и все такое. Она извинилась за тон и т.п.
Нет, я сделал все возможное. В принципе какую бы маленькую должность я не занимал, у меня никогда не было психологических проблем пойти «на ковер» к генералу.
Но проблема была неразрешимой.
Начальник АСУ корпорации был племянником генеральши (имевшей значительный пакет акций) и он решил что старую версию 1с нужно заменить на новую. Ведь уже вышла 8.0 бета…
На момент моего увольнения (через месяц после событий) документов еще не было.
То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле)
Бугага! И еще трижды «Ха» в придачу!
Если предприятие достаточно времени существует, то в подавляющем большинстве случаев всё болото исходит именно от «самого главного который принимает решения».
Жанну и главбуха кто-то нанимал. Генерал, или совет директоров. Не суть. Самого генерала кто-то нанимал. Их кто-то продвигал. Других задвигал. Кто-то нанимал кадровиков. Кто-то выплачивал им премии и выписывал штрафы. Кто-то назначал коммерческого, кто-то утверждал его стратегические планы.
И во всем этом была та или иная мотивация.
Это могло быть «да пофиг». Могло быть «во всем этом я не сильно разбираюсь, деньги приносит, ну нафиг, вдруг поломаю». Бывает " ну блин, я же его генерального со школы знаю, Главбух моя любовница а Жанна лучшая подруга жены". Не важно. Важно то, что «всё это» приходит именно от «самого главного, главнее генерала». Всегда.
Ну а если там много акционеров, то все равно примерно та же картина, только с учетом балансов интересов разных сторон.
Не раз запускал composer update, ничего особо не рассыпалось.
Особенно когда есть хоть мало-мальски покрытие тестами, да хоть какое-то подобие CI настроено…
композер аптейт, идем запарить чай пока тесты пройдут, коммит в мастер, на тестовом/деве по вебхуку вытягиваются свежие коммиты, бегло пробежались что не только синтетические тесты живы, но и глазами (ну не делают большинство разработчиков полноценного покрытия интеграционными тестами, не делают), дальше или отдаем QA (если есть), или на прод сразу.
Потому что так безопасней. Потому что более умные люди рекомендуют так делать (даже тут на хабре есть статьи с рекомендациями, именно менять токен после постинга)
Пруф?
DMclient
Из того что удалось найти — проприетарный офлайн-клиент для одного конкретного сайта/движка(?) работающий по неизвестному протоколу и заброшенный девять лет назад. Я правильно понял? Хорошая попытка. Еще варианты будут?
Ну не 301 же.
Практическая проблема которая тут будет это попадание страницы в индекс. Собственно один из старых способов пессимизации сайта конкурента — загнать в индекс много копий страниц конкурента. В идеале — нечетких.
Приведите пример ПО которое не умеет работать с токенами (в простейшем случае, с доп.полем в форме), и при этом будет работать авторизация (такая как у вас).
Ну хоть один. Можно такой который не существует сейчас, но был актуален когда вы начинали писать сайт.
Один пример. Всего один.
Вы запутались
У всех работает. У меня работает. У вас не работает. Но запутался я. Л — логика.
так как токен меняется после каждого POST
А зачем? просто потому что вы не разбираетесь в безопастности, в стандартах и т.п. но использовать код написанный теми кто разбирается вы не хотите — велосипед важнее.
На любое значение в GET-параметре с кавычкой у вас возвращается ошибка 400.
Михаил, ну что вы как маленький. Какое 400?)
Там 200. Вернуть 400 мы не умеем, или «а зачем? люди писавшие стандарты дураки, лучше редиректить на 200».
404 и 403 чувак тоже не умеет, везде 200. Так что про SEO можно забыть. Ну и так далее.
А еще мы с вами не понимаем, что лучше всего верстать таблицами. Ну а мобильная верстка для слабаков.
В общем это дешевый закос под Милторга.
Только с Андреем не понять он действительно дурачек или талантливо тролит, а тут все понятно.
А ну да, в квалификацию упирается. Фреймворк позволяет снизить порог вхождения. Не удивительно что такой «наркотик» затягивает людей…
Именно в нее и упирается. И даже вашей квалификации хватило бы чтобы писать грамотно.
А чуть позже можно было бы и попробовать что-то свое сваять. Накосячить как у вас, но получить опыт. попросить коллег ревью. Услышать замечания. Переписать. Еще раз. И еще раз. Потом посмотреть на то как у других, и написать лучше.
Вы хуже зеленого новичка.
Полного нуба можно взять стажером и сделать из него программиста. Из вас уже нет. Школьник понимает что он ничего не знает и не умеет, и готов учиться. А вы только упрямствовать. Фу таким быть.
Действительно. В чем проблема написать код который закрывает уязвимость? Тем более у всех она закрыта лет пятнадцать назад, и можно подсмотреть как это делают остальные если не осилил сам.
Мне например не стыдно было подсмотреть как в Yii BREACH закрыли, ибо сам не сообразил.
А вот оставить уязвимость потому что не додумался как ее закрыть — было бы стыдно.
DRY, SOLID, MVC (или другая парадигма), паттерны, стандарты оформления кода, документация и покрытие тестами. Собственно это и дает «читабельность» и полноценный ревью. Плюс факт популярности фреймворка дает возможность найти отзывы о нем других людей. Что спасает от таких психопатов как антонн, или например есть такая CMS — Опенкарт. Утверждается что она ООП и MVC. И беглый взгляд может не дать понимание с чем столкнулись. А вот если погуглить, то можно найти такую технологию как VQMOD, и все становится сразу ясно.
но из-за защиты от которой отваливаются сторонние клиенты (ПО), ибо не умеют в токены (это предложение читать два раза)
Нет, и никогда не было ПО которое «не умеет в токены».
Зато есть разработчики которые не умеют в токены.
Для работы токенов достаточно работы сессии. Для сессий нужны или куки, или замусоревать урл.
Любой сайт написанный прямыми руками будет работать с защитой XSRF даже при выключенных куках и жаваскрипте. А если не будет (не верен что все текстовые/консольные браузеры нормально отработают, но вроде бы да, работали), то и авторизации пользователей у вас не будет.
Далее — проблема «открыл два окна» связана с тем что вы параноите, используя разные токены, хотя один токен на сессию вполне себе надежное решение. Но даже паранойя у вас выходит кривая. Да, необходимость в разных токенах никем доказана не была, но тем не менее, некоторые ее реализуют, и подобные реализации как правило не имеют проблему «открыл в другом окне, и в первом окне форма не работает».
У фреймворка основной набор уязвимостей закрыт из коробки. Если бы антонн писал свой сайт под фреймворком, то даже с его уровнем квалификации сайт был бы относительно защищенным.
Потому что свой код лучше изучен и понятнее его автору. Да, это может создать излишние издержки для бизнеса, но и добавит безопасности и маневренности.
Безопасности и маневренности… для автора. Просто в силу того, что код лучше знаком… автору. Что делает его относительно незаменимым. Ну и bus factor равный единице это круто да. Просто мечта любого бизнеса.
Вообще, использование фреймворка никак не предотвратит неуловимого Джо в суперкрутого разработчика.
Не превратит. Но если инструмент выбран правильно (старшие товарищи посоветовали), то гораздо меньше шансов что продукт будет дырявым как швейцарский сыр.
Да плевать на то чье несовершенство.
Есть задача — сайт должен быть написан быстро, и его характеристики (в том числе и безопасность) должны не слишком уступать большинству современных сайтов.
Фреймворк — быстро, минимум глюков.
Велосипед — медленно, много глюков.
А чье несовершенство — уже не важно. Вообще не важно.
Вы точно ко мне обращаетесь?)
Я здесь говорю лишь о том, что вариант «все сломать, а потом построить свой новый прекрасный мир» ничуть не лучше чем загнивать в старом болоте.
А так то всякое в жизни бывает.
Я и на месте Сережи был, и на месте Коли, и на месте Жанны, и на месте генерала, и не одно внедрение видел, и пару крупных сам делал. Вот по разному бывает. И не помню ни одного случая когда бы «сломать а там построим лучше» приводило бы к хорошему результату. Обычно хорошо получается только первая часть плана.
Да, нормализация поверх текущей. Долнительные поля, которые пока не используются. Дополнительные отчеты, находящие дубли (которые в текущем раздрае некритичны) и т.п.
Потом те же полтора землекопа постепенно сдвигают родную структуру в сторону «храним нормализованно, но отображаем через врапер чтобы старый апи работал». Ловим проблемы реального бизнеса, несостыковки.
Параллельно пишем новую структуру, новый клиентский код.
Начинаем пилотное внедрение где часть функций в новой платформе, а старое в старой. Обязательно не забыть плюшки для рядовых сотрудников, чтобы они увидели что им удобнее работать по новому. Желательно «ненужных» не увольнять, а придумать как они принесут дополнительную прибыль, вместо убытков.
Еще на этапе нормализации на каждом шаге делаем кучу отчетов чтобы находить проблемные места и показывать ТОПам реальную прибыль/экономию. Аккуратно обойдя все те места которые если не обойдешь, то саботаж убьет весь проект. (Никогда не задумывались почему бизнес-аналитики обычно таскают большой физический диктофон? Его удобно демонстративно включать и выключать… «не для протокола»).
И тогда да. Можно говорить о техническом долге.
Я очень хорошо помню, как одно время работал манагером в одной корпорации.
Основное направление было расходники и прочая химия от одного западного бренда, чье название было у корпорации в названии (по лицензии), но и тендеры на оборудование и прочие особо выгодные вещи тоже были, и не на последних местах.
Помню как позвонил кто-то. Секретарь назвал вслух название организации, и весь оупенспейс" начал активно махать руками, мол только не на меня. Ну понятное дело я сказал чтобы переключили на меня (хотя это и совсем не моя задача была, но «человек же ждет...»). В общем это была какая-то больница. Им полгода назад поставили оборудование по тендеру. И они уже несколько месяцев не могли получить весь пакет документов. Их главбух (а это была она) очень переживала (мягко, очень мягко говорю), ведь у них пришла проверка из КРУ, а документов нет.
Я ее конечно заверил что сделаю все возможное, и все такое. Она извинилась за тон и т.п.
Нет, я сделал все возможное. В принципе какую бы маленькую должность я не занимал, у меня никогда не было психологических проблем пойти «на ковер» к генералу.
Но проблема была неразрешимой.
Начальник АСУ корпорации был племянником генеральши (имевшей значительный пакет акций) и он решил что старую версию 1с нужно заменить на новую. Ведь уже вышла 8.0 бета…
На момент моего увольнения (через месяц после событий) документов еще не было.
Бугага! И еще трижды «Ха» в придачу!
Если предприятие достаточно времени существует, то в подавляющем большинстве случаев всё болото исходит именно от «самого главного который принимает решения».
Жанну и главбуха кто-то нанимал. Генерал, или совет директоров. Не суть. Самого генерала кто-то нанимал. Их кто-то продвигал. Других задвигал. Кто-то нанимал кадровиков. Кто-то выплачивал им премии и выписывал штрафы. Кто-то назначал коммерческого, кто-то утверждал его стратегические планы.
И во всем этом была та или иная мотивация.
Это могло быть «да пофиг». Могло быть «во всем этом я не сильно разбираюсь, деньги приносит, ну нафиг, вдруг поломаю». Бывает " ну блин, я же его генерального со школы знаю, Главбух моя любовница а Жанна лучшая подруга жены". Не важно. Важно то, что «всё это» приходит именно от «самого главного, главнее генерала». Всегда.
Ну а если там много акционеров, то все равно примерно та же картина, только с учетом балансов интересов разных сторон.
Началось все так:
— Сереееж… Ну сколько мы еще будем скитаться по съемным квартирам? Давай возьмем ипотеку!
Особенно когда есть хоть мало-мальски покрытие тестами, да хоть какое-то подобие CI настроено…
композер аптейт, идем запарить чай пока тесты пройдут, коммит в мастер, на тестовом/деве по вебхуку вытягиваются свежие коммиты, бегло пробежались что не только синтетические тесты живы, но и глазами (ну не делают большинство разработчиков полноценного покрытия интеграционными тестами, не делают), дальше или отдаем QA (если есть), или на прод сразу.
Собственно в этом и соль, что «мало».
И с каждым проектом становится «больше».
Пруф?
Из того что удалось найти — проприетарный офлайн-клиент для одного конкретного сайта/движка(?) работающий по неизвестному протоколу и заброшенный девять лет назад. Я правильно понял? Хорошая попытка. Еще варианты будут?
Практическая проблема которая тут будет это попадание страницы в индекс. Собственно один из старых способов пессимизации сайта конкурента — загнать в индекс много копий страниц конкурента. В идеале — нечетких.
Приведите пример ПО которое не умеет работать с токенами (в простейшем случае, с доп.полем в форме), и при этом будет работать авторизация (такая как у вас).
Ну хоть один. Можно такой который не существует сейчас, но был актуален когда вы начинали писать сайт.
Один пример. Всего один.
У всех работает. У меня работает. У вас не работает. Но запутался я. Л — логика.
А зачем? просто потому что вы не разбираетесь в безопастности, в стандартах и т.п. но использовать код написанный теми кто разбирается вы не хотите — велосипед важнее.
Ну ок, ок. Ну вот например SamDark — взял фреймворк «с полочки» и счастлив :). И таких тут много.
Михаил, ну что вы как маленький. Какое 400?)
Там 200. Вернуть 400 мы не умеем, или «а зачем? люди писавшие стандарты дураки, лучше редиректить на 200».
404 и 403 чувак тоже не умеет, везде 200. Так что про SEO можно забыть. Ну и так далее.
А еще мы с вами не понимаем, что лучше всего верстать таблицами. Ну а мобильная верстка для слабаков.
В общем это дешевый закос под Милторга.
Только с Андреем не понять он действительно дурачек или талантливо тролит, а тут все понятно.
Именно в нее и упирается. И даже вашей квалификации хватило бы чтобы писать грамотно.
А чуть позже можно было бы и попробовать что-то свое сваять. Накосячить как у вас, но получить опыт. попросить коллег ревью. Услышать замечания. Переписать. Еще раз. И еще раз. Потом посмотреть на то как у других, и написать лучше.
Вы хуже зеленого новичка.
Полного нуба можно взять стажером и сделать из него программиста. Из вас уже нет. Школьник понимает что он ничего не знает и не умеет, и готов учиться. А вы только упрямствовать. Фу таким быть.
Действительно. В чем проблема написать код который закрывает уязвимость? Тем более у всех она закрыта лет пятнадцать назад, и можно подсмотреть как это делают остальные если не осилил сам.
Мне например не стыдно было подсмотреть как в Yii BREACH закрыли, ибо сам не сообразил.
А вот оставить уязвимость потому что не додумался как ее закрыть — было бы стыдно.
Нет, и никогда не было ПО которое «не умеет в токены».
Зато есть разработчики которые не умеют в токены.
Для работы токенов достаточно работы сессии. Для сессий нужны или куки, или замусоревать урл.
Любой сайт написанный прямыми руками будет работать с защитой XSRF даже при выключенных куках и жаваскрипте. А если не будет (не верен что все текстовые/консольные браузеры нормально отработают, но вроде бы да, работали), то и авторизации пользователей у вас не будет.
Далее — проблема «открыл два окна» связана с тем что вы параноите, используя разные токены, хотя один токен на сессию вполне себе надежное решение. Но даже паранойя у вас выходит кривая. Да, необходимость в разных токенах никем доказана не была, но тем не менее, некоторые ее реализуют, и подобные реализации как правило не имеют проблему «открыл в другом окне, и в первом окне форма не работает».
Безопасности и маневренности… для автора. Просто в силу того, что код лучше знаком… автору. Что делает его относительно незаменимым. Ну и bus factor равный единице это круто да. Просто мечта любого бизнеса.
Не превратит. Но если инструмент выбран правильно (старшие товарищи посоветовали), то гораздо меньше шансов что продукт будет дырявым как швейцарский сыр.
Есть задача — сайт должен быть написан быстро, и его характеристики (в том числе и безопасность) должны не слишком уступать большинству современных сайтов.
Фреймворк — быстро, минимум глюков.
Велосипед — медленно, много глюков.
А чье несовершенство — уже не важно. Вообще не важно.