После окончания финального экзамена и выдачи электронных сертификатов, сотрудники MITx 6.002x опубликовали краткую статистику:

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

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

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Доброго времени суток, уважаемое сообщество!

Спешу поделиться с Вами своим опытом выполнения разработки электроники фрилансером. Итак, рассказываем по порядку…

Я занимаюсь разработкой электроники последние 7 лет. Основное место работы – предприятие выпускающее различные охранно-пожарные панели и сопутствующие изделия. На предприятие пришел молодым и неопытным студентом 3-го курса. В течение последующих 2-3 лет мне удалось выполнить несколько проектов, запущенных в производство. Среди них были как обновленные версии ранее выпускающихся изделий, так и новые разработки. Со временем я полностью погрузился в сопровождение производства (более 10000 изделий ежегодно), поэтому новых разработок не начиналось.

Из-за скуки я начал разными способами искать заказы на разработку различных устройств. Почему бы и нет? Ведь так много людей с оригинальными идеями отличных устройств – нужно лишь встретиться и сделать проект. Для этого я зарегистрировался на известной фриланс-бирже Рунета, а также разослал предложения различным предприятиям.

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

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

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



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

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

Вчера задался себе таким вопросом: как можно обезопасить мой профиль в Google Chrome и вообще все данные, которые в нем хранятся? Немножко погуглив, я нашел ссылки на кучу расширений (типа этого), которые позволяют устанавливать пароль как на браузер так и на отдельные его профиле (это логично, если знать как работает Chrome в режиме мультипрофильности). Я начал их устанавливать и сразу тесты на баги. И как оказалось ни один из них не хочет адекватно работать в режиме мультипрофильности. Не очень-то долго думая я решил написать собственное расширение и заодно разобраться в Google Chrome API.

В данной статье представлена пошаговая инструкция по разработке простейшего расширения для FireFox.
Это частичный перевод оригинальной статьи.

Это не моя статья, а моего друга (его мыльце: templar8@gmail.com). Он очень хочет попасть на Хабр. У меня самого не хватает кармы для инвайта.

В последнее время вебмастера используют семантическую микроразметку все чаще: по нашим данным, сейчас 10% страниц рунета размечены, и это число постоянно растет. А вслед за популярностью микроразметки растет и потребность вебмастеров в дополнительных ее видах. И не только тех, которые поддерживает Яндекс. Именно поэтому мы решили сделать валидатор микроразметки в Яндекс.Вебмастере универсальным. Для начала мы научили его проверять корректность всех типов разметки Schema.org и microdata.

Пример валидации разметки Product (Schema.org):

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

Но все же я продолжаю настаивать на той точке зрения, что работа это для рабов. Это скрыто в самом названии слова. Работа это то, что делается от нужды, через силу. Под давлением обстоятельств. То, чем человек не стал бы заниматься имей такую возможность. Работа не может быть любимой — это самообман.

В противовес работе есть другое слово — дело. Дело это то, что захватывает, приносит удовольствие. То чем бы человек занимался даже если бы ему пришлось за это платить. То, чем можно гордиться, что является предметом самореализации. Любимое дело раскрывает потенциал человека, высвобождает чудовищную производительность и самоотдачу. Желание сделать лучше и совершенней. А раз так, то резко растет качество и эффективность труда. И, естественно, возрастает доход с дела. За качество готов платить каждый из вас, я в этом не сомневаюсь.

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

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

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

Откуда пошла дурацкая привычка сохранять счета, бухгалтерские и финансовые документы в формате MS Excel? Зачем хранить и передавать документы, предназначенные для печати в формате электронной таблицы, если есть специальный формат PDF? Однако, во всех бухгалтерских программах документы в первую очередь обязательно экспортируются в MS Excel и уже потом предлагаются альтернативные способы сохранения документов. От сюда и возникла задача: пусть бухгалтер сохраняет свои документы как хочет, но клиент должен получить их в формате PDF и обязательно точно в том образе, который бухгалтер сваял в шаблоне MS Excel.
В качестве бухгалтерской программы мы использовали бесплатную ВС: Бухгалтерию. (По правде сказать из этой программы можно сразу сохранять документы в PDF, но раз сказали excel, значит – excel.)
Бухгалтер выгружает XLS-файл в определенный каталог на диске, откуда мы должны его забрать, перевести в PDF и сохранить в другой каталог. Все это должно быть реализовано в виде веб-сервиса, то есть клиент должен увидеть и иметь возможность скачать свои pdf-документы в «Личном кабинете» на сайте.

Пути решения:

Первое, что захотелось сделать, – это отыскать готовую библиотеку для PHP или Perl и прямо «на лету» конвертировать файлы.
Такие библиотеки для работы с форматом Excel действительно нашлись, например: PHPExcel, PHPExcelReader, Spreadsheet::ParseExcel и др.
Эти библиотеки действительно хорошо работают, но делают именно то, для чего предназначены: выискивают данные в электронной таблице Excel и оперируют с ними.
Нам же нужно совсем иное – получить экселевскую таблицу в виде как для печати, со всеми картинками с печатями и подписями, с форматами шрифтов, и ячеек.

Второй вариант решения — виртуальный принтер. Суть его в том, что мы открываем файл в подходящей программе и отправляем его на печать, но не на настоящий принтер, а – на виртуальный, который вместо бумаги сохранит в файл, сначала в постскрипт формате ps, а потом сделает из него файл PDF.
Поскольку система ко всему еще и должна функционировать как веб-сервис, я выбрал в качестве платформы Linux с Apache. А в качестве программы, которая умеет открывать все файлы MS Office – бесплатный OpenOffice.org 3.4

Итак, что делаем:

Устанавливаем OpenOffice. В руководстве по по установке конвертера PyODConverter предлагают устанавливать версию OpenOffice.org 2.4 обязательно -headless, но я просто установил OpenOffice.org 3.4 из репозитория и все получилось.
После установки я попробовал запустить программу, но система отказалась, захотев еще Java Runtime Environment. А нужен ли он? Оказалось, что нет. И запускать OpenOffice целиком, чтобы отправить файл на виртуальный принтер вовсе ни к чему. У программы есть прекрасный конвертер в pdf, который легко вызвать из командной строки.

Делается это так:

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

Несколько месяцев назад мы стартовали масштабный эксперимент и смонтировали два объекта, работающих на альтернативной энергии. Задача – понять, могут ли автономные комплексы небольшой мощности работать более-менее стабильно и иметь коммерческую перспективу в РФ.


Cолевая батарея нового поколения

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