Простое обьяснение. Нет

7 странных технических терминов

Откуда получили свое название 7 странных технических терминов

Технические термины могут быть очень занятными. Например: что на самом деле означает "Bluetooth"? Почему мы называем фрагмент кода, который отслеживает пользователей, "печенькой" (cookie)? И что насчет любимых "вики"?

Так откуда произошли некоторые странные технических термины и их необычные названия? Набирайте печенюшки и давайте поищем ответы.

Bluetooth

Если верить избранному в 2006 г. в галерею славы Bluetooth Джиму Кардачу, имя "Bluetooth" было позаимствовано у короля Дании, известного как Гаральд Блютус (Синезубый). Нет, король Б - не замаскированный Папа Смурф. Согласно легенде, парень просто любил голубику и его так прозвали из-за окрашенных в синий цвет зубов.

Примечательно то, что Король Гаральд объединил разрозненные датские племена в единое королевство. Теперь понимаете?

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

Wi-Fi

"Wi-Fi", как выяснилось, не значит ничего. Фил Беленджер из Wi-Fi Alliance официально заявил, что этот термин -- всего лишь броское название, придуманное брендинговой компанией.

Как вспоминает Беленджер, участники Wi-Fi Alliance не приняли бы термина без объяснений и согласились использовать его как ключевой в рекламной кампании: "The Standard for Wireless Fidelity". Он является результатом, как говорит Беренджер, "неудачной попытки придумать два слова, сочетавшые "Wi" and "Fi". Через год термин перестали использовать в рекламных целях. 

Тролль

Хотя образ пещерного монстра на подобие гоблина кажется очень подходящим, за данным термином скрывается намного больше. Слово "troll" также переводится как "ловить рыбу на блесну с движущейся лодки" ("to fish by trailing a lure or baited hook from a moving boat.")

Учитывая вышесказанное, становиться понятным, откуда произошло интернет-значение.

Вики

Авторство первого вики приписывают Уорду Каннингему, разработчику сайта WikiWikiWeb (1995 г.).

Уорда привлекло слово "wiki" во время путешествия на Гавайи. Там служащий аэропорта сказал ему ехать с одного терминала в другой "автобусом вики-вики". Он объяснил ему, что "вики-вики" означает "быстрый".

Спам

Согласно популярному мнению, название "спам" связано не с низкопробной тушенкой, а с известным в 70-е гг. скетчем Монти Пайтон.

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

Печенька (Cookie)

Хотя точных сведений о происхождении интернет-cookie нет, можно "состряпать" собственную версию.

Считается, что термин берет начало от Unix-систем, где использовали словосочетание "magic cookie". Имелись в виду порции данных, которыми обменивались программы. Улавливаете сходство?

А вот почему выбрали именно слово "cookie" неясно. Некоторые указывают на крошки от печенья; остальные связывают его с печеньями с предсказаниями, внутри которых находится послание.

источник

В преддверии выпуска iPad 3

Subjective C

SOA для всех

Неожиданная новость от Spanner: на место NoSQL приходит NewSQL

Недавно Google опубликовал материалы о проекте Spanner, своём инструменте глобального масштаба для организации всемирной информации. Джефф Дин предопределил значительность Spanner еще в 2009. Теперь Spanner уже в сети интернет, ждет управления «миллионами машин в сотнях датацентров и триллионами строк данных». Впечатляет.

Специалистам еще надо провести полемику на тему Spanner. Много в чем еще предстоит разобраться. Наибольший интерес вызывает раздел, описывающий мотив отказа Google от NoSQL в пользу NewSQL. Заявление, заслуживающее внимания:

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

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

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

Как и в любом другом случае присутствует обратная сторона медали: возможные задержки.

источник

Утро без новой версии Firefox

Проблема не в технологии?

Николас Френкель -- технолог: готовый с радостью часами дискутировать с вами о преимуществах Java в сравнении со Scala, SQL в сравнении с NoSQL, Google в сравнении с Apple и т.д. на самом деле, это не столь важно. Статистика показывает, что более половины разрабатываемых проектов -- провальные. Николас занимается разработкой программного обеспечения на разных должностях более 10 лет, и отмечает, что технология никогда не была основной причиной ошибок.

За свою карьеру он определил 3 главных источника провалов проекта (не по порядку):

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

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

Условием успешного проекта является умение корпоративных пользователей работать над своими потребностями: формулировать их, охарактеризовать и уточнить. Верные признаки будущего провала –- разговоры вроде «у нас нет времени это записать» или «это очевидно». Хотя первое понятно –- у фирмы тоже есть дела, но оба вместе демонстрируют отсутствие заинтересованности и ответственности. Единственным логичным выводом будет отказ конечного пользователя.

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

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

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

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

источник

Когда садится аккумулятор

Гики. Несколько "ласковых" строчек

Фантомная боль

Как справиться с ненавистным проектом