Мдя. Интересно. Тоже когда-то задавался таким вопросом. А потом решил, что лучший ответ дадут не подобные эксперименты (у меня база на 20 млн. записей, поэтому что только я не пробовал для ускорения), а просто опыт больших игроков рынка. У меня в свое врем получилась такая табличка:
1. Skype — использует Postgress, в котором более миллиарда клиентов. Естественно, все распределено, но тем не менее. Кстати, после покупки MS были планы перенести все на MongoDB, yо потом от них отказались.
2. Facebook — использует MySQL в режиме NoSQL, то есть как просто хранилище key=value. Для кеширования используется memcache. У них сейчас около 2,5-3 тыс. серверов. Кстати, подход, на мой взгляд, самый правильный. Тут и целостность, и скорость. Я примерно такого же придерживаюсь, но в связке Postgres + REDIS. И стараюсь делать несколько простых запросов, понятных планировщику, вместо нескольких сложных.
3. Craiglist — используется MySQL, были заявления о переходе на MongoDB для хранения архива сообщений пользователей и поиска комментариев в нем. Но статус текущий не знаю.
4. YouTube — использует MySQL, но данных об архитектуре найти не смог.
5. IMDB.com — использует Postgress, но деталей не знаю.
6. Twitter — использует MySQL с очень серьезными «доточками» под себя. Были планы по переходу на NoSQL, но от них отказались, так как тесты не показали существенного прироста производительности перед доточенной MySQL.
Если у кого есть еще какая информация, поделитесь, плз.
В целом, после месяцев двух разных мытарств я уже перестал смотреть разные бенчмарки. :)
Здесь у меня тоже интересное наблюдение. Зачастую боссы искенне хотят иметь эффективную команду, и в частных разговорах говорят о недопустимости «подсиживания» и прочего. Однако на практике, в условиях привычки русских не выносить сор из избы и не докладывать начальству о проблемах, подобные острые ситуации, по сути, являются одним из наиболее эффективных способов узнать о ситуации внутри коллектива. И подавляющее большинство увидев это, не станут принимать меры, а просто соберут информацию для дальнейшего манипулирования коллективом.
В этом и проблема. В крупных проектах как правило нет явных виновников — любой провал является следствием какой-то несогласованности между функциями. Условно говоря, можно, например, разработать продукт, который требует, например, обязательного наличия письменного договора, хотя все вокруг работают по электронным офертам. И нужно просто принять риски. Но в результате продукт не запускается. Чья вина? Юриста, что не взял риск на себя? Или разработчика, который предложил «нелегальный» продукт? Но юрист в своем праве — он оберегает компанию от рисков. А разработчик сделал продукт MUST HAVE, имеющийся на рынке, и способный реально повлиять на место компании на рынке.
А дальше — классика. Собственник скажет генеральному, почему у всех есть, а у нас нет, генеральный спустит это вниз, и вынудит обоих встать в защитную позицию, и валить срыв друг на друга. Если не будут валить, то виноват генеральный, а это, понятно, недопустимо.
Это очень типичный кейс, который как раз и культивирует взаимную неприязнь, отбивает желание проявлять инициативу, и искать наилучшие решения для своей компании.
Самое интересное, что я ни разу не видел, чтобы при описанном варианте ситуация развивалась по другому, несмотря на тим-билдинги, коучинги и аналогичные мероприятия.
Как правило, профессионалы работают в компаниях. И над ними стоят менеджеры, отвечающие за выручку. И у них цель простая — плевать на ТЗ, главное «взять» деньги. А дальше профессионалу некуда деваться — придется «отрабатывать» «эффективность» менеджера.
Да, такой риск есть. В целом, обсуждая вопрос доставки товара, корректность заполнения адреса многие знакомые магазины называют критически важным. Некоторые вообще считают, что нормальной практикой может являться запрос только телефона, обратный звонок, и детальное уточнение адреса доставки. В противном случае — расходы на обслуживание возврата товара могут быть существенны.
Если указывать индекс почтового хаба или города (с тремя нулями на конце), то посылка дойдет, но чуть позже. Для Интернет-магазинов это может быть критичным, поэтому они стараются указывать как-можно более точный индекс.
Еще дополню. В прицнипе, неправильно, если Интернет-магазин требует жестко индекс. Он должен требовать заведения либо индекса, либо адреса. И во втором варианте уже менеджер должен через Интернет или по телефону позвонить в почтовое отделение и выяснить этот индекс. клиента эта проблема касаться не должна. По моему опыту, свой индекс не знают примерно 30% клиентов, это не так много.
К сожалению, одной и той же улице и населенному пункту может соответствовать несколько индексов. Поэтому можно уменьшить их число, но все равно придется задавать вопрос: «Выберите, какой из следующих индексов ваш».
Вот например, здесь вбейте «москва» и «ленинградский». Там 8 индексов.
Хм. На многих АТС есть объекты спецсвязи. Очень хочу посмотреть либо на убеждение силовиков снести их во имя высоких технологий, либо посмотреть на процесс заселения постояльцев, особенно заморских :)
Я тоже думал об этом, пока читал статью. Но кто мешает прицепить к этому кабелю «маленькую черную коробочку», пока водитель обедает? Мои наблюдения в Моунтейн Вью говорят о том, что почти никто машины не закрывает (я и сам не закрывал свою). Открыть ее, подключить телефон с GPRS к колодке и спрятать его под сидением — дело 2-3 минут.
Если уже кто-то захочет развлечься таким способом (этот кто-то будет понимать, что он играет жизнью людей), найти способ «сделать безкабельный доступ к диагностическому разъему» — несложно.
Это документ 2003 года. Тогда GPON еще не было, и МГТС тогда принадлежала не АФК «Система». Проект GPON начался в 2011 году. Где деньги на GPON в бюджете г. Москвы 2011-2013 гг.?
Ух ты. А статью в бюджете московского правительства сможете показать, из которой 40 ярдов на это взяли? Для информации: финансирование проекта идет за счет АФК «Система»
Тоже подпишусь под каждым словом. Убеждал партнера-коммерсанта идти по максимально простому пути: сделать только iOS приложение для одной системы, максимально быстро, с основной функцией. Но уже на этапе 1.0 раздули приложение до ios, android, web, сунули туда кучу функций и вывели на рынок с опозданием в 3 месяца.
И сейчас проблема: уже появляются колмпании, которые хотят это запартнерить, но для этого нужны серьезные изменения, причем сразу в трех составляющих: ios, android, web.
Если бы я сейчас начинал новый стартап, то быстро бы лепил на PhoneGap приложение, и начал бы смотреть спрос на него. И уже по фидбеку с рынком начал бы его менять. По достижении осознанного необходимого функционала переводил на натив и писал web.
dropbox и googledoc — это проекты с предоставлением доступа третьим лицам (например, друзьям). Если доводить ситуацию до абсурда, то достаточно будет подключить друга, и можно сразу лепить обвинение в оказании телематических услуг и передачи данных без лицензии. :) Поэтому если такой подход станет массовым, то прикроют через механизм лицензирования.
У нс сейчас идет крупный проект. По моим оценкам — завершен уже процентов на 70%. При этом бедный PM все еще проводит согласования в электронной системе документооборота, периодически что-то детализирует (там уже более 600 строк) :), а периодически все понимают, что реальное дело обогнало план-график, и нужно его глобально актуализировать. После этого цикл бессмысленных согласований начинается практически заново. :) Наблюдать за этим очень увлекательно.
В общем, да. Я и хотел сказать своим комментарием — что главное авторитет, харизма и профессионализм менеджера. А решает он проблемы диаграммами ганта, совещаниями или личными звонками — дело десятое.
Интересный текст, многое так, но не всегда. У меня руководителем был коммерческий директор одной крупной московской компании с 4 млн. клиентов. Планы особо не вел. Достаточно было ему периодически давать просто по электронной почте основные вехи. Сам мог работать — если была проблема, то засучивал рукава и влезал в проблему вплоть до мелочей. Под управлением было примерно 1000 человек. После его ухода впечатление у всех осталось крайне благоприятным. Планы по продажам всегда выполнял.
Сейчас живет в США, основал там стартап в области финансов.
Так что бывают менеджеры без диаграмм ганта, увлеченный, готовый работать до 11 вечера, способный на ходу менять план, если изменение позволит добиться лучшего результата. Я знаю таких двух.
Видел такой живьем у знакомого в США. Прикольная штука, действительно фотографирует с ярко выраженным 3D эффектом. Особенно классно смотрелась фотография гриба под ногами. Вау-эффект есть, но слишком много фоток смотреть сложно. Постоянно ловил себя на мысли, что попытка высмотреть: «как оно 3D-шное получилось» мешала воспринимать фотографию в целом.
Хм… я всегда предполагал, что рачительный хозяин — не тот, кто широко тратит деньги, а кто может потратить их разумно. Если есть предприниматель, который не только "… живет на эти два процента...", но и имеет пытливый ум и прямые руки, то это уже нетривиальный человек, которого надо беречь и поддерживать. Я очень хотел бы, что как можно больше предпринимателей были у нас такие. :)
1. Skype — использует Postgress, в котором более миллиарда клиентов. Естественно, все распределено, но тем не менее. Кстати, после покупки MS были планы перенести все на MongoDB, yо потом от них отказались.
2. Facebook — использует MySQL в режиме NoSQL, то есть как просто хранилище key=value. Для кеширования используется memcache. У них сейчас около 2,5-3 тыс. серверов. Кстати, подход, на мой взгляд, самый правильный. Тут и целостность, и скорость. Я примерно такого же придерживаюсь, но в связке Postgres + REDIS. И стараюсь делать несколько простых запросов, понятных планировщику, вместо нескольких сложных.
3. Craiglist — используется MySQL, были заявления о переходе на MongoDB для хранения архива сообщений пользователей и поиска комментариев в нем. Но статус текущий не знаю.
4. YouTube — использует MySQL, но данных об архитектуре найти не смог.
5. IMDB.com — использует Postgress, но деталей не знаю.
6. Twitter — использует MySQL с очень серьезными «доточками» под себя. Были планы по переходу на NoSQL, но от них отказались, так как тесты не показали существенного прироста производительности перед доточенной MySQL.
Если у кого есть еще какая информация, поделитесь, плз.
В целом, после месяцев двух разных мытарств я уже перестал смотреть разные бенчмарки. :)
А дальше — классика. Собственник скажет генеральному, почему у всех есть, а у нас нет, генеральный спустит это вниз, и вынудит обоих встать в защитную позицию, и валить срыв друг на друга. Если не будут валить, то виноват генеральный, а это, понятно, недопустимо.
Это очень типичный кейс, который как раз и культивирует взаимную неприязнь, отбивает желание проявлять инициативу, и искать наилучшие решения для своей компании.
Самое интересное, что я ни разу не видел, чтобы при описанном варианте ситуация развивалась по другому, несмотря на тим-билдинги, коучинги и аналогичные мероприятия.
Вот например, здесь вбейте «москва» и «ленинградский». Там 8 индексов.
Если уже кто-то захочет развлечься таким способом (этот кто-то будет понимать, что он играет жизнью людей), найти способ «сделать безкабельный доступ к диагностическому разъему» — несложно.
И сейчас проблема: уже появляются колмпании, которые хотят это запартнерить, но для этого нужны серьезные изменения, причем сразу в трех составляющих: ios, android, web.
Если бы я сейчас начинал новый стартап, то быстро бы лепил на PhoneGap приложение, и начал бы смотреть спрос на него. И уже по фидбеку с рынком начал бы его менять. По достижении осознанного необходимого функционала переводил на натив и писал web.
Такой подход потребует минимум денег и времени.
Сейчас живет в США, основал там стартап в области финансов.
Так что бывают менеджеры без диаграмм ганта, увлеченный, готовый работать до 11 вечера, способный на ходу менять план, если изменение позволит добиться лучшего результата. Я знаю таких двух.