Maks00088: В общем и целом лог говорит нам, что Jersey находит какие-то классы в jar-ах, но среди них не находит классов, имплементирующих какие-то интерфейсы. Тому может быть хрелион разных конкретных причин - от не проставленной аннотации в каком-нить вашем исходнике и вплоть до наразрешающейся в рантайме транзитивной зависимости. А дальше моих лично телепатических способностей недостаточно, чтоб угадать все остальное необходимое на расстоянии. Без малейшего намека на то, что и как Вы там пытаетесь сделать по одному этому логу нельзя сказать, в чем проблема, да и есть ли она вообще :)
Григорий Васильков: Бросайте поиск заговора под подушкой... почитайте мой ответ. Возможно, он подтолкнет Вас в нужном направлении. И, если возникнут, задавайте более конкретные вопросы :)
Меня сюда позвали, как "эксперта" (ха-ха)... Но мне, собственно, нечего добавить ко всем ответам - да, можно использовать... только обратить внимание на полярность на штекере, т.к. у универсальных БП ее иногда легко перепутать. Но если штекер точно подходит под модель ноута и правильно вставлен, все должно быть ОК.
alex_ak1: IDA, Оля - это все дизассемблеры... Если у Вас есть исходники приложения, берите сам Билдер и - вперед по коду... там все станет понятно. А если нет, то это не называется "отладить"... это называется "реверснуть" :) Но, судя по вопросам, у Вас это, к сожалению, вряд ли получится :(
Николай Антонов: Как узнать dx и dy - очевидно! Например так: dx=x2-x1; dy=y2-y1;
Непонятно совсем другое - угол наклона ОТНОСИТЕЛЬНО ЧЕГО нужно узнать? От этого сильно зависит, как именно считать dx и dy :))
Антон: И еще... как определить, что опыта достаточно? В книжках можно вычитать теорию, но в реальности все гораздо жестче. Представьте себе свой первый трудовой день. Скорее всего, в первый раз Вам, как новичку, никто не даст организацию проекта с нуля - Вам дадут полудохлую лошадь (планы, документация, требования, ТЗ хз. где, разрабы заняты хз. чем, бюджет давно исчерпан, а сдача уже через месяц), которую нужно оживить, намарафетить и превратить в арабского скакуна. И вот Вас представили команде, разрабы сказали "Угу" и отвернулись каждый в свой монитор. Начальник ушел и сказал, завтра в 9 представить хотя бы примерный план действий. Спросите себя прямо сейчас, что Вы конкретно будете делать в этой ситуации, пошагово, вплоть до 9 утра следующего дня... вот когда будете знать точный ответ на этот вопрос, это и будет означать, что у Вас уже достаточно опыта для позиции ПМа :)
Удачи Вам и терпения!
Антон: В идеале хорошо бы начать с позиции разработчика в проекте, чтоб посмотреть на эту кухню, так сказать, изнутри. В конечном итоге резраб - именно тот, кто определяет успех или неудачу, остальные только помогают или мешают :) Но ассистент ПМ - тоже хорошо, если уже есть хоть минимальный опыт разработки. Ну, и параллельно, разумеется, читать литературу по теме. Начните с того же Де Марко, и далее в сторону агильных технологий. Вы должны хотя бы понимать сущность водопада, V-модели, скрама/канбана, иметь представление о более навороченых методиках типа сигмы-шесть (которые Вам, почти наверняка, в ближайшие лет 10-15, а то и вообще применять не придется, но хоть раз прочесть о них все равно стоит!), о принципах управления качеством, о методиках оценки и управления рисками, о методиках и принципах управления требованиями, знать основы психологии формирования команд. Вот после этого и 2~3, по возможности РАЗНЫХ проектов на должности ассистента можно будет задумываться о должности ПМа.
Risin0: Да нет, почему костыльно... не Джавой же единой. Такой подход ничем не отличается от какого-нибудь MAKE или др. сборщиков. В некоторых случаях сборка - несколько сложнее, чем просто компиляция и упаковка. Maven, конечно, заточен под ванильную Java, но как раз для нестандартных случаев и существуют плагины. У меня, например, подобным образом в продакшене собирается документация очень даже серьезных, сертифицированных вдоль и поперек проектов. Там, правда, ничего не патчится, но без распаковки зависимостей никак не обойтись. И ничего - пока еще никто не жаловался :)
Free_ze : Или мы по-разному интерпретируем суть вопроса, или же у нас развивается полемика "ниочем" :) В моем понимании, автора вопроса интересует лучшая практика для конкретного сценария "КОД ОШИБКИ"... в частности, для 2 возможных значений. В этом смысле я полностью согласен с вашим ответом. Для случая же возможного расширения утверждаю, что строки и исключения ощутимо хуже enum. Почему:
>То есть заводить новый код ошибки - это ОК, а новый класс исключения унаследовать - это плохо?
Да, плохо... т.к. для этого сценария неоправдано дорого.
- Самый дешевый код ошибки - статическая константа, например, int. Из недостатков: консистентность значений не может быть проверена компилятором, плюс, при сериализации теряется мнемоника.
- Чуть дороже enum. Стоимость одного кода ошибки в enum, грубо, если отбросить прочие накладные расходы VM, Строка + оrdinal. Преимущества: гарантированый синглтон, гарантированная (компилятором) корректность, мнемоническая сериализация, values()/valueOf(), ну, и, разумеется, чисто эстетическое удовольствие от того же сравнения по == вместо богопротивного equals() :)
- Строка выглядит на первый взгляд дешевле, но если учесть, что в реализованном говнокодом сценарии реально создается минимум 2 экземпляра строки (при "заполнении" и при "сравнении"), мнимое преимущество теряется... а недостатки остаются. (А если не говнокодом, то, опять же, у строки нет преимуществ перед static final int, кроме недостатков.)
- Исключение - самое дорогое, что можно придумать. Один безполезный (для сценария!) стектрейс впридачу чего стоит... про приятные неожиданности в реализации на разных VM, например, проброса из цикла, даже заикаться не буду :) Лучшая практика относительно исключений - не использовать их всуе, т.е. если в этом нет конкретной осознанной необходимости.
В контексте вопроса такой необходимости явно нет и ваш аргумент про loose coupling для данного сценария бряд ли уместен. Если кто-то проверяет код ошибки, ему по определению известен класс или, как минимум, реализуемый объектом интерфейс, а значит, и сигнатуры всех методов, так что, вопрос - если ничего не дофантазировать - сводится всего навсего к выбору адекватного типа результата. Не знаю, как Вы, а я, лично, задумался бы о профпригодности коллеги, написавшего
public void getError() throws Error1Exception, Error2Exception {...
:)
Надеюсь, что мне удалось исчерпывающе аргументировать, почему именно enum - лучшая практика для сценария "КОД ОШИБКИ". По поводу остальных ваших аргументов ничего не могу сказать, т.к., к сожалению, не понимаю, с кем Вы спорите по этим моментам... я ничего подобного не утверждал :)
Free_ze: 1. Строки для заявленного сценария - вообще зло. Если они не константы (т.е. значения могут прилететь извне), то их нужно как минимум проверять на валидность, null/empty/Upper/LowerCase и пр. пританцовывания... а если константы, то зачем выкидывать на них столько памяти, если можно обойтись enum с той же самой выразительностью, но гораздо дешевле по ресурсам плюс - и это основное преимущество - проверка компилятором? Серьезно рассматривать строки как альтернативу тут как-то даже неудобно... но, если конкретно по вопросу: как минимум, меньше кода при расширении. Сравните private static String CASE_NUMBER_THREE = "мой новый супер-пупер кейс"; против добавления CASE_NUMBER_THREE в enum :) Хотя, конечно, если говнокодить, то особой разницы действительно не будет :)
2. Примерно по тем же соображениям. Даже если не знать, что обработка исключений в смысле ресурсов еще дороже, чем обработка строк, и отвлечься от того, что на каждый новый случай придется заводить новый класс исключения (я тут, опять же, не рассматриваю говнокодовские практики упаковки всего и вся в строковый месседж внутри java.lang.Exception, который, кроме бешенных накладных расходов, мало чем отличается от строк), то исключение - конструкция языка, предназначенная для информирования НЕИЗВЕСТНОГО получателя о ситуации, которая не может быть обработана в той части кода, которая его бросает. Именно от этого они, при бездумном использовании, имеют свойство пролетать на самый верх и ронять все приложение. В описанном сценарии ни в том, ни в другом нет никакой необходимости. Для этого случая enum - наиболее адекватная конструкция языка.
Хотя, конечно, если очень хочется, то можно все, ибо, забивать шуруп молотком все же проще, чем закручивать гвоздь отверткой :)
И, кстати, для проверки значения enum тоже можно (и нужно!) использовать switch() / case. Это делает код намного более читаемым. А, кроме того, код с enum гораздо лучше расширяется, если, например, в один прекрасный день окажется, что возможно не два, а больше разных значений. Это в любом случае намного лучше, чем бросаться исключениями...
И, кстати говоря, даже ЕСЛИ БЫ это было так, стороннему приложению сначала пришлось бы поднапрячься, чтоб самому узнать серый IP. А иначе все что оно могло бы спалить - какой-нибудь 192.168.x.y... не сильно полезная инфа для АНБ, т.к. такие IP у 99% хостов по всему миру. Так что, заморачиваться на эту тему вообще имеет смысл только если клиент крутится на машине с реальным IP :)
Андрей Ермаченок: Octoberfest: У меня была аналогичная фигня с УКВ RFID (866МГц)... Теги периодически "улавливались" на таком расстоянии от одной определенной антенны, которое по всем рассчетам и измерениям было просто невозможно. Чего только не делали... даже стену в одном месте покрыли экранирующе-адсорбирующим материалом - ниче не помогало. Пока в один прекрасный день не выяснили, что явление наблюдается, когда на пути от антенны до этого проклятого места (а это хороших 3~4м в обе стороны) открывают дверь шкафа. Причем, возникающий при этом локальный максимум поля объемом не более 2~3дм^3 был сконцентрирован вокруг дверной ручки, мимо которой как раз и носили контейнеры. Проблема решилась бы заменой дверной ручки, с прямой на, непример, шарообразную, но это было невозможно, так что пришлось переносить антенну :) Думаю, подобные истории есть у каждого, кому приходилось иметь дело не только с красивой теорией, но и с увлекательной практикой. Так что, мораль басни проста: коефициенты и формулы хороши, чтоб понять суть и принципы физический явлений... но на практике, если нужно, чтоб реально работало, а не просто соответствовало формулам, все равно придется настраивать по месту.
Octoberfest: Ну, так средний - он и есть средний... как средняя температура по больнице :) Для стекла без металлизации примерно 3dB, с металлизацией - уже 5-8dB, стены - от 10-15 и до 20-25dB - в зависимости от материала. Выбирайте любой, какой нравится, и вставляйте в любую формулу.... все равно толку от этого ноль. На практике я даже встречал софт (очень дорогой, но практически бесполезный), который, учитывая это, на основе плана помещения типа прогнозирует дальность... но это все полная туфта, т.к. в один прекрасный день рядом с антенной поставят железный шкаф... и все эти расчеты можно будет свернуть в трубочку и вставить в одно место продавцу софта :)
Шановний, ви ж не сподіваєтесь, що хтось стане вбивати цей текст ручками, щоб знайти, де там строка 46 або 66? Тут є кнопочка "..." (вставить исходный код). Будьте ласкаві принаймні вставити текст замість PNG. А, взагалі, вчіться користуватися debugger-ом. Щоб самостійно знайти відповідь, вам буде потрібно макс. 30 секунд: поставити breakpoint на строку, дочекатися останову і подивитися, які об'єкти null :)
Может, конечно, статься, что автор вопроса действительно пытается сделать что-то странное... но, в принципе, есть один сценарий, при котором такое реально нужно. Если собирается не Java проект, к которому нужно подтягивать зависимости, которые процессируются тулзой, ожидающей, что все "части" (а не только исходники проекта) будут доступны из какой-то единой корневой папки и, при этом, нет возможности сделать сам проект модульным. Например, copy-dependencies приходилось делать для asciidoc проекта, подтягивающего шаблоны документа и картинки, экспортируемые Jenkins-ом.
Но, что, действительно, смущает в вопросе - зачем это делать ПОСЛЕ сборки, когда, в общем-то, нужно делать ДО :)
