Спасибо за отзыв, я всегда стараюсь делать для себя выводы, но тем не менее хотелось бы уточнить несколько вещей:
Во первых тренинг начинался в 10 утра и заканчивался в 5 вечера. Даже если вычесть 45 минут на обед и ещё две дополнительные перемены по 15 минут, оно всё равно совсем не выходит 5 часов, а учитывая, что время обучения всегда считается в академических часах, то выходит 8 академических часов.
Во вторых, я считал практику очень важной частью тренинга, и поэтому на ВСЕХ моих тренингах много практики. На данном тренинге было одно задание на скале, одно задание на джаве, одно задание по датафрэймам и один финальный проект.
Так что и правда получается 4 задания. Однако каждое задание состояло из нескольких заданий (от 2 до 6) а финальный проект мы начали после обеда второго дня, и пилили до конца тренинга, с перерывами на общие вопросы и замечания-советы по проекту.
Поскольку проект до конца не допилили (что в принципе не было целью, целью было придти к точки от которой уже понятно, как доделать) я предложил всем желаюшим продолжить его допиливать дома. Более того, я сказал, что с удовольствием буду помогать и общаться по мэйлам. По-скольку моей целью было дать людям почувствавать что у них есть реальный опыт, а не голая теория подкрепленная кодом с тренинга.
И должен сказать, что некоторые люди воспользовались моим предложением, и проект мы докрутили до более серьёзного статуса.
По моим подсчётам общее количество часов практики этого тренинга никак не меньше 6.
Но в чём я согласен с Владиславом, так это в том, что финальный проект надо было давать не как одним заданием, а поделить его на куски.
Сегодня мне прислали очень позитивные отзывы такого же тренинга, который я проводил спустя два дня в Киеве:
Я всегда рад отзывам и коментариям, хотя немного удивляет, что отзыв Владислава не был ни высказан лично на тренинге или после,
Да, я в курсе, просто этот проект всплыл в контексте, а где ещё можно бы использывать Spark, и я хотел подчеркнуть как развивыется мир Spark-a для различных распределённых хранилищ
Я бы не очень доверял мнению человека, который использует Eclipse :)
А если серьёзно, меня раздирают противоречивые чувства. С одной стороны, да правильно, человеку надо двигаться вперед, но когда он достигает зоны комфорта, это желание пропадает. И всё происходит как у David Pollak-a, но если смотреть не с точки зрения человека, а с точки зрения компании, то время затрачиваемое на постоянное обучение, не всегда себя оправдывает в разработке. Потратить пару дней, чтобы выучить спринг бут, а потом экономить кучу времени при написании проектов это имеет смысл, с точки зрения энтерпрайза, а влкадывать месяцами в обучение Скалы, ради просто саморазвитие работника, это им вряд ли надо.
А я просто пытаюсь искать золотую середину. Вперед двигаться надо, поэтому спринг, спарк, и джава 8, со всеми её плюсами, где можно груви. А вот скала, это уж только если её знают изначально, но поскольку таких мало, то я лучше буду тратить время, чтобы улучшить мир джавы.
Вы ещё до сих пор пытаетесь найти преимущества у TestNG, вместо того, чтобы пользоваться Споком? Тогда мы идём к вам.
Всё что сказано в данной статье относительно преимуществ TestNG над JUnit-ом — абсолютно справедливо, но сегодня в этом полностью отпадает необходимость, потому как есть более удобные и новые вещи. DataDriven тесты НАМНОГО удобней делать на споке, а главное это даёт возможность хотя бы тесты писать на груви.
Будет время напишу статью, пока опубликую видео своего доклада с JEConfa, как только его зальют.
Вы совершенно правы, это таки был джоб кварца, который обращался к вебсервису, и время от времени обновлял данные для БД. Если вебсервис сдох, то обновлять все равно было нечего и приложение могло работать против существующих данных.
Я согласен, что такое вообще не должно случаться в продакшне, но увы и ах, есть компании которые выкатывают новые версии каждую неделю и некоторые проблемы приходится решать вот таким образом.
Но этот пример является очень крайним. Это не пример того, как надо работать, а пример какие плюсы могут быть у конфигурации, которую можно менять без перекомпиляции.
И есть компании, которым такая функциональность полезна, не потому что они так пытаются решать проблемы, а потому что хотят иметь возможность максимально быстро перекастомизировать продукт не прогоняя билд. Такая стратегия подрозумевают целую эко систему заточенную под это и многим это просто необходимо.
А вот насчет XML-ей я согласен, сегодня в них надобность отпадает. То мизирное количество конфигураций, которые требуют динамизма, можно выкинуть в груви. Но это уж, кто как любит.
Основная масса пока останется в джава конфигурации, с этим я тоже не спорю.
Случайно вписать логику звучит круто. Хотя я знал одного умельца, который случайно логику умудрялся и в XML вписать при помощи SpEL-a. А поскольку XML-ов на то время у нас было много, мы потом неделями его баги выискивали.
Вы когда нибудь пробовали дебажить SpEL прописанный в XML-e?
С груви в этом будет проще.
Хотя настоящую гарантию от «умельцев» может дать только пистолет.
Дело не в том, как часто падает, дело в том, что альтернатива была ехать в пятницу ночью обратно на работу. И ради того, что бы не ехать можно и не такое вспомнить. :)
Отличная статья, спасибо автору! Возник такой вопрос, а можно ли для улучшение перформенса настроить Mongo так, чтобы все чунга чанги хринились не на диске а в оперативной памяти, как это например сделано в XAP. Ведь при правильно настроенных репликациях данные пропасть не должны. Зато производительность должна вырости неумоверно.
парни, мне тут к докладу готовиться, так что на остальные вопросы отвечу в воскресенье.
Вы лучше на JUG приходите — вживую поговорим. Остальным будет линк.
Горлышко бутылки в первую очередь была БД.
И добавлять еще инстансов проблему не решает. Оракл не рекомендует больше чем 16 инстансов — там дальше на их синхронизацию и локи будет больше тратиться времени чем то что можно будет выиграть. И решать проблему приходится аппликативно. То есть делать много разных схем и разбрасывать данные по машинам, что в принципе XAP дает out of the box. С той только разницой что оперативка еще и намного быстрее работает чем БД. И нет никакого ограничение сколько инстансов может быть.
А какая альтернатива?
Оперативка может и не экспоненциально дешевеет, но она в любом случае дешевле чем БД.
Понятно что можно взять бесплатную БД и тогда выйдет дешевле, причем существенно, так как жесткий диск дешевле оперативки.
Но мы же говорим про огромнные массивы данных. А тут каким нибудь дерби не отделаешься, а покупать у оракла лизенцию и саппорт выйдет намного дороже оперативки.
Запись будет, JUG в этом году очень качественный, и запись будет на высоком уровне, по крайней мере так мне обещали :)
Как только ее зальют, я скину линк.
На счет продолжение статей про XAP, если будет время с удовольствием напишу еще, скажите только в каком направлении писать.
Во первых тренинг начинался в 10 утра и заканчивался в 5 вечера. Даже если вычесть 45 минут на обед и ещё две дополнительные перемены по 15 минут, оно всё равно совсем не выходит 5 часов, а учитывая, что время обучения всегда считается в академических часах, то выходит 8 академических часов.
Во вторых, я считал практику очень важной частью тренинга, и поэтому на ВСЕХ моих тренингах много практики. На данном тренинге было одно задание на скале, одно задание на джаве, одно задание по датафрэймам и один финальный проект.
Так что и правда получается 4 задания. Однако каждое задание состояло из нескольких заданий (от 2 до 6) а финальный проект мы начали после обеда второго дня, и пилили до конца тренинга, с перерывами на общие вопросы и замечания-советы по проекту.
Поскольку проект до конца не допилили (что в принципе не было целью, целью было придти к точки от которой уже понятно, как доделать) я предложил всем желаюшим продолжить его допиливать дома. Более того, я сказал, что с удовольствием буду помогать и общаться по мэйлам. По-скольку моей целью было дать людям почувствавать что у них есть реальный опыт, а не голая теория подкрепленная кодом с тренинга.
И должен сказать, что некоторые люди воспользовались моим предложением, и проект мы докрутили до более серьёзного статуса.
По моим подсчётам общее количество часов практики этого тренинга никак не меньше 6.
Но в чём я согласен с Владиславом, так это в том, что финальный проект надо было давать не как одним заданием, а поделить его на куски.
Сегодня мне прислали очень позитивные отзывы такого же тренинга, который я проводил спустя два дня в Киеве:
Я всегда рад отзывам и коментариям, хотя немного удивляет, что отзыв Владислава не был ни высказан лично на тренинге или после,
А если серьёзно, меня раздирают противоречивые чувства. С одной стороны, да правильно, человеку надо двигаться вперед, но когда он достигает зоны комфорта, это желание пропадает. И всё происходит как у David Pollak-a, но если смотреть не с точки зрения человека, а с точки зрения компании, то время затрачиваемое на постоянное обучение, не всегда себя оправдывает в разработке. Потратить пару дней, чтобы выучить спринг бут, а потом экономить кучу времени при написании проектов это имеет смысл, с точки зрения энтерпрайза, а влкадывать месяцами в обучение Скалы, ради просто саморазвитие работника, это им вряд ли надо.
А я просто пытаюсь искать золотую середину. Вперед двигаться надо, поэтому спринг, спарк, и джава 8, со всеми её плюсами, где можно груви. А вот скала, это уж только если её знают изначально, но поскольку таких мало, то я лучше буду тратить время, чтобы улучшить мир джавы.
Всё что сказано в данной статье относительно преимуществ TestNG над JUnit-ом — абсолютно справедливо, но сегодня в этом полностью отпадает необходимость, потому как есть более удобные и новые вещи. DataDriven тесты НАМНОГО удобней делать на споке, а главное это даёт возможность хотя бы тесты писать на груви.
Будет время напишу статью, пока опубликую видео своего доклада с JEConfa, как только его зальют.
Или читайте в первоисточнике: здесь
Я согласен, что такое вообще не должно случаться в продакшне, но увы и ах, есть компании которые выкатывают новые версии каждую неделю и некоторые проблемы приходится решать вот таким образом.
Но этот пример является очень крайним. Это не пример того, как надо работать, а пример какие плюсы могут быть у конфигурации, которую можно менять без перекомпиляции.
И есть компании, которым такая функциональность полезна, не потому что они так пытаются решать проблемы, а потому что хотят иметь возможность максимально быстро перекастомизировать продукт не прогоняя билд. Такая стратегия подрозумевают целую эко систему заточенную под это и многим это просто необходимо.
А вот насчет XML-ей я согласен, сегодня в них надобность отпадает. То мизирное количество конфигураций, которые требуют динамизма, можно выкинуть в груви. Но это уж, кто как любит.
Основная масса пока останется в джава конфигурации, с этим я тоже не спорю.
Вы когда нибудь пробовали дебажить SpEL прописанный в XML-e?
С груви в этом будет проще.
Хотя настоящую гарантию от «умельцев» может дать только пистолет.
Кстати а почему NetBeans?
Вот он: www.youtube.com/watch?v=a-ArgBL5WhA
Вы лучше на JUG приходите — вживую поговорим. Остальным будет линк.
И добавлять еще инстансов проблему не решает. Оракл не рекомендует больше чем 16 инстансов — там дальше на их синхронизацию и локи будет больше тратиться времени чем то что можно будет выиграть. И решать проблему приходится аппликативно. То есть делать много разных схем и разбрасывать данные по машинам, что в принципе XAP дает out of the box. С той только разницой что оперативка еще и намного быстрее работает чем БД. И нет никакого ограничение сколько инстансов может быть.
Оперативка может и не экспоненциально дешевеет, но она в любом случае дешевле чем БД.
Понятно что можно взять бесплатную БД и тогда выйдет дешевле, причем существенно, так как жесткий диск дешевле оперативки.
Но мы же говорим про огромнные массивы данных. А тут каким нибудь дерби не отделаешься, а покупать у оракла лизенцию и саппорт выйдет намного дороже оперативки.
Как только ее зальют, я скину линк.
На счет продолжение статей про XAP, если будет время с удовольствием напишу еще, скажите только в каком направлении писать.