Я понимаю, что вы в розовых очках, но это, честно говоря, отстой.
Т.е. зачем не переписывать старые сервисы — это понятно. Но зачем писать новое на полудохлом языке и переучивать на него сложившихся спецов, тратя время, деньги и теряя кучу кандидатов, которые понимают, что это знания, которые они выбросят, как только выйдут за дверь…
В век SOA, Microservices и т.п. это выглядит жутким сектантством, вроде как, если бы кучка «архитекторов» захватила власть и всех заставляла ботать Perl, чтобы как-то оправдать свою нужность.
Помнится в далекие ВУЗовские времена один препод нам рассказывал, что инженер в Российской империи должен был уметь разбираться в любых механизмах.
И из пушки стрелять и дороги строить.
Для этого нужна штука, которая называется абстрактное мышление.
К сожалению, рынок труда таков, что ценится специализация, поэтому многие программеры из страха провала начинают бояться шагнуть не в ту сторону.
Кто не боится — тот full stack. )
Не без проблем, конечно, но полет нормальный. Sbt не быстрый, но свое дело делает, это он раньше был совсем отсталым. Scala сам по себе уже не новый язык, на нем есть большие проекты, например, Apache Spark.
Twitter, опять же, давно юзает его в Production и выпустил много open-source инструментов.
Java уже давно двигается по инерции, как, впрочем, и сам Oracle, который все больше катится в забвение.
Да, нет. Те же люди из Украины, России да откуда угодно, перебирающиеся в сторону Запада довольно легко адаптируются к другим условиям. Видел немало примеров.
Такие вещи, кстати, на Западе тоже не редкость. Говноконтор тоже хватает.
Основная проблема всей отрасли — низкое качество управленческих кадров.
Говоря на пальцах, есть разница между Agile и бардаком, между внедрением процессов и микроменеджментом. Дьявол в деталях.
Поэтому часто начинается «адаптация под местные реалии», разговоры про менталитет и прочее.
Все это — только оправдания собственной некомпетентности руководителей в ИТ.
Вы, в принципе, это и описали. Неумение работать с новичками, которые пришли из других отраслей, нежелание вкладывать в развитие команды, плохая коммуникация с разработчиками и т.п.
Так сложилось, что некоторые люди собственную лень и некомпетентность объясняют с позиции «я гуманитарий». Понимаете, в этой среде уважение можно заслужить только сделав что-то своими руками и преодолев хоть какие-то трудности на пути.
Как вариант, осильте любой онлайн-курс по основам. Например, «Introduction to Computer Science» на edx.
Потом изучите любой язык программирования, например, Python на Codecademy хотя бы на уровне сделать простой сайт.
Даже, если это будет кривая нубская фигня, это будет попытка, требующая определенных усилий.
Общий негатив к журналистам, конечно, есть.
Многие журналисты, которые пишут на около ИТ темы грешат некоторыми вещами. Например,
1. Дешевый популизм и конъюктурщина (например, 10 советов стартапу и т.п. отстой)
2. Откровенный репост и плагиат с западных сайтов и блогов аля творческая переработка
3. Вопиющая некомпетентность в самых базовых вещах (вспомните ту ведущую с ЭХА про «8 миллионов, я гуманитарий», в ИТ это частенько вылезает)
4. Очень поверхностный характер текстов (много-много воды и мало сути)
Не делайте этого и вы автоматом попадете в топ 10% лучших ИТ журналистов.
Любые материалы на сложные темы надо давать экспертам на вычитку, иначе проблемы неизбежны.
Не знаю, насколько это ляжет в ваши реалии, но при регистрации бизнеса на Западе, есть хорошие инструменты, например, клиф и вестинг периоды. Удачи Вам в следующих начинаниях!
должны были полностью прописать правила функционрирования бизнеса, описать бизнес-процессы; указать цели, которых надо достигать; определить формулу по которой директор будет получать свою зарплату
Вы такое на практике хоть где-нибудь встречали или только в книжках?
Судя по риторике автора он не самый конфликтный человек, к тому же предложил Ане выкупить его долю. Для первого раза — очень неплохо.
Возможно, но это будет скорее внутренняя проблема банка, мы же говорим о фроде с картами для мерчантов, там все более-менее универсально.
Нужно за 1-2 часа написать быдлокод, чтобы «хоть как-то работало»
В банках большинство кода такого, так что ничего не изменится.
Более того, система, построенная на базе machine learning, может выявить аномалии гораздо раньше, чем «аналитики», склонные долго обедать и работать 8 часов в день.
Если вы делаете проект «for fun», то могу только пожелать удачи.
Если хотите коммерциализировать, то не хотелось бы убивать ваш энтузиазм и не рекламы ради, но все это уже придумано.
Непросто будет сделать что-то дешевле и лучше сервиса за 1 цент/транзакция, сделанного парнями из Гугла. В России такой тоже имеется, например, у ПС Assist.
Сами понимаете, в machine learning все зависит от количества данных, поэтому выигрывает тот, у кого больше данных.
По своему опыту в платежах, вижу в статье несколько не совсем верных посылов.
Например, мерчанты (за исключением больших, типа того же упомянутого badoo) почти всегда пользуются антифродом от ПС, уговорить их интегрировать что-то еще непросто.
Также цифры по «потерянным» платежам с/без 3DS могут разниться, 20% — это скорее экстремальный случай, зависит от бизнеса мерчанта.
PCI DSS, в общем-то не нужен. Первые 6 и последние 4 цифры карты вполне хватает для ее идентификации и их можно хранить без сертификации. По персональным данным, конечно, надо смотреть.
Смотрите, у вас есть data scientist, который знает Python.
Ему нужно дать возможность придумывать новые атрибуты для моделей.
Я не знаю, как это выглядит в Spark, но полагаю. что это будут, например, какие-то функции над RDD.
Теперь надо как-то эти функции вызвать из Java приложения, которое крутится у вас на продакшене, чтобы оно из них составило, например, feature vector.
Так можно?
Статья у вас получилась очень сумбурная, такой поток сознания.
Осталось неясно, что вам конкретно не нравится в Scrum.
есть потери времени на стендапы, ретроспективы и т.п.
Стендап длится от силы 10 минут и это, пожалуй, самый полезный митинг.
На новости на Хабре уходит куда больше времени.
Ретро помогает разобраться в корнях проблем, до того, как будет поздно.
Например, в вашем примере со студией, возможно, программер уже подустал писать однотипные магазы и уже смазывает лыжи, но вы прочувствуете этот момент, если не будете получать от него регулярный фидбек по работе.
совместное владение кодом и ограничение на число одновременных задач снижают общую эффективность
Т.е. распыление внимания на много разных задач эффективность повышает?
Весьма спорно. Тем более, в методологии команда сама решает, сколько задач она может тянуть параллельно.
Совместное владение кодом — это не про эффективность, а про взаимозаменяемость.
Это на случай, если тот программер из студии укатил на смазанных лыжах, работа не встанет на неделю, пока кто-то будет в панике разгребать его код.
Честно говоря, осталось впечатление, что вы не видите за деревьями леса.
Максимизация эффективности идет из психологии работников, из их внутренней мотивации. Ритуалы просто помогают поддерживать эту мотивацию, но они не самоцель.
Т.е. зачем не переписывать старые сервисы — это понятно. Но зачем писать новое на полудохлом языке и переучивать на него сложившихся спецов, тратя время, деньги и теряя кучу кандидатов, которые понимают, что это знания, которые они выбросят, как только выйдут за дверь…
В век SOA, Microservices и т.п. это выглядит жутким сектантством, вроде как, если бы кучка «архитекторов» захватила власть и всех заставляла ботать Perl, чтобы как-то оправдать свою нужность.
Наверное, я ошибаюсь, как вам кажется?
И из пушки стрелять и дороги строить.
Для этого нужна штука, которая называется абстрактное мышление.
К сожалению, рынок труда таков, что ценится специализация, поэтому многие программеры из страха провала начинают бояться шагнуть не в ту сторону.
Кто не боится — тот full stack. )
А в чем проблема? Spark можно собрать под 2.11 начиная с версии 1.2 или вроде того.
Поживем — увидим, но это точно не Rust, так что все не должно сломаться.
Выстрелить себе в ногу можно разными способами. Увидев Play 2 после Play 1, уже можно было понять, что эти парни — маньяки.
Twitter, опять же, давно юзает его в Production и выпустил много open-source инструментов.
Java уже давно двигается по инерции, как, впрочем, и сам Oracle, который все больше катится в забвение.
Да, нет. Те же люди из Украины, России да откуда угодно, перебирающиеся в сторону Запада довольно легко адаптируются к другим условиям. Видел немало примеров.
Такие вещи, кстати, на Западе тоже не редкость. Говноконтор тоже хватает.
Основная проблема всей отрасли — низкое качество управленческих кадров.
Говоря на пальцах, есть разница между Agile и бардаком, между внедрением процессов и микроменеджментом. Дьявол в деталях.
Поэтому часто начинается «адаптация под местные реалии», разговоры про менталитет и прочее.
Все это — только оправдания собственной некомпетентности руководителей в ИТ.
Вы, в принципе, это и описали. Неумение работать с новичками, которые пришли из других отраслей, нежелание вкладывать в развитие команды, плохая коммуникация с разработчиками и т.п.
Как вариант, осильте любой онлайн-курс по основам. Например, «Introduction to Computer Science» на edx.
Потом изучите любой язык программирования, например, Python на Codecademy хотя бы на уровне сделать простой сайт.
Даже, если это будет кривая нубская фигня, это будет попытка, требующая определенных усилий.
Общий негатив к журналистам, конечно, есть.
Многие журналисты, которые пишут на около ИТ темы грешат некоторыми вещами. Например,
1. Дешевый популизм и конъюктурщина (например, 10 советов стартапу и т.п. отстой)
2. Откровенный репост и плагиат с западных сайтов и блогов аля творческая переработка
3. Вопиющая некомпетентность в самых базовых вещах (вспомните ту ведущую с ЭХА про «8 миллионов, я гуманитарий», в ИТ это частенько вылезает)
4. Очень поверхностный характер текстов (много-много воды и мало сути)
Не делайте этого и вы автоматом попадете в топ 10% лучших ИТ журналистов.
Любые материалы на сложные темы надо давать экспертам на вычитку, иначе проблемы неизбежны.
Удачи вам!
Это и был знак, просто Вы его неверно истолковали.
Удачи вам!
Вы такое на практике хоть где-нибудь встречали или только в книжках?
Судя по риторике автора он не самый конфликтный человек, к тому же предложил Ане выкупить его долю. Для первого раза — очень неплохо.
Возможно, но это будет скорее внутренняя проблема банка, мы же говорим о фроде с картами для мерчантов, там все более-менее универсально.
В банках большинство кода такого, так что ничего не изменится.
Более того, система, построенная на базе machine learning, может выявить аномалии гораздо раньше, чем «аналитики», склонные долго обедать и работать 8 часов в день.
Если хотите коммерциализировать, то не хотелось бы убивать ваш энтузиазм и не рекламы ради, но все это уже придумано.
Непросто будет сделать что-то дешевле и лучше сервиса за 1 цент/транзакция, сделанного парнями из Гугла. В России такой тоже имеется, например, у ПС Assist.
Сами понимаете, в machine learning все зависит от количества данных, поэтому выигрывает тот, у кого больше данных.
По своему опыту в платежах, вижу в статье несколько не совсем верных посылов.
Например, мерчанты (за исключением больших, типа того же упомянутого badoo) почти всегда пользуются антифродом от ПС, уговорить их интегрировать что-то еще непросто.
Также цифры по «потерянным» платежам с/без 3DS могут разниться, 20% — это скорее экстремальный случай, зависит от бизнеса мерчанта.
PCI DSS, в общем-то не нужен. Первые 6 и последние 4 цифры карты вполне хватает для ее идентификации и их можно хранить без сертификации. По персональным данным, конечно, надо смотреть.
Бесплатно, $29, $49, $149
После запуска(год назад):
$9, $49, $149, $299
Сейчас:
$250, $2000, $6000
Смело они задрали, конечно, молодцы.
Ему нужно дать возможность придумывать новые атрибуты для моделей.
Я не знаю, как это выглядит в Spark, но полагаю. что это будут, например, какие-то функции над RDD.
Теперь надо как-то эти функции вызвать из Java приложения, которое крутится у вас на продакшене, чтобы оно из них составило, например, feature vector.
Так можно?
Например, написать что-то на Python, потом вызвать из Java?
Осталось неясно, что вам конкретно не нравится в Scrum.
Стендап длится от силы 10 минут и это, пожалуй, самый полезный митинг.
На новости на Хабре уходит куда больше времени.
Ретро помогает разобраться в корнях проблем, до того, как будет поздно.
Например, в вашем примере со студией, возможно, программер уже подустал писать однотипные магазы и уже смазывает лыжи, но вы прочувствуете этот момент, если не будете получать от него регулярный фидбек по работе.
Т.е. распыление внимания на много разных задач эффективность повышает?
Весьма спорно. Тем более, в методологии команда сама решает, сколько задач она может тянуть параллельно.
Совместное владение кодом — это не про эффективность, а про взаимозаменяемость.
Это на случай, если тот программер из студии укатил на смазанных лыжах, работа не встанет на неделю, пока кто-то будет в панике разгребать его код.
Честно говоря, осталось впечатление, что вы не видите за деревьями леса.
Максимизация эффективности идет из психологии работников, из их внутренней мотивации. Ритуалы просто помогают поддерживать эту мотивацию, но они не самоцель.