Многие студенты не годны даже после обучения, так они не были годны и до обучения. Можно сказать, институт как раз наоборот отсеивает всех способных, и остаются лишь не способные. Уже умеющие программировать не хотят тратить время на обучение в одной компании с теми для кого и hello, world проблема.
В приведенном приложении так и сделано Js/css компилируется и сжимается только в случае боевого использования. Во время разработки файлы только линкуются, чтобы не было проблем с подключением страницы.
И как раз-таки настройка Teamcity, добавление профилей и прочие мелочи не позволят уложиться в 15 минут на запуск.
Кстати почему JSP?
Не хватило времени разобраться в разных шаблонизаторах. Хотелось один раз сгенирировать страницы, сложить в статичные ресурсы, а дальше лишь обрабатывать данные.
Я бы поспорил с развертыванием приложения за 15 минут. Проблемы возникнут уже на стадии подготовки базы данных, простого решения разделить sql скриптов на две группы (одна для всех, другая только для разработки) я не вижу. С локализацией тоже есть вопросы — не генировать же страницы из jsp каждый раз при запросе? Компиляцию javascript/css тоже придется прикручивать. Но возможно стоило все-же использовать Spring Boot.
По поводу xml — это вопрос предпочтений. Мне лично кажутся немного странными классы в которых почти нет логики, зато куча параметров. И xml и java код не являются в данном случае идеальными.
Например вы ожидали, что ошибка будет в этом месте, добавили вывод, посмотрели результат, а там все нормально и на самом деле ошибка скрывается где-то ниже по коду. Придется двигаться дальше и смотреть.
Я и имел в виду hot deploy со специально предназначенными для этого инструментами…
Специально преднозначеный инструмент это дебагер. Он позволяет не только посмотреть содержимое переменных. Но и узнать стек вызова, поменять прямо в рантайме значение некоторых переменных, выполнить произвольный код, заморозить на время процесс и еще многое другое. При отладке через print все это делать гораздо неудобней.
Если вы так хотите несмотря ни на что вызывать метод у любого объекта, то используйте рефлексию. Чем она вас не устраивает?
А нормальный способ это создать общий интерфейс
Тип мы и так известен — IExecutable. На объект наложен четкий контракт, что он должен быть исполняемым. Если уж вы так хотите исполнить метод у объекта который данный контракт не поддерживает, то не удивляйтесь что это приходиться делать через рефлексию.
Да и даже если использовать hot deploy на java — мороки куча. Промахнулся со строчкой — добавляй код и заново вызывай метод. Лучше уж использовать специально предназначенный инструмент.
Неправда в самой популярной ide «Блокнот» дебагера по умолчанию нет.
Типичные используемые для статических типизированных языков ide уже довольно зрелые продукты с большой функциональностью.
Всякие же небольшие редакторы Javascript полагают, что в случае необходимости отладку будут производить в браузере, а не в ide.
В конце-концов использование чего-нибудь вроде JavaScript для создания гигантских приложений приведет к тому, что появится среда разработки которая будет достаточно подробно анализировать код, чтобы выявлять все эти неявные контракты, знать какие на самом деле методы и переменные есть в конкретный момент у данной переменной и явно указывать на данные ошибки.
Но это по-факту приведет к тому, что мы сделаем JavaScript типизированным языком, просто типы будут прикручены грубыми костылями.
Есть большое подозрение, что типичные написанные на динамических и интерпретируемых языках программы гораздо меньше и проще устроенные. Сравните поиск ошибки в каком-нибудь рендеринг страницы, где число задействованных переменных и методов редко переваливает за два-три десятка и отладку какого-нибудь внутри системного компонента.
Надо просто объявить общий интерфейс IExecutable с единственным методом Execute(), а IProgram, IAction унаследовать от него. Так полностью соблюдается логика использования языка — контракт должен быть явно прописан.
Попытки же вызвать у любого объекта метод с просто совпадающим названием — это потенциальная ошибка. Название может совпадать у принципиально разных и несовместимых методов. Явно определение всего стремиться минимизировать число таких слепых вызовов. Если уж вы точно знаете, что делаете то используйте рефлексию, но это явно не типичная ситуация.
Интересно, сильно они потеряют в деньгах, если многие станут подписываться на тариф без рекламы...?
А может наоборот приобретут в деньгах? Пользователи же платят деньги за просмотр конкретных роликов и часть этой платы пойдет авторам.
И вообще хотелось бы подобного аналога для всего интернета. Платишь x $ в месяц и лазаешь по сайтам без рекламы. Владельцам сайта в конце месяца приходит сумма пропорциональная проведенному на их сайте времени. Пользователям удобно, так как не надо смотреть рекламу. Владельцам сайта тоже удобно — можно сосредоточиться на главном качестве и удобстве использования, а не пытаться выдумывать сценарии при которых пользователей больше времени просмотрит рекламу.
Вообще удивительно как такая неудобная вещь как skype стала стандартом. И главное со временем становиться только хуже. Была например возможность локально переименовать группы, но ее удалили. Приходиться теперь пользоваться внутренними малопонятными названиями проектов со стороны заказчика.
В scala ровно те же проблемы с дженериками, что и java. И scala используется гораздо реже.
Учитывая как бизнес быстро переходит хотя бы с 6 на 7, то ломание совместимости не очень бы сильно и замедлило динамику. Так как старые проекты очень редко переводят на новую платформу и основной приток идет за счет новых проектов.
Есть вещи которые трудно исправить сторонними библиотеками. Например половинчатая система дженериков.
C# очень быстро развивался, так как просто позволял себе ломать обратную совместимость и быстро выкинул из себя не очень удобные решения. А вот java тянет с собой старый код, а вместе и кучу проблем.
И как раз-таки настройка Teamcity, добавление профилей и прочие мелочи не позволят уложиться в 15 минут на запуск.
Не хватило времени разобраться в разных шаблонизаторах. Хотелось один раз сгенирировать страницы, сложить в статичные ресурсы, а дальше лишь обрабатывать данные.
По поводу xml — это вопрос предпочтений. Мне лично кажутся немного странными классы в которых почти нет логики, зато куча параметров. И xml и java код не являются в данном случае идеальными.
Например вы ожидали, что ошибка будет в этом месте, добавили вывод, посмотрели результат, а там все нормально и на самом деле ошибка скрывается где-то ниже по коду. Придется двигаться дальше и смотреть.
Специально преднозначеный инструмент это дебагер. Он позволяет не только посмотреть содержимое переменных. Но и узнать стек вызова, поменять прямо в рантайме значение некоторых переменных, выполнить произвольный код, заморозить на время процесс и еще многое другое. При отладке через print все это делать гораздо неудобней.
Как-то не очень им удается. Простой пример
На последней строчке idea говорит, что у переменной есть функции как и foo, так и bar. Хотя на самом деле только bar.
А нормальный способ это создать общий интерфейс
Да и даже если использовать hot deploy на java — мороки куча. Промахнулся со строчкой — добавляй код и заново вызывай метод. Лучше уж использовать специально предназначенный инструмент.
Неправда в самой популярной ide «Блокнот» дебагера по умолчанию нет.Типичные используемые для статических типизированных языков ide уже довольно зрелые продукты с большой функциональностью.
Всякие же небольшие редакторы Javascript полагают, что в случае необходимости отладку будут производить в браузере, а не в ide.
Есть небольшое подозрение, что занимающиеся дебагом кода использовали дебагер, а не отлаживались с помощью print или allert.
Но это по-факту приведет к тому, что мы сделаем JavaScript типизированным языком, просто типы будут прикручены грубыми костылями.
Попытки же вызвать у любого объекта метод с просто совпадающим названием — это потенциальная ошибка. Название может совпадать у принципиально разных и несовместимых методов. Явно определение всего стремиться минимизировать число таких слепых вызовов. Если уж вы точно знаете, что делаете то используйте рефлексию, но это явно не типичная ситуация.
А может наоборот приобретут в деньгах? Пользователи же платят деньги за просмотр конкретных роликов и часть этой платы пойдет авторам.
И вообще хотелось бы подобного аналога для всего интернета. Платишь x $ в месяц и лазаешь по сайтам без рекламы. Владельцам сайта в конце месяца приходит сумма пропорциональная проведенному на их сайте времени. Пользователям удобно, так как не надо смотреть рекламу. Владельцам сайта тоже удобно — можно сосредоточиться на главном качестве и удобстве использования, а не пытаться выдумывать сценарии при которых пользователей больше времени просмотрит рекламу.
Учитывая как бизнес быстро переходит хотя бы с 6 на 7, то ломание совместимости не очень бы сильно и замедлило динамику. Так как старые проекты очень редко переводят на новую платформу и основной приток идет за счет новых проектов.
C# очень быстро развивался, так как просто позволял себе ломать обратную совместимость и быстро выкинул из себя не очень удобные решения. А вот java тянет с собой старый код, а вместе и кучу проблем.