Привет.

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

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

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

Агентство McKinney по заказу благотворительной организации Urban Ministries of Durham разработала Spent — финансовый симулятор жизни обычного американца, который получает 9 долларов в час, то есть минимальную зарплату. Попробуйте сыграть и продержаться хотя бы до конца месяца — и вы точно поймёте, почему в США выдают чеки еженедельно.

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

Проект Spent запущен в феврале 2011 года, он взял главный приз (Best in Show) на рекламной конференции OMMA 2011, где отмечают самую креативную интернет-рекламу года. К августу 2011 года игровой счётчик перевалил за миллион запусков, а агентство McKinney составило открытое письмо в Конгресс США с призывом к каждому конгрессмену потратить 10 минут на эту игру.

Третья и заключительная часть стенограммы-трилогии (см. часть 1 и часть 2) доклада про Дополненную Реальность.

Речь пойдет об обработке изображений в применении к дополненной реальности:

• детектирование маркеров и меток;
• многокамерные системы маркерного захвата движений;
• структурированная подсветка;
• Z-сенсоры (в частности, Kinect);
• использование баз данных поз;
• чисто оптические системы захвата движений.

И на закуску — субъективный взгляд на будущее дополненной реальности, который прояснит смысл картинки с собакой.

Аннотация

Представляю вашему вниманию материалы одноименного доклада, сделанного мной на конференции ADD-2010 осенью прошлого года.

В докладе после краткого экскурса в историю рассматривается текущее¹⁾ состояние дел в освоении дополненной реальности:

• использование датчиков: акселерометры, гироскопы, магнитные компасы, GPS
  (различные мобильные телефоны, Wii, Sony Move, XSens)
  
• использование маркеров: с инфракрасной подстветкой, в видимом диапазоне
  (Sony Move, OptiTrack, Vicon)
  
• использование структурированной подсветки
  (на примере Microsoft Surface)
  
• Z-камеры, выдающие картику + расстояние до объекта
  (Microsoft Kinect, её предшественники и аналоги)
  
• безмаркерный захват движений
  (OrganicMotion, iPi Soft Desktop Motion Capture)
  
• сканирование 3d-поверхности по набору изображений:
  (стереокамеры, 3d-сканеры, воссоздание 3d-сцены с движущейся камеры)
  

После небольшого перерыва продолжаю переводить видео. Пока еще осталось несколько роликов с Ричардом Фейнманом.

В этот раз знаменитый физик пытается объяснить, насколько сложны вопросы «почему?». Если честно, то мне приятнее осозновать, что на любой ответ можно задать еще десяток «почему?», такая бесконечная рекурсия природы может и немного пугает, но зато гарантирует интересные вещи! Было бы очень обидно, если бы существовал конечный ответ…

(Оригинал ролика на английском языке)

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


И так начнем. Нашим подопытным будет плеер YouTube.

Здравствуй хаброчеловек!

Так уж случилось, что с этого семестра в своем вузе я записался на спецкурс по паттернам проектирования. Курс проходит в виде семинаров, на которых ты (студент) должен рассказать чему научился за неделю (имеется ввиду, какие паттерны изучил и применил на практике).

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

Это очень важное решение, которое создаёт прецедент. Во-первых, теперь полностью легализован обмен виртуальной валюты на реальную, даже в играх, где это запрещено правилами игры, например, в WoW. То есть корейские пользователи могут делать это, не опасаясь уголовного преследования (хотя игровой аккаунт у них всё равно могут закрыть, потому что игра принадлежит американской фирме Blizzard).

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

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

Я достаточно часто сталкивался с подобным мнением и не придавал ему особого значения, но когда женский коллектив нашей организации поздравил программистов с 23-м февраля по доброму назвав их «космическими войсками», решил всё же расставить определенные акценты в данном вопросе, т.к. одна из моих профессий связана напрямую с психоанализом. Да и баш уже не молчит.

Учёные уже полностью дизассемблировали H1N1 и занесли его в вирусную базу NCBI Influenza Virus Resource. Там всё задокументировано в подробностях. Например, образец A/Italy/49/2009(H1N1) был обнаружен в носу 26-летней женщины, вернувшейся из Италии в США. Вот первые 120 бит его генетического кода.

atgaaggcaa tactagtagt tctgctatat acatttgcaa ccgcaaatgc agacacatta

Сколько бит убьёт человека?
По приблизительным подсчётам, общий размер исходников H1N1 составляет 26 022 бит, а если исключить служебные стоп-сигналы (указывают на окончание каждой белковой последовательности), то исполняемый код состоит примерно из 25 054 бит. Это число является приблизительным ещё и потому, что в вирусе присутствует механизм генерации избыточного мусора для маскировки от антивирусов.

Итак, получается около 25 килобит или 3,2 килобайта. Таков объём кода для программы, имеющей ненулевые шансы убить человека. H1N1 написан гораздо эффективнее, чем компьютерный вирус MyDoom размером около 22 КБ.

Очень унизительно, что меня могут убить всего 3,2 КБ генетических данных. Впрочем, в 850 МБ человеческого генома по любому должны быть дыры для парочки эксплойтов.

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

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

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

Задача

Нужно написать настоящий сервис на эрланге, который будет работать в кластере. Кроме того, нужно максимально упростить жизнь тем, кто будет обслуживать сервис.
Требования:

• У сервиса будет RESTful интерфейс (это модно и современно)
• основные настройки сервиса должны быть вынесены в маленький файл с понятным синтаксисом
• сервис должен писать опциональный access-лог
• сервис должен запускаться через upstart

Для простоты сервис будет представлять собой счетчик, который каждому клиенту выдает увеличивающееся с каждым запросом на 1 целое число (уникальное до перезапуска счетчика).

Технологии

Выберем все самое модное и современное:

• HTTP-сервер — cowboy 0.10.0
• логгер — lager
• система сборки — erlang.mk
• сборщик релиза — relx

Мы продолжаем рассказывать о технологиях, используемых на нашем сервисе email-маркетинга Pechkin-mail.ru. Одной из ключевых задач любого сервиса, связанного с данными клиентов, является загрузка этих данных на сервис. Для Печкина очень важно быстро и без проблем для пользователя загружать адресные базы, содержащие email-адреса, имена, фамилии и другие дополнительные данные.

Что использовать в качестве инструмента?

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

• это стандартный инструмент, которым на базовом уровне владеют 100% пользователей компьютеров. Более того, в бизнесе — это де-факто корпоративный стандарт и используется даже, если на рабочих компьютерах Mac или Linux.
• Практически все CRM-, CMS-, облачные или десктопные системы имеют экспорт в Excel или CSV, который простым пересохранением приводится к формату XLS или XLSX.
• Известно также, что “90% ошибок ПО сидит в полуметре от монитора”. Не в обиду будет сказано рядовым пользователям, но мы должны учитывать самый базовый уровень подготовки и тех. поддержке для объяснения достаточно сказать “Загрузите Excel-файл”, а не объяснять процедуру подготовки файла в нужном формате.

Проблему пользователей при импорте адресных баз сняли. Но тут возникает уже проблема непосредственно разработки.

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

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Grunt — это инструмент для сборки javascript проектов из командной строки с использованием задач. Релиз вышел совсем недавно, автор Ben «Cowboy» Alman, проект есть на github. В этой статье я рассмотрю основы Grunt, его установку и использование.

К написанию этого материала меня побудила статья и назревшая необходимость адаптации нескольких своих сайтов к поддержке Retina-дисплеев. Под адаптацией я понимаю подготовку изображений высокого разрешения на страницах сайта.

Пожалуй лучшим способом адаптации на сегодняшний день является способ c background-image в CSS. Но он сложно применим к обычным изображениям в теге . Поэтому я решил определить для себя список необходимых мер по достижению результата в комплексе и продолжить поиски решения. Ниже описано два способа, каждый из которых применим к своим задачам. Показанные решения не претендуют на открытие, скорее это агрегация существующих способов, описанных ранее моими коллегами по цеху веб-разработок и небольшие собственные дополнения.

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

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

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

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.