Прекрасный продукт, решающий проблему, которая никому не нужна – провалится. Уродливый продукт, решающий реальную проблему, может стать успешным.

Пост, разъясняющий некоторые вопросы по статье "Дриббблификация дизайнеров"

Существует замкнутый круг непонимания дизайна

Годами важность хорошего дизайна в разработке ПО недооценивалась и оставалась непонятой. Дизайнеры всего мира жаловались, что отдел разработки просто заказывает визуально воплотить те идеи, которые уже утверждены кем-то другим. Они иронически называли себя «обезьянами с Фотошопом». Они постоянно находились в поисках новой работы и новых команд. Они знали, что то, чем им приходилось заниматься – это не дизайн.

Доброго времени суток!

В этом году у меня появилась возможность сходить на выставки в рамках Фотобиенале-2012, посмотрев афишу моё внимание привлек фотограф Даг Меньюз. Его проект в основном посвящен Стиву Джобсу в период 1986-2000гг., но постепенно работа вышла за рамки одной личности и серия фотографий превратилась в летопись компьютерных технологий.
Я не планировал писать статью когда шёл на выставку, потому что о ней можно почитать и посмотреть, но после неё мир перевернулся я был поражен историей рассказанной фотографом на столько, что решил пересказать её хабрасообществу. Проект представляет из себя 50 фотографий с аннотациями которые написал сам Даг Меньюз. Трафик ~3Мб и много текста.

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

Во второй части я хотел сформулировать и изложить пошаговое практическое руководство, т.е. некий HowTo о том, как купить какие-то конкретные акции на бирже NASDAQ или NYSE. Допустим, вы захотели купить акции какой-то конкретной компании, например, Google, Apple, Microsoft, Yandex, Intel или Tesla Motors с целью инвестиций (в расчёте на рост стоимости этих акций в будущем).

Что для этого нужно, и с чего вообще начать?

Представляю очередной выпуск обзора наиболее интересных материалов, посвященных теме анализа данных и машинного обучения. Как всегда есть материалы по алгоритмам машинного обучения (в том числе Deep Learning). Несколько практических статей по популярному пакету для машинного обучения Scikit-Learn для Python. Есть статьи, посвященные практическому применению языка R. Некоторое количество материалов посвящено теме Data Engineering. Присутствуют интересные статьи про популярные проекты 'Google Brain' и 'Project Adam'.

Идея данной статьи возникла у нас после прочтения статьи «Как работает автоматическое выделение документа на изображении в программе ABBYY FineScanner?», опубликованной на Хабре компанией ABBYY, в которой подробно описан алгоритм определения границ документа на образе, полученном камерой мобильного телефона.
Статья, безусловно, интересная и полезная. Мы, «с чувством глубокого удовлетворения» отметили, что ABBYY использует в работе те же математические алгоритмы, что и мы, и благоразумно опускает некоторые детали, без которых точность определения границ документа существенно снижается.
Думаю, что по прочтении статьи у некоторой части читателей возник резонный вопрос: «А что делать с обнаруженным на снимке документом дальше?» Отвечу словами Чеширского Кота Алисе: «А куда ты хочешь прийти?» Если конечная цель – «вытащить» из снимка текстовые данные, тогда нужно максимально облегчить задачу системе распознавания. Для этого в первую очередь нужно исправить перспективные искажения, бич всех фотоснимков документов «от руки». Если не решить эту проблему, попытка распознать данные может дать результат, сравнимый с попытками распознавания капчи. На фрилансерских сайтах с завидной регулярностью появляются «верующие» в победу машинного интеллекта над капчой за мелкий прайс. Блажен, кто верует, но мы сейчас не об этом.
Итак, в данной статье мы попытаемся подхватить эстафету у ABBYY и рассказать на своем опыте, как можно с минимальными затратами привести призмообразный, в лучшем случае, документ, который мы идентифицировали на снимке (спасибо ABBYY за науку), к прямоугольной форме, желательно с сохранением исходных пропорций. Экзотические случаи, вроде пятиугольных или овальных документов мы пока не рассматриваем, хотя, вопрос интересный.

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

Знание алгоритма JPEG очень полезно не только для сжатия изображений. В нем используется теория из цифровой обработки сигналов, математического анализа, линейной алгебры, теории информации, в частности, преобразование Фурье, кодирование без потерь и др. Поэтому полученные знания могут пригодиться где угодно.

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

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

Так как сделать ваше приложение более быстрым? Вот несколько интересных техник, понимая которые вы сможете сделать ваше приложение более быстрым.

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

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

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

И так, для примера возьму задачу определения пола по имени. Конечно, чтобы определить пол можно создать большой список имен с метками пола. Но этот список в любом случае будет неполон. Для того чтобы решить эту проблему, можно «натренировать» модель по маркированным именам.
Если интересует, прошу

Первоисточник: Том ДеМарко “Deadline. Роман об управлении проектами”

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

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Архипенков Сергей — эксперт в управлении разработкой ПО, более 30 лет в разработке ПО, PMP® PMI, вице-президент Гильдии менеджеров программных проектов. Активный «продвигатор» и «задвигатор» теории и практики управления проектами и людьми в проектах по разработке ПО. Активный заседатель программных комитетов. Из последнего — председатель программного комитета конференции «Software Project Managment Conference» (ноябрь, Санкт-Петербург).

Ниже опубликован доклад Сергея с конференции CodeFest, на тему «Теория и практика адаптивного управления проектом».

Проработав несколько лет в небольших web агентствах, 5 месяцeв назад я решил попробовать что-то новое и устроился в довольно крупную (3500 сотрудников) IT-компанию. То, что я увидел на новом рабочем месте, оказалось очень далеким от моих ожиданий. По многочисленным просьбам моих друзей и в ответ недавней статье под катом несколько наблюдений о различиях между большими и маленькими IT компаниями. На вкус и цвет, как известно, фломастеры разные. Так что эта статья — далеко не истина в последней инстанции, это то, с чем я столкнулся и что было для меня важным.

В чем идея?

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

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

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

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

Отдых тела и ума

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

Второй важный пункт — еда. Для работы мозга — а работа в IT суть интеллектуальный труд — нужно много хорошей еды.
Если вы выспались и сыты, то силы должны быть, если их нет, идем дальше.

Активное тело, температура в помещении
Иногда нужно размять тело. Вовсе не так просто в СССР была производственная зарядка, о которой так бодро пел Высоцкий.

Тут есть глубокий физический смысл. Когда вы приводите свои мышцы в активность, повышается их тонус, в теле изменяется обмен веществ. Организм понимает, что нужно стать бодрее — и через 10-15 минут разминки вы себя не узнаете.

Данная статья является кратким конспектом по книге "Andre Kukla: Mental Traps"

Ментальные ловушки — это так называемые грабли, на которые мы наступаем снова и снова. Безусловно каждый нормальный человек хочет, чтобы этот «неудачный шаг» в его деятельности был последним и больше не повторялся.

С «граблями» или ментальными ловушками можно легко справиться, если они лежат перед вами во всей красе, безо всякой маскировки. Но так бывает далеко не всегда и зачастую мы не видим и не понимаем в чем заключаются наши ошибки. Целью этой статьи является знакомство с наиболее «популярными» ментальными ловушками, которые Андре Кукла описал в своей книге.

«Человек добился успеха, если он встает утром и ложится спать вечером, а в промежутке занимается тем, чем хочет»

— Боб Дилан

Я – программист по образу жизни. Я в одиночку работаю программистом, чтобы обеспечить себя интересной, полезной, гибкой и хорошо оплачиваемой работой. У меня нет инвесторов, я не собираюсь нанимать сотрудников, не говоря уже о том, чтобы стать следующим Google или Facebook. У меня нет личного самолета, и мое лицо вряд ли скоро появится на обложке Newsweek. Меня это устраивает.

В первой части мы изучили некоторые вопросы безопасности хранения и передачи данных. Теперь переходим к защите исполняемого кода. Мы будем модифицировать функционал iOS-приложения во время выполнения и проделаем реверс-инжиниринг. И снова, помните! Наша цель — не стать гадким взломщиком, а защитить ваше приложение и пользователей от злонамеренных действий. Для этого нужно понять, что может сделать взломщик.