Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1214 сообщений
Cообщения с меткой

баги - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Про разделение труда и его последствия

Пятница, 19 Августа 2016 г. 10:01 (ссылка)

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



В разработке счётчика газа принимало участие трое специалистов (по факту больше, но в рамках статьи нас интересуют лишь три компетенции). Это были:


  1. Инженер-конструктор, по совместительству специалист по метрологии

  2. Схемотехник

  3. Программист

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



Требовалось измерить время нахождения клапана в открытом состоянии (расстояние от A до B), и частоту открывания клапана.

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



Устройство будет работать от батареи, так что большую часть времени микроконтроллер будет находиться в Sleep Mode. Поэтому программист попросил завести сигнал на Interrupt pin, настроил пробуждение микроконтроллера по прерыванию от соответствующего порта и в обработчике прерывания выполнял запуск/останов таймера.

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



Почему так получилось?



Некорректную работу расходомера обнаружили на раннем этапе разработки. Такие ошибки случаются и в этом нет ничего страшного. Страшно другое, никто не знал где ошибка и как её найти.

Причинами недостаточной точности расходомера могли служить:


  1. Ошибки в конструкции клапана и генератора входного сигнала

  2. Ошибки в схеме преобразования входного сигнала

  3. Ошибки в программном обеспечении

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

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



Что делать?



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

Мы видели два пути решения проблемы:


  1. Тотальное тестирование и приёмка работы каждого члена команды

  2. Человек-оркестр

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

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

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

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

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

Заглянем под капот

И вот наш человек-оркестр приступил к анализу проекта.

Анализ начался с преобразователя входного сигнала:



Оригинал схемы не сохранился, но суть её можно уловить по картинке. Как видно, схема построена на триггере (4013) и оптронах. Ложные срабатывания устранены с помощью стабилитрона D1 и RC-цепочек.

Схема вполне неплохо преобразует входной сигнал от клапана. Но при её построении схемотехник не учитывал конечную цель и специфику сигнала.

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

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

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



Человек-оркестр



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

Проще всего было решить программную проблему — запуск и останов таймера. На применявшемся нами микроконтроллере имелся Gate-controlled timer, который мог запускаться и останавливаться аппаратно, до пробуждения микроконтроллера и, если потребуется, даже без его пробуждения. Если бы программист интересовался метрологией, он бы и сам давно нашёл такое решение и постарался его реализовать. Но зачастую программистов интересует лишь программирование. К тому же было ещё два фактора, значительно повлиявших на принятие неудачных решений программистом:


  1. Программист не работал в режиме активного энергосбережения. Он просто не сталкивался с проблемой медленного пробуждения микроконтроллера и эффектами, проявляющимися в связи с этим

  2. Программист уже работал c Gate-controlled таймером и столкнулся с тем, что он просто не работает. Так что на всех последующих проектах он избегал этой функции и боялся её как огня. Как оказалось, не все программисты читают Errata и отслеживают ревизии микроконтроллеров. На ранних ревизиях микроконтроллера эта функция действительно не работала.

Попутно мы затронули точность преобразования входного сигнала. Для нас была очевидна необходимость перехода от оптронов к компараторам. Заказчика беспокоила проблема повышения потребления, он уже слышал об этом от своего схемотехника. Схемотехник отлично разбирался в своей предметной области, но даже не задумывался о функционале применяемого на проекте микроконтроллера. Мало того, что микроконтроллер уже содержал в себе два компаратора, так ещё оказалось, что нам вполне хватит одного из них, мы просто будем коммутировать нижний и верхний уровни опорного напряжения программно, без применения дополнительных внешних коммутаторов. Учитывая, что низкое энергопотребление было одним из ключевых преимуществ применяемого нами микроконтроллера, компаратор обошёлся нам очень дёшево (около 8 мкА). А высокое входное сопротивление компаратора позволило сделать достаточно недорогой по потреблению набор опорных напряжений (не более 10 мкА). В итоге имеем довольно таки простую схему обработки входного сигнала:



Т.к. От клапана приходит сигнал как положительный, так и отрицательный, мы смещаем его с помощью резисторов R1 и R2. Делителем R3-R5 мы задаём опорные напряжения. По мере снижения напряжения на батарее опорные напряжения и смещение на R1 и R2 будут понижаться синхронно, так что на точности преобразования сигнала это скажется незначительно.

Чтобы запускать и останавливать таймер за счёт применения технологии gate-control, наш микроконтроллер формирует сигналы открытия и закрытия ворот с помощью компаратора на аппаратном уровне без выхода из sleep mode. RC цепочки упразднены, так как мы можем программно управлять воротами с помощью порта RA5 микроконтроллера. Выход компаратора соединён с CLK входом триггера. Опорное напряжение компаратора комутируется программно (подключается либо C12IN0-, либо C12IN1-, в зависимости от того, ожидаем мы открытия или закрытия клапана).



Что в итоге?



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

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

Также хотелось бы обратить внимание на то, что имея поверхностные знания по широкому кругу областей, человек-оркестр на этапе собеседования не выглядит привлекательным как с точки зрения программиста, так и с точки зрения метролога и схемотехника. Но по факту он может сыграть ключевую роль в сложной ситуации.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308090/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Самые дорогие и судьбоносные ошибки в ИТ-индустрии

Вторник, 09 Августа 2016 г. 09:45 (ссылка)





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



Первый баг был зафиксирован 9 сентября 1945 года: в вычислительной машине Mark II Aiken Relay Calculator нашли мотылька, застрявшего между контактами электромеханического реле, что приводило к ошибкам. Извлеченное насекомое было вклеено в технический дневник с сопроводительной надписью: «First actual case of bug being found». Этот забавный факт и положил начало использованию слова «баг» в современном значении.



Ракета «Маринер-1»: ущерб в 18,5 млн долларов



21 июля 1962 с Мыса Канаверал был произведен запуск ракеты-носителя «Атлас», несущей аппарат «Маринер-1», который должен был отправиться к Венере. Через несколько минут после взлета ракета отклонилась от курса и была подорвана из соображений безопасности.





Фото: NASA



«Инженеры, проанализировавшие записи телеметрии, вскоре обнаружили, что причиной послужили две независимых ошибки. Антенна ведения на „Атласе“ была изготовленна некачественно, с параметрами ниже заявленных. Когда получаемый ракетой сигнал стал слабым и зашумленным, ракета потеряла привязку к сигналу с Земли, посредством которого передавались команды поворота. Такая возможность была предусмотрена; в случае потери сигнала радиоведения бортовой компьютер должен был игнорировать сигналы с неисправной антенны и выполнять собственную программу, которая, возможно, смогла бы обеспечить успешный запуск. Однако, в этот момент проявилась вторая ошибка. Каким-то образом в программе ведения оказался пропущенным дефис, что привело к некорректному управлению ракетой — уходу влево и опусканию носа. Дефис был пропущен и во время предыдущих успешных запусков „Атласа“, но эта часть программы не использовалась, т.к. не происходило разрыва радиосвязи. Таким образом, первая попытка Штатов осуществить межпланетный перелет потерпела крах из-за пропущенного дефиса.» (Oran W. Nicks, NASA, 1985)


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



Cтадион «Хартфорд Колизей»: ущерб в 90 млн долларов



18 января 1978 года болельщики чудом избежали смерти на стадионе «Хартфорд Колизей». Через несколько часов после того, как они покинули стадион, его стальная крыша рухнула на трибуны.







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



15 января 1990 года ошибка в новой версии прошивки междугородних коммутаторов привела к сбою 114 коммутаторов



Из-за этого более 60 тысяч человек остались без междугородней связи на 9 часов. Согласно программе, коммутатор должен перезагрузиться, если получит соответствующий сигнал, однако этот сигнал по ошибке пересылался каждый раз при восстановлении после сбоя какого-либо коммутатора.



Все началось с падения и перезагрузки коммутатора в Нью-Йорке, который вызвал масштабную цепную реакцию, в результате которой 114 коммутаторов перезагружались непрерывно каждые 6 секунд. Сначала компания обвиняла хакеров, однако позже выяснилось, что причиной стала одна неверная строка кода, в которой реализовывалась отправка сигнала.



Баг в процессоре Pentium: ущерб в 475 миллионов долларов



В 1994 году профессор математики Линчбургского колледжа Томас Найсли обнаружил баг в популярном процессоре Pentium и опубликовал об этом статью.

Ошибка Pentium FDIV — это ошибка в модуле операций с плавающей запятой в оригинальных процессорах Pentium, выпускавшихся фирмой Intel в 1994 году. Ошибка выражалась в том, что при проведении деления над числами с плавающей запятой при помощи команды процессора FDIV в некоторых случаях результат мог быть некорректным.



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


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







По прогнозам Intel, вероятность её возникновения была столь низкой, что подавляющее большинство пользователей даже не заметили бы её. Однако возмущённые клиенты потребовали заменить процессоры всем желающим. Финансовые потери Intel в результате составили около 475 миллионов долларов.



Ракета Ariane 5: ущерб в 8,5 млрд долларов



4 июня 1996 года случился неудачный запуск ракеты-носителя Ariane 5, которая была разработана Европейским космическим агентством. Ракета разрушилась на 39-й секунде полета из-за неверной работы бортового программного обеспечения. Эта история запомнилась, как одна из самых дорогостоящих компьютерных ошибок.







В системе управления полетом новой ракеты Ариан 5 использовались фрагменты программного обеспечения ракеты Ариан 4, в частности системы инерциальной навигации. Однако при переносе этой системы для использования на новой ракете, разработчиками не были учтены все особенности. Из-за другой траектории выведения ракеты на 30-й секунде после запуска значение горизонтальной скорости превысило установленные в программе ограничения и вызвало сбой в работе компьютера.


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



Программное обеспечение, установленное на борту Ariane 5, было разработано для более ранней модели – Ariane 4. Более мощный двигатель Ariane 5 спровоцировал баг, не встречавшийся в предыдущих версиях ПО.



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



На разработку Ariane 5 было потрачено около 8 миллиардов долларов. Общая стоимость спутников, которые должна была вывести на орбиту эта ракета, составляла 500 миллионов долларов.



Cпутник «Mars Climate Orbiter»: ущерб в 125 млн долларов



Из-за фатальной ошибки аппарат оказался слишком близко к поверхности Марса.

Аппарат летел к Марсу 9 месяцев. Mars Climate Orbiter 23 сентября 1999 года должен был выдать тормозной импульс и перейти на высокоэллиптическую орбиту с периодом 14 часов, а затем в течение двух месяцев с помощью ряда аэродинамических маневров в верхней атмосфере Марса довести орбиту до круговой. В расчетное время на высоте 193 км аппарат включил двигатели на торможение. Через 5 минут MCO запланировано ушел за Марс и больше никаких сигналов с него не поступало. Из анализа данных было предположено, что аппарат прошел над поверхностью Марса на высоте 57 км вместо расчетных 110 км и распался в атмосфере.


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



Бизнес-ошибки в ИТ



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



А ведь события могли сложиться так, что не появились бы ни Microsoft, ни Apple. В альтернативном мире главным поисковым сервером был бы не Google, а Yahoo. Самым распространенным компьютером был бы Xerox, самой популярной социальной сетью – CompuServe. А музыку мы слушали бы через RealPod.



Спасение Apple



В конце 1990-х годов продажи компьютеров Apple Mac существенно снизились. Этому способствовали более дешевые конкуренты – Power Computing и Radius. Цена акций Apple упала до $5. Но неожиданно помощь пришла от Microsoft: помощь в размере $150 миллионов. Кроме того, Microsoft пообещала продолжить разработку своего пакета офисных программ для MacOS.



Из-за такого решения Microsoft лишила себя определенных перспектив. Вполне возможно, сегодня на рынке царили бы WinPhone, музыку на них мы бы качали через WinTunes. А все пользователи до сих пор с нетерпением ожидали бы выхода достойной альтернативы Windows.







Потерянный рынок



В середине 1990-х годов, еще до появления Google, самой продвинутой поисковой машиной была даже не Yahoo, не AltaVista, не Lycos или Hot Wired. Система Open Text, как и Google сегодня, работала максимально быстро, точно, охватывая весь объем информации. В 1995 году менеджеры компании Open Text небезосновательно утверждали, что их система смогла проиндексировать каждое слово из 5 миллионов документов, которые на тот момент и составляли Всемирную сеть.



Однако в 1997 году разработчики Open Text посчитали рынок поиска недостаточно перспективным и занялись системами управления корпоративными данными. Ну а через год появилась компания Google, которая показала, что они ошибались на счет перспектив этого рынка.



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



CompuServe и упущенное лидерство



CompuServe 24 сентября 1979 года запустила первый информационный сервис MicroNET, доступ к которому осуществлялся по телефонным линиям. Сервис позволял участникам сети передавать файлы, получать доступ к новостям и событиям, обмениваться сообщениями и присоединяться к дискуссионным форумам. В 1980 году сервис был переименован в CompuServe Information Service (CIS).



Конечно, пользователей сервиса привлекали прежде всего не новости, а возможность общаться, и появившаяся в 1980 году программа CB Simulator, обеспечивающая чат в реальном времени, стала невероятно популярной. В начале 1981 года число пользователей CIS перевалило за 10 тысяч, а к началу 1990-х исчислялось миллионами, в то время сервис был самым популярным в США. Компания имела базу лояльных клиентов, обилие информации об их вкусах, полезная база знаний и практически полное отсутствие каких-либо конкурентов в этой нише.







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



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



Компьютеры Xerox



Alto от компании Xerox был первым в мире компьютером с пользовательским интерфейсом в виде окон. Он был создан за 10 лет до появления персональных компьютеров под управлением Windows и Maс, задолго до микрокомпьютеров MITS Altair.



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

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







Когда в компании поняли, что допустили серьезную ошибку, было уже поздно. Была начата работа по продвижению графической рабочей станции Xerox Star, но это уже не могло изменить ситуацию: в результате на рынке прочно закрепились персональные компьютеры с Windows и Mac OS.



Непроданный Facebook



В 2006 году, когда Facebook было всего два года, широкая общественность относилась к ней, как к узкопрофильной социальной сети для студентов. В то время на Facebook было зарегистрировано 8 миллионов пользователей. В то время как аудитория MySpace превышала 100 миллионов.



Компания Yahoo предложила Марку Цукербергу $1 миллиард за его детище. В июне 2006 года Цукерберг подписал контракт о продаже Facebook.







Однако, на фоне резкого ухудшения финансового положения Yahoo, ее тогдашний гендиректор Терри Сэмел сбавил сумму до $800 миллионов. Цукерберг отказался продавать компанию за эти деньги. Через два месяца Yahoo вернулась к предыдущим условиям сделки, но было уже поздно. После этого дела этой компании шли все хуже. Теперь она продана холдингу Verizon. В начале 2000-х годов капитализация Yahoo превышала $125 миллиардов. Теперь Verizon купила компанию всего за $4,83 миллиарда.



Странная идея



Информация о том, что iPod придумал Стив Джобс, не совсем верна. Руководство компании Real Networks не оценило идею Тони Фэделла о создании совершенно нового типа музыкального плеера. К тому времени рынок был уже насыщен MP3 плеерами.



Но его плеер был тоньше и меньших размеров, а система доставки контента давала меломанам простые способы наполнить свой плеер новой музыкой. Так, в 2000-ом году Стив Джобс согласился сотрудничать с Тони Фэделлом. Джобс доработал дизайн плеера, а другие специалисты Apple доработали систему доставки контента, которая получила имя iTunes.



В результате около 80% рынка цифровой музыки сегодня принадлежит компании Apple. Сам Тони Фэделл проработал в отделении, разрабатывающем iTunes до ноября 2008 года. А компания Real Networks все так же производит обычные плееры. Однако ее доходы не идут ни в какое сравнение с тем, сколько iTunes приносит корпорации Apple.
Original source: habrahabr.ru.

https://habrahabr.ru/post/307394/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Виолетта_Сорванцова

ОБЪЯСНЯЕМ, ЗАЧЕМ СОЗДАН POKEMON GO

Понедельник, 08 Августа 2016 г. 12:09 (ссылка)

Букв много, но почитайте, это нужно знать всем!


ЧАСТЬ 1.
ХОТИТЕ РАССКАЖУ ВАМ ИНТЕРЕСНОЕ ОБ ИГРЕ «POKEMON GO»?
Трижды давал на эту тему интервью, так что пришлось покопаться в англоязычных первоисточниках.
— Разработчик игры: Niantic Labs. Внутренний старт-ап Гугла.
— Ниантик основан Джоном Хэнком (John Hanke), так же основавшим Keyhole, Inc ( «Замочная скважина» ) — проект для картографирования поверхности, выкупленный все тем же Гуглом и создавшим на его базе Гугл-карты, Гугл-Земля, Гугл-Стритс.
— А теперь внимание. Keyhole, Inc спонсировался венчурным фондом In-Q-Tel. Это фонд ЦРУ, вполне официально созданный в 1999 году.

Посредством вышеуказанных аппликаций, были решены важные задачи:
— Обновляемое картографирование поверхности планеты, включая дороги, базы и тд. А ведь когда-то, карты-километровки считались стратегическими и секретными. В гражданские карты даже специально вносились погрешности.
— Автомобили-роботы от Гугл-Стритс заглянули во все переулки, картографировав наши города, машины, лица…

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

И что бы вы думали? Все та же конторка, Niantic Labs, выпускает гениальную вирусную игрушку, новомодной технологии дополнительной реальности. Стоит вам скачать приложение и дать ей соответствующие права (доступ к камере, микрофону, гироскопу, GPS, подключаемым устройствам, в том числе — носителям USB и тд), и ваш телефон тут же завибрирует, сообщая о нахождении первых трех покемонов! (Первая тройка всегда появляется сразу и поблизости).
Игра потребует заснять их со всех сторон, счастливо наградив вас первым успехом. А заодно получив фото помещения где вы находитесь, включая координаты и угол наклона телефона.

Поздравляю вас! Вы только что провели съемку вашей квартиры! Дальше объяснять?

Кстати, устанавливая игру, вы принимаете условия оферты. А она — не простая. Niantic вас официально предупреждает: «Мы сотрудничаем с государственными структурами и частными компаниями. Мы можем раскрыть перед ними любую информацию о вас или вашем ребенке…». Но кто же это читает?

А еще там есть пункт 6: «наша программа не имеет возможности выполнять запрос вашего браузера «Do not track» — «Не следи за мной». Другими словами — следили и будут следить.

Читать далее...
Метки:   Комментарии (4)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Кого волнуют баги продукта, если он успешно продается

Воскресенье, 31 Июля 2016 г. 20:19 (ссылка)



Изображение сайта media.licdn.com



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



По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.



Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений. Зато очевидным преимуществом этих компаний является удачная бизнес-модель. В купе с активным продвижением, эти сервисы смогли стать одними из самых востребованных и дорогих стартапов мира. Но вряд ли они нанимали десятки инженеров, чтобы разработать сервис и подготовить его к запуску, сомневается Половетс.



Однако он признает, что есть компании со сложными технологиями, требующими тщательной и выверенной реализации: SpaceX, Zoox, Rigetti Quantum Computing. Но, по его мнению, эти исключения только подтверждают правило.



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



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



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

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



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


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



Джон Эванс из HappyFunCorp обращает внимание на проблему качества продуктов, сделанных на скорую руку (Startup Software Quality Problem). Многие проекты разрабатываются под флагом Minimum Viable Product (MVP), что нередко создает стартаперам больше проблем, чем пользы.







«MVP (минимально жизнеспособный продукт) — простейший работающий прототип продукта, которым тестируют спрос до полномасштабной разработки. Такой подход страхует предпринимателя от невостребованности конечного продукта и потери потраченных на разработку ресурсов». (Словарь предпринимателя: MVP | Rusbase).



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



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







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



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



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



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



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



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



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



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







Еще один пример от Аркадия Морейниса – ситуация, когда роль ПО второстепенна:

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



Они пошли в ближайший супермаркет и начали ловить тетушек. То есть они буквально подходили к тетушкам, которые ходили закупаться в этот супермаркет и говорили: «У нас есть сервис — за 9,95 долларов в неделю мы можем вам привозить продукты и рецепты на целую неделю готовки».

Они нашли первую тетушку, которая согласилась заплатить им $9,95. После этого они опять же не побежали программировать. Они начали подбирать рецепты, закупать товары, резать, раскладывать по мешочкам и каждую неделю приносить все это тетушке и выслушивать от нее всю обратную связь за прошлую неделю. И получать свои законные $9,95.



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


Пример Netflix



Старт с продуктом в качестве услуги – с этого начинал свою деятельность Netfix.

Netflix появился на свет в Калифорнии, его основателями стали двое мужчин: Рид Хастингс и Марк Рэндольф. Хастингсу пришлось заплатить огромную неустойку за возвращение с опозданием фильма, который он брал напрокат. Именно тогда к нему пришла идея создать сервис, который позволит заказывать по электронной почте фильмы без штрафов за опоздания с их возвращением.



Сразу же после этого они начали давать напрокат друзьям коллекцию своих фильмов – так зародился Netfix. Это может показаться очевидным, но, если вы спросите большинство предпринимателей, как они начали бы свой собственный Netflix сегодня, вы получите очень подробные технологические ответы.


Для стартапа жизненно важно создать продукт, который действительно нужен людям. Как уже говорилось, продукт – это не только софт. Но если стартап построен вокруг какого-то программного обеспечения, то даже при изначально высоком спросе проект может сойти на нет из-за проблем с ПО.
Original source: habrahabr.ru.

https://habrahabr.ru/post/306814/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] World of Warcraft: одна строка кода, чтобы потерять все

Четверг, 28 Июля 2016 г. 16:10 (ссылка)





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



/run RemoveExtraSpaces=RunScript


Интерфейс WoW (например, строка меню, окно чата и другие 2D графические элементы) и также дополнения написаны на языке Lua. Обе стороны строки — RemoveExtraSpaces и также RunScript — легальные функции и часть WoW Lua API. Но введение этой строки кода в диалоговом окне изменяет поведение интерфейса WoW.



Что делает эта команда на самом деле?



/run — команда для интерпретации следующего текста как сценария Lua.

RemoveExtraSpaces — встроенная функция, которая удаляет ненужные пробелы из текста.

RunScript — функция, которая выполняет текст в качестве кода Lua (аналогично команде /run)



Чем это опасно?



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



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





Ничего не подозревающий игрок собирается отправить вредоносную строку кода





Злоумышленник отправляет сообщение в чате жертве





Полученное сообщение интерпретируется как Lua код и затем выполняется



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



Временное скрытие и сохранение команды



После того как жертва открыла бэкдор в свой интерфейс, злоумышленник отправляет следующее сообщение:





Атакующий устанавливает новый канал передачи данных



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



Для того, чтобы понять цель этой команды, нужно знать что в WoW есть возможность общаться с помощью скрытого канала (локально и удаленно). Этот канал установлен через использование событий “CHAT_MSG_ADDON”.







Сценарий создает фрейм (строка 2), к которому можно установить различные свойства. Сценарий регистрирует события CHAT_MSG_ADDON с конкретным префиксом (строка 6 и 25). Только тот, кто знает выбранный префикс, может тайно управлять интерфейсом жертвы. Это все равно что пароль для бэкдор.



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



Вывод: пока злоумышленник не решит Вам показать, что происходит, Вы, к сожалению, про это не узнаете.



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



Какой вред может быть причинен?



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



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



Как можно себя защитить?



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



В данном примере мы говорили об атакующем персонаже в игре, кто принадлежал к популярной гильдии. Но по факту он не принадлежал к этой гильдии. Он выбрал известную гильдию и скопировал имя, заменив “L” на “I”. Возможно, Вы уже знакомы с такими методом фишинг-атак.



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



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







Выбор “Yes” отключает сообщение навсегда, даже перезапуск не вернет его – по этой причине вопрос нельзя считать решенным. Чтобы повторно активировать данное сообщение, нужно вручную удалить одну строку кода в конфиг-файле.



Код, который должен быть удален:SET AllowDangerousScripts "1"

Файл: config-cache.wtf

Путь: World of Warcraft\WTF\Account\\
Original source: habrahabr.ru.

https://habrahabr.ru/post/306618/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Уязвимость в электронном дневнике или как украсть персональные данные 2-х миллионов пользователей

Среда, 18 Мая 2016 г. 19:29 (ссылка)


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



В этой статье пойдет речь о багах/уязвимостях в том же проекте. Читать дальше →

https://habrahabr.ru/post/283464/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Дыра в авторизации Gmail?

Вторник, 17 Мая 2016 г. 09:07 (ссылка)


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

Однако, сегодня меня ждал интересный сюрприз. Стоило мне открыть почту, как на меня посыпались ссылки на регистрацию в Avito, потом подтверждение (!!!) адреса электронной почты, потом подтверждение номера чужого номера телефона. Читать дальше →

https://habrahabr.ru/post/300964/

Комментарии (0)КомментироватьВ цитатник или сообщество
Кикайон

Ну что, опять Лиру накрылся?

Пятница, 29 Апреля 2016 г. 22:37 (ссылка)

















 



Сижу сегодня - тихо и спокойно.

Ни я ни к кому не хожу, ни ко мне никто не заглядывает.

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

Прошла по дневникам.

Ну, что сказать? Новые посты есть, и не по одному, а ко мне ни одно извещение на почту не пришло. Значит, и мои ни к кому не попали.



Перегенерировала все настройки - ноль.



142 (500x327, 151Kb)



То, что вот уже неделю в фотоальбоме, да и в общей фотогалерее не отражаются картинки - уже, кажется, никого и не волнует.



Редактирование поста занимает полдня - так "весело" страницы грузятся.



А что, привыкли к плохому. Вот и дальше привыкайте.



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



 










29 (350x525, 72Kb)

r76 (2) (500x671, 243Kb)


 



622 (700x163, 141Kb)



Если сами не справляются - пусть обратятся к толковым специалистам! Недорого.



adminjpg-photosession_full (548x562, 113Kb)



А у меня уже просто на все это нет слов - одни буквы...











eb (100x100, 6Kb)




pizdets (100x100, 5Kb)




 Впрочем, выбор всегда за нами.



r5-(1) (350x335, 137Kb)

Приношу глубокие извинения, если чьи-то эстетические чувства ранила почти ненормативной лексикой.  






 


Метки:   Комментарии (10)КомментироватьВ цитатник или сообщество

Следующие 30  »

<баги - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda