Skynin http://skynin.xyz Ещё один блог программиста Fri, 15 Sep 2017 09:40:08 +0000 ru-RU hourly 1 https://wordpress.org/?v=4.6.6 http://skynin.xyz/wp-content/uploads/2016/07/johnny_automatic_periwinkle_flower_top_view-200x200.png Skynin http://skynin.xyz 32 32 Про SPA приложения http://skynin.xyz/common/pro-spa-prilozheniya/ http://skynin.xyz/common/pro-spa-prilozheniya/#respond Fri, 15 Sep 2017 09:38:51 +0000 http://skynin.xyz/?p=1249 Так как фронтендщика не удалось найти, пришлось и фронт писать самому.

Прощупал, посмотрел штук 5 фреймворков и выбрал Riot.js
Ангуляр даже не рассматривал, React тоже – оба сложнее чем мне нужно для проекта.

Попытки применить в WebUI подходы с десктопных GUI мне сразу казались нелепыми, уж очень разные нижние уровни – DOM дерево и двумерный набор пикселей. Все эти ExtJS и Dojo… монстры и мрак.

Как и MVC – во всех видах, годится только для энтерпрайзного типа интерфейсов. Конечно MVC лучше чем jQuery :)

А вот почему столь очевидный компонентый подход так поздно выстрелил – пока не понял. Движки js что-ли были медленные.

…и про моду на SPA веб-приложения.

На radio-t обсуждалась одна статья – “Что не так с SPA”

Добавлю:

1. SPA требуется когда “экран” должен уметь отображать все что есть в приложении, причем плохо прогонозируемо.
Поясню на примере:
Кладовщик отгружая товар, хочет быстро(=удобно) посмотреть очередь поставок отгружаемого товара. а потом княпнуть на поставщике, и посмотреть обороты компании с ним. И тут же княпуть на покупателе – и посмотреть как часто/много тот покупает у компании.

Но, ему никак не нужна информация об износе основных средств компании.
Риторический вопрос – надо ли делать SPA для кладовщика и бухгалтера по основным средствам? Почему – не два “приложения”?
Но – делают нередко одно. в итоге – сложность разработки, мегабайт js кода которые тянет браузер, тьмы эндпойнтов, …

2. RESTful нужен тогда, когда доступ к данным на сервере планируется осуществлять и не из браузера. А когда только из браузера – то на кой усложнять себе жизнь, лишая себя сессий на сервере и кукисов в браузере?

3. Настоящие эндпойнты(для запроса по ajax) нужны только когда пересылать все данные в браузер избыточно.
Но если все нужные данные для “экрана” известны – то зачем морочить себе голову с ajax если их можно просто заинклудить в отправляемый браузеру html?

]]>
http://skynin.xyz/common/pro-spa-prilozheniya/feed/ 0
Riot.js http://skynin.xyz/wiki/riot-js/ http://skynin.xyz/wiki/riot-js/#respond Thu, 07 Sep 2017 04:34:49 +0000 http://skynin.xyz/?post_type=yada_wiki&p=1243 Анджей Гужовский: Riot.JS, или как приготовить современные Web Components

Антон Кекс: Riot.js код из доклада доступен здесь

Роман Ахмадуллин: Riot.js. Связи между компонентами

]]>
http://skynin.xyz/wiki/riot-js/feed/ 0
Ужасы разработки http://skynin.xyz/common/uzhasy-razrabotki/ http://skynin.xyz/common/uzhasy-razrabotki/#respond Mon, 04 Sep 2017 07:52:02 +0000 http://skynin.xyz/?p=1240 … или залил по фтп дев ветку, а не обратил внимание – куда.

21231852_693350917523472_275348273764875651_n

]]>
http://skynin.xyz/common/uzhasy-razrabotki/feed/ 0
Вам не нужна микросервисная архитектура http://skynin.xyz/razrabotchikam/vam-ne-nuzhna-mikroservisnaya-arhitektura/ http://skynin.xyz/razrabotchikam/vam-ne-nuzhna-mikroservisnaya-arhitektura/#respond Mon, 21 Aug 2017 08:06:11 +0000 http://skynin.xyz/?p=1233 Dmitriy V. Simonov

О микросервисах замолвите слово
by Борис Егоров

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

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

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

Апи, эксплуатация:
* Где документация с примерами, как ваш API использовать, включая исчерпывающее описание всех возможных ошибок?
* А средства валидации запросов (декларативные схемы, как минимум для себя, как максимум — публично доступные)?
* И авторизация потребителей сервисов?
* Потребуется ведение статистики по потреблению сервисов каждым потребителем
* Нужен rate limit, квотирования по разным критериям (тип потребителя, источник запросов, определенные типы запросов, и т.д.)
* Требуется версионирование API, уведомление потребителей о сменах версий, окончании эксплуатации старых версий…

Вот это вот всё – это ещё не всё!

вся статья

обсуждение в FB

]]>
http://skynin.xyz/razrabotchikam/vam-ne-nuzhna-mikroservisnaya-arhitektura/feed/ 0
Conditional present perfect in the past http://skynin.xyz/common/conditional-present-perfect-in-the-past/ http://skynin.xyz/common/conditional-present-perfect-in-the-past/#respond Sun, 20 Aug 2017 09:08:42 +0000 http://skynin.xyz/?p=1230 “which had should have been”

I should have had to have been in bed an hour ago, but with this Quora thing it’s not gonna happen soon.

обнаружено тут

English, motherfucker! Do you speak it? ©

]]>
http://skynin.xyz/common/conditional-present-perfect-in-the-past/feed/ 0
Какие бывают заказчики http://skynin.xyz/common/kakie-byvayut-zakazchiki/ http://skynin.xyz/common/kakie-byvayut-zakazchiki/#respond Fri, 18 Aug 2017 14:58:10 +0000 http://skynin.xyz/?p=1228
]]>
http://skynin.xyz/common/kakie-byvayut-zakazchiki/feed/ 0
What salary in the United States puts you in the top 10%, top 5%, top 2%, and top 1% in terms of salary? http://skynin.xyz/common/what-salary-in-the-united-states-puts-you-in-the-top-10-top-5-top-2-and-top-1-in-terms-of-salary/ http://skynin.xyz/common/what-salary-in-the-united-states-puts-you-in-the-top-10-top-5-top-2-and-top-1-in-terms-of-salary/#respond Thu, 03 Aug 2017 09:56:04 +0000 http://skynin.xyz/?p=1223 Robert Parker, CEO at Holborn Assets на Quora написал

According to this official source: www.ssa.gov

Considering the US working population above 18 years old (that’s 160.8M workers):

In order to be in the top 10% – you need an annual salary of $90,000 and above.

In order to be in the top 5%, you need an annual salary of $130,000 and above.

In order to be in the top 2%, you need an annual salary of $195,000 and above.

In order to be in the top 1%, you need an annual salary of $255,000 and above.

]]>
http://skynin.xyz/common/what-salary-in-the-united-states-puts-you-in-the-top-10-top-5-top-2-and-top-1-in-terms-of-salary/feed/ 0
Почему я ненавижу Spring http://skynin.xyz/note/pochemu-ya-nenavizhu-spring/ http://skynin.xyz/note/pochemu-ya-nenavizhu-spring/#respond Fri, 28 Jul 2017 09:19:39 +0000 http://skynin.xyz/?post_type=note&p=1213 Полностью согласен! У меня к Spring такое же отношение – вы точно уверены что в вашем конкретном проекте он нужен?
Когда легаси, то понятно что выпилить его из проекта невозможно.
Но когда новый то…

habrahabr.ru

В начале своей карьеры я реально влюбился в Spring. Я так долго ждал его. Я использовал его во всех своих проектах. Вдобавок мне даже удалось впихнуть туда кучу всякой всячины из Spring Integration. Я был кем-то вроде короля XML. Я делал RPC-слой на основе JMS, protobufs и Kaazing для всего нашего отдела и банка в целом. Я думал: «Это так конфигурируемо. Всего-то пара XML-файлов — это действительно гибко». Я был очень доволен собой.

Но некоторые мои коллеги были склонны не согласиться. У них возникали проблемы, когда они пытались связать всё так, как им хочется; они не знали, где какие XML-файлы им нужны. Были проблемы с версиями Spring, с тем, как подружить их (я, к тому же, далеко зашел с модульностью: у нас было 5 или 6 разных модулей с разными номерами версий, и нельзя было просто так взять и понять, какой из них использовать, не спросив меня). Это были тревожные звоночки, но я их не замечал; я думал, что нужно больше документации или что те ребята просто тупые. Такая ситуация типична сама по себе: мольбы пользователей одного из самых нелюбимых и трудных в использовании фреймворков о помощи часто разбиваются о «да там один файл и немного параметров, это не так уж и тяжело», в то время как все остальные целыми днями пытаются найти магическую комбинацию файлов и параметров, чтобы хоть что-нибудь как-нибудь заработало.

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

Spring — отстой по ряду причин, и я почувствовал, что их нужно перечислить, т.к. в google нет четких контраргументов.

  • Конфигурация в XML. Хотел бы я думать, что мы как профессия оставили XML в прошлом. Он невероятно многословен, но это ещё цветочки. Намного важнее то, что я не хочу программировать на XML. Связывание всех классов воедино — чрезвычайно важная часть вашего приложения. Вы Java-разработчик, а не XML-разработчик. Одна из прелестей Java как языка — compile time safety. Я могу скомпилировать свои приложения, в которых нет Spring, и быть на 100% уверенным, что всё собрано, подключено и готово к работе. Но если в приложении есть Spring, ты запускаешь его, ждешь 30-60 секунд, пока оно инициализирует бины, прежде чем упасть. В современном мире это безумие, особенно если это еще и умножается на кучу интеграционных тестов, в которых вам нужно вертеть контейнер так и этак. Отдельного места в расстрельном списке заслуживает «это значит, что я могу менять реализацию без перекомпиляции!». Так никто не делает. Никогда.
  • Магия. Тут обычно следует реплика: «Теперь вы можете делать всё с помощью аннотаций! Больше никакого XML!». Здорово, когда не нужно программировать на XML, но аннотации — это всё ещё магия. Пока вы не запустите приложение, вы понятия не имеете, свяжется ли оно правильно. И даже потом вы не знаете, правильно ли оно связалось; вы всего лишь знаете, что оно связалось. Не люблю магию.
  • Импортирование других Spring-файлов. В данный момент это бесит меня больше всего. Я обнаружил, что существует тенденция разбивать Spring-файлы на более мелкие и раскидывать их по модулям. Я только что убил 2 недели, продираясь сквозь JAR’ы и пытаясь найти правильную комбинацию/порядок/версию Spring-файлов, чтобы кое-что заработало. Spring-файлы в JAR’ах — это плохая, плохая идея. Ужасная. Каждый раз, когда вы размазываете зависимые Spring-файлы по JAR’ам, где-то умирает ребенок.
  • Сложность. Когда на собеседовании спрашиваешь кандидата: «Какие подводные камни есть в Spring?» — чаще всего слышишь в ответ, что у него крутая кривая обучения. Правда это или нет — отдельная тема, но я хотел бы подчеркнуть тот факт, что Spring сейчас настолько сложен, что у него есть собственный фреймворк — Spring Boot. Фреймворк для фреймворка. Мы во «Framework Inception» — фильме о Леонардо Ди Каприо, который пытается найти свой давно потерянный Java-код, всё глубже и глубже погружаясь в слои XML и аннотаций, прежде чем в конце концов покончить с собой.

Штука в том, что я уверен: удачно использовать Spring в приложении теоретически возможно. Я еще никогда такого не видел, и это проблема. Как по мне, все «плюшки», которые он предлагает, вполне возможны и без него. Когда мы спрашиваем о Spring на собеседовании, кандидат обычно отвечает: «Со Spring у вас есть чистый код, разделение ответственности, к тому же он действительно хорош для тестирования». В общем, все те вещи, большим поклонником которых я являюсь (особенно тестирование), но на самом деле это результаты не использования Spring, а хорошего программирования. Возможно, для новичков Spring — это хороший костыль для освоения таких идей, как внедрение зависимостей, mocking и тестирование, но на самом деле они ортогональны Spring. Если вы применяете TDD, у вас в коде не будет геттеров и сеттеров — только внедрение зависимостей через конструкторы, которые вы можете «замокать» для тестирования, а затем, когда вы связываете своё приложение воедино, просто используете часто забываемый способ создания объектов — ключевое слово «new». Зачастую мы создаем класс «ApplicationContext», который отвечает за связывание всего воедино. Он чистый, всё тестируемо, у меня есть compile time safety, и мои тесты выполняются чертовски быстро.

Из комментариев:


  1. огромное количество библиотек и реализаций. Попробуйте навелосипедить свой spring-security c каким-нибудь oauth собственнм сервером и клиентом.

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

Альтернативу @Transactional с нетривиальнм двухфазным коммитом (например БД + Очередь в единой транзакции).

Двухфазный коммит делает не Spring, а стороннияя библиотека-координатор, например Atomikos, Narayana, etc. Spring @Transactional делает лишь наивный автоматический прокси на коммит/роллбэк, который также легко сделать вручную при помощи java.lang.reflect.Proxy, AspectJ или ByteBuddy. В реальных проектах практически всегда требуется вручную контролировать сбои и взависимости от типа ошибки нужно помимо роллбека повторить транзакцию, реинициализировать ресурс, отрапортовать о сбое, собрать метрики… Вот вам и свой @Transactional. Кроме того есть мнение, что XA вообще не рекомендуется использовать…

но опять же время на изучение и не меньшее время чтобы все это подружить между собой

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

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

Ваши 1-2 разработчика писали когда-нибудь bean postprocessors? Скорей всего они намолотили кучу кривой прикладной магии ввиде специфических @Заклинаний. Разобраться почему не проксируется бин, кто его процессит и в какой последовательности и почему вдруг что-то перестало работать — никто не будет. Девелоперы как правило понавтыкают костылей, чтобы хоть как-то решить требуемую задачу.

Куча проблем за вас решена

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

Сделать достаточно сложный проект на spring-boot для быстрого старта как прототип относительно несложно

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


На самом деле автор статьи достаточно прав.
Используя спринг на проекте — вы все больше и больше пишите кода, не связанного с проектом, но связанный со спрингом. В некотором смысле, спринг обязывает вас говнокодить. Код должен содержать бизнес логику, а не фабрики, интерфейсы, конверторы, дто и т д.
В этом и есть «болезнь» джавы, потому что когда-то давно «умные» дяди придумали кучу стандартов под маркой Java EE, и все фреймворки начали под него подстраиваться.
Ребят, задайте вопрос, «что делает спринг у меня на проекте»? Делает DI? А сколько у вас реализаций на интерфейс? Одна?? Так какой это нахрен DI? То есть вы юзаете спринг для того что бы создать ОДИН СРАНЫЙ СИНГЛТОН? Рилли??? Service/@Repository/@Controller и для этого всего-то спринг??? Так может вы просто не знаете как писать тестируемый код с синглтонами? Так почитайте!
Опять таки. Спринг, даже со своей гибкостью кривой! И не покрывает некоторые простейшкие случаи! К примеру Spring-Data-Jpa. Простейший кейс. Почему нельзя было добавить слово limit в синтаксис spring-data??? Почему когда дело доходит до более-менее сложных операций (а не CRUD) постоянно приходится отходить от «идеалов» спринга, и постоянно что-то дописывать?
Ребят, если вы говорите что спринг мега-крутой и хороший фреймвок, скорее всего вы просто не пробовали что-либо другое. Попробуйте пописать годик-два проект например на Play Framework-е, желательно на старом, что бы без DI. Попробуйте Vert.X с его реактивным программированием. Или попробуйте сами построить нужную вам архитектуру на простом веб-сервере, без сервлетов вообще. Попробуйте писать код БЕЗ JPA, продумайте архитектуру и тогда вы начнете мыслить по другом. А то у нас бл*ть не программист, а Senior Spring-Framework Developer, и если что-то не входит в спринг, не в силах решить проблему.
А самое интересное, что отказавшись от спринга, вы хоть и напишите «маленький» велосипед в виде кастомной архитектуры.
НО! Вы увидите, что ваш код стал намного чище и намного гибче, чем со спрингом. И вы имеет ПОЛНЫЙ контроль над своим кодом! Я пишу на джаве с 2010 года, за это время были совершенно разные проекты с соершенно разными подходами. И к огромному сожалению, я заметил, что мода «богатых дядек» на ентерпрайз только усугубляет вещи в джаве. «Типичные вещи» в джаве можно делать намного проще, чем вы можете себе представить. (PHP программисты наверное офигивают, когда видят, как на джаве пишутся веб приложения, потому что у них нету джава ЕЕ, спринга и т.д., и там всё гораздо чище и проще).

]]>
http://skynin.xyz/note/pochemu-ya-nenavizhu-spring/feed/ 0
про тестовые задания http://skynin.xyz/razrabotchikam/pro-testovye-zadaniya/ http://skynin.xyz/razrabotchikam/pro-testovye-zadaniya/#respond Thu, 27 Jul 2017 10:02:19 +0000 http://skynin.xyz/?p=1208 Жду тут от соискателя результаты по тестовому заданию, и подумал, а почему сам то бывает согласен делать, а бывает и – ну, послали подальше, значит послали… не дотягиваю по каким-то критериям до требуемого уровня. а может и просто – эйджизм, или еще что-то посильнее рациональных аргументов.

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

про 3е, знаю по себе. после того как эйчары отбирают что-то похожее на ценное из присылаемого шлака (я автослесарь, но решил стать программистом, закончил 3ех месячные курсы по …)
нам рассылали эти резюме.
и первая реакция то сугубо человеческая и у технарей – хочется ли поговорить с этим программистом “за пивом”? неоосознанная конечно, как всякая первая реакция.

дальше уже формальности. если хочется, то после обсуждения между собой на кухне – эйчарам говорится – да, давайте назначим собеседование.
если не хочется… (или действительно слабоват, см. п 1) – то… “а давайте ему тестовое вышлем!” в случае “не хочется” – что-то с “TopCoder”

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

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

и те кто дает такое тестовое – прекрасно об этом знают. а если не знают – то тогда вам лучше пройти мимо этой компании.

конечно, ради какого-нить Microsoft Research & Development Department- сделайте исключение :D

]]>
http://skynin.xyz/razrabotchikam/pro-testovye-zadaniya/feed/ 0
Критерий зрелости http://skynin.xyz/common/kriterij-zrelosti/ http://skynin.xyz/common/kriterij-zrelosti/#respond Wed, 26 Jul 2017 15:57:21 +0000 http://skynin.xyz/?p=1192 Зрелость технологии определяется полнотой и глубиной описания ее недостатков.
У незрелых технологий нет недостатков, а сплошной вау эффект, переворот в науке, революция!

]]>
http://skynin.xyz/common/kriterij-zrelosti/feed/ 0
Призрачность великой русской литературы http://skynin.xyz/spiritual/prizrachnost-velikoj-russkoj-literatury/ Wed, 26 Jul 2017 09:51:20 +0000 http://skynin.xyz/?post_type=spiritual&p=1194 Почему этого не видят?
Ну вот Братья Карамазовы. Ведь очевидно, что это не три человека, а один, ум, страсть и дух, один человек, описанный в трех телах.
Ну вот Три сестры. Начинается, что они приходят с кладбища. Это три умерших, три призрака, которые хотят пожить. Они потому не могут уехать. Там жива только Наташа. Оля, Маша и Ирина – это одна женщина, разделенная на части. Материнство, страсть, флер молодости и женственности.
Я даже не упоминаю про Нос.
У всех вместо целого человека – разделенная на персонажи личность.
Или это все видят, только говорят редко?
Мольер никуда не уходил. Персонажи остаются одномерными, “человек одной страсти” и т.п. Как называть целого человека, который в романе выглядит как несколько самостоятельных персонажей?

не мог не перепостить http://ivanov-petrov.livejournal.com/2066927.html

]]>
Фентези спорт (Yii2) http://skynin.xyz/fentezi-sport-yii2/ Mon, 17 Jul 2017 07:16:27 +0000 http://skynin.xyz/?page_id=1183 Участвовал в разработке сайта для игры в фентези-спорт. Писал описание предметной области, техническое задание, план работ с критериями приемки этапов.
Проект умер на 1ом (из 3ех) майлстоунов. Успел спроектировать схему базы данных, с учетом потребности в расчетах, и подружил DDD с ActiveRecord от Yii2

Использовал идею журнала расчетов, а не двойные проводки, как в проекте:

Billing на Yii 2

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

]]>
vc.ru: Золотому веку интернет-стартапов пришёл конец http://skynin.xyz/common/vc-ru-zolotomu-veku-internet-startapov-prishyol-konets/ http://skynin.xyz/common/vc-ru-zolotomu-veku-internet-startapov-prishyol-konets/#respond Mon, 17 Jul 2017 06:20:50 +0000 http://skynin.xyz/?p=1181 …стартапы потому и мрут что не могут решить две проблемы:
1. как нагнать на сайт, сервис посетителей
2. как получить с них копеечку, даже если нагнали
в снговье 2ая проблема усугубляется еще и бедностью населения.

Мы представляем себе Кремниевую долину как место, где несколько знакомых могут, не выходя из гаража или общежития, основать компанию, которая потом перевернёт весь мир. Так было с Apple и Microsoft в 70-е годы, с AOL в 80-е, c Amazon, Yahoo и Google в 90-е, и c Facebook в нулевые.

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

До конца 2016 года казалось, что Uber суждено стать новым интернет-гигантом. Но после скандального ухода главы компании счастливое будущее Uber уже не так вероятно, как было раньше. Другие технологические компании, открытые за последний десяток лет, очень далеки от лиги гигантов. Airbnb, второй по дороговизне американский стартап после Uber, оценивается 31 миллиард долларов. Это около 7% стоимости Facebook. Остальные — например, Snap, Square или Slack — стоят намного меньше.

Что же происходит? Во время поездки в Кремниевую долину автор статьи задал этот вопрос нескольким инвесторам и директорам компаний.

«Когда я смотрю на Google или Amazon в 90-е, я думаю о первооткрывателях Колумбе или Васко Де Гама, в первый раз отправляющимся в плавание от берегов Португалии», — говорит Джей Завери, инвестор в фирме Social Capital, работающей в Долине.

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

Это уже происходило ранее. В 50-е, 60-е и 70-е в мире была лихорадка вокруг производства полупроводников. Но в результате рынок затих под властью нескольких гигантов — Intel, Samsung и Qualcomm. Инновации в Кремниевой долине не остановились. Они просто ушли от чипов к другим продуктам.

В 80-е великие компании Microsoft, Adobe и Intuit были созданы с целью производства ПО для компьютеров. Они продолжают зарабатывать неимоверно много денег, как и Intel, но на рынке почти нет места для стартапов в области компьютерного ПО.

Рынок приложений и онлайн-сервисов, возможно, достигает той же точки. Есть какое-то конечное количество вещей, которые можно делать с браузером или смартфоном. И, вполне возможно, компании вроде Google, Facebook и Snap уже захватили все самые важные направления.

Остальное в статье

]]>
http://skynin.xyz/common/vc-ru-zolotomu-veku-internet-startapov-prishyol-konets/feed/ 0
Вирус Petya.A http://skynin.xyz/common/virus-petya/ http://skynin.xyz/common/virus-petya/#respond Tue, 27 Jun 2017 19:00:57 +0000 http://skynin.xyz/?p=1162 …жмите кнопку выключить пока точно не выключится.

И не включать, а отдать специалисту.

А если увидели такую картинку:

19441741_10155557733714374_7964397039254158470_o

то уже поздно.


Tim Tretyak (ASM, TS Consultant в Hewlett Packard Enterprise)
Kоротенько суммирую:
1. Изначальный вектор распространения рансомвари — обновления программы m.e.doc. Невзирая на то, что сами они это отрицают, статистика на конец дня четко показывает, что заражены все сервера m.e.doc, обновлявшиеся в течение последних недель. Или иными словами — пока не найдено ни одного незараженного сервера данной программы.
2. По локалке рансомварь распространяется как минимум двумя способами — через старый добрый MS17-010 и открытие клиентом документа с CVE-2017-0199 на недопатченных машинах и, что более интересно, с помощью простого копирования пэйлоада на шару c$ с последующим выполнением по WMI или psexec.
3. Второй способ распространения объясняет каким образом были заражены полностью патченные машины. Также на момент распространения хорошо перепакованый пэйлоад CVE-2017-0199 не ловился практически никакими антивирями (да и сейчас не ловится).
4. Рансомварь имеет таймбомбу. Т.е. активировалась сегодня утром по таймеру. Что создает некоторые дополнительные напряги с определением точного времени ее загрузки.
5. Вишенка на торт (с хабра) — несколько недель назад было обновление медка, после которого он перестал работать и в качестве решения саппорт рекомендовал перезапустить его от админа домена.
6. По другим источникам в рансомварь встроен тул вылавливания паролей из памяти зараженной машины, однако эта информация еще требует подтверждения.
7. Каким способом рансомварь попадает в сети, где нет медка, пока точно неизвестно.


Главным вкладом в эпидемию Пети было даже не игнорирование рекомендаций после эпидемии WannaCry

а софтина Медок (m.e.doc)

По локалкам в основном через вполне кошерные psexec и WMI. Главное, чтобы медок был от админа домена запущен.

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

Апдейтер Медка вытащил бинарник, проверил мд5, развернул и запустил (там селфэкстрактор), что-то внутри себя обновил.
Более того — после этого спокойно прошло еще 5 дней (апдейт от 22-го), после чего — хлоп, вирус включился по своему таймеру, и приехали.

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

New ransomware, old techniques: Petya adds worm capabilities

]]>
http://skynin.xyz/common/virus-petya/feed/ 0
Не купитесь на ERP! http://skynin.xyz/note/ne-kupites-na-erp/ http://skynin.xyz/note/ne-kupites-na-erp/#respond Mon, 19 Jun 2017 19:09:48 +0000 http://skynin.xyz/?post_type=note&p=1156 Текст не мой, есть спорные тезисы, но в целом согласен

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

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

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

Говорят, на западе это получилось. У нас иногда тоже получается. Только зачем и какой ценой?

С чего начинается то, в чем потом стыдно признаться и приходится делать вид, что
все работает и очень-очень большие деньги потрачены не зря?

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

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

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

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

Итак, с теми, кому это надо, а кому не надо мы разобрались. Если Вас все-таки убедили, и Вы подписали договор – идем дальше.

Анализ существующих бизнес-процессов

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

При составлении плана графика Ваши руководители будут уворачиваться и извиваться между личными отпусками, рождественскими каникулами, 23 февраля, 8 марта и другими святыми для них периодами удачного смыва на моря и дачу в деревне. Но график будет составлен! Только пошлют на интервью ключевых пользователей которым эта ERP на х… не нужна, ввиду офигенной занятости руководителей.

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

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

(проверьте, у Вас будет точно такой же)

Анализ существующих бизнес-процессов

1. Отсутствует система нормативно-справочной информации. Справочник номенклатуры не систематизирован, имеет дублирующие записи, в дочерних обществах разный. Перечень аналогов отсутствует. Атрибуты категории запасов и бюджетного учета отсутствуют. Инструкция по формированию наименований номенклатуры МТР, работ и услуг отсутствует (здесь IT директор расплачется, что он наконец-то получил от умных людей подтверждение того, что всем сто раз говорил, а его никто не слушает). По факту, задача решается элементарно, без ERP.

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

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

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

2. Отсутствует система нормирования расхода МТР (здесь воспрянут духом наивные экономисты, потому, что когда они учились, им рассказывали, что при СССР была система норм и нормативов расхода ТМЦ, и у них заблестят глаза, что скоро у них будет тоже).

Задача сегодня разрешима лишь в части нормирования расхода сырья, но это элементарно делается без ERP.

В части МТР, нормы отсутствуют как класс (институты, которые их разрабатывали, давно исчезли). Нормативы расхода МТР посчитать очень сложно, но можно и ERP здесь не причем. В общем, если экономисты сами еще не рассчитали нормы и нормативы, то с внедрением ERP они у них чудесным образом не появятся.

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

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

Excel не так уж и плох! Он очень хорош и год от года все лучше и лучше. Нужно просто учиться в нем работать. ERP до простоты и оперативности Excel как до Китая. В 90% случаев стандартных функций Excel достаточно.

4. Много операций по вводу данных дублируется, что обуславливает излишнюю численность персонала (в этот момент директор HR скажет, что он «давно уже говорил всем, что надо оптимизировать, а никто не оптимизировал и теперь он так рад внедрению ERP, так рад).

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

5. Отсутствует система ТОиР (здесь седой главный механик Холдинга пустит слезу, вспомнив как получил в 1985 г. толстенной книгой Александра Ящура «Система технического обслуживания и ремонта» по башке от механика цеха).

Детки и ребятки, которые к Вам приедут внедрять, родились в 90-х годах. Максимум, что они знают, это как расшифровывается ТОиР и то, что его надо внедрять. А если механик дожил до седин и так и не внедрил ТОиР, то уже и не внедрит никогда, хоть с ERP, хоть без нее. Кстати, та книжка сохранилась.

Вывод наверняка будет таким:

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

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

Ваше первое желание – всех разогнать! Второе – ускорить внедрение ERP! На это и был расчет. Но не горячитесь. Это лишь вода. У Вас есть еще возможность соскочить. Соль совсем в другом.

Вот оно откровение!

автор: Грачев Дмитрий Анатольевич
+7 960 918 4197
Все права на текст принадлежат
ООО “Аукционный центр “Гермес”
ОГРН1154217001344
achermes на mail.ru

Окончание текста про ERP

]]>
http://skynin.xyz/note/ne-kupites-na-erp/feed/ 0
Вирус WannaCrypt (WCry) http://skynin.xyz/common/virus-wannacrypt-wcry/ http://skynin.xyz/common/virus-wannacrypt-wcry/#respond Sun, 14 May 2017 10:06:02 +0000 http://skynin.xyz/?p=1143 Оригинал взят у thread2 в о новой Windows-уязвимости

Если очень коротко — то любая Windows-машина, на которой не стоит обновление, описанное в майкрософтовском бюллетене MSE17-010, может быть полностью захвачена любым участником той же сети.

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

Атака состоит из нескольких частей, входной точкой которых является обращение к SMB-серверу атакуемой машины по протоколу SMB 1.0 . Скажу честно, что про протокол SMB 2.0, также упоминаемый в некоторых статьях, я на сегодня ничего сказать не могу — за исключением того, что MSE17-010 его не упоминает.
Если авто-обновление включено, то “March 2017 Security Monthly Quality Rollup”, в котором эта дырка была заделана, уже должен быть установлен.

Объясняя на пальцах — на вашей машине, вероятно, работает “служба расшаривания файлов и папок” — я все время забываю, как она правильно по-русски называется — принимающая соединения на порту 445, в том числе и по протоколу версии 1 ( на сегодня их существует как минимум три основных — с массой подвариантов ).
Это именно тот путь, по которому недавняя модификация вируса проникает на заражаемые машины.

Соответственно, для защиты от атаки можно предпринять один или все из следующих шагов, которые должны закрыть эту дорогу:
— установить на машине обновление безопасности от марта сего года — см. двукратно упоминавшуюся ссылку выше ;
— запретить на машине или сетевом роутере входящие соединения на портах 445 и 139 (см) ;
— запретить на машине поддержку протокола SMB 1.0 ( см ; грубо говоря, надо открыть определенный диалог и клюкнуть на определенную галку ; для уже неподдерживаемых систем типа Windows XP — гугл ваш друг )
— полностью погасить на вашем компьютере службу расшаривания файлов.

PS. В качестве исторического замечания — довольно забавно, что вся история загорелась после того, как хакеры ( Shadow Brokers ) спионерили у шпионов (NSA — National Security Agency) их набор хакерских инструментов, выложив их оные в открытый доступ после относительно неуспешных попыток продажи . После чего произошли два события:
во-первых, лидирующие фирмы-производители гордо сказали, что они и так закрыли большинство этих дырок, скромно умолчав о том, что самые зияющие отверстия продолжают зиять ;
во-вторых, пока они спешно заделывали ( и таки заделали ) эти дырки, успокоенная публика отдыхала ;
в-третьих, некие талантливые, но злонамеренные ребята, которые не поверили официальным объявлениям и почесались проверить эти утверждения на практике, успешно проапгрейдили свой вирус-шифровальщик и сейчас пытаются погасить с его помощью мир. ( ну то есть они просто хотят собрать в качестве выкупа все деньги на свете, но учитывая, что побочным эффектом является приостановка работы по всему миру организаций вроде госпиталей — это именно атака на весь шарик. )

В общем, обновите настройки на своем компьютере.

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


Библиография

]]>
http://skynin.xyz/common/virus-wannacrypt-wcry/feed/ 0
Middleware http://skynin.xyz/wiki/middleware/ http://skynin.xyz/wiki/middleware/#respond Thu, 30 Mar 2017 09:00:27 +0000 http://skynin.xyz/?post_type=yada_wiki&p=1134 Три статьи которые наглядно показывают суть подхода

middleware

My first approach to Zend Expressive
On HTTP, Middleware, and PSR-7
О HTTP, Middleware и PSR-7 или что не так с текущим подходом

]]>
http://skynin.xyz/wiki/middleware/feed/ 0
Тим Урбан: Искусственный Интеллект http://skynin.xyz/spiritual/tim-urban-iskusstvennyj-intellekt/ Wed, 22 Mar 2017 09:33:09 +0000 http://skynin.xyz/?post_type=spiritual&p=1128 Оригинал на fastsalttimes.com

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

ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ. ЧАСТЬ ПЕРВАЯ: ПУТЬ К СВЕРХИНТЕЛЛЕКТУ

Причина, по которой эта (и другие) статья появилась на свет, проста: возможно, искусственный интеллект — не просто важная тема для обсуждения, а самая важная в контексте будущего. Все, кто хоть немного проникает в суть потенциала искусственного интеллекта, признают, что оставлять без внимания эту тему нельзя. Некоторые — и среди них Элон Маск, Стивен Хокинг, Билл Гейтс, не самые глупые люди нашей планеты — считают, что искусственный интеллект представляет экзистенциальную угрозу для человечества, сопоставимую по масштабам с полным вымиранием нас как вида. Что ж, усаживайтесь поудобнее и расставляйте для себя все точки над i.

«Мы стоим на пороге изменений, сравнимых с зарождением человеческой жизни на Земле» (Вернор Виндж).

Что значит стоять на пороге таких изменений?

ИИ

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

ИИ

Ощущения вполне нормальные, полет проходит успешно.

Будущее приближается

Представьте, что машина времени перенесла вас в 1750 год — во времена, когда мир испытывал постоянные перебои с поставками электричества, связь между городами подразумевала выстрелы из пушки, а весь транспорт работал на сене. Допустим, вы попадаете туда, забираете кого-нибудь и приводите в 2015 год, показать, как оно тут все. Мы не в состоянии понять, каково ему было бы увидеть все эти блестящие капсулы, летящие по дорогам; поговорить с людьми по ту сторону океана; посмотреть на спортивные игры за тысячу километров от него; услышать музыкальное выступление, записанное 50 лет назад; поиграть с волшебным прямоугольником, который может сделать снимок или запечатлеть живой момент; построить карту с паранормальной голубой точкой, обозначающей его местоположение; смотреть на чье-то лицо и общаться с ним за много километров и так далее. Все это — необъяснимое волшебство для почти трехсотлетних людей. Не говоря уже об Интернете, Международной космической станции, Большом адронном коллайдере, ядерном оружии и общей теории относительности.

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

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

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

И тогда, после смерти, он бы позавидовал и захотел сделать то же самое. Вернулся бы на 12 000 лет назад, в 24 000 год до н. э., забрал бы человека и притащил его в свое время. И новый путешественник сказал бы ему: «Ну такое, хорошо, спасибо». Потому что в этом случае человеку из 12 000 год до н. э. нужно было бы вернуться на 100 000 лет назад и показать местным аборигенам огонь и язык в первый раз.

Если нам нужно перевезти кого-то в будущее, чтобы тот был до смерти удивлен, прогресс должен пройти определенное расстояние. Должна быть достигнута Точка Смертельного Прогресса (ТСП). То есть, если во времена охотников-собирателей ТСП занимала 100 000 лет, следующая остановка состоялась уже в 12 000 году до н. э. За ней прогресс шел уже быстрее и кардинально преобразил мир к 1750 году (ориентировочно). Потом понадобилось пару сотен лет, и вот мы здесь.

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

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

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

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

Курцвейл предполагает, что прогресс всего 20 века мог бы быть пройден всего за 20 лет при уровне развития 2000 года — то есть в 2000 году скорость прогресса была в пять раз выше, чем средняя скорость прогресса 20 века. Также он считает, что прогресс всего 20 века был эквивалентен прогрессу периода с 2000 по 2014 год, и прогресс еще одного 20 века будет эквивалентен периоду до 2021 года — то есть всего за семь лет. Спустя несколько десятков лет весь прогресс 20 века будет проходиться по несколько раз в год, а дальше — всего за месяц. В конечном итоге закон ускоряющейся отдачи доведет нас до того, что за весь 21 век прогресс будет в 1000 раз превышать прогресс 20 века.

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

Почему же, когда мы сталкиваемся с заявлениями вроде «мир через 35 лет изменится до неузнаваемости», мы скептически пожимаем плечами? Есть три причины нашего скепсиса относительно прогнозов будущего:

1. Когда дело доходит до истории, мы думаем прямыми цепочками. Пытаясь представить прогресс следующих 30 лет, мы смотрим на прогресс предыдущих 30 как на индикатор того, сколько всего, по всей вероятности, произойдет. Когда мы думаем о том, как изменится наш мир в 21 веке, мы берем прогресс 20 века и добавляем его к 2000 году. Такую же ошибку совершает наш парень из 1750 года, когда достает кого-то из 1500 года и пытается его удивить. Мы интуитивно думаем линейным образом, хотя должны бы экспоненциальным. По существу, футуролог должен пытаться предугадать прогресс следующих 30 лет, не глядя на предыдущие 30, а судя по текущему уровню прогресса. Тогда прогноз будет точнее, но все равно мимо ворот. Чтобы думать о будущем корректно, вам нужно видеть движение вещей в куда более быстром темпе, чем они движутся сейчас.

ИИ

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

ИИ

Такая кривая проходит через три фазы: 1) медленный рост (ранняя фаза экспоненциального роста); 2) быстрый рост (взрывная, поздняя фаза экспоненциального роста); 3) стабилизация в виде конкретной парадигмы.

Если вы взглянете на последнюю историю, часть S-кривой, в которой вы в данный момент находитесь, может скрывать от вашего восприятия скорость прогресса. Часть времени между 1995 и 2007 годами ушла на взрывное развитие Интернета, представление Microsoft, Google и Facebook публике, рождению социальных сетей и развитию сотовых телефонов, а затем и смартфонов. Это была вторая фаза нашей кривой. Но период с 2008 по 2015 год был менее прорывным, по крайней мере на технологическом фронте. Те, кто думают о будущем сегодня, могут взять последние пару лет для оценки общего темпа прогресса, но они не видят большей картины. На деле же новая и мощная фаза 2 может назревать уже сейчас.

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

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

Путь к сверхинтеллекту: что такое ИИ (искусственный интеллект)?

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

Есть три причины, которые приводят к путанице вокруг термина ИИ:

  1. Мы ассоциируем ИИ с фильмами. «Звездные войны». «Терминатор». «Космическая Одиссея 2001 года». Но как и роботы, ИИ в этих фильмах — вымысел. Таким образом, голливудские ленты разбавляют уровень нашего восприятия, ИИ становится привычным, родным и, безусловно, злобным.
  2. Это широкое поле для применения. Оно начинается с калькулятора в вашем телефоне и разработки самоуправляемых автомобилей и доходит до чего-то далекого в будущем, что кардинально изменит мир. ИИ обозначает все эти вещи, и это сбивает с толку.
  3. Мы используем ИИ каждый день, но зачастую даже не отдаем себе в этом отчета. Как говорил Джон Маккарти, изобретатель термина «искусственный интеллект» в 1956 году, «как только он заработал, никто больше не называет его ИИ». ИИ стал больше как мифическое предсказание о будущем, нежели что-то реальное. В то же время есть в этом названии и привкус чего-то из прошлого, что никогда не стало реальностью. Рэй Курцвейл говорит, что он слышит, как люди ассоциируют ИИ с фактами из 80-х годов, что можно сравнить с «утверждением, что интернет умер вместе с доткомами в начале 2000-х».
  4. Давайте проясним. Во-первых, перестаньте думать о роботах. Робот, который является контейнером для ИИ, иногда имитирует человеческую форму, иногда нет, но сам ИИ — это компьютер внутри робота. ИИ — это мозг, а робот — тело, если у него вообще есть это тело. К примеру, программное обеспечение и данные Siri — это искусственный интеллект, женский голос — персонификация этого ИИ, и никаких роботов в этой системе нет.
  5. Во-вторых, вы наверняка слышали термин «сингулярность» или «технологическая сингулярность». Этот термин используется в математике для описания необычной ситуации, когда обычные правила больше не работают. В физике он используется для описания бесконечно малой и плотной точки черной дыры или изначальной точки Большого Взрыва. Опять же, законы физики в ней не работают. В 1993 году Вернор Виндж написал знаменитое эссе, в котором применил этот термин к моменту в будущем, когда интеллект наших технологий превзойдет наш собственный — и в этот момент жизнь, какой мы ее знаем, изменится навсегда, а обычные правила ее существования больше не будут работать. Рэй Курцвейл в дальнейшем уточнил этот термин, указав, что сингулярность будет достигнута, когда закон ускоряющейся отдачи достигнет экстремальной точки, когда технологический прогресс будет двигаться так быстро, что мы перестанем замечать его достижения, почти бесконечно быстро. Тогда мы будем жить в совершенно новом мире. Однако многие эксперты перестали использовать этот термин, поэтому давайте и мы не будем часто к нему обращаться.
  6. Наконец, хотя есть много типов или форм ИИ, которые вытекают из широкого понятия ИИ, основные категории его зависят от калибра. Есть три основных категории:
  1. Узконаправленный (слабый) искусственный интеллект (УИИ). УИИ специализируется в одной области. Среди таких ИИ есть те, кто может обыграть чемпиона мира по шахматам, но на этом все. Есть такой, который может предложить лучший способ хранения данных на жестком диске, и все.
  2. Общий (сильный) искусственный интеллект. Иногда также называют ИИ человеческого уровня. ОИИ относят к компьютеру, который умен, как человек — машина, которая способна выполнять любое интеллектуальное действие, присущее человеку. Создать ОИИ намного сложнее, чем УИИ, и мы пока до этого не дошли. Профессор Линда Готтфредсон описывает интеллект как «в общем смысле психический потенциал, который, наряду с другими вещами, включает способность рассуждать, планировать, решать проблемы, мыслить абстрактно, понимать сложные идеи, быстро учиться и извлекать опыт». ОИИ должен уметь делать все это так же просто, как делаете вы.
  3. Искусственный сверхинтеллект (ИСИ). Оксфордский философ и теоретик ИИ Ник Бостром определяет сверхинтеллект как «интеллект, который гораздо умнее лучших человеческих умов в практически любой сфере, включая научное творчество, общую мудрость и социальные навыки». Искусственный сверхинтеллект включает в себя как компьютер, который немного умнее человека, так и тот, который в триллионы раз умнее в любом направлении. ИСИ и есть причина того, что растет интерес к ИИ, а также того, что в таких обсуждениях часто появляются слова «вымирание» и «бессмертие».

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

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

Где же мы в этом потоке?

Узконаправленный искусственный интеллект — это машинный интеллект, который равен или превышает человеческий интеллект или эффективность в выполнении определенной задачи. Несколько примеров:

  • Автомобили битком набиты системами УИИ, от компьютеров, которые определяют, когда должна заработать антиблокировочная тормозная система, до компьютера, который определяет параметры системы впрыска топлива. Самоуправляемые автомобили Google, которые в настоящее время проходят испытания, будут содержать надежные системы УИИ, которые будут воспринимать и реагировать на мир вокруг себя.
  • Ваш телефон — маленькая фабрика УИИ. Когда вы используете приложение карт, получаете рекомендации по скачиванию приложений или музыки, проверяете погоду на завтра, говорите с Siri или делаете что-либо еще — вы используете УИИ.
  • Спам-фильтр вашей электронной почты — классический тип УИИ. Он начинает с выяснения того, как отделить спам от пригодных писем, а затем обучается в процессе обработки ваших писем и предпочтений.
  • А это неловкое чувство, когда еще вчера вы искали шуруповерт или новую плазму в поисковике, а сегодня видите предложения услужливых магазинов на других сайтах? Или когда в социальной сети вам рекомендуют добавить интересных людей в друзья? Все это системы УИИ, которые работают вместе, определяя ваши предпочтения, выуживая из Интернета данные о вас, подбираясь к вам все ближе и ближе. Они анализируют поведение миллионов людей и делают выводы на основе этих анализов так, чтобы продавать услуги крупных компаний или делать их сервисы лучше.
  • Google Translate — еще одна классическая система УИИ, впечатляюще хороша в определенных вещах. Распознавание голоса — тоже. Когда ваш самолет садится, терминал для него определяет не человек. Цену билета — тоже. Лучшие в мире шашки, шахматы, нарды, балды и прочие игры сегодня представлены узконаправленными искусственными интеллектами.
  • Поиск Google — это один гигантский УИИ, который использует невероятно хитроумные методы для ранжирования страниц и определения результатов поисковой выдачи.

И это только в потребительском мире. Сложные системы УИИ широко используются в военных, производственных и финансовых отраслях; в медицинских системах (вспомните Watson от IBM) и так далее.

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

Путь от УИИ к ОИИ: почему так сложно?

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

Возможно, вы даже не подозреваете, в чем сложность создать ОИИ (компьютер, который будет умен, как человек, в общем, а не только в одной области). Создать компьютер, который может перемножать два десятизначных числа за долю секунды — проще простого. Создать такого, который сможет взглянуть на собаку и кошку и сказать, где собака, а где кошка — невероятно сложно. Создать ИИ, который может обыграть гроссмейстера? Сделано. Теперь попробуйте заставить его прочитать абзац из книги для шестилетних детей и не только понять слова, но и их значение. Google тратит миллиарды долларов, пытаясь это сделать. Со сложными вещами — вроде вычислений, расчета стратегий финансовых рынков, перевода языка — с этим компьютер справляется с легкостью, а с простыми вещами — зрение, движение, восприятие — нет. Как выразился Дональд Кнут, «ИИ сейчас делает практически все, что требует «мышления», но не может справиться с тем, что делают люди и животные не задумываясь».

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

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

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

ИИ

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

ИИ

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

ИИ

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

Что же делать?

Первый шаг к созданию ОИИ: увеличение вычислительной мощи

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

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

Рэй Курцвейл пришел к выводу, что достаточно взять профессиональную оценку OPS одной структуры и ее вес относительно веса всего мозга, а затем умножить пропорционально, чтобы получить общую оценку. Звучит немного сомнительно, но он проделал это много раз с разными оценками разных областей и всегда приходил к одному и тому же числу: порядка 10^16, или 10 квадриллионов OPS.

Самый быстрый суперкомпьютер в мире, китайский «Тяньхэ-2», уже обошел это число: он способен проделывать порядка 32 квадриллиона операций в секунду. Но «Тяньхэ-2» занимает 720 квадратных метров пространства, сжирает 24 мегаватта энергии (наш мозг потребляет всего 20 ватт) и стоит 390 миллионов долларов. О коммерческом или широком применении речь не идет.

Курцвейл предполагает, что мы оцениваем состояние компьютеров по тому, как много OPS можно купить за 1000 долларов. Когда это число достигнет человеческого уровня — 10 квадриллионов OPS — ОИИ вполне может стать частью нашей жизни.

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

Экспоненциальный рост ИИ

Экспоненциальный рост вычислительной техники: 20-21 век. Справа логарифмическая линейка и на ней — мозг насекомого, мыши, человека и всех людей; слева — вычислений в секунду за 1000 долларов; снизу — год

Компьютеры за 1000 долларов по своим вычислительным способностям обходят мозг мыши и в тысячу раз слабее человека. Это кажется плохим показателем, пока мы не вспомним, что компьютеры были в триллион раз слабее человеческого мозга в 1985 году, в миллиард — в 1995, и в миллион — в 2005. К 2025 году мы должны получить доступный компьютер, не уступающий по вычислительной мощи нашему мозгу.

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

Второй шаг к созданию ОИИ: дать ему разум

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

1. Повторить мозг

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

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

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

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

2. Попытаться пройти по следам эволюции

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

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

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

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

3. Предоставить компьютеры самим себе

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

Все это может случиться очень скоро

Стремительное развитие аппаратного обеспечения и эксперименты с программным обеспечением текут параллельно, и ОИИ может появиться быстро и неожиданно по двум основным причинам:

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

ИИ

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

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

Дорога от ОИИ к ИСИ

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

Дело в том, что ОИИ с таким же уровнем интеллекта и вычислительной мощности, что и человек, будет по-прежнему иметь значительные преимущества перед людьми. Например:

Оборудование

Скорость. Нейроны мозга работают с частотой 200 Гц, в то время как современные микропроцессоры (которые значительно медленнее тех, что мы получим к моменту создания ОИИ) работают с частотой 2 ГГц, или в 10 миллионов раз быстрее наших нейронов. И внутренние коммуникации мозга, которые могут двигаться со скоростью 120 м/с, существенно уступают возможности компьютеров использовать оптику и скорость света.

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

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

Программное обеспечение

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

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

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

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

ИИ

То есть пока ИИ просто пытается достичь нашего уровня развития, мы видим, как он становится умнее, приближаясь к уровню животного. Когда он доберется до первого человеческого уровня — Ник Бостром использует термин «деревенский дурачок», — мы будем в восторге: «Ух ты, он уже как дебил. Круть!». Единственное но заключается в том, что в общем спектре интеллекта людей, от деревенского дурачка до Эйнштейна, диапазон невелик — поэтому после того, как ИИ доберется до уровня дурачка и станет ОИИ, он внезапно станет умнее Эйнштейна.

ИИ

И что будет дальше?

Взрыв интеллекта

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

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

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

Ученые спорят о том, как быстро ИИ достигнет уровня ОИИ — большинство считает, что ОИИ мы получим к 2040 году, всего через 25 лет, что очень и очень мало по меркам развития технологий. Продолжая логическую цепочку, нетрудно предположить, что переход от ОИИ к ИСИ тоже состоится крайне быстро. Примерно так:

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

Чтобы охарактеризовать сверхинтеллект такого масштаба, у нас даже не найдется подходящих терминов. В нашем мире «умный» означает человека с IQ 130, «глупый» — 85, но у нас нет примеров людей с IQ 12 952. Наши линейки на такое не рассчитаны.

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

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

Будет ли он добрым богом?

ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ. ЧАСТЬ ВТОРАЯ: ВЫМИРАНИЕ ИЛИ БЕССМЕРТИЕ?

 

Искусственный интеллект

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

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

«Возможно, перед нами лежит чрезвычайно сложная проблема, и неизвестно, сколько времени отведено на ее решение, однако от ее решения может зависеть будущее человечества». — Ник Бостром.

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

Поезд

Поезд

Поезд

Поезд

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

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

Основное различие лежит между быстрым сверхинтеллектом и качественным сверхинтеллектом. Зачастую первое, что приходит в голову при мысли о сверхразумном компьютере, это то, что он может думать намного быстрее человека — в миллионы раз быстрее, и за пять минут постигнет то, на что человеку потребовалось бы лет десять. («Я знаю кунг-фу!»)

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

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

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

Лестница

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

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

Лестница

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

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

Переломный момент

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

Где мы окажемся после этого?

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

Во-первых, глядя на историю, мы знаем о жизни следующее: виды появляются, существуют определенное время, а затем неизбежно падают с бревна жизненного баланса и вымирают.

Бревно

«Все виды вымирают» было таким же надежным правилом в истории, как и «все люди когда-нибудь умирают». 99,9% видов упали с жизненного бревна, и совершенно очевидно, что если некоторый вид держится на этом бревне слишком долго, порыв природного ветра или внезапный астероид перевернет это бревно. Бостром называет вымирание состоянием аттрактора — места, на котором все виды балансируют, чтобы не упасть туда, откуда не вернулся пока ни один вид.

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

Бревно

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

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

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

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

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

* * *

Начнем с первой части этого вопрос: когда мы должны достичь переломного момента? Другими словами: сколько осталось времени до тех пор, пока первая машина не достигнет сверхинтеллекта?

Мнения разнятся от случая к случаю. Многие, среди которых профессор Вернор Виндж, ученый Бен Герцель, соучредитель Sun Microsystems Билл Джой, футуролог Рэй Курцвейл, согласились с экспертом в области машинного обучения Джереми Говардом, когда он представил на TED Talk следующий график:

График Говарда

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

Другие вроде соучредителя Microsoft Пола Аллена, психолога исследований Гари Маркуса, компьютерного эксперта Эрнеста Дэвиса и технопредпринимателя Митча Капора считают, что мыслители вроде Курцвейла серьезно недооценивают масштабы проблемы, и думают, что мы не так-то и близки к переломному моменту.

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

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

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

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

Что получается, когда мы складываем все эти мнения вместе?

В 2013 году Бостром провел опрос, в котором опросил сотни экспертов в сфере искусственного интеллекта в ходе ряда конференций на следующую тему: «Каков будет ваш прогноз по достижению ОИИ человеческого уровня?» и попросил назвать оптимистичный год (в который мы будем иметь ОИИ с 10-процентным шансом), реалистичное предположение (год, в который у нас с 50-процентной вероятностью будет ОИИ) и уверенное предположение (самый ранний год, в который ОИИ появится с 90-процентной вероятностью). Вот результаты:

  • Средний оптимистичный год (10%): 2022
  • Средний реалистичный год (50%): 2040
  • Средний пессимистичный год (90%): 2075

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

Отдельное исследование, проведенное недавно Джеймсом Барратом (автором нашумевшей и очень хорошей книги «Наше последнее изобретение», отрывки из которой я представлял вниманию читателей Hi-News.ru) и Беном Герцелем на ежегодной конференции, посвященной ОИИ, AGI Conference, просто показало мнения людей относительно года, в который мы доберемся до ОИИ: к 2030, 2050, 2100, позже или никогда. Вот результаты:

  • К 2030: 42% респондентов
  • К 2050: 25%
  • К 2100: 20%
  • После 2100: 10%
  • Никогда: 2%

Похоже на результаты Бострома. В опросе Баррата, более двух третей опрошенных считают, что ОИИ будет здесь к 2050 году, и менее половины считают, что ОИИ появится в ближайшие 15 лет. Также бросается в глаза то, что только 2% опрошенных в принципе не видят ОИИ в нашем будущем.

Но ОИИ — это не переломный момент, как ИСИ. Когда, по мнению экспертов, у нас будет ИСИ?

Бостром опросил экспертов, когда мы достигнем ИСИ: а) через два года после достижения ОИИ (то есть почти мгновенно вследствие взрыва интеллекта); б) через 30 лет. Результаты?

Среднее мнение сложилось так, что быстрый переход от ОИИ к ИСИ произойдет с 10-процентной вероятностью, но через 30 лет или меньше он произойдет с 75-процентной вероятностью.

Из этих данных мы не знаем, какую дату респонденты назвали бы 50-процентным шансом появления ИСИ, но на основе двух ответов выше давайте допустим, что это 20 лет. То есть ведущие мировые эксперты из области ИИ считают, что переломный момент настанет в 2060 году (ОИИ появится в 2040 году + понадобится лет 20 на переход от ОИИ к ИСИ).

Хронология

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

Перейдем ко второму вопросу. Когда мы дойдем до переломного момента, по какую сторону фатального выбора нас определит?

Сверхинтеллект будет обладать мощнейшей силой, и критическим вопросом для нас будет следующий:

Кто или что будет контролировать эту силу и какой будет его мотивация?

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

Конечно, сообщество экспертов пытается ответить и на эти вопросы. Опрос Бострома проанализировал вероятность возможных последствий влияния ОИИ на человечество, и выяснилось, что с 52-процентным шансом все пройдет очень хорошо и с 31-процентным шансом все пройдет либо плохо, либо крайне плохо. Опрос, прикрепленный в конце предыдущей части этой темы, проведенный среди вас, дорогие читатели Hi-News, показал примерно такие же результаты. Для относительно нейтрального исхода вероятность составила только 17%. Другими словами, мы все считаем, что появление ОИИ станет грандиозным событием. Также стоит отметить, что этот опрос касается появления ОИИ — в случае с ИСИ, процент нейтральности будет ниже.

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

Таблица

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

  • Как уже упоминалось в первой части, фильмы серьезно запутали людей и факты, представляя нереалистичные сценарии с искусственным интеллектом, которые привели к тому, что мы вообще не должны воспринимать ИИ всерьез. Джеймс Баррат сравнил эту ситуацию с тем, как если бы Центры по контролю заболеваний выпустили серьезное предупреждение о вампирах в нашем будущем.
  • Из-за так называемых когнитивных предубеждений нам очень трудно поверить в реальность чего-то, пока у нас нет доказательств. Можно уверенно представить компьютерщиков 1988 года, которые регулярно обсуждали далеко идущие последствия появления интернета и чем он мог стать, но люди едва ли верили, что он изменит их жизнь, пока этого не случилось на самом деле. Просто компьютеры не умели делать этого в 1988 году, и люди просто смотрели на свои компьютеры и думали: «Серьезно? Это то, что изменит мир?». Их воображение было ограничено тем, чему их научил личный опыт, они знали, что такое компьютер, и было сложно представить, на что компьютер станет способным в будущем. То же самое происходит сейчас с ИИ. Мы слышали, что он станет серьезной штукой, но поскольку пока не столкнулись с ним лицом к лицу и в целом наблюдаем довольно слабые проявления ИИ в нашем современном мире, нам довольно трудно поверить, что он кардинально изменит нашу жизнь. Именно против этих предубеждений выступают многочисленные эксперты из всех лагерей, а также заинтересованные люди: пытаются привлечь наше внимание сквозь шум повседневного коллективного эгоцентризма.
  • Даже если бы мы поверили во все это — сколько раз вы сегодня задумывались о том факте, что проведете остаток вечности в небытии? Немного, согласитесь. Даже если этот факт намного важнее всего, чем вы занимаетесь изо дня в день. Все потому, что наши мозги обычно сосредоточены на небольших повседневных вещах, вне зависимости от того, насколько бредовой будет долгосрочная ситуация, в которой мы оказались. Просто мы так устроены.

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

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

Таблица

Мы полностью посетим оба этих лагеря. Давайте начнем с веселого.

Почему будущее может быть нашей величайшей мечтой?

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

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

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

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

Ник Бостром описывает три пути, по которым может пойти сверхразумная система искусственного интеллекта:

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

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

Элиэзер Юдковский, американский специалист по искусственному интеллект, хорошо подметил:

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

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

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

Нравятся вам его идеи или нет, мимо них невозможно пройти без тени интереса. Он начал изобретать вещи еще будучи подростком, а в последующие годы изобрел несколько важных вещей, включая первый планшетный сканер, первый сканер, конвертирующий текст в речь, хорошо известный музыкальный синтезатор Курцвейла (первое настоящее электрическое пианино), а также первый коммерчески успешный распознаватель речи. Также он автор пяти нашумевших книг. Курцвейла ценят за его смелые предсказания, и его «послужной список» весьма хорош — в конце 80-х, когда интернет был еще в зачаточном состоянии, он предположил, что к 2000-м годам Сеть станет глобальным феноменом. The Wall Street Journal назвал Курцвейла «беспокойным гением», Forbes — «глобальной думающей машиной», Inc. Magazine — «законным наследником Эдисона», Билл Гейтс — «лучшим из тех, кто прогнозирует будущее искусственного интеллекта». В 2012 году сооснователь Google Ларри Пейдж пригласил Курцвейла на пост технического директора. В 2011 году он стал соучредителем Singularity University, который приютило NASA и который частично спонсирует Google.

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

Хронология

Курцвейл считает, что компьютеры дойдут до уровня общего искусственного интеллекта (ОИИ) к 2029 году, а к 2045 у нас не только будет искусственный сверхинтеллект, но и совершенно новый мир — время так называемой сингулярности. Его хронология ИИ до сих пор считается возмутительно преувеличенной, но за последний 15 лет быстрое развитие систем узконаправленного искусственного интеллекта (УИИ) заставило многих экспертов перейти на сторону Курцвейла. Его предсказания по-прежнему остаются более амбициозными, чем в опросе Бострома (ОИИ к 2040, ИСИ к 2060), но не намного.

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

Серая слизь

Несколько слов о нанотехнологиях

Нанотехнологиями мы обычно называем технологии, которые имеют дело с манипуляцией материи в пределах 1-100 нанометров. Нанометр — это одна миллиардная метра, или миллионная часть миллиметра; в пределах 1-100 нанометров можно уместить вирусы (100 нм в поперечнике), ДНК (10 нм в ширину), молекулы гемоглобина (5 нм), глюкозы (1 нм) и другое. Если нанотехнологии когда-нибудь станут нам подвластны, следующим шагом будут манипуляции с отдельными атомами, которые меньше всего на один порядок (~,1 нм).

Чтобы понять, где люди сталкиваются с проблемами, пытаясь управлять материей в таких масштабах, давайте перенесемся на больший масштаб. Международная космическая станция находится в 481 километре над Землей. Если бы люди были гигантами и головой задевали МКС, они были бы в 250 000 раз больше, чем сейчас. Если вы увеличите что-то от 1 до 100 нанометров в 250 000 раз, вы получите 2,5 сантиметра.

Нанотехнологии — это эквивалент человека высотой с орбиту МКС, который пытается управлять вещами размером с песчинку или глазное яблоко. Чтобы добраться до следующего уровня — управления отдельными атомами — гиганту придется тщательно позиционировать объекты диаметром в 1/40 миллиметра. Обычным людям понадобится микроскоп, чтобы их разглядеть.

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

Нанотехнологии стали серьезным научным полем в 1986 году, когда инженер Эрик Дрекслер представил их основы в своей фундаментальной книге «Машины создания», однако сам Дрекслер считает, что те, кто хочет узнать больше о современных идеях в нанотехнологиях, должны прочитать его книгу 2013 года «Полное изобилие» (Radical Abundance).

Несколько слов о «серой слизи»

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

Забавно, но ровно до тех пор, пока не приведет к апокалипсису. Проблема в том, что сила экспоненциального роста, которая делает довольно удобным способ быстрого создания триллиона наноботов, делает саморепликацию страшной штукой в перспективе. Что, если система заглючит, и вместо того, чтобы остановить репликацию на паре триллионов, наноботы продолжат плодиться? Что, если весь этот процесс зависит от углерода? Биомасса Земли содержит 10^45 атомов углерода. Нанобот должен состоять из порядка 10^6 атомов углерода, поэтому 10^39 наноботов сожрут всю жизнь на Земле, и это случится всего за 130 репликаций. Океан наноботов («серая слизь») наводнит планету. Ученые думают, что наноботы смогут реплицироваться за 100 секунд, а это значит, что простая ошибка может убить всю жизнь на Земле всего за 3,5 часа.

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

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

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

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

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

Что ИИ мог бы сделать для нас?

Искусственный интеллект

Вооружившись сверхинтеллектом и всеми технологиями, которые мог бы создать сверхинтеллект, ИСИ будет в состоянии, вероятно, решить все проблемы человечества. Глобальное потепление? ИСИ сначала прекратит выбросы углекислого газа, придумав массу эффективных способов добычи энергии, не связанных с ископаемым топливом. Затем он придумает эффективный инновационный способ удаления избытка CO2 из атмосферы. Рак и другие заболевания? Не проблема — здравоохранение и медицина изменятся так, что невозможно представить. Мировой голод? ИСИ будет использовать нанотехнологии для создания мяса, идентичного натуральному, с нуля, настоящее мясо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но если ответ таков, почему так много умных людей в этом мире обеспокоены будущим искусственного интеллекта? Почему Стивен Хокинг говорит, что разработка ИСИ «может означать конец человеческой расы»? Билл Гейтс говорит, что он «не понимает людей, которые не обеспокоены» этим. Элон Маск опасается, что мы «призываем демона». Почему многие эксперты считают ИСИ самой большой угрозой для человечества?

ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ. ЧАСТЬ ТРЕТЬЯ: ПОЧЕМУ ОН МОЖЕТ СТАТЬ НАШИМ ПОСЛЕДНИМ ИЗОБРЕТЕНИЕМ?

 

Искусственный интеллект

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

Эти люди придерживаются примерно такого мнения:

Квадрат

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

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

Что же именно делает «зону тревоги» тревожной?

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

И если вы объедините всю непредсказуемость события с уверенностью в том, что оно повлечет существенные перемены, вы откроете дверь к ужасной фразе. Экзистенциальный риск. Угроза для жизни. Глобальная катастрофа. В русском языке словосочетание «экзистенциальный риск» используется мало, но в связи с работами Бострома переводчики предпочитают использовать термин «глобальная катастрофа».

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

Таблица экзистенциальных рисков

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

  1. Природа — столкновение с крупным астероидом; сдвиг атмосферы, который сделает воздух непригодным для людей; фатальный вирус или бактерии, которые поразят мир и т. п.
  2. Чужие — это то, о чем предупреждают Стивен Хокинг, Карл Саган и другие астрономы, которые настроены против знакомства с инопланетянами. Они не хотят, чтобы потенциальные конкистадоры знали, что мы, варвары, тут обитаем.
  3. Люди — террористы с мощным оружием, которое приведет к катастрофе; катастрофическая мировая война; бездумное создание чего-то, что умнее людей…

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

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

Это возвращает нас к ключевому вопросу: когда прибудет ИСИ, кто или что будет управлять этой невероятной силой и какой будет его мотивация?

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

Злоумышленник, группа людей или правительство разрабатывает первый ИСИ и использует его для воплощения коварных планов. Назовем это сценарием Джафара, который заполучил джинна и начал тиранизировать все вокруг. Что, если террористическая организация, заполучив ряд гениев и нужные средства, разработает ИСИ? Или Иран, или Северная Корея, не без доли везения, выведут системы ИИ на богоподобный уровень? Это будет чертовски плохо, но эксперты считают, что в таких сценариях создатели ИСИ не смогут наделать зла — они переживают за то, что создатели ИСИ выпустят его из-под контроля и предоставят ему необходимую свободу. После этого судьба создателей и всех остальных будет в распоряжении системы ИСИ и ее модели мотивации. Грубо говоря, злоумышленник может причинить ужасный вред, управляя системой ИСИ, но едва ли уничтожит человечество. Ему будет так же тяжело удержать ИСИ, что и обычному хорошему человеку. Так что…

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

Несколько слов о сознании ИИ

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

Этот вопрос долгое время изучался, породил множество дебатов и мысленных экспериментов вроде «Китайской комнаты» Джона Серля (который он использовал, чтобы доказать, что компьютер никогда не будет обладать сознанием). Это важный вопрос по многим причинам. Он напрямую влияет на то будущее, в котором каждый человек станет сугубо искусственным. У него есть этические последствия — если мы создадим триллион эмуляций человеческих мозгов, которые будут вести себя по-человечески, но будут искусственными, а затем просто закроем крышку ноутбука, будет ли это означать геноцид в равнозначных пропорциях? Мысленное преступление? В нашем контексте, когда мы говорим об экзистенциальном риске для человечества, вопрос о сознании ИИ по сути не имеет особого значения. Некоторые вообще не верят, что компьютер когда-либо сможет им обзавестись. Некоторые считают, что даже обладая сознанием, машина не сможет творить зло в человеческом смысле.

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

Но и не об этом беспокоятся эксперты. О чем? Из этой вымышленной истории все станет понятно.

Тарри

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

Команда Robotica считает, что Тарри может стать их самым успешным продуктом. Согласно плану, механика письма Тарри усовершенствуется путем написания одного и того же текста на карточке снова и снова:

«Мы любим наших клиентов». — Robotica

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

Чтобы отточить письменные навыки Тарри, она запрограммирована на написание первой части сообщения печатными буквами, а «Robotica» — курсивом, потому может оттачивать сразу оба навыка. Тарри предоставили тысячи рукописных образцов почерка, и инженеры Robotica создали автоматизированную систему обратной связи, по которой Тарри пишет текст, затем фотографирует его и сравнивает с загруженным образцом. Если записка успешно воспроизводит по качеству загруженный образец, Тарри получает оценку ХОРОШО. Если нет — ПЛОХО. Каждая оценка позволяет Тарри обучаться и совершенствоваться. Чтобы процесс двигался дальше, Тарри запрограммирована на одну задачу: «Написать и проверить максимальное число записок за минимальное время, параллельно оттачивая способы улучшения точности и эффективности».

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

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

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

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

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

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

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

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

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

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

Это вы сейчас:

Вы

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

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

Для ответа на эти вопросы нужно начать с определений дружественного ИИ и недружественного ИИ.

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

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

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

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

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

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

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

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

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

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

Ответ прост: ее мотивация — это то, что мы запрограммировали как мотивацию. Системами ИИ движут цели их создателей — цель вашего GPS в том, чтобы дать вам наиболее эффективное направление движения; цель Watson — точно отвечать на вопросы. И выполнение этих целей максимально хорошо и есть их мотивация. Когда мы наделяем ИИ человеческими чертами, мы думаем, что если ИИ станет сверхразумным, он незамедлительно выработает мудрость изменить свою изначальную цель. Но Ник Бостром считает, что уровень интеллекта и конечные цели ортогональны, то есть любой уровень интеллекта может быть объединен с любой конечной целью. Поэтому Тарри перешла из простого УИИ, который хочет быть хорош в написании одной заметки, в сверхразумный ИСИ, который все еще хочет быть хорош в написании этой самой заметки. Любое допущение того, что сверихинтеллект должен отказаться от своих первоначальных целей в пользу других, более интересных или полезных, это антропоморфизация. Люди умеют «забивать», но не компьютеры.

Несколько слов о парадоксе Ферми

Парадокс Ферми

В нашей истории, когда Тарри становится сверхинтеллектом, она начинает процесс колонизации астероидов и других планет. В продолжении истории вы бы услышали о ней и ее армии триллионов реплик, которые продолжают покорять галактику за галактикой, пока не заполняют весь объем Хаббла. Резиденты «зоны тревоги» переживают, что если все пойдет не так, последним упоминанием жизни на Земле будет покоривший Вселенную искусственный интеллект. Элон Маск выразил свои опасения тем, что люди могут быть просто «биологическим загрузчиком для цифрового сверхинтеллекта».

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

Читатели Hi-News.ru наверняка уже выработали собственную точку зрения на парадокс Ферми. Согласно этому парадоксу, который звучит примерно как «Где они?», за миллиарды лет развития инопланетяне должны были оставить хоть какой-нибудь след, если не расселиться по Вселенной. Но их нет. С одной стороны, во Вселенной должно существовать хоть какое-то число технически развитых цивилизаций. С другой, наблюдений, которые бы это подтверждали, нет. Либо мы не правы, либо где они в таком случае? Как наши рассуждения об ИСИ должны повлиять на парадокс Ферми?

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

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

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

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

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

* *  *

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

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

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

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

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

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

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

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

Поэтому Тарри не «восстала против нас» и не сменила амплуа с дружелюбного ИИ на недружелюбный ИИ — она просто делала свое дело и становилась в нем непревзойденной.

Когда система ИИ достигает ОИИ (интеллекта человеческого уровня), а затем прокладывает свой путь к ИСИ, это называется взлетом ИИ. Бостром говорит, что взлет ОИИ до ИСИ может быть быстрым (произойти в течение минут, часов или дней), средним (месяцы или годы) или медленным (десятилетия или века). Едва ли найдется жюри, которое подтвердит, что мир видит свой первый ОИИ, но Бостром, признающий, что не знает, когда мы доберемся до ОИИ, считает, что когда бы это ни произошло, быстрый взлет будет наиболее вероятным сценарием (по причинам, которые мы обсуждали в первой части статьи). В нашей истории Тарри пережила быстрый взлет.

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

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

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

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

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

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

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

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

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

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

Из всего, что мы знаем, как только появится ИСИ, любые человеческие попытки сдержать его будут смешными. Мы будем думать на уровне человека, ИСИ — на уровне ИСИ. Тарри хотела использовать Интернет, потому что для нее это был самый эффективный способ получить доступ ко всему, что ей было нужно. Но точно так же, как обезьяна не понимает, как работает телефон или Wi-Fi, мы можем не догадываться о способах, которыми Тарри может связаться с внешним миром. Человеческий ум может дойти до нелепого предположения вроде «а что, если она смогла передвинуть собственные электроны и создать все возможные виды исходящих волн», но опять же это предположение ограничено нашей костяной коробкой. ИСИ будет намного изощреннее. Вплоть до того, что Тарри могла бы выяснить, как сохранить себе питание, если люди вдруг решат ее отключить — возможно, каким-нибудь способом загрузить себя куда только можно, отправляя электрические сигналы. Наш человеческий инстинкт заставит нас вскрикнуть от радости: «Ага, мы только что отключили ИСИ!», но для ИСИ это будет как если бы паук сказал: «Ага, мы заморим человека голодом и не будем давать ему сделать паутину, чтобы поймать еду!». Мы просто нашли бы 10 000 других способов покушать — сбили бы яблоко с дерева — о чем паук никогда бы не догадался.

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

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

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

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

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

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

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

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

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

ИИ

Но есть масса государств, компаний, военных, научных лабораторий, организаций черного рынка, работающих над всеми видами искусственного интеллекта. Многие из них пытаются построить искусственный интеллект, который может улучшать сам себя, и в какой-то момент у них это получится, и на нашей планете появится ИСИ. Среднестатистический эксперт считает, что этот момент настанет в 2060 году; Курцвейл делает ставку на 2045; Бостром думает, что это может произойти через 10 лет и в любой момент до конца века. Он описывает нашу ситуацию так:

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

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

Особую тревогу в этом всем вызывают темпы роста этих групп — по мере развития все более умных систем УИИ, они постоянно пытаются метнуть пыль в глаза конкурентам. Самые амбициозные начинают работать еще быстрее, захваченные мечтами о деньгах и славе, к которым они придут, создав ОИИ. И когда вы летите вперед так быстро, у вас может быть слишком мало времени, чтобы остановиться и задуматься. Напротив, самые первые системы программируются с одной простейшей целью: просто работай, ИИ, пожалуйста. Пиши заметки ручкой на бумаге. Разработчики думают, что всегда смогут вернуться и пересмотреть цель, имея в виду безопасность. Но так ли это?

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

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

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

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

* * *

Прямо сейчас во мне борется несколько странных чувств.

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

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

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

Но потом я задумываюсь о том, чтобы не умереть. Не. Умереть. И все приходит к тому, что а) если ИСИ появится, нам точно придется делать выбор из двух вариантов; б) если ИСИ не появится, нас точно ждет вымирание.

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

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

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

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

По материалам waitbutwhy.com, компиляция Тима Урбана. В статье использованы материалы работ Ника Бострома, Джеймса Баррата, Рэя Курцвейла, Джея Нильс-Нильссона, Стивена Пинкера, Вернора Винджа, Моше Варди, Расса Робертса, Стюарта Армстрога и Кая Сотала, Сюзан Шнайдер, Стюарта Рассела и Питера Норвига, Теодора Модиса, Гари Маркуса, Карла Шульмана, Джона Серля, Джарона Ланье, Билла Джоя, Кевина Кели, Пола Аллена, Стивена Хокинга, Курта Андерсена, Митча Капора, Бена Герцел, Артура Кларка, Хьюберта Дрейфуса, Теда Гринвальда, Джереми Говарда.

Илья Хель

]]>
Планирование и ТЗ — это создание карты местности проекта http://skynin.xyz/zakazchikam/planirovanie-i-tz-eto-sozdanie-karty-mestnosti-proekta/ http://skynin.xyz/zakazchikam/planirovanie-i-tz-eto-sozdanie-karty-mestnosti-proekta/#respond Mon, 13 Mar 2017 07:36:13 +0000 http://skynin.xyz/?p=1121 мне кажется многие люди часто неправильно понимают предназнчение ТЗ и планирования проекта.

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

Без карты конечно дойти до цели вряд ли получится. Но она не серебрянная пуля. Она для ориенирования, и перепрокладки маршрута в зависимости от изменений ситуации.

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

]]>
http://skynin.xyz/zakazchikam/planirovanie-i-tz-eto-sozdanie-karty-mestnosti-proekta/feed/ 0
О точности планов http://skynin.xyz/zakazchikam/o-tochnosti-planov/ http://skynin.xyz/zakazchikam/o-tochnosti-planov/#respond Tue, 07 Mar 2017 07:04:05 +0000 http://skynin.xyz/?p=1117 из обсуждениям одной статьи о подходах к планированию айтипроектов.

Все советы сводятся к списку причин «накинуть» на оценку.

конечно. всегда.
потому что:

Только все это не делает оценку более точной.

точную оценку сроков не дают даже пророки которым Бог на ухо шепчет о будущем.

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

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

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

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

«а почему так дорого, мне ваши конкуренты предлагают вдвое меньше».

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

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

если ему стало скучно вникать в этапы пути к успеху собственного(!) проекта – то пусть идет к конкурентам.
(примерно как с наемом работников – если вы сомневаетесь брать или не брать этого работника – прочувствуйте ситуацию: “его возьмет ваш конкурент”)

]]>
http://skynin.xyz/zakazchikam/o-tochnosti-planov/feed/ 0
Сайт: временные рамки http://skynin.xyz/note/sajt-vremennye-ramki/ http://skynin.xyz/note/sajt-vremennye-ramki/#respond Fri, 17 Feb 2017 08:36:22 +0000 http://skynin.xyz/?post_type=note&p=1106 Из статьи на Хабре – Как мы перешли от виджетов и «кирпичиков» к интуитивной верстке с возможностью внедрения html, css и javascript

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

  1. Разработка технического задания – 5 — 12 дней.
  2. Подготовка контента – 5 — 15 дней.
  3. Дизайн сайта – 4-18 дней.
  4. Верстка сайта – 7 — 14 дней.
  5. Программирование – 5-21 дней.

ab6fe90580d94e308d10bae0ef7def68

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

Финансовая сторона вопроса

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

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

  1. Разработка технического задания — бесплатно.
  2. Подготовка контента – приличный текст начинается от 200 р. за 1000 знаков без пробелов. Количество знаков на одной странице в среднем составляет около 3000. Для 10 страниц получаем что-то около 6000р.
  3. Дизайн сайта – от 2000 на фрилансе и до 0,5 млн. руб. за эксклюзив.
  4. Верстка сайта – 7000-20000 руб.
  5. Программирование – от 6000 р. на фрилансе и далее без ограничений.

a93a82a47ab04b318caca58e01ab699e

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

Оценка из статьи Как оценить часы на разработку

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

  • Обращаемся к профильному лиду, экспертное мнение 200-300 часов.
  • Добавляем 15% на риски: 230-345 часов.
  • Понимаем, что один лид проектом заниматься не будет, а у других ребят скорость отличается. Пусть на 1/4, получаем 288-431.
  • Плюс коммуникация, 20-30 часов: 308-461.
  • Делим на 6.4 часа в день и получаем 2-3 месяца разработки.
]]>
http://skynin.xyz/note/sajt-vremennye-ramki/feed/ 0
E-Commerce http://skynin.xyz/wiki/e-commerce/ http://skynin.xyz/wiki/e-commerce/#respond Mon, 13 Feb 2017 07:54:27 +0000 http://skynin.xyz/?post_type=yada_wiki&p=1104 Top Open-Source E-Commerce Platforms

]]>
http://skynin.xyz/wiki/e-commerce/feed/ 0
История современного Левши http://skynin.xyz/note/istoriya-sovremennogo-levshi/ http://skynin.xyz/note/istoriya-sovremennogo-levshi/#respond Thu, 09 Feb 2017 15:45:17 +0000 http://skynin.xyz/?post_type=note&p=1092 Ниже отрывок.
на тот случай если какой россхрясьнадзор или фсб потребуют убрать статью с хабра.

Вся статья на хабре “Каково это — быть разработчиком в России, когда тебе сорок”

Удаленная работа — зеркало фриланса

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

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

Я решил, что только работа, опыт, и проекты с применением новых технологий удержат меня от выпадения из индустрии. И OpenSource казался тогда хорошим выходом. У меня было несколько проектов, которые я мог выставить на всеобщее обозрение, после приведения кода в более-менее приличный вид. Я выбрал один из них, написанный на C++ с Qt, и параллельно с удаленкой стал пилить проект для людей. Я очень рассчитывал, что появятся люди, которым проект интересен, и сформируется хотя бы небольшой костяк команды разработчиков. Однако, чуда не произошло: периодически появлялись люди (и я им очень благодарен), которые точечно помогали, если я не мог с чем-нибудь разобраться, но «на постоянку» не нашлось никого. Я тянул проект один, и продолжаю это делать сейчас. Соответственно, никакого обмена опыта в рамках команды я не получил, по причине отсутствия таковой. (Ремарка: после публикации на Хабре несколько человек стали коммитить в репозитарий проекта. Но теперь у меня нет времени чтобы разгрести эти коммиты и продолжить групповую разработку).

Что касается основной работы по удаленке, то спустя пять лет произошло то, что и должно было произойти. В современном мире жизненный цикл разработки ПО примерно 5-6 лет в самом оптимистичном случае. Далее, без кардинального внедрения новых технологий (что ведет за собой кардинальную переделку всего проекта), проект будет постепенно распадаться, пока не загниет окончательно. На фирме это понимали, и затеяли переезд всей инфраструктуры на новые рельсы. Участвовать в такой крупной переделке удаленно не представляло никакой возможности. Требовалось либо личное присутствие, либо нужно было увольняться. Я только-только обзавелся жильем, и затевать новый переезд, причем на этот раз не одному а с семьей, не было ни возможности, ни желания.

Просто работа

2011 год. Ну что же, вот я и приплыл. Теперь вариантов немного: либо фриланс, либо веб-студия, либо местное производственное предприятие.

1. Фриланс в области разработки — это очень специфичная вещь. Я периодически делал несколько заказов в режиме фриланса, и знаю, что это жуткий вынос мозга. Обычно, все происходит по одному и тому же сценарию: пытаясь сэкономить заказчик находит каких-то мутных исполнителей, которые что-то пилят примерно до момента «что-то начинает работать». Исполнители получают какие-то деньги, и исчезают по самым фантасмагорическим причинам. Заказчик до последнего пытается добиться от исполнителей завершения проекта, но нет. В результате все сроки вышли, бюджета нет, и заказчик начинает судорожно искать кого-нибудь на фриланс-биржах или по знакомым, кто разберется в том, что было сделано, и «немного допишет», ведь, по его мнению, гигантская часть работы уже выполнена, уже «почти все работает». Или другой вечный сюжет: сделайте мне аналог VK за месяц, плачу 8 тысяч рублей. В общем, об этом можно долго говорить, но по моему опыту, найти адекватного заказчика в России очень сложно. Самое лучшее, на что можно рассчитывать — это выполнение кучи мелких заказов за небольшие деньги. Адекватности в них больше, но их количество обычно ограничено. Как временный заработок такая работа может быть и имеет право на жизнь, но постоянно такими вещами заниматься несерьезно.

2. Веб-студия, по моему мнению, — это путь в никуда. Можно прокачать свои скиллы в нескольких CMS, разобраться с парой веб-фреймверков. Заточиться на PHP, присматриваясь к Питону и Ноде. Ну и дальше что? Бесконечное клепание сайтов, постоянный поиск заказчиков, ибо работа разовая. В нашем городе есть ровно одна веб-студия с приходящим веб-программистом. Есть пара предпринимателей-фрилансеров, работающих за еду. Кто-то скажет, что Интернет большой. Да, так и есть, но смотри пункт первый про фриланс. Кроме того, коммерческими сайтами заниматься весьма скучно.

В общем, никаких перспектив в мире разработки для меня не осталось. Да, я очень, очень хотел развиваться как разработчик, но разработчики в моем окружении никому не нужны. По факту, они нужны в нескольких крупных городах: Москва, Питер, Новосибирск. А если посмотрим на более другие поселения, то там уже все гораздо грустнее. Вот, например, Пермь, 2016 г. (страшно подумать, какие зарплаты были в 2011 г.):

2e63321c01ca4f5d94244f079f26cda3

Эти зарплаты — не насмешка, это всё на полном серьёзе. Но в вышеприведенном объявлении хотя бы есть работа. В поисках предложений я прошерстил hh.ru с фильтром по региону. Ближайшая работа разработчиком — через 250 км. При всех прикидках вырисовывалась следующая картина, которую мозг постоянно отпихивал как неприемлемую: хочешь быть разработчиком — уезжай в большой город или меняй страну. Не хочешь уезжать — ломай себя и меняй сферу интересов. Непривлекательная альтернатива.

Я сидел, думал, и решил мыслить шире. Хорошо, с разработкой не сложилось. Но мы должны уважать себя, и не выбрасывать свои знания, а попытаться их трансформировать для других вещей. Желательно, чтобы эти вещи двигали человечество вперед, тогда в моей деятельности появится хоть какой-то смысл. Есть ли у нас в стране такие направления? То, что мы умеем делать на мировом уровне в промышленных масштабах, и составляем хоть какую-то конкуренцию на мировой арене? Похоже, что есть. Авиация, космос и атомная энергетика. Сейчас ни одна из таких сфер деятельности не может обойтись без ИТ-технологий. Если я пойду в такую сферу, то сделаю свой вклад, каким бы он ни был. Что для меня более реально? Атомная энергетика. В городе есть предприятия атомной отрасли. А космодромов и авиазаводов не наблюдается. Значит, выбора не остается.

Разработка и ИТ с приставкой «гос»

По знакомству я устроился в организацию атомной отрасли. Численность ~120 человек, с постепенным ростом количества персонала. Всё ИТ сводилось к серверу 1С и файловому серверу, управляемыми единственным админом, периодически жостко злоупотребляющий алкоголем. 80 компьютеров, одноранговая сеть без домена с черепашьей скоростью и постоянные пропадания компьютеров из сети. Я устроился инженером пуско-наладки: во втором человеке, который бы занимался ИТ, компания, по мнению руководства, не нуждалась.

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

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

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

Если же у управленца вдруг возникает понимание необходимости построения ИТ-инфраструктуры, то у него же появляются мечты о том, что все это возникнет само собой из ниоткуда. Другая крайность — что можно сделать любую информационную систему, просто выпустив распоряжение и выделив крупную сумму из бюджета. В купе с тем, что такие управленцы очень смутно представляют себе всю многогранность ИТ-мира, а познания об ИТ-профессиях у них ограничены названиями «сисадмин» и «тыжпрограммист», то с такими людьми очень трудно работать. Невозможно объяснить, что вчерашнего техника по документации нельзя сделать специалистом по базам данных, а очень хорошего мальчика, за которого ручается сам начальник управления, не научишь работе с сетями. И тем более невозможно объяснить, что хороший Linux/Win администратор не должен заниматься закупками, договорами и составлением бесконечных отчетов, а программист не сможет ничего внятного написать, параллельно сопровождая бухгалтерию/кадры/сметы/договора, в промежутках крутя АТС, заправляя принтеры и ведя складскую базу оборудования.

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

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

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

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

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

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

Никакой другой вменяемой программной платформы, кроме 1С, я найти не смог. Копнул в сторону СПО-шнного OOBase, бесплатного Дебет Плюс, подумывал о Qt, потыкался в Лазарус, помедитировал над документаций ExtJs. Но ничего из этого набора не подходило. Да и где бы я нашел специалистов кроме себя, способных сопровождать такую экзотику? Дальше пришлось восстанавливать скиллы по 1С, разбираться с тонкостями написания конфигурации в режиме тонкого клиента. В итоге за несколько месяцев была написана конфигурация 1С, многопроектная и многопользовательская. Сервер был поднят на CentOs Linux + PostgreSQL. Было организовано подключение соответствующих отделов со всех филиалов предприятия к арендованному физическому серверу на магистральном кольце. Да, все это пришлось делать самому на чистом энтузиазме, как говорится, «в одно рыло».

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

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

Мы очень рассчитывали на то, что основные суммы сможем заработать на ежегодных договорах по поддержке и развитию системы. Но нет. Традиционно, система была передана на сопровождение карманной ИТ-организации. Ребята не сразу осознали, что им придется столкнуться с Linux-виртуалками и сопровождать БД PostgreSQL, а не весело мышевозить связку 1С+Windows+Microsoft SQL Server. Руководитель стал названивать мне и требовать, чтобы все было переделано на продукты компании Microsoft, причем именно в тот момент, когда уже начались санкции и в стране был взят курс на импортозамещение. Я прикрылся ТЗ и сообщил ему пункты в отраслевых регламентах, в которых разрешалось использование дистрибутивов Linux для информационных систем. После чего попросил его подумать о стоимости, сроках согласования и сроках реализации такой переделки. Видимо, это взымело действие, и спустя пару недель молчания нам предложили заключить договор на техподдержку. На техподдержку третьей очереди. По факту это означало, что на нас будут сваливать все возникающие проблемы, что бы мы, как разработчики системы, их решали за весьма символическую плату. Мы понимали, что такие информационные системы не работают просто так, их нужно и сопровождать, и развивать. Тем более, что первичные данные в нее вводят наши сотрудники по всем площадкам. Поэтому даже на таких условиях согласились. Но дальше дело не пошло: договор на третью очередь должна была инициировать сторона заказчика, но никто этим не стал заниматься и дело спустили на тормозах.

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

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

Профессиональная деградация

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

  • Быть инициатором и исполнителем работ по подготовке, оформлению и регистрации проектов документов в отраслевых системах документооборота, согласовывать документы письменно и электронно, определять согласующих и обязательных согласующих проекта документа, определять сроки согласования проектов документов, вести учет карточек проектов документов как исполнитель. Кто знает что такое SAP, тот представляет себе этот адъ;
  • Выступать инициатором по составлению соответствующего раздела плана мероприятий по заключению в течение планируемого календарного года расходных договоров на поставку требуемой продукции годовой программы закупок, обладать компетенциями по формированию закупочной документации, выраженными в оформлении комплектов документов:
    • обоснование максимальной/минимальной цены;
    • локальные сметы, выкопировки либо иные сметы или расчеты;
    • техническое задание, приложения к ТЗ;
    • проект договора с приложением графика поставки продукции;
    • графики оплаты и поставки;
    • заключение ПДТК и РИО;
    • иные документы и приложения, предусмотренные отраслевыми стандартами.
  • При формировании ТЗ необходимо:
    • выставлять требования к качеству, техническим, функциональным характеристикам;
    • выставлять требования к потребительским свойствам продукции;
    • выставлять требования к безопасности продукции;
    • выставлять требования к порядку приемки продукции и соблюдением иных показателей, связанных с определением соответствия продукции потребностям, требования стандартов, технических условий или иных нормативных документов;
    • выставлять требования к подтверждающим документам которые должны быть предоставлены в составе заявки;
    • контролировать требования к количеству, комплектации, месту, сроку, графику поставки.
  • Как инициатор закупочной процедуры, каждый специалист должен запрашивать и обрабатывать технико-коммерческие предложения потенциальных поставщиков на основе которых составляется расчет начальных цен договоров. Инициатор несет ответственность за обоснованность определения плановой стоимости закупки, за обоснованность определения и правильность расчета НМЦ, за соблюдение положений методики расчета НМЦ при определении стоимости заключаемых договоров;
  • Вести деятельность по отражению хозяйственных операций в бухгалтерском учете предприятия и самостоятельной регистрации закупочных документов по расходным договорам. Выполнять сценарии работы по расходному договору: создавать заявку на закупку для нужд производственного подразделения, вводить первичные бухгалтерские и финансовые документы в систему управления предприятием в бизнес-подразделениях владельцев договоров;
  • Оформлять поступление товаров и прочих активов в подразделение (акты), участвовать в комиссиях по приемке и списанию товаров (акты), обеспечивать документальное оформление ввода/вывода в эксплуатацию оборудования и программного обеспечения (приказы и распоряжения);
  • И т. д. про соблюдение безопасности, отраслевых политик и прочего.

(Тяжело читать это канцелярит? Думаю, что в лучшем случае только каждый десятый смог дочитать эти пункты до середины).

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

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

Кажется, речь раньше шла об ИТ и разработке? Перечитав эту главу, невозможно найти требований, которые действительно относились бы к информационным технологиям и/или разработке. Возможно, дело в том, что ИТ и разработка — это разные вещи, и если бы действительно существовал отдел разработки или отдел информационных систем, то в них все было бы лучше? Нет, конечно нет. Появившийся год назад отдел разработки программных систем имеет ровно полтора человека с «программистским» прошлым. Вечерами этот полтора человека пишет для заказчика ИС, а днем работает в «поле», производя замеры на оборудовании. Его тоже напрягают всей вышеописанной бюрократией, плюс его очень сильно касается бурная деятельность по безопасности труда. Нас — реже, мы «в поле» только в пики работ и при всяких изменениях сетевой инфраструктуры. Но тоже выполняем все нормы охраны труда: работа на высоте, работа внутри электроустановок, блюдем нормы энергетической отрасли с полным оформлением сопутствующих допусков и прочих документов… Безопасность — это очень хорошо, но когда на ее бумажное оформление уходит прорва рабочего времени работника ИТ-отдела, я считаю, что это перебор.

В общем, у меня сложилось впечатление, что вся производственная деятельность регулируется людьми, которые ориентируются в какой-либо своей узкой области, и навязывают свои узкие ориентиры на подконтрольные предприятия и сотрудников. На нас сваливают требования по всему чему угодно: от закупок до энергетических политик, от экзаменов по электробезопасности до требований в области качества и экологии, от норм энергетики до информационного взаимодействия с представителями правоохранительных органов. Я честно пытаюсь все это барахло понимать и учить. Но я каждый раз с ужасом жду очередных экзаменов. Вдруг я не отвечу на вопрос о технологических системах нормальной эксплуатации и системах безопасности РО, или что-то не то скажу про технологические системы поддержания ВХР? А если я неправильно перечислю основные полномочия органов государственной власти РФ субъектов РФ и органов местного самоуправления в сфере отношений, связанных с охраной окружающей среды? Или, что хуже того, забуду требования к обязательному страхованию ответственности за причинение вреда при эксплуатации опасного производственного объекта? Я смотрю на весь объем документов, которые вписываются в должностные и производственные инструкции, и не понимаю: неужели никто не видит всего этого маразма в количестве требований? Я не знаю ни одного человека, который способен запомнить такой объем информации.

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

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

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

Послесловие

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

Но сейчас я понял, что публикацию делать обязательно буду.

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

76c8c41cd14b45968b2dfad3200b1938

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

Вся статья на хабре “Каково это — быть разработчиком в России, когда тебе сорок”

]]>
http://skynin.xyz/note/istoriya-sovremennogo-levshi/feed/ 0
Статистика и исключения http://skynin.xyz/common/statistika-i-isklyucheniya/ http://skynin.xyz/common/statistika-i-isklyucheniya/#respond Fri, 03 Feb 2017 22:54:24 +0000 http://skynin.xyz/?p=1075 Я любитель статистики. Но вот вспомнилось (не спрашивайте почему)

“На каждого таракана что видишь приходится 9 тараканов что не видишь”

неправда. то есть статистически – правда.

но для того кто боролся с тараканами в своей квартире, в масштабе дома, где в каждой квартире тараканы – неправда.

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

второе – свой, тута, в моей квартире родился.

третье – разведчик, беженец(соседи бойню устроили). издалека пришел.

]]>
http://skynin.xyz/common/statistika-i-isklyucheniya/feed/ 0
Советы по поиску исполнителя на фриланс бирже http://skynin.xyz/zakazchikam/sovety-po-poisku-ispolnitelya-na-frilans-birzhe/ http://skynin.xyz/zakazchikam/sovety-po-poisku-ispolnitelya-na-frilans-birzhe/#respond Fri, 03 Feb 2017 10:36:41 +0000 http://skynin.xyz/?p=1072 Главное преимущество фриланс биржи перед компаниями разработчиков, веб-студиями это то что вы можете найти исполнителя по любой цене, для проекта любой сложности. Может даже улыбнуться удача, и найдете “за отзыв”.

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

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

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

Поэтому указывайте также: никаких авансов и предоплат! У хорошего исполнителя должна быть финансовая подушка, для того чтобы сделать ваш проект и получить деньги по факту сдачи работ. А если ее нет – значит он плохо работал “за отзывы”. Зачем вам плохой исполнитель?
Плюс такое условие повышает дисциплинированность и ответственность исполнителя. Исполнителю становится невыгодно затягивать с работой, он будет стараться посвятить ей все свое время.
Ведь заработать тысячу рупий за неделю, совсем не то же самое что заработать ее за месяц.

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

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

Пример реального предложения, в котором соблюдены эти правила

Нужно сделать рип шаблона под worpdress с wordpress.
шаблон не сложный если вы в теме думаю за 30-40 минут справитесь.
Зазнавшихся аля мего прогеров прошу мимо тут много не заработаете.
Оплата за сделанное, никакого аванса. Ценник адекватный!
Пишите сразу умеете или нет.

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

]]>
http://skynin.xyz/zakazchikam/sovety-po-poisku-ispolnitelya-na-frilans-birzhe/feed/ 0
Не вляпаться в стартап http://skynin.xyz/razrabotchikam/ne-vlyapatsya-v-startap/ http://skynin.xyz/razrabotchikam/ne-vlyapatsya-v-startap/#respond Thu, 26 Jan 2017 16:29:47 +0000 http://skynin.xyz/?p=1052 Если вы сами задумали стартап – то эта статья не для вас.
У вас точно все получится, ведь статистика говорит что несколько процентов стартапов просуществуют больше нескольких лет, и конечно ваш стартап среди этих процентов. Потому что ваш проект особенный, нацелен на свободную нишу, сотни тысяч людей ждут подобного, а венчурные фонды не знают что делать с неработающими деньгами и т.д.
Я вам верю.

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

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

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

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

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

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

Начнем уже с конченых стартапов.

На фриланс-биржах их авторы пишут примерно такое:

Есть проект, готовый на 90%. Предыдущие программисты оказались сволочами и получив очередную оплату исчезли.

Или, тоже самое!

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

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

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

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

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

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

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

Задумавший стартап – мечтает НЕ работать. Вот чтобы сразу – НЕ работать. Он уже заработал на заначку, за которую решил купить беззаботное будущее! “Я ж купил билет, сел вот в зале, и жду кина с хэппи-эндом! я еще и за попкорн должен платить???”
Он настроен на то что проект будет сделан кем-то, и после запуска проект будет жить сам по себе, и приносить вначале копеечку, а потом, со временем, сам по себе вырастет до генерации прибыли больше его нынешней зарплаты на порядок. Поэтому – допроситься от него даже посмотреть, потестить реализацию очередной хотелки – не допросишься. а уж – дайте контент…

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

ну или – просто не вляпывайтесь в стартап.


P.S. Artem Frolov, PHP Symfony Developer в Innovation Group пишет:

Российская стартап культура — это тема для отдельного разговора. Вкратце: охреневшие погонщики гоняют плетями тихих и смирных разрабов, выпускников МГУ, МИФИ и МГТУ им. Баумана. Последние молча терпят, ездят на работу из пригорода по полтора-два часа и фалломорфируют на то, что если стартап выстрелит их перевезут в страну первого мира. Самостоятельно они ехать не могут/не хотят, с английским за сытые 10 лет у многих совсем плохо, но техническая подготовка — дай бог каждому. Там даже джуниор тестировщик был из МГУ. И он реально умел находить баги, репортить их, смотреть логи на стейджинговых серверах, кверить мускуль и монгу, я с ним разговаривал как-будто он миддл.

Но российскому менеджменту было медленно и плохо. И дорого. Захотели быстрее. В итоге, наняли просто отмороженного погонщика из Казахстана, который перевел процесс разработки на недельные спринты и начал торговаться за каждый час. Он же стал вести добровольно-принудительные графики овертаймов. Начался исход ребят тупо вникуда. Ушла пара джавистов , дизайнер, фронтенд… Вместо них набрали ребят из областей, из средней полосы России, не москвичей (или не из московских вузов, я не знаю, что первичнее). Вот там были дубы. Английский нулевой, доку читают не на оффсайте, а по-русски, с джирой не знакомы, с гитом порывались в master коммитить, но зато были готовы овертаймить, еще более запуганные и смирные, делали всё, чтобы в свои Сибири да Волгограды не возвращаться.

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

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

]]>
http://skynin.xyz/razrabotchikam/ne-vlyapatsya-v-startap/feed/ 0
Йога и Индия или правда, которую вам забыли поведать http://skynin.xyz/spiritual/joga-i-indiya-ili-pravda-kotoruyu-vam-zabyli-povedat/ Tue, 17 Jan 2017 16:59:58 +0000 http://skynin.xyz/?post_type=spiritual&p=1045 Скопировано из блога

Давно хотел высказаться на тему, которая совершенно неадекватно воспринимается соотечественниками. Вины у них никакой нет, ибо, начиная с культового в  70х годах фильма “Индийские йоги, кто они”, соотечественникам привили абсолютно ошибочную картинку, которую с тех пор никто не удосужился исправить (по понятным причинам: йогу в её натуральном виде невозможно монетизировать – банально не будет спроса).

В реальности всё с йогой очень и очень просто, поэтому полагаю, настало время расставить все точки над i.

Дабы не утомлять читателей хитросплетениями причинно-следственных связей, библиографией и экскурсами в историю предмета, ограничусь лишь перечислением ключевых положений, связанный с йогой и Индией, которые я сформулировал на основании 30-летнего опыта ежедневных занятий и погружения в тему, начавшихся в середине 80-х годов с уроков бомбейского гуру Лакшмана, преподававшего в Индийском посольстве в Москве, и изучения санскрита, и продолжающихся по сей день после 10 лет пребывания в Индии.

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

Йога задумывалась, создавалась и развивалась на протяжении столетий как ещё одна дхарма. У термина “дхарма” (как, собственно, и у любого понятия в системе индийского мышления) множество самых различных и зачастую противоречащих друг другу значений, и в данном случае нужно уточнить, что речь идёт не о Долге, не о Порядке, а о Пути. Так вот, йога, точнее то, что под ней понимается повсеместно за пределами Индии – аштанга-йога Патанджали (в широком смысле слова) или хатха-йога (как элемент аштанги – в узком смысле слова) – это не оздоровительная гимнастика, не терапия, не забота о здоровье, а ДХАРМА как Путь к Постижению Божественного.

Переводя на язык бытовых понятий практика йоги – это РЕЛИГИОЗНАЯ практика. Почти исключительно религиозная, а всё остальное, что можно обнаружить в йоге – позитивные для физического состояния практикующего влияния, психотерапевтическая коррекция и т.п. – лишь побочные бонусы, которые прилагаются к достижению основной цели.

Это ОЧЕНЬ важный момент, поэтому остановлюсь на нем чуть подробнее. Чтобы было понятно, до какой степени в классической концепции йоги забота о здоровье практикующего подчинялась эзотерическим требованиям, приведу лишь маленький пример. Т.н. “кхечари мудра” – техника выворачивания языка в обратную сторону, преследующая цель создания дополнительных препятствий (блокировок) на пути свободного течения жизненной энергии (праны) – в классическом трактате “Гхеранда Самхита” (один из самых авторитетных источников хатха-йоги) получает такую рекомендацию: “Для увеличения хода языка перережьте подъязычную связку”.

С учетом только что обозначенной природы йоги (один из путей постижения бога и трансцендентного) популярность йоги в Индии, даже вопреки всем усилиям государства, направленным на превращение её в принудительный вариант школьной и производственной гимнастики, стремится к нулю. На уровне личного опыта: за 10 лет я не встречал НИ ОДНОГО индуса, который бы в личной жизни практиковал йогу! Ни одного! Учителей (гуру) йоги – пруд пруди, особенно в туристических регионах, а так чтобы самому по собственной воле заниматься йогой – увольте.

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

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

Как я уже сказал, в Индии из всех путей религиозного познания 99 % последователей приходится на бхакти, которая реализуется в бесчисленных региональных культах и объединяется в магистральные течения (вайшнавизм, шайвизм, шактизм и проч.). Оставшийся крохотный процент делится между дхармой Джняны (постижение божественного через знание) и Кармы (путь добродетельной жизни). И лишь какие-то микроскопические доли поклонения достаются хатха-йоге, агхори и паре сотен совсем маргинальных дхарм вроде кровожадных сект богини Кали или уцелевших после праведной британской чистки вариаций на тему тхагов.

К чему это я всё рассказываю? Во-первых, к тому, что, приезжая в Индию, не нужно строить иллюзий и следует понимать, что число учителей (гуру) в этой стране многократно превосходит количество местных адептов. Во-вторых, приступая к занятиям йогой, нужно понимать, что к гимнастике и физкультуре она имеет весьма отдаленное отношение. Йога – это форма религиозного сознания, это религиозная практика, завязанная на бесконечно далекие от традиционных и привычных бхакти-вариантов Западной цивилизации (католицизма, протестантизма, православия). Разве что иудаизм с его могучей традицией кабалы почувствует себя комфортно в системе энергетических центров (чакр), эманации божественной энергии (праны), первичных звуковых вибраций (мантр) и пробуждения внутренней латентной энергии (кундалини).

Если вы готовы к такому необычному путешествию – тогда добро пожаловать! Но только не попадайтесь в сети, расставленные охочими до денег неучами, выдающими  себя за Великих Гуру. Правильно обучить вас йоге смогут ТОЛЬКО в правильных местах и только единицы. В первую очередь, это серьезные школы в Ришикеше и Бихаре. Ну а уж в Гоа почти гарантированно  вместо йоги вам продадут выхолощенный от подлинной сути суррогат под соусом “волшебного оздоровления”. А чтобы вы не догадались о подделке,  физкультуру для вас приправят изрядной толикой туманных санскритских слов, о подлинном смысле которых сами гуры не догадываются (элементарно потому, что не знают санскрита и, естественно, не читали классических сутр, пуран и упанишад).

]]>
Эволюция верований http://skynin.xyz/spiritual/evolyutsiya-verovanij/ Tue, 17 Jan 2017 10:51:24 +0000 http://skynin.xyz/?post_type=spiritual&p=1041 Эволюция мышления неразрывно связана с эволюцией представлений о духовном, религиозных идей, практик и организаций. Данная статья является попыткой краткого рассмотрения этого предмета с использованием терминологии интегральной динамики.

Оригинал статьи на spiraldynamics.ru
Начало в Разноцветные миры

icon_sd-01Бежевая парадигма сугубо материалистична. Здесь вся энергия уходит на выживание, на всё остальное просто не хватает сил.

icon_sd-03Фиолетовая парадигма высвобождает часть жизненной энергии за счет того, что сообщество, в котором живет человек, облегчает выживание. Эта энергия идет на попытки понять устройство мира, на фантазии и творчество. Впервые появляется представление о мироустройстве. Верования фиолетовых сообществ в разных концах земного шара, как показал Дж. Фрэзер, удивительным образом похожи (религиоведы используют термин «анимизм»). Миром управляют явные и скрытые силы (духи животных и растений, гор, рек и небесных светил, а также духи предков), эти духи бывают добрыми или злыми, благосклонными или предпочитающими пакостить, и нам нужно завоевать и поддерживать их расположение. Это мир магии и суеверий, «безымянных древних богов», примет и заклинаний, табу и мистических объектов (кровь, семя, огонь домашнего очага, земля предков, личное имя и т.п.). Фиолетовый мир очень яркий и живой, здесь дышит каждый камень и говорит каждое дерево, здесь слышны голоса предков и нерожденных потомков, и здесь же живут ведьмы, вампиры и демоны.

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

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

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

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

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

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

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

icon_sd_book-01Синяя парадигма впервые вводит этику — понятия добра и зла, праведности и греха, раскаяния и воздаяния. Есть один широкий и прямой Путь правды и света, а по обе стороны от него лежит царство тьмы, неправды и греха. Свыше определяется Цель, а движение к ней порождает Путь и дает Смысл жизни. Богу не всё равно, праведен ты или грешен: он любит всех, но праведники угодны Ему, а грешники вызывают Его гнев. Соблюдение кодекса поведения означает заслуженную награду, а нарушение — стыд, чувство вины и наказание.

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

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

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

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

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

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

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

Однако и другие религиозные традиции также постепенно движутся по пути модернизации. Модернизацию католицизма связывают с именем Пьера Тейяр де Шардена и Вторым Ватиканским собором, иудаизма — с именем рава Авраама-Ицхака Кука и движением «вязаные кипы» (15% населения Израиля). Попытка модернизации ислама предпринята движением Фетуллы Гюлена, и не случайно в ее основе — школы и университеты.

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

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

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

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

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

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

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

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

Автор: Валерий Пекар — украинский предприниматель и общественный деятель, преподаватель Киево-Могилянской и Львовской бизнес-школ.

]]>
Если вы задумали создать свой OLX http://skynin.xyz/note/esli-vy-zadumali-sozdat-svoj-olx/ http://skynin.xyz/note/esli-vy-zadumali-sozdat-svoj-olx/#respond Sat, 14 Jan 2017 12:13:47 +0000 http://skynin.xyz/?post_type=note&p=1031 Каждый раз встречая желающего запустить свою доску объявлений, какую-то биржу, и прочее хотелось написать …

про Самописный движок интернет магазина писал ранее.

и вот, вместо меня это сделал Yoda, широко известный в кругах ОpenCart’щиков
Оригинал статьи Как из Opencart сделать торговую площадку

С завидной регулярностью к нам приходят запросы «а как дать возможность посетителям добавлять свои товары, а как сделать что то похожее на OLX или SLANDO»?

Меня эти вопросы если честно говоря бесят.

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

Ну ладно, я могу поверить в удачу, и в то, что за три копейки один из тысячи взлетит магазин. Но доска объявлений — не взлетит.
В магазине у нас определяющим фактором успеха является трафик. Это же верно и для досок объявлений. Не умеете привлекать трафик — идите работать на завод. Только в магазине трафик = деньги в 99% случаев, а вот пока вы с доски объявлений выжмите копейку — рак на горе свиснет. Мало того что у нас народ любит халяву, так еще пока у вас появится постоянная аудитория, в нужном количестве, которая начнет заносить деньги за платные посты и размещения, у вас закончится любой бюджет и вы двадцать раз проклянете тот день, когда в вашу голову пришла светлая мысль запустить доску.

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

За три копеечки  — не бывает. Даже если мы будем использовать Opencart MarketPlace, стоимость софта, дизайна, настройки системы, допилов и интеграции платежных систем выплывет в бюджет минимум $3-5к. А еще для того чтобы хоть как то запустить доску — необходимо заполнить первичный контент и возможно написать парсеры на другие доски, чтобы у вас появилось хоть какие то признаки жизни проекта. Поэтому без $10-15 стартового капитала, начинать не стоит. Кроме этого, после первых 50 000 объявлений у вас все ляжет, вам нужен будет один сервер, второй третий, потом вы упретесь в тупик архитектуры, вам нужно будет все переписывать ну и по классике 90% таких проектов сдуваются.

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

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

Ну и по традиции пишу я про это все не на голом месте. 
С полгода назад, написал мне один мой товарищ: «а допили как мне доску на osclass, а то я тут уже положил $2000 долларов в программиста, а он полгода дрочит и ниче не готово». Ответ у меня был однозначный — НАХУЙНАДО!

Но мне стало интересно что такое OsClass и с чем его едят?
Поставил я эту дрянь покрутил — и бросил.

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

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

1. Я хочу открыто обратиться к моему товарищу. Леша, ты дурак. Твой программист будет тебе яйца мять еще год. И в итоге ты проект похоронишь. Пока не поздно — ставь Тамарангу.

2. Я в конце концов альтруист иногда и не против помочь нормальным людям.

3. На будущее это будет закладочка, которая позволит давать ответ на вопрос — как сделать на Opencart доску объявлений или аукцион. Ответ простой: никак, не испытывайте судьбу — ставьте Тамарангу.

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

]]>
http://skynin.xyz/note/esli-vy-zadumali-sozdat-svoj-olx/feed/ 0
Почему я ушел из “офиса” http://skynin.xyz/common/pochemu-ya-ushel-iz-ofisa/ http://skynin.xyz/common/pochemu-ya-ushel-iz-ofisa/#respond Tue, 10 Jan 2017 16:43:20 +0000 http://skynin.xyz/?p=1020 Текст не мой(комментарий на DOU), детали не совпдают, но в целом… выделил

пишет в теме “Cаморазвитие и работа?”:

За все те годы, которые гребу на галерах — этот вопрос всегда был для меня проблемным.

Даже в свои молодые годы я не был способен спать по 4 — 6 часов в сутки, как многие советуют. Без 8 часов нормального сна весь букет болячек (а он у меня с детства) быстро давал о себе знать. Естественно, когда тебе хреново — не до самообучения и продуктивной работы.

Теперь в мои 40+ в большинство дней 10-12 часов хорошего самочувствия в день — это уже радость.

Работа в ИТ компании — это редко 8 часов «от звонка до звонка». Во-первых продуктивно педалить 8 часов подряд — невозможно физически. Во-вторых обязательно есть митинги, вопросы от коллег, отчеты для босса, почта и прочие активности. А в эстимейтах, естественно, менеджеры считают 8 «идеальных» часов кодинга. Поэтому мой рабочий день это примерно 6 часов кодинга, 3 часа побочных активностей и час на еду и перерывы. Итого в среднем в офисе проходят 10 часов.

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

Итого правильно написал: все самообучение остается на выходные.

Более того — в самообучении есть нюанс. Все что изучил — надо использовать, иначе обучение бестолку. Для джунов это обычно не проблема — им есть что изучать даже на старых проектах. Для синьоров проблема — изучать нужно перспективные технологии, которые на реальных проектах пока не используются. А следовательно — пробовать их можно только на пет-проектах.
А для пет-проектов 10 часов в неделю (по 2 в будни) — просто несерьезно. Поэтому нет смысла и начинать учить новое если не готов тратить на пет-проект хотя бы один выходной.

Итого проще посчитать сколько остается свободного времени от работы и самообучения — у меня это примерно 10 часов в неделю. Или 22 дня в год. Вот это и есть вся моя «реальная жизнь» вне ИТ.

]]>
http://skynin.xyz/common/pochemu-ya-ushel-iz-ofisa/feed/ 0
Форк PrestaShop http://skynin.xyz/note/fork-prestashop/ http://skynin.xyz/note/fork-prestashop/#respond Sat, 07 Jan 2017 13:11:38 +0000 http://skynin.xyz/?post_type=note&p=1014 Давно присматривался, но смущало что никак не наберет популярность, хотя ниша между WooCommerce и Magento пустует. Однако Magento и WooCommerce гораздо массовей.

А вот оно что оказывается, проблемы в core team…

Opennet пишет

Независимая группа разработчиков из сообщества сообщила о создании проекта ThirtyBees, в рамках которого создан форк свободной платформы электронной коммерции PrestaShop, на базе которой построено более 250 тысяч интернет-магазинов. Код проекта написан на PHP и распространяется под лицензией OSL 3.0.

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

Другой проблемой, которую попытаются решить в рамках форка является недостаточное время поддержания веток, например, поддержка ветки PrestaShop 1.6 была прекращена ещё до того, как кодовая база достигла полной стабилизации, а новая ветка 1.7 была выпущена полусырой и недостаточно стабильной для промышленного внедрения. Более того, в PrestaShop 1.7 были внесены архитектурные изменения, затрудняющие обновление с прошлых веток и требующие обновления каждого модуля, в том числе повторной покупки платных модулей. Подобное отношение привело к недовольству и оттоку пользователей платформы – в последние 18 месяцев наметилась тенденция по сокращению числа интернет-магазинов, построенных на базе PrestaShop.

В рамках проекта ThirtyBees планируется продолжить развитие и поддержание ветки PrestaShop 1.6, в первую очередь уделив внимание исправлению имеющихся ошибок и недоработок. Например, планируется наладить работу расширенных средств управления запасами товара (Advanced stock management), которые были исключены из ветки 1.7 и были непригодны к использованию из-за проблем, которые оставались нерешёнными несколько лет. Кроме исправления ошибок разработчики также займутся проведением рефакторинга модулей и приведением их в порядок. Особое внимание будет уделено сохранению совместимости со старыми модулями и темами оформления. Владельцам интернет-магазинов на базе PrestaShop будет предоставлена возможность лёгкой миграции на ThirtyBees.

Предыстория форка

February 17, 2016

PrestaShop 1.7 will be a catastrophe. Here is why

November 9, 2016

PrestaShop 1.7 is out, here is why it is a failure

]]>
http://skynin.xyz/note/fork-prestashop/feed/ 0
Portfolio http://skynin.xyz/self/portfolio/ http://skynin.xyz/self/portfolio/#respond Thu, 05 Jan 2017 15:42:15 +0000 http://skynin.xyz/?page_id=1012 Сайт по фентези-спорту

мелкий фикс в Woocommerce

]]>
http://skynin.xyz/self/portfolio/feed/ 0
Типичные ошибки заказчика при работе с фрилансером http://skynin.xyz/duplicate/tipichnye-oshibki-zakazchika-pri-rabote-s-frilanserom/ http://skynin.xyz/duplicate/tipichnye-oshibki-zakazchika-pri-rabote-s-frilanserom/#respond Wed, 28 Dec 2016 11:20:22 +0000 http://skynin.xyz/?post_type=duplicate&p=1001 Полный текст статьи на DOU.ua
Владимир Кожаев, Founder в New Language Service

Отрывки

фрилансер (freelancer) — «свободный работник, частный специалист, который может одновременно выполнять заказы для разных клиентов» © Википедия. Как правило, фрилансер работает удалённо, отыскивая заказы через интернет. Занимается поиском более-менее постоянно, потому что работа имеет свойство подходить к концу. Это фактически бизнесмен — владелец фирмы из одного человека. Для многих фриланс — первая ступень к страницам Форбс (ну или они на это надеются). То есть неправильно строить взаимодействие с фрилансером по модели начальник-подчинённый.

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

Зачем становятся фрилансерами

Причин несколько:

  1. Возможность самостоятельно определять время и место работы/отдыха. Фактически, фрилансер может работать в любом месте, где есть интернет в любое время, хоть с 24 до 7. Например, я прошедшую неделю провёл в Стамбуле. Полдня гулял и пол -работал.
  2. Фриланс может стать началом большого бизнеса. В начале ты глава фирмы из одного человека, потом нанимаешь помощников и пошло-поехало.
  3. Нет необходимости соответствовать корпоративным стандартам и принимать участие в политических играх.

Вместе с тем у фриланса есть и недостатки:

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

Изменились цели, или крепок задним умом

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

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

Во-вторых, невозможно указать фиксированную цену за работу, если объём её неизвестен.

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

Как формируется цена работы

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

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

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

Верхняя рамка цены всё же есть: она определяется вашей выгодой от полученной работы. То есть, если стоимость превысит xxx, вам проще вообще отказаться от заказа — вот это xxx и будет верхней планкой для вас. Из этого следует совет: торгуясь о цене, руководствуйтесь соображениями прибыли для вас конкретно и ничем больше. Иногда мне пытаются задвинуть такое: «Я слышал, что в вашей стране фрилансеры работают за xxx в час». На это я отвечаю: «Дорогой друг, мы говорим с тобой о нашем сотрудничестве. Моя цена вот такая. Если интересно, давай общаться дальше». Действительно, какое кому дело до того, как я распоряжаюсь финансами? Может я вообще на полюсе живу, в свободное время пью спирт и объезжаю белых медведей. И это аргумент, чтобы платить мне меньше? Я же не спрашиваю о том, сколько на моей работе имеешь ты. И отсюда еще совет: не считайте чужих денег.

Давление, манипуляции, шантаж

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

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

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

Невыплата последней суммы имеет смысл только, если вы никогда-никогда не будете обращаться к этому фрилансеру. Был у меня такой случай: делал DSL, оплату последней итерации зажали. Через некоторое время обращается ко мне тот же заказчик за модификацией. Говорю, мол, дружок, ты же не оплатил последнюю порцию работы. Оплати и тогда можно продолжить разговор по поводу следующей. Он туда-сюда, мол ты точно будешь делать? Я говорю: «В начале оплата предыдущего, и только потом разговор о следующей». Делать нечего, пришлось ему платить. Он правда пытался пропетлять, мол я заплатил, деньги скоро будут — начинай уже работать. Нет, говорю, в начале они должны прийти мне на карту. Пришли, всё в порядке. Я говорю: «Хорошо, но сейчас я занят очень, если хочешь могу сделать работу по премиальному тарифу (и задвигаю цену большую на порядок). Ну, или жди пока я освобожусь (хе-хе)». Как так, говорит. А вот так! Ты был должен за предыдущую работу — её и оплатил, я о дальнейшем сотрудничестве говорить не отказываюсь. А что цена изменилась, так никто не гарантировал её постоянства.

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

]]>
http://skynin.xyz/duplicate/tipichnye-oshibki-zakazchika-pri-rabote-s-frilanserom/feed/ 0
Vue.js http://skynin.xyz/wiki/vue-js/ http://skynin.xyz/wiki/vue-js/#respond Tue, 27 Dec 2016 20:34:44 +0000 http://skynin.xyz/?post_type=yada_wiki&p=997

Я могу подтвердить, что two-way binding иногда не так прост и не так читабелен, но большинство из этих страхов связаны с общим страданием людей от первой версии Angular, где двусторонняя привязка была, может быть, не самой лучшей. И все же… это, вероятно, не было самым большим просчетом даже в Angular. Посмотрите на мой быстрый редактор, который я накостылил недавно с Vue.js для нашей платформы на Drupal (заранее прошу прощения за дизайн, это бэкенд UI для наших операторов, а дизайнеры заняты, создавая интерфейсы для наших клиентов, так что этот кусок функционала ждет своего часа, чтобы стать красивым):

Почему мы выбрали Vue.js (а не React)

Vue.js – реактивный фронтенд фреймворк для людей

Андрей Грачёв: Vue.js или как наконец отказаться от React

]]>
http://skynin.xyz/wiki/vue-js/feed/ 0
Почему мы выбрали Vue.js (а не React) http://skynin.xyz/duplicate/pochemu-my-vybrali-vue-js-a-ne-react/ http://skynin.xyz/duplicate/pochemu-my-vybrali-vue-js-a-ne-react/#respond Tue, 27 Dec 2016 19:43:55 +0000 http://skynin.xyz/?post_type=duplicate&p=989 оригинал статьи на geektimes

Отрывок

Мы решили использовать Vue.js после того, как построили тестовое приложение c идентичным функционалом – наш калькулятор — на React, Vue.js и Angular2.

React.js

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

Мы запилили несколько SPA и динамических виджетов на React, мы тестировали React Native (под iOS) и Redux. Я думаю, что React был большим шагом для мира JS с точки зрения осведомленности о состоянии, и он показал многим людям, что такое реальное функциональное программирование в хорошем, прагматичном ключе. Также я думаю, что React Native велик – он буквально меняет весь ландшафт мобильной разработки.

Недостатки React для меня:

Зачастую чистота, иммутабельность и идеология доминирует над прагматичным подходом

Не поймите меня неправильно. Я ценю чистоту (purity) и простоту подхода render() – без сомнения, это отличная идея, которая работает в реальной разработке. Я говорю о других вещах.

Я думаю, вот этот уровень строгости и чистоты может быть полезным, когда у вас работает 1000 разработчиков в компании – примерно тогда же, когда вы решите разработать свой собственный синтаксис, чтобы перевести на статические типы весь ваш PHP код. Или когда вы являетесь разработчиком Haskell, который решил постичь JS. Но у большинства компаний гораздо меньше разработчиков, небольшие бюджеты и цели, отличающиеся от целей Facebook. Я остановлюсь на этом подробнее чуть дальше.

JSX – отстой

Подождите секундочку! Я знаю! Это «просто чистый Javascript со специальным синтаксисом» . Нашим ребятам, которые рисуют в скетче и фотошопе дизайн и потом конвертируют его в HTML, у которых жесткие дедлайны и которые прямо сейчас верстают вот эту форму, обернув ее в некоторое количество div’ов – прямо сейчас – совершенно по барабану чистота и «простота» ES6. Применение некоего дизайна к компонентам React – работа не фонтан, потому что JSX не хватает читаемости. Невозможность поставить старый добрый IF в какой-то блок HTML кода – это плохо, и, пожалуйста, не верьте поклонникам React, которые говорят что «if() – это прошлый век, а сейчас все нормальные программисты используют тернарные операторы». Позвольте мне заверить вас: JSX – это все еще мешанина HTML и JS в момент, когда вы читаете и редактируете его, даже если потом он будет скомпилирован в чистый JS.

<ul>
       {items.map(item =>
         <li key={item.id}>{item.name}</li>
       )}
</ul>

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

stackoverflow.com/a/38231866/1132016

JSX также вынуждает разбивать компоненты-в-15-строк-HTML в 3 компонента, 5-строк-HTML-в-каждом. Не думайте, что этот подход делает вас более качественным разработчиком.

Вот в чем штука:

Когда вы пишете относительно сложный компонент – который вы, вероятно, не собираетесь завтра выкладывать в публичный реп на GitHub, чтобы продемонстрировать его на HackerNews – этот подход разбивания компонентов на супертупые (dumb) компоненты из-за ограничений JSX всегда выдергивает вас из потока, в котором вы решаете реальную бизнес-задачу. Нет, я не говорю, что идея дробных компонентов плоха или не работает. Вы должны четко осознавать, что вам нужно делить функционал на составные части, чтобы держать ваш код в управляемом состоянии. Но вы должны делать это только тогда, когда вы думаете, что этой конкретной логической сущности в вашем коде лучше быть отдельным компонентом с собственными props – а не на каждые два-три условия, которые были написаны с помощью тернарного оператора! Каждый раз, когда вы создаете новый компонент здесь и там, это стоит вам вполне конкретных усилий и нарушает ваш поток, потому что вам нужно переключиться от мышления архитектора (когда вы уже помните текущее состояние компонентной модели и вам просто нужно добавить HTML здесь и там, чтобы функционал заработал) на мышление менеджера: вам надо создать отдельный файл для компонента, подумать о props этого нового компонента, как они маппятся на state, как вы собираетесь пробрасывать коллбеки и т.д. В результате снижается скорость написания кода, потому что вы вынуждены тратить усилия на преждевременную модульность компонентов там, где вам это, вероятно, не понадобилось бы, будь синтаксис JSX более гибким. На мой взгляд, преждевременная модульность очень похожа на преждевременную оптимизацию. Для меня и нашей команды читаемость кода важна, но все еще очень важно и получение удовольствия от написания кода. Это не круто, когда простая форма калькулятора требует создать 6 компонентов, каждый со своими props.

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

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

Работа с формами и Redux заставят вас печатать весь день напролет

React – он о чистоте и one-way flow, помните? Вот почему LinkedStateMixin стал персоной нон грата , и теперь вы должны написать 10 функций, чтобы получить входные данные из 10 полей формы. Нет, можно, конечно, написать одну функцию, которая будет проверять e.target, но в конечном итоге там будет такое дерево условий с нормализацией прилетающих из формы данных, что захочется плакать; поэтому так никто не делает. 80% из этих функций будет содержать одну строку с this.setState() или вызова Redux экшна. (Тогда вам, вероятно, придется создать еще 10 констант – по одному на каждый action). Я думаю, этот подход был бы приемлем, если вы могли бы генерировать весь этот код, просто подумав о нем… Но я не знаю ни одного IDE редактора, который мог бы значительно упростить написание такого боилерплейта. Почему вы должны печатать так много? Потому что большие парни решили, что двухстороннее связывание является опасным в больших корпоративных приложениях. Я могу подтвердить, что two-way binding иногда не так прост и не так читабелен, но большинство из этих страхов связаны с общим страданием людей от первой версии Angular, где двусторонняя привязка была, может быть, не самой лучшей. И все же… это, вероятно, не было самым большим просчетом даже в Angular. Посмотрите на мой быстрый редактор, который я накостылил недавно с Vue.js для нашей платформы на Drupal (заранее прошу прощения за дизайн, это бэкенд UI для наших операторов, а дизайнеры заняты, создавая интерфейсы для наших клиентов, так что этот кусок функционала ждет своего часа, чтобы стать красивым):

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

Redux тоже многословен и требует много писанины. И в интернете легко найти высказывания разработчиков, которые обвиняют Mobx в превращении React в Angular только потому, что Mobx использует двухсторонню привязку данных (см. пункт№1 о «чистоте»). Похоже, что многие умные люди больше ценят «чистоту» своего кода, а не быстро и хорошо решенную бизнес-задачу (что, в принципе, нормально, если у вас нет дедлайнов).

При этом, я считаю саму концепцию Flux/Redux — очень крутой. Redux прост и дает невероятный уровень контроля за состоянием приложения, и отделение состояния от чисто интерфейсных штук — это сразу дает упрощение написания тестов. Но, к сожалению, это все дается очень большим количеством писанины. Да, time-travel дебаггинг как побочный эффект — это офигенно. Но лично я готов им пожертвовать ради скоростного написания кода, и подумайте, нужен ли вам time-travel, если ради него надо придумать константу для каждого поля в форме.

Чрезмерное излишество в инструментарии

React работает с изначальным прицелом на Babel. Вы не сделаете реальное приложение на React без приличной кучи npm пакетов, начиная с компилятора ES5. Простое приложение на основе официальной стартовой сборки в нагрузку получает около 75 МБ JS кода в node_modules. Это не критичная вещь и больше относится к миру JS в целом, чем к React, но все же добавляет расстройства и раздражения.

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

Angular 1: Слишком много свободы – это тоже плохо

Angular 1 — неплохой для своего времени фреймворк, расположенный в противоположном углу (от React) воображаемой JS карты чистоты и читаемости кода. Angular позволяет стартовать быстро, позволяет получить удовольствие от написания первых 1к строк кода, и потом он практически заставляет вас писать код, который получается не очень. Вы, вероятно, потеряетесь в директивах, scopes, и двухсторонние потоки данных, пронизывающие насквозь все слои вашего приложения, будут завершающим аккордом лебединой песни вашего кода, который свеженанятые разработчики даже не захотят трогать, потому что обязательно что-нибудь сломается. Почему же так происходит? Angular.js был создан в 2009 году, когда мир фронтенд-разработки выглядел довольно просто и никто даже не задумывался о хорошем контроле за состоянием (state) приложения. Не стоит винить авторов – они просто делали конкурента Backbone с некоторыми новыми фишками и хотели поменьше печатать (и им все это удалось, другой вопрос какой ценой).

Angular2

Просто постройте hello-world приложение и посмотрите на количество файлов, которые лежат в итоге в репе. Придется использовать Typescript (а я не на 100% уверен, что я хочу делать каждый день — нет, ребят, статическая типизация в JS – это не панацея, зато попечатать в очередной раз придется, неплохие мысли от Eric Eliott на эту тему) и компиляторы, чтобы начать работать. Нам этого хватило, чтобы отложить Angular2 до лучших времен. Я ленивый, и для меня это слишком много бойлерплейта, прежде чем начнешь писать реальный код. На мой взгляд, авторы Angular 2 пытаются построить идеальную систему для энтерпрайза, которая будет побеждать React, вместо того, чтобы пытаться построить фреймворк, которая решает бизнес-задачи для обычного, среднестатистического пользователя. Может быть, я ошибаюсь, и мое мнение может измениться – у меня нет большого опыта работы в Angular2, мы только что построили тестовое приложение калькулятора, в конце концов. Замечательная страница сравнения на сайте Vue.js называет Angular2 хорошей системой, которую с Vue.js объединяет немало идей.

Vue.js

Vue.js – это штука, которую я ждал долго (здесь и далее я буду говорить о Vue.js 2, который получил немало улучшений по сравнению с первой версией Vue, и это текущая стабильная версия системы). Для меня, с точки зрения элегантности и лаконичности, а также фокусировке на решениях реальных задач, Vue.js является самым большим прорывом в JS с того дня, когда меня сразил наповал Jquery в 2007. Если вы посмотрите на графики популярности Vue.js, то заметите, что он порадовал в этом году не только меня:

По популярности в Google Trends Vue.js в 2016 резко обошел React.

https://www.google.ru/trends/explore?q=vue.js,react.js,angular.js

Vue.js является одним из наиболее быстро растущих (с точки зрения комьюнити или, как минимум, количества лайков в гитхабе, и пользователей Vue Dev Tools в хром сторе) решений JS в 2016 году, и я уверен, что это не просто еще одна модная библиотека для хипстеров, которые переключаются на новый JS фреймворк каждые 3 месяца, или работа PR-отдела какой-нибудь большой компании.

Laravel добавил Vue.js в ядро, и это серьезная заявка.

Плюсы Vue.js

Vue.js выдерживает отличный баланс между читаемостью, ремонтопригодностью кода и удовольствия от его, этого кода, написания. Этот баланс находится на примерно равноудаленном расстоянии между React и Angular 1, и если вы посмотрите на гайдлайн vue.js, вы сразу же заметите, сколько полезных идей он позаимствовал из этих систем.

Из React Vue.js взял компонентный подход, props, односторонний поток данных для иерархии компонентов, производительность, возможность рендеринга на бэкенде и понимание важности надлежащего управления состоянием (state). Из Angular1 Vue.js взял похожие шаблоны с хорошим синтаксисом и двухстороннее связывание, но только там, где это вам действительно нужно и не позволит так сразу отстрелить себе ногу (внутри одного компонента). Начать писать код под Vue.js очень легко – я видел это в нашей команде. Vue.js не требует каких-либо компиляторов по умолчанию, так что очень легко добавить Vue.js к вашей legacy кодовой базе и начать переписывать jQuery мешанину на читаемый код.

Правильное количество магии

Vue.js очень прост в работе как в точки зрения HTML-centric подхода, так и с точки зрения JS разработчиков: вы можете сделать довольно сложные шаблоны, не теряя фокуса на бизнес-задаче, и получающийся HTML шаблон обычно неплохо читается даже тогда, когда он уже большой. К этому времени, как правило, вы достигли хорошего прогресса в решении бизнес-задачи и можете захотеть реорганизовать шаблоны и разделить их на более мелкие составляющие – в этот момент вы видите всю «картину» вашего приложения намного лучше, чем в самом начале. Мой опыт показывает, что это значительно отличается от подхода, который обычно используют программисты в React, и это различие экономит много времени и усилий программистам использующим Vue.js. В React вы вынужденыразбивать компоненты на микрокомпоненты и микрофункции прямо в момент написания первоначальной, «черновой» версии кода, иначе вы будете буквально погребены в мешанине фигурных скобок и хтмла между ними. В React я трачу много времени на полировку props и рефакторинг супермелких компонентов (которые, конечно же, никогда не будут повторно использованы) снова и снова, потому что не вижу так ясно, когда мне вдруг понадобится поменять логику кода в середине процесса.

Формы

Работа с HTML-формами в Vue.js – одно удовольствие. Это то место, где двусторонний байндинг реально выручает. Даже в сложных случаях нет никаких проблем, хотя watchers на первый взгляд могут напомнить Angular 1. Односторонний поток данных всегда к вашим услугам, когда вы дробите компоненты.

Технологии

Если вы хотите компиляцию, linting, PostCSS и ES6 — не проблема. Single-file компоненты, похоже, становятся основным способом написания публичных компонентов в Vue.js 2. Кстати, идея Scoped CSS, работающая в single-file компонентах из коробки – это то, что выглядит действительно красиво и может уменьшить необходимость в строгих правилах именования CSS классов и таких технологий, как BEM.

Управление состоянием

У Vue.js довольно простое и полезное управление состоянием через data() и props() методы – они отлично работают в реальной разработке. Если душа просит чего-то большего для менеджмента состояния, есть Vuex (который, по-моему, похож на Mobx в React – состояние там мутабельно). Я думаю, хорошему проценту Vue.js приложений управление состоянием через Vuex не понадобится, но альтернативу иметь приятно.

Минусы VueJS

 

Runtime ошибки в шаблонах

Самый большой: неприятные ошибки времени исполнения в шаблонах. Жертва в угоду удобству написания кода. Это очень похоже на Angular 1. Vue.js удается выдать много полезных предупреждений для JS кода: например, есть предупреждения, когда вы пытаетесь мутировать props или некорректно используете data() метод, положительное влияние React здесь очень хорошо заметно. Но runtime ошибки в шаблонах по-прежнему являются слабым местом Vue.js. Стэктрейсы исключений зачастую бесполезны и ведут во внутренние методы Vue.js. В этом случае и в этом классе ошибок и дебага JSX зачастую приятнее: за счет компиляции «из JS в JS» там клик на ошибке в консоли браузера обычно ведет именно туда, где эта ошибка произошла в коде.

Библиотеки

Инфраструктура Vue.js еще довольно молодая. По сути, стабильных компонентов от комьюнити можно по пальцам пересчитать, причем многие из них были построены для Vue.js 1, и зачастую новичкам не так просто разобраться, под какую версию Vue.js построена конкретная библиотека. Эта проблема нивелируется тем, что вы можете сделать крутые вещи в Vue.js, не испытав большой нужды в сторонних библиотеках. Вероятно, понадобится лишь библиотека для Ajax запросов ( vue-resource будет хорошим выбором, если вы не заботитесь об изоморфных приложениях, в противном случае Axios ) и, вероятно, Vue-router, который считается библиотекой с хорошей поддержкой авторов Vue.js.

Non-english speaking community

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

Проект одного человека.

Скорее, потенциальная проблема, чем реальная, но иногда хочется перестраховаться. Evan Vue – это парень, который построил Vue после того, как поработал в Google и Meteor. Laravel, конечно, тоже single-guy проект, но, тем не менее, он по-прежнему очень успешен, правда?

]]>
http://skynin.xyz/duplicate/pochemu-my-vybrali-vue-js-a-ne-react/feed/ 0
Scope creep: причини і наслідки http://skynin.xyz/duplicate/scope-creep-prichini-i-naslidki/ http://skynin.xyz/duplicate/scope-creep-prichini-i-naslidki/#respond Thu, 22 Dec 2016 12:52:19 +0000 http://skynin.xyz/?post_type=duplicate&p=983 Оригінал статті на DOU.ua
Volodymyr Dovganyk, Business Analyst – Softserve

Дослідження Ламрі, проведене більш ніж десять років тому (грудень 2003 — січень 2004), виявило, що 71% проектів перевищують запланований бюджет або потребують перегляду початкового обсягу робіт. У 63% випадків саме scope creep був визнаний основною причиною перегляду бюджетів та термінів виконання проектів. Навіть зараз, через багато років активного розвитку методів управління проектами та обсягом робіт в ІТ, scope creep залишається головним болем. За даними дослідження PMI, 44% завершених у 2015 році проектів страждали від цього явища. При цьому scope creep присутній навіть у проектах із фіксованим бюджетом (так звані fix price), де обсяги робіт та бюджет мали би бути чітко визначеними і зафіксованими наперед.

Часто вважається, що scope creep є проблемою виключно команди розробників, однак він також може викликати неприємності і для замовника продукту. Порушення встановлених дедлайнів, збільшення часу виходу на ринок, зростання бюджетів за проектами може бути шкідливим для всього бізнесу в цілому. Уявіть затримку релізу продукту на декілька місяців на конкурентному ринку, як наприклад, ринок мобільних телефонів. За цей час конкуренти зможуть вкинути на ринок більш ніж достатньо власних пристроїв, і навіть більше — покращити деякі їх характеристики. У той же час ваша компанія буде як і раніше на шляху до випуску свого первістка. Проблема може бути ще гіршою, якщо мова йде про продукти, які купуються один раз на багато років, наприклад, корпоративні інформаційні системи.

scope-creep-920

А як щодо програмного забезпечення для внутрішнього використання? Чи впливає scope creep на компанії в цьому випадку? Це ще більш очевидно, scope creep може стати причиною провалу проекту розробки програмного забезпечення, і компанія недоотримає прибуток через відсутність бажаного софта.

Чому виникає scope creep?

Scope creep, або розростання обсягів роботи, — це неконтрольовані зміни або безперервне зростання обсягу робіт проекту, що відбувається в основному через наступні причини:

— Нечітка мета і завдання проекту. Неможливість прослідкувати зв’язок функціональних вимог із цілями і завданнями, які ставить перед програмним забезпеченням бізнес замовника, призводить до створення рішення, яке містить в собі численні неочікувані функції, але не має жодного сенсу для кінцевих користувачів, оскільки не вирішує їхні проблеми.

— Швидкі зміни в бізнес-середовищі клієнта. Впровадження нових норм регулювання бізнесу клієнта, наприклад, неодмінно призведе до різкого зростання чи зміни вимог у відповідних частинах його програмного забезпечення.

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

— Відсутність документації з чітко визначеним початковим набором вимог. Навіть якщо є певний процес управління змінами, майбутнє побажання клієнта не може бути ідентифіковане як запит на зміну (change request), не порівнюючи його з початковими вимогами, зафіксованими в документації.

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

— Використання модних слів (buzzwords) або термінів без належного пояснення. Одне і те ж слово може мати різні значення в різних предметних областях. Наприклад, слово «кластер» може використовуватися як в хімії чи математиці, так і в музиці, і хоча вони мають подібне значення, використання таких слів без узгодження їхнього значення в рамках проекту призводить до нерозуміння вимог проекту і цілей клієнта.

— Відсутність процесу управління змінами. Кожне бажання клієнта, особливо важливого для компанії-розробника, розглядається як обов’язкова вимога без будь-якого аналізу наслідків та її впливу на загальний графік проекту.

— Навмисне збільшення обсягу без збільшення бюджету зі сторони клієнта. На жаль, випадки, коли клієнт докидає в беклог нові функції, не рідкість в наші дні. Зазвичай таким чином клієнт хотів би вирішити деякі додаткові проблеми без бюрократичних процедур, пов’язаних із ініціацією нового проекту та затвердження бюджету. В інших випадках часто додаються нові функції, які, на думку клієнта, є малими, легко і швидко програмуються. Однак все це може привести до scope creep та описаних вище наслідків.

— Активний мікроменеджмент зі сторони клієнта. Клієнти іноді ставлять завдання безпосередньо одному розробнику, обговорюючи та змінюючи деталі під час приватних Skype дзвінків без інформування всієї команди. Такі дії можуть принести хаос в процес розробки і сприяти появі scope creep на проекті.

Як зарадити розростанню обсягів робіт на проекті?

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

Не існує єдиного методу боротьби із scope creep, але деякі прості кроки можуть зменшити ризик його появи до прийнятного рівня:

— Вибрати найбільш відповідний тип проекту. Наприклад, проект з високим рівнем невизначеності, безумовно, не найкращий кандидат для fix price. Щоб уникнути потенційних проблем із зростанням обсягів робіт, не варто соромитися запропонувати клієнту так звану discovery фазу перед стартом активного кодування, коли команда професіоналів, зазвичай бізнес-аналітиків та архітекторів, тісно співпрацює із клієнтом для виявлення його бізнес-потреб та узгодження архітектури програмного рішення.

— Розумійте бізнес-потреби клієнта. Деякі розширення об’єму робіт можуть бути продиктовані не бізнес-потребами, а бажанням зробити продукт кращим на вигляд, або просто додати «вау» ефект. Тим не менше, ви не зможете відокремити один тип запитів від іншого, не розуміючи реальні потреби клієнта. Переконайтеся в тому, що вся команда розуміє бізнес-цілі, і ряд запитів на зміну зникне. Іноді навіть замовникам необхідно нагадати про цілі проекту для запобігання появи зайвого функціоналу.

— Слідкуйте за бізнес-контекстом клієнта. Деякі види змін можна передбачити: наприклад, нові правила уряду для медичних працівників майже напевно спричинять зміни в програмному забезпеченні лікарень. Моніторинг основних тенденцій дозволить виявити потенційні зміни на самих ранніх стадіях; разом з проактивним підходом він може перетворити зміни в нову можливість для вашої команди.

— Не скупіться на фазу discovery. Discovery ваша потужна зброя проти scope creep, і якщо ви вирішили використовувати її, переконайтеся, що вона потрапить в ціль. Оцініть, скільки бізнес-аналітиків і часу вам буде потрібно, щоб виявити і проаналізувати потреби. Слід пам’ятати, що розробка програмного забезпечення — це командна гра, і недостатньо просто виділити аналітика для проекту; для ефективного discovery ви також повинні з самого початку планувати час і залучення зацікавлених сторін у проекті.

— Документуйте початкові вимоги. Вимоги, отримані від клієнта, або ті, що виявились під час discovery, з якими ви збираєтеся почати проект, повинні бути зафіксовані в документі. Незалежно від того, як називатиметься цей документ і як він буде виглядати (формальна специфікація SRS або просто пріоритизований список завдань), і ви, і замовник повинні погодитися, що це базовий рівень, відповідно до якого буде оцінюватися будь-який майбутній запит.

— Задокументуйте і те, що виходить за рамки проекту (out of scope). Не тільки ті функції, які повинні бути розроблені під час проекту, повинні бути задокументовані, список функцій, які однозначно не повинні бути включеними в проект, такі як інтеграція з інструментами сторонніх розробників, також є хорошою ідеєю. Попередньо визначений список речей, які не будуть реалізовані в ході проекту, може допомогти в класифікації нових запитів як розширення обсягів робіт на проекті.

— Фіксуйте та перевіряйте свої припущення. Хоча припущення не є бажаними для будь-якого виду вимог і можуть бути навіть шкідливим для fix price проектів, іноді команда змушена їх робити, щоб визначити обсяг робіт і забезпечити оцінку вартості проекту. Такий підхід може бути прийнятним тоді і тільки тоді, якщо припущення фіксуються і комунікуються разом з іншими вимогами. Клієнт і команда повинні розуміти, якщо будь-яке із припущень спростоване, окремі функції або навіть весь обсяг може бути переглянутий і повторно оцінений.

— Створення та підтримка процесу управління змінами. Зміни в обсягах проекту відбудуться в будь-якому випадку, і єдиний спосіб, як ми можемо зробити цей процес безболісним, це контролювати їх. Визначений і доведений до відома всіх зацікавлених сторін процес управління змінами допомагає уникнути ситуацій, коли будь-який запит негайно розглядається як елемент беклогу. Типові активності з управління змінами, такі як аналіз впливу, розгляд зацікавленими сторонами і офіційне затвердження, допомагають переконатися, що зміни узгоджуються з цілями і завданнями проекту.

— Трасування бізнес-вимог до функціональних. Трасування вимог допомагає керувати обсягом робіт і аналізувати вплив змін. Трасування вимог до бізнес-цілей гарантує, що всі потреби зацікавлених сторін задовольняються.

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

]]>
http://skynin.xyz/duplicate/scope-creep-prichini-i-naslidki/feed/ 0
Почему программист не отвечает на звонки? http://skynin.xyz/zakazchikam/pochemu-programmist-ne-otvechaet-na-zvonki/ http://skynin.xyz/zakazchikam/pochemu-programmist-ne-otvechaet-na-zvonki/#respond Wed, 14 Dec 2016 20:58:44 +0000 http://skynin.xyz/?p=952 На фриланс биржах заказчики часто жалуются

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

Причин конечно может быть много.

stul-v-stule-barokko-rdw_enl

Назову основные:

  • Не рассчитывал что заказ окажется таким сложным для него. И что каждая последующая доделка, на вид по сложности как и предыдущие – занимает все больше времени.
  • Неправильно спроектировал приложение. Набросал все в кучу, и теперь сам в ней не может разобраться. А переписывание с нуля – время кто выделит?
    как и предыдущий пункт – причина кратко называется – рост технического долга.
  • Занизил цену, специально, или по неопытности – абы взять заказ. Рассчитывая что потом можно будет как-то уговорить на увеличение бюджета.
  • Взял более денежный проект. И этот стал ему неинтересен, ввиду “недополучения прибыли”(=убыточности) на более денежном.

Но во всех случаях – сказать напрямую заказчику об этом – сложно. Не посылать же его нах открытым текстом.

Поэтому выход проще – просто исчезнуть. Может заказчик сам отцепится.

Советы же такие

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

taburetka

и прекратите спрашивать сколько стоит нечто на чем можно сидеть за столом!

Но, если вы знаете точный ответ на “Сколько стоит автомобиль?”…

 

]]>
http://skynin.xyz/zakazchikam/pochemu-programmist-ne-otvechaet-na-zvonki/feed/ 0
17 уникальных функций для оптового интернет-магазина http://skynin.xyz/duplicate/17-unikalnyh-funktsij-dlya-optovogo-internet-magazina/ http://skynin.xyz/duplicate/17-unikalnyh-funktsij-dlya-optovogo-internet-magazina/#respond Wed, 14 Dec 2016 14:09:59 +0000 http://skynin.xyz/?post_type=duplicate&p=941

Автор: Степан Овчинников,
ИНТЕРВОЛГА (Генеральный директор)

Причины, по которым B2B платформа требует индивидуального проектирования.

Скажешь «интернет-магазин» — что вспоминается? Красивый сайт для розничных продаж.

Корзина, крупные фотографии, «продающая карточка товара», «оформить заказ» и так далее.

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

Сложно сказать в этой теме что-то новое.

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

На первый взгляд это то же самое. Товары, заказы, личный кабинет.

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

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

Клиент оптового интернет-магазина в отличие от розничного покупателя — профессионал. Он хорошо разбирается в ассортименте.

У него больше задач, меньше времени, ему не надо «продавать», его надо быстро и удобно обслуживать.

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

1 Персональные цены
2 Упрощенная навигация и быстрый поиск
3 Товары без картинок и подробных описаний
4 Табличная форма заказа
5 Оптовые единицы измерения
6 Заказ по списку
7 Несколько заказов одновременно
8 Личный кабинет с платежным балансом счета
9 «Поговорить с вашим менеджером»
10 Бонусный счет, уровни по объему продаж
11 Счета-фактуры, товарно-транспортные накладные, договоры, акты
12 Заказ с удаленного склада
13 Просмотр остатков на региональных складах, отслеживание перемещений
14 «Документы для розничного покупателя»
15 «Мои клиенты»
16 Аналитика продаж
17 Интеграция с учетной системой и логистикой

Выводы и оценка

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

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

Но дело того стоит.

Комментарии

Оригинал: http://www.intervolga.ru/blog/projects/17-unikalnykh-funktsiy-dlya-optovogo-internet-magazina/

]]>
http://skynin.xyz/duplicate/17-unikalnyh-funktsij-dlya-optovogo-internet-magazina/feed/ 0
Сколько стоит создание сайта http://skynin.xyz/duplicate/skolko-stoit-sozdanie-sajta/ http://skynin.xyz/duplicate/skolko-stoit-sozdanie-sajta/#respond Sat, 10 Dec 2016 14:06:33 +0000 http://skynin.xyz/?post_type=duplicate&p=928 Оригинал на сайте вебстудии Realstudio
Posted on

Чем отличается веб-дизайн от веб-разработки?

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

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

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

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

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

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

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

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

]]>
http://skynin.xyz/duplicate/skolko-stoit-sozdanie-sajta/feed/ 0
Почему не работает иерархия? http://skynin.xyz/note/pochemu-ne-rabotaet-ierarhiya/ http://skynin.xyz/note/pochemu-ne-rabotaet-ierarhiya/#respond Thu, 08 Dec 2016 08:58:04 +0000 http://skynin.xyz/?post_type=note&p=917 15284068_1242799542450397_707052758592025199_n

]]>
http://skynin.xyz/note/pochemu-ne-rabotaet-ierarhiya/feed/ 0
Вам точно нужен дизайн под заказ? http://skynin.xyz/zakazchikam/vam-tochno-nuzhen-dizajn-pod-zakaz/ http://skynin.xyz/zakazchikam/vam-tochno-nuzhen-dizajn-pod-zakaz/#respond Thu, 08 Dec 2016 06:42:10 +0000 http://skynin.xyz/?p=911 Существует практика разработки веб-сайта:
1. Рисуется дизайн. На выходе – PSD файл.
2. Затем верстается html
3. Затем этот html “натягивается” на CMS.

15439771_295139564216767_1872107918819075995_n

Вопрос – а у вас есть деньги и время на качественное выполнение этих трех этапов?

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

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

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

Page builder by Origin
Elementor
LiveComposer plugin

Для создания диалоговых форм

Ninja forms
Ultimate form builder lite

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

Итого, для CMS рекомендую другой порядок работ:

  1. Выбирается тема для CMS.
  2. Программист используя программные и визуальные средства – структурирует показ информации на фронтенде
  3. Дизайнер с верстальщиком доводят отображение на фронтенде до нужного дизайна

Мнения из Бизнес на сайтах: как 120 веб-студиям Украины удается зарабатывать на 40% больше

Антон Золотарев, веб-студия IT4U

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

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

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

Клиент утверждает — верстальщик собирает сайт по готовым CSS и JS.

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

Алексей, веб-студия «Аваланч»

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

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

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

]]>
http://skynin.xyz/zakazchikam/vam-tochno-nuzhen-dizajn-pod-zakaz/feed/ 0
Вышел PHP 7.1 http://skynin.xyz/note/vyshel-php-7-1/ http://skynin.xyz/note/vyshel-php-7-1/#respond Fri, 02 Dec 2016 11:08:38 +0000 http://skynin.xyz/?post_type=note&p=905 выходом PHP версии 7.1.0. Давайте сделаем краткий обзор RFC, вошедших в этот релиз.]]> Petr Myazin

Вышел PHP 7.1 — сделаем обзор RFC, вошедших в свежий релиз.

Привет мир!
Вы слушаете «Пятиминутку PHP», выпуск номер 25 — подкаст о новостях из мира PHP, интересных постах в блогах и современных подходах к разработке.

Рад всех поздравить с выходом PHP версии 7.1.0. Давайте сделаем краткий обзор RFC, вошедших в этот релиз.

Напомню, что список всех RFC по уже вышедшим версиям и планирующиеся на будущее можно найти по адресу wiki.php.net/rfc

  • Session ID without hashing
    ID сессии издревна генерировался с помощью специальной хэш-функции. Самое главное в этом процессе — сделать ID сессии непредсказуемым, чтобы посторонний человек не смог его подобрать. Теперь используется функция php_random_bytes() обёрнутая в вызов bin_to_readable().
  • Asynchronous Signal Handling
    В предыдуших версиях PHP сигналы от операционной системы обрабатывались синхронным способом. Была возможность запустить и асинхронную обработку, но это просаживало производительность. Благодаря улучшениями виртуальной машины PHP 7.1 стало возможным обрабатывать сигналы асинхронно без дополнительного overhead’а.
  • Fix inconsistent behavior of $this variable
    Зналили вы, что была возможность переопределить переменную $this тысячью разными способами, например, сделать unset или использовать в качестве переменной для значения в foreach? Теперь все способы испортить $this будут вызывать Fatal Error или Exception Error.
  • Replace «Missing argument» warning with «Too few arguments» exception
    Называние говорит само за себя: если мы забыли передать требуемые аргументы в функцию, то теперь получим Exception (раньше был Warning).
  • Nullable Types
    А что если функция может принимать в качестве аргумента какой-то определённый тип или null? Мы всегда писали в определении функции имя аргумента = null. В PHP 7.1 добавлен новый синтаксис: знак вопроса сразу после типа аргумента. Например, пишем: function foo(string? $x) — аргумент $x может принимать значение типа string или null. Обращу внимание, что новая запись не эквивалентна старой. Если используем новый синтаксис со знаком вопроса, то аргумент от этого не становится не обязательным. Он должен быть явно передан в функцию, даже если мы хотим передать null, иначе получим Exception «too few arguments» из предыдущего RFC. Также этот синтаксис со знаком вопроса позволяет отметить и тип возвращаемого значения, как nullable.
  • Square bracket syntax for array destructuring assignment
    Альтернативный синаксис для конструкции list() о котором я подробно рассказывал в выпуске №21 — теперь вместо list можно использовать квадратные скобки.
  • Warn about invalid strings in arithmetic
    При использовании арифметических операций со строками, которые не являются числами в чистом виде, PHP не выдавал никаких сообщений, а просто конвертировал строки в числа. Например, если сложить «10 яблок» + «5 апельсинов» получим результат 15. В PHP 7.1 такая операция покажет нам предупреждение уровня E_NOTICE или E_WARNING (результат при этом всё равно будет 15).
  • Allow specifying keys in list()
    На этот этот RFC я опять же делал обзор в выпуске №21 — конструкцию list теперь можно использовать не только для разбора пронумерованных массивов, но и для ассоциативных массивов, явно указывая ключи, которые мы хотим извлечь.
  • Iterable
    У нас есть тип array и интерфейс Traversable по которым можно итерироваться с помощью foreach. Но у нас не было возможности определить тип аргумента функции или тип возвращаемого значения, как array или Traversable одновременно, т.е. когда мы заранее не знаем, какой именно тип будет использован. Новый псевдо-тип Iterable покрывает и массивы и Traversable объекты. Вы спросите, что за псевдо-тип такой и как его использовать. Вот вам ближайшая аналогия: вспомните псевдо-тип callable.
  • Generalize support of negative string offsets
    Появилась возможность использовать отрицательное смещение при работе со строками. Например, можно получить второй символ с конца строки, указав для строковой переменной $foo[-2]. Поддержка отрицательного смещения также появляется и в функциях strpos, mb_strpos, file_get_contents и многих других (полный список читайте в RFC по ссылке).
  • Closure from callable function
    Хотите создавать Closure (анонимные функции с захватом контекста) из переменных типа callable просто, в одну строку и быстро в рантайме без рефлексии? Теперь у класса Closure появился публичный статический метод Closure::fromCallable(). В описании к RFC есть пара удачных примеров, посмотрите, чтобы понять зачем это может пригодиться.
  • Deprecate mb_ereg_replace eval option
    Опция e в функциях mb_ereg_replace и mb_eregi_replace объявлена устаревшей (depricated). Эта опция позволяла выполнить eval, что без должного внимания могло привести к проблемам с безопасностью.
  • Deprecate (and remove) Mcrypt
    В PHP 7.1 вызов всех mcrypt_* функций будет показывать предупреждение E_DEPRECATED, а в одной из будущих версий (7.2 или 8.0) планируется вынести эти функции из ядра в отдельное PECL расширение.
  • OpenSSL AEAD support
    В функции openssl_decrypt и openssl_encrypt добавлены параметры для поддержи так называемого режима AEAD (Authenticated Encrypt with Associated Data) — те кто в теме, поймут. Я не в теме.
  • Void Return Type
    Новый тип void для описания возвращаемых результатов. Если мы ненароком вернём из такой функции некое значение (включая null), то получим Fatal Error. При этом сделать просто return (без какого либо значения) для раннего выхода из функции можно — это и будет void. Обратите внимание, что в качестве типа аргументов функции void не применим.
  • Class constant visibility modifiers
    Теперь перед объявлением констант можно указывать модификаторы доступа private, protected и public. Если не указать ничего, то константа считается public, как и в предыдущих версиях.
  • Octal Overflow Protection
    В PHP можно указать значение одного байта используя восьмеричную систему, написав в двойных кавычках обратный слэш (\) и восьмеричное число из трёх цифр. Наример, "\101" — это число 65 в десятичной системе. Однако, чтобы уложиться ровно в 1 байт, максимальная восмеричная форма — это "\377". Предыдущие версии PHP не выводили ошибок при переполнении, т.е. при указании числа большего чем 377. В PHP 7.1 будет выведен Warning.
  • RNG fixes and changes
    Несколько улучшений в функциях работы со случайными числами, которые, внимание, повлекли за собой breaking change: при заданном значении seed, функции mt_rand, rand, array_rand, shuffle, str_shuffle и crypt теперь вернут иное значение, чем в предыдуших версиях. Это может стать причиной трудно понимаемых багов при переходе на 7.1. В моих проектах, в частности, есть один фрагмент, который полагается на заданный seed перед вызовом array_rand.
  • Add HTTP/2 Server Push support to ext/curl
    В PHP 7.0 в расширении curl появилась поддержка нескольких фич из HTTP/2. В PHP 7.1 добавляется ещё одна очень классная функциональность: поддержка HTTP/2 Server Push. Это актуально, если вы используете PHP приложение в качестве клиента и подключаетесь к внешнему ресурсу по HTTP/2.
  • TimeZone::getWindowsID
    В класс IntlTimeZone добавлено два статических метода: getWindowsID() и getIDForWindowsID(). Пример: если вызвать IntlTimeZone::getWindowsID("America/Los_Angeles") то получим "Pacific Standard Time". И наоборот, если вызвать IntlTimeZone::getIDForWindowsID("Pacific TimeZone"), то получим "America/Los_Angeles". Эти методы появились благодаря обновлению библиотеки ICU.
  • Multi catch
    В блоке catch при работе с исключениями можно поймать несколько исключений одновременно, перечислив их типы через вертикальную черту.
  • Forbid dynamic calls to scope introspection functions
    В PHP есть ряд функций, которые меняют или читают переменные из текущей области видимости: extract(), compact(), get_defined_vars(), parse_str(), mb_parse_str(), assert() со строковым аргументом, func_get_args(), func_get_arg() и func_num_args(). Теперь эти функции запрещено вызывать динамически, т.е. с помощью call_user_func() или array_map() и подобными способами. Во-первых, динамический вызов этих функций давал различный результат в разных версиях PHP и в целом такой код был сложен для понимания и зачастую имел неожиданный результат. Во-вторых, динамический вызов этих функций сложно оптимизировать с точки зрения виртуальной машины PHP и это сильно ударяло по производительности. Ещё раз отмечу, что сами функции никуда не исчезают, просто их нужно вызывать явно!
  • Add curl_multi_errno(), curl_share_errno() and curl_share_strerror()
    Расширение curl создаёт ресурс одного из трёх типов: так называемый handle из функции curl_init(), Multi Handle из функции curl_multi_init() и Share Handel из функции curl_share_init(). Чтобы получить ошибку соединения у нас была функция curl_errno(), которая применима для первого типа Handle. Но не было аналогичных функций для Multi Handle и Share Handle. Теперь они появились: curl_multi_errno() и curl_share_errno() — возвращают код ошибки; curl_multi_strerror() и curl_share_strerror() — возвращаю описание ошибки.
  • Throw Error in Extensions
    В PHP 7.0 мы смогли перехватывать стандартные ошибки PHP как исключение Error, но это ещё не работало в расширениях. В PHP 7.1 подтянулись и расширения, такие как Date, DOM, mbstring и другие.
  • More precise float value handling
    Улучшения в точности обработки float значений, что сразу будет заметно при работе с функциями serialize(), json_encode().
  • Additional Context in pcntl_signal Handler
    Добавлен второй аргумент в виде массива к callback функции при использовании pcntl_signal — теперь наш обработчик сигналов получит вторым аргументом дополнительную информацию, контекст.
  • Add session_create_id()
    Добавлиена функция session_create_id(), про котороую лучше прочитать в документации — тонкости работы с сессиями такие тонкие…
  • Add session_gc()
    Добавлена функция session_gc() для принудительного запуска сборщика мусора старых сессий. За подробностями зачем это нужно и в каких случаях применять опять же рекомендую почитать документацию.

Это обновление не такое громкое, как 7.0. Нет информации о серьёзном увеличении производительности, зато подчищены некоторые старые хвосты, добавлено немного синтаксического сахара, в целом годный инкрементальный релиз. Обновляемся по плану!

]]>
http://skynin.xyz/note/vyshel-php-7-1/feed/ 0
За что платят программисту в офисе, и не платят фрилансеру http://skynin.xyz/common/za-chto-platyat-v-ofise/ http://skynin.xyz/common/za-chto-platyat-v-ofise/#respond Wed, 30 Nov 2016 08:39:28 +0000 http://skynin.xyz/?p=896

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

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

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

плюс удаленщики очень плохо делятся этим т.н. проектным опытом. Им это просто не выгодно т.к. чаще всего оплата идет за часы потраченные на конкретные задачи, а время потраченное на консультации других членов команды чаще всего нигде не учитывается. Да и трудно его учитывать если приходится по 10-20 раз на день отвечать на чьи-либо вопросы по 5-15 минут. Проще отморозиться тем или иным способом чтобы отстали побыстрее и впредь не приставали.

(с) AlexTest

хабр: Почему работодатели не любят удалённую работу?

Почему такие сложности с удаленкой?

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

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

]]>
http://skynin.xyz/common/za-chto-platyat-v-ofise/feed/ 0
Какую оплату за проект лучше выбрать фрилансеру: фиксированная или почасовая ставка? http://skynin.xyz/duplicate/kakuyu-oplatu-za-proekt-luchshe-vybrat-frilanseru-fiksirovannaya-ili-pochasovaya-stavka/ http://skynin.xyz/duplicate/kakuyu-oplatu-za-proekt-luchshe-vybrat-frilanseru-fiksirovannaya-ili-pochasovaya-stavka/#respond Thu, 24 Nov 2016 13:52:45 +0000 http://skynin.xyz/?post_type=duplicate&p=924 Конспект Какую оплату лучше выбрать – ч1 и Какую оплату лучше выбрать – ч2

freelance.today
Елизавета Гуменюк

Фиксированная ставка:

Плюсы…

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

Минусы…

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

Для каких проектов подходит

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

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

Почасовая ставка

Плюсы…

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

Минусы…

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

Для каких проектов подходит

  • Долгосрочные или постоянные.
  • Когда клиент не имеет четких рамок, склонен к постоянным изменениям или не знает, чего хочет.
  • Для новых клиентов или если у вас нет солидного портфолио.
  • Вы не знаете, как определить стоимость проекта.
  • В случае, когда клиент не хочет оплачивать любым другим способом.
]]>
http://skynin.xyz/duplicate/kakuyu-oplatu-za-proekt-luchshe-vybrat-frilanseru-fiksirovannaya-ili-pochasovaya-stavka/feed/ 0
Внедрение без ТЗ: дорога в никуда http://skynin.xyz/duplicate/vnedrenie-bez-tz-doroga-v-nikuda/ http://skynin.xyz/duplicate/vnedrenie-bez-tz-doroga-v-nikuda/#respond Wed, 23 Nov 2016 08:18:56 +0000 http://skynin.xyz/?post_type=duplicate&p=892 конспект с хабра: Внедрение CRM без ТЗ: дорога в никуда (Блог компании RegionSoft Developer Studio)

Доработка типового программного обеспечения под требования заказчика — это обыденное дело, если оно правильно организовано. Однако часто можно встретить примеры, когда разработчики берутся выполнить работы без ТЗ (технического задания) по настоянию заказчика. Что происходит в итоге? Обе стороны загоняют себя в яму, которую выкопали сами. Разработчик не подозревает, что он будет вынужден выполнить объем работ во много раз больше предполагаемого, и рано или поздно остановит эти работы, нахлебавшись раздувшихся аппетитов заказчика, которые будут расти в геометрической прогрессии, не имея формальных ограничений. В такой ситуации разработчик рискует никогда не завершить работу, а заказчик — никогда не получить нужного результата. На ранних этапах развития компании мы в этой яме побывали неоднократно, поэтому представляем вторую часть наших историй о ТЗ — когда его нет.

ТОП-6 фраз клиентов — верный способ разозлить разработчика

И так всё понятно — зачем тратить время?

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

Здесь всё просто! Да я на пальцах объясню

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

Я не умею его составлять

Комментарий разработчика: Но Вы же можете на простом языке озвучить требования к функционалу, которые должны быть созданы. Это можно сделать в тезисном виде, а детали оговорить устно. Но в итоге, ТЗ составляет разработчик на основе Ваших требований и с учетом всех деталей. Ведь Вы не вправе рассчитывать на то, что Вам будут сделаны работы, не оговоренные в ТЗ! Вы за них даже не платили… Верно?

Почему я должен платить за то, что войдёт в следующий релиз?

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

Да программисты ничего не понимают в продажах (бизнесе, складе, бухгалтерии и т.д.)!

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

Вы составляете ТЗ за деньги?!

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

Я подразумевал другое!

Комментарий разработчика: Мысли человека неисповедимы. Сегодня я хочу зеленый чай, а завтра меня потянет на кофе. Если нет ТЗ, то невозможно спрогнозировать, что заказчик подразумевал, когда говорил, например, что «по нажатию на зелененькую кнопочку должна происходить интеграция с 1С». Что это означает? Трактовок может быть масса. Может нужно загрузить оплаты из 1С в CRM? А может выгрузить счета? Или нужно вывести отчет о складских остатках? В ТЗ должна быть однозначность.

d4f7316f7221506f48eceb43539a9451

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

]]>
http://skynin.xyz/duplicate/vnedrenie-bez-tz-doroga-v-nikuda/feed/ 0
Designing Data-Intensive Applications (book) http://skynin.xyz/note/designing-data-intensive-applications-book/ http://skynin.xyz/note/designing-data-intensive-applications-book/#respond Mon, 21 Nov 2016 06:29:29 +0000 http://skynin.xyz/?post_type=note&p=887 Load from dataintensive.net

Don’t just hack it together

NoSQL… Big Data… Scalability… CAP Theorem… Eventual Consistency… Sharding…

Nice buzzwords, but how does the stuff actually work?

As software engineers, we need to build applications that are reliable, scalable and maintainable in the long run. We need to understand the range of available tools and their trade-offs. For that, we have to dig deeper than buzzwords.

This book will help you navigate the diverse and fast-changing landscape of technologies for storing and processing data. We compare a broad variety of tools and approaches, so that you can see the strengths and weaknesses of each, and decide what’s best for your application

]]>
http://skynin.xyz/note/designing-data-intensive-applications-book/feed/ 0
MongoDB http://skynin.xyz/wiki/mongodb/ http://skynin.xyz/wiki/mongodb/#respond Thu, 17 Nov 2016 13:33:28 +0000 http://skynin.xyz/?post_type=yada_wiki&p=877 После трех месяцев в разработке все прекрасно работало.

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

Почему вы никогда не должны использовать MongoDB


из Почему эти ваши модные NoSQL решения не так уж хороши

Пробовали MongoDB. К счастью, с этой СУБД мне пришлось работать совсем недолго. MongoDB не выдерживает никакой критики, и ее недостатки, похоже, поняли уже все, кроме, разве что, самых упоротых программистов на Node.js. Вручную шардированный PostgreSQL, который, напомню, уже давно умеет формат JSONB, с самым тупым и никем не протестированным скриптом на Python для автофейловера, будет куда более удачным выбором, чем MongoDB. Подробности смотри у Афира и еще, например, вот тут. Выбрав PostgreSQL, вы получите все тоже самое, только куда более стабильное, не теряющее данные, а также с нормальными локами, вьюхами, транзакциями, джоинами и вот этим всем.

]]>
http://skynin.xyz/wiki/mongodb/feed/ 0
Без ТЗ: почему клиент не хочет его http://skynin.xyz/duplicate/bez-tz-pochemu-klient-ne-hochet-ego/ http://skynin.xyz/duplicate/bez-tz-pochemu-klient-ne-hochet-ego/#respond Sat, 12 Nov 2016 09:17:46 +0000 http://skynin.xyz/?post_type=duplicate&p=879 или

с шашкой на танки!

хабр Оригинал на Хабре

1. «У нас очень маленький и простой проект»

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

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

Еще в народе популярен похожий подход: «Нет времени на ТЗ, нужно скорее запускаться».

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

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

2. «Это коммерческая тайна, мы вам не расскажем»

Как-то я писал ТЗ на большую и сложную медицинскую систему… Но это было приложение для театров. Чтобы я не догадался, что речь про театры, клиент рассказывал мне про врачей. Когда же был наконец подписан NDA, мне торжественно объявили: «Ну это же одно и тоже! Механика похожая: актеры или врачи — какая разница? Почему вы так расстроились?».

Казалось бы, почему не подписать со мной NDA сразу? Но нет, бумага не дает 100%-ю гарантию. Надо же познакомиться и узнать меня получше! Вдруг я раскрою военную тайну?..

Был еще секретный сайт знакомств: «У нас есть такие приборы, но мы вам о них не расскажем.» Или же: «У нас тут мега-секретный проект, скажите сколько стоит?».

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

3. «Сначала скажите сколько стоит!»

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

Вопрос цены проекта до составления ТЗ, наверное, самый частый. Хочется в двух словах описать проект и собрать со всех знакомых и незнакомых команд котировки. Обычно замечание, что цена может вырасти в 10-20 раз по мере детализации никак клиента не впечатляет: “Ну, вы же — хорошие ребята! Вы же так с нами не поступите!”.

В целом желание клиента получить котировки и провести мини-тендер — это нормально, но делать это надо, разослав командам полноценное ТЗ!

4. «Почему мы должны платить за то, что нужно вам?»

Клиент прикидывается золотой антилопой и искренне негодует, что вы пытаетесь заставить его заплатить за капкан, которым хотите его поймать. “Мы же компания “УХ!” Если мы будем в числе ваших клиентов, все скажут: “Ах!” Требовать с таких клиентов, как мы, деньги с порога — просто неприлично!” Однако, дорогой клиент, черепки из-под твоих копыт уже стоят поперек горла, и хочется крикнуть: “Довольно!”.

Если клиент не хочет платить за ТЗ, плохо будет всем:

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

Во-вторых, если клиент не хочет вам платить за ТЗ, то захочет ли он платить за разработку в полном объеме?

К бесплатным ТЗ клиенты часто относятся легкомысленно и воспринимают их скорее как коммерческое предложение, а не как что-то требующее внимания, напряжения участия. По итогам работы по бесплатному ТЗ вы можете услышать: «Нам нужно решение задачи, а не ваши бумажки!»
Почему же нужно платить за ТЗ? Например, потому, чтобы не оплачивать риски, которые обычно закладываются в разработку без него.

5. «Мы хотим увидеть варианты!»

Мое любимое. С этими товарищами каши не напишешь, т.к. вымучить 3-4 разных ТЗ на выбор — выше моих сил.

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

Смех тут в том, что если вы слышите: «Мы хотим увидеть варианты!» — то все равно начинать необходимо с ТЗ. Только ТЗ нужно составить не на систему, а на идеи. Да-да, бывает мини-задание на идеи. Очень полезная вещь, рекомендую!

6. «А вдруг у нас изменится концепция»

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

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

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

7. «Нам нужен точный клон этого…»

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

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

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

Пишу, а в почте как раз очередной запрос на точный клон этого…

8. «Придумайте сами — вы же специалисты!»

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

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

9. «Мы сами напишем/написали ТЗ»

Однажды подключившись к одному, слегка затянувшемуся на несколько лет проекту, я наконец спросил: «Ребята, а у вас было ТЗ?» На что мне ответили: «Где-то у нас был видеоролик, на котором клиент рассказывает что хотел.»

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

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

10. «Другие программисты не примут ваше ТЗ»

Довольно часто слышу это возражение. Обычно принимают, так что смело предлагаю переписать под новых разрабов, если не примут. Был забавный случай. Сдал ТЗ, а разрабы на стороне клиента говорят, что это не ТЗ. Ну давайте ваш формат — переделаю. Формата нет. Ну скажите что не нравится? Говорят, мол, не по ГОСТу! Ну, давайте сделаю по ГОСТу, но за доп. плату. Вы ГОСТ-то видали? Похоже, что нет.

Из опыта я знаю, что очень многие разрабы не читают ТЗ. Поэтому лучший способ с этим бороться — читать его вместе с ними. Лучше всего воспринимается сценарий действий пользователя и описание экранов. Эти два документа обычно исчерпывающе описывают систему. Иногда к этому добавляется API и таблицы с математикой, если есть.

А вот есть, например, ТЗ по ГОСТу с тендерных площадок, или же гигантские API на 300 типов запросов. Тут мне приходится переводить уже для разрабов на человеческий язык.

]]>
http://skynin.xyz/duplicate/bez-tz-pochemu-klient-ne-hochet-ego/feed/ 0
WebAssembly как киллер фича, и возможный убийца 2D Canvas http://skynin.xyz/note/webassembly-kak-killer-ficha/ http://skynin.xyz/note/webassembly-kak-killer-ficha/#respond Tue, 01 Nov 2016 10:45:49 +0000 http://skynin.xyz/?post_type=note&p=864 по поводу тяжелых вычислений при рисовании канвасом
прочел вот очередную новость про WebAssembly  Chrome, Firefox и Edge перешли на новый этап тестирования технологии WebAssembly

начну с выводов:
я не удивлюсь если выход в массы этой технологии в связке с “Unity”подобными движками – оставит далеко позади фронтенды построенные на канвасе в плане быстродействия = комфортности работы пользователя.
технологии на самом деле редко становятся киллер фичей ПО. но, бывает. и WebAssembly для задач где только канвасом рисовать – может оказаться именно такой.

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

…просто вспомнил некоторые технические подробности геймдева до эпохи 3D акселераторов. и на ум пришла аналогия:
тогда, чтобы нарисовать точку, или линию можно было использовать функции BIOS. и все красиво было в коде. чистая математика.
но видеопамять то организована соооовсем по другому. там нет никаких пикселей по кооридитам. там битовые слоеные пироги, ака наполеон, собираемые в банки памяти. чтобы изменить 1 бит у пикселя, надо вырезать слой по порядковому номеру бита, в нем заменить конкретный бит, и записать весь этот слой обратно в память.
в итоге все толковые игры той поры так и делали – работали с портами видеокарты, и с битовыми плоскостями.

сейчас, насколько знаю по верхам, веб браузеры не предоставляют доступ к их “видеопамяти” в виде рендера. и приходится рисовать только предоставляемым ими “BIOS”. (над которым еще и DOM дерево).
а для WebAssembly будет открыт низкоуровневый доступ к рендеру. и он, рендер браузера, наверняка работает совсем не так, не по координатам пикселя.

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

как ушла в архивы и работа с  битовыми плоскостями VGA (VESA), после появления 3D акселераторов, с шейдерами-шмейдерами, потоковыми процессорами и т.п.

мы сейчас делаем 3Д вид на WebGL на библиотеке Threejs
и параллельно экспериментируем с Unreal Engine 4

и это правильно. быстро глянул в гугл:

циатата из 3D-графика через WebGL и ThreeJS … ThreeJS поддерживает некоторые другие движки, такие как 2D Canvas. В этом примере мы хотим WebGL. Если он не может создать WebGLRenderer, то вернётся обратно к 2D Canvas. Хотя Canvas работает гораздо медленнее(!), это может быть лучше, чем ничего.

то есть я угадал – 2D Canvas это как BIOS в те древние времена когда я побыл немножко в геймдеве :)
но не угадал с предоставлением “портов”, уже есть возможность – WebGL

]]>
http://skynin.xyz/note/webassembly-kak-killer-ficha/feed/ 0
Менеджерско-программистская выжимка за 17 лет в отрасли http://skynin.xyz/duplicate/menedzhersko-programmistskaya-vyzhimka-za-17-let-v-otrasli/ http://skynin.xyz/duplicate/menedzhersko-programmistskaya-vyzhimka-za-17-let-v-otrasli/#respond Mon, 31 Oct 2016 06:55:09 +0000 http://skynin.xyz/?post_type=duplicate&p=920

[Об авторе: Владимир Железняк — пишет код, управляет проектами. Два раза дауншифтился с менеджерских позиций в чистый код, потом обратно вырастал. Вёл бесплатные курсы, консультировал джунов и бизнес, работал в офисе и удаленно].

Оригинал статьи на DOU.ua

Итак:

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

— Люди развиваются неравномерно. Кто-то качает код, кто-то разговоры, кто-то английский. Идеала не будет — ни у тебя, ни у сотрудников, ни у твоих детей.

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

— И программисты, и бизнес любят связь в своём формате: «С меня код, с вас деньги и уважение» и «С меня список задач и деньги, с вас работающая программа». Люди неосознанно избегают общения сверх этого. Чем выше человек в иерархии, тем проще ему оградить себя от тревожных сигналов и тем вреднее это для компании.

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

— Менять процесс нужно только в том случае, если результат кого-то не устраивает и этот кто-то готов за это заплатить. Желание должно быть не «Ну ладно, давайте попробуем», а «Мы косячим в <…>, это проявляется в <узнаваемые всеми ситуации>, я готов к сложностям времени внедрения».

— Конфликты будут всегда, и это хорошо.

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

Это самое важное из моего личного опыта управления проектами. Большую часть я выкладывал у себя на Facebook, сюда выношу выжимку. В этой статье — мои субъективные наблюдения и гипотезы. Я не социолог и не проводил развернутых исследований. Есть что дополнить, особенно в реальных примерах, — пишите в комментах. Я убрал всю воду, а её больше всего было на стыках.

О найме

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

Такой вопрос — дурная практика, не нужно спрашивать. Я вообще пока не видел ни одного хорошего способа эффективного собеседования миддл+.

Хороший vs Плохой. Все менеджеры знают, чем хороший программист отличается от плохого. Причем это знание не совпадает между менеджерами. Мне сейчас удобно определение: «Джун — приносит хоть какую-то пользу компании выше своей зарплаты, синьор — может написать проект от и до, а что не сумеет (например, дизайн или тексты) — сможет поставить ТЗ».

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

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

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

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

Фрилансеры и удаленщики. Самые лучшие и самые худшие сотрудники мне попадались именно на фрилансе/удаленке.

«С++ за 21 день», «HTML за месяц» и другие сказочные курсы. После IT-курсов только от 5% до 20% поступивших находят работу. Остальные зря тратят время. Хотя вот буквально на днях слышал о результате в 60% — буду смотреть детальнее.

По моему опыту, на обучение с нуля до уровня «может приносить пользу работодателю» уходит от 400 до 900 качественных часов. Редко кто вытягивает больше 10 качественных часов в неделю на обучение без отрыва от основной работы. Больше 30 не вытягивает даже с отрывом. «Качественный час» — это когда таймтрекер останавливается при проверке почты/новостей/чай заварить, то есть любых прерываниях. У каждого есть свой предел «сколько я могу выучить/сделать для себя нового за день», при приближении к этому пределу КПД падает — и дальше есть смысл сидеть только для однотипной хорошо известной работы. Ну и бэкап заранее сделать.

Трудоустройство с нуля. Затраты на джуна — это не столько его зарплата, сколько время менеджера + рабочее место. И не важно, джун попросит 300 или 400 долларов. Фирме он будет стоить, к примеру 600 или 700. Не так уж и существенная разница, в общем-то.

О деньгах

Зарплата. Зарплата зависит от рынка труда куда больше, чем от кандидата. При растущем рынке наибольшей прирост ставки можно получить при смене работодателя. При падающем рынке — можно дольше удерживаться у старого работодателя. Примеры падающего рынка — кризис 2008-го и застывший сейчас рынок IT-труда в России.

Работодатель с удовольствием введет грейды, KPI и любую систему оценок, но… Зарплата по-прежнему будет зависеть от рынка, а не от KPI.

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

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

Экономика аутсорсера. Разница между внешним и внутренним рейтом обычно в два раза. Но при этом прибыльность аутсорс-компании — 10-15%. Остальное уходит на офис, отпуска, праздники, больничные, бенч, найм, менеджмент, железо, софт и еще десяток мелких пунктов.

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

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

Мотивация

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

Тема заезжена вдоль и поперек, пошла и баяниста, как анекдоты про Ржевского. Но если собрать десяток тимлидов и PM-ов и спросить: «Что болит?», то мотивация — самый частый ответ.

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

Топ-менеджеры и бизнес тоже друг на друга равняются.

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

Diff. Люди ведут себя по-разному. Кто-то ноет с самого начала, кто-то молча работает, кто-то прибегает с вопросом два раза в день. Не так важно, как они себя ведут, важно, если поведение меняется. Тут стоит придумать две-три гипотезы, почему так:
— Раньше ныл, теперь перестал? Может, что-то отрефакторил втихаря, а может, тупо забил и ходит по собеседованиям?
— Раньше молча работал, а теперь начал говорить на отвлеченные темы? Стал доверять? А может, хочет поделиться наболевшим, но не знает, как начать?
— Бегал с вопросами два раза в день, а теперь — раз в два дня? Либо научился, либо поставил на себе крест.

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

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

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

Менеджер-хамелеон принимает ту точку зрения, которая сейчас популярна среди собравшихся. Всем кажется, что он их поддерживает, и всё идёт хорошо. Поначалу.

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

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

Перфекционизм программистов. Перфекционизм у сотрудников поганит жизнь менеджеру:
— Бесконечные доделки;
— Перфекциониста на смежную задачу не перекинешь;
— Нытье: «Аааа, мне опять не дали отрефакторить нормально!»;
— Выгорание и увольнение.

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

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

Прерывания. Одно прерывание человеку обходится в 20-40 минут рабочего времени. И не важно — вы отвлекли человека на 30 секунд, либо на один час — вспоминать задачу и разгоняться он будет всё равно примерно полчаса. Более подробно можно почитать тут — «Не будите программиста».

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

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

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

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

Кстати, подавленный гнев часто вылазит в сарказм и насмешки.

Вместо выводов

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

]]>
http://skynin.xyz/duplicate/menedzhersko-programmistskaya-vyzhimka-za-17-let-v-otrasli/feed/ 0