Monday, June 04, 2007

IDC оценила рынок OSS в $1.8 миллиардов

По оценкам IDC в 2006 году рынок open source software достиг $1.8 миллиардов. И будет увеличиваться ежегодно на 26%, достигнув $5.8 миллиардов в 2011 году.

Among the key results presented in IDC's study are the following:

  • Worldwide revenue from standalone open source software reached $1.8 billion in 2006.
  • This revenue will reach $5.8 billion in 2011, representing a compound annual growth rate (CAGR) of 26% from 2006 to 2011.
  • Software vendors are advised to consider several factors when evaluating how best to leverage open source software as a business opportunity, including the most appropriate business model, the appropriate usage of partnerships and alliances, and the characteristics of the community supporting the open source software.

Вообще эти цифры было бы интересно сравнить с оценкой роста всего рынка на этот же период и, соответственно, посмотреть изменение доли OSS в общем рынке.

Sunday, June 03, 2007

Microsoft снова против

На этот раз Microsoft против TestDriven.Net. До суда дело, вроде, еще не дошло, но "личная" переписка по увещеванию разработчика (Jamie Cansdale) отказаться от продукта уже довольно объемна. TestDriven.Net - Add-In для MS VisualStudio (в том числе поддерживает и Express). Понять недовольство MS можно – в Express многое обрезано и она должна "подталкивать" разработчиков к переходу на платную полнофункциональную MSVS. Ясное дело, что TestDriven.Net "тормозит" подобные переходы.

Ситуация немного непонятна. Джеми Кансдейл утверждает, что за пол года переписки MS так и не указали, какой же пункт EULA был нарушен. Опять же не понятно почему, если этот вопрос так важен для MS, увещевание за пол года так и осталось на уровне личной переписки и до сих пор дело не дошло до суда. Может Джеми Кансдейл на самом деле ничего не нарушил и его пытаются "задавить авторитетом"?

Update. Еще обсуждения данной темы:
Microsoft борется с TestDriven.NET
Microsoft против TestDriven.NET

Tuesday, May 29, 2007

SVN for Distributed Development Teams

Сегодня-завтра на CMcrossroads намечается пара интересных вебинаров, посвященных использованию Subversion для работы распределенных команд разработчиков:

  • Globally Distributed Development Using Subversion
    Сегодня, 29 мая в 22:00 по Москве (поздновато).
    Докладчики:
    Blair Zajac, Principle, OrcaWare Technologies
    Jim Campigli, Executive VP, Product Management & CTO, WANdisco
    Patrick Egan, Editor-in-Chief, CM Journal
  • Subversion for Enterprise Distributed Teams: Why, When and How?
    Завтра, 30 мая в 18:00 по Москве.
    Докладчики:
    Carey Schwaber, Senior Analyst, Forrester Research, Inc.
    Auke Jilderda, Senior Collaboration Consultant, CollabNet, Inc.
    Mark Phippard, Director, Subversion Engineering, CollabNet, Inc.

Вопрос Source Control Management для распределенных команд один из наиболее проблемных. Надеюсь будут интересные идеи не только по SVN, но и по SCM в целом.

И вообще, здесь довольно много интересных вебинаров. В частности еще ожидаемые по Distributed Development:

Прошедшие вебинары доступны в течении 6 месяцев on-demand.

Friday, May 04, 2007

Resume vs. CV

Давно у меня было желание написать по поводу того, чем же отличается резюме от CV (т.к. последнее время аббревиатура CV встречается все чаще). Но, как это часто бывает, такие «не острые» проблемы все время откладываются на потом. Сейчас же триггером к написанию поста послужил пост «Как абсолютно правильно составить резюме». В общем-то, написано там все очень верно, только это не резюме, а CV. Так в чем же разница?

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

Резюме

В Америке, в гораздо большей степени, чем в Европе, выражена узкая специализация сотрудников, конвейерный подход, набор сотрудников через агентства (которые ищут по четко заданным критериям). Каждое резюме прочитывается многими людьми на разных уровнях, прежде чем будет принято решение, что с соискателем можно и пообщаться (хотя бы по телефону). Отсюда требование к резюме – оно должно быть только по делу и очень кратким (максимум 1 лист A4 нормальным шрифтом). Одного быстрого взгляда должно хватать, чтобы понять – что именно этот человек нужен на конкретной должности.

Первым делом надо указать должность, на которую подается резюме и зарплату, на которую рассчитывает соискатель.

Далее самый важный блок - информация о навыках, причем только тех, которые непосредственно относятся к должности, на которую претендует соискатель. В зависимости от требований конкретной компании меняются приоритеты, т.е. вверх поднимаются навыки, которые требуются на конкретной должности в конкретной компании. Соответственно резюме одного и того же соискателя могут отличаться как при подаче на разные должности, так и при подаче на одну и ту же должность, но в компании с разной специализацией (пример см. в конце поста). Сколько лет или месяцев проработал соискатель в той или иной области не очень важно (можно указать, а можно и нет), но очень важны количественные и качественные показатели систем, с которыми приходилось работать (проектировал БД со 100 справочниками, 15 оперативными таблицами; участвовал в разработке системы с 20 рабочими местами), параметры лучше выбирать самые «впечатляющие».

Далее идет информация о местах работы, но, опять же, только тех, которые непосредственно относятся к должности. Здесь хорошо подробнее остановиться на месте работы (не обязательно последнем), которое считаете «достижением».

Образование – указывается только то, что относится к описанным навыкам. Т.е. школа вообще никого не интересует. И институт, если он не по специальности тоже. Курсы и сертификаты, опять же, только по тем предметам, которые указаны в навыках.

Контактная информация – Имя (или фамилия, на данном этапе полные данные не нужны), email, телефон и др. способы связи. Возраст и пол указываются только если к ним есть особые требования.

CV (curriculum vitae)

Европейский подход более «человечный» - главное чтоб человек был хороший, а навык появится. CV - это полная автобиография. В ней надо отразить весь жизненный бэкграунд.

Начинать, конечно, надо с представления, чтобы будущий работодатель сразу почувствовал, что за бумажкой, которую он читает, стоит человек. Тут можно не только полное ФИО указать с контактной информацией, но и полный адрес (район проживания много может сказать о человеке), семейное положение, и, возможно, состав семьи.

И далее все очень хорошо описано здесь.

Что соискатель хочет от работы - т.е. не какая конкретная должность (как в резюме), а чем бы ему вообще интересно было заниматься.

Навыки – в порядке заинтересованности соискателем. Этот блок логическое продолжение предыдущего блока. Он должен рассказать работодателю чем соискатель хочет продолжать заниматься исходя из своих возможностей.

Места работы – все места, где проработал соискатель в обратном хронологическом порядке с подробным описанием чем и где занимался, круг должностных обязанностей и т.д. (можно даже указать почему менялись места работы). В CV это основной блок – он раскрывает работодателю бэкграунд соискателя.

Научные публикации, если таковые имеются. Должен идти сразу же после опыта работы, т.к. на текущий момент CV, в основном, используется в научной среде. Если публикации плотно связаны м местами работы, то блок научных публикаций можно объединить с блоком мест работы и делать их подблоками для каждого из мест.

Образование – тоже в обратном хронологическом порядке «официальное» образование, в конце дополнительные курсы.

Личностные характеристики – все что еще хочет сказать о себе соискатель работодателю.

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

--

Пример особенностей резюме для разных должностей

Возьмем соискателя программиста VB.NET + MS SQL Server, имеющего опыт работы как в крупной компании (работа по четко поставленному ТЗ), так и в небольшой (самому приходилось бегать и выяснять требования).

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

Отличия в резюме для разных компаний заключаются в том, на каких технических навыках стоит акцентироваться (например, в одном случае требуется подробнее описать навык работы с сетью, в другом создание собственных визуальных компонентов, а в третьем разработку и поддержку системы репликации).

--

Послушать (eng) чем отличаются резюме и CV можно здесь (прямая ссылка на MP3 файл)

Friday, April 20, 2007

Aspect-oriented programming

Если что-то появляется, значит, оно кому-то нужно.

И снова новая методология программирования и к ней новый подход к разработке ПО. Приглашаем любить и жаловать: Aspect-Oriented programming (AOP) и Aspect-Oriented software development (AOSD).

В отличии от предыдущей методологии (OOTD) (которая была только идеей и поводом немного задуматься, да и на устои привычной OOP серьезно не покушалась), эта методология вполне оформившаяся и претендует быть кардинально отличной от OOP.

История:

Aspect-Oriented подход разработан в Xerox PARC в 2001 году под руководством Gregor Kiczales. Этой же группой была разработана первая реализация – AspectJ, которая на текущий момент входит в Eclipse Foundation. Кроме AspectJ уже создано несколько десятков реализаций AOP парадигмы, практически для всех языков.

Идея AOP захватила сообщество - существует Aspect-Oriented Software Association (AOSA), проходят ежегодные конференции по AOSD, в которых в качестве спонсоров выступают Microsoft, Google и IBM.

Основная цель, которую себе поставил Gregor Kiczales, и в результате движения к которой появился AOP – уменьшение кол-ва ошибок и улучшение качества кода за счет борьбы с запутанностью кода и разбросанностью функционала.

Дисклэймер:

Я, человек привыкший думать объектно-ориентированно, не совсем поняла их претензии к OOP. Т.е., на мой взгляд, при правильном дизайне системы (в объектно-ориентированной парадигме) нижеизложенные проблемы не дают серьезного ухудшения качества кода. Описание же AOP, на мой взгляд, слишком похоже на патерны. Но то, что я не вижу преимуществ – это не значит что их нет. OOP тоже плохо приживался в процедурно мыслящей среде.

С чем боремся:

В объектно-ориентированном подходе как на уровне системы в целом, так и на уровне отдельных классов присутствует сквозная функциональность (т.е. та, которая реализована понемногу в разных модулях), а так же большое количество кода, который фактически не относится к функционалу системы. На уровне системы это идентификация, защита, логирование, репликации, сериализация/десериализация, сохранение настроек системы и т.д., т.е. или общий или «сервисный» функционал, зачастую реализованный в разных частях системы (примеры: сериализует один модуль - десериализует другой; каждый из модулей системы занимается идентификациеи и защитой), в связи с чем усложняется отладка и поддержка (со временем начинается «расползание»). То же самое на уровне классов – класс инкапсулирует в себя не только функциональную часть, но и внутренние «сервисы», обеспечивающие корректность работы – отлов ошибок, работа с памятью и т.д., которые загромождают код и усложняют чтение логики – в следствии чего, опять же сложности с отладкой и длительной поддержкой.

Метод борьбы:

Выделение сквозной функциональности в отдельные модули, которые называются аспектам (aspects). Поведение аспекта в конкретном месте программы (точке подсоединения, join point) определяет advice (собственно программная реализация модуля). Все точки подсоединения конкретного аспекта описываются в наборе pointcut.

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

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

Ссылки по теме:

Gregor Kiczales о AOP (Google Video)

Aspect-Oriented programming на wiki

Книги:

Aspect-Oriented Analysis and Design: The Theme Approach. Siobhàn Clarke, Elisa Baniassad.

Aspect-Oriented Software Development. Robert E. Filman, Tzilla Elrad, Siobhan Clarke, Mehmet Aksit.

Aspect-Oriented Software Development with Use Cases. Ivar Jacobson, Pan-Wei Ng.

Aspect Oriented Refactoring. Ramnivas Laddad.

AspectJ in Action: Practical Aspect-Oriented Programming. Ramnivas Laddad.

Sunday, April 15, 2007

Очень точно подмечено

Ко всем существующим фобиям у современных людей добавилась еще одна - боязнь потерять флешку!

(автор где-то в ЖЖ)

Tuesday, April 10, 2007

Фильм про Дубну и Синхрофазотрон

Тем, кого заинтересовала Дубна, а так же тем, кто любит физику, историю и, особенно, историю физики:

10 апреля на канале "Культура" в 20.35 (по мск) будет фильм "Властелины кольца", посвященный созданию дубненского синхрофазотрона.