В какой-то момент я понял, что книжно-интернетного образования по программированию мне немного не хватает и надо бы получить какую-то базу знаний, чтобы эффективнее расти в профессиональном плане. Тогда я наткнулся на AcademicEarth, про который на Хабре писали уже не раз. Потом, с помощью гугла и любопытства, я обнаружил, что все эти курсы представлены в iTunesU, которым просто удобнее пользоваться, т.к. он отмечает то, что смотрели/не смотрели. Плюс, в нем лекции разделены по годам. Т.е. если в какой-то год лекция не попала в запись, можно порыться в архивах и с большой вероятностью ее там обнаружить. Единственное, чего не хватало, это обсуждений и оценок своих действий.

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

Fat-Free чем-то похож на известный Ruby-фреймворк Sinatra. Автор Fat-Free помешан на минимализме и чистоте кода, что положительно отразилось на этом простом каркасе для разработки самых разнообразных приложений.

Fat-Free состоит из одного файла и весит всего 55KB. При этом фреймворк обладает таким функционалом: специфический и довольно удобный шаблонизатор, гибкое кеширование, автоматическая защита от спама, интегрированные средства для юнит тестов, профайлер кода.

Он настолько маленький и быстрый, что даже может использоваться для контроля траффика Web-сервера.

Это, также, единственный фреймворк, который защищает Ваше приложение от хотлинкинга и DoS атак.

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

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

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

Навеяно вот этим.

Я решил вспомнить некоторые особенности PHP, связанные с производительностью.

Отмечу, что включил в свой небольшой список лишь то, что обычно вызывает удивление у junior developers, с которыми мне приходилось работать.
О банальных вещах, вроде «одинарные кавычки вместо двойных», думаю, знают все, поэтому постараюсь кого-нибудь удивить.

Результаты и выводы, сделаны на основании нескольких версий PHP, который крутятся на знакомых мне серверах, а именно 5.2.6 из Debian Lenny, 5.3.2 из Ubuntu, и 5.2.14 из dotdeb. Возможно, на других платформах, есть отличия.

Пусть расцветают сто цветов, пусть соперничают сто школ. Этим лозунгом первого китайского императора Цинь Ши Хуана хочется поднять волну народного негодования стремления к появлению как можно большего количества шрифтов с веб-лицензией, которые поддерживают кириллицу. Сто школ в данном случае — различные словолитни и сервисы, предоставляющие встраиваемые шрифты.

В настоящее время подобные сервисы активно развиваются. Крупнейший из них, Typekit, содержит на данный момент 376 шрифтов от более чем 30 производителей. Но вот незадача: Typekit пока поддерживает только подмножество Latin-1, хотя и работает над добавлением поддержки других подмножеств Unicode.

Что же прямо сейчас делать нам, пользователям кириллицы?

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

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

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

Автор книги «Быть гиком» Майкл Лопп (Michael Lopp) о рабочих собеседованиях, подозрительной профессии менеджера и о том, как вовремя уволиться.

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

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

Примерно к такому выводу в итоге приходят системно мыслящие (system thinkers) — категория сотрудников, к которым Майкл Лопп относит и себя. Лопп является гиком. Он тот, кто любит порядок и предсказуемый результат. И он понимает, что системно мыслящие люди могут столкнуться с уникальным давлением в офисе.

В этом интервью Лопп делится тяжело добытыми крупицами знаниями о работе в офисе: как гикам общаться с не-гиками, почему гики и менеджеры не могут ужиться и как распознать момент, чтобы уволиться с работы.

Любовь к HTML5 продолжает вдохновлять Поля Айриша. Во-первых, он подарил нам Modernizr, а сейчас он объединился с Divya Manian для создания шаблона HTML5, который использует передовые техники, чтобы Вы могли начать использовать его в своей практике.

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

1. Верстка, аутсорсинг и технические задания

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

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

Сегодня мне кинули ссылку на прикольный сервис для быстрого генерирования изображений-заглушек. Может пригодиться для html-верстки. На мой взгляд, это удобно тем, кто и так использует заглушки — экономит время при вёрстке, т.к. сами заглушки уже готовы. Можно цвета/размеры подбирать, меняя только числа/буквы в коде, не отвлекаясь на сам файл картинки — и сразу видеть эффект. И сами размеры видеть написанными, если нужно, чтоб к коду не возвращаться для проверки. Или вместо размеров можно текст добавить, чтоб всегда знать, для чего эта заглушка (типа «Бан(н)ер» или там «Лого», или «Фотография»).

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

<img src="http://placehold.it/350x50" />

и получаете:


Update. Благодаря усилиям k0rv1n, найден вариант этого сервиса, только лучше :)
Во-первых, там поддерживается кириллица. Во-вторых, там даны ссылки на исходники для разных языков.
Автор dummyimage.com — тот же Russell Heimlich, что и у placehold.it. У placehold.it есть ещё один автор, но будем считать, что он делал дизайн (дизайн там правда круче, но видимо как раз из-за понтового шрифта Unicode и не выходил).

Примеры (см. под хабракатом) я поменял с placehold.it на dummyimage.com, раз уж он функциональнее…

Мы выделили 5 основных пунктов, по которым можно определить юзабилити сайта. Список спорный и в основном касается продающих сайтов. И да, эти пять пунктов — среднее арифметическое опыта, полученного при обработке заявок на конкурс «Юзабельный вебпроект». Думаете, мы раздали слонов и забыли?


_{оригинал картинки}

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

Ошибки, само собой, повторялись. Голова пухла, а мы продолжали писать одинаковые комменты. Результатом марафона стал ниже приведенный чеклист.

Сразу оговоримся, что мы не оцениваем юзабилити в вакууме, нам важно, чтобы сайт работал, т.е. «продавал». Товары, услуги, идеи — не важно. Речь может идти о бесплатном веб-сервисе, для которого транзакцией станет регистрация посетителя.

Перевод статьи Джейсона Калаканиса (jasonnation.com) «How to deal with bubbles».

За свою карьеру я промахнулся более 9 тысяч раз. Проиграл практически 300 игр. 26 раз мне доверяли сделать решающий бросок, но я промахивался. В своей жизни, я терпел неудачу снова и снова. Поэтому я и добился успеха.
Майкл Джордан jc.is/bI33SE

«Мыльный пузырь интернета скоро лопнет? Когда?»
«Мне лучше продать компанию сейчас, либо подождать, и продать дороже в следующем году?»
«Нужно ли мне поднимать деньги сейчас, до того, как бум закончится?»

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

В этом письме я затрону следующие темы:

1. Как я научился по-сложному (aka мой смешанный опыт)
2. Правда о пузырях
3. Правда о выдающихся компаниях
4. Что делать, если мыльный пузырь растет
5. Что делать, если мыльный пузырь лопается
6. Заключительные мысли: Как я научился всему этому (aka у кого я все это украл)

В рамках проекта Computer Science Student сегодня я постараюсь дать короткое наглядное объяснение: что такое генетический алгоритм? В самой простой и общей формулировке для решения самой простой задачи. Исходные коды решения (код не самый качественный, потому что писался на скорую руку; но код и не важен в этом курсе) и текст самих заданий доступен на CS-Student Wiki.

Первая часть


Вторая часть — под катом.

В погоне за оптимизацией сайтов захотел уменьшить количество запросов, не в ущерб размерам оптимизированных файлов.
Цель — передавать в одном файле изображения разных форматов, с разными настройками оптимизации.
Как средство, выбрал data uri и gzip'нутый css файл. Однако IE с data uri работают из рук вон плохо. Но в них есть mhtml. Существовавшая реализация не отвечала моим требованиям, т.к. приходилось 1 файл передавать два раза — раз для IE, в mhtml, и второй для всех остальных, в data uri. В поисках решения наткнулся на статью bolk'а, где описывалось решение для формата jpeg и некоторые теоретические выкладки для gif и png. После почти трехнедельного раскуривания манов мне удалось реализовать решение для gif и png и автоматизировать процесс для всех трех форматов.

Перевод статьи Тима Ферриса из его блога.


(Учебник Дзюдо Окано Исао, который я использовал для изучения японской грамматики)

Изучение языка не должно быть сложным.

Принципы когнитивной нейронауки и управления временем могут быть применены для достижения свободного владения языком на разговорном уровне (в данном случае определяется как 95%+ процентов понимания и 100% выразительных возможностей) в течение 1-3 месяцев.

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

1. Исключения — это гибкий, расширяемый метод обработки ошибок;
2. Это стандартизованный механизм – человеку, не работавшему с вашим кодом, не нужно будет читать мануал, чтобы понять, как обрабатывать ошибки. Ему достаточно знать, как работают исключения;
3. С исключениями гораздо проще находить источник ошибок, так как всегда есть стек вызовов (trace).

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

Что я понимаю под правильной обработкой:

• Универсальное решение, которое можно вставить в любой существующий код;
• Легко расширяемое решение;
• В PHP аж три «механизма ошибок»: собственно ошибки (error), исключения (exception) и утверждения (assertion). Свести три механизма к одному — exception. В комментариях к предыдущей статье на эту тему выражалось мнение, что exception это плохой и/или сложный метод обработки ошибок. Я так не считаю и готов это обсудить в комментариях;
• Опциональное логирование;
• Общий обработчик exception, который будет поддерживать разные форматы вывода и debug/production режимы;
• В debug режиме должен выводится trace. Требования к trace: компактный, понятный и по возможности ссылки на открытие файлов в IDE.

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

Программисты с Etsy.com поделились опытом, как им удалось эффективно решить задачу по пакетному ресайзингу фотографий с 1,5 МБ до 3 КБ (после смены дизайна оказалось, что старые превью-окошки не вписываются в новые шаблоны страниц). Задача не такая банальная, как кажется. Дело в том, что Etsy.com — крупный интернет-аукцион, и количество изображений различных товаров превышает 135 млн штук.

Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда. Затем они начали считать, можно ли отдать пакет в облако EC2 и во сколько это встанет. Посмотрев на получившуюся сумму, программисты решили поискать другой способ.

В итоге им удалось завершить обработку 135 млн фотографий всего за 9 дней, задействуя четыре 16-ядерных сервера. Средняя скорость обработки составила 180 изображений в секунду.