Pull to refresh
49
0
Ярослав @GD666

Пользователь

Send message
Ну если любите регулярки, то у нас вот такое используется:
( /(?:\.)([^.]+$)/.exec('jquery.validate.unobtrusive.min.js') || [] )[1]
Выдаст неверный ответ, если в имени файла вообще нет точки.
Opera 12.00 alpha build 132812 — тормозит
Понятно… Тогда проблема действительно существует.
К этому костылю будет полезно прикрутить логику увеличивающихся интервалов. Не получили новость за секунду, умножаем на два и ждём две секунды, не получили за две — ждём 4. И так далее, до верхней границы, которую вы сами себе определите. Например, пинг раз в минуту. Это значительно снизит нагрузку на сервер.

Часто в подобных костылях применяется следующий подход — с каждым полученным ответом сервер шлёт минимальное время интервала, коэффициент умножения и максимальное время. Например, если сервер видит, что кто-то усиленно комментирует пост, то он может выставить коэффициенты (1, 2, 60), а если комментарии редкие, то (10, 3, 180).

Есть ещё 4 параметр — через какое время прекратить долбиться на сервер. Это делается специально для людей, которые открыли вкладку и пошли спать.
Вот сайт с оригиналом этой игры www.boxcar2d.com/
Там же есть собственный редактор, форум и возможность попробовать свои алгоритмы.
CoffeScript — это всего лишь синтаксический сахар для JavaScript. Когда вы пишите на CoffeScript, то думаете в терминах JavaScript. Когда вы пишете на Dart, то думаете в терминах Dart. Ожидается, что там будут объекты и сообщения между ними, инкапсуляция, система типизации и ещё куча отличий от JavaScript. Может быть это и будет компилироваться в JavaScript, но язык будет совсем другим.
Я думаю, что стоит упомянуть, что это всего лишь одна из догадок каким будет новый язык. Нигде ещё не было опубликовано каким именно он будет. Один из популярных вариантов, что это будет язык Newspeak, компилируемый в JavaScript, либо исполняемый нативно в браузере. Это следует из того, кто будет выступать с докладом этого языка в понедельник: один из докладчиков — автор Newspeak, а второй занимается V8 JavaScript Engine.
А! Ещё забыл очень важный момент :) Многие думают, что они там увидят полноценное изображение и ищут его там, а когда не находят, думают что не могут смотреть стереоизображения. Я сам так думал, когда слышал от друзей: «да там же дельфинчик» или «там такая красивая земля!». На самом деле, там будут те же самые загогулины, которые видно, но только они будут выгнутые или вогнутые.
Есть ещё один похожий способ, но только без приближения лица к картинке и без скрещивания глаз.

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

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

Если не получится на картинке из поста, попробуйте на других стереокартинах. Там главное понять принцип, а дальше будет очень просто.
Я пользуюсь.
Я считаю этот метод очень эффективным, когда приходится выполнять долгую и нудную работу. Правда пришлось немного адаптировать для себя: я делаю большой перерыв через три помидорки и не веду инвентаризацию. Мне достаточно списка дел, который я иногда веду отдельно. А ещё мне не нравится тикающий звук, поэтому я не пользуюсь физическим таймером, а пользуюсь программой focus booster.
В GAE есть ограничение в 1 мегабайт на одну запись.
Вчера leron написал небольшое дополнение к этой статье. Советую прочитать.
Пожалуйста!
На Хабре есть несколько статей «Заметки об объектной системе языка Python». Рекомендую всем, кто хочет лучше понять как это всё работает.
Заметки об объектной системе языка Python ч.1
Заметки об объектной системе языка Python ч.2
Заметки об объектной системе языка Python ч.3
Подводные камни могут быть в том, что некоторые браузеры будут считать размеры в pt по старой методике, без привязки к референтному пикселю, либо считать их как настоящие физические размеры. Насколько я помню, W3C рекомендует использовать пункты, дюймы, сантиметры и прочие абсолютные размеры только когда они действительно необходимы. Привязка к референтному пикселю — это как бы такой костыль для ленивых дизайнеров.

Меньше всего проблем будет если вы будете использовать px, em и % для дизайна на экране. Причём нет какого-то общего, универсального решения. Для разных задач нужны разные категории размеров.
Относительные размеры будут одинаковые, потому что будет меняться только размер референтного пикселя.
Именованные размеры делятся на два типа: абсолютные и относительные.

К абсолютным относятся значения xx-small, x-small, small, medium, large, x-large, xx-large, где xx-small — это самый маленький шрифт, а xx-large — самый большой. Здесь нет общего стандарта на размер, браузер должен сам высчитывать размеры как ему нравится, беря за основу настройки базового шрифта и приравнивая его размер значению medium.

Рекомендуется, чтобы заглавные буквы при значении xx-small были не меньше чем самый читаемый шрифт. Обычно это равно 9 px, либо устанавливается пользователем в настройках. Обычно шаг увеличения/уменьшения шрифта равен 1.2 от ближайшего размера, т.е. large = 1.2*medium = 1.2*1.2*small, но бывают и другие значения.

К относительным именованным значениям относятся smaller и larger. При этом браузер, опять же по своей логике, должен высчитать значение, которое обычно на 1.2 меньше или больше значения родительского элемента.

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

Многие не понимаю разницы, поэтому попробую объяснить технические премудрости.

Пункты определяют абсолютные физические размеры и с другими физическими размерами определена такая связь: 72 pt = 1 in = 2.54 cm = 25.4 mm = 12 pc, т.е. если бы все браузеры соблюдали правила CSS, то размер в 72 pt занимал бы ровно один дюйм на любом устройстве. Это очень удобно, если вы хотите показать пользователю прямоугольник с высотой в один дюйм, но не всегда удобно для отображения шрифтов. Например, размер шрифта в 14 pt будет легко читаться с экрана ноутбука или мобильного телефона, но, чтобы прочитать тот же шрифт на телевизоре, вам придётся сидеть рядом с телевизором впритык. Если вы попробуете прочитать те же самые буквы сидя на диване далеко от телевизора, то буквы сольются в одну линию.

Ещё замутнее обстоит дело с пикселями. Пиксель в CSS — это по определению тонкая, острая линия, которую может показать устройство, но он не имеет ничего общего с настоящими пикселями устройства. Точнее, имел, но в CSS2 это убрали. В CSS1 пиксель равнялся пикселям устройства. Представьте себе какая бы разница была в картинках на экране и на бумаге. Если на экране с разрешением 96 px на дюйм картинка в 960 px занимала бы 10 дюймов, то на бумаге у принтера с разрешением 600 px на дюйм — в 6 раз меньше! Технически это правильно, но для пользователей это часто контринтуитивно. Поэтому в CSS2 ввели два понятия: во-первых, связали пиксель CSS с абсолютным значением в 0.75 pt, а во-вторых ввели понятие референтного пикселя — он рассчитывается через визуальный угол, который занимает пиксель в 0.75 pt на экране устройства с разрешением в 96 px на дюйм c расстояния вытянутой руки. В этой ситуации пиксель занимает 0.26 mm. Теперь, используя этот угл, можно отойти от телевизора и сказать, что пиксель телевизора будет иметь размер 1.3 mm.
Референтный пиксель и угол обзора

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

Единицы CSS em и ex определяют относительные размеры и берут их из размеров шрифта. em — это просто размер шрифта. ex — размер маленькой буквы «x» этого шрифта, либо «x-height» свойство шрифта, либо 0.5 em. Если пользователь установил в настройках браузера, что ему нравится смотреть на сайт со шрифтом в 10 pt — то em будет пересчитан в эти 10 pt. Если 16, то в 16. Для дизайнеров засада состоит в том, что em пересчитывается для каждого элемента и за основу em берётся размер родительского элемента. Т.е. если у body установлено 2 em, а у дочернего элемента тоже 2 em, и размер базового шрифта = 10 pt, то размер дочернего элемента будет не 20 pt, а 40 pt.

В CSS есть ещё такая величина размеров как %. Там всё ещё запущеннее :) Когда указываются проценты, то для каждого свойства в документации есть описание откуда считать эти проценты. Если вы указываете высоту строки в 150% — это откуда считать? А если 150% высота рисунка? А если шрифта? А что делать, если проценты указаны для свойства, у которого нет родителя, с которого эти проценты считать? Расписывать долго, но могу сказать, что почти всегда это интуитивно понятно, и если возникают проблемы, то читайте документацию.

Сейчас разрабатываются ещё одни размеры для CSS: «rem» — считает как em, но только берёт размер от корневого элемента документа, а не от родителя; «vw» и «vh» — 1/100 часть ширины и 1/100 часть высоты экрана соответственно.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity