В проекте, в котором я сейчас работаю, все построено на Zend Framework + JQuery. Соответственно приходиться сталкиваться теперь довольно часто с jQuery.

Вчера мне понадобилась там одна фишка: нужно было получить данные через Ajax запрос и дальше сделать с ними некоторые манипуляции (обрезание строки и т.д, не суть важно) и вывести клиенту.

Недолго думая, была сделана такая конструкция:

$.getJSON(’<?=$this->newsLetterUrl(’content-start’)?>/’,
 { load_eds_data: 1, idpage: $(’#eds_ref-key’).val(), ajax: ’true’},
 function(data) {
 subTitle = ’Dates: ’+data.date_text + ’ Venue: ’ + data.xvenue;
 });

Удивление наступило позже, когда я понял, что переменная subTitle не видна после этого и не доступна.

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

Оказалось, что проблема … в асинхронности запроса $.getJson и для того, чтобы получить нужное мне, конструкцию надо заменить на такую:

$.ajax({
 async: false,
 data: { load_eds_data: 1, idpage: $(’#eds_ref-key’).val(), ajax: ’true’},
 dataType : «json»,
 url: ’newsLetterUrl(’content-start’)?>/’,
 success: function(data) {
 subTitle = ’Dates: ’+data.date_text + ’ Venue: ’ + data.xvenue;
 }
});

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

Самое интересное, что в prototype таких проблем у меня вообще не возникало. Видимо связано с особенностями реализации библиотеки.

Возможно кому-то пригодится, когда столкнетесь с подобной задачей.

Сегодня выдалось свободное время, решил немного написать сюда.

Итак, социальные сети. Я считаю, что социальных сетей уже чуть более, чем дохуя слишком много на сегодняшний день и поезд создания социальных сетей ушел еще в 2005–2006 году, все социалки, которые были созданы позднее или создаются еще сегодня — чаще всего не имеют будущего. Максимум — стать лидером своего региона.

К примеру, социальная сеть «Коннект» (connect.ua) — была запущена в 2007 году, с опозданием, когда украинская часть аудитории уже использовала во всю vkontakte.ru и, фактически, рынок уже был забит. Однако ребята всеравно запустили проект, хотя лично я, еще тогда, говорил Сергею (Коркину), что конкурировать с существующими сетями будет почти бесполезно.

Сегодня первые дни 2010 года, проекту (коннекту) стукнуло недавно 2 года со времени запуска. Проект до сих пор не набрал еще миллиона аккаунтов, хотя и вышел на самоокупаемость. Каким образом? Довольно простым — превратили социальную сеть в сайт знакомств, аналогично мамба.ру и подобным — с подарочками, отметками фотографий и прочего. Ребята поняли, что будущего нет в социальной сети и пользователям она просто даже не нужна. Уже сейчас там трудно кого-то найти (впрочем и ранее так было), т.к. пользователей, которые имеют там реальные имя, фамилию и фотографию — очень мало. Большинство анкет закрыто, имена и фамилии изменены на произвольные логины и т.д.

Однако радует, что руководители проекта вовремя поняли, что социальная сеть — путь в никуда и нужно менять направление проекта.

Одно время я следил за статистикой проекта: она доросла до 40К уников и миллиона хитов в день и ..встала на месте. Где-то полгода ничего не менялось, до тех пор, пока не было введено понятие «валюты» внутри проекта, которую можно было получить за разного рода активность на проекте: голосования, посещения и т.д. Подросло количество хитов. А вот уники так и не растут, до сих пор.

Если посмотреть сюда — http://top.bigmir.net/report/16789479/, то станет еще понятнее: сайт зарегистрирован в разделе «Знакомства».

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

Разделами фото, видео, аудио, сообщества пользуются не более 10–15% пользователей. Мы планируем заменить их на те, которые понравятся большинству нашей аудитории. В данном случае разделы только мешают — распыляют внимание пользователей, усложняют техническую поддержку, размывают позиционирование.

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

А ты,  %username%, тоже хочешь потерять кучу времени и создать очередную никому не нужную социальную сеть? Или может задумаешься и сделаешь что-то более полезное?

У каждого языка для веб-разработок есть свой фреймворк или даже несколько. Каким пользуетесь вы и почему?

Скажу за себя — для всех более-менее увесистых проектов (больше хоумпага) я использую Zend Framework, впрочем использую его уже давненько, первым проектом на нем был — http://prometr.ua , сделанный в командной работе (хотя откровенно говоря я принял в нем довольно малое участие, но все же).

С тех пор мне данный фреймворк понравился и я продолжаю работать с ним.

А вы на чем работаете и почему?

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

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

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

Основная сложность, как на меня, это закачка, обработка и отдача видео.

Закачка видео

Основная задача и проблема, как на меня тут следующая: загрузка видео (как впрочем и его отдача) не должна тормозить работу веб-морды проекта. Следовательно, понадобиться две машины — одна будет содержать морду проекта, вторая будет отвечать за загрузку видео и его отдачу.

Одну машину называем host.ru, вторую upload.host.ru и используем технологию (звучит пафостно, но это не технология совсем, так, умное название) CDS — Cross Domain Scripting (больше об этом можно узнать в гугле). Это позволит нам с помощью javascript, отправлять запрос на upload.host.ru, а он, в свою очередь, благодаря CDS будет иметь возможность вызывать куски JavaScript-кода на host.ru, таким образом мы сможем мониторить процесс закачки, не используя для этого flash.

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

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

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

Обработка видео

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

Машинка, которая называется upload.host.ru имела на борту у себя операционную систему Debian. На ней с помощью apt’a было установлено FFMpeg и Mencoder в качестве конвертеров для обработки видео.

Видео после того, как заливалось пользователем, складывалось в отдельную папку, откуда забиралось скриптом, который раз в минуту проверял список необработанных видео (у обработанных видео добавлялся префикс .processed в названии) и забирал на обработку.

Скрипт был написан на перле, администратором, который помогал мне все это добро настроить. Впоследствии я уже только занимался модификацией данного скрипта (заодно и о перле немного больше узнал).

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

Во многих туториалах советую указывать битрейт видео при декодировании. Однако нельзя указывать тупо битрейт, не зная текущий битрейт видео. Например пользователь заливает видео с YouTube, которое имеет битрейт 68К. Тогда нужно сначала определить битрейт видео и только потом принять решение, в какой битрейт его кодировать. Я выбрал такую стратегию при кодировке видео:

• Если битрейт видео больше 1024К, то видео кодируем в два битрейта — 128К и 1024К (для обладателей разных каналов по скорости интернет)
• Если битрейт больше 128K, но меньше 1024K, то кодируем только в 128К
• Если битрейт ниже 128К, то битрейт не меняем и используем ключи к ffmpeg такие «-sameq -vcodec copy». Где первый ключ говорит, что при кодировании нужно сохранить тоже качество видео, что и у исходного файла, а второй говорит, что нужно скопировать кодек для кодирования из исходника.

Определить текущий битрейт видео можно довольно просто (не забудьте только поставить mplayer в системе), запустив следующую команду в консоли:

mplayer $wrkfile -identify -vo null -nocache -nolirc -nojoystick
-channels 6 -loop 1 -frames 1 | grep ID_VIDEO_BITRATE

Бывают случаи, когда mplayer не определяет битрейт видео, либо ставит его равным 0, тогда для определения битрейта можно воспользоваться утилитой ffprobe (установить можно через apt-get install ffprobe). Команда следующая:

ffprobe -show_files $wrkfile | grep bit_rate

$wrkfile — полный путь к видеофайлу, информацию о котором мы хотим получить.

Аналогичными командами можно получить и разрешение текущего видео:

mplayer $wrkfile -identify -vo null -nocache -nolirc -nojoystick
-channels 6 -loop 1 -frames 1 | grep ID_VIDEO_WIDTH

mplayer $wrkfile -identify -vo null -nocache -nolirc -nojoystick
-channels 6 -loop 1 -frames 1 | grep ID_VIDEO_HEIGHT

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

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

Все, теперь остается сгенерировать превьюшку-картинку для видео. Для этого можно использовать следующую команду из консоли:

ffmpeg -ss $seconds -i $outfile -vcodec mjpeg -vframes 1 -an
-f rawvideo -s $thumb_size preview.jpg

Данная команда сгенерирует картинку в формате jpeg для указанной секунды ($seconds) обработанного видео ($outfile) указанного размера ($thumb_size — в формате 160×120). Таким образом можно сделать несколько картинок-превьюшек для видео и сделать что-то по типу «карусели» при наведении пользователем мыши на изображение, показав ему, о чем видео с помощью картинок.

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

Отдача видео

С этим вопросом я тоже не стыкался до этого в целом. Решено было отдавать видео пользователям посредством Nginx, как веб-сервера. Он позволяет ограничить скорость потока отдачи (мы поставили отдачу в 2М, как лимит), кроме того более оптимально работает, чем апач для этих целей. Более подробно о Nginx можно узнать опять же, в гугле.

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

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

Для решения этой задачи, опять же, использовался Nginx, т.к. он уже содержит готовый модуль для этих целей — http://sysoev.ru/nginx/docs/http/ngx_http_flv_module.html (при условии, что мы отдаем конент в формате flv. Но можно отдавать и в mp4, плагин для псевдостриминга для mp4 для nginx тоже есть — http://wiki.nginx.org/NginxMP4StreamingLite (вполне возможно есть и другие решения)

————————————————————————————

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

Если есть вопросы — пишите, постараюсь ответить, если буду знать ответ и будет время.

P.S. Про HTML5 и Theora можете не спрашивать, активно слежу за развитием в данной области, надеюсь, что скоро вообще не нужно будет использовать сторонние флеш-плееры и видео будет нужно конвертировать только в .ogv. Но пока, на сегодняшний день, технология еще сыровата, есть много проблем с ней, поэтому надеюсь, что скоро все поменяется в лучшую сторону, т.к. предпосылки к этому есть — Firefox уже поддерживает возможность проигрывание видео в HTML5, есть возможность переключения в полноэкранный режим и т.д. Но еще много чего нету. Жду.

Пришлось во многих вещах поразбираться, в том числе с перекодировкой видео, импортами для Яндекс.Видео и Гугл.Видео и т.д.

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

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

Итак, следующая заметка будет на тему создания своего видеохостинга «с нуля». Следите за обновлениями.

P. S. Написал новую заметку про ODesk на фрилансхаке — http://freelancehack.ru/blog/2009/12/odesk-4/ , возможно кому-то будет интересно.

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

Точнее не развитие, а я нашел тему на Хабре от этого заказчика (который впрочем и на моем блоге комментировал довольно часто под ником Andrew), где он конечно не стал указывать, что речь обо мне, но я решил высказаться также, т.к. вышло как будто заказчик белый и пушистый, а я вот такой вот плохой фрилансер, бросил заказчика на полдороги.

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

Возможно мой опыт кому-то пригодиться из читающих меня.

Всегда берите с них предоплату, не менее 30% от стоимости проекта, иначе будет вероятность, что ввиду каких-либо обстоятельств больше вам ничего не заплатят.

Если проект критичен заказчику по времени, то давайте накрутку в 30–40%, при этом озвучивайте, что это накрутка за важность и спешку, чтобы потом не было удивленных лиц по типу «ты много попросил, я согласился только потому, что думал, что ты как фрилансер все сделаешь сам, от а до я, ведь цена у тебя большая, больше, чем у людей, которые у меня работают в офисе и делают все по ТЗ».

Большинство клиентов не понимает, что тестирование никак не входит в стоимость проекта, когда идет речь о разработке движка и это отдельный пункт, который нужно проговаривать сразу, чтобы было понимание откуда береться цена допустим в 2500$ за 3–4 недели работы.

Не откладывайте оплату куска работы ни при каких обстоятельствах на последний день, даже если заказчик говорят, что «пару багов это не 100% сделанная работа, принимать не буду». Баги нужно исправлять, это и ежу понятно, но когда отказываются платить часть денег за этап, кивая на пару мелких багов — повод задуматься, а стоит ли их исправлять и надеяться, что клиент заплатит, иначе можно потерять кучу времени, в результате не увидев никакой оплаты.

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

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

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

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

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

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

С чем себя собственно и поздравляю, а также читателей, которые были и есть со мной на протяжении этих лет

Спасибо вам за вашу поддержку и интерес к моей личности и моим мыслям на IT тематику

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

Как показывает моя практика — в результате создания новой заметки из своих фидаггрегаторов переходит максимум до 40–50 людей. Естественно часть пассивной аудитории, которая только читает и никогда ничего не комментирует (или комментирует редко) намного больше. Однако определить это практически никак не возможно.

Таким образом встает вопрос: а что дают цифры на счетчике? Как на меня это цифра, которая позволяет поднять свое ЧСВ и ничего более.

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

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

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

то сразу броситься в глаза то, что рост был стабилен на протяжении 3/4 времени, тоесть до зимы этого года, когда моя активность в блоггинге приупала, т.к. было много дел (диплом, работа и т.д.).

Таким образом очень удобно оценивать блоггера и его блог по данному графику, делая какие-либо выводы, например при покупке блога или заказе рекламы и т.д.

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

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

Таким образом, я считаю, что считать авторитетным блоггера-тысячника уже неправильно. Планка должна расти. Например, до 2000.

Таких блоггеров не так много (чуть менее 50) и если из их количества исключить еще специальные сайты по типу novate.ru и т.д., то круг сократиться в несколько раз. Вот — теперь в самый раз.

А вообще блоггера лучше оценивать по контенту, а не по цифаркам на счетчиках.

А вы как считаете?