Как стать автором
Обновить

Комментарии 53

Статья написана для форсирования собственного авторитета. Прием сравнивания себя с идолами часто работает. Но автор этой статьи перебрал помоему)
Спасибо за перевод
Пожалуйста

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

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

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

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

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

Например по запросу «создание сайтов» Гугл пишет:
Результатов: примерно 58 800 000 (0,24 сек.)

Но при попытке перейти на 101 страницу выдачи (вручную в адресной строке выставить параметрe start значение 1010) появляется надпись:
Извините, но Google не выдает более 1000 результатов, а вы запросили результаты с номера 1010.

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

Хабрахабр честно пишет — найдено 1000 топиков, 1000 комментариев, хотя материалов явно больше. habrahabr.ru/search/?q=java
это потому что сфинкс, которого они используют для поиска, по-умолчанию имеет ограничение в 1000 результатов максимум:
sphinxsearch.com/docs/2.0.4/api-func-setlimits.html

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

Потому что это абсолютно никого не интересует.
НЛО прилетело и опубликовало эту надпись здесь
Сдается мне что показывать 1000 когда найдено 100500 ничем не лучше чем показывать 100500 когда найдено 1000 :)
у многих серч енжинов есть такие ограничения на кол-во. На это есть свои, вполне понятные причины.
К слову о Яндексе: у них есть другая «убийственная фича», которую Гуглу пока не удаётся достичь (да и пытается ли?) — это учёт морфологии русского языка. Они нашли своё (:
Не порите чушь, морфология русского языка учитывается гуглом много лет. Посмотрите, например, какие слова выделены при запросе "индия код".
К чему столько злобы?

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

p.s. И дело то в том, что у Яндекса свои фичи — это главная мысль.
На прибыли Google это никак не сказывается (то, что они пишут про миллионы, а показывают, на самом деле, всего 1000). Понты не важны, важны деньги.
Правильно пишет. Все, что может быть скопировано, будет скопировано.
Интеллектуальной собственности не бывает — как говорили в зАиБи и также говорит Ричард. И рассчитывать на интеллектуальную собственность в стартапе, имхо, не особо стоит.
Однако — внутренний мир СУБД Oracle и MS SQL храниться за семью печатями и договорами о неразглашении. И это вообщем помогает им сохранять нехилое преимущество перед глубокоуважаемыми и любимыми postgers и mysql.
Как говорится — jedem das siene…
Перешли с Оракла и MsSql на Постгре.

БД 7 миллиардов записей, highload (10,000 запросов в секунду), в кластере десятки серверов.

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

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

При этом Постгре реально не хуже для кучи задач.
Постгре не хуже для кучи задач, mysql хорош — я их люблю и использую, НО:
1. Разрабов mysql ~150, разрабов оракла — думаю в 50-100 раз больше, разрабы мускула признают, что опыт в оракл несравнимо больше.
К тому же, имхо, качество реально сложного софта достигается потом и кровью и большим количеством времени…
2. Enterprise сектор, база ~400 таблиц, по размеру небольшая 3-4Гб, вариант на посгре на в среднем(на различных операциях) на 30% медленнее, на бесплатной версии DB2 где-то те же результаты.
3. Mysql, innodb движок, таблица 80млн записей — а попробуйте удалить из них 55млн — на это может уйти неделя! А в MS SQL — в пределах минут…

А по поводу Бренда и лицензий — как повергала меня в ужас политика лицензирования MS, Oracle и (особенно!) Cisco так и будет повергать…
Еще раз — каждому свое — Photoshop несравнимо лучше GIMP для полиграфии, RHEL несравнимо лучше всех кластерных изысков виндов для HPC, Oracle лучшая СУБД в корпоративном секторе, а SSH лучшее впн решение для тех кто умеет им пользоваться…
Постгре у нас тоже корпоративный сектор :)

Быстрее или нет оракла – сложно сказать, зависит от серверов, запросов, структуры бд, рук разработчиков

Я бы сказал, оракл равен пг. Это охуенные бд
Одна лучше в одном, другая в другом, в целом кул

Мускул требует тонких рук.я в нем не спец, багов в триггерах таблиц и хранимках хватило. Имхо без допилки это плюшевая бд

Мс скл не знаю, чтобы судить. Судя по ее мизеру, бд так себе, но это имхо
БД 7 миллиардов записей, highload (10,000 запросов в секунду), в кластере десятки серверов.
на посгре внушает уважение и интерес. А 10К запросов — это именно запросов к базе или кликов и проект интернет или корпоративный?
К бд
Это группа проектов с одной бд

А представьте, бд обновляется раз в час из 500 источников, даннве приводятся в один формат…
Кул:)
Я думал, намного будет… Намного хуже будет это все. И очень хороший перевод, просто очень хороший перевод! Я думал, намного хуже это все будет. Сколько раз сюда ходииил — было намного хуже, но на этот раз как-то удалось.

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

Я не профессиональный переводчик, так что прошу извинить, если что.
Да всё круто, правда, мне от души понравилось :)
Из перевода понравилось:
Эппл жертвует всем во имя дизайна.
«Эппл, эппл, эппл, аааа Apple!»
Честно, завис на минуту читая эту строчку.
Ехал Эппл через Apple
Видит Эппл, эппл, Apple
Сунул Эппл эппл в Apple
Эппл, эппл, аааа Apple!
Эндрю! Ну тогда как то так Ж)

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

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

При этом посещает кучу конференций, помогает новичкам, и делает другие компании.

Self-made man. Он имеет основания быть пафосным.
Поэтому лучший ответ на пафос — превзойти его, стать самому крутым бизнесменом/управленцем/да хоть просто спецом-исполнителем, и писать такие же статьи в своей теме, чтобы уже про вас говорили одни — ух, ну и пафос, а другие отвечали, что есть основания.
Из психологов в тимлиды разработчиков, ага. Уперёд!
Яркая фантазия у автора.
Автор явно употребляет вещества…
И таки зеркало по утрам чмокает, да…
В чём содержание статьи помимо того, что «правильные люди — главное»? *где правильные = настойчивые взаимодополняющие друг друга специалисты в определенной тематике, умело набирающие авторитет, а также знающие свой рынок
окей, давайте тезисами.
1. выбор сферы. нишевый фокус. вы не обязательно должны иметь опыт в сфере или человека с опытом. но вы выбираете сферу и фокусируетесь на ней. в отличие от 99% говностартапов-конкурентов, рассчитанных «на всех»

2. выбор команды. не работаете с п@здоболами, работаете с профи. целенаправленно собираете команду, а не из друзей по пиву. см. пункт про 99% процентов конкурентов

3. клиенты и продажи как ОСНОВА. производство — следствие. вы не делаете того, что делает 99%. простите за злоупотребление, как говорит автор :) вы думаете по-западному, а не по советскому образцу. в СССР как — барыга спекулянт это козел, а производитель — все. сейчас — ритейл и сети это говно, а производитель — все.

на деле — наоборот. продажи без производства — легко. делать деньги на (пере)продажах можно — Эппл прекрасно это делает, Микрософт и т.д. Айфоны ФИЗИЧЕСКИ делают в Китае, напоминаю.

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

поэтому начните продавать завтра. вы увидите продукт глазами клиентов и сразу получите обратную связь. прочитайте мою статью про это.
у нас пытаются сделать СРАЗУ КРУТО. запомните — вы ВСЕГДА будете ПЕРЕДЕЛЫВАТЬ. что бы вам не пели программисты. то есть вы будете 100% переделывать. поэтому лучший способ начать ПЕРЕДЕЛЫВАТЬ правильно — сделать просто и быстро. говнокодом. и уже через месяц (а не год) продать.

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

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

5. Главный абзац статьи

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

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

Большая часть стартаперов думает, как бы получить бабла. Потом — на какие конференции сходить, и какие п@здатые айпады купить. Как ДИЗАЙН ДОЛЖЕН БЫТЬ ИДЕАЛЕН. ПРОДУКТ ДОЛЖЕН БЫТЬ ИДЕАЛЕН. ДАВАЙТЕ ДЕЛАТЬ ЕГО ДВА ГОДА. И КОНКУРЕНТОВ У НАС НЕТ И НЕ МОЖЕТ БЫТЬ.

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

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

К примеру, у меня есть проект, который мы с другом сделали за 2 часа, а у него 2000 людей в день ходит.
Просто на коленке. Нет дизайна (не было первые полгода).
Проект for fun, анонимная благотворительность.

Косвенные конкуренты раскручивали свой форум 3 года с кучей денег и т.д. А потом просто слизали БД у нас. Ток не учли инсайдерской инфы.
При этом почему я против проектирования сразу крутого.
Я напишу скоро статью.

Это не я придумал. Роберт Мартин, Uncle Bob, который подписал Agile Manifest, круто пропиарил TDD, сформулировал SOLID принципы (IoC это оттуда, если что), об этом писал еще в 1994 (!!!) году.

Поэтому мы делаем так
1. итерация один. до стадии самодостаточности проекта, когда его можно бросить на полгода и он проработает.
— первая версия. говнокод. заглушки.
— вы выясняете ТРЕБОВАНИЯ, показывая рабочие прототипы. и ЖИВЫЕ данные. любые таблицы, любые верстки, дизайны и тд, любая логика только на ЖИВЫХ данных проверяется. и никак иначе. факт жизни.
к примеру, самолеты только упав, говорят нам, где ошиблись теоретики теории турбулентностей и т.д
на компах у инженеров самолеты не падают.
и проекты на макетах не падают, и на компах программеров. ток когда я использую (а не ТЕСТИРУЮ мля) проект, он падает и получается фидбэк.
— как программист вы лучше уясняете себе сущности. выделяете главное.
— в итоге эволюций за 5-15 требования устаканиваются. проект работает процентов на 20%, реализован главный функционал.
замораживаем его, если надо.
и внедряем окончательно.

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

3. итерация три — визуальный тюнинг
— отрисовываем все красиво
— яваскрипты, силверлайты, флэши, Qt-навороты, у кого что.
— тюнингуем всякие штуки.

4. итерация четыре — бесконечности
— выделяем новые разделы в проекте, и делаем их по тем же самым итерациям.
— так как проект ветвится, как дерево, развивать его можно бесконечно. любой проект. секрет — БЫТЬ В СФЕРЕ ПРОЕКТА, смотреть глазами пользователя
— если исходное дерево проект засралось, рефакторим структуру. рефакторить нужно регулярно, закон суров: любой порядок стремиться к хаосу, если его не поддерживать.
Мартин сказал — нельзя спроектировать сверху вниз, только снизу вверх.
Писать качественный кодж и говнокод — это почти одинкаковые затраты. Вы наверно путаете overengineering с качественным преоктирование. Качественное проектирование позволяет делать большее меньшим количеством строк. Особенно это будет заметно, если захотите значителньо изменить структуру. Хорошо организованый код надо будет либо донастроить, говнокод — переписать.
>Писать качественный кодж и говнокод — это почти одинкаковые затраты.
O RLY?

у меня есть ООП задача, в лоб она решается одним классом с ПХП+ХТМЛ, и все нарушается: IoC, SOLID etc.

и ровно в 5 раз медленнее делается нормальное ООП, если писать реализацию.
интерфейсы, абстрактные классы, фабрики, прокси и тд.; причем МИНИМАЛЬНО необходимые для нормального масштабирования под требования.
2ой абзац — это overengeneering, то есть излишнее усложнение.
Все перечисленное там тебе не надо, если все можно сделать в одном классе. А что бы не нарушались твои IoC просто надо грамотно продумать код.

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

В одном классе — это антиООП. Задача конкретная — есть алгоритм. Он должен одинаково работать под консоль, под веб — I/O объекты и хранилища разные, а алгоритм один. Необходимо обеспечить легкость добавления новых реализаций I/O объектов и хранилищ в виде новых «сред» (контекстов) так, чтобы исходный алгоритм не изменялся вообще.

Отличная ООП задача, выявляет все и сразу.

Впрочем, о чем мы спорим? :) Если бы можно было измерить overengeneering точно и сразу, моя работа архитектора была бы просто формальным применением матмодели.
Наверное надо уточнить — быстрый запуск тяп-ляп допустим, когда ниша не занята, чтобы сразу получать фидбек (+ пресловутый traction) и быстро дополнять/пилить функционал. Если ниша конкурентная — такая тактика не прокатит.
Да даже если есть конкуренты.
Какая разница? Побеждает сегодня тот, кто самый быстрый, а не самый страшный.
Об этом еще в 99 году Билл Гейтс в своей книге, кстати, писал
как утверждает фонд Джоэла Спольски (Joel Spolsky), «их софт — всего лишь набор текстовых полей»)

А что за фонд у Джоэля? Помощи молодым геям-программистам?

В оригинале:
as Joel Spolsky is fond of saying, “Their software is just a bunch of text fields!”

Google Translate:
как Джоэл Спольски любит говорить: «Их программное обеспечение просто набор текстовых полей!»
да, глаз замылился.
спс, щас поправлю
статья — во многом клон или размазанный повтор книги «22 непреложных закона маркетинга». И, да, статья подтвердила последний или предпоследний тезис книги «даже самая плохая идея с хорошим количеством денег лучше, чем самая хорошая идея без них» (если брать кисметрикс с мощной «спиной» информационной поддержки гуру «той страны»
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории