[recovery mode] Youtube поменял дизайн

сегодня в 23:52

В очередной раз Youtube меня свою обложку.



Может быть это хорошо, а может быть и плохо. Пока что я только заметил положительные стороны данных изменений.

Первое что я хочу сказать, это то что упростился в каком — то роде дизайн. Хотя многие могут сказать, Куда еще проще. Видно есть еще проще.

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

Появились какой то странно плейлисты, которыми мало кто наверное пользуется.

Ну и много чего еще.

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Из песочницы] Эффективность команды. Расчет бонусов

Если вы — менеджер проекта и работаете с профессиональной, слаженной командой — считайте, что вам крупно повезло.

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

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



И вот, к примеру:

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


• вы рассчитываете бонусы исходя из потраченного времени. То есть, чем больше времени потрачено на проект, тем больше сумма бонусов. А если команда не эффективно тратит время, чтобы увеличить сумму бонусов? Ну или просто неэффективно тратит время? И снова цель не достигнута


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

Успешная бонусная система должна иметь ряд критериев:

1. Отражать объем выполненной работы каждым членом команды. То есть, если Оля сделала больше работы, чем Петя, сумма ее бонуса должна быть больше


2. Отражать эффективность потраченного времени. То есть, если Оля выполнила задачу быстро и качественно, это должно отражаться в сумме бонуса


3. Отражать уровень профессиональных навыков каждого члена команды. Если спектр полезных навыков Оли гораздо шире, чем Пети — это позволяет привлекать ее к различным проектам(возможно назначить ее Тим Лидом) — что должно отражаться в сумме бонуса.

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

Чтобы работала нижеприведенная система расчета бонусов необходимо следующее:

• Первоначальная оценка задачи по времени. Хоть оценка и достаточно субъективна, оценивать задачи до начала их выполнения нужно. В этом поможет наиболее компетентный член команды-Тим Лид и опыт в подобных проектах/задачах.


• Одна задача должна быть назначена на одного человека. Если нужно задействовать более одного человека — разбейте задачу на несколько и оцените каждую

Система расчета бонусов.

Для примера возьмем таблицу 1.

Табл.1 Расчет бонусов команды



*TM-team member

Из табл.1 видно, что над проектом работали 6 человек, которые сделали объем работы изначально оцененный в 804 часа. Потратили они 768 часов, т.е. вложились в план, плюс — остался некоторый запас времени. Задачи, оценка которых попала в столбец В, должны быть полностью выполнены. Конечно, не обязательно ждать окончания проекта -можно рассчитать бонусы, например, за спринт.

Данная система призвана учесть два параметра — эффективность работы и уровень профессиональных навыков.

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

Таким образом:

1. Зная ставку сотрудника в час (H1...6) и умножив ее оценочное время(B1...6), можно вычислить плановые затраты(D7). Умножив ставку сотрудника в час (H1...6) на потраченное время(С1...6), можно вычислить реальные затраты(С7).


2. Объем запланированной работы измеряется общим оценочным временем (B7), а объем выполненной работы — общим потраченным временем (С7). Далее, считаем ДОВ (доля в оценочном времени команды) (F1...6) — доля работы, которую выполнил каждый сотрудник, в общем объеме запланированной работы. Для этого разделим плановую оценку для каждого сотрудника (B1...6) на общую сумму оценочного времени (B7).


3. Чтобы перенести пропорционально объем полезной работы на реально потраченное время, нужно ДОВ(F1...6) умножить на потраченное время(C7), получим Эффективно потраченное время (G1...6).


4. Какую общую сумму выделить в данном случае на бонусы команде, решает конечно же компания, исходя из условий проекта и своего финансового положения.
   
   
   
   
   • Можно в качестве общей суммы бонуса взять разницу между плановыми и реальными затратами по проекту.
   
   
   • Можно выделить на бонусы какой-то процент от суммы договора. И, если команда вложилась в план, платить ей бонусы, если не вложилась — не платить. В общем, вариантов много...
   
   
   
   Допустим в нашем случае на бонусы по конкретному проекту выделено 16 000 каких- то у.е. (см. табл.2) Таким образом, общая сумма бонуса команды известна и нам нужно справедливо распределить ее между участниками проекта
   
   Табл. 2
   
   
   
   Чтобы узнать среднюю ставку бонуса в час одного члена команды (M9), общую сумму бонуса (М8) разделим на общее кол-во эффективно потраченных часов (G7). Т.е, если бы все сотрудники сделали одинаковое кол-во работы и имели одинаковую ставку оплаты, то каждый сотрудник получил бы одинаковую сумму бонуса (М9). Поскольку в команде 6 человек умножим среднюю ставку бонуса(М9) на 6 и получим ставку бонуса в час всей команды (М10)


5. Чтобы вычислить какую долю в ставке зарплаты команды получает каждый сотрудник, ставку сотрудника (H1...6) делим на ставку команды (H7), получаем ДЗ (доля в зарплате команды) (I1...6)


6. Далее узнаем, какую ставку бонуса в час каждый сотрудник получит исходя из его уровня профессионализма (т.е. уровня ставки зарплаты в час). Для этого, ДЗ (долю в зарплате в команде) (I1...6) умножим на ставку бонуса в час всей команды (M10) и получим ставку бонуса в час (J1...6) для каждого сотрудника


7. И наконец-то рассчитаем справедливую сумму бонуса для каждого сотрудника(K1...6), для этого умножим ставку бонуса в час на кол-во эффективно потраченных часов (G1...6).
   

   Но это еще не конец. Как мы видим сумма распределенного бонуса (K7) оказалась меньше выделенных 16 000 у.е. Это произошло из-за того, что ставки бонуса теперь согласованы с долей заработной платы каждого сотрудника в общей командной заработной плате. По идее теперь мы должны взять недостающую/избыточную сумму и распределить между людьми по той же схеме и добавить/вычесть ее к уже полученным суммам бонусов. Если опять общая сумма распределенного бонуса будет меньше/больше, нужно снова повторить операцию, пока общая сумма бонусов (K7) не станет равна выделенной сумме бонусов (M8).
   
   Но, поскольку нас волнует лишь справедливое распределение этой суммы внутри команды, мы можем не тратить время на множество итераций, чтобы приблизиться к исходной сумме бонуса и вручную подогнать сумму ставки бонуса в час всей команды. А именно, увеличить или уменьшить ее так, чтобы получить в ячейке К7 точную сумму выделенного команде бонуса.(см. Табл. 2.1 (М10) и Табл. 1.1 (К7))

   
   

   Таким образом получим финальную таблицу 1.1
   
   

   
   

   и Таблицу 2.1
   
   

   
   

Из распределения Таблицы 1.1 видно, что:

• ТМ1, ТМ2 и ТМ3 имеют одинаковую ставку оплаты, а значит уровень и кол-во навыков у них примерно одинаковы. Они сделали одинаковый оценочный объем работы, при этом ТМ1 потратил ровно столько времени, сколько было выделено в оценке, ТМ2 потратил меньше времени, чем было выделено в оценке, а ТМ3 потратил больше времени, чем в оценке. Тем не менее все они получили одинаковую сумму бонусов. «А как же эффективность работы повлияла на сумму бонуса?» — спросите вы.
  
  А теперь сравним результаты: ТМ1 четко вложился в оценку, сравним с ним остальных ТМ2 и ТМ3. ТМ2 потратил всего 100 часов из оценочных 168, значит у него осталось свободное время, которое он посвятил другому проекту и выполнил на нем некую работу, за которую так же полагаются бонусы. А значит, он получит бонусы по обоим проектам и суммарный бонус будет больше, чем у ТМ1, потому что ТМ2 быстрее сделал свою работу и поскольку работа выполнена качественно(время на переделки не затрачено).


• Посмотрим на ТМ3. Вероятно, чтобы сделать тот же оценочный объем работы, что и ТМ1 и ТМ2, ему приходилось работать на выходных (либо он очень много времени проводил в курилке и грузил время в отчеты, хотя реально работал мало) и заметьте излишне потраченные/прогулянные часы не увеличили его бонус. Он получил только сумму соответствующую реально выполненной работе, если же он и вправду работал на выходных, а не пил кофе, то он оказался наказан за то, что он недостаточно опытен и медленно делал свою работу, хотя его ставка оплаты (уровень профессионализма) такая же как у его товарищей ТМ1 и ТМ2. Если бы ТМ3 и в самом деле физически не мог выполнить работу быстрее, его навыки считались бы ниже чем у ТМ1 и ТМ2 и его заработная плата должна быть ниже. Если же он просто не добросовестно делал свою работу, то это отразилось на его сумме бонусов, за время безделья бонусов он не получает. Кроме того, на ваше усмотрение за сильное превышение потраченных часов над планируемыми, можно вообще лишить бонусов данного члена команды.


• Теперь рассмотрим ТМ6, он имеет такую же ставку оплаты как и ТМ1 и так же четко вложился в оценочное время, но он сделал меньший оценочный объем работы, поэтому его сумма бонусов меньше чем у ТМ1. Оставшееся время он вероятнее всего посвятит другому проекту и если на нем тоже четко вложится в оценку то суммарная сумма бонуса за оба проекта будет близка к ТМ1 (при условии, что второй проект имеет ту же сложность, т.е на него выделяют такую же сумму бонуса). В любом случае, если член команды успевает быстрее сделать свою работу, у него остается время сделать еще какие-то задачи этого или другого проекта и увеличить сумму бонуса за счет большего объема выполненной работы. То есть, кто быстрее делает свою работу, тот выполнит больше работы за тот же период и таким образом увеличит свой бонус.


• Рассмотрим теперь ТМ4 ТМ5 и ТМ6, все три сделали одинаковый объем работы и все четко вложились в отведенную оценку. Но ставка оплаты ТМ4 выше чем, у ТМ5, а ставка ТМ5 выше, чем ставка ТМ6. Возможно ТМ4 это Тим Лид команды, который имеет много навыков, тем самым подходит под требования множества проектов и кроме того ответственен за качество. ТМ5 имеет чуть меньше навыков, а ТМ6 умеет только что-то одно и поэтому его сложно задействовать на других проектах, он очень узконаправленный, хотя и неплохо делает свою работу. Таким образом, ТМ4 как Тим лид получает самый высокий бонус, ТМ5 средний и ТМ6 самый низкий. А значит, уровень и спектр профессиональных навыков так же учтен в данной системе расчета бонусов.

Узкие моменты данной системы расчета бонусов:

• Первоначальная оценка задачи должна соответствовать ее реальному уровню сложности. Обычно достаточно сложно сразу точно оценить задачу, но к этому надо стремиться. Кроме того, если в ходе работы выяснились новые непредвиденные детали, Тим Лид должен сообщить об этом и, если по объективным причинам не удается решить задачу в оценочное время, можно увеличить оценку. В данном вопросе важна компетентность менеджера проекта и Тим Лида и их взаимное доверие.


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


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

Вот такая математика.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Несколько приемов и советов по работе с легаси-кодом

Данная статья является компиляцией моего собственного опыта и знаний полученных из различных статей и книг, в частности «Эффективная работа с унаследованным кодом» Майкла Физерса. Стоит оговориться, что опыт мой связан только с работой с динамическими языками, поэтому не все пункты в списке применимы для всех разработчиков.

1. Не делите код на старый и новый

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

2. Почкование методов

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

Плюсы:

• новый код отделен от старого


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

Минусы:

• далеко не всегда создание нового метода является лучшим выбором с точки зрения общей архитектуры

3. Почкование классов

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

Плюсы:

• новый код отделен от старого


• возможность покрытия нового кода тестами


• возможность при дальнейшем добавлении функциональности размещать ее во вновь созданном классе


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

Минусы:

• нарушение общей архитектуры классов


• не всегда небольшие добавления в функциональности являются новой «ответственностью»

4. Охват метода и охват класса

Применяется в более простой ситуации, когда изменения не нужно вставлять в середину действующего метода или класса. В этом случае создается новый метод(или класс), который вызывает и старый код, и новый добавленный метод. Подробнее об это приеме, как и о предыдущих можно прочитать у Физерса[1].

5. Применяйте изменения как можно чаще

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

6. Пишите интеграционные тесты

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

7.Измеряйте покрытие кода тестами

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

8. Определите точки сужения

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

9. Сохраняйте сигнатуры методов

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

Если вы хотите глубже изучить данную проблему, читайте Физерса. У меня на этом все, боритесь с легаси-кодом — если вы не победите легаси-код, то однажды он победит вас.

Дополнительные ссылки

1. Michael Feathers — Working Effectively with Legacy Code

http://ift.tt/ZdNAqO

2. Kerri Miller — Harry Potter and The Legacy Code Base

http://ift.tt/1hv3DYI

3. Bryan Helmkamp — Gold Master Testing

http://ift.tt/1d5tDUx

4. David Heinemeier Hansson — Legacy Software

http://ift.tt/1qQkSEu

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Чем грозит Heartbleed простому пользователю?

Многие уже слышали про найденную в OpenSSL уязвимость. Можно с уверенностью сказать, что по освещенности в интернет-СМИ она займет почетное первое место. Про нее не только пишут, но и создают специальные сайты, проверяющие сервисы и даже рисуют комиксы. И не удивительно — масштаб поражения действительно впечатляет, по некоторым оценкам более 17% всех сайтов с поддержкой ssl уязвимы, учитывая простоту эксплуатации это событие можно сравнить с эпидемией. К сожалению, даже это для многих не является достаточным аргументом — спустя неделю многие сайты продолжают оставаться под угрозой. Это может быть не критично для простых сервисов, но не для финансовых. Особенно болезненно это может сказаться на платежных шлюзах, через которые осуществляются платежи. Об одном из таких я и расскажу.

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

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

Убедиться в этом оказалось не просто, а очень просто. Взяв один из готовых эксплоитов на github и чуть модифицировав его код уже очень скоро у меня был дамп-файл из кусочков по 64 килобайта. Что же в нем было?

В нем было все. Буквально все, что проходит через платежный шлюз: номер заказа, номер карты, CVV2, ФИО, год и месяц до которого она действительна. За полчаса работы скрипта в дампе оказалось несколько сотен реальных банковских карт и данных об их владельцах.

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю №104 (6 — 12 апреля 2014)

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

Пометьте топик понятными вам метками, если хотите

Метки лучше разделять запятой. Например: общение, социальные сети, myspace.com, подростки, мердок

или закрыть

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Симулятор доставки грузов с помощью роя квадрокоптеров

Всем привет!

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

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

За пример взяли Москву и покрыли ее сеткой из станций подзарядки\пересадки с шагом в 5 км.

Условия в мире симулятора следующие:

• Расстояние между станциями — 5 км


• Начальное распределение коптеров — по 2 на станцию (кроме самых крайних станций)


• Вместимость станции — 4 коптера


• Частота появления заказа — раз в 10 минут


• Интервал допустимых весов заказа — от 1 до 8 кг

Квадрокоптер используется со следующими ТТХ:

• Скорость полета — 16 м\c


• Высота эшелона полета — 200 м


• Время полета без груза — 30 мин


• Время полета с полной загрузкой в 4кг — 10 мин


• Скорость разряда батареи линейна относительно массы груза


• Время полного заряда батареи — 20 минут


• Скороподъемность при снижении\наборе — 6 м\c

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

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

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

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

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

Доставка двух тяжелых заказов двумя коптерами

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

Перегруппировка коптеров с занятых станций на свободные

Посмотреть симулятор вживую можно здесь — http://ift.tt/QLELSt

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

Что не учтено сейчас в симуляторе:

• Погодные условия — ветер всегда штиль. Никаких ураганов и ливней. Через некоторое время добавим, исходя из Ю-З розы ветров в Москве.


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


• Высокие здания — сейчас задана постоянная высота эшелона в 200 м, однако в реальности коптер будет использовать карту зданий с Гугла и лететь просто выше крыш всех зданий на маршруте. Это позволит сэкономить заряд на набор высоты в 200 метров там, где хватит и 50, или же наоборот подняться выше в районе Сити, Метрополии или Останкинской башни.

Итоговые предположения:

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

P.S.

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

За подробностями добро пожаловать на karlssonproject.com

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Из песочницы] Современное образование для программистов

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

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



Все 5 лет нам преподавали огромное количество математических дисциплин, начиная от Алгебры и заканчивая Уравнениями мат.физики и ТФКП. Практически по каждому из этих предметов мы писали какие-то программы (элементарный метод итерации, более сложные итеративные методы решения разных уравнений). Да, все это было, безусловно, полезным, но… Сейчас я занимаюсь реальной разработкой и фактически все вышеупомянутые навыки мне не нужны. Да, у нас были и Сети и Технологии разработки ПО и много чего другого, но количество учебных часов для этих дисциплин было настолько мизерным, а иногда и просто преподавание было не компетентным (чему может научить преподаватель, который за свою жизнь не написал ни одной программы, студентов-программистов?), что толку от них вообще очень мало.

Помимо математики, у нас была целая кучка гуманитарных дисциплин (Экологии, Экономики и т.д.), которые, конечно, вносят некоторый вклад в развитие, но зачем программисту с профессиональной точки зрения знать «как озоновые дыры влияют на климат»? Видимо предполагается, что мы будем писать «экологичные» программы — бред сивой кобылы.

Ладно, выше я рассказал как проходило наше образование. Теперь немного о Болонской системе, на которую переводят\перевели наши ВУЗы.

Если у нас на 1-2 курсах было две проф.дисциплины — ПЯВУ (Программирование на языке высокого уровня) и ООП (Объектно-ориентированное программирование), то у бакалавров эти две дисциплины «схлопнули» в одну и теперь ООП, как самостоятельной дисциплины просто нет, однако количество гуманитарных дисциплин ни на толику не уменьшили. Получается, лет через 5, когда эта Болонская система вступит в наше образование окончательно и бесповоротно, новые программисты будут Экономику знать лучше, чем «как написать хороший код»!

Вновь вернусь к себе. Приняв предложение о работе в другом конце страны, я даже не подозревал сколько материала мне придется прочесть, изучить, чтобы более-менее нормально работать (объективно, спасибо огромное коллегам за помощь)!

Читая, Интервью с Джеффри Рихтером на конференции Microsoft SWIT 2014, конкретно нижеследующий участок, я понял, что очень скоро технические ВУЗы будут просто «фейком», который будет приносить только синюю\красную корочку:

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

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

В последний день моего пребывания в родном городе, мне пришла целая горка профессиональной литературы, заказанной с огромной скидкой еще в январе. Пока ехал, читал одну из этих книжек: Роберт Гласс — «Программирование и конфликты 2.0», в которой автор говорит более корректными словами тоже, что написал я выше, т.е. такая проблема есть не только в нашем образовании, но и за рубежом. Если кратко перефразировать на простой язык, адаптировав это под отечественное ухо, то Гласс делает примерно следующие выводы: приходишь из школы в институт, тебе говорят: «Забудь все то, чему тебя учили в школе»; приходишь из института на работу, тебе говорят: «Забудь все то, чему тебя учили в институте».

Читая в свободное время статьи на Хабре, бывает натыкаюсь на статьи из разряда: «Современные junior-программисты ни черта не умеют» (буквально недели 3-4 назад читал подобную о Java, уже сейчас не найду ее). А что вы хотите, если в наших технических ВУЗах минимум 50% учебного времени тратится на изучение вещей, которые либо никогда не пригодятся, либо неактуальны уже лет 10 минимум?

Я сам довольно часто изучал и изучаю техническую литературу, посвященную практике программирования, занимаюсь самообразованием, неплохо знаю английский (читаю SO и прочее), реализовывал различные системные вещи (драйвера, в частности), но теперь не могу похвастать, что знаю C# «от и до».

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

P.S. Спасибо за внимание и потраченное время.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Из песочницы] MNP: Скидывай оковы правильно

Так уж получилось, что мне пришлось принимать активное участие в реализации и в внедрении услуги переноса номера (MNP) у одного из региональных операторов связи. На хабре уже появлялись статьи посвященные данной теме, но в них не был затронут важный вопрос — с какими же проблемами сталкиваются абоненты при переносе номера и как их избежать? Кроме того, как показала практика трех месяцев с момента отмены мобильного рабства, абоненты не до конца понимают с чем же они имеют дело. Ниже я опишу наиболее часто встречающиеся проблемы, а также особенности переноса номера, о которых не все догадываются.

Несоответствие персональных данных

Это самая банальная и в тоже время самая распространенная ошибка, которую допускает абонент. Перед тем как переносить номер, убедитесь в том, что у оператора-донора есть самая актуальная информация о ваших персональных данных. ФИО, серия и номер документа, удостоверяющего личность, а также адрес прописки. Когда Вы подадите заявление на перенос номера оператору-реципиенту, он отправит упомянутые персональные данные оператору-донору. Если хоть что-то не будет совпадать, то донор в праве отказать в переносе номера.

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

Нельзя менять оператора чаще, чем раз в 70 дней

Некоторые абоненты, разочаровавшись в новом операторе, хотят снова перейти к другому или вернуться к прежнему. Помните, что повторно сменить оператора можно только через 70 дней. Любые попытки переноса номера в этом случае будут отклонены оператором Центральной База Перенесенных Номеров (ЦБДПН).

Некоторые наиболее хитрые абоненты, желающие вернуться к прежнему оператору не дожидаясь 70 дней поступают следующим образом. Расторгают договор с текущим оператором, при этом перенесенный номер возвращается к исходному оператору, а затем бегут к нему с просьбой подключить им этот номер. Так поступать, конечно, можно, но помните, что не каждый оператор готов таким образом восстановить вам номер. Поэтому прежде, чем так поступать, узнайте у оператора — сможет ли он возобновить вам номер.

Заплатите долги

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

Переоформление договора на другое лицо

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

Зависший перенос

Когда наступает время переноса, то сперва оператор-донор отключает у себя номер, а затем оператор-реципиент подключает его у себя. Обычно эта процедура занимает несколько минут. Но может сложиться ситуация, когда донор уже отпустил номер, а реципиент по каким-то причинам не подключил его. Абонент оказывается без связи. Я наблюдал ситуации, когда связь отсутствовала в течении нескольких дней. Поэтому, если вы решили перенести номер, то стоит подумать о том, что вы будете делать в такой ситуации. Стоит запастись альтернативной sim-картой.

Отмена переноса

Если вы подали заявление о переносе, а затем передумали, то вы можете написать заявление об отмене переноса. Причем сделать это вы можете как у оператора-донора, так и у оператора-реципиента. Главное помните, что отменить перенос можно не позже, чем за три дня до даты переноса.

Другие операторы и внешние платежные системы

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

Послесловие

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Поехали!

У нас было одна ракета-носитель, 89 тонн окислителя, 4 слоя атмосферы, 200 км летного пространства и целое множество строк кода всех сортов и расцветок, а также необходимость развить первую космическую скорость, не влететь в перегрузки и выйти на гагаринскую орбиту. Не то, чтобы это был необходимый запас для полета, но если уж начал писать код, становится трудно остановиться. Единственное, что вызывало у меня опасение – это гагаринская орбита. Нет ничего более непредсказуемого, головокружительного и невообразимого, чем неуправляемая траектория ракеты. Но я знал, что рано или поздно мы выйдем на неё.

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

Что мы хотели сделать?

Сначала мы хотели создать очень простой симулятор полета: обойтись без ступеней, зафиксировать силу притяжения на всем участке полета (до высоты 200 км) и сделать траекторию прямой.

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

Для пущей реалистичности даже привлекли специалиста из ИКИ РАН, хотя один астроном в нашей команде уже имелся.

Что нужно сделать?

Нужно настроить график расхода топлива в зависимости от высоты. Заметьте, что от высоты, а не от времени, как говорит один персонаж из популярного мультфильма: «Это важно!». Больше никаких настроек, наслаждаемся полетом и изучаем слои атмосферы.

• Рано закончилось топливо? Попробуйте расходовать его более экономно.


• Ракета испытывает сильные перегрузки? Сделайте тягу меньше.


• Не забывайте, что скорость ракеты должна быть всегда положительной.


• Ракета может двигаться по инерции, даже когда топливо кончилось.

Что вам предстоит?

Вам необходимо найти оптимальную функцию расхода топлива, чтобы ракета достигла высоты в 200 км и ее скорость была не меньше первой космической (7,9 км/с).

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

На сладкое

40 лучших участников получат футболки космонавтов с принтом от нашего могучего иллюстратора. Обладатель самого лучшего результата отправится на экскурсию в ЦУП.

Cтыковка ТПК «Союз ТМА-09М» с МКС. ЦУП Королев. ©

Ну и конечно сама игра!

ПОЕХАЛИ!

Ваша команда JetBrains.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Хакеры получили $10,000 за взлом Google

сегодня в 18:00

Команда исследователей безопасности Detectify, обнаружила серьезную уязвимость на сервере Google.

В основу для взлома легла уже давно известная уязвимость XXE (XML External Entity Processing).

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

Всему виной являлся один из сервисов Google, а именно Toolbar Button Gallery. Исследователи обнаружили, что для удобства настройки тулбара, разрешена загрузка XML файла с пользовательскими настройками. Внедрив специальный участок кода в файл и загрузив его на сервер, хакеры получили нужные данные, XXE сработала.

Безопасники ограничились лишь демонстрацией уязвимости в виде чтения файлов /etc/passwd и /etc/hosts, но на этом возможности уязвимости не ограничиваются. Например, с помощью XXE можно было добиться отказа в обслуживании, SSRF, а также, при нужном подходе, выполнения произвольного кода на целевом сервере. По программе вознагражения за найденные уязвимости, компания Google выплатила исследователям награду в виде 10000 долларов.

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Обзор видеорегистратора TrendVision TV-Q5NV

Видеорегистратор TrendVision TV-Q5NV… Кто-то скажет, что модель старая и ничем не примечательная; я же скажу, что TV-Q5NV — один из самых актуальных и предпочтительных вариантов в ценовом диапазоне до 6,5-7 тысяч рублей. Данная модель выпускается с начала 2013 года по сегодняшний день. За всё это время видеорегистратор претерпел ряд изменений и доработок, как в программной части, так и в технической. Последние изменения коснулись устройства в апреле 2014 года.

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

Внешний вид видеорегистратора для многих людей очень важен и для меня тоже. При этом я никогда не купил бы видеорегистраторы больших размеров, как например: TrendVision TV-Q2N (Каркам Q2), Каркам Q4 или DOD F900. Большинство стремится купить регик небольшого размера, который умещается за зеркалом заднего вида, некоторые же вообще предпочитают регистраторы с миниатюрными выносными камерами или регистраторы в корпусе зеркала.

TrendVision TV-Q5NV представлен в форм-факторе «раскладушка» и имеет сравнительно небольшие размеры, при этом он легко умещается за зеркалом заднего вида.

При наличии шелкографии в автомобиле часть видеорегистратора будет просто скрыта и не заметна снаружи. Если «раскладушку» сложить, то снаружи TV-Q5NV вообще практически не будет видно.

Функциональность — слово многозначное и включает в себя ряд разных программных опций (SpeedCam, функция «копия для протокола», возможность регулировки экспозиции и др.) и внешних фич (питание через кронштейн, поляризационный фильтр, GPS модуль и др.). Каждый человек сам определяет важные для себя функции и в соответствии со своими предпочтениями уже выбирает регистратор. Для примера, если вам нужен GPS, то TrendVision TV-Q5NV – однозначно не ваш вариант!

Но рассмотрим те функции и особенности, которые предусмотрены в TV-Q5NV.

1. Монитор: 2", высококонтрастный. Предусмотрена возможность автоматического отключения экрана во время записи через заданный промежуток времени: 5, 15, 30, 60 секунд. Включение происходит путем нажатия на любую кнопку (кроме кнопки Power).

Визуально размеры экрана ТрендВижн TV-Q5NV можно сравнить с размерами экранов некоторых других моделей видеорегистраторов на фото:

2. Внутренняя память: есть, 256 Мб. На деле можно использовать только 211 Мб. Двухминутное видео с новой апрельской прошивкой при постоянном повышенном битрейте занимает 215-217 Мб дискового пространства. То есть если вы выбрали запись роликов по 2 минуты или больше (возможно по 1, 2, 3, 5, 10, 15 минут) и у вас установлено «наилучшее» качество записи (возможны еще два варианта: «хорошее», «обычное»), то скопировать ролик на внутреннюю память не удастся. Поэтому предусмотрен вариант редактирования ролика, то есть можно вырезать нужную вам часть и уже эту часть скопировать на внутреннюю память устройства.

Замечу, что после покупки TrendVision TV-Q5NV лучше попробовать режим редактирования роликов заранее дома, чем пытаться это делать впервые, когда вам это действительно будет необходимо. Справиться с этой задачей (с редактированием) методом «тыка» не получится, обязательно первый раз всё нужно делать по инструкции. Когда поймёте, как это делается на практике, то процесс уже будет казаться очень простым.

Циклическая запись на внутреннюю память отключена, то есть производить запись роликов в дороге можно только на карту памяти.

3. При просмотре роликов предусмотрены так же функции: масштабировании и ускоренная промотка.

4. В последней прошивке добавлен «зимний режим», проще говоря — это задержка включения на 30, 60, 90 секунд.

Многим автомобилистам, которые оставляли на ночь в сильные зимние морозы свои регистраторы в автомобиле, пришлось столкнуться с проблемой «черного экрана» и нестабильной работой видеорегистраторов при первичном включении после ночи. Почему именно этой зимой? Потому что эта проблема по большей части характерна для новых матриц AR0330, рабочая температура у которых далеко не -20°С или -10°С. А регистраторы с такой матрицей получили свое широкое распространение именно в 2013 году.

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

5. Уровень экспозиции (EV) можно задать отдельно для дня и ночи. При этом в зависимости от уровня освещения в кадре уровень EV будет изменяться автоматически! Это уже дает TV-Q5NV большой плюс. Для примера, вы едите днем с установленным вами значением EV день и заехали в неосвещенный тоннель — произойдет автоматическое переключение в EV ночь. При этом можно задать уровень освещенности, при котором происходит переключение с ночного на дневной уровень экспозиции и наоборот.

А нужна ли вообще эта автоматическая смена экспозиции? Безусловно да, если вы стремитесь получить более или менее идеальную картинку. Ведь пониженная экспозиция ночью уменьшает уровень засвета от фар и количество шумов на видео, а днем низкий уровень EV может многим не нравиться из-за относительно темной картинки. Поэтому многие, имея аппараты подобные TV-Q5NV, задают разные значения EV для дня и ночи.

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

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

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

7. G-сенсор, датчик движения.

8. Питание: 12В. Запитать видеорегистратор можно напрямую от бортовой сети автомобиля, необходимо использовать только предохранитель на 1А. Подключить видеорегистратор естественно можно так же к прикуривателю через зарядное устройство, которое идет в комплекте.

9. TV-Q5NV быстросъемный с возможностью подключения кабеля питания непосредственно в кронштейн, а не в корпус самого аппарата. То есть дергать провод питания постоянно не нужно.

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

После того, как регистратор сняли, при использовании кронштейна на липучке, на стекле останется вот такая штука:

10. Защита файла от перезаписи кнопкой, отключение микрофона кнопкой.

Надежность видеорегистратора – важнейший параметр. Пусть качество видео будет не самым идеальным (в идеале должно быть идеальным!), но регистратор обязательно должен выполнить свое основное предназначение – заснять и сохранить на карту памяти ту или иную важную ситуацию (ДТП, момент вашего НЕ нарушения правил ПДД). В Интернете достаточно много видео, которые некоторых людей спасли от уплаты штрафа, а некоторым людям сохранили свободу. При этом многие из этих роликов имеют неудовлетворительное качество картинки.

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

«Глючный» экземпляр может попасться у абсолютного любого производителя регистраторов, будь это TrendVision, Fuho, Datakam, Lukas или любой другой. Другое же дело, что существуют так называемые «детские болезни» и не совсем «детские», при выявлении которых производитель должен в обязательном порядке и как можно быстрее устранить их. Несколько «детских болезней» в свою очередь было и у TrendVision TV-Q5NV: были и программные косячки, и конструктивные. В частности TrendVision один из первых (может и первый), кто стал ставить металлические держатели объектива на некоторые свои модели, дабы устранить признаки расфокусировки при нагреве в летнее время. Хотя почти все производители на это просто забивают.

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

Качество видео однозначно должно быть хорошим. Под выражением «хорошее качество видео» каждый человек понимает что-то свое. Некоторые люди хвалят качество видео с дешевых моделей видеорегистраторов, купленных в российских магазинах за 2-3 тысячи рублей, а кто-то может сказать, что выложенные мною ниже ролики с TV-Q5NV по качеству ниже среднего; но таких людей, уверен, не будет.

TV-Q5NV модель не новая, так что видео-роликов с этого регистратора достаточно много на ютубе, да и оригинал найти не сложно. В частности оригинальные ролики можно посмотреть на форуме ТрендВижена. Я выложу несколько роликов только с ютуба:

День:

Ночь (EV=-0.7)

И приведу несколько сравнительных скринов по чтению номеров ночью. Первый скрин — TrendVision TV-Q5NV, второй — DATAKAM G5, третий — Axiom Car Vision 1100.

Технические характеристики и комплектация.

Подробнее с техническими характеристиками и с описанием видеорегистратора TrendVision TV-Q5NV можно ознакомиться на официальном сайте: trendvision.su .

Я лишь назову основные тех.характеристики: процессор — Ambarella A5S30; матрица — APTINA AR0330, CMOS 1/3", 3.5Мп; оптика и угол обзора — стеклянный объектив, 5Мп, 8 линз, F=1.6, f=2.9мм, угол обзора — 140° (105° по горизонтали); разрешение видео — 1920х1080р 30 к/с, 1280х720p 60 к/с.

В комплекте: сам видеорегистратор,

крепежи для прокладки кабеля, кронштейн на присоске, кронштейн на липучке, поворотный кронштейн,

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

О недоязыках. Лекция Михаила Даниэля в Яндексе

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

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



Рассмотрим очень распространенный пример отхода от языковой нормы, «испорченного языка».

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

Дагестанский русский

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

Особо копейки тоже нету.

Прощаться нету.

А чо стала?

…бывает жи/…жи есть.

Оставь да свою тему!

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

Разберем еще пару примеров дагестанского русского. Это цитата из речи девушки из сельского Дагестана (первый язык у нее был этнический), которая рассказывала о своей учебе в университете в Махачкале.

Письменность тоже нету, поэтому по-русскому пишу.

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

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

Приведем еще одну конструкцию, которая очень распространена в сельском русском в Дагестане, но при этом почти не встречается в городском.

Они [бабушка и ее семья] оказывается были когда совсем маленькие наверное такими дошкольного возраста, вот такой, они были выселенные в Сибирь, оказывается были выселенными в Сибирь, <…> там она ходила оказывается в школу. <…> В Сибири, там не знаю в каком города что там были… они оказывается были образованные люди, тогда в школе там учились, и если что переводить, они переводили <…>.

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

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

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

Пиджины

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

Приведем пример нескольких фраз из говорки – русского пиджина, применяющегося на Таймыре:

Это рога длинный олень./У этого оленя длинные рога.

Тебя какой люди?/Ты кто такой?

Меня видал лавка места его./Я его видел в магазине.

Чими девка-то песня пел меня сестра место./Девушка Чими пела песню для моей сестры.

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

Есть несколько типов пиджинов:

• Язык плантации (межэтнический). Такие пиджины возникали в рабовладельческие времена, когда рабам из разных племен, говорящим на разных языках приходилось находить какое-то общее средство общения.


• Язык торговли.


• Язык бродяг.


• Язык матросов. Иногда на одном корабле могли собираться носители разных языков, которым нужно как-то общаться и координировать свои действия.


• Язык обслуги.

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

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Построение тестовых окружений с помощью OpenStack

Автор: Евгения Шумахер

Евгения Шумахер – бизнес-аналитик компании Mirantis и автор предложения: How to Avoid Picking Problems that OpenStack Can’t Solve, докладчик по теме Will your Cloud be Compliant? на саммите OpenStack, который пройдет этой весной в Атланте.

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

Текущее положение дел

Пожалуй, самое важное требование к тестовой среде – чтобы она было копией соответствующей рабочей среды (хотя в действительности это не всегда на 100% так – см. ниже). Любые другие требования и ограничения вытекают из сценариев использования программного обеспечения (ПО) и методологии тестирования.

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

Рассмотрим подход к тестированию, который предполагает выполнение следующих шагов:

• выполнить тесты на предыдущей версии ПО в первой тестовой среде;

• выполнить тесты на новой версии ПО во второй тестовой среде; и

• сравнить результаты.

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

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

Такой подход имеет следующие недостатки:

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

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

• Трудности при масштабировании. Что если потребуется еще одно тестовое окружение для пользовательских приемочных испытаний или юзабилити-тестирования, к примеру? Больше ресурсов, больше времени, больше зависимостей.

• Команда тестировщиков не имеет возможности самостоятельно управлять тестовыми средами – они во многом зависят от команды IT.

А что если использовать OpenStack?

В качестве ключевых требований к тестовым средам можно выделить следующие характеристики:

• Низкие затраты на построение;

• Простая и быстрая настройка и эксплуатация;

• Простое и быстрое масштабирование;

• Возможность самообслуживания.

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

• создавать виртуальные сервера (Nova);

• создавать/прикреплять тома для хранения данных (Cinder);

• настраивать сети (Neutron);

• формировать инфраструктуры для облачных приложений (Heat).

Подходит ли вам облако?

Перенос тестовой среды в облако требует глубокого понимания тестируемого приложения (приложений) и технических возможностей для:

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

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

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

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

Если, вы уверены, что ваше приложение будет работать должным образом, и что тестирование в облачной среде будет давать осмысленные результаты, то облако (и, вместе с тем OpenStack) – это правильный выбор.

Архитектура облака

Перенос тестовой среды в облако меняет картину:

Что же требуется для переноса стека, на базе которого работает приложение, в виртуальную среду?

Предположим, вы строите облако OpenStack на существующем аппаратном обеспечении.

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

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

Во-первых, требование высокой доступности облака одно из основных. О том, как построить высокодоступный OpenStack кластер можно прочитать вот здесь: Mirantis OpenStack’s implementation of HA,

Следующим пунктом стоит вопрос производительности кластер. По данной теме полезным будет пост о способах повышения производительности вычислений в облачных средах на базе OpenStack.

Другие проектные решения, такие как:

• Конфигурация сети

o Сколько сетей вам потребуется?

o Как будет осуществляться передача трафика VM?

o Потребуется ли доступ в Интернет, и как он будет предоставляться?

• Конфигурация компонентов OpenStack

o Какие компоненты необходимо установить?

o Где следует установить сервисы OpenStack (на вычислительном узле, на узле контроллера, на каком-то другом выделенном узле, например, узле хранения данных)?

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

• Как рабочие данные копируются в тестовое окружение?

• Как часто создается или обновляется тестовое окружение?

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

Подготовка образов виртуальных машин

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

• набор универсальных образов для vCPU, vRAM, vHDD, гостевой ОС и некоторых фиксированных программ, которые установлены и настроены;

• набор образов для конкретных vCPU, vRAM, vHDD, возможно, необычных ОС и особых программ, которые установлены и настроены.

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

Heat it!

Как обеспечить разворачивание тестовых окружений?

На помощь приходит Heat, компонент OpenStack, отвечающий за оркестрацию облачных приложений.

Heat предлагает механизм шаблонов. Шаблон Heat описывает инфраструктуру облачного приложения, например, набор серверов, томов и связей между ними, сетевые настройки, в т.ч. плавающие IP-адреса, группы безопасности, настройки аутентификации и т.д. Для автоматической настройки ПО можно использовать такие инструменты, как Puppet или Chef.

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

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

Пример использования

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

Компания занимается разработкой приложений для WEB.

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

Компания выявила ряд проблем:

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

• IT-специалистам требовалось слишком много времени для выполнения запросов на создание новых тестовых окружений.

• Были трудности с масштабированием тестового окружения и/или добавления нового.

• Затраты на создание, поддержку и масштабирование тестовых окружений были высокими (отчасти из-за стоимости лицензий на VMWare).

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

• Предоставление тест-инженерам возможности создавать и поддерживать тестовую среду через портал самообслуживания.

• Оперативное создание и подготовка тестовых сред.

• Простота масштабирования и поддержки функционирования тестовых окружений.

• Низкая общая стоимость решения.

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

• Изолированность разных тестовых окружений.

• Предоставление команде IT возможности контролировать потребление ресурсов каждой командой тестировщиков.

Архитектор решений предложил построить тестовое окружение в облаке на базе OpenStack. В результате был развернут кластер OpenStack, состоящий из 10-20 узлов с высокой степенью доступности узлов контроллера.

Полученное в результате решение дает следующие преимущества:

• Для обеспечения изолированности каждое тестовое окружение работает в отдельном тенанте. Например, один проект для команды тестировщиков, другой для команды консультантов и т.д. (См. http://ift.tt/1gm76In)

• Шаблоны Heat позволяют оперативно создавать новые окружения. Команда тестировщиков может создавать новые шаблоны Heat самостоятельно.

• Самообслуживание обеспечивается через OpenStack CLI/Horizon и шаблоны Heat.

• Общая стоимость решения на базе OpenStack ниже, т.к. компании не нужно платить за лицензии и она может использовать недорогое ПО и аппаратные средства общего назначения.

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

• OpenStack позволяет сотрудникам IT устанавливать квоты на каждый проект. Компонент OpenStack под названием Ceilometer также может использоваться для мониторинга потребления ресурсов облачными инстансами.

Заключение

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

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

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

При принятии решения о переносе тестового окружения в облако на базе OpenStack важно тщательно планировать каждый шаг.

Оригинал статьи на английском языке

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Lenovo и EMC – глобальное партнерство

Добрый день, дорогие читатели Хабра!

Перед тем как писать обзоры нового оборудования и показывать вам его техническую составляющую, хотелось бы заглянуть немного назад и рассказать вам небольшую предысторию о союзе двух гигантов ИТ индустрии — Lenovo и EMC…

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

Партнерство охарактеризовано несколькими стратегическими направлениями:

Во-первых, компании формируют OEM и реселлерское партнерство, в котором Lenovo предоставит ведущие сетевые решения от EMC своим клиентам, первоначально в Китае, и далее на других международных рынках, одновременно с развитием собственного серверного бизнеса.

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

Во-вторых, EMC и Lenovo планируют перенести часть активов компании iOmega (бизнес EMC) в новое совместное предприятие, которое будет обеспечивать сетевыми системами хранения данных (NAS) малый и средний бизнес, а так же корпоративные сети.

Вывод: на рынке NAS появятся (уже появилось) качественные сетевые системы хранения данных.

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

Сетевые хранилища LenovoEMC бизнес-класса:

Сетевые хранилища Lenovo iOmega для малого бизнеса

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

Спасибо за Ваше внимание к данному материалу, а пока можете посмотреть видео презентацию по сетевым решениям (NAS) для малого и среднего бизнеса:

LenovoEMC Network Storage Desktop Family

LenovoEMC Network Storage Rackmount Family

PS: …. а так же ждите, в ближайшее время мы уделим особое внимание еще одной немало важному событию: — Серверным решениям «Lenovo ThinkServer в России»

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.