По хадупу книга это штука очень очень очень странная. Про что рассказывать — про API Yarn? а зачем если вы никогда не будете системным программистом в хадуп инфраструктуре и будет пользоваться только Spark и Hive. рассказывать про основы? — это 2 страницы. Очень интересна была бы книга, которая бы провела через эпоху становления SQL баз и обьяснила почему они такие, какие они есть, потом обьяснила подробно почему они не масштабируются и насколько реально они масштабируются. И со всей это историей подошла бы cassandra, hadoop и spark.
Я собесдовался в 45 компаний за последнии 3 года. Половина российских, половина западных. Наши собесы похожи на их собесы в стартапы. Книжка про задачки ACM-like в компании типа гугла амазона, фейсбука, убера, яху. А собесы в российские компании в большинстве своем — какие есть методы у класса Object если совсем плохо, и если более менее — «у вас есть банковские счета… а как избежать dead lock… » За исключением JB, Yandex, Mail. В ВК не собеседовался не знаю.
Зачем? Книга про интервьюирование в западные компании. Их процесс интервью радикально отличается. Она не поможет для российских компаний. А если человек собеседуется в западную, то пусть читает на английском — ибо интервью будет на английском
Еще раз. Они туда коммитят или являются коммитерами? Я в своей статье пытался показать, что это разные вещи.
Очень может быть что наши картины различаются ибо мы смотрим на разные проекты. Из-за этого не совпадают ощущения. но прежде чем делать такой вывод посмотрите являются ли Ваши соотечественники коммитерами и работают ли они в Российских компаниях
Можете пояснить — это карта коммитев или коммитеров? Потому что я писал о коммитерах, а не коммитах. Здесь мне кажется не учитывается размер проектов, что на мой вкус важно. Я полтора года назад вконтрибутил немного кода в главный класс спарка — RDD — и это было сравнительно просто. Сейчас даже тесты в MLLib не вмерживают из-за того, что есть коммитерами одобреная гуглодока стратегии развития этого куска кода и мой код туда не вписывается. Надо писать обоснование, получать одобрение на интерфейсы… Проект стал большой. Теперь контрибутить нетревиальные вещи — большой труд. И эти виды коммитов как мне кажется надо разделять.
P.S. насчет статистики. Я верю что это аккуратные цифры и они репрезнтуют что-то. Но есть исследование StackOverflow которое дает иную картину — stackoverflow.com/research/developer-survey-2015. Я не буду спорить на уровне больших цифр — я не компетентен. Я могу только сказать про проекты в которых я копал откуда растут эти фичи и что оттуда еще должно вырасти.
Я контрибьючу немного в Спарк, немного раньше в Zeppelin. Делал патчи в Solr но их (правильно на мой вкус) не приняли.
На мой вкус это 2 разные истории — когда компания просто выкладывает свой код в опен сорс, и когда она делает свой продукт реально опен сорсным. Второе подразумевает — внутри перейти на опен сорс версию, развивать и работать с коммунити, формировать набор комитеров за пределами своей компании, и для некоторых проектов может — пойти под «зонтик» того же Apache для следования стандартам индустрии(традиции версионирования, мейлинг листы, стандарты CI)
В яндексе настолько вкладываются как мне кажется только в BEM(и в него вкладываются довольно профессионально на мой вкус). Я не знаю, но представляю каким интересам компании это может соответствовать — стандартизировать верстку, чтобы иметь возможность легче потом все интегрировать в свои поисковые снипеты, или верстать проще(?) Опять же плохо знаю этот фреймворк. Но в нем наверно я вижу черты нужды в committers про которые я говорил.
Есть open source проекты в которых не участвуют интересы никаких компаний. Они на мой вкус позорят звание top level apache проекта. Например Oozie без нормальной документации архитектуры и поддержки спарка до недавнего времени, или big top который отстает от контейнерной революции, спарка, ambari, и вообще всего на свете.
Как мне кажется это связано с тем, что никто их не коммерциализирует или не завязан на них в своей архитектуре настолько, чтобы вкладывать силы в развитие.
Да на самом деле, если уж по совести делать, то все эти части должны быть на английском. Но тогда русскими останутся только союзы. Но тогда уже надо весь текст писать на английском. Но зачем, если только русско-язычной публике это интересно? Поэтому я выбрал что-то посередине.
Очень может быть что наши картины различаются ибо мы смотрим на разные проекты. Из-за этого не совпадают ощущения. но прежде чем делать такой вывод посмотрите являются ли Ваши соотечественники коммитерами и работают ли они в Российских компаниях
P.S. насчет статистики. Я верю что это аккуратные цифры и они репрезнтуют что-то. Но есть исследование StackOverflow которое дает иную картину — stackoverflow.com/research/developer-survey-2015. Я не буду спорить на уровне больших цифр — я не компетентен. Я могу только сказать про проекты в которых я копал откуда растут эти фичи и что оттуда еще должно вырасти.
Я контрибьючу немного в Спарк, немного раньше в Zeppelin. Делал патчи в Solr но их (правильно на мой вкус) не приняли.
В яндексе настолько вкладываются как мне кажется только в BEM(и в него вкладываются довольно профессионально на мой вкус). Я не знаю, но представляю каким интересам компании это может соответствовать — стандартизировать верстку, чтобы иметь возможность легче потом все интегрировать в свои поисковые снипеты, или верстать проще(?) Опять же плохо знаю этот фреймворк. Но в нем наверно я вижу черты нужды в committers про которые я говорил.
Как мне кажется это связано с тем, что никто их не коммерциализирует или не завязан на них в своей архитектуре настолько, чтобы вкладывать силы в развитие.