У меня правый win — переключене раскладки. Большой палец правой руки как раз почти на ней лежит, когда я не набираю текст, потому очень удобно начинать писать с любого языка. При этом указательный палец лежит на Enter, а мизинец и безымянный — над кнопками перемещения курсора.
Правый menu — консоль.
Левый win + 1..5, q..t, a..h, z..v — хоткеи, чтобы удобно было нажимать одной рукой.
Мой вывод из моего опыта работы за компьютером однозначен — переключение раскладки должно быть одной клавишей, если выполняется часто и должна отображаться индикацией на клавиатуре. Более того, любая частая операция должна происходить по нажатию одной кнопки — переключение в консоль, переключение раскладки, закрытие окна, открытие окна браузера, и так далее. Любые менее частые операции с окнами — переключение в нужное окно, сворачивание, разворачивание окна, переход в полноэкранный режим, перемещение окна по виртуальным рабочим столам и реальным мониторам, закрепление окна поверх других должны иметь комбинации клавиш. Привыкнуть к ним довольно просто, а отказ от «возюканья мышкой» при этих операциях экономит кучу времени.
Относительно windows могу сказать, что интерфейсы должны быть кастомизируемыми, чтобы претендовать на удобство, и хотя в windows такого и близко нет, но проблема частично решается установкой сторонних программ — например, в punto switcher можно настроить переключение раскладки по правому ctrl. Также есть некие nncron и HotKeybord, которые тоже кое-что умеют.
Совет к первому пункту, помельче ваших: удаляйте временные переменные после использования.
Временные переменные часто называют короткими именами. После чего они мешаются, например, в подсказках IDE и усложняют понимание, нужна ли эта переменная далее.
пример:
args, x, xx, defaults = inspect.getargsspec(method)
del x, xx
К сожалению, более-менее удобно хранить информацию в виде файловой системы в таком виде не получится — нет программных средств. Вместимость для JPEG-картинок — порядка 5%, таким образом на 1 гигабайт картинок можно получить 50 мегабайт защищённого хранилища — вполне неплохо, но информацию о распределении хранилища по реальным файлам и само средство работы с ним как с файловой системой тоже придётся куда-то спрятать, получая к нему доступ стандартными утилитами стеганографии. Теоретически-то это возможно, но кто бы на практике всё это запрограммировал?
У меня сначала загрузил процессор на полминуты, потом отпустил, а надпись «checking...» осталась. 30 минут подождал, но ничего он мне так и не показал. Попробовал ещё раз — то же самое. Javascript включен, tcpdump пишет, что сетевой активности, связанной с вебом, больше нет. Я один такой?
Такие вещи хорошо отправлять автору личным сообщением, а не вывешивать для всеобщего обозрения и чтения теми, к кому замечание не имеет никакого отношения.
А я уже бросил употреблять эту дурь пару лет назад. Сначала было тяжело, всё тянуло вернуться обратно, даже подумывал вступить в клуб анонимных PHP-шников и обратиться к доктору, а потом мне друг, который тоже страдал и излечился от PHP, принудил попробовать django и twisted, и как-то раз — и отпустило. Сейчас, когда встречаю где-то PHP, меня охватывает ужас и отвращение. Но до сих пор жалко тех, кто всё ещё использует эту дурь.
Не каждый же раз вручную запускать каждый кусочек, который нужно проверить. Впрочем, может я что-то не так понял?
Угу, это в примере было проще запустить тестирование именно так. А вообще доктесты (а именно так называются тесты из примера) прекрасно интегрируются в классические юнит-тесты. Сказал про минус доктестов, но забыл сказать про главный плюс — они являются ещё и документацией к функции, потому так и называются.
проще всего тестировать — как по мне, так прямо в IDE
С трудом понимаю… В смысле в IDE есть интерфейс для запуска конкретного теста, группы тестов? Или для создания тестов? Опишите, пожалуйста.
Не шаришь, это — ужасно неудобно! :)
На клавиатурах ЕС1841 было две клавиши со светодиодами с надписями «РУС» и «ЛАТ». Одна — слева, одна — справа, на месте современных «винкеев». При выборе одной из раскладок загорался соответствующий светодиод.
Итого:
— где зажжён светодиод, видно боковым зрением при слепом наборе
— видно прямым зрением при взгляде на клавиатуру
— раскладка переключается нажатием одной кнопки
— при желании переключиться на нужную раскладку не нужно задумываться о текущей
Немного реализует первые три плюса такое поведение Option «XkbOptions» «grp:rwin_toggle,grp_led:scroll» в X-сервере, четвёртое — мне мешает задействованность остальных клавиш для хоткеев.
Кстати, и в DOS-е были переключатели раскладки lat-rus — при отпускании левого-правого shift, при этом текущая раскладка отображалась цветом бордюра. Решение обладало примерно теми же преимуществами.
Переключение раскладки для меня — операция частая, потому за идею переключения ДВУМЯ кнопками её создателю нужно оторвать руки. Я никак не могу понять, почему это может быть кому-то удобно.
Вы не тратите время на обдумывание кода (все поведение обдумывается на этапе написания тестов, код пишется только, чтобы их выполнить)
Есть путь менее правильный, но более быстрый — тестирование осуществляется вручную с консоли, а потом результаты просто копи-пастятся в доктест. Это не даёт гибкости в том плане, что удобны лишь проверки на полное равенство вывода эталонному, но зато накладных расходов на написание таких тестов нет. Поясню примером:
Захотелось мне написать функцию для разложения числа на простые множители. Создаю файлик my.py со следующим кодом:
def f(x):
assert x > 1
i = 2
while i <= x:
if x % i == 0:
x /= i
yield i
else:
i += 1
Как проще и быстрее тестировать такое? Правильно, в консоли. Запускаю с тестовыми параметрами и смотрю результат:
>>> from my import f
>>> list(f(1))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "my.py", line 8, in f
assert x > 1
AssertionError
>>> list(f(3))
[3]
>>> list(f(4))
[2, 2]
>>> list(f(60))
[2, 2, 3, 5]
Визуально понимаю, что результат меня устраивает. Использую буфер обмена для помещения вывода в код как теста:
def f(x):
'''
>>> list(f(1))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "my.py", line 8, in f
assert x > 1
AssertionError
>>> list(f(3))
[3]
>>> list(f(4))
[2, 2]
>>> list(f(60))
[2, 2, 3, 5]
>>>
'''
assert x > 1
i = 2
while i <= x:
if x % i == 0:
x /= i
yield i
else:
i += 1
Теперь как-то надо уметь этот тест запускать. Простейший способ — добавить в конец файла немножко кода для вызова теста текущего модуля при загрузке этого модуля первым:
if __name__ == '__main__':
import doctest
doctest.testmod()
Запускаем: $ python my.py
$
Вывод пустой — всё в порядке.
Сэмулируем теперь ошибку логики, поправив тест:
$ python my.py
*******************
File "my.py", line 13, in __main__.f
Failed example:
list(f(60))
Expected:
[2, 2, 3, 6]
Got:
[2, 2, 3, 5]
*******************
1 items had failures:
1 of 4 in __main__.f
***Test Failed*** 1 failures.
Кто-то мог заметить, что в трэйсбэке исключения зашит номер строки — это мелочи, фрэймворк корректно обрабатывает их отличия от эталона в тесте.
Итого — тесты имеются, а накладных расходов — минимум.
В рамках одного проекта — или везде или нигде
Не соглашусь. В рамках большого проекта начать писать тесты на всё сразу — не хватит сил, не писать по-прежнему — неразумно, потому тесты пишутся на новый, изменившийся функционал и на обнаруженные ошибки. Через некоторое время можно не переживать о том, что значительная часть кода не покрыта тестами — значит, этот код относительно стабилен.
Вы меня опередили на минуту. Ещё замечу, что скобки здесь важны, без них условие -path '*/.svn/*' будет выполнено для файлов внутри директории .svn и в соответствии с правилами оптимизации логических выражений действие -delete уже не будет для них запущено.
find ищет по каким-то условиям и выполняет определённое действие с результатом поиска. Дело в том, что по умолчанию find делает -print, то есть выводит результат на стандартный вывод, разделяя имена переводом строки.
xargs читает со стандартного ввода записи, разделяя, их, среди прочего, и пробелами. Таким образом, если find найдёт файл с именем «раз два», то xargs запустит указанную команду с аргументами «раз» и «два». Нам нужно, чтобы find разделял записи разделителем, который не может присутствовать в именах файлов. Среди ext2/3 таких символов два — это нулевой символ (не имеет печатаемого обозначения) и символ прямого слэша. Прямой слэш, кажется, в некоторых файловых системах может являться частью имени файла, потому нам остаётся только нулевой символ.
Как сказано в мануале в первых строках по find: «you should probably consider using ‘-print0’ instead».
Действие -print0 заставляет find вывести на стандартный вывод результаты, разделяемые нулевым символом, а опция -0 у xargs заставляет в качестве разделителя записей принимать только нулевой символ.
В моём мане (это не сарказм, маны на разных системах бывают очень разные) есть такой пример для этого дела:
Символ перевода строки разрешён в большинстве файловых систем для linux, потому, строго говоря, разделение результатов поиска этим символом чревато. Не думаю, что это имеет большое для практики значение (если, конечно, вы не пишите вдруг CGI-скрипты), но второй способ абсолютно корректен и ничем не хуже первого.
Извини, у меня нет цензурных слов. За такое я отрываю разработчикам руки. Такой код в скриптах — это бомба замедленного действия, она срабатывает редко, но неожиданно и разрушительно. О grep-е после find-а и xargs rm вместо -delete уже говорили, но это можно попытаться оправдать тем, что примеры учебные и искуственные. А вот опасность этого примера оправдать нельзя!
Автор, создай у себя, для эксперимента директорию где-нибудь в темпе:
$ mkdir -p 'документы'/'.svn' 'документы на удаление'/'.svn'
В «документы» положи очень важные и ценные тебе документы. В «документы на удаление» — ерунду. А теперь выполни эту команду и сожалей, что директория «документы» исчезла. Не .svn в этой директории, а «документы» целиком!
Писать так — опасно, учить других писать так — во сто крат опасней! Читать маны перед написанием учебной статьи — напротив, не только неопасно, но и крайне полезно.
Я это не утверждал и не подразумевал. Я сказал именно то, что хотел — способов проникновения вредоносной программы на linux при работе обычного пользователя меньше.
Правый menu — консоль.
Левый win + 1..5, q..t, a..h, z..v — хоткеи, чтобы удобно было нажимать одной рукой.
Относительно windows могу сказать, что интерфейсы должны быть кастомизируемыми, чтобы претендовать на удобство, и хотя в windows такого и близко нет, но проблема частично решается установкой сторонних программ — например, в punto switcher можно настроить переключение раскладки по правому ctrl. Также есть некие nncron и HotKeybord, которые тоже кое-что умеют.
Временные переменные часто называют короткими именами. После чего они мешаются, например, в подсказках IDE и усложняют понимание, нужна ли эта переменная далее.
пример:
args, x, xx, defaults = inspect.getargsspec(method)
del x, xx
Угу, это в примере было проще запустить тестирование именно так. А вообще доктесты (а именно так называются тесты из примера) прекрасно интегрируются в классические юнит-тесты. Сказал про минус доктестов, но забыл сказать про главный плюс — они являются ещё и документацией к функции, потому так и называются.
С трудом понимаю… В смысле в IDE есть интерфейс для запуска конкретного теста, группы тестов? Или для создания тестов? Опишите, пожалуйста.
Не шаришь, это — ужасно неудобно! :)
На клавиатурах ЕС1841 было две клавиши со светодиодами с надписями «РУС» и «ЛАТ». Одна — слева, одна — справа, на месте современных «винкеев». При выборе одной из раскладок загорался соответствующий светодиод.
Итого:
— где зажжён светодиод, видно боковым зрением при слепом наборе
— видно прямым зрением при взгляде на клавиатуру
— раскладка переключается нажатием одной кнопки
— при желании переключиться на нужную раскладку не нужно задумываться о текущей
Немного реализует первые три плюса такое поведение Option «XkbOptions» «grp:rwin_toggle,grp_led:scroll» в X-сервере, четвёртое — мне мешает задействованность остальных клавиш для хоткеев.
Кстати, и в DOS-е были переключатели раскладки lat-rus — при отпускании левого-правого shift, при этом текущая раскладка отображалась цветом бордюра. Решение обладало примерно теми же преимуществами.
Переключение раскладки для меня — операция частая, потому за идею переключения ДВУМЯ кнопками её создателю нужно оторвать руки. Я никак не могу понять, почему это может быть кому-то удобно.
Есть путь менее правильный, но более быстрый — тестирование осуществляется вручную с консоли, а потом результаты просто копи-пастятся в доктест. Это не даёт гибкости в том плане, что удобны лишь проверки на полное равенство вывода эталонному, но зато накладных расходов на написание таких тестов нет. Поясню примером:
Захотелось мне написать функцию для разложения числа на простые множители. Создаю файлик my.py со следующим кодом:
def f(x): assert x > 1 i = 2 while i <= x: if x % i == 0: x /= i yield i else: i += 1Как проще и быстрее тестировать такое? Правильно, в консоли. Запускаю с тестовыми параметрами и смотрю результат:
>>> from my import f >>> list(f(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "my.py", line 8, in f assert x > 1 AssertionError >>> list(f(3)) [3] >>> list(f(4)) [2, 2] >>> list(f(60)) [2, 2, 3, 5]Визуально понимаю, что результат меня устраивает. Использую буфер обмена для помещения вывода в код как теста:
def f(x): ''' >>> list(f(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "my.py", line 8, in f assert x > 1 AssertionError >>> list(f(3)) [3] >>> list(f(4)) [2, 2] >>> list(f(60)) [2, 2, 3, 5] >>> ''' assert x > 1 i = 2 while i <= x: if x % i == 0: x /= i yield i else: i += 1Теперь как-то надо уметь этот тест запускать. Простейший способ — добавить в конец файла немножко кода для вызова теста текущего модуля при загрузке этого модуля первым:
if __name__ == '__main__': import doctest doctest.testmod()Запускаем:
$ python my.py
$
Вывод пустой — всё в порядке.
Сэмулируем теперь ошибку логики, поправив тест:
$ python my.py ******************* File "my.py", line 13, in __main__.f Failed example: list(f(60)) Expected: [2, 2, 3, 6] Got: [2, 2, 3, 5] ******************* 1 items had failures: 1 of 4 in __main__.f ***Test Failed*** 1 failures.Кто-то мог заметить, что в трэйсбэке исключения зашит номер строки — это мелочи, фрэймворк корректно обрабатывает их отличия от эталона в тесте.
Итого — тесты имеются, а накладных расходов — минимум.
Не соглашусь. В рамках большого проекта начать писать тесты на всё сразу — не хватит сил, не писать по-прежнему — неразумно, потому тесты пишутся на новый, изменившийся функционал и на обнаруженные ошибки. Через некоторое время можно не переживать о том, что значительная часть кода не покрыта тестами — значит, этот код относительно стабилен.
xargs читает со стандартного ввода записи, разделяя, их, среди прочего, и пробелами. Таким образом, если find найдёт файл с именем «раз два», то xargs запустит указанную команду с аргументами «раз» и «два». Нам нужно, чтобы find разделял записи разделителем, который не может присутствовать в именах файлов. Среди ext2/3 таких символов два — это нулевой символ (не имеет печатаемого обозначения) и символ прямого слэша. Прямой слэш, кажется, в некоторых файловых системах может являться частью имени файла, потому нам остаётся только нулевой символ.
Как сказано в мануале в первых строках по find: «you should probably consider using ‘-print0’ instead».
Действие -print0 заставляет find вывести на стандартный вывод результаты, разделяемые нулевым символом, а опция -0 у xargs заставляет в качестве разделителя записей принимать только нулевой символ.
В моём мане (это не сарказм, маны на разных системах бывают очень разные) есть такой пример для этого дела:
Что касается возможности запуска без xargs — для скриптов я бы посоветовал такую конструкцию:
Для применения вручную, после запуска без -delete и изучения списка:
При этом, файлы и директории типа .svnlalala тоже будут уничтожены, если присутствуют.
Извини, у меня нет цензурных слов. За такое я отрываю разработчикам руки. Такой код в скриптах — это бомба замедленного действия, она срабатывает редко, но неожиданно и разрушительно. О grep-е после find-а и xargs rm вместо -delete уже говорили, но это можно попытаться оправдать тем, что примеры учебные и искуственные. А вот опасность этого примера оправдать нельзя!
Автор, создай у себя, для эксперимента директорию где-нибудь в темпе:
В «документы» положи очень важные и ценные тебе документы. В «документы на удаление» — ерунду. А теперь выполни эту команду и сожалей, что директория «документы» исчезла. Не .svn в этой директории, а «документы» целиком!
Писать так — опасно, учить других писать так — во сто крат опасней! Читать маны перед написанием учебной статьи — напротив, не только неопасно, но и крайне полезно.
rdesktop -g1014x716 -k en-us -n home-06 ip.add.ress.here