Странноватая, честно говоря, изначальная формулировка. Я, общаясь с некоторыми заведомо людьми, притом вида Homo Sapiens, не в состоянии определить, с человеком я говорю или с компьютером. Кто из нас в этой ситуации [не] проходит указанный тест?
Дико извиняюсь. Консоль вообще-то не нарушает принципа черного ящика. Как там что работает для меня до сих пор загадка. А консолью пользуюсь профессионально.
Дело скорее в том, что глубокие знания о консоли можно получить в основном академическим путем (чтение и изучение чужого опыта). А GUI гораздо лучше поддается эмпирическому изучению (метод проб и ошибок, личный опыт, случайные находки). При всем при этом у двух методов взаимодействия с компом еще и существенно различаются, так сказать, правила использования. Это как выяснять что круче круче — бор-машинка или пассатижи. Разные вещи, по разному применяются.
В итоге GUI и консоль — два разных религиозных течения. Фотошопщику обработать тысячу картинок с помощью ImageMagick — всё равно что головоломку разобрать вслепую и с отрубленными пальцами. Мастер консоли глупо хлопает глазами, глядя на мой файловый менеджер, и совершает миллион ненужных кликов (хотя задача решается двумя). Не факт при этом, что фотошопщик не знает и не учитывает внутренних приниципов и заморочек фотошопа, или что консолист четко представляет себе, что именно происходит при копировании файла.
Как и во многих вещах в жизни, дело не в них самих — дело в нас, нашем отношении.
Покуда вы не установите настоящую Helvetica. Хотя под виндой и не в фотошопе/safari действительно сложно увидеть разницу между ними двумя. А у них между прочем даже формы некоторых букв различаются. Впрочем, даже на наших беззаконных просторах добыть вменяемую кириллическую версию Helvetica крайне сложно, и очень много любитеьских поделок на эту тему распространено — увидите, расхотите Helvetica пользоваться вообще. А это, меж тем, один из самых старых шрифтов без засечек, уважаемый дизайнерами и весьма развитый. И дорогой потому.
Настроить сглаживание. Установить все шрифты которые вам нужны (вы ж с винды переходите, оттуда и заберите — сильно сомневаюсь что в российских реалиях сотрудники ораганов станут докапываться до лицензий шрифтов).
Я линукс именно за то и люблю, что у меня в нем шрифты выглядят многократно лучше, чем в Windows. Actually, дело привычки, ибо MS в деле сглаживания экранных шрифтов никак не могло не пойти своим путем и не изобрести что-то патентованное (и сомнительной пользы). Шрифты в других осях именно поэтому никогда не будут выглядеть точно так же как в Windows. Arial, к примеру, в Linux отобразится совсем иначе (в моих настройках — получается наиболее похоже на печатный вариант, и как же мне в этом виде нравится «скучный» Arial — он реально красив, хотя Helvetica еще красивее).
Tahoma и Verdana в в Windows — совершенно особая песня, вид, которого вы вряд ли добъетесь где либо еще. И всё потому же. Вся фишка в том, что большинство систем сглаживания пытаются просто компенсировать низкое разрешение экрана разными ухищрениями, а у MS кривые, составляющие фигуру буквы, особым образом изменяются, чтобы больше соответствовать пиксельной сетке. Создатели шрифтов должны определять правила, согласно которым это происходит — правила, которыми сам MS, понятно, владеет лучше всего, потому шрифты, адаптированные им под собственную же технологию, выглядят лучше чем множество бесплатных или дизайнерских вариантов. Характерно, что, например, Adobe Photoshop не пытается пользоваться этой технологией, а предлагает дизайнеру 4 варианта. Потому-то и бьются головой о монитор HTML-верстальщики по всей Руси-матушке — не выйдет шрифтовая работа в браузере точно так же как на макете, равно как на самолете нельзя гоняться в формуле-1. Разные технологии — разный результат.
И по-моему, в последних релизах Kubuntu сглаживание уже вкл по умолчанию. Хотя не знаю, может я его сам уже левой ногой не думая включаю…
Меня всегда тем более удивляло это упражнение, что для меня оно срабатывает несколько необычным образом — оба крестика я вижу всегда, но если замереть и не шевелиться несколько секунд (даже глазами не двигать, что сложно на самом деле), то крестик на периферии поля зрения пропадает вне зависимости от расстояния до монитора. Стоить совершить малейшее движение — пропавший объект вновь появляется. В школе так забавлялся с тетрадкой в клеточку — заставлял «пропадать» саму клеточку, кроме 4-8 ячеек в центре поля зрения.
Еще момент: вчера всплывала статья про jQuery, хотел откомментить там, но хабр коммент сожрал.
Итак: кэшируя jQ-объект в переменную, именуйте ее с помощью $ в начале. То есть:
$a = $('a')
«Лишний» байт на самом деле сугубо повысит читаемость/разбираемось вашего кода для сторонних программистов (или вы гарантируете, что через год поможете модифицировать скрипт?). Особенно важно в обработчиках событий:
$('#myid').bind('click', function(){ // когда делаем обработчик события
var $this = $(this) // оборачиваем DOM-объект, на котором всплыло событие, в jQuery
})
Не понадобится обертка вокруг this — всегда можно удалить одну строчку. Но лично у меня уже стало паттерном, руки сами набирают, пока голова думает над деталями обработки события.
И еще. Бывает, глубоко в цепочке из многих .find() вдруг оказывается позарез нужна текущая jQuery-выборка в виде переменной. Понятное дело, не разорвав красивой цепочки, такую переменную не родишь ниоткуда. Заново повторять выборку ради своих действий тоже накладно. Для такого дела я когда-то написал простенький плагин: plugins.jquery.com/project/jquery_apply. Посреди цепочки можно вызвать .apply(function(){}), где внутри функции текущая jQuery-выборка доступна в форме this.
Про .noconflict(): стоит упомянуть, что с момента употребления этой функции объект $ возвращается в первоначально определенное состояние. То есть, по-русски, если сначала вы загрузили Prototype, a потом jQuery, jQuery.noconflict() снова сделает объект $ прототиповской функцией. Это не всегда может быть удобно для дополнительного «навешивания» скриптов, полагающихся на jQuery в форме $. Посему (и не только поэтому), свои jQ-скрипты стоит писать следующим образом: // начинаем файл нашего скрипта
(function($) // анонимная функция-обертка с параметром
{
$(".mystuff").do(things) // наши jQuery-выкрутасы, за состояние $ можно не бояться
}
)(jQuery) // и вот почему :)
// заканчиваем файл нашего скрипта
Первой и последней строчками мы оборачиваем наш скрипт в анонимную функцию, принимающую параметр $. В последней строке мы вызываем только что созданную функцию и в качестве этого параметра передаем объект jQuery. В итоге .noconflict() нам не страшен (его и можно, кстати, употребить в первой строчке нашего скрипта, перед объявлением функции). Заодно работа скрипта внутри анонимной функции, вызываемой немедленно после создания, не оставит после себя мусора в виде локальных переменных — если их объявлять с ключевым словом var, они исчезнут из памяти сразу после исчезновения контекста функции (то есть в простейших случаях сразу после окончания ее работы, в случаях замыканий при обработке событий — после снятия обработчиков событий). Практическая польза кажется небольшой и неочевидной, пока вы используете только jQuery, но стоит взяться за большой проект с несколькими библиотеками… сэкономите на Солпадеине, вобщем.
Спасибо за статью, более-менее раскрыли мне глаза на сущность SharePoint и современное состояние серверных продуктов от Microsoft. К несчастью, большинство комментов — неаргументированная «вонь» против нелюбимой всеми компании.
Дело скорее в том, что глубокие знания о консоли можно получить в основном академическим путем (чтение и изучение чужого опыта). А GUI гораздо лучше поддается эмпирическому изучению (метод проб и ошибок, личный опыт, случайные находки). При всем при этом у двух методов взаимодействия с компом еще и существенно различаются, так сказать, правила использования. Это как выяснять что круче круче — бор-машинка или пассатижи. Разные вещи, по разному применяются.
В итоге GUI и консоль — два разных религиозных течения. Фотошопщику обработать тысячу картинок с помощью ImageMagick — всё равно что головоломку разобрать вслепую и с отрубленными пальцами. Мастер консоли глупо хлопает глазами, глядя на мой файловый менеджер, и совершает миллион ненужных кликов (хотя задача решается двумя). Не факт при этом, что фотошопщик не знает и не учитывает внутренних приниципов и заморочек фотошопа, или что консолист четко представляет себе, что именно происходит при копировании файла.
Как и во многих вещах в жизни, дело не в них самих — дело в нас, нашем отношении.
А еще — поеживаюсь при мысли о коде, распространяемом в зашифрованном виде (ioncube и иже), как такое вообще можно покупать?
Я линукс именно за то и люблю, что у меня в нем шрифты выглядят многократно лучше, чем в Windows. Actually, дело привычки, ибо MS в деле сглаживания экранных шрифтов никак не могло не пойти своим путем и не изобрести что-то патентованное (и сомнительной пользы). Шрифты в других осях именно поэтому никогда не будут выглядеть точно так же как в Windows. Arial, к примеру, в Linux отобразится совсем иначе (в моих настройках — получается наиболее похоже на печатный вариант, и как же мне в этом виде нравится «скучный» Arial — он реально красив, хотя Helvetica еще красивее).
Tahoma и Verdana в в Windows — совершенно особая песня, вид, которого вы вряд ли добъетесь где либо еще. И всё потому же. Вся фишка в том, что большинство систем сглаживания пытаются просто компенсировать низкое разрешение экрана разными ухищрениями, а у MS кривые, составляющие фигуру буквы, особым образом изменяются, чтобы больше соответствовать пиксельной сетке. Создатели шрифтов должны определять правила, согласно которым это происходит — правила, которыми сам MS, понятно, владеет лучше всего, потому шрифты, адаптированные им под собственную же технологию, выглядят лучше чем множество бесплатных или дизайнерских вариантов. Характерно, что, например, Adobe Photoshop не пытается пользоваться этой технологией, а предлагает дизайнеру 4 варианта. Потому-то и бьются головой о монитор HTML-верстальщики по всей Руси-матушке — не выйдет шрифтовая работа в браузере точно так же как на макете, равно как на самолете нельзя гоняться в формуле-1. Разные технологии — разный результат.
И по-моему, в последних релизах Kubuntu сглаживание уже вкл по умолчанию. Хотя не знаю, может я его сам уже левой ногой не думая включаю…
Я мутант…
Итак: кэшируя jQ-объект в переменную, именуйте ее с помощью $ в начале. То есть:
$a = $('a')
«Лишний» байт на самом деле сугубо повысит читаемость/разбираемось вашего кода для сторонних программистов (или вы гарантируете, что через год поможете модифицировать скрипт?). Особенно важно в обработчиках событий:
$('#myid').bind('click', function(){ // когда делаем обработчик события
var $this = $(this) // оборачиваем DOM-объект, на котором всплыло событие, в jQuery
})
Не понадобится обертка вокруг this — всегда можно удалить одну строчку. Но лично у меня уже стало паттерном, руки сами набирают, пока голова думает над деталями обработки события.
И еще. Бывает, глубоко в цепочке из многих .find() вдруг оказывается позарез нужна текущая jQuery-выборка в виде переменной. Понятное дело, не разорвав красивой цепочки, такую переменную не родишь ниоткуда. Заново повторять выборку ради своих действий тоже накладно. Для такого дела я когда-то написал простенький плагин: plugins.jquery.com/project/jquery_apply. Посреди цепочки можно вызвать .apply(function(){}), где внутри функции текущая jQuery-выборка доступна в форме this.
// начинаем файл нашего скрипта
(function($) // анонимная функция-обертка с параметром
{
$(".mystuff").do(things) // наши jQuery-выкрутасы, за состояние $ можно не бояться
}
)(jQuery) // и вот почему :)
// заканчиваем файл нашего скрипта
Первой и последней строчками мы оборачиваем наш скрипт в анонимную функцию, принимающую параметр $. В последней строке мы вызываем только что созданную функцию и в качестве этого параметра передаем объект jQuery. В итоге .noconflict() нам не страшен (его и можно, кстати, употребить в первой строчке нашего скрипта, перед объявлением функции). Заодно работа скрипта внутри анонимной функции, вызываемой немедленно после создания, не оставит после себя мусора в виде локальных переменных — если их объявлять с ключевым словом var, они исчезнут из памяти сразу после исчезновения контекста функции (то есть в простейших случаях сразу после окончания ее работы, в случаях замыканий при обработке событий — после снятия обработчиков событий). Практическая польза кажется небольшой и неочевидной, пока вы используете только jQuery, но стоит взяться за большой проект с несколькими библиотеками… сэкономите на Солпадеине, вобщем.