Comments 61
продолжим?
Глупость
Использовали собственные реализации очередей и семафоров
Следствие
Потраченное время, сложный код, ошибки собственных реализаций
Что я должен был сделать
Убедить в необходимости миграции на Java 5, использовать соответствующие классы из Collection API и java.util.concurrency
Глупость
Использовали собственные реализации очередей и семафоров
Следствие
Потраченное время, сложный код, ошибки собственных реализаций
Что я должен был сделать
Убедить в необходимости миграции на Java 5, использовать соответствующие классы из Collection API и java.util.concurrency
+12
Глупость
Интеграция новых фич, забыв о рефакторинге старого кода
Следствие
Сложный код, который не поддается никаким изменениям
Что я должен был сделать
Использовать TDD + рефакторинг на ранних стадиях проета
Интеграция новых фич, забыв о рефакторинге старого кода
Следствие
Сложный код, который не поддается никаким изменениям
Что я должен был сделать
Использовать TDD + рефакторинг на ранних стадиях проета
+8
Это целый класс клупостей — делать свой велосипед и не пользовать хорошо известную библиотеку.
+2
Очень интересный топик — посоветовал всей команде хоть и на php пишем. :)
Можно этот пункт раскрыть?
Как система билдов поможет с библиотеками? Все равно в проекте используется определенная версия в каждый момент времени? значит ее надо где то хранить. Или вы предлагаете при билде тянуть версию библы из чужого репозитория?
А что делать когда библиотеку приходиться патчить? да лучше до этого не доводить, но иногда приходиться…
Можно этот пункт раскрыть?
Как система билдов поможет с библиотеками? Все равно в проекте используется определенная версия в каждый момент времени? значит ее надо где то хранить. Или вы предлагаете при билде тянуть версию библы из чужого репозитория?
А что делать когда библиотеку приходиться патчить? да лучше до этого не доводить, но иногда приходиться…
+1
Именно так. Библиотеки скачиваются из публичных репозиторев. Однако mvn аккуратно и очень педантично сохраняет всё скаченное локально. Поэтому можно относительно не бояться — два раза одну версии одной библиотеки в общем случае качать не придётся.
Сами зависимости объявляются в xml-файле, а файл находится под контролем версий. Поэтому если вы использовали допустим версию 1.3, а вдруг решили обновиться — вы просто правите цифру в xml-файле — 1.4. Теперь билд будет использовать новую версию.
Сами зависимости объявляются в xml-файле, а файл находится под контролем версий. Поэтому если вы использовали допустим версию 1.3, а вдруг решили обновиться — вы просто правите цифру в xml-файле — 1.4. Теперь билд будет использовать новую версию.
+3
«два раза одну версии одной библиотеки в общем случае качать не придётся» — сколько проектов у вас не было б. копии сохраняются в win — «C:\Documents and Settings\user\.m2\»
0
Я бы добавил еще возмодность использования промежуточных репозитрориев уровня команды (Apache Archiva, Artifactory). Тогда скачивать придется один раз на команду, да и свои артефакты там держать удобно.
+3
хотя у меня на маке был момент с тем, что запуск мавена с коммандной строки и с IDEA приводил к созданию 2 репозиториев. Решилось путем настройки всего, что связано с мавеном, но на маке с мавеном стоить быть осторожным :)
0
а на компьютере девелопера данную библиотеку кто обновлять будет? или у всех стоит клиент от maven?
0
Поддерживаю!
Кроме того maven может помочь избежать таких глупостей как:
1. Отыскивание и разрешение зависимостей вручную.
2. Написание и поддержка длинных ant скриптов для сборки, деплоя и тестирования проекта (вообзе имхо, так что фанаты ant'a не ругайтесь :) )
3. Создание тега в source control для стабильных версий кода.
4. Много еще чего.
Кроме того maven может помочь избежать таких глупостей как:
1. Отыскивание и разрешение зависимостей вручную.
2. Написание и поддержка длинных ant скриптов для сборки, деплоя и тестирования проекта (вообзе имхо, так что фанаты ant'a не ругайтесь :) )
3. Создание тега в source control для стабильных версий кода.
4. Много еще чего.
+4
Or use Ant+Ivy
0
Глупость
Вести всю работу с кодом в trunk репозитория, не заботиться об управлении конфигурациями
Следствие
Невозможность в нужный момент собрать необходимый релиз; невозможно править и коммитить несколько багов одновременно
Ч я д б с
Получше освоить корректное управлении исходными кодами (например, здесь, применить на практике паттерны управления версиями www.scmpatterns.com
Вести всю работу с кодом в trunk репозитория, не заботиться об управлении конфигурациями
Следствие
Невозможность в нужный момент собрать необходимый релиз; невозможно править и коммитить несколько багов одновременно
Ч я д б с
Получше освоить корректное управлении исходными кодами (например, здесь, применить на практике паттерны управления версиями www.scmpatterns.com
+13
у меня таких глупостей под 100 штук наберется, но главное делать своевременно выводы и двигаться вперед… главное — вперед. не боятся изучать новое и пробовать новые концепции.
+11
scalability переводится, как правило, как «расширяемость» или «масштабируемость».
Исповедь говнокодера, вставшего на путь истинный.
Исповедь говнокодера, вставшего на путь истинный.
-11
Глупость
Использовать константы для вывода i18n надписей
Следствие
Фоллбэк затруднен, а кое где невозможен,
Фраза должна добавляться сразу во все локализации,
Не отследишь непереведенные фразы,
Усложняет жизнь переводчика знаниями о кавычках и т.п.,
Сложно найти код, который выводит нужную фразу
Что делать
Юзать gettext на худой конец
Использовать константы для вывода i18n надписей
Следствие
Фоллбэк затруднен, а кое где невозможен,
Фраза должна добавляться сразу во все локализации,
Не отследишь непереведенные фразы,
Усложняет жизнь переводчика знаниями о кавычках и т.п.,
Сложно найти код, который выводит нужную фразу
Что делать
Юзать gettext на худой конец
+2
Глупость: пишу собственную реализацию event-management модели на java.
Следствие: не знаю как её применить.
Что делать: не страдать фигнёй :(
Следствие: не знаю как её применить.
Что делать: не страдать фигнёй :(
+2
UFO just landed and posted this here
без ошибок и набивания шишек не понять смысла умных вещей. Уж лучше самому изобрести велосипеды чтобы лучше понимать зачем нужные чужие и готовые — а не бездумно пользоваться результатами чужого труда.
+8
Честно говоря, IDE — глупость номер 0. Минус один. Вселенская глупость!
// добавьте Idea, пожалуйста. Штука очень мощная и безусловно окупается.
// добавьте Idea, пожалуйста. Штука очень мощная и безусловно окупается.
+4
Глупо верил в существование «серебрянных пуль» компьютерной науки.
Повзрослел. Теперь отношусь терпимее к своему и чужому говнокоду
Повзрослел. Теперь отношусь терпимее к своему и чужому говнокоду
+28
Да и вообще нужно было Grails использовать вместо всей этой разрозненной ботвы.
-8
UFO just landed and posted this here
Скажите, а сколько времени ушло на написание этого «велосипеда» и его отладку, сколько еще уйдет на добавление новых фич при необходимости. Автор говорит о том, что лучше использовать готовое решение если оно уже давно написано и работает как надо. По моему нужно иметь очень веские основания, чтобы писать свою orm, когда есть монстры вроде hibernate.
0
Мне интересно — есть ли какие ORM системы для php
0
Мда. А всего-то стоило заюзать что-то из пункта 1 и проблемы 3, 5, 6 сразу отпали бы.
+2
хм, я как дилетант, думал, что для DB connection pool надо просто юзать appllication servers, в которых это уже есть
+1
Одна из самых глупый вещей, которая не позволяет оглядываться назад и пересматривать себя со стороны — это отношение к критике.
Глупость
Не принимал критику кода/решений — взрывался, отрицал, начинал оправдываться. Очень резко относился к любому вмешательству в свой код.
Следствие
Заблуждения, конфликты с коллегами, «допотопность» — не использовал кругозор других.
Что я должен был сделать
Прислушаться к критике, самому на нее нарываться. Потому что люди, критикующие или сообщающие тебе об ошибке — чаще всего, делают тебе хорошую услугу. Обсуждая свой код, свои решения — мы учимся, находим правильные решения, ведь спор заставляет нас думать, аргументировать наши поступки. Понимание этого вкупе с терпимостью :-) и позволяет легко учиться на своих ошибках.
Глупость
Не принимал критику кода/решений — взрывался, отрицал, начинал оправдываться. Очень резко относился к любому вмешательству в свой код.
Следствие
Заблуждения, конфликты с коллегами, «допотопность» — не использовал кругозор других.
Что я должен был сделать
Прислушаться к критике, самому на нее нарываться. Потому что люди, критикующие или сообщающие тебе об ошибке — чаще всего, делают тебе хорошую услугу. Обсуждая свой код, свои решения — мы учимся, находим правильные решения, ведь спор заставляет нас думать, аргументировать наши поступки. Понимание этого вкупе с терпимостью :-) и позволяет легко учиться на своих ошибках.
+9
Сделал 1-3 на C# :)
Как-то работает, конечно, но сейчас бы так уже делать не стал.
Как-то работает, конечно, но сейчас бы так уже делать не стал.
+2
Глупость
Изобрел велосипед.
Следствие
Все работает медленно, находятся новые баги.
Что я должен был сделать
Воспользоваться Java API, а не изобретать велосипед.
Изобрел велосипед.
Следствие
Все работает медленно, находятся новые баги.
Что я должен был сделать
Воспользоваться Java API, а не изобретать велосипед.
+3
а помоему все это жутко полезно, сталкиваться с проблемами, даже изобретая свой велосипед — это самый лучшии опыт.
+2
Ну по поводу пунктов про ORM, EAV и IDE я бы поспорил.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
+2
Правка имеющихся ORM без внесения этих изменений в транк библиотеки — это ещё одна глупая вещь. Я не представляю, как вы будете писать «свой Hibernate». Это было бы очень и очень глупо. Написание своей ORM могут себе позволить только очень крупные компании, понимающие почему им не подходят конкретные библиотеки, даже после допилки.
Про IDE. Eclipse очень хорошо пилится и дополняется плагинами. Единственный его недостаток — скорость работы и требуемая память.
Про IDE. Eclipse очень хорошо пилится и дополняется плагинами. Единственный его недостаток — скорость работы и требуемая память.
0
Кстати, не подскажите, какие подходы к кэшированию EAV и обеспечению когерентности популярны/распространены?
0
Если из вопроса убрать слова 'популярны/распространены' (не обладаю достаточными данными чтобы отвечать именно на это), то…
* Кеширование 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.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
+1
Т.е. кэш заранее делается на определённый состав пропертей (и, соответственно, под определённый класс запросов)? Просто интересно, может для этого есть какие-нибудь невелосипедные библиотечки/наработки. Это в частности, интересно, т.к. некоторые игроки предлагают key-value базы данных и было бы неплохо производить какие-нибудь простенькие операции с ними на стороне клиентов в семантике SQL.
Я так понимаю, что оригинальный жалующийся автор (Ioannis Cherouvim) как раз и реализовал в своём самописном ORM какую-то извратную обёртку вокруг EAV. Из-за этого велосипеда (а также из-за замены продумывания схемы БД кажущимся ему «серебрянной пулей» EAVом) он и получил фэйл…
Я так понимаю, что оригинальный жалующийся автор (Ioannis Cherouvim) как раз и реализовал в своём самописном ORM какую-то извратную обёртку вокруг EAV. Из-за этого велосипеда (а также из-за замены продумывания схемы БД кажущимся ему «серебрянной пулей» EAVом) он и получил фэйл…
0
При создании оберток нужно не забывать что обертка делается для человека а не наоборот.
Не следует запрещать самому себе все и вся, это вредно — именно это обычно порождает проблемы.
P.S. Производительность практически всегда приносится в жертву удобству, и наоборот. Если видите что система получается слишком сложной (взаимозависимости технологий друг от друга большое), лучше остановиться и прекратить решать как еще извратиться чтобы получить результат (анекдот про программиста и чайник помните?). Лучше написать своё.
Не следует запрещать самому себе все и вся, это вредно — именно это обычно порождает проблемы.
P.S. Производительность практически всегда приносится в жертву удобству, и наоборот. Если видите что система получается слишком сложной (взаимозависимости технологий друг от друга большое), лучше остановиться и прекратить решать как еще извратиться чтобы получить результат (анекдот про программиста и чайник помните?). Лучше написать своё.
0
Кэш делается после анализа узких мест (которые можно и заранее предугадать кстати), само собой запросы должны будут переписаны под использование этого кэша (у нас это было легко сделать, даже с учетом дрянной реализации и временных наслоений кэш заменил собой вьюху, которую oracle не очень хотел оптимально разворачивать в запросах, хотя у нас и специалиста как такового не было).
0
Собственные интерфейсы мониторинга и управления вместо JMX.
+1
Сервера приложений там, где сгодился бы сервлет-контейнер,
контейнер — там, где прекрасно себя чувствовал бы 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.
Работа с файлами и окружением из кода вместо шелл-скриптов.
+2
UFO just landed and posted this here
+1 к фанатам IDEA. Стоящая вещь, экономящая время и нервы, а заодно в фоне обучающая новым методам рефакторинга :-)
+1
Для чего в 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 отпадают сами собой?
0
половина глупостей слишком странные
0
Sign up to leave a comment.
Самые глупые вещи, которые я сделал будучи программистом