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

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

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

Здравствуйте!

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

Дисклеймер: если вам кажется, что текст направлен определённому человеку, а не аудитории в целом, то так оно и есть, но менять я ничего не буду.

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

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

Этот пост о том, почему в инженерной среде важны книги и почему их по-прежнему нужно писать — и читать тоже.

Всем привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. В свободное время я люблю искать баги. В сегодняшнем посте я хочу рассказать об одной довольно интересной уязвимости, которую я нашёл и зарепортил в bug bounty нескольких крупных компаний, за что получил солидное вознаграждение. Уязвимость заключается в следующем: если сформировать специальный видеофайл и загрузить его на сервер, то:

• можно получить на нём SSRF;
• можно получить local file read;
• если пользователь скачает этот файл, то автоматически будет подвержен уязвимостям, даже если его не откроет: можно будет получить доступ к данным на компьютере пользователя и узнать его имя.

Знакома ли вам ситуация, когда в контекстной рекламе для привлечения внимания используется название конкурента, а ссылка дается уже на свой рекламируемый сайт?
Кажется, что такими низкими методами никто не пользуется со времен «лихих девяностых». Ан нет! То ли они у нас в сердцах, то ли дело вовсе не в годах.

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

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

К моему удивлению, предыдущую статью приняли достаточно тепло. Сегодня продолжим рассмотрение этого вопроса.

Продолжу начатую в моей предыдущей статье работу по оптимизации алгоритма. Вкратце расскажу, что было сделано. Были взяты готовые java исходники и каскадная модель одной из реализаций алгоритма Виола-Джонса. Данный алгоритм используется для поиска объектов на фотографии, в частности для поиска лиц. Тестирование проводил на своем телефоне, по результатам было получено, что изначальный код на java работал 54 секунды на фотографии размером 300 на 400. Это было слишком медленно, переписанный мною код на C++ показал результат в 14 секунд. В комментариях было предложено догнать java-реализацию до C++ следующим образом: отпрофилировать и найти узкие места, и заменить двумерный массив на одномерный. Также у меня в планах было распараллелить алгоритм на C++. Все было сделано и исследовано, результаты ниже.

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

Совсем недавно я уже писал о том, сколько нужно получить загрузок для ТОП-10 бесплатных игр App Store. Сегодня хочу продолжить эту тему и рассказать о более значительных рубежах в рейтингах онлайн-магазина от Apple, а также о том сколько органических инсталлов можно получить с самых высоких позиций. Мне правда, так и не удалось поднять на первое место общего ТОПа, но я был к этому очень близок, и помешала мне только компания Viber. В общем дело было так:

На 31 августа был запланирован релиз моей игры 1-2-3-4 Premium. В российском App Store она стала видна на день раньше в 21:00 по московскому времени, и тут же началась активная PR-кампания. В ТОП-10 игр удалось попасть уже к 14:00, и для этого, как и в прошлый раз мне понадобилось около 6000 загрузок, которые, правда, на этот раз удалось сделать менее чем за сутки, потратив около 500 долларов.

Готтфрид Свартхольм / Getty images

Готтфрид Свартхольм, один из основателей известнейшего торрент-трекера The Pirate Bay, был арестован в Дании сразу же после того, как вышел из тамошней тюрьмы, отбыв положенный ему срок. Официально арест был произведён из-за того, что по какой-то причине он не досидел месяц в своей родной Швеции, в которой он ранее отбывал наказание. Теперь он будет экстрадирован в Швецию с целью отбывания этого месяца в тюрьме.

Свартхольм в 2003 году стал одним из основателей TPB — а кроме этого был IT-активистом, принимал непосредственное участие в развитии Пиратской партии Швеции. Он помогал Wikileaks — в частности, участвовал в публикации скандальной видеозаписи т.н. «багдадского авиаудара». Эта 30-минутная запись была опубликована в апреле 2010 года.

12 июля 2007 года в иракской столице произошёл инцидент, известный как Сопутствующее убийство (Collateral Murder). В результате обстрела иракцев двумя вертолётами армии США погибли несколько десятков человек, большинство из которых не были повстанцами. С вертолётов AH-64 Apache американцы из 30-миллиметровых пушек стреляли в иракцев на улице, после чего ракетами AGM-114 Hellfire уничтожили целое здание. В результате погибли, в том числе, 2 репортёра Reuters, а также женщины и дети.

Прошёл почти год с тех пор, как Microsoft купила за $2,5 млрд шведскую компанию Mojang AB, разработчика известной игры Minecraft.

Маркус [Нотч] Перссон после этой сделки стал миллиардером. По оценке Forbes, личное состояние разработчика оценивается в $1,3 млрд.

К сожалению, деньги не принесли радости. Сегодня Маркус опубликовал серию очень печальных твитов, которые вызывают сочувствие и беспокойство за него.

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

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

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

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

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

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

На написание этого опуса меня сподвиг данный пост, так как в нем некоторые моменты освещены недостаточно подробно. Ниже я опишу на собственном примере реализацию автоматической качалки торрентов с Lostfilm-а пр помощи FlexGet и Deluge. Все будет проиходить под Ubuntu 9.10

Автор: maxim_korobtsev, WorkAndPlay.Ru

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

Фиксить баги скучно, если не превращать это в игру. Особенно, если речь идет о низкоприоритетных багах, которые не были исправлены в свое время из-за незначительности. Но, обо всем по порядку!

Как все начиналось?

Все началось за несколько месяцев до Багатлона, когда мы, Work&Play, вместе с OK придумывали игровые механики и само соревнование. Родилась достаточно неплохая идея: расфасовать все множество накопившихся низкоприоритетных багов по группам (коробкам с багами). Для каждого бага заранее указать навыки, которые он прокачивает у того, кто его фиксит или проверяет. Далее раз в несколько месяцев устраивать соревнование. Причем, победителем будет не тот, кто больше пофиксил, а тот, кто больше всех прокачался пока багфиксил. Также хотелось, чтобы вся игра проходила без отрыва от работы(в рабочие дни), по тикетам из багтрекера и доступ к ней был прямо из Jira.

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

Что у нас получилось в итоге?

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

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

В чем проблема? — спросите вы. Ставишь серваки с большими дисками, настраиваешь балансировщик — и понеслась. Однако опытный видео-ниндзя знает, что проблем тут целый ворох:

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

Да, это



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

Перед вами очередная история инди разработчика без счастливого финала. Я Android быдлокодер разработчик уже три года и большую часть из них вне закона на Google Play.