Если вам не хочется использовать гифы на сайте, а предпочитаете PNG за их лучшую цветность, но всё же нужно анимировать их, тогда вот способ:

у анимаций CSS с ключевыми кадрами есть свойство под названием animation-timing-function. Одна из его возможностей — использовать функцию steps(), как в нижеследующем примере:

div {
    animation: play 1s steps(10) infinite;
}
@keyframes play { 
      0% { background-position:    0px 0; } 
    100% { background-position: -500px 0; }
}

Различие между нею и остальными анимационными функциями состоит в том, что вместо плавного движения от 0px к −500px происходят резкие прыжки с паузами между ними. Это идеально подходит для анимаций, использующих лист с покадровым изображением спрайта. В вышеприведённом примере шаг равен 50px, а пауза — 100 миллисекунд (всего 10 шагов).

Вот небольшое демо.

Это перевод статьи «How to trick C/C++ compilers into generating terrible code?», автор оригинала — Aater Suleman.

На курсе архитектуры ЭВМ мне сказали, что процессор похож на машину. Руль и педали — это ISA, двигатель — микроархитектура, а программа — водитель. Продолжая эту аналогию, скажу, что использование компьютера похоже на управление машиной через пульт дистанционного управления. Пульт — это клёвая вещь, но в то же время важно понимать, как он работает. Даже в профессиональном ПО я видел много примеров кода, который может смутить даже самый умный компилятор. В этой статье я расскажу об основных методах запутывания компиляторов.

Настройка резервного копирования в Ubuntu за 20 минут.

Для работы над проектами использую svn, который находится на удаленном виртуальном выделенном хосте, под управлением ubuntu 8.04. Со временем объемы данных выросли, как и критичность этих данных. Потеря чего-то снилась в кошмарах. Время от времени копировал репозитории на локальный компьютер. Недавно мне это надоело. И я стал искать возможности автоматизировать это дело. Не буду говорить о поисках и вариантах, расскажу о результатах.

Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.

Сразу оговорюсь, что python и gtk у меня 2й версии.

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

Чего нет в этой статье:
— как делать перевод формы в процессе работы. Этого я не смог найти, а хотелось бы знать…
— как делать перевод текста в .py коде в процессе работы.
— пива, блэкджека и остального тут тоже конечно нет.

Перевод будет осуществляться с помощью указания локали при старте (или локали по умолчанию).

На хабре уже были статьи о сценерах, которых в итоге арестовали. Сегодня я публикую перевод интервью с человеком, которого так и не поймали. Очевидно, он американец, и всё это происходило в США. Интервью состоялось в 2010 году, анонимно, по понятным причинам он не называет и группы, в которой он был. Поэтому в качестве картинки к статье я использовал случайным образом выбранный логотип узла, через который проходили пиратские файлы.

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

Добрый день!

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

SVN

Subversion — это централизованная система контроля версий. Это главный ее минус и главный ее плюс :)

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

Главный минус — это merge… Те, кто часто делает мерж средствами svn, понимает о чем я.
Это медленно (даже меееееееедлееенно), требует постоянного соединения с репозиторием, а еще эти svn-properties, которые мешают читать diff.

Мне очень нравится JavaScript и я считаю его мощным и удобным. Но для большинства начинающих JS-программистов, много проблем создаёт недопонимание аспектов языка. Часто конструкции языка ведут себя «нелогично». В данной статье я хочу привести примеры «граблей», на которые я наступил; объяснить поведение языка и дать пару советов.

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

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

Тот дизайнер, который ценит своё время, любит порядок в работе, разукрашивает папки и обзывает слои вменяемыми именами, а иногда даже оставляет «сноски в фотошопе в трудных для понимания местах» мгновенно переходит на следующий уровень с соответствующим ценником. И даже если финансы позволяют вам воспользоваться их услугами – их очень не просто найти, так-как соотношение между «дизайнерами-новичками» и «дизайнерами-со-скиллом-именования-слоёв» стремится к 80% — 20% или даже 90% — 10%.

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

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

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

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

Совет 1

Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».

Совет 2

Отталкиваясь от предыдущего, в начало каждого скрипта неплохо помещать что-то вроде:

read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE 
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2

Команда echo, кстати, здесь нужна потому, что после нажатия кнопки <y> у вас не будет перевода строки, следовательно, следующий любой вывод пойдет в эту же строку.

Совет 3

Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:

Безусловно, все те кто общается с ОС Linux хоть раз да имели дело(во всяком случае слышали точно) с командной оболочкой BASH. Но BASH не только командная оболочка, это еще и превосходный скриптовый язык программирования.
Цель этой статьи — познакомить поближе юзеров с bash, рассказать про синтаксис, основные приемы и фишки языка, для того чтобы даже обычный пользователь смог быстренько написать простой скрипт для выполнения ежедневной(-недельной, -месячной) рутинной работы или, скажем, «на коленке» наваять скриптик для бэкапа директории.

Я увлекаюсь фотографией ещё со Смены-8М. Тогда были длительные ожидания пятницы или субботы (печать обычно шла в ночь на выходные), а перед этим оочень долгие ожидания фотоплёнки, химикатов, фотобумаги (ибо дефицит). Теперь же я вырос, стал большим и ленивым. Моя мыльница почти всегда со мной: либо в рюкзаке, либо где-то в кармане. Фотографирую всё, что вызвало интерес. При этом за день может быть одна фотография (шёл с работы), а может быть сразу много (целенаправленно вышел на прогулку). И если с целенаправленным случаем я скорее всего по приходу домой фотографии солью и разберу, то в единичных случаях я забуду и потом окажется что надо рассортировать фотографии сделанные в десяток разных дней. В последнее время выбираться целенаправленно получалось всё меньше, поэтому росло количество одиночных фотографий. И вот в один из таких дней, вдохновившись прошлогодней статьёй, я решил упростить себе хобби. Поскольку на компьютере стоит Linux (openSUSE 12.1), то нерешаемых проблем быть не должно — подумал я. А захотелось мне чтоб оно само копировало и чтоб никуда тыкать не нужно было. Ну, а поскольку я ненастоящий линуксоид (первый и последний скрипт был на третьем курсе 0x0C лет назад), сразу скажу — не всё получилось.

22 октября на kickstarter начался сбор средств для проекта «Light» — продвинутого linux-светильника. Он представляет собой куб из матового пластика, внутри которого на гранях расположены 52 RGB-светодиода, под управлением микрокомпьютера с акселерометром и беспроводным модулем, что открывает большие возможности для применения этого устройства: его можно использовать и как необычный светильник и как индикатор (например, использования системных ресурсов на сервере), и как будильник, или ambilight.

Одной из целей этого проекта является создание платформы для разработки, доступной не только опытным системным программистам. Так как для управления устройством используется REST-интерфейс, то не имеет значения, на каком языке было написано приложение и выполняется ли оно на самом Light, или где-то на другом конце Земли.

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

Хочу поделится с вами очень интересным приемом оптимизации в Javascript.

В этой статье мы рассмотрим 7 приемов навигации по тексту в программе Emacs
1. Построковая
2. Поэкранная
3. Перемещение по словам
4. Особая
5. По параграфам
6. Поиск
7. Перемещение из командной строки

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

Так уж сложилось, что испокон веков единственный кроссбраузерный способ показать анимацию в браузере без JS — анимированный gif. Был бы у него JPEG-based аналог — и интернет мог бы быть совсем другим… Современные альтернативы, например APNG — работает не везде и со столь же небольшим сжатием, а долгожданный тэг <video> страдает от патентов.

Хочу поделится результатами моего небольшого академического эксперимента по конвертированию видео в формат SVG (которое затем при везении можно просто показать через <img src="">).

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

SVG — это не только векторная графика, но и 3 а то и 4 метра качественного видео...

Прим. переводчика: underscore.js — одна из самых известных и любимых javascript-библиотек. Но мало кто знает, что есть её более удачный клон. В одном из своих проектов мы без каких-либо проблем перешли на него и теперь решили познакомить с ним других читателей Хабрахабра.

Lo-Dash — это полноценная замена^* для Underscore.js. Lo-dash имеет более высокую производительность, избавлен от некоторых багов underscore и даёт некоторые новые возможности.

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

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

ОСТОРОЖНО! Концентрированная ностальгия! Описанное здесь морально устарело много-много лет назад. Более того, оно устарело до того, как было реализовано. Из статьи вы не узнаете ничего нового.
В давние-давние времена, когда Embarcadero CodeGear Borland Delphi RAD Studio C++ Builder был версии 4, когда Autodesk 3ds Max Discreet 3dsmax 3D Studio Max был версии 3, когда 80 Гб и 200 МГц были не в холодильниках, а в компьютерах, когда Интернет был неведомым и таинственным существом, каждое прикосновение к которому было магическим… я учился в старших классах школы и учился программировать. А также моделировать. И ещё всякое-разное по мелочи.
Подозрительный скриншот: