к разговору, что java никому не нужен... откуда у apache платиновые спонсоры взялись, которые платят $100k в год? Microsoft спонсирует разработку Apache HTTP Server'а?
Thanks
Sponsorship
---
про последние события в java-мире в целом
|
Цитата:
|
|
Пару лет назад я бы точно сказал, что у Java будущее есть. Последние события заставили появиться тень сомнения. То, что Oracle собирается делать платную VM, явный раскол JCP и т.п. Как-то мне это не нравится. Вряд ли уж в ближайшие несколько лет язык загубят совсем - сама Oracle в него миллиарды вложила - но популярность он может сильно потерять.
|
Мужики! Смена деятельности?!
---
давай посмотрим на популярность java
TIOBE Programming Community Index for December 2010
---
в целом, что можно сказать... действия Google, Apache, Apple никак не связаны с "java с точки зрения программиста". Google java нужна для Android. Apache интересует открытая java. Что интересует Джобса - это только он знает. И да, там сейчас имеют место быть некоторые терки, но что будет дальше пока не ясно. Ты же не хочешь сказать, что Oracle собирается загубить java? Зачем? я думаю, что java просто станет более платной и более закрытой
---
Кроме того, не надо забывать, что основное применение java - enterprise-сектор, с которым ни я, ни ты не сталкиваемся
Joel on Software - Пять миров
|
Цитата:
|
Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга..
Вы - разработчик программного обеспечения. Я тоже. Но у нас могут быть совсем неодинаковые цели и требования. На самом деле, существует несколько различных миров разработки ПО, и к разным мирам применимы разные правила.
Допустим, Вы читаете книжку по UML моделированию, а в ней нигде не говорится о её бессмысленности для программирования драйверов. Или же Вы читаете статью, утверждающую, что "20МБ среда [требующаяся для .NET] - это НЕ проблема", а она не содержит очевидного: если Вы пытаетесь написать код для пейджера с 32КБ ROM, то это ещё та проблема!
Я считаю, что в программировании есть пять миров, иногда пересекающихся друг с другом, а в основном нет. Это:
1. Ширпотреб
2. Внутреннее ПО
3. Встроенное ПО
4. Игры
5. Одноразовое ПО
При чтении одной из последних книг по Экстремальному программированию, одной из замечательных книг Стива МакКонннелла, сайта "Джоэль о софте" или журнала "Разработка программного обеспечения Вы видите много утверждений, как же разрабатывать ПО, однако вряд ли Вы когда-либо замечали малейшее упоминание, о каком же всё-таки типе разработки они ведут речь, что довольно-таки плохо, ведь иногда в разных мирах необходимо разрабатывать по-разному.
...
Важно знать, что когда бы Вы ни читали книгу о методологии программирования, написанную гуру/консультантом по разработке ПО, работающим на полную ставку, можете быть спокойны, что он говорит о разработке внутреннего, корпоративного ПО. Не ширпотребного, не встроенного и, конечно же, не игр. Почему? Потому что именно корпорации нанимают этих гуру. Они им платят. (Поверьте мне, id software никогда и ни за что не собирается нанимать Эда Йордона, чтобы тот размышлял о структурном анализе.)
На прошлой неделе Кент Бэк заявил, что системы отслеживания ошибок не нужны при экстремальном программировании, потому что комбинация парного программирования (с постоянной проверкой кода) и разработка, основанная на тестах (гарантирующая 100% покрытия кода автоматическими тестами) означает, что у Вас вряд ли когда-либо будут ошибки. Это показалось мне неправильным. Я заглянул в нашу собственную базу хранения ошибок, чтобы проверить, каких типов ошибок в ней особенно много.
Имеющий глаза да увидит – я обнаружил, что очень мало тамошних ошибок могли бы быть обнаружены парным программированием или тестами. Многие наши "ошибки" на языке экстремального программирования называются историями – по существу, это лишь запросы о возможных улучшениях. Мы используем систему отслеживания ошибок для запоминания, выставления приоритетов и управления всеми маленькими улучшениями и большими возможностями, которые мы хотели бы реализовать.
Много других ошибок были обнаружены только лишь после длительного использования на месте. Проблема с польской клавиатурой. Нет способа, которым парное программирование поможет найти такие вот ошибки. Ещё есть логические ошибки использования различных возможностей, которые никогда с нами не случались. Чем больше и сложнее программа, тем больше взаимодействий между возможностями, о которых Вы и не догадываетесь. Определённая последовательность символов ({${?, если хотите знать) вводит в замешательство лексер. Некоторые ftp-сервера сообщают об ошибке при попытке удаления несуществующего файла (наш на такое не жалуется, поэтому такого никогда с нами не случалось).
Я внимательно изучил каждую ошибку. Из 106 ошибок, которые мы исправили в первом пакете обновления для CityDesk, ровно 5 могли бы быть предотвращены с помощью парного программирования или разработки на основе тестов. У нас на самом деле было больше ошибок, о которых мы уже знали, но не считали их важными (только если нас не поправят наши покупатели!), чем ошибок, которые могли бы быть выловлены методами ХР.
Но Кен прав, только вот для других типов разработки. Для большинства корпоративных приложений ни одна из рассмотренных выше не считалась бы ошибкой. Программа вылетает от неверного ввода? Запустите ещё раз, и на этот раз следите за своими {${?! И мы используем только лишь один FTP-сервер и никто во всей компании не использует Польские Windows.
Большей частью разработка ПО одинакова вне зависимости от проекта, но не вся. Когда Вам говорят о методологии, подумайте о том, как она согласуется с делаемой именно Вами работой. Подумайте, откуда говорящий. Стив МакКоннелл, Стив Магуайр и я все из одной песочницы: мира ширпотребных электронных таблиц, написанных в Редмонде, штат Вашингтон. И у таких у нас высокая планка на лёгкость в использовании и низкая для ошибок. Большинство других гуру методологии зарабатывают свой кусок хлеба, консультируя внутренние корпоративные разработки, поэтому о них они и говорят. В любом случае, мы должны уметь учиться друг у друга.
|
|