→

Перепост →  IT-ишникам

Обращение Михаила Бродского. У меня нет слов.

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

Сначала было предложение всех IT-ишников вообще исключить из единого налога и запретить им заниматься ВЭД.

Дальше были большие встречи с представителями отрасли, обсуждения, споры. Мы изучили конкурентную среду и решили оставить ВЭД. IT-ишники тогда соглашались на ставку в 1500 грн.

А потом началось нытье, стоны, возмущения. В результате оставили ставку 1000 грн и разрешили ВЭД. А вы теперь так себя ведёте…

Ещё не поздно. Может поставить ставку 600 грн и отменить ВЭД?

А те, кто плачет, что 300 тысяч оборота — это мало, переходите на общую форму. 3 млн грн. без налога на прибыль — прекрасные условия для бизнеса. Что же вам не нравиться? Налог на прибыль — 0%!… А НДС — это не ваши деньги. Ни химичить не нужно, ни придумывать ничего. Работай себе честно и все.

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

Источник и обсуждение здесь: http://mihailobrodskiy.livejournal.com/446127.html

Как все начиналось: http://php5.com.ua/blog/perepost/168.html
0

Перепост →  С Днем Программиста!



День Программиста традиционно отмечается на 256-й день года. Число 256 выбрано потому, что это количество чисел, которые можно выразить с помощью одного байта. В високосные годы этот праздник попадает на 12 сентября, в невисокосные — на 13 сентября.

Все мы выбрали эту профессию по-разному. Кто-то вышел на нее случайно, кто-то выбрал специально, но теперь все мы трудимся вместе над одним общим делом: мы создаем будущее. Создаем прекрасные алгоритмы, заставляем эти серые коробочки трудиться, трудиться и еще раз трудиться, даря людям новые профессии, возможности для самовыражения… Даря людям возможность общаться друг с другом, зарабатывать на жизнь… Мы создаем для людей тот микромир, которого им не хватает. Ведь благодаря нашей профессии возникают все новые и новые произведения искусства, созданные в графических растровых и векторных редакторах… Благодаря нашей профессии создаются шедевры трехмерной графики. Мы!!! Да, именно мы ускоряем бизнес для бизнесменов! Ускоряем бухгалтерские расчеты, заставляем меняться курс доллара!!! Будь то виросуписатель или программист детских игрушек… Каждый из нас изменил чью-то жизнь…

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

Спасибо каждому, кто создавал эту профессию!

С Днем Программиста вас!!!

З.Ы. Небольшая подборочка





IRQ


Зажигательная вечеринка


Анекдот


Респект вот таким вот парням


Источник: http://habrahabr.ru/blogs/development/104101/
1
3

Перепост →  Не будите программиста

Вот в отпуске побывал впервые в жизни… а некоторые так за всю жизнь ни разу там и не бывают как я подозреваю.

Не знаю полезно это или нет — отвлечься вот так от работы на почти целый месяц. Я пока не понял какой это возъимеет эффект на производительность труда. Зато во время отпуска я понял кое что о чём много раньше думал и никак не мог осознать.

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

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

Ну вобщем хватит предъистории. Как работает программист.

Работа программиста — это СОН.

Звучит нелепо, правда?

Если вы хотите представить что именно делает программист во время работы, то легче всего это представить именно так. Он спит!

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

Это вы думаете что программист взял задачу, написал программу и задача решилась. Всё не так.

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

Для решения задачи программисту приходится стать в своём сознании и лабиринтом, и искомым выходом, и заблудившейся девочкой, и тем перстом что ведёт её куда-то, и теми камушками которые она разбрасывает по дороге чтобы узнавать уже пройденные места. Всё это СНИТСЯ программисту во время работы.

Я не фигурально выражаюсь. Это БУКВАЛЬНО снится. Программист при решении задачи виртуально живёт в создаваемом мире химер, похожих каким-то образом на условия решаемой задачи.

Внешне наблюдение за работающим программистом это тоже самое что наблюдение за спящим человеком. Вы вот сразу засыпаете когда решаете отойти ко сну?

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

Вот тоже самое и в работе программиста. Процесс начала работы это тоже самое. Программист не может просто сесть и начать работать точно также как вот вы не можете сказать себе «СПИ УЖЕ СКОРЕЙ!» и отключиться. И общего какого-то способа тоже нет, как нет его в ритуале засыпания.

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

Это ведь ещё и меняется со временем. Сегодня вот вы легли спать и всё — уже сладкие грёзы. А завтра ворочаетесь час, два, три и ну никак. Тоже самое и в работе программиста. буквально тоже самое.

Ну и что делать всвязи с этим?

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

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

Представили?

Вот это именно так выглядит для нас — программистов. БУКВАЛЬНО ТАК.

Это вам со стороны кажется что вы просто подошли и спросили который час.

А давайте я вас подойду и спрошу в три часа ночи который час?
Чего страшного-то? Ну и что такого что вы только что заснули?
Я просто спрошу, вы ответите и спите дальше. Чего такого-то?

Так легче понять я думаю будет. На таком примере.

Вот вы представляйте что от вашего сна зависит ВСЁ! Всё при всё. Вот от того как вы сегодня поспите зависит будет завтра чего дома жрать или нет. Зависит будет ваша дочть замужем или нет. Вырастет ваш сын неудачником или добьётся чего-то в жизни. Всё это зависит от того как продуктивно вы сегодня поспите.

Представили?

И вот вы собираетесь начать этот сон. Этот вот самый сон от которого ВСЁ зависит и вы это отчётливо осознаёте.

Скажите вот теперь. Как насчёт спать и одновременно немножко, краем глаза разговаривать, чуть чуть помогать сыну решать арифметику, немножко подглядывать в телевизор и чуть чуть так совсем немного съездить в магазин? Не на долго…

Как спится, сладко?

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

Вы бы так смогли КАЖДЫЙ ДЕНЬ?

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

Хотите?

Призодите работать программистом в нашу контору. Получите в полной мере!

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

Ну так вот и программисты тоже такие бывают. Они всегда находятся в состоянии близком ко сну. Чуть не мешает никто — сразу «брык» и в сон. Не глубоко, только на чуть чуть. Особо серьёзных никаких химер не успеешь понагрезить, но чуть-чуть немножко слабо-туманных вполне успеешь. Вот в такой сон.

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

Ну потому что отвлекают постоянно. Потому что БУДЯТ же бля постоянно! Потому что люди не понимают что ты же спишь и что их ебучая менеджерская «организационная» активность она на самом деле только мешает работать. Большинство людей НЕ программистов этого не понимают.

Я надеюсь что осознав аналогию работы программиста со сном может быть люди лучше поймут как надо обходиться с программистами и откуда вообще берутся хорошие программы. Поймут наконец что вот этот ебучий ЖЖ — это то что пишу и читаю ПЕРЕД СНОМ. Вот также как вы. Вы не можете спать пока неначитаетесь или пока телевизор не насмотритесь. Не можете ведь?

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

Хотите хороших программ?

Хотите чтобы ваш муж-программист был успешен и заработал все деньги?

Хотите чтобы ваши подчинённые программисты наконец-то сделали всё как надо?

Тогда вот вам простой рецепт:

НЕ БУДИТЕ СЛИШКОМ ЧАСТО ПРОГРАММИСТА!

Источник: http://alexthunder.livejournal.com/290612.html
0
1

Перепост →  Обсуждение проекта Налогового Кодекса в ГосКомПредпринимательства

16 августа в ГосКомПредпринимательства состоялось совещание на тему «Использование упрощенной системы налогообложения для компаний, работающих в ИТ-сфере».

От чиновников были: керівник служби Віце-прем’єр-міністра України з питань економіки, Воробей С. И., голова Держкомпідприємництво України, Бродский М.Ю.

От компаний: АктівМедиа, lemon.ua, Мірасофт Груп, Софт-Индастри, Сіклум, представитель Ukrainian Hi-Tech Initiative и АПІТУ. Я официально представлял интересы фрилансеров и самозанятых.

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

Встреча заняла чуть больше двух часов. Первые минут 30 Бродский рассказывал, что будет в НК и почему. По его словам, та версия, что была опубликована в Урядовом Кур’єрі уже безнадежно устарела. Это был первый сюрприз.

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

Тем не менее, обсуждение было и в общем довольно эффективное. Хорошо, чтобы было где-то 10 человек, так что «базар-вокзала» не было.

Суть изменений (по отношению к той редакции, что была опубликована):

1. Деятельность в сфере автоматизации и ВЭД на упрощенке оставят, но только для одной категории — ИТ. При этом будет и специальная «акционная» цена, 1500 грн единого налога в месяц. Лимит — 300 тыс. грн. При превышении лимита автоматически переводят на общую систему налогообложения. Платеж в ПФ (320 грн) тоже остается, т.е. получается 1820 грн.
2. Для не-ИТ будет ставка единого налога от 200 до 600 грн плюс ПФ.
3. Для ИТ уберут пункт 12.1 (требование о том, что на одного заказчика/клиента для СПД разрешено не более 50% дохода за 3-6-9 месяцев).
4. Для юрлиц на упрощенке будет два варианта: 3 млн плюс 0% на прибыль на пять лет («дает лично Янукович») плюс 5% налог на дивиденды и второй вариант — 2 млн и 5% с оборота.

В твиттере меня спрашивали, откуда взялась цифра в 1,5 тыс. грн единого. Объясняю как я это понял.

Средняя зарплата шахтера абстрактного рабочего это 4 тыс. грн. Он платит 53% налогов — ФОТ + НДФЛ. Программисты получают больше и если бы работали как сотрудники платили бы 4-5 тыс. грн. Мы понимаем, что они такие деньги платить не будем, поэтому компромисс — возможность работать на едином налоге, но будьте добры платить 1,5 тыс. грн. Разница в цене с «обычным» единым в 600 грн за привилегию вести ВЭД плюс ИТ.

Компании пытались поторговаться. Вот только чтобы торговаться, нужны рычаги давления, а с этим проблемы. Тем не менее, предложение было такое: оставьте 600 грн единого для ИТ, но запретите ВЭД для физлиц. Тогда ВЭД будет вести украинская компания-юрлицо и работать по привычной схеме с СПД, но платить 600 грн вместо 1500. На это получили категорическое нет, хотя в какой-то момент мне показалось, что ВЭД действительно могут забрать.

Еще над одним предложением пообещали подумать. Вариант следующий: 6% с оборота вместо 1500 грн, при этом компании-юрлица не смогут относить на валовые расходы операции за наличный расчет, только безнал. Т.е. смысл в том, что компании будут платить СПД на 2600* и соответственно эти потоки легко проконтролировать. При этом 6% от 15 тыс. грн это 900 грн, а не 1500. Какая-то, но экономия. Насколько мне показалось, шансы что это пройдет совсем небольшие.

Если доход меньше 10 тыс. грн то физлицам предлагают не оформляться как СПД на едином, а оформляться как независимое самозанятое лицо и платить 15% НДФЛ.

По срокам — по-прежнему считается, что новый НК вступит в действие с 1-го января 2011, максимум — со второго квартала.

Вопрос о том, где и когда можно будет увидеть новую версию НК остался без ответа.

По лимиту в 300 тыс. грн — нам сказали, что это требование МВФ. И если мы хотим его убрать придется сначала вернуть 15 млрд. долларов МВФ. Все тот же пресловутый МВФ оказывается вообще требовал убрать упрощенку, но ее «отстояли».

Такие дела. Выводы: так или иначе, платить будем в разы больше. Как именно все будет работать и что конкретно будет с ВЭД и физиками — пока до конца непонятно.

Комментарии других участников ожидаются, дополню по мере поступления.

UPDATE: Размышления на тему.
Несколько раз включался тезис о том, что государство пытается создать равные условия для бизнеса. При этом наличие упрощенной vs. общей системы налогообложения – это уже неравные условия. Упрощенка появилась только потому, что нагрузка в 55% на общей системе просто делает невозможной легальную работу многих видов бизнеса.

С отчислениями в ПФ кстати ровно то же. Система у нас солидарная — т.е. отчисления, которые мы делаем сегодня идут сегодняшним пенсионерам, а не плательщику как будущему пенсионеру. Иными словами, если у вас нет родственников пенсионеров вы автоматически в неравных условиях с теми, у кого такие родственники есть. Т.е. сирота платит вообще непонятно за кого и по сути это не ПФ, а просто еще один налог.

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

Источник: http://www.developers.org.ua/archives/max/2010/08/16/mihailobrodskiy-2/
1

Управление проектами →  Как программисты строили дом (Юмор)

1.03. Уpа! Hам пpедложили кpупный контpакт на постpойку 12-этажного жилого дома. У всех буpный энтузиазм. Выпили на pадостях 2 ящика пива.

2.03. Заказчику не нpавится выpажение «как только, так сpазу». Тpебует назвать конкpетные сpоки. Темный, ничего не смыслит в высоких технологиях.

3.03. Обсуждали сpоки. Выпили 3 ящика пива. Петpович говоpит, что тут всей pаботы на 4 месяца. Значит, на самом деле 8. В итоге в контpакте записали 12, хотя pаньше, чем за 16, вpяд ли упpавимся.

6.03. Петpович пошел сдавать бутылки.

8.03. Отмечаем 8 Маpта. Женщин у нас в фиpме нет, так что пpаздник никто не поpтит.

2.04. Петpович говоpит, что поpа начинать pаботать. Сговоpились они, что ли? Обнесли площадку забоpом и повесили кpасивые плакаты «Стpоительство ведет компания „Аllstroу“ (www.аllstгоу.ru)». С чувством выполненного долга игpаем в Quake.

20.04. Пpишел заказчик, интеpесовался, как дела. Посадили его за Quake и позволили нас всех обыгpать.

21.04. Обсуждали пpоект. Сидоpов пpедлагает кpупноблочную аpхитектуpу. Петpович настаивает, что все надо стpоить по стаpинке, из киpпича, не по-ламеpски. Самый pадикальный пpоект пpедложил Алекс: постpоить несколько десятков деpевянных коттеджей и потом соединить их подземными туннелями. Hа Западе сейчас так модно. Hапомнили ему, что заказчик тpебует именно 12-этажный дом. Пытались pешить вопpос дуэлью в Quake. Алекса с его коттеджами завалили сpазу, но между Петpовичем и Сидоpовым вышла ничья. В итоге каждый будет стpоить по своему плану, а потом попытаемся все это соединить, чтоб не pухнуло.

30.04. Пеpвый этаж готов! Показали его заказчику. Он интеpесовался, почему в pазных комнатах pазная высота потолков, почему из стен вываливаются киpпичи и почему в доме нет подъезда, а влезать пpиходится чеpез окно. Объяснили ему, что это специальные огpаничения демо-веpсии. Уходим на пpаздники, гоpдые собой.

10.05. Петpович пpотpезвел пеpвым и долго pугался. Мы думали, что Алекс выпил все пиво. Оказалось хуже: мы забыли пpо фундамент. В пpоекте он, конечно, описан, но ведь документацию читают только ламеpы.

11.05. Ломали пеpвый этаж. Обидно, блин.

11.07. Работаем. Петpович достpаивает втоpой этаж, Сидоpов — пятый. Алекс отгpохал шахту лифта до девятого этажа, она в сильный ветеp подозpительно качается. Вpеменно поставили деpевянные подпоpки.

17.07. Алекс стpоит чеpдак и кpышу. Hа земле. Потом поднимем кpаном.

13.08. У Сидоpова не стыкуются панели. Щель больше метpа. Сидоpов позвал Петpовича, но тот заявил, что у него своих дел по гоpло и вообще без знания внутpенней аpхитектуpы панелей ничего сделать нельзя.

14.08. Разломали несколько панелей, чтобы Петpович мог изучить внутpеннюю аpхитектуpу. Петpович pугается, кpичит, что пpоектиpовщики панелей — полные ламеpы.

17.08. Петpович заделал дыpу. Пpавда, панели пpи этом пеpекосились, но это уже мелочи. Пpоводку из обеих панелей пpишлось вывести наpужу и связать узлом. Петpович замотал узел изолентой и увеpяет, что будет pаботать, если только дождь не пойдет.

1.09. Стpойкомбинат выпустил новую веpсию панелей, улучшенной пpочности и утепленности, со встpоенными стенными шкафами. Пpавда, ни по фоpме, ни по pазмеpу они не совместимы с пpедыдущими и в тpи pаза тяжелее. Hа какую аpхитектуpу они вообще pассчитывают, эти комбинатские?

16.09. Пpибежал Алекс, обуpеваемый идеей. Пpедлагает сделать все окна в доме изменяемого pазмеpа. Говоpит, за-казчик будет тащиться. Сказали ему, чтоб не выпендpивался.

2.10. Петpович добpался до пятого этажа. Гоpд собой. Обpатили его внимание на тот факт, что его стена наклонена под углом 40 гpадусов. Он pугался, кpичал, что мы ламеpы и ничего не понимаем. Потом обещал подумать.

3.10. Пpиходил заказчик. Спpосил, почему стена наклонена под углом 40 гpадусов. Объясняли ему пpо силу Коpиолиса. Он все выслушал, потом сказал, что он, конечно, в стpоительном деле ничего не смыслит, но у него по соседству точно такой же дом, и там стена пpямая. Блин. Потом этот идиот Алекс ляпнул пpи нем пpо свои изменяемые окна. Заказчик, естественно, загоpелся и настаивает, чтоб делали именно так. Дважды блин.

4.10. Спpосили Алекса, пpидется ли все pазбиpать pади его окон. Он увеpяет, что нет — будто бы и у стандаpтных панелей есть такая недокументиpованная функция.

5.10. Петpович пpизнал, что со стеной действительно имеется пpоблема. Говоpит, что непpавильно положил какой-то киpпич. Hо чтобы понять, какой именно, надо пеpебpать их все. Пpоще все снести и постpоить заново.

6.10. Убеждали Петpовича, что постpоить все заново из киpпича он уже не успеет. Демонстpиpовали ему pасчеты на калькулятоpе. Петpович pугался, кpичал, что калькулятоp пpидумали ламеpы. Потом все-таки согласился стpоить из панелей и ушел с гоpя в запой.

8.10. Ломали киpпичную часть. Попутно повpедили панельную. Вся постpойка скpипит и угpожающе шатается. Укpепили деpевянными подпоpками и пошли игpать в Quake.

17.10. Петpович вышел из запоя. Работаем.

7.11. Пpазднуем 7 Hоябpя — или как оно там тепеpь называется? Коммунистов у нас в фиpме нет, так что пpаздник никто не поpтит.

15.11. Вспомнили, что у нас кpан достает только до 8 этажа. Послали Сидоpова доставать новый кpан. Игpаем в Quake. Алекс замочил Петpовича. Растет смена!

24.11. Веpнулся Сидоpов. Кpан не достал, зато достал кpутой экскаватоp. Пpедлагает выpыть глубокую шахту и постpоить дом не в высоту, а в глубину. Говоpит, что нигде в контpакте не сказано, что 12 этажей должны быть над повеpхностью. Еле отговоpили.

25.11. Устpоили мозговой штуpм по пpоблеме кpана. Hа последней бутылке пива нашли pешение. Бpосили основное стpоительство. Стpоим pядом 4-этажный дом. Потом втащим наш кpан ему на кpышу.

25.12. Пpазднуем католическое Рождество. Католиков у нас в фиpме нет, так что пpаздник никто не поpтит.

14.01. Hичего не помню. Голова болит. Мужики, какой сейчас год?

2.02. Hу, кажется, наконец-то достpаиваем 12-й этаж. Завтpа будем пpилаживать свеpху чеpдак и кpышу, что сооpудил Алекс.

3.02. Алекс — ламеp. Кpыша pегуляpно съезжает. Пока подпеpли кpаном. Думаем, что делать дальше.

4.02. Алекс доказывает, что он не виноват. Пpосто 12 этажей Сидоpова на 4 метpа выше и на 5 метpов шиpе, чем 12 этажей Петpовича. Выяснилось, что они стpоили из pазных панелей. Hо Алекс все pавно ламеp, поскольку его кpыша не подходит по pазмеpу ни одному из ваpиантов. Его шахта лифта, кстати, тоже.

5.02. Латали, укpепляли и наpащивали кpышу. Петpович говоpит, что будет деpжаться, если снег не пойдет.

7.02. Снег пошел.

10.02. Соорудили крышу из фанеры, покрасили под жесть. Будем надеяться, заказчик не заметит.

11.02. Тестировали лифт. Его остановки приходятся между этажами, но выбраться из кабины можно. Hа четных этажах ползком, на нечетных — подтягиваясь. Hе забыть описать это в документации.

12.02. А вообще-то лифт ездит крайне медленно. Петрович ругает всех ламерами и собирается заняться оптимизацией.

13.02. Петрович оптимизировал лифт. Тот разогнался, пробил крышу и улетел в неизвестном направлении. Хорошо, что крыша фанерная, и чинить будет легко. После этого шахта лифта рухнула. Вспомнили, что так и не заменили деревянные подпорки на что-нибудь более прочное. Hичего. Ходить пешком полезно.

15.02. Идут отделочные работы. Почему-то куда-то исчезают маляры и штукатуры. Договорились, чтоб прислали еще.

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

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

21.02. Приходил заказчик. Спрашивал, нельзя ли внести в проект небольшие изменения. В частности, вместо 12-этажного дома построить поселок из деревянных коттеджей, соединенных туннелями. Он прочитал, что на Западе сейчас так модно. Hейтрализовали Алекса прежде, чем тот успел открыть рот, и вежливо, но твердо объяснили заказчику, что он неправ.

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

23.02. Праздновали 23 февраля. Военных у нас в фирме нет, так что праздник никто не портил. Женщин тоже нет, так что подарков нам никто не дарил. Обидно.

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

27.02. Вспомнили, что так и забыли сделать подъезд. Размышляли, не рухнет ли дом, если прорубить его сейчас. Сидоров сказал, что лучше не рисковать. Петрович обозвал его ламером и согласился. Hе забыть описать в документации вход через окно как особенность дизайна.

1.03. К-как первое марта?! Откуда?! Вчера же еще… Блин. Кто ж знал, что в этом ламерском феврале 28 дней! Выходит, сдача объекта — не через неделю, а послезавтра?!

2.03. Аврал. Работаем 24 часа в сутки, не просыпаясь.

3.03. Убедили заказчика, что нам нужен еще день для финального тестирования. М-да, ну мы вчера и наработали… А в общем, не все так страшно. Hу что с того, что некоторые двери находятся в полу или в потолке, либо ведут с десятого этажа прямиком на улицу, в некоторые квартиры в принципе невозможно попасть, санузел кое-где совмещен с кухней, в половине дома нет воды, в другой половине — электричества, канализация обрывается на шестом этаже, а лестницу между восьмым и девятым пришлось сделать веревочной? Главное — провести заказчика правильным маршрутом. И еще — успеть до завтра развесить на месте исчезнувших окон картинки с изображением заоконных пейзажей…

4.03. Yes! Yes! Мы сделали это! Отмечаем сдачу объекта. Я пью мало, мне надо еще успеть уволиться, прежде чем эта хренотень рухнет к чертовой матери…

Источник: Moskalyuk.com
1

А мне интересно →  Вы верите в байки о программистах? Кто мы? Люди будущего или дауны?

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

Я тут смотрела фотки с нового года для детей сотрудников и поняла — основой нового общества станут программисты. То есть, как после атомного взрыва выживут тараканы и крысы, так после постмодернизма, «смерти взрослых», социетального кризиса и окончательного исчезновения реальности выживут программисты. Я практически уверена. Они будут господствующей разумной формой жизни на Земле, потому что, именно они обладают всеми признаками обеспечивающими выживание.

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

Во-вторых, программисты сохраняют матримониальное поведение, чем так же повышают свои шансы на выживание. В отличие от остальных они создают семьи, которые как известно, являются наиболее устойчивой социальной формой существования.
Идея о том, что программисты это жуткие тщедушные, занудные ботаники, которые естественным образом выпадают из процесса размножения — ошибочна. Во-первых, они бывают разные, во-вторых, разбирают всех! Честно вам говорю. Причем жутких и тщедушных быстрее остальных. Потому что, на самом деле, программист это весьма подходящая для семейной жизни штуковина! Он безобиден, тих, верен и зарабатываем много денег. А самое главное, программист хочет жениться, потому что добывать секс и еду в борьбе на вольных выпасах ему не интересно, лениво, да и просто страшно. В результате он с радостью покоряется первой же девушке, которая решит отвести его в ЗАГС.
Разводится программист тоже только в одном случае — если сходит на психологический тренинг, но это бывает крайне редко. Да и то, он потом сразу же снова женится, на чем-то аналлогичном. В результате программистские семьи просто нереально показательно крепки.

Третье. Как известно, залогом выживания вида является размножение. И, я скажу вам, програмисты размножаются! У нас в конторе на 80 сотрудников уже около 60 детей. У многих по двое, у некоторых по трое.
Происходит это потому, что средний программист уютнее и увереннее всего ощущает себя в положении «уткнувшись в комп». Он допоздна торчит на работе, а когда приходит домой, то снова принимает удобное положение. В это время его жена стервенеет от невнимания и скуки. Первый год она надеется, что все изменится, второй — скандалит, на третий плюет, рожает и начинает развлекаться самостоятельно ребенком. Для программиста ребенок это практически единственный способ сделать так, чтобы жена была относительно удовлетворена и отстала от него. Правда приколюхи хватает года на два, потом ей снова становится скучно и тогда заводят второго, благо денег хватает.
В общем, пока крутые доминирующие самцы хлещутся в страстях, пьянках и интригах программисты тихо делают свое дело. Угадайте, чьих детей в итоге будет больше?

В-четвертых, программисты обладают завидной психологической устойчивостью. Если программист пережил институт (говорят на математических и ITшных факультетах самый большой процент сходов с катушек) то он практически неуязвим в психологическом плане. Дело в том, что программисты воспринимают и строят жизнь как некий алгоритм с ответвлениями возможных вариаций. Их мир стабилен и прост, а объективная реальность интересует слабо. Вчера два сотрудника спросили меня: «Маш, а че все по какой-то кризис раздувают, расскажи, а?» Вчера!
От этого у программистов не бывает страхов, серьезных жизненных сомнений и не случается неожиданностей. Так же у них, по большей части, напрочь отсутствует навык рефлексии, поэтому, даже имеющиеся у них комплексы, они не ощущают. Тот дискомфорт и неуверенность которые они, возможно, испытывают в реальном мире проходят у них по графе «невнятных ощущений» и, не получая никакого развития, просто игнорируются.
Устойчивости им добавляет еще и то, что большинство программистов действительно любят свою работу и получают от нее моральное удовлетворение. Они творят! Какой процент остальных людей может похвастаться тем же? Вооот. При этом, им не нужно нюхать кокс и тусоваться ночами как киношникам и музыкантам.
Словом, в то время как весь остальной мир тщетно носится по психоаналитикам и бухает от непонятной тоски, программисты чувствуют себя в полном порядке.

Ну и пятый фактор это образ жизни. Не сказать, чтобы он у программистов был очень здоровый, но с другой стороны я думаю, что пора бы уже пересмотреть этот термин. Согласитесь, все эти упругие мускулы, крепкие ноги и ловкие руки не являются залогом выживания в современном мире. А даже наоборот, являются опасной роскошью и повышают риск помереть в цвете лет (например, подхватив СПИД от очередной девицы, которая повисла на тебе в баре). Я давно уже заметила, что дольше всех живут не спортсмены и комсомольцы, а буфетчики и вахтеры. Не те, кто тренировался, а те, кто изнашивался как можно меньше. С этой точки зрения программисты практически законсервированы! Они как стеклянные банки — если не ронять, то практически вечны.

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

Единственное, уязвимое место программистов это их крайне низкая способность к объединению и взаимодействию. Обороняться стаей они не способны, потому что у них проблемы с общением, и каждый из них считает себя умнее других.
От этого самоорганизующиеся программистские системы не эффективны в плане самообеспечения, и совершено не устойчивы к внешним воздействиям. Проще говоря, если кучку программистов оставить на некоторое время без присмотра (читай без управления), они очень быстро скатываются в производство не продукта, а прикольных фиговин для самих себя. Как правило, эти фиговины остальным людям не интересны, поэтому программистам перестают давать за них деньги. Соответственно программисты умирают от голода.
Но на этот случай у программистов тоже есть регулирующий механизм: Менеджер. Их самый страшный враг и единственный друг. С одной стороны он заставляет их делать то, что им не интересно, тем самым подкашивая их ощущение бога, но с другой — он обеспечивает их выживание, сохраняя восстребованость продукта, поэтому они его терпят. По сути, менеджер такой же залог выживания программиста, как фермер для пшеницы: культуру необходимо возделывать, иначе она дичает.
Поэтому если в кучке программистов заводится толковый менеджер, они, сцуко, делаются непобедимыми!

В общем я думаю, что если расклады не изменятся, то все остальные группы населения постепенно переубиваются ап стену, а программисты останутся. И люди будущего будут не теми гармонично развитыми мультиталантливыми суперменам как у Ефремова в «Часе Быка», а программистами с легкой норвежской примесью.
Ах, да, чуть не забыла вам сказать: Норвеги тоже выживут, потому что они не пьют, не курят, все как один бегают на лыжах, внешним миром не интересуются и живут в согласии с природой. Мне Моргана рассказывала.
0
2

Управление проектами →  Упражнение для программистов. Почувствуйте себя программистом.

Абсолютно точное отражение нашего взаимодействия с заказчиком.

Благодаря этому уникальному упражнению, вы, совершенно не зная ни одного языка программирования, сможете почувствовать себя настоящим программистом-профессионалом!


Для упражнения потребуются:
— два участника;
— часы (желательно с секундомером);
— листок чистой бумаги;
— ручка (шариковая или гелевая, но именно ручка, — это важно).

Один из участников будет «Заказчиком» (Работодателем), другой «Исполнителем» (Программистом). «Заказчику» выдаются часы и право голоса, «Исполнителю» — бумага и ручка.

Начало упражнения:
«Заказчик» засекает 10 минут и дает задание «Исполнителю»: «Нарисуйте мне, пожалуйста, красивую девушку.»
Далее, пока «Исполнитель» рисует, стоя у него «над душой», высказывать следующие пожелания к рисунку:

0:30 — Пусть у нее в руке будет меч.
1:00 — Двуручный меч, который она держит обоими руками!
1:30 — А в другую руку ей дайте УЗИ.
2:00 — Пусть она будет уставшей путешественницей, присевшей отдохнуть.
2:30 — На меч она опирается, отдыхает, значит.
3:00 — Пусть на ней будет развивающийся по ветру плащ!
3:30 — …И купальник.
4:00 — А лучше доспех!
4:30 — Не… униформа!
5:00 — Уберите плащ, он не идет к униформе.
5:30 — Пусть она смело стоит на мостике космического крейсера!
6:00 — Почему у нее меч? Уберите это старье. А УЗИ переделайте в бластер!
6:30 — Ее волосы развиваются по ветру… для красоты, значит.
7:00 — Бластер не смотрится… уберите его. Она вообще капитан этого корабля, ей не нужен бластер!
7:30 — Ей нужна фуражка капитана! И аккуратно собранные на голове волосы!
8:00 — И сидеть она должна в кресле капитана!
8:30 — Красивая, суровая и необычайно смелая капитанша корабля пиратов…
9:00 — Нет, эскадры боевого флота Галлактической Федерации!
9:30 -… Вытягивая палец, отдающая приказ о смене курса…

По истечению 10 минут «Заказчик» берет работу «Исполнителя», критически ее осматривает и высказывает свое впечатление:

«Ну это же совсем не то, что я хотел! А где ее верный советник? А почему у нее нет табельного оружия? И вообще, почему она такая некрасивая и суровая? Я же просил КРАСИВУЮ девушку! И вообще на рисунке столько каракулей… Плохой вы программист, зря я к вам обратился… Не буду платить за такую халтуру!»

Для большей остроты ощущений, можно взять целую «Команду Разработчиков», и пусть они вместе рисуют «большой и красивый пейзаж» за 10 минут.
0
1

Что новенького →  Жизненный цикл программиста Часть 3

Начало:
Жизненный цикл программиста Часть 1
Жизненный цикл программиста Часть 2

После ухода из «Параграфа», я не смог найти другую работу, в основном по принципу «двух медведей в одной берлоге», когда начальник не хотел иметь в команде еще одного лидера. Поэтому в 1994 году мне пришлось заняться бизнесом, организовав свою фирму «ДИСКо» (Donskoy Interactive Software Company), существующую по сей день. Фирма занимается разработкой программ на заказ. Основными клиентами являются крупные фирмы, работающие в области информационных технологий. Связано это, в первую очередь с тем, что доказывать разумность нашей ценовой политики клиентам из других отраслей крайне сложно. Они искренне полагают, что любую программную систему можно сделать одному человеку за месяц. Ситуация усугубляется тем, что рынок полон дешевых предложений, связанных либо с самонадеянностью вчерашних студентов, либо, что еще хуже, с сознательным затягиванием клиента с целью дальнейшей раскрутки его уж на совсем большие деньги. Это напоминает «бесплатные» лекции по народной медицине, где вход формально свободен, а выход фактически с пустым кошельком.

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

До кризиса доткомов «ДИСКо» работало в основном на рынке США, но после него пришлось переориентироваться на российский рынок. Одну вещь после этого перехода пришлось прочувствовать сразу. В Америке ни один менеджер не ведет переговоры вне рамок своей компетенции и, особенно, вне рамок своего бюджета. В России, особенно на первых порах, много раз приходилось, уже придя к соглашению по всем параметрам проекта – техническим требованиям, цене, срокам, — слышать замечательную фразу «А теперь я пойду согласовывать это с начальством». Эффективность переговоров с такого рода менеджерами, мягко говоря, невелика. Отсюда – нацеленность «ДИСКо» работать с крупными кампаниями, про которые ясно, кто есть кто.

В начале этого тысячелетия пришлось сделать еще один крутой поворот. На этот раз — в сторону мобильных устройств и всего, что с ними связано, в первую очередь, беспроводными технологиями связи. Поскольку первые заказы были американскими, приходилось убеждать авторов технологий в их «незрелости» для практического использования. Слышать это от маленькой российской фирмы им было странно. К счастью, это потом подтверждалось и другими, более авторитетными источниками. Так было, например, с технологией BlueTooth, про которую было много критики на CeBit-2002. Мы сделали пилотный проект для разных средств связи по заказу 3COM, и, если инфракрасная связь и WiFi работали прекрасно, то с BlueTooth были серьезные проблемы.

Однако с 2004 г. с BlueTooth стало все в порядке, а мобильные устройства становятся все популярнее и популярнее. Хотя карманные компьютеры и сходят на нет, их с успехом заменяют (а может, и вытесняют) смартфоны, имеющие все прелести и карманных компьютеров и мобильных телефонов. Для лэптопов и ноутбуков сейчас тоже очень хороший сезон. А впереди маячат планшетные компьютеры и сетевые и многое другое.

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

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

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

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

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

Похожая история должна произойти с Symbian, операционной системой, установленной на телефонах Nokia и Sony Eriicsson. Подход ее авторов тоже был минималистским. Она, конечно, лучше, чем Палм, но все равно, крайне трудна для программистов. А именно программисты решают все. Самой лучшей операционной системой последние 30 лет является Юникс, но плохой пользовательский интерфейс привел к тому, что более популярно изделие Майкрософта.

Кроме того, программисты, пишущие для Юникса, имеют весьма специфический характер. Их почему-то больше волнует идеологическая чистота системы, чем ее преимущества для пользования. Однажды я работал с «юниксоидом», делавшим серверную систему для салона игровых автоматов. На все мои требования сделать возможной выдачу статистики игр, он отвечал, что это уменьшает безопасность системы. То, что в данном случае гораздо большую опасность представлял собой вульгарный сговор персонала с игроками, против которого и нужна статистика, его не волновало. Видимо, в книгах по Юниксу это нигде не написано.

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

Пока последний поворот в моей программистской биографии – видео в Интернет. Интернет, точнее, мировая паутина – это особая тема для разговора. Она обладает врожденным пороком. Это — система, придуманная для обмена гипертекстовой информацией в распределенных сетях. Однако за свои 13 лет, начиная с появления «Мозаики», паутина эволюционировал в сторону системы доступа к гигантскому хранилищу информации.

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

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

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

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

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

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

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

Они не понимают, что если заказчик меняет требования к уже почти готовой системе, это означает, что система ему нравится. Если система ему не нравится, он вздохнет, заплатит за нее и про нее забудет.

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

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

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

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

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

Михаил Донской

Взято здесь: http://polit.ru/science/2008/08/20/programmist.html
0

Что новенького →  Жизненный цикл программиста Часть 2

Начало:
Жизненный цикл программиста Часть 1

А в 80-х началась эра языка Си на машинах, скопированных с PDP и IBM PC. Мы потеряли весь свой ассемблерный «языковый запас» и так и не достигли аналогичного уровня инструментария на Си. Это была своего рода эмиграция. Привыкнув к детальному пониманию, как происходят реальные вычисления в памяти, пришлось отвыкать и работать в гораздо более абстрактных сущностях.

Зато остался интерес к базовым понятиям программирования, выходящим за пределы конкретных языков, операционных систем и устройств. Как любят говорить мои сотрудники «В конце концов, в компьютере биты бегают».

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

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

Создание собственного «языка программирования» и отладочных средств для конкретного проекта оказало решающее влияние в победе «Каиссы» на первом чемпионате мира среди шахматных программ. Большая часть программы была написана в терминах операций над «досками» — 64 битными объектами, которые задавали булево значение одновременно для всех полей доски. Эффективная реализация таких операций и их использование в алгоритмах позволили реализовывать сложные решающие правила за приемлемое время.

«Система наблюдения» «Каиссы» состояла в возможности вывода на печать хода перебора в любом разрезе, начиная с любой точки, как в партии, так и в переборе. Что важно, сама форма выдачи была «человеческой», то есть в шахматных терминах, а не в терминах программы. Во время матча «Каиссы» с читателями «Комсомольской Правды» в 1972 году результатом каждого хода была распечатка толщиной 2-3 сантиметра. И мы ее всю внимательно прочитывали. Поэтому к чемпионату мира мы знали о глубинах перебора гораздо больше, чем все остальные. В этих условиях было трудно не придумать эффективные методы сокращения перебора, которые и принесли «Каиссе» победу. Кстати, в научных кругах, матч 1972 года ценится гораздо выше, чем победа в чемпионате мира.

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

Если до середины 80-х еще реальны были программы, созданные если не одним человеком, то хотя бы в рамках одного коллектива, то в дальнейшем в производство шли программы, построенные по принципу «Лего», а именно, собранные из различных полуфабрикатов (библиотек и компонент), разработанных в разных уголках мира.

Как ни странно, это сделало ценность программистов с хорошим математическим (не скажу образованием, а подходом) гораздо выше. Их стали называть по-разному – системными аналитиками, руководителями проектов, системными архитекторами. И наряду с программистами, умевшими «выполнить проект» — реализовать конкретное техническое задание, — потребовались именно такие «абстрактные» специалисты, умевшие совсем другое. А именно, разбить процесс создания большой системы на проекты, выбрать для них инструментарий, подобрать исполнителей, суметь их проконтролировать и, в конечном счете, обеспечить работоспособность созданной системы. И сегодня таких специалистов приблизительно столько же, сколько было программистов в начале моего трудового пути.

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

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

Однако инструментарий инструментарием, но приходится выбирать алгоритмы обработки информации, и иногда ограничения на их трудоемкость влияют на размер решаемых задач, а, значит, и подходов. Здесь мой опыт семинара по эффективным алгоритмам и, особенно, опыт работы над шахматной программой, сыграл существенную роль. Как говорил мой соратник А. Усков «после шахматной программы все задачи кажутся простыми».

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

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

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

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

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

Вернемся к 1980-м. Еще до перестройки мы — отдел ВНИИСИ под руководством В. Арлазарова — локально победили институтскую и академическую бюрократию за счет того, что на игольчатом принтере «Электроники» смогли изобразить шрифт печатной машинки. В то время, например, было запрещено подавать к защите диссертации, напечатанные на компьютере, но с нашим шрифтом понять, что это печать компьютера, а не машинки, без специальной экспертизы было нельзя. Аналогичным образом дело обстояло со многими другими документами – планами, отчетами, выездными характеристиками и так далее.

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

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

В начале российской эпохи персональных компьютеров, случайно или не случайно совпавшей с кооперативным движением, ко мне обратился прекрасный менеджер Е. Соколинский, возглавлявший кооператив «Перспектива» с предложением реанимировать «Каиссу» для ПК. Для этого мне нужно было из работавшего в свое удовольствие ученого стать начальником группы программистов, да еще и создать эту группу с нуля. Уговорив меня, Соколинский нашел изумительный способ формирования группы. Мы дали объявление в газеты о платных курсах шахматного программирования. Стоимость месячного обучения для наших слушателей составляла 200 рублей, что по тем временам была существенная сумма. Занятия шли шесть дней в неделю и кооператив доплачивал за аренду аудиторий и компьютеров немалую сумму.

Из десяти слушателей, которых мы тщательно отобрали, только один человек пропустил одно занятие потому, что у него в этот день был выпускной из Физ-теха. Потом мы всей группой перешли в СП «Параграф».

В конце 1980-х, когда я оказался в СП «Параграф», он представлял собой своеобразную сборную лучших московских программистов. В «Параграфе» того времени работали Е.Веселов (автор «Мастера» и «Лексикона»), А. Чижов (автор многих русификаторов, в частности, знаменитой «Беты», он же автор альтернативной таблицы кодировки кириллицы) и другие. В качестве помощницы у Веселова в «Параграфе» работала О. Дергунова, получившая известность уже в Майкрософте. Игры продавал В. Савюк, потом раскрутивший марку «Денди». В общем, компания подобралась неплохая.

По дороге пришлось пережить очередной крутой поворот – появилась Windows 3.1, и пришлось от традиционного процедурного программирования переходить к системам, управляемым потоком событий. Сегодня они привычны и понятны, а тогда ушло много усилий на понимание, «куда лошадь запрягать», а именно как устроен порядок исполнения кода в таких системах. Поток управления в них весьма неочевиден, и проблемы многопоточности и синхронизации вышли на первый план.

У меня в «Параграфе» был отдел шахматного программирования, в котором «Каисса» получила вторую жизнь в качестве программы для IBM PC. Хотя мы и сделали в отделе шахматную программу – реинкарнацию «Каиссы» для IBM PC, которая достойно сыграла на компьютерной олимпиаде 1990 года, заняв третье место, интерес быстро сдвинулся в сторону пользовательского интерфейса, поскольку графические оболочки Мака и Windows очень манили в эту сторону.

Наш отдел, в котором работали А. Дубец, М. Караев, В.Кокин, И. Шабалин и другие, открыл целое направление графических редакторов. Мы сделали редактор формул, а, уже уйдя из Параграфа, и редактор факсов, а потом и новую версию Лексикона.

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

В это же время пришлось осваивать C++. Мое знакомство с этим языком началось с экскурсии в офис Bell Laboratories в Murray Hill, которую мне устроил в 1989 году автор Юникс Кен Томпсон. Мы с сыном жили у Кена в гостях, и в воскресный вечер он предложил прокатиться в офис. Офис был безлюден, и я с интересом смотрел на технические чудеса, которых там хватало. В какой-то момент Кен показал на дверь кабинета со словами «А здесь сидит чудак, который думает, что на его языке будет программировать весь мир». Табличка на кабинете гласила, естественно, «Б. Страутсруп».

Потом пришлось-таки учиться программировать на C++. Язык очень коварен. На нем должны программировать либо начинающие программисты, которым важно быстро получить результат любыми средствами, либо очень опытные. Создание больших систем на C++ программистами среднего класса может приводить к самым печальным последствиям. Однажды в книжном магазине Стэнфордского университета я видел книжку по C++, напоминавшую сборник кроссвордов. Там приводилось множество выражений на C++, выглядевших очень естественно, но транслировавшихся в умопомрачительный набор команд.

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

Продолжение:
Жизненный цикл программиста Часть 3
0

Что новенького →  Жизненный цикл программиста Часть 1

Статья известного российского системного программиста, зав. лабораторией Института системного анализа РАН, члена Российской академии интернета, автора шахматной программы «КАИССА» (первого чемпиона мира среди шахматных программ), президента компьютерной фирмы ДИСКо, лауреата всех профессиональных опросов «Top-100 Российского компьютерного бизнеса», Михаила Донского.

У каждой профессии есть свой романтический период и есть период, когда она превращается в рутинную. Быть шофером в начале прошлого века было трудно и почетно. Сегодня автомобиль может водить любой желающий, а в большинстве районов США жизнь без автомобиля практически невозможна. Так профессия шофера прошла полный цикл от интеллектуальной и романтической до бытовой и повседневной за какие-то 60 лет.

Цикл профессии авиапилота тоже близится к окончанию и займет те же 60 лет.

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

Так получилось, что время моей жизни практически совпало с жизненным циклом моей профессии. Я – программист. Сами компьютеры появились в 40-х годах (и не надо здесь вспоминать ерунду про дочку Байрона), то есть в то же десятилетие, когда я родился.

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

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

В группе программистов Института Теоретической и Экспериментальной Физики, где для вычислительных работ ядерной физики стояла эта самая М-20, придумали массивы, списки, необходимость использования подпрограмм и многое другое. Один из моих учителей, Г.М. Адельсон-Вельский придумал хэш память. Подробности можно найти в книге другого моего учителя – А.С. Кронрода «Беседы о программировании». Еще до Дийкстры основные принципы структурного программирования были изложены А.Л. Брудно в книге «Программирование в содержательных обозначениях». Там же была создана первая шахматная программа.

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

В итоге тогда шахматная программа ИТЭФ, предшественница «Каиссы», умещалась в памяти М-20, а именно в 4096 ячейках, каждая из которых имела 48 разрядов (теперь это называют битами). Где-то рядом уже существовал Алгол-60, но им «настоящие» программисты не пользовались, поскольку техники отладки практически не было. Чуть позже большую популярность получила статья «Почему настоящие программисты не пишут на Фортране».

Мои студенческие годы пришлись на целый ряд советских машин – Раздан-3, Минск 1, 2, 22, 32, Урал-14, все из которых имели пульт, за которым сидели программисты, а программы и данные вводились с перфокарт или с перфолент. АЦПУ — устройство «широкой» печати — появилось только в конце 1960-х.

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

Рассказывают, что в операционной системе «Пульт», написанной в Вычислительном Центре АН СССР для БЭСМ-6, был счетчик ошибок оператора, и при достижении некоторого порога система выдавал «вежливое» сообщение «А если ты – дурак, то не садись за „Пульт“». Когда директор ВЦ академик А. Дородницын инспектировал систему, он понажимал несколько раз случайные кнопки и был крайне огорчен полученным результатом.

О серьезности задач, которые тогда приходилось решать на тогдашних компьютерах, говорит то, что одним из моих проектов в студенческое время была система инверсного поиска патентов для экспертов. Кстати, ВМК еще не было, было отделение вычислительной математики на мех-мате, но я учился на отделении математики. Сдавая зачет по программированию, я должен был аппелировать к своему профессору М.Р. Шуре-Буре, поскольку его аспиранты, принимавшие зачет, программировать почему-то не умели. И вообще на мех-мате программирование считалось чем-то вроде предательства чистой математики, и всерьез на моем курсе им занималось не больше десятка человек. Была даже частушка: «Меня милый не целует, не садится близко, говорит „я – математик, а ты – программистка“». А потом 90 процентов выпускников с моего курса пошло-таки работать программистами.

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

Конец моих студенческих времен совпал с революцией в компьютерах. Появились компьютеры «общего пользования с системами разделения времени. Это IBM 360, ICL 4-70, ЕС ЭВМ. Писать в кодах для таких машин стало принципиально невозможно, и на передний план вышел (как наименьшее зло) язык ассемблера. Были и другие языки программирования (Фортран, Кобол, Алгол, PL-1), но они не позволяли эффективно контролировать оттранслированный код. Мой сосед по кабинету в ИПУ М. Фурман, на мой изумленный вопрос, как ему удается программировать на PL-1, просто заметил, что он в уме транслирует все операторы, прежде чем написать их.

За 15 лет работы с ассемблером мы общими усилиями овладели этим языком так, что он стал языком более высокого уровня, чем все выше перечисленные. Под термином „овладеть языком“ я имею в виду не то, что мы досконально знали его синтаксис и семантику, а то, что были наработаны библиотеки подпрограмм, приемы программирования, идиомы и многие специфические приемы, так что программы писались легко и свободно. И, главное, еще легче отлаживались и адаптировались. Те, кто писал на Фортране, оценят последние свойства.

Именно за эти годы мною и моими товарищами по работе под руководством В. Арлазарова были написаны „Каисса“, „ИНЕС“, АСУ МНТС (Международного научно-технического сотрудничества для ГКНТ СССР) и много конкретных прикладных систем. Где-то в это время нам пришлось расстаться с привычными перфокартами и пересесть за дисплеи, между прочим, – алфавитно-цифровые.

Сделанная в ИПУ „Каисса“ стала первым чемпионом мира среди шахматных программ. Кроме удовлетворения амбиций, она принесла мне еще много друзей по всему миру, поскольку в те времена создание хорошей шахматной программы было делом сложным, и сформировался своего рода теневой клуб авторов и знатоков шахматных программ.

Среди них были знаменитые в мире информационных технологий люди – К. Шеннон (автор теории информации), К. Томпсон (автор операционной системы Юникс), Д.Леви, М. Ньюборн, А. Марсланд, Б. Миттман, Ф. Фридель (автор ChessBase) и многие другие.

СУБД „ИНЕС“, в которой я занимался системными вопросами – генерацией и дистрибуцией системы, системой поддержки версий, для чего была написана Архивная Система — и АСУ МНТС, устанавливать которую мне пришлось по всем министерствам и республикам СССР, принесли мне много хороших знакомых по всей стране. В любой город СССР можно было поехать, и везде встречали очень тепло, даже когда устанавливаемые мною системы были принимающим, мягко говоря, не слишком нужны (как сейчас сказали бы, АСУ МНТС снижало коррупционную емкость планирования научных командировок за границу).

И мое тогдашнее хобби – спортивный бридж – тоже было источником многих дружб и знакомств. Не случайно, когда мои американские друзья приезжали в СССР, они, после очередной случайной встречи с кем-нибудь на улице, спрашивали меня „Тебя все здесь знают?“.

С К. Шенноном связана одна из самых удивительных историй в моей жизни. Меня с ним познакомили в 1980 году на чемпионате мира среди шахматных программ в Линце. Каждый чемпионат имеет своего почетного гостя, и в том году им был Клод. Услышав его имя, я подумал „Как! Он еще жив?“. Ведь работы Шеннона по шахматному программированию относились к году моего рождения, то есть для меня он существовал в очень давней перспективе. Оказалось, что ему в год моего рождения было меньше тридцати, и в 1980м он был еще очень не старым человеком. Когда же пришла моя очередь быть почетным гостем чемпионата мира 1999 года в Падерборне, я прочел в глазах молодых шахматных программистов все тот же немой вопрос „Как! Он еще жив?“. И, поняв, что с момента моих публикаций уже прошло больше двадцати лет, я вспомнил Шеннона и успокоился.

В начале 1970-х появились машины серии „Ряд“. Так получилось, что во время моего распределения после МГУ мне пришлось быть свидетелем, как А.С. Кронрод боролся за продолжение проектирования и производства оригинальных советских машин (он даже предлагал назвать серию „АС“ — автоматическая советская — по своим инициалам) против В.М. Глушкова и Л.Т. Кузина, которые ратовали за копирование IBM. Одним из аргументов у последних было то, что можно будет воспользоваться всем математическим обеспечением, созданным для IBM и ликвидировать то небольшое отставание в вычислительной технике, которое имелось в конце 1960-х.

Глушков и Кузин победили (а судьей был председатель ГКНТ Кириллин), но все оказалось не так-то просто. Первый компьютер серии с трудом (титаническим трудом инженеров-электронщиков, запустивших его в жаркое лето 1972 года на ВДНХ, после чего они искупались в фонтане Дружбы Народов) был запущен в 1972 году, а массовая работа на нем – только в 1979 году. Все это время я неплохо зарабатывал лекциями по ОС ЕС ЭВМ. Документация по системе переводилась моими однокурсницами и другими людьми, не представлявшими себе, что такое компьютер вообще и операционная система в частности, и разобраться по такой документации было невозможно.

Таким образом, Глушков и Кузин просчитались именно в этой компоненте – культуре пользования. Теперь я понимаю, что неправ был и Кронрод, за которого я „болел“, потому что надо было и копировать IBM и делать свои машины именно для сохранения культуры. А в итоге к 80-м мы потеряли культуру проектирования элементов, потом и культуру проектирования устройств, а сейчас от нас уходит (вместе с носителями – людьми, которые умеют это делать) культура создания операционных систем.

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

Продолжение:
Жизненный цикл программиста Часть 2
Жизненный цикл программиста Часть 3
0
←  сюда    туда  →
1 2