Уже достаточно давно заинтересовался темой сериализации, а если конкретно, то сериализацией объектов, хранящихся по указателю на базовый класс. Например, если мы хотим загружать интерфейс приложения из файла, то скорее всего нам придется заполнять полиморфными объектами контейнер по типу “std::vector<iWidget*>”. Возникает вопрос, как подобное реализовать. Этим я недавно решил заняться и вот что получилось.

Для начала я предположил, что нам все-таки придется унаследовать в базовом классе интерфейс iSerializable, такого вида:

class iSerializable
{
public:
    virtual void serialize (Node node) = 0;
};

Честно говоря, этот проект — лучшее, что я видел до сих пор. Конечно, есть различные невероятные моддинг-проекты, когда из ПК делают роботов, или огромные стимпанковые устройства, или еще что-то. Но подобные проекты, они… ну, ненастоящие, что ли. Выглядят супер, а вот смысла как-то нет. Человек проделывает огромную работу, но вот моддинг не несет обычно никакой смысловой нагрузки. Не всегда, конечно, но в большей части проектов по моддингу ПК это именно так. Но вот ЭТО понравилось мне очень и очень. «Это», то есть проект L3P D3SK, представляет собой гибрид рабочего стола и компьютера. Причем выглядит такое рабочее место уж очень футуристично, но вместе с тем, ничего лишнего.

Семьдесят лет назад, в 1941 году, был создан первый программируемый компьютер. С тех пор утекло немало воды, и сейчас компьютеры окружают нас повсюду. Многие аспекты устройства компьютеров сильно эволюционировали, многие, напротив, ничуть не изменились по сути. В частности, не изменился и, вероятно, никогда не изменится сам принцип работы центральных процессоров — алгоритмическая модель. Хорошо понятны физические ограничения этой модели, и соответственно, отчётливо виден предел развития центральных процессоров в смысле их быстродействия. Технологически до этого потолка ещё довольно далеко: несколько десятилетий развития и несколько порядков быстродействия. Но это не должно помешать нам всерьёз подумать, какими же будут процессоры на пороге предела их скоростного развития.

Я редко плачу за софт, мягко говоря. Но буквально за последние несколько месяцев сделал это трижды. Причем за игры. Есть такой человек в Нью-Йорке – Дэйв Гилберт. Так этот мужчина сейчас, по прошествии 15-ти лет, делает квесты в стиле Sierra-on-Line начала девяностых, я бы сказал. На порядок попроще и покороче, но Gabriel Knight: Sins of the fathers и Conquest of the longbow вспоминаются. Берется свободно распространяемый игровой 2D-движок, пишется очень неплохой грустный детективный сценарий, находятся вменяемые художники, которые рисуют фоны и спрайты персонажей. Классного композитора для последней по времени выхода игры Гилберт вообще нашел где-то в районе Голландии. Все эти поиски происходят по специализированным game-dev форумам, как я понял из комментариев автора, и участники проекта практически никогда не требуют оплаты. Озвучкой персонажей занимаются голосистые родственники и знакомые Гилберта плюс немного профессиональных актеров. Результаты трудов такой команды продаются за 5-15$. На защиту продукта автор решил вообще не заморачиваться, а просто скомпилировать два варианта – полный и демо. Наверняка где-то лежит на шару и полный, но я заплатил за все три игры: Shivah про раввина в депрессии, и Blackwell Legacy и Unbound о том, как в семье медиумов по наследству передается приведение, склоняющее этих медиумов к совместному спасению застрявших на пути в лучший мир душ. Уходит на создание такого наколеночного квеста до полугода, и Гилберт с этого живет. Автор заметно прогрессирует от игры к игре. Прекрасное занятие, я считаю. По доходности, конечно, с MMORPG не сравнимое, зато какое-то уютное, несвоевременное и очень милое. Я под впечатлением даже скачал движок и кое-какие свои текстовые наработки стал к формату игрового сценария приводить

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

Сформулируем определения и задачу.
Графом будем называть несколько точек (вершин), некоторые пары которых соединены отрезками (рёбрами). Граф связный, если от каждой вершины можно дойти до любой другой по этим отрезкам. Циклом назовём какой-то путь по рёбрам графа, начинающегося и заканчивающегося в одной и той же вершине. И ещё граф называется взвешенным, если каждому ребру соответствует какое-то число (вес). Не может быть двух рёбер, соединяющих одни и те же вершины.
Каждый из алгоритмов будет решать какую-то задачу о кратчайших путях на взвешенном связном. Кратчайший путь из одной вершины в другую — это такой путь по рёбрам, что сумма весов рёбер, по которым мы прошли будет минимальна.
Для ясности приведу пример такой задачи в реальной жизни. Пусть, в стране есть несколько городов и дорог, соединяющих эти города. При этом у каждой дороги есть длина. Вы хотите попасть из одного города в другой, проехав как можно меньший путь.

Прошли те времена, когда каждый форум на персональной страничке каждого Васисуалия Свердыщенко требовал отдельной регистрации.
Мы потихонечку привыкаем к тому, что оставить комментарий от имени своего OpenID/OAuth провайдера можно фактически везде. Также для всех популярных CMS давно написаны плагины сквозной авторизации Twitter/Facebook/Google/Яndex/Вконтакте. Кроме того есть DISQUS… Но что делать, если мы хотим предоставить пользователю стороннего сервиса какие-то дополнительные полномочия, не вынуждая его заводить отдельную учетную запись на нашем сайте? Особенно, если для нашей CMS пока нет чудо-плагина?
Я расскажу о том, как быстро и безболезненно прикрутить сквозную авторизацию к экзотической CMS и какие на этом пути встречаются подводные грабли.

Данная статья не содержит никаких откровений. В первую очередь информация о типовых уязвимостях и методах их решения будет полезна начинающим. Опытные разработчики все это знают, или должны знать, если считают себя таковыми.

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

С удивлением обнаружил, что про явление алиасинга (aliasing) здесь постов нет. Ситуацию нужно исправить, тк. алиасинг в любой сколько-то сложной C++ программе обязательно хоть где-нибудь, да есть. Это может быть хорошо, давая возможность ловких оптимизаций, а может быть плохо, внося повышенной паршивости баги. Под катом вкратце про оба случая (ну и неизменное «компилятор бьет спина», конечно; для разнообразия сегодня это gcc).

Многие наверняка используют индикаторы процесса, например, когда передаете/получаете какие-нибудь данные через AJAX.

Однажды я озадачился, чтобы при нажатии на кнопку, которая отправляет данные формы на сервер, внутри неё появился этот самый индикатор. Изначально фон был однотонный, но в любой момент дизайнеры могли заменить его на другой, либо вообще сделать градиент.

Делать специальный GIF под каждую ситуацию довольно глупо. Поэтому правильное решение — использовать Canvas.

Под катом — описание восьми сервисов, которые могут заметно облегчить жизнь веб-разработчика, верстальщика или дизайнера.

Привет, хабрасообщество! Хотел бы рассказать вам о своем проекте, над которым я работаю в свободное время. Он называется Viewpot и является первым в Сети хостингом 3D-моделей.

Мой прошлый пост вызвал огромный резонанс. Комментариев было не много, но я получил множество писем, а некоторые читатели выступили даже с открытыми заявлениями (там, правда, преобладают наезды на меня лично и на хабр в целом, но есть и мысли по существу вопроса). Поэтому я решил продолжить писать в жанре «мои мысли по поводу вопросов известной компании». Этим постом я постараюсь решить две задачи: (i) ответить на вопросы и возражения читателей предыдущего поста и (ii) толкнуть в некотором смысле философскую мысль о безIFовом программировании. Букв получилось довольно много, но те, кому интересно только что-то одно из поста, могут пропустить половину.

И ещё: этот топик (как и прошлый) — не наезд ни на кого. Просто интересно порассуждать об интересных вопросах. Здесь нет подтекста, намёка, вызова. Параноиков и сторонников теорий заговоров попрошу расслабиться.

В этот раз хотел бы взглянуть на вопрос 4.

Десять лет я пишу на С++. Первые пять лет моей задачей было писать эффективный код для компьютерных игр, потом основным требованием была стабильность, так как речь шла об автоматизации промышленных объектов. Я бы хотел поделиться своим личным опытом и практическими наработками, которые помогут создавать эффективные и в то же время стабильно работающие программы.


Материал разбит на части, от самых общих практических правил, интересных начинающим, до конкретных вопросов, актуальных опытным программистам.
В первой части я на практике дам свой ответ на самые базовые вопросы. Как вообще писать программу, в особенности — сложную программу? Что следует сделать в самом начале, чтобы потом не переделывать с нуля? Как создать оптимальную структуру программы?

Первод статьи, автором которой является Fabien Potencier, ведущий разработчик и идеолог Symfony. Статья поднимает обсуждение о шаблонизаторах PHP в целом и представляет Twig — быстрый и функциональный шаблонизатор.

Куда будет двигаться FF? Что может принципиально в нем измениться в скором времени?
— Oliver Reichenstein и Aza Raskin, не последние люди в компании, ответили на эти вопросы, предложив убрать систему табов!

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

В процессе работы с CUDA я практически не касался вопросов об использовании памяти видеокарты. Настало время убрать этот пробел.

Специализация шаблонов является одной из «сложных» фичей языка с++ и использутся в основном при создании библиотек. К сожалению, некоторые особенности специализации шаблонов не очень хорошо раскрыты в популярных книгах по этому языку. Более того, даже 53 страницы официального ISO стандарта языка, посвященные шаблонам, описывают интересные детали сумбурно, оставляя многое на «догадайтесь сами — это же очевидно». Под катом я постарался ясно изложить базовые принципы специализации шаблонов и показать как эти принципы можно использовать в построении магических заклинаний.

Vim (сокр. от Vi Improved, произносится Вим) — свободный режимный текстовый редактор, созданный на основе более старого vi. Ныне это один из мощнейших текстовых редакторов с полной свободой настройки и автоматизации, и созданным благодаря этому расширениям и надстройкам. (с)wiki

Вот и настроим. У меня была цель — сделать из Vim полноценную IDE для perl. Но таким же путем это делается и для любого другого языка.