то что вы описываете отчасти было в 90х у нас и в общем-то все выжили
на самом деле вы зануда и не понимаете сарказма, а учитывая что я тоже зануда, то я вам отвечу, что во-первых это не принято официально, во-вторых это про климат и экосистему, а не про строение земной коры, что и имелось ввиду автором.
и да и нет, реально были годные статьи после которых не думаешь что потерял время
Классика доу — статья ни о чем от капитана КО(очередного лайфкоуча). Единственное что порадовало это: «Геологи как раз из разряда тех, кто все понял о жизни. Они считают, что за последние несколько миллионов лет на земле ничего существенного не произошло.» — я начал уважать геологов
уровень сложности изложенного материала — тимлид в плариуме
Некоторые организации просто выпускают документы с заголовками «best current practice». Они неправы?
конечно правы, но они же не называют себя единственными носителями правды и не говорят что они изобрели эти практики и только они являются правильными. Более того, такие организации чаще всего вырабатывают специфические подходы которые сильно эффективнее обобщенных agile практик
Аgile/Scrum коучи это секта какая-то как по мне, люди собрали несколько хороших практик которые существовали всегда и назвали это отдельным словом. При этом они говорят что только это хорошо и что это подойдет абсолютно всем. Большинство адекватных и опытных ПМов и лидов и так применяют такие подходы в определенных ситуациях и называется это у них не agile, а здравый смысл. Все эти коучи, скрам мастеры и тренеры — это просто монетизация человеческих страхов и фальшивая возможность потом отгородиться от проблем.
В дополнение хороший тред на тему почему в гугле понятия agile не существует: www.quora.com/...evelopment-to-be-nonsense
Какой же это лютый колхоз и джинсовый айти популизм, поражают люди которые говорят ну хоть какие-то изменения будут. Набор базвордов, в общем походу кроме волонтеров которые сами что-то педалят в ближ годы ничего не будет ну и понятно не на государственном уровне. Хоть бы к 2050 запустили единый билет на транспорт.
9 пункт зло, надо делать как раз наоборот, другое дело что общение внутри команды никто не отменял
Я думаю в первую очередь стоит определится нужна тебе наука или инженерия. То DS/ML и тд
о котором ты говоришь это инженерия и в будущем еще больше будет инженерией скорее всего. То есть с большой вероятностью ты буде строить что-то из уже существующих кирпичиков не проводя исследования и тд. Я бы шел на физику если есть способности и лучше не в Украине, а где-то за границей, вроде как сейчас не сложно и не дорого попасть в нормальный универ. У тебя всегда будет возможность спрыгнуть в программирование. Никто не мешает тебе заниматься программированием и AI как хобби и быть в курсе событий в отрасли. Удачно выбрав прикладную область думаю можно будет потом все это совмещать.
PR здорового человека. Трудно понять, что делалось на самом деле не будучи внутри компании, но то, что хотя бы на уровне деклараций они идут дальше чем организация курсов и хайринг конференций это круто.
Это как хотелось бы в идеале. Понятно, что просто так никто никого не сможет заставить куда-либо ехать. Работники из другого пригорода всегда могут работать в центральном офисе. Cейчас не стоит вопрос о массовости, а скорее о прецеденте. Cкорее всего, пока промышленность в упадке и офисы кроме айтишников никому не нужны, это не будет сильно выгодно работодателю. Разве что плюшка для работника и повышение лояльности для работодателя.
зачем много лет? мы же исходим из того что в пригороде все дешево и тд — не вижу проблемы тогда просто поработать два три года и переехать обратно при надобности с минимальными финансовыми потерями. К тому же с большой вероятностью если это будет тренд то работы в пригороде будет достаточно.
Офисы должны уходить из центра города — вначале в спальные районы, потом в пригород. Необязательно закрывать офис и открывать новый в пригороде. Вполне можно открыть доп офис для команды которой будет удобно работать в спальном районе или пригороде. Это будет развивать локальную инфраструктуру и экономить время работникам.
Придется, я об этом и говорю. Хотя все очень зависит от проекта. Вы видимо просто еще не столкнулись с такими ситуациями. Если у вас нету индекса в хранилище — это не значит что вам не придется втулить его на уровне апы. Про схему я вообще молчу — кассандра или монго — там по любому схема будет в том или ином виде и ее надо будет мейнтейнить либо в виде классов либо в виде скриптов и будут все те же стандартные бока только немного в другом месте.
Единственный аргумент в вашей статье с которым я согласен это скорость работы: большинство NoSql пилились с мыслью о производительности, для СУБД же в первую очередь было важно ACID. И тут им нет равных, особенно если говорить про простые key value. Но очень часто за это приходится платить либо упрощением требований либо сложным кодом. Последнее например не всегда приемлемо для стартапов.
Нету проблем с деплойментом, схемой, апдейтами и тд. Если у ни возникают при работы с СУБД и современными фреймворками, то вероятно что-то делается не так. И заменив СУБД на Nosql скорее всего такие же проблемы вылезут где-то на другом уровне. Просто надо понимать реальные отличия и юскейсы и я вам скажу очень мало кто внедрял NoSql только что бы избавится от схемы или упростить деплоймент.
PS. лет 7 назад сталкивался с базой MySql в 20GB положенной на RAMDRIVE — это было в десятки раз дешевле чем нанимать программистов и переписывать на NoSql
Понятия не имею что там ваш проект делал — там про редис 2 строки написано и да я сталкивался с такими системами, ровно как и с такими которые требуют скорости в несколько тысяч ответов за секунду.
Моя мысль была в том, что в общем-то те проблемы которыми вы описали SQL очень просто решаются или вообще решены из коробки(деплоймент мейнтенанс, схема индексы и тд) и не особо отличаются от NoSql. К тому же, например, какую бы технологию вы не выбрали, вам придется где-то хранить схему и индексы(или доп кеши) — либо в самой апе либо в виде структуры стореджа. Вот в плане перформанса конечно у NOSQL явный выигрыш тк нормально запартишинить SQL базу довольно неудобно.
Странно, что у вас в голове не укладывается, что бывают задачи где очень мало запросов, но каждый запрос может занимать огромное количество времени и обрабатывать тонны данных.
так себе статейка, особенно про «Несерьёзно делать системы, которые умирают при нагрузке в 10 рек-сек.». Про SQL vs NoSql — если вопрос в перформансе то все равно после первого года переписывать придется. В плане сложности и поддержки оба подхода уже достаточно абстрагированы настолько что бы не приходилось вдаваться в детали деплоймента или написание даошек. Складывается такое ощущение что чувак не работал с серьезные NoSQL проектами и не хлебнул там.
после первого абзаца уже статью читать не хочется
про бизнес аналитика уже говорили, добавлю IT журналистика и аналитика по типу техкранча и дальше все смежные профессии включая организаторство внутри IT тусовки, реклама и продакт овнершип