Comments 61
продолжим?
Глупость
Использовали собственные реализации очередей и семафоров
Следствие
Потраченное время, сложный код, ошибки собственных реализаций
Что я должен был сделать
Убедить в необходимости миграции на Java 5, использовать соответствующие классы из Collection API и java.util.concurrency
Глупость
Использовали собственные реализации очередей и семафоров
Следствие
Потраченное время, сложный код, ошибки собственных реализаций
Что я должен был сделать
Убедить в необходимости миграции на Java 5, использовать соответствующие классы из Collection API и java.util.concurrency
Глупость
Интеграция новых фич, забыв о рефакторинге старого кода
Следствие
Сложный код, который не поддается никаким изменениям
Что я должен был сделать
Использовать TDD + рефакторинг на ранних стадиях проета
Интеграция новых фич, забыв о рефакторинге старого кода
Следствие
Сложный код, который не поддается никаким изменениям
Что я должен был сделать
Использовать TDD + рефакторинг на ранних стадиях проета
Это целый класс клупостей — делать свой велосипед и не пользовать хорошо известную библиотеку.
Глупость
Храним библиотеки, в том числе открытые, в SVN
Следствие
Сложная процедура обновления конкретной библиотеки, особенно если она имеет зависимости. Большой трафик к серверу
Что я должен был сделать
Использовать maven
Храним библиотеки, в том числе открытые, в SVN
Следствие
Сложная процедура обновления конкретной библиотеки, особенно если она имеет зависимости. Большой трафик к серверу
Что я должен был сделать
Использовать maven
Очень интересный топик — посоветовал всей команде хоть и на php пишем. :)
Можно этот пункт раскрыть?
Как система билдов поможет с библиотеками? Все равно в проекте используется определенная версия в каждый момент времени? значит ее надо где то хранить. Или вы предлагаете при билде тянуть версию библы из чужого репозитория?
А что делать когда библиотеку приходиться патчить? да лучше до этого не доводить, но иногда приходиться…
Можно этот пункт раскрыть?
Как система билдов поможет с библиотеками? Все равно в проекте используется определенная версия в каждый момент времени? значит ее надо где то хранить. Или вы предлагаете при билде тянуть версию библы из чужого репозитория?
А что делать когда библиотеку приходиться патчить? да лучше до этого не доводить, но иногда приходиться…
Именно так. Библиотеки скачиваются из публичных репозиторев. Однако mvn аккуратно и очень педантично сохраняет всё скаченное локально. Поэтому можно относительно не бояться — два раза одну версии одной библиотеки в общем случае качать не придётся.
Сами зависимости объявляются в xml-файле, а файл находится под контролем версий. Поэтому если вы использовали допустим версию 1.3, а вдруг решили обновиться — вы просто правите цифру в xml-файле — 1.4. Теперь билд будет использовать новую версию.
Сами зависимости объявляются в xml-файле, а файл находится под контролем версий. Поэтому если вы использовали допустим версию 1.3, а вдруг решили обновиться — вы просто правите цифру в xml-файле — 1.4. Теперь билд будет использовать новую версию.
«два раза одну версии одной библиотеки в общем случае качать не придётся» — сколько проектов у вас не было б. копии сохраняются в win — «C:\Documents and Settings\user\.m2\»
Я бы добавил еще возмодность использования промежуточных репозитрориев уровня команды (Apache Archiva, Artifactory). Тогда скачивать придется один раз на команду, да и свои артефакты там держать удобно.
хотя у меня на маке был момент с тем, что запуск мавена с коммандной строки и с IDEA приводил к созданию 2 репозиториев. Решилось путем настройки всего, что связано с мавеном, но на маке с мавеном стоить быть осторожным :)
а на компьютере девелопера данную библиотеку кто обновлять будет? или у всех стоит клиент от maven?
Поддерживаю!
Кроме того maven может помочь избежать таких глупостей как:
1. Отыскивание и разрешение зависимостей вручную.
2. Написание и поддержка длинных ant скриптов для сборки, деплоя и тестирования проекта (вообзе имхо, так что фанаты ant'a не ругайтесь :) )
3. Создание тега в source control для стабильных версий кода.
4. Много еще чего.
Кроме того maven может помочь избежать таких глупостей как:
1. Отыскивание и разрешение зависимостей вручную.
2. Написание и поддержка длинных ant скриптов для сборки, деплоя и тестирования проекта (вообзе имхо, так что фанаты ant'a не ругайтесь :) )
3. Создание тега в source control для стабильных версий кода.
4. Много еще чего.
Or use Ant+Ivy
Глупость
Вести всю работу с кодом в trunk репозитория, не заботиться об управлении конфигурациями
Следствие
Невозможность в нужный момент собрать необходимый релиз; невозможно править и коммитить несколько багов одновременно
Ч я д б с
Получше освоить корректное управлении исходными кодами (например, здесь, применить на практике паттерны управления версиями www.scmpatterns.com
Вести всю работу с кодом в trunk репозитория, не заботиться об управлении конфигурациями
Следствие
Невозможность в нужный момент собрать необходимый релиз; невозможно править и коммитить несколько багов одновременно
Ч я д б с
Получше освоить корректное управлении исходными кодами (например, здесь, применить на практике паттерны управления версиями www.scmpatterns.com
у меня таких глупостей под 100 штук наберется, но главное делать своевременно выводы и двигаться вперед… главное — вперед. не боятся изучать новое и пробовать новые концепции.
scalability переводится, как правило, как «расширяемость» или «масштабируемость».
Исповедь говнокодера, вставшего на путь истинный.
Исповедь говнокодера, вставшего на путь истинный.
Глупость
Использовать константы для вывода i18n надписей
Следствие
Фоллбэк затруднен, а кое где невозможен,
Фраза должна добавляться сразу во все локализации,
Не отследишь непереведенные фразы,
Усложняет жизнь переводчика знаниями о кавычках и т.п.,
Сложно найти код, который выводит нужную фразу
Что делать
Юзать gettext на худой конец
Использовать константы для вывода i18n надписей
Следствие
Фоллбэк затруднен, а кое где невозможен,
Фраза должна добавляться сразу во все локализации,
Не отследишь непереведенные фразы,
Усложняет жизнь переводчика знаниями о кавычках и т.п.,
Сложно найти код, который выводит нужную фразу
Что делать
Юзать gettext на худой конец
Глупость: пишу собственную реализацию event-management модели на java.
Следствие: не знаю как её применить.
Что делать: не страдать фигнёй :(
Следствие: не знаю как её применить.
Что делать: не страдать фигнёй :(
без ошибок и набивания шишек не понять смысла умных вещей. Уж лучше самому изобрести велосипеды чтобы лучше понимать зачем нужные чужие и готовые — а не бездумно пользоваться результатами чужого труда.
Честно говоря, IDE — глупость номер 0. Минус один. Вселенская глупость!
// добавьте Idea, пожалуйста. Штука очень мощная и безусловно окупается.
// добавьте Idea, пожалуйста. Штука очень мощная и безусловно окупается.
Глупо верил в существование «серебрянных пуль» компьютерной науки.
Повзрослел. Теперь отношусь терпимее к своему и чужому говнокоду
Повзрослел. Теперь отношусь терпимее к своему и чужому говнокоду
Да и вообще нужно было Grails использовать вместо всей этой разрозненной ботвы.
Скажите, а сколько времени ушло на написание этого «велосипеда» и его отладку, сколько еще уйдет на добавление новых фич при необходимости. Автор говорит о том, что лучше использовать готовое решение если оно уже давно написано и работает как надо. По моему нужно иметь очень веские основания, чтобы писать свою orm, когда есть монстры вроде hibernate.
Мне интересно — есть ли какие ORM системы для php
Мда. А всего-то стоило заюзать что-то из пункта 1 и проблемы 3, 5, 6 сразу отпали бы.
хм, я как дилетант, думал, что для DB connection pool надо просто юзать appllication servers, в которых это уже есть
Одна из самых глупый вещей, которая не позволяет оглядываться назад и пересматривать себя со стороны — это отношение к критике.
Глупость
Не принимал критику кода/решений — взрывался, отрицал, начинал оправдываться. Очень резко относился к любому вмешательству в свой код.
Следствие
Заблуждения, конфликты с коллегами, «допотопность» — не использовал кругозор других.
Что я должен был сделать
Прислушаться к критике, самому на нее нарываться. Потому что люди, критикующие или сообщающие тебе об ошибке — чаще всего, делают тебе хорошую услугу. Обсуждая свой код, свои решения — мы учимся, находим правильные решения, ведь спор заставляет нас думать, аргументировать наши поступки. Понимание этого вкупе с терпимостью :-) и позволяет легко учиться на своих ошибках.
Глупость
Не принимал критику кода/решений — взрывался, отрицал, начинал оправдываться. Очень резко относился к любому вмешательству в свой код.
Следствие
Заблуждения, конфликты с коллегами, «допотопность» — не использовал кругозор других.
Что я должен был сделать
Прислушаться к критике, самому на нее нарываться. Потому что люди, критикующие или сообщающие тебе об ошибке — чаще всего, делают тебе хорошую услугу. Обсуждая свой код, свои решения — мы учимся, находим правильные решения, ведь спор заставляет нас думать, аргументировать наши поступки. Понимание этого вкупе с терпимостью :-) и позволяет легко учиться на своих ошибках.
Сделал 1-3 на C# :)
Как-то работает, конечно, но сейчас бы так уже делать не стал.
Как-то работает, конечно, но сейчас бы так уже делать не стал.
Глупость
Изобрел велосипед.
Следствие
Все работает медленно, находятся новые баги.
Что я должен был сделать
Воспользоваться Java API, а не изобретать велосипед.
Изобрел велосипед.
Следствие
Все работает медленно, находятся новые баги.
Что я должен был сделать
Воспользоваться Java API, а не изобретать велосипед.
а помоему все это жутко полезно, сталкиваться с проблемами, даже изобретая свой велосипед — это самый лучшии опыт.
Ну по поводу пунктов про ORM, EAV и IDE я бы поспорил.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
Правка имеющихся ORM без внесения этих изменений в транк библиотеки — это ещё одна глупая вещь. Я не представляю, как вы будете писать «свой Hibernate». Это было бы очень и очень глупо. Написание своей ORM могут себе позволить только очень крупные компании, понимающие почему им не подходят конкретные библиотеки, даже после допилки.
Про IDE. Eclipse очень хорошо пилится и дополняется плагинами. Единственный его недостаток — скорость работы и требуемая память.
Про IDE. Eclipse очень хорошо пилится и дополняется плагинами. Единственный его недостаток — скорость работы и требуемая память.
Кстати, не подскажите, какие подходы к кэшированию EAV и обеспечению когерентности популярны/распространены?
Если из вопроса убрать слова 'популярны/распространены' (не обладаю достаточными данными чтобы отвечать именно на это), то…
* Кеширование EAV?
Самое первое решение, что приходит обычно в голову, это возврат к модели преставления данных, проблемы которой оно и решает, т.е. создание таблиц с полями — соответствующих элементам из EAV. Само собой только для тех атрибутов, доступ к данным которых — узкое место.
EAV: prop(id,name)={1: это,2: то,3: тому,4: того,...}, object(id,...), values(id,object_id,prop_id,data)
Кэш: cache(object_id,prop1,prop2,prop3)
Плюсы: облегчает задание сложных ограничений целостности (constraint на кэш), увеличивает скорость доступа к значениям пропертей (индексы на propX у кэша)
Минусы: неполная транзакционность (изменение prop, да еще внутри тригеров — кошмар), вроде нет БД предоставляющих транзакции на команды DDL, меняет подход к построению SQL запросов и ограничивает/усложняет удаление элементов из prop.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
* Кеширование EAV?
Самое первое решение, что приходит обычно в голову, это возврат к модели преставления данных, проблемы которой оно и решает, т.е. создание таблиц с полями — соответствующих элементам из EAV. Само собой только для тех атрибутов, доступ к данным которых — узкое место.
EAV: prop(id,name)={1: это,2: то,3: тому,4: того,...}, object(id,...), values(id,object_id,prop_id,data)
Кэш: cache(object_id,prop1,prop2,prop3)
Плюсы: облегчает задание сложных ограничений целостности (constraint на кэш), увеличивает скорость доступа к значениям пропертей (индексы на propX у кэша)
Минусы: неполная транзакционность (изменение prop, да еще внутри тригеров — кошмар), вроде нет БД предоставляющих транзакции на команды DDL, меняет подход к построению SQL запросов и ограничивает/усложняет удаление элементов из prop.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
Т.е. кэш заранее делается на определённый состав пропертей (и, соответственно, под определённый класс запросов)? Просто интересно, может для этого есть какие-нибудь невелосипедные библиотечки/наработки. Это в частности, интересно, т.к. некоторые игроки предлагают key-value базы данных и было бы неплохо производить какие-нибудь простенькие операции с ними на стороне клиентов в семантике SQL.
Я так понимаю, что оригинальный жалующийся автор (Ioannis Cherouvim) как раз и реализовал в своём самописном ORM какую-то извратную обёртку вокруг EAV. Из-за этого велосипеда (а также из-за замены продумывания схемы БД кажущимся ему «серебрянной пулей» EAVом) он и получил фэйл…
Я так понимаю, что оригинальный жалующийся автор (Ioannis Cherouvim) как раз и реализовал в своём самописном ORM какую-то извратную обёртку вокруг EAV. Из-за этого велосипеда (а также из-за замены продумывания схемы БД кажущимся ему «серебрянной пулей» EAVом) он и получил фэйл…
При создании оберток нужно не забывать что обертка делается для человека а не наоборот.
Не следует запрещать самому себе все и вся, это вредно — именно это обычно порождает проблемы.
P.S. Производительность практически всегда приносится в жертву удобству, и наоборот. Если видите что система получается слишком сложной (взаимозависимости технологий друг от друга большое), лучше остановиться и прекратить решать как еще извратиться чтобы получить результат (анекдот про программиста и чайник помните?). Лучше написать своё.
Не следует запрещать самому себе все и вся, это вредно — именно это обычно порождает проблемы.
P.S. Производительность практически всегда приносится в жертву удобству, и наоборот. Если видите что система получается слишком сложной (взаимозависимости технологий друг от друга большое), лучше остановиться и прекратить решать как еще извратиться чтобы получить результат (анекдот про программиста и чайник помните?). Лучше написать своё.
Кэш делается после анализа узких мест (которые можно и заранее предугадать кстати), само собой запросы должны будут переписаны под использование этого кэша (у нас это было легко сделать, даже с учетом дрянной реализации и временных наслоений кэш заменил собой вьюху, которую oracle не очень хотел оптимально разворачивать в запросах, хотя у нас и специалиста как такового не было).
Собственные интерфейсы мониторинга и управления вместо JMX.
Сервера приложений там, где сгодился бы сервлет-контейнер,
контейнер — там, где прекрасно себя чувствовал бы Jetty.
EJB(2, 3) вместо Spring.
Бинарный ремоутинг там, где сгодились бы HTTP-запросы.
SOAP вместо REST.
GWT вместо фронтенда на jQuery (или подобном) к REST-бекенду.
Чисто джавские MVC-фреймворки вместо Grails.
Толстые клиенты на RCP и Swing вместо Flex/AIR.
Подключаемые библиотеки для работы с картинками вместо внешнего ImageMagick.
Работа с файлами и окружением из кода вместо шелл-скриптов.
контейнер — там, где прекрасно себя чувствовал бы Jetty.
EJB(2, 3) вместо Spring.
Бинарный ремоутинг там, где сгодились бы HTTP-запросы.
SOAP вместо REST.
GWT вместо фронтенда на jQuery (или подобном) к REST-бекенду.
Чисто джавские MVC-фреймворки вместо Grails.
Толстые клиенты на RCP и Swing вместо Flex/AIR.
Подключаемые библиотеки для работы с картинками вместо внешнего ImageMagick.
Работа с файлами и окружением из кода вместо шелл-скриптов.
+1 к фанатам IDEA. Стоящая вещь, экономящая время и нервы, а заодно в фоне обучающая новым методам рефакторинга :-)
Для чего в Hibernate нужно было реализовывать пул соединений через c3p0? Разве сам Hibernate этого не поддерживает?
И еще вопрос, Prepared Statements:
String sql = «from Logon where sid = :sid»;
Query q = session.createQuery(sql).setString(«sid», logonValues.getSid());
Это ведь именно prepared statement. Я это к тому, что если использовать Hibernate, то глупость №3 и №6 отпадают сами собой?
И еще вопрос, Prepared Statements:
String sql = «from Logon where sid = :sid»;
Query q = session.createQuery(sql).setString(«sid», logonValues.getSid());
Это ведь именно prepared statement. Я это к тому, что если использовать Hibernate, то глупость №3 и №6 отпадают сами собой?
половина глупостей слишком странные
Sign up to leave a comment.
Самые глупые вещи, которые я сделал будучи программистом