Ну а почему же "на попе ровно" и без развития?
Как раз индивидуальный и плановый подход к развитию каждого отдельного сотрудника вполне вроде проявлен…
Если спектр задач в компании достаточно широк, то и возможностей для развития может хватить…
Другое дело, что не очень понятно, можно ли удержать в такой конструкции навсегда сотрудника, у которого есть свой заметный потенциал для руководства...
Немного странновато подан тезис "Безусловное подчинение", как мне кажется...
Разумеется, принципа "мы тут посоветовались, и я решил" никто не отменял :)
Но когда народ уже "безусловно подчиняется" и "не сопротивляется" — это уже немного отдаёт самодурством и забитостью народа имхо...
И узнать, что народ думает в отношении того, что и как сделать, никогда не интересно?
По мне — так удивительная история… Не тем удивительная, что человек нашёлся, который уместный вопрос задал, и не тем удивительная, что разумное решение нашлось (всё отметить) :)
А удивительная тем, что похоже, что в процессе разработки отсутствует роль product owner'а, а как это по-русски — я не знаю :)
То есть нет человека, который выступал бы основным заказчиком на разработку (пусть даже внутренним) и понимал бы, что действительно нужно и для чего, и нёс бы персональную ответственность за то, что пилится разработчиками...
Если нет такого человека — так ведь печаль это, и в первую очередь печаль высшего руководства, хотя бывает и так, что им и невдомёк… Тогда-то и надо, чтобы кто- нибудь им намекнул… :)
Так а "продумывать за" вроде и не требуется… Всё что требуется — это убедиться, что мысль у стажёра движется в правильном направлении, и что его подготовки достаточно, чтобы двигаться туда самостоятельно… А если подготовки не хватает, то подсказать, в какую сторону и каким путём рулить...
Можно конечно и совсем всё на самотёк пустить и подождать, пока стажёр сам по всем граблям лично пройдёт, но не факт, что это пойдёт на пользу проекту и заказчику/работодателю… :)
А в чём изюмина того, чтобы прорыть канаву целиком самому и непременно лопатой, если рядом стоит экскаватор? :)
Неужели мастерство и ценность разработчика состоит только в том, чтобы решить задачу непременно в одиночку, никого не спрашивая?
А способность пользоваться разными "шаблонами проектирования", а не только одним (упереться рогом и прорыть всё непременно в одиночку) никак не украшают разработчика? Ну например способность спросить на форуме? Способность задать толковый вопрос на StackOverflow? Способность устроить мозговой штурм с коллегами?
Да и просто способность задать вопрос старшему/равному/младшему, не стесняясь, потому что "знать всё" всё равно невозможно, и поэтому спрашивать не стыдно? :)
Ну и тем более тогда похоже, что нога отлынивает :)
Нога могла бы немного активнее работать и задачу стажёрам почётче ставить… Тогда руке проще было бы…
Кстати, иногда эта часть работы "ноги бога" называется архитектурной проработкой… :)
Если у тебя опыта больше, а у соседа меньше — в чём проблема поделиться? И медали за это даже особой не надо вроде, процесс сам по себе по идее достаточно приятен… :) Ну и вообще менторство можно и в должностную инструкцию старшим коллегам писать по-простому… Только на пользу всем будет — если действительно разумно временем распоряжаться...
Ну и по поводу "вариться в своем соку" тоже не очень понятно. Это всё только если регулярной коммуникации между членами команды совсем нет...
А если код-ревью ввести на регулярной основе? Понятно, что в ближней перспективе трудозатраты возрастут. Зато в дальней — улучшится качество кода, ускорится делёжка опытом и повысится уровень команды в целом. Разве не достойная цель?
PS Первый экземпляр этого комментария куда-то пропал необъяснимым образом, хотя в извещении на почту приехал в полном объёме… Так что это — дубль два :)
Ну, через 50 лет многое по-другому может уже оказаться, и вполне может быть, что и все архивы ведутся в облаках с унифицированным интерфейсом к ним на естественном языке… или через прямое подключение к мозгу… :) И что все необходимые антикварные спецификации форматов тоже где-то сохранены и систематизированы на случай, если вдруг понадобятся...
Только вот вопрос: как обеспечить сохранность информации на первые 10-20 лет из этих 50? :)
А если чуть серьёзнее, то я не поленился посмотреть исходники и увидел там слово "phone4pay". Ну а дальше, перейдя по ссылке, увидел много всего, включая оферту.
А там ведь уже на вид всё по-взрослому… И это уже вполне едет под ФЗ и под определение как минимум "оператора услуг платежной инфраструктуры"… Со всеми вытекающими...
Я бы разделил вопрос на две части:
1) phone4pay и его бизнес. Мне кажется, что не очень безопасно тешить себя идеей, что ФЗ вас не касается. Потому что вполне могут найтись казённые люди, которые аргументированно скажут, что касается. А закон написан так, что трактовать его формулировки можно в широких пределах.
2) Доброе дело по отношению к окружающему миру — с потенциальными ИП, которые могли бы хотеть принимать у себя на сайте платежи с карты на карту, с кодом на Гитхабе и со всем таким. Здесь есть большой риск сделать таким людям вместо доброго дела подлянку, потому что даже если это и не эквайринг в обычном понимании, всё равно это как минимум серая зона с не до конца ясными правилами и с явным несоответствием PCI DSS. А люди-то, которые воспользуются, вряд ли смогут в это всё вникнуть и поверят вам, что всё норм и безопасно...
В принципе этот механизм, наверно, можно сделать более безопасным и более соответствующим правовому полю, если не принимать номер карточки плательщика в свои руки и отложить его ввод до страницы банка. И на страницу банка передавать только номер карточки получателя. Это же можно наверняка сделать? Всё остальное сложится при этом?
Меня здесь пока больше всего беспокоит словосочение "эмулируя страницу банка" вот в этой фразе:
Шлюз работает между браузером пользователя и страницей банка, реализует функции ввода/вывода эмулируя страницу банка, дополняет и изменяет данные, и обрабатывает ответы и ошибки от сервисов банка.
Там точно не происходит введение посетителя в заблуждение относительно того, кому принадлежит страница для ввода реквизитов карты?
И ещё беспокоит то, что всё участники электронных платежей относятся к PCI DSS очень серьёзно. А здесь ввод реквизитов карточек производится в систему, которая на соответствие PCI DSS не сертифицирована и вряд ли даже надлежащим образом спроектирована.
Я — не специалист по правоприменительной практике. И толкователь ФЗ не очень хороший. Поэтому с какими корочками могут прийти казённые мужи к оператору такого платёжного шлюза, и на какие статьи ФЗ и подзаконных актов они будут при этом ссылаться — прогнозировать не буду. Но пропагандировать такой инструментарий как законный и безопасный точно не стал бы...
Если же этот же механизм модифицировать так, чтобы номер карточки плательщика вводился строго на странице банка, а не на странице получателя платежа, то думаю, что претензий уже не будет ни у кого...
Если же очень хочется занять какое-то место в цепочке прохождения платежей, то самое разумное, что можно сделать — это отказаться от реализации собственной формы для ввода реквизитов платёжных карт и заниматься только переадресаций браузера посетителя на сайты банков — туда, где имеется сертифицированная и законно используемая инфраструктура...
А почему "не имеет"?
Есть регламентация, и есть следующая за ней реализация.
Точно так же как есть кодинг, а потом деплоймент… и эксплуатация… :)
И разумееется регламентация должна учитывать все человеческие аспекты — чтобы получались регламенты, которыми действительно можно руководствоваться.
И результат будет зависеть от обеих стадий — и от регламентации, и от реализации. Какая из них важнее? Почему? Косяк на любой из этих фаз даст отсутствие требуемого результата...
Понятно, что работа с людьми имеет отличия от работы с железками и с программами, спору нет… И навыки там во многом новые нужны...
Различия тоже конечно есть :)
И да, люди — это не код.
А вот регламентация производственного процесса, любого — это вполне уже код — и декларативный, и императивный… :)
И на всякий случай: я совсем не агитирую за отношение к людям как к коду и как к функциям… Прочто полезно видеть сходства и различия там, где они есть… :)
А меня ещё и в другую сторону наблюдение есть. Уже нескольких руководителей видел — вполне успешных, выросших из разработчиков, которые огорчались тем, что занимаются руководящей работой и кодить ну не то, чтобы совсем разучились, но тягаться в этом деле с рядовыми уже не могут.
И огорчаются, что если вдруг какой катаклизм — так разработчику намного проще себе новое применение найти, нежели руководителю...
А ещё видел разработчиков, которые все задатки имели расти по руководящей линии — и при этом сознательно этого не хотели, и хотели расти дальше именно как разработчики — всё ровно из тех же соображений...
На самом деле кое-что общее всё же есть… Если посмотреть попристальнее, скажем, на стандарты менеджмента — ну, например, на стандарт ISO 9001, то можно увидеть, что там — почти такое же программирование :)
И проектирование общей структуры процессов есть, и кодирование последовательности исполнения процессов — тоже. Только язык программирования — не Java и не C++, а некий DSL на основе "обычного бюрократического" :) А за фазой разработки там следуют фазы деплоймента… и мониторинга… и отладка тоже предусмотрена… :)
Кто-то ведь должен этим заниматься, чтобы процессы в организации не падали и не глючили? Ну и совсем не плохо, если этот "кто-то" будет иметь навыки проектирования систем и процессов...
Сама реализация кук и огромные исторические пробелы в их безопасности…
И я не понял: а какие проблемы безопасности есть у куков? Куки — это просто очень низкоуровневый механизм сохранения состояния в цепочке взаимодействий браузера и сервера. Я по правде не вижу там никакой безопасности.
Это поверх куков можно уже строить разные более сложные технологии сохранения состояния и доступа к нему, и вот у них уже будут разные вопросы безопасности. И уязвимости тоже могут быть и могут не быть...
Вам точно удобно хранить данные пользователя (ну кроме как ID сеанса) в куках?
Так а вроде никто и не заставляет… Можно хранить, и можно не хранить :) Куки — очень низкоуровневые и согласны на всё :) Что, где и как хранить — это ж разработчик этажом выше решает...
использовать для этих целей localStorage/sessionStorage и локальную базу
На мой взгляд, localStorage и sessionStorage решают хоть и близкие, но другие задачи. Они все работают на стороне клиента. Они не реализуют никакого взаимодействия сами по себе. Хотя гибкости и добавляют конечно...
Если подойти конструктивно: букв в тексте, вынесенном на обсуждение, получилось действительно много :) И мне лично, наверно, всё стало бы понятнее, если бы у текста появилась более развитая преамбула с аргументированной критикой того, что сейчас есть. С чуть более подробной классификацией рассматриваемых сценариев и их недостатков...
Ну а почему же "на попе ровно" и без развития?
Как раз индивидуальный и плановый подход к развитию каждого отдельного сотрудника вполне вроде проявлен…
Если спектр задач в компании достаточно широк, то и возможностей для развития может хватить…
Другое дело, что не очень понятно, можно ли удержать в такой конструкции навсегда сотрудника, у которого есть свой заметный потенциал для руководства...
Немного странновато подан тезис "Безусловное подчинение", как мне кажется...
Разумеется, принципа "мы тут посоветовались, и я решил" никто не отменял :)
Но когда народ уже "безусловно подчиняется" и "не сопротивляется" — это уже немного отдаёт самодурством и забитостью народа имхо...
И узнать, что народ думает в отношении того, что и как сделать, никогда не интересно?
Или понял я что-нибудь неправильно? :)
По мне — так удивительная история… Не тем удивительная, что человек нашёлся, который уместный вопрос задал, и не тем удивительная, что разумное решение нашлось (всё отметить) :)
А удивительная тем, что похоже, что в процессе разработки отсутствует роль product owner'а, а как это по-русски — я не знаю :)
То есть нет человека, который выступал бы основным заказчиком на разработку (пусть даже внутренним) и понимал бы, что действительно нужно и для чего, и нёс бы персональную ответственность за то, что пилится разработчиками...
Если нет такого человека — так ведь печаль это, и в первую очередь печаль высшего руководства, хотя бывает и так, что им и невдомёк… Тогда-то и надо, чтобы кто- нибудь им намекнул… :)
Сдаётся мне, что у нас нет разногласий :)
Самое главное — чтобы всё в меру и в адеквате :)
Ну, если стажёр может такой вопрос задать, так кто же против :)
Так а "продумывать за" вроде и не требуется… Всё что требуется — это убедиться, что мысль у стажёра движется в правильном направлении, и что его подготовки достаточно, чтобы двигаться туда самостоятельно… А если подготовки не хватает, то подсказать, в какую сторону и каким путём рулить...
Можно конечно и совсем всё на самотёк пустить и подождать, пока стажёр сам по всем граблям лично пройдёт, но не факт, что это пойдёт на пользу проекту и заказчику/работодателю… :)
А вместе подумать — не вариант? :)
А в чём изюмина того, чтобы прорыть канаву целиком самому и непременно лопатой, если рядом стоит экскаватор? :)
Неужели мастерство и ценность разработчика состоит только в том, чтобы решить задачу непременно в одиночку, никого не спрашивая?
А способность пользоваться разными "шаблонами проектирования", а не только одним (упереться рогом и прорыть всё непременно в одиночку) никак не украшают разработчика? Ну например способность спросить на форуме? Способность задать толковый вопрос на StackOverflow? Способность устроить мозговой штурм с коллегами?
Да и просто способность задать вопрос старшему/равному/младшему, не стесняясь, потому что "знать всё" всё равно невозможно, и поэтому спрашивать не стыдно? :)
Ну и тем более тогда похоже, что нога отлынивает :)
Нога могла бы немного активнее работать и задачу стажёрам почётче ставить… Тогда руке проще было бы…
Кстати, иногда эта часть работы "ноги бога" называется архитектурной проработкой… :)
Если честно, то не очень понимаю пафос :)
Если у тебя опыта больше, а у соседа меньше — в чём проблема поделиться? И медали за это даже особой не надо вроде, процесс сам по себе по идее достаточно приятен… :) Ну и вообще менторство можно и в должностную инструкцию старшим коллегам писать по-простому… Только на пользу всем будет — если действительно разумно временем распоряжаться...
Ну и по поводу "вариться в своем соку" тоже не очень понятно. Это всё только если регулярной коммуникации между членами команды совсем нет...
А если код-ревью ввести на регулярной основе? Понятно, что в ближней перспективе трудозатраты возрастут. Зато в дальней — улучшится качество кода, ускорится делёжка опытом и повысится уровень команды в целом. Разве не достойная цель?
PS Первый экземпляр этого комментария куда-то пропал необъяснимым образом, хотя в извещении на почту приехал в полном объёме… Так что это — дубль два :)
Ну, через 50 лет многое по-другому может уже оказаться, и вполне может быть, что и все архивы ведутся в облаках с унифицированным интерфейсом к ним на естественном языке… или через прямое подключение к мозгу… :) И что все необходимые антикварные спецификации форматов тоже где-то сохранены и систематизированы на случай, если вдруг понадобятся...
Только вот вопрос: как обеспечить сохранность информации на первые 10-20 лет из этих 50? :)
:))
А если чуть серьёзнее, то я не поленился посмотреть исходники и увидел там слово "phone4pay". Ну а дальше, перейдя по ссылке, увидел много всего, включая оферту.
А там ведь уже на вид всё по-взрослому… И это уже вполне едет под ФЗ и под определение как минимум "оператора услуг платежной инфраструктуры"… Со всеми вытекающими...
Я бы разделил вопрос на две части:
1) phone4pay и его бизнес. Мне кажется, что не очень безопасно тешить себя идеей, что ФЗ вас не касается. Потому что вполне могут найтись казённые люди, которые аргументированно скажут, что касается. А закон написан так, что трактовать его формулировки можно в широких пределах.
2) Доброе дело по отношению к окружающему миру — с потенциальными ИП, которые могли бы хотеть принимать у себя на сайте платежи с карты на карту, с кодом на Гитхабе и со всем таким. Здесь есть большой риск сделать таким людям вместо доброго дела подлянку, потому что даже если это и не эквайринг в обычном понимании, всё равно это как минимум серая зона с не до конца ясными правилами и с явным несоответствием PCI DSS. А люди-то, которые воспользуются, вряд ли смогут в это всё вникнуть и поверят вам, что всё норм и безопасно...
В принципе этот механизм, наверно, можно сделать более безопасным и более соответствующим правовому полю, если не принимать номер карточки плательщика в свои руки и отложить его ввод до страницы банка. И на страницу банка передавать только номер карточки получателя. Это же можно наверняка сделать? Всё остальное сложится при этом?
Меня здесь пока больше всего беспокоит словосочение "эмулируя страницу банка" вот в этой фразе:
Там точно не происходит введение посетителя в заблуждение относительно того, кому принадлежит страница для ввода реквизитов карты?
И ещё беспокоит то, что всё участники электронных платежей относятся к PCI DSS очень серьёзно. А здесь ввод реквизитов карточек производится в систему, которая на соответствие PCI DSS не сертифицирована и вряд ли даже надлежащим образом спроектирована.
Я — не специалист по правоприменительной практике. И толкователь ФЗ не очень хороший. Поэтому с какими корочками могут прийти казённые мужи к оператору такого платёжного шлюза, и на какие статьи ФЗ и подзаконных актов они будут при этом ссылаться — прогнозировать не буду. Но пропагандировать такой инструментарий как законный и безопасный точно не стал бы...
Если же этот же механизм модифицировать так, чтобы номер карточки плательщика вводился строго на странице банка, а не на странице получателя платежа, то думаю, что претензий уже не будет ни у кого...
Присоединяюсь к уже высказавшимся. Организация инфараструктуры, позволяющей собирать реквизиты платёжных карт, без надлежащей сертификации — дело незаконное и административно наказуемое. ФЗ "О национальной платежной системе" — не самый простой материал для чтения, но есть более-менее доступные для понимания статьи с комментариями, например вот: http://zarlaw.ru/lifehacks/articles/federal-law-national-payment-system/ .
Если же очень хочется занять какое-то место в цепочке прохождения платежей, то самое разумное, что можно сделать — это отказаться от реализации собственной формы для ввода реквизитов платёжных карт и заниматься только переадресаций браузера посетителя на сайты банков — туда, где имеется сертифицированная и законно используемая инфраструктура...
А почему "не имеет"?
Есть регламентация, и есть следующая за ней реализация.
Точно так же как есть кодинг, а потом деплоймент… и эксплуатация… :)
И разумееется регламентация должна учитывать все человеческие аспекты — чтобы получались регламенты, которыми действительно можно руководствоваться.
И результат будет зависеть от обеих стадий — и от регламентации, и от реализации. Какая из них важнее? Почему? Косяк на любой из этих фаз даст отсутствие требуемого результата...
Понятно, что работа с людьми имеет отличия от работы с железками и с программами, спору нет… И навыки там во многом новые нужны...
Но это же не значит, что общего ничего нет? :)
Различия тоже конечно есть :)
И да, люди — это не код.
А вот регламентация производственного процесса, любого — это вполне уже код — и декларативный, и императивный… :)
И на всякий случай: я совсем не агитирую за отношение к людям как к коду и как к функциям… Прочто полезно видеть сходства и различия там, где они есть… :)
А меня ещё и в другую сторону наблюдение есть. Уже нескольких руководителей видел — вполне успешных, выросших из разработчиков, которые огорчались тем, что занимаются руководящей работой и кодить ну не то, чтобы совсем разучились, но тягаться в этом деле с рядовыми уже не могут.
И огорчаются, что если вдруг какой катаклизм — так разработчику намного проще себе новое применение найти, нежели руководителю...
А ещё видел разработчиков, которые все задатки имели расти по руководящей линии — и при этом сознательно этого не хотели, и хотели расти дальше именно как разработчики — всё ровно из тех же соображений...
На самом деле кое-что общее всё же есть… Если посмотреть попристальнее, скажем, на стандарты менеджмента — ну, например, на стандарт ISO 9001, то можно увидеть, что там — почти такое же программирование :)
И проектирование общей структуры процессов есть, и кодирование последовательности исполнения процессов — тоже. Только язык программирования — не Java и не C++, а некий DSL на основе "обычного бюрократического" :) А за фазой разработки там следуют фазы деплоймента… и мониторинга… и отладка тоже предусмотрена… :)
Кто-то ведь должен этим заниматься, чтобы процессы в организации не падали и не глючили? Ну и совсем не плохо, если этот "кто-то" будет иметь навыки проектирования систем и процессов...
И я не понял: а какие проблемы безопасности есть у куков? Куки — это просто очень низкоуровневый механизм сохранения состояния в цепочке взаимодействий браузера и сервера. Я по правде не вижу там никакой безопасности.
Это поверх куков можно уже строить разные более сложные технологии сохранения состояния и доступа к нему, и вот у них уже будут разные вопросы безопасности. И уязвимости тоже могут быть и могут не быть...
Так а вроде никто и не заставляет… Можно хранить, и можно не хранить :) Куки — очень низкоуровневые и согласны на всё :) Что, где и как хранить — это ж разработчик этажом выше решает...
На мой взгляд, localStorage и sessionStorage решают хоть и близкие, но другие задачи. Они все работают на стороне клиента. Они не реализуют никакого взаимодействия сами по себе. Хотя гибкости и добавляют конечно...
Если подойти конструктивно: букв в тексте, вынесенном на обсуждение, получилось действительно много :) И мне лично, наверно, всё стало бы понятнее, если бы у текста появилась более развитая преамбула с аргументированной критикой того, что сейчас есть. С чуть более подробной классификацией рассматриваемых сценариев и их недостатков...