-Поиск по дневнику

Поиск сообщений в rss_rss_hh_full

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 1

Habrahabr








Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://habrahabr.ru/rss/.
Данный дневник сформирован из открытого RSS-источника по адресу http://feeds.feedburner.com/xtmb/hh-full, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

[Из песочницы] Разработка прибыльной Android игры двумя школьниками

Воскресенье, 24 Сентября 2017 г. 16:26 + в цитатник
Noobariouse сегодня в 16:26 Разработка

Разработка прибыльной Android игры двумя школьниками

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

image


Предыстория


Мы начали заниматься разработкой игры в 10-м классе. До этого никакого опыта в разработке и продвижении мобильных игр у нас не было. Были лишь базовые знания Java и небольшой опыт создания сайтов. И все!

image

Идея


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

Мы начали перебирать в голове все топовые на тот момент игры: такие, как Flappy Bird, Crossy Road и тд, так как захотели создать что-то похожее, что заставило бы людей «залипнуть» в нашу игру.

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

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

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

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

Нейминг


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

Фичи


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

Мы придумали 2 основных фичи:


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

image

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

image

Дизайн


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

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

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

Это был очень волнительный момент. Мы думали, что это наш единственный шанс получить крутой дизайн, и мы не можем его упустить. Я крутил у себя в голове наш диалог, продумывал наше общение на пять сообщений вперед. Наконец, собравшись с силами, я отправил ему первое сообщение. Ответ не заставил себя долго ждать. Художник ответил всего через пол часа.
Всего за работу он хотел не много не мало 5000-8000$…

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

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

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

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

Разработка всего дизайна по времени отняла приблизительно 2-3 недели. В итоге, он нам не то, чтобы очень сильно понравился, но был неплох.

image

Итак, дизайн был готов! Настало время разработки!

Разработка


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

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

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

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

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

Сейчас мы поставляем сразу 5 версий приложения в Гугл Плей (4 версии с разделением ресурсов и 1 версию без разделения), что позволяет экономить у некоторых пользователей около 18 мегабайт веса.

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

Монетизация


После того, как в игре появился хоть какой то функционал, мы начали думать о способах монетизации. Мы перепробовали много разных компаний-рекламодателей, включая StartApp, ChartBoost и тд. Но решили оставить свой выбор на Appodeal, которая показалось нам самой адекватной сетью, несмотря на большой размер SDK и необходимость использования multidex.
Также очень понравилась работа поддержки, ответы были всегда оперативными и понятными.

Всего рекламы в игре довольно много: от простых маленьких баннеров на разных Activity до их полноэкранных видов. Также в игре присутствует видео-реклама, которую пользователь может просмотреть, если захочет ускорить прохождение игры.

Сразу после внедрения рекламной сети доход от игры откровенно печалил. Он составлял не более 0,1$ в день, так как просмотров было очень мало, всвязи с маленьким количеством игроков.

Со временем график очень медленно, но верно рос вверх. За пол года игра начала приносить около 1$ в день.

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

Старая и новая иконки игры:


image

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

Количество установок пользователей в день также резко подскочило вверх:

image

Ошибки


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

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

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

image

Итоги


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

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

С текущими перспективами мы теперь планируем создать что-то по-настоящему стоящее, что-то оригинальное и гораздо более продуманное!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338596/


Метки:  

[Из песочницы] Разработка прибыльной Android игры двумя школьниками

Воскресенье, 24 Сентября 2017 г. 16:26 + в цитатник
Noobariouse сегодня в 16:26 Разработка

Разработка прибыльной Android игры двумя школьниками

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

image


Предыстория


Мы начали заниматься разработкой игры в 10-м классе. До этого никакого опыта в разработке и продвижении мобильных игр у нас не было. Были лишь базовые знания Java и небольшой опыт создания сайтов. И все!

image

Идея


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

Мы начали перебирать в голове все топовые на тот момент игры: такие, как Flappy Bird, Crossy Road и тд, так как захотели создать что-то похожее, что заставило бы людей «залипнуть» в нашу игру.

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

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

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

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

Нейминг


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

Фичи


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

Мы придумали 2 основных фичи:


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

image

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

image

Дизайн


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

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

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

Это был очень волнительный момент. Мы думали, что это наш единственный шанс получить крутой дизайн, и мы не можем его упустить. Я крутил у себя в голове наш диалог, продумывал наше общение на пять сообщений вперед. Наконец, собравшись с силами, я отправил ему первое сообщение. Ответ не заставил себя долго ждать. Художник ответил всего через пол часа.
Всего за работу он хотел не много не мало 5000-8000$…

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

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

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

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

Разработка всего дизайна по времени отняла приблизительно 2-3 недели. В итоге, он нам не то, чтобы очень сильно понравился, но был неплох.

image

Итак, дизайн был готов! Настало время разработки!

Разработка


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

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

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

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

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

Сейчас мы поставляем сразу 5 версий приложения в Гугл Плей (4 версии с разделением ресурсов и 1 версию без разделения), что позволяет экономить у некоторых пользователей около 18 мегабайт веса.

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

Монетизация


После того, как в игре появился хоть какой то функционал, мы начали думать о способах монетизации. Мы перепробовали много разных компаний-рекламодателей, включая StartApp, ChartBoost и тд. Но решили оставить свой выбор на Appodeal, которая показалось нам самой адекватной сетью, несмотря на большой размер SDK и необходимость использования multidex.
Также очень понравилась работа поддержки, ответы были всегда оперативными и понятными.

Всего рекламы в игре довольно много: от простых маленьких баннеров на разных Activity до их полноэкранных видов. Также в игре присутствует видео-реклама, которую пользователь может просмотреть, если захочет ускорить прохождение игры.

Сразу после внедрения рекламной сети доход от игры откровенно печалил. Он составлял не более 0,1$ в день, так как просмотров было очень мало, всвязи с маленьким количеством игроков.

Со временем график очень медленно, но верно рос вверх. За пол года игра начала приносить около 1$ в день.

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

Старая и новая иконки игры:


image

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

Количество установок пользователей в день также резко подскочило вверх:

image

Ошибки


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

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

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

image

Итоги


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

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

С текущими перспективами мы теперь планируем создать что-то по-настоящему стоящее, что-то оригинальное и гораздо более продуманное!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/338596/


Метки:  

Еще один нюанс JavaScript, о котором все знают, но не все задумываются

Воскресенье, 24 Сентября 2017 г. 16:25 + в цитатник
VladVR сегодня в 16:25 Разработка

Еще один нюанс JavaScript, о котором все знают, но не все задумываются

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

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

    let a = {
      'myKey': 'myValue'
    }
    let key = 'constructor'; // comes from outside source
    let b = a[key] || 'defaultValue';
    expect(b).to.be.equal('defaultValue'); // fails
    

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

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

    Библиотека hash-map решает эту задачу методом сокрытия всех нижележащих полей пустыми значениями:

      const result = {};
      for (var prop of Object.getOwnPropertyNames(Object.prototype)) {
        result[prop] = undefined;
      }
      return result;
    

    Способы использования можно посмотреть в readme.

    Yet another JS library


    Статья получилась короткая, да и нечего особо рассказать об этой микропроблеме. Поэтому я до кучи решил упомянуть об еще одной библиотечке — typescript-reexport-generator. В процессе разработки на typescript я прибегал к разным способам экспортировать-импортировать код между файлами, пришел к тому, что наиболее удобным является следующее. Все .ts файлы в папке экспортируют код следующим образом:

    // file1
    export function myFunction(){}
    
    // file2
    export class myClass{}
    

    Далее в папку кладется файл index.ts со следующим содержимым:

    export * from './file1';
    export * from './file2';
    

    Теперь можно импортировать можно вот так:

    //было
    import { myFunction } from './folder/file1';
    import { myClass } from './folder/file2';
    //стало
    import { myFunction, myClass } from './folder';
    

    кроме этого, между файлами одной папки можно импортироваться вот так:

    import { myClass } from '.';
    export function myFunction(){ // doSmth with class }
    

    Есть еще один мини-выигрыш: навигация в VSCode (ctrl + mouse click) наилучшим образом работает с таким экспортированием. Навигация от использования до имплементации в 1 клик. С default экспортом навигация осуществлялась в два клика, что несколько удручало, поэтому я от такого довольно быстро полностью отказался.

    И для того, чтобы не писать эти реэкспорты руками, я написал простенький генератор, который создает эти файлы index.ts из таски с gulp.watch. Если вы используете такой же способ импортов-экспортов, библиотека может оказаться полезной.

    Недостаток библиотеки, а куда же без них, это то, что VSCode не следит за изменениями файлов, поэтому только что созданный файл с экспортами не сразу позволяет импортироваться снаружи. Приходится руками зайти в index, чтобы студия «увидела», что там появилась новая строчка. Другой недостаток, который уже зависит от меня — gulp.watch не сообщает что именно изменилось, соответственно генератору приходится просматривать (и парсить) все файлы в проекте. В будущем возможно создам следующую версию библиотеки где это будет решено. Полным будет только первый проход, а далее будут парситься только те файлы, которые были изменены.
    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/338594/


    Метки:  

    Еще один нюанс JavaScript, о котором все знают, но не все задумываются

    Воскресенье, 24 Сентября 2017 г. 16:25 + в цитатник
    VladVR сегодня в 16:25 Разработка

    Еще один нюанс JavaScript, о котором все знают, но не все задумываются

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

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

      let a = {
        'myKey': 'myValue'
      }
      let key = 'constructor'; // comes from outside source
      let b = a[key] || 'defaultValue';
      expect(b).to.be.equal('defaultValue'); // fails
      

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

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

      Библиотека hash-map решает эту задачу методом сокрытия всех нижележащих полей пустыми значениями:

        const result = {};
        for (var prop of Object.getOwnPropertyNames(Object.prototype)) {
          result[prop] = undefined;
        }
        return result;
      

      Способы использования можно посмотреть в readme.

      Yet another JS library


      Статья получилась короткая, да и нечего особо рассказать об этой микропроблеме. Поэтому я до кучи решил упомянуть об еще одной библиотечке — typescript-reexport-generator. В процессе разработки на typescript я прибегал к разным способам экспортировать-импортировать код между файлами, пришел к тому, что наиболее удобным является следующее. Все .ts файлы в папке экспортируют код следующим образом:

      // file1
      export function myFunction(){}
      
      // file2
      export class myClass{}
      

      Далее в папку кладется файл index.ts со следующим содержимым:

      export * from './file1';
      export * from './file2';
      

      Теперь можно импортировать можно вот так:

      //было
      import { myFunction } from './folder/file1';
      import { myClass } from './folder/file2';
      //стало
      import { myFunction, myClass } from './folder';
      

      кроме этого, между файлами одной папки можно импортироваться вот так:

      import { myClass } from '.';
      export function myFunction(){ // doSmth with class }
      

      Есть еще один мини-выигрыш: навигация в VSCode (ctrl + mouse click) наилучшим образом работает с таким экспортированием. Навигация от использования до имплементации в 1 клик. С default экспортом навигация осуществлялась в два клика, что несколько удручало, поэтому я от такого довольно быстро полностью отказался.

      И для того, чтобы не писать эти реэкспорты руками, я написал простенький генератор, который создает эти файлы index.ts из таски с gulp.watch. Если вы используете такой же способ импортов-экспортов, библиотека может оказаться полезной.

      Недостаток библиотеки, а куда же без них, это то, что VSCode не следит за изменениями файлов, поэтому только что созданный файл с экспортами не сразу позволяет импортироваться снаружи. Приходится руками зайти в index, чтобы студия «увидела», что там появилась новая строчка. Другой недостаток, который уже зависит от меня — gulp.watch не сообщает что именно изменилось, соответственно генератору приходится просматривать (и парсить) все файлы в проекте. В будущем возможно создам следующую версию библиотеки где это будет решено. Полным будет только первый проход, а далее будут парситься только те файлы, которые были изменены.
      Original source: habrahabr.ru (comments, light).

      https://habrahabr.ru/post/338594/


      Метки:  

      Дайджест интересных материалов для мобильного разработчика #222 (18 — 24 сентября)

      Воскресенье, 24 Сентября 2017 г. 16:00 + в цитатник
      EverydayTools сегодня в 16:00 Разработка

      Дайджест интересных материалов для мобильного разработчика #222 (18 — 24 сентября)

        Дайджест с прекрасным номером 222 – мы снова разбираемся с работой Android, новой iOS, Kotlin, дизайном и маркетингом приложений и игр.



        Как работает Android, часть 2

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

        Руководство по выживанию в Steam для мобильных разработчиков

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

        Дайджест доступен и в виде рассылки. Подписаться вы можете тут.

        iOS

        (+6) CGLayout — новая система автоматического layout'а в iOS
        (+5) Абстракция сетевого слоя с применением «стратегий»
        Magic Sudoku: решение судоку на iPhone
        Приложение IKEA с дополненной реальностью вышло в App Store
        Исчезновение топа зарабатывающих не скажется на аналитике
        image Погружение в iOS 11
        image Выступ в iPhone X касается только брендинга
        image Отзывчивый UI в iOS без AutoLayout
        image Редизайн iOS-приложения Sephora
        image Гибридная архитектура Basecamp 3 для iOS: Сигнал против Шума
        image Отслеживание лиц с ARKit
        image Топ-5 iOS-библиотек сентября
        image Создание кастомных коллекций в Swift
        image NotchKit: простой способ скрыть выступ на iPhone X
        image AudioKit Version 4: новая версия платформы обработки звука для iOS

        Android

        (+14) Kotlin в продакшене, что мы получили, и что мы потеряли?
        (+8) LibGDX. Практические вопросы и ответы
        (+7) AStA: собираем APK на самом устройстве
        (+6) Легкая работа со списками — RendererRecyclerViewAdapter (часть 2)
        (+3) Travis CI: автоматическая загрузка собранных модулей на GitHub
        Google выкупает команду HTC
        image Android Dev Подкаст. Выпуск 42. Новости
        Отправка FCM Push при помощи Cloud Functions в Firebase
        Android Things и Firebase
        Конкурс Android Things
        image Realm, ObjectBox или Room: что подходит для вас
        image Большие запросы к базам данных на Android
        image Иконка с количеством в ActionBar
        image Топ-5 Android-библиотек сентября
        image Круглый Progress View
        image Руководство по адаптивным иконкам в Oreo
        image От дизайна к Android
        image Берем все от дебаггера Android Studio
        image Возможности Java 8 на Android

        Разработка

        (+34) Взбираясь на непокорённую гору: сложности создания игры в одиночку
        (+24) Трансляция с геймдев-конференции 4C в Санкт-Петербурге. День первый и День второй
        (+20) GeekUniversity открывает набор на факультет разработки игр
        (+9) «Невидимый дизайн»: проектируем вместе с машинами
        (+7) С чего начать молодым разработчикам мобильных игр из России [Часть 3]
        (+4) Создаем «внешний контур» экосистемы с независимыми разработчиками: итоги конкурса Skyeng API
        Инструменты для создания хорошего дизайна
        Как стартапы платят сотрудникам на 40% меньше нужного
        Почему не стоит разблокировать телефон при помощи лица
        Unity выпустила SDK для машинного обучения
        Как я перестала бояться и полюбила дизайн-мышление
        ABBYY поможет удаленно идентифицировать клиентов с помощью смартфона
        Поищите вдохновение в другом месте
        Будущее общения: смешанная, а не виртуальная реальность
        Признаки плохого и хорошего UX-дизайна для рядовых пользователей
        Designgo.io: простой, быстрый и удобный инструмент для коммуникации между дизайнером и клиентом
        image Для инди-разработчиков игровой дизайн и маркетинг это одно и тоже
        image Как я сделал CMS для приложения на React за один день
        image Detox: фреймворк для тестирования мобильных приложений
        image Интересное приключение: создание 2D изометрического платформера на Unity
        image Unity 2017.2 с поддержкой ARCore, Vuforia, Windows Mixed Reality и пр.
        image Шаблон мобильного AWS React Native приложения

        Аналитика, маркетинг и монетизация

        (+10) Как сделать хороший ролик для App Store и Google Play
        (+6) В App Store появилась категория «Инди». Но речь не об этом
        (+3) ASO в Playstore: добавим немного юмора в работу, или как поэзия может помочь в росте органики на 304% за 30 дней
        Мобильная экономика дает 3.8% ВВП России
        Бум смартфонов среди пожилых
        «Неотзывчивые жесты»: отчет Appsee
        3 стратегии монетизации мобильного приложения: как диверсифицировать выручку?
        image Таинственный мир инди-маркетинга
        image О чем мобильный рынок говорил на Dmexco 2017

        Устройства, IoT, AI

        (+96) Достижения в глубоком обучении за последний год
        (+59) Как мы обучали приложение Яндекс.Такси предсказывать пункт назначения
        (+11) Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе
        У Apple Watch Series 3 проблемы с LTE
        4 способа сделать чат-боты для обслуживания клиентов более полезными
        Автомобили с Яндексом на борту
        Blackberry возвращается в Россию

        < Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку — пришлите, пожалуйста, в почту.
        Original source: habrahabr.ru (comments, light).

        https://habrahabr.ru/post/338592/


        Дайджест интересных материалов для мобильного разработчика #222 (18 — 24 сентября)

        Воскресенье, 24 Сентября 2017 г. 16:00 + в цитатник
        EverydayTools сегодня в 16:00 Разработка

        Дайджест интересных материалов для мобильного разработчика #222 (18 — 24 сентября)

          Дайджест с прекрасным номером 222 – мы снова разбираемся с работой Android, новой iOS, Kotlin, дизайном и маркетингом приложений и игр.



          Как работает Android, часть 2

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

          Руководство по выживанию в Steam для мобильных разработчиков

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

          Дайджест доступен и в виде рассылки. Подписаться вы можете тут.

          iOS

          (+6) CGLayout — новая система автоматического layout'а в iOS
          (+5) Абстракция сетевого слоя с применением «стратегий»
          Magic Sudoku: решение судоку на iPhone
          Приложение IKEA с дополненной реальностью вышло в App Store
          Исчезновение топа зарабатывающих не скажется на аналитике
          image Погружение в iOS 11
          image Выступ в iPhone X касается только брендинга
          image Отзывчивый UI в iOS без AutoLayout
          image Редизайн iOS-приложения Sephora
          image Гибридная архитектура Basecamp 3 для iOS: Сигнал против Шума
          image Отслеживание лиц с ARKit
          image Топ-5 iOS-библиотек сентября
          image Создание кастомных коллекций в Swift
          image NotchKit: простой способ скрыть выступ на iPhone X
          image AudioKit Version 4: новая версия платформы обработки звука для iOS

          Android

          (+14) Kotlin в продакшене, что мы получили, и что мы потеряли?
          (+8) LibGDX. Практические вопросы и ответы
          (+7) AStA: собираем APK на самом устройстве
          (+6) Легкая работа со списками — RendererRecyclerViewAdapter (часть 2)
          (+3) Travis CI: автоматическая загрузка собранных модулей на GitHub
          Google выкупает команду HTC
          image Android Dev Подкаст. Выпуск 42. Новости
          Отправка FCM Push при помощи Cloud Functions в Firebase
          Android Things и Firebase
          Конкурс Android Things
          image Realm, ObjectBox или Room: что подходит для вас
          image Большие запросы к базам данных на Android
          image Иконка с количеством в ActionBar
          image Топ-5 Android-библиотек сентября
          image Круглый Progress View
          image Руководство по адаптивным иконкам в Oreo
          image От дизайна к Android
          image Берем все от дебаггера Android Studio
          image Возможности Java 8 на Android

          Разработка

          (+34) Взбираясь на непокорённую гору: сложности создания игры в одиночку
          (+24) Трансляция с геймдев-конференции 4C в Санкт-Петербурге. День первый и День второй
          (+20) GeekUniversity открывает набор на факультет разработки игр
          (+9) «Невидимый дизайн»: проектируем вместе с машинами
          (+7) С чего начать молодым разработчикам мобильных игр из России [Часть 3]
          (+4) Создаем «внешний контур» экосистемы с независимыми разработчиками: итоги конкурса Skyeng API
          Инструменты для создания хорошего дизайна
          Как стартапы платят сотрудникам на 40% меньше нужного
          Почему не стоит разблокировать телефон при помощи лица
          Unity выпустила SDK для машинного обучения
          Как я перестала бояться и полюбила дизайн-мышление
          ABBYY поможет удаленно идентифицировать клиентов с помощью смартфона
          Поищите вдохновение в другом месте
          Будущее общения: смешанная, а не виртуальная реальность
          Признаки плохого и хорошего UX-дизайна для рядовых пользователей
          Designgo.io: простой, быстрый и удобный инструмент для коммуникации между дизайнером и клиентом
          image Для инди-разработчиков игровой дизайн и маркетинг это одно и тоже
          image Как я сделал CMS для приложения на React за один день
          image Detox: фреймворк для тестирования мобильных приложений
          image Интересное приключение: создание 2D изометрического платформера на Unity
          image Unity 2017.2 с поддержкой ARCore, Vuforia, Windows Mixed Reality и пр.
          image Шаблон мобильного AWS React Native приложения

          Аналитика, маркетинг и монетизация

          (+10) Как сделать хороший ролик для App Store и Google Play
          (+6) В App Store появилась категория «Инди». Но речь не об этом
          (+3) ASO в Playstore: добавим немного юмора в работу, или как поэзия может помочь в росте органики на 304% за 30 дней
          Мобильная экономика дает 3.8% ВВП России
          Бум смартфонов среди пожилых
          «Неотзывчивые жесты»: отчет Appsee
          3 стратегии монетизации мобильного приложения: как диверсифицировать выручку?
          image Таинственный мир инди-маркетинга
          image О чем мобильный рынок говорил на Dmexco 2017

          Устройства, IoT, AI

          (+96) Достижения в глубоком обучении за последний год
          (+59) Как мы обучали приложение Яндекс.Такси предсказывать пункт назначения
          (+11) Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе
          У Apple Watch Series 3 проблемы с LTE
          4 способа сделать чат-боты для обслуживания клиентов более полезными
          Автомобили с Яндексом на борту
          Blackberry возвращается в Россию

          < Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку — пришлите, пожалуйста, в почту.
          Original source: habrahabr.ru (comments, light).

          https://habrahabr.ru/post/338592/


          [Из песочницы] ViewModel и LiveData: паттерны и антипаттерны

          Воскресенье, 24 Сентября 2017 г. 15:48 + в цитатник
          artem_dobrovinskiy сегодня в 15:48 Разработка

          ViewModel и LiveData: паттерны и антипаттерны

          Привет, Хабр! Представляю вашему вниманию перевод статьи ViewModels and LiveData: Patterns + AntiPatterns автора Jose Alc'erreca.

          View и ViewModel


          Распределение ответственностей


          Типичное взаимодействие объектов приложения, построенное с помощью Архитектурных Компонентов:

          image

          В идеале ViewModel не должна ничего знать про Android. Это улучшает тестируемость и модульность, снижает кол-во утечек памяти. Основное правило — в Вашей ViewModel не должно быть импортов android.* (за исключением вроде android.arch.*). Это относится и к Presenter.
          ViewModel (и Presenter) не должны знать о классах фреймворка Android

          Условные операторы, циклы и общие решения должны проводиться в ViewModel или прочих слоях приложения, не в активити или фрагментах. View обычно не подвергается unit-тестированию (кроме случаев, когда используется Robolectric), поэтому чем меньше строчек кода — тем лучше. View должны только отображать данные и посылать действия пользователя в ViewModel (или Presenter). Этот паттерн называется Passive View.
          Активити и фрагменты должны содержать минимум логики

          Ссылки на View в ViewModel


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

          ViewModels сохраняется при изменениях конфигурации:

          image

          Передача ссылки на View (активити или фрагмент) в ViewModel является серьезным риском. Предположим, ViewModel запросила данные из сети, и они придут чуть позже. В этот момент ссылка на View может быть уничтожена или активити может больше не отображаться — это приведет к утечке памяти, а возможно и к крэшу приложения.
          Избегайте ссылок на View в ViewModels.
          Рекомендуемый способ коммуникации между ViewModel и View — использование observer pattern, при помощи LiveData или observable из других библиотек.

          Observer Pattern (шаблон проектирования «Наблюдатель»)


          image

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

          1. ViewModel сохраняются при изменении конфигурации, поэтому нет нужды в повторном запросе внешних источников данных (к примеру, базы данных или сетевого хранилища) при произведенном повороте устройства.
          2. Когда заканчивается какая-либо длительная операция, observable в ViewModel обновляются. Не важно, велось ли наблюдение за данными или нет. NPE не произойдет даже при попытке обновления несуществующего View.
          3. ViewModel не содержат ссылки на View, что снижает риск возникновения утечек памяти.

          Типичные подписки от активити или фрагмента:

          private void subscribeToModel() {
            // Observe product data
            viewModel.getObservableProduct().observe(this, new Observer() {
                @Override
                public void onChanged(@Nullable Product product) {
                  mTitle.setText(product.title);
                }
            });
          }
          Вместо того, чтобы отсылать данные в UI, пусть UI наблюдает за изменениями в данных.

          «Жирные» ViewModel


          Разделение ответственностей — всегда хорошая идея. Если Ваш ViewModel содержит в себе слишком много кода или имеет слишком много ответственностей, подумайте о том, что возможно следует:

          • Переместить часть логики в Presenter, с тем же scope, что у ViewModel. Именно он будет связываться с другими частями приложения и обновлять LiveData в ViewModel.
          • Добавить слой Domain и адаптировать приложение под Чистую Архитектуру. Это облегчит проведение тестов и поддержку кода. Также это обычно приводит к тому, что большая часть логики не выполняется в главном треде. С примером Чистой Архитектуры можно ознакомиться в Architecture Blueprints.

          Распределяйте ответственности, добавьте слой domain если требуется.

          Использовать репозиторий для данных


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

          1. Удаленный: сеть или облако
          2. Локальный: база данных или файл
          3. Кэш

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

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

          Обработка состояний данных


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

          Вы можете предоставить доступ к LiveData через ViewModel. К примеру, MyDataState может содержать информацию о том, корректно ли загружаются данные, загрузились ли окончательно или загрузка была прервана.

          image

          Вы можете обернуть данные в клас, который содержит в себе состояния и другие метаданные (например, сообщение о ошибке). См. класс Resource в предоставленных примерах (TODO: add link)
          Expose информацию о состоянии данных, используя обертку или другой LiveData.

          Сохраняя состояние активити


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

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

          Для эффективного сохранения и восстановления состояния UI используйте комбинацию сохранения данных, onSaveInstanceState() и ViewModel.

          Для примера см.: ViewModels: Persistence, onSaveInstanceState(), Restoring UI State and Loaders Events

          События


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

          Концепция События не вписывается в то, как LiveData хранит и воссоздает данные. Представим себе ViewModel с таким полем:

          LiveData snackbarMessage = new MutableLiveData<>();

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

          snackbarMessage.setValue("Объект сохранен!");

          Активити получает значение и показывает Snackbar. Вроде всё работает.

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

          Для того, чтобы решить эту проблему в одном из наших примеров мы создали класс SingleLiveEvent (класс наследуется от LiveData). Он посылает только те обновления, которые произошли после подписки на изменения. Также обратите внимание, что класс поддерживает только одного подписчика.
          Для таких событий, как показ сообщений в Snackbar или навигации используетй observable вроде SingleLiveEvent.

          Утечки памяти в ViewModels


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

          То, как ViewModels будет сообщаться с прочими компонентами приложения — решать Вам, но остерегайтесь утечек памяти и пограничных состояний. В нижеприведенной диаграмме слой Presentation использует observer pattern и слой Data, который получает колбэки.
          Observer pattern в UI и колбэки в слой Data:

          image

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

          image

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

          image

          Этого можно достигнуть многими способами:

          • С помощью ViewModel.onCleared() Вы можете сообщить репозиторию о том, что он должен сбросить колбэк к ViewModel.
          • В репозитории Вы можете использовать WeakReference или Event Bus (использование обеих может проводиться некорректно и даже считается вредным).
          • Используйте LiveData для коммуникации между репозиторием и ViewModel также, как используете ее для коммуникации между View и ViewModel.
          Учитывайте пограничные случаи, утечки памяти и то, как долгие операции может повлиять на инстансы в Вашей архитектуре.
          Не помещайте в ViewModel логику, которая является критически важной для сохранения чистоты архитектуры или если она связана с данными. Каждый вызов, сделанный от ViewModel может быть последним.

          LiveData в репозиториях


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

          image

          Когда ViewModel очищена или когда жизненный цикл view прекратился, подписка очищается:

          image

          В этом способе есть одна тонкость: как подписаться к репозиторию от ViewModel, если нет доступа к LifecycleOwner? С помощью Трансформаций. Transformations.switchMap позволяет создавать LiveData, которая реагирует на изменения в других инстансах LiveData. За счет этого информация передается через observer жидненного цикла по цепочке:

          LiveData repo = Transformations.switchMap(repoIdLiveData, repoId -> {
                  if (repoId.isEmpty()) {
                      return AbsentLiveData.create();
                  }
                  return repository.loadRepo(repoId);
              }
          );

          Пример трансформации [ссылка]

          В этом примере, когда триггер получает обновление, выполняется функция и результат каскадируется. Активити наблюдает за репозиторием и тот же LifecycleOwner будет использован для вызова repository.loadRepo(id).
          Каждый раз, когда Вы думаете, что Вам нужен объект Lifecycle внутри ViewModel, использование Transformation скорее всего поможет этого избежать и решит проблему.

          Наследуясь от LiveData


          Самый частый вид использования LiveData это использование MutableLiveData в ViewModel представление их как LiveData для того, чтобы сделать их неизменяемыми для наблюдателей.

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

          public class MyLiveData extends LiveData {
          
              public MyLiveData(Context context) {
                  // Initialize service
              }
          
              @Override
              protected void onActive() {
                  // Start listening
              }
          
              @Override
              protected void onInactive() {
                  // Stop listening
              }
          }

          Когда не надо наследоваться от LiveData


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

          Добавьте метод start() в ViewModel и вызовите его как можно скорее [см. пример с Blueprints]
          Назначьте поле, которое прекращает загрузку [см. пример GithubBrowserExample].
          Обычно наследование от LiveData не происходит. Пусть активити или фрагмент подскажет ViewModel когда начать загружать данные.
          Оригинал статьи
          Original source: habrahabr.ru (comments, light).

          https://habrahabr.ru/post/338590/


          Метки:  

          IMaskjs — простое маскирование в браузере

          Воскресенье, 24 Сентября 2017 г. 13:49 + в цитатник
          burfee сегодня в 13:49 Разработка

          IMaskjs — простое маскирование в браузере



            Нам нужна была работающая и удобная библиотека без зависимостей для маскирования ввода — и мы ее сделали. Через полгода с момента выпуска нулевой версии была выпущена версия 1.0 с многочисленными изменениями и улучшениями:

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


            В качестве предисловия


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

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

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

            Нужны рабочие варианты из коробки. Добавлены новые маски и примеры использования.

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

            Что нового


            Библиотека увеличилась в объеме в 2 раза в основном за счет нового функционала. Наиболее значимым дополнением стали маски для работы с числами и датами:
            var numberMask = new IMask(inputElement, {
                mask: Number,
                min: -10000,
                max: 10000,
                thousandsSeparator: ' '
            });
            
            var dateMask = new IMask(inputElement, {
                mask: Date,
                min: new Date(2000, 0, 1),
                max: new Date(2020, 0, 1),
                placeholder: {lazy: false}
            });

            Демо тут.

            Фактически маска для ввода чисел — это надстройка над регулярками. А маска для ввода дат — надстройка над шаблонами. Т.к. дата состоит из условно независимых частей — дня, месяца и года, то для удобства переиспользования маски хотелось иметь возможность отдельной настройки независимых частей маски. Проблема была решена введением групп, которые являются частью основной маски, но также предоставляют возможность независимой обработки значений. Как-то так:
            var groupsMask = new IMask(inputElement, {
              mask: '19YY.MM.DD',
            
              // описание групп
              groups: {
                // общее описание группы
                YY: {
                  mask: '00',
                  // возможно использование валидатора
                  // validate: function (value, group) {}
                },
            
                // но можно создавать группы из интервала значений или перечислений
                MM: new IMask.MaskedPattern.Group.Range([1, 12]),
                DD: new IMask.MaskedPattern.Group.Range([1, 31])
              }
            });


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

            В процессе рефакторинга также были выделены модель и представление. Модель предоставляет все возможности маскирования без UI. А представление “склеивает” dom-элемент и модель маски, обеспечивая реагирование на события и обновление элемента. Также довольно просто добавить собственные обработчики событий, например, для поддержки старых браузеров (из коробки поддерживаем IE11+).

            Планы на будущее


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

            Несмотря на то, что библиотека неплохо работает в проде с несколькими сотнями тысяч активных пользователей, по-прежнему нет нормальных тестов и 0 issues на github))) Стыд и позор, нет слов. Исправляемся.
            Original source: habrahabr.ru (comments, light).

            https://habrahabr.ru/post/338566/


            Метки:  

            IMaskjs — простое маскирование в браузере

            Воскресенье, 24 Сентября 2017 г. 13:49 + в цитатник
            burfee сегодня в 13:49 Разработка

            IMaskjs — простое маскирование в браузере



              Нам нужна была работающая и удобная библиотека без зависимостей для маскирования ввода — и мы ее сделали. Через полгода с момента выпуска нулевой версии была выпущена версия 1.0 с многочисленными изменениями и улучшениями:

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


              В качестве предисловия


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

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

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

              Нужны рабочие варианты из коробки. Добавлены новые маски и примеры использования.

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

              Что нового


              Библиотека увеличилась в объеме в 2 раза в основном за счет нового функционала. Наиболее значимым дополнением стали маски для работы с числами и датами:
              var numberMask = new IMask(inputElement, {
                  mask: Number,
                  min: -10000,
                  max: 10000,
                  thousandsSeparator: ' '
              });
              
              var dateMask = new IMask(inputElement, {
                  mask: Date,
                  min: new Date(2000, 0, 1),
                  max: new Date(2020, 0, 1),
                  placeholder: {lazy: false}
              });

              Демо тут.

              Фактически маска для ввода чисел — это надстройка над регулярками. А маска для ввода дат — надстройка над шаблонами. Т.к. дата состоит из условно независимых частей — дня, месяца и года, то для удобства переиспользования маски хотелось иметь возможность отдельной настройки независимых частей маски. Проблема была решена введением групп, которые являются частью основной маски, но также предоставляют возможность независимой обработки значений. Как-то так:
              var groupsMask = new IMask(inputElement, {
                mask: '19YY.MM.DD',
              
                // описание групп
                groups: {
                  // общее описание группы
                  YY: {
                    mask: '00',
                    // возможно использование валидатора
                    // validate: function (value, group) {}
                  },
              
                  // но можно создавать группы из интервала значений или перечислений
                  MM: new IMask.MaskedPattern.Group.Range([1, 12]),
                  DD: new IMask.MaskedPattern.Group.Range([1, 31])
                }
              });


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

              В процессе рефакторинга также были выделены модель и представление. Модель предоставляет все возможности маскирования без UI. А представление “склеивает” dom-элемент и модель маски, обеспечивая реагирование на события и обновление элемента. Также довольно просто добавить собственные обработчики событий, например, для поддержки старых браузеров (из коробки поддерживаем IE11+).

              Планы на будущее


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

              Несмотря на то, что библиотека неплохо работает в проде с несколькими сотнями тысяч активных пользователей, по-прежнему нет нормальных тестов и 0 issues на github))) Стыд и позор, нет слов. Исправляемся.
              Original source: habrahabr.ru (comments, light).

              https://habrahabr.ru/post/338566/


              Метки:  

              Как на анимешниках криптовалюту добывают

              Воскресенье, 24 Сентября 2017 г. 13:22 + в цитатник
              unc1e сегодня в 13:22 Разработка

              Как на анимешниках криптовалюту добывают

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

                Он подгружал еще один wasm скрипт
                Убрано под спойлер
                image

                Искомый скрипт был впилен в iframe
                Убрано под спойлер
                image

                Который выглядил так
                Убрано под спойлер
                image

                Загрузка цп при этом достигала 100%
                Убрано под спойлер
                image

                iframe трафик любезно предоставили эти товарищи
                Убрано под спойлер
                image

                А скрипт вот эти
                Убрано под спойлер
                image
                Однако, их слоган мне понравился. Скрипт оказался monero майнером в веб исполнении.

                Сам скрипт: pastebin.com/raw/9ejjyFsN
                Основная нагрузка: filebin.ca/3bTq9sInAOxJ

                Вот такие вот дела. Этот случай произошел с одним из самых популярных сайтов рунета согласно статистике alexa. В обозримом будущем, наверняка, блокчейн и майнеры окажутся даже в наших телевизорах.
                Главным следствием из подобной ситуации является полный отказ от взаимодействия с левыми рекламодателями, которые позволяют вставлять произвольный код в рекламу.
                Original source: habrahabr.ru (comments, light).

                https://habrahabr.ru/post/338580/


                Метки:  

                Как на анимешниках криптовалюту добывают

                Воскресенье, 24 Сентября 2017 г. 13:22 + в цитатник
                unc1e сегодня в 13:22 Разработка

                Как на анимешниках криптовалюту добывают

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

                  Он подгружал еще один wasm скрипт
                  Убрано под спойлер
                  image

                  Искомый скрипт был впилен в iframe
                  Убрано под спойлер
                  image

                  Который выглядил так
                  Убрано под спойлер
                  image

                  Загрузка цп при этом достигала 100%
                  Убрано под спойлер
                  image

                  iframe трафик любезно предоставили эти товарищи
                  Убрано под спойлер
                  image

                  А скрипт вот эти
                  Убрано под спойлер
                  image
                  Однако, их слоган мне понравился. Скрипт оказался monero майнером в веб исполнении.

                  Сам скрипт: pastebin.com/raw/9ejjyFsN
                  Основная нагрузка: filebin.ca/3bTq9sInAOxJ

                  Вот такие вот дела. Этот случай произошел с одним из самых популярных сайтов рунета согласно статистике alexa. В обозримом будущем, наверняка, блокчейн и майнеры окажутся даже в наших телевизорах.
                  Главным следствием из подобной ситуации является полный отказ от взаимодействия с левыми рекламодателями, которые позволяют вставлять произвольный код в рекламу.
                  Original source: habrahabr.ru (comments, light).

                  https://habrahabr.ru/post/338580/


                  Метки:  

                  Типичное использование Observable объектов в Angular 4

                  Воскресенье, 24 Сентября 2017 г. 12:25 + в цитатник
                  lucius сегодня в 12:25 Разработка

                  Типичное использование Observable объектов в Angular 4

                    Представляю вашему вниманию типичные варианты использования Observable объектов в компонентах и сервисах Angular 4.



                    Подписка на параметр роутера и мапинг на другой Observable


                    Задача: При открытии страницы example.com/#/users/42, по userId получить данные пользователя.


                    Решение: При инициализации компоненты UserDetailsComponent мы подписываемся на параметры роутера. То есть если userId будет меняться — будер срабатывать наша подписка. Используя полученный userId, мы из сервиса userService получаем Observable с данными пользователя.


                    // UserDetailsComponent
                    
                    ngOnInit() {
                      this.route.params
                        .pluck('userId') // получаем userId из параметров
                        .switchMap(userId => this.userService.getData(userId))
                        .subscribe(user => this.user = user);
                    }


                    Подписка на параметр роутера и строку запроса


                    Задача: При открытии страницы example.com/#/users/42?regionId=13 нужно выполнить функцию load(userId, regionId). Где userId мы получаем из роутера, а regionId — из параметров запроса.


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


                    ngOnInit() {
                      Observable.combineLatest(this.route.params, this.route.queryParams)
                        .subscribe(([params, queryParams]) => { // полученный массив деструктурируем
                          const userId = params['userId'];
                          const regionId = queryParams['regionId'];
                          this.load(userId, regionId);
                        });
                    }
                    

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


                    The Router manages the observables it provides and localizes the subscriptions. The subscriptions are cleaned up when the component is destroyed, protecting against memory leaks, so we don't need to unsubscribe from the route params Observable. Mark Rajcok

                    Остановка анимации загрузки после окончания выполнения подписки


                    Задача: Показать значок загрузки после начала сохранения данных и скрыть его, когда данные сохранятся или произойдет ошибка.


                    Решение: За отображение загрузчика у нас отвечает переменная loading, после нажатия на кнопку, установим ее в true. А для установки ее в false воспользуемся Observable.finally функций, которая выполняется после завершения подписки или если произошла ошибка.


                    save() {
                      this.loading = true;
                      this.userService.save(params)
                        .finally(() => this.loading = false)
                        .subscribe(user => {
                          // Успешно сохранили
                        }, error => {
                          // Ошибка сохранения
                        });
                    }

                    Создание собственного источника событий


                    Задача: Создать переменную lang$ в configService, на которую другие компоненты будут подписываться и реагировать, когда язык будет меняться.


                    Решение: Воспользуемся классом BehaviorSubject для создания переменной lang$;


                    Отличия BehaviorSubject от Subject:


                    1. BehaviorSubject должен инициализироваться с начальным значением;
                    2. Подписка возвращает последнее значение Subjectа;
                    3. Можно получить последнее значение напрямую через функцию getValue().

                    Создаём переменную lang$ и сразу инициализируем. Так же добавляем функцию setLang для установки языка.


                    // configService
                    lang$: BehaviorSubject = new BehaviorSubject(DEFAULT_LANG);
                    setLang(lang: Language) {
                      this.lang$.next(this.currentLang); // тут мы поставим
                    }

                    Подписываеся на изменение языка в компоненте. Переменная lang$ является "горячим" Observable объектом, то есть подписка требует отписки при разрушении объекта.


                    private subscriptions: Subscription[] = [];
                    ngOnInit() {
                      const langSub = this.configService.lang$
                        .subscribe(() => {
                          // ...
                        });
                      this.subscriptions.push(langSub);
                    }
                    ngOnDestroy() {
                      this.subscriptions
                        .forEach(s => s.unsubscribe());
                    }

                    Использование takeUntil для отписки


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


                    private ngUnsubscribe: Subject = new Subject();
                    
                    ngOnInit() {
                      this.configService.lang$
                        .takeUntil(this.ngUnsubscribe) // отписка по условию
                        .subscribe(() => {
                          // ...
                        });
                    }
                    
                    ngOnDestroy() {
                      this.ngUnsubscribe.next();
                      this.ngUnsubscribe.complete();
                    }

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


                    Использование Observable для автокомплита или поиска


                    Задача: Показывать предложения страниц при вводе данных на форме


                    Решение: Подпишемся на изменение данных формы, возьмём только меняющиеся данные инпута, поставим небольшую задержку, чтобы событий не было слишком много и отправим запрос в википедию. Результат выведем в консоль. Интересный момент в том, что switchMap отменит предыдущий запрос, если пришли новые данные. Это очень полезно, для избегания нежалательных эффектов от медленных запросов, если, к например, предпоследний запрос выполнялся 2 секунды, а последий 0.2 секунды, то в консоль выведется результат именно последнего запроса.


                    ngOnInit() {
                      this.form.valueChanges
                        .takeUntil(this.ngUnsubscribe)      // отписаться после разрушения
                        .map(form => form['search-input'])  // данные инпута
                        .distinctUntilChanged()             // брать измененные данные
                        .debounceTime(300)                  // реагировать не сразу
                        .switchMap(this.wikipediaSearch)    // переключить Observable на запрос в Вики
                        .subscribe(data => console.log(data));
                    }
                    
                    wikipediaSearch = (text: string) => {
                      return Observable
                        .ajax('https://api.github.com/search/repositories?q=' + text)
                        .map(e => e.response);
                    }

                    Кеширование запроса


                    Задача: Необходимо закешировать Observable запрос


                    Решение: Воспользуемся связкой publishReplay и refCount. Первая функция закеширует одно значение функции на 2 секунды, а вторая будет считать созданные подписки. То есть, Observable завершится, когда все подписки будут выполнены. Тут можно прочитать подробнее.


                    // tagService
                    
                    private tagsCache$ = this.getTags()
                      .publishReplay(1, 2000) // кешируем одно значение на 2 секунды
                      .refCount()             // считаем ссылки
                      .take(1);               // берем 1 значение
                    
                    getCachedTags() {
                      return tagsCache$;
                    }

                    Последовательный combineLatest


                    Задача: Критическая ситуация на сервере! Backend команда сообщила, что для корректного обновления продукта нужно выполнять строго последовательно:


                    1. Обновление данных продукта (заголовок и описание);
                    2. Обновление списка тегов продукта;
                    3. Обновление списка категорий продукта;

                    Решение: У нас есть 3 Observable, полученных из productService. Воспользуемся concatMap:


                    const updateProduct$ = this.productService.update(product);
                    const updateTags$ = this.productService.updateTags(productId, tagList);
                    const updateCategories$ = this.productService.updateCategories(productId, categoryList);
                    
                    Observable
                      .from([updateProduct$, updateTags$, updateCategories$])
                      .concatMap(a => a)  // выполняем обновление последовательно
                      .toArray()          // Возвращает массив из последовательности
                      .subscribe(res => console.log(res)); // res содержит массив результатов запросов

                    Загадка на посошок


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


                    Полезные ссылки


                    • Заворожённо посмотреть на шарики: rxviz.com
                    • Потаскать шарики мышкой: rxmarbles.com
                    Original source: habrahabr.ru (comments, light).

                    https://habrahabr.ru/post/337512/


                    Метки:  

                    Баг или фича в Facebook Messenger — Опрос

                    Воскресенье, 24 Сентября 2017 г. 12:02 + в цитатник


                    Если написать в Facebook Messenger сообщение и добавить к нему ссылку, а потом удалить ее, то ссылка всё равно будет отправлена.

                    Читать дальше ->

                    https://habrahabr.ru/post/338576/


                    Метки:  

                    [Из песочницы] Cоздаём компонент карт Google Maps API с помощью VueJs2

                    Суббота, 23 Сентября 2017 г. 23:03 + в цитатник
                    BRAINKIT вчера в 23:03 Разработка

                    Cоздаём компонент карт Google Maps API с помощью VueJs2

                    Google Maps API — это сервис геолокации. С помощью этого сервиса мы можем отобразить карту и места на карте.

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

                    Чтобы создать компонент на основе статьи, нужно самостоятельно подготовить «hello word» приложение на VueJs2 с использованием es6. Итак по порядку:

                    Установка доступа к API


                    Для начала нужно получить API ключ на странице. После получения ключа, мы добавим скрипт подключения google maps api в файл index.vue нашего приложения

                    
                    

                    В скрипте необходимо заменить "[YOUR API KEY]" на ваш ключ Google Maps API.
                    Скрипт даёт доступ к глобальному google объекту, который будет использоваться для создания карты.

                    Создание основной структуры файлов


                    Структура файлов будет состоять из папки components, в ней файл googleMap.vue для реализации компонента и файл index.vue — основной файл «hello word» приложения.

                    Начнём с создания шаблона в googleMap.vue:

                    
                    

                    Для возможности установки нескольких карт на одной странице, добавим атрибут id с параметром name — имя карты, будет задаваться в параметрах компонента.

                    Параметры компонента и логика работы карты храниться в части файла со скриптами. Подготовим основу для скриптов компонента в файле googleMap.vue:

                    
                    

                    В коде выше: название компонента google-map, свойство name, метод data в котором будут храниться параметры, метод mounted который вызывается при создании компонента и объект methods в котором будут вызываться методы работы с картой.

                    Теперь добавим немного стилей для карты:

                    
                    

                    Бинго!

                    Основа файла компонента готова, далее вызовем компонент в файле index.vue:

                    
                    
                    

                    Компонент вызывается тегом google-map, который используется для названия компонента. Сам компонент загружается через метод import и присоединяется к index.vue в объекте components.

                    После создания структуры файлов и основного кода, компонент подключается, но карта не отображается, для отображения нужно создать новую карту с помощью new google.maps.Map

                    Отображение карты


                    Вернёмся к файлу компонента. Скрипт, который добавляет карту вызовем в методе mounted, этот метод вызывается после загрузки шаблона, соответственно доступен заготовленный пустой div. В методе mounted создадим новую карту с помощью new google.maps.Map. Карта будет дочерним объектом нашего div. Минимально для создания карты укажем zoom level и координаты центра:

                    export default {
                            name: 'google-map',
                            props: ['name'],
                            data: function () {
                                return {
                                    map: ''
                                }
                            },
                            computed: {
                                mapMarkers: function () {
                                    return this.markers
                                }
                            },
                            mounted: function () {
                                const element = document.getElementById(this.name)
                                const options = {
                                    zoom: 14,
                                    center: new google.maps.LatLng(59.93, 30.32)
                                }
                                this.map = new google.maps.Map(element, options)
                            },
                            methods: {}
                        }
                    

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

                    image

                    Добавление маркеров


                    Карта видна, центрирована, но на ней ещё нет объектов!

                    Для добавления объектов создадим массив маркеров, в котором будут содержаться координаты. Для простоты, массив поместим в файл компонента, далее его можно вынести в массив props:

                    data: function () {
                       return {
                           map: '',
                           markers: [
                               {
                                   position: {
                                       latitude: 59.93,
                                       longitude: 30.32
                                   }
                               },
                               {
                                   position: {
                                       latitude: 59.928,
                                       longitude: 30.32
                                   }
                               }
                           ]
                       }
                    }
                    

                    В массиве 2 объекта маркеров, в которых в position хранятся координаты маркеров. Координаты сохранены отдельно в position, чтобы в будущем было удобно добавить другие поля маркерам, например title.

                    После создания массива маркеров — нужно добавить их на карту, для этого внутри функции mounted обойдём массив, а в процессе обхода создадим маркер с помощью new google.maps.Marker:

                    mounted: function () {
                                const element = document.getElementById(this.name)
                                const options = {
                                    zoom: 14,
                                    center: new google.maps.LatLng(59.93, 30.32)
                                }
                                this.map = new google.maps.Map(element, options)
                                this.markers.forEach((marker) => {
                                    const position = new google.maps.LatLng(marker.position.latitude, marker.position.longitude)
                                    marker.map = this.map
                                    marker.position = position
                                    new google.maps.Marker(marker)
                                })
                            }
                    

                    В процессе обхода мы сначала создали объект position — который необходим для указания позиции маркера, далее привязали к маркеру объект карты map и позицию position, далее создали маркер с помощью new google.maps.Marker(marker)

                    Готово!

                    Карта теперь выглядит так:

                    image

                    Итоговый код компонента:

                    
                    
                    
                    
                    
                    

                    Если установлен eslint, его нужно отключить командами eslint-disable/eslint-enable для секции mounted, чтобы он не ругался на объект google.maps.

                    Итоговый код index файла:

                    
                    
                    
                    

                    Статья создана по мотивам вот этой статьи.
                    Original source: habrahabr.ru (comments, light).

                    https://habrahabr.ru/post/338568/


                    Метки:  

                    Лекция Илья Сегаловича «Как создать компанию — мирового лидера?»

                    Суббота, 23 Сентября 2017 г. 19:31 + в цитатник
                    Leono сегодня в 19:31 Управление

                    Лекция Илья Сегаловича «Как создать компанию — мирового лидера?»

                      На этой неделе Яндексу 20 лет. Перед вами одна из последних лекций Ильи iseg Сегаловича.




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

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

                      Это воспринималось просто абсолютнейшим безумием. С другой стороны, возраст такой — в общем-то, терять нечего. Не то что я трагически это все воспринял, но через годик я сам к нему пришел и говорю: «Слушай, у тебя работа не найдется для меня попрограммировать чего-нибудь?» Он говорит: «Ну давай приходи». Я подключился, и работа, на которую я пришел ради приработка, — она оказалась достаточно интересной, а потом такой интересной, что захватила всю мою жизнь. Работа была связана с изготовлением поисковых систем для компьютеров IBM PC.

                      Тогда у нас был первый продукт. Он назывался «Международный классификатор изобретений для патентоведов». Таких было семь толстых книг, которые никакой нормальный человек прочитать или даже просмотреть или выучить наизусть был совершенно не в состоянии, а нужно было быстро ориентироваться, находить нужные рубрики. Мы сделали все это, по-моему, на десяти дискетах, и с этого началась моя трудовая биография в этой компании: я занимался форматированием дискет. Это не самая интеллектуальная деятельность. Почему я не программировал? Там смешная история была. Я к нему прихожу и говорю: «Давай».

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

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

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

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

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

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

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

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

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

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

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

                      Результат получился довольно приятный. Мы продали тысячу экземпляров. Это безумная сумма — 40 000 долларов. Она очень долго к нам приходила, наверное, два или три года, но как результат — нашу группу из CompTek, из этой компании, которая занималась «железом», не выгнали, хотя все предпосылки к этому были, потому что бухгалтер все время, когда платила зарплату, она смотрела на нас так и думала: «Что эти бездельники здесь делают?» Компания зарабатывает, она «железо» продает, а эти какие-то непонятные программисты тут сидят, программируют и на какую-то копеечку продают.

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

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

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

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

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

                      Мы стремились сделать так, как надо, то есть мы стремились сделать так, чтобы это было идеально с точки зрения user experience, с точки зрения качества, удовольствия от владения продуктом и так далее. Даже когда мы не занимались интернетом, а занимались локальными продуктами, все равно требования мы ставили себе максимальные. Когда мы подключились к интернету, я помню, где-то примерно тогда я обнаружил такую систему — AltaVista. Они закрылась три дня назад. В общем, наверное, никто не обратил внимания на эту новость, но люди, кто в интернете давно, — у них в этот момент скатилась скупая слеза.

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

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

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

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

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

                      Илья:
                      — Я бы отметил два таких момента в девяностые годы. Во-первых, примерно в 1993–1994 году, когда мы еще не подключились к интернету, еще у нас не было Библии, а наши старые продукты уже прогорали, и нужно было как-то выжить. Мы буквально зацепились, сделав эту Библию. Это нас спасло протянуть год-два.

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

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

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

                      Обычно если инвесторы дают деньги, особенно в России, то говорят: сейчас мы будем командовать и говорить, что делать, а что не делать. Это был очень тонкий момент.

                      Еще один был момент — примерно в районе 2002–2003 года, когда мы выныривали из этого минуса, когда мы прожигали инвесторские деньги. Интернет тогда очень мало еще зарабатывал, но мы учились жить на самоокупаемости. Это был довольно острый момент. Мы примерно три года вообще не росли или почти не росли. Когда мы получили деньги, инвестиции, мы набрали примерно сто человек за год, и мы на этом уровне находились примерно два или три года, как минимум до 2004-го.

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

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

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

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

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

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

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

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

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

                      Нужно было, например, сделать какой-нибудь анонс — мы выходили в середину, а там сидели ребята, аквариум был такой смешной. Назывались technical support. Они отвечали на возмущенные письма пользователей. Люди пишут: «Почему у меня Яндекс.Почта не работает целый час? Почему у меня файлы на Народе? У нас тогда был Народ, Почта, Новости, поиск. В общем, много разных, и ребята отвечали на эти письма.

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

                      Что еще такого интересного рассказать? Мы приближаемся к самому главному: будущее человечества, интернета и поисковых систем. Давайте еще немножечко про историю — не про будущее, а просто про пот и кровь нашего бизнеса, про то, что мы собственно делаем. Когда мы в 2000 году рискнули и взяли инвестиции, стартовали компанию, у нас тоже был выбор. Мы не знали, как вообще подойти. Вариант А — можно было сохранять фокус на поиске и ничего больше не делать, оставаться такой чисто поисковой системой. Но мы понимали, что вокруг нас происходит совершенно другой бизнес, люди набирают аудиторию проектами аудиторными.

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

                      Поэтому как-то так получилось, что у меня в команде были люди, которые мехмат заканчивали, ВМК, а я ими всеми руководил нахально. Не то что руководил — слово «руководил» не подходит. Коммуницировал, как бы так выразиться. То есть я их понимал, они меня понимали. Достаточно сказать, что у нас из первоначальной команды до сих пор никто не уволен, никто не ушел. Мы очень сплоченный и дружный коллектив много лет. Это базовая четверка–шестерка людей. Мы до сих пор все в Яндексе, уже 12-15 лет. У нас есть такой внутренний сайт: staff.yandex-team.ru. В нем есть дата приема на работу, и люди гордятся. У кого-то есть дата приема на работу — 1992 год, то есть Яндекса еще не было, вообще ничего не было, а люди уже работали над этим проектом.

                      Зритель:
                      — А компания Яндекс в каком году?..

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

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

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

                      Команда хардкорных С++-программистов, которые всю жизнь решали алгоритмические задачи на сервере, писали на FreeBSD, на UNIX, — хотя у нас всех был бэкграунд Windows, поэтому нельзя сказать, что у нас Windows (неразборчиво — прим. ред.) был очень большой. Я очень извиняюсь, что я говорю технические вещи, но, может, кто-то понимает. Поэтому у нас был репозиторий, который сразу компилировался на Linux, FreeBSD и Windows. Это было заведено в 1996 году и до сих пор так, то есть до сих пор у нас большая часть кода помогает его делать очень качественным, компактным, хорошо компилируемым, ошибки позволяет находить и так далее. И потом Windows позволяет это хорошо отлаживать.

                      Это была такая компашка хардкорных программистов на С++, алгоритмистов — и тут надо творить какой-то РНР-кошмар: narod.ru, еще чего-то. Это была какая-то совершенно для нас не дискомфортная вещь, но пришлось переступить через себя. Я считаю, что тут первую скрипку сыграл опять Аркаша. Он просто взял каких-то хороших ребят, менеджеров. На самом деле первым менеджером был парень, который делал 1С для CompTek. Он говорит: «Дима, давай ты будешь менеджером и сделаешь нам быстренько вот это, вот это и вот это на PHP». «Да, давай».

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

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

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

                      Во-вторых, она тоже немножечко про драматизм, про изменение сознания. Когда мы стартовали в 2000 году как самостоятельная компания, то нашими инвесторами были западные фонды. Вообще, Baring Vostok Capital Partners — это фонд, основанный еще в середине девяностых годов. Там формально два руководителя, космонавта: Стратфорд и Леонов. Они встречались в «Союз — Аполлоне». Этот фонд статусный. Там в основном, по-моему, английские деньги, американские деньги, русские деньги, там перемешано. Нормальный успешный фонд. Они двадцать лет существуют в России. В основном пароходствами занимались, еще чем-то там, пшеном, зерном.

                      Я не собираюсь исследовать деятельность этой замечательной компании, но группа людей, которая работает с нами, это очень симпатичные люди, потому что они нам точно не мешали, и всегда от них исходил позитив. Они не пытались захавать нас, изменить нашу политику, а просто нормальные такие грамотные финансовые инвесторы. Когда они к нам пришли, они сказали: «Ребята, мы все будем делать вчистую, по-белому, белые зарплаты». Тогда были зарплаты очень маленькие, и не так было принципиально, белые они или нет. Зарплата программиста была 600 долларов. Это не очень большие деньги были, но мы решили, что надо делать все вбелую, как-то согласились внутренне на это и поддержали это.

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

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

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

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

                      Каково же было удивление наших сотрудников, когда Яндекс вышел на IPO. Никто не продавал ничего практически. Обладатели большого количества акций чуть-чуть продавали до IPO, чтобы просто переехать в другую квартиру, например, но когда в 2011 году случилось IPO, и выяснилось, что в компании «Яндекс» 120 миллионеров, это был шок в каком-то смысле для всех. Ко мне подходили люди. Помню, Саша ко мне подходит и говорит: «Илья, вы знаете, я хочу вам сказать одну вещь. Помните, вы мне дали в 2005 году?» Я говорю: «Да». «Я ведь тогда относился к этому совершенно… Вы знаете, я хотел бы сказать, я потрясен». Ощущение этого клуба, коллектива близких людей.

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

                      Зритель:
                      — Есть стереотип, что сделать карьеру в IT-сфере для девушки практически нереально. Так ли это?

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

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

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

                      У меня нет внутренних различий. Так же и для Аркаши, и для большинства ребят, которые в компании с основания. Для нас нет этого разделения, но объективно, статистически заметный перекос: очень много девушек-менеджеров и меньше программистов. Если говорить про опционную программу, есть ли девушки-миллионеры? Да, есть и мультимиллионеры. Сколько у нас директоров-девушек? Лена, Женя Завалишина, Катя Фадеева, юрист. В общем, в нашем иконостасе треть девушек, так что все нормально. Иконостас — это у нас такая страничка, где фотографии руководителей компании.

                      Зритель:
                      — Добрый вечер! Я Евгений из МГТУ. На самом деле нас много учат общаться и воспринимать идеи и инновации — такое очень модное слово. Мне бы очень хотелось узнать про инновации, которые есть в Яндексе, про то, что вы делаете реально лучше многих. Я знаю некоторые из них, но мне кажется, из первых уст это было бы более интересно услышать, тем более вы уже 15 лет на передовой сервисов.

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

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

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

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

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

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

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

                      Я сейчас начинаю думать про это глубже и понимаю, что, наверное, через 5–7 лет такой способ ловли такси просто вымрет, то есть люди будут делать 90% вещей из смартфона. Там столько плюсов, и они в сумме начинают перевешивать — это и безопаснее, и у вас ситуация полностью trackable, то есть вы знаете, кого вы вызвали и так далее, то есть там все становится прозрачно, и биллинг прозрачный. Вы можете c карточки просто снять деньги, без денег вы можете ехать. У нас вокруг Яндекса столовые, которые кормят по бейджику. Знаете, да? Бейджик Яндекса является платежным средством. У нас примерно двадцать ресторанов вокруг, и в них можно есть Яндексом. Ситуация, когда у вас вообще ни копейки у вас в кармане, ничего кроме бейджика, и вы можете пообедать.

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

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

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

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

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

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

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

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

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

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

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

                      Первый сценарий — пойти водителем грузовика. Аня рассказывала про «Детей Марии». У нас тоже десять лет назад был момент, когда очень нужен был автобус в студии, и представитель Toyota подарил нам старую Toyota. Ну, как подарил? Продал, но дешево. Фокус был в том, что было четырнадцать мест. Четырнадцать мест — это уже водительские права категории D. Значит, нужно было их как-то получать, а никого не было. Поэтому я пошел, честно два месяца отучился на каком-то жутком ЛАЗе. Очень интересно.

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

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

                      Второе — программистом. Программистом под расстрелом, под угрозой голода семейного я вполне смогу, думаю, на чем-нибудь таком простеньком, на Python что-нибудь ваять, какие-нибудь сайтики — с удовольствием. Не опозорюсь.

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

                      Илья:
                      — Это очень хороший и глубокий вопрос, он философский. Вся наша Школа анализа данных, наши 140 выпускников, которые работают, они в основном заняты искусственным интеллектом, и искусственный интеллект моделирует поведение человека. То есть всё, чему учат у нас в школе, — мы учимся, как предсказывать человека: что он любит, что он не любит, что ему кажется полезным, что ему кажется бесполезным, какой перевод ему нравится, что он сейчас сказал, и машина должна понять, что он сказал. Мы все время читаем человека, мы все время предсказываем человека, а с погодой — это такая фишка.

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

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

                      Зритель:
                      — У меня вопрос по поводу ошибок. Вообще были они? Они сбивали или направляли, вдохновляли? Как? Вот ошибки в работе компьютера.

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

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

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

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

                      Зритель:
                      — Меня зовут Роман. Я представитель Тюменского госуниверситета. У меня такой вопрос. Как вы строите свои отношения с органами государственной власти? Я вспомнил, что произошел такой информационный скандал с увольнением главы РЖД. Было такое в медиапространстве, и там был Яндекс замешан. Все-таки это уже мощный такой информационный ресурс. Как вообще выстраиваете свою политику в этом плане?

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

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

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

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

                      Зритель:
                      — Здравствуйте, Илья! Меня зовут Сергей. Я хочу вам два вопроса задать. Первый касается Яндекс.Такси. Он сейчас работает только в Москве и в Петербурге. Когда же вы планируете уже продвигаться на рынки других городов?

                      Илья:
                      — Во-первых, по-моему, еще где-то. По-моему, еще несколько городов.

                      Зритель:
                      — А Екатеринбург когда будет?

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

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

                      Илья:
                      — Самообразовывался я еще когда-то давно по книжкам, из-за чего выстаивал в очередях в начале девяностых годов. Когда вышел в интернет, то самообразовывался в интернете. Примерно до 2008 года у нас не было мирового поиска вообще. У нас был довольно тонкий слой в основном главных страниц западных сайтов, которые мы как-то втаскивали в Яндекс, и этого нам хватало существенным образом для потока нашей аудитории, потому что, по-моему, 90% аудитории не требовался английский. С 2008 года у нас был первый запуск, в 2010 или в 2011 году — второй. У нас сейчас довольно большая английская база, и мы очень интенсивно работали особенно в прошлом и позапрошлом году над качеством этого поиска.

                      Поэтому я сам лично 80–90% всей западной технической литературы и информации нахожу сейчас на yandex.ru или на yandex.com. Это очень важный принцип. Это принцип, что ешьте свой собственный догфуд, то есть, если вы не едите, это никто не сможет есть. Поэтому я ищу в Яндексе, но у меня нет никаких религиозных проблем с этим. Я и к Google хорошо, и к Microsoft хорошо отношусь. У нас нет вообще в компании запретов на использование Google или еще чего-то такого: «Оставьте Google, всяк сюда входящий». Нет ничего такого.

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

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

                      Мы видим, что они стараются эту информацию, естественно, с разрешения пользователя получить и улучшить жизнь пользователя. У них есть такой продукт Google Now, сейчас он называется просто Google Services, если не ошибаюсь. Я не могу сказать, что я в полном от него восторге, точно так же я не разделяю восторги по поводу Google Glass. Я очень ценю пиар-кампанию, очень ценю пиар-команду Google, но, так сказать, сердце мое не бьется учащенно от этого продукта. Я им пользуюсь, но оно не бьется, но там идея примерно такая, как вы говорите.

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

                      Если отбросить в сторону конспирологию и

                      Метки:  

                      [Из песочницы] Кто, как и зачем собирается регулировать Big Data в России?

                      Суббота, 23 Сентября 2017 г. 16:29 + в цитатник
                      akolesov сегодня в 16:29 Управление

                      Кто, как и зачем собирается регулировать Big Data в России?

                      Сегодня утром получил очередное PR-письмо с таким очередным предложением:

                      Готовы предоставить комментарий с анализом и прогнозом по законопроекту о регулировании Big Data будет, который будет готов к концу 2017 года.

                      Тема («регулирование Big Data») меня сразу заинтересовала (я был у ее истоков ), и я спросил в ответ: «О каком именно законопроекте спич?»

                      «Вот об этом, ria.ru/technology/20170919/1505085765.html», — оперативно ответила мой контрагент по переписке:

                      Медиа-Коммуникационный союз (МКС) к концу 2017 года представит законопроект, в том числе регулирующий использование «больших» пользовательских данных (Big Data), рассказал РИА Новости глава Роскомнадзора Александр Жаров

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

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

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

                      3. При этом новость РИА трудно назвать новостью. Дело в том, что о подобной идее по созданию «Закона о Big Data» говорили, и в начале июне этого года, и даже осенью прошлого, причем год назад тот же г-н Жаров говорил о вопросе, почти как об уже решенном, сказав тогда (как и сейчас), что законопроект будет готов к концу года (но в тот раз говорилось о конце 2016 года).

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

                      И вот тут я хочу вернуться к истоку темы «регулирования Big Data».

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

                      Этот вопрос – «чем вызвана сама повестка дня?» – был задан тогда организаторам, на что они дали ответ – «Правительство попросило нас изучить вопрос».

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

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

                      Да, конечно, за два года (с того экспертного обсуждения) многое могло произойти. «Все течет, все изменяет…» Вполне возможно, теперь обнаружились проблемы.

                      Но хорошо бы узнать – какие?
                      Original source: habrahabr.ru (comments, light).

                      https://habrahabr.ru/post/338560/


                      Метки:  

                      [Перевод] Go: 10 лет и растём дальше

                      Суббота, 23 Сентября 2017 г. 16:15 + в цитатник
                      divan0 сегодня в 16:15 Разработка

                      Go: 10 лет и растём дальше

                      • Перевод

                      На этой неделе мы отмечаем 10-летнюю годовщину создания Go.


                      Всё началось с обсуждения вечером в четверг, 20 сентября 2007. Оно привело к организованной встрече между Робертом Грисмайером, Робом Пайком и Кеном Томпсоном в 2 часа дня на следующий день в конференс-руме Yaounde в Здании 43 главного кампуса Google Mountain View. Название для языка появилось 25-го числа, несколько сообщений спустя после начала переписки о дизайне:


                      Тема: Re: обсуждение языка программирования 
                      От: Роб 'Коммандер' Пайк 
                      Дата: Вт, Сен 25, 2007 в 3:12 PM
                      Кому: Роберт Грисмайер, Кен Томпсон    
                      
                      у меня возникло пару мыслей по этому поводу на пути домой.
                      
                      1. имя
                      
                      'go'. можно найти оправдания для такого имени, но у него очень хорошие свойства.
                      оно короткое, легко печатать, например: goc, gol, goa. если будет интерактивный 
                      дебаггер/интерпретатор, он может быть просто назван 'go'. расширение файла .go
                      ...

                      (Следует отметить, что язык называется Go; "golang" происходит от названия сайта (go.com был уже занят компанией Disney), но это не есть правильное название языка)


                      Днем Рождения проекта Go официально является 10 ноября 2009 — день, когда проект был открыт open-source миру, сначала на code.google.com, перед тем как мигрировал на Github несколько лет позднее. Но сейчас давайте считать дату рождения от фактического рождения языка, двумя годами ранее, что позволит нам заглянуть глубже в прошлое, увидеть более полную картину и стать свидетелями некоторых более ранних событий из истории Go.


                      Первым большим сюрпризом в разработке Go было получение вот этого письма:


                      Тема: Фронтенд gcc для Go
                      От: Ян Ленс Тэйлор 
                      Дата: Сб, Июнь 7, 2008 в 7:06 PM
                      Кому: Роберт Грисмайер, Роб Пайк, Кен Томпсон
                      
                      Один из моих коллег показал мне http://.../go_lang.html .
                      Выглядит очень интересным языком и я сделал gcc фронтенд
                      к нему. Понятно, там ещё много чего не хватает, но он может
                      скомпилировать код для решета Эратосфена с главной страницы.

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


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


                      Расс Кокс присоединился к зарождающейся команде Go тоже в 2008-м, принеся массу свежих трюков с собой. Расс открыл — и это именно подходящее слово — что обобщённая природа методов в Go означает, что функции тоже могут иметь методы, что привело к появлению http.HandlerFunc, что было очень неожиданно для нас всех. Расс родил и другие интересные идеи, вроде io.Reader и io.Writer интерфейсов, которые сформировали структуру всех I/O библиотек.


                      Джини Ким, которая была нашим продакт менеджером вначале, наняла специалиста по безопасности Адама Лангли, чтобы помочь нам запустить Go в мир. Адам сделал огромное количество вещей, которые не сильно широко известны, включая создание первой версии сайта golang.org и дашборда сборки, но, конечно, главным его вкладом были криптографические библиотеки. Поначалу они казались непропорционально большими и по размеру и по сложности, по крайней мере для многих из нас, но они стали фундаментом для столь большого количества сетевого и криптографического кода, что стали ключевой частью истории Go. Сетевые инфраструктурные компании вроде Cloudflare зависят очень сильно от работ Адама в Go, и интернет благодаря ним стал лучше. Равно как и Go, за что огромная благодарность Адаму.


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


                      Роль Go в облачной экосистеме на самом деле даже больше. В марте 2014 Donnie Berkholz, в статье для RedMonk, написал, что Go был "появляющимся языком для облачной инфраструктуры". Примерно в тоже время Derek Collision из Apcera указал, что Go был уже языком для облака. Это могло быть ещё не так истинно в те дни, но как слово "появляющийся" и указывало, это становилось всё более истинно.


                      Сегодня Go это язык для софта в облаке, и одна мысль о том, что язык, которому всего 10 лет, стал доминирующим в такой большой и быстрорастущей индустрии это успех, о котором можно только мечтать. И если вам кажется, что "доминирует" это слишком сильное слово, посмотрите на интернет внутри Китая. Какое то время, высокая популярность Go в Китае, показываемая Google trends намекала на какую-то ошибку, но каждый, кто был хоть раз на Go конференциях в Китае, понимает, что эта популярность реальна. Go невероятно популярен в Китае.


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


                      Говоря о гоферах, это было забавно наблюдать, как идея маскота Рене Френч — гофер Go — стала не только самым излюбленным созданием, но и символом Go программистов по всему миру. Многие из крупнейших Go конференций называются GopherCons, так как собирают гоферов со всего мира.


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


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


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


                      Что принесут следующие 10 лет?


                      • Роб Пайк, с Робертом Грисмайером и Кеном Томпсоном
                      Original source: habrahabr.ru (comments, light).

                      https://habrahabr.ru/post/338556/


                      Метки:  

                      [Перевод] Офис открытого типа умер?

                      Суббота, 23 Сентября 2017 г. 14:41 + в цитатник
                      m1rko сегодня в 14:41 Управление

                      Офис открытого типа умер?

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

                      Как мы к этому пришли


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

                      Не прошло и десяти лет, как Роберт Пропст, исполнительный директор Herman Miller, изобрёл кубикл — и стены вернулись. Пропст критиковал офисы открытого типа как пустыню, которая «высасывает жизненную энергию, мешает талантам, делает тщетными любые достижения». Он представлял себе кубиклы как способ дать свободу работникам, обеспечив им приватность и персональное пространство. К сожалению, большинство компаний свело его просторные, гибкие планировки ко всем нам известным депрессивным, но менее дорогим, перенаселённым бежевым кубиклам. (В интервью от 1998 года сам Пропст обвинил компании, что они превратили его оригинальную идею в «адские дыры»).

                      Сегодня планировки офисов открытого типа вернулись, чтобы отомстить. В исследовании 2013 года, проведённом CoreNet Global, ассоциацией для корпоративных менеджеров по недвижимости, более 80% респондентов сказали, что их компании перешли на открытую планировку. И опять начали проявляться негативные последствия. В последние пять лет этот прогрессивный дизайн, который предполагался прогрессивным, атаковало множество статей с алармистскими заголовками вроде «Смерть офисам открытого типа!» и «Офисы открытого типа созданы дьяволом в самых глубоких пещерах ада».

                      Так что конкретно не так с современными планировками открытых офисов и как организовать пространство в соответствии с изначальными обещаниями более радостной и эффективной совместной работы?

                      В чём проблема


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

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

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

                      Как знает каждый, кому приходилось звонить врачу по телефону в офисе открытого типа, один из главных недостатков открытых планировок в том, что вы не можете контролировать, кого вы слышите — а кто слышит вас. В исследовании 2013 года о компромиссах приватности в офисах открытого типа, 60% работников в кубиклах и 50% работников в офисах без перегородок значительной проблемой назвали отсутствие конфиденциальности переговоров.

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

                      Офис будущего уже здесь


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

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

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

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

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

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

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

                      https://habrahabr.ru/post/338552/


                      Метки:  

                      Kак Microsoft пытается отправить мобильную почту к себе

                      Суббота, 23 Сентября 2017 г. 11:03 + в цитатник
                      hardpoint сегодня в 11:03 Разработка

                      Kак Microsoft пытается отправить мобильную почту к себе



                        Хранит ли Outlook-iOS-Android копию почтового ящика на сервере микрософт?


                        В подвешенном состоянии очутились многие корпоративные пользователи, которые недавно обновились до iOS 11. Дело в том, что после обновления перестает работать стандартный клиент (Mail.app) с ресурсами на Exchange Server 2016, Office 365 или Outlook.com
                        Отправка сообщения заканчивается ошибкой «Cannot Send Mail. The message was rejected by the server.»
                        Проблема заключается в том, что Exchange 2016 использует HTTPS / 2 TLS-соединения для своих клиентов. Когда почтовое приложение iOS пытается подключиться к Exchange с помощью ActiveSync, оно неправильно согласовывает соединение.


                        Microsoft подтвердило проблему и в качестве решения предлагает установить клиента Outlook for iOS.

                        Данное решение весьма спорное, т.к. программа Outlook не подключается напрямую к почтовому серверу, а с введенными учетными записями сервер Microsoft, расположенный в США, подключается к вашему серверу и, скорее всего, загружает на него копию вашего почтового ящика.

                        Ниже приведен фрагмент анализа логов подключения из программы SkypeTime.



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

                        news.ok.ubc.ca/it/2015/02/03/outlook-app-for-ios-and-android-devices-blocked
                        blog.winkelmeyer.com/2015/01/warning-microsofts-outlook-app-for-ios-breaks-your-company-security
                        blog.winkelmeyer.com/2015/02/updates-on-the-latest-outlook-ios-app-issues

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

                        New-ActiveSyncDeviceAccessRule -QueryString "Outlook for iOS and Android" -Characteristic DeviceModel -AccessLevel Block

                        Надеюсь данная информация будет кому то полезна.
                        Original source: habrahabr.ru (comments, light).

                        https://habrahabr.ru/post/338542/


                        Метки:  

                        Трансляция с геймдев-конференции 4C в Санкт-Петербурге. День второй

                        Суббота, 23 Сентября 2017 г. 09:57 + в цитатник
                        Wargaming сегодня в 09:57 Разработка

                        Трансляция с геймдев-конференции 4C в Санкт-Петербурге. День второй

                          Продолжаем текстовую трансляцию с геймдев-конференции 4C в Санкт-Петербурге.



                          Видео-стрим: www.facebook.com/4CSPb/videos/1849539205375515

                          Original source: habrahabr.ru (comments, light).

                          https://habrahabr.ru/post/338526/


                          Метки:  

                          Поиск сообщений в rss_rss_hh_full
                          Страницы: 1824 ... 1544 1543 [1542] 1541 1540 ..
                          .. 1 Календарь