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

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

Если же вам нужны базовые сведения о предназначении данного файла, то вы можете получить из нашей статьи введение в .htaccess (перевод данной статьи не делал, так как там основы, их достаточно в русскоязычном сегменте Сети, но если будет проявлен интерес, то можно и ее перевести для полноты картины — прим. переводчика), в которой достаточно подробно раскрыты все аспекты его применения.

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

Веб-разработчики к адаптации сайтов для слабовидящих (и других категорий людей с ограниченными возможностями здоровья) относятся двойственно. С одной стороны, я еще не встречал человека, который бы сказал «их слишком мало, чтобы тратить на них время»; с другой — в условиях фиксированных бюджетов и сжатых сроков именно так и случается. К тому же, тот факт, что для этого надо изучать какие-то правила, рекомендации, часто просто пугает. А между тем, большинство рекомендаций WCAG 2.0 от консорциума W3C (Web Content Accessibility Guidelines, Руководство по обеспечению доступности веб-контента) при ближайшем рассмотрении банально совпадают с правилами хорошего тона, рекомендациями для адаптации сайтов под мобильные устройства, да и просто не так уж и сложны в реализации. При этом следование этим рекомендациям упростит работу с сайтом не только не только пользователям с ограниченными возможностями здоровья, но и пользователям с ограниченными техническими возможностями (низкоскоростной Интернет; отсутствие мыши, как на смартфонах; маленький экран), а также пожилым людям. Поэтому я решил написать вольное изложение всех двенадцати положений WCAG 2.0, которое и предлагаю вашему вниманию.

Когда-то 3D в браузере было большой проблемой. К чему только не прибегали для создания объемной динамичной трехмерной графики в браузере: использованию псевдо-3D в SVG, построениям в canvas, использованию flash… Однако, прогресс не стоит на месте: наконец-то все современные браузеры стали поддерживать облегченную версию OpenGL (OpenGL ES 2.0) — WebGL. Это — довольно молодая технология, ей всего-то чуть больше года от роду. Однако, уже сейчас можно оценить ее мощь по всевозможным браузерным играм и примерам.

Из-за сравнительной молодости этой технологии, руководств по работе с ней не так уж и много. Почитать кое-что о работе с ней можно здесь (здесь — перевод на русский). Здесь можно узнать кое-что об основах WebGL.

Для облегчения работы с WebGL разработан ряд библиотек (правда, большинство из них еще довольно сырые). Применению одной из них — webGLU — для формирования простой сцены, освещенной одним источником-фонарем, и посвящена эта статья. Здесь можно посмотреть пример, а отсюда скачать полный архив для запуска его на своей машине.

В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 ;-) ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать хостеру?

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

В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).

UPD: получил инвестиции под свой проект в сфере обучения облачным технологиям

Здравствуйте уважаемые Хабравчане, особенно те, у кого есть идея своего стартапа! А вот с деньгами и осведомленностью похуже. Хочу Вам в помощь поделиться небольшой таблицей IT-инвесторов, которая была составлена для себя. Дело в том, что я также как и вы, обладаю минимум информации. Такие вопросы как: «к кому идти за деньгами», «как составить бизнес-план», и наконец «кому я вообще нужен со своей идеей» — давно стали навязчивыми.
Именно сейчас, после Новогодних праздников, самое время начать искать тех самых менторов, инвесторов, бизнес-ангелов, да и в целом зачитываться информацией на эту тему. Да, и у меня есть свой стартап, который перестал быстро развиваться и я активно ищу инвестора на дальнейшее развитие (О чем уже писал неделю назад).
Под катом таблица, со списком полезных ссылок, в помощь начинающим IT-компаниям.

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

В качестве теста решил перевести все свои сайты на nginx, до этого все работало на Apache из состава ZendServerCE. Интересно было пробовать насколько сложно будет полностью переехать на новый для себя веб-сервер, ведь используется несколько CMS (DLE, Wordpress, самописныеCMS).

Задачи:

• базовая работа web сервера — обработка html;
• запуск php скриптов;
• корректная работа phpmyadmin для всех сайтов на сервере;
• запуск cgi и pl скриптов;
• использование кеширования и подбор оптимальных параметров для увеличения производительности.

Имеем свежеустановленный сервер Debian 6 в минимальной установке из netinstall. И так поехали.

О том, как надо правильно создавать стартап, написано много статей. Много говорится и о роли команды в проекте. Но при этом незаслуженно опускается тот факт, что сама личность стартапера, его психика и ментальные процессы прочно интегрированы в проект и составляют с ним неразрывное целое. Создание стартапа – это процесс, в котором когнитивные процессы всех участников влияют друг на друга, и НАПРЯМУЮ на результат.



Attention!
Терминология не совпадает с классической, хотя некоторые элементы в ней присутствуют. Пост не претендует на научную ценность, а служит лишь для иллюстрации типичных ошибок людей, гордо именующих себя стартаперами. Пост основан на реальных событиях, а также на моих личных наблюдениях самого себя и коллег по цеху. Я — стартапер. Коллеги — тоже.

Итак, вот типичные ошибки, некоторые из которых выглядят как симптомы:

Осенью 2008 года мы потратили две-три недели свободного от основной работы времени, чтобы написать маленькую утилитку для бэкапа баз данных (MS SQL Server и потом MySQL). Сегодня она приносит нам около $230 000 в год и можно с уверенностью говорить, что суммарно мы заработаем на ней больше $1 000 000.

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

Пост «Кое-что о весе страницы» вызвал у меня желание написать маленькое дополнение. Многие замечают, что оптимизация размера веб-страниц становится менее актуальной в связи с увеличением пропускных способностей каналов. Рано или поздно все будут сидеть на гигабите, и будет совершенно неважно, весит ваша страница 100Кб или 250. Возможно, так оно и будет. Однако помимо скорости канала есть и другой параметр — задержка или латентность. И если пропускная способность каналов с развитием технологий может вырасти ещё очень сильно, то у латентности существует физический предел: это скорость света в оптоволокне — около 200 тысяч километров в секунду.

Хотя эта скорость очень велика, но всё же недостаточно, чтобы о ней забывать, ведь и планета у нас немаленькая. Wolfram Alpha не зря выдаёт на запросы по расстоянию время прохождения этого расстояния светом в волокне. Пусть у вас стоит сервер в Токио, а клиент пришёл из Рио-де-Жанейро. Если даже эти два города соединить оптоволокном по кратчайшей траектории на поверхности Земли, свет будет идти 86.7 мс.

Введение

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

Я много раз использовал возможность кэширование nginxом страниц, и натыкался на пару неудобных для себя вещей:

• Можно легко закешировать вообще все страницы, но для динамических сайтов или для сайтов с авторизацией нужно ли это?
• Можно закешировать отдельно несколько url, вида /album/*, но не переписывать же конфиг nginx каждый раз при появлении новых разделов сайта?

Многие уже слышали о проекте WebRTC, некоторые даже используют его (или пытаются применять в существующих проектах), а кто-то злобно потирает руки, предвкушая постепенную расправу со Skype и Flash.

Погуглив в Хабре (хе-хе) я почему-то не нашел статей, которые углублялись в техническую сторону WebRTC, показывали бы примеры его использования.

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

Проблема

Webex использует 32битные Linux библиотеки для своей работы, поэтому работать в 64битной системе (а такие сейчас практически все десктопные Linux) отказывается.

% file ~/.webex/12_1324/libwelsvp.so
/home/user/.webex/12_1324/libwelsvp.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

Выражается это в том, что вы не слышите и вас не слышат. Ошибка «The Audio Device is Unaccessible Now» — это с большой долей вероятности оно.

Всем привет! В этом топике мне хотелось бы обсудить одну из самых интересных и в тоже время загадочных тем для большинства, как мне кажется, инди-разработчиков – это продвижение своих собственных приложений. Скажу пару слов о себе: я примерно 2 года занимаюсь Android-разработкой (исключительно в качестве хобби, правда). У меня есть десяток приложений в Play Store, с совокупным количеством загрузок более 5 млн. Ни то что бы очень много, да и большая часть загрузок приходится на одно приложение, но какие-то выводы касательно маркетинга я для себя сделал. Здесь я хочу поделиться своим опытом, наблюдениями, а так же призываю Вас рассказывать о своих результатах в комментариях. Обмен опытом в этом вопросе был бы полезен всем, я думаю.

Часто меня спрашивают студенты: «Какой элемент сайта самый важный?», на что я им отвечаю — формы. Ведь с помощью форм пользователи совершают почти все конверсионные действия. Именно с этим элементом связано больше всего проблем. В этой статье я постараюсь рассказать, что можно улучшить при взаимодействии с формами. А заодно описать новые возможности работы с ними в браузерах.

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

    Не так давно, просматривая глубокой ночью достаточно интересную заметку о игре на основе JS/Canvas (со своими ошибками и заблуждениями, которые были и у меня, что уж греха таить, понастальгировал всласть), я наткнулся на очередную порцию откровенно холиварных комментариев, после прочтения которых мир за окном стал серым и безрадостным, еда потеряла вкус, а любимый чай оказался несладким. И в тот момент то ли звезды сошлись, то ли срочных и важных багов и фич на вчера стало немного меньше, но я решил ввязаться в спор с достаточно резкими тезисами и вступиться за любимую технологию, которую так откровенно поливали непонятно чем. Так бы и осталось все это на уровне беспредметного перебрасывания пакетов с доводами через забор, если бы в ту же ветку не решил написать RussianSpy, и не об абстрактных попугаях, которых легче переписать в 3D, а о вполне конкретной задаче. И промелькнувшая фраза «Могу прислать ТЗ...» плавно намекнула на то, что вечер обещает быть интересным.

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

Пару лет назад я начал пользоваться различными сервисами для развития своих способностей — LinguaLeo, Codecademy, Coursera. Это просто отличные инструменты. Удивительно, но тогда я не нашел подобного сервиса, который помог бы моему хобби — музыка (гитара). Идея создать отличный сервис для гитаристов, включающий в себя образовательную платформу, созрела в декабре 2011 года. История проекта Totallicks банальна.

В прошлой статье я рассказывал о переменных, теперь пойдет речь о массивах.

Что такое массивы на уровне PHP?

На уровне PHP, массив — это упорядоченный список скрещенный с мэпом. Грубо говоря, PHP смешивает эти два понятия, в итоге получается, с одной стороны, очень гибкая структура данных, с другой стороны, возможно, не самая оптимальная, точнее, как выразился Anthony Ferrara:

PHP arrays are a great one-size-fits-all data structure. But like all one-size-fits-all <anything>, jack-of-all-trades usually means master of none.

Ссылка на письмо

(на картине изображен HashTable с Bucket-ами, В. Васнецов)

Для перемещения элемента по экрану есть два основных способа:

• CSS 2D-преобразования и translate();
• position:absolute и изменение top/left.

Крис Койер недавно писал, почему лучше и логичнее использовать translate (это быстрее, и свойство position имеет большее отношение к вёрстке, а не к визуальным эффектам и анимации, в отличие от translate).

Я хочу расширить его ответ и привести несколько хороших примеров. Я записал скринкаст, в котором помощью Chrome DevTools timline рассматриваю различия между этими подходами с точки зрения производительности, особенностей рендеринга и композитинга на GPU.



Если вам нужна сокращённая текстовая версия — продолжайте читать.