Далёкий 1988й год был полон удивительных событий. В этом году увидел свет 4й альбом группы Metallica «...And justice for all», а СССР запустил в свой первый и единственный полёт многоразовый космический корабль «Буран». В этом же году началась история видеосжатия – появился самый первый стандарт видео-кодека.
Самые известные стандарты видеосжатия появились благодаря двум конторам: VCEG и MPEG. Нельзя назвать их конкурентами: некоторые стандарты были выпущены комитетами поодиночке, некоторые стали плодом их запретной любви коллективной работы в составе объединённых групп. По иронии судьбы именно эти «совместные» форматы и получили наибольшее распространение.

1988 год – H.261

Итак, 1988 год. H.261 стал первым полноценным форматом видеосжатия, получившим широкое распространение. Это был «классический» стандарт, работающий в цветовом пространстве YCbCr, базирующийся на дискретном косинусном преобразовании блоков и сжатии Хаффмана. Поднимите руку те, кто слышал о нём? А ведь именно в этом стандарте впервые появились такие понятия, как макро-блок, целопиксельный вектор движения и де-блокинг (или пост-процессинг). А еще именно тогда, 23 года назад, появилась концепция опорных кадров. H.261 предусматривал кадры 2х типов: I(ntra) – полностью независмый кадр, и P(redicted) – кадр, зависимый от предыдущего. Максимальное разрешение CIF (пример приведён слева), поддерживаемое H.261, сейчас не впечатлит даже любителей смотреть видео на телефоне. И тем не менее, для своего времени это был очень прогрессивный, весьма «продвинутый» стандарт. Все последующие стандарты видеосжатия базируются на идеях, берущих свое начало в H.261, и де-факто являются результатом его эволюционного развития.

При реализации одного из проектов на Yii framework у меня возникла задача сделать регистрацию и авторизацию пользователей через сторонние сервисы (Google, Facebook, Twitter, etc).

У данной задачи есть два пути решения:

• Использовать сервис авторизации, например Loginza;
• Реализовывать функции авторизации самостоятельно для каждого сервиса.

UPDATE: Актуальная версия и инструкция по настройке доступны на github.com. Инструкция в данной статье подходит для EAuth версии <= 1.1.3.

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

Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

Люди в течение многих веков упорядочивали важные знания, которые теперь составляют основу правил дизайна. Это знания об общей природе положительных реакций человека. Дэвид Хьюм назвал такую природу «постоянными и универсальными принципами человеческого естества». Правила универсального дизайна не всегда могут быть мерилом всех вещей, но они могут помочь добиться успеха в различных сферах деятельности, включая коммуникации, производство, услуги, технику, искусство и природоохранное проектирование.

Сегодня речь пойдёт об WaterSpout — веб сервере, способном обрабатывать websockets запросы, позволяя общаться в реальном времени между сервером и браузером используя websockets или long polling. Написан он на PHP.

В первую очередь идёт проверка поддерживаются ли websockets (это Chrome, Опера и FF, если включим), если нет, то ничего страшного, будет использоваться long polling.
Преимущества этой технологии: доставка сообщений мгновенна, высокая производительность. Тестировал в Chrome, FF, IE6+.
Демка.

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

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

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

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

Следы от пуль

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

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

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

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

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

Итак, займемся классификацией троллей и их приемов. Сегодня — формальный троллинг. В другой раз троллинг очный.

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

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

Не обманывайтесь — каждый хочет продать свой стартап. Мы все восхищаемся тем, как Groupon и другие компании превращаются в миллиардных гигантов, хотя, в общем-то, это ложь самим себе. Даже Ларри Пейдж и Сергей Брин хотели продать Google за $1 миллион Yahoo в течение 10 секунд после начала работы, однако последняя ответила отказом.

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

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

1. Готовьтесь за год вперед. Основательно готовьтесь ко встрече с каждым, кому вы хотите продать свой бизнес. Начинайте разговаривать с ними уже сейчас. Первая компания которую я продал (в 1998) начала вести переговоры со всеми рекламными агентствами за год до фактической продажи. Я не был готов (всмысле, я бы продал ее сразу, но она была слишком мала), поэтому я держал каждого потенциального покупателя в курсе ежемесячными рассылками. И завтраками или обедами каждые три месяца, просто для того чтобы рассказывать новости о бизнесе, в общем. К тому моменту, когда я был окончательно готов продать компанию, мы получили 4 или 5 срочных предложений. Наконец, мы продали ее компании, с которой я даже не контактировал ранее, но она слышала о нас потому что все остальные обсуждали это.

Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

Чтобы было проще, предлагаю рассмотреть более подробно одну из систем стандарта, а именно АСУДД (автоматизированную систему управления дорожным движением). Тем более, что это сейчас крайне модная тема в нашей стране, где еще сильны иллюзии того, что компьютеры смогут заменить нормальный асфальт, а, может быть, вообще позволят обойтись без дорог.

Введение

Восемь лет назад у меня была идея открыть сеть ресторанов быстрого здорового питания в городе Красноярске. Я достаточно долго проработал в сфере общепита, начиная от официанта, бармена, повара до помощника директора + было неплохое видение будущего бизнеса. При этом отсутствовали всего лишь знания и опыт в области предпринимательства и необходимые денежные средства. Мелочь :-) Но я был полон энтузиазма и намерения воплотить задуманное.

Весьма интересный пост, опубликованный недавно на Хабре, и особенно комментарии к нему подтолкнули меня к описанию, пожалуй, единственной симметричной схемы, действительно обеспечивающей страховку от кражи базы паролей с сервера – схемы Лэмпорта («Lamport hash chain»). Алгоритм на самом деле чрезвычайно прост и предложен автором (L.Lamport) еще в 1981 году. Более того, схема в большинстве учебников уже упоминается как «устаревшая», т.к. целью ее разработки была в первую очередь защита от перехвата пароля на этапе передачи, а появившиеся позднее схемы семейства «challenge-handshake» (CHAP, CRAM) решают эту задачу гораздо более эффективно. А вот о втором интересном свойстве схемы Лэмпорта уже потихоньку забыли – она не требует конфиденциальности аутентификационных данных пользователей, хранимых на серверной стороне (свойство, обычно присущее только асимметричным схемам с сертификатам клиентов). Посмотрим, как можно достичь этого свойства с помощью одной только криптостойкой хеш-функции.

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

Наглядное представление популярных Open Source лицензий

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

За основу были взяты идеи gitimmersion.com, но переведены на русский язык и немного изменены под реалии не-ruby разработки, поэтому спешите любить и жаловать — githowto.com!

Буду чрезвычайно рад любым замечаниям и пожеланиям к проекту.

В разработке банковского ПО данному аспекту системы уделяется наибольшее внимание. Часто, описывая отказоустойчивую систему, используют слова: Fault Tolerance, Resilience, Reliability, Stability, DR (disaster recovery). Данная характеристика — суть способность системы продолжать корректно работать при падении одной или нескольких подсистем, от которых она зависит. Я кратко опишу какие подходы могут применяться в данной области и приведу пару примеров.

Суть языка Brainfuck в том, что мы всегда бегаем по ячейкам ленты, уменьшая или увеличивая значения в них. В циклах мы можем пробегать из одного конца в другой, что-то подсчитывая, зачастую используя много вложенных циклов. Не трудно догадаться, что интерпретация этого языка относительно медленна. Конечно, на современных компьютерах этого практически не заметно, но… Предлагаю небольшой тест: берите написанный вами интерпретатор, и запускайте вот этот не хитрый код:

>+>+>+>+>++<[>[<+++>-
 >>>>>
 >+>+>+>+>++<[>[<+++>-
   >>>>>
   >+>+>+>+>++<[>[<+++>-
     >>>>>
     >+>+>+>+>++<[>[<+++>-
       >>>>>
       +++[->+++++<]>[-]<
       <<<<<
     ]<<]>[-]
     <<<<<
   ]<<]>[-]
   <<<<<
 ]<<]>[-]
 <<<<<
]<<]>.

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