Привет, Geektimes! Сегодня мы продолжаем наш цикл PC Buyers Guide и поговорим о той железке, без которой вообще ни один компьютер не будет работать. О блоке питания.



Вопросов про блоки питания задают много и регулярно. Разумеется, самый распространённый вопрос — о том, как правильно выбрать БП и насколько мощный «питальник» нужен для опреедлённого набора железа. Но кроме подсчётов необходимой мощности есть ещё несколько интересных тем, которые хотелось бы сегодня осветить: что такое сертификация «80+», какие маркетинговые «улучшайзеры» стоит проигнорировать, а какие учесть, ну и, разумеется, какого производителя выбрать.

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



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

Введение

Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».

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

Предлагаю читателям «Мегамозга» расширенный материал, подготовленный автором на основе доклада, прочитанного на конференции REQ Labs 2014.

На протяжении последних лет наблюдается устойчивый рост популярности профессии бизнес-аналитика. В подтверждение данного высказывания можно привести несколько фактов. Так по данным TEKsystems, крупнейшего игрока на рынке подбора кадров, с 2008 по 2013 спрос на специалистов в области бизнес-анализа на рынке США вырос на 236%.

Данная тенденция характерна и для отечественного рынка. Если говорить о постсоветском пространстве, дополнительно можно отметить появление тематических конференций по бизнес-анализу (ReqLabs и AnalystDays), организацию Киевского и Российского отделений Международного института бизнес-анализа (International Institute of Business Analysis (IIBA). Рост интереса можно объяснить общим увеличением емкости рынка, бурным ростом продуктовых компаний, стремлением аутсорсинговых компаний выйти на новый качественный уровень за счет выполнения всех проектных активностей на своей стороне.

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

Каждый раз при покупке батареек у меня возникало много вопросов:

Насколько дорогие батарейки лучше дешёвых?
Насколько ёмкость литиевых батареек больше обычных?
Насколько ёмкость солевых батареек меньше, чем у щелочных?
Отличаются ли батарейки для цифровых устройств от обычных?
Какие из батареек, стоящих одинаково, лучше покупать?

Чтобы получить ответы на эти вопросы я решил протестировать все батарейки АА и ААА, которые удастся найти в Москве. Я собрал 58 видов батареек АА и 35 видов ААА. Всего было протестировано 255 батареек — 170 АА и 85 ААА.

История создания терминов

При создании методики по имитационному моделированию мне понадобилось разобраться с терминами. Проблема была в том, что общепринятые термины не годились для описания статистических данных, собранных в процессе имитации. Термины: процесс и экземпляры процесса были неприемлемы, потому что я не мог работать в парадигме Аристотеля. Парадигма Аристотеля не стыкуется с примененным мной матаппаратом. При этом практическое применение данной методики было простое – моделирование и имитация бизнес-объектов с целью принятия управленческих решений. В программе создавался виртуальный объект, описание которого состояло из описания сценариев и их взаимодействия. Сценарии прогонялись внутри программы, а также моделировались ресурсы и их взаимодействия.

Мы не раз рассказывали, как первый же крупный клиент чуть не убил весь наш бизнес. Тогда одной из явных дыр, наряду с QA (Quality Assurance), был BA (Business Analysis). До появления в нашем портфеле по-настоящему больших проектов необходимости в глубоком анализе бизнес-требований заказчика и выработки системных решений для их удовлетворения не было. Сейчас в Redmadrobot три бизнес-аналитика, которые определяют точки развития мобилити-проектов, исходя из бизнес-задач клиентов.
Один из наших BA — Семен Заморов — поделился своим Toolset, набором программ, которые помогают ему выполнять работу еще быстрее.

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

В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

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

Любят на Хабре солнечную энергетику: вот Гугл строит солнечные электростанции (1 2 3 4 5 6), вот Германия однажды генерировала треть текущего энергопотребления на солнечных электростанциях…

Комментарии делятся на 2 категории: «Вот молодцы, а мы только нефть жгем» и "EROEI! Производство солнечных батарей требует больше энергии чем они производят!".

Въедливый читатель наверняка подумает: Как это производит меньше, чем требуется на производство? Их же поставил — они работают, каши не просят, 10 лет, 50лет, 100лет — значит суммарная произведенная энергия равна бесконечности, и они должны быть выгодны при любой стоимости постройки…

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

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

Работая над статьей о роли требований в процессе разработки программного обеспечения я обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).

Хочу поделиться с читателями habrahabr данной классификацией.

Введение

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

Ниже приведена шкала уровней зрелости процесса управления требованиями, построенная по аналогии с моделью CMMI. Эти модели никак не связаны между собой, но имеют некоторое пересечение. Так, достижение уровня 5 (Интеграция требований) зрелости процесса управления требованиями позволит получить как минимум уровень 3 (Процессы определены на уровне всей организации) по модели CMMI. Однако это не является прямым следствием, так как достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом.

Введение

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

В этой статье я расскажу о следующем:

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

Реми Кулом (слева) с компьютерной программой Crazy Stone против гроссмейстера Норимото Ёды

В 1994 году компьютер обыграл чемпиона мира по шашкам, в 1997 году — по шахматам. Сегодня компьютеры превосходят людей абсолютно во всех популярных играх с полной информацией, кроме одной — го.

У классической игры с 2500-летней историей очень простые правила, но компьютерные программы даже близко не могут подобраться к победе над лучшими гроссмейстерами, пишет Wired.

Публикуем доклад Печенкина Григория с предыдущей конференции Analyst Days 2013.

Аннотация:

В части обеспечения профессиональными инструментами, аналитики представляют собой наиболее угнетённый класс по сравнению с другими участниками разработки ПО. Аналитики привыкли к этому и часто даже не задумываются о том, как часто в своей работе им приходится использовать неудобные и неэффективные «костыли». Кроме того, аналитику обычно приходится полностью менять свой инструментарий при смене работы, так как построенные на этих «костылях» системы почти всегда оказываются уникальными и не переносимыми.
В докладе будут рассмотрены некоторые типичные костыли и грабли систем управления требованиями, а также высказаны пожелания о том, каким должен быть инструмент мечты аналитика.

Видео доклада:

Если в соседнем лесу вырубают деревья, скоро вы можете узнать об этом практически в реальном времени, благодаря новому проекту Global Forest Watch, разработанному Google в сотрудничестве с Институтом мировых ресурсов и ещё 40 организациями.

На сайте опубликованы фотографии со спутников НАСА за последние 13 лет. Более того, алгоритмы обработки изображений позволяют детально подсчитать объёмы потерянных и выросших лесов на каждой территории и в каждой стране, по годам. Например, вот статистика по России за 2000-2013 гг: потери 36,5 млн га, выросло только 16,2 млн га (1-е место в мире по потере леса); Украина: -565 тыс. га, +353 тыс. га; Беларусь: -416 тыс. га, +375 тыс. га.

Адам Мадьяр — компьютерный гик, бросивший университет, фотограф-самоучка, Руб Голдберг высоких технологий, путешественник по миру и художник-концептуалист с растущим мировым признанием. Но никто не мог предположить, что он может быть еще и террористом, до того утра, пока он не спустился на станцию метро Юнион-Сквер в Нью-Йорке.

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

По работе я пишу тексты: посты на хабр, email-рассылку, статьи в СМИ. Пишу уже пару лет, последние полгода не меньше двух текстов в неделю. Значительным шагом в развитии моего навыка письма было открытие для себя информационного стиля и советов Максима Ильяхова.

Цель текста в информационном стиле — донести информацию до читателя. Информационный стиль: лаконичный, однозначный, точный и объективный. В информационных текстах нет лишних слов, эмоций, личного мнения. Они читаются легко и быстро.

Максим вводит понятие стоп-слов. Стоп-слова не характерны для текстов в информационном стиле и если вы встретили его — задумайтесь и перефразируйте это место. Стоп-слова это «кстати», междометия, модальные глаголы, отглагольные существительные и другие, всего около 100.

В какой-то момент мне стало сложно искать эти слова в текстах, поэтому я создал себе в помощь Test The Text. Test The Text выделяет в тексте слова нехарактерные для информационного стиля и объясняет почему.

1. Что такое IEMs?

Внутриканальные наушники (англ. In-Ear-Canalphone), еще именуемые как затычки, реже ухо-мониторы или (правильное) IEMs (в дальнейшем в статье будет именно это название, т.к. оно очень лаконичное и нравится автору) — это наушники, внешне очень похожие на вкладыши, но разработанные для максимальной звукоизоляции ушного канала слушателя. Ее (звукоизоляцию) еще называют, звуковая «герметизация», — она имеет две функции: блокировка лишних шумов и формирование звуковой площади (камеры) для достижения полноты звучания. Создает такую герметизацию насадка, надетая на сопло наушника и вложенная в переднюю часть ушного канала. Существуют также наушники, где насадка создана по слепкам ушей владельца, — они называются (у русскоговорящей аудитории) кастомами (англ. Custom molded earplugs), — подобные вещи служат для достижения максимального качества звука и комфорта от прослушивания.

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

Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.

Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.

Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.

В данном посте я расскажу о наиболее интересных командах, которые могут быть очень полезны при работе в консоли. Однозначных критериев определения какая команда лучше другой — нет, каждый сам для своих условий выбирает лучшее. Я решил построить список команд на основе наиболее рейтинговых приемов работы с консолью от commandlinefu.com, кладовой консольных команд. Результат выполнения одной из таких команд под Linux приведен на картинке. Если заинтересовало, прошу под кат.

«Что? Стивен Кинг „Как писать программный код“ ?! Нет такой книги! Да он вообще не программист ни разу!».
Да, так и есть. Тем не менее — книга с таким содержанием у него есть. Хотя он и не думал, что пишет её об этом. Хотя в результате написал. Хотя, наверное, и не знает об этом. О чём же я тут рассуждаю? О недавно прочитанной мною прекрасной книге «Как писать книги» (англ. — «On Writing»).

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