Совершил ли я ошибку, продав Del.icio.us Yahoo?



Совершил ли я ошибку, продав Yahoo свою избранницу из социальных сетей?
Новаторский сайт социальных закладок Джошуа Шахтера Del.icio.us, основанный в 2003 году, популяризировал идею «теги…nymag.com»



Новаторский сайт социальных закладок Джошуа Шахтера Del.icio.us, основанный в 2003 году, популяризировал идею тегов — организации закладок путем добавления всего одного или двух слов. На пике своего развития Del.icio.us был тостом многообещающих социальных сайтов, известных как Web 2.0, имел миллионы пользователей и служил непосредственным источником вдохновения для таких сайтов, как Reddit и Pinterest. Шахтер поговорил с Intelligencer о своем решении продать Del.icio.us компании Yahoo в 2005 году и о том, каково было наблюдать за тем, как компания плохо управляется и продается ряду покупателей, прежде чем окончательно закрыться в 2017 году.

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

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

Любое решение было бесконечным обсуждением. Помню, однажды нам нужно было выступить перед старшим вице-президентом. У нас была подготовлена ​​колода из 105 слайдов, и мы не смогли пройти дальше второго слайда, потому что они проболтались об одном гребаном слайде. Это была ужасная обстановка.

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

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

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

Есть поговорка: "Вы можете быть богатым или королем". Вы можете продать свою компанию как можно дороже, или вы можете взять на себя ответственность. Хотя, возможно, ни то, ни другое не совсем возможно. Когда я основал свою вторую компанию, нас было семь человек, и мы все еще спорили о том, что и как делать. Я был генеральным директором и до сих пор не добился своего.

Когда продажи — это не просто продажи: советы основателям на ранних рынках — Андреессен Горовиц



Когда продажи — это не просто продажи: советы для основателей на ранних рынках
Возможно, самая большая проблема, с которой сталкиваются основатели на ранних рынках, — это переход от продукта к продажам… em>a16z.com



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

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

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

Другими словами: не думайте, что проблема в отсутствии таланта продавца.

  • Это разбивает мечту о том, что все должны быть техничными:

Я слышал, как основатели часто сетуют на то, что их торговые представители «недостаточно техничны». Но торговые представители не должны быть техническими; Вместо этого торговые представители на раннем рынке должны иметь возможность делать следующее: (1) подбирать клиентов и заключать сделки (понимать, есть ли реальная возможность или нет); (2) поиск бюджета (помните, что на ранних рынках может не быть строки бюджета); (3) составление карты целевой организации (определение ключевых лиц, принимающих решения, и заинтересованных сторон); (4) вызов подкрепления (основатели стартапа, менеджеры по продукту и т. д.) в нужное время; (5) навигация по закупкам и ценообразованию.

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

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

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

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

Обновление структурированного параллелизма — 250 ударов в минуту



Обновление структурированного параллелизма — 250 ударов в минуту
Наконец, следует сказать, что все известные мне реализации используют сопрограммы и игнорируют потоки ОС. Что…250bpm.com



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

Самое главное, что Натаниэль Дж. Смит опубликовал свою статью «Заметки о структурированном параллелизме, или: оператор Go считается вредным». (Если вы предпочитаете смотреть видео, перейдите сюда.) Это лучше, детальнее и красноречивее всего, что я когда-либо писал на эту тему. Если вы хотите узнать что-то о структурированном параллелизме, прочтите статью Натаниэля.

После libdill на основе C у нас также есть Venice, которая привнесла структурированный параллелизм в Swift, и Trio, которая привнесла его в Python.

Несколько недель назад была выпущена новая версия библиотеки сопрограмм Kotlin, поддерживающая структурированный параллелизм. Вот сопровождающая запись в блоге Романа Елизарова.

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

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

Все это отличная работа, и я надеюсь, что мы увидим больше в будущем!

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

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

Сначала: Заметки о структурированном параллелизме, или: оператор Go считается вредным — блог njs. Ничего себе, это когда-нибудь отличное пошаговое руководство по приземлению на API и абстракции вокруг очень сложной темы. Эта история GOTO и go замечательна и заслуживает прочтения. Любой, кто потратил много времени на работу с параллельными системами, интуитивно понимает эти концепции. Они могут чувствовать путаницу и трудности с отслеживанием этих систем. Я думаю, что многие из них являются попытками сделать вещи слишком простыми. Это возвращает нас к великому Ричу Хики разговор о легком и простом. Многие из этих абстракций, пытающихся быть простыми, на самом деле делают вещи менее простыми и, таким образом, на практике становятся более сложными. Не обязательно сложнее кодировать, но сложнее понять и отследить при использовании в реальной системе.

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

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

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

Это то, с чем мы столкнулись при создании нашей библиотеки Python для системы очередей задач Google App Engine (GAE) под названием Furious. Хотя нам все еще приходилось использовать такие вещи, как обратные вызовы, из-за некоторых нюансов GAE, мы попытались сделать очевидным то, что происходит. Существующая на тот момент библиотека, предоставленная Google (называемая Deferred), скрывала слишком много. Это потребовало действия, которое включало сериализацию ввода (через Python pickle всех ужасных вещей), выполнение безопасных HTTP-вызовов POST и фоновый ввод-вывод, что сделало его похожим на стандартный вызов функции Python. Вы можете себе представить, почему я большой поклонник таких языков, как Haskell и Purescript, которые требуют аннотации функций с побочными эффектами и особенно эффектами, основанными на вводе-выводе. Эта абстракция вызвала так много проблем еще до того, как мы попытались создать сложные рабочие процессы. Как только мы начали моделировать эти сложные рабочие процессы и, что еще хуже, пытались отлаживать рабочие процессы, созданные другими, стало очевидно, что эта библиотека имеет плохо абстрагированный API. Нам нужно было что-то, что делало бы более очевидным то, что делается. Мы были далеки от совершенства с Furious. Хотелось бы, чтобы мы лучше справились с координацией и обратными вызовами. Хотя кое-что из этого было пределом GAE и Python.

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

Интересно, как многие старые API могут ошибаться. Если вы пойдете по пути, который мы сделали в этом сообщении в блоге, и начнете с размышлений о применении тайм-аута к сложной операции, состоящей из нескольких блокирующих вызовов, то станет очевидным, что если первый вызов израсходует весь бюджет тайм-аута, то любые последующие вызовы должен немедленно выйти из строя. Тайм-ауты, естественно, запускаются уровнем. И затем, когда мы обобщаем от тайм-аутов до произвольных отмен, понимание сохраняется. Но если вы думаете только о тайм-аутах для примитивных операций, то это никогда не возникает; или если вы начнете с универсального API отмены, а затем используете его для реализации тайм-аутов (как, например, Twisted и asyncio do), то преимущества отмены, инициируемой уровнем, легко упустить.

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

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

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

И даже если у нас есть хорошая идея, иногда среда не позволяет:

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

Ура!

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

Бу!

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

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

($$$) Создатели имиджа саудовцев: армия троллей и инсайдер из Твиттера — The New York Times



Саудовские имиджмейкеры: армия троллей и инсайдер Твиттера
Каждое утро Джамал Хашогги проверял свой телефон, чтобы узнать, какой новый ад был развязан, пока он был…www.nytimes.com



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

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

"Хуже всего для него было утро, потому что он просыпался под непрерывную перестрелку в Интернете", – говорит Мэгги Митчелл Салем, подруга Хашогги более 15 лет.

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

  • Я публикую это для этого раздела:

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

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

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

Застигнутые врасплох действиями правительства, руководители Twitter отправили г-на Альзабару в административный отпуск, допросили его и провели судебно-медицинскую экспертизу, чтобы определить, к какой информации он мог получить доступ. Им не удалось найти доказательств того, что он передал данные Twitter правительству Саудовской Аравии, но тем не менее в декабре 2015 года его уволили.

  • Ух… вау.

Быстрые обращения

Новости / Случайные

Системы/инфраструктура/облако

Разработка продукта/программирование

Математика/естественные науки/поведение/экономика

Блокчейн/Криптовалюта

ИИ/машинное обучение/обработка данных/статистика

Если вам нужна помощь с вашей архитектурой или организацией разработки, не стесняйтесь обращаться к нам: realkinetic.com @real_kinetic

Вы можете подписаться на меня напрямую @lyddonb

Подпишитесь на рассылку Real Kinetic