Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

AAPL

Новый MacBook Air 11.6", представленный сегодня эплом, является первым девайсом, который может конкурировать с PowerBook 12" 2005 года выпуска.

По размеру и весу PowerBook 12" оставался непревзойдённой машинкой неприлично долгое время. MacBook Pro 13" был гораздо тяжелее (и больше!), а предыдущая MacBook Air была недоделкой, которая постоянно перегревалась, после чего у неё отпадали процессорные ядра. К тому же, она стоила серьёзных денег, особенно с SSD.

Несмотря на то, что своим PowerBook G4 12" я очень доволен, всё-таки некоторые тормоза при проигрывании H.264 и плохая поддержка рабочего места разработчика для iPhone сделали своё дело — я скрепя сердце вынужден переходить с PowerPC на Intel.

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

PowerBook G4 12"MacBook Air 11.6"
ПроцессорPowerPC G4 1.5 GHzIntel Core 2 Duo 1.4 .. 1.6 GHz
Шина166 MHz800 MHz
Память1.25 GB2..4 GB
Дисплей1024x768, Anti-glare1336x768, Glossy
Диски100 GB 2.5" IDE HDD64..128 GB (SATA?) SSD
ПримочкиМодем, Ethernet, FireWire, Line In, DVD  Камера, поддержка 27"/30" внешнего монитора
БатарейкаЗаменяемая, 1.5—3 часаНеснимаемая, 5 часов
Цена$2400 тогда, ~$240 сейчас$999..$1399


Модем, Ethernet, FireWire, Line In и DVD я за последние несколько лет использовал всё реже и реже, и на настоящий момент практически свёл использование их к нулю. А вот без внешнего монитора жить не могу. Поэтому по примочкам текущий Air уделывает PowerBook.

Счастье — пришло.

Если я его таки куплю, это будет первый апгрейд, который принесёт уменьшение номинальной тактовой частоты (1.4 GHz vs 1.5 GHz).

RSI — как бороться с туннельным синдромом

Начальные симптомы туннельного синдрома у меня появились в конце девяностых. И конечно же, как и все другие будущие пациенты с RSI, я их проигнорировал. В 2000 году oleyka прислала мне клавиатуру Acer Ergo 61 (ошибочно прозванную «13R Future» в Компьютерре), с которой первые симптомы практически исчезли, и я смог ещё несколько лет поработать в своём обычном темпе. Но клавиатура всего лишь позволила мне продолжать травмирующую активность более интенсивно.

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

Месяц спустя врач, к которому уговорили пойти меня коллеги в Cisco, диагностировал «a mild case of RSI/CTS» (repetitive strain injury / carpal tunnel syndrome). Первые три месяца я практически не прикасался к программированию. Затем ещё полгода делал минимально общественно полезную деятельность: 50 строчек в день считалось удачей. Это с учётом написания писем. Код же, с его постоянными двух- или трёхклавишными комбинациями (скобки, подчёркивания, camelcase) набирать было особо неприятно. Если это считается «mild case», тогда что же такое severe case?..

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


Проверка предрасположенности к RSI у мужчин.
Я пытался применить систему голосового распознавания, но быстро бросил: она посадила мне голосовые связки так, что я не мог разговаривать в голос. Оказывается, у людей с врождённой предрасположенностью к RSI (предрасположенность проверяется путём доставания большим пальцем запястья той же руки), голосовые связки очень быстро садятся от постоянной активности. Так что, voice recognition мне не помог. Единственное, что осталось от этого эксперимента — неплохая USB-гарнитура, которую использую для Skype-переговоров.

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

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

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

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

Сначала замечу, что RSI почти не лечится, или лечится десятилетиями. То, на что вы можете рассчитывать — это законсервировать процесс на текущем уровне. Главное, что может в перспективе хоть как-то помочь — это прекращение травмирующей активности, то есть программирования и работы с клавиатурой. Уйдите в менеджмент, в конце концов: email меньше травмирует, чем кодирование кода. Используйте менее многословные языки программирования, например функциональные языки программирования, Perl. В этом отношении PHP лучше, чем многословная Java, а Haskell лучше, чем PHP.

Рекомендую книгу Dr. Pascarelli's Complete Guide to Repetitive Strain Injury: What You Need to Know About RSI and Carpal Tunnel Syndrome.

Так вот, нехитрый список правил того, как жить с RSI:
  1. Мышку использовать нельзя. В списках причин RSI мышь стоит на первом месте. В опросниках у врачей по поводу RSI мышь стоит на первом месте: «Используете ли вы компьютерную мышку?» Используйте точпад. У меня есть точпад и планшет, но планшет мне неудобен для повседневной работы всё-таки. Некоторые говорят, что приноровившись, планшет эргономичнее. Чем что? Чем мышка — конечно. Чем точпад? Сомневаюсь.
  2. Используйте vi, а не Emacs. Многоклавишные комбинации вредят эргономике процесса http://xahlee.org/emacs/emacs_hand_pain_celebrity.html
  3. Коротко стригите ногти Обрезайте ногти под ноль. Два миллиметра — уже много. Нажатие на клавиатуру подушечками пальцев щадит связки сильнее, чем нажатие или задевание части поверхности клавиши ногтями.
  4. Используйте клавиатуру с мягким ходом клавиш, без «дребезга» и щелчков. Шелчки передаются связкам и травмируют их.
  5. Сухожилия давят на сухожильную сумку и перетирают, раздирают её изнутри. Вывод: нужно держать руки так, чтобы сухожилие не проходило в запястье под углом. Эргономические клавиатуры нехило помогают, но не все клавиатуры, на которых написано «Ergonomic» являются такими. Например, клавиатуры с верхним рядом клавиш, расположенным выше (дальше от поверхности стола), чем нижний, такими не являются. Некоторые модели Kinesis рулят, Acer Ergo 31/61 рулит (но её невозможно достать). В крайнем случае, если уж совсем ничего нет, сойдёт Microsoft Ergonomic Keyboard.
  6. Печатайте размеренно, в одном ритме и подчёркнуто медленно. Старайтесь делать одинаковые интервалы между нажатиями клавиш, и не допускайте особо вредных взрывных нагрузок, когда после относительно долгого обдумывания строчка или токен набиваются моментально, одним проходом рук. Лучше помедленней набрать, чем сорвать руку таким образом.
  7. Для того, чтобы кисти приучались не изгибаться в процессе работы, нужны развитые кости и мышечный корсет. Если вам до 25 лет — идите в качалку, тренируйте мышцы рук. Это будет способствовать развитию костей. Если вы старше, то кости уже сформировались, и изменить их практически невозможно. Так что берите PowerBall и/или занимайтесь спортом, адресно тренирующим мышцы кистей: скалолазание или бадминтон, например. Не теннис.
  8. Будете использовать PowerBall — используйте без фанатизма. Регулярное превышение 6-8 тысяч оборотов на нём вам сделает RSI, если его даже не было. Для того, чтобы укрепить мышцы, надо систематично крутить его на относительно небольших оборотах: «столько, пока комфортно терпишь, плюс ещё тридцать секунд».
  9. Рука в процессе работы не должна лежать на клавиатуре или столе, а должна держаться на весу. Класть руку на подушку клавиатуры или на стол можно только если в это время не происходит нажатий на клавиши.
  10. Для больших движений используйте большие мышцы, для малых — малые. Это значит, что набирать на верхних рядах клавиш нужно перемещая всю руку, а не путём доставания до крайних рядов клавиш вытягиванием пальцев. Во время печати кисть не должна двигаться влево-вправо или вниз-вверх, следите!
  11. Сплинты — это такие медицинские перчатки без пальцев, укрепляющие кисть. Использовать их при работе нельзя, они приводят к деградации мышц при относительно недолгом использовании. Через неделю работы в сплинтах мышцы атрофируются настолько, что есть шанс совсем не суметь работать без сплинтов. Сплинты можно иногда использовать на ночь, чтобы во время сна не перегибать кисть. Но в конце концов надо от сплинтов избавиться. Я был только первые полтора года в сплинтах — спал в них, и лишь очень изредка работал.
  12. Ибупрофен — копеечное, но очень действенное лекарство, с минимумом побочных эффектов. Оно эффективно снимает боль и обладает противовоспалительным эффектом. Оба свойства подходят для снятия симптомов боли и/или онемения. Но использовать его во время работы нельзя — воспаление-то оно чуть притушит (хорошо), но симптом боли снимет. В итоге вы не будете чувствовать, когда требуется срочно прекращать активность. Короче, если пользоваться ибупрофеном — а на начальных этапах лечения именно его и рекомендуют — ибупрофен надо принимать после травмирующей работы, или перед сном. Чтобы боль во время работы никуда не исчезала и была индикатором того, что надо завершать процесс.
  13. Перед работой руки следует прогревать. Сначала тёплой водой под краном, затем разминающие, разогревающие мышцы и чуть-чуть растягивающие действия кистями.
  14. Не работайте на ноутбучной клавиатуре, и тем более, не работайте на ноутбуке лёжа. День работы на ноутбуке мне стоит трёх дней отходняка.
  15. Алкоголь дополнительно повреждает нервы в воспалённом районе кисти и, похоже, смазку сухожилий. FYI: пить вредно.

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

Мир компьютеров (1988)

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



Семиуровневая модель иерархии протоколов ISO OSI.



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



Телеконференция. Только в 2006 году я впервые увидел такое вживую. Обратите на сходство книги и реальности двадцать лет спустя.



Ну и DES, конечно, куда же без DES в восьмидесятых.



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

Feeding Frenzy: Selectively Materializing Users’ Event Feeds

Adam Silberstein, Jeff Terrace, Brian F. Cooper, Raghu Ramakrishnan

http://www.google.com/search?q=pdf+selectively+materializing+user%27s+event+feeds

Feeding Frenzy: Selectively Materializing Users’ Event Feeds


Народ из Yahoo! Research и Princeton University разбирает проблему глобальной оптимизации расходования машинных ресурсов для поддержки передачи реал-таймовых фидов.

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

Теперь проблема: если есть быстрые поставщики фидов и огромное количество не очень часто посещающих свои фиды потребителей, то материализация фидов для такой толпы становится накладной операцией. Например, в твиттере есть такой пользователь «Ashton Kutcher», каждое сообщение которого расходится по «френдлентам» почти пяти миллионов подписчиков. То есть, каждое сообщение от него должно повлиять на миллионы материализованных представлений.

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

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

Авторы вводят понятие k,t-diversity. Неформально это можно понимать так: если приходит событие от Боба в последние t квантов времени, тогда мы не показываем более k событий от Алисы, ежели мы не показываем в это же время событие от Боба.

Рассматриваются две модели когерентности: per-producer и global (эта деталь неважна сейчасlionet). В модели per-producer, стоимость события для конкретного потребителя зависит от частоты актов потребления (рефреша страницы френдленты) и событий поставщика. В глобальной модели когерентности, стоимость события зависит от частоты актов потребления и суммы частоты событий от всех поставщиков событий для данного потребителя.

Что такое стоимость — это выраженная в CPU или в disk IO операциях сложность обслуживания события для системы.

Адаптивный алгоритм, который они предлагают ("правильный" knapsack алгоритм — NP-hard) выглядит примерно так:

We simply sort the pull edges by descending, and shift some number of top-ranked edges to push. Then, if our latency is higher than the SLA, we incrementally shift the top-ranked pull edges to push. If our latency is lower than the SLA, we incrementally shift the lowest-ranked push edges back to pull (note that we never shift edges to pull if they are assigned to push).


От себя:

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

Хотите узнать главное отличие Маков от Винды?

Сергей Булаев (Интернетные штучки, etc) наткнулся на известный эффект различия в идеологии многооконной работы между маком и виндой.

Не знаю почему, но стоит виндоузятнику сесть за мой ноут, скажем проверить почту, первым делом производится попытка увеличить окно браузера до максимума. И это при разрешении монитора 1920x1200. Я давно уже отвык от этих странностей.

Это абсолютно стандартная практика, проверенная уже на десятках друзей. Единственное что я могу предположить - походу в винде, в отличии от маков, не особо удобно работать с несколькими окнами на десктопе.
http://bulaev.org/10150221

Этот эффект неоднократно описан в литературе по UI дизайну, и замечается достаточно быстро с переходом на мак.

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



В чём прикол? В маках зелёная кнопка со значком плюсик не предназначена для распахивания окна на полный экран. В наш век экранов с двухтысячепиксельными разрешениями мало какое приложение может рационально отобразить информацию на таком пространстве. Открой тот же браузер на полный экран — и все эти «тянущиеся» дизайны, не говоря уж про plain text, превратятся в набор длинных строк. Длинные строки — это зло, пока переносишь взгляд от правого края экрана до левого, ты забываешь на какой строчке этот взгляд должен в итоге остановиться. Ширина строчек в книгах — 60-70 букв по горизонтали, не больше. Журнальная и газетная вёрстка — и того у́же, и не без причины. Распахивание на полный экран — неработоспособная парадигма для современных разрешений.

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

Нажатие на зелёную кнопку убирает скроллбары.

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

Не во всех приложениях эта модель уместна. Например, как в текстовом редакторе без концепции постраничной разбивки (TextEdit, это что-то типа Notepad) определить, влез контент, или нет, если мы пишем свободно перетекающий в зависимости от размеров окна долгий текст? Для подобных приложений зелёная кнопка может работать несколько иначе. Но основной момент именно таков — зелёная кнопка расширяет окно до размера контента в нём.

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

Естественно, контекста может быть слишком много: никому не нравится, когда из его экрана торчит множество одновременно движущихся червяков и выедают мозг. Защита от распыления внимания на маке состоит из следующих моментов:
  • Реальный, (почти) удобный механизм рабочих столов. Да, как на юниксах. В отличие от винды, в которой приложения упорно не желают мириться с разными десктопообразующими тулзами, и постоянно брыкаются. В итоге разные активности просто размещаются в разных рабочих пространствах, группируясь по любым критериям, типа "работа1", "работа2", "развлечения", и поэтому один визуальный контекст с несколькими одновременно видимыми приложениями не мешает другому.

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


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

Thunderbird 3

Если у вас Mac OS X, и вы используете ноутбук на базе PowerPC процессора, то не ставьте Thunderbird 3.

1. Тормозит. Ищет очень медленно (несмотря на то, что там новый поисковый движок внутри).
2. Тормозит. Какой-то цикл, похожий на GC (?!) постоянно приводит к залипаниям Thunderbird, с отрывом существенной части ресурсов. Это длится минуты и даже десятки минут. Иногда при этом можно работать, но чаще — rainbow cursor.
3. Тормозит. При набирании текста писем может залипнуть на несколько десятков секунд. Каждый второй абзац.
4. За неделю пользования я сегодня его впервые выключил руками. Обычно он сам падал — а что, удобно! Предыдущий Thunderbird (2.x) выключался только вместе с перезагрузкой компьютера (раз в пару недель или месяцев).
5. Очень тормозит.

P.S. Количество писем, обслуживаемых у меня Thunderbird'ом — в районе сотни тысяч. История порядка 24 гигабайт.
P.P.S. Принял финальное решение подумать о переходе на mutt, ибо достало.

HDD progress

Заменяя диски в своём NAS'е, решил поделиться впечатлениями от прогресса в области производства жёстких дисков.

В ощущениях даны три диска Seagate.

Вот это — 9 GB SCSI драйв.


Это — 250 GB SATA.


Это — 500 GB SATA.


Когда ребёнок вырастет, ковырять, ломать и исследовать в дисках уже будет нечего ;(

Computer History Museum

Сегодня с Ольгой и Марком ходили в музей компьютерной истории, в Mountain View.

Узнали и увидели кучу интересностей.

Вот, например, суперкомпьютер Cray-1:



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

Интересно, что в музее сейчас функционирует одна из двух существующих в природе действующих машин Беббиджа: Difference Engine #2. Тринадцать тонн! Приводится в движение нехилой рукояткой сбоку, и печатает результат с точностью тридцать один знак после запятой на бумажной ленте.

Беббидж спроектировал её в середине девятнадцатого века, но построить её у него не хватило сил, несмотря на отсутствие проблем с финансированием. Только в конце двадцатого века для Лондонского музея сделали работающую машину, с использованием оригинальных чертежей и технологических допусков девятнадцатого века (чтобы проверить, мог ли Беббидж в принципе построить её по тем технологическим возможностям). Вторая сделанная машина и стоит сейчас в музее в Mountain View, и будет стоять там почти до конца года.

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



Одной из поразивших меня вещей были компоненты электро-механических машин Конрада Цузе. Z3 (Тьюринг-полная) была сделана в 1941 году!

В связи с этим появилось желание найти какие-то экземпляры техники советской разработки...



Мы пошли правее, ещё правее, ещё...

Collapse )

(no subject)

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

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



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

"Около трех миллионов надувных шаров для фитнеса отозваны производителем после того, как Комиссия по безопасности товаров широкого потребления США признала их опасными для потребителей.", via mr_sheriff.

http://medportal.ru/mednovosti/news/2009/04/20/balls/
http://www.medicalnewstoday.com/articles/146590.php

Читая названия марок этих шаров, начинаешь задумываться над мнемоничностью именования. Как вам лопнутый под вами шар фирмы EB Brands, называющийся Everlast?

Everlast? Где-то я это уже видел. Ах да! Батарейки, которые Олька использует в своих игрушках, имеют марку Ultralast. Их отличительной особенностью является то, что у них в коробках 33% брака. Так, если клавиатура требует три батарейки, то нужно взять три батарейки, принести к клавиатуре, вставить, убедиться что клавиатура не заработала, пойти в серверную, достать тестер, подойти назад к клавиатуре, протестировать, выкинуть две батарейки (Ultralast, однако...), взять две новых батарейки, вставить в клавиатуру, убедиться что она опять не работает, вынуть батарейки, протестировать, выкинуть одну, заменить, и только тогда она заработает.

Видимо, у маркетологов для таких случаев срабатывает какой-то компенсационный механизм. С лёгкостью представляется следующая ситуация. Сидит такой маркетолог, в очках и галстуке (галстук пережимает ток крови к голове, вы знаете), за дубовым столом. К нему приходят из отдела разработки, брякают на стол упаковку батареек, сто штук, десять копеек пучок, и говорят: паря, у нас тут такая ерунда с продакшном вышла. Никак не можем довести качество процесса до такого уровня, чтобы в прямо в каждой батарейке был до краёв залит алкалин. Иногда робот промахивается, проливает жидкий металл прямо нам в сапоги на ленту конвейера. Зато там, где не проливает, батарейки вроде бы работают и способны приносить пользу.

Так вот, маркетер отрывается от книжки Сета, поднимает ясные очи, тычет пальцем в коробень, и волит:
— Мы должны position ourselves as a market leader!
— ...innovate on value proposition!
— и вообще, play on our strengths! Хорошо работают батарейки, говоришь? Значит, называем Ultralast. В смысле, "какие выживают — те до старости живут!"

Примеров море.

Какой софт самый монстрообразный по размеру? Microsoft сразу всплывает. Пытался поставить Vista, диска не хватило.

Процессоры, которые не смогли тягаться на равных с интеловскими чипами? PowerPC. Они были так специально названы! Создали параллельную реальность, где процессоры становятся на каком-то синтетическом тесте быстрее, чем Pentium, просто потому что их назвали излучающим силу именем. UltraSPARC в ту же копилку. У меня один сервер до сих пор работает на УльтраСпарке. Пока он компилирует сиплюсплюсный hello world, в нашей семье расходуется кофе.

Самый тормозной браузер на маковской платформе? FireFox, который бывший FireBird. Животное в огне.

Слышите палёный запах? Это жгут маркетологи.

cisco rebranding

http://www.artlebedev.ru/kovodstvo/business-lynch/2008/11/07/

Насколько я помню из материалов, розданных перед ребрендингом, новые палки являются блендом между старым символом моста (Golden Gate) и представлением формы периодического сигнала; всё-таки коммуникационная компания.

Про мост могут клиенты ничего и не знать, а осциллограф видели все.