http://code.google.com/android/
http://www.openhandsetalliance.com/
Blog:
http://android-developers.blogspot.com/2007/11/android-first-week.html
оттуда интересная статья:
http://www.onlamp.com/pub/a/onlamp/2007/11/12/google-calling-inside-the-gphone-sdk.html
http://devphone.com/category/android
Поднимается очень сильный ветер...
2007-11-17
2007-11-13
Java и JVM - туда и обратно
Programming Languages for the Java Virtual Machine
http://www.robert-tolksdorf.de/vmlanguages.html
Java Implementations
Старый каталог: http://www.dwheeler.com/java-imp.html
IBM: http://www.ibm.com/developerworks/java
BEA: http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/jrockit/
GNU: http://www.gnu.org/software/java/
bonus: http://www.gnu.org/software/java/java-software.html
Google: http://en.wikipedia.org/wiki/Dalvik_virtual_machine
http://www.robert-tolksdorf.de
Java Implementations
Старый каталог: http://www.dwheeler.com/java
IBM: http://www.ibm.com/developerwo
BEA: http://www.bea.com/framework
GNU: http://www.gnu.org/software
bonus: http://www.gnu.org/software
Google: http://en.wikipedia.org/wiki/Dalvik_virtual_machine
2007-10-14
Преимущества Java для разработки server side jobs.
Преимущества:
1. Широко известная возможность Java программ работать на разных платформах БЕЗ ПЕРЕКОМПИЛЯЦИИ.
Т.е. тщательно оттестированная программа, с большой вероятностью (если зависимости от платформы не внес по небрежности сам программист, но это находится и правится)
будет работать везде, где есть эта и выше версия JRE.
С использованием .conf-файлов, можно вынести все платформозависимые части из исходников (ex: пути к shell скриптам, regexp для разбора вывода shell скриптов, etc).
С использованием wrappers, таких как: http://wrapper.tanukisoftware.org/ можно запустить программу как сервис Windows или демон Linux/Solaris/HPUX/etc.
2. Дополнительный уровень абстракции (JVM и байт-код), позволяют меньше беспокоиться о том, что
- сервис “завалит” всю платформу или
- будет найдена уязвимость позволяющая получить права root unsafe коду.
Использование JDBC драйверов написанных полностью на Java, позволяет сократить количество ПО, которое требуется установить на сервер.
3. В отличие от (обычно) монолитного .exe файла, в который слито все, что нужно для работы. Классы Java образуют истинную модульность, позволяя модифицировать (обновлять) небольшие куски приложения, ДИНАМИЧЕСКИ определять что будет загружено и догружать по мере необходимости (в том числе из БД, сети).
4. Для Java существует большое количество функционально богатых широко протестированных библиотек логирования, с возможностью удобно группировать логируемую информацию по категории (обычно полный.путь.к.классу.Класс) и важности (trace, debug, info, warn, error). Без каких-либо изменений в исходном коде, логирование может быть отфильтровано, перенаправлено на консоль, по почте, в syslog, БД, файл, и даже лог windows. Новые библиотеки, такие как http://slf4j.org/ позволяют варьировать фактическую библиотеку логирования на конечной системе и практически до нуля снизить потерю производительности от логирования (параметризованые сообщения и отключение лишних логов).
5. Исключения Java помимо традиционных ТИПА исключения и поясняющего сообщения (message) содержат:
а) полный стек на момент создания исключения (stackTrace), включающий названия классов, методов, исходных файлов и номера строк в них;
б) «причину» (cause) - другое исключение (которое также может содержать cause), которое явилось причиной создания этого, что позволяет не тащить на верхние уровни абстракции низкоуровневые исключения, но при желании иметь возможность детально разобраться в том, что случилось.
6. Наиболее важным достижением (можно сказать уникальным на сегодняшний день) Java можно считать т.н. checked exceptions.
Если Вы встретите того, кто уверяет, что checked exceptions это плохо, смело плюньте ему в глаза.
Для разработки надежных устойчивых приложений checked exceptions полезны чрезвычайно!
Поясню на примере: в простом коде, открывающем соединение к БД, выполняющем запрос и генерирующем по полученным данным файл, порядка 80% строк могут сгенерировать исключения (драйверов БД нет, ошибка подключения к БД, ошибка работы с БД, ошибка работы с файлом и т.д.).
В случае Java и checked exceptions компилятор предупредит Вас обо всех проблемных участках и предложит что-то сделать (игнорировать, передавать наверх в чистом виде, передавать наверх «обернув», обрабатывать), т.е. полученный код сразу, после того как скомпилируется, будет устойчив к большинству ошибок! Это разительно отличается от ситуации, например, в Delphi, где любой вызов стандартной библиотеки, библиотеки логирования, библиотеки доступа к БД и т.д. может закончиться неожиданным исключением. Частично Вы найдете описание генерируемых исключений в документации, частично будете отлавливать в течении длительного времени, в процессе рабочей эксплуатации.
7. Мелкая радость для тех, кто в теме: sleep, wait, join и т.д. можно прервать из другого потока и они сгенерируют InterruptedException. На Delphi у меня была собственная библиотека с наследником Thread и заменой sleep (используя события).
К замеченным недостаткам Java можно отнести:
1. Крайне потребительское отношение к оперативной памяти. Java очень любит память ;-(
2. Меньший объем предложений хостинга в сравнении с PHP и Perl.
p.s.
Мелкие хотелки по синтаксису языка (syntax sugar ;-)
1. is вместо instanceof.
2. Объект as Тип вместо (Тип)объект т.к. приходится почти всегда делать ((Тип)объект).метод.
3. in для любых типов и .. для перечислимых типов, т.е:
чтобы можно было писать if (myStr in ("bla", "БЛА", "BLA", "бла")), if (myInt in (1,5,7..300)),
case 1..300: case 400:.
4. чтобы в switch () case могли участвовать любые объекты, а не только целые и enum.
Т.е. тщательно оттестированная программа, с большой вероятностью (если зависимости от платформы не внес по небрежности сам программист, но это находится и правится)
будет работать везде, где есть эта и выше версия JRE.
С использованием .conf-файлов, можно вынести все платформозависимые части из исходников (ex: пути к shell скриптам, regexp для разбора вывода shell скриптов, etc).
С использованием wrappers, таких как: http://wrapper.tanukisoftware.org/ можно запустить программу как сервис Windows или демон Linux/Solaris/HPUX/etc.
2. Дополнительный уровень абстракции (JVM и байт-код), позволяют меньше беспокоиться о том, что
- сервис “завалит” всю платформу или
- будет найдена уязвимость позволяющая получить права root unsafe коду.
Использование JDBC драйверов написанных полностью на Java, позволяет сократить количество ПО, которое требуется установить на сервер.
3. В отличие от (обычно) монолитного .exe файла, в который слито все, что нужно для работы. Классы Java образуют истинную модульность, позволяя модифицировать (обновлять) небольшие куски приложения, ДИНАМИЧЕСКИ определять что будет загружено и догружать по мере необходимости (в том числе из БД, сети).
4. Для Java существует большое количество функционально богатых широко протестированных библиотек логирования, с возможностью удобно группировать логируемую информацию по категории (обычно полный.путь.к.классу.Класс) и важности (trace, debug, info, warn, error). Без каких-либо изменений в исходном коде, логирование может быть отфильтровано, перенаправлено на консоль, по почте, в syslog, БД, файл, и даже лог windows. Новые библиотеки, такие как http://slf4j.org/ позволяют варьировать фактическую библиотеку логирования на конечной системе и практически до нуля снизить потерю производительности от логирования (параметризованые сообщения и отключение лишних логов).
5. Исключения Java помимо традиционных ТИПА исключения и поясняющего сообщения (message) содержат:
а) полный стек на момент создания исключения (stackTrace), включающий названия классов, методов, исходных файлов и номера строк в них;
б) «причину» (cause) - другое исключение (которое также может содержать cause), которое явилось причиной создания этого, что позволяет не тащить на верхние уровни абстракции низкоуровневые исключения, но при желании иметь возможность детально разобраться в том, что случилось.
6. Наиболее важным достижением (можно сказать уникальным на сегодняшний день) Java можно считать т.н. checked exceptions.
Если Вы встретите того, кто уверяет, что checked exceptions это плохо, смело плюньте ему в глаза.
Для разработки надежных устойчивых приложений checked exceptions полезны чрезвычайно!
Поясню на примере: в простом коде, открывающем соединение к БД, выполняющем запрос и генерирующем по полученным данным файл, порядка 80% строк могут сгенерировать исключения (драйверов БД нет, ошибка подключения к БД, ошибка работы с БД, ошибка работы с файлом и т.д.).
В случае Java и checked exceptions компилятор предупредит Вас обо всех проблемных участках и предложит что-то сделать (игнорировать, передавать наверх в чистом виде, передавать наверх «обернув», обрабатывать), т.е. полученный код сразу, после того как скомпилируется, будет устойчив к большинству ошибок! Это разительно отличается от ситуации, например, в Delphi, где любой вызов стандартной библиотеки, библиотеки логирования, библиотеки доступа к БД и т.д. может закончиться неожиданным исключением. Частично Вы найдете описание генерируемых исключений в документации, частично будете отлавливать в течении длительного времени, в процессе рабочей эксплуатации.
7. Мелкая радость для тех, кто в теме: sleep, wait, join и т.д. можно прервать из другого потока и они сгенерируют InterruptedException. На Delphi у меня была собственная библиотека с наследником Thread и заменой sleep (используя события).
К замеченным недостаткам Java можно отнести:
1. Крайне потребительское отношение к оперативной памяти. Java очень любит память ;-(
2. Меньший объем предложений хостинга в сравнении с PHP и Perl.
p.s.
Мелкие хотелки по синтаксису языка (syntax sugar ;-)
1. is вместо instanceof.
2. Объект as Тип вместо (Тип)объект т.к. приходится почти всегда делать ((Тип)объект).метод.
3. in для любых типов и .. для перечислимых типов, т.е:
чтобы можно было писать if (myStr in ("bla", "БЛА", "BLA", "бла")), if (myInt in (1,5,7..300)),
case 1..300: case 400:.
4. чтобы в switch () case могли участвовать любые объекты, а не только целые и enum.
2006-11-24
Удобный доступ к сайтам в zip архиве
Обнаружил интересную возможность: нормально просматривать сайт, сохраненный в локальном zip архиве.
Т.е. имеем скачанный ручками, teleport Pro или иным способом сайт.
Он представляет из себя кучу мелких файликов (сжирающих на NTFS кратное 4к место и безобразно выглядящих).
Если сжимаем в ZIP становится красиво и компактно, но сложно пользоваться (ссылки не работают, картинки не показываются).
Решение:
ставим JDK
после чего задаем в Firefox путь вида:
jar:file:///D:/DOC/mysite.zip!/dir1//index.htm
работает практически прозрачно (есть мелкие глюки с JS)
Т.е. имеем скачанный ручками, teleport Pro или иным способом сайт.
Он представляет из себя кучу мелких файликов (сжирающих на NTFS кратное 4к место и безобразно выглядящих).
Если сжимаем в ZIP становится красиво и компактно, но сложно пользоваться (ссылки не работают, картинки не показываются).
Решение:
ставим JDK
после чего задаем в Firefox путь вида:
jar:file:///D:/DOC/mysite.zip!/dir1//index.htm
работает практически прозрачно (есть мелкие глюки с JS)
2006-10-13
На память: нужна ли лицензия контент-провайдеру?
Очередным субъектом налоговых претензий ФНС стали "Мобильные ТелеСистемы".
Наряду с "ВымпелКомом" МТС придется отстаивать правоту отнесения расходов на услуги контент-провайдеров к расходам по налогу на прибыль.
Продолжение под катом...
Наряду с "ВымпелКомом" МТС придется отстаивать правоту отнесения расходов на услуги контент-провайдеров к расходам по налогу на прибыль.
Александр Титов - выпускник МГЮА; общий стаж юридической
практики более 4-х лет. Работал в юридическом отделе Управления Россвязьнадзора
по Москве и Московской области, в телекоммуникационных компаниях.
Александр Титов занимается аналитическими исследованиями законодательства в
области связи, юридическим консалтингом, правовым сопровождением деятельности
операторов связи.
Член постоянно действующей рабочей группы по проблемам развития систем
беспроводного широкополосного фиксированного доступа отраслевого отделения
"Операторы связи" Общероссийской общественной организации "Деловая Россия".
Читать все колонки автора
Продолжение под катом...
Федеральная налоговая служба (ФНС) насчитала МТС недоимку по итогам проверки отчетности за 2003-2004 гг. в размере 1,28 млрд. руб., в том числе 0,3 млрд. руб. штрафов и пеней, сообщается в пресс-релизе компании. Первоначальный размер претензий составлял 1,14 млрд. руб. (без пеней и штрафов), но с учетом возражений МТС сумма была снижена до 976 млн руб. Основная сумма претензий связана с неправильным, по мнению налоговых инспекторов, исчислением налогов по взаиморасчетам МТС с контент-провайдерами. Контент-провайдеры работают без лицензий на оказание услуг связи, поэтому налоговики не признают вознаграждение, которое выплачивает им МТС, расходами и считают, что оператор должен был заплатить с этого вознаграждения налог на прибыль, поясняет пресс-секретарь оператора Кирилл Алявдин.
Если не рассматривать налоговых аспектов данных претензий, то принципиальным является вопрос лицензирования контент-провайдеров. Как ранее сообщалось, разъяснение Мининформсвязи о том, что лицензию на телематические услуги должны получать не только операторы, но и взаимодействующие с их сетями фирмы, появилось только в 2005 году. Данный тезис является неоднозначным. В функции Мининформсвязи не входят вопросы лицензирования, и разъяснения в этой сфере Министерство давать не может. Сфера лицензирования отнесена п.5.4 Положения о Федеральной службе по надзору в сфере связи, утвержденного постановлением Правительства РФ от 30 июня 2004 г. N 318 к компетенции Россвязьнадзора, который в соответствии с п. 6.2 названного положения уполномочен давать разъяснения государственным органам, органам местного самоуправления, юридическим и физическим лицам по вопросам, отнесенным к сфере ведения службы. Таким образом, налоговые органы могут руководствоваться только позицией Россвязьнадзора в вопросе лицензирования контент-провайдинга.
Хозяйствующий субъект должен решать вопрос необходимости получения лицензии на тот или иной вид деятельности исходя из четких положений законодательства. В соответствии с 29 статьей Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" деятельность юридических лиц и индивидуальных предпринимателей по возмездному оказанию услуг связи осуществляется только на основании лицензии на осуществление деятельности в области оказания услуг связи. Перечень наименований услуг связи, вносимых в лицензии, и соответствующие перечни лицензионных условий устанавливаются Правительством Российской Федерации и ежегодно уточняются.
Итак, закон устанавливает три критерия, по которым определяется необходимость получения лицензии на деятельность в области оказания услуг связи. Первым из них является - лицензироваться должна услуга связи. Вторым является указание на такую услугу в перечне наименований услуг связи, вносимых в лицензии. И третьим критерием является возмездность услуги связи.
Анализируя деятельность контент-провайдеров по указанным в законе критериям можно отметить следующее:
1. Определение услуги связи приводится в статье 2 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи". Под услугой связи понимается деятельность по приему, обработке, хранению, передаче, доставке сообщений электросвязи или почтовых отправлений. Рассматривая данное определение услуги, необходимо установить какие конкретно из перечисленных видов деятельности осуществляет контент-провайдер. Если услуга контент-провайдера осуществляется с использованием, принадлежащим ему технических средств то контент-провайдер осуществляет деятельность по приему запросов абонентов о получении контента, обработке запроса и передаче контента абоненту. Запрос абонента и конент являются сообщениями электросвязи. Доставку контента осуществляет оператор сети подвижной связи. Таким образом, можно констатировать, что деятельность контент-провайдеров соответствует данному критерию, если услуга оказывается на принадлежащих ему технических средствах. Если же техническое обеспечение оказания услуги возложено не на контент-провайдера, а на самого оператора подвижной связи или сервис-провайдера, то деятельность контент-провайдера по продаже контента не образует услугу связи.
2. Перечень наименований услуг связи, вносимых в лицензии, определен постановлением Правительства Российской Федерации от 18 февраля 2005 г. N 87 "Об утверждении перечня наименований услуг связи, вносимых в лицензии, и перечней лицензионных условий". В перечень лицензируемых услуг связи пунктом 16 включены телематические услуги связи. Раздел XVI перечня лицензионных условий определяет лицензионные условия осуществления деятельности в области оказания телематических услуг связи. Подпункт в) пункта 4 раздела предполагает обеспечение при оказании телематических услуг связи предоставления абоненту и (или) пользователю доступа к информации мировых и региональных информационно-телекоммуникационных сетей, в том числе к сети Интернет. Деятельность контент-провайдеров может быть квалифицирована как деятельность по предоставлению абоненту и (или) пользователю доступа к информации информационно-телекоммуникационной сети. Соответственно она может рассматриваться в качестве лицензируемой телематической услуги связи.
3. И последним принципиально важным критерием является критерий возмездности. В письме Минсвязи России N5279 "О позиции Минсвязи России по проблеме доступа в сеть Интернет из библиотек" регулятор рекомендовал библиотекам, оказывающим читателям услуги доступа в Интернет за плату, отказаться от взимания такой платы, чтобы избежать необходимости получения лицензии на оказание услуг связи. Таким образом, сам по себе факт оказания услуги не приводит к необходимости получения лицензии, если только за эту услугу не взимается плата.
Применительно к сервисам контент-провайдеров предполагающим только продажу контента, необходимо отметить, что ценность в этой услуге образует сам контент, а не деятельность по обеспечению его передачи в память сотового телефона т.е. услуга связи. Абонент платит за передачу ему конент-провайдером права однократной записи объекта интеллектуальной собственности (рингтона, логотипа, фото и т.п.) в память его телефона. Сама же услуга связи, при этом присутствует, однако такая услуга может быть принята контент-провайдером по стоимости равной нулю, т.е. оказываться бесплатно в целях обеспечения абоненту получения контента в память телефона. Сама по себе продажа контента не требует получения лицензии на деятельность в области связи; оборот прав на объекты авторского и смежных прав регулирует Закон РФ от 9 июля 1993 г. N 5351-I "Об авторском праве и смежных правах" и ряд других нормативно-правовых актов в области интеллектуальной собственности.
Высказывая собственную точку зрения, предположу, что контент-провайдер может избежать необходимости получения лицензии на телематические услуги связи, декларируя эти услуги в качестве безвозмездных, направленных на техническое обеспечение продажи контент-провайдером самого контента (точнее права его записи в сотовый терминал) абонентам.
2006-10-11
Google Office
Можно сказать, что пакет сетевых программ Google Office готов.
Есть
* замечательная почта и менеджер контактов: http://gmail.com,
* календарь и органайзер: http://calendar.google.com,
* IM с функциями IP телефонии и голосовой почты: http://talk.google.com,
* записная книжка и todo list: http://www.google.com/notebook
* решение для бизнеса: https://www.google.com/a/
* для территориально распределенного бизнеса, конечно, карты:
http://earth.google.com/, http://maps.google.com/, http://sketchup.google.com/
и, наконец, недавно объявленный, Word + Excel в одном флаконе:
http://docs.google.com
Короткий, но познавательный тур по данному продукту
http://www.google.com/google-d-s/tour1.html
Главное достоинство всех продуктов доступность отовсюду, с чего угодно и возможность командной работы.
Также как человек, который работал с корпоративными web based системами, должен отметить, что продукты Google приятно быстрые.
Update:
* calendar.google.com позволяет отправлять SMS на телефоны СНГ-операторов
* Как разместить карту путешествия на своем сайте. Вариант использования для транспортных компаний и такси: где находится Ваш груз, Ваша машина, сколько машин в вашем районе.
Есть
* замечательная почта и менеджер контактов: http://gmail.com,
* календарь и органайзер: http://calendar.google.com,
* IM с функциями IP телефонии и голосовой почты: http://talk.google.com,
* записная книжка и todo list: http://www.google.com/notebook
* решение для бизнеса: https://www.google.com/a/
* для территориально распределенного бизнеса, конечно, карты:
http://earth.google.com/, http://maps.google.com/, http://sketchup.google.com/
и, наконец, недавно объявленный, Word + Excel в одном флаконе:
http://docs.google.com
Короткий, но познавательный тур по данному продукту
http://www.google.com/google-d-s/tour1.html
Главное достоинство всех продуктов доступность отовсюду, с чего угодно и возможность командной работы.
Также как человек, который работал с корпоративными web based системами, должен отметить, что продукты Google приятно быстрые.
Update:
* calendar.google.com позволяет отправлять SMS на телефоны СНГ-операторов
* Как разместить карту путешествия на своем сайте. Вариант использования для транспортных компаний и такси: где находится Ваш груз, Ваша машина, сколько машин в вашем районе.
2006-09-27
2006-08-23
Ленивая оптимизация программ на Delphi/BCB
Обычно говоря про оптимизацию, мы подразумеваем бессонные ночи в обнимку с профайлером, поиск более эффективных алгоритмов и изучение сгенерированного кода в дизассемблере.
На этом фоне выделяются два замечательных проекта, которые позволяют ускорить работу программы, просто добавив пару модулей в uses dpr файла.
1) альтернативный менеджер памяти FastMM
http://fastmm.sf.net/
последняя версия 4.70
настолько хорош, что Borland заменила им стандартный менеджер в BDS2006.
В составе идет замена borlndmm.dll (Shared Memory Manager) позволяющая заметно ускорить работу самой IDE.
2) проект FastCode, FastMove.
http://www.fastcodeproject.org/
http://fastcode.sourceforge.net/
Я использовал только FastMove, но качать придется и FastCode, т.к. FastMove использует один небольшой модуль из него.
Замена стандартных функций Delphi (таких как move) на ускоренные аналоги (MMX, etc) с патчем в runtime.
Т.е. в обоих случаях в своих исходниках ничего менять не нужно, кроме как добавить
Uses FastMove, FastMM4 в начале dpr файла.
Вчера, наконец, дошли руки – написал тестовую программу, работающую с сокетами (отправляющую и принимающую бинарные пакеты). Ускорение работы с FastMove+FastMM4 практически двукратное, совершенно на ровном месте (я особо не выделяю память и не использую move)!
Будет интересно увидеть ваши результаты на таких же бытовых программах!
На этом фоне выделяются два замечательных проекта, которые позволяют ускорить работу программы, просто добавив пару модулей в uses dpr файла.
1) альтернативный менеджер памяти FastMM
http://fastmm.sf.net/
последняя версия 4.70
настолько хорош, что Borland заменила им стандартный менеджер в BDS2006.
В составе идет замена borlndmm.dll (Shared Memory Manager) позволяющая заметно ускорить работу самой IDE.
2) проект FastCode, FastMove.
http://www.fastcodeproject.org/
http://fastcode.sourceforge.net/
Я использовал только FastMove, но качать придется и FastCode, т.к. FastMove использует один небольшой модуль из него.
Замена стандартных функций Delphi (таких как move) на ускоренные аналоги (MMX, etc) с патчем в runtime.
Т.е. в обоих случаях в своих исходниках ничего менять не нужно, кроме как добавить
Uses FastMove, FastMM4 в начале dpr файла.
Вчера, наконец, дошли руки – написал тестовую программу, работающую с сокетами (отправляющую и принимающую бинарные пакеты). Ускорение работы с FastMove+FastMM4 практически двукратное, совершенно на ровном месте (я особо не выделяю память и не использую move)!
Будет интересно увидеть ваши результаты на таких же бытовых программах!
2006-08-21
2006-08-13
Что мешает Java-счастью. Взгляд со стороны.
Я не являюсь Java разработчиком, можно сказать, что я присматриваюсь.
На текущий момент есть всего две альтернативы Java или .NET.
Мне верится, что "правда" за свободным сообществом Java разработчиков.
Небольшое изучение вопроса показало его (общества, Java) болевые точки.
Буду рад, если кто-то более знающий прокомментирует мои наблюдения.
1. Разброд в рядах. Та же самая болезнь, которая вредит unix/linux/остальным подобным проектам. Конкурент - Microsoft - монолитен, согласован и напоминает шеренгу спартанцев.
В рядах же не-Microsoft разработчиков беснуется Новодворская Ричард Столман, тянут в разные стороны разобщенные группы фанатов PHP, C, Python, Perl и т.д., развивается кукушонок Mono.
На заре "раздела мира" похожая ситуация, когда производители UNIX, существенно превосходивших DOS-Windows, воевали между собой – привела к победе Microsoft.
Наиболее опасным я считаю две вещи:
1) Отсутствие Java доминирования. Заслуга Microsoft в том, что там поняли, как важно иметь ОДИН язык разработки (пусть вас не смущает рекламная шелуха про любые языки на .NET – фактически язык один C#). Из бытовых примеров правильности такого подхода мы видим Английский Язык (до развала СССР ещё Русский Язык). Когда люди ДУМАЮТ на одном языке – количество переходит в качество. Снижаются накладные расходы на переводчиков, издание книг об одном и том же на разных языках, люди более коммуникабельны и т.д. Microsoft жестко и даже с потерей доходов указало фанатам C++, а особенно VB – что их место у параши. "Или учишь C# или остаешься разработчиком второго сорта". В другом же лагере махровым цветом цветут С-сектанты и куча мелких языковых народностей.
2) Mono - проект кукушонок или для желающих троянский конь. Как некогда на заседание антимонопольного суда представитель Microsoft пришел с дистрибутивом Linux, так и Mono является такой же обманкой кросс-платформенности .NET. Рассмотрим живой пример: менеджер нового проекта решает, на чем вести разработку: Linux+Mono+Delphi.Net или Microsoft Windows+.NET+C#. Linux+Mono+Delphi.Net прекрасны, функциональны и открыты, но они вторичны. Менеджеру не нужны будущие потенциальные проблемы несовместимости с новыми версиями .NET. Никто не знает Microsoft лучше Microsoft. Если вы считаете, что пример надуман – вспомните odbc, ole db, ado, ado.net или VB vs Delphi. Всем людям с нормальной психикой было ясно, что Delphi в разы превосходит убогий чудовищный VB, тем не менее, сформирован огромный лагерь умственно отсталых VB разработчиков, которые даже любят это убожество.
Вывод: в качестве решения вижу создание крепкой дружной коалиции, в лице коммерческих организаций (Google, Sun, IBM, Oracle) и open source разработчиков (Linux, Apache, Open Office, Mozilla) выступающих единым фронтом, с единым мнением и комплексными интегрированными решениями: Linux+Java+Web.
2. Оптимизация быстродействия и требования к ресурсам.
Эта тема чрезвычайно интересна тем, что мнения по ней сугубо полярны.
Java разработчики: "программы на Java работают ничуть не медленнее, чем программы на C++/Delphi, а зачастую даже быстрее. Требования к ресурсам у них минимальны".
Пользователи Java разработок: "все безумно тормозит и жрет уйму ресурсов".
Небольшой поиск в Internet приносит материалы (охотно поверю, что рекламные) о том, что .NET приложения быстрее, чем приложения на Java.
Мне кажется, что сообществу Java/Sun/IBM следует привлечь хороших специалистов двух типов:
a) по оптимизации кода, менеджерам памяти и т.д.
b) по маркетингу и PR ;-)
Вывод: всегда есть, что улучшить! Вот горячий пример этого года: fastmm.sf.net – менеджер памяти для Delphi/BCB ускоряющий работу программ в РАЗЫ.
3. Интерфейс пользователя.
Больной вопрос, поскольку Java выросла из UNIX мира, где интерфейсы рисуют студенты второкурсники с гипертрофированной манией величия и отсутствием вкуса. Сейчас ситуация улучшается и desktop приложения на Java уже выглядят как плохенькие Windows приложения, но нельзя на этом останавливаться. Без завоевания Desktop все остальные победы временные. Любимый пример Java-разработчиков в таких случаях Borland JBuilder. Безусловно, отличная IDE! Недостижимый для большинства Java-разработчиков идеал, но начинающий разработчик на Delphi сделает такую IDE (без функционала, конечно :-) за несколько часов.
Вывод: поскольку Windows занимает доминирующие позиции на Desktop, и пользователи избалованы стильным дизайном от Microsoft – красивый стильный GUI для Java приложения должен стать не достижением, а нормой (видно что разработчики OpenOffice это поняли и результат не замедлил сказаться).
4. Кросс-платформенность в ширь и в глубь.
"В ширь" - означает большее количество платформ доступных по умолчанию.
Наиболее кричащий пример Pocket PC. Если для коммуникаторов на борту идет какая-то х.з J2ME, то для остальных ситуация просто удручающая. Нужно срочно исправлять положение: для мощных КПК разработать стандартную J2SE, для слабых/мобильных стандартную J2ME.
"В глубь" легче пояснить шуткой про Амфибию, которая плохая лодка и плохой автомобиль. Кросс-платформенность не должна означать, что на всех платформах программа работает одинаково плохо ;-)
На вскидку два примера:
1) "как запустить это чертово Java приложение". Я скачал и установил у себя свежий JRE, но ни .class файлы, ни .jar файлы не запускаются по клику. От запуска программ строкой в Command Line вида "java -ClassPath . bla.bla.bla" надо уходить, на дворе не 1980 год! (да, да, да! JBuilder запускается по клику – возьмите с полки пирожок).
2) Java daemon под Windows (NT service). Я не нашел простого быстрого способа запустить приложение на Java как сервис. Имеется в виду не только "запуск", но и получение и обработка событий suspend, resume, stop, а также работа с EventLog.
Это совершенно нормальные требования и если отмахиваться от них, то Java так и останется чем-то далеким и пугающим.
Вывод: расти в ширь и в глубь, не слушать крики "а нас все устраивает, у нас связка Oracle+Tomcat+IE" т.е. основательно идти на PDA и Desktop.
PS: Если кто-то говорит Java, .NET какая разница – мы на всем пишем. Знайте перед вами типичная "амфибия" ;-)
Настоящий профессионализм подразумевает многолетнюю практику, когда человек думает на языке и в терминах используемой библиотеки классов.
Любой Job-сайт показывает, что на должность простого кодера требуют 2 года опыта, архитектора до 5 и выше.
На текущий момент есть всего две альтернативы Java или .NET.
Мне верится, что "правда" за свободным сообществом Java разработчиков.
Небольшое изучение вопроса показало его (общества, Java) болевые точки.
Буду рад, если кто-то более знающий прокомментирует мои наблюдения.
1. Разброд в рядах. Та же самая болезнь, которая вредит unix/linux/остальным подобным проектам. Конкурент - Microsoft - монолитен, согласован и напоминает шеренгу спартанцев.
В рядах же не-Microsoft разработчиков беснуется Новодворская Ричард Столман, тянут в разные стороны разобщенные группы фанатов PHP, C, Python, Perl и т.д., развивается кукушонок Mono.
На заре "раздела мира" похожая ситуация, когда производители UNIX, существенно превосходивших DOS-Windows, воевали между собой – привела к победе Microsoft.
Наиболее опасным я считаю две вещи:
1) Отсутствие Java доминирования. Заслуга Microsoft в том, что там поняли, как важно иметь ОДИН язык разработки (пусть вас не смущает рекламная шелуха про любые языки на .NET – фактически язык один C#). Из бытовых примеров правильности такого подхода мы видим Английский Язык (до развала СССР ещё Русский Язык). Когда люди ДУМАЮТ на одном языке – количество переходит в качество. Снижаются накладные расходы на переводчиков, издание книг об одном и том же на разных языках, люди более коммуникабельны и т.д. Microsoft жестко и даже с потерей доходов указало фанатам C++, а особенно VB – что их место у параши. "Или учишь C# или остаешься разработчиком второго сорта". В другом же лагере махровым цветом цветут С-сектанты и куча мелких языковых народностей.
2) Mono - проект кукушонок или для желающих троянский конь. Как некогда на заседание антимонопольного суда представитель Microsoft пришел с дистрибутивом Linux, так и Mono является такой же обманкой кросс-платформенности .NET. Рассмотрим живой пример: менеджер нового проекта решает, на чем вести разработку: Linux+Mono+Delphi.Net или Microsoft Windows+.NET+C#. Linux+Mono+Delphi.Net прекрасны, функциональны и открыты, но они вторичны. Менеджеру не нужны будущие потенциальные проблемы несовместимости с новыми версиями .NET. Никто не знает Microsoft лучше Microsoft. Если вы считаете, что пример надуман – вспомните odbc, ole db, ado, ado.net или VB vs Delphi. Всем людям с нормальной психикой было ясно, что Delphi в разы превосходит убогий чудовищный VB, тем не менее, сформирован огромный лагерь умственно отсталых VB разработчиков, которые даже любят это убожество.
Вывод: в качестве решения вижу создание крепкой дружной коалиции, в лице коммерческих организаций (Google, Sun, IBM, Oracle) и open source разработчиков (Linux, Apache, Open Office, Mozilla) выступающих единым фронтом, с единым мнением и комплексными интегрированными решениями: Linux+Java+Web.
2. Оптимизация быстродействия и требования к ресурсам.
Эта тема чрезвычайно интересна тем, что мнения по ней сугубо полярны.
Java разработчики: "программы на Java работают ничуть не медленнее, чем программы на C++/Delphi, а зачастую даже быстрее. Требования к ресурсам у них минимальны".
Пользователи Java разработок: "все безумно тормозит и жрет уйму ресурсов".
Небольшой поиск в Internet приносит материалы (охотно поверю, что рекламные) о том, что .NET приложения быстрее, чем приложения на Java.
Мне кажется, что сообществу Java/Sun/IBM следует привлечь хороших специалистов двух типов:
a) по оптимизации кода, менеджерам памяти и т.д.
b) по маркетингу и PR ;-)
Вывод: всегда есть, что улучшить! Вот горячий пример этого года: fastmm.sf.net – менеджер памяти для Delphi/BCB ускоряющий работу программ в РАЗЫ.
3. Интерфейс пользователя.
Больной вопрос, поскольку Java выросла из UNIX мира, где интерфейсы рисуют студенты второкурсники с гипертрофированной манией величия и отсутствием вкуса. Сейчас ситуация улучшается и desktop приложения на Java уже выглядят как плохенькие Windows приложения, но нельзя на этом останавливаться. Без завоевания Desktop все остальные победы временные. Любимый пример Java-разработчиков в таких случаях Borland JBuilder. Безусловно, отличная IDE! Недостижимый для большинства Java-разработчиков идеал, но начинающий разработчик на Delphi сделает такую IDE (без функционала, конечно :-) за несколько часов.
Вывод: поскольку Windows занимает доминирующие позиции на Desktop, и пользователи избалованы стильным дизайном от Microsoft – красивый стильный GUI для Java приложения должен стать не достижением, а нормой (видно что разработчики OpenOffice это поняли и результат не замедлил сказаться).
4. Кросс-платформенность в ширь и в глубь.
"В ширь" - означает большее количество платформ доступных по умолчанию.
Наиболее кричащий пример Pocket PC. Если для коммуникаторов на борту идет какая-то х.з J2ME, то для остальных ситуация просто удручающая. Нужно срочно исправлять положение: для мощных КПК разработать стандартную J2SE, для слабых/мобильных стандартную J2ME.
"В глубь" легче пояснить шуткой про Амфибию, которая плохая лодка и плохой автомобиль. Кросс-платформенность не должна означать, что на всех платформах программа работает одинаково плохо ;-)
На вскидку два примера:
1) "как запустить это чертово Java приложение". Я скачал и установил у себя свежий JRE, но ни .class файлы, ни .jar файлы не запускаются по клику. От запуска программ строкой в Command Line вида "java -ClassPath . bla.bla.bla" надо уходить, на дворе не 1980 год! (да, да, да! JBuilder запускается по клику – возьмите с полки пирожок).
2) Java daemon под Windows (NT service). Я не нашел простого быстрого способа запустить приложение на Java как сервис. Имеется в виду не только "запуск", но и получение и обработка событий suspend, resume, stop, а также работа с EventLog.
Это совершенно нормальные требования и если отмахиваться от них, то Java так и останется чем-то далеким и пугающим.
Вывод: расти в ширь и в глубь, не слушать крики "а нас все устраивает, у нас связка Oracle+Tomcat+IE" т.е. основательно идти на PDA и Desktop.
PS: Если кто-то говорит Java, .NET какая разница – мы на всем пишем. Знайте перед вами типичная "амфибия" ;-)
Настоящий профессионализм подразумевает многолетнюю практику, когда человек думает на языке и в терминах используемой библиотеки классов.
Любой Job-сайт показывает, что на должность простого кодера требуют 2 года опыта, архитектора до 5 и выше.
Подписаться на:
Сообщения (Atom)
Сообщения
