Аппарат фотографа Джона Хеллера, стоимостью в $9,000, был украден на съемках в Голливуде. После того как тот потерял всякую надежду вернуть свой Nikon D3, он решил воспользоваться сайтом GadgetTrak который сканирует Flickr и другие фото сайты на наличие фотографий с данным серийным номером.

За несколько секунд он нашел фотографии сделанные своим аппаратом. При помощи полицейских он вернул свой аппарат и теперь сервис для слежения стал любимым сайтом для полиции Лос Анджелеса для поиска украденных фотокамер.

Хотите попробовать? Можете поискать бесплатно. там содержится 10 млн серийных номера и он проверяет такие сайты как 500px.com и Flickr на недавние снимки. также учтите что вам придется записать серийный номер своей камеры как можно скорее чтобы все сработало.

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

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

Немного статистики:

• 5% американцев узнает о скидках в Твиттере;
• 70% известных компаний работают в Твиттере, в среднем у них 1500 фолловеров;
• 80% компаний, присутствующих в Twitter, твитят еженедельно, 40% отвечают клиентам.

Я уже достаточно давно провожу технические интервью с кандидатами на позицию Software engineer и на моем счету их имеется несколько десятков. Сегодня я попробую сформулировать основные моменты, которые лично мне, как интервьюеру, кажутся довольно важными.

Советы довольно очевидные (хотя, как показывает практика, бывают и те, кто не знает этих очевидных вещей) и субъективные.

Полезная и удобная сокращалка адресов типа
plus.google.com/набор_всяких_цифр в
gplus.to/your_own_nickname

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

p.s. спасибо Kpyto за наводку.

Обладатели неновых смартфонов со скромным объемом оперативной памяти (160 в моем случае) очень скоро начинают ощущать тормоза при работе. Поставил буквально несколько программ, а переключение между ними уже сопровождается ощутимыми задержками, и вызов Quick Settings становится уже совсем не «quick».

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

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

Итак, вот и наступил тот долгожданный день (хотя конечно стоить отметить, что мы гораздо раньше собирались выпустить апдейты), когда вышли обновления приложения Геопланировщик. Данное приложение уже описывалось у нас ранее http://habrahabr.ru/blogs/android/114297/. Как известно, главной проблемой, которая возникала ранее — это невозможность работы программы по сети, и обновления в большей своей степени должны были решить именно эту проблему, однако, мы увидели намного больше изменений, не зря версия программы поднялась на одну старшую цифру.

Mail.Ru — огромный портал, существующий более 15-ти лет. За это время мы прошли путь от небольшого веб-проекта до самого посещаемого сайта рунета. В состав портала входит огромное количество сервисов, у каждого из которых своя судьба, и над каждым из которых работает отдельная команда. Разработчикам пришлось как следует потрудиться, чтобы на всех проектах — и новых, и старых, и тех, которые присоединились к порталу по мере его развития, — использовалась единая система авторизации. А через много лет перед нами встала фактически обратная задача: разделить пользовательские сессии. О том, зачем мы это делали, какие трудности нас ожидали и как мы их обошли, я расскажу в этом посте.

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

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

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

Достаточно много интереса проявляется среди технического сообщества к Docker и Ansible, я надеюсь, что после прочтения данной статьи, вы тоже разделите этот интерес. Вы так же получите навыки практического применения Ansible и Docker в настройке сервера и окружения для Rails приложения.

«Почему бы просто не взять и использовать Heroku?», спросите вы.
Прежде всего, я могу запустить Docker и Ansible на любой машине, с любым хостинг провайдером. Во вторых, я предпочитаю гибкость, удобству. Я могу, таким же образом, запускать все что угодно, не только web приложения. Ну и напоследок, потому что я эксперементатор в душе, я получаю удовольствие от понимания того как оно все вместе работает. Фундаментальная основа Heroku это Linux контейнер. Та же технология лежит и в основе Docker'a. На самом деле, одним из девизов Docker'a является «Контейнеризация это новая виртуализация»

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

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

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

Если для вас такое состояние дел кажется близким и знакомым — добро пожаловать под кат.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

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

Для их реализации мы исследовали и опробовали некоторое количество инструментов, среди которых были Apache JMeter и написанный нами на Python скрипт LogSniper, который выполнял реплей заранее подготовленных серверных логов с HTTP-запросами на цель.

Определяем места, где стоит подстелить соломку

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

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

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

Готовимся к любым падениям

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

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

Соотносим потребности бизнеса с его возможностями

В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:

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

И все бы ничего, если бы не ограниченные финансовые возможности организации, не позволяющие приобрести все необходимые резервы для оперативного восстановления. По этой причине заключительная задача планирования аварийного восстановления – поиск баланса между потребностями и финансовыми возможностями бизнеса, и закрепление его в виде соглашения об уровне обслуживания (Service Level Agreement – SLA) в части устранения возникающих инцидентов.

Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:

Исповедь 1

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

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

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