ReactOS 0.4.2 будет превосходным

[Перевод] Так вы думаете, что знаете Const?

[Перевод] Атоматизация администрирования систем, обзор проблем и вариант решения. Из книги «PowerShell and WMI»

Ниже перевод части главы 1 книги Powershell and WMI. Освещается направление развития информационных систем применительно к системному администрированию. Дается взгляд Ed Wilson на проблемы эксплуатационщиков, указывается направление снижения расходов на обслуживание инфраструктуры.

Solving administrative challenges
Спросите любого администратора Windows о его самых больших проблемах, и где-то в верхней части списка будет слишком много работы и нехватка времени чтобы сделать это. Они знают о средствах автоматизации, возможно даже осведомлены о возможностях WMI и Powershell, но не имеют времени чтобы освоить эти технологии. Это позорная ситуация, потому что принято считать, что 70% бюджета ИТ организации расходуется на то «чтобы все было в рабочем состоянии» (прим переводчика: в оригинале “keep the lights on.”). Автоматизация может значительно сократить эти 70%, за счет чего освободятся время и деньги для задач ниже по списку «проблем».

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

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

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

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

• Количество систем
• Повышение сложности инфраструктуры
• Скорость изменения

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

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

1.1 Административные задачи

Администраторы — очень занятые люди. Они, кажется, постоянно должны сделать больше с меньшим количеством ресурсов. Рисунок 1.1 иллюстрирует это. С одной стороны, мы видим график снижение стоимости, аппаратного обеспечения. Например, я недавно приобрел ноутбук с 4х ядерным процессором (HyperThreading позволяет увидеть восемь ядер) и с 16 Гб оперативной памяти, я буду использовать его как мобильную лабораторию. Несколько лет назад, машина с этими параметрами была в среднем сегменте серверов, а не ноутбуков!

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

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

PowerShell и WMI может помочь вам переломить эту кривую роста. Для начала нам необходимо разобраться в этой проблеме глубже – откуда появляется сложность и рост расходов на администрирование?

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

• Снижение стоимости аппаратной мощности – это приводит к тому что при высокой загрузке проще добавить новый сервер чем искать как использовать имеющиеся. Закупы отделов или закупки под проекты – этот подход вызывает вопросы принадлежности сервера, департаменты или «проектники» не хотят чтобы на их серверах кто-то «сидел». Они не желают предоставлять другим свои ресурсы.
• В правило «одно приложение – один сервер» — разделение приложений так чтобы проблема в одном не влияла на другие, это правило все еще может быть действительным для критически важных бизнес-приложений, но это не обязательно требуется для второго или третьего ряда приложений. И безусловно, это не требуется для тестирования и обучения.
• Медленная реакция или ригидность ИТ отделов – отсутствие контроля и процессов в области ИТ приводит к беспорядку в проектах и изменениях систем.

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

• Сокращение числа физических серверов
• Снижение требований ЦОД объектов, в том числе пространства, мощности и затрат на кондиционирование
• Более точное использование мощности физических активов, что дает большую отдачу от инвестиций

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

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

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

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

1.1.3 Сложность и понимание
Сложность является реальной проблемой во многих случаях. Она может возникнуть из-за ряда причин:

• Несколько операционных систем приносят различные наборы инструментов и терминологию, разница есть даже между двумя версиями Windows.
• Различные типы приложений, таких как базы данных, электронная почта, службы каталогов Active Directory, и веб-приложения, требуют различных навыков, требуют использовать различные инструменты, имеют разные требования и создают различную нагрузку на сервера.
• Многие машины выполняют одинаковые или схожие роли, но незаметные особенности реализация, недокументированные возможности увеличивают вероятность ошибки.

Сложность нарастает из-за неполных знаний и навыков самих администраторов. Слишком часто проект вводит новую технологию и от администраторов ожидается что он сразу же подхватит и начнет управлять системами. У администраторов есть навыки? Есть ли у них время, чтобы узнать тонкости нового технологии? К сожалению, ответ на оба вопроса часто отрицательный.
Администратор в такой ситуации примет лучшее решение как разрешить проблему – он начнет делать так как умеет. Иногда, если новая технология является изменением версии от чего-то уже, администратор продолжит использовать старые методы, даже если есть появился лучший способ выполнить задание.

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

1.2 Автоматизация – путь для прорыва вперед.
Решением для преодоления этих проблем является автоматизация (прим переводчика: я бы назвал это программные роботы. С английского можно перевести и так и так. Суть в том что мы имеем много разных инструментальных интерфейсов и систему регистрации событий в системе, с помощью одного но мощного движка управления мы можем связать их воедино и наделать программных роботов выполняющих в системе работу. Они будут поднимать коннекты, следить за загрузкой, делать базовый ремонт и обслуживание и т.п., таким образом автоматика в том виде как она рассматривается здесь, становится частью инфраструктуры наряду с железом и софтом. И она может также эволюционировать. Это больше не набор отдельных сценариев действий, не запрограммированая последовательность выполняемая по расписанию, это автоматическая реакция на события конкретно этой инфраструктуры). Поручить машине делать простую, повторяющуюся работу это то радичего мы изобрели их!
Автоматизация понимается по разному разными людьми. В иерархии автоматизации выстроены разные понимания этого вопроса рисунок 1.2

Для использования этой иерархии нужно ответить на вопрос – «от внедрения более сложной системы будет ли получена большая польза?». Я знаю целый ряд организаций, которые вполне счастливы используя стандартный инструментарий Windows и несколько инструментов массовой рассылки команд (прим. переводчика: можно перевести как «инструменты массового редактирования». Ориг: «a few bulk-editing tools»). Другие пытаются максимально использовать планировщик зада или даже создают автоматизированные ответы на события. Автоматизация для большинства организаций представляет из себя смесь инструментов командной строки, сценариев, и плановых задач.

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

PowerShell сам по себе прекрасный инструментом (Да, я фанат PowerShell) (прим. Переводчика Ed Wilson входит в состав команды Scripting Guys, автор книг о PowerShell, автор множества статей по PowerShell). При необходимости вы можете перейти на следующий уровень сложности, и WMI будет на самом верху. (прим переводчика. По словам Richard Siddaway (глава английского сообщества powershell) приведенным в книге «powershell in practice», если вы не используете WMI совместно с powershell то теряете около 60% мощности. Как это посчитано не знаю). Это открывает Вам доступ к стандартному набору инструментария управления системой, которую вы можете использовать на локальной и удаленной машине, потенциально включающую не Windows системы (прим. Переводчика Имеется в ввиду использование CIM). Сценарии могут быть запущены интерактивно или могут быть запланированы на время. Но прежде чем мы углубимся в эти пучины нам нужно осмотреть автоматизацию в целом.

В этой книге, мы будем концентрироваться на сценариях как основном средстве автоматизации. Можно утверждать, что вы могли бы сделать много работы из командной строки подключаясь к удаленным машинам. Однако, преимущество сценариев в том что вы можете использовать код повторно, каждый раз экономя время на написание и отладку кода. Эта тема подробно рассматривается в главе 4 книги «PowerShell in practice» издательства Manning 2010 (прим. переводчика. Хорошая книга). Запланированные задачи и «автоматические реакции на события» слишком сильно зависят от вашей конкретной инфраструктуры, в главе 3 мы начнем рассматривать как вы можете сделать автоматические ответы на события происходящие в вашей системе. Мы рассмотрим еще раз последующих главах рассматривающих конкретную область управления. В книге мы не будем использовать командную строку, хотя многие сценарии достаточно коротки для использования в командной строке в интерактивном режиме.

Давайте рассмотрим пример. Предположим вам нужно определить количество свободного пространства на диске С нескольких машин в вашей среде. Один из способов прийти в ЦОД к каждой машине. Подключится к каждой по очереди и посмотреть в проводнике свободное пространство диска С. Записать ответ и повторить для следующей машины в списке.
Немного проще вариант – использовать RDP для подключения к каждой машине и вручную сгружать информацию. Таким образом вы не будете выходить из за своего стола. Но вы по прежнему должны сделать очень много маленьких действий, вы по прежнему теряете слишком много времени.
И решение которое мне нравится – использовать для этой цели PowerShell, код приведен в листинге 1.1. Не волнуйтесь если вы прямо сейчас не понимаете его. Мы вернемся к этому сценарию в главе 6 когда будем рассматривать как управлять дисковой подсистемой.

Стандарт написания сценариев
Это обсуждалось в ведении к книге, но если вы похожи на меня вы пропустили эту часть книги.
Техники применяемы для работы с серверами могут быть применены для работы с клиентскими машинами.
PowerShell команды (командлеты и функции) могут иметь сокращения, известные как алиасы. Я обычно не использую алиасы в сценариях, т.к. я хочу чтобы мои скрипты было легко читать, понимать спустя время. Я также буду использовать полное название параметров командлетов.
Существует одно исключение из этого правила для некоторых командлетов:
• Вместо Where-Object используется алиас where, но никогда не используется сокращение ?
• Вместо ForEach-Object используется алиас foreach, но никогда сокращение %
• Вместо Select-Object используется алиас select
• Вместо Sort-Object используется алиас sort
В ходе дискуссии я всегда использую полное имя командлета.

Я принял эту конвенцию по целому ряду причин:
• По совету команды PowerShell.
• Потому что она представляет собой общепринятую практику и использование.
• Потому что это читаемо.
• Это экономит немного места на странице.

Пример начинается со списка имен компьютер моей лаборатории. Этот список передается по конвееру в командлет ForEach-Object (foreach) который вызывает Get-WmiObject для каждого сервера из списка с запросом данных о логическом диске С. Затем полученная информация форматируется и выводится в виде таблицы

Листинг 1.1 Определить свободное место на диске

"dc02", "W08R2CS01", "W08R2CS02", "W08R2SQL08", "W08R2SQL08A", "WSS08" | foreach {
Get-WmiObject -Class Win32_LogicalDisk -ComputerName $_ -Filter "DeviceId='C:'" } |
Format-Table SystemName, @{Name="Free"; Expression={[math]::round($($_.FreeSpace/1GB), 2)}} -auto 

Свободное пространство пересчитывается из байтов в гигабайты, чтобы сделать результаты более понятными. Обратите внимание что PowerShell понимает сокращение GB, а также KB, MB, TB и PB.

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

SystemName Free
---------- ----
W08R2CS01 119.04
W08R2CS02 118.65
W08R2SQL08 114.8
W08R2SQL08A 115.17
WSS08 111.41
DC02 118.53

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

Есть ряд модификаций можно внести в этот сценарий:

• Поместите имена компьютеров в CSV файл (как мы будем делать в листинге 1.4)
• Добавьте результаты работы в таблицу Excel, или базы данных, так чтобы можно было видеть тенденцию изменения места на серверах
• Запланировать выполнение задачи во времени

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

Мне понадобилось всего несколько минут чтобы написать его и есть окупаемость когда я запускаю его снова и снова.
PowerShell спроектирован именно для такого типа использования. Словами Jeffrey Snover, архитектора PowerShell «Я твердо верю, что экономика определяет, что люди делают и что они не делают. PowerShell разработан с нуля, чтобы быть расширяемой, высоко уровневой, задаче ориентированной абстракцией, удешевляющей расходы на задачи администрирования и поддержки.» (прим переводчика. Оригинал: «I firmly believe that economics determine what people do and don’t do so PowerShell is designed from the ground up to make composable, high-level task oriented abstractions be the cheapest things to produce and support») Полный текст его статьи, «Семантический разрыв» («The Semantic Gap») доступен на странице Windows Powershell blog по адресу http://ift.tt/1vzuvOQ сделайте поиск по слову «semantic gap» и вы натолкнетесь на эту статью.

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

прим переводчика здесь мной пропущено несколько разделов

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

PowerShell может помочь разорвать эту кривую, обеспечивая следующее:

• Набор инструментов для интерактивного администрирования серверов и приложений
• двигатель автоматизации, которая работает во всех состояниях Windows (примечание переводчика: в оригинале применено слово estate точный перевод – поместья, владения. Подразумевается, что это core технология Microsoft и все системы так или иначе имеют командлеты (даже Symantec BackupExec и Veeam выпускают свои командлеты))
• способность применять универсальный подход и методы к большому числу систем и приложений (прим переводчика: вам не нужно изучать список команд консольной утилиты, все командлеты однообразны)
• движок удаленного позволяющий управлять множеством машин одной командой
• асинхронные и запланированные задачи для дальнейшего повышения автоматизации

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

P/S/ Итог: если ваша инфраструктура стоит перед лицом все большего усложнения, то стоит задуматься о переходе на новый уровень автоматизации. Я много слышу от друзей о усложнении инфраструктуры, постоянное давление от маркетинговых отделов, постоянное изменение систем. Лично я такое давление ощущаю, сейчас ищу способ создать автоматических ботов для админских задач.

Let's block ads! (Why?)

Google I/O глазами непрограммиста

Автор: Елена Федорова

Меня зовут Елена Федорова, по профессии я врач, но так сложилось, что более десяти лет работаю в IT (чему очень рада). Руковожу департаментом Human Resources Marketing компании DataArt в Воронеже. Кроме того, больше восьми лет координирую техническое сообщество Google Developer Group Voronezh и организую IT-события. Поэтому я и попала на Google I/O 2016 в Маунтин-Вью.

Анроиды-хипстеры встречают гостей.
Это был мой второй Google I/O. Восторженный отчет о первой для меня конференции можно просмотреть тут.
Попасть на I/O может в принципе любой желающий с 900 долларами в кармане — цена билета. Впрочем, можно попасть на конференцию и бесплатно — лайфхак читайте под статьей.

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

Технические подробности и полную запись keynote лучше посмотреть на сайте I/O. Буду рассказывать, что впечатлило меня как простого техногика.
Те, кто летал через Атлантический океан, знают, что утро начинается рано. Вот и мы пошли добывать свои бейджи с самого открытия регистрации. К большому удивлению, очередей не обнаружили.

Очереди появились позже и были везде. Куда же без них, когда на конференцию приехало больше 7000 человек. Сначала была большая очередь на кейноут, но это нормально. Все хотят первыми услышать самые важные новости, особенно сумашедшие Android-разработчики. Нам как участникам Google комьюнити предоставили право первой ночи (зачеркнуто) разместиться в зоне недалеко от сцены под навесом. Далее были очереди на секции: участники занимали очереди на доклады за пару часов до начала презентаций.

Представители GDG Russia в сборе.
После Keynote я пошла гулять по секциям. Территория просто огромная, всюду большущие шатры, в которых проходят доклады, площадки для пощупать-потрогать разные устройства, сцены-тусовки для общения, зоны для программирования, навесы для отдыха и общения, павильоны и разные лавочки, качели, гамаки и лежанки. Вокруг много кораблей (?) и разнообразных Android-фигур.

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

Самоходная повозка (зачеркнуто) Google-автомобиль выглядит, мягко говоря, странно простовато, особенно внутри. Но я вживую наблюдала эту коробченку курсирующей в потоке автомобилей на пути к I/O. В ней сидели два человека, а водитель отсутствовал. Ребята, а будущее-то уже здесь!

Каких только интересных личностей не встретишь на такой гиковской конференции! Вот, например, стимпанк-дедушка с кучей VR-очков.

Мечта всех IT-рекрутеров — мастеркласс по программирования на Android — собирает стадионы! На большом экране чувак пишет код, а народ наблюдает, делает заметки и наслаждается процессом.

Зона для программирования CodeLab — специальная секция для тех, кто хочет на реальных девайсах с помощью настоящих Google-экспертов научиться программировать или попробовать новую технологию.

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

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

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

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

В павильоне Google Play Music царили темнота, музыка и мистика.

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

Ну и, конечно, бедный безымянный Android N! Ну кто-нибудь, придумайте уже ему имя! Пара кулинарных вариантов от меня: Napoleon ( ну он же торт), Noktyurn (есть такое пирожное).

А гантели можно отнести к wearables?

Стена идей. Разместите свою идею, а Google задумаются и рассмотрит.

Проект по Google-картам был оформлен как очаровательный автобус, в который можно было попасть внутрь и потестировать электронные экспонаты.

Проект Android Auto вызывает бурные обсуждения.

Здорово, что у нас есть друзья и активные участники Google-групп, которые проводили трансляцию конференции из Маунтин-вью. Как это было, читайте тут. Спасибо вам!
И, конечно, было круто встретить друзей и коллег-организаторов GDG из других городов и стран. Отдельная благодарность Наталье Ефимцевой и Кате Писанке за поддержку российских GDG-сообществ.

Как попасть на I/O бесплатно

Итак, друзья, я готова поделиться секретом.
Несколько лет назад на мировой карте Google Developer Group в районе России были лишь единичные пятнышки групп: Москва, Воронеж, Омск, Питер. Сейчас я очень рада, что количество групп единомышленников растет. В этом году в России уже 16 Google-комьюнити.
Так вот, чтобы поехать на эту чумовую конференцию, вам нужно найти Google-сообщество в вашем городе и стать его активным участником. Если такого комьюнити рядом с вами нет — организуйте его! Не знаете как? Спросите у нас! До встречи на Google I/O 2017 И не ешьте много сладкого :)!

Let's block ads! (Why?)

Отпуск по-программистски, или как я не поучаствовал в конкурсе по программированию на JS. Часть первая

Новый кандидат в релизы САПР Qucs-0.0.19S-RC6

Qucs — это кроссплатформенный (Linux, Windows, MacOS-X) симулятор электронных схем с открытым кодом. О нём рассказывают мои предыдущие статьи на Хабре:

• Qucs — open-source САПР для моделирования электронных схем http://ift.tt/1gWK66c
• Новости проекта Qucs: подготовка к релизу 0.0.19 http://ift.tt/1gWK66e
• Новости проекта Qucs: доступен кандидат в релизы с поддержкой моделирования схем в SPICE http://ift.tt/1qOwgXS

В настоящее время готовятся к релизу параллельно две версии Qucs:

• Qucs — сборки с обычным набором функций. Используется только движок моделирования Qucsator
• QucsS — сборка с возможностью использования SPICE (поддерживаеются движки Ngspice, XYCE, SpiceOpus) как движка моделирования по умолчанию. Данные сборки содержат букву «S» после номера версии. Для инженеров наибольший интерес представляет Ngspice

Пока очередной релиз Qucs вновь отложен на неопределённый срок, вышел кандидат в релизы Qucs-0.0.19S-RC6 с поддержкой SPICE. Этот релиз-кандидат значительно отличается от всех предыдущих. Скачать пакеты для двух платформ (Windows и Linux) можно здесь: http://ift.tt/1qOvAC7

Под катом будет рассказано о нововведения в данном релиз-кандидате.

Установка

Linux

Процедура установки для Linux не изменилась. Нужно собирать пакет из исходников. Требуются компиляторы и Qt4 для разработчиков. Нужно собрать отдельно Qucs и движок моделирования Qucsator:

tar xvfz qucs-0.0.19S-rc6.tar.gz
cd qucs-0.0.19S-rc6
cd qucs
./configure
make
make install
cd ../qucs-core 
./configure
make
make install

При этом всё поставится в /usr/local, и если туда уже установлена предыдущая версия Qucs, то она перезапишется. Чтобы установить QucsS в другой каталог, нужно изменить команду configure:

./configure --prefix=/some_qucs_location/

Если требуется только SPICE, то можно собрать только интерфейс Qucs:

tar xvfz qucs-0.0.19S-rc6.tar.gz
cd qucs-0.0.19S-rc6/qucs
./configure --prefix=/some-qucs-location/
make
make install

Ngspice следует установить при помощи пакетного менеджера. Он есть во всех современных дистрибутивах.

При первом запуске QucsS попросит указать симулятор по умолчанию.

Windows

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

Обзор новых функций Qucs-0.0.19S-RC6

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

Установка симулятора по умолчанию

Изменилась процедура запуска моделирования при помощи SPICE-симулятора. Теперь можно назначить симулятор по умолчанию, который будет запускаться каждый раз, когда пользователь вызывает моделирование (например нажав F2). Использовать специальный пункт меню Simulate with SPICE теперь не нужно. Если выбран один из SPICE-движков, то для работы программы теперь не требуется движок Qucsator и полная установка.

Симулятор по умолчанию можно назначить либо при первом запуске программы, либо потом выбрав в главном меню Simulation->Select default simulator. Если выбран один из SPICE-движков, то несовместимые с ним компоненты и библиотеки не показываются. Диалог установки симулятора по умолчанию выглядит так:

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

Расчёт рабочей точки при помощи Ngspice

Реализован расчёт рабочей точки по постоянному току (по нажатию F8) для SPICE-движков. Теперь если симулятором по умолчанию назначен Ngspice, то он и будет рассчитывать рабочую точку. Результаты расчёта выглядят так:

Новый набор аналоговых блоков XPSPICE

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

SPICE-директивы .MODEL и .INCLUDE

В дополнении к имеющему набору SPICE-совместимых полупроводниковых компонентов добавлена возможность размещения на схеме директив .MODEL и .INCLUDE, что позволяет использовать в схеме немодифицированные библиотеки полупроводниковых компонентов. Директива .MODEL позволяет сослаться не библиотеку, а директива .MODEL — построчно скопировать SPICE-модель и внедрить её в схему. Схема смесителя на полевых транзисторах иллюстрирует использование этой директивы.

Модели трансформаторов и сердечников

Добавлены компоненты, позволяющие моделировать трансформаторы и катушки с ферромагнитным сердечником. Имеется библиотека Transformers, содержащая трансформаторы и библиотека Cores с моделями сердечников (в основном стальные сердечники). Данный функционал доступен только через Ngspice. На рисунке показана схема лампового УНЧ (на лампе 6П6С), которая иллюстрирует использование новых библиотечных моделей трансформаторов и SPICE-моделей.

Создавать свои трансформаторы можно применяя комбинацию компонентов Icouple (обмотка) и Core (сердечник). Идеальные трансформаторы можно создать, используя компонент «K coupling»

Создание нестандартных SPICE компонентов

Добавлены два компонента «SPICE generic device» и «XSPICE generic device». Они позволяют создавать новый нестандартный компонент, зная только число выводов и букву, которая ему назначена в SPICE. Это полезно если компонент уже добавлен в движок, а графический интерфейс запаздывает. Особенно это касается симулятора XYCE, где новые компоненты добавляются в каждом релизе. На прилагаемой схеме как нестандартный компонент объявлен обычный полевой транзистор. Модель полевого транзистора подключается при помощи директивы .MODEL.

Поддержка моделей XSPICE CodeModel

Добавлена поддержка языка описания моделей аналоговых компонентов XSPICE CodeModel (известен с 1991 года). Он позволяет создавать новые модели и подключать их к движку моделирования Ngspice без перекомпиляции. Подробнее о синтаксисе CodeModel моделей можно прочитать в мануале Ngspice и XSPICE. Подключить модель CodeModel можно используя комбинацию компонентов «XSPICE generic device» (УГО компонента) и «XSPICE CodeModel» (исходный текст модели). На схеме можно видеть пример использования таких моделей:

Модель CodeModel состоит из пары файлов cfunc.mod (реализация модели) и ifspec.ifs (описание интерфейса). Вот так выглядит исходный текст (файл cfunc.mod) CodeModel модели усилителя:

void cm_gain(ARGS)  
    Mif_Complex_t ac_gain;

    if(ANALYSIS != MIF_AC) {
        OUTPUT(out) = PARAM(out_offset) + PARAM(gain) * 
                         ( INPUT(in) + PARAM(in_offset));
        PARTIAL(out,in) = PARAM(gain);
    } else {
        ac_gain.real = PARAM(gain);
        ac_gain.imag= 0.0;
        AC_GAIN(out,in) = ac_gain;
    }
}

Подключение немодифицированных библиотек со SPICE-моделями

Добавлен специальный компонент «SPICE Library device», который позволяет использовать SPICE-библиотеки без их модификации и слоёв совместимости. Можно использовать один из имеющихся шаблонов символов для компонента. Пока доступны только шаблоны для ОУ с 3 или 5 выводами. Достаточно указать путь к библиотеке, название компонента, шаблон символа и при необходимости параметры компонента. Схем иллюстрирует как можно таким образом подключить ОУ. Планируется автоматизировать данный процесс. В будущем SPICE библиотеки будут отображаться в менеджере библиотек вместе с нативными библиотеками Qucs, и компоненты из них будут доступны для вставки в схему. Также планируется добавить редактор библиотек и символов по аналогии с PCAD Library Executive.

Заключение

Как именно будет дальше развиваться проект QucsS — неизвестно. В настоящее время Qucs и QucsS достаточно сильно разошлись. Я рассматриваю различные варианты. Возможно Qucs и QucsS в этом году объединятся. Но не исключено и выделение QucsS в самостоятельный проект с другим названием уже в этом году.

Let's block ads! (Why?)

Таких не берут в программисты: «реверс-инжиниринг» личности

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

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

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

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

Каждому — по способностям

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

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

«Ломать не строить», – скажут разработчики. Так вот и ни к чему тогда такому человеку в разработку идти. Так же, как и гуру программирования, который наслаждается своим могуществом, воплощая в жизнь задуманные идеи, не стоит идти в тестировщики.

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

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

Эмуляция в режиме 5/2

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

Значит, мало того, что они претендуют на позицию лишь потому, что она в тренде, так еще и резюме составляют, как говорят веб-разработчики, «под ключ». Если они все-таки попадают в компанию, например, на позицию джуниор-разработчика, то им приходится и дальше соответствовать тому, что они там в резюме себе нафантазировали.

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

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

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

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

Общий рецепт – нужно провести «реверс-инжиниринг» своей личности. Нужно исследовать недокументированные возможности своего «ядра».

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

Мы решили не откладывать это в долгий ящик и задали несколько вопросов специалистам, прошедшим этап профессионального становления.

Михаил, Системный администратор ОТП (тех поддержка)

Вы начинали карьеру как разработчик? (да/нет)

Нет. Вот как-то заинтересовался еще со школы компьютерами: всякие установки ОС, программ, почему игры не пашут… настройка сети. Так и пошло — выездной эникейщик, сидячий эникейщик, сейчас вроде уже не совсем эникейщик, даже должность называется — системный администратор.

Почему перешли / выбрали вашу текущую должность?

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

Что лично вам нравится в работе на текущей позиции?

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

Дмитрий, Руководитель проектов

Вы начинали карьеру как разработчик? (да/нет)

Да.

Почему перешли / выбрали вашу текущую должность?

Для развития, большей самостоятельности.

Что лично вам нравится в работе на текущей позиции?

Гибкий график, сдельная оплата.

Тестировщик ПО с перспективой в QA, пожелавший остаться неизвестным

Вы начинали карьеру как разработчик? (да/нет)

Нет.

Почему перешли / выбрали вашу текущую должность?

Пытался устроиться куда-нибудь в IT. Когда наткнулся на вакансию тестирования, то попробовал туда. С первого раза не взяли, но идея мне понравилась, потому продолжил подготовку по тестированию и устроился-таки.

Что лично вам нравится в работе на текущей позиции?

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

Тоня, Проект-менеджер

Вы начинали карьеру как разработчик? (да/нет)

Нет, как тестировщик

Почему перешли / выбрали вашу текущую должность?

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

Что лично вам нравится в работе на текущей позиции?

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

Сергей, Product manager – Team lead

Вы начинали карьеру как разработчик? (да/нет)

Да.

Почему перешли / выбрали вашу текущую должность?

Было желание, и руководство предоставило такую возможность.

Что лично вам нравится в работе на текущей позиции?

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

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

Максим, разработчик ПО

Вы начинали карьеру как разработчик? (да/нет)

Да.

Почему перешли / выбрали вашу текущую должность?

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

Что лично вам нравится в работе на текущей позиции?

Интересные задачи, интересная зарплата.

Данил, разработчик ПО

Вы начинали карьеру как разработчик? (да/нет)

Да.

Почему перешли / выбрали вашу текущую должность?

Да как бы по специальности и нравится вообще :)

Что лично вам нравится в работе на текущей позиции?

Нравится разрабатывать продукты на разных языках программирования и используя современные инструменты

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

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

Реверс-инжиниринг личности

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

В дополнение к вопросам может быть задана ситуация: если бы вам дали $1 мегалиард инвестиций, дали хорошего гендиректора и поручили придумать стартап и работать в нем. В какой сфере мог бы работать этот стартап? А главное — какие задачи как ИТ-специалист хотели бы решать там вы? Как бы вы оценили свои перспективы в качестве сотрудника этой компании? Куда бы хотели развиваться?

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

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

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

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

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

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

Let's block ads! (Why?)

Пора ли переходить на Swift?

[Перевод] Проклятие культуры

В одной из фундаментальных книг по этой теме «Организационная культура и лидерство» Эдгар Шейн пишет:

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

В терминологии Шейна вещи вроде столов для настольного тенниса и холодильников с пивом — это два (маленьких) примера артефактов – видимых качеств организации. Их легко заметить, но их значение обычно не поддаётся расшифровке и уникально для конкретной группы (другими словами, простое копирование фишек Google не работает).

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

Самым важным, на самом деле, является третий уровень: базовые основополагающие представления. Шейн пишет:

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

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

Слепота Microsoft

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

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

Вероятно, каноническим примером такого образа мышления была Microsoft после выхода iPhone. Сейчас это уже забылось, но ни одна компания не приблизилась к такому уровню монополии, который был у Microsoft в компьютерной индустрии примерно с 1985 по 2005 годы. (Да, Apple в итоге смогла получить гораздо больше прибыли, чем Microsoft в своей истории, и Google приблизилась близко, но они обе сделали это на гораздо большем рынке). Компания поставила дерзкие цели: «Компьютер на каждом столе и в каждом доме, с программным обеспечением Microsoft» — которую сумела достичь и превзойти: она ещё захватила и рабочие офисы. Этот беспрецедентный успех превратил цель, которая изначально провозглашалась как ценность, в неоспоримое убеждение, что все компьютеры должны, конечно же, работать на программах Microsoft. Учитывая это, настоящим шоком стало бы, если бы Стив Балмер не высмеял iPhone.

500 долларов за телефон???

Спустя полтора года Microsoft осознала, что её операционная система для смартфонов Windows Mobile не способна конкурировать с iPhone, и началась работа над тем, что впоследствии получит название Windows Phone. Однако основополагающие культурные допущения остались прежними. Первое допущение, что у Microsoft имеются время и неограниченные ресурсы, чтобы выпустить что-то поначалу хуже, но в итоге неизбежно лучшее. Во-вторых, что компания может использовать для давления доминирующее положение Windows и Office. Оба эти допущения вцементировались в культуру компании после победы Microsoft в войне браузеров и в процессе их планомерного захвата корпоративных дата-центров. В реальности, попытки Microsoft выпустить успешное мобильное устройство были обречены на провал изначально, и все понимали это ещё до того, как Windows Phone появился со своей похоронной процессией для iPhone.

^{Похоронная процессия для iPhone, сентябрь 2010 г}

Стив Балмер так никогда и не понял этого. Его последними шагами были реорганизация компании со стратегией “One Microsoft”, которая была сконцентрирована на Windows, и покупка Nokia, чтобы поддержать Windows Phone. Он уступил место Сатье Наделле, своему преемнику, чтобы тот занялся изменением культуры, и вот почему его первое выступление на публике, в котором он представил Office для iPad, было настолько важным. Я писал в то время:

«Это та власть, которая есть у исполнительных директоров. Они не могут делать всю работу, они не могут повлиять на тенденции индустрии, которые вне их контроля. Но они могут сделать выбор: принимать реальность или нет, и принимая её, повлиять на мировоззрение всех своих сотрудников»

Microsoft под управлением Наделлы за последние три года совершила потрясающие трансформации, приняв свою судьбу независимого от платформы сервис-провайдера. Но она всё ещё пытается догнать Amazon на рынке облачных сервисов, пытается догнать инструменты open source и преодолеть тот факт, что мобильные пользователи за шесть лет привыкли обходиться без программного обеспечения Microsoft. Насколько сильнее была бы компания, если бы приняла реальность в 2007 году, но культура сделала это невозможным.

Лидерство Стива Джобса

Шейн определяет лидерство в контексте культуры:

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

Отличным примером такого рода разрушения стало выступление Стива Джобса как временного исполнительного директора компании на Boston Macworld 1997 года, особенно шокирующий анонс партнёрства Apple с Microsoft.

Когда Джобс произнёс слово “Microsoft“, аудитория внятно охнула. Через несколько минут, когда Джобс щёлкнул на слайд, где Internet Explorer назывался браузером по умолчанию в Macintosh, аудитория начала гудеть так громко, что Джобсу пришлось прервать речь. Когда Джобс наконец-то произнёс эти слова «браузер по умолчанию», аудитория загудела ещё громче, и даже некоторые воскликнули «Нет!». Это, в контексте сегодняшних презентаций Apple, выглядит шокирующе.

Потом, после того как Билл Гейтс выступил перед аудиторией через спутниковую связь (что впоследствии Джобс назовёт «своим самым плохим и глупым выступлением в истории»), Джобс начал речь, которую его биограф Уолтер Айзексон назовёт «импровизированным поучением»:

«Если мы хотим двигаться вперед и увидеть, как Apple вновь встанет на ноги, мы должны пойти на некоторые уступки. Мы должны отказаться от формулы, что победа Microsoft означает поражение Apple. Окей? Мы должны принять, что если Apple хочет победить, что Apple должна проделать большую работу, и если другие собираются помочь нам, это здорово, потому что нам нужна любая помощь. И если мы запорем дело и не проделаем хорошую работу, это не чья-то вина. Так что я думаю, это очень важная перспектива.

По-моему, если мы хотим получить Microsoft Office для Macintosh, то должны с некоторой благодарностью относиться к компании, которая это сделает. Нам нравятся их программы. Так что эпоха конкуренции между Apple и Microsoft закончилась, насколько я могу судить. Речь идёт об оздоровлении и о том, как Apple сможет сделать невероятно ценный вклад в индустрию, чтобы снова стать здоровой и процветающей».

Вот что пишет Шейн:

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

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

Джобс дал Apple в целом и Macintosh в частности степень абсолютной уникальности и превосходства над конкурентами, особенно над ненавистной IBM PC и её операционной системой Windows (изначально DOS). Однако к 1997 году Microsoft победила, а Apple боролась за выживание. И всё равно аудитория освистывала тот спасательный трос, который бросили компании! Вот какую силу может нести культура — и вот почему «импровизированное поучение» Джобса было таким необходимым и настолько сильным. Это была «яблочная» версия Office для iPad, и великолепный пример лидерства.

Предупреждающие знаки для Google и Apple

На прошлых выходных Марко Армент написал широко обсуждаемое эссе «Если Google права насчёт ИИ, то это проблема для Apple»:

«Успехи BlackBerry подошли к концу не потому что RIM начала выпускать смартфоны худшего качества, а потому что новая роль смартфонов вышла практически полностью за пределы их возможностей, и было уже слишком поздно догонять. RIM не тратила несколько лет на создание операционной системы мирового класса, у неё не было большой команды великих дизайнеров или опыта в массовом производстве потребительской электроники люксового класса, или потрясающих API, или средств разработки, или каталога приложений с миллионами пользователей, которые уже стоят в очереди с кредитками в руках, или всех основных активов, которые Apple накопила за десятилетие (или дольше), которые связаны с iPhone. Никакие новые инициативы, смена менеджмента или приобретения не спасли бы BlackBerry в 2007 году. Было слишком поздно, и пропасть была слишком велика.

Сегодня Amazon, Facebook и Google много вкладывают в Искусственный интеллект, вездесущих цифровых помощников и голосовые интерфейсы, надеясь, что это станет следующим большим прорывом на рынке мобильных устройств. Если они правы — и это большое «если» — я волнуюсь за Apple… Если ландшафт изменится так, что станут важны эти сервисы ИИ с большими данными, то Apple обнаружит себя в том же положении, что и BlackBerry почти десять лет назад: всего, что они способны сделать, даже в самом лучше виде, больше не будет достаточно, и они просто не смогут догнать конкурентов».

Армент полностью прав. Однако самое интересное в том, что у Google есть собственный набор проблем: пользователи в реальности проводят время в социальных приложениях, которые в основном контролируются Facebook, и хотя критическим активом Google является Android, её самые ценные пользователи (с точки зрения монетизации) сидят на iOS. Как пользователи в реальности получат доступ к возможностям ИИ от Google (если такой будет) и как Google монетизирует их?

Конечно, ни одна из компаний в данный момент не находится в затруднительном положении. Может быть, Apple впервые за 13 лет не показала рекордные показатели, но их доход $50,6 млрд во II кв. 2016 года больше, чем общий доход Microsoft, Google и Facebook вместе взятых. В то же время, Google опять обновила исторический рекорд квартальной прибыли: $17,3 млрд.

Однако тут есть проблема: ведь BlackBerry тоже не находилась в затруднительном положении в 2006 году, как и Microsoft в 2007 году, и даже Apple в 1993-м. Не было никаких очевидных причин подозревать что-нибудь неладное, и именно культура гарантировала, что любые намёки будут проигнорирован. Снова Шейн:

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

Поэтому BlackBerry полагала, что Apple лжёт насчёт iPhone; Стив Балмер был убеждён в верности курса Microsoft, а сама Apple решила, с точки зрения Джобса, пожертвовать продуктом ради прибылей. Временем для действий был момент отрицания, а не момент кризиса.

Путь вперёд

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

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

• Apple может вступить в альянс с компанией вроде Microsoft (снова), чтобы выстроить слой сервисов как в бэкенде (Azure), так и во фронтенде, если подойти к вопросу кардинально (сочетание Siri и Cortana). Самым радикальным решением будет полностью открыть iOS, чтобы пользователи могли установить сервисы Google (или любые другие) по умолчанию. Это устраняет любые среднесрочные угрозы для iPhone со стороны функциональности Android, которая тесно завязана на возможности ИИ от Google (это проблемы скорее в долгосрочной перспективе).
• Google может — должна! — создать бота для Facebook Messenger. Более того, она должна создать полноценный бэкенд для разработчиков Facebook Messenger. Люди хотят жить на Facebook? Отлично, там и встретимся, также как Google нашла своих пользователей на операционной системе Windows посредством своего браузера.

Эти идеи (определённо, есть и другие) не лишены недостатков: Apple лишает себя будущего в качестве провайдера услуг, но если честно, я крайне скептически расцениваю возможность такого будущего в любом случае. У компании не только неправильная организационная структура, похожая на Microsoft, но ошеломляющий успех компании оказал долговременное влияние на её культуру; в данном случае, компания настолько сконцентрировалась на производстве физических продуктов, что вообще трудно представить, что появится эффективная ментальность относительно оказания сервисов, не упоминая даже присущий компании (и временами лицемерный) абсолютизм относительно приватности.

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

Проклятие культуры

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

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

Let's block ads! (Why?)

Профилирование и оптимизация программ на Go

Статистика распределения доменов по AS, IP, NS, MX и прочим параметрам

Приглашаем на конференцию DotNext

3 июня в Санкт-Петербурге состоится пятая по счету конференция DotNext для разработчиков на платформе .NET. О будущем платформы .NET рассказывают Ромуальд Здебский, руководитель направления Microsoft по играм в Центральной и Восточной Европе, который сделает на DotNext доклад на тему «Разработка игр на платформе Microsoft — технологический обзор», и технологический евангелист Microsoft Дмитрий Сошников, который выступит на DotNext с докладом «Сколько жизней у .NET: размышляем о судьбах любимой платформы, гибели Silverlight и тому подобном».

Какими изначально были цели создания платформы .NET? Достигнуты ли они?

Дмитрий Сошников: Появление .NET — это реакция на повышение сложности программных систем. Когда стало слишком трудно создавать серьезные приложения на C++, особенно с учетом существования различных вычислительных платформ, появилась цель радикально упростить процесс создания программного обеспечения, в том числе многоплатформенного. И в конце концов исследователи научились изолировать аппаратные сложности (а заодно и ряд трудоемких моментов, таких, как распределение памяти, многопоточность и т.д.) на уровне абстрактной виртуальной машины, а прикладному программисту давать возможность создавать код для этой машины. Так появились Java и .NET. Но основной целью языка Java была возможность запускать один и тот же байт-код на всех устройствах, в то время как платформа .NET гордилась многообразием поддерживаемых языков программирования.
Надо сказать, что основные цели по сути были достигнуты уже по факту создания платформы. Теперь же мы продвинулись гораздо дальше. На основе .NET можно писать приложения под все основные мобильные платформы и под микроконтроллеры. В арсенале .NET-программиста — целый спектр языков от C# и F# до Python и Objective C. Код на базе .NET используется как на устройствах, так и в облаке. Мечта программиста сбылаcь — зная всего лишь один стек технологий, он может быть продуктивным, разрабатывая практически любой программный код.

Расскажите коротко о современных технологиях разработки игр для платформы Microsoft, таких как Windows и Xbox. В чем их преимущества перед альтернативными платформами?

Ромуальд Здебский: Наверное, самое интересное сейчас преимущество для разработчиков на .NET заключается в том, что на всех устройствах, на всех форм-факторах теперь актуальна операционная система Windows 10 — с единым ядром, единым магазином приложений и, что особенно важно для разработчиков, единым API, который позволяет, разработав игру и создав единый установочный пакет, дать возможность пользователям играть в эту игру на любых устройствах с любыми форм-факторами, на смартфонах, ноутбуках, десктопах, Xbox One, HoloLens. Разработчики всегда мечтали о том, чтобы меньше заниматься низкоуровневыми техническими вещами, связанными с портированием или с возможностью запуска приложений на различных форм-факторах, и больше сосредоточиться на том, что интересно — на создании логики приложения, инновационных алгоритмов, повышении производительности, оптимизацией и т.д. И как раз Windows 10, Universal Windows Platform, позволяет это реализовывать.

Чем эти платформы интересны для разработчиков на платформе .NET?

Ромуальд Здебский: Этот вопрос содержит в себе и ответ — с учетом ответа на первый вопрос. Теперь можно создавать приложения не для какой-то малонаселенной пользователями реальности, а для очень большой экосистемы Windows. На Windows 10 функционирует уже более 300 млн устройств. Рост инсталляционной базы Windows 10 уже почти в 1,5 раза опережает рост в свое время очень популярной Windows 7. Более миллиарда ПК на планете сейчас могут быть бесплатно обновлены до Windows 10. Мы ожидаем, что в течение следующих двух-трех лет инсталляционная база Windows 10 достигнет более чем миллиарда устройств — и доступ к этой огромной аудитории дает разработчикам .NET.

Чем вызвана критика .NET со стороны сообщества разработчиков? Какова позиция Microsoft по этим вопросам?

Дмитрий Сошников: Microsoft — большая компания, и ее любят ругать. Очень популярно было, например, критиковать «закрытость» .NET, то, что называется «vendor lock». Однако теперь ситуация в корне изменилась, поскольку будущее .NET определяет уже не Microsoft, а организация .NET Foundation. Исходный код нового поколения .NET открыт и разрабатывается коллективными усилиями по модели открытого кода.

Еще одна популярная «претензия» — это частые перемены. Сначала была классическая платформа .NET, потом Silverlight, потом Universal Windows Platform — и каждый раз приходилось переучиваться. С этим отчасти придется согласиться — но это верно не только в отношении .NET. На самом деле любой разработчик должен быть готов всю жизнь изучать что-то новое и жить в условиях неопределенности! Более того, к этому должен быть готов вообще любой серьезный профессионал в любой предметной области.

Ромуальд Здебский: Когда появилась платформа .NET, она охватывала в первую очередь самые популярные на тот момент форм-факторы — настольный Windows-клиент и Windows Server. Тогда это был один из самых популярных форм-факторов в мире. Но с ростом популярности веба росла популярность различных интерактивных веб-плагинов, таких как Adobe Flash и т.д. Поэтому мы разработали «легкую» браузерную «адд-ин» платформу Silverlight, чтобы разработчики могли создавать богатые, интерактивные веб-приложения на базе .NET. Сегодня популярность браузерных дополнений падает, индустрия движется к HTML 5, чтобы браузеры работали с предсказуемой производительностью без нативных «адд-инов» для базового рендеринга.

И, наконец, индустрия двинулась в сторону мобильных приложений. Для первых версия Windows Phone была использована платформа Silverlight — «легкий» браузерный «адд-ин». А теперь появилась Windows 10, Universal Windows Platform — это .NET c возможностью создавать на C# и приложения, и игры. Компания Xamarin влилась в Microsoft, и мы сделали ее инструментарий бесплатным — это прекрасная возможность для .NET-разработчиков использовать свои навыки для создания кросс-платформенных приложений, работающих и на iOS, и на Android. Очень популярна среда разработки игр Unity, в которой можно использовать также C#.

Кстати, то же самое происходит на серверной стороне — .NET Core позволяет .NET-разработчикам создавать, например, ASP.NET-приложения для Mac OS и Linux.

Silverlight изначально считалась весьма перспективной технологией, однако ее развитие прекращено. Можно ли коротко поделиться историей вопроса, появится ли альтернатива этой технологии?

Дмитрий Сошников: Silverlight — это по сути дела первая попытка сделать на базе принципов .NET альтернативный «легкий» фреймворк, способный работать в браузере на разных платформах. Благодаря своей «легковесности» он применялся для приложений Windows Phone 7.

Но сейчас сама идея использования плагинов сходит на нет, а поколение Windows Phone 7 вытеснено более современными устройствами, поэтому и актуальность Silverlight падает. Вместо него появляются новые реинкарнации платформы .NET, в т.ч. .NET Native и .NET Core, основанные на одних и тех же базовых принципах и базовых API.

Вы считаете, что тот факт, что в стратегии платформы часто происходят перемены, не является проблемой .NET?

Ромуальд Здебский: Зачем мы что-то меняем? Ради того, чтобы и платформа, и разработчики оставались актуальными на современном рынке. Мы хотим быть конкурентоспособной платформой, мы хотим развиваться. Все изменения, которые мы вносим, так или иначе связаны именно с этим. Все это делается в рамках общей стратегии открытости делается для того, чтобы и сама компания Microsoft, и разработчики на платформе Microsoft оставались конкурентоспособными.

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

Каковы перспективы мобильных игр на Windows Phone?

Ромуальд Здебский: Здесь надо говорить шире, нельзя замыкаться только на Windows Phone. .NET позволяет создавать универсальные игры, которые запускаются на смартфонах, на планшетах, на персональных компьютерах и на игровых приставках. Только так вы охватите своими играми всю потенциальную аудиторию. Если концентрироваться только на смартфонах, то больше половины аудитории останется «за бортом». Сейчас уже неправильно создавать отдельные версии игр под разные форм-факторы. Надо создавать единую игру, предусматривая корректное, разумное масштабирование. Выходить сейчас с игрой, которая не рассчитана на все форм-факторы – не самый эффективный подход.

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

В целом — каково, на ваш взгляд, будущее .NET?

Дмитрий Сошников: На мой взгляд — самое радужное! Развитие .NET происходит по нескольким направлениям:

• Поддержка различных платформ и сред выполнения. Сейчас .NET выполняется на компактных устройствах, под управлением Windows 10, на Linux — в общем, почти везде, где может работать программный код, от микроконтроллеров до облака.
• Особенно важна многоплатформенность в смысле охвата мобильных платформ — iOS, Android, Windows Phone. Благодаря недавнему приобретению Xamarin, американского производителя многоплатформенных средств программирования, теперь любой разработчик может создавать приложения для любой мобильной платформы, находясь на любой платформе, с использованием проверенных языков (C#/F#) и инструментов. Стоит добавить сюда Unity как игровую платформу, также основанную на C#/.NET, и мы получаем полный охват мобильных платформ!
• Важно упомянуть расширение API на различные сферы, такие, например, как построение компиляторов. Инструментарий Roslyn позволяет манипулировать программами на C#/VB и легко создавать инструменты, встраиваемые в процесс компиляции.
• Распространение идей функционального программирования и сопутствующих технологий быстрой обработки и анализа данных. Вокруг языка F# возникает целая экосистема продуктов, позволяющих проводить интеллектуальную обработку и исследование данных в интерактивном режиме, затем перенося ее в облако. Ряд компаний (наиболее известен кейс Jet.com), используя основанный на F# технологический стек, существенно повысили свою эффективность.

Лично я, когда перешел на .NET из мира Java в 2003 г., почувствовал себя значительно счастливее. А сегодняшняя платформа .NET делает программиста счастливее во всех отношениях — будь то возможность использовать умный и красивый язык F# или позволяя сразу писать приложения для всего многообразия мобильных платформ и облачных сервисов.

---

Разделяете точку зрения специалистов или хотите ввязаться в спор о перспективах .NET? Нет ничего проще — все будут услышаны на DotNext Piter.

Времени остаётся совсем мало — позаботьтесь о самолёте, поезде, машине, мотоцикле, велосипеде до Санкт-Петербурга заранее.

Let's block ads! (Why?)

[Перевод] Анонс Rust 1.9

How much is the fish?

— Утром деньги, вечером стулья.
— А можно наоборот?
— Можно, но деньги вперед.

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

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

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

Итак, «fixed price» или «time&materials»?

В нашем проекте нам пришлось использовать обе схемы: в момент достаточного количества денег и их уверенного пополнения каждый месяц меня абсолютно не обламывало оплачивать труд разработчиков по схеме «time&materials». Проблемы начались, когда фактический бюджет проекта превысил запланированный в два раза, а источник финансов накрылся медным тазом (следствие крымнаша и доллар-кризиса).

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

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

Оплата за результат:

• необходима точная постановка задачи с оговоренными критериями выполнения,
• в большинстве случаев необходимо оформлять договор со штрафными санкциями (просрочки),
• исполнитель может получить аванс в размере до 50% от оговоренной суммы,
• простота планирования ресурсов для выполнения проекта,
• высокая эффективность работы (исполнитель стремится выполнить задачу в сжатые сроки).

Оплата за время:

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

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

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

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

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

PPS. Интересно, что самые финансово незащищённые участника процесса, об оплате труда которых никто не беспокоится, кроме них самих – это предприниматели. Зачастую они долгое время работаю забесплатно. А ведь именно это те маленькие лошадки, которые везут тележку с кокаином потребителям. Закон не гарантирует получение ими оплаты за труд, в отличие от работников, которые защищены ТК РФ или договором. Риск их работы и ответственность за её выполнение закономерно соразмерны их доходам.

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

Let's block ads! (Why?)

NeDB: аналог SQLite для NodeJS

[Перевод] Как понять нужно ли интегрировать blockchain в ваш продукт?

Blockchain технологии в данный момент являются слишком раздутыми. О нем пишут и говорят все: от конференций Sibos и Money20/20 до популярных материалов в изданиях The Economist и Euromoney – кажется, что каждый стремится ухватить свою долю в золотой блокчейн-лихорадке.

Как определить, что у вас реальный случай применения технологии блокчейн? Мы в Web-payment.ru много пишем о технологии распределенного реестра, и по роду деятельности нашего Digital агентства, ориентированного на финтех компании, замечаем, что поднятый вопрос очень актуальный для многих игроков рынка. Эта статья, опубликованная в блоге открытой платформы для создания своих блокчейнов MultiChain, призвана помочь разобраться в этом.

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

А что не так с теми, у кого действительно есть идея проекта? Очень часто проект может быть замечательно реализован при помощи обычной реляционной базы данных. Это такие железные чудища, как Oracle и SQL Server, а для менее предубежденных – MySQL и Postgres. Так что позвольте начать, расставив все точки над «i»:

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

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

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

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

1. База данных

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

Регистр для финансовых активов обычно может быть выражен в виде таблицы базы данных, в которой каждая строка представляет один вид активов, принадлежащих одной конкретной сущности. Каждая строка содержит три колонки, содержащие: (а) идентификатор владельца, например, номер счета; (б) идентификатор типа активов, например, «USD» или «AAPL»; (в) количество единиц актива на счету конкретного владельца.

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

2. Множество авторов

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

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

3. Отсутствие доверия

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

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

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

4. Транзакции без посредников

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

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

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

5. Взаимодействие транзакций

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

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

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

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

6. Установка правил

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

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

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

7. Выберите своих валидаторов

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

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

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

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

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

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

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

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

8. Обеспечивайте свои активы

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

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

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

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

Заключение

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

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

Let's block ads! (Why?)