вторник, 2 апреля 2013 г.
понедельник, 1 апреля 2013 г.
воскресенье, 31 марта 2013 г.
суббота, 30 марта 2013 г.
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" неясно. Некоторые указывают на крошки от печенья; остальные связывают его с печеньями с предсказаниями, внутри которых находится послание.
источник
пятница, 29 марта 2013 г.
Неожиданная новость от Spanner: на место NoSQL приходит NewSQL
Недавно Google опубликовал материалы о проекте Spanner, своём инструменте глобального масштаба для организации всемирной информации. Джефф Дин предопределил значительность Spanner еще в 2009. Теперь Spanner уже в сети интернет, ждет управления «миллионами машин в сотнях датацентров и триллионами строк данных». Впечатляет.
Специалистам еще надо провести полемику на тему Spanner. Много в чем еще предстоит разобраться. Наибольший интерес вызывает раздел, описывающий мотив отказа Google от NoSQL в пользу NewSQL. Заявление, заслуживающее внимания:
«Мы считаем, что пусть лучше прикладные программисты решают проблемы производительности из-за злоупотребления транзакциями при возникновении узких мест, нежели пишут программы с малым набором транзакций»
Иронично звучит, если учесть, что база данных Bigtable помогла реализовать концепцию NoSQL/согласованность/ключ-значение.
Очевидно, критика в сторону NoSQL обернулась проблемой и для Google. Только Google решал вопросы по-своему, успешно объединяя современную теорию и технологии. Результат: программисты получили настоящие транзакции (желанные для многих), схемы, языки запросов, вместе с необходимой масштабируемостью и высоким уровнем доступности.
Как и в любом другом случае присутствует обратная сторона медали: возможные задержки.
источник
четверг, 28 марта 2013 г.
Проблема не в технологии?
Николас Френкель -- технолог: готовый с радостью часами дискутировать с вами о преимуществах Java в сравнении со Scala, SQL в сравнении с NoSQL, Google в сравнении с Apple и т.д. на самом деле, это не столь важно. Статистика показывает, что более половины разрабатываемых проектов -- провальные. Николас занимается разработкой программного обеспечения на разных должностях более 10 лет, и отмечает, что технология никогда не была основной причиной ошибок.
За свою карьеру он определил 3 главных источника провалов проекта (не по порядку):
Неумение принимать решения
Как архитектор, Николас старается предусмотреть различные решения, которые более или менее соответствуют требованиям. Каждое имеет свою цену и риск. В ответ ожидается четкое решение со стороны руководства касательно этих альтернатив. Когда начальство уклоняется от обязанности принятия решений, проектам не хватает четкого видения и рано или поздно они обречены на провал. Вероятно, рано.
Несформулированные производственные потребности
Традиционные модели водопадной разработки требуют формальной спецификации, а более современные гибкие модели требуют определения владельца продукта. Однако, в обоих случаях главное, чтобы программист знал, что разрабатывать.
Условием успешного проекта является умение корпоративных пользователей работать над своими потребностями: формулировать их, охарактеризовать и уточнить. Верные признаки будущего провала –- разговоры вроде «у нас нет времени это записать» или «это очевидно». Хотя первое понятно –- у фирмы тоже есть дела, но оба вместе демонстрируют отсутствие заинтересованности и ответственности. Единственным логичным выводом будет отказ конечного пользователя.
Ретроспективное планирование
Проекты должны быть реалистичными. Точнее, людей нужно спросить, за сколько времени они рассчитывают завершить задание, и планирование проекта должно базироваться на этом. Если получается наоборот, будьте готовы к неудаче.
Если планирование не реалистичное, уложиться в сроки нелегко: иногда кажется, что весь мир сговорился остановить тебя. Из-за недостижимости целей давление начнет возрастать, мотивация снижаться, и в какой-то момент руководитель проекта будет вынужден предоставить запасной план: реалистичное планирование.
Итак, вместо поисков лучших технологий, нам следует иногда сосредотачиваться на других вопросах и стараться устранить наиболее вероятные препятствия, даже если они не из нашей сферы интересов.
Николас отмечает, что, как инженер, он был не готов решать эти трудности: они не имеют никакого отношения к технологиям, но только устранив их, мы можем снова сосредоточиться на своем основном деле, создавая качественные программы.
источник
За свою карьеру он определил 3 главных источника провалов проекта (не по порядку):
Неумение принимать решения
Как архитектор, Николас старается предусмотреть различные решения, которые более или менее соответствуют требованиям. Каждое имеет свою цену и риск. В ответ ожидается четкое решение со стороны руководства касательно этих альтернатив. Когда начальство уклоняется от обязанности принятия решений, проектам не хватает четкого видения и рано или поздно они обречены на провал. Вероятно, рано.
Несформулированные производственные потребности
Традиционные модели водопадной разработки требуют формальной спецификации, а более современные гибкие модели требуют определения владельца продукта. Однако, в обоих случаях главное, чтобы программист знал, что разрабатывать.
Условием успешного проекта является умение корпоративных пользователей работать над своими потребностями: формулировать их, охарактеризовать и уточнить. Верные признаки будущего провала –- разговоры вроде «у нас нет времени это записать» или «это очевидно». Хотя первое понятно –- у фирмы тоже есть дела, но оба вместе демонстрируют отсутствие заинтересованности и ответственности. Единственным логичным выводом будет отказ конечного пользователя.
Ретроспективное планирование
Проекты должны быть реалистичными. Точнее, людей нужно спросить, за сколько времени они рассчитывают завершить задание, и планирование проекта должно базироваться на этом. Если получается наоборот, будьте готовы к неудаче.
Если планирование не реалистичное, уложиться в сроки нелегко: иногда кажется, что весь мир сговорился остановить тебя. Из-за недостижимости целей давление начнет возрастать, мотивация снижаться, и в какой-то момент руководитель проекта будет вынужден предоставить запасной план: реалистичное планирование.
Итак, вместо поисков лучших технологий, нам следует иногда сосредотачиваться на других вопросах и стараться устранить наиболее вероятные препятствия, даже если они не из нашей сферы интересов.
Николас отмечает, что, как инженер, он был не готов решать эти трудности: они не имеют никакого отношения к технологиям, но только устранив их, мы можем снова сосредоточиться на своем основном деле, создавая качественные программы.
источник
среда, 27 марта 2013 г.
вторник, 26 марта 2013 г.
пятница, 22 марта 2013 г.
вторник, 16 октября 2012 г.
Лямбда в Java 8: кардинальное изменение в разработке Java-программ
Все доминирующие языки программирования сегодня максимально используют мощную идею замыканий. Все, кроме одного. Кто отстает? Java, и годами казалось, что с этим ничего не поделаешь.
Пятнадцать лет назад, когда Мартин Одерски, автор языка Scala и основатель «TypeSafe», вместе с Филипом Вадлером выпустили экспериментальный проект «Pizza», люди старались сделать замыкания неотъемлемой частью языка. Несмотря на кажущуюся излишнюю сложность, сообщество Java вернулось к идее включить замыкания в язык примерно в 2008 году, потом эти планы отложили, поскольку корпорация «Oracle» поглотила «Sun Microsystems», а Java теряла позиции в то время как новые релизы постоянно откладывались.
Но с появлением Java 8 все кардинально меняется и сообществу лучше быть готовым. «Это, наверное, самое значительное обновление для Java» - утверждает Браян Гетц, разработчик Java в «Oracle». Он отмечает, что замыкания изменят метод разработки Java-программ даже больше, чем появления обобщений в Java 5. Так же, как обобщения позволили разработчикам не зацикливаться на определений типов, целью Лямбда-выражений является помочь разработчикам не обращать внимания на поведение.
Лямбда -- название проекта, который привязывает замыкания к языку Java. И что программистам даст Лямбда и использование замыканий? Программисты смогут трактовать блок кода как часть данных, которую можно передать в качестве аргумента, словно в действительности он является экземпляром или типом. «Вроде, ничего особенного, но на самом деле -- это громадное достижение» - заявляет Гетц. «Это существенно изменит подход к разработке Java-библиотек».
Потребовалось много времени, но с выпуском Java 8 проект Lambda наконец станет полноценной частью спецификации языка. Синтаксис, который сначала раскритиковали как слишком сложный для обычного программиста, в результате станет стандартным инструментом разработки, встречающимся в каждом современном Java-приложении.
источник
Пятнадцать лет назад, когда Мартин Одерски, автор языка Scala и основатель «TypeSafe», вместе с Филипом Вадлером выпустили экспериментальный проект «Pizza», люди старались сделать замыкания неотъемлемой частью языка. Несмотря на кажущуюся излишнюю сложность, сообщество Java вернулось к идее включить замыкания в язык примерно в 2008 году, потом эти планы отложили, поскольку корпорация «Oracle» поглотила «Sun Microsystems», а Java теряла позиции в то время как новые релизы постоянно откладывались.
Лямбда -- название проекта, который привязывает замыкания к языку Java. И что программистам даст Лямбда и использование замыканий? Программисты смогут трактовать блок кода как часть данных, которую можно передать в качестве аргумента, словно в действительности он является экземпляром или типом. «Вроде, ничего особенного, но на самом деле -- это громадное достижение» - заявляет Гетц. «Это существенно изменит подход к разработке Java-библиотек».
Потребовалось много времени, но с выпуском Java 8 проект Lambda наконец станет полноценной частью спецификации языка. Синтаксис, который сначала раскритиковали как слишком сложный для обычного программиста, в результате станет стандартным инструментом разработки, встречающимся в каждом современном Java-приложении.
источник
понедельник, 15 октября 2012 г.
Четыре причины, по которым Facebook отказался от HTML5 и перешел к нативной разработке
Facebook спровоцировал массу споров, выпустив свое приложение для iOS. Но не из-за приложения, как такового, а потому, что посчитал использование HTML5 самой большой своей ошибкой. Собственно, это и стало причиной перехода на нативную разработку.
Все утверждали, что Facebook просто сделал плохое HTML5 приложение, а сам стадарт HTML5 таковым не является, поскольку множеству других разработчиков удалось создать качественные мобильные решения.
Интересная и актуальная точка зрения, особенно если учесть, что мобильные системы получают все больше и больше замечаний. Ранее отсутствовали какие-либо детали, относительно принятого решения, но сейчас все иначе. Если вы хотели знать, почему Facebook забраковал HTML5, Тоби Лангел в Perf Feedback приводит следующие причины:
Интересная и актуальная точка зрения, особенно если учесть, что мобильные системы получают все больше и больше замечаний. Ранее отсутствовали какие-либо детали, относительно принятого решения, но сейчас все иначе. Если вы хотели знать, почему Facebook забраковал HTML5, Тоби Лангел в Perf Feedback приводит следующие причины:
- Инструменты/API разработчика. Самое главное, нехватка инструментов для отслеживания проблем с памятью.
- Прокрутка. Она должна быть быстрой, плавной и четырехсторонней.
- Графический процессор. Громоздкий API и абстракция «черного ящика» делают данный подход не совсем ненадежным.
- Другое. Желательна поддержка сенсорного управления браузером, более плавная анимация и эффективная система кэширования.
четверг, 5 апреля 2012 г.
среда, 4 апреля 2012 г.
вторник, 3 апреля 2012 г.
пятница, 30 марта 2012 г.
четверг, 29 марта 2012 г.
среда, 28 марта 2012 г.
понедельник, 26 марта 2012 г.
суббота, 24 марта 2012 г.
четверг, 15 марта 2012 г.
среда, 14 марта 2012 г.
вторник, 13 марта 2012 г.
понедельник, 12 марта 2012 г.
суббота, 10 марта 2012 г.
пятница, 9 марта 2012 г.
четверг, 8 марта 2012 г.
среда, 7 марта 2012 г.
вторник, 6 марта 2012 г.
понедельник, 5 марта 2012 г.
воскресенье, 4 марта 2012 г.
суббота, 3 марта 2012 г.
пятница, 2 марта 2012 г.
четверг, 1 марта 2012 г.
Подписаться на:
Сообщения (Atom)