Этим летом мне посчастливилось быть в Торонто. Именно там, а не в привычной всем Долине, находится офис стартапа №1 в Канаде — 500px. Конечно, нельзя было упускать шанс побывать в гостях у известного на весь мир проекта, который, кстати сказать, создали и развивают два «наших» фотографа — москвич Евгений Чеботарев и киевлянин Олег Гуцол. Так что, в одну из пятниц я отправился в гости.

Что такое 500px?

«500px — is a photo community powered by creative people worldwide», — так о своем проекте говорят сами авторы. Я бы добавил, что это лучший сайт с самыми красивыми фотографиями, которые я когда либо встречал.

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

Побывать в офисе у такого проекта и окунуться в рабочую атмосферу было по-настоящему интересно.

Офис

Основное рабочее пространство — open space в большой комнате. Столы расположены «фермами» в несколько рядов по 4-6 рабочих мест в ряду. Рабочие места — друг на против друга.

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

Предисловие

Не знаю, все ли программисты всесторонне любознательные люди, но я всегда пытаюсь получить фундаментальные знания во всех областях, которые могут быть практически полезны. В то время, когда мне в голову пришла эта идея я изучал анатомию и физиологию по журналам «Тело человека. Снаружи и внутри», ну а по работе я занимался стерео-варио фотографиями (для тех кто не знает — были такие советские календарики с ребристой поверхностью, где картинка либо казалась объемной, либо менялась). Так вот, в один из вечеров мне пришла в голову замечательная идея, которую я на протяжении уже 4х лет использую для поддержания своего зрения.
Обещаю, что эффект почувствуете сразу!

Осторожно, трафик! Но можно хотя бы посмотреть картинки )

   Идея создать дома свой «рабочий кабинет» у меня зрела давно – как-то сам дошел до осознания его необходимости, хотя немалый вклад в начинания сделал этот давний пост на Хабре. У меня было своё рабочее место – большой удобный стол, где помещалось практически всё и даже больше… но, по сути, он был проходным двором – все время кто-то ходил, был рядом, отвлекал… такое очень часто мешает сосредоточиться и начать работать. Иногда, бывает, сидишь весь вечер за компом и понимаешь, что абсолютно ничего не сделал, хотя родным заявил «так, мне надо поработать».

На днях я посетил грандиозную тусовку любителей NoSQL — World MongoDB Conference.



Eliot Horowitz, Co-Founder и CTO в MongoDB, рассказал о 3 новшествах, которые будут доступны уже в ближайшем релизе.
Каждое из анонсированных нововведений нацелено на достижение следующих принципов в архитектуре MongoDB:

• Продуктивность разработчика
• Горизонтальная масштабируемость
• Операционная масштабируемость
• Администрирование одного вебсервера должно быть простым. То же самое касается кластеров

Видео презентации можно посмотреть здесь.

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

В данной статье будет рассмотрена одна из новых возможностей MongoDB версии 2.4 — полнотекстовый поиск. Большая часть этой статьи будет вольным переводом документации, которая, к слову, очень подробная, но разрозненная. Здесь все будет собрано вместе. Так как этого для полноценной статьи мне показалось мало, я решил сравнить МонгоДБ с другой популярной программой для текстового поиска — Sphinx. Мое сравнение будет очень поверхностным, так как со Сфинксом я раньше не работал. Создам таблицу с 16 000 000 записей и посмотрю, кто быстрее.

Полная авторская верcия из моего блога. Оригинал материала написан специально для Developers.org.ua

Наверное любой современный веб-проект сложно себе представить без… без контента! Да, именно контент в разных его проявлениях сегодня «правит бал» в различных веб-проектах. Не так важно — создаваемый пользователями или получаемый из других источников автоматически — информация является основной любого (ну, или почти любого) проекта. А раз так — то вопрос поиска необходимой информации стоит очень остро. И острее с каждым днем, ввиду стремительного расширения количества этого самого контента, в основном за счёт создаваемого пользователями (это и форумы, и блоги и модные нынче сообщества, вроде Habrahabr.ru). Таким образом, любой разработчик, реализующий сегодня какой-либо проект, сталкивается с потребностью реализовать поиск в своём веб-приложении. При этом требования к такому поиску уже намного сложнее и шире, чем даже год-два назад. Конечно, для каких-то проектов вполне подойдёт и простое решение, к примеру, вполне можно использовать Custom Google Search. Но чем более сложное приложение, и чем сложнее структура контента, если требуются особые виды поиска и обработки результата, или же просто количество или формат данных в вашем проекте особый, вам потребуется собственная поисковая система. Именно своя система, собственный поисковый сервер или сервис, а не сторонний, пусть даже гибкий и настраиваемый. Но что же выбрать, и вообще — какие сейчас на рынке есть поисковые проекты, которые готовы для использования в реальных проектах, не исследовательских или научных, а реальных бизнес-приложениях? Далее мы кратко рассмотрим различные варианты поисковых решений, пригодных для встраивания в ваше веб-приложение или развёртывания на собственном сервере.

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

Теперь мы обеспечиваем защиту как сервис. Делается это на двух уровнях: установкой железа Radware DefensePro у клиента и при необходимости переключением трафика на наш центр очистки.



Максимальная мощность атаки — 80 Гб/с (на уровень приложений, более мощные тоже фильтруются, но уже без гарантий по отсутствию потерь легитимного трафика), планируем по мере необходимости расширять до 160. Время от начала до отражения атаки на стороне клиента — 18 секунд максимум, на стороне центра очистки данных — до 40 секунд с учётом времени переключения трафика. При переключении потерь трафика не происходит.

На тему «использование MongoDB вместо memcached» гуглится немало историй успеха. Такое ощущение, что есть широкий класс задач, для которых идея работает неплохо: прежде всего это проекты, где интенсивно используется тэгирование кэша. Но если вы попробуете, то заметите, что в MongoDB не хватает функции удаления из кэша записей, которые читаются реже всего (LRU — Least Recently Used). Как поддерживать размер кэша в разумных рамках? LRU — это, кстати, «конек» memcached; вы можете писать в memcached, не задумываясь о том, что ваш кэш переполнится; но как же быть с MongoDB?

Раздумывая над этим, я написал на Python небольшую утилиту CacheLRUd (выложена на GitHub). Это демон для поддержки LRU-удаления записей в различных СУБД (в первую очередь, конечно, в MongoDB). Ферма таких демонов (по одному на каждой MongoDB-реплике) следит за размером коллекции, периодически удаляя записи, к которым доступ на чтение производится реже всего. Отслеживание фактов чтения той или иной записи кэша происходит децентрализовано (без единой точки отказа) по протоколу, основанному на UDP (почему так? потому что «наивный» вариант — писать из приложения в мастер-базу MongoDB при каждой операции чтения — плохая идея, особенно если мастер-база окажется в другом датацентре). Читайте подробности чуть ниже.

Но зачем?

Введение

С помощью LinkedIn Company Lookup API можно получить информацию о компании зарегистрированной на LinkedIn. Искать можно по ключевым словам, а можно и с помощью ID. Например, GET запрос

http://api.linkedin.com/v1/companies::(1337)

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

Ratchet — так называется HTML5-фреймворк для быстрого прототипирования мобильных приложений, который 1,5 года назад создали те же парни, которые когда-то выпустили Bootstrap.

Инструмент позволяет быстро создать красивый интерфейс мобильного приложения — и дает вам красивые стили и замечательные иконки, согласованные с гайдлайном в зависимости от платформы. Можно сделать прототип, а можно завернуть в PhoneGap и без особых усилий получить сравнимый с нативным интерфейс приложения в продакшене.
Фреймворк очень прост в использовании и прекрасно документирован.

Я являюсь поклонником Ratchet с момента выхода первой версии. Тогда он был доступен только под iOS.
Не так давно вышла вторая версия, которая наряду с iOS поддерживает Android. Ура-ура!
(правда, обратной совместимости с первой версией нет)

Кому интересно про новые возможности Ratchet 2.0 — прошу под кат!

Сразу отвечу на вопрос «а зачем?». Просто интересно получить указатель на объект и потом подумать, что с ним особенного можно сделать :) Ведь если получить указатель, то дальше можно сделать все что угодно. Например, становится возможным изучить поведение SyncBlockIndex, или взять MethodTable и изучив, где что находится, изменить его содержимое. Можно мастерить собственные типы данных, не прибегая к Reflection. В общем можно делать много странных вещей, которые относятся больше к спортивному программированию и к саморазвитию. Однако, приступим.

Когда Эдвард Сноуден впервые появился перед видеокамерой летом прошлого года, многие обратили внимание на его ноутбук с наклейками анонимайзера Tor и Фонда электронных рубежей. Сейчас стало известно, какая операционная система установлена на этом ноутбуке: защищённый дистрибутив Linux под названием TAILS (The Amnesic Incognito Live System) на основе Debian.


Раньше дистрибутив назывался Amnesia и базировался на ОС Incognito

Загрузив образ TAILS с диска или флэшки, мы сразу получаем все необходимые инструменты для безопасной работы в интернете: Tor запускается автоматически, GPG для шифрования почты, OTR-чат, парольный менеджер KeePassX и другие программы, многие из которых модифицированы для безопасности. Дистрибутив спроектирован таким образом, что не хранит никакой информации локально (и вообще не обращается к накопителю), чтобы защитить секретные данные в случае, если компьютер попадёт в руки врага, и обезопасить систему от вредоносного ПО. Оперативная память стирается перед завершением работы с помощью sdmem, чтобы злоумышленник не мог восстановить её содержимое с недавно выключенного компьютера. Графический интерфейс может подделываться под Windows XP, чтобы не вызывать подозрений у окружающих.

^{Мыс Доброй Надежды}

С английским у меня беда. Дело в том, что учил я его по MS-DOS и Паскалю, а потом по фильмам. Поэтому читать и переводить в нашу сторону научился хорошо, а вот строить предложения на лету для разговора – нет. А оно сильно надо, потому что у Мосигры всё больше и больше партнёров в Европе. Думаю, у вас такие проблемы не возникают, но вот желание заправить трактор иногда появляется — и живой английский реально нужен почти каждому.


^{Мой заезд: Швейцария, Эмираты, Германия, Канада, Франция}

Поэтому я недолго думая отправился в Южную Африку. Быстрых по визе вариантов с тёплой погодой было три: Мальта (где среди учеников сплошь китайцы, а сам остров можно обойти за два дня), Дублин (с очень интересным акцентом) и Кейптаун (колония Великобритании). Поэтому – вниз, за экватор, и на самый край обитаемого мира. В Африку, к пушистым слонам и пингвинам, копающим норы.

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

Я согласен, такие таблицы нужны, чтобы лучше ориентироваться в несовершенствах оператора… вот только несовершенства в организации данных в самих таких таблицах, на мой взгляд ещё больше усложняют ситуацию. Вот, к примеру, таблица из ссылки, приведённой выше:



Кошмар, товарищи!.. Как по мне, так здесь бóльший беспорядок в очерёдности строк/столбцов.

Салют, Хабр!
Недавно я уволился с довольно завидной должности (главного архитектора) в довольно неплохой компании (Acronis) и с непоколебимым решением в мозгу больше не работать по найму переехал из Москвы обратно в Ереван, откуда семь лет назад понаехал в Златоглаво-Нерезиновую. Учитывая необычность произошедшего и часто задаваемый вопрос «но почему?!», я решил разобраться в собственных мыслях и озвучить их вслух для себя самого и тех, кто может почерпнуть в моих размышлениях что-то для себя полезное. Короче говоря, это рассказ о том, почему я оставил высокооплачиваемую перспективную работу в международной компании ради сомнительной перспективы начать собственное дело, и как я собираюсь дальше жить.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Пост — резюме

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

Google использует своего «паука» FeedFetcher для кэширования любого контента в Google Spreadsheet, вставленного через формулу =image(«link»).

Например, если в одну из клеток таблицы вставить формулу

=image("http://example.com/image.jpg")

Google отправит паука FeedFetcher скачать эту картинку и закэшировать для дальнейшего отображения в таблице.

Однако если добавлять случайный параметр к URL картинки, FeedFetcher будет скачивать её каждый раз заново. Скажем, для примера, на сайте жертвы есть PDF-файл размером в 10 МБ. Вставка подобного списка в таблицу приведет к тому, что паук Google скачает один и тот же файл 1000 раз!

=image("http://targetname/file.pdf?r=1")
=image("http://targetname/file.pdf?r=2")
=image("http://targetname/file.pdf?r=3")
=image("http://targetname/file.pdf?r=4")
...
=image("http://targetname/file.pdf?r=1000")

Все это может привести к исчерпанию лимита трафика у некоторых владельцев сайтов. Кто угодно, используя лишь браузер с одной открытой вкладкой, может запустить массированную HTTP GET FLOOD-атаку на любой веб-сервер.

Атакующему даже необязательно иметь быстрый канал. Поскольку в формуле используется ссылка на PDF-файл (т.е. не на картинку, которую можно было бы отобразить в таблице), в ответ от сервера Google атакующий получает только N/A. Это позволяет довольно просто многократно усилить атаку [Аналог DNS и NTP Amplification – прим. переводчика], что представляет серьезную угрозу.



С использованием одного ноутбука с несколькими открытыми вкладками, просто копируя-вставляя списки ссылок на файлы по 10 МБ, паук Google может скачивать этот файл со скоростью более 700 Мбит/c. В моем случае, это продолжалось в течение 30-45 минут, до тех пор, пока я не вырубил сервер. Если я все правильно подсчитал, за 45 минут ушло примерно 240GB трафика.