AutoCAD начала 80-х

Зум появился очень давно, на заре эры графических интефейсов, с первыми векторными редакторами.
Но с тех пор он не был использован почти нигде, кроме САПР и программ для работы с графикой. Про него вспомнили только когда появились мобильные устройства — на маленьком экране не умещались большие фотки и веб-страницы.
В мобильных интерфейсах зум стал вполне привычным и естественным и продолжает эволюционировать. Но на десктопе зум заброшен и, на мой взгляд, совершенно напрасно. Zoomable user interface (ZUI) даёт ряд преимуществ, позволяющих лучше решить актуальные задачи. Я решил описать эти преимущества по типам зума, с примерами.

Когда-то книга “Совершенный код” Стива МакКоннела произвела на меня большое впечатление. Я лично думаю, что эту книгу обязательно должен прочесть каждый, кто зарабатывает на жизнь написанием кода. Особенно настоятельно я рекомендую эту книгу новичкам.

Настоящие размышления о программировании посвящаются главе 33 “Личность” и тем, кто решил связать свою жизнь с разработкой программного обеспечения.

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

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

Совсем недавно cppcheck помог найти уязвимость в проекте Xorg, которая существовала там почти 23 года! Он помог уже тысячам программистов по всему миру, на официальном сайте можно найти информацию о найденных с помощью cppcheck уязвимостях в программах, и этот список постоянно растёт. Итак, если вы хотите знать, почему нужно использовать cppcheck всегда и везде — прошу под кат.

Robot Odyssey

Нью-йоркский программист Дэвид Ауэрбах (David Auerbach) вспоминает компьютерную игру, для прохождения которой ему понадобилось 13 лет и которая определила его будущее как программиста.

Как-то полтора года назад я сидел в кафе на Арбате и думал о своем будущем. На тот момент работал программистом на полставки и учился в одном техническом ВУЗе. Все было стабильно, но хотелось чего-то большего – и я решил посмотреть, сколько зарабатывают хорошие программисты на фрилансе. Опыт «фрилансерства» у меня к тому моменту уже был, но впечатление осталось не самое лучшее — деньги маленькие, заказчики не всегда адекватные, один раз даже меня «кинули» с оплатой.

Я зашел на сайт всем известной российской фриланс-биржи и увидел, что за год моего отсутствия там ничего не изменилось: платят — мало, просят — много и так далее. Так у меня родилась идея посмотреть, что происходит на западе. Я нашел на Хабре статьи про иностранные биржи Odesk и Elance, почитал, подумал, как все сложно, и благополучно забыл про эту затею.

С понедельничком (говорят — самым депрессивным в году), хабровчане!
После публикации этой статьи, многие заметили, что я шустрый карьерист, и у меня начали просить совета на тему: как обеспечить карьерный рост в IT-индустрии. Во избежание повторения одних и тех же советов разным людям в личных сообщениях я и пишу эту статью, делясь в ней историей своего собственного карьерного роста и основными наблюдениями, которые я сделал за 13 лет опыта работы в больших и не очень компаниях.
Сразу предупрежу, что не претендую на изложение универсальной теории карьерного роста сферического коня в вакууме, и большинство замечаний искривлено призмой моего восприятия. То, что неоднократно работало в моем случае, необязательно сработает в вашем.

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

Не пришло ли время для следующего технологического уклада, который позволит вывести цивилизацию человеков на качественно новый уровень? Судя по интересу со стороны государств и крупных корпораций (aka Google), да и просто с точки зрения личных убеждений основой нового технологического уклада могут стать биоинженерия и робототехника. Если, конечно, внезапно не наступит технологическая сингулярность!

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

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

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

В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:

• 20:1 по времени написания кода
• 25:1 по времени отладки кода
• 10:1 по скорости работы программы
• 5:1 по объему кода

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

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

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

Исключения и связанная с ними раскрутка стека – одна из самых приятных методик в C++. Обработка исключений интуитивно понятно согласуется с блочной структурой программы. Внешне, обработка исключений представляется очень логичной и естественной.

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

Тем не менее, в C++, исключения традиционно рассматриваются буквально как исключительные ситуации, связанные с восстановлением после ошибок. Трудно сказать, является ли это причиной или следствием того, что реализация обработки исключений компиляторами чрезвычайно дорога. Попробуем разобраться почему.

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

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

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

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

Недавно нашей сети исполнилось 5 лет. Первые два года были просто взрывом: мы стартовали без кредитных средств с одного маленького магазина и как-то вдруг стали российской розничной сетью.

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

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

Мне приходится очень много читать код. Это и open source, и всяческие фреймворки, и код enterprise приложений. Именно о последних я хотел бы сегодня поговорить.

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

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

Приветствую вас, славные жители Хаброгорода!

Плюсы в комментариях в посте IBM и ответы на мой вопрос в Тостере а еще карма, выросшая за ночь в 3 раза обозначили яркое желание Хабра читать научно-популярные статьи: достаточно глубокие, но написанные человеческим языком и с прозрачными аналогиями. Заранее определим, как и о чем мы будем писать.

В постах НЕ будет:

• повторов знаний из Википедии и научно-популярной клюквы с утверждениями, «взятыми с потолка»;
• математики и формул. Вообще;
• ликбеза по поводу школьного курса физики.

  да мне не сложно, но тогда статья вырастет до размеров самки кита ;D. Все мы люди взрослые и если не понимаем основы основ — ищем ответ самостоятельно или спрашиваем в комментариях.

В публикациях будет:

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

Материала очень много и для усиления усваивания лучше начать с инженерной статьи. Итак, как же понять, что за технология перед нами, нано или нет? Давайте измерим ее.

Странно, что про этот крайне популярный и полезный чип до сих пор не было статьи на Хабре. Считаю необходимым восполнить этот пробел. В статье будет описано несколько интересных способов применения чипа FTDI FT232H и его аналогов для различных прикладных целей.
Пару слов о нем: относительно дешевый, простой в разводке и программировании, распространенный конвертер USB 2.0 <-> последовательные протоколы (USART, SPI, I2C, JTAG TAP и просто GPIO bit-bang), хорошо подходящий как для изготовления собственных устройств с подключением к ПК по USB, так и для тестирования и отладки других устройств.
Из простой breakout-платы на этом чипе легко и непринужденно можно сделать UART-конвертер, SPI-программатор, JTAG-отладчик, I2C-master, конвертер GPIO bit-bang (а с ним и остальных протоколов, не требующих запредельных частот и стойких к возможным задержкам, вносимым USB-стеком, к примеру, Dallas 1-wire).
Если вышеуказанные возможности сумели вас заинтересовать — прошу под кат.