К написанию данного топика меня подтолкнула одна заметка о генерации xls в PHP.
Способ, представленный в той заметке действительно очень прост, но не всегда может быть удобен.
Есть множество других способов передать табличные данные из PHP в Excel, я опишу тот, который показался мне наиболее простым и функциональным. Нужно особенно отметить, что что я не говорю о генерации xls файла, а лишь предлагаю пользователю открыть полученные данные при помощи Excel так, что пользователи не искушённые в программировании не заметят подлога.

Докладом «Эволюция разработки» открываю серию расшифровок с Форума Технологий Mail.Ru 2011. Данная расшифровка была получена в день мероприятия, 16 ноября 2011 года. Подробности о том, как работает система расшифровки докладов — см. в статье «Изнанка» Форума технологий Mail.Ru: Хай-тек в event-management

(Скачать видеоверсию для мобильных устройств – iOS/Android H.264 480x368, размер 204 Mb, видеобитрейт 500 кбит/с, аудио — 64 кбит/с )
(Скачать видеоверсию большего разрешения H.264 624x480, размер 610 Mb, видеобитрейт 1500 кбит/с, аудио — 128 кбит)
(Скачать слайды презентации, 2Mb)

Вступление вице-президента Mail.Ru Group, технического директора Габриеляна Владимира

— Коллеги, я надеюсь, что вам понравился обед. Сытые, добрые, довольные. Напишите в «Твиттер». На самом деле я хочу представить нашего следующего докладчика. Знаете, в каждой компании есть человек, которого можно назвать «Мистер «Я знаю как», человек, который находится в курсе всех технологий, человек, который имеет очень правильное визионерское мышление, и он во многом определяет нашу технологическую политику в «Mail.ru Group». Это Игорь Ермаков, заместитель технического директора, то есть меня. Игорь сегодня расскажет нам о том, как мы эволюционировали в наших технологиях на протяжении 13 лет, и, если вы внимательно будете слушать этот доклад, он на самом деле поможет вам перескочить те этапы развития, которые мы уже прошли, и сразу перейти к тем технологиям, которые мы используем в Mail.Ru. Игорь!

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

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

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

Многие разработчики используют Memcached, систему кэширования различных объектов в оперативной памяти. Устанавливается она очень просто

В компании, где я работаю, мы используем деперсонализированную базу с Production-a. Ее суммарный объем на данный момент около 30 ГБ. Обфускация ruby скриптом занимала около 6 часов. Ускорение обработки можно добиться, если переписать это все в хранимую процедуру (stored procedure). Но у нас в проекте они запрещены… Увы и ах.

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

Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.

Введение

Для начала, о названии серии постов: посты будут и о кэшировании в Web’е (в высоконагруженных Web-проектах), и о применении memcached для кэширования, и о других применениях memcached в Web-проектах. То есть все три составляющие названия в различных комбинациях будут освещены в этой серии постов.

Когда я писал проект crafthunters.com, я заметил что для раскрутки клиенты используют социальные сети. Пользовались виджетами и лайками, но по хорошему надо было попадать в ленту новостей. Кроме того, популярный вконтакте вывел новости на главную страницу в сентябре. Т.е. для распространения контента надо было адаптировать standalone блог для представления в социальных сетях, используя простую истину: попасть в ленту новостей популярных социальных сетей. Вначале это происходило вручную и приносило более половины траффика. Потом пришла идея это всё автоматизировать.
Популярными социальными сетями у нас были:

• facebook
• вконтакте
• livejournal
• твиттер

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

Далее я хочу представить реализацию кросспостинга под эти четыре социальные сети для asp.net mvc.

Moment.js это отличная библиотека для работы с датами в JavaScript. Примеры под катом.

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

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

1. На каких данных это все расчитывать.
2. Где эти данные взять.
3. Как эти данные сохранять.
4. Каким алгоритмом воспользоваться для расчетов.

В апреле-мае 2011 года компания Яндекс проводила очередной тур конкурса Яндекс интернет математика. Тема тура: «Определение визуальной схожести изображений».
Я публиковал новость про объявление победителей и обещал в скором времени описать решение поставленной задачи нашей командой — LookLikeIt, которая заняла 12-е место в финальном рейтинге.

И вот, не совсем скорое время наступило!

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

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.

Приветствую!

Я JavaScript разработчик и последнее время занимаюсь разработкой приложений на Ext JS. Для наглядности интерфейсов, иногда необходимо вбить в них JSON данные. Сперва я писал небольшие скрипты на PHP для генерации необходимых данных, но вскоре это стало забирать все больше времени и я отказался от этого подхода. Потом я начал создавать *.json файлы с данными, но зачастую мне требовалось наличие в них полей с уникальным ID и, по возможности, уникальными данными для красоты. Правда, задавать уникальные значения для полей, особенно в массиве из 100+ объектов занятие не благодарное.

И я решил немного автоматизировать данный процесс.

В текущем проекте возникла необходимость выполнить последовательную серию ajax запросов и, по завершении — что-то сделать со всеми их результатами.
Довольно типовая задача, паттерн ее решения обычно называют waterfall (водопад). Реализации этого паттерна есть для node.js, хотя некоторые работают и в браузере — async.
Но включать целый модуль ради одного метода не хотелось. Copy/paste тоже не стал делать, но по соображениям скорее эстетическим. В async в метод передается функция обратного вызова, у нас же везде используется jQuery.Deferred. Разницы, конечно, никакой, но «ломать» стиль проекта мое «чувство прекрасного» мне не позволило :)
В результате написал небольшую утилитку по аналогии с jQuery.when

Вступление

В ходе реализации текущего проекта мне понабилось выпадающее дерево. Так как я уже пользовался jQuery плагином TreeView, и его функционал меня устраивает, было принято решение cделать выпадающее дерево на его основе. В результате родился плагин DropDownTreeView которым я хочу поделится.

Функционал

Плагин позволяет создавать выпадающие деревья с AJAX загрузкой (пример). При создании дерева к объекту обертки добавляется кнопка открытия дерева, и подгружается дерево. Дерево можно подгружать как целиком так и частями (актуально для больших деревьев). HTTP запросы могут выполнятся POST и GET методами. Параметры HTTP запроса определяются пользователем. Дерево строится посредством jQuery.Treeview. Дерево сворачивается при выборе пункта и клике вне зоны дерева.

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