Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 30910 сообщений
Cообщения с меткой

google - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

На каких основаниях Alphabet претендует на членство в «клубе четырех запятых»

Пятница, 26 Августа 2016 г. 19:22 (ссылка)





Alphabet возник чуть более года назад, в результате реструктуризации Google. Все акции Google были полностью конвертированы в акции Alphabet без каких-либо изменений их параметров. Холдинг Alphabet стал новым игроком на рынке, в состав которого на правах дочек вошли сама Google и все ее предыдущие проекты – в частности Calico, Fiber, Google Ventures, Google Capital, Google X, Life Sciences и Nest. Это, по мнению представителей компании, должно было обеспечить их большую самостоятельность и более четкую структуру руководства.



В ведении Google останется поисковая система, а также карты, рекламный бизнес, сервис Google Play Store, видеохостинг YouTube и разработка операционной системы Android, а также Chrome, Google Apps и социальная сеть Google+.



Пока большинство наиболее прибыльных подразделений всё ещё принадлежат Google. Далеко не все проекты, которыми теперь управляет Alphabet, показывают удовлетворительные результаты.



Генеральным директором Alphabet был назначен уже бывший руководитель Google — Ларри Пейдж. Сооснователь поискового гиганта Сергей Брин занял должность президента холдинга.



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



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



«После реорганизации в воздухе повис вопрос: как это всё будет работать. Многие, и я в том числе, не были уверены, что главы отдельных подразделений смогут поддерживать глобальное видение Ларри Пейджа и Сергея Брина, которое те вырабатывали в течение многих лет», — отмечает Леви.



Результаты работы за год



Стоимость акций за год значительно выросла: капитализация Alphabet в феврале 2016 года достигла $550 миллиардов. Но пока почти вся прибыль компании приходится на проекты Google.



По одной из версий, Alphabet также создавался, чтобы «удержать» менеджеров высшего звена. Однако в начале июня 2016 года свой пост покинул руководитель подразделения Nest Тони Фаделл. В середине августа со своей должности ушёл глава Google Ventures Билл Марис.



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



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



Как полагает издание The New York Times, одной из причин конфликта между Урмсоном и Пейджем стала кандидатура нового главы подразделения.



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



Google Fiber



А пока проект, на который Alphabet возлагал большие надежды, не оправдал их. По плану, провайдер Google Fiber должен был к 2016 году набрать 5 миллионов подписчиков. В 2014 году у Google Fiber было 200 тысяч подписчиков.



В связи с этим гендиректор Alphabet Ларри Пейдж принял решение сократить команду Google Fiber в два раза – до 500 человек.







Провайдер Google Fiber приступил к реализации проекта в 2010 году. Компания потратила сотни миллионов долларов на прокладку волоконно-оптических линий связи в ряде городов, чтобы обеспечить скорость подключения к интернету примерно в 30 раз выше среднего показателя по США. Однако после шести лет развития сети было решено вместо кабелей использовать на «последней миле» беспроводные системы, писали «Ведомости» со ссылкой на The Wall Street Journal.



Это коснется ряда подключаемых сейчас к проекту городов, в том числе Лос-Анджелеса, Далласа и Чикаго. В Сан-Хосе (Калифорния) и Портленде (Орегон) проект приостановлен. В Google Fiber также сообщили, что запуск их сервиса в Пало-Альто и окрестных городах откладывается по меньшей мере на полгода.



Более тысячи городов подали заявку на подключение к Google Fiber, а в ноябре 2012 года этот сервис начал работать в Канзас-Сити. Гендиректор Google Эрик Шмидт заявлял, что Google Fiber – «не просто эксперимент, а реальный бизнес» и что компания решает, куда должна быть направлена его дальнейшая экспансия. За шесть лет сервис успел охватить лишь шесть крупных агломераций.



Финансовые показатели проекта Fiber не разглашаются – они включаются в показатели группы подразделений, не относящихся к поиску и объединенных под названием «other bets». В данную группу помимо Fiber входят такие подразделения, как Nest и Verily. Совокупная выручка этих подразделений за последний квартал составила $185 миллионов, а операционные убытки достигли $859 миллионов. Квартальные капиталовложения по всей этой группе составили $280 миллионов, основная их часть пришлась на Fiber.



Alphabet рассчитывает на то, что Fiber будет окупаться за счёт абонентской платы и, косвенно, роста бизнеса онлайн-рекламы. Провайдер продаёт доступ к интернету за $70 в месяц, ТВ-сервис — ещё за $60. В марте 2016 года Fiber обслуживал около 53 тысяч ТВ-зрителей — столько же, сколько и в конце 2015 года, подсчитали аналитики MoffettNathanson. Аналитики полагают, что подключение одного дома к Fiber обходится Alphabet более чем в $500, при этом не все квартиры в домах становятся абонентами.



Проблема с Google Fiber не является единственной для Alphabet. В прошлом году компания прекратила продажу первой версии носимого интеллектуального устройства Glass, а недавно была расформирована команда, занимавшаяся разработкой роботов.



Alphabet и «клуб четырех запятых»



Тем не менее, у Alphabet есть серьезные амбиции, которые сводятся в конечном итоге к росту рыночной капитализации до $1 триллиона.







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



Alphabet доминирует на рынке интернет-рекламы. Позиции компании и перспективы рынка способствуют росту стоимости акций Alphabet.



По прогнозам аналитиков, прибыль компании будет расти до 2018 года. К этому времени капитализация Alphabet может составить $950 миллиардов. Если верить прогнозам, то компания имеет все шансы стать членом «клуба четырех запятых».







По оценкам аналитиков, объем продаж Amazon к 2018 году превысит $28 триллионов, и лишь 5,5 процентов обеспечит электронная коммерция. Ставка сделана на AWS — облачный бизнес Amazon, у которого есть большой потенциал. Корпоративные расходы на инфраструктуру растут, растет рынок и будет расти рыночная капитализация Amazon. Аналитики считают, что компания может достичь оценки в триллион долларов в ближайшее десятилетие.



Пока самой дорогой из этой тройки является компания Apple. Дела у Apple идут хорошо, но есть проблема, которая мешает Apple достигнуть заветного триллиона долларов.







Корпорация Apple отчиталась о падении выручки второй квартал подряд. Главная причина — падение продаж iPhone, в основном на китайском рынке. Выручка за третий финансовый квартал упала на 14,6% по сравнению с аналогичным периодом 2015 года. Если в третьем квартале прошлого года этот показатель равнялся $49,6 млрд, то в 2016-м он опустился до $42,4.



Пока рост компании замедлился. Крупные обновления iPhone будут выходить реже, автомобиль от Apple в ближайшее время ждать не приходится.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308630/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Что такое большие данные, часть 2

Пятница, 26 Августа 2016 г. 11:12 (ссылка)



В первой части этой серии статей вы узнали о данных и о том, как можно использовать компьютеры чтобы добывать смысловое значение из крупных блоков таких данных. Вы даже видели что-то похожее на большие данные у Amazon.com середины девяностых, когда компания запустила технологию для наблюдения и записи в реальном времени всего, что многотысячная аудитория клиентов одновременно делала на их сайте. Довольно впечатляюще, но назвать это большими данными можно с натяжкой, пухлые данные — больше подойдёт. Организации вроде Агентства национальной безопасности США (NSA) и Центра правительственной связи Великобритании (GCHQ) уже собирали большие данные в то время в рамках шпионских операций, записывая цифровые сообщения, хотя у них и не было простого способа расшифровать их и найти в них смысл. Библиотеки правительственных записей были переполнены наборами бессвязных данных.



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



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



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



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



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



Коммерческий интернет тогда имел две очень схожие задачи: поиск всякой всячины во Всемирной паутине и плата рекламой за возможность что-то найти.



Задача поиска. К 1998 году общее число веб-сайтов достигло 30 миллионов (сегодня их более двух миллиардов). 30 миллионов мест, каждое из которых содержит множество веб-страниц. Pbs.org, например, это сайт, содержащий более 30 000 страниц. Каждая страница содержит сотни или тысячи слов, изображений и информационных блоков. Чтобы что-то найти в вебе, нужно было проиндексировать весь интернет. Вот это уже большие данные!



Для индексации сначала нужно было прочитать весь веб, все 30 миллионов хостов в 1998 году или 2 миллиарда сегодня. Это сделали с помощью так называемых пауков (spiders) или поисковых роботов — компьютерных программ, которые методично ищут в Интернете новые веб-страницы, читают их, а затем копируют и перетаскивают обратно в индекс их содержимое. Все поисковые системы используют поисковых роботов, и они должны работать непрерывно: обновлять индекс, содержать его в актуальном состоянии с появлением новых веб-страниц, их изменением или исчезновением. Большинство поисковых систем поддерживает индекс не только текущего веба, но, как правило, и всех старых версий, так что при поиске более ранних модификаций можно вернуться в прошлое.



Индексация означает запись всех метаданных — данных о данных — слов, изображений, ссылок и других типов данных, таких как видео или аудио, встроенных в страницу. Теперь умножьте это на стопятьсот миллионов. Мы делаем это потому, что индекс занимает примерно один процент объёма сервера, который он представляет — эквивалент 300 тысяч страниц данных из 30 миллионов в 1998 году. Но индексация — это не поиск информации, а только запись метаданных. Поиск полезной информации из индекса еще сложнее.



В первое десятилетие интернета существовали десятки поисковых систем, но четыре были наиболее важными, и каждая имела свой технический подход по получению смыслового значения из их всех этих страниц. Альта-Виста была первым реальным поисковиком. Она появилась в лаборатории Digital Equipment Corporation, в Пало-Альто. Digital Equipment Corporation на самом деле была лабораторией информатики в XEROX PARC, перевезённой почти в полном объеме на расстояние двух миль Бобом Тейлором, который построил их обе и нанял большинство старых сотрудников.



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



Но даже тогда дерьма в интернете было много, а значит Альта-Виста, индексировала всё это дерьмо и не умела отличать хорошее от плохого. Это были всего лишь слова, в конце концов. Естественно, плохие документы часто поднимались наверх, а систему было легко надуть, вставляя скрытые слова чтобы исказить поиск. Альта-Виста не могла отличить реальные слова от скрытых.



В то время, как преимуществом Альта-Висты было использование мощных компьютеров DEC (что было важным моментом, так как DEC были ведущими производителями компьютерной техники), преимуществом Yahoo! было использование людей. Компания нанимала работников для того, чтобы они весь день буквально просматривали веб-страницы, индексировали их вручную (и не очень тщательно), а потом отмечали самые интересные по каждой теме. Если у вас есть тысяча человеко-индексаторов и каждый может индексировать 100 страниц в день, то Yahoo могла индексировать 100 000 страниц в день или около 30 миллионов в год — вся вселенная интернета в 1998. Это работало на ура во Всемирной паутине, пока веб не разросся до межгалактических масштабов и стал неподвластен Yahoo. Ранняя система Yahoo с их человеческими ресурсами не масштабировалась.



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



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



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



Но Google был еще лучше.



Google внёс два усовершенствования в поиск — PageRank и дешёвое железо.



Продвинутый векторный подход Excite помогал выводить нужные искомые результаты, но даже его результаты часто были бесполезны. Ларри Пейдж из Google придумал способ оценки полезности с помощью идеи, основанной на доверии, который приводил к большей точности. Поиск Google в начале использовал лингвистические методы, подобные Альта-Виста, но затем добавил дополнительный фильтр PageRank (названо в честь Ларри Пейджа, заметили?), который обращался к первым результатам и выстраивал их по количеству страниц, с которым они были связаны. Идея заключалась в том, что чем больше авторов страниц заморачивалось дать ссылку на данную страницу, тем более полезной (или, по крайней мере, интересной, пусть даже в плохом смысле) была страница. И они были правы. Другие подходы стали отмирать, а Google быстро вышел в тренд со своим патентом PageRank.



Но была еще одна деталь, которую Google реализовал иначе. Альта-Виста появилась из Digital Equipment и работала на огромном кластере миникомпьютеров VAX от DEC. Excite использовал не уступающее им по мощности железо UNIX от Sun Microsystems. А Google запускался всего лишь с помощью свободного программного обеспечения, с открытым исходным кодом, на компьютерах чуть более мощных, чем персональные. А вообще, они были меньше, чем ПК, потому что у самодельных компьютеров Google не было ни корпусов, ни источников питания (они питались, буквально, от автомобильных аккумуляторов и заряжались от автомобильных зарядных устройств). Первые модификации были прикручены к стенам, а позже ими фаршировали стеллажи, как противнями со свежей выпечкой в промышленных печах.



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



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



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



Результатом всего этого иррационального изобилия было возрождение идей, большинство из которых не реализовалось бы в другие времена. Broadcast.com, например, задумывался для транслирования телевидения через dial-up на огромную аудиторию. Идея не сработала, но Yahoo! все-таки купил его за $5,7 миллиардов в 1999 году, что сделало Марка Кубана миллиардером, которым он и сегодня остаётся.



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



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



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



Доткомы в 2001 развалились из-за того, что у стартапов закончились деньги доверчивых инвесторов, поддерживавших их рекламные компании на Суперкубке. Когда последний доллар последнего дурака был потрачен на последнее офисное кресло от Herman Miller, почти все инвесторы уже продали свои доли и ушли. Тысячи компаний рухнули, некоторые из них за ночь. Amazon, Google и несколько других выжили благодаря тому, что поняли как зарабатывать деньги в интернете.



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



Пришло время для Второго Чудесного Пришествия больших данных, которое полностью объясняет, почему Google сегодня стоит $479 миллиардов, а большинство остальных поисковых компаний давно мертвы.





GFS, Map Reduce и BigTable. Поскольку Пейдж и Брин были первыми, кто понял, что создавать собственные супер-дешевые серверы — это ключ к выживанию компании, Google пришлось построить новую инфраструктуру обработки данных, чтобы заставить тысячи дешевых ПК выглядеть и работать как один суперкомпьютер.



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



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



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



Получается, огромная проблема для Google — это скорость света.



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



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



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



Но Google для достижения своих финансовых целей этого было недостаточно.



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



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



Теперь мы, наконец, говорим в масштабах больших данных.



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



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



Google опубликовал статью о GFS в 2003 году и о MapReduce в 2004. Один из волшебных моментов этого бизнеса: они даже не пытались хранить в тайне свои методы, хотя, вполне вероятно, что остальные когда-нибудь дошли бы до подобных решений сами.



Yahoo!, Facebook и другие быстро воспроизвели открытую версию Map Reduce, которая называется Hadoop (в честь игрушечного слона — слоны ничего не забывают). Это и позволило появиться тому, что мы сегодня называем облачными вычислениями. Это просто платная услуга: распределение вашей задачи между десятками или сотнями арендованных компьютеров, иногда арендованных на несколько секунд, а затем объединение нескольких ответов в одно логически связанное решение.



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



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



Даже Amazon перешел на Hadoop, и сегодня нет практически никаких ограничений для роста их сети.



Amazon, Facebook, Google и NSA не могут функционировать сегодня без MapReduce или Hadoop, которые, кстати, навсегда уничтожили необходимость индекса. Поиск сегодня производится не по индексу, а по сырым данным, которые меняются от минуты к минуте. Точнее, индекс обновляется от минуты к минуте. Не суть важно.



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



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



Большой вопрос без ответа: почему Google поделился своими секретами с конкурентами и сделал публичными свои исследования? Было ли это глупым высокомерием со стороны основателей Google, которые в то время ещё защищали докторские диссертации в Стенфорде? Нет. Google поделился своими секретами, чтобы создать отрасль. Ему было нужно не выглядеть в глазах конкурентов монополией. Но что еще более важно, позволяя тысячам других цветов зацвести, Google способствовал росту интернет-индустрии, чем увеличил свой доход на 30-40 процентов.



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



Вот так, в двух словах, и появились Большие Данные. Google отслеживает каждый ваш щелчок мышью, и миллиард или больше щелчков других людей. Так же и Facebook, и Amazon, когда вы находитесь на их сайте или пользуетесь Amazon Web Services на любом другом сайте. А они охватывают треть обработки данных всего интернета.



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



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



Нет задачи, которая была бы непреодолимо большой.



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


Original source: habrahabr.ru.

https://habrahabr.ru/post/308586/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Осталось 7 дней для покупки Early Bird билетов на MBLTdev 16

Четверг, 25 Августа 2016 г. 15:47 (ссылка)

17 ноября в Москве пройдет третья Международная конференция мобильных разработчиков MBLTdev 16.

Приглашенные эксперты из Великобритании, США, Германии, Румынии, Дании и России поделятся опытом разработки для iOS и Android.







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



Для разработчиков


Хардкорные доклады, практические воркшопы и live coding:


  • особенности выбора дизай-паттернов на Swift 3 для юнит тестирования и TDD,

  • фишки Google Cardboard и Daydream SDK,

  • детальный разбор Firebase,

  • тестирование с помощью Espresso,UiAutomator, Appium и использование Firebase Test Lab и Amazon Device Farm,

  • повышение читаемости кода через грамотную организацию коллбэков,

  • обеспечение консистентность хранимых данных с помощью синхронизации доступа,

  • обработка зависимостей асинхронными методами,

  • особенности Robolectric

  • работа с данными, которые пока не существуют, при создании интерфейсов,

  • альтернативные варианты разработки приложения без использования фрагментов,









Для дизайнеров


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







До 1 сентября вы можете приобрести Early Bird билет по самой низкой цене — 2500 руб. Подробности на официальном сайте.



Следите за новостями на Facebook.

До встречи на MBLTdev 16!



Организаторы конференции: e-Legion и РАЭК.

Партнёры: Google, Aviasales, Avito.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308452/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

О чём молчит Google и почему вам стоит использовать Apache HttpComponents в Android

Четверг, 25 Августа 2016 г. 15:16 (ссылка)

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



Введение



Если вы разрабатываете под Android, то наверняка сталкивались с тем, что открываете вы своё приложение, которое отлично работало несколько лет, и тут внезапно оказывается, что Apache httpComponents стали deprecated, и их не рекомендуется использовать. Сначала давайте разберём, что же произошло, а потом сделаем выводы, что делать.



Что произошло



Слишком далеко закапываться я не стал, однако много интересных вещей можно получить из рассылки org.apache.hc.dev и джиры Apache. Например, факт что



Android включал в себя старый pre-beta релиз библиотеки

Более того, на протяжении всей истории версия библиотеки не менялась, и если включаете у себя apache legacy, то это всё та же pre-beta.

Подтверждение можно прочитать тут.

Подтверждение на английском
Google Android 1.0 was released with a pre-BETA snapshot of Apache HttpClient. To coincide with the first Android release Apache HttpClient 4.0 APIs had to be frozen prematurely, while many of interfaces and internal structures were still not fully worked out. As Apache HttpClient 4.0 was maturing the project was expecting Google to incorporate the latest code improvements into their code tree. Unfortunately it did not happen. Version of Apache HttpClient shipped with Android has effectively become a fork. Eventually Google decided to discontinue further development of their fork while refusing to upgrade to the stock version of Apache HttpClient citing compatibility concerns as a reason for such decision. As a result those Android developers who would like to continue using Apache HttpClient APIs on Android cannot take advantage of newer features, performance improvements and bug fixes.



Google просто забил на проблему

Разработчики из Apache активно работали над библиотекой, но назначенные им менеджеры Google не отвечали месяцами, менялись, а в конце концов сказали, что это не приоритетная задача, пользователям хватает старой версии, да и вообще надо выкинуть эту библиотеку. В подтверждение — немного из упомянутого мной листа рассылки (работа началась в 2008 году, а в 2010 внезапно проявился новый менеджер):

Новый менеджер признаёт, что задаче не уделяют внимания... Ну и ладно.
Jesse Wilson commented on HTTPCLIENT-898:

I'm Bob's successor on the Android team. If you've got questions about our use of the HTTP client code, I'll do my best to answer 'em. I regret that we haven't given this code much attention lately; that said I'm happy that it hasn't really needed it.



Тогда же прозвенел первый тревожный звоночек:

Знаете, спустя два года мы решили, что ничего не надо делать.
I'm quite sorry that Android included an unreleased rev of Apache HTTP client, and I suspect we'll be paying for that mistake for quite a while.



Because of the strict compatibility requirements of our platform, we will be unable to make forwards-incompatible API changes to the HTTP code. Unlike your desktop and serverside users, including the API as a part of the core platform significantly reduces our ability to make API changes.



These days we aren't spending much time on the HTTP client code. Our users seem to be mostly satisfied with the ancient version in the SDK, and have been directing their complaints elsewhere (crypto, locales, XML...).



That said, we do want to figure out a long term strategy for an HTTP client API that will work for both us and the Apache HTTP client team. We're considering a variety of options…



— Discouraging our users from using the built-in Apache HTTP client, preferring the JDK's own URLConnection classes. Whether this is feasible depends mostly on whether the new APIs in Java 6 (which we're working on) will satisfy the use cases that Apache HTTP client has covered for years.



— Replacing the Apache HTTP client API with a 3rd API in a «com.google» or «android.» package. Such an API would likely be based on parts of your own code, but with a more limited API.



— Tidying up the version of Apache HTTP that we're already stuck with. This includes deprecating APIs that shouldn't have ever been exposed as public, and possibly filling in any gaps using newer code from your project.



But none of this work is particularly urgent since we're actively fighting fires in other areas of the core libraries.



Они не могут производит изменения в коде существующей библиотеки из-за несовместимостей? Oh rly? А если вынесут это в свой отдельный пакет на основе кода Apache, то внезапно смогут? Вообще, breaking changes в Android это отдельная тема, выходящая за рамки данной статьи, но чего стоит только ограничение разрешений приложений в шестёрке… При этом ребята из Apache активно старались предоставить максимальную совместимость, и было готовы сделать для этого что угодно. Но увы.

Ребят, у нас мало времени, мы взяли вашу разработку и забили на неё, не беспокойте нас по пустякам.
I explained on several earlier occasions that Android doesn't allow binary incompatibilities of any kind (not my rule). I understand that the HttpClient team is more tolerant of binary incompatibilities. While I'm not saying it would be impossible to make these changes in Android, I am saying that it would take a lot of convincing (and time), it would annoy other people who are time-constrained and who have higher priorities, and it could likely fail anyway.





Финал



А дальше библиотеку просто без всяких адекватных объяснений выпилили с официальной рекомендацией использовать HttpUrlConnection. Вот хотя бы что-то, отдалённо похожее на объяснение ситуации от Джесси Вилсона, который был на то время в Dalvik team (к слову, он же и был вторым менеджером Google по связям с Apache. Запомните это имя).



В его статье вы можете увидеть, что среди преимуществ он видит:




  • Кеширование (которое, если надо, реализуется где угодно)

  • Малый вес библиотеки (да, но сомнительный аргумент)

  • Компрессия, которая сохраняет батарейку и ускоряет загрузку (да, но при желании мы можем использовать Google Compression Proxy и через Apache HttpComponents как обычный прокси)



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

К сожалению, большинство разработчиков слепо верят Google и сразу считают, что библиотека Apache “плохая”, и нужно бежать выкидывать её из своего кода.

Разработчики из Apache прокомментировали это кратко:

Google has used the project when it suited their goals and screwed us afterwards. There is nothing we can do about it.




Эпилог c OkHttp



Если вы разрабатываете под Android, то наверняка видели рекомендации заменять Apache HttpComponents ныне популярной библиотекой OkHttp от Square.

А вы всё ещё помните милого парня Джесси Вилсона из Dalvik team? А вы знаете, что сейчас он работает в Square? И именно он является создателем OkHttp? Более того, вы знате, что OkHttp начинался как форк куска AOSP (Android Open Source Project), который в свою очередь брал свой код из Apache Harmony?

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



И что же?



Давайте разберёмся, какие есть варианты того, как жить дальше.



1. Использовать HttpUrlConnection

Рекомендованный подход Google. Действительно имеет смысл, если у вас простое приложение. Но не дай бог вам попробовать сделать что-то не совсем тривиальное. В моей практике таких случая было два — когда я пытался использовать SSL прокси и когда хотел обратиться к некоему айпишнику со своим именем хоста. Обе задачи при помощи HttpUrlConnection реализовать невозможно.



2. Использовать другие продвинутые альтернативы

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



3. Использовать legacy библиотеку

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



4. Использовать последние версии Apache HttpComponents

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

Вопрос — как её подключать?

Если просто брать и подставлять в gradle, то выйдет конфликт классов с этой самой древней версией.

В релизе 4.3 разработчики apache предлагали использовать специальные постфиксы “HC4” в классах для избегания конфликтов, но работало это как-то очень плохо.

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



Что дальше?



Заметок по использованию пятой версии библиотеки на Android пока что нету — возможно, это объясняется тем, что она пока ещё в альфа версии. Или просто в Apache решили больше не иметь дела с Google и Android. Впрочем, даже если так — всегда найдутся энтузиасты, которые смогут корректно перепаковать последнюю версию. А работать с ней — сплошное удовольствие.



Ссылки




  1. Репозиторий с перепакованной версией httpComponents;

  2. Заметки о релизе 4.5, где рекомендуют использовать этот репозиторий;

  3. Интересные фрагменты переписки ребят из Apache и Google;

  4. Любопытные задачи с комментариями в джире Apache — раз и два.



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

https://habrahabr.ru/post/308522/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

История языков программирования: от Objective C к Swift

Среда, 24 Августа 2016 г. 18:07 (ссылка)





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



Что заставило множество разработчиков перейти на Objective C? Что сейчас заставляет отказаться от него и выбрать Swift?



Objective C является расширением языка Си, в который были добавлены новые возможности для объектно-ориентированного подхода программирования. Язык использует объектную модель Smalltalk. Полностью совместим с языком программирования Си. Компания Apple долгое время использовала Objective C как основной язык программирования для разработки своих продуктов.



Создателями Objective C являются Брэд Кокс и Том Лав. Они начали работать над ним в начале1980-х годов, когда еще были сотрудниками телекоммуникационной компании ITT Corporation. Примерно в то же время Кокс и Лав познакомились с языком программирования Smalltalk. Кокса тогда занимали проблемы повторного использования программного кода.

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






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



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



Набор методов представляет собой интерфейс для взаимодействия с инвариантами.


OOPC



Брэд Кокос быстро понял, что Smalltalk не подойдет для решения задач в ITT Corporation: совместимость с языком С для них была критична. Однако Кокс решил модифицировать препроцессор для С в сторону Smalltalk.

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


То, что получилось, Кокс назвал «OOPC» – Object-Oriented Pre-Compiler. В 1982 году Лав устроился в Schlumberger Research и получил возможность приобрести коммерческую версию Smalltalk-80. Это помогло им в дальнейшей работе над Objective C. В итоге в Objective C была реализована возможность создавать объекты и работать с ними.







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



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



Привязка сообщения к соответствующей функции происходит на этапе выполнения.



Язык Objective C поддерживает работу с метаинформацией — так, на этапе выполнения можно узнать класс объекта, список его методов (с типами передаваемых аргументов) и instance-переменных, проверить, является ли класс потомком заданного и поддерживает ли он заданный протокол и так далее.



NeXT



В 1986 году Кокс опубликовал книгу Object-Oriented Programming, An Evolutionary Approach, в которой разместил описание своего языка программирования, разобрал проблему повторного использования кода и указал преимущества Objective C при ее решении. Лав и Кокс также создали компанию Productivity Products International (PPI), который должен был помочь монетизировать компилятор Objective C с библиотеками классов. Далее фонд был переименован в StepStone.



В 1988 году компания NeXT Software лицензировала язык Objective C, усовершенствовала его библиотеки и добавила новые – AppKit и Foundation Kit. На их основе позднее была создана среда разработки NEXTSTEP.







В 1992 к усовершенствованию языка и компилятора подключились разработчики проекта GNU в рамках проекта OpenStep. С тех пор GCC поддерживает Objective C.



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



20 декабря 1996 года компания Apple купила NeXT Software, а среда разработки NEXTSTEP стала основной средой разработки для будущей основной версии операционной системы Apple — OS X.



После покупки NeXT, Apple взяла их SDK (компилятор, библиотеки, IDE) за основу для своих дальнейших разработок. IDE для разработки кода получила название Xcode, а для GUI – Interface Builder. Фреймворк Cocoa для GUI разработок (и не только) на сегодня является наиболее значимой средой разработки программ на Objective C.



В 2007 году компания Apple презентовала обновленную версию языка и назвала его Objective C 2.0, данная версия языка является актуальной в настоящее время. Используется в разработке Apple OS X, iOS.



Swift



В 2014 году компания Apple представила новый язык программирования – Swift. Он стал самым быстрорастущим языком программирования в истории.



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







Создатель языка Swift – Крис Латтнер. Он пришел в Apple в 2005 году. Там он занимался разработкой LLVM. Apple использовала LLVM для того, чтобы изменить способ использования Objective C при создании приложений.

LLVM (Low Level Virtual Machine) — это универсальная система анализа, трансформации и оптимизации программ или, как её называют разработчики, «compiler infrastucture».
Крис Латтнер курирует все инструменты разработчиков Apple: все, с помощью чего создаются программы для телефонов, планшетов и компьютеров Apple, как сторонними разработчиками, так и инженерами компании. Будучи аспирантом университета штата Иллинойс, он создал своего рода средства для разработчика под названием LLVM, которые сегодня лежат в основе Xcode.

Латтнер также использовал LLVM в качестве основы для Swift. Эти два продукта специально были созданы для работы в тандеме.



Над Swift он начал работать летом 2010 года. Латтнер держал это в секрете полтора года. Он создавал Swift в свободное от основной работы время.



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



По мнению Apple, язык Swift имеет все шансы изменить ИТ-индустрию.



2 июня 2014 года компания выпустила тестовую версию для сторонних разработчиков и программистов. Apple позиционирует это язык как более быстрый и эффективный способ создания программ для iPhone, iPad и Mac.







Расширение аудитории



Языку программирования необходимо несколько лет, чтобы стать популярным хотя бы в узких кругах энтузиастов. Достаточно показательна ситуация с языком Go, который компания Google представила еще в 2009 году. Над Go работали лучшие умы (Кен Томпсон и Роб Пайк), однако и по сей день прикладываются немалые усилия для его популяризации. Однако Apple делает все, чтобы Swift стал исключением и последовал примеру языков Java и C# в 1990-х и начале 2000-х соответственно.



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



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



«Не было никакого реального стимула использовать Google Go» — говорит Пол Янсен, который отслеживал прогресс различных языков программирования в течение около пятнадцати лет. «Swift отличается наличием стимула».



В рейтинге TIOBE Swift занимает 14-ю позицию. За год он поднялся на 3 позиции. Язык Go переместился с 95 позиции на 20, что очень впечатляет. А Objective C опустился с 6 места на 15. Таким образом, можно сказать, что Swift технически обошел своего предшественника.







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



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



Swift быстр (скорость реализации некоторых алгоритмов в 3,9 раза больше, чем на Python) и лаконичен (разработчики избавились от многословности Objective C). Ещё одно важное нововведение — это возможность писать код и видеть результаты в режиме реального времени.



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



P.S. Apple не первая компания, которая выпустила новый язык программирования в недавнем прошлом. Это уже сделали Facebook, Google и Mozilla. К чему это приведет — покажет время.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308450/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Дождется ли ФАС своего «звездного часа» в тяжбе с Google

Понедельник, 22 Августа 2016 г. 18:06 (ссылка)





Компания Google обязана выплатить штраф за нарушение антимонопольного законодательства в размере 438 миллионов рублей. Такое решение 17 августа вынес Девятый арбитражный апелляционный суд, который отказал ей в удовлетворении жалобы на решение Федеральной антимонопольной службы (ФАС) по делу об ограничении конкуренции на рынке мобильного софта. Сумма штрафа не пугает Google, но теперь компания должна пересмотреть условия контрактов, запрещающих производителям смартфонов устанавливать приложения конкурентов.



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



После того, как суд вынес решение, Google должна в течение 8 дней выполнить требования ФАС. Иначе компании грозит еще и административный штраф. Как сообщала представитель ФАС Анна Орлова, размер штрафа составит 300-500 тысяч рублей.



В сентябре 2015 года ФАС признала Google нарушителем закона о конкуренции. Суд согласился с тем, что компания злоупотребляет доминирующим положением на российском рынке предустановленных приложений для Android OS. Еще тогда нарушитель должен был скорректировать свой бизнес в России. Но американская компания подала апелляцию.

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


14 марта 2016 года законность решения ФАС подтвердил Арбитражный суд Москвы. После этого Google вновь подала апелляцию.



11 августа ФАС сообщила, что штраф для Google составит 438 миллионов рублей. При этом сообщалось, что ведомство продолжает переговоры с компанией о мировом соглашении.

В начале июня представитель «Яндекса» отмечал в разговоре с РБК, что главной целью для компании являются «восстановление конкурентной ситуации на рынке и устранение последствий тех нарушений, которые были установлены ФАС и подтверждены судом». Если Google добровольно исполнит ключевые требования основного решения ФАС в результате заключения мирового соглашения, компанию это также устроит, пояснял представитель «Яндекса».


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





Фото: Kimihiro Hoshino/AFP



Восстановить справедливость



Текущее судебное решение предусматривает, что компания Google обязана исполнить предписание ФАС и разослать всем пользователям телефонов на базе Android сообщение о том, что они могут перейти на приложения конкурентов. До этого момента Google не сталкивалась с подобными предписаниями нигде в мире.



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



Намерен ли Google рассылать пользователям Android соответствующее сообщение, пока не известно. Если это случится, изменения коснутся значительной части российских пользователей.







Какие шансы выйти сухой из воды в этой «патовой» ситуации есть у Google?



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



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



Последствия



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



Решение о штрафе мало что изменит и для «Яндекса», и для российского рынка в целом, считают эксперты. «Штраф не будет определяющим фактором для Google в вопросе, исполнять решение ФАС или нет, — считает аналитик Райффайзенбанка Сергей Либин. — Это 2% от выручки российского подразделения, для компании это копейки. Скорее аргументом будет окончательное решение суда по иску «Яндекса».



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



Некоторые производители смартфонов все же считают, что решение ФАС снизит давление Google на участников рынка. «Когда «Яндекс» подал иск к Google и ФАС начала разбирательство, Google перестал давить на производителей с требованием подписать договор MADA. Пару месяцев назад давление возобновилось, но сейчас, видимо, опять утихнет», — рассказал РБК источник в руководстве одной из компаний— производителей смартфонов.

В июле 2016 года генеральный директор «Яндекса» в России Александр Шульгин, объявляя результаты компании по итогам второго квартала, рассказывал, что компании удалось заключить новые договоры о дистрибуции своих приложений с производителями мобильных устройств после решения ФАС. В результате этих соглашений доля российской компании в поиске на мобильных устройствах с операционной системой Android начала расти в конце июня, отмечал Шульгин.


Мировая практика



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





данные StatCounter с января 2010 по август 2016, Desktop
Original source: habrahabr.ru.

https://habrahabr.ru/post/308274/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Отчет о посещении конференции YouTube в Киеве или Почему видеоконтент стал частью жизни

Четверг, 18 Августа 2016 г. 10:42 (ссылка)

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







Общие впечатления



Первое. Ютуб, и Гугл тоже, очень даже неплохо используют все современные достижения и исследования в области социальной философии, социальной психологии и социологии, и даже знают такие слова как «нарратив». Ведь для того, чтобы как-то управляться с таким огромным социумом (1 млрд в месяц на Ютубе) без социальной философии не обойтись (философам привет). Так что «Большой Гугл, следит за тобой, бро!»





Слайд с экрана с тем, что больше всего смотрят на Ютубе — воспитание, увы — всего 8%



Как сказал один выступавший мужик, главный по Ютубу в Европе: весь ютуб — это про то, что обычное — может быть (показано) необычным — и да, я согласен, Ютуб — он по своей философии как раз про это: extraordinary from ordinary. Сказал, что первое видео, загруженное на Ютуб было про слонов, которое для теста загрузил инженер Гугл (хотя я слышу уже вторую версию — какое видео на Ютубе было первым). А первым видео загруженным в Украине было тоже про слона в Киевском зоопарке — “что-то есть в этих слонах”.







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



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







Гугл уже 10 лет имеет офис в Украине, в Киеве. Его возглавляет Дмитрий Шоломко, вышел, сказал что на Украину у Гугла, и конкретно, в плане Ютуба — очень большие планы. Поэтому они организовали такое мероприятие. Для чего? Чтобы развить тех авторов из Украины, которые приносят Ютубу контент много бабла (что и понятно) и чтобы те, которые не очень большие, поняли как развивать свои каналы, как создавать, правильно продвигать и продавать свой контент.





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



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



Каждый день на Ютуб грузится где-то 400 часов видео. Чтобы вы понимали это в эквиваленте жизни — где-то 46 000 лет жизни.





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



80% — Ютуба — не из США, а из других стран, в том числе из развивающихся в сегменте Ютуба стран, Украина сюда входит — Ютуб в Украине растет на 70% в год. Т.е. в Украине Ютуб растет быстрее чем он растет в глобальном масштабе — 83% пользователей интернета в Украине — заходят на Ютуб.







В Ютубе 108 000 креаторов видеоконтента (как их называли представители Гугла).



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



80% авторов ютуба — это нищеброды авторы с числом подписчиков от 1000 до 10000. Если у тебя 100 000 подписчиков — то за тобой закрепляется постоянный менеджер, который будет тебя вести, говорить что и как делать, на что обратить внимание и т.д. На скрине можно увидеть, что из Украины есть автор EeOneGuy, у которого больше 8 млн подписчиков – Боже! Как же это можно было?!







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



Была интересная лекция о форматах



Формат 360

Да, они его запустили, да, обещали допилить.

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



Где сами ютуберы рекомендуют это использовать:

— музыка (клипы)

— экстремальное видео (когда кто-то куда-то летит, (не ты же:), ты можешь полюбоваться видами саваны)



360 Лайв — скоро запустят возможность делать прямые трансляции в режиме 360.



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



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



Всякие траблы с авторскими правами







Был доклад, о таком важном для Ютуба вопросе — как авторское право, и как с ним работать.



Что нового:

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

— убрали концепцию плохой репутации канала

— страйк теперь будет не полгода, а 90 дней (!).

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

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







Будет много изменений по инфокартам, всякие подсказки, аннотации видосов и пр.



NB: не знал что подсказки — видны на мобильном, а остальные инфокарты не видны, вроде так говорили.







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

— название видоса

— описание

— субтитры (можно разрешить зрителям добавлять субтитры).

— аннотации

— подсказки

— теги (их переводить даже не обязательно — так как робот их сам переводит).



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



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







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







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







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



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



Аналитика Ютуба



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



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



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



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



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



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



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



— очень важен процент от просмотров (Процент просмотра видео (квартиль видео)

Процент просмотра видео: 25% – количество просмотров четвертой части видеоролика.

Процент просмотра видео: 50% – количество просмотров половины видеоролика.

Процент просмотра видео: 75% – количество просмотров трех четвертей видеоролика.

Процент просмотра видео: 100% – количество просмотров видеоролика до конца.)


авторам нужно стремится, чтобы было хотябы не ниже 50%



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



— от удержания аудитории зависит рейтинг видоса



— если аудитория уходит — сравниваем такие же ролики, и делаем выводы что у них лучше?



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



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



— статистика скажет когда выпускать видосы, но ориентирование на утро-вечер — условная штука, у нас утро, а где-то в США — вечер, поэтому не всегда это панацея



— нужно стремится к тому, чтобы статистика хотя бы на треть просмотров — была именно от подписчиков



— удержание аудитории нужно смотреть не по каналу, а по каждому видео отдельно, так как канал выдает усредненную цифру. Автор должен четко понимать: почему в этом ролике аудитория не свалила, а в этом свалила.



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



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



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



— нужно понимать разницу между представление текста и видео. Например, видосы про рецепты лучше называть и как “рецепт чего-то там” — это как текст, и “как приготовить что-то там”. Так как если человек зайдет в Гугл, он забьет “рецепт”, а если зайдет в Ютуб, забьет “как приготовить”, и вот если в вашем видео все это есть, то уже в Гугле как бы он не забил в поиск запрос — ваше видео с рецептом выпадет уже в поиске.



Общие размышления



Ютуб давно уже стал таким масс-медиа-СМИ, который совмещает в себе телевизор, СМИ, и народную газету. Вот кто бы мог представить что соединение: видеорегистратор+ютуб — значительно понизило градус наглости дорожных инспекторов?



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



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







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




Спонсор репортажа — компания SIM-Networks, покупка и продажа серверов, VPS, хостинг и облака в европейских дата-центрах (спасибо, что на конференцию отпустили).
Original source: habrahabr.ru.

https://habrahabr.ru/post/307866/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<google - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda