Я за 8 лет не могу назвать себя программистом с большой буквы, хоть уже и не один проект в продакшн ушел. Так что девушка молодец. Только движется она в каком-то непонятном направлении на мой взгляд. Все вышепоказанные примеры — какие-то разбросанные и т.п. В общем не видно какого-то конкретного направления движения. Скорее напоминает какой-то разрозненный набор копипастов в попытке найти себя.
Задержка именно при записи происходит. Количество записей — меньше 10 000. В рамках одной виртуальной машины сконфигурирован репликасет из 3-ех нод. Посмотрел время записи через логи(написал специальный интерцептор, который логирует долгие операции — те, что больше 500 мс выполняются — пишется название метода и сколько он выполнялся). Так что с этим все точно.
Стоит отметить, что это бежит на aws ec2. На «large» машине с Ubuntu на борту.
Спрошу — почему MongoDB и напоролись ли на какие-то грабли?
Спрашиваю по причине того, что не так давно тоже приходилось столкнуться с выбором NoSQL базы. И выбор пал на MongoDB. Из неприятного отметили — долгое время для записи при репликасете уже из трех нод на одной девелопмент тачке(3-5 секунд), где нет нагрузки почти что никакой. Должен оговориться, что WriteConcern был выставлен в REPLICA_ACKNOWLEDGED. Но всеравно неприятное удивление.
Хорошо написал. Жизненно. В качестве маленькой заметки от себя могу добавить то, что по моему наблюдению мало кому удается удержаться в программистах кто пришел только из-за того, что зарплаты хорошие. Если не интересно то, чем ты занимаешься и не хочется совершенствоваться, то такие ребятки продолжают плодить джуниор код спустя Н лет работы. Далее они зачастую переходят в менеджеры или просто меняют сферу. Хотя есть и индивидуумы, которые 20+ лет пишут джуниор код. Но я только одно такое исключение знаю.
Идея мне в общем-то понравилась. Но есть один нюанс!
Скажем так, в вышеприведенных фрагментах кода есть к чему придраться — хотя бы к отсутствию отступов и способу расстановки скобок. Это все сливается во едино. Мне уже пришлось напрягать извилины для того, что бы понять, к какому ветвлению что относится. А это плохо.
Со сторонними либами не работает в случае отсутствия сорцов — с этим согласен. Но бОльшая часть библиотек на ура подтягивается через центральный мавен репозиторий с Eclipse/IntelliJ IDEA на ура. В случае с Ant тут конечно несколько больше проблем по подключению но в принципе можно подключить исходники по нужде. И кстати сторонние стабильные библиотеки довольно редко преходится дебажить. Мне например лишь единожды пришлось дебажить Spring Jdbc довольно глубоко что бы узнать о баге в нашем коде. Проблемы как правило как раз в коде не сторонних библиотек, а в коде написанным внутри конторы(прошу особенно отметить здесь «как правило» — ибо есть и ОЧЕНЬ глючные сторонние либы, это было в моей практике как правило редкость).
Ну вот не понимаю я — чего пристали к программистам? Вам нужно что бы они код писали качественно или что бы резюме вам красивые писали но при этом были посредственными специалистами? Большинство талантливых программистов, что я знал имели отвратительные резюме. Да, именно так — отвратительные — но были и есть классные специалисты.
К чему это я? Вы судите по обложке. Требуете от людей того, чего они не любят и не умеют — писать красивые резюме.
Уровень человека может оценить только другой квалифицированный программист на собеседовании. Да и то не всегда это удается сделать.
Даже если данный подход был бы признан неправильным/устаревшим наврядли Java избавится от метода finalize.
Это как с багом в базе данных Oracle — там пустая строка и null это одно и тоже. Баг смешной, но от него никто никогда не избавится по понятным причинам :)
P.S. И пример с кредитованием приведенный выше еще неизвестно как выльется через несколько лет. А все потому, что один из программистов не подумал заранее и позволил продолжить ехать с по его мнению «выключенной фарой», хотя на самом деле это были «сломаные тормоза».
Да. Но вы согласны, что при неудачном стечении обстоятельств(темная ночь, плохая видимость) эта негорящая фара может привести к аварии и с точки зрения безопасности было бы разумнее поменять фару?
Я думаю вы согласитесь в том, что тот факт, что вам в финализаторы пришлось логику пихать — это следствие толи низкой внимательности программистов, толи низкой квалификации программиста. В общем это следствие чьей-то ошибки. И это цена, которую пришлось вам заплатить за чью-то лень/неванимателность/тупость.
Факт того, что ваш парсер логов собирает ошибки и отправляет автоматически всем разработчикам на электронную почту — это и есть «кричать во все горло».
Я имел счастье саппортить систему написанную несколькими поколениями разработчиков. И знаете — насмотрелся на «код, который как-то работает». И в долгосрочной перспективе получается система, которая слабо поддается отладке.
Другой пример из моей практикой, схожий с вашим — есть калькулятор финансов, который выдает расчет работнику кредитования о кредитной истории в виде PDF документа. И вот тоже ошибка «логировалась» о том, что часть данных не удается загрузить с внешнего сервиса. Но это успешно проигнорировали. И так проработало пару недель, пока не заметили случайно на продакшне. За этот срок было выдано много кредитов. И неизвестно какой урон понесет фирма после такого в долгосрочной перспективе.
Так что в долгосрочной перспективе для фирмы лучше один раз получить по шапке за оплошность.
Моя практика показывает, что код работающий «хоть как-то» именно так и работает «хоть как-то». Вместо того, что бы сообщить явно и потратить пол дня на фиксинг этого бага — на последующий дебаг проблемы тратятся месяцы.
>> Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват.
Я с этим утверждением полностью согласен. Именно поэтому я придерживаюсь философии «Let it crash» — это позволяет узнать о проблеме намного раньше. Не работающий код должен кричать об этом во все горло, а не «тихо неправильно работать».
Вот ведь признайтесь — если код будет работать неправильно на продакшне — как скоро вы об этом узнаете? В случае «exception'a» я думаю к вам сразу прибегут. В случае логирования с уровнем «error» и продолжающей неправильно работать системе — к вам прибегут намного позже.
Так что на мой взгляд бОльшее зло позволять коду работать тихо неправильно.
>> из-за изменения в логике вкралась ошибка
Я понимаю, что такие ошибки очень неприятные, но я подобного типа проблемы стараюсь решать другими путями, если это возможно. Понятно, что есть когда «по-другому вообще никак». Но на самом-то деле если соединения «текут», то соответственно и производительность всей системы тоже падает.
Мне кажется, что это не правильно — усложнять свой код, что бы кто-то подобрать за кем-то. Тогда весь код нужно обвешать if'ами, который прощитывает все остальные невалидные инварианты помимо одного валидного(так называемая защита от дурака).
ИМХО Код должен работать только так, как он должен работать. В остальных случаях он должен либо падать либо работать не правильно. Если пишите либу — нужно писать об этом в Faq/туториале, том же Javadoc. Если человек не умеет/не хочет читать документацию/вики/туториал, то это его проблемы.
Ведь это и так достаточно нетривиальная задача — написать код который просто работает(как бы смешно это не звучало).
Спустя годы могу сказать, что в школе мозги тоже промывают нехило.
Лично меня обучение в школе не сделало гармоничноразвитой личностью.
Разве что пятая точка у меня стала несколько шире чем хотелось бы от долгово сидения над уроками.
Насчет «общей базы» — я с этим согласиться могу. Опять же знание частных случаев не освобождает от знания общего случая и наоборот.
В общем к чему это я? К тому что работать над собой нужно в правильном направлении, а не плыть по течению просиживая штаны потому что дядьки с длинными бородами сказали, что так надо. Ибо эти самые дядьки с длинными бородами сидят в универе за скажем так не сильно большую зарплату.
Стоит отметить, что это бежит на aws ec2. На «large» машине с Ubuntu на борту.
Спрошу — почему MongoDB и напоролись ли на какие-то грабли?
Спрашиваю по причине того, что не так давно тоже приходилось столкнуться с выбором NoSQL базы. И выбор пал на MongoDB. Из неприятного отметили — долгое время для записи при репликасете уже из трех нод на одной девелопмент тачке(3-5 секунд), где нет нагрузки почти что никакой. Должен оговориться, что WriteConcern был выставлен в REPLICA_ACKNOWLEDGED. Но всеравно неприятное удивление.
Скажем так, в вышеприведенных фрагментах кода есть к чему придраться — хотя бы к отсутствию отступов и способу расстановки скобок. Это все сливается во едино. Мне уже пришлось напрягать извилины для того, что бы понять, к какому ветвлению что относится. А это плохо.
P.S. Когда я был Juinior'ом я открыл для себя дебагер и step into и стал меньше донимать своих более опытных коллег без дела.
К чему это я? Вы судите по обложке. Требуете от людей того, чего они не любят и не умеют — писать красивые резюме.
Уровень человека может оценить только другой квалифицированный программист на собеседовании. Да и то не всегда это удается сделать.
Это как с багом в базе данных Oracle — там пустая строка и null это одно и тоже. Баг смешной, но от него никто никогда не избавится по понятным причинам :)
Я имел счастье саппортить систему написанную несколькими поколениями разработчиков. И знаете — насмотрелся на «код, который как-то работает». И в долгосрочной перспективе получается система, которая слабо поддается отладке.
Другой пример из моей практикой, схожий с вашим — есть калькулятор финансов, который выдает расчет работнику кредитования о кредитной истории в виде PDF документа. И вот тоже ошибка «логировалась» о том, что часть данных не удается загрузить с внешнего сервиса. Но это успешно проигнорировали. И так проработало пару недель, пока не заметили случайно на продакшне. За этот срок было выдано много кредитов. И неизвестно какой урон понесет фирма после такого в долгосрочной перспективе.
Так что в долгосрочной перспективе для фирмы лучше один раз получить по шапке за оплошность.
>> Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват.
Я с этим утверждением полностью согласен. Именно поэтому я придерживаюсь философии «Let it crash» — это позволяет узнать о проблеме намного раньше. Не работающий код должен кричать об этом во все горло, а не «тихо неправильно работать».
Вот ведь признайтесь — если код будет работать неправильно на продакшне — как скоро вы об этом узнаете? В случае «exception'a» я думаю к вам сразу прибегут. В случае логирования с уровнем «error» и продолжающей неправильно работать системе — к вам прибегут намного позже.
Так что на мой взгляд бОльшее зло позволять коду работать тихо неправильно.
>> из-за изменения в логике вкралась ошибка
Я понимаю, что такие ошибки очень неприятные, но я подобного типа проблемы стараюсь решать другими путями, если это возможно. Понятно, что есть когда «по-другому вообще никак». Но на самом-то деле если соединения «текут», то соответственно и производительность всей системы тоже падает.
ИМХО Код должен работать только так, как он должен работать. В остальных случаях он должен либо падать либо работать не правильно. Если пишите либу — нужно писать об этом в Faq/туториале, том же Javadoc. Если человек не умеет/не хочет читать документацию/вики/туториал, то это его проблемы.
Ведь это и так достаточно нетривиальная задача — написать код который просто работает(как бы смешно это не звучало).
Лично меня обучение в школе не сделало гармоничноразвитой личностью.
Разве что пятая точка у меня стала несколько шире чем хотелось бы от долгово сидения над уроками.
Насчет «общей базы» — я с этим согласиться могу. Опять же знание частных случаев не освобождает от знания общего случая и наоборот.
В общем к чему это я? К тому что работать над собой нужно в правильном направлении, а не плыть по течению просиживая штаны потому что дядьки с длинными бородами сказали, что так надо. Ибо эти самые дядьки с длинными бородами сидят в универе за скажем так не сильно большую зарплату.