Почти все продвинутые зеркальные камеры, а также некоторые правильные мыльницы, позволяют управлять собой с компьютера. Программное управление камерой дает интересные возможности, например: съемка time lapse video, сопряжение камеры с микроскопом, эксперименты в области компьютерного зрения. Для управления камерой вендоры предоставляют свои проприетарные SDK, которые обычно работают исключительно под Windows и поддерживают камеры только в рамках определенной линейки (например у Canon есть аж 4 несовместимых между собой SDK). Какое счастье, что есть достойная открытая альтернатива — проект gphoto.

Прямо сейчас gphoto поддерживает 1598 моделей камер и список постоянно растет. Проект собирается под все UNIX-like ОС, включая Linux и Mac OS X. Съемкой можно управлять как при помощи command line утилиты, так и из своей собственной программы, используя библиотеку libgphoto. Доступны биндинги для разных языковых платформ, включая node.js.

В современных ОС присутствуют встроенные средства для работы с цифровыми камерами — как правило под «работой» подразумевается только выгрузка фото из камеры. Эти встроенные механизмы препятствуют работе gphoto, так как захватывают USB устройство в эксклюзивном режиме. Особенно интересно дела в этом плане обстоят в Mac OS X — ОС не предоставляет никаких штатных возможностей для отключения, но при этом система поддержки цифровых камер легко поддается реверс инжинирингу.

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

Это заметка о подходе к реализации автоматизации механизма psd to html.

Человек — ужасно ленивая зараза. Нет, ну я не о вас, конечно! Ну что вы! Я так, о себе. О 99% человечества. Но не о вас, нет. Вы сами за себя решайте. Но вот те 99%, так уж вышло — ужасно ленивы. Кто-то это отрицает, кто-то мирится, кто-то борется. А лично мне кажется, что это такая же неотъемлемая черта нашего вида, как, например, две руки и две ноги. Можно убиваться, что у нас нет крыльев или жабр — а можно научиться хорошо пользоваться тем, что есть. Так же и с ленью. Зачем её отрицать? Надо её использовать по-полной. И вот тут, поскольку мы с вами имеем кое-какое отношение к ИТ, давайте посмотрим, как с этим обстоит дело в нашей профессии.

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

Просматривая одно из обучающих видео "Школы разработки интерфейсов" Яндекса, наткнулся на ссылку на офигенный труд израильской веб-программистки Тали Гарсиэль (Tali Garsiel) "How browsers work" (Как работают браузеры).

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

Когда на 90% компьютеров был установлен IE, приходилось мириться с тем, что это загадочный «черный ящик», однако теперь, когда более половины пользователей выбирает браузеры с открытым исходным кодом, пришло время разобраться, что скрывается у них внутри, в миллионах строк программного кода на C++...

Пролистав, я был поражен — отличная работа. Внутреннее устройство браузеров, алгоритмы разбора — все хорошо иллюстрировано, доступно и понятно. И без излишних подробностей, страниц на 30-40. Как раз то, что нужно. Решил — это надо обязательно перевести. Покопался еще немного — оказалось перевод уже как 1,5 года есть!

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

Под катом содержание перевода, чтобы решить стоит ли читать.

Всем привет.

Небольшая шпаргалка для новичков, и всех остальных кто забыл, по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Это статья была написана для людей, которым всегда интересно знать как работают разные вещи. Для тех разработчиков которые обычно пишут свои программы на высоком уровне, C, C++ или Java — не важно, но при этом столкнулись с необходимостью сделать что-то на низком уровне. Мы будем рассматривать низкоуровневое программирование на примере работы bootloader-а.

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

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

Идея использовать git для хранения всех своих фотографий.

Чего хотелось добиться?

1. Скидывать фотки одной кучей (DCIM), а когда будет время сортировать по папкам.
2. Скинуть фотки с одного компа, а работать с ними с другого.
3. Чтобы перемещение-переименование фоток и папок волшебным образом синхронизировалось на всех компьютерах.
4. Чтобы можно было редактировать фотки, но иметь возможность восстановить оригинал.
5. Чтобы сохранялась история правок.

Как оказалось, GIT с большим трудом справляется с этой задачей.

Vim — уникальный по своей гибкости редактор, который при должной настройке может едва ли не идеально удовлетворять все пожелания работающего с ним. Правда эта настройка может продолжаться месяцы, а то и годы, что является и достоинством, и недостатком vim’а. Существует множество статей и туториалов по использованию Vim для разработки на Python и Django, надеюсь мне удастся рассказать что-то новое. В своей статье я постараюсь по минимуму упоминать плагины общего назначения, вроде NERDTree или surround.vim и опишу несколько более специализированных расширений и настроек, которые существенно упростили процесс работы на Python.

«Что? Стивен Кинг „Как писать программный код“ ?! Нет такой книги! Да он вообще не программист ни разу!».
Да, так и есть. Тем не менее — книга с таким содержанием у него есть. Хотя он и не думал, что пишет её об этом. Хотя в результате написал. Хотя, наверное, и не знает об этом. О чём же я тут рассуждаю? О недавно прочитанной мною прекрасной книге «Как писать книги» (англ. — «On Writing»).

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

Бен Кэменс обнаружил, что в выпадающем списке Shop by Department на сайте «Амазон» ховер-эффект происходит очень быстро, абсолютно без какой-либо задержки. Тем самым происходит нарушение старого, выработанного ещё в 90-х годах прошлого века правила: перед отображением пункта подменю необходим так называемый гистерезис, запаздывание.



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

Техника – это способ справиться с заданием, и у нас, разработчиков и дизайнеров фронтэнда, этих способов бывает достаточно много. При это, будучи погруженными в рутинную работу, мы порой не всегда замечаем как стремительно меняется окружающая нас сфера. В период с 2002 по 2010 годы сообщество фронтэнд-разработчиков буквально покрывалось язвами избыточного кода и ресурсов, от которых страдали и работа сайтов, и удобство их использования. Чтобы с этим справиться, мы придумали уйму хаков, трюков и уловок под кодовым названием «техника». Мы по-прежнему продолжаем выполнять поставленные перед нами задания, просто используем не самые эффективные способы.



Оборачиваясь назад, отметим, что в последние несколько лет установились новые, лучшие, стандарты и способы их применения, позволяя нам создавать более продвинутые «техники». Этот новый мир, открытый перед нами, называется «modern web». Web 2.0, которым восхищались в свое время, сегодня для нас стал запутанным и застойным. С одной стороны нет сомнений в том, что подобная судьба постигнет и то, что мы называем «modern web». С другой — пока что мы можем использовать этот термин и злоупотреблять им сколько угодно, пока понимаем, что он означает.



В 2010 появился стандарт HTML5, обеспечивающий совершенно новую, полустандартизованную веб-среду. Такие браузеры, как Opera, Firefox, Chrome и Safari приняли нововведения, и их разработчики вышли за пределы реализации стандартов и изучения интерфейса программирования приложений. Чтобы представить себе, насколько автономны эти браузеры, можно ознакомиться с отличной наглядной демонстрацией поддержки HTML5 на www.html5readiness.com.

Привет, Хабр. Некоторое время назад я рассказывал, как мы в Parallels реализовали софтверное решение для организации распределенного облачного хранилища. На прошедшем в начале февраля Parallels Summit был официально анонсирован Parallels Cloud Server. На его представлении прозвучало несколько любопытных фактов, в том числе был получен ответ на вопрос о ценах, который волновал читателей прошлой статьи. Тех, кому интересно, приглашаю под кат.

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

Все мы знаем как хорошо и похвально принимать участие в разработке открытых проектов.
К тому же потом можно мерятся количеством коммитов в rails и зарплату попросить побольше.

А что если вы решили написать свой open source проект?

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

AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.

В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).

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

Проблемы бывают разные. Те, которые связаны с багами софта, железа или мозга клиента приходится локализовывать и передавать кому следует. Это не так интересно.

Гораздо интереснее заморочистые задачки.

Как то:
OSPF пиринг поднимается и падет через некоторое время.
Маршруты, полученные Route Reflector'ом по BGP не анонсируются клиентам.
Не работает Inter-AS Option C.

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

В этой статье мы подготовили для вас подробную пошаговую инструкцию «Как сдавать экзамен Cisco?» и делимся своим опытом успешной регистрации на экзамен и особенностями процедуры его прохождения.

Что представляют собой центры тестирования Pearson VUE? Сколько длится и стоит сертификационный экзамен? Как правильно зарегистрироваться на экзамен, чтобы получить весомую скидку? Как он проходит? Это вопросы, которые есть у всех, кто еще только хочет получить сертификат Cisco.