Ребята с webmasterworld.com решили собрать все факторы, которые учитивает Google при ранжировании сайтов. Официальным представителем было заявлено (еще на тот момент), что их более 200. Пока список выглядит так, не исключено, что некоторые пункты включают в себя несколько факторов.

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

Вашему вниманию мой вгляд на правила обработки URL с объяснениями и коментариями «почему так?».

Сперва логика

Объясню сперва логику:
1) все страницы имеют .html окончания.
2) все языки для страниц имеют вид pagename.en.html или pagename.html для языка по умолчанию. Никто, конечно, не запрещает иметь ссылки, где язык идёт вначале как /en/
3) «входной» скрипт только один в docroot.
4) Разрешены запросы на другие скрипты только в docroot
5) Соглашение по определению окончаний в url:
# site.com/
# site.com/index -> site.com/
# site.com -> site.com/
# site.com/file/ -> site.com/file.html
# site.com/file -> site.com/file.html
# site.com/dir/file ->site.com/dir/file.html
# site.com/dir/file/ -> site.com/dir/file.html
Но это можно менять.

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

О чем это

Я долгое время был адептом идей о равенстве, свободе и братстве том, что существует красная таблетка.

— Что можно с помощью ООП решить все проблемы масштабирования программ;
— Что с помощью одной методологии можно выстроить разработку проектов;
— Что с помощью нескольких гениальных книг можно научиться проектировать интерфейсы.

На самом деле, после пары десятков проектов я пришел к выводу, что все это — не более чем заблуждения, и чудеса происходят только в книгах авторов, которые делают на своих бестселлерах миллионы. Или в головах консультантов, которые делают деньги, продавая вам фуфло в виде Agile, KPI и прочих умных слов.

Я не сделаю, возможно, в этом посте никаких открытий. Но сэкономлю вам пару лет, если вы решитесь поверить моему опыту.

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

Алгоритм Диффи — Хеллмана позволяет двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены канал связи. Полученный ключ можно использовать для обмена сообщениями с помощью симметричного шифрования.

Предлагаю ознакомиться с принципом работы алгоритма Диффи – Хеллмана в замечательном видео от Art of the Problem в моем переводе.

Хочу поделиться набором ссылок на нексолько полезных, интересных и, возможно, не самых известных материалов по JavaScript. Из них вы узнаете немного больше об истории появления языка, о его настоящем, тонкостях реализации в различных браузерах, и о будущем развития стандарта ECMAScript. О различных способах наследования в том числе об эмуляции «классического» ООП, множественном наследовании и миксинах. О функциональном стиле программирования в JavaScript: чистые функции, map, reduce, частичное применение и композиции функций. И, наконец, что если бы Хемингуэй писал на JavaScript?

Данный пост не претендует на полноценную статью и не является рекламным, а всего лишь небольшой lifehack, который может немного упростить жизнь верстальщикам

Наверное, каждый нормальный web-верстальщик задавался вопросом: «Как удобнее сверять макет с уже готовой вёрсткой», ну или что-то вроде этого. Сегодня я тоже задался этим вопросом.

Первая мысль, которая пришла в голову, это «Было бы неплохо быстро изменять прозрачность окон». Насколько я знаю, в Windows 7 нет такой функции. Немного погуглив я в этом окончательно убедился. Но поиски на этом не остановились. Позже я набрёл на замечательную программу, под названием: See Through Windows.

Just for fun. Что-то в этом есть.

Иногда разработчики различных веб-проектов сталкиваются с необходимостью обработки больших объемов данных или использованием ресурсозатратного алгоритма. Старые инструменты уже не дают необходимой производительности, приходится арендовать/покупать дополнительные вычислительные мощности, что подталкивает к мысли переписать медленные участки кода на C++ или других быстрых языках.

В этой статье я расскажу о том, как можно попробовать ускорить работу Node.JS (который сам по себе считается довольно быстрым). Речь пойдет о нативных расширениях, написанных с помощью C++.

Подлинная история.

Жесткий диск, который хранил раздел /home на моей Linux машине, накрылся и я должен был заменить его новым. Так как системный блок находится под столом, то я должен был отключить все кабели, достать его, поменять жесткие диски местами и вставить все это обратно.

Довольно стандартные действия. Подключить блок питания, подключить клавиатуру, подключить мышь, но когда я дошел до аудиокабеля, я просто пропустил его.

Плагин BigVideo.js для jQuery добавляет на страницу видео в качестве фонового изображения через HTML5 Fullscreen API. Видео автоматически растягивается на любой размер экрана. Для работы нужно предварительно загрузить библиотеки jQuery, jQuery UI и jQuery imagesloaded. Запуск:

$(function() {
    var BV = new $.BigVideo();
    BV.init();
    BV.show('http://video-js.zencoder.com/oceans-clip.mp4');
});

В качестве хостинга своих видеороликов удобно использовать Vimeo Pro, он даёт прямую ссылку на mp4-файл и отгружает контент со скоростью более 10 Мбит/с.

Хочу поделиться с обществом собственным плагином, который упрощает работу с динамическими формами и называется jqDynaForm. Под динамическими формами я подразумеваю формы, в которые при заполнении пользователь может добавлять по необходимости дополнительные поля или блоки полей. Разумеется, в каждом месте разрешено добавлять только заранее разрешенные виды блоков. Вот примеры подобных простейших форм:

1. Контактная форма, в которой есть поле «телефон». Пользователь может добавить еще несколько дополнительных полей для телефонов, если возникнет желание.

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

Давайте рассмотрим работу с jqDynaForm на примере такого счета. Вот пример такой формы:

Предисловие

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

Поиски

Долгое время я обходился консервативными методами отладки в виде периодического вывода объёма используемой памяти и времени выполнения критических участков кода в консоль, но настал момент, когда необходимость наличия качественного инструмента встала очень остро.

Первым делом я решил посмотреть не оправился ли node-inspector, который после перехода на node.js 0.6.x перестал поддерживать профилирование CPU и Heap. Оказалось, что в новой версии node-inspector неработающий профайлинг окончательно исключён и теперь это просто debugger. Немного покопавшись в коде старой версии, мне всё же удалось завести профилирование CPU и Heap на node 0.8.x, однако это решение не было идеальным. Чтобы вывести его из состояния «поделки» необходимо было бы заменить устаревший интерфейс WebKit-консоли на современный, переписав приличное количество кода и исправить некоторые проблемы производительности. В целом, решение на основе консоли WebKit мне кажется очень не гибким, поэтому я бросил эту затею и продолжил поиски.

Вот оно

Они уходят. Ещё вчера мы были вынуждены прикручивать очередной костыль для IE6/IE7, а сейчас в этом уже нет необходимости. В СНГ у IE6 сегодня всего 0.5% трафика, у IE7 — 1.8%. Они действительно уходят. Думаю, большинство верстальщиков давно уже не добивается попиксельного соответствия макету, а кто-то даже не проверяет на работоспособность сайтов в столь старых браузерах. В таком случае не будет лишним предупредить пользователя, что сайт может работать неправильно, и предложить обновиться. Предлагаю готовый комплект из панельки предупреждения и страницы с предложением выбрать новый браузер.

Ища на просторах сети музыкальный плеер для сайта, я наткнулся на интересный плеер под названием Speakker, написанный на jQuery.

Одна из постоянных проблем верстальщиков адаптивных сайтов — это задача удобно представить обычные таблицы на мобильных устройствах. Вот как выглядят такие таблицы чаще всего:


Не очень удобно, правда? К счастью уже существует несколько хитрых способов решить такую проблему.

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

Здравствуйте.
Мне бы хотелось рассказать про мой «Bart Chalkboard Generator».
Я уверен, что большинство из вас знают сериал «The Simpsons», и вы помните что почти в каждой новой заставке Барт писал на школьной доске что-то новое, типа: «They are laughing at me, not with me». А в интернете часто всплывает картинка с текстом: «I will use google before asking dump questions». И вот однажды я подумал, почему бы не создать простой генератор подобных картинок, да ещё и на Html5, что бы попрактиковаться?

Первая часть — вводная.
Вторая часть — быстрый старт.

Третья часть — тонкости и особенности.

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

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