Хочу поделиться своими мыслями по оптимизации общения адекватного руководителя и адекватного исполнителя. Что надо делать и чего делать не стоит, для того, что бы работа была выполнена качественно и в срок?

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

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

Проекты для дяди

Когда вы создаете проект для заказчика, то вам, по большому счету, плевать, будет ли проект коммерчески успешным. Заказчик хочет новую социальную сеть? Пожалуйста. А о том что очередная социальная сеть никому не нужна, и что создавать ее сегодня уже просто смешно, вы скромно умолчите. Заказчики часто не понимают, что большая часть фич, которые они хотят, на самом деле никогда не будут востребованы. Как-то мне довелось столкнуться с проектом, который со стороны выглядел обычным каталогом сайтов. На создание аналогичного каталога ушла бы неделя. Но на самом деле объем этого проекта составлял более ста тысяч (!) строк.

Жаль, если ваше изучение концепции исключений закончится чтением соответствующего раздела официальной документации по вашему языку.

Изучив синтаксис конструкции try{...}catch(Exception $e){...}, узнав о возможности создавать собственные классы исключений, наследуя их от класса Exception и поверхностно осознав мощь оказавшегося в ваших руках механизма, дальше вы можете пойти по одному из двух путей:

• Начать тут же использовать исключения. Скажем, прикручивать их к системе, в которой они никогда не использовались. Или приколачивать их к проекту, в котором ООП и не пахнет. Или, что самое ужасное, пытаться использовать их повсеместно, особенно там, где это не нужно.
• Попытаться понять, где их применять, как делать это правильно, и зачем они нужны.

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

Далее я коснусь трёх основных моделей ведения бизнеса, которые мне нравятся. Читать дальше про стратегии ИТ компаний →

Введение

Ниже представлен перевод главы 6 классической книги “Planning Extreme Programming” by Kent Beck and Martin Fowler.

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

Читать дальше про умных людей и что же им мешает →

Сайты компаний — Актив или Пассив?

Большинство коммерческих организаций, которые охотно пользуются традиционной рекламой, не готовы выделять адекватные суммы на Интернет. Как правило, в компаниях за эти решения отвечают маркетологи, которые считают, что в Интернете всё довольно просто, поэтому работы и реклама в Интернете должна стоить дёшево.

Например, считается нормальным и они готовы платить за профессиональный 30 секундный ролик, больше сотни тысяч долларов и полмиллиона за двух недельный показ его по центральным каналам (это называется имиджевая реклама с непонятной отдачей). Но когда им говоришь, что их сайт, который будет лицом их компании и с ним они будут работать на протяжение 5 лет, может стоить 20, 30, 40 или 50 тысяч долларов, и что на его развитие нужно тратить хотя бы тысяч 100 долларов в год, они не понимают, почему так дорого.

Причин, почему так происходит много:

Что-то я затянул с очередной серией, но тому были причины: от кучи неотложных дел на работе, до раненого автомобиля :(
Ладно, в этот раз — организация внешних вводов, вопросы построения телефонии и некоторые аспекты построения Wi-fi. Как и в предыдущих сериях, я не претендую на глубину раскрытия техники, стремясь лишь показать основные варианты развития элементов инфраструктуры. Предыдущие серии про инфраструктуру здесь и здесь (а здесь — бонус трек про оборудование Allied Telesis).

Провайдерские вводы

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

1. Вы — небольшая компания (до десяти человек), заезжаете в подвал жилого дома или, пуще того, в квартиру на первом этаже жилого здания.
   В такой ситуации с выбором провайдера привередничать не приходится и надо рассчитывать на наличие в здании местного провайдера (если их несколько — вам сильно повезло, конкуренция повышает уровень сервиса). Можно пытаться экономить, оформляя интернет на физическое лицо, однако, в таком случае, стоит быть готовым к тому, что в прайм-тайм местечковый провайдер решит, например, «поменять сетевое оборудование», что приведет к неприятному простою в работе. Целесообразно в такой ситуации предусмотреть резерв хотя бы в виде мобильного интернета (Skylink, Yota, Edge/GPRS) — критически важное письмо в таком случае, пусть медленно, но доползёт. Телефония в такой ситуации, как правило, исполняется в виде «медно-волоконного канала» городского провайдера.
2. Вы все еще небольшая компания, но сидите в гараже (бытовке, ларьке, домике на дереве, здании на территории промзоны).
   Все безрадостно — ваш единственный выход — радиоканал до ближайшей точки присутствия скоростного интернета, либо, если шансов добить по радио нету — интернет через сотовый телефон. Если шансы все же есть, запасайтесь дальнобойными направленными антеннами и шагайте в ближайшее место, где может быть интернет. В моей практике был случай, когда автосервис около года работал через стрим, который находился в двух километрах от. Проблемы в таком случае те же, что и в предыдущем (нестабильность местного кабельного провайдера), правда, в случае использования длинного Wi-Fi линка вы еще и от погоды зависеть будете. В сильный дождь или снегопад перебои — не редкость..
3. Вы заезжаете в бизнес-центр.
   Все уже лучше, но не без специфики: как правило владельцы бизнес центров уже договорились с одним-двумя большими провайдерами, что ограничивает ваш выбор (притащить своего провайдера удастся только если вы — очень большая компания с серьезной арендной ставкой). Плюс ситуации в том, что канал организуют быстро, и, скорее всего без проблем. Явный минус — один — монополисты в здании тарифы могут воротить очень грустные.
4. (моя ситуация) Вы заезжаете в отдельно стоящее здание.
   Геморрой страшный, но при должном подходе получится очень красиво :) Подробно об этом сценарии — чуть ниже.

Итак, отдельно стоящее здание. Учитывая, что вы — хозяин положения, при организации провайдерских вводов стоит учитывать следующее:

• Отказоустойчивость (любой более-менее серьезный маршрутизатор умеет выбирать живой канал). По возможности закладывайте два независимых канала от независимых провайдеров;
• Дороговизна (более серьезный провайдер будет просить более серьезных денег). При этом более дешевый провайдер будет, скорее всего, грешить всеми детскими болезнями домовых сетей — падения канала в течение дня, « плановые профилактические работы» в прайм-тайм и прочие прелести
• Время подключения. Если в предыдущих сценариях вас скорее всего подключили бы в течение дня-двух, то построение индивидуального канала может стать вопросом нескольких месяцев (тут и согласования с городскими кабельными службами, и неповоротливость больших провайдеров, и проблемы со строителями..)

Договор не должен быть трудночитаемым сплошным полотном сумбурного текста. Он должен быть структурирован, если вам нечего скрывать. Кроме того, есть обязательные и устоявшиеся разделы, которые я опишу ниже.

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

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

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

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

Я продолжаю рассказ о применении философской геометрии на практике. Прошлая часть была обзорная, она говорила о том, что многие века геометрия использовалась для поиска универсальных идеальных законов природы. Эти законы повсеместно использовались в произведениях искусства, архитектуре и духовной жизни.

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

Начнем с построения пропорции. Возьмем отрезок AB.



Примем его за радиус и построим окружность с центром в A.



Теперь построим вторую окружность с тем же радиусом, но с центром в B.



У нас получилась фигура ACBD, имеющая огромное значение для наших предков. Она называется Vescica Piscis (пузырь рыбы). Самый простой и важный пример — она давно является символом христианства.



Я продолжу под катом. Спорим, никогда не догадаетесь чем там все закончится :)

Этот хабратопик навеян топиком ООО «Снежинка» — Часть 1. Пошаговое руководство по регистрации..
Так как после моих слов в комментариях о потенциальной возможности написать продолжение моя карма вышла в плюс, эту возможность было решено не упускать.

Здесь речь пойдет о небольшой фирме работающей в сфере услуг.

Мы кратко рассмотрим следующие вопросы:

1. Регистрация через фирму или собственными силами?
2. Юридический адрес: покупать или нет?
3. Уставной капитал: какой и в какой форме?
4. Открытие расчетного счета в банке (потенциальные сложности)
5. Работа с наличными средствами, зарплата, интернет-банкинг

Итак, начинаю публикацию целой серии долгожданных заметок о договорах и прочей документации дизайн-студии. Сразу скажу, что договор студии Made выкладывать сюда или куда-нибудь еще я не буду, у нас политика такая. Хотя, какие-то его части, быть может, и появятся в открытом доступе. Вместо рыбы я дам вам удочку.

Индустрия программного обеспечения — это, наверное, крупнейший в мире питомник новых систем управления. Agile, Экстремальное Программирование, Разработка Через Тестирование (Test Driven Development, TDD) — акронимы и фреймворки продолжают плодиться. Почему?

Кто-то скажет: незрелость — производство ПО еще молодая промышленность и все эти изменения — путь к некоторым истинным основам. Другие говорят, это потому, что люди от программирования просто любят выдумывать всякие штуки и сами не могут разобраться. А я скажу так: раз уж мы идем к тому, чтобы иметь дюжины моделей, хотя бы некоторые из них могут быть честными, хотя и циничными, по отношению к тому, что на самом деле происходит большую часть времени.

Продолжаем цикл статей на тему построения сайтов (веб-приложений) ориентируясь на максимальное применение AJAX технологии. Зачастую, при работе сайтов и приложений использующих AHAH требуется вместе с подгружаемым HTML контентом догружать файлы скриптов, которые не использовались ранее на страницах сайта. Одним из моментов обработки догружаемого AJAX-ом контента является выделение из получаемого контента файлов скриптов, с последующим их применением к текущему документу (DOM). Благо, на данный момент практически все основные библиотеки умеют это делать. Однако, если копнуть глубже в реализацию процесса обработки догружаемых скриптов, то текущая ситуация совсем «не радужная». Не все хорошо известные библиотеки умеют это делать хорошо, а тем более оптимально. Давайте рассмотрим указанный процесс изнутри, разберем существующие проблемы и узнаем пути их решения.

Мы потратили несколько часов, исследуя онлайн-сервисы из списка Webware 100 Top Web Apps 2008 и изучая их бизнес модели. Следующая диаграмма показывает результаты исследования — 34% сервисов используют рекламную модель, 12% различные схемы подписки, 8% продают виртуальные товары (чаще всего в виде данных для скачивания), такая же доля сервисов предлагает сопутствующие продукты (обычно большие компании-разработчики предлагают бесплатный вариант продукта для привлечения к их платформе) и еще 8% сервисов используют схему «оплата за использование».

В некоторых проектах достаточно часто возникает необходимость в хранении данных, объем которых уже нельзя назвать маленьким, но в тоже время использовать какую-либо СУБД слишком накладно из-за сложности развертывания приложения. И тут на помощь приходит такая прекрасная вещь как SQLite – компактная встраиваемая база данных.

Для тех, кто пишет с использованием платформы .NET приятным моментом станет наличие

Впервые опубликована на usability.by

Прототипирование для ИТ

Я занимаюсь созданием прототипов ИТ-продуктов и хочу поделиться секретами своей кухни — написать несколько статей о том, как внедрение фазы прототипирования может преобразить ваш процесс разработки или даже ваш ИТ-бизнес в целом.

В своей первой статье я хочу рассказать о вещах, которые могут быть не замечены или недооценены руководителями отделов разработок, дизайн-департаментов, бизнес-аналитиками, помочь отыскать упущенные возможности и подсказать некоторые ходы, пригласить вас заглянуть в философию дизайна. Потребность в прототипировании чаще всего вырастает из потребности сделать наглядной и более прозрачной фазу сбора информации и написания технического задания (ТЗ, спецификации, vision) [1], но я хочу рассказать о менее очевидных вещах.

Я противопоставлю прототип и ТЗ, чтобы в контрасте показать отдельные свойства и качества прототипа и всё, чем он может обрасти. Показать положительные побочные эффекты применения прототипов, которые обнаруживают себя ещё до использования прототипов в юзабилити-тестировании.

Предлагаю мой вольный перевод вопроса с stackoverflow, который мне показался полезным и сидит в фаворитах. Что-то я взял с MSDN (в основном вырезки из русской редакции), что-то -с блогов.
Все мы, С# разработчики, знаем базовые комманды C#. Я имею ввиду объявления, условия, циклы, операторы и т.д.
Некоторые из нас знают даже про Generics, anonymous types, lambdas, linq,…

Но, каковы реально скрытные возможности и трюки C#, про которые даже фанаты и эксперты не всегда знают?

Объектно-ориентированные базы данных – базы данных, в которых информация представлена в виде объектов, как в объектно-ориентированных языках программирования.

Применять или не применять объектно-ориентированные системы управления базами данных (ООСУБД) в реальных проектах сегодня? В каких случаях их применять, а в каких нет?

Вот преимущества использования ООСУБД:

• Отсутствует проблема несоответствия модели данных в приложении и БД (impedance mismatch). Все данные сохраняются в БД в том же виде, что и в модели приложения.
• Не требуется отдельно поддерживать модель данных на стороне СУБД.
• Все объекты на уровне источника данных строго типизированы. Больше никаких строковых имен колонок! Рефакторинг объектно-ориентированной базы данных и работающего с ней кода теперь автоматизированный, а не однообразный и скучный процесс.

Интересно? Тогда стоит попробовать!

В статье описано все, что требуется для начала работы с ООСУБД db4o.