То есть, если мне нужно сделать, что-то с новой (для меня) технологией, то я последовательно наступаю на ВСЕ грабли, который можно найти.

Сегодняшний пример.
Мне нужно написать небольшой Servlet (условно говоря 1 страница кода) и отмерять jMeter’ом его быстродействие. Ну блин, что может быть проще?

Ан… нет. Учитывая, что сервлеты я писал дааавно (да и JSP’шки, разве что самые простенькие делал), то естественно я успел наткнуться на странные грабли.

Посылаю POST (из jMeter), а в Servlet приходит GET. Ладно, сделал HTML, посылаю форму POST, все равно зараза приходит GET. В общим, в инете рылся, ничего не нашел по этому поводу. Плюнул, Нашел пример сервлета, запустил – для него таки приходит POST.

Ok. Ищем разницу. Нашел таки. Оказывается, в порыве страсти, когда я делал servlet-mapping, то url-pattern я указал «/»
Соотвественно, весь URL у меня должен выглядеть так «http://localhost:8080//». А я вместо этого и в jMeter и в HTML написал «http://localhost:8080/» (без последнего слеша).

И вот эта зараза, вместо того, чтобы послать меня нафиг или работать нормально, решила, что вместо POST, она будет делать GET, а все параметры выкинем в окно.

Бац-бац-бац головой об стену.

Доктор, дайте мне пилюль от граблей.

Вопрос:
в) Как бы по правильному использовать JNI в JEE envinronment (под JBoss).

То, что написано дальше, может быть чушью, так как опыта в этом ноль без палочки и дай бог день чтения форумов.
Так, что прошу не судить строго.

Из того, что я прочел и понял
- Если у нас что-то крешится в DLL, то падает весь сервер.
- Если Java класс делающий System.LoadLibrary загружен одним ClassLoader’ом, то если второй ClassLoader попытается
загрузить тот же класс, то оно не сможет загрузить DLL, так как DLL уже загружен в процессе (особенность винды) и поэтому не сможет использовать JNI интерфейсы.
- Как я понял, по спецификации EJB не работают с JNI. С другой стороны, в нескольких местах прочел, что работаю, но с ограничениями.

Пару идей которые встречал
а) Сделать C++ приложение JMS enabled. И общаться из приложения в app server с этим JMS enabled приложение
б) Поднять отдельный сервер и общаться через RMI.
в) Сделать adaptor (JavaEE connector architecture). Это опцию я понял хуже всего, но зато похоже она наиболее правильная.

Ну и еще раз повторю вопрос, только теперь чуть более развернуто. Как бы сделать это по правильному? Какие есть еще подводные камни о которых нужно знать (так как хочется не только сделать правильно, но и понимать, почему это правильно).

Ну, это естественно на бумаге, а в жизни, как оказалось множество оврагов. Очень быстро и поверхностно (все пишется с точки зрения C/C++, но на самом деле актуально фактически для всего из чего можно собрать DLL)

- Ну начнем с простого факта. В DLLMain нельзя делать много из того, что можно делать в многих других местах.
а) Вызывать LoadLibrary, FreeLibrary
б) Работать с Registry
в) Работать с потоками и процессами. (Создавать потоки можно, но ждать их нельзя)
г) Использовать API, которые предоставляются не Kernel32.dll
д) И само собой нельзя делать все то, что использует вышеперечисленные вещи. Например нельзя использовать COM

- Увы, факт ограничений в DLL написал маленькими буквами где-то на 5 странице документации. Еще хуже то, что зачастую все будет работать нормально, до тех пор пока вам какой-нибудь заказчик не пришлет баг, которые повторяется в 30% случаев, когда луна находится в перегелии и не зная этих ограничений можно долго и счастливо все это дебажить.

- Ладно. С ограничениями разобрались. Если нам что-то надо будет сделать, мы создадим потом, который сделает эти операции или сделаем глобальную переменную объекта, в конструкторе которого сделаем все что нам надо. Правильно? Бззззз… Ответ не правильный.
а) Если мы создаем поток и не ждем его (так как ждать нельзя), мы не можем быть уверенными что DllMain уже закончится, так что мы просто создали race condition и проблемы стали еще более тяжело воспроизводимы
б) Глобальные переменные и статические члены классов инициализируются и деинициализируются внутри DllMain. Хотя это с ходу не видно, но если полезть в CRT, то это станет понятно. Таким образом, описанные ограничения касаются также конструкторов и деструкторов.

- Итого, имеем, чтобы по честному сделать какую-ту серьезную инициализацию, то нужно иметь функцию в нашей DLL которую клиент вызовет и там мы сделаем все сложные действия. Аналогично, кстати для деинициализации.

- Особенно все прикольно становится, когда мы пишем DLL которую будет впихивать в чужие процессы с помощью SetWindowHookEx или просто plugin’ы к какой-то системе. В обоих случаях, интерфейс может быть заранее определен и там нету функций инициализации и деинициализации. Соотвественно, не ясно что делать.

- Ok. Поздняя инициализация нам поможет насчет инициализации. То есть когда-то кто-то вызовет первый из интерфейсов, мы сделаем все сложные действия. А что делать с деинициализацией? В отличии поздней инициализации, ранней деинициализации не существует то? На это увы, общего ответа я не нашел и в каждом случае, нужно искать свое решение.

- Следующая особенность состоит в том, что все потоки созданные в DLL на самом деле принадлежат процессу. То есть если вдруг DLL будет выгружена из памяти (потому что вызывающий процесс сделал FreeLibrary и DLL counter стал равным 0), то внезапно адресное пространство где была DLL будет высвобождено. А поток останется __ЖИВ__. То есть он попытается выполнить свою следующую операцию, для этого попытается считать следующую команду из адресного пространства где была DLL и мгновенно закрешится. Скажите прекрасно?

- Ok. То есть нам надо остановиться все потоки, которые мы создали в DLL перед тем, как она будет выгружена и это при том, что мы еще даже точно не знаем, как нам запустить какой-то код перед выгрузкой, причем в момент, где нет ограничений. А да, и я еще молчу о том, что написать нормальный thread manager который обрабатывает достаточно большое количество разных ситуаций не вызывая dead lock’ов и race condition, задача в целом не тривиальная.

- Так… Что там у нас дальше. Ага. Вам нужно использовать COM? Само собой вы привыкли к CoInitialize(Ex) и побежали. Только вот, есть одна проблема. Если вы это делаете в DLL то вы исполняетесь в чужом потоке и у потока уже может быть инициализирован COM, причем не в том режиме (STA vs MTA) в котором вам нужно. Что делать? Создавать отдельный поток в котором выполнять все COM действия.

- Единственное пожалуй из положительного. Многое из того, что я писал относится к выгрузке DLL системой. Есть простой трюк, как удостовериться, что система никогда не выгрузит ваш DLL (исключая закрытие программы). Все что вам нужно сделать в DLL это вызывать GetModuleHandle(Ex). Это добавит 1 к DLL counter’у и можно не беспокоиться, что counter когда-либо вернется к нулевому значению.

- А еще во время выхода из процесса, система убивает все потоки, причем поток мог быть посередине модифицирования каких-нибудь данных (внутри критической секции). Еще приятней то, что он мог быть внутри функции работы с heap и таким образом heap будет в inconsistent state. И поэтому лучше не делать ничего хитрого (а по возможность вообще ничего) в DLLMain DLL_PROCESS_DETACH и в деструкторах глобальных объектов (взято отсюда: http://blogs.msdn.com/b/oldnewthing/archive/2007/05/03/2383346.aspx

Вроде все, хотя может что-то еще вспомню.

За последние пол года, покопался с хорошей кучей всякого open source:
- Apache
- OpenSSL
- Ruby
- BouncyCastle
- EJBCA
и еще с некоторым количеством менее известных вещей.

Ну, что.. Боязнь лезть в код исчезла. Плюс, даже кинул авторам проектов пару пофиксов, багов, которые по ходу нашел.

Те проекты, которые распространненые, обычно очень неплохо написаны – нормальная архитектура и код, так что разобраться можно.

Единственное, с чем я по прежнему не согласен, это то, что код – лучшая документация. Лично для меня, лучшая документация – графические диаграммы, дающие взгляд с высоты птичьего полета на систему, плюс хорошие описание public API. Детали, действительно проще таки подчерпнуть из кода.

Из того, что наболело

- Управление памятью в Objective C какой-то странный изврат. С одной стороны вроде reference counter, а с другой стороны извольте ручками добавлять, убавлять, прописывать правильные атрибуты пропертям.

- XCode 3 расчитан на чертовых ниндзь. Кучу наиболее часто используемой функциональности (а-ля запуск программы или build) висит на комбинации из трех кнопок, вместо одной (или максимум двух). Постоянно приходится мудры какие-то руками выделывать.

- XCode 4 гораздо лучше в использовании клавиш, но он явная beta и крешится на любой чих и при отладке частенько теряет стрелочку, что же мы сейчас отлаживаем.

- Куча системных API возвращает, что операция не удалась, но не возвращает ошибки (и как я понимаю, нету эквивалента GetLastError)

- Куча API крешится при передаче каких-то не совсем подходящих значений. Блин, а слабо входные параметры проверять и не крешиться? Особенно радует, когда это происходит при передаче
параметров только что полученных из другой системной функции.

- API растасовано так, что черт ногу сломит. Естественно чтение из файла и URL нужно запихнуть в NSString. Божественно… может запихнем в NSString вообще все функции, которые возвращают строки?

- Security framework с которым мне надо работать урезан по самое нехочу. При том, что я четко знаю, что API эти в библиотеки есть и пользуются внутренними программами.

Уххх… Поубивал бы.

Поделить впечатлениями о
а) Стабильности
б) Проблемах
в) Насколько оно нормально работает с внешними устройства (а-ля Debug через USB)

Как показывает опыт, гигантское количество может быть проблем.

Ну начнет с того, что есть куча кодировок: всякие UTF-8, Windows-1251, ASCII, ANSI? Если вы не совсем понимаете откуда растут ноги, то почитайте тут.

Кстати. еще приятная вещь, которая наложилась поверх всех этих UTF-16 это little-endianess и big endianess (можно почитать тут).

Но это еще все. Еще приятная штука, что куча программ/форматов используют специальные разделители для своих внутренних нужд.Ну например sheel в Unix использует | для pipes, да в Windows/DOS command line она тоже вроде используется. Соответственно, люди придумали escape символы, чтобы показать, что символ пользуется не в переносном (специальном смысла), а
прямом. К этому еще добавилось разделитель слов (пробел) и кавычки (как метод показать, что пробел не специальный знак).

К чему это я? Да прост убил фактически день на отслеживание следующей ситуации.

Installer использует
Command line и вызывает
Ruby script (с параметрами), который использует
Command line и вызывает
Java (c параметрами), которая вызывает какой-то
Java bean (внутри одного большого проекта), который читает и пишет
DB, а также создает
Certificate.

Из этого все Command line не любит определенные символы.
DB не любит определенные символы.
Certificate не любит определенные символы
Большой продукт пытается примерить некоторые входные параметры с тем, что не любит DB и Certificate. Но примеряет не все, не до конца и не совсем по стандарту. Плюс благодаря
этому он еще и херит некоторое количество того, что должно было работать для Certificate.

В общем, выдайте мне машину времени, нужно срочно вернуться на 50 лет назад и выдать им единый метод
а) Хранения integer в памяти
б) Encoding строк
в) Использования разделителей и escape characters
г) Правил по работе с строками вот в таких вот стеках.

С одной стороны, вроде чем лучше покрытие – тем лучше. С другой стороны unitTest’ы – это тоже код, который при изменении основного кода нужно поддерживать.

Опять же, для небольшого классика на несколько килобайт кода, зачастую можно наколбасить кучу тестов, которые будут проверять кучу разнообразных граничных условий.

Собственно говоря, как вы выбираете, когда остановиться?

Подумал и решил выдать это дело на RentACoder. Выложил и получил эдак 30 bid’ов и немножко был поражен. Начинаются bid’ы от $400 и заканчиваются $3k.
Те кто были на нижней стороне диапазона имеют либо достаточно фиговые отзывы, либо не имеют их вообще. По моему опыту заказывать у них – это выстрел себе в ногу. Боли много, толку мало.

ok. Смотрим на тех, кто может сделать это профессионально и достаточно хорошо (люди, которые имеют достаточно много отзывов и уже работали над такими же проектами). Ух… $1.5-$3K. Мдя… Я конечно хочу этот проектик, но если вдуматься то, я в результате получу просто сайт, который нужно еще раскручивать и т.п. Собственно, я получу очень небольшую кучку кода и дизайн, взамен я должен отдать эквивалент, скажем недельной поездки с женой на Гаваи.

Я вполне понимаю, что скажем для Москвы $500 – это уже не деньги. И ясно, что человеку там для хорошей жизни нужно делать уже некоторое количество таких проектов. Однако, RentACoder сайт всемирный и Вася Пупкин живущий где-нибудь в небольшом городке в Малазии, зарабатывая $1000 в месяц будет чувствовать себя местным королем.

В целом, чувствуется некая взвинченность нижнего ценового диапазона. Кстати, я вполне осознаю, что при этом есть задавленность вниз среднего ценного диапазона (на большинство средних проектов идет дикая конкуренция).

В целом, пока проектик лежит на полке. Делать его самому мне совсем сейчас не светит, времени мало и веб опыт достаточно ограниченный, поэтому осознаю, что убью времени гораздо больше, чем хотелось бы.

Как лучше всего распределять время и рабочий график программиста?

Я это спрашиваю в связи с тем, что в последнее время стал замечать, что совершенно не могу работать в офисе. Меня эта обстановка сковывает и я целый день занимаюсь фигнёй и ковыряюсь в интернете. Но совершенно по-другому обстановка выглядит дома. Тут я могу сосредоточенно думать, могу писать код по 4-5 часов подряд. И всегда, самые интересные мысли приходят когда я занимаюсь совершенно посторонними вещами.

В общем, если предоставить мне некую свободу, мне кажется я принесу больше пользы компании, потому что смогу больше думать и больше создавать, не находясь в рамках офисной обстановки.

Не уверен, но думаю не у одного меня такое ощущение: приходишь на работу работать, потому что это надо не тебе, а директору. Хотя хочется приходить на работу творить и создавать новое, ради удовольствия.

Как я понимаю, под «распределять время/рабочий график» имелось в виду «когда, где и как» работать.

Разобью вопрос на несколько частей.

1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?
2) Какие методы хороши для каких видов работы?
3) Куда послать директора или что нужно фирме?
4) Творить или не творить?

Итак пойдем по пунктам.

1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?

Бьюсь об заклад, это будет единственный вопрос, по которому все сойдутся в мнениях. Единственного и правильного решения не существует. Один человек «сова» и ему хорошо работать вечером, другой «жаворонок» и ему хорошо работать утром. Кто-то быстрее заныривает в работу, а кто-то буквально из-за мелкого внешнего раздражителя выпадает и долго не может сосредоточиться.

Так, что скорее важно разобраться какой метод работы подходит лучше для вас. Что подводить нас к второму пункту.

2) Какие методы хороши для каких видов работы?

Я бы сказал, что есть два типа программистской работы: требующая концентрации и требующая коммуникации. Решение сложный задач, добавление большего количество «мяса» на скелет, отладка – требует концентрации. Создание архитектуры, работа с QC, интеграция, планирование требует коммуникации.

Ну и логично, что в зависимости от того, что вы делаете (в основном и прямо сейчас) гораздо выгоднее быть либо в тихом закрытом помещении (офисе, домашней обстановке) или в комнате где сидят другие люди с которыми вам нужно общаться.

3) Куда послать директора или что нужно фирме?

Если вы работаете в обстановке, которая не подходит для вашего типа деятельности, то это может обозначать несколько вещей
Категория недопонимание:
- вы делаете не тот тип деятельности который от вас на самом деле от вас ожидали (например, вы – team lead и должны со всеми общаться, а вы хотите на неделю запереться дома и активно педалить код)
- просто ваше начальство не осознает, что вы могли бы быть более продуктивным работая по другому.

Тут, все просто. Вы идете и в спокойной обстановке обсуждаете, как сделать так, чтобы и вы и фирма выиграли (вы получили более подходящий метод работы. фирма получила более эффективного программиста).

Категория несоответствие:
- вы осознаете, что от вас хотят (например сосредоточение на коде), но вы хотите совсем другого (team leader’ство с постепенным переходом в менеджеры)
- вашей компании может не быть прямой выгоды от того, что вы работаете эффективно (например для тех компаний которые берут внешние проекты c time&material оплатой, может складываться ситуации, когда выгодно чтобы программист делал как можно дольше (естественно удерживая это ниже уровня, когда заказчик уйдет)

Это уже слегка похуже. Но, в целом, опять же, можно пойти к начальству и попытаться найти какое-то разумное решение. Хотя тут оно уже не всегда возможно.

Категория конфликт:
- вы и компания хотите чего-то одного (например эффективности), а ваш прямой начальник хочет чего-то совсем другого (минимального напряжения на работе, при игнорировании целей фирмы).

В общем решать такую ситуацию, что плевать против ветра. Силы уйдет много, а результат будет один – сами себя оплюете. Я бы рекомендовал вместе вложения сил в военные действия внутри фирмы, спокойно разослать ваше резюме и найти другое место работы.

Кстати, еще одно замечание по поводу сосредоточения. Я сам по себе знаю, частенько начинаешь копаться в инете, когда просто не хочется за что-то браться. В таком случае, лучше себя заставить из зачастую быстрее сделать не слишком вкусную задачу, чем пол дня мусолить и откладывать ее.