Я навострил уши, потому что знал, что большая часть разработчиков с моей первой серьёзной работы, компании В-Реал, была, в своё время, в порт сманена. Как показал дальнейший разговор, уши я навострил не зря.

Выяснилось, что программа, первую версию которой мы, с Серёгой Щербаковым и коллегами, разрабатывали в 1997 году, до сих пор работает в порту!

Программа называется Integrated Object Manager (IOM) и представляет из себя универсальный клиент, для объектно ориентированного доступа к данным. В реляционной базе, мы тогда использовали Sybase, хранятся описания объектов и действий с ними и, естественно, содержимое объектов. IOM читает эти описания из базы и работает с объектами.

Мы тогда планировали использовать эту систему как универсальную платформу для разработки программ хранения и обработки данных, для различных клиентов.

Не помню уже точно чья была идея изначально, помню, что активно учавствовали Саша Будник, Рома Герасимов, Серёга Щербаков и я. Первый вариант IOM, на Delphi, писали я и Серёга.

Забавно, что дело наше живёт через 14 лет, после первой версии.

Кстати, сейчас там работает следующая версия, на C++. И у них ходит легенда, что кто-то там переписал весь код, что мы с Серёгой делали полгода, за 10 дней, на C++.

Спор такой действительно был. И какую-то заглушку конечно написали. Но полного функционала за 10 дней добиться таки не удалось. Кто бы сомневался

Но, хорошая часть, плохим кандидатам это не помогает...

Вариант для C/C++. Увлеченно используем арифметику указателей.

char* reverse(char *s) {
    char *s0, *s1;

    for (s1 = s; *(s1) != '\0'; s1++);
    s1--;
    for (s0 = s; s0 < s1; s0++ && s1--) {
        char c = *(s0);
        *(s0) = *(s1);
        *(s1) = c;
    }
    return s;
}

Сравнивая производительность с предыдущими вариантами, надо обратить внимание на два момента:

• фактически первый цикл — это вычисление длины строки, т.е. быстрее или медленнее это место, по сравнению со strlen, зависит от реализации strlen. Не знаю что конкретно там обычно написано, спекулировать не буду. Но думается, что что-то типа того и написано С другой стороны, если вдруг окажется, что strlen работает быстрее чем просто поиск конца, в цикле, то никто не мешает нам написать конструкцию вида s1 = s+strlen (s). А дальше продолжить делать как тут.
• Во время самого обмена значениями мы заметно сокращаем количество вычислений, т.к. вместо s+i и s+len-i, на каждом присваивании, мы все указатели вычисляем один раз, на проход.

На Java так красиво не получится. За отсутствием собственно указателей. Но близко к этому будет вариант с запуском навстречу двух счетчиков массива...

Так что попробую описать своё видение этого подхода в отдельной статье. А потом буду на неё везде ссылаться

Говорить буду, в основном, про софтверную часть. Как самую мне близкую.

Проблема

Есть известная шутка: Качественно, быстро, недорого. Выбери любые два. Хоть и звучала эта шутка изначально, кажется, про ремонт, она не менее справедлива и в разработке программного обеспечения.

Но, в отличии от ремонта, в разработку программы нельзя нагнать ещё несколько десятков таджиков или индусов, чтобы класть кафель в три смены, без выходных.

Время тоже всегда ограничено: конкуренты не спят, протянешь с выпуском — потеряешь рынок.

Деньгами много не решить, т.к. много индусов не нагнать, а те что есть имеют вполне конечные аппетиты.

Вот и получается, что практически единственный фактор, которым может играть производитель программ, — качество этих самых программ.

В управлении же качеством есть два основных подхода...

Наиболее частое решение

Так уж исторически сложилось, что большинство производителей программ пытаются напихать в свои продукты максимальное количество функций. Видимо маркетологам так удобнее меряться с конкурентами: количество функций — объективный показатель, который легко измерить. А потрясённые пользователи затем пытаются разобраться во всём этом зоопарке.

Беда в том, что ограничение по времени никуда не девается и выбрав путь на увеличение количества функций, далеко не всегда и далеко не всем нужных, приходится жертвовать качеством исполнения каждой отдельной функции. Вот и получается, что задекларировано много, но каждая отдельная функция работает кое как или вообще не работает.

Я уже как-то приводил в пример, мягко скажем, не очень удачную реализацию редактирования и выделения текста в Android. И Android-ный же не-GMail почтовый клиент. Из мира iOS можно вспомнить реализацию нотификаций, которая сделана на порядок хуже, чем  в Android.

Другая сторона этой медали, пользователи перестают осознавать, что просто количество функций не является главным плюсом или минусом какой-то программы. Зачем тебе нужен монстр, имеющий в списке сотни функций, если реально ты будешь пользоваться десятком?! Если же снизить планку по функциональности, до необходимого минимума, то выбор увеличивается, а цены снижаются.

Классический пример — все, вне зависимости от реальных потребностей, редактируют текст в MS Word, а фотографии в Adobe Photoshop.

Менее популярное решенее

Очевидно, что альтернативным решением может стать: сделать меньше, да лучше.

Суть такого подхода состоит в отборе для реализации самых необходимых и самых востребованных функций и безжалостном отбрасывании остальных на следующие релизы и версии. В итоге получается продукт, который, возможно, не удовлетворяет, в первой версии, часть потребностей особо продвинутых пользователей. Но покрывает, тем не менее, основные потребности большинства и, главное, делает это хорошо. А новый функционал последовательно добавляется в новых версиях.

Именно его, как правило, и исповедует Apple. Вся история iPhone и iOS, а теперь и iPad является примером реализации такого подхода.

Но такой подход далеко не всегда находит понимание у продвинутых пользователей, привыкших считать, что чем функций номинально больше, тем лучше. Дело доходит до абсурда. Очень многие мои знакомые называли невозможность отправки MMS на первых версиях iPhone его существенным недостатком. Картинка сравнения Nokia 3310 (2000г) и iPhone 3G (2008г), где единственным отличием iPhone было названо наличие цветного дисплея, радостно курсировала по интернету. Но ни один (!) из критиков отсутствия MMS не признал, что он постоянно пользуется этой функциональностью на своём нынешнем телефоне. Большинство, как и я, один раз отправило MMS, когда в первый раз увидело такую возможность, и забыло о них навсегда.

Так настоящим ли минусом было отсутствие MMS?!

Тоже и с видео чатами и звонками, которые присутствовали в том сравнении с 3310. Да, номинально многие телефоны умеют делать видео звонки через сеть 3G. Но поднимите руки, кто регулярно этим пользуется? И реальность, к сожалению, такова, что видео звонки на современных мобильниках практически отсутствуют как класс. Лишь Apple сделала FaceTime, для iPhone 4, и Google обещает видео чат в Android 2.3 на новом Nexus S, который появится в продаже меньше чем через неделю.

И вопрос с подвохом. Если FaceTime получит реальное распространение, то кто будет настоящим первопроходцем в видео звонках с мобильников и смартфонов? Nokia или таки Apple?

Выводы

Я понимаю, что подход «меньше, да лучше» нетрадиционен в нынешних компьютерных реалиях. И его реализация, а часто даже и восприятие требует некоторого срыва шаблона. Но лично мне так нравится больше.

Microsoft, кстати, в своей Windows Phone 7, похоже пошла тем же путем. Ведь первая версия этой операционной системы не многим превосходит по возможностям первые версии iPhone OS, а кое где и проигрывает. Например, там нельзя отправить USSD запрос, а это значительно более часто используемая функция, чем MMS.

Вот пост Марка Рейнхольда (Mark Reinhold) по этому поводу: http://blogs.sun.com/mr/entry/quartet

I’m pleased to note the submission of four new Java Specification Requests to the Java Community Process:

• JSR 334: Small Enhancements to the Java Programming Language, by Joe Darcy with help from Jon Gibbons, Maurizio Cimadamore, and many others in Project Coin;
• JSR 335: Lambda Expressions for the Java Programming Language, by Brian Goetz with help from Alex Buckley, Maurizio, and others in Project Lambda;
• JSR 336: Java SE 7 Release Contents, for the enormous team effort that is JDK 7 (the first half of Plan B); and, finally,
• JSR 337: Java SE 8 Release Contents, for the eventual JDK 8 (the rest of Plan B).

These JSRs have been a long time coming. They’re now—finally—on the JCP Executive Committee ballot for approval; results should be available in two weeks.

My thanks to everyone who’s contributed to the related OpenJDK Projects.

Как видно, нам тут интересны JSR336 и JSR337. Через две недели должны появиться результаты голосования по этим JSR.

• iPhone и роуминг
• iOS vs Android: Что лучше?! (Часть 1)
• iPhone, оценки из прошлого

Опыт очень интересный. Фактически часть моего словоблудия и мыслеизлияния из этого блога перешло в стадию какой никакой, но работы.

Ну и, понятно, меняются сразу требования, хоть и не сильно. Надо больше следить за языком. И заниматься на более-менее постоянной основе, а не как тут.

Посмотрим, что из этого выйдет...

Как бы это сформулировать в резюме? Аналитическая журналистика?

Король умер. Да здравствует король!

15 февраля2010 года // Hi-Tech, Потребрынок, Intel, Nokia, компьютерная техника, новинки

Nokia и Intel совместно выпустят новую операционную систему

Компании Intel и Nokia объявили о создании новой операционной системы на базе Linux, которая будет поддерживаться нетбуками, смартфонами и планшетами Продолжение статьи

Долго к этому шли...

15 февраля2010 года // Hi-Tech, Потребрынок, Телеком, интернет, Общество, сотовая связь

Сотовые операторы мира делают общую платформу для приложений

Ведущие телекоммуникационные компании мира объединились, чтобы создать открытую платформу для доставки приложений пользователям мобильных телефонов Продолжение статьи

JavaME, судя по всему, совсем не хватает...