EndUser: Да нет никакого перечня... перечень возможен для ограниченного владения (например, знаю, как написать цикл, но не знаю, как отнаследоваться от класса). А свободное - оно на то и свободное, что подразумевает "знаю все, что нужно для продуктивной работы" :)
"NFC - связь ... индуктивная" 125 кГц (LF RFID; это которые животным под кожу вживляют или в дешевых замках используют) - тоже связь индуктивная, однако его не принято называть NFC.
"RFID - просто цифровая этикетка"... Просто, да не совсен! В EPC Gen2 (UHF) еще какой протокол... если уронить на ногу его спецификацию, распечатанную мелким шрифтом, можно остаться инвалидом :)
Горькая правда в том, что термин NFC придумали маркетологи, чтоб как-то обозначить слегка доведенный напильником ISO 14443. Фактически NFC- это частный случай RFID.
QuAzI: А аргументация, почему SOAP и WSDL на сегодня скорее зло, чем добро, достаточно прозрачна. Эта технология подразумевает принудительную статическую зависимость между соединяемыми системами, и делает это ценой очень большой сложности. Это было вершиной технической мысли в 90х, но с тех пор отрасль сильно шагнула вперед, обзавелась языками с динамической типизацией, более компактными (по сравнению с ХМL) форматами сериализации, и т.д... и технология морально устарела.
QuAzI: Приведенный в качестве примера совет, к сожалению, далеко не универсален. Такое расширение списка параметров может прокатить в какой-то конкретной имплементации, но для большинства (мне известных) изменение сигнатуры метода повлечет за собой как минимум генерирование и компиляцию новых классов на клиенте. Для "старых" клиентов придется поддерживать "старую" версию интерфейса, и таких версий наплодится со временем немало.
И так - со всем. Именно поэтому практически невозможно дать какие-то конкретные советы - все "тонкости" слишком сильно завязаны на конкретную имплементацию. Все грабли совместимости - соответственно, на пару имплементаций. Если у Вас есть конкретные сомнения или проблемы - спрашивайте. А иначе тут пришлось бы написать средней толщины учебник, который все равно останется неполным :)
Вот вам best practice - если возможно, вообще откажитесь от него в пользу REST. По хорошему, вебсервисы на SOAP существуют до сих пор только потому, что стандарт настолько монстрозный, что нет такой большой помойки, на которую его можно было бы выкинуть :)
Если такой возможности нет, то, конечно, генерируйте, но все равно не удивляйтесь, когда полезут грабли несовместимости MS и Java стеков. Ну и, разумеется, www.soapui.org Вам в помощь :)
Юрий Ярош: Ну, такой генезис полномочий - это для случая, когда речь идет об одном продукте/проекте, например, редизайне или создании с нуля внутриконторского софта, или одного интернет ресурса под конкретную бизнесмодель... тогда да. Но бывают варианты, когда СТО отвечает одновременно за несколько разных продуктов (иногда созданых до его прихода), да еще и за R&D, и за гребаную ежегодную ISO сертификацию, и за соответствие целому вороху отраслевых норм, и за патентные заморочки, и за связи с партнерами по совместным проектам... т.е. фактически, за технологическую стратегию и тактику всей компании. Вот тут без изначально четко проговореных и прописаных полномочий уже никак. Потому варианты, типа давай, впрягайся, а там мы по ходу дела решим... могут идти лесом и возвращаться только с конкретными предложениями :)
Без гарантий, это еще пол-беды, а вот без четко очерченных полномочий (недавно предлагали) - вот это ход конем :) А так, по опыту - организовывать с нуля обычно проще, чем перекраивать.
Stepan Miloslavsky: Есть, причем, именно что ощутимая. JPEG предназначен для компрессии с потерей качества... (в основном, т.к. есть еще и экзотика вроде lossless JPEG). За счет чего он, разумеется, меньше по размеру. TIFF - наоборот, для компрессии без потери качества (или же вовсе без нее). Кроме того, в TIFF есть много плюшек вроде слоев, пирамид и пр. лабуды, включая встроенные превьюхи... сжатые тем же JPEG :) Так что, оба формата как бы дополняют друг друга и используются соответствующе: TIFF - для работы с оригиналами и подготовки к печати, а JPEG - для передачи по сети и отображения на конечных устройстваx с а аддитивной цветовой моделью (в основном, на мониторах). И хотя в JPEG можно упаковать CMYK и даже добавить ICC профиль, будут ли цвета правильно истолкованы при отображении, зависит от софта.
uvelichitel: Ясно. Жаль. Давно присматривался, но все как-то не с руки посылать им официальный запрос ценника, т.к. мне она "официально" как бы не очень нужна.
Эм... а кто сказал, что там Апач фронтом, а не какой-нибудь Tomcat или WildFly на 80 порту? По идее, нужно конфигурировать веб-контейнер или сам JSF сервлет, но, не зная подробностей, можно только гадать, что и где конкретно.
Ответ верен лишь от части. Делать площадь соприкосновения с охлаждаемой деталью меньше возможной, действительно, не имеет смысла, а вот насчет того, делать ли поверхность радиатора, с которой соприкасается деталь, больше площади детали, играют роль, в основном, иные соображения.
Для радиатора важна не столько площадь соприкосновения с деталью (она, в конце концов, ограничена самой деталью), сколько площадь поверхности, соприкасающейся с окр. средой, которой (среде) он должен отдавать тепло, отводимое от детали. Имено для ее увеличения радиаторы делают ребристыми, штыревыми и т.д.
Минимальная необходимая площадь контакта радиатора с окр. средой рассчитывается исходя из электрической мощности, которая должна рассеиваться на детали, с одной стороны, и удельной теплоемкости, теплопроводности материала, цвета (белый или черный) и параметров окр. среды и максимально допустимых температур поверхности детали / внутри корпуса / условий эксплуатации (влажность воздуха, диаппазон температур и т.д.) с другой. Делать радиатор больше этой рассчетной площади - избыточно, но какого размера делать отдельные его стороны в рамках необходимой общей плошади - абсолютно неважно. КО в данном случае подсказывает, что вся площадь радиатора, которая не соприкасается с деталью, есть площадь соприкосновения с окр. средой. Так что делать радиатор больше детали, само по себе, отнюдь не избыточно... просто это не важно.
Правда, есть еще одно соображение, которое может заставить "вытягивать" радиатор в высоту, а не в ширину. Часто (но не всегда!) поверхность охлаждаемой детали, с которой он соприкасается, имеет потенциал земли, и если эту землю "растянуть" в ширину за габариты детали плоским широким радиатором, это может плохо сказаться на помехоустойчивости всей схемы.
Отдельный случай - черный радиатор, на стороне которого выфрезеровано и отшлифовано "посадочное место" детали. В этом случае снимать черное покрытие с лишней площади - значит уменьшать эффективность радиатора.
Так что, на практике никто ничего не подгоняет тупо под размер детали, а рассчитывает исходя из терморежима и общих конструкционных соображений.
Merzley: Рад был помочь. Да и не расстраивайтесь так. Программист (как и любой специалист), это же не тот, кто уже все знает, а тот, кто всегда учится ;)
Merzley: Кхе-кхе... в простонародье "электролитом" называется, ибо с оксидным диэлектриком. Плюсик еще на схеме имеет. Если этот плюсик не туда включить, взрывается, или выстреливает в глаз :) для этой схемы как раз такой и нужен.
