Логика ты моя всёмоёшная …

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

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

Но сразу же выяснилось, что просто так использовать правила “размер в 1/10 экрана” нельзя. Иначе на устройствах с большим экраном (iPad или 27″ монитор) элементы управления начинают напоминать игрушечные: такие же больше и аляповатые. В общем, необходимо размеры некоторых элементов привязать к реальному размеру.

Qt тут помогает. В нем есть Screen.pixelDensity (берем из QtQuick.Window 2.1), который говорит о числе точек экрана на миллиметр. И если нам нужен размер чего-то в сантиметр, то просто ставим Screen.pixelDensity*10 и проблема исчезает.

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

Но я отвлекся. Итак, у нас есть формочка с двумя полями ввода, чекбоксом и кнопкой “войти”. Как все это дело обрабатывать? Ну что бы было удобно пользователю и программа не мозолила ему мозги со всякой дрянью?

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

Запуск VseMoe

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

Что я преследовал, рисуя кучу этих линий?

– Если пользователь поставил галочку “запомнить меня”, приложение должно запускаться без каких-либо вопросов, запросов и прочего. Всякие блокировки оставим операционной системе.
– Однако пользователь может быть немного параноидальным и не хочет, что бы кто-то, кто имеет право пользоваться телефоном (ребенок к примеру), что-то там понатыкал. Защита обычным пин-кодом.
– Если пользователь специально на каком-то устройстве снял галочку “запомни меня”, засинхронизировался и перелогинился, то все остальные устройства при первом же подключении к сети должны заново запросить пароль и засинхронизироваться заново. Это защита от утери устройства/утечки токена.
– Ну и устройство не должно при обычной работе лезть в интернет за синхронизацией, если пользователь не разрешил. Говоря другими словами, настройки “синхронизироваться только через wifi” и “синхронизироваться только вручную”.

Как-то так. Про реализацию в следующем посте.

Что нести в облачный офис?

Итак, несмотря на мои страшилки в предыдущих постах, вы все-таки решили использовать “облака” в своей деятельности. Хоть чуть-чуть, но использовать. Как выбрать то, что стоит нести в облака, а что не стоит?

Для этого есть несколько методик, ниже я попробую объяснить наиболее … подходящие, что ли.

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

“Ну ладно, веб-сайт понятно, а как же с почтой и телефоном? Их смогут читать/слушать чужие люди?”. Да, при наличии соответствующих навыков или всяких судебных решений их и так будут читать и слушать чужие люди. Если говорить про телефон, то на операторе (тот, который выдал вам телефонный номер) уже стоит система, позволяющая прослушивать все телефонные разговоры, проходящие через него. А что касается внутренних переговоров, то они в большинстве случаев абсолютно никому не интересны и способны забить любой сервер. То же самое касается и почты. Буквально пара команд у провайдера, который предоставляет вам доступ в интернет, как весь ваш трафик оказывается у него как на ладони. И не обольщайтесь насчет страшных слов SSL/TLS – в подавляющем большинстве случаев все вскрывается так же легко, особенно при наличии административного ресурса. Правда, вынужден добавить ложку меда: по разговорам со знакомыми, такое используют очень редко, ибо во-первых, принцип “неуловимого джо” никто не отменял, а во-вторых, через налоговую сделать все необходимое гораздо проще.

Следующая методика “берите все, что нам негоже”. Тут в облака отправляются данные, которые вам не нужны прямо сейчас или которые нужны всем. Тут главное установить принцип, насколько эти данные вам не нужны. Скажем, данные от систем резервного копирования вам именно сейчас не нужны, занимают много места и хранение их рядом с резервируемыми системами прямо противоречит всем нормам. Так зашифруйте их посильнее и пусть лежат где-нибудь в Америке. Что касается данных которые нужны всем: зачем устраивать на своем сервере каталог “для скачки”? Ролики, дистрибутивы программ и прочие подобные штуки с удовольствием примут к себе системы CDN. Будут довольные и пользователи, которые будут скачивать необходимое им быстро и Вы, так как канал до вас (или вашего сервера) не будет загружаться.

И наконец, в облака удобно/выгодно отправлять то, что относится ИТшному понятию R&D. Говоря кратко, то, что запускается “на посмотреть”, меняется по двадцать раз на дню и наполняется тестовыми или сильно устаревшими данными.

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

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

А теперь абзац неприкрытой рекламы меня любимого: мне нравятся “облака” и я готов совершенно бесплатно (конечно, не откажусь и от оплаты, если предложите 🙂 ) поконсультировать/помочь/рассказать как сделать по поводу “облаков”. Просто из любви к теме. Я не связан с каким-либо провайдером или сервисом “облаков” или производителем систем виртуализции, поэтому мне абсолютно начхать на маркетинговые заморочки. Пишите письма на multik@multik.org, в skype пользователю kiltum или оставляйте комменты.

Дорогие мои облака …

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

Наверняка вы уже задумывались о использовании “облаков” в своем бизнесе, но простые расчеты на калькуляторе и консультации с ИТшниками неизменно приводили к обескураживающим результатам: стоимость аналогичного, но “облачного” сервиса неизменно оказывалась в 1,5-2 раза выше. Как же так? Ведь вон сколько компаний использует облака в своей работе и рапортуют о снижении расходов … А тут ИТшники опять начинают свою вечную волынку про недостаток серверов … Что делать?

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

1. Фаирволл. Он же брэндмауэр. Штука, которая выпускает вас в интернет, фильтрует лишнее и иногда служит HR-инструментом под названием “на какие сайты ходят сотрудники”. Хватит 50 тыщ.
2. Почтовый сервер. Без почты нынче никуда. Тут лучше заложить где-то в районе 100 тыщ.
3. Веб-сервер. Сайтик обычно много нагрузки не требует, поэтому тоже 50.
4. Сервер телефонии. Положим те же 50 тыщ.
5. Сервер бухгалтерии. Бухгалтера люди нервные, поэтому 100 тыщ и не надо экономить.
6. Файлопомойка. Сотрудникам надо файликами обмениваться. Возлагать это на почту – моветон. Тыщ 80 надо.
7. Резервное копирование. Есть компании, где уже теряли данные, а есть, где еще только будут. Тыщ 100.

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

Итого получается в районе 550 тысяч рублей. Эти 7 коробок жрут электричество, требуют охлаждения, запасных частей и квалифицированного присмотра. Через некоторое время их мощности начинает не хватать и начинаются узаконенные репресии пользователй в духе “более 500 мегабайт в почтовом ящике не хранить” и “бухгалтерия тормозит, потому что в сервере винт сдох” (хорошо, что тормозит. у некоторых просто падает). Знакомо?

Что делать? Бизнес растет, но на одних серверах разориться же можно … И тут в дело вступает хороший, качественный ИТшник. Срываю так сказать, покровы. Для начала: одиночные сервера никогда не загружены на 100%. Из-за разных там особенностей больше 60-70% нагрузку поднимать попросту нельзя: будет все ломаться.

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

Отсюда вытекает вполне логичное предложение: почему бы серверу резервного копирования не поделиться днем своими ресурсами? А серверу бухгалтерии и файлопомойки ночью? С использованием современных технологий – легко.

Сам процесс объединения стайки серверов в “облако” я пропущу. Вам это во-первых попросту неинтересно, а во-вторых, там слишком много нюансов, описанию которых пришлось бы посвятить много места.

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

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

Что вы получаете?

– Возможность продать один-другой сервер. Подчеркиваю – возможность (ИТшники просто так не выпустят из своих рук 🙂 ). Ибо если одиночные сервера нельзя грузить на 100%, то в “облаке” вполне.
– Более высокую доступность серверов. Теперь в случае поломки одного из “железных” серверов есть возможность попросить “пододвинуться” другие, пусть и за счет уменьшения скорости работы.
– Возможность отдавать более мощный сервер (у нас же сервера не одинаковые изначально) на более необходимую сейчас работу. Скажем, днем самый мощный сервер будет помогать процессу сдачи бухгалтерского отчета, а ночью обрабатывать данные для системы резервного копирования.
– Более разумно распределять нагрузку. Скажем, отобрать ночью у почтового сервера ресурсы процессора в пользу других. Пусть письмо ходит не 1-2 секунды, как днем, а 10-20. Кому какая разница?

А теперь о более приятном. Если делать подобное с “нуля”, то более высокую производительность и бОльший запас по мощности всего комплекса можно получить с помощью пары серверов, каждый из которых стоит по 200тр. И эти серверы будут жрать меньше электричества, меньше греть окружающую среду и требовать меньший уход. 150 тысяч экономии прямо “в лоб”!

Но это “частное облако”. Как же можно заработать или сократить расходы с помощью публичных облаков?

Для начала можно легко увеличить безопасность вашего бизнеса. Не знаю как в других странах, но в России до сих пор не изжили “изъятие вещественных доказательств”. С одной стороны, счет не заблокирован и на нем есть деньги, а с другой – все данные остались на тех самых “вещественных доказательствах”. Вот для примера бухгалтерия. Объемы базы данных очень редко превышают еденицы гигабайт. Вот возьмите и дайте задачу, что бы система резервного копирования попутно заливала данные еще и туда. Для безопасности – хорошо зашифрованными. Сейчас стоимость хранения одного гигабайта на S3 – $0.03 в месяц. Да, я не ошибся – три цента за гигабайт в месяц. Добраться до архивов можно будет с любого компьютера, подключенного к интернету, а уж что с ними делать – дело ваше. Сравните со стоимостью хранения подобного где-нибудь на стороне “обычным” способом.

Затем рассмотрите свои бизнес-процессы и выделите те, которые требуют непродолжительных, но больших компьютерных ресурсов. Скажем, в каком-нибудь рекламном агенстве это может быть процесс рендеринга роликов. Покупать для этого отдельный мощный сервер, который будет 90% времени пинать балду – не выгодно. А без него никак. Куда лучше за $3 в час арендовать гораздо более мощный сервер в облаке и использовать его только тогда, когда надо. И кто мешает арендовать не один сервер, если роликов много?

Надо изредка рассылать большие объемы писем (и которые ни разу не спам)? Вон, SES берется доставить со всеми заморочками тысячу писем за 10 центов. Стоимость обычного почтового сервера, способного переварить хотя бы 20-30 тысяч писем за час, предлагаю узнать самостоятельно.

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

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

И подобных возможностей в каждой компании – уйма. Честно.

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

А таких – мало.

Облака, белогривые лошадки …

… или о облаках простыми словами.

Покупайте наших слонов, теперь и в облаках! Самые облачные облака по выгодным тарифам!

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

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

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

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

Ушлые маркетологи мгновенно раскопали ассоциацию и начали толкать “облака” в массы. В результате вышеописанное (несколько мощных серверов, которые стоят в серверной у вас за стенкой) стали называть “частное облако” или private cloud.

Тут же появились провайдеры, которые стали предлагать “облака” для всех страждущих. Такие облака стали называть “публичными облаками” или public cloud. Услуга довольно быстро стала популярной: ведь большинству людей не нужны для своих задач мощные компьютеры, а провайдерам очень дорого обслуживать обычные слабые сервера.

Следующим появились на свет “гибридные облака”. Это когда часть виртуальных серверов работает в серверной за стенкой, а часть – у провайдера. А для вас – ну абсолютно никакой разницы, где они размещены. Вы работаете с ними одинаково во всех случаях.

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

Итак, в чем же основное преимущество облаков?

– Снижение расходов на серверный парк. По моим прикидкам, переход с классической схемы (один сервис – один сервер) на облачную (много серверов – много сервисов) дает экономию примерно в 20-30% просто от самого факта использования.
– Снижение времени простоя. Теперь для обслуживания “железного” сервера нет необходимости останавливать работу размещенных на нем сервисов.
– Резкое ускорение специфических для ИТ задач. Поднять новый сервер или скопировать работающий – дело минут, но никак не часов.
– Возможность при наличии соответствующих навыков кратковременно и очень резко увеличивать мощность какого-либо сервиса.

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

“Старые” облака (провайдер вам предоставляет один или несколько серверов, возможно объединяя их в одну сеть с вашей) стали называть IaaS (Infrastructure as a service). Инфраструктура как сервис. Легко понимаемая всеми ИТшниками модель. Яркий пример – Amazon

Вон та возможность резко увеличивать мощность (повторюсь, при наличии навыков!) привела к следующему варианту облаков: PaaS (Platform as a service). Платформа как сервис. Пример – Azure. Суть простая. Берет провайдер толковых спецов, которые настраивают какой-либо сервис как надо. А потом продает этот сервис вам. Скажем, у вас есть веб-сайт, на который приходит 1000 человек в день. Ваши маркетологи, продавцы и прочие товарищи что-то такое замутили, что к вам внезапно пришло 100000 человек. Обычно веб-сайт в таких случаях тупо умирает под нагрузкой. В случае PaaS правильно настроенный сервис начинает поднимать для внезапно свалившейся нагрузки еще сервера. Десять, сто, тыщу. В общем пока не переварит весь поток. А потом точно так же берет и “убивает” ставшие ненужными сервера. В итоге все довольны: пользователи увидели ваш сайт, а не сообщение о недоступности, вы получили новые заказы, а провайдер – деньги.

Очень это понравилось маркетологам и они придумали SaaS (Software as a service) или программа как сервис. Оно очень похоже на PaaS, но про отдельный сервис. Скажем, вам нужен почтовый сервер. Можно сказать админу, он купит сервер, настроит его … А можно пойти к провайдеру и купить доступ к его почтовому серверу. Если у вас в компании 100 человек, так и купите кусочек провайдерского сервера на 100 человек. А провайдер пусть уже сам мучается с антивирусами, антиспамами и прочей фигней. Яркий пример – Office 365.

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

Думаете это кого-то остановило? Неа, просто стали продавать старое под новым соусом.

И для резюме нужно подвести итоги. Сравним их с привычной всем “своей серверой”

Преимущества:
– Быстрота развертывания. При наличии денег на карточке можно получить полностью готовый сервер или сервис за десятки минут. Причем в стране на выбор.
– Более высокая доступность. У провайдеров просто больше возможностей это обеспечить.
(ТОЛЬКО для частных облаков) – Более низкая стоимость обслуживания

Недостатки:
– Более высокая стоимость обслуживания. На данный момент – в 1,5-2 раза дороже. За тренд надо платить.
(для всех КРОМЕ частных облаков) – Полная потеря контроля за вашими данными. Что бы там не писали маркетологи в пресс-релизах и зазывалках, данные из облака очень легко (по сравнению с классической схемой) могут быть взяты без возможности какого-либо контроля с вашей стороны. Люди, которые имеют доступ к физическим серверам, всего лишь люди.

Тут обычно возникает мысль про то, что я (в смысле автор) ничего не понимаю. Ведь если “облака” стоят дороже, то почему ими пользуются? Люди же не настолько глупые …

Но где можно “выиграть в облаках”, я напишу в другой раз. Вдруг никому не надо и я только зря клавиатуру терзал? 🙂

Как правильно угробить компанию …

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

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

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

Всякие умные слова можно прочитать … ну скажем, на e-xecutive.

Согласитесь же, круто все? Наша компания самая прогрессивная и вообще практически мгновенно адаптируется к изменяющимся условиям!

Однако … в общем, опять перейду на личности. В общем, в свое время я совершил две ошибки: во-первых, позволил этому зародиться в компании. Не подумал, пропустил, не смог доказать. Уже не важно. А во-вторых, вместо активного разъяснения я выбрал линию активного противодействия. Думаю, многие вспомнят совещания, где я прямым текстом говорил, что я дал команду подчиненным всех приходящих к ним с вопросами/задачами/еще чем посылать “на х.й”. Вообще всех. И все претензии отправлять мне. И мне было абсолютно пофиг на то, что айтишников ругали. Хорошо еще, что еще было кого ругать …

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

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

Не верите? Смотрите, что произойдет в гипотетической (да, она идеальная) организации при приеме на работу нового сотрудника. Кадровик вбивает в какую-нибудь систему “принят на работу Иванов Иван Иванович”. Система отправляет данные в кадровую систему (заплата, паспорт и так далее), кадровая система переварив данные и проверив все, плюет запрос в систему поддержки (компьютер со столом надо? к сети подключить надо?), система поддержки раскидывает запросы к АХОшникам (за столами и стульями) и к айтишникам (логин, пароль, распределение по группам и прочие). Данные от айтишников убегают назад в кадровую систему (где сидит), на портал (где типа все тусуются, можно посмотреть телефоны и прочее) и дальше расходятся по другим бизнес системам (где-то надо завести каталог, где-то скрипт выполнить, где-то еще что-то надо делать). И все это попутно проверяется на ошибки, синхронизируется между собой и так далее. А потом приходит Иван Иванович и отправляет запрос “не хочу быть Ivan, хочу быть Vanya” и начинается легкий армагеддец внутри систем, которые начинают внутри менять данные, да так что бы не порвать уже налаженные связи.

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

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

Сначала он укладывает в голове то, что существует сейчас. Примите как данность, что одинаковых систем не бывает и у всех есть нюансы, иногда (хорошо, почти всегда) не описанные.
Потом он мысленно пробегает по взаимосвязям в духе “ага, это идет туда, а потом собирается вот тут и тут”. Говоря другими словами имитирует деятельность системы прямо в голове.
Следующим шагом он добавляет в полученную схему новое. Мысленно. “тут надо перехватить, сюда идут, отсюда выходят …”
И наконец, проиграв еще раз схему, он ее реализует в реальности.

Так или примерно так работает башка у любого айтишника. Разница обычно в глубине “охвата” и “проработки” деталей. Кто-то способен в башке удержать инфраструктуру целиком, а у кого-то мозгов хватает только на одну функцию.

И вот состояние, в котором пребывает айтишник во время подобного, кто-то называет “потоком”, кто-то “размышлизмами”, кто-то еще как. У авиадиспетчеров вроде это называется “поймать картинку”.

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

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

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

И вот садится этот инженер, берет задачу “включить хрень в Х”. Читает документацию, вникает, заходит на систему, начинает править … И тут прибегает продажник с “тут клиент звонит, Х умеет такую фигню через пипку?”. Бабах! “Потока” почти нет. Выяснили, чем пипка от фиговинки отличается, умеет ли Х это и так далее, “поток” ушел совсем. Начинаем снова. Через некоторое время прибегает менеджер с другого проекта с вопросом “ну как там внедрение Х?”. Бабах! Начинаем снова. И это в зависимости от “проектной” загрузки повторяется с завидной частотой.

Результат: “включить хрень в Х” проседает по срокам и качеству напрочь. Инженер, как любой нормальный человек, начинает нервничать и пытаться хоть как-то вытянуть задачу, а раздражители продолжают сыпаться … Все последующее можете додумать сами.

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

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

Я начальник, а значит подчиненные должны быть зае…ными!

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

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

И вот начальник придумал гениальную мысль: а пусть все подчиненные присылают отчеты! А я буду их смотреть и сравнивать, что изменилось между прошлым отчетом и этим. Ну и буду ругать согласно не сделанному. Потом, ведь эти отчеты можно будет использовать и для докладов вышестоящему начальству! Кругом же польза для меня любимого. Легко задавив робкие “так вон же, все данные лежат …”, быстро смастерил табличку и грозным рыком разослал по подчиненным.

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

Но потом внезапно понял начальник, что он начал тонуть в отчетах. А потом пару раз произошли факапы. И наказать не получилось: сотрудники предъявили старые отчеты, в которых они прямо предупреждали о этом. А ведь перед вышестоящим начальником отвечать ему, а не его сотрудникам.

Думал-думал начальник и решил заставить сотрудников писать сводный отчет. Дескать, все мы в одной компании работаем, вот и собирайте все в кучу. И снова будем совещаться и обсуждать. И началось раздолье: кто не успел, тот виноват, ату его! А сотрудники стали тратить половину дня в выяснении, у кого последняя версия файла, почему кто-то записал то, когда в реальности вон то … нет, они потом сообразили использовать Google Docs, но все равно: потери времени были чудовищными.

А ведь будь начальник потолковее, возглавил бы процесс объединения систем, благо знания про такие системы были у его подчиненных, настроить отчетность как надо и реально получил бы инструмент контроля …

Как правильно угробить компанию или …

… что я узнал на своем опыте и что невозможно прочитать в книжках. Часть первая.

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

Как обычно, отмазка: все совпадения с реально существующими людьми и компаниями случайны. На самом деле: многие из знающих меня смогут соотнести описания с реальностью и попытаться персонализировать персонажей. Кто-то это сделает правильно, а кто-то нет. Систематизируя свои заметки, я обнаружил что некоторые события повторялись в разных компаниях практически один-в-один. Только при одних событиях я был юн и мне было пофиг на творящееся вокруг, а в развитии других событий я принимал самое активное участие. И не всегда положительное …

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

… гоните своих рекрутеров нафиг!

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

Как обычно решают такие задачи?

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

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

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

И наконец, апофеоз: заплатить за поиск человека специализированному агентству. Размер пафосности – по усмотрению.

Почему это плохо? Ведь многие так работают и ничего …

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

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

И наконец, в случае агентств срабатывает еще один фактор: они попросту не показывают “спорных” кандидатов заказчику. Ибо “иначе они решат, что мы им подсовываем плохих”.

А как же собеседования? Собеседования штука хорошая, но посмотрим, как это обычно происходит.

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

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

Следующие иногда совмещают, а иногда нет. Тут идет разговор с руководителем, куда идет прием. Именно тут иногда дают тестовые задания, расспрашивают подробно про знания и так далее и тому подобное.

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

Что получаем в результате? Получаем в результате практически случайную выборку и слова про то, что найти невозможно …

Что делать? Все просто: не стоит применять методику, рассчитанную на массовость для найма одиночных людей. Как это делал я, когда делал.

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

Во-вторых, чуть-чуть (реально совсем чуть-чуть) формализуйте параметры. Типа ищем инженера, умеющего работать с системами резервного копирования. Обязательно укажите нижний и верхний уровень зарплаты. Никаких “по договоренности”. Ибо “по договоренности” всегда означает “ниже рынка”.

И самое важное: напишите небольшую задачку по теме. Раз мы ищем инженера по системам бэкапа, то задачка может быть в духе “у нас есть 100 серверов, на 80 из них 100 гигов мало меняющихся данных, а на остальных по 20 гигов быстро меняющихся данных. Примерно половина из этого объема – одно и тоже. Необходимо все это зарезервировать и обеспечить полное восстановление любого набора за час, а хранить данные год. Бюджет любой. Опишите архитектуру, ПО и прочее необходимое. Срок написания – три дня.”. Главное, что бы на описание решения надо было потратить максимум час (а лучше меньше).

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

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

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

Чуть не забыл еще один вопрос: “а что, если он решение подсмотрел в интернете и выдал за свое?”. Чушь. Если возникнет такое предположение (ибо обычно в интернете обсасывают какую-либо одну сторону решения), то пара-тройка вопросов “по теме” легко показывает, кто есть кто.

И наконец, понравившихся людей можно приглашать на собеседование. Лично для меня уже пофиг на всякие профессиональные качества (они проверены раньше), лично я смотрю на человека только как на личность. Как он выглядит, как двигается … Грубо говоря нравится он мне или нет. Иногда на собеседование приглашал его будущих коллег. Тут очень важны именно личностные качества. Ведь именно мне и коллегам придется вместе работать. И даже если он крутой профи, но вот если все внутри говорило что “не сработаемся”, то я отказывал. Один раз я преступил через это правило и все окончилось судом.

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

Почему же я (да, переходим на личности) перестал так делать? Чего там оправдываться, банальная лень (ведь еще столько надо сделать, сроки горят) и “мне за это не платят”. То, что происходили срывы сроков и прочие факапы из-за “некому работать” как-то относил к чему угодно, не к себе.

… сотрудника у заказчика контролируй, но замещать не смей!

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

Согласно хорошей традиции обе компании выделили из своих рядов по сотруднику, которые и стали вести все дела. Или говоря по-другому, стали “точками входа”.

Долго ли, коротко, но у одной из сторон случился факап. Совершенно не важно, что именно: не сделали, сорвали сроки или внезапно поменялись условия. Главное, что возникла напряженность и слухи о этой напряженности начали проникать “наверх”.

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

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

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

Но это мелочь. Хуже всего то, что оба (ОБА!) начальника, не слушая рассказов, сделали “втык” своим сотрудникам за то, что они “мышей не ловят”. Стоит ли говорить, что в результате обе стороны максимально забили на проект (а нафиг пахать, если все равно вые..ут)? Итог: хороший проект похоронен, обе стороны понесли потери, сотрудники демотивированы.

А ведь стоило уделить буквально 15 минут и поинтересоваться у сотрудников текущим положением дел перед “урегулированием”, как все было бы не так …

Думаю, для первой части хватит, а то я расписался что-то 🙂

Клиент ВсеМое.ру – логин

Скорей, надо скорей писать код! Как театр начинается с вешалки, так и любой клиент ВсёМоё начинается с окошка логина. Надо его нарисовать!

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

Screen Shot 2014-03-30 at 14.57.55

В оригинале всё, кроме полей ввода и чекбокса, нарисовано прямо на бэкграунде. С одной стороны, это хорошо и уменьшает объем кода. А с другой стороны, ограничивает нарисованным. А ведь охота нарисовать сразу для всех платформ. Ну или практически для всех …

Разбиваем окошко на следующие элементы: бэкграунд, “банка”, логотип, и два поля ввода. Для десктопа еще должна добавиться кнопка “Войти”, ибо на мобильных её функцию выполняет кнопка на виртуальной клавиатуре. Кнопку “регистрация” … а нехай будет

В общем, как-то так получается в реальности.

Screen Shot 2014-03-30 at 15.52.12

Берем Qt Creator и создаем в нем проект, который использует QtQuick.Controls. Мне он поугрожал, что использовать полученное можно будет только с версией iOS больше 5.1 … но найдите мне такую версию живьем?

Создаем в нем фаил ресурсов и загоняем туда картинки, тупо выдранные из оригинала (красоту будем наводить потом).

Для начала нам надо добиться, что бы один и тот же код выполнялся и под десктопом и под айфончиком.

Для этого надо:

а) загнать qml в ресурсы
б) нафиг сменить процедуру загрузки, иначе будут ошибки про not ready и прочее. Короче QTBUG-29873

main.cpp сейчас у меня выглядит так

Screen Shot 2014-03-30 at 17.24.36

Красивая картинка? Полностью полученное можно посмотреть где положено (то есть в git и нефиг ныть!), а у меня получилось следующее:

Screen Shot 2014-03-30 at 17.21.06

Поверьте, на андроиде примерно тоже самое. Теперь необходимо осуществить … гламуризацию всего этого дела. Например, где кнопочка “регистрация” (и нужна ли она)? И все криво при повороте набок. И пароль набирается видимыми буквами. И нету чекбокса. И вообще, все криво.

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

Для начала убираем всякие Column { и тупо прописываем все подряд. Затем добавляем State почти по инструкции http://doc.qt.digia.com/qtquick-components-symbian-1.1/qt-components-scalability-guidelines-orientation-specific-layouts.html

Так как там немного древнее, я заиспользовал одну StateGroup, без отдельной с when:true


StateGroup {
states: [
State {
when: (main.width / main.height) < 1.00

PropertyChanges {
target: loginEmail; text: "portrait"
}

AnchorChanges { target: logoImage; anchors.top: parent.top }
AnchorChanges { target: loginEmail; anchors.top: logoImage.bottom }
// AnchorChanges { target: userPassword; anchors.top: loginEmail.bottom }
},
State {
when: (main.width / main.height) > 1.00

PropertyChanges {
target: loginEmail; text: "landscape"
}
AnchorChanges { target: loginEmail; anchors.top: logoImage.bottom }
// AnchorChanges { target: userPassword; anchors.left: loginEmail.right }
}
]
}

Для проверки я тупо убрал лишнее и в поле для логина начал выводить, какой же State используется. И потом, с помощью PropertyChanges и AnchorChanges я меняю свойства и привязки элементов. В итоге получается “адаптивный” дизайн.

Вот теперь можно и добавить кнопки про регистрацию и вперде!

Правда, вперде прямо сразу не получится. По двум причинам.

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

Во-вторых, это долбанное разнообразие разрешений и форматов экрана. У кого-то 4:3, а у кого-то 16:9. Кому-то хватает 640х480 или даже 320 на 240, а кому-то и 1920 на 1080 не хватает.

Что делать?

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

Для определения платформы (мобильная или десктопная) проще всего использовать предопределенные константы прямо из Qt. напрямую из QML не получится, слишком кроссплатформенный он получился …

Итак, что имеем?

1. ориентацию экрана легко узнать из самого QML. Просто по соотношению высоты и ширины экрана.
2. Ориентацию элементов управления (для мобильного прижимаем кверху, а для десктопа – центрируем) передаем в QML снаружи. Делать свой QML для каждой платформы – моветон.
3. Для удобства позиционирования волевым решением принимаю, что экран в горизонтальной ориентации в реальности имеет размеры 40х30. Кто-то это называет device independed pixels, кто units, кто еще как. И все координаты будут преобразовываться в реальные пикселы отдельной функцией. Сначала засуну ее в QML, а там посмотрим.

Ну, пункт 1 сделан еще на подготовительном этапе.

Теперь надо передать платформу в QML. Обычно народ сразу хватается за классы, но нам-то по идее хватит что-нибудь типа 0 – по центру, 1 – прижимать все вверх.

Для этого тупо устанавливаем переменную для QML

engine.rootContext()->setContextProperty(“platform”,31);

Теперь везде можно использовать platform. Ну и для порядку неплохо бы обернуть все это в обертку из #define

int platform=0;

#ifdef Q_OS_ANDROID
platform=1;
#endif

#ifdef Q_OS_IOS
platform=1;
#endif

#ifdef Q_OS_WINPHONE
platform=1;
#endif

Потом как-нибудь можно будет сделать более тонкое разделение по платформам.

Что касается пикселов, то это решается еще проще.

Где-нибудь в начале QML, сразу после ApplicationWindow вставляю следующее:

property int guxSize: width/40
property int guySize: height/30

function gux(c)
{
return guxSize*c;
}
function guy(c)
{
return guySize*c;
}

Потом везде, где надо привязаться к координатам, использую gux для х/ширины и guy для y/высоты. Опять же, потом мне ничего не мешает переопределить подсчет этих значений для более тонкого соответствия какому-нибудь хитровыделанному дисплею.

Ну а теперь пора переходить к определению элементов и их размеров. При этом крайне рекомендую внутри элемента описаться на его ширину/высоту, а не на guy/gux. Просто потом будет гораздо легче. И никаких pointSize! Только pixelSize.

Как это выглядит в коде, вы можете увидеть в Stage1. В реальности это выглядит так:

Для “десктопа”

landscape

Для “портретного” режима

portrait

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

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