Каждую осень я объясняю новому потоку аспирантов, что такое степень кандидата наук.

Сложно описать это словами.

Поэтому я использую картинки.

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

В понедельник утром за неделю до Нового Года этот вопрос, думаю, актуален для многих.

Есть куча статей на эту тему. Вот основные советы:

• Начинайте с самой сложной задачи
• Сделайте первый шаг — продолжать будет уже легче
• Составьте план и неукоснительно ему следуйте
• Занимайтесь любимым делом
• Не отвлекайтесь

Всё просто. Закройте Хабр и приступайте к работе!

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

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

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

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

В 1979 году американский психолог Бенджамин Либет провел свой знаменитый эксперимент, который взбудоражил научное сообщество, но как-то прошел мимо широкой массы. А очень зря, ведь он показывает всю чудовищную правду о нашей «свободной воле».

Concise Binary Object Representation (сжатое бинарное представление объекта) — формат данных, который был спроектирован таким образом, чтобы обеспечить максимально простой код реализации, формирования компактных выходных данных и возможность расширения формата без необходимости обмена информацией о версии.

Стандарт формата CBOR был официально анонсирован комитетом IETF в октябре 2013 года в новом документе RFC 7049, авторами которого являются Carsten Bormann и Paul Hoffman. Взглянув на имя первого автора, можно предположить другую причину происхождения аббревиатуры для названия формата, но возможно это просто совпадение. Формат CBOR получил MIME-тип application/cbor.

На данный момент существует, вероятно, сотни всевозможных бинарных форматов для представления структурированных данных, ряд которых стандартизирован, популярен и широко применяется (например, BER и DER для ASN.1, MessagePack и BSON). Все существующие стандарты решают поставленные перед ними задачи, и CBOR здесь не исключение. К формату было предъявлено семь важных требований, и, поскольку ни один из существующих форматов в полной мере не мог им удовлетворить, был создан новый (да, тут напрашивается картинка ).

Abstract: О новом тренде — software defined strorge и главной родовой травме блочных устройств — обещании бесконечной надёжности.

Лирика

На горизонте новый buzzword: Software defined $thing. Мы уже имеем состоявшийся и сформировавшийся круг всего, относящегося к software defined networks (SDN), пришла очередь и storage (SDS). Видимо, дальше у нас будет software defined computing или ещё что-то подобное, потом резко всполошатся и подтянутся HP/VMWare и предложат (private) «software defined enterprise», который будет означать всё тоже, что было, но ещё моднее и актуальнее.

Впрочем, рассказ не про баззворды. За каждым таким странным названием (grid, elastic, cloud) стоит дальнейшее развитие технологий — построение дальнейших слоёв взаимодействия компонент (эм… взаимодействия участников взаимодействия, иначе не скажешь), основным мотивом которых является уход от гранулированности компьютерной системы, так, чтобы вся терминология, вся предметная область ушла от «межпроцессного взаимодействия» и стала автономной. В более-менее приличном виде мы это (в виде уже свершившегося факта) мы видим в волшебном мире javascript работе www, когда нас никаким образом не волнуют сервера, на которых крутятся задачи — всё общение происходит на уровне между браузером (с учётом его интимных подробностей DOM, JS и т.д.) и абстракцией, под названием URI, которой не важно — один это сервер или сотни разных.

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

Перед рассказом про SDS, посмотрим на уже состоявшееся: SDN (software defined network).

Оригинал статьи носит название «10 SQL ошибок, которые делают Java разработчики», но, по большому счёту, приведённые в ней принципы можно отнести к любому языку.



Java программисты мешают объектно-ориентированное и императивное мышление в зависимости от их уровня:
— мастерства (каждый может программировать императивно)
— догмы (шаблон для применения шаблонов где-либо и их именование)
— настроения (применять истинный объектный подход немного сложнее чем императивный)

Но всё меняется, когда Java разработчики пишут SQL код.

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

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

А вот более длительные фазы, период которых составляет несколько месяцев, проследить значительно сложнее. Хотя эти фазы так же реальны, как и кратковременные фазы.

Доброго времени суток, уважаемые читатели. Прочитав одну статью о второй жизни старых машин решил Вам рассказать один очень простой, но действенный способ, как сделать с одного ПК — два. Я уверен, многие это уже знают и даже знают несколько программ от разных разработчиков по этой теме, которые дублируют работу Windows и.т.д.
Я же предложу способ, в котором 2-й ПК будет независимым (ну почти независимым, так как если выключить/перезагрузить физический ПК – естественно второй наш виртуальный тоже вырубится). Но пока работает физический — второй ПК будет полностью работоспособным и вполне производительным.

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

Мне было немного странно видеть, что в таком замечательном ресурсе мало обсуждения и самой темы о торговых марках, то есть наименовании IT продуктов и компаний (“торговой марки”, “торгового наименования”, “ТМ”, “trademark”). Очевидно, что любой программист и участник IT рынка (а особенно те, кто пишут свои продукты), рано или поздно столкнется с этим вопросом. Поэтому, чем раньше IT-шники об этом будут задумываться, тем меньше будет проблем в их бизнесе в будущем.

Итак, постараемся восполнить пробел и открыть тему торговых марок. Очевидно, что с точки зрения программирования легко повторить и tetris, и facebook, и любые «фермы». Но попробуйте раскрутить свой продукт (клон он или нет) с похожими на эти продукты названиями — тут же владельцы (вернее их юристы) вас закроют со всех ресурсов. С другой стороны, если ваш продукт становится популярным, то тут же назревает необходимость защитить его от клонов и сделать так, чтобы другие не использовали и не забивали вашу марку в свои ключевые слова. Если коротко — это и есть причина, по которой торговая марка выступает одним из основных параметров оценки и стоимости любого IT проекта при его финансировании, продаже и заключении солидных контрактов.

Из опыта (и интуиции тоже) обучение программированию хочется надежно отнести поближе к отметке 14+.

Почему 14 с плюсом?

Потому, что: раньше — не значит вовремя. На самом деле 12, но в целом лучше c 14-ти…
Да, можно раньше. Но не нужно. Программирование в основном занимается анализом, обработкой и структурированием информации. Как эффективные, осознаваемые механизмы восприятия и взаимодействия с миром – эти качества складываются (созревают) в человеке к 12-14 годам. Вот тогда, изучение программирования становиться естественным и логичным продолжением дальнейшего развития. Не для всех, но для тех, кому оно видится интересным.

Как это оценить? Никак.
В 12-14 лет у человека уже достаточно для этого опыта. Он сделает это самостоятельно (надо только предложить). Программирование – объемная и не самая простая область знаний. Без настоящего (самостоятельного) интереса к нему, программирование быстро становится каторгой. Ещё одной, в дополнение ко всем тем необязательным дисциплинам, которые были скорее навязаны заранее, чем предложены вовремя.



То, что информатика (тень программирования) есть в школьной программе начиная с первого класса – лишь следствие крайне буквального применения и без того неуравновешенного, догматического посыла: что «чем раньше, тем лучше».

За годы преподавания и коммерческой разработки я повстречал много студентов и разработчиков, которые не до конца понимают смысл слова абстракция. Из многочисленных попыток разъяснить смысл этого термина получилась настоящая статья. Что Вы найдете под катом:

• Определение понятия абстракции и объяснение откуда оно взялось в ООП.
• Объяснение на простых примерах, что такое барьер абстракции, побочный эффект абстракции.
• Как получается хардкод.

Мы ходим в японские рестораны,
но не едим рыбу. Кто мы?

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

Идея

Ровно год назад в декабре 2012 года мы сидели с женой в одном из ресторанов. Был новогодний ажиотаж, поэтому меню, как водится, не хватило на всех, а обслуживали достаточно долго. Даже чек пришлось ждать минут 20. Неделей ранее я впервые увидел в другом ресторане механическую кнопку вызова официанта. Тогда у меня в первый раз промелькнула идея о том, что неплохо бы каждому ресторану иметь электронное меню и такой же электронный вызов официанта. Сначала появилась мысль о маленьком Atom PC, который будет стоять в ресторане и по wifi принимать запросы от ресторанных планшетов. Подумал, обсудил с женой и забыл на пару недель. Спустя две недели ситуация с меню повторилась и тогда я понял, что все можно обернуть в красивый SaaS сервис. Сейчас, даже странно смотрится то, что эта идея не пришла ко мне сразу. Так появилась идея сервиса, который мы назвали «47 ресторанов».

^{Прекрасная картинка неизвестного автора}

Я долго не писал эту статью. На протяжении полугода я регулярно практиковал попытки пройти в поликлинике к докторам без очереди и хамское вождение с московскими номерами в глубинке, чтобы стать толстокожим и невосприимчивым к ненависти (даже НЕНАВИСТИ!!!1), которая прольётся на меня после этой статьи. Это неизбежно, так как Хабр — гик-ориентированный ресурс, а QR-коды — гик-технология. Они уже получили широкое распространение и теплую поддержку от гиков Хабра, так что будущее у меня в мрачных оттенках. Не удивлюсь бритвенным лезвиям в почтовом ящике и молчаливому дыханию в телефонную трубку от полуночных незнакомцев.

Видимо, для апологетов QR-кодов эта технология — возможностью приблизить будущее, шагнуть в прекрасный мир завтрашнего дня с дополненной реальностью из всех этих многочисленных видеороликов и фильмов про будущее с прозрачными дисплеями, что-то разобрать на которых можно только при отсутствии просвечивающегося пёстрого бабушкина ковра на стене. Гики радуются любому новому примеру использованию QR-кода, даже если это помогающая рассказывать сказки детская пижама с QR-кодами, надгробия, коровы. И с мечтательным видом прогнозируют, что в будущем QR-коды будут повсеместно. По моему мнению, такой вариант событий можно описывать в антиутопиях, что-нибудь вроде «Мы» Замятина.

Для создания видимости аргументов в защиту своего мнения я мог бы устроить тут филиал wtfqrcodes.com и со злыми комментариями публиковать самые неудачные и даже опасные случаи использования QR-кодов, завершив всё это ссылкой на понятную инструкцию. Но эта демагогия не поможет прийти к цели — понять суть проблемы QR-кодов, так что passive-aggressive mod off, и давайте разберемся.

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

Другими словами, сегодня мы поговорим о том, как мы пришли от этого — к этому:



А еще мы поговорим о том, как кнопки изменили наше понимание этого мира. Вы не представляете, насколько сильным было это влияние: кнопки поменяли саму парадигму нашего мышления.

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

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

Кратко: после браузерных войн организация W3C и группы разработчиков, такие как Web Standards Project, долго и упорно работали, чтобы восстановить единый нефрагментированный Веб. Но в последние несколько лет мы, разработчики, взяли, и заново всё зафрагментировали… Наверное, нам надо понять, что мы теряем, прежде чем потеряем этот Веб навсегда.

Ровно год назад патриарх веб-индустрии Anil Dash написал: "Мы потеряли Веб", скорбя по ранней, «досоциальной» блогосфере, до всех этих наших постингов фото, видео и мыслей, находящих последний приют в катакомбах Фейсбука, Твиттера, Инстаграма и Ютуба. Это вызвало отклик у многих, кто застал те дни; многих, кто по иронии судьбы затем ушёл работать в эти катакомбы.

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