Его запрещено распространять. Можно купить (под подпись, нужна копия паспорта). Распространяют в бумажном виде с уникальным номером и голографической наклейкой.
Может кто-то конечно вылил в паблик, но я когда 2 года назад искал — не нашел. Пришлось покупать у lindex.net.ua/
Для желающих разрабатывать — как-то эту проблему решим.
Мне как .Net-чику — не очень прискорбно читать подобные новости.
И дело даже не в Linux vs Windows. Дело в необдуманной политике MS делать вещи (хорошо хоть не все) ТЯЖЕЛЫМИ И СЛОЖНЫМИ!
Яркий пример — ASP.Net. Постарались сделать так, чтобы разработчик вообще абстрагировался от Web. И что на деле? Пришлось вникать и в Web-технологии и в внутренности работы Asp.Net. Как результат — и разрабатывать сложно и работает медленно.
Хоть бы одну причину оригинальную написали. Ну кто об этом не знает?
Проблема в том, что в мире нет идеального ПО. Те кто используют .Net и Windows — прекрасно знают о его платности, закрытости и пр. Однако используют, ибо бесплатное ПО имеет СВОИ существенные недостатки.
Вы как в воду глядите. Сейчас самое актуальное — распознаватель смысла языка. И сделать для русского языка это сможет только для кого он родной. Кстати, вы просто так сказали или начали работы в этой области?
Данный функционал в некоторой степени предоставляют «программы проактивной защиты». К примеру, Comodo Internet Security. Но т.к. код неуправляемый — 100% гарантии что все будет перехвачено нет.
Для управляемого кода это сделать можно без проблем. Можно даже доработать сабжевую программу, и запускать все управляемые программы с ее помощью с настройками по умолчанию.
Проблема лишь в том что управляемых программ очень мало.
ОС — это неуправляемый код. Последняя попытка написать ОС с использованием управляемого кода (Singularity), насколько мне известно, успехом не увенчалась.
На уровне современной ОС можно очень грубо, в сравнении с управляемым кодом, управлять правами.
Если мы захотим средствами ОС ограничить доступ ко всем файлам на диске С и D для определенной программы — нам прийдется создавать специальную учетную запись (под которой будем в дальнейшем запускать программу) и явно устанавливать права для этой учетки. Кстати, установка прав для пользователя занимает не мало времени.
Наверное зависит от того, будете ли вы для каждого метода приводить примеры и полезное описание. Иначе получается слишком много воды, а это плохо. Кто будет открывать и просматривать всем члены всех классов, дабы найти те 3-4 нещастных метода, где вы разместите примеры?
Просмотрел LibTiff.Net. Красота! Глаз нельзя отвести, как красиво. И себе захотелось так сделать… А вот толку — нуль (я имею в виду та часть, где неймспейсы и классы, а не где примеры и общее описание). Реально, если бы я использовал их библиотеку — мне бы были интересны лишь примеры и общее описание. Остальное легче глянуть в intellisense.
Ну разве что для красоты, для «крутости» имеет смысл это сделать. Чтоб же все видели, что я таки не отстаю от жизни и как все делаю абсолютно никому не нужную автогенеренную документацию (это ж круто!).
И еще одно. MSDN врядли писалась прямо в коде .Net. Это не удобно. Все примеры, все примечания туда втулить. У них наверняка более удобный инструмент. Вот от чего-либо подобного я б не отказался. А автогенеренная документация ТОЛЬКО по коду — не есть гуд. Тем более как ее переводить на другие языки?
Я вот лет 5 назад тоже увидел эту программулину и давай сразу тыкать, применять для всего. Но потом задумался — а кому нафик нужна эта автоматически сгенеренная документация? Особенно если там нет внятных примеров использования кода а всего по 2-3 очевидных объяснения к методу, которые можно и так понять из его названия.
Даже проводил соц. опрос среди разработчиков: полезна эта документация всего 10% разработчиков.
Ну сами подумайте. Скачали какую-нибудь либу. Открываете папку — там 150 Кб либа и 2 Мб документации. В документации только названия методов и очевидное их описание. Ну какой смысл в ТАКОЙ документации? Станете ли вы ее читать?
Нужна документация иного рода, где описывается процесс использования в общем + приведены конкретные примеры. И поменьше воды.
Мне гораздо полезнее примеры использования. Вот на это стоит потратить время. А заниматься пустотой смысла нет. То что так делают все — это не повод транжирить время.
>>Второй эксепшен — это базовый для всех класс Exception, которым ловлю все не мои исключения.
Давайте попробую ответить в ракурсе концепции.
Наверняка вы читали в MSDN, что не рекомендуется перехватывать базовый класс Exception. И как и 90% разработчиков, не найдя в этом большого смысла, проигнорировали эту рекомендацию. На самом деле смысл есть. В первую очередь вы «нейтрализуете» (пытаетесь нейтрализовать) исключения нижнего уровня, к примеру такие как ExecutionEngineException, OutOfMemoryException. В некоторых случаях это может повлечь повреждение данных (программа некоторое время продолжит работу, затем упадет). Как минимум после перехвата вам нужно проверить было ли исключение низкоуровневым и если было — закрыть программу.
Большинство об этом не задумываются. И поскольку низкоуровневые проблемы возникают редко — программа вроде как нормально работает.
>>Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение)
Если я правильно понял, то это первый тип исключений из таблицы? Исключения «нарушения правил бизенс-логики» вы выделяете — это правильно.
Но все-же и исключения «некорректности данных» и «некорректности кода» нужно отличать от «системных» (системные — это низкоуровневые, а не наследники SystemException!).
Некорректные данные выгодно отличать уже потому, что это не ваша вина. Вы всегда можете выдать сообщение пользователю: от сервиса банка «Пупсобанк» получен некорректный ответ. И польователь будет негодовать на их сервис, а не на вашу программу. Именно для этого я и различаю проблемы кода и проблемы данных.
Я вот тоже так думал — нужен контроллер с .Net или Java. После исследования понял — все аппаратно/программные решения, где можно использовать .Net или хотя бы Java — стоят НАМНОГО дороже тех, где можно писать на C.
После недельки вспоминаний C — не пожалел что отказался от высокоуровневых контроллеров. Во-первых, используя C — лучше понимаете архитектуру. Во-вторых, программы реально быстрее работают. Ну и в третьих нет ничего особо сложного в этом C. А то MS подсадила всех на этот наркотик — теперь приходится переплачивать.
Понял. Тогда вы бы могли купить отладочную плату с тем же ARM9 намного проще. А то купили монстра — я и подумал что будете делать что-то с функционалом PDA.
Или вам экран в отладке поможет? Есть же отладчики, вывод данных в терминал…
Очень сомнительно, что вы сможете на базе ARM9 сделать устройство намного дешевле серийных. А то что у КПК больше возможностей — никак не мешает — его можно использовать для нескольких дел одновременно. Иначе прийдется платить за 2 устройства: и за КПК и за ваш прибамбас (не знаю что именно он будет делать).
Т.е. вам нужно сделать миниатюрное устройство, на порядок меньше серийных PDA? Или чем они (готовые устройства) вам не подходят? Если возможностей PDA хватает — то зачем делать новое устройство? Дешевле то вы не сможете сделать…
Может кто-то конечно вылил в паблик, но я когда 2 года назад искал — не нашел. Пришлось покупать у lindex.net.ua/
Для желающих разрабатывать — как-то эту проблему решим.
«не очень прискорбно» следует читать как «очень прискорбно»
И дело даже не в Linux vs Windows. Дело в необдуманной политике MS делать вещи (хорошо хоть не все) ТЯЖЕЛЫМИ И СЛОЖНЫМИ!
Яркий пример — ASP.Net. Постарались сделать так, чтобы разработчик вообще абстрагировался от Web. И что на деле? Пришлось вникать и в Web-технологии и в внутренности работы Asp.Net. Как результат — и разрабатывать сложно и работает медленно.
Будь проще, тупица!
Проблема в том, что в мире нет идеального ПО. Те кто используют .Net и Windows — прекрасно знают о его платности, закрытости и пр. Однако используют, ибо бесплатное ПО имеет СВОИ существенные недостатки.
Кстати, многие пользуются для уничтожения конкурентов — сами постите нелегальный контент и пишите abuse.
Вы как в воду глядите. Сейчас самое актуальное — распознаватель смысла языка. И сделать для русского языка это сможет только для кого он родной. Кстати, вы просто так сказали или начали работы в этой области?
Проблема лишь в том что управляемых программ очень мало.
На уровне современной ОС можно очень грубо, в сравнении с управляемым кодом, управлять правами.
Если мы захотим средствами ОС ограничить доступ ко всем файлам на диске С и D для определенной программы — нам прийдется создавать специальную учетную запись (под которой будем в дальнейшем запускать программу) и явно устанавливать права для этой учетки. Кстати, установка прав для пользователя занимает не мало времени.
Просмотрел LibTiff.Net. Красота! Глаз нельзя отвести, как красиво. И себе захотелось так сделать… А вот толку — нуль (я имею в виду та часть, где неймспейсы и классы, а не где примеры и общее описание). Реально, если бы я использовал их библиотеку — мне бы были интересны лишь примеры и общее описание. Остальное легче глянуть в intellisense.
Ну разве что для красоты, для «крутости» имеет смысл это сделать. Чтоб же все видели, что я таки не отстаю от жизни и как все делаю абсолютно никому не нужную автогенеренную документацию (это ж круто!).
И еще одно. MSDN врядли писалась прямо в коде .Net. Это не удобно. Все примеры, все примечания туда втулить. У них наверняка более удобный инструмент. Вот от чего-либо подобного я б не отказался. А автогенеренная документация ТОЛЬКО по коду — не есть гуд. Тем более как ее переводить на другие языки?
Я вот лет 5 назад тоже увидел эту программулину и давай сразу тыкать, применять для всего. Но потом задумался — а кому нафик нужна эта автоматически сгенеренная документация? Особенно если там нет внятных примеров использования кода а всего по 2-3 очевидных объяснения к методу, которые можно и так понять из его названия.
Даже проводил соц. опрос среди разработчиков: полезна эта документация всего 10% разработчиков.
Ну сами подумайте. Скачали какую-нибудь либу. Открываете папку — там 150 Кб либа и 2 Мб документации. В документации только названия методов и очевидное их описание. Ну какой смысл в ТАКОЙ документации? Станете ли вы ее читать?
Нужна документация иного рода, где описывается процесс использования в общем + приведены конкретные примеры. И поменьше воды.
Мне гораздо полезнее примеры использования. Вот на это стоит потратить время. А заниматься пустотой смысла нет. То что так делают все — это не повод транжирить время.
Давайте попробую ответить в ракурсе концепции.
Наверняка вы читали в MSDN, что не рекомендуется перехватывать базовый класс Exception. И как и 90% разработчиков, не найдя в этом большого смысла, проигнорировали эту рекомендацию. На самом деле смысл есть. В первую очередь вы «нейтрализуете» (пытаетесь нейтрализовать) исключения нижнего уровня, к примеру такие как ExecutionEngineException, OutOfMemoryException. В некоторых случаях это может повлечь повреждение данных (программа некоторое время продолжит работу, затем упадет). Как минимум после перехвата вам нужно проверить было ли исключение низкоуровневым и если было — закрыть программу.
Большинство об этом не задумываются. И поскольку низкоуровневые проблемы возникают редко — программа вроде как нормально работает.
>>Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение)
Если я правильно понял, то это первый тип исключений из таблицы? Исключения «нарушения правил бизенс-логики» вы выделяете — это правильно.
Но все-же и исключения «некорректности данных» и «некорректности кода» нужно отличать от «системных» (системные — это низкоуровневые, а не наследники SystemException!).
Некорректные данные выгодно отличать уже потому, что это не ваша вина. Вы всегда можете выдать сообщение пользователю: от сервиса банка «Пупсобанк» получен некорректный ответ. И польователь будет негодовать на их сервис, а не на вашу программу. Именно для этого я и различаю проблемы кода и проблемы данных.
Вот именно! Так что много времени вы не выиграете. Да и вообще Си более подходит для низкого уровня. Более экономный язык, скажем так.
Кстати, вы же можете эту ОС (или что там) использовать на другой железке с ARM9? Или лицензия не позволяет?
После недельки вспоминаний C — не пожалел что отказался от высокоуровневых контроллеров. Во-первых, используя C — лучше понимаете архитектуру. Во-вторых, программы реально быстрее работают. Ну и в третьих нет ничего особо сложного в этом C. А то MS подсадила всех на этот наркотик — теперь приходится переплачивать.
Или вам экран в отладке поможет? Есть же отладчики, вывод данных в терминал…