Методы быстрого печатания

[Olegator]

Кто-нибудь пробовал осваивать какие-нибудь методы быстрого, слепого, десятипальцевого печатания.

[Гром]

Я печатаю вслепую 8-ю пальцами. Без мизинцев.
Никакой методики. Только практика. Причем клавиатура у меня вообще без русских букв

[RXL]

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


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

[Olegator]

Есть две прогаммы
1. VerseQ
2. СОЛО на клавиатуре
Пытался вторую освоить, но там требование, во время обучения больше ничего другого не печатать, кроме тех примеров, которые требуется выполнить в этой программе. И поэтому я не стал её проходить. Её придумал какой то психолог. И там куча анекдотов и успокаивающих слов, которые видимо должны меня настроить на удачное прохождение курса.
Первая обещает:

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

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

От других клавиатурных тренажеров VerseQ отличается целым набором
уникальных свойств:

- Обучение начинается сразу со всех букв алфавита.
- Программа сразу заставляет пальцы запоминать "аккорды" клавиш, характерные
  для языка. 
- Программа обучает незаметно для пользователя, аккуратно подстраиваясь под
  его индивидуальные ошибки.
- Дифференциальный подход к времени обучения часто и редко
  встречающихся символов.
- Вы не будете испытывать дискомфорта при обучении, наоборот работа с VerseQ
  способствует психологическому расслаблению.
- Профессионалы найдут в VerseQ прекрасную разминку для пальцев перед работой!
PS: А тем кто знает KeyTO, легко узнают его продолжение в VerseQ

[Alf]

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

Если ты собрался учиться быстрому печатанию только ради программирования, IMHO это пустая трата времени - программист много думает и совсем немного печатает. Может получиться так, что потратишь массу времени на тренировки, чтобы выгадывать несколько минут в день.

[RXL]

Alf, помимо кода, иногда приходится набирать и человеческий текст (те же описания программ, ф-ий, служебки и прочую чушь).

[Alf]

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

[Olegator]

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

[Гром]

Альф - а откуда такая статистика про 10 операторов.
Если я правильно понял - оператор - + - / * == = и т.д.

Что под этим имеется ввиду.

[Alf]

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

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

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

[Alf]

Альф - а откуда такая статистика про 10 операторов.
Если я правильно понял - оператор - + - / * == = и т.д.

Что под этим имеется ввиду.

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

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

Очень хороший вопрос - что здесь имеется в виду под словом оператор. Большинство подобных статистических данных собиралось в старые добрые времена структурного программирования. По устоявшейся традиции тех времен термин statement переводился на русский как оператор. Впоследствии к нам пожаловали языки типа С++, в которых присутствовало понятие operator. Это внесло некоторую сумятицу в и без того неустойчивую терминологию. В данном случае под оператором следует понимать именно statement, то есть речь идет об условных операторах, операторах цикла и т.п., а не о знаках арифметических операций и т.п. Потратить рабочий день на кодирование формулы из 10 слагаемых - это перебор даже для отлаженной программы

И в завершение - первая цитата, подвернувшаяся мне под руку:

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

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

(Фредерик БРУКС. Мифический человеко-месяц, или Как создаются программные системы).

Если кто не помнит, Брукс - это легендарная личность из не менее легендарной IBM, под руководством которого создавались операционные системы для (конечно же, вы не ошиблись, тоже легендарного)  семейства IBM 360/370. Как видим, если грубо прикинуть 200 рабочих дней в году, парни Брукса работают ровно вдвое медленнее приведенной мной цифры - 5 операторов в день. Впрочем, операционная система - штука серьезная, там есть над чем подумать.

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

[Alf]

P.S. Вот еще подвернулось, когда листал Брукса:

Данные Харра и OS/360 относятся к программированию на языке ассемблера. Есть немного публикаций относительно производительности системного программирования с использованием языков высокого уровня. Корбато (Corbato) из проекта MAC Массачусетского технологического института сообщает о средней производительности 1200 строк отлаженных операторов PL/I на человека в год при разработке операционной системы MULTICS (от 1 до 2 миллионов слов).

Добавления к изданию 1995 года (первое вышло в 1975):

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

8.6 По данным Арона из IBM, производительность труда лежит в пределах от 1,5 до 10 тысяч строк программы на человека в год в зависимости от количества взаимодействий между частями системы.

8.7 По данным Харра из Bell Labs, производительность труда при задаче типа разработки операционной системы составила около 0,6 тысяч строк кода на человека в год, а при разработке компиляторов — 2,2 тысячи для законченных продуктов.

8.8 Данные Брукса по OS/360 согласуются с данными Харра: 0,6-0,8 тысяч строк кода на человеко-год для операционных систем и 2-3 тысячи для компиляторов.

8.9 Данные Корбато по проекту МТИ MULTICS показывают, что производительность труда при разработке смеси операционной системы и компиляторов составила 1,2 тысяч строк кода на человека в год, но это строки кода PL/I, а остальные данные относятся к строкам кода ассемблера!

8.10 Производительность примерно постоянна в переводе на элементарные операторы.

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

[Люсь]

История о том, как я научилась быстро и слепо (не замечая ошибок, хехехе) печатать.

Началось это в школе, на уроках информатики.

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

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

Поэтому на новой работе, где у меня наконец-то появился компьютер, начала осваивать программку Соло на клавиатуре, скоро мне она жутко надоела - ну что такое, каждый урок сначала по 1 символу, потом по 2 попеременно - на 6 занятии бросила, пыталась пропечатать то, что находится в 20 и 40 уроке. Нафиг. (с) Многа букв, ниасилил ))

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

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

У меня всё.

[Алексей++]

а я так и не научился вслепую, хотя пытался (возможно плохо пытался) - ну не получается "глаза не видят, что руки делают"

[Люсь]

Леший, неправильную выбрал пословицу.
"Глаза боятся, а руки делают".

[Алексей++]

может и неправильно, но вслепую никак не выходит. Интересно - это лень или отклонение от нормы?

[Люсь]

это недостаток
а может наоборот - достоинство

да ты не переживай, у меня это тоже года 2-3 назад стало выявляться, что можно оказывается и не смотреть я даже сама не заметила, как это произошло

[Алексей++]

эксперимент:

"вь этдт ткслч я реснбвд лп гжядя"

)))))

это я написал:

вот этот текст я печатал не глядя

  хохотался...

[Люсь]

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

[Люсь]

Леший, знаешь, я вру - я ведь на экран гляжу, когда печатаю )) Только на клаву не смотрю Так что это полуслепой метод А  с закрытыми глазами я бы наверное тоже неуверенно печатала
Знаешь, печатать глядя на экран сильно помогает спасаться от уличения высшим начальством - чуть-что - ты наготове свернуть всё непотребное ))
а если глядеть на клаву, и тут начальство - ты вынужден тратить несколько лишних времён, чтобы перевести взгляд на экран, хватаясь за мышь, соориентироваться на экране и свернуть всё
если только у тебя не линукс

[Анна на шее]

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

Мне всё это жутко надоело

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

[Люсь]

Анна - это какие же? Те же самые, что и для сисадминов?
Если нечто новенькое - публикуй, чего таиться

[Гром]

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

[Alf]

Я думаю, нужно учитывать специфику приведенной статистики. Там приводятся данные для: 1) очень крупных проектов, 2) достаточно больших коллективов.

Чем больше проект, тем чаще приходится пересматривать уже написанное, подгонять новый код к ранее написанному, а иногда и ранее написанный - к новому, если чего-то не учел сразу. Брукс и другие считают только итоговый код. Если ты 10 раз переписывал заново модуль на 100 строк, ты написал не 1000 строк в итоге, а всего лишь 100, остальное - брак и в зачет не идет.

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

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

P.S. Взять цитату для ответа не удалось, к сожалению.

[Гром]

Alf - я как бы не буду настаивать.
Я работаю сейчас именно в таком вот крупном проекте и с заседаниями.
Вот пример:
система строкового поиска с помощью железяки. Чип (3 штуки) управление Альтера, мы - программный продукт, формирующий запросы на различный тип поиска, осуществление сложного набора поисковых фильтров (дерево фильтров) нахождение искомого в пакете (стрим сети все виды протоколов). Поиск включает в себя поиска с регулярными выражениями.
Пока поддерживается ин ордер поток, с ретрансмит пакетами.

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

Полновесный конечный автомат с решением данной задачи = 2 файла общей цифрой в 1500 строк.  Плюс интерфейсная функция в заданном, старой системой, формате (в качестве интеграции в старый код) длиной в 500 строк сложный тройной вложенный цикл с 4 уровнем по пакетам

Вся логика не уложится в описание, увы, но суть что 2000 полностью строк ,код,  где каждая строка = оператор практически (очень сжатый код пишу ) был написан и отлажен в течении 2 недель.
Считаем 5 * 8 = 40 * 2 = 80 рабочих часов.
2000/80 = 25 качественно отлаженных операторов в день

Кроме того - интересен тот факт, что параллельно за эти 2 недели отлавливалось еще два бага в общем коде.

Примечание:
при работе с проектом участвовало 2 программиста 4 начальника 3 заседания.
код писался до моего прихода 1 год и был уже готов (т.е. мне пришлось вписываться в чужой код).
колличество строк подсчитано без учета фигурных скобок и всякой порнографии....

[Alf]

2 недели и 2000 строк - это несколько не тот масштаб, о котором говорит Брукс. Тут как раз действует одна из его оговорок:

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

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

Мне кажется, причина невысоких (с точки зрения нас, спринтеров) показателей среди промышленных команд кроется еще и в различном подходе к процессу тестирования. Вот, например, передо мной лежит книга Гленформа Майерса "Искусство тестирования программ" (из того же золотого фонда, что и Брукс). Вот как она начинается:

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

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

Напишите на листе бумаги набор тестов (т.е. специальные последовательности данных), которые, как вам кажется, будут адекватно проверять эту программу.

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

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

[Анна на шее]

Buu, а я знаю методы борьбы с нерадивыми секретаршами

Анна - это какие же? Те же самые, что и для сисадминов?
Если нечто новенькое - публикуй, чего таиться

О, нашего полку плохих девченок прибыло!

Цитата Buu:

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

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

[Гром]

Alf я же написал

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

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

Это часть проекта многопроцессорной системы защиты реального времени. РАзмер порядка 200 000 строк то, что я видел.

[Alf]

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

У меня вот личный опыт не слишком расходится с Бруксом, к сожалению. По крайней мере сейчас. Дело выглядит примерно так. Несколько дней копаешься в связных стандартах (ISDN, OSS7, рекомендации CIT и тому подобное). Несколько дней разбираешься в тонкостях выбора маршрута при установлении телефонного соединения с учетом разнородной сети, поддерживающей одновременно несколько сигнализаций. Несколько дней нужно на изучение структур данных, в которых центральный процессор станции хранит таблицы маршрутизации. И, наконец, дело доходит до компьютерной модели - за пару дней накопленный материал воплощается в несколько сот строк кода, которые на третий день отлажены и подключены к модели.

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

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

[Гром]

Alf  - ну тут по моему ты спутал.
Если речь идет о вкладывании своего куска кода в чужой - то ни о каком исследовании и ТЗ речи не идет все готово давно.
Берешь продукт - день на прикидки алгоритма и в путь.
Далее делаешь по куче строк кода и дня два отлаживаешь базисный принцип. Максимум - 4 дня.

Далее - уже тонкая настройка всей системы, но там могут быть общие баги.

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



К примеру отладка сортировки с методом пузырька в институте, у меня занимала 2 дня в первый раз.
А сегодня написание блока сортировки занимает минут 30-40 с всей отладкой - которой в принципе нету