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

Часто пользователи удивляются, откуда спаммеры узнают их e-mail адреса и выливают на них тонны спама. Оставляя за рамками этой статьи такие способы пополнения спаммерских базы, как вирусы, «слив» адресов владельцами почтового сервера или прослушивание HTTP и ICQ траффика, рассмотрим самый распространенный случай.
Одним из основных источников новых e-mail адресов являются собственно веб-страницы, на которых беспечные пользователи (а порой и владельцы сайта) открыто публикуют свой e-mail, откуда спамботы (сборщики e-mail) без проблем его извлекают и используют в своих нехороших целях.

Далее будут рассмотрены основные приемы шифрования e-mail адресов от спамботов, а также приведены результаты замера эффективности каждого из приемов, путем практического использования каждого способа для свежезарегистрированных e-mail адресов и оценки количества спама.

После открытия API ВКонтакте сразу появилось несколько статей по созданию быстрой авторизации на своём сайте пользователей vk.com, в т.ч. и на PHP. Решил заняться написанием модуля авторизации для Kohana.

Документация по API очень хилая, пришлось изучать js-скрипты durov.at и переносить некоторый функционал на PHP (отправка POST-запроса с получением полной информации о пользователе, вместо ajax-овой реализации на durov.at). Самым сложным местом оказалось генерирование уникальной подписи запроса (как они объясняют, «подпись запроса по стандартной схеме»), т.к. этот процесс нормально не описан.

Модуль Vk умеет логиниться и получать информацию о пользователе и, соответственно, разлогиниваться. Информация хранится в cookie и в сессии. При желании, можно складывать всё в БД, запрашивать дополнительную информацию о пользователе и т.д.

Подробное описание на странице модуля в github. Не забываем создать свое приложение ВКонтакте для тестирования и записать полученные API ID, ключ приложения и защищенный ключ в config/vk.php, а также создать файл xd_receiver.htm по примеру в описании.

Здравствуйте.
Май и июнь, как оказалось, весьма богаты на различного рода мероприятия. Поэтому, пожалуй, вкратце расскажу об ещё одной конференции — Bryansk Web Day.

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

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

В мире существуют тысячи CMS для самых разных целей, самого разного качества, самой разной перспективы, стоимости, распространённости и так далее. Серьёзно опробовать их все — нереально. Поэтому когда я только знакомился с миром движков для сайтов, выбирать приходилось наугад. Ниже я опишу свои впечатления от знакомства с теми или иными движками для тех или иных целей. К некоторым приложу краткое описание особенностей, впечатление о прочих состоит только из заглядывания в админку. Заметки эти составлялись и редактировались в течении долгого времени, но сейчас я решил, что лучше опубликовать их в нынешнем виде, чем ещё полгода-год по чуть-чуть редактировать не добавляя ничего принципиально нового.
Преимущество отдаётся бесплатным движкам. Платные будут рассматриваться только для сравнения или от безысходности, т.е. если нет бесплатных аналогов. Также ограничение на технологии: php. О движках на перле и питоне я не более чем слышал, на шарпе и джаве имел дело с самописными.
Итак, рассматриваются

• CMS общего назначения. Информационные сайты, визитки, блоги…
• Многофункциональные монстры.
• Галереи.
• Социальные сети.
• Форумы.
• Интернет-магазины.

Мы все прекрасно понимаем, что не существует универсальной системы управления проектами, которая бы подходила для всех случаев. Выбор системы целиком и полностью зависит от Ваших нужд. Если вы не нуждаетесь в репозитариях, и для общения Вам достаточно комментариев в тикетах, а работаете Вы над проектром по «гибким» методологиям, то возможно одним из лучших вариантов будет — Pivotal Tracker.

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

Наверняка каждый из вас делал сайт, где администратор, или даже пользователи, могу закачивать изображения, которые должны отобразится на сайте. Такие изображения можно разделить условно на 2 группы: те, которые вставляются в тело статей, скажем с помощью wysiwyg-редактора, и те, которые закачиваются в отдельное поле и потом выводятся в заранее отведенном месте. Ко вторым относятся всевозможные картинки к новостям, фотографии в фото-галереях, какие-нибудь логотипы партнеров и прочее.

И те и другие требуют какой-то обработки после размещения, но каждая группа имеет свои особенности.

QR-code, уже давно распространен повсеместно, во всех сферах человеческой жизни. Вроде такая популярная вещь, а нормальной библиотеки (Open Source) на PHP — нет. Товарища deltalab, очень напрягла эта проблема и он решил переписать имеющиеся в наличии С библиотеки ibqrencode от Kentaro Fukuchi, на более привычный ему язык PHP.

В мире разработки программных продуктов бытует немало мифов и заблуждений. Чтобы двигаться вперед, а не топтаться на месте, их совершенно необходимо разрушить. Сегодня об одном из самых закоренелых заблуждений, которое к тому же достаточно вредное — называется «Миф об обязательном поле».

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

1. Все необходимые с точки зрения предмета поля (например, ФИО и дата рождения человека, если речь о паспортном столе);
2. Все необходимые для функционирования системы поля (те, без которых не будут работать алгоритмы — например, дата, с которой начинается предоставление услуг, чтобы делать по ним начисления);
3. Важные поля — такие, которые не необходимо, но желательно заполнить (например, обоснование вносимого изменения) — с той мотивацией, что пусть лучше пользователь попотеет, когда не нужно, чем забудет ввести значение, когда будет нужно.

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

Независимые разработчики уже давно могут создавать приложения для нашей социальной сети Мой Мир@Mail.Ru, а также ставить на своих страницах специальные кнопки, которые дают пользователям возможность обмениваться в рамках Моего Мира ссылками на интересные материалы с этих сайтов.

Сегодня мы сделали очередной шаг в этом направлении и открыли для сторонних ресурсов еще один вид API, который так и называем – Mail.Ru API.Сайты. Желание его использовать уже выразили (и сейчас проводят все необходимые технические процедуры), например, такие проекты, как Afisha.ru и Pravda.ru.

Что это такое? Прежде всего, потенциальный источник большого числа новых пользователей.

Команда «ВКонтакте» так и не ушла на выходные, чтобы вслед за Merchant API успеть запустить еще один важный сервис для разработчиков — Open API. Благодаря VK Open API, любые внешние сайты теперь имеют возможность производить у себя авторизацию наших пользователей.

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

К делу

Внешне задумка выглядит так:

Занимаясь разработкой интернет-каталогов (или же интернет-магазинов) столкнулись с проблемой подбора картинок для товара. Не каждый заказчик может позволить внедрить в свои процессы фотографирование каждого товара (особенно когда их более 7000), да и есть ли смысл фотографировать товары когда их изображения уже есть в интернете, причем абсолютно легально на сайтах производителей. Вручную скачивать-заливать изображения — не вариант. За время работы испробовали массу способов «автоматизации» данного процесса:

• Выгрузка товаров из 1С и синхронизация картинок
• Загрузка картинок «оптом» через FTP
• Поиск картинок средствами Google API

Всё началось с создания сложного AJAX приложения с применением java технологий GWT, GXT, Spring, Hibernate, Terracota, AndroMDA, ActiveMQ и множеством других волшебных звуков за которыми прячется вся мощь и могущество java технологий создаваемых десятками тысяч гениальнейших программистов уже второе тысячелетие подряд …

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

Входные данные: размер текстовых данных js, css, xml, html, images коло ~1,2MБ(+ флэш), время загрузки в Москве более полутора минут, при хождении по ссылкам заметное время(1-15 секунд) на загрузку картинок, при повторном обращении картинка загружалась повторно.

Приняв во внимание все замечания из предыдущего поста с базой городов, мы обновили ее и добавили еще родительный падеж. Теперь база отвечает на вопрос «Откуда?». Например: Вася из Ярославля.

Скачать:

1. CSV
2. MySQL

Автоматическая обработка: Jetfish
Вычитка и ручная корректировка Sofrus

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

Хочу поделиться базой стран, регионов и городов на русском языке. Возможно, кому-то пригодиться в своих проектах. В базе 106 стран, 922 региона и 10969 городов!

Если кто не понял о чем речь, то вспомните, например, как на ВКонтакте указывается город: выбирается страна -> подгружается список регионов -> выбирается регион -> подгружается список городов

Поступила задача – создать API для сайта scribbler.ru, которое позволило бы сторонним разработчикам работать с ресурсами сайта, писать приложения как внутри, в виде swf файла, так и находящиеся вне сайта, допустим десктопное приложение, которое может получать/отправлять почту пользователям сайта.

Всем известно, что популярные российские проекты (vkontakte.ru, mail.ru и какие-либо другие) имеют свой API. Для примера я начал было их осваивать и смотреть, как же они реализованы, и знаете что, каждый сайт пишет API так, как ему вздумается (как разработчики считают правильным), т.е. API mail.ru и vkontakte.ru сильно разнятся в своих архитектурах, грубо говоря они не схожи, что, я думаю, усложняет жизнь разработчикам, сперва пишем свои классы, работающие с API, под vkontake, потом пишем свои классы под mail.ru и т.д.

Возник вопрос: «А как же решили эту задачу «забугорные» сайты?»

11 правил, следуя которым можно увеличить производительность скрипта, написанного с использованием jQuery.

«Website Screenshots & Thumbnails Extractor — это Windows приложение с открытым исходным кодом для извлечения скриншотов и превьюшек сайтов. Для работы требуется .NET Framework 3.5.

Основные возможности:

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