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

В то же время, The Pirate Bay блокируется многими европейскими интернет-провайдерами. По мнению антипиратских организаций и звукозаписывающих компаний, работа этого торрент-трекера также должна быть запрещена и в Швеции. Совместный иск был подан группой организаций, включая Universal Music, Sony Music, Warner Music, Nordisk Film и the Swedish Film Industry. Компании в судебном порядке пытались добиться от провайдера Bredbandsbolaget блокирования ресурса.

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

Суд в своем решении постановил, что не считает Bredbandsbolaget ответственным за действия клиентов-нарушителей.

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

ссылка на оригинал статьи http://geektimes.ru/post/266646/

Калининская АЭС (источник: Росэнергоатом)

Росэнергоатом приступил к строительству крупнейшего в стране дата-центра, который будет обслуживать потребности АЭС на севере страны. Мощность дата-центра по завершению строительства составит около 80 МВт, а количество стоек достигнет 10000. Дата-центр строится в Тверской области, рядом с Калининской АЭС. Если точнее, то станция будет располагаться в городе-спутнике станции Удомле.

Строить дата-центр будет компания «ЦХД Инжиниринг», которая обеспечивает работу «под ключ», прокладывая электроснабжение, водоснабжение, отопление, вентиляцию и кондиционирование, плюс строит даже дороги и другие инфраструктурные объекты. 10% дата-центра будет зарезервировано под нужды Росэнергоатома, а остальные мощности смогут брать в аренду сторонние компании. Ранее госкомпания предложила перенести персональные данные русскоязычных пользователей в свой дата-центр, в связи в вступлением в силу федерального закона о хранении персональных данных на территории России.

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

Первая фаза строительства дата-центра будет завершена к марту 2017 года. Срок завершения второй фазы — лето 2018. Общая стоимость всего проекта составляет около $975 миллионов, исключая стоимость ИТ-инфраструктуры.

Количество коммерческих дата-центров в России, по данным iKS-Consulting, достигло 200. За прошлый год объем рынка хранения данных в стране увеличился на 28%, вплоть до 11,9 млрд рублей. В этом году, по мнению экспертов, рынок будет продолжать рост.

ссылка на оригинал статьи http://geektimes.ru/post/266644/

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

0) Желательно заранее отрубить службы Windows Search и Superfetch и защитник винды. Они на наших операциях будут только тормозить систему, а ресурсы нам скоро понадобятся. Кроме того очень полезно сделать языком ввода по умолчанию английский.

1) Создаем папку «C:\QT» — тут будут жить наши сборки.

2) Для начала нам конечно же понадобится сам компилятор mingw-w64. Качаем инсталлер тут.

3) Устанавливаем по очереди обе версии:
первая установка:
Version — 5.2.0 — последняя на момент написания статьи;
Architecture — i686 — сначала ставим 32 битную версию (пускай вас не пугает что оно не i386, i686 это Интел пентиум про и выше, сумеете запустить 2k винду на чем то более древнем — удачи!)
Threads — win32 — если не портируете исходники с юниксов лучше выбрать нативные;
Exeption — sjlj — мне нужно так, если вам нужны другие — бога ради;
Build revision — 1 опять же последняя на момент написания статьи;
Назначение выбрал «C:\mingw-w64-i686» ибо из Program Files могут быть проблемы с пробелами в путях у qt.
Вторая установка все то же самое кроме:
Architecture — x86_64;
Путь «C:\mingw-w64-x86_64»;
Я так же убрал галку «создать ярлыки», иначе они перезапишутся 64 битной версией, мне это неудобно.
Если не хотите плодить много папок в корне ставить можно в «C:\QT\mingw-w64-i686» и «C:\QT\mingw-w64-x86_64» соответвенно архитектурам, роли это не играет.

4) Качаем исходники бибилиотеки QT 4.8.7 тут

5) Распаковываем сам Qt (тут лучше заранее озаботится наличием программы 7zip ибо виндовый архиватор сначала будет распаковывать во временную папку, потом копировать из нее туеву хучу мелких файлов, идиот, а потом ещё и создаст дополнительную папку внутри с тем же именем) сразу в 2 копии «C:\QT\qt-4.8.7-mingw-w64-i686» и «C:\QT\qt-4.8.7-mingw-w64-x64» (вторая нужна на случай ошибок при конфигуре, гораздо быстрее переименовать копию и пустить фоном распаковываться ещё одну, чем ждать пока отработает mingw32-make confclean). Если не уверены в архиваторе проверяем чтобы в этих папках сразу были папки bin, util, src и т.д., если архиватор создал ещё одну вложенную — вытаскиваем содержимое на уровень выше.

6) Идем в свойства системы и меняем переменную PATH (надо же в моей 10-ке сделали нормальный интерфейс для этого) добавляем туда путь пока только к 32 битной версии компилятора, у меня это: «C:\mingw-w64-i686\mingw32\bin». Если вдруг у вас в PATH есть пути к другим компиляторам временно убираем их оттуда.

7) Запускаем cmd от админа (это важно) и вводим:

g++ -v

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

Если все нормально переходим в папку с Qt:

cd C:\QT\qt-4.8.7-mingw-w64-i586

запускаем там конфигур как-то так:

.\configure -debug-and-release -opensource -confirm-license -platform win32-g++ -graphicssystem raster -no-openssl -nis -iconv -system-proxies -no-freetype -plugin-sql-odbc -plugin-sql-sqlite -qt-style-windows -qt-style-windowsxp -qt-style-windowsvista -qt-style-plastique -qt-style-cleanlooks -qt-style-motif -qt-style-cde -qt-style-windowsce -qt-style-windowsmobile -qt-style-s60

в этом конфиге по максимому все что можно собрать без зависимостей. Мне openssl не очень нужен, иначе его нужно собрать заранее. Если критично время можно отключить примеры, не собирать дополнительные темы и odbc плагин. Справку по опциям можно получить так: ".\configure -help". Далее ждем несколько минут пока отработает конфигур, и запускаем компиляцию:

mingw32-make -j4

у меня 4 ядерный процессор по этому опция -j4 она обозначает делать компиляцию в 4 потока. Сразу оговорюсь, компиляция с этой опцией до конца не проходит, грохается на qtdeclarative с ошибкой копирования файла, видимо где то неправильно прописаны зависимости. Мне достаточно было запустить компиляцию после сбоя ещё раз. Ошибка кстати повторилась и на 64 битной версии. На core i5-3570 c 8-ю гигами оперы компиляция одной версии в 4 потока занимает почти 2 часа.

8) Если у вас медленный интернет, пока компилится сам Qt можно поставить на закачку qt creator 3.2.2 (это последняя версия, которая компилится на 4.8.x), ActivePerl-5.20.2 !32 битную версию! и msysgit !32 битную версию! Указанные тут верcии это последние на момент написания статьи, и, соответственно, те с которыми работал я. Если у вас что-то не пошло на более новых, попробуйте указанные мной. Предупрежу сразу, до сборки qtcreator ставить msysgit очень не желательно, креатор нормально не соберется если увидит в патче sh.exe, а для нормальной работы с гитом его как раз стоит ставить с прописыванием PATH.

9) Устанавливаем perl: я не ставил документацию и примеры, местом назначения сделал «C:\perlx86». Галку «Add perl to the PATH environment variable» не снимаем. После установки в командной строке (естественно не в той, в которой компилится Qt) пишем «perl -v», должна появится информация о версии.

10) Распаковываем qt creator в " C:\QT\qt-creator-opensource-src-3.2.2", так же проверяем чтобы внутри не было вложенной папки, а сразу были папка bin и остальное.

11) Ждем когда компилируется qt. Никаких прямых сообщений что компиляция завершена успешно, не будет. У меня последним собрался ‘C:/QT/qt-4.8.7-mingw-w64-i586/demos/declarative/webbrowser’. Можно запустить qtdemo.exe для проверки, позапускать примеры. Снова открываем редактор переменных среды, дописываем в PATH «C:\QT\qt-4.8.7-mingw-w64-i586\bin». Опять же убеждаемся, что это единственный профиль qt в PATH. Проверяем себя, перезапустив командную строку и набрав «qmake -v».

12) Открываем блокном файл «C:\QT\qt-creator-opensource-src-3.2.2\src\libs\ssh\sshconnectionmanager.cpp», находим строчку

#if __GNUC__ == 4 && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 2)

и меняем её на

#if __MINGW64_VERSION_MAJOR == 5 || (__GNUC__ == 4 && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 2))

13) Перезапускаем cmd опять же от админа. Собираем creator в новой папке:

mkdir C:\QT\qt-creator-3.2.2-x86 cd C:\QT\qt-creator-3.2.2-x86 qmake -r ../qt-creator-opensource-src-3.2.2/qtcreator.pro mingw32-make release -j4

надеюсь, повторяться про опцию -j4 не надо.

14) Ждем окончания компиляции, запускаем qtcreator, убеждаемся что работает. Закрываем, настраивать в нем пока ещё нечего. Если очень жалко места на диске и оперативы, можно уже скомпиленный creator закинуть в папку с Qt (скопировать только папки bin, lib, share) и добросить в папку bin недостающие dll-ки из mingw. По человечески же, надо наоборот: убрать компилятор и Qt из PATH и докопировать в папку bin creator-а dll-ки из папок bin от Qt и компилятора.

15) Снова открываем редактор PATH убираем оттуда путь к скомпиленному Qt «C:\QT\qt-4.8.7-mingw-w64-i586\bin» и меняем путь к компилятору c «C:\mingw-w64-i686\mingw32\bin» на «C:\mingw-w64-x86_64\mingw64\bin». Опять же перезапускаем cmd от админа и проверяем что нам выдаст

g++ -v

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

cd C:\QT\qt-4.8.7-mingw-w64-x86_64 .\configure -debug-and-release -opensource -confirm-license -platform win32-g++ -graphicssystem raster -no-openssl -nis -iconv -system-proxies -no-freetype -plugin-sql-odbc -plugin-sql-sqlite -qt-style-windows -qt-style-windowsxp -qt-style-windowsvista -qt-style-plastique -qt-style-cleanlooks -qt-style-motif -qt-style-cde -qt-style-windowsce -qt-style-windowsmobile -qt-style-s60 mingw32-make -j4

16) Теперь, пока компилится 64 битная версия Qt, можно заняться и гитом (джитом, не знаю какая транскрипция правильнее). Устанавливаем msysgit v2.6.3 !32 битную версию! запускаем инсталлер сразу от админа, иначе он поставит нам версию только для локального пользователя, оно нам не надо. Путь я выбрал «C:\msysGitX86». На следующем шаге можно ткнуть галку, которая создаст ярлык к консоли на рабочем столе. Eщё через шаг выбираем «Use git from the Windows Command Promt», Я еще выбрал «Use Windows` default console window» для терминала, остальное на любителя или по умолчанию.

На blogspot есть замечательная статья о том как подружить qt creator и github. Однако в ней не даны инструкции что делать если винт на котором все это настроено сгорел синим пламенем. Попробуем восполнить этот пробел.

17) Запускаем git-bash от админа, с ярлыка который нам создал установщик

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

git config --global user.email "myMail@example.com" git config --global user.name "myGithubNick" git config --global push.default simple

генерим новую пару ключей для ssh:

ssh-keygen -t rsa -C "myMail@example.com"

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

пробуем склонировать существующий репозиторий:

mkdir C:\\myproject cd C:\\myproject git clone git@github.com:myGithubNick/mysuperproject.git

обратите внимание что пользователь «git», а не никнейм; никнейм указывается уже после двоеточия. Кроме того никаких https:// или git:// перед адресом быть не должно, если получаете сообщение, что нужно использовать https, значит гитхаб не опознал в вас владельца репозитория, ищите проблемы с ключами или ssh. Если все в порядке, гит сделает нам копию репозитория в папке mysuperproject. Зайдем в нее и проверим что репозиторий рабочий, и у нас есть все права

cd ./mysuperproject git remote -v touch .testfile.txt git add .testfile.txt git commit -m test git push git reset --hard HEAD~1 git push -f

естественно ошибок быть не должно, если есть значит что-то не так с установкой гита или ssh.

18) Дожидаемся пока скомпилится 64 битная версия Qt. Убираем из PATH 64 битный компилятор, либо совсем, либо меняем на 32 битную версию, это уже как удобнее. Открываем блокнотом «C:\QT\qt-4.8.7-mingw-w64-x86_64\mkspecs\win32-g++\qmake.conf», сразу после комментов дописываем «QMAKE_TARGET.arch += x86_64», сохраняем, закрываем.

19) Снова запускаем creator (если сейчас он перестал запускаться, значит что-то лишнее есть в path или не все библиотеки мы ему подложили).

Открываем Инструменты(Tools)->Параметры(Options). Сразу же в разделе Среда(Environment) на вкладке Основные(General) нас просят ввести путь к командe patch, можно использовать «C:\msysGitX86\usr\bin\patch.exe». Идём во Внешние утилиты(External Tools) — правим пути.

Переходим в раздел Сборка и запуск(Build & Run), переходим на вкладку Отладчики(Debuggers), нажмаем Добавить(Add), название даем: «mingw32-w64-gdb», путь: «C:\mingw-w64-i686\mingw32\bin\gdb.exe». Снова жмем Добавить(Add), название даем: «mingw64-w64-gdb», путь: «C:\mingw-w64-x86_64\mingw64\bin\gdb.exe».

Переходим на вкладку Компиляторы(Compilers), нажмаем Добавить(Add) ->MinGW, если нет определенных в path имя даем «MinGW32-W64» и путь «C:\mingw-w64-i686\mingw32\bin\g++.exe» (можно и копию сделать для удобства, не страшно). Добавляем ещё один: имя «MinGW64-W64» путь «C:\mingw-w64-x86_64\mingw64\bin\g++.exe», ABI выбираем 64битные, если есть.

Переходим на вкладку Профили Qt (Qt versions), Если 32 битного профиля нет в path добавляем сначала его «C:\QT\qt-4.8.7-mingw-w64-i586\bin\qmake.exe». Потом добавляем 64 битный «C:\QT\qt-4.8.7-mingw-w64-x86_64\bin\qmake.exe». Имена у меня «Qt 4.8.7 mingw-w64 i586» и «Qt 4.8.7 mingw-w64 x86_64» соответвенно.

Переходим на вкладку Комплекты(kits), сначала настраиваем профиль Desktop:
Название:Desktop
Имя в файловой системе: x86
Тип устройства:Desktop
Устройство: Локальный ПК
Sysroot: — оставляем пустым
Компилятор: MinGW32-W64
Отладчик: mingw32-w64-gdb
Профиль Qt: Qt 4.8.7 mingw-w64 i586
Добавляем ещё один
Название:Desktop 64
Имя в файловой системе: x86_64
Тип устройства:Desktop
Устройство: Локальный ПК
Sysroot: — оставляем пустым
Компилятор: MinGW64-W64
Отладчик: mingw64-w64-gdb
Профиль Qt: Qt 4.8.7 mingw-w64 ч86_64
сохраняем, применяем, пробуем что-нибудь собрать.

Вот пожалуй и все что вспомнил по данной теме.

Кстати небольшой хак: если нужно незначительно переконфигурить уже собранную сборку, ну например openssl вы решили добавить или плагин к какому-нить мускулю не собрался, а 2-3-4 часа ждать пока все перекомпилиться ни разу не улыбается, делаем так: выставляем системное время на минут 10-15 раньше чем последний раз конфигурили сборку, переконфигуриваем, возвращаем время на настоящее. Блокнотом изменяем тот(те) мейкфайл(ы) который(е) затрагивает(ют) наши изменения и запускаем мейк, если не ошиблись с мейкфайлами (на самом деле если знать из чего состоит Qt, и что от чего зависит, ошибится трудно) перекомпилится только тот кусок который нам нужен.

ссылка на оригинал статьи http://geektimes.ru/post/266642/

От переводчика:

Для нетерпеливых есть видео.

Презентация, котрая использовалась во время лекции:

I. Классический миф о Силиконовой долине

Классический миф о Силиконовой долине заключается в том, что именно стартапы делают ее особенной.
Классическая история Силиконовой долины такова:

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

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

II. Проблема классического мифа

Основная проблема данной истории заключается в том, что сегодня стартапов более чем достаточно в Силиконовой долине, в США и в остальном мире – в Европе, Латинской Америке, Азии и пр. Сегодня вполне возможно собрать команду, найти средства и создать продукт в любой точке мира.

При этом сегодня в Силиконовой долине расположено немало качественно новых компаний. Почему так?

Если посмотреть на компании, которые стоят более 10 млрд. долларов, все они, кроме двух, расположены в Силиконовой долине (Alibaba и Tencent – исключения).

Если посмотреть на первые 10% компаний-единорогов (компаний, которые на бумаге стоят более 1 млрд. долларов) – 50% из них – это выходцы из Области залива Сан-Франциско. Если посмотреть на первые 60% компаний-единорогов – 47% из них из Области залива.

Учитывая, что в Области залива всего 7 миллионов людей – почему в этом регионе такая концентрация трансформационных компаний? Что-то очень странное происходит в Области залива Сан-Франциско по сравнению с другими местами, в которых создаются стартапы.

Теория и основа этой лекции заключается в том, что Силиконовая долина особенна, потому у нас богатый опыт и достаточно оперативных знаний относительно развития компаний – Рейд Хоффман и Крис Йе назвали это «Blitzscaling» (молниеносное масштабирование).

III. Цель лекции

Цель лекции — задокументировать и поделиться знаниями о Blitzscaling с участниками лекции и всем миром (эти лекции записываются и выкладываются в сети).

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

IV. Сети

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

Например, в Силиконовой долине и в частности в Стэндфордском университете огромное количество людей, которые построили и развили множество стабильных компаний. Примеры включают: Frederick Terman, Hewlett and Packard, Andy Bechtolsheim, Aneel Bhusri, Sergey Brin и пр.

V. Уровни масштабирования

Вот как Рейд, Джон и Аллен разделили различные уровни масштабирования.

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

VI. Ключевые вопросы на различных уровнях масштабирования

Некоторые ключевые вопросы на различных уровнях масштабирования включают:

Некоторые вопросы, которые мы обсудим в этом квартале

• Какова роль основателя? Генерального директора? Команды? Совета директоров?
• Как изменяется процесс найма по мере масштабирования компании? Кто? Как? Что представляет собой введение в должность?
• Что вы думаете о соответствии продукта рынку? Откуда вы это знаете? Как он развивается?
• Что вы должны знать о конкуренции? Прочих угрозах?
• Каковы основные решения и вопросы, которые вы должны себе задать? Когда?
• Что вы должны знать о партнерах и развитии бизнеса?
• Как изменяется ваша стратегия по мере вашего роста?
• Что вы думаете о таких глобальных понятиях, как рынки, конкуренция, масштаб?
• И многое другое…

Например, в Workday один из основателей Анил Бхусри лично проводил собеседования со всеми новыми работниками от 0 до 500 человек, так как для него особенно важна была культура. Однако, когда количество работников переваливает за 500-1000, это становится трудным, и на таком уровне необходимо искать новый подход в отношении расширения штата и культуры.

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

VII. Как масштабирование влияет на функции вашей компании

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

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

VII. Основные соображения Blitzscaling

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

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

3. По мере расширения вы движетесь от:

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

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

5. Сохранение либо адаптации, либо высокого профессионализма – Быстрое развитие означает операционные потери. Пример: Paypal увеличивал базу пользователей и операций на 2-5% в день, и в один момент количество писем в техподдержку перевалило за 20 тысяч и с каждым днем увеличивалось. Клиенты злились и звонили 24 часа в сутки. За 2 месяца им пришлось увеличить штат работников техподдержки от 0 до 200, обучаемых по ходу дела, и в результате им пришлось отсеять большую часть таких работников. Такой негативный эффект был необходим при повышении скорости в ущерб профессионализма.

6. Глобальный охват – LinkedIn начинал с 12 стран, и впоследствии добавлял страны только тогда, когда люди писали и просили добавить их страну.

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

IX. Пример молниеносного масштабирования от LinkedIn

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

X. “Стадия семьи”

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

На этом этапе наиболее важны следующие моменты:

• Насколько хорош ваш продукт?
• Ваш продукт кому-нибудь вообще интересен?
• Можете ли вы нанимать работников? Как вы убеждаете кого-либо присоединиться к вам на Facebook/Uber/Airbnb/и пр.? Как вы заинтересовываете работников?
• Как вы будете платить работникам при малейшей потере управления?
• Много букв: продукт продукт продукт, люди люди люди, и как вы будете платить людям.
• Моменты, которые не важны на данном этапе:
• Совет директоров
• Аналитика, показатели и таблица индикаторов – Просто следите за основными элементами
• Стратегия (лучше действовать)
• Все остальное

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

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

Одна из любимейших статей Джона Лилли на этом этапе – это статья Пола Грэхэма Do things that don’t scale

Когда вы только начинаете, вся ваша команда должна делать следующее:

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

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

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

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

XI. Материалы для прочтения на этапе роста “Стадия семьи”

1. Do things that don’t scale
2. Startup Advice, Briefly
3. Why Silicon Valley Works

ссылка на оригинал статьи http://megamozg.ru/post/22244/

Angular Light — самостоятельный клиентский MV(C/VM) фреймворк, который построен на идеях Angular.js и Knockout.js, и похож на упрощенный Angular.js

Вышла версия Angular Light 0.11, которая включает много изменений.

В Angular.js, как и в старых версиях Angular Light, Scope — это механизм отслеживания изменений (Change Detector) и в нем располагаются пользовательские данные для отслеживания. Такое смешивание данных и механизма отслеживания в одном объекте породило ряд разных проблем: для таких директив как ng-if/ng-include/ng-repeat фреймворк вынужден создавать дочерние CD с прототипом к родительскому, чтобы иметь доступ к данным — это негативно влияет на расход памяти и скорость работы, но, самое важное, примеры как этот не работают как ожидается:

<div>     <input type="text" ng-model="value" /> {{value}}     <div ng-if="flag">         <input type="text" ng-model="value" /> {{value}}         <button ng-click="value=5">set</button>     </div> </div> 

ng-click=«value=5» и ng-model=«value» изменят переменную дочернего CD, которую создал ng-if, а не ту что выше. Из-за этой проблемы авторы Angular.js сделали рекомендации: не использовать данные в корне Scope (используйте имена с «точкой») и использовать controllerAs.
Так же при создании Angular 2, они учли эту проблему — теперь в нем есть отдельный тип ChangeDetector (отдельный от данных).

В Angular Light 0.11 так же внесены изменения в этом плане: бывшый Scope был разделен на ChangeDetector и пользовательские данные, — это дало дополнительную гибкость и подобные примеры (как выше) работают как ожидается:

<div>     <input type="text" al-value="value"> {{value}}     <div al-if="flag">                 <input type="text" al-value="value"> {{value}}         <button al-click="value=5">set</button>     </div> </div> 

Пример на jsfiddle

Так же и с al-repeat, al-click=«active=current» внутри цикла меняет пользовательские данные, а не дочерний Scope.

<div>     {{active.name}}     <div al-repeat="current in list">         <div al-click="active=current">{{current.name}}</div>     </div> </div> 

Пример на jsfiddle

Т.к. al-repeat создает локльные переменные внутри цикла: current, $index, $last и т.п. и они не должны менять пользовательские данные (как и пересекаться с другими циклами), сделан небольшой трюк, а в Angular 2 для этого создана сложная система компиляции (не даром он весит около 1.7 Мб).

Еще одно важное новшество в Angular Light: теперь в нем есть настоящие асинхронные фильтры. Если сравнивать их с Angular.js $stateful фильтрами то можно заметить, что Angular.js вызывает ваш фильтр на каждом $digest цикле, и когда вам нужно «отправить» новое значение вы его возвращаете на следующем $digest цикле, в то время, как Angular Light не «дергает» ваш фильтр каждый раз, вы можете «отправить» новое значение в любой момент (например когда данные пришли с сервера), пример: {{user.companyId | loadCompanyName}}

al-repeat теперь может итерировать по объекту, в отличие от ng-repeat, вы можете задать сортировку.

У дериктив появился «изолированный режим», при правильном использовании это может снизить нагрузку в 100 раз, для тех кто беспокоится о dirty-checking. Так же «замороженные» массивы через Object.freeze дают ускорение dirty-checking и в планах добавление поддержки популярного immutable.js

Ускорен биндинг, теперь Angular Light стал в 2 раза быстрее чем Angular.js (в некоторых случаях), тест, что удивительно — он стал быстрее чем Basis.js, не говоря о других фреймворках.

Не знаю насколько он был нужен, но al-select был добавлен в стандартную поставку, в отличие от ng-options, al-select работает совместно с al-repeat — это дает дополнительную гибкость. Например, в одном select можно использовать несколько al-repeat циклов, или добавлять пользовательские (одиночные) пункты, пример.

alight.bootstrap был немного изменен для более удобного использования, пример:

<div id="app">     <button al-click="click()">click</button>     <input type="text" al-value="name" /> Hello {{name}}! </div> 

alight.bootstrap('#app', {     name: 'user',     click: function() {         this.name = 'world'     } }) 

Пример на jsfiddle

Также внесено несколько меннее значимых улучшений. Для тех кто использовал Angular Light 0.10 и старше, есть список основных отличий.

Предыдущие статьи:

• Angular Light + Object.observe
• Angular 0.6, основные изменения
• «Ленивое» подключение директив и препроцессор
• Управляем декларативным биндингом данных в HTML
• Наследование директив

ссылка на оригинал статьи http://habrahabr.ru/post/271925/