Кажется PMP (специализации точно не было). Среди прочих курсов и той напряженной учебы даже не помню точно.
Значок и сертификат где то дома валяются.
Было обострение по учебе и проектным работам на работе…
3-4 года точно как прошло. Но на данный момент практического смысла подтверждать не вижу (работу не планирую менять...)
(если это не ваша статья, то считайте, что я обращаюсь к автору)
Вы не придумали новый контекст. Начали Вы исключительно в контексте деятельности, которая однозначно попадает под то, что пытаются классифицировать, обобщить и стандартизировать в том же PMI.
Изобретать новую терминологию исходя из своего незнания чего то, и опираясь исключительно на свой ограниченный опыт — это не верный подход. Вас просто не поймут, если вы придумаете свою собственную терминологию пересекающуюся со стандартной.
«ограниченный опыт» — это не оскорбление и не принижение. Опыт у всех ограничен. Но не повод…
И не надо говорить о контексте и приводить примеры «а Лобачевский свою геометрию придумал в другом контексте». Он, по крайней мере Эвклидову геометрию знал. А Вы похоже с управлением проектом как деятельностью, или с поддержкой продуктов не сталкивались. Или сталкивались, но даже не пытались изучать чужой опыт, а полагаетесь исключительно на свой собственный опыт «наступить на грабли» и «свой здравый смысл».
Я Вас заверяю, в этой области очень много наработок.
А насчет сумбура в тесте… Перечитайте его сам. Просто бессистемный поток сознания с перескоками с мысли на мысль.
Статья очень вредная. Особенно, для тех кто не совсем в теме.
Вначале я подумал, прочитав заголовок, что это из области управления проектами.
От интерпретации автором стандартных терминов «проект» и «продукт», волосы встали дыбом.
(Автор совсем не понимает ни что такое «проект» ни что «такое „продукт“. Рекомендую ему почитать учебники PMI, и не придумывать свое уникальное понимание очень стандартных и весьма четко сформулированных терминов.)
Прочитав чуть дальше, я понял, что это довольно бессвязный текст из „области“ треп под пиво и „тут Остапа понесло“.
Жаль потраченного времени на такие статьи. Заголовки попроще нужно „Мой опыт в программировании и ответ на главный вопрос жизни, вселенной и всего такого».
У меня хорошо работало в пустой (почти как офисной) комнате.
В специально загроможденной препятствиями комнате (подушки на полу, одежда на спинках стульев) — не очень.
А уж если заслонить ногами (подойти к роботу), то вообще.
Понятно что 4-х маяков маловато.
Но, если честно, я забросил потому что не придумал «а зачем это может пригодится?». Поигрался с автономным движением робота и его ориентацией и забросил. Ну ездит, ну объезжает препятствия и приезжает в заданную точку.
Но, смысл…
Всякие промышленные решение (склад и пр.) я бы просто по другой технологии автоматизировал, чем свободно бродящий по маячкам робот. А вот навигация именно по такому принципу — только для игрушек. Как мне кажется.
Для своего робота похожее делал. Я правда делал маяки (4 маяка) на более дешевых приемниках 433Мгц. (дешевейшие брелки китайские на PT2262)
А на робота пошел какой то китайский модуль RF RS232 (лениво смотреть).
Базовая станция транслирует сигнал на робота, определяющий, какой маяк будет активирован и почти сразу же «жмет» на кнопку брелка.
Робот однозначно определяет какой маяк будет «пищать» и зная расположение и расстояние до маяков позиционирует себя.
Цикл по 4-м маякам — 1 сек. (можно и меньше, но тогда уже не «брелки» нужны).
Точность правда не 2 см. но 5 см в идеале(медленно движется или стоит), в квартире с мебелью — получалась. Очень много ошибок за счет отражений, когда не в прямой видимости маяк. Но все решаемо за счет коррекции (по времени движения) и отбрасывания заведомо ложных расстояний от маяков с отраженным сигналом.
В общем, конечно не просто, но и сказать, что ОЧЕНЬ сложно — нельзя.
Хотя поигрался и надоело. Брелки пошли на автономные датчики сигнализации на дачу. Робот вначале получил манипулятор, камеру поворотную и удаленной управление, а теперь вообще стоит пылится.
Пыль от стеклотекстолита очень вредная. Так что для себя я решил однозначно. Только вода. И еще в воздухе брызгаю пульверизатором, что бы осадить пыль.
Максимальный режим, определенный опытным путем, для фрезы 1мм — заглубление 1мм, подача 300 мм/мин.
Чуть выше — вероятность поломки фрезы.
Фреза стачивается по стеклотекстолиту на 40 минутах работы где то на 0.05-0.1мм. Очень хорошо заметно. Гнездо под подшипник свежей фрезой — подшипник входит с небольшим натягом в 5-6 кг (пальцами). «Уставшей» фрезой ту же деталь — приходится впрессовывать тисочками.
А фреза вся не греется. Вот только кончик у нее до минимум 150 градусов разогревается. Инфракрасным бесконтактным термометром смотрел. А если учесть, что он градусов 10 сектор меряет, то и больше 150.
Да и по цвету видно — черный кончик.
И все это из-за того, что в ANSI X9.24 part 1 алгоритм DUKPT приведен как пример реализации и не является частью стандарта.
Поэтому производители его интерпретируют как им удобно.
Со всякой экзотикой да. А с критичными вещами (PIN Блоки) делают то, что поддерживают наиболее распространенные HSM.
Кому нужен PINPAD или PIN клавиатура банкомата, выдающая PIN блок, для работы с которым нужно что то не стандартное.
А тот же Thales 8000 вообще только два варианта поддерживает.
Перевод, кстати, ужасен. Лучше читать исходную статью.
Откуда у вас такие сведения? Вы можете дать статистику?
Мм… погорячился. Статистика как раз в обратную сторону. Но субъективно, из за уровня проблем и согласований… что бы убедить изменить/включить параллельно HTTP.
… а почему не SOAP1.1?
В основном потому, что это определяется партнерами у которых уже есть работающий сервис, к которому нужно подключится.
<wsdl:definitions… xmlns:soap12=«schemas.xmlsoap.org/wsdl/soap12/» ...wsdl/">
А в тех случая, когда мы свой сервис создаем, то для единобразия, после согласования с партнерами обычно SOAP 1.2
Других аргументов при выборе — нет.
Нет, я считаю, что не нужно изучать ASMX, потому что эта технология устарела, и есть другие технологии, позволяющие достичь тех же результатов.
Вообще то, я с этим даже не спорил! И не говорил, что нужно изучать ASMX.
Только если не путать конкретную технологию (набор библиотек, их описание и способа кодирования в VS) от Microsoft со стеком протоколов, включающих, в данном случае, SOAP.
Понятие разницы надежности между WCF и ASMX — это особенности реализации, которые снаружи (внешнему пользователю сервиса) зачастую не видны.
Ну какая разница, например, на каком движке скажем МТС выдает интерфейс для автоплатежей (хотя догадаться по косвенным признакам можно).
Если будет использоваться WCF в варианте SOAP+HTTP — снаружи никто разницу и не увидит.
В этом смысле — разницы нет. Если удобней разрабатывать с WCF — то пожалуйста.
Но чаще всего, прочему то начинают использовать не, как Вы сказали с «параметры из коробки», и тогда начинаются проблемы.
И вообще, я не сравнивал WCF и ASMX с точки зрения удобства и надежности.
Мне, как пользователю сервиса или как разработчику сервиса НЕ в среде VisaulStudio доступно только SOAP1.2+HTTP. Как только на «той стороне» начинают что то менять и играться с транспортным уровнем, то у меня возникают проблемы.
Про слова SOAP, xsd, wsdl и пр. зачастую разработчики сервисов под VisualStudio даже не знают. У них это все скрыто.
Вот ровно это, я имел в виду. Знать все уровни протокола просто надо. Не агитирую за кодирование на ассемблере собственного стека TCP/IP, но когда складываешь из кубиков, то нужно понимать что за этим скрывается.
Вы понимаете, но почему то считаете, что знание уровня SOAP не нужно.
Или, может быть, я не правильно понял…
Дискуссия, которая открыта Вами, конкретно мне интересно «на посмотреть», но не интересна в прикладном смысле.
Вы lair, спорите (точнее троллите), что лучше ASMX или WCF. И то и другое — исключительно применимо в продуктах MS.
Сервис, разработанный под WCF, с большой вероятностью поддержит только клиент созданные в среде VS.
C поддержкой сервиса на ASMX (SOAP) проблем не будет.
Если Вы считаете, что это не принципиально — Ваше право. Мой опыт взаимодействия с через web-сервисы между разными организациями подсказывает другой.
Да прямого отношения не имеет.
Просто очень хотел бы увидеть если не статью, то хотя бы комментарии по использования SOAP не в среде VS и проблемы совместимости.
В этой статье я расскажу о различных приемах разработки SOAP веб-сервисов по технологии ASMX, а также об этой технологии в целом.
В статье, кстати, нет дискуссий. Это просто примеры.
Считаете, что дискуссия не нужна — значит не нужна.
У нас вообще MS Windows на не используется на продакшен серверах.
И уже сталкивались, с тем, что на нашу просьбу «дайте описание протокола» нам давали кусок кода клиента на .NET 3.0 и говорили «Вот протокол — пользуйтесь».
А на просьбу «дайте wsdl» спрашивали «а что это такое?».
В общем я не верно выразился и не совсем то хотел сказать.
Не протоколы, как таковые, а то что программисты, пишущие под VS даже не подозревают, что мир не ограничен рамками Visual Studio (Кстати, ужасные и не переносимые исходники на C++ под VS получаются)
Есть только одна проблема с новыми протоколами, предлагаемыми Microsoft…
Мир отнюдь не заканчивается на Microsoft Windows, VisualStudio и .NET.
Так что SOAP жив и будет жить. Как раз из за своей относительной простоты и уже наработанных библиотек и пр. для сред, отличных от .NET
Живой пример ряда:
Кусок исходников, которые должны работать после сборки на GCC (Solaris), VisualStudio, под Green компилятор для терминалов Verifone.
И ничего из ряда убрать нельзя.
Ни за что переносимом коде нельзя использовать фичи, появившиеся позже 2000 года…
Иначе сюрпризы будут на каждом шагу.
Я активно (уже 5 шт.) пользую в разных хоббийных задачах.
Про трансфлективность не задумывался. Экран довольно яркий (на максимуме подсветки) и мне этого хватало для всего.
Один раз брал просто экран и отдельный модуль STM32F103Z (максимальный в серии) для робота.
У меня автономный прибор на этой базе живет около 8 часов на аккумуляторе 18650 (но там еще RF приемо-передатчик обеспечивающий эмуляцию RS-232 в полудуплексе на 100м)
Потребление в серии STM32F103 сравнимо с Atmel 8бит.
Значок и сертификат где то дома валяются.
Было обострение по учебе и проектным работам на работе…
3-4 года точно как прошло. Но на данный момент практического смысла подтверждать не вижу (работу не планирую менять...)
А что?
Философстовать на кухне, в курилке и ЖЖ — пожалуйста.
Но на хабре я все же ищу статьи не уровня ЖЖ.
Вы не придумали новый контекст. Начали Вы исключительно в контексте деятельности, которая однозначно попадает под то, что пытаются классифицировать, обобщить и стандартизировать в том же PMI.
Изобретать новую терминологию исходя из своего незнания чего то, и опираясь исключительно на свой ограниченный опыт — это не верный подход. Вас просто не поймут, если вы придумаете свою собственную терминологию пересекающуюся со стандартной.
«ограниченный опыт» — это не оскорбление и не принижение. Опыт у всех ограничен. Но не повод…
И не надо говорить о контексте и приводить примеры «а Лобачевский свою геометрию придумал в другом контексте». Он, по крайней мере Эвклидову геометрию знал. А Вы похоже с управлением проектом как деятельностью, или с поддержкой продуктов не сталкивались. Или сталкивались, но даже не пытались изучать чужой опыт, а полагаетесь исключительно на свой собственный опыт «наступить на грабли» и «свой здравый смысл».
Я Вас заверяю, в этой области очень много наработок.
А насчет сумбура в тесте… Перечитайте его сам. Просто бессистемный поток сознания с перескоками с мысли на мысль.
Вначале я подумал, прочитав заголовок, что это из области управления проектами.
От интерпретации автором стандартных терминов «проект» и «продукт», волосы встали дыбом.
(Автор совсем не понимает ни что такое «проект» ни что «такое „продукт“. Рекомендую ему почитать учебники PMI, и не придумывать свое уникальное понимание очень стандартных и весьма четко сформулированных терминов.)
Прочитав чуть дальше, я понял, что это довольно бессвязный текст из „области“ треп под пиво и „тут Остапа понесло“.
Жаль потраченного времени на такие статьи. Заголовки попроще нужно „Мой опыт в программировании и ответ на главный вопрос жизни, вселенной и всего такого».
Главное в таких вещах даже не сделать, а «продать». Как в прямом, так и переносном смысле.
В специально загроможденной препятствиями комнате (подушки на полу, одежда на спинках стульев) — не очень.
А уж если заслонить ногами (подойти к роботу), то вообще.
Понятно что 4-х маяков маловато.
Но, если честно, я забросил потому что не придумал «а зачем это может пригодится?». Поигрался с автономным движением робота и его ориентацией и забросил. Ну ездит, ну объезжает препятствия и приезжает в заданную точку.
Но, смысл…
Всякие промышленные решение (склад и пр.) я бы просто по другой технологии автоматизировал, чем свободно бродящий по маячкам робот. А вот навигация именно по такому принципу — только для игрушек. Как мне кажется.
Для своего робота похожее делал. Я правда делал маяки (4 маяка) на более дешевых приемниках 433Мгц. (дешевейшие брелки китайские на PT2262)
А на робота пошел какой то китайский модуль RF RS232 (лениво смотреть).
Базовая станция транслирует сигнал на робота, определяющий, какой маяк будет активирован и почти сразу же «жмет» на кнопку брелка.
Робот однозначно определяет какой маяк будет «пищать» и зная расположение и расстояние до маяков позиционирует себя.
Цикл по 4-м маякам — 1 сек. (можно и меньше, но тогда уже не «брелки» нужны).
Точность правда не 2 см. но 5 см в идеале(медленно движется или стоит), в квартире с мебелью — получалась. Очень много ошибок за счет отражений, когда не в прямой видимости маяк. Но все решаемо за счет коррекции (по времени движения) и отбрасывания заведомо ложных расстояний от маяков с отраженным сигналом.
В общем, конечно не просто, но и сказать, что ОЧЕНЬ сложно — нельзя.
Хотя поигрался и надоело. Брелки пошли на автономные датчики сигнализации на дачу. Робот вначале получил манипулятор, камеру поворотную и удаленной управление, а теперь вообще стоит пылится.
Максимальный режим, определенный опытным путем, для фрезы 1мм — заглубление 1мм, подача 300 мм/мин.
Чуть выше — вероятность поломки фрезы.
Фреза стачивается по стеклотекстолиту на 40 минутах работы где то на 0.05-0.1мм. Очень хорошо заметно. Гнездо под подшипник свежей фрезой — подшипник входит с небольшим натягом в 5-6 кг (пальцами). «Уставшей» фрезой ту же деталь — приходится впрессовывать тисочками.
А фреза вся не греется. Вот только кончик у нее до минимум 150 градусов разогревается. Инфракрасным бесконтактным термометром смотрел. А если учесть, что он градусов 10 сектор меряет, то и больше 150.
Да и по цвету видно — черный кончик.
Со всякой экзотикой да. А с критичными вещами (PIN Блоки) делают то, что поддерживают наиболее распространенные HSM.
Кому нужен PINPAD или PIN клавиатура банкомата, выдающая PIN блок, для работы с которым нужно что то не стандартное.
А тот же Thales 8000 вообще только два варианта поддерживает.
Перевод, кстати, ужасен. Лучше читать исходную статью.
Мм… погорячился. Статистика как раз в обратную сторону. Но субъективно, из за уровня проблем и согласований… что бы убедить изменить/включить параллельно HTTP.
В основном потому, что это определяется партнерами у которых уже есть работающий сервис, к которому нужно подключится.
<wsdl:definitions… xmlns:soap12=«schemas.xmlsoap.org/wsdl/soap12/» ...wsdl/">
А в тех случая, когда мы свой сервис создаем, то для единобразия, после согласования с партнерами обычно SOAP 1.2
Других аргументов при выборе — нет.
Вообще то, я с этим даже не спорил! И не говорил, что нужно изучать ASMX.
Только если не путать конкретную технологию (набор библиотек, их описание и способа кодирования в VS) от Microsoft со стеком протоколов, включающих, в данном случае, SOAP.
Ну какая разница, например, на каком движке скажем МТС выдает интерфейс для автоплатежей (хотя догадаться по косвенным признакам можно).
Если будет использоваться WCF в варианте SOAP+HTTP — снаружи никто разницу и не увидит.
В этом смысле — разницы нет. Если удобней разрабатывать с WCF — то пожалуйста.
Но чаще всего, прочему то начинают использовать не, как Вы сказали с «параметры из коробки», и тогда начинаются проблемы.
И вообще, я не сравнивал WCF и ASMX с точки зрения удобства и надежности.
Мне, как пользователю сервиса или как разработчику сервиса НЕ в среде VisaulStudio доступно только SOAP1.2+HTTP. Как только на «той стороне» начинают что то менять и играться с транспортным уровнем, то у меня возникают проблемы.
Про слова SOAP, xsd, wsdl и пр. зачастую разработчики сервисов под VisualStudio даже не знают. У них это все скрыто.
Вот ровно это, я имел в виду. Знать все уровни протокола просто надо. Не агитирую за кодирование на ассемблере собственного стека TCP/IP, но когда складываешь из кубиков, то нужно понимать что за этим скрывается.
Вы понимаете, но почему то считаете, что знание уровня SOAP не нужно.
Или, может быть, я не правильно понял…
Вы lair, спорите (точнее троллите), что лучше ASMX или WCF. И то и другое — исключительно применимо в продуктах MS.
Сервис, разработанный под WCF, с большой вероятностью поддержит только клиент созданные в среде VS.
C поддержкой сервиса на ASMX (SOAP) проблем не будет.
Если Вы считаете, что это не принципиально — Ваше право. Мой опыт взаимодействия с через web-сервисы между разными организациями подсказывает другой.
Просто очень хотел бы увидеть если не статью, то хотя бы комментарии по использования SOAP не в среде VS и проблемы совместимости.
В статье, кстати, нет дискуссий. Это просто примеры.
Считаете, что дискуссия не нужна — значит не нужна.
И уже сталкивались, с тем, что на нашу просьбу «дайте описание протокола» нам давали кусок кода клиента на .NET 3.0 и говорили «Вот протокол — пользуйтесь».
А на просьбу «дайте wsdl» спрашивали «а что это такое?».
В общем я не верно выразился и не совсем то хотел сказать.
Не протоколы, как таковые, а то что программисты, пишущие под VS даже не подозревают, что мир не ограничен рамками Visual Studio (Кстати, ужасные и не переносимые исходники на C++ под VS получаются)
Мир отнюдь не заканчивается на Microsoft Windows, VisualStudio и .NET.
Так что SOAP жив и будет жить. Как раз из за своей относительной простоты и уже наработанных библиотек и пр. для сред, отличных от .NET
Но это, с моей стороны, был сарказм на тему «о вхождение в стандарт языка».
Кусок исходников, которые должны работать после сборки на GCC (Solaris), VisualStudio, под Green компилятор для терминалов Verifone.
И ничего из ряда убрать нельзя.
Ни за что переносимом коде нельзя использовать фичи, появившиеся позже 2000 года…
Иначе сюрпризы будут на каждом шагу.
Странная статья. Ну есть библиотека, ну и что.
Я активно (уже 5 шт.) пользую в разных хоббийных задачах.
Про трансфлективность не задумывался. Экран довольно яркий (на максимуме подсветки) и мне этого хватало для всего.
Один раз брал просто экран и отдельный модуль STM32F103Z (максимальный в серии) для робота.
Потребление в серии STM32F103 сравнимо с Atmel 8бит.