А с какой скоростью печатает ЛОРовец?

подписываюсь под каждым словом

Стенографисты печатают под 800, если не ошибаюсь.

354.

http://pic4a.ru/iIzz/

Не знаю, не мерил. И нужды в этом не вижу.

Я аккорды на рояле лабаю))

А так у меня на английском около 70 слов в минуту и около 75 на русском. Лёжа за лаптопом на кровати перед сном.

слов 49, знаков 244

На русском все умеют. Предлагаю вытащить и померяться http://10fastfingers.com/typing-test/japanese

Знаки 204

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

А вы тут на какой раскладке вообще меряетесь? На русской или на английской?

Русская

Слов в минуту (СВМ) 44
Знаки 283
(219 | 64)
Правильные слова 42
Неправильные слова 12
You are better than 65.25% of all users (position 800 of 2302 - last 24 hours)

378 с первой попытки, но несколько раз отвлекался на принцип работы этой штуки (например, опечатался, хотел исправить, но уже нажал пробел - в таком случае исправить нельзя)

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

http://susepaste.org/17652266

Слов в минуту (СВМ) 64 Знаки 344

Слов в минуту 71
Знаки 362

Русский? Я хоть и печатаю вслепую на русском, но делаю это крайне редко. Код, консоль, url, поисковый запрос... Везде английский. Даже пробовать не буду. Наверно поэтому я русский дворак не осилил (:

А как же ЛОР, форумы и чатики?

Мой результат: 499

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

- А сколько знаков вы набираете в минуту?

- 1200

- а как это получается?

- незнаю как это получается - но получается полная фигня...

Я например думаю когда набираю, перечитываю. Не всегда все очепятки нахожу (виноват)...

499 - это анекдоты по памяти набирать или мысли с параллельным продумыванием и перечитываением? :)

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

Это тоеть по схеме: вижу слово - пишу слово?

Надеюсь обычно лоровцы в начале думаю - потом пишут, потом читают написанное и опять думают :)

вижу слово - пишу слово

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

Может быть у тебя своеобразный талант? :)

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

если печатаешь 1 слово в минуту, то выбросить страницу кода, чтобы переписать его по-новому, более лучше, будет казаться недопустимым расточительством. А выбросить эту страницу 10 раз...

особенно забавно смотреть, когда в refactoring-driven development (в смысле, TDD) приходит чел, который медленно печатает. Там ведь нужно постоянно рефакторить - значит каждую минуту выбрасывать какой-то код. Получается изощрённая такая пытка.

RU

Слов в минуту (СВМ) 80
Знаки 408
(401 | 7)
Правильные слова 74
Неправильные слова 1
You are better than 95.16% of all users (position 103 of 2127 - last 24 hours)

EN

Слов в минуту (СВМ) 68
Знаки 340
(340 | 0)
Правильные слова 65
Неправильные слова 0
You are better than 86.91% of all users (position 20415 of 156000 - last 24 hours)

кстати да, набираю сейчас вместо привычной microsoft natural на обычной доске от BTC, все кнопки совершенно не там где надо, приходилось перепечатывать слова заново

А выбросить эту страницу 10 раз...

Наверное я не правильно понимаю значение слова рефакторинг.

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

У меня обычно это 2 раза написать какой-то класс или функцию:

первый раз, чтобы он просто заработал (или если он нужен на вчера)

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

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

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

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

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

В остальных компаниях, что я работал, такого безапеляционно небыло.

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

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

Слишко долго писать об выигрышах полученных в целом.

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

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

Почему мне дали возможность порефакторить эту штуку и разрешили на это потратить столько времени - это отдельный вопрос и могу ответить если интересно.

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

Из вашего поста у меня сложилось жуткое представление, о вашем понимании сути рефакторинга.

Расскажите мне ваше представление этого процесса.

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

Но предлагаю тебе пойти, и еще раз прочитать, что такое TDD. Например, на Википедии: https://ru.wikipedia.org/wiki/Разработка_через_тестирование

Или прочитать книжки Кента Бека: http://www.ozon.ru/context/detail/id/1501671/

На каждую новую фичу вначале всегда создаётся новый тест.

На каждую чертову фичу, даже мелкую. Хочешь чтобы функция принимала не только int, но и double? Напиши тест.

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

При починке этого кода, упадут другие тесты. Придётся его переписывать, чтобы тесты перестали падать.

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

Когда ты изменишь тесты, упадёт еще больше кода, и его тоже нужно переписать.

Таким образом, в рамках TDD, переписывание кода занимает значительную часть времени.

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

И отлично! Архитектура не нужна. Архитектура получается автоматически, в ходе переписывания кода под тесты.

Архитектура получается автоматически, в ходе переписывания кода под тесты

Я знаю что такое тесты.

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

откда возьмётся сотни классов (те первые сотни, которые потом рефакторить)

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

Конечно же она нужна - архитектура.

откда возьмётся сотни классов

ниоткуда. незачем им браться.

А не про случай создания с нуля нового проекта.

например, ты создаешь новое веб-приложение

создаешь новый пустой проект в IDE

идёшь в тесты и создаешь новый тест:

String requestURL = "/home";
String desiredResponse = "Hello Web App";
String actualResponse = HTTPClient.get(requestURL);
assertEquals (desiredResponse, actualResponse)

Вот и первый тест. Конечно, он не скомпилируется. Значит надо чинить код.

Вначале, IDE красеньким напишет, что не знает что такое assertEquals. Чтобы починить это, надо пойти в pom.xml или еще куда, и добавить библиотеку JUnit.

Теперь красеньким отображается HTTPClient, потому что такого класса нету вообще. Пойдем создадим его.

Теперь красеньким отображается, что у HTTPClient нет метода get, Создадим пустой метод (возвращающий пустую строку).

Теперь тест компилируется, но выдаёт ошибку. Наша реализация get какая-то неправильная. Время рефакторинга!

Первый рефакторинг - пусть метод просто возвращает строку «Hello Web App». Теперь тест выполняется ОК.

Теперь я хочу новую фичу:

String requestURL = "/home/username/Serg_HIS";
String desiredResponse = "Hello Serg_HIS";
String actualResponse = HTTPClient.get(requestURL);
assertEquals (desiredResponse, actualResponse)

Тест тут же упадёт. Значит настало время рефакторинга! Идём в метод get и, например, добавляем туда парсинг URL.

Ну и так далее, и тому подобное. Тест-рефакторинг-тест-рефакторинг-тест-рефакторинг, и так до бесконечности.

Буквально через пару тестов мы приходим к необходимости прикрутить какой-нибудь http-сервер. Например, тест читающий HTTP-заголовки. Самым простым решением будет пойти в pom.xml и добавить туда какой-нибудь сервер типа Jetty, который уже всё это умеет.

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

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

Дальше читай уже сам про TDD, XP, Agile, итп. Накладно на лоре длинные объяснения писать в рабочее время xD

Печатаю достаточно быстро, одна буква за одно нажатие клавиши.

Реквестирую нотариально заверенный скриншот.

Тест синтетический какой-то. Слова не связаны, нет знаков препинания и заглавных букв. А так, у меня где-то 400 знаков в минуту было.

http://klavogonki.ru/u/#/139852/

например, ты создаешь новое веб-приложение

Гм...

Это прекарсно конечно.

А что за приложение, что оно будет делать?

На какую нагрузгу расчитано?

Какие объямы данных должно мочь хранить?

упадёт еще больше кода, и его тоже нужно переписать

Это случай именно качающийся хреновой архитектуры

Добавляешь оду фичу и всё сыпется...

Я бы сразу уволился из такой конторы.

А что за приложение, что оно будет делать?

именно это и описывается тестами. Берешь спецификацию (если она вообще есть - обычно нет), и последовательно превращаешь её в тесты на языке программирования. То, что все тесты проходят - значит, что все фичи реализованы.

важно, что tdd-тесты не показывают покрытие в смысле качества (качеством занимаются qa-шники), они прежде всего показывают покрытие спецификации и являются скелетом для проверки что система пережила очередной рефакторинг

в каком-то смысле тесты и есть архитектура.

На какую нагрузгу расчитано?
Какие объямы данных должно мочь хранить?

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

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

Добавляешь оду фичу и всё сыпется...

сыпется не всё, а тесты. А тесты - это инструмент, точно показывающий что и в каком месте надо исправить.

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

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

не любят TDD только всякие «архитекторы», которые с таким подходом не нужны вообще. Их увольняют, вот они и не любят бгг

У тебя за плечами сколько проектов?

А то помоему ты пишешь ерунду.

Если ты пишешь сайт визитку на 10 посещений в день без БД и т.п.

Описанный тобой метод прокатывает.

Не вопрос - пускай описывается тестами.

Но перед тем как их писать - есть цель проекта.

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

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

Не мудри сильно.

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

Но перед тем как их писать - есть цель проекта.

«Идея на минус миллион»: https://www.artlebedev.ru/kovodstvo/sections/161/
«Метод прогрессивного джипега»: https://www.artlebedev.ru/kovodstvo/sections/167/

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

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

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

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

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

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

Если тебе нужно авторитетов, читай про TDD, Extreme Programming, Agile итп. Слишком большая тема, что ответить одним постом.

Надо тренироваться: http://10fastfingers.com/speedtests/generate_screenshot_result/26_55_278_0_0_46_1_80.41_401_2047

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

Если тебе нужно авторитетов, читай про TDD

Поянтно всё с тобой.

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

Ты наверное Юрист, а не программер? :)

Хватаешься за «высокопроизводительные ....».

Лишь бы ничего не написать конкретного в тему вопроса про архитектуру.

Причём тут инвесторы?

каким членом они связаны с архиектрурой и тестами?

троль 80 уровня вобщем :)

Поэтому важен «метод прогрессивного джипега»

Сам то понял что написал?

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

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

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

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

каждое новое приложение делает что-то новое. Что тут можно сказать?

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

«архитекторы» при таком раскладе склонны быстро сходить с ума xD Каждая новая фича, каждый новый тест, разваливают «архитектуру» к чертям собачьим

кстати, цель проекта может меняться 7 раз в неделю

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

Будь и дальше таким - инвесторы таких любят.

http://img.10fastfingers.com/badge/typing-test_26_AY.png

Форумы и чатики тоже забугорные. А на ЛОР я чаще с телефона пишу (:

22 слова в минуту.
111 символов в минуту.
Без ошибок.
Это одним пальцем.
В 10 пальцев - раза в три по-шустрее будет, если не больше.
Только умное так быстро писать не будешь.