Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

Те, кому в гуглотаблицу не хочется, просим под кат. Там перевод.

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

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Язык JavaScript был представлен как язык функционального программирования. Причина заключается в том, что функции в JS не просто разделяют логику на операционные блоки, функции являются объектами первого класса, способными создавать другие объекты. Подобная зависимость от функций одновременно является как сильной стороной, так и настоящим проклятием этого языка. Сильная сторона заключается в том, что язык, обладая подобными особенностями, становится легковесным и быстрым (каким JavaScript изначально и видели его создатели). Однако если вы не знаете что делаете — однозначно ждите беды.

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

Итак, существует четыре пути вызова функций:

• Вызов метода — Method Invocation
• Вызов функции — Function Invocation
• Вызов конструктора — Constructor Invocation
• Вызов apply и call — Apply And Call Invocation

Должен признаться, что я плохой программист. Я не люблю настраивать Maven и писать конфигурации для Spring Framework. Я не знаю в деталях, как работает JVM (да и в общих чертах представляю это себе довольно смутно). Я плохо понимаю паттерны проектирования, а любая новая технология вводит меня в уныние. И тем не менее, я люблю программировать.

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

Минуточку внимания.

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

Как реализовать long polling с помощью Nginx и Javascript в сети достаточно много материала. Но полного руководства я ещё не встречал. То возникают проблемы с компиляцией модуля под Nginx, то в браузере вертится иконка загрузки при long poll запросах. Под катом, полный материал как же все таки это сделать правильно.

В сети гуляет довольно много решений для эмуляции многопоточности в php. Чаще всего они основываются на форках, но есть и вариации на тему с использованием curl, proc_open и т.п.

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

• Использование форков;
• Синхронный режим с сохранением интерфейса при отсутствии необходимых расширений;
• Многократное использование дочерних процессов;
• Полноценный обмен данными между процессами. Т.е. запуск с аргументами и получение результата по завершении;
• Возможность обмена событиями между дочерним процессом-«потоком» и основным процессом во время работы;
• Работа с пулом потоков с сохранением многократного использования, передачи аргументов и получения результатов;
• Обработка ошибок выполнения;
• Таймауты на выполнение работы, ожидание работы потоком, инициализацию;
• Максимум производительности;

В результате получилась библиотека AzaThread (старое название — CThread).

Я давний подписчик блога «GTD» (уст. Учись работать).

С 2008 года я активно читал статьи на Хабре и в Интернете и пробовал:
— вставать в 5:00 утра
— делать зарядку
— обливаться холодной водой
— бегать по утрам
— питаться правильно (особенно зачитывался вегетарианством)
— вести свои делало системе GTD (Things установлен на всех гаджетах :)
— выключать компьютер вовремя (хотя бы до 23:00)
— ну и конечно, сделать 100 отжиманий и кубики на животе…

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

Что изменилось в январе 2012 года?

Рано… в начале кратко обо мне:
— Возраст: 26 лет;
— Семейное положение: женат (с февраля 2012), детей пока нет;
— живем отдельно в Санкт-Петербурге.
— Работаю в офисе 5 дней в неделю с 8:30 до 17:30.
— Иногда задерживаюсь, но не часто.

Если Вы считаете, что опыт Вам не подойдет… Ваше право, но мы же понимаем, что оправдания всегда можно придумать? Я их придумывал лет 5. Я знаю о чем говорю.

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

В результате стандартный консервативный аллокатор выстраивает все запросы в очередь на pthread_mutex / critical section. И наш многоядерный процессор медленно и печально едет на первой передаче.

И что с этим делать? Познакомимся поближе с деталями реализации метода Scalable Lock-Free Dynamic Memory Allocation. Maged M. Michael. IBM Thomas J. Watson Research Center.

Самый простой код что я сумел найти — написан под LGPL камрадами Scott Schneider и Christos Antonopoulos. Его и рассмотрим.

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

Вступление

Приветствую всех.

Люди любят читать. Но не все, и не всё. А то, что любят, не всегда можно найти в магазинах. А если и можно найти, то не всегда это по карману. Из этого следует один элементарный факт: что-то с этим надо делать. Конечно, можно читать с экрана монитора/ноутбука/телефона. Или распечатать и читать в разрозненных, пусть и упорядоченных, листочках. Кроме того (это более затратный вариант, но для любителя чтения он лучше), можно купить специализированную читалку на электронных чернилах. Да, она решает проблему, но… Спустя какое-то время начинаешь скучать по весу настоящей книги, по шелесту перелистывания бумажных страниц, и по кипе других подобных маловажных, но таких приятных сердцу мелочей.
И из этой неприятности тоже есть свой выход. Просто-напросто надо самому сделать нужную книгу.
Осторожно, под катом очень много фотографий.

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

Сколько я себя помню, всегда мечтала сделать процессор. Наконец, вчера я его сделала. Не бог весть что: 8 бит, RISC, текущая рабочая частота — 4 кГц, но он работает. Пока что в программе моделирования логических цепей, но все мы знаем: «сегодня — на модели, завтра — на деле!».

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

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



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

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

Доброго дня.

Изображение честно позаимствовано с Dribbble.com

Прошло немногим менее два года с момента публикации моего первого топика по теме. Что за это время произошло? Mail.ru, Rambler, Yahoo и Яндекс дружно перелопатили свои почтовые интерфейсы, и как следствие — парсеры писем, что доставило приятных эмоций, т.к. было исправлено много противных багов. Gmail стал поддерживать фоновые изображения. Ну а благодаря развитию рынка мобильных платформ к нам на помощь приходят media queries.

Смысл поста — подытожить методику верстки писем под сегодняшние реалии, при этом не забывая про ископаемые клиенты.

И да, в посте картинок почти нет. За картинками прошу в обзоры css3 фич.

На данный момент занимаюсь версткой писем, скорей как хобби, поэтому времени на тестирование opera mail, sparrow и прочих «вроде как популярных» клиентов не было. Речь пойдет о следующих:

— Все версии MS Outlook
— Mail.ru
— Rambler почта (в новом интерфейсе не исключены баги)
— Яндекс почта
— Gmail
— Yahoo!
— Thunderbird начиная с версии 2.0
— Hotmail
— Windows Live Mail
— Apple Mail начиная с третьей версии
— AOL Mail
— Lotus Notes 8-8.5.
— theBat! дотошно не тестировал, но и нареканий особенно не было

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

Не претендуя на библию или «настольную статью программиста» я хочу поделиться полезными находками в моей любимой IDE, не скатываясь в тупую копипасту мануалов и скучных списков хоткеев, только то, что я сам использую постоянно и над чем удивляются коллеги: «о! а так можно?»

Не так давно была замечательная статья, описывающая общие принципы работы с сервером очередей Gearman. Мне бы хотелось продолжить материал, дополнив его некоторыми деталями практического применения, а именно:
— установка и управление сервером
— управление очередью — что возможно и как
— PECL и PEAR php-расширения для работы с Gearman
— мониторинг сервера
— примеры кода
— передача данных порциями
— организация параллельных вычислений в PHP

Интересно? Прошу под кат

Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

Поскольку я отношусь к секте Vim, далее мы обсудим неисчерпаемые возможности этого редактора, а также инструменты командной строки, вызываемые прямо из Vim для расширения встроенной функциональности. Некоторые из обсуждаемых дальше принципов могут быть применимы и для Emacs, но не для простых редакторов, вроде Nano.

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

Но недавно, просматривая официальную документацию по API скайпа, я обратил внимание на «D-BUS messaging», не знаю, почему я раньше не обращал на него внимание. Разобравшись со всем, я наконец сделал то, что давно хотел! Я получил доступ к Skype API на PHP. Об этом я и хочу рассказать в своей статье.