Хотел было отписать незаметненько автору в личку, какие ошибки нужно поправить, но что-то их уж очень много. В процессе подготовки письма с исправлениями мозг вскипел и уважения к автору, как носителю русского языка, изрядно поубавилось.
В итоге, плюнул, не дописал, думается, что, если уж был выброшен настолько сырой текст, то и эффект от личной переписки будет нулевой. Утвердился во мнении, что полезнее будет обнародовать, привожу незаконченное письмо ниже (жалко труды выкидывать).
Уважаемые хабровчане, давайте писать грамотно, ну или хотя бы проверять свои тексты с помощью средств текстовых редакторов!
Прошу прощения, может быть, за излишнюю педантичность, но в достаточно неплохом обзоре орфографические ошибки сильно режут глаз.
Если не трудно, запаситесь терпением и исправьте, пожалуйста, найденные мной ошибки в вашей статье. Уверен, что это поможет сделать Хабр лучше =)
… для бессплатных акаунтов а для платных ...
правильно:
"… для бесплатных аккаунтов, а для платных ..."
… до 50GB, но придеться заплатить…
правильно:
"… до 50GB, но придется заплатить… " проверка: Что сделает? — вопрос без мягкого знака
… но для большенства ...
правильно:
"… но для большинства ..."
После отсылки к скриншотам неплохо поставить двоеточие:
"… вот скриншоты программы: ..."
"… Тут можно поменять расположение папки синхронизации: ..."
Как мы видим программа не чем не премечательна, но в этом есть и болшой плюс
правильно:
«Как мы видим, программа ничем не примечательна, но в этом есть и есть большой плюс»
У вас создаеться папка <… > И там появляються…
правильно:
«У вас создается папка <… > И там появляются… „
Да очень просто, способа есть 2
1 — для обычного пользователя и 2 — гиковский
1 — просто переносим что намнужно синхронизировать в папку дропбокса
правильнее:
“Да очень просто, способа есть два: первый для обычного пользователя и второй — гиковский.
1) просто переносим что нам нужно синхронизировать в папку дропбокса
2) ...»
они автоматически загружаються на сервис
правильно:
«они автоматически загружаються на сервис»
На самом деле не самое очевидное и логичное решение))) По-моему, такие извраты запутывают код и притянуты за уши, то есть не вытекают из требований к функционалу системы.
На ум приходит доработать напильником для корректной работы с unicode-строками плагин.
Мне одному кажется заголовок излишне кричащим, и чуть ли не желтым, мало соответствующим содержанию?
По сути, автор только заглянул в настройки и попробовал убрать галочку, которая там просто установлена по умолчанию. Уведомление о новых версиях всплывающим окном — не ахти какая вредная и порочная функция, встроенная, к тому же, в большинство современных развивающихся и активно поддерживаемых проектов.
За статью спасибо, взял на заметку. Имена wiki-страниц изначально создавал только латиницей, поэтому пока проблемы не стояло. Есть мысль, что и в других плагинах может быть аналогичный глюк.
Пожалуйста, поправьте заголовок, у вас «плгин» вместо «плагина».
Прошу прощения, но «…вопрос лишь в том, как убедить пользователей пользоваться клавишей Tab.» — это не вопрос, а утверждение.
Вопрос у вас задан вполне конкретный: «Так, может быть, дать возможность пользователям самим определять последовательность обхода полей по клавише Tab?»
И без вашего комментария, на что именно обращать внимание (спасибо за уточнение), сильно хочется ответить «Да, дать возможность» или «Нет, ни в коем случае», а не предложить способ мотивации юзеров.
В институте нас уважаемая, если не лучшая, преподавательница, но старой закалки, указкой по пальцам лупила, если за мышь брались =)
Как вариант вижу не отрабатывать какую-нибудь малозначительную(?) часть интерфейса, например не подсвечивать редактируемое поле, если фокус на него был установлен мышью.
Возможны и более радикальные вариации, как то:
— изредка попапом вываливать «полезный» совет «Знаете ли вы, что жить станет удобнее и проще, если пользовать Tab?»
— при выборе значения из выпадающего списка фиксировать это значение в поле, только если нажат Tab/Enter, и т.д.
Со своими пользователями я пошел на компромисс — у них привычка вместо Tab нажимать на Enter. Решил, пусть пользуются Enter'ом, но переход на предыдущее поле — только по Shift+Tab.
На симуляторе сильно хочется, чтобы ноги на полноценные педали руля направления давили, желательно педали ВКБ… Только цены на них никак не меньше этой вот мыши. А для обзора лучшее уже придумано — TrackIR.
Думал, что уникален, время от времени проверял поисковиками, где встречаюсь. Оказалось, кто-то попользовал мое имя и в нелучшей форме =( Либо я чего-то не помню из своей жизни…
Что-то мне подсказывает, что особо сложную технику не дадут =( Уверен, Лено-Енисейский канал копать будем лопатами, силами торрент-заключенных… Ну а квалифицированный тоже невостребованным не останется — ТрансСибКолымаОптику проложить там… Инфраструктура…
Глобальные жесты на замену глобальным хоткеям? Интересная, должно быть, мысль =) Сейчас глобальными хоткеями пока только треки Winampa переключаю, да раскладку в ручном режиме PS… Надо попробовать подирижировать винампом))))
Нигде больше кроме оперы не видел реализацию фишки «Разместить по ширине страницы» — убирает горизонтальный скроллбар. В аддонсах для ФФ, помнится, сколь ни бился — не нашел =( Давно дело было, может кто знает, появилось что-нибудь похожее?
Почитать в электронном варианте, присмотреться к содержанию получится только в случае с относительно давно изданной книгой. Где вы найдете текст по неделю назад вышедшей новой версии фотошопа?
Огорчает еще то, что качественно переведенное издание выходит с изрядным временным лагом после выхода оригинала, а чаще уже и после всеобщего признания книги, и переиздания этого самого оригинала за границей.
Ну все-таки не «отменить коммит», а вернуться к прежней правке ;)
> Особенно радует, что изменения в текущей ветке оказались утеряны.
Еще раз… Никакие изменения не теряются. Все что вы редактируете, мержите (проводите слияние веток) — эти операции выполняются в вашей рабочей копии проекта. В любой момент времени с помощью svn status, svn diff вы можете с точностью до замененного символа просмотреть, чем отличается ваша раб. копия от крайней HEAD или любой другой правки в хранилище.
Смысл слияния, вроде, прозрачен и понятен всем — например, объединить изменения кода, накопленные во временных ветках, разрабатываемых разными программистами в одну главную ветку, из которой будет собран релиз. Но почему-то, наткнувшись, на проблемы, подобные сабжу, забывается, что команда svn merge — это всего лишь инструмент, помогающий провести объединение кода из разных мест наиболее быстрым образом, поскольку эта команда старается отслеживать всю историю изменений в указанном для слияния диапазоне правок. Конечное слово перед коммитом остается за программистом.
Наивно предполагать, что коммит получится провести сразу после выполнения svn merge, скорее всего, часть файлов войдет в конфликтующее состояние, требующее обязательного «ручного» анализа с принятием/удалением/редактированием своих/чужих вариантов отдельных строк кода, которые в спорных случаях довольно удобным образом помечаются, плюс рядышком в рабочей копии merge подкладывает пару файликов .left, .right с содержимым, взятым из «левой» и «правой» сравниваемых версий соответственно.
Задача сводится к устранению конфликтов в нескольких файлах после merge или update, а не поиску и перепроверке всех измененных мест в проекте.
Автор статьи указал случай, за что ему огромное спасибо (взял на заметку), когда такого конфликта SVN не подсказывает, и теперь на переименования файлов в проекте буду обращать отдельное внимание.
К сожалению, не настолько силен, чтобы дописать какой-нибудь триггер на переименование файлов для отслеживания таких граблей, но статья определенно пошла на пользу.
Системы контроля версий как раз и позволяют вам иметь полный бэкап кода за любую дату и в любой ветке разработки. Плюс в помощь предоставляется автоматическое сравнение правок с подсветкой различий между ними и лог коммитов-сохранений с вашими комментариями, по желанию подробными, также привязываемыми к каждой правке.
Присмотритесь попристальней, поймете, что это благо.
P.S. А архивчики с бэкапами проекта вы наверное датами нумеруете?
«они автоматически загружаются на сервис»
иерархии
В итоге, плюнул, не дописал, думается, что, если уж был выброшен настолько сырой текст, то и эффект от личной переписки будет нулевой. Утвердился во мнении, что полезнее будет обнародовать, привожу незаконченное письмо ниже (жалко труды выкидывать).
Уважаемые хабровчане, давайте писать грамотно, ну или хотя бы проверять свои тексты с помощью средств текстовых редакторов!
Прошу прощения, может быть, за излишнюю педантичность, но в достаточно неплохом обзоре орфографические ошибки сильно режут глаз.
Если не трудно, запаситесь терпением и исправьте, пожалуйста, найденные мной ошибки в вашей статье. Уверен, что это поможет сделать Хабр лучше =)
правильно:
"… для бесплатных аккаунтов, а для платных ..."
правильно:
"… до 50GB, но придется заплатить… " проверка: Что сделает? — вопрос без мягкого знака
правильно:
"… но для большинства ..."
После отсылки к скриншотам неплохо поставить двоеточие:
"… вот скриншоты программы: ..."
"… Тут можно поменять расположение папки синхронизации: ..."
правильно:
«Как мы видим, программа ничем не примечательна, но в этом
естьи есть большой плюс»правильно:
«У вас создается папка <… > И там появляются… „
правильнее:
“Да очень просто, способа есть два: первый для обычного пользователя и второй — гиковский.
1) просто переносим что нам нужно синхронизировать в папку дропбокса
2) ...»
правильно:
«они автоматически загружаються на сервис»
правильно:
«функции просмотра иреархии изменений»
— это вообще что имелось в виду?
правильно:
«Заметили на скриншоте пункт»
…
На ум приходит доработать напильником для корректной работы с unicode-строками плагин.
По сути, автор только заглянул в настройки и попробовал убрать галочку, которая там просто установлена по умолчанию. Уведомление о новых версиях всплывающим окном — не ахти какая вредная и порочная функция, встроенная, к тому же, в большинство современных развивающихся и активно поддерживаемых проектов.
Пожалуйста, поправьте заголовок, у вас «плгин» вместо «плагина».
Вопрос у вас задан вполне конкретный: «Так, может быть, дать возможность пользователям самим определять последовательность обхода полей по клавише Tab?»
И без вашего комментария, на что именно обращать внимание (спасибо за уточнение), сильно хочется ответить «Да, дать возможность» или «Нет, ни в коем случае», а не предложить способ мотивации юзеров.
В институте нас уважаемая, если не лучшая, преподавательница, но старой закалки, указкой по пальцам лупила, если за мышь брались =)
Как вариант вижу не отрабатывать какую-нибудь малозначительную(?) часть интерфейса, например не подсвечивать редактируемое поле, если фокус на него был установлен мышью.
Возможны и более радикальные вариации, как то:
— изредка попапом вываливать «полезный» совет «Знаете ли вы, что жить станет удобнее и проще, если пользовать Tab?»
— при выборе значения из выпадающего списка фиксировать это значение в поле, только если нажат Tab/Enter, и т.д.
Со своими пользователями я пошел на компромисс — у них привычка вместо Tab нажимать на Enter. Решил, пусть пользуются Enter'ом, но переход на предыдущее поле — только по Shift+Tab.
Стильные одинаковые костюмчики IBM-служащих мне напомнили раскопировавшегося по матрице агента Смита.
Нет фоновой музыке на веб-страницах!
Да качественному midi в кейгенах!
Огорчает еще то, что качественно переведенное издание выходит с изрядным временным лагом после выхода оригинала, а чаще уже и после всеобщего признания книги, и переиздания этого самого оригинала за границей.
> Особенно радует, что изменения в текущей ветке оказались утеряны.
Еще раз… Никакие изменения не теряются. Все что вы редактируете, мержите (проводите слияние веток) — эти операции выполняются в вашей рабочей копии проекта. В любой момент времени с помощью svn status, svn diff вы можете с точностью до замененного символа просмотреть, чем отличается ваша раб. копия от крайней HEAD или любой другой правки в хранилище.
Смысл слияния, вроде, прозрачен и понятен всем — например, объединить изменения кода, накопленные во временных ветках, разрабатываемых разными программистами в одну главную ветку, из которой будет собран релиз. Но почему-то, наткнувшись, на проблемы, подобные сабжу, забывается, что команда svn merge — это всего лишь инструмент, помогающий провести объединение кода из разных мест наиболее быстрым образом, поскольку эта команда старается отслеживать всю историю изменений в указанном для слияния диапазоне правок. Конечное слово перед коммитом остается за программистом.
Наивно предполагать, что коммит получится провести сразу после выполнения svn merge, скорее всего, часть файлов войдет в конфликтующее состояние, требующее обязательного «ручного» анализа с принятием/удалением/редактированием своих/чужих вариантов отдельных строк кода, которые в спорных случаях довольно удобным образом помечаются, плюс рядышком в рабочей копии merge подкладывает пару файликов .left, .right с содержимым, взятым из «левой» и «правой» сравниваемых версий соответственно.
Задача сводится к устранению конфликтов в нескольких файлах после merge или update, а не поиску и перепроверке всех измененных мест в проекте.
Автор статьи указал случай, за что ему огромное спасибо (взял на заметку), когда такого конфликта SVN не подсказывает, и теперь на переименования файлов в проекте буду обращать отдельное внимание.
К сожалению, не настолько силен, чтобы дописать какой-нибудь триггер на переименование файлов для отслеживания таких граблей, но статья определенно пошла на пользу.
Присмотритесь попристальней, поймете, что это благо.
P.S. А архивчики с бэкапами проекта вы наверное датами нумеруете?