Диалог программиста и программистки )


Содержание

Анекдот

Похожие:

— Так, здесь уберем, а здесь, пожалуй, немного оставим. Головушка будет просто загляденье! Можно хоть на переговоры, хоть на тусовку, хоть на свидание — везде не стыдно будет показаться.

— Рэбе, а можно сделать обрезание без лишнего пафоса?

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

— Слабаки! У нас еще стоит!
Не долго думая отвечаю:
— Так третий год пошёл, надоела она нам!
В ответ тишина, а после чей-то удрученный женский голос свыше:
— Нет, Лёша! Эта палка не будет стоять у нас три года!

Как общаться с программистом?

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

Cosmo рекомендует

Где купить модную куртку с поясом на зиму: лучшие модели сезона по версии Cosmo

Распродажа AliExpress: топ лучших товаров для волос, которые ты захочешь купить

Компьютерщики — народ загадочный. Целыми днями смотрят в монитор , шуршат клавиатурой , ковыряются в «железе». Но сами они не железные! Ты легко в этом убедишься. Главное , найти правильный подход!

ПЕРВЫЙ ТИП

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

+ Основную работу сисадмин делает в офисе , в свободное время рабочие проблемы его почти не трогают. Значит , иногда ты можешь рассчитывать на его общество и внимание.

Возможно , одну из комнат в вашем доме все же придется отдать под серверную.

КАК К НЕМУ ПОДОЙТИ: Сисадмины питаются печеньками. Подкармливай его иногда — и тебе зачтется!

ВТОРОЙ ТИП

ПРОГРАММИСТ
Его основное профессиональное и личное качество — терпение , поскольку отладка программного кода дело небыстрое. На секс его развести можно , а вот на разговоры — вряд ли. Если тебе удалось с ним поговорить , можешь считать себя избранной. Со стороны программист часто выглядит полным… хм… интравертом , поскольку умственным трудом может заниматься где угодно и когда угодно.

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

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

КАК К НЕМУ ПОДОЙТИ: Подходи к нему осторожно , иначе спугнешь! Кстати , 13 сентября — День программиста , хороший повод для неформального общения!

ТРЕТИЙ ТИП

ГЕЙМЕР
У сисадмина и программиста есть веская причина сидеть за компьютером день и ночь — они все-таки деньги на жизнь зарабатывают. А вот с геймером все сложнее — если его захватят компьютерные монстры , кормить вас обоих придется тебе. Впрочем , если ты ответишь на вопрос , чего ему недостает в реале , ты сможешь грамотно и аккуратно предложить ему альтернативу. И тогда — добро пожаловать в реальный мир!

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

Игрушки — это заразно! Ты сама можешь не на шутку втянуться , бывали прецеденты!

КАК К НЕМУ ПОДОЙТИ: Предложи ему новую игру. Необязательно компьютерную. Шахматы на раздевание — это тоже интересно.

ЧЕТВЕРТЫЙ ТИП

ОНЛАЙН-ТУСОВЩИК
Даже в рабочее время он умудряется отвечать на сообщения в форумах , просматривать анкеты на сайтах знакомств , болтать если не по скайпу , то по аське , изучать фотоотчеты друзей и оставлять свои комментарии , читать онлайн-издания и слушать радио онлайн… да мало ли что еще! Он зарегистрирован во всех социальных сетях и , в отличие от обычных пользователей , успевает поддерживать свое присутствие в каждой из них. Он свято верит , что будущее — за интернет-технологиями. Кто же спорит? Но если ты хочешь , чтобы в этом прекрасном будущем нашлось место для тебя , придется постараться , потому что на реальных женщин у онлайн-тусовщика не всегда остается время.

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

Даже если ты оторвешь его от компьютера , у него в кармане всегда найдется сотовый телефон. А значит , он повсюду будет искать Wi-Fi , пытаясь « зачекиниться» в каждой кофейне , куда вы заглянете на чашку капучино.

КАК К НЕМУ ПОДОЙТИ: Конечно , через Интернет. Поймать его в Сети несложно: отправь ему пару любопытных ссылок или комментариев , и посещаемость твоей странички повысится.

ПЯТЫЙ ТИП

WEB-ДИЗАЙНЕР
Этот парень , с одной стороны , технарь , а с другой — эстет , даже если он в этом не признается. Скорее всего , именно этим он тебе и нравится. Ему , в свою очередь , нравятся дружелюбные интерфейсы , он неравнодушен к пиктограммам и много времени проводит в Интернете , потому что изучение аналогов — важная часть его работы. Он трудится на благо всех пользователей Сети. Его задача сделать так , чтобы тебе и всем-всем-всем было удобно и приятно посещать сайт заказчика , который ему платит. Как правило , немало.

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

Он работает на стыке творчества и математики в широком смысле , поэтому его перекашивает то в одну , то в другую сторону. Сегодня побеждают эмоции , завтра — четкая логика.

КАК К НЕМУ ПОДОЙТИ: Он любит все красивое и креативное , так что привлечь его внимание нетрудно. Ему понравится , если ты будешь выглядеть графично , фотогенично и необычно.

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

Марина ,
жена программиста:
«Отправила мужа , загруженного рабочей проблемой , в магазин за детскими консервами. Он купил шпроты и кильки в томате. На вопрос , как этим кормить годовалого сына , был получен логичный ответ: «Ну , я посмотрел , тут рыбки вроде маленькие…»

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

Лена ,
девушка геймера:
«Решила купить в подарок молодому человеку Sony Playstation. Подруга отговаривала: «Тебе нравится секс? Тогда не покупай!» И ведь она оказалась права…»

СМОТРИ И ЧИТАЙ

«ЧИП И ДЕЙЛ СПЕШАТ НА ПОМОЩЬ» — этот мульт-сериал стоит пересмотреть ради трогательного образа Гаечки , обожаемого многими мужчинами , которые работают с техникой вообще и с компьютерами в частности. Она разбирается в технике , не болтает по пустякам и носит сексуальные комбинезоны.

«ХАКЕРЫ» — культовый фильм в компьютерной среде. Главная героиня Кейт Либби — девушка-хакер и настоящий IT-секс-символ. Что неудивительно , ведь ее играет Анджелина Джоли!

«КОМПЬЮТЕРЩИКИ» — британский телесериал о специалистах техподдержки и их начальнице , которая ничего не смыслит в IT.

«ПОЛНЫЙ ROOT» — роман Александра Чубарьяна , в котором описывается не такое уж отдаленное будущее: виртуальная реальность стала частью повседневного мира — страшный сон и одновременно мечта всех пользователей Сети.

«ГИЛЬДИЯ» — интернет-сериал , смешная история о людях , увлеченных онлайн-игрой.

«ЗАПИСКИ ЖЕНЫ ПРОГРАММИСТА» — юмористическая проза Алекса Экслера. Образы персонажей утрированы , но кто встречался с программистами , тот поймет.

«ТРОЕ В СЕРВЕРНОЙ , НЕ СЧИТАЯ АДМИНА» — повесть Алексея Ковязина , опубликованная в Сети. Можешь читать ее на ночь своему любимому — пусть тебе не все будет понятно , зато он посмеется от души.

Неправильный, но быстрый способ стать программистом

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

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

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

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

Как я стал программистом

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


Первый шаг — резюме

Первая и основная проблема, с которой сталкиваются новички, — резюме. Без адекватного, цепляющего резюме вас не будут приглашать на собеседования. Но как быть тем, у кого совсем нет опыта работы? Для того чтобы «не с пустыми руками» идти к HR, мы с моим другом вписали мне в резюме целый год опыта работы над его проектом, над которым мы якобы вместе трудились.

Зарплатная политика

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

Позор и стыд

Первые собеседования были провальными. Надо мной буквально смеялись. На первом же техническом собеседовании, где мне дали пару задачек на бумаге, меня раскусили в два счёта. Кто-то даже по-отечески посоветовал книгу Thinking in Java.

Первая работа

В конце концов меня пригласили на собеседование в филиал одной датской компании, где я ответил на фундаментальные вопросы и приятно удивил всех своим английским. Меня взяли на должность Junior Java developer с одним условием — первые три месяца я буду проходить курс SCJP (Sun Certified Java Programmer), который восполнил бы мои пробелы и выковал бы из меня более подготовленного специалиста. Что может быть лучше, чем оплачиваемая стажировка без нужды работать (выдавать свою некомпетентность)? В этой компании я проработал полгода, чтобы через несколько месяцев пойти на повышение в компанию покрупнее.

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

Рекомендации для начинающих программистов

  1. Резюме. Оно должно быть правильно отформатированным и написанным исключительно на английском. Если не хватает опыта, то его можно (и нужно) придумать, но следует подготовиться отвечать за каждое написанное в резюме слово. Например, если у вас там написано JMS (Java Message Service), то вам как минимум следует пройти хоть одну обучалку и поиграться с JMS, поделать какие-нибудь примеры, пускай это и будет банальное «Hello, world!». Теперь вам будет удобнее пускать пыль в глаза, вы ведь и правда «работали с JMS».
  2. Выучите азбуку программирования. Если вы ещё можете позволить себе «плавать» на глубоких уровнях каких-нибудь комплексных технологий вроде Struts и Spring, то неправильные ответы на элементарные вопросы вам никогда не простят. Если вас ночью разбудить, то вы должны уметь рассказать про ООП, наследование, инкапсуляцию, полиморфизм и другие базовые концепции, а также суметь объяснить это всё на примерах.
  3. Практика. Научиться программировать можно, только лишь программируя. Это больно и неприятно (если вы не программист), но другого пути нет. Единственный способ перестать бояться задачек на собеседованиях — порешать их дома самостоятельно.
  4. Читайте книги и проходите туториалы по Java только на английском. Абсолютно все термины программирования проще понимать на языке оригинала, то есть на английском. Читать техническую литературу по Java на русском — себя не уважать. Почему? Потому что, чтобы понимать что-нибудь в духе «…модуль таблицы во многих смыслах представляет собой промежуточный вариант, компромиссный по отношению к сценарию транзакции и модели предметной области», нужно быть поистине гением, которым вы вряд ли являетесь.
  5. Выучите, наконец, английский! В первую очередь это касается разговорного английского. Сложно сосчитать то огромное количество толковых программистов, которых на моей памяти забраковали по одной единственной причине — неудовлетворительный уровень разговорного английского. Нет, если вы, конечно, собираетесь работать программистом где-нибудь в «Киевстаре» или в другой отечественной компании, то ваш уровень языка не будет играть важной роли. Но если вы хотите попасть на работу в международную компанию, то сам бог велел выучить язык. Уровень вашего английского будет конвертироваться в дополнительные сотни долларов прибавки к вашей зарплате.
  6. Знайте рынок. Походите по вакансиям, почитайте требования, поспрашивайте друзей-программистов, сколько они получают. Используйте сервисы, которые позволят составить вам более полную картину о рынке IT. Вы были бы удивлены, узнав о том, насколько велико количество талантливых программистов, которые получают в два раза меньше, чем могли бы, только лишь по причине своей лени и нежелания держать нос по ветру.
  7. Торгуйтесь. Нет ничего предосудительного в том, чтобы торговаться за зарплату. Вашим аргументом в споре может быть как хороший английский, так и предложение о работе в другой компании. Последний аргумент особенно хорошо работает: «Да, но мне в Luxoft предлагают на 300 долларов больше, почему я должен соглашаться на ваши условия? Может, мы могли бы найти компромиссный вариант?». В своё время мне пару раз удалось выторговать дополнительную сотню долларов к своей зарплате, и через год эта сотня долларов дала мне дополнительные 1 800 долларов дохода на ровном месте. Вы должны понимать, что даже для небольших зарубежных IT-компаний лишняя сотня баксов как капля в море.
  8. Найдите себе ментора. Хорошо, если у вас будет более опытный товарищ, который сможет помочь советом и ответить даже на самые глупые вопросы. Благодаря его опыту и моральной поддержке вы будете продвигаться в программировании быстрее, чем в одиночку. Если нет ментора, то неплохо бы сходить на какие-нибудь курсы по программированию, которые не только дадут вам более полную картинку того, чем занимается программист, но и позволят познакомиться с более опытными людьми. Кто знает, может быть, кто-нибудь из них захочет стать вашим ментором.
  9. Начните свой проект. Даже если он будет образцом самых худших практик кодинга и вы его никогда не закончите, по крайней мере у вас будет то дело, ради которого вам захочется разбираться в программировании и изучать новые технологии. Кроме того, у вас появится дополнительная тема для задушевных бесед на собеседованиях.
  10. Ищите работу летом. Во-первых, когда все в отпусках, в компаниях более остро ощущается нехватка кадров и повышается вероятность того, что вас позовут на собеседование. Во-вторых, поскольку ваши конкуренты-соискатели тоже на отдыхе, у вас опять-таки повышаются шансы быть замеченным HR.
  11. Никогда не сдавайтесь. Даже если вам кажется, что вы заваливаете собеседование, важно проявить стойкость и продолжить попытки решить задачу, какой бы сложной она ни казалась. Кто знает, может быть так, что вас именно в этот момент проверяют на усердие в работе!
  12. Избегайте заданий на компьютере. Нет способа быстрее раскусить непрофессионала, чем сразу же бросить его в пекло программирования. Ваша задача — постараться перевести все беседы на высокий уровень, где обсуждаются общие подходы и концепции, но никак не конкретная реализация в решении той или иной задачи. Если вам дали бумагу и ручку и попросили записать решение, то попросите возможность нарисовать его схематически. Таким образом, удалившись от синтаксиса конкретного языка, вы не только убережёте себя от каких-нибудь режущих глаз ошибок, но и покажете, что способны мыслить абстрактно, не вдаваясь так уж сильно в детали.
  13. Начинайте говорить первым. Избегайте ситуаций, когда в воздухе виснет пауза, во время которой в мозгу у интервьюера может созреть очередной коварный вопрос. Как только происходит какая-либо заминка, следует начать рассказывать что-нибудь из того, что вы хорошо знаете. Постарайтесь навязать интервьюеру свою игру.
  14. Старайтесь говорить правду. Если вы никогда не писали PL/SQL процедуры, то лучше об этом сказать прямо. Возможно, в этом для вас будет минус, однако вы убережёте себя от нужды выкручиваться, отвечая на вопрос, в котором ничего не смыслите. Опытный интервьюер за версту почувствует ваши пробелы в знаниях.
  15. Бойтесь маленьких компаний. В небольших компаниях, как правило, небольшие команды. Чем меньше в команде людей, тем быстрее вас раскусят. Ваша цель — большая и неповоротливая корпорация, где вы сможете выиграть для себя немного времени.
  16. Соблюдайте дресс-код. Если вы придёте на собеседование на должность программиста в шикарном костюме, то это вызовет больше подозрения, чем если вы явитесь в шортах или потёртом свитере. Не лишним будет также нацепить очки, мол, «эдакий я книжный червь».

Конечно, кто-то знающий может отметить, что приведённый выше рецепт — это скорее способ стать кодером, чем программистом, и он где-то будет прав. Однако дело всё в том, что вы никогда не найдёте вакансию с заголовком «Требуется плохой кодер». Всем нужны программисты. Желательно senior. У которых более пяти лет опыта работы на корпоративных проектах и которые одинаково хорошо владеют сразу несколькими языками программирования, при этом досконально разбираются в СУБД, умеют писать bash-скрипты, хранимые процедуры, знают в совершенстве Linux, TCP/IP, обладают лидерскими качествами, стрессоустойчивостью, коммуникабельностью и ещё массой навыков, «без которых никак».

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

Письмо слепого программиста

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

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

О себе

Меня зовут Михаил Духонин. 37 лет. Живу в Саратове. Холост. Получил высшее образование по специальности «Социальная философия», закончил аспирантуру, защитил диссертацию. В общем, незамутненной чистоты гуманитарий.

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

Предваряя стандартный вопрос о том, как же я, слепой, работаю на компьютере (хотя, как специалист в ИТ-сфере, возможно, вы и в курсе…), замечу, что существуют так называемые программы экранного доступа (скринридеры, screen reader), которые озвучивают интерфейс ОС и программ. Они позволяют ориентироваться на компьютере на слух.

Компьютер у меня появился достаточно поздно — в 2002 г. До этого несистематически учился на нем работать в школе и спец-библиотеке. Даже DOS слегка зацепил… Но вообще, обучать меня работе на компьютере особо было некому. Поэтому я с самого начала привык действовать методом научного тыка, логикой и читать разного рода хелпы, руководства и прочую тому подобную литературу. Так что на сегодняшний момент без ложной скромности могу назвать себя очень продвинутым пользователем. Работаю на Win7. Эту ОС, правда, не изучал столь же глубоко, как Win98 и WinXP.

Где-то в году 2005-м попал мне в руки диск с актуальными на тот момент средами программирования. Именно с этого момента начинается мой путь в программирование.

Цели и задачи

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

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

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

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

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

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

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

Выбор инструмента и общий план пути

На вышеупомянутом диске помимо всяких ассемблеров были Borland Visual C++, Borland Delphi 6 и Visual Basic 6. Само собой первой проблемой, которая встала передо мной, был вопрос выбора. Выбор я вполне сознательно сделал в пользу Delphi. И вот почему. Становиться профессиональным программистом я не собирался. Программирование было для меня исключительно средством решения тех или иных проблем, для которых не удалось найти готовых решений Ну или чего-то совсем специфичного. В то время я располагал следующей информацией. VB — интерпретируемый язык, где код выполняется интерпретатором. Это мне не нравилось (потенциальные тормоза и т.п.). Ну и репутация у Бэйcика была как у чего-то совсем детсадовского.

В то же время C и C++ позиционировался как сложный в освоении язык, ориентированный на профессиональных программистов. Это мне также не подходило. Хотелось чего-то среднего по сложности и в то же время универсального. Всем этим требованиям отлично соответствовала Delphi. С одной стороны Pascal позиционировался как достаточно простой в освоении язык, с другой — Delphi была вполне современной и профессиональной средой разработки. Ну и то, что разработанные с ее помощью программы исполнялись без дополнительных посредников вроде интерпретаторов, тоже было плюсиком. Забегая вперед скажу, что относительно недавно я пытался освоить плюсы в варианте Visual Studio, но для меня это оказалось действительно очень сложной задачей. В общем, пока остановился на Python.

Честно говоря, для меня так и осталось загадкой, почему Borland перестала поддерживать Delphi. ИНХО именно это стало причиной упадка данной среды разработки. Монструозность… Хм… Ну Visual Studio от Microsoft тоже не сказать, чтобы такая уж компактная… Кстати, насколько мне известно, потомок Delphi до сих впор вполне себе существует под другим брендом, а к Visual Studio есть расширение для разработки на Pascal от той же компании. Тем не менее, не знаю, как за бугром, но в России эта среда считай, что не существует. Ничего на русском я о ней не видел.

В заключение этого раздела немного о периодизации. Первым моим крупным этапом в освоении программирования стала, как уже понятно, Delphi. Года два — три я интенсивно ее осваивал, даже CGI-приложение на ней написал, вполне себе рабочее. Жаль только, пропало все практически с убитым диском. Затем у меня был достаточно длительный перерыв. К тому времени я устроился на работу, где сильно увлекся MS-Excel. Первоначально глубоко изучил штатные возможности программы. Но их мне оказалось недостаточно. В конце-концов возникла потребность в изучении VBA, что я с успехом и сделал. Показателем успеха стало то, что сейчас я пишу макросы не только для себя, но и по рабочим задачам, т.е. стал профессиональным программистом в вашем понимании этого понятия. Правда, больших денег за это я не имею… Но это тонкости. По VBA я даже прошел один из курсов на Интуит и обладаю соответствующим сертификатом. Правда, не могу сказать, что этот курс сам по себе сделал меня программистом…

Между делом я попытался освоить Visual C++, причем чистый, не под NET. Все таки хотелось чего-то такого, на чем можно писать программы любого типа. Но увы. Язык этот оказался на данном этапе мне не по зубам. И литературы для начинающих, кстати, для него на удивление очень мало. Не идет ни в какое сравнение ни с Delphi времен ее расцвета, ни с тем же Python. Пытался также изучать PHP, но оно тоже не пошло. Видно не судьба мне писать на C-подобных языках…

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

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

Методика изучения


Изучал программирование я исключительно по книгам. Честно говоря, для меня является загадкой, как можно изучать его по видеокурсам. Хотя надо бы попробовать… Копипастить же код в любом разе удобнее из книги, чем переписывать из окна плейера. Да и печатный текст, по-моему, гораздо доступнее для освоения, нежели речь. Но тут готов допустить, что на вкус и цвет все фломастеры разные.

Здесь есть одна любопытная особенность, которая несмотря на свой привходящий характер имеет большое значение для освоения предмета. Дело в том, что литература по программированию в подавляющем большинстве случаев выложена в формате PDF. Сам по себе он является картинкой, для чтения скринридерами недоступной. Поэтому я обычно читал книги, распознанные с помощью FineReader в формате TXT. Файнридер же совершенно безобразно распознает листинги. Причем, это касается как OCR-слоя в PDF, так и книг в скринридеро-доступных форматах (вроде html, doc, chm и т.п.) В общем чистый копипаст в подавляющем большинстве случаев не катил никак. Прежде чем изучить работу тех или иных примеров из книг, эти примеры приходится дешифровывать. И этот этап для меня является вполне себе обычным. Именно поэтому, думаю, я совершенно не заметил того «большого барьера», о котором вы пишете в своей книге. Для меня вполне естественно, прежде чем что-то заработает, это нечто надо тщательно вылизать. Да и если сам набираешь код, тоже от опечаток никуда не деться. И вообще, уж не помню почему, но я изначально был ориентирован на то, что программирование это не совсем написание литературного произведения.

Поэтому, первым шагом в освоении любого языка или технологии программирования является поиск подходящей книги. В идеале не больше одной — двух. Delphi я начинал изучать по «Delphi 6» Фаронова и «Иллюстрированному самоучителю по Delphi 7 для начинающих». Огромное значение для меня в последствии сыграла «Библия Delphi» Фленова.

Excel и VBA я изучал по книгам Джона Уокенбаха. Кстати, 3 тома почти по 1000 стр. Целиком я их, конечно, не осилил, но тем не менее, программировать на VBA научился. Об интуитовском курсе уже упоминал, хотя нового там было только то, что касалось Word.

C++ пытался изучать по Хортону. Но, как уже писал, не пошло. Хотя несколько глав я таки прошёл. Были еще книги Прохорёнка, но этого автора я вообще почему-то воспринимаю очень плохо. С Python’ом мне вообще повезло — первой же мне под руку попалась книга Майкла Макграта «Программирование на Python для начинающих», где этот язык был описан с той детализацией, что доктор прописал.

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

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

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

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

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

Остановлюсь немного на том, какие книги стоит выбирать. Для освоение азов лучше всего подойдут книги типа «… шаг за шагом». Дело в том что мне не очень интересно читать сотню — другую страниц, прежде чем можно будет открыть IDE и написать первые строки кода. Процесс изучения должен быть исключительно активным: прочитал параграф, тут же набросал что-нибудь запускающееся, иллюстрирующее прочитанный материал. Примеры также можно самостоятельно переписывать, а в идеале, и как-нибудь модифицировать, и воочию смотреть, как всё это работает. Впрочем, кому-то, наверное, будет под силу прочитать учебник от корки до корки, да ещё и не один раз, прежде чем начать писать программы… Но это явно не я! Выбирать лучше всего книги, объёмом не более 200 — 300 страниц. Ну или талмуды с хорошо прописанной первой частью (где про основы). Большую роль играет и то, кто написал книгу. Выбирать надо такого автора, которого хорошо воспринимаешь и понимаешь.

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

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

  1. какого результата хочу добиться и
  2. какие исходные данные у меня есть.

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

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

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

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

Достижения

Прежде чем описать те проблемы, с которыми я столкнулся, хотелось бы систематизировать свои достижения. Когда я писал на Delphi, главным моим достижением стал иерархический блокнот. Он представлял собой дерево, каждый узел которого был ассоциирован с неким текстом. Данные хранились в базе Access (2003 тогда еще). Соответственно, там были и SQL-запросы, и активное использование событий (не только OnClick) и куча всего другого. Даже класс простенький написал. К сожалению, исходный код был утрачен, хотя экзешник где-то валяется. Я успел сделать много вкусных для себя плюшек, вроде манипулирования расположением узлов с клавиатуры, создания нескольких блокнотов, причем, кроме универсального блокнота можно было создать специальный, где с каждым узлом можно было связать ссылку, которая по желанию открывалась в браузере прямо из программы. К сожалению, не успел прописать импорт/экспорт данных, без чего на постоянной основе программой не пользовался, хотя несколько блокнотов и создал. Сейчас пользуюсь близким по функционалу Flash Note. Но многого из того, чего хотелось бы, там нет.

Илон Маск рекомендует:  Visual basic для начинающих

На VBA у меня также есть макросы, причем некоторыми из них пользуюсь по работе буквально каждый день. Основные успехи связаны с конвертацией данных из определенным образом оформленных файлов Word или XML в таблицу Excel. Есть одна смешная вещь — я могу на VBA легко написать формулу массива (Ну она возвращает variant, который является массивом), а вот с готовыми функциями массива у меня жесткие сложности. Для меня до сих пор осталось загадкой, почему СУММ не захотела суммировать массив, возвращаемый ВПР (массив точно возвращался). Пришлось идти другим путем, и получать нужный массив комбинацией ИНДЕКС и ПОИСКПОЗ. Он прекрасно просуммировался. Есть в моей коллекции и пользовательские функции массива.

Также написал функции, конвертирующие десятичное число в 62-ричное и обратно (захотелось получить числа, где малым числом символов можно было записать возможно большее количество чисел. Числа записывались символами 0..9, a..z, A..Z — ну вот и 62…)

Причем меня не особо смущает, если приходится писать кучу вложенных друг в друга условий и циклов. Эх, есть у меня один макрос… Даже самому страшно, чего я там наворочал, но же работает.

На Python’е, так уж повелось, я сосредоточился на работе с архивами, парсинге HTML/XML. Экспорт в CSV… В общем, библиотеки/классы ElementTree, BeautifulSoup, zipfile, csv, os и т.п. — наше все…И также есть скрипты, которые используются как мной любимым, так и другими. Недавно вот jSon разбирал. Главным достижением стала библиотечка по извлечению метаданных из FB2-книг. Потом они складировались в CSV, который можно скопировать в таблицу Excel. Правда, тут столкнулся с некоторыми проблемами, решить которые пока не удалось.

Проблемы

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

В ваших маркетинговых материалах вы высказываете мысль, что для того, чтобы стать программистом, совсем необязательно профильное образование. Более того, некоторые ваши высказывания можно трактовать в том смысле, что таковое образование вообще не делает человека программистом, нагружая его массой совершенно лишней информации с одной стороны, и не давая знаний собственно по программированию с другой. Чем-то мне это напомнило ворчание школьника — типа «нафига мне учить математику, если я хочу стать юристом. » Нет, ну понятно, что у 40-летнего дядечки это снимет одно из типичных возражений: «Как я могу стать программистом, если у меня нет профильного образования, и вообще я гуманитарий…» Но вы позиционируете ваш курс и для 14-летних подростков. Мне даже страшно подумать, что будет, если кто-нибудь из них воспримет ваши слова всерьез. И те кумиры, которых вы упоминаете (ну которые не закончили образования) станут примером для подражания для этих детей…

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

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

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

Но даже в повседневной практике, где я не зарываюсь в вышеописанные дебри, я постоянно натыкаюсь на разного рода засады. Приведу пример. Я уже говорил, что написал библиотеку по извлечению метаданных из FB2-книг. Но полноценно пользоваться я ей пока не могу. В ТЗ, которое я для себя сформулировал, были следующие требования. Книги запакованы в ZIP-архивы. необъходимо извлекать из них данные, причем без распаковки файлов на диск. Иными словами, надо распаковать файл в переменную. После этого переменная должна скармливаться парсеру XML. Казалось, бы чего проще…

В Python за работу с ZIP-архивами отвечает модуль zipfile, а парсер XML содержится в библиотеке xml.etree.ElementTree, где сам парсер содержится в классе ElementTree.

Первой засадой стало то, что напрямую распаковать файл в переменную не получается. В конце-концов, я это сделал, но в итоге получил строку байтов. А конструкторы ElementTree требуют именно файла. Пришлось использовать функции из этой библиотеки, которые предназначены для анализа XmL из строк. А они возвращают не целостный объект XML, а объекты узлов. Не смертельно, но неприятно. Поясню — у меня несколько сот тыс. fb2-книг. Мне до ужаса не охота при пакетной их обработке распаковывать каждый архив на диск, анализировать распакованный файл, а потом его стирать… Это, боюсь, и долго будет, да и винчестер жалко… То ли дело все проворачивать в оперативной памяти…

Но и это еще не все. Некоторые архивы обрабатываются некорректно. Возникают ошибки двух типов. Во-первых, парсер не захотел обрабатывать некоторые fb2-файлы в кодировке ANSI (CP-1251). Он падал на некоторых символах, например &, или с кодом 7. В то же время, все файлы в кодировке UTF-8 в этом смысле обрабатывались корректно. Во-вторых, метод FromString класса ElementTree почемуто некорректно извлекал данные из некоторых строк, считанных из архивов. Причем, будучи распакованными, эти файлы парсились корректно. В чем разница между архивами, которые читались неправильно, и всеми остальными — понять мне так и не удалось.

Еще одной проблемой, с которой я столкнулся, стало создание графического интерфейса. Собственно, для зрячих тут никакой проблемы нет. Практически каждая IDE в своем составе имеет простые инструменты для построения GUI. Когда я работал с Delphi, тоже без особых напрягов создавал графические приложения на основе библиотеки VCL. Пользоваться палитрой и дизайнером, правда, я не мог, но IDE Delphi имела список всех компонентов, из которого эти компоненты можно было добавлять на форму. А затем ужевручную можно было настроить свойства TOP, Height, Left и Bottom каждого компонента. Моей способности к пространственному мышлению вполне хватало на то, чтобы представить, как компоненты должны были располагаться на форме и вычислить значения соответствующих свойств. А если пользоваться различными заданными значениями свойства Align, то и вычислять было не обязательно.

В общем, с Delphi было почти все отлично. «Почти» было связано с еще одной проблемой — сам по себе интерфейс, это хорошо, но он должен корректно озвучиваться скринридерами. VCL в этом плане была вполне достойной библиотекой. Судя по всему она представляла собой обёртку вокруг стандартных графических компонентов Windows. А эти компоненты, в свою очередь, более или менее нормально озвучиваются. Тем не менее, неприятные моменты и тут имелись. Например, там был компонент TCheckListView, — обычный ListView, но с каждым элементом списка в нём связан флажок. Так вот, как этот флажок, так и его состояние не озвучивались совсем…

Здесь имеется еще один путь — Скринридер, которым я пользуюсь, имеет инструменты, которые позволяют пользователю настраивать озвучивание новых приложений. В том числе, он содержит собственный скриптовый язык. Вообще говоря, в действительности первым языком программирования, который я изучал, был именно данный скриптовый язык. Основы языка я освоил без особых проблем. Но вот полноценно решать сколь-нибудь сложные проблемы озвучивания приложений я так и не научился. Суть проблемы в том, что озвучка основана на знаниях структуры окон Windows и свойств этих окон, умении работать с интерфейсами COM вообще и MSAA в частности, а также навыках обработки событий Windows. Ну там еще кое-какую информацию иногда можно получить, посылая сообщения функциями send-и postmessage. Чисто теоретически я все это понимаю, даже могу написать какой-нибудь перехватчик события или что-то извлечь из MSAA. Но всё равно — написание полноценного пакета скриптов для озвучки чего-нибудь у меня ниразу не получалось.

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

С Питоном тоже не все ладно. Во-первых, программное создание GUI в Python неразрывно связано с ООБ. Это само по себе для меня сложно, о чём уже писал. Во-вторых, встаёт вопрос о выборе библиотеки. Выбирать приходится между QT5 и Tkinter. Никаких других вариантов, которые можно было бы освоить самостоятельно, я не нашёл. Есть еще WX, которая, на самом деле, является наилучшим вариантом, но ее до сих пор не портировали на Python3. Неизвестно, когда это случится, случится ли вообще и напишут ли для нее русский мануал…

GUI, написанные на ранних версиях QT не озвучиваются скринридерами в принципе. Спецсофт просто ничего не видит в соответствующих окнах. Кстати, именно поэтому слепым абсолютно недоступна десктопная версия Telegram. В последних версиях библиотеки были добавлены инструменты Accessibility. Теперь кнопки и прочие контролы более или менее озвучиваются. Насколько я мог понять, информация берется из MSAA. Но люди, работавшие с библиотекой, пишут, что корректно озвучивается далеко не всё. Например, проблемы возникают с работой в многострочных полях редактирования. Ну и возникает вопрос — имеет ли смысл тратить кучу времени и сил на изучение сложного материала, чтобы в очередной раз понять, что всё бесполезно?

Библиотека Tkinter, также меня не вдохновила. Во-первых, судя по той информации, которая мне доступна, она достаточно бедна компонентами. Я не смог понять, как на ее основе писать оболочку вокруг БД. Ну и если дефолтная IDE Python действительно написана на Tkinter, озвучку придётся доводить напильником. И без гарантий, что я с этим напильником совладаю…

У меня даже была мысль изучить PHP или Django (под Python), чтобы уйти от проблемы GUI, ограничившись Web-интерфейсом. Но, как ни крути, а браузер достаточно ограничен в плане интерфейса. Нет, как раз оболочку к БД я сделаю. Может для этого даже не обязательно изучать язык, а можно ограничится PHPAdmin’ом. Но вот обеспечить тот функционал, который мне нужен, вряд ли получится. Например, как в браузере работать с архивами, в которых лежат далеко не всегда HTML-файлы? А ведь эти файлы нужно открывать либо в ассоциированных программах, либо во внутреннем просмотрщике, создать который в Web-интерфейсе та еще задача…

Собственно, всё… Что делать дальше, я пока не знаю. По-видимому, мне таки не хватает тех фоновых знаний, которые даются студентам в ВУЗах. Изучать новые инструменты? — Какие. Тоже и по литературе — не понятно что читать, за что браться…

Заключение

Итак, какие выводы можно сделать на основании моего опыта самообразования в области программирования?

1. Изучить основы языка и начать писать на нём типовые программы, используя современные IDE, — относительно просто.
2. Последовательность шагов при освоении программирования путём самообразования.

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

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

Диалоги — Программист и Заказчик, Юзер и Windows, Антивирус и Вирус, Покупатель и Продавец

Скачать книгу в формате:

Аннотация

Программист и Заказчик

Программист играет в тетрис. Входит Заказчик. Заказчик. Ваша программа не работает. Программист. А должна? Заказчик. А как же! Программист. Точно? Заказчик. Зуб даю! Программист. Откуда такая уверенность? Заказчик. В документации написано. Программист. Где? Заказчик показывает. Программист. Это на каком языке? Заказчик. Hа русском. Программист. Я, по-вашему, должен документацию на русском читать? Английский перевод есть? Заказчик. H-нет. Программист. (торжествующе) Hу вот видите! Заказчик. (смущенно) Извините. (достает из кармана зуб и отдает программисту)

Юзер. Поставь-ка новые драйвера видеокарточки. Windows. А диск есть? Юзер. Есть. Windows. А что сказать надо? Юзер. ОК. Windows. Фиг тебе, а не ОК. Hе могу найти необходимые файлы. Юзер. Так вот же они! Windows. Где? Юзер. Да на диске! Windows. Hа каком? Юзер. Hа B: Windows. Hет такого диска. Юзер. А почему под ДОСом есть? Windows. Hе .


Отзывы

Популярные книги

  • 42340
  • 1

Габриэль Гарсиа Маркес Сто лет одиночества ройдет много лет, и полковник Аурелиано Буэндиа, .

Сто лет одиночества

  • 141090
  • 7
  • 13

Сто тысяч лет назад Homo sapiens был одним из как минимум шести видов человека, живших на этой пла.

Sapiens. Краткая история человечества

  • 73697
  • 1
  • 5

В книге автор представляет независимый и разносторонний взгляд на жизнь и достижения самого ярког.

Илон Маск. Tesla, SpaceX и дорога в будущее

  • 47475
  • 14
  • 7

Зои Сагг Девушка Online Я посвящаю эту книгу всем, кто сделал ее появление реальностью. Всем, к.

Девушка Online

  • 44618
  • 9
  • 9

Думала ли Рая, затевая уборку дома, что ударится головой и очнётся в ином мире? А там она, свобо.

Как приручить кентавра, или Дневник моего сна

  • 42402
  • 11
  • 4

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

Лучшая академия магии 2, или Попала по собственному желанию

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

  • Понравилось: 0
  • В библиотеках: 0

Новинки

Фикрайтер-слешер, да к тому же законченная снейпоманка, попавшая во вселенную ГП — банально и изби.

«Диалоги — Программист и Заказчик, Юзер и Windows, Антивирус и Вирус, Покупатель и Продавец» (Нестеренко Ю.) — скачать книгу бесплатно без регистрации

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

Название:Автор:Жанр(ы):
Диалоги — Программист и Заказчик, Юзер и Windows, Антивирус и Вирус, Покупатель и Продавец
Нестеренко Юрий Леонидович
Компьютеры и Интернет, Околокомпьютерная литература, Юмор, Юмор

А пока Ваш файл готовится — ознакомьтесь с новинками!

Самый Свежачок! Книжные поступления за сегодня


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

Дилогия+бонус в одном файле

Аннотация к Том 1

Как думаешь, почему все легенды складываются о королях?

— Наверное, им чаще приходится быть героями…»

Шанакарт… Империя Сумрака, построенная демонами арши на прочной основе из магии и интриг. Их цепкие незримые сети паутиной оплетают Обсидиановый замок, а может, и весь мир. Роли бесконечно меняются, ставки растут! Это игры, достойные истинных демонов! Так как же в них попала маленькая человеческая графиня? Может… А впрочем, обо всём по порядку.

Аннотация к Том 2

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

И кем же станет в этой игре маленькая человеческая графиня? Жертвой, союзником или трофеем победителю? А может.

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

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

Иллюстрация на обложке и внутренние иллюстрации А. Мелик-Саркисяна.

Джеймс Фенимор Купер. Мерседес из Кастилии, или Путешествие в Катай (роман, перевод Ф. Мендельсона, иллюстрации А. Мелик-Саркисяна), стр. 3-464

Я. Свет. Послесловие, стр. 465-475

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

Эта книга для начинающих изучать теорию решения изобретательских задач (ТРИЗ).

Она описывает наиболее общие способы решения нестандартных (изобретательских) задач и получения новых идей.

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

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

Набор «Неделька» — топ новинок — лидеров за неделю!

Что общего между везением и проклятием? Ничего. Вот и Летта так считала. Пока однажды не получила чужое проклятие и не оживила его. А все дар, о котором она не подозревала. Сомнительный дар дарить везение и притягивать чужое невезение. И, похоже, не только его, но и приключения на свою… голову. Живое проклятие с принципами, охотник за темными магами, забывший, что такое чувства. И принц в нагрузку. А на хвосте тот, кого опасаются даже короли. Знай Летта, чем закончится ее встреча с подругой, сидела бы дома. А теперь остается только верить, что дружба и любовь куда сильнее древних чар, чужих обещаний и чудовищ.

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

Попасть можно всегда! На деньги, в неприятности, в историю…. Или в другой мир! У меня и так всё было нормально, да и возраст, ну да, за сорок уже, но ведь не старик ещё. А попал-то вот как раз в пацана, умирающего. А у людей планы, в том числе и на мою, теперь, смерть. И только случай и помог выжить. И ни родителей, ни друзей, ни каких ещё знакомых бывшего владельца тела. Из наследства, высокий социальный статус, как выяснилось, ни от чего не защищающий. Нет, если что, за тебя отомстят, посмертно. Мир-то вроде и русский, но столица не там и название не такое, и во главе Император и, вообще, всем заправляют Рода. Ах да, досталась ещё фамилия, от деда, которой не то чтобы детей по ночам запугивают…. Обычно это делают со взрослыми и при свете дня. Ещё и дар прорезался, эспера. Тут маги стены ломают кулаками, а мне эвона что досталось. Эх, печалька. Правда, такой дар у каждого уникальный…. Хоть что-то хорошее. Ну и девушки здесь….

Первое правило невесты дракона — никогда ему не перечить!

Да. Именно так. Вот только как сдержаться, если все идет не по намеченном плану?

Я ТийрРи Грин — потомственная черная ведьма. Поэтому все невзгоды и проблемы двух близлежащих королевств списывают на меня. И даже на костер отправили! Но мне повезло… Как сказать — повезло? Верховный дракон прислал приказ доставить ему очередную невесту. Да не кого-нибудь, а единственную дочь правителя соседнего государства. И меня отправили вместо неё. Теперь я буду играть роль благородной дамы в высшем свете драконов. Я могла бы справиться, но…Я совсем не собираюсь становиться новой лейдой империи.

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

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

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

Увы, награда победительнице – возможность выбрать себе пять молодых мужей…

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

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

Набор «Из отпуска» — топ лидеров месяца!

Что не так?! Именно этот вопрос задаст любой, кому мне вздумалось бы пожаловаться на свою жизнь. Ещё бы. Для счастья всё в наличии: королевская кровь, звание «Лучший зельевар Белого континента», внешностью Создатели не обидели. Ах, да, с этого года я ещё и занимаю пост ректора Академии стихий. Нравится? А мне не очень. Потому что я — маг-боевик, и ненавижу зельеваренье! А еще меня зовут Аленна.

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

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

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

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

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

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

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

И немного информации.

1. Данный роман в черновой версии будет выложен на ресурсе целиком, от начала до конца. Подписки на него нет. Но после завершения он будет урезан до ознакомительного фрагмента. Кто не успел — тот опоздал.

2. Немного уменьшен объем глав, теперь вместо 5100-5300 слов они составляют 4200-4500 слов. Просто мне так удобнее, я уже привык к данному стандарту на других проектах. Но это не значит, что текста станет меньше. Просто самих глав станет больше.

3. Нет, я не знаю последний это роман из данного цикла или нет. Хочется верить, что последний.

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

«Диалоги — Программист и Заказчик, Юзер и Windows, Антивирус и Вирус, Покупатель и Продавец» (Нестеренко Ю.) — скачать книгу бесплатно без регистрации

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

Название:Автор:Жанр(ы):
Диалоги — Программист и Заказчик, Юзер и Windows, Антивирус и Вирус, Покупатель и Продавец
Нестеренко Юрий Леонидович
Компьютеры и Интернет, Околокомпьютерная литература, Юмор, Юмор

А пока Ваш файл готовится — ознакомьтесь с новинками!

Самый Свежачок! Книжные поступления за сегодня

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

Дилогия+бонус в одном файле

Аннотация к Том 1

Как думаешь, почему все легенды складываются о королях?

— Наверное, им чаще приходится быть героями…»


Шанакарт… Империя Сумрака, построенная демонами арши на прочной основе из магии и интриг. Их цепкие незримые сети паутиной оплетают Обсидиановый замок, а может, и весь мир. Роли бесконечно меняются, ставки растут! Это игры, достойные истинных демонов! Так как же в них попала маленькая человеческая графиня? Может… А впрочем, обо всём по порядку.

Аннотация к Том 2

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

И кем же станет в этой игре маленькая человеческая графиня? Жертвой, союзником или трофеем победителю? А может.

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

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

Иллюстрация на обложке и внутренние иллюстрации А. Мелик-Саркисяна.

Джеймс Фенимор Купер. Мерседес из Кастилии, или Путешествие в Катай (роман, перевод Ф. Мендельсона, иллюстрации А. Мелик-Саркисяна), стр. 3-464

Я. Свет. Послесловие, стр. 465-475

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

Эта книга для начинающих изучать теорию решения изобретательских задач (ТРИЗ).

Она описывает наиболее общие способы решения нестандартных (изобретательских) задач и получения новых идей.

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

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

Набор «Неделька» — топ новинок — лидеров за неделю!

Что общего между везением и проклятием? Ничего. Вот и Летта так считала. Пока однажды не получила чужое проклятие и не оживила его. А все дар, о котором она не подозревала. Сомнительный дар дарить везение и притягивать чужое невезение. И, похоже, не только его, но и приключения на свою… голову. Живое проклятие с принципами, охотник за темными магами, забывший, что такое чувства. И принц в нагрузку. А на хвосте тот, кого опасаются даже короли. Знай Летта, чем закончится ее встреча с подругой, сидела бы дома. А теперь остается только верить, что дружба и любовь куда сильнее древних чар, чужих обещаний и чудовищ.

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

Попасть можно всегда! На деньги, в неприятности, в историю…. Или в другой мир! У меня и так всё было нормально, да и возраст, ну да, за сорок уже, но ведь не старик ещё. А попал-то вот как раз в пацана, умирающего. А у людей планы, в том числе и на мою, теперь, смерть. И только случай и помог выжить. И ни родителей, ни друзей, ни каких ещё знакомых бывшего владельца тела. Из наследства, высокий социальный статус, как выяснилось, ни от чего не защищающий. Нет, если что, за тебя отомстят, посмертно. Мир-то вроде и русский, но столица не там и название не такое, и во главе Император и, вообще, всем заправляют Рода. Ах да, досталась ещё фамилия, от деда, которой не то чтобы детей по ночам запугивают…. Обычно это делают со взрослыми и при свете дня. Ещё и дар прорезался, эспера. Тут маги стены ломают кулаками, а мне эвона что досталось. Эх, печалька. Правда, такой дар у каждого уникальный…. Хоть что-то хорошее. Ну и девушки здесь….

Первое правило невесты дракона — никогда ему не перечить!

Да. Именно так. Вот только как сдержаться, если все идет не по намеченном плану?

Я ТийрРи Грин — потомственная черная ведьма. Поэтому все невзгоды и проблемы двух близлежащих королевств списывают на меня. И даже на костер отправили! Но мне повезло… Как сказать — повезло? Верховный дракон прислал приказ доставить ему очередную невесту. Да не кого-нибудь, а единственную дочь правителя соседнего государства. И меня отправили вместо неё. Теперь я буду играть роль благородной дамы в высшем свете драконов. Я могла бы справиться, но…Я совсем не собираюсь становиться новой лейдой империи.

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

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

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

Увы, награда победительнице – возможность выбрать себе пять молодых мужей…

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

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

Набор «Из отпуска» — топ лидеров месяца!

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

Таким он предстал передо мной.

Таким оказался и его правитель…

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

Машина времени, которую изобрел ученый-энтузиаст из Санкт-Петербурга XXI века, открыла нашим современникам дорогу в XIX век, когда во главе Российской империи стоял император Николай I. Но секрет машины времени вскоре стал известен правительству Российской Федерации. И уже не кучка энтузиастов, а вполне серьезные конторы вместе с жандармами стали бороться с вражеской агентурой, а глава III отделения граф Бенкендорф применяет в своей повседневной работе все возможности специальных служб России XXI века.

Сотрудники ФСБ и III отделения совершили рискованную командировку в Лондон, где отловили Дэвида Уркварта – злейшего врага России и куратора британской агентуры на Северном Кавказе, где уже много лет немирные горцы ведут войну против России.

Но с поимкой Уркварта тайная война против Российской империи не закончилась. Довольно сложная обстановка сложилась и в Русской Америке, на Аляске и в Калифорнии. Работы у людей из прошлого и будущего впереди непочатый край!

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

Илон Маск рекомендует:  Загружаем задачу

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

Луна Хэера давно потеряла свою семью, и теперь она путешествует по разным деревням, пытаясь найти подходящее место. Тайно она надеется встретить другую семью кроликов и, возможно, найти свою пару. Однако, она никак не ожидала, что когда приедет в Грей Ридж, то найдет не только одного единственного, а сразу троих. Три огромных волка, которые выглядят голодными, и дело явно не в еде.

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

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

Но кто бы ее спрашивал! Однажды ее попросту украли и силком обвенчали с бароном Мэлоуэном, пытаясь таким образом побороть лежащее на нем проклятие. И что теперь? Покорно жить с мужем, рожать детишек и почитать свекровь? Вот еще! Грета Саттон вовсе не такова, чтобы сложить руки и смириться с обстоятельствами.

Мужа приручить? Дракона… простите, свекровь одолеть? Проклятие распутать? Нет ничего невозможного, когда за дело берется старший научный сотрудник Грета Саттон!

Наставление для программистов, руководящих другими программистами

Информация о книге

Дж. Ханк Рейнвотер. Как пасти котов

Наставление для программистов, руководящих другими программистами

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

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

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

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

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

Я немного перекомпановал наиболее интересный материал и постарался выделить главное. Оригинальный текст максимально сохранен.

О технологиях

«Да, технологии важно, но все дело в тех, кто их реализует. Технология «волшебной пули» или «золотого молотка» (как бы вы ее ни назвали) не может решить бизнес-проблем, это делают люди»

«Учитесь организовывать сотрудничество технологии и бизнеса; при этом не забывайте, что доминирующую роль в этом союзе играет именно бизнес»

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


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

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

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

Важное замечание о том, как нужно стремиться к удачной архитектуре:

Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана. С точки зрения этих авторов, любой архитектор должен:

• в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;

• хорошо разбираться в предметной области клиента – будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;

• получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;

• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;

• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;

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

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

Простые, понятные, но важные замечания к проектным ограничениям:

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

• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?

• Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?

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

• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?

В этом мире существует огромное количество технологий и методик. И с каждым днем их становится все больше. За всем угнаться невозможно. Поэтому:

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

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

Предмет многолетних споров, возникающих практически на каждом проекте. Не знаю как Вам, но для меня это проблема, которую приходится обсуждать с сотрудниками регулярно:

Поиск равновесия между чистотой и практичностью – трудное дело для человека, влюбленного в программирование. Концепция «хорошего программного обеспечения нужно в меру», возможно, впервые открытая Microsoft, имеет свои достоинства. Вы можете тратить очень много времени, добиваясь чистоты кода в ущерб практичности. Что действительно нужно, так это удобство эксплуатации программного обеспечения, и практичность больше соответствует этой цели, чем чистота. Конечно, чистота может быть полезной, но какой ценой? Я не говорю о создании неряшливого или непродуманного кода, я имею в виду программное обеспечение, которое может дополняться и расширяться не только его создателем, но и другими программистами. Проблема чистоты кода состоит в том, что она подобна красоте – ее воспринимают глазами. Вашим глазам постоянно нужно носить очки практичности.

О делегировании задач

Классика передачи задач:

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

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

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

«Не соблазняйтесь непосредственным удовольствием от кодирования; лучше поразмыслите, как помочь остальным получать это удовольствие под вашим руководством»

«Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить»

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

А следующую цитату я испытывал не раз на собственном опыте:

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

«В ходе выполнения проекта от начальных стадий к завершающим у лидера нередко появляется ощущение стрельбы по движущейся мишени – вот почему для него так важен опыт. Если бы лидеры разработки программных продуктов могли тренироваться в стрельбе по движущимся мишеням на стрельбище, было бы просто здорово. К сожалению, практиковаться нам приходится в реальных условиях – иначе вряд ли мы срывали бы сроки. Чем больше вы будете тренироваться, тем совершеннее станут ваши навыки. Делегирование – это лучший помощник в деле стрельбы по мишеням. Стоит вам попытаться сбить их все самостоятельно (то есть поддаться соблазну мелочной опеки), патроны кончатся раньше времени»

О планировании

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

А ниже просто аксиома, как много народу обжигалось!:

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

А вот золотые слова:

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

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

Надо учиться расставлять приоритеты и «дожимать» задачи до конца:

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

Полезная цитата о коммуникациях внутри проекта и полноте формулирования требований:

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

Ох уж эти переработки! Как знакомо это любому it-специалисту. Относиться к переработкам можно по-разному, как собственно, и происходит на самом деле. Лично мое мнение, что надо с этим бороться. Переработки возможны, но только как форс-мажор, а не как норма жизни!

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

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

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

«Неудачный результат простителен, а вот недостаточные усилия – это смертный грех»

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

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

Практичные рекомендации по выявлению требований:

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

1. Прочтите требования дважды: один раз, чтобы понять широту замысла, второй – чтобы постичь его глубину.

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


3. Набросайте предварительный план макетирования проектов – он поможет выявить среди требуемых свойств неизвестные.

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

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

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

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

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

Вопросы управления командой разработчиков

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

«Если попробовать свести функции управления к нескольким четким и удобоваримым принципам, получится, что руководитель:

• расставляет приоритеты и борется с раздражителями (фокусируется на поставленных задачах);

• совершенствует свои навыки в области руководства проектами и прорабатывает все их детали;

• пресекает низкое качество кодирования, пока оно не пустило в проекте корни;

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

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

«Менеджеры иногда погрязают в хитросплетениях своей работы; лидеры, напротив, всегда стремятся разработать новые приемы, позволяющие подчиненным брать все более высокие планки»

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

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

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

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

«Некоторые начальники – я имею в виду тех, кто находится выше вас в руководящей иерархии – предъявляют к своим подчиненным чрезмерно высокие требования, но при этом не удосуживаются посвящать их в подробности своих замыслов»

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

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

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

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

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

«Дипломатия – это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус»

«Кейперс Джонс (Capers Jones) в своей книге «Applied Software Measurement» утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью общими характеристиками.

1. Они проводят точные измерения продуктивности и качества программных продуктов.

2. Они тщательно планируют и оценивают программные продукты.

3. У них работают квалифицированные менеджеры и технические специалисты.

4. У них адекватные организационные структуры.

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

6. Их сотрудники работают в достойных условиях»

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

Любую трудную задачу следует рассматривать как возможность для дальнейшего развития, а отнюдь не как очередной повод «сжать кулаки»

О контроле работы программистов

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

«Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая»

«В попытках исцелить молодых и неопытных программистов проявляйте такт. Упираются рогом? Ради бога – пусть некоторое время поучатся на собственных ошибках; при этом не забывайте регулярно показывать им правильное направление. Естественно, прежде чем допустить их код до компиляции, предложите свои коррективы. Мы, программисты (впрочем, как и все человеческие существа), имеем обыкновение совершать ошибки, лицезреть их последствия и только после этого искать лучшие пути достижения тех же целей – так мы учимся»

«Старайтесь, чтобы в ходе цикла разработки программисты-новички занимались тестированием не меньше, чем кодированием. Это позволит им перенять ценный опыт своих более квалифицированных собратьев»

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

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

«Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля»

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

Некачественная или случайная архитектура приводит к таким последствиям:

• сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;

• нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;

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

Ниже перечислены последствия неадекватного проектирования:

• из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;

• модификация в одном месте приводит к нарушению в нескольких других;

• вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.

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

Ну вот, к примеру, классическая ситуация – цикл разработки подходит к концу, как вдруг выясняется, что один из ваших сотрудников забыл выполнить данное ему задание. Если времени в обрез, а вокруг никого, кому это задание можно было бы перепоручить, вы, скорее всего, не удержитесь и возьметесь за него сами. Скажете, это простительное исключение? Может быть, но имейте в виду – действуя подобным образом, вы приучаете своих подчиненных к тому, что за невыполненную работу никаких взысканий не последует – вы просто сами все доделаете. Хорошо ли это? Думайте сами.

Перечислю некоторые методики проверки.

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


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

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

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

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

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

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

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

Про совещания

• Ваша задача – сделать так, чтобы все функции были корректно спроектированы и впоследствии качественно разработаны.

• У каждого участника группы могут быть собственные представления относительно проектного решения одной и той же функции.

• Программисты склонны проектировать лишь те функции, которые они могут или хотят разрабатывать.

• У некоторых программистов могут быть планы, отличные от ваших; трудно выявляемые, такие бунтари способны привести к саботажу совещаний.

• Единодушная поддержка сотрудниками высказанных вами идей (если только они не объективно гениальны) наводит на грустные размышления.

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

«Совещания, не должны представлять собой арену для выражения недовольства»

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

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

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

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

О компетенциях сотрудников

• Прошлые достижения отдельного сотрудника группы совершенно не гарантирует успешной деятельности группы в целом.

• Формированием группы должен заниматься только ее руководитель. В этом отношении он должен пользоваться полным доверием своего начальника.

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

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

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

10 стереотипов о программистах

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

Поговорим о том, какими еще стереотипами обросла специальность программиста.

И разработчик, и сисадмин — все «компьютерщики»

«Чаще всего люди не делают отличий между профессией разработчика и другими специальностями в сфере информационных технологий. Если сказать, что работаешь программистом, можно в ответ услышать „О, ты компьютерщик! Слушай, а не глянешь, у меня тут телефон глючит“. В этом случае лучше всего помогает аналогия с медициной: „и стоматолог, и проктолог — врачи, но ты ведь различаешь их специализацию“» — делится Кирилл Громов, ведущий разработчик баз данных «Лестэр ИТ».

«Часто люди не готовы понять, что у программиста может быть какая-то специализация. С чем-то похожим сталкиваются врачи. Но всё-таки не каждому приходит в голову попросить хирурга посмотреть, что не так с глазом. А с программистами похожие ситуации возникают гораздо чаще.

Люди путают их с системными администраторами, думают, что программист должен понимать всё в компьютере. Если ты попал в гости и рассказал, что ты программист — 70% хозяев попросят посмотреть свой компьютер, на котором „что-то не так“. Хотя далеко не все программисты разбираются в железе» — делится Даниял Гулиев, архитектор отдела разработки компании «ТрастВерс».

Иногда доходит до комичного: «Директор долгое время был свято уверен, что программист может выполнять вёрстку корпоративных буклетов вместо удалённых дизайнеров, а и также настраивать 1С: Предприятие и вносить правки по сайту (он у нас на Битриксе). Логика железобетонная: эти действия ведь производятся в программах, соответственно программист обязан в этом разбираться» — говорит Виктория Чеботарева, программист-эникейщик в «Гидроланс».

Разработчики всегда крайние

«Если получился кривой или неудобный сайт, программа, то виноват всегда программист. А то, что у нас есть разделение профессий и зон ответственности, во внимание не принимается» — рассказывает Андрей Вариков, директор центра разработки ПО Модульбанка.

«Тыжпрограммист» всемогущ

«Если попытаться обобщить все мифы о программистах, то станет понятно, что „тыжпрограммист“ — это такой зверёк, который может починить телефон, ноутбук и вообще любую технику, написать сайт, мобильное приложение, AI для робота и вообще любую программу, по фотографии вылечить вирус, по телефону определить, почему ничего не работает, на расстоянии заправить принтер» — говорит Даниял Гулиев, архитектор отдела разработки компании «ТрастВерс».

Плохая физическая форма

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

Отшельнический образ жизни

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

Например, один из моих знакомых программистов, внешне очень мирного вида, на самом деле является „боевой машиной“, экспертом по единоборствам. Другой товарищ — активный участник бодибилдерских соревнований. А среди программистов „ТрастВерса“ есть двое людей, всерьез увлеченных электронной музыкой, с концертами и гастрольной деятельностью» — говорит Даниял Гулиев, архитектор отдела разработки компании «ТрастВерс».

«Когда я говорю о своей работе: „я начальник программистов“, незнакомые люди обычно делают круглые глаза и замирают с открытым ртом. И отвечают, что совсем не так представляли себе программистов. Обычно формулируют так: „айтишники все угрюмые, бородатые и в свитерах“.

Илон Маск рекомендует:  Введение в регулярные выражения синтаксис

Ну, бороды и свитера — это уже давно опционально. А вот на счет угрюмости подтвержу — чем молчаливей программист, тем обычно он профессиональней» — делится Юлия Котенко, председатель правления Ассоциации интернет–разработчиков «ВебАльянс».

Программист = крэкер

«Стоит отметить прямое сравнение программистов и хакеров. Конечно, оба направления являются звеньями одной цепи, но постоянные вопросы друзей о том, смогу я или нет взломать какой-нибудь сайт, мне уже немножко поднадоели» — сетует Юрий Пановский, разработчик в компании «Биплан».

Среди программистов больше всего стартаперов

«Любой программист рано или поздно попробует запустить свой стартап. Возможно, он делает это прямо сейчас, пока вы читаете этот текст. Думаю, что стартаперов среди программистов не больше, чем среди представителей других „диджитал-профессий“» — говорит Андрей Вариков, директор центра разработки ПО Модульбанка.

Три правдивых стереотипа

Некоторые из предрассудков, всё-таки, правдивы:

«„Guys in sandals“ — действительно чуть ли не половина матерых программистов ходит по офису в тапках/шлепанцах/сланцах…
„В IT нет ничего невозможного!“ — возможно практически все, но очень часто у заказчика может не хватить денег на невозможное.
„Избалованные засранцы с высокими зарплатами!“ — да, получение результата интеллектуального труда требует особого подхода, поэтому программисты избалованы условиями, в том числе компенсацией за труд, но не они заставили делать эти условия, окружающий мир постарался» — подтверждает Всеволод Андронов, заместитель Технического директора ООО «Стрим».

А с какими стереотипами сталкивались вы?

Обучаем без стереотипов: профессия «Веб-разработчик» от GeekBrains.

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

Поговорим о том, какими еще стереотипами обросла специальность программиста.

И разработчик, и сисадмин — все «компьютерщики»


«Чаще всего люди не делают отличий между профессией разработчика и другими специальностями в сфере информационных технологий. Если сказать, что работаешь программистом, можно в ответ услышать „О, ты компьютерщик! Слушай, а не глянешь, у меня тут телефон глючит“. В этом случае лучше всего помогает аналогия с медициной: „и стоматолог, и проктолог — врачи, но ты ведь различаешь их специализацию“» — делится Кирилл Громов, ведущий разработчик баз данных «Лестэр ИТ».

«Часто люди не готовы понять, что у программиста может быть какая-то специализация. С чем-то похожим сталкиваются врачи. Но всё-таки не каждому приходит в голову попросить хирурга посмотреть, что не так с глазом. А с программистами похожие ситуации возникают гораздо чаще.

Люди путают их с системными администраторами, думают, что программист должен понимать всё в компьютере. Если ты попал в гости и рассказал, что ты программист — 70% хозяев попросят посмотреть свой компьютер, на котором „что-то не так“. Хотя далеко не все программисты разбираются в железе» — делится Даниял Гулиев, архитектор отдела разработки компании «ТрастВерс».

Иногда доходит до комичного: «Директор долгое время был свято уверен, что программист может выполнять вёрстку корпоративных буклетов вместо удалённых дизайнеров, а и также настраивать 1С: Предприятие и вносить правки по сайту (он у нас на Битриксе). Логика железобетонная: эти действия ведь производятся в программах, соответственно программист обязан в этом разбираться» — говорит Виктория Чеботарева, программист-эникейщик в «Гидроланс».

Разработчики всегда крайние

«Если получился кривой или неудобный сайт, программа, то виноват всегда программист. А то, что у нас есть разделение профессий и зон ответственности, во внимание не принимается» — рассказывает Андрей Вариков, директор центра разработки ПО Модульбанка.

«Тыжпрограммист» всемогущ

«Если попытаться обобщить все мифы о программистах, то станет понятно, что „тыжпрограммист“ — это такой зверёк, который может починить телефон, ноутбук и вообще любую технику, написать сайт, мобильное приложение, AI для робота и вообще любую программу, по фотографии вылечить вирус, по телефону определить, почему ничего не работает, на расстоянии заправить принтер» — говорит Даниял Гулиев, архитектор отдела разработки компании «ТрастВерс».

Плохая физическая форма

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

Отшельнический образ жизни

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

Например, один из моих знакомых программистов, внешне очень мирного вида, на самом деле является „боевой машиной“, экспертом по единоборствам. Другой товарищ — активный участник бодибилдерских соревнований. А среди программистов „ТрастВерса“ есть двое людей, всерьез увлеченных электронной музыкой, с концертами и гастрольной деятельностью» — говорит Даниял Гулиев, архитектор отдела разработки компании «ТрастВерс».

«Когда я говорю о своей работе: „я начальник программистов“, незнакомые люди обычно делают круглые глаза и замирают с открытым ртом. И отвечают, что совсем не так представляли себе программистов. Обычно формулируют так: „айтишники все угрюмые, бородатые и в свитерах“.

Ну, бороды и свитера — это уже давно опционально. А вот на счет угрюмости подтвержу — чем молчаливей программист, тем обычно он профессиональней» — делится Юлия Котенко, председатель правления Ассоциации интернет–разработчиков «ВебАльянс».

Программист = крэкер

«Стоит отметить прямое сравнение программистов и хакеров. Конечно, оба направления являются звеньями одной цепи, но постоянные вопросы друзей о том, смогу я или нет взломать какой-нибудь сайт, мне уже немножко поднадоели» — сетует Юрий Пановский, разработчик в компании «Биплан».

Среди программистов больше всего стартаперов

«Любой программист рано или поздно попробует запустить свой стартап. Возможно, он делает это прямо сейчас, пока вы читаете этот текст. Думаю, что стартаперов среди программистов не больше, чем среди представителей других „диджитал-профессий“» — говорит Андрей Вариков, директор центра разработки ПО Модульбанка.

Три правдивых стереотипа

Некоторые из предрассудков, всё-таки, правдивы:

«„Guys in sandals“ — действительно чуть ли не половина матерых программистов ходит по офису в тапках/шлепанцах/сланцах…
„В IT нет ничего невозможного!“ — возможно практически все, но очень часто у заказчика может не хватить денег на невозможное.
„Избалованные засранцы с высокими зарплатами!“ — да, получение результата интеллектуального труда требует особого подхода, поэтому программисты избалованы условиями, в том числе компенсацией за труд, но не они заставили делать эти условия, окружающий мир постарался» — подтверждает Всеволод Андронов, заместитель Технического директора ООО «Стрим».

А с какими стереотипами сталкивались вы?

Обучаем без стереотипов: профессия «Веб-разработчик» от GeekBrains.

Письмо слепого программиста

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

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

О себе

Меня зовут Михаил Духонин. 37 лет. Живу в Саратове. Холост. Получил высшее образование по специальности «Социальная философия», закончил аспирантуру, защитил диссертацию. В общем, незамутненной чистоты гуманитарий.

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

Предваряя стандартный вопрос о том, как же я, слепой, работаю на компьютере (хотя, как специалист в ИТ-сфере, возможно, вы и в курсе…), замечу, что существуют так называемые программы экранного доступа (скринридеры, screen reader), которые озвучивают интерфейс ОС и программ. Они позволяют ориентироваться на компьютере на слух.

Компьютер у меня появился достаточно поздно — в 2002 г. До этого несистематически учился на нем работать в школе и спец-библиотеке. Даже DOS слегка зацепил… Но вообще, обучать меня работе на компьютере особо было некому. Поэтому я с самого начала привык действовать методом научного тыка, логикой и читать разного рода хелпы, руководства и прочую тому подобную литературу. Так что на сегодняшний момент без ложной скромности могу назвать себя очень продвинутым пользователем. Работаю на Win7. Эту ОС, правда, не изучал столь же глубоко, как Win98 и WinXP.

Где-то в году 2005-м попал мне в руки диск с актуальными на тот момент средами программирования. Именно с этого момента начинается мой путь в программирование.

Цели и задачи

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

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

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

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

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

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

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

Выбор инструмента и общий план пути

На вышеупомянутом диске помимо всяких ассемблеров были Borland Visual C++, Borland Delphi 6 и Visual Basic 6. Само собой первой проблемой, которая встала передо мной, был вопрос выбора. Выбор я вполне сознательно сделал в пользу Delphi. И вот почему. Становиться профессиональным программистом я не собирался. Программирование было для меня исключительно средством решения тех или иных проблем, для которых не удалось найти готовых решений Ну или чего-то совсем специфичного. В то время я располагал следующей информацией. VB — интерпретируемый язык, где код выполняется интерпретатором. Это мне не нравилось (потенциальные тормоза и т.п.). Ну и репутация у Бэйcика была как у чего-то совсем детсадовского.

В то же время C и C++ позиционировался как сложный в освоении язык, ориентированный на профессиональных программистов. Это мне также не подходило. Хотелось чего-то среднего по сложности и в то же время универсального. Всем этим требованиям отлично соответствовала Delphi. С одной стороны Pascal позиционировался как достаточно простой в освоении язык, с другой — Delphi была вполне современной и профессиональной средой разработки. Ну и то, что разработанные с ее помощью программы исполнялись без дополнительных посредников вроде интерпретаторов, тоже было плюсиком. Забегая вперед скажу, что относительно недавно я пытался освоить плюсы в варианте Visual Studio, но для меня это оказалось действительно очень сложной задачей. В общем, пока остановился на Python.

Честно говоря, для меня так и осталось загадкой, почему Borland перестала поддерживать Delphi. ИНХО именно это стало причиной упадка данной среды разработки. Монструозность… Хм… Ну Visual Studio от Microsoft тоже не сказать, чтобы такая уж компактная… Кстати, насколько мне известно, потомок Delphi до сих впор вполне себе существует под другим брендом, а к Visual Studio есть расширение для разработки на Pascal от той же компании. Тем не менее, не знаю, как за бугром, но в России эта среда считай, что не существует. Ничего на русском я о ней не видел.

В заключение этого раздела немного о периодизации. Первым моим крупным этапом в освоении программирования стала, как уже понятно, Delphi. Года два — три я интенсивно ее осваивал, даже CGI-приложение на ней написал, вполне себе рабочее. Жаль только, пропало все практически с убитым диском. Затем у меня был достаточно длительный перерыв. К тому времени я устроился на работу, где сильно увлекся MS-Excel. Первоначально глубоко изучил штатные возможности программы. Но их мне оказалось недостаточно. В конце-концов возникла потребность в изучении VBA, что я с успехом и сделал. Показателем успеха стало то, что сейчас я пишу макросы не только для себя, но и по рабочим задачам, т.е. стал профессиональным программистом в вашем понимании этого понятия. Правда, больших денег за это я не имею… Но это тонкости. По VBA я даже прошел один из курсов на Интуит и обладаю соответствующим сертификатом. Правда, не могу сказать, что этот курс сам по себе сделал меня программистом…

Между делом я попытался освоить Visual C++, причем чистый, не под NET. Все таки хотелось чего-то такого, на чем можно писать программы любого типа. Но увы. Язык этот оказался на данном этапе мне не по зубам. И литературы для начинающих, кстати, для него на удивление очень мало. Не идет ни в какое сравнение ни с Delphi времен ее расцвета, ни с тем же Python. Пытался также изучать PHP, но оно тоже не пошло. Видно не судьба мне писать на C-подобных языках…

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

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

Методика изучения

Изучал программирование я исключительно по книгам. Честно говоря, для меня является загадкой, как можно изучать его по видеокурсам. Хотя надо бы попробовать… Копипастить же код в любом разе удобнее из книги, чем переписывать из окна плейера. Да и печатный текст, по-моему, гораздо доступнее для освоения, нежели речь. Но тут готов допустить, что на вкус и цвет все фломастеры разные.

Здесь есть одна любопытная особенность, которая несмотря на свой привходящий характер имеет большое значение для освоения предмета. Дело в том, что литература по программированию в подавляющем большинстве случаев выложена в формате PDF. Сам по себе он является картинкой, для чтения скринридерами недоступной. Поэтому я обычно читал книги, распознанные с помощью FineReader в формате TXT. Файнридер же совершенно безобразно распознает листинги. Причем, это касается как OCR-слоя в PDF, так и книг в скринридеро-доступных форматах (вроде html, doc, chm и т.п.) В общем чистый копипаст в подавляющем большинстве случаев не катил никак. Прежде чем изучить работу тех или иных примеров из книг, эти примеры приходится дешифровывать. И этот этап для меня является вполне себе обычным. Именно поэтому, думаю, я совершенно не заметил того «большого барьера», о котором вы пишете в своей книге. Для меня вполне естественно, прежде чем что-то заработает, это нечто надо тщательно вылизать. Да и если сам набираешь код, тоже от опечаток никуда не деться. И вообще, уж не помню почему, но я изначально был ориентирован на то, что программирование это не совсем написание литературного произведения.

Поэтому, первым шагом в освоении любого языка или технологии программирования является поиск подходящей книги. В идеале не больше одной — двух. Delphi я начинал изучать по «Delphi 6» Фаронова и «Иллюстрированному самоучителю по Delphi 7 для начинающих». Огромное значение для меня в последствии сыграла «Библия Delphi» Фленова.

Excel и VBA я изучал по книгам Джона Уокенбаха. Кстати, 3 тома почти по 1000 стр. Целиком я их, конечно, не осилил, но тем не менее, программировать на VBA научился. Об интуитовском курсе уже упоминал, хотя нового там было только то, что касалось Word.

C++ пытался изучать по Хортону. Но, как уже писал, не пошло. Хотя несколько глав я таки прошёл. Были еще книги Прохорёнка, но этого автора я вообще почему-то воспринимаю очень плохо. С Python’ом мне вообще повезло — первой же мне под руку попалась книга Майкла Макграта «Программирование на Python для начинающих», где этот язык был описан с той детализацией, что доктор прописал.

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

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

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

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

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

Остановлюсь немного на том, какие книги стоит выбирать. Для освоение азов лучше всего подойдут книги типа «… шаг за шагом». Дело в том что мне не очень интересно читать сотню — другую страниц, прежде чем можно будет открыть IDE и написать первые строки кода. Процесс изучения должен быть исключительно активным: прочитал параграф, тут же набросал что-нибудь запускающееся, иллюстрирующее прочитанный материал. Примеры также можно самостоятельно переписывать, а в идеале, и как-нибудь модифицировать, и воочию смотреть, как всё это работает. Впрочем, кому-то, наверное, будет под силу прочитать учебник от корки до корки, да ещё и не один раз, прежде чем начать писать программы… Но это явно не я! Выбирать лучше всего книги, объёмом не более 200 — 300 страниц. Ну или талмуды с хорошо прописанной первой частью (где про основы). Большую роль играет и то, кто написал книгу. Выбирать надо такого автора, которого хорошо воспринимаешь и понимаешь.

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

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

  1. какого результата хочу добиться и
  2. какие исходные данные у меня есть.

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

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

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

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

Достижения

Прежде чем описать те проблемы, с которыми я столкнулся, хотелось бы систематизировать свои достижения. Когда я писал на Delphi, главным моим достижением стал иерархический блокнот. Он представлял собой дерево, каждый узел которого был ассоциирован с неким текстом. Данные хранились в базе Access (2003 тогда еще). Соответственно, там были и SQL-запросы, и активное использование событий (не только OnClick) и куча всего другого. Даже класс простенький написал. К сожалению, исходный код был утрачен, хотя экзешник где-то валяется. Я успел сделать много вкусных для себя плюшек, вроде манипулирования расположением узлов с клавиатуры, создания нескольких блокнотов, причем, кроме универсального блокнота можно было создать специальный, где с каждым узлом можно было связать ссылку, которая по желанию открывалась в браузере прямо из программы. К сожалению, не успел прописать импорт/экспорт данных, без чего на постоянной основе программой не пользовался, хотя несколько блокнотов и создал. Сейчас пользуюсь близким по функционалу Flash Note. Но многого из того, чего хотелось бы, там нет.

На VBA у меня также есть макросы, причем некоторыми из них пользуюсь по работе буквально каждый день. Основные успехи связаны с конвертацией данных из определенным образом оформленных файлов Word или XML в таблицу Excel. Есть одна смешная вещь — я могу на VBA легко написать формулу массива (Ну она возвращает variant, который является массивом), а вот с готовыми функциями массива у меня жесткие сложности. Для меня до сих пор осталось загадкой, почему СУММ не захотела суммировать массив, возвращаемый ВПР (массив точно возвращался). Пришлось идти другим путем, и получать нужный массив комбинацией ИНДЕКС и ПОИСКПОЗ. Он прекрасно просуммировался. Есть в моей коллекции и пользовательские функции массива.

Также написал функции, конвертирующие десятичное число в 62-ричное и обратно (захотелось получить числа, где малым числом символов можно было записать возможно большее количество чисел. Числа записывались символами 0..9, a..z, A..Z — ну вот и 62…)

Причем меня не особо смущает, если приходится писать кучу вложенных друг в друга условий и циклов. Эх, есть у меня один макрос… Даже самому страшно, чего я там наворочал, но же работает.

На Python’е, так уж повелось, я сосредоточился на работе с архивами, парсинге HTML/XML. Экспорт в CSV… В общем, библиотеки/классы ElementTree, BeautifulSoup, zipfile, csv, os и т.п. — наше все…И также есть скрипты, которые используются как мной любимым, так и другими. Недавно вот jSon разбирал. Главным достижением стала библиотечка по извлечению метаданных из FB2-книг. Потом они складировались в CSV, который можно скопировать в таблицу Excel. Правда, тут столкнулся с некоторыми проблемами, решить которые пока не удалось.

Проблемы

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

В ваших маркетинговых материалах вы высказываете мысль, что для того, чтобы стать программистом, совсем необязательно профильное образование. Более того, некоторые ваши высказывания можно трактовать в том смысле, что таковое образование вообще не делает человека программистом, нагружая его массой совершенно лишней информации с одной стороны, и не давая знаний собственно по программированию с другой. Чем-то мне это напомнило ворчание школьника — типа «нафига мне учить математику, если я хочу стать юристом. » Нет, ну понятно, что у 40-летнего дядечки это снимет одно из типичных возражений: «Как я могу стать программистом, если у меня нет профильного образования, и вообще я гуманитарий…» Но вы позиционируете ваш курс и для 14-летних подростков. Мне даже страшно подумать, что будет, если кто-нибудь из них воспримет ваши слова всерьез. И те кумиры, которых вы упоминаете (ну которые не закончили образования) станут примером для подражания для этих детей…

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

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

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

Но даже в повседневной практике, где я не зарываюсь в вышеописанные дебри, я постоянно натыкаюсь на разного рода засады. Приведу пример. Я уже говорил, что написал библиотеку по извлечению метаданных из FB2-книг. Но полноценно пользоваться я ей пока не могу. В ТЗ, которое я для себя сформулировал, были следующие требования. Книги запакованы в ZIP-архивы. необъходимо извлекать из них данные, причем без распаковки файлов на диск. Иными словами, надо распаковать файл в переменную. После этого переменная должна скармливаться парсеру XML. Казалось, бы чего проще…

В Python за работу с ZIP-архивами отвечает модуль zipfile, а парсер XML содержится в библиотеке xml.etree.ElementTree, где сам парсер содержится в классе ElementTree.

Первой засадой стало то, что напрямую распаковать файл в переменную не получается. В конце-концов, я это сделал, но в итоге получил строку байтов. А конструкторы ElementTree требуют именно файла. Пришлось использовать функции из этой библиотеки, которые предназначены для анализа XmL из строк. А они возвращают не целостный объект XML, а объекты узлов. Не смертельно, но неприятно. Поясню — у меня несколько сот тыс. fb2-книг. Мне до ужаса не охота при пакетной их обработке распаковывать каждый архив на диск, анализировать распакованный файл, а потом его стирать… Это, боюсь, и долго будет, да и винчестер жалко… То ли дело все проворачивать в оперативной памяти…

Но и это еще не все. Некоторые архивы обрабатываются некорректно. Возникают ошибки двух типов. Во-первых, парсер не захотел обрабатывать некоторые fb2-файлы в кодировке ANSI (CP-1251). Он падал на некоторых символах, например &, или с кодом 7. В то же время, все файлы в кодировке UTF-8 в этом смысле обрабатывались корректно. Во-вторых, метод FromString класса ElementTree почемуто некорректно извлекал данные из некоторых строк, считанных из архивов. Причем, будучи распакованными, эти файлы парсились корректно. В чем разница между архивами, которые читались неправильно, и всеми остальными — понять мне так и не удалось.

Еще одной проблемой, с которой я столкнулся, стало создание графического интерфейса. Собственно, для зрячих тут никакой проблемы нет. Практически каждая IDE в своем составе имеет простые инструменты для построения GUI. Когда я работал с Delphi, тоже без особых напрягов создавал графические приложения на основе библиотеки VCL. Пользоваться палитрой и дизайнером, правда, я не мог, но IDE Delphi имела список всех компонентов, из которого эти компоненты можно было добавлять на форму. А затем ужевручную можно было настроить свойства TOP, Height, Left и Bottom каждого компонента. Моей способности к пространственному мышлению вполне хватало на то, чтобы представить, как компоненты должны были располагаться на форме и вычислить значения соответствующих свойств. А если пользоваться различными заданными значениями свойства Align, то и вычислять было не обязательно.

В общем, с Delphi было почти все отлично. «Почти» было связано с еще одной проблемой — сам по себе интерфейс, это хорошо, но он должен корректно озвучиваться скринридерами. VCL в этом плане была вполне достойной библиотекой. Судя по всему она представляла собой обёртку вокруг стандартных графических компонентов Windows. А эти компоненты, в свою очередь, более или менее нормально озвучиваются. Тем не менее, неприятные моменты и тут имелись. Например, там был компонент TCheckListView, — обычный ListView, но с каждым элементом списка в нём связан флажок. Так вот, как этот флажок, так и его состояние не озвучивались совсем…

Здесь имеется еще один путь — Скринридер, которым я пользуюсь, имеет инструменты, которые позволяют пользователю настраивать озвучивание новых приложений. В том числе, он содержит собственный скриптовый язык. Вообще говоря, в действительности первым языком программирования, который я изучал, был именно данный скриптовый язык. Основы языка я освоил без особых проблем. Но вот полноценно решать сколь-нибудь сложные проблемы озвучивания приложений я так и не научился. Суть проблемы в том, что озвучка основана на знаниях структуры окон Windows и свойств этих окон, умении работать с интерфейсами COM вообще и MSAA в частности, а также навыках обработки событий Windows. Ну там еще кое-какую информацию иногда можно получить, посылая сообщения функциями send-и postmessage. Чисто теоретически я все это понимаю, даже могу написать какой-нибудь перехватчик события или что-то извлечь из MSAA. Но всё равно — написание полноценного пакета скриптов для озвучки чего-нибудь у меня ниразу не получалось.

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

С Питоном тоже не все ладно. Во-первых, программное создание GUI в Python неразрывно связано с ООБ. Это само по себе для меня сложно, о чём уже писал. Во-вторых, встаёт вопрос о выборе библиотеки. Выбирать приходится между QT5 и Tkinter. Никаких других вариантов, которые можно было бы освоить самостоятельно, я не нашёл. Есть еще WX, которая, на самом деле, является наилучшим вариантом, но ее до сих пор не портировали на Python3. Неизвестно, когда это случится, случится ли вообще и напишут ли для нее русский мануал…

GUI, написанные на ранних версиях QT не озвучиваются скринридерами в принципе. Спецсофт просто ничего не видит в соответствующих окнах. Кстати, именно поэтому слепым абсолютно недоступна десктопная версия Telegram. В последних версиях библиотеки были добавлены инструменты Accessibility. Теперь кнопки и прочие контролы более или менее озвучиваются. Насколько я мог понять, информация берется из MSAA. Но люди, работавшие с библиотекой, пишут, что корректно озвучивается далеко не всё. Например, проблемы возникают с работой в многострочных полях редактирования. Ну и возникает вопрос — имеет ли смысл тратить кучу времени и сил на изучение сложного материала, чтобы в очередной раз понять, что всё бесполезно?

Библиотека Tkinter, также меня не вдохновила. Во-первых, судя по той информации, которая мне доступна, она достаточно бедна компонентами. Я не смог понять, как на ее основе писать оболочку вокруг БД. Ну и если дефолтная IDE Python действительно написана на Tkinter, озвучку придётся доводить напильником. И без гарантий, что я с этим напильником совладаю…

У меня даже была мысль изучить PHP или Django (под Python), чтобы уйти от проблемы GUI, ограничившись Web-интерфейсом. Но, как ни крути, а браузер достаточно ограничен в плане интерфейса. Нет, как раз оболочку к БД я сделаю. Может для этого даже не обязательно изучать язык, а можно ограничится PHPAdmin’ом. Но вот обеспечить тот функционал, который мне нужен, вряд ли получится. Например, как в браузере работать с архивами, в которых лежат далеко не всегда HTML-файлы? А ведь эти файлы нужно открывать либо в ассоциированных программах, либо во внутреннем просмотрщике, создать который в Web-интерфейсе та еще задача…

Собственно, всё… Что делать дальше, я пока не знаю. По-видимому, мне таки не хватает тех фоновых знаний, которые даются студентам в ВУЗах. Изучать новые инструменты? — Какие. Тоже и по литературе — не понятно что читать, за что браться…

Заключение

Итак, какие выводы можно сделать на основании моего опыта самообразования в области программирования?

1. Изучить основы языка и начать писать на нём типовые программы, используя современные IDE, — относительно просто.
2. Последовательность шагов при освоении программирования путём самообразования.

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

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL