Согласен. И дело даже не только в том, что "зачем нужна вся эта толпа в современной разработке". Дело в том, что например, ответ на вопрос, реализуемо ли требование, может выясниться именно в процессе разработки. И никак не раньше. И в моей практике достаточно типичным результатом разработки является скажем такой: "Мы это сделаем, вам это будет стоить столько-то, заказывайте сервера, столько-то штук, такой-то конфигурации. После чего заказчик отвечает: "Ну ок, я подумаю" - и как правило не возвращается. Или возвращается с еще одним потребителем той же фичи и двумя чемоданами денег.
Ну т.е. не только он не знает, можем ли мы создать - мы точно так же не знаем ответа на такой вопрос.
В итоге, SMART применительно к требованиям я бы назвал желательным свойством. Если они не такие, с ними зачастую тоже можно работать, и часть заказчиков готова оплачивать доработку требований до такого состояния.
Ну, есть такая штука, как Apache POI, это один из самых старых, и самых продвинутых пакетов поддержки форматов Офиса, помимо собственно COM. Так что выбор (одного из) языков для JVM - он в принципе-то вполне логичный.
А так да, я бы тоже начал писать на груви, а не на Java :) Ну или на скале. Не то чтобы на скриптовом языке в полном смысле этого слова, но на чуть более гибком, чем Java.
Простой парсер excel на java - это где-то 10 строк. Три вложенных цикла - по страницам .xls файла, строкам, колонкам. Плюс еще 10 строк - преобразование типов данных, кои бывают разные, в разные же типы базы. Плюс еще строк 10 - само сохранение.
Даже если я ошибаюсь в два раза - это не существенно, я такое реально делал раз десять за свою практику. Реально можно написать за час, не сильно напрягаясь. За день - если вы никогда этого не делали, тоже норм. И если вы на windows, и у вас есть доступ к COM объекту Excel, то на любом из языков с поддержкой COM, то еще чуть проще.
А вот если вы ко мне придете и попросите чтобы моя команда это написала (причем переносимое на линукс) - я тоже попрошу неделю срока. Потому что не знаю, кто именно будет писать, и как глубоко придется объяснить человеку суть дела, сколько времени уйдет на тестирование, и т.п. Иными словами - оценку вам выкатили совершенно адекватную. При мне начинающий java-программист писал такое месяц, и при этом все еще не закончил.
И я не сказал что велосипед хуже. У меня для этого просто нет данных. Я сказал, что велосипед вам тоже будет что-то стоить. Если вы сопоставимую цену просто заплатите позже, иногда даже это уже вполне можно считать плюсом.
Ну то есть, меня лично допустим смущает отказ от очередей - потому что у меня был опыт развертывания ActiveMQ за один день, и использования в проекте. Т.е. за день - все вместе, и оно уже заработало, вместе с кодом. Но не имея такого же опыта вы вполне можете принять и другое решение, просто потому, что не можете оценить сроки внедрения.
Опять же - у нас в большой компании можно просто зайти на портал заказа железок, и выбрать там из меню кафку, задать конфигурацию (использовав готовый калькулятор) - и завтра она уже работает. А в маленькой команде сначала еще и настроить придется.
Ну как-бы все имеет свою цену. Вы не использовали кафку или какое-то решение с очередями, назовем его условно MQ. Вместо этого вы сделали свой велосипед для асинхронного выполнения длительных задач. Никуда же не деться - длительные задачи нужно развязать от обработки коротких запросов. Ваш алгоритм вам тоже будет стоить денег - на сопровождение. Это не значит что условная кафка не стоила бы - это уже надо сравнивать.
Если у вас не было опыта с такими решениями - ну это тоже решение, работать с тем что умеешь. Особенно в маленькой команде. И у него свои недостатки и ограничения.
Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.
В том-то и дело. Вы не можете выкинуть планирование (спринта, или любого другого периода). Планирование все равно будет - другое дело, что оно будет например происходить в другое время и в другом месте. Например, в голове или на бумажке у тимлида. Но само по себе оно никуда не денется, или у вас будет бардак почище эджайла.
Тоже самое - демо. Вы конечно можете никому не показывать результаты своего релиза - но это в конечном счете отольется вам же лишней работой по сопровождению. Ваш заказчик должен видеть, что вы сделали. Это даже не столько реклама себя, любимого, сколько обучение потребителя, чтобы он понимал, какие новые фишки появились, какие проблемы решены.
Заставлять нас искать кусок про OSGI в довольно длинном видео - это садизм :)
Можете примерно сказать, на какой минуте про OSGI? Все прочие доклады что я видел на эту тему, страдали тем, что авторы не понимали OSGI с практической стороны, т.е. никогда не использовали в жизни. Чистые теоретики.
Вопрос не в том, прибегая или нет. Вопрос скорее в том, как проще. И ответ на него не всегда одинаковый. Скажем, я не встречал тех проблем, что автор тут описывает, зато например split package, когда один пакет определен в двух разных jar, это как правило геморрой с гарантией.
Но в большинстве классических случае использования зависимостей (и конфликтов в процессе) в OSGI контейнере выглядит как-то примерно так (у меня опыт работы с чистым karaf. Fuse и ServiceMix, они все основаны на карафе же):
загружаем в контейнер очередной наш модуль
выясняем, что он не стартует, потому что зависимости не разрешились - нет каких-то пакетов
выясняем, откуда эти пакеты
устанавливаем зависимости прямо из репозитория maven
обновляем наш компонент
И при этом нам как правило до лампочки, что одному нашему модулю нужна guava другой версии - мы их все можем загрузить.
То есть, по сути это выглядит как добавление зависимостей при сборке проекта в pom.xml или чем мы там собираем - только в рантайме.
Как раз OSGI упрощает этот процесс сильно. Другое дело, что не всегда это реально нужно. И не всегда можно. Иногда собрать fat.jar таки приходится, но сильно реже, чем если вы собираете простое spring приложение.
Когда HR начинает решать, что является ключевым при найме скажем программиста - я лично сделаю все возможное, чтобы просто исключить это звено из процесса.
Очень смешно. У меня уже третий проект на нем. Начиная с 2010 года я с маленькими перерывами на нем работаю. А судя по тому что ни одной статьи про OSGI у вас нет (в отличие от меня), то я вами и спорить не стану. Оставайтесь при своем мнении.
«Теоретические основы проектирования компиляторов» (авторы Ф.Льюис, Д.Розенкранц и Р.Стирнз)
Подпишусь. Аналогичное мнение об этой книге. Я по ней научился и написал LL(1) анализатор. И вообще, понял как в принципе писать компиляторы, и перестал считать эту задачу чем-то невозможным.
Ну будет, да. Но разница все равно очень велика, и я бы сказал, что именно вот эта разница - она как раз самая большая в моей практике. Он не будет спрашивать, как собрать проект - он как правило соберет сам. Он будет спрашивать предметную область, то есть ровно то, что сам узнать не может. Да и ту возможно прочитает - если есть где.
Синьор не будет отвлекать других, джун - будет непременно. На свою зарплату - скорее нет, но разгрузить команду для полезных дел, причем сразу - скорее да.
А я и не утверждал обратного. Я сказал бы, что синьор будет приносить пользу (на сравнительно простых задачах) довольно быстро, сильно быстрее миддла, и явно быстрее джуна, и с меньшей нагрузкой на старых членов команды. Т.е. сам разберется во многом. А сложное будет конечно пилить позже. И разница с миддлом и джуном в том, что эти двое сложное пилить возможно не будут никогда. Ну т.е. никогда - это значит в рамках этого проекта, в его плановые сроки - никогда не будут. Вырастут потом когда-то, лет через пять - сделают другое сложное что-то, но то будет другая история, и в общем-то другие уже люди.
А что тут такого? Я тоже помню что у меня есть в холодильнике :) Вот на какой оно полке - это другое, тут я могу запутаться...
Согласен. И дело даже не только в том, что "зачем нужна вся эта толпа в современной разработке". Дело в том, что например, ответ на вопрос, реализуемо ли требование, может выясниться именно в процессе разработки. И никак не раньше. И в моей практике достаточно типичным результатом разработки является скажем такой: "Мы это сделаем, вам это будет стоить столько-то, заказывайте сервера, столько-то штук, такой-то конфигурации. После чего заказчик отвечает: "Ну ок, я подумаю" - и как правило не возвращается. Или возвращается с еще одним потребителем той же фичи и двумя чемоданами денег.
Ну т.е. не только он не знает, можем ли мы создать - мы точно так же не знаем ответа на такой вопрос.
В итоге, SMART применительно к требованиям я бы назвал желательным свойством. Если они не такие, с ними зачастую тоже можно работать, и часть заказчиков готова оплачивать доработку требований до такого состояния.
Ну, есть такая штука, как Apache POI, это один из самых старых, и самых продвинутых пакетов поддержки форматов Офиса, помимо собственно COM. Так что выбор (одного из) языков для JVM - он в принципе-то вполне логичный.
А так да, я бы тоже начал писать на груви, а не на Java :) Ну или на скале. Не то чтобы на скриптовом языке в полном смысле этого слова, но на чуть более гибком, чем Java.
Простой парсер excel на java - это где-то 10 строк. Три вложенных цикла - по страницам .xls файла, строкам, колонкам. Плюс еще 10 строк - преобразование типов данных, кои бывают разные, в разные же типы базы. Плюс еще строк 10 - само сохранение.
Даже если я ошибаюсь в два раза - это не существенно, я такое реально делал раз десять за свою практику. Реально можно написать за час, не сильно напрягаясь. За день - если вы никогда этого не делали, тоже норм. И если вы на windows, и у вас есть доступ к COM объекту Excel, то на любом из языков с поддержкой COM, то еще чуть проще.
А вот если вы ко мне придете и попросите чтобы моя команда это написала (причем переносимое на линукс) - я тоже попрошу неделю срока. Потому что не знаю, кто именно будет писать, и как глубоко придется объяснить человеку суть дела, сколько времени уйдет на тестирование, и т.п. Иными словами - оценку вам выкатили совершенно адекватную. При мне начинающий java-программист писал такое месяц, и при этом все еще не закончил.
Это смотря где. Хотя вы правы - понимание того, сколько стоит такая активность есть далеко не всегда. И не у всех. Но встречается.
И я не сказал что велосипед хуже. У меня для этого просто нет данных. Я сказал, что велосипед вам тоже будет что-то стоить. Если вы сопоставимую цену просто заплатите позже, иногда даже это уже вполне можно считать плюсом.
Ну то есть, меня лично допустим смущает отказ от очередей - потому что у меня был опыт развертывания ActiveMQ за один день, и использования в проекте. Т.е. за день - все вместе, и оно уже заработало, вместе с кодом. Но не имея такого же опыта вы вполне можете принять и другое решение, просто потому, что не можете оценить сроки внедрения.
Опять же - у нас в большой компании можно просто зайти на портал заказа железок, и выбрать там из меню кафку, задать конфигурацию (использовав готовый калькулятор) - и завтра она уже работает. А в маленькой команде сначала еще и настроить придется.
Ну как-бы все имеет свою цену. Вы не использовали кафку или какое-то решение с очередями, назовем его условно MQ. Вместо этого вы сделали свой велосипед для асинхронного выполнения длительных задач. Никуда же не деться - длительные задачи нужно развязать от обработки коротких запросов. Ваш алгоритм вам тоже будет стоить денег - на сопровождение. Это не значит что условная кафка не стоила бы - это уже надо сравнивать.
Если у вас не было опыта с такими решениями - ну это тоже решение, работать с тем что умеешь. Особенно в маленькой команде. И у него свои недостатки и ограничения.
В том-то и дело. Вы не можете выкинуть планирование (спринта, или любого другого периода). Планирование все равно будет - другое дело, что оно будет например происходить в другое время и в другом месте. Например, в голове или на бумажке у тимлида. Но само по себе оно никуда не денется, или у вас будет бардак почище эджайла.
Тоже самое - демо. Вы конечно можете никому не показывать результаты своего релиза - но это в конечном счете отольется вам же лишней работой по сопровождению. Ваш заказчик должен видеть, что вы сделали. Это даже не столько реклама себя, любимого, сколько обучение потребителя, чтобы он понимал, какие новые фишки появились, какие проблемы решены.
Заставлять нас искать кусок про OSGI в довольно длинном видео - это садизм :)
Можете примерно сказать, на какой минуте про OSGI? Все прочие доклады что я видел на эту тему, страдали тем, что авторы не понимали OSGI с практической стороны, т.е. никогда не использовали в жизни. Чистые теоретики.
Вопрос не в том, прибегая или нет. Вопрос скорее в том, как проще. И ответ на него не всегда одинаковый. Скажем, я не встречал тех проблем, что автор тут описывает, зато например split package, когда один пакет определен в двух разных jar, это как правило геморрой с гарантией.
Но в большинстве классических случае использования зависимостей (и конфликтов в процессе) в OSGI контейнере выглядит как-то примерно так (у меня опыт работы с чистым karaf. Fuse и ServiceMix, они все основаны на карафе же):
загружаем в контейнер очередной наш модуль
выясняем, что он не стартует, потому что зависимости не разрешились - нет каких-то пакетов
выясняем, откуда эти пакеты
устанавливаем зависимости прямо из репозитория maven
обновляем наш компонент
И при этом нам как правило до лампочки, что одному нашему модулю нужна guava другой версии - мы их все можем загрузить.
То есть, по сути это выглядит как добавление зависимостей при сборке проекта в pom.xml или чем мы там собираем - только в рантайме.
Как раз OSGI упрощает этот процесс сильно. Другое дело, что не всегда это реально нужно. И не всегда можно. Иногда собрать fat.jar таки приходится, но сильно реже, чем если вы собираете простое spring приложение.
Когда HR начинает решать, что является ключевым при найме скажем программиста - я лично сделаю все возможное, чтобы просто исключить это звено из процесса.
Очень смешно. У меня уже третий проект на нем. Начиная с 2010 года я с маленькими перерывами на нем работаю. А судя по тому что ни одной статьи про OSGI у вас нет (в отличие от меня), то я вами и спорить не стану. Оставайтесь при своем мнении.
Karaf OSGi Runtime 4.4.5
January 10, 2024
Сказать что технология активно развивается - конечно соврать. Но "забили" в ситуации, когда последний релиз был вот только что - тоже соврать.
Автор, а зачем вы берете Felix в чистом виде? Есть же Karaf и Fuse. И ServiceMix. Там все сильно удобнее. Или я вас не так понял?
Подпишусь. Аналогичное мнение об этой книге. Я по ней научился и написал LL(1) анализатор. И вообще, понял как в принципе писать компиляторы, и перестал считать эту задачу чем-то невозможным.
Ну будет, да. Но разница все равно очень велика, и я бы сказал, что именно вот эта разница - она как раз самая большая в моей практике. Он не будет спрашивать, как собрать проект - он как правило соберет сам. Он будет спрашивать предметную область, то есть ровно то, что сам узнать не может. Да и ту возможно прочитает - если есть где.
От джуна будет убыток - он и сам ничего делать не сможет, и других отвлекать будет. Скорее всего - исключения конечно бывают.
Синьор не будет отвлекать других, джун - будет непременно. На свою зарплату - скорее нет, но разгрузить команду для полезных дел, причем сразу - скорее да.
А я и не утверждал обратного. Я сказал бы, что синьор будет приносить пользу (на сравнительно простых задачах) довольно быстро, сильно быстрее миддла, и явно быстрее джуна, и с меньшей нагрузкой на старых членов команды. Т.е. сам разберется во многом. А сложное будет конечно пилить позже. И разница с миддлом и джуном в том, что эти двое сложное пилить возможно не будут никогда. Ну т.е. никогда - это значит в рамках этого проекта, в его плановые сроки - никогда не будут. Вырастут потом когда-то, лет через пять - сделают другое сложное что-то, но то будет другая история, и в общем-то другие уже люди.