Не то чтобы я абсолютно не в курсе проблемы, и документацию читал, и официальный курс проходил на education.mongodb.com, во время которого подчеркивалась необходимость в минимум трех инстансах для production. И форумы курил, в которых народ жаловался на то, что при OOM у них целостность базы иногда нарушалась, что при единственном инстансе равнозначно потере данных от последнего бэкапа. Кстати, если взять CouchDB, к примеру, то у него целостность данных очень даже замечательно обеспечивается.
Так что никакой паники нет, а привычка к базе (не MySQL в моем случае), которая не теряет все данные при падении сервера — есть :-)
Если одной машины хватает, то проблем с CAP-теоремой не возникнет.
B MongoDB одной машиной по определению пользоваться нельзя в production. Так что она действительно в какой-то степени «broken by design», как в заголовке одной из ссылок в начале статьи. Конечно, не MongoDB единой жив не-только-SQL.
У меня лично проблема с использованием не-SQL баз заключалась в первую очередь с отсутствием поддержки в генераторах отчетов типа BIRT-a. Только в последнее время понемногу начали прикручивать, вроде. А еще-бы найти генератор отчетов, который данные из REST Web сервисов умеет вытаскивать.
А если взять пластиковую трубку, запечатанную с одного конца, зарядить с дула патроном 38го калибра, и на тыльной стороне приспособить пружинный боек… тоже надо запретить…
XML и JSON по природе своей не сильно отличаются, и такая кардинальная разница в скорости парсинга может случиться только в случае, если для разбора XML использовалась какая-то ну очень неудачная библиотека, которая жутко свопила на диск. То есть теоретически можно было и с XML работать также быстро — все дело только в библиотеке подходящей (конечно, если используемая платформа таковую поддерживает).
А статья интересная — всегда приятно, когда за счет смены инструментария на более подходящий, производительность ускоряется на порядки.
Как это ни странно, куча народу на Виндах ссидит и не парится… юзают TextPad или NotePad++ и т.п., и про vim даже не слышали. «Все крутые пацаны рубятся в консоль, и только девчонки предпочитают ГУИ» — это моя половина так шутит.
Самое страшное в виме для новичка — это то, что выйти из него никак нельзя! Помню я этот кошмар 20 лет назад… На этом попытки изучения обычно и заканчиваются.
P.S. Написано с Debian Linux, чтоб не пинали за рекламу виндов…
Да нет, авторы оригинального кода были очень профессиональными разработчиками с большим опытом проектирования — система в целом была очень грамотно разработана. У них не было злого умысла. Их подвело то, что эта идея о разработке без комментариев работает только до тех пор, пока поддержкой и развитием занимаются только оригинальные разработчики.
Самодокументируемым код типа
std::vector(Property) getPropertiesByMainType( int mainType )
Пришел я как-то работать в один большой энтерпрайз проект, который в течение лет трех разрабатывали исходя из этой идеологии, что если код правильно спроектирован, то комментарии не нужны.
Для того, кто оригинально этот код писал, комментарии были действительно не нужны.
А все новички, коих было много (не важно с десятью годами опыта или с двумя) жутко плевались и страдали от того, что им приходилось переловачивать горы кода и изучать реализацию, чтобы понять, какие параметры допустимы, как функции реагируют на ошибки, и т.п.
Представьте себе, что библиотека Java или С++ начнет следовать такой идеологии и обходиться без комментариев…
Без комментариев можно обходиться в небольших проектах, которые один человек пишет.
Вопрос про «Замена услуг лицензией на использование программно-аппаратных средств» — то есть, если мой сайт предоставляет платный сервис, то я плачу НДС, а если я продаю лицензию, то я не плачу НДС?
А чем для меня продажа лицензии отличается от предоставления услуг в правовом плане — означает-ли это, что я передаю пользователю больше прав на свой продукт?
И кто может инициировать переквалификацию соглашения, и по каким причинам?
Статья очень хороша! Хорошо прикладывается к любой профессии, не обязательно game dev и design.
У вас выпадает первый молочный зуб. Ужасно страшно (если бы вы помнили) потом они сыплются как дождь из ведра в размере 32 капель. Еще 32 в зависимости от ситуации тоже начнут покидать вас рано или поздно.
И проще, и сложнее. Зависит от точки зрения. Про проще все понятно — рабочий процесс идет, доходы не снижаются — все довольны. Все довольны? Не факт! Владельцы-то фирмы довольны, а вот работники — как посмотреть. Вот тут и начинается сложнее — чтобы сохранить хороших работников и их мотивацию (задача актуальная, на самом деле), недостаточно тупо раздавать им задачи и следить за исполнением. Нужно следить за настроениями — это не все умеют (я — не особо), и на это обычно нет времени.
В подавляющем большинстве фирм заедает текучка. Как правило, ни у начальства, ни у подчиненных нет времени анализировать и оглядываться на удовлетворенность работника своей работой, ни на пользу фирме от работника — до тех пор, пока не назревает исключительная ситуация, и дело заканчивается увольнением, и хорошо если без скандалов.
Так вот эти встречи раз в год или полгода как раз и позволяют обеим сторонам пересмотреть свои успехи, настроения, удовлетворенность друг другом, и при необходимости скорректировать то, что нуждается в корректировке.
Изначально идея здравая, а перегибы можно в чем угодно устроить.
А про то, что тим лид должен постоянно ситуацию мониторить, так я таких тим лидов единицы встречал, которые на это реально способны.
Если Вы с явлением не сталкивались, это не значит, что оно не существует.
Я в двух компаниях работал, 100-200 чел работников, где в определенный момент времени начали проводить такие мероприятия два раза в год. Народ их не сильно любил (у нас все-таки не западный менталитет), но при этом относился ответственно.
Так что никакой паники нет, а привычка к базе (не MySQL в моем случае), которая не теряет все данные при падении сервера — есть :-)
B MongoDB одной машиной по определению пользоваться нельзя в production. Так что она действительно в какой-то степени «broken by design», как в заголовке одной из ссылок в начале статьи. Конечно, не MongoDB единой жив не-только-SQL.
У меня лично проблема с использованием не-SQL баз заключалась в первую очередь с отсутствием поддержки в генераторах отчетов типа BIRT-a. Только в последнее время понемногу начали прикручивать, вроде. А еще-бы найти генератор отчетов, который данные из REST Web сервисов умеет вытаскивать.
Там были банальные злые северокорейцы? :-)
А статья интересная — всегда приятно, когда за счет смены инструментария на более подходящий, производительность ускоряется на порядки.
Самое страшное в виме для новичка — это то, что выйти из него никак нельзя! Помню я этот кошмар 20 лет назад… На этом попытки изучения обычно и заканчиваются.
P.S. Написано с Debian Linux, чтоб не пинали за рекламу виндов…
Самодокументируемым код типа
std::vector(Property) getPropertiesByMainType( int mainType )
или
void setTimeout( int timeout )
быть не может в принципе.
Работа с datetime, конечно, правильней. Но для простых вещей часто проще задать константу.
Для того, кто оригинально этот код писал, комментарии были действительно не нужны.
А все новички, коих было много (не важно с десятью годами опыта или с двумя) жутко плевались и страдали от того, что им приходилось переловачивать горы кода и изучать реализацию, чтобы понять, какие параметры допустимы, как функции реагируют на ошибки, и т.п.
Представьте себе, что библиотека Java или С++ начнет следовать такой идеологии и обходиться без комментариев…
Без комментариев можно обходиться в небольших проектах, которые один человек пишет.
Вопрос про «Замена услуг лицензией на использование программно-аппаратных средств» — то есть, если мой сайт предоставляет платный сервис, то я плачу НДС, а если я продаю лицензию, то я не плачу НДС?
А чем для меня продажа лицензии отличается от предоставления услуг в правовом плане — означает-ли это, что я передаю пользователю больше прав на свой продукт?
И кто может инициировать переквалификацию соглашения, и по каким причинам?
А молочных зубов вроде 20, нет?
И проще, и сложнее. Зависит от точки зрения. Про проще все понятно — рабочий процесс идет, доходы не снижаются — все довольны. Все довольны? Не факт! Владельцы-то фирмы довольны, а вот работники — как посмотреть. Вот тут и начинается сложнее — чтобы сохранить хороших работников и их мотивацию (задача актуальная, на самом деле), недостаточно тупо раздавать им задачи и следить за исполнением. Нужно следить за настроениями — это не все умеют (я — не особо), и на это обычно нет времени.
Так вот эти встречи раз в год или полгода как раз и позволяют обеим сторонам пересмотреть свои успехи, настроения, удовлетворенность друг другом, и при необходимости скорректировать то, что нуждается в корректировке.
Изначально идея здравая, а перегибы можно в чем угодно устроить.
А про то, что тим лид должен постоянно ситуацию мониторить, так я таких тим лидов единицы встречал, которые на это реально способны.
Ну как-бы всему учатся постепенно, и умение себя подать/продать это очень важное умение на самом деле.
Я в двух компаниях работал, 100-200 чел работников, где в определенный момент времени начали проводить такие мероприятия два раза в год. Народ их не сильно любил (у нас все-таки не западный менталитет), но при этом относился ответственно.