Pull to refresh
25
0
Евгений Тарасов @tranquil

Пользователь

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

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

Та же ситуация кстати с С++.
«Кстати, если вы ещё не используете принцип дополнительных продаж в своём бизнесе, его стоит попробовать. Это отличный метод увеличить прибыль («не хотите ли ещё и жареной картошечки на гарнир?»)»

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

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

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

Я понимаю все ограничения, в которых работают авиакомпании и я вполне доволен сроками вылета, которые мне называют. Тем более что чаще всего всё происходит гладко без задержек.
Представьте что вы летите в Лондон.

Вы приходите покупать билет, вам дают билет на рейс #12345.
— А когда вылет? Мне нужно на 10 число — говорите вы.
— Мы не можем сказать точно, как только лайнер закончит предыдущие рейсы.
— А когда это хотя бы примерно будет? Ну, там через 2 дня или через месяц?
— Мы не знаем, много не поддающихся контролю факторов. Мы просто делаем свою работу хорошо, мы вам позвоним когда самолёт освободится.

Что поделать, видимо они действительно профи.
Через неделю раздаётся звонок:
— «Здравствуйте, начинается подготовка к вылету самолёта на рейс #12345»
— Что ж вы так внезапно то, ладно выезжаю.

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

Через полтора часа объявляют о посадке на рейс #12345.

«Здравствуйте, вас приветствует командир корабля Иван Петров. Мы готовы к взлёту, сколько продлится полёт мы не знаем. Долетим ли мы — мы не знаем. Куда мы прилетим — мы тоже не знаем. Желаем вам приятного полёта!»

Вы зовёте стюардессу и говорите:
— Что за ерунда, я же брал билеты на Лондон, а вы говорите что не знаете куда прилетим!
— А вы посмотрите внимательнее, там написано не «пункт прибытия: Лондон», а «куда я хотел бы попасть: Лондон». Может нам придётся совершить вынужденную посадку где-то ещё, или вдруг нас угонят террористы, или вдруг аэропорт Лондона не сможет нас принять по техническим причинам, или вдруг мы разобъёмся. Мы не можем сказать точно.
— Почему вы говорите о том что мы разобъёмся?
— Это не исключено.
— Но ведь вы профессионалы, мы ведь скорее всего долетим?
— Нет, это совершенно нельзя сказать заранее, это не предсказуемо, может и разобъёмся.
— А почему вы так спокойно об этом говорите, вы не боитесь за свою жизнь?
— Видите ли, весь экипаж состоит из опытных скайдайверов и на нас надеты парашюты, — поворачивается и показывает парашют.
Значит у нас с вами сильно отличается базовое понимание о том что такое оценка сроков и для чего она нужна =)
Мне кажется у нас с вами разные теории вероятности =)
Я думаю эти действия не полностью раскрыты.
Нужно не «помогать шефу» и «вести себя правильно с шефом», а «помогать всем» и «вести себя доброжелательно со всеми». От уборщицы до директора. А шеф это просто частный случай.
«С моей стороны — скажем, неделю обкатать в лабе, и еще неделю на внедрение в продакшн. А потом в лабе вылезет баг, устранение которого вендором займет месяц. Устранили, начинаем аккуратно внедрять — и по ходу дела еще один баг вылез, который невозможно было обнаружить в лабе, и еще месяц ожидания.»


Я считаю что это отличный профессиональный прогноз сроков.

«А черт его знает.»

А это нет.

Вот 2 графика распределения вероятности окончания проекта. Первый — «черт его знает» — от 0 до бесконечности. Второй — с грамотным анализом сроков.
По какому из графиков можно принимать более успешные решения?


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

Это ведь типичная задача Ферми.
Ещё эта задача связана с теорией вероятности, ответом может быть распределение вероятности с самым вероятным значением и отклонениями.

Ещё конкретно вопрос со скоростью выкатки фиксов можно обернуть себе во благо. Можно например рассказать каковы ожидаемые сроки выкатки исправлений сейчас и как эти сроки изменятся с внедрением Continuous Delivery. А потом предложить потратить время на разработку инструментов Continuous Delivery, тем самым «продав» менеджменту чисто инженерную задачу, которую клиенты никогда не увидят.
В андроиде от шифрования одно название.

Утверждают что там dm-crypt — полное шифрование блочного устройства.

1) Шифрования нет.
Я проделал следующие действия: зашифровал раздел, создал документ, сбросил к заводским настройкам. Теперь телефон начал загружаться без запроса пароля на расшифровку. И файл на месте.
В dm-crypt должно быть невозможно получить доступ к данным без пароля и невозможно преобразовать зашифрованный раздел к незашифрованному — нужно каждый байт переписывать.

Более того, в dm-crypt очень сложно преобразовать незашифрованный раздел к зашифрованному. Поэтому сказочно быстрое преобразование раздела по кнопке «зашифровать мой телефон» очень сомнительно.

2) Пароль обязан быть одинаковым на блокировку телефона и на раздел.
Это полный бред и искусственное огранчение стойкости шифрования. Телефон разблокируется пальцами и четырёхзначное число достаточно надёжно.
Раздел же расшифровывается автоматическим брутфорсером с гигантской скоростью подбора паролей. Надёжным разработчики dm-crypt считают пароль больше 10 символов, с капсом, цифрами, специальными символами. Такой пароль невозможно использовать, так как его придётся вводить каждый раз для разблокировки.
В нормальных системах пароль на раздел спрашивается один раз при загрузке, а для блокировки — другой пароль.
В ITIL одних ролей 26 штук, это больше чем людей в некоторых организациях =)
Всякие change manager, risk manager, facility manager, security manager, deployment manager, service desk manager, finance manager, incident manager, relationships manager, их там целая толпа.
Хотя может быть для организаций уровня газпрома можно просто взять и внедрить.
… и по совместительству босс…
«и кроме того, проверяют, как именно они это делают»

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

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Registered
Activity