• Как я написал компилятор C за 40 дней
    +1
    это будет скорее монотонная работа

    Да, монотонность работы часто наблюдается пока идет описание грамматики и начальное её покрытие реализацией парсера\компилятора\интерпретатора\генератора\….
    Типа, как в этом дневнике — скукотища: вот первая 1000 строк, вот вторая… ага, вот свет в конце тоннеля уже виден… и, наконец, 100% покрытие спецификации языка.

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

    Разработчику попроще, если разрабатывается реализация для какго-нибудь «известного и стабильного» языка, а если ещё и язык новый, то точно о монотонности и не вспомните даже на начальном этапе. Особенно на фоне «живой» спецификации языка.
  • Итоги 2015-го года для C++
    0
    Кстати .NET умеет собирать в нативный код (уже)

    Подобные попытки предпринимались неоднократно и многими. Особенно на ранних стадиях развития виртуальных сред исполнения. Вот только один пример для Java среды: https://gcc.gnu.org/java/
    Однако приоритет развития был всё-таки отдан «компиляции на лету» (англ. Just-in-time (JIT) compilation).
  • STM32F4: GNU AS: Программирование на ассемблере (Часть 1)
    0
    Статья — хороший бочонок меда начинающим для вхождения в тему.
    Ложка дёгтя — слова «линковщик»\«линковка» вместо более традиционных «компоновщик»\«компоновка».

    Такое особенно вредно для начинающих — в комментариях уже цитируют…
  • Что такое хорошо: как мы разрабатывали критерии для оценки качества вёрстки веб-проектов
    0
    FYI Критерии качества, связанные с Section 508 [1], могут оказаться весьма полезными даже, если к Веб-сайту и не предъявляются повышенные требования для обеспечения возможности взаимодействия с людьми с ограниченными возможностями. Например, отдельные критерии из этого списка [2] могут весьма положительно повлиять на качество большинства Веб-сайтов.

    [1] en.wikipedia.org/wiki/Section_508_Amendment_to_the_Rehabilitation_Act_of_1973
    [2] webaim.org/standards/508/checklist
  • Шайбу вбросим в iOS восемь
    +1
    Присмотритесь идеи везде! Вот это, к примеру:
    «Рисунок 7. На корте появился хоккеист.»
    это же идея новой игры «Теннис на льду»)
  • Инстанцировать не инстанциируемое
    +1
    Write once, fun anywhere?
  • Пишите компараторы правильно
    –1
    Цветочки на рубашке звёздного ученого мужа не интересны — они никак не влияют на производительность систем. Константа завернута в класс для получения дополнительных методов работы с ней. Ссылка в переменной на инстанцию такого класса также будет также иметь характер константы. Создание\удаление инстанций классов это дорогостоящая операция. Сборщик мусора потратит дополнительно и время и память на такую инстанцию, что однозначно снизит производительность. Метод класса, где происходит создание, может вызываться очень многократно. Для большой развивающейся системы на этапе проектирования класса мы чаще всего даже не знаем сколько раз такой метод будет вызван и сколько временных инстанций будет создаваться. Конечно, можно пользоваться только вкусом и о проблеме с производительностью, связанной с порождением кучи временных инстанций, «вдруг» узнать перед сдачей проекта в процессе профилирования. Но, можно попробовать и избегать подобных неожиданностей, выбирая несколько иной вкус и стиль.

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

    Всех с Новым годом и желаю Вам делать системы с достаточной производительностью, чтобы ваши пользователи никогда не вспоминали про тормоза!
  • Пишите компараторы правильно
    –3
    Статья претендует на обучение читателя правильному в области Java — это хорошо. Думаю, что в такой статье всё должно быть правильно во всех аспектах.

    У меня возникло подозрение, что не соблюдается выполнение соглашения Java для имен в примере со строками

    DoubleHolder nan = new DoubleHolder(Double.NaN);
    DoubleHolder zero = new DoubleHolder(0.0);

    Ведь «переменные» nan и zero в левых частях обоих выражений это на самом деле константы, а, следовательно, их имена должны быть написаны буквами в верхнем регистре.
    См. www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367

    Конечно, моя претензия к примеру будет некорректной, если найдется хотя бы один случай, когда переменные в коде всё-таки изменят свои значения на отличные от инициализированных. Моей фантазии сейчас не хватило, что бы изобрести такой корректный случай.

    Кроме того, если эти «переменные» будут признаны константами, то правильно их объявление делать на уровне класса, добавляя модификаторы final static.
  • Как я получил медаль за код
    0
    Вряд ли истинные мотивы автора будут нам известны. Диапазон мотивов велик от бездумного творчества со скуки, или от бесшабашного бахвальства и до выверенного прагматизма. Не удивлюсь, если через несколько лет он и сам не сможет объяснить почему он именно в таком виде опубликовал, когда его будут награждать юбилейной медалью за участие в той кампании… А после, от избытка чувств, он напишет очередной перл.
  • Как я получил медаль за код
    0
    Может главный посыл статьи не в том, что он что-то написал, а в том, что он награжден начальниками, чьи инструкции он нарушил?
    И это первая статья из цикла по карьерному росту — дальше: «Как я стал начальником», «Как я награждал...»,…?
  • Как я получил медаль за код
    0
    А при ещё большем повышении интенсивности использования системы буквы на «клавиатуре» просто обязаны превращаться в слова
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Увольнение принимаю. Вы не первый, кто говорит мне, что я своими словами заставляю работать.
    У вас сейчас есть всё, что бы самому получить ответы на свои вопросы. Уверяю, это не сложно. Надо только абстрагироваться от имеющихся у вас в голове догм и шаблонов (не важно даже какие они!). Открываете главу «4. Considerations for producing a good SRS» и формально\пунктуально примеряете эти положения на свои утверждения\требования к Системе.
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Какая дуэль?
    Утром на рассвете… как обычно. :-)
    Для подготовки схем целая ночь впереди — достаточно же :-)

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

    мы не успели потестировать стандарт
    Потестировать стандарты в каких-то приёмочных сценариях
    «Ну, Вы, блин даёте!» — сказал генерал из особенностей разработки национальных стандартов.
    Можно и дальше обсуждать QA процессы для разработки стандартов, ответственность руководителей за качество в рамках мультисерийного стандарта ISO 90XаXа…
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Нет уж, увольте. Вы сами назвались профессионалом в этом. Так что, сами, сами, сами, пожалуйста.

    «Главная задача высшей школы это научить студентов (от лат. studens — усердно работающий, занимающийся, интересующийся) к самостоятельному обучению и обретению новых навыков»
    из материалов XVI съезда КПСС.
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Дык, неудивительно. «Кураж был — был», а Системный подход?
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Зачем Вам пользоваться опытом неизвестно Виктора.
    Возьмите лучше авторитетный источник, ну, хотя бы какой-нибудь IEEE Recommended Practice for Software Requirements Specifications. Он старый и добрый — он поможет. Примените его положения к своим требованиям и поймите почему оба(!) ваших варианта не «good».

    А если интересно моё мнение, то у меня не хватило пальцев на руках, считая «недочеты» к этим двум требованиям.
    Уточню, у меня на руках 10 пальцев.
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Разумеется я это взял на основе сакрального знания о потребности государства иметь систему стандартизации, разработка которой без использования системных подходов… дает наглядный результат.
    И печаль моя от этого результата.

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

    Эталонную иерархическую организационную диаграмму, в которой присутствуют позиции всех(!) без исключения вариаций «стандартных» ИТ менеджеров.
    Эталонный технологический IT процесс, в который вовлечены эти менеджеры

    И строго, как на дуэле: «Выбор достойных графических языков для описания за вами...»

    С такой «линейкой» можно будет тогда поговорить и о качестве стандарта, и о его применимости в быту…
    И не хай, что сейчас висит этот стандарт в вакууме… промеряем, взвесим и оценим…

    Не думаю, что это должно вызвать серьёзное напряжение… Ведь, во «внутренних отчётных документах МинТруда» наверняка есть какой-нибудь «Отчет об испытаниях стандарта». Так же-ж?

    Однако, если применения этого стандарта «в быту» не предусматривается, то не надо тратить на это время…
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Десятилетиями на сотнях примерах убеждаюсь в справедливости фразы, которую говорил выдающийся человек — профессор Петр Петрович Гель своим студентам на первой же лекции по конструированию:
    «К сожалению, научить разрабатывать нельзя! Это либо дано, либо...».
    Либо жизнь заставляет Вас готовить специалистов по разработке требований из того, что есть.

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

    Надеюсь ваши шаблоны содержат раздел «Область применения» или там так же, как со «Списком литературы» в стандарте?
    И ваша первая тема на тренинге это «Шаблоны и правила выбора подходящего», а вторая тема «Что делать, если подходящего шаблона нет?»

    Эх, жаль Peter Coad «забил» на свой бизнес — у него и его команды изумительно получалось жонглировать всякими шаблонами. Мир много потерял от этого. Надеюсь, по роду своей деятельности Вы отслеживаете все современные достижения в этой области… Судя по Вашим словам выше, свято место пока пусто. Или нет?

    К стати, Вы своими словами только что подтвердили обязательность наличия в стандартах, учебных пособиях и т.д. раздела «Определения».

    Попробуйте дать определение для термина «Качество продукта» (или найдите готовое в стандартах — только не в учебниках и популярных книжках — я там такой бред встречал — ужас, наши стандарты, к стати, тоже очень «хромают» в части терминологии) для лучшего собственного понимания, сравните несколько различных определений для приближения к «математическому ожиданию и уменьшения дисперсии». Далее определите коэффициенты корреляции для каждого требования при вычислении целевой функции качества.
    При этом ужаснитесь: «Ой, все(!) > 0. Что же делать!?».
    Я доходчиво объяснил?

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

    Но, это так, замечание в сторону. Я буду рад, если это замечание принесет пользу. Но, мне совершенно не хочется разворачивать на поле Хабрахабр «Битву Водогреев» по данному вопросу — не тот формат. К тому же, моё имя уже по любому определяет победителя :-)
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Давайте, добьемся вставки в стандарт одной ссылки… на эту переписку в Хабрахабр и вопрос будет решён —
    Хабрахабр войдет в федеральную систему стандартизации :-)
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    У нас есть поговорка: «Поздно пить боржоми...»
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Вы правда думаете, что вопрос «где найти теорию портфельного управления» — это вопрос к тексту стандарта?

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

    Назвав, стандарт "… в вакууме" я не издевался, а высветил отсутствие базиса и внешних связей стандарта.

    Почему создатели «стандарта» позволили себе отвергнуть опыт человечества, которое веками снабжала свои шедевры разделом «Список литературы»?

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

    Я вам по секрету скажу, что есть Закон:
    "… Участники работ по стандартизации, а также национальные стандарты, предварительные национальные стандарты, общероссийские классификаторы технико-экономической и социальной информации, правила их разработки и применения, правила стандартизации, нормы и рекомендации в области стандартизации, своды правил образуют национальную систему стандартизации.

    www.consultant.ru/popular/techreg/45_3.html#p377
    © КонсультантПлюс, 1992-2014"

    Или у вас есть ноу-хау, позволяющее строить Систему без связей?

    Но, не беспокойтесь, юридически составители этого стандарта, вроде как, чисты — ваш «стандарт» не технический.
    Он скорее гуманитарный :-)
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Было в России две беды. И придумали мудрые люди правила безопасного сосуществования с обоими бедами в 3D пространстве.
    Но, МинКомСвязи, осваивая пространство им. Вирта, накликал ещё беду. И теперь, если терпеливо исполнять правило 3Д, то с большой вероятностью мимо неторопливо проплывет… менеджер с какой-нибудь специализацией. И скажет нам мудрец восточный: «Я понимать, у Вас Манагер, как Иванов, многая такая фамилия».

    Не могу утверждать точно, но похоже Министерства вовлекли грамотных и образованных специалистов в процесс, имеющий целый ряд системных ошибок. Я так полагаю потому, что в хорошем процессе вовлеченные эксперты имели бы, как минимум, несколько шансов указать на эти ошибки и исправить их (на вскидку таких точек для выявления в этом процессе должно было быть быть штук 5-6).

    Слово менеджер уже прочно вошло в корпус русского языка.

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

    В случае применения такого слова при разработке какого-нибудь международного стандарта, спецификации или любого подобного документа QA специалист обязательно должен был бы оставить в системе отслеживания ошибок запись со словами «ambiguous term». И я вас уверяю, это было бы исправлено очень быстро.

    Задумайтесь, мы заимствовали слово. Ну, типа взяли кредит по которому нам придется расплачиваться долгие годы, каждый раз объясняя: «Ну, у нас это не совсем менеджер в истинном понимании значения этого слова. У нас офис-менеджер это секретарша, менеджер у прилавка это продавец, а ассистент младшего менеджера это… ну, как бы вам объяснить получше… ».

    Представьте себе только стоимость чернил, которые на это будет потрачено? Ведь много Менеджеров смогли бы безбедно прожить остаток жизни на такие деньги не пачкаясь в чернилах.
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    Эх, к Рождеству надо настоящее чудо просить!
    Не интересно же спрашивать про то, что уже упомянуто в стандарте. Интереснее про то, чего ещё нет…
    Спросите сразу про «Теорию управления рисками» :-)

    Это даже более актуально для гильдии менеджеров, чем всё перечисленное. Потому, что это коротко связано с деньгами.

    К стати, в прошлом веке в СССР, когда ещё несоблюдение стандартов каралось по закону, эту теорию не оставляли без внимания. Сам свидетель, когда после игр с привлечением «Теории вероятности» выход годного при массовом производстве повышался с 30% до 90%. Вот такое было управление риском брака.
  • Утверждён профстандарт менеджера ИТ-продуктов
    0
    менеджер ИТ-продуктов… профессия очень молодая и ещё не устоялась даже на западе.

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

    Если коротко:

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

    Вот коротко как-то так.

    Помню, я действительно испытал шок, когда открыл для себя, что во многих(!) российских ИТ компаниях Менеджер проекта\продукта это настоящий кудесник-камикадзе, который, не обладая административными полномочиями над исполнителями, отвечает за выполнение проекта или счастливую жизнь продукта.
    Это тогда подорвало мою веру:
    • в непогрешимость IDEF0 — у нас процессы работают даже когда ресурсы\механизмы неподконтрольны.
    • в необходимость иметь в организации строгую иерархию и единоначалие — «прибегает левый менеджер продукта к исполнителю и в пожарном порядке ориентирует его на выполнение срочной работы, прибегает правый менеджер… и понеслось...».
  • Утверждён профстандарт менеджера ИТ-продуктов
    +1
    Думаю что должностные инструкции и тексты вакансий лучше писать человеческим языком, а не формальным.

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

    Или Вы за то, чтобы должностные инструкции и тексты вакансий можно было бы расценивать по принципу «как захочешь»? :-)

    Хотя, да, авторов некоторых «формальных» текстов очень хочется попросить изложить свои мысли «человеческим языком».
    Но, это чаще возникает совсем не из-за формализма.
  • Утверждён профстандарт менеджера ИТ-продуктов
    +1
    Печальный какой-то этот документ. И кегль 12-тый и шрифт черный, и всё вроде бы согласно Методических рекомендаций, но не могу заставить себя назвать стандартом этот набор околоИТшных слов с опасным коммерческим креном.

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

    Тем не менее, очень хочется спросить самих авторов документа из компаний со звучными названиями:
    • Действительно ли использовался "Системный подход" при разработке этого продукта, какой? Почему при таком прогрессивном подходе это осталось не задокументировано?
    • Какие "… предприятия компьютерных и информационных технологий" были выбраны в качестве эталона для тщательного "… системного анализа" установленных у них технологических и деловых процессов, которые «вдруг» потребовали привлечения трудовых ресурсов именно такого рода? И почему они были избраны, как эталон?
    • Почему в "" входной язык почти русский, а в стандарте применяется странно-неоднозначное заимствованное слово «менеджер» без каких либо разъяснений его значения для русскоязычного читателя?
      Есть ли вообще возможность прояснить ситуацию с этой, вроде как по-определению руководящей(!) должностью, в случае «ассистент младшего менеджера» — кто такому в организационной иерархии будет подотчётен? Или предполагается, что эта должность вообще не административная, т.е. это просто недоАналитик с начальным(!) профессиональным образованием «заточенный» на торговлю и нанимаемый для перекладывания бумажек по модерновой безбумажной технологии?


    И главный вопрос к авторам:
    Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?

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

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


    Допускаю, что документ возможно хорош для каких-то своих целей, но в таком виде некоторым ИТ компаниям он явно может оказать «медвежью услугу» и не простую, а многоаспектную.

    Конечно же, кроме единственного советского «Оператора ЭВМ» в ИТ отрасли должны быть и какие-то другие специалисты, но есть большие опасения возникновения в компаниях состояния «перебора» от такого количества «мастей» менеджеров-коммерсантов.

    Может в этом документе и всё изумительно правильно написано, просто «очень профессиональные» слова использованы и смысл написанного ускользает от обычного ИТ специалиста. Но, как же читателю понять это, если даже самого бестолкового словаря не предусмотрено?

    Не знаю, как у вас, а у меня напрашивается вывод один:
    Не тянет как-то этот документ на рождественский подарок ИТ сообществу. Не радостный он.
  • Светильник декоративный бытовой СДБ-З «Евлампия»
    0
    Нашёл…
    Для парктроника квадрокоптера использовалось устройство из серии сенсоров XL-MaxSonar®-EZ™.
    Конкретно в них в «черном бочонке» и «динамик» и «микрофон».

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

    А по первой попавшейся ссылке с DX, которую я прислал в качестве примера, не могу точно сказать… Вы же сами видите, как там русскими буквами на китайском написано, что и понять то сложно. Но, оптимизм в названии внушает, что это не просто УЗ датчик, а всё-таки «датчик расстояния». И по его картинке похоже, что это именно тот активный элемент, который ставится на плату HC-SR04.

  • Светильник декоративный бытовой СДБ-З «Евлампия»
    +1
    Те датчики, что на видео абсолютно «бесшумные», как летучая мышь! Не помню точные характеристики, но 1-я гармоника излучаемой частоты этих приборов, ну, стопроцентно выше верхней границы слышимого диапазона (> 20 кГц).

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

    Не уговариваю, но, уверен, что светильник с несколькими УЗ датчиками с подобранными характеристиками и расположением сможет распознавать даже простые жесты (типа «рука вверх», «рука вперед», и т.д.), не говоря уже о весьма точном (до сантиметров) измерении расстояния до управляющего субъекта.
    Да, и название модифицированной версии вашего изделия привлекательнее будет:
    «Светильник СДБ-ЗУ „Евлампия“ с парктроником со светтроником».
  • Бизнес vs программная инженерия
    +1
    По теме статьи можно сказать одной фразой:

    Культура бизнеса (читай «делания денег») определяет культуру производства,
    и, следовательно, существенно влияет на то, что производится для нашего потребления.

    … ну, и чтобы печально замкнуть цикл процитирую: "мы есть то, что потребляем".
  • Бизнес vs программная инженерия
    –1
    Это важно: НЕ «составляются новые планы», а корректируются существующие планы.

    Изначальный «план» ДОЛЖЕН составляться на основании четко проработанного и известного Жизненного цикла человека продукта.
    Вероятность изменения содержания и последовательности этапов такого цикла весьма мало.

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

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

  • Светильник декоративный бытовой СДБ-З «Евлампия»
    0
    Когда смотрел ваш ролик и вслушивался в музыкальное сопровождение — классно подобранную вариацию на тему популярной нынче песни кометы 67P, сразу как-то вспомнились творения господ Скрябина и Термена.

    Прочитал в статье о проблеме с ИК датчиком и на фоне мыслей о звуке вспомнил об одном своем давнем эксперименте с ультразвуковыми сенсорами — может такое решение поможет вам избавиться от текущих проблем и добавит для развлечения других.
  • Google Chrome пометит HTTP-сайты как небезопасные
    +2
    Классный термин в результате опечатки получился:

    оGOLDелое внедрение — внедрение с целью ни чем не сдерживаемого обогащения.
  • Грабли гостиниц: что надо знать заранее, если вы делаете конференц-зал
    +2
    Жаль, когда после «наивысшего достижения человечества — разделения труда по специальностям» архитекторы залов как-то самоустраняются от проблем акустики в своих творениях, рассчитывая только на современную аппаратуру.

    В акустическом плане меня когда-то поразил актовый зал в Питере в старом здании Бонча (наб. реки Мойка, 61).
    Там со сцены можно не напрягаясь шепотом «докричаться» до самого дальнего угла зала, но чтобы из этого же угла стало что-то слышно на сцене надо реально крикнуть. Как так у архитекторов и строителей получилось, ведь никаких «замурованных» амфор под креслами!?

    image
  • Пора завязывать склонять латиницу
    +1
    Мы не достигли нужного перформанса.

    IMHO Это нехороший «положительный» пример в статье.
    Для технического текста на русском языке правильнее написать:

    Мы не достигли нужной производительности

    Тогда будет проще понять смысл написанного.
    А, манерное слово «перформанс» лучше оставить специалистам от «шоу бизнеса».
  • Что такое красивый код, и нужен ли он? Что думают в Яндексе
    0
    Думаю, что цифры нужно читать, как «гуру» фирмы. И эти ребята были выбраны авторами публикации, чтобы представить годами наработанное мнение 6000-ного коллектива по профессиональному вопросу, который важен для любого программиста.
  • Что такое красивый код, и нужен ли он? Что думают в Яндексе
    0
    Есть проекты, где год за два считается.
  • Что такое красивый код, и нужен ли он? Что думают в Яндексе
    0
    Без разницы. Программа это идея воплощенная в исходном коде. Комментарий свидетельствует, что в коде воплощена «некрасивая» идея. Процесс разработки обязан уметь отслеживать наличие подобных проблем в коде для возможности их оценки и, возможно, исправления. Рассматриваемый комментарий серьезно затрудняет это. Именно поэтому он некрасивый.

    «Красивый» коммерческий(!) код обязан быть прагматичным.

    Например, этот комментарий мог бы быть таким:
    // FixMe #100500
    где #100500 это ссылка на запись в используемой системе отслеживания проблем.

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

  • Что такое красивый код, и нужен ли он? Что думают в Яндексе
    0
    Хочется верить, что подобное не уходит в релиз. Хотя, сам факт возникновения этого поста свидетельствует о том, что Яндекс дошел в своем развитии до необходимости решения таких проблем. И это радует.

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

    комментарии в коде на английском или на русском?

    IMHO Ключевые слова, константы, переменные… — на «английском», тогда логично, что и комментарии на том же языке. Иначе будут ненужные сложности перевода для неминуемо связанного «embedded language» в комментариях. Да, и неоднократно доказано, что правильно написанные комментарии на английском будут короче, обеспечивая тот же объем информации.

  • Что такое красивый код, и нужен ли он? Что думают в Яндексе
    0
    Слово и дело:

    // The following code is no longer required ...
    ...<boat anchor>...

    Допустимы ли антишаблоны в красивом исходном коде?
  • Google заключает договор с морским извозчиком
    0
    Может просто в один прекрасный день лоцман проложит маршрут сюда!?