«Умные очки» — возможно, самое перспективное семейство носимых устройств доступных на рынке. Google Glass — самый интересный гаджет среди них. Да, Google Glass — красивое и крутое устройство. У них отличный дизайн. Они маленькие и футуристичные. В конце концов Google Glass — типичный продукт Google, простой и крутой одновременно. Не смотря на это, я думаю что Glass не будет успешным как продукт и рано или поздно провалиться.
Дисклеймер: все нижесказаное является моим личным мнением и не выражает официальную позицию компании, в которой я работаю или R&D команды, которой я руковожу. Честно говоря, некоторые из моих сотрудников спорят со мной, что Google Glass — отличное устройство, которое покорит мир и т.п. Конечно, я немного преувеличиваю в этой статье, но все же мне кажется, что Glass рано или поздно провалиться.
Так что же с ним не так? Я вижу две проблемы:
1. Само устройство. Я опишу главные его недостатки чуть ниже.
2. Его позиционирование и рынок. Далее я попробую провести некоторые интересные исторические аналогии и спроецировать их в будущее.

Пять причин почему Google Glass — отстой

Итак, что же не так с Google Glass? Когда вы смотрите рекламу или слушаете сотрудников Google, которые пиарят Glass, устройство выглядит настолько футуристическим и крутым, что вы начинаете верить, что вот оно — будущее, и ищете кнопку заказа. Но ваше отношение может сильно поменяться когда вы в конце концов получите устройство в свое распоряжение. Мы купили пару штук для нашей R&D команды пару месяцев назад и… ну, я бы не сказал, что это было большое разочарование, но устройство очень далеко от того, чтобы считаться готовым к выходу на рынок. Вот список из пяти вещей, которые наиболее разочаровывают в Google Glass:

JavaScript — это ассемблер Веба. В мире существуют десятки проектов, которые компилируют код на C++, Java, C#, Python, Ruby или любом другом языке в JavaScript. Практически не осталось языка, который невозможно скомпилировать в JavaScript. Ну разве что кроме… самого JavaScript!

Мы решили исправить эту ситуацию. Встречайте: js2js — революционный компилятор, который компилирует JavaScript в JavaScript!

Ключевые особенности проекта

Контроль: вы получаете полный контроль над каждой строчкой результирующего кода. Вы даже можете скомпилировать неработающую программу на JavaScript в идентичную ей неработающую программу.
Нулевой оверхед: js2js не замедлит исполнение кода, скомпилированный код будет иметь точно такую же производительность как и исходный.
Интеграция: js2js работает с любой другой существующей технологией связанной с JavaScript: AngularJS, Emscripten, Vanilla JS, jQuery, CoffeeScript, TypeScript, и даже Dart.
Совместимость: код, сгенерированный js2js поддерживает все виды стационарных, мобильных устройств и браузеров. Даже если вы пишете под Netscape 2.0, вы можете скомпилировать свой код в js2js.

 

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

Стадия первая. Рождение

«Я программист. Я олимпиадник. Я знаю что такое «о»-маленькое. Я знаю, что такое «О»-большое. Я понимаю, чем отличается «эн-квадрат» от «эн-факториала» и почему они оба стыдливо прячутся при виде «эн-логарифм-эн». Сейчас я приду на проект и перепишу эту тормозную кашу из кода так, что она будет работать в много раз быстрее! Смотрите, я знаю алгоритм Кнута-Морриса-Пратта! А здесь можно сэкономить одно сравнение строчек на равность! А если эту рекурсию развернуть в цикл, то за счет экономии вызовов методов и выделения памяти в стэке… Что, программа тормозит? Сейчас я посмотрю код… Вот! Смотрите, здесь вместо двух вложенных циклов можно написать один и использовать бинарный поиск вместо внутреннего!»

Знакомтесь, это первая стадия. Она, в отличие от следущих, особенно характерна именно для олимпиадников. Пациент думает о том, как написать быстрый код. Он одержим быстрым кодом. К сожалению, наличие быстрого кода не всегда делает быстрым программный продукт в целом.

Война между гигантами мирового софтостроения в разгаре и идет на нескольких фронтах. Microsoft запустил серию агресивных видеороликов о преимуществах своих корпоративных и офисных решений над альтернативными от Google и OpenOffice.org под общим названием Why Microsoft.

По ссылкам ниже можно ознакомится с другими роликами:
Why Microsoft: Exchange vs. Gmail
Why Microsoft: Microsoft Excel vs. Google Spreadsheets — Sharing
Why Microsoft: Microsoft Excel vs. Google Spreadsheets — Authoring
Why Microsoft: Microsoft Word vs. OpenOffice.org Writer
Why Microsoft: Microsoft PowerPoint vs. OpenOffice.org Impress
Why Microsoft: Microsoft Excel vs. OpenOffice.org Calc
Интересно, будет ли ответ от Google?
И да, естественно, это реклама.

Здравствуйте!
Примерно месяц назад я написал статью, в которой представил на суд уважаемой хабрапублики несколько графиков. Графики как могли отражали историю развития этого сайта и пытались оценить качество контента на нем. Даже не знаю, удалось ли им добиться своей цели, но в целом статью встретили довольно тепло. Еще тогда я пообещал себе, что при возможности попытаюсь продолжить тему.

И снова о тематическом наполнении

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

Здравствуй, дорогой Google!

Я очень люблю твой GMail — это мой основной почтовый сервис. Я очень люблю твой GTalk — это мой основной IM-клиент. Я очень люблю множество других твоих сервисов. Но, я тебя прошу, пойми, что иногда почта должна оставатся просто почтой. Неужели так сложно было сделать это отдельным сервисом?
Пускай эта картинка повисит здесь, я слышал, многим твоим пользователям не нравится яркая цветная иконка другого сервиса в основном меню твоего почтового клиента, а как избавится от нее они не знают:

Попроще: Settings->Labels->Buzz->Hide или перетащить его мышью в «More».
Спасибо тебе, дорогой Google.

С наилучшими пожеланиями и мечтой увидеть Buzz отдельным сервисом,
твой пользователь.

Лирическое отступление

Здравствуйте!
Однажды темным зимним вечером мне было нечего делать и я убивал время чтением любимого Хабрахабра. В коментах в очередной раз проскочила фраза о том, что Хабр, дескать, уже не торт.

Статистика, статистика и еще раз статистика

Мне стало интересно, можно ли как-нибуть оценить качество статей на Хабре численно и будет ли видно по полученной оценке, как оно менялось со временем, или же, на самом деле, все эти комментарии не более чем брюзжание о том, что раньше и трава была зеленее? Дело было вечером и делать было нечего, поэтому я взял волю в кулак и написал простенького бота, который неспеша перекопал почти 2800 страниц главной Хабра и собрал статистику по захабренным статьям с момента открытия Хабра и по 31 декабря 2009 года.
Традиционная картинка для привлечения внимания, график количества статей по месяцам:

Здравствуйте.
Вчера я опубликовал на Хабре перевод статьи об одной из новых возможностей четвертой версии C# 4.0 – ключевого слова dynamic. В комментариях развернулась бурная дискуссия, основными мотивами которой было две вещи: производительность динамиков и область их применения. В этой статье я не буду затрагивать первый вопрос, а попытаюсь привести пример того, как новая возможность позволяет решить вполне реальную задачу за пару часов с минимальными усилиями.

В статье «Обзор C# 4.0» я обсуждал некоторые из новых особенностей четвертой версии языка C#. Так получилось, что я не рассмотрел одно из самых важных нововведений: ключевое слово dynamic.

Большинство прикладных приложений, которые приходится разрабатывать на практике, сводятся к примитивному шаблону: есть некая предметная область, в которой выделены объекты и связи между ними. Все это легко представляется в виде таблиц в базе данных, а базовый функционал приложения состоит в том, чтобы выполнять над этими таблицами четыре основных действия: создание, модификацию, просмотр и удаление объектов. Далее, обычно, на эту основу прикручивают дополнительную бизнес-логику, модуль отчетов и остальной необходимый функционал.
Естественной реакцией организма разработчика на присутствие определенного шаблона является желание автоматизировать его применение, например, используя кодогенерацию. Шутка. Кодогенерация – это тот же метод copy-paste, только за программиста его делает специально написанный инструмент. Иногда это оправдано, но перед тем, как решится на генерацию кода, лучше хорошо подумать, а нельзя ли здесь обойтись средствами ООП, к примеру?

Собираюсь начинать новый проект и постепенно приближаюсь к стадии написания некоторых базовых вещей. Решил собрать и систематизировать свои знания об некоторых аспектах разработки ПО на платформе ASP.Net, полученные за более чем год коммерческой разработки. В результате получилась вот такая статья. Она не претендует на принципиально новые вещи, это все давно знают, в определенном смысле это своеобразные best practices. Все, что написано ниже, скорее всего пригодится новичкам, но и опытные разработчики смогут почерпнуть для себя что-нибуть интересное.

Этот топик является ответом на это заявление в хабраюзера wizard о том, что проекты для работы с БД на .Net занимают очень много места на диске и вообще, двадцать лет назад трава была зеленее, а деревья выше.
Как высказался один из комментаторов вышеупомянутого топика (neuotq):

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

Важно понимать, что современные фреймворки дают программисту множество инструментов для решения задач. И если вам нужно, цитирую, «получить пару строк данных» из БД, не нужно для этого применять «комбайны с лазерным прицелом» а-ля ADO.Net Entity Framework или NHibernate. Важно понимать, что такие инструменты созданы для больших проектов. Под большим проектом я понимаю не курсовую или дипломную работу, а крупномасштабные коммерческие системы, которые стоят очень больших денег и лишний «1 день(неделя, месяц)» (опять цитата), затраченный на написание собственных велосипедов, обходится заказчику в сотни(тысячи, миллионы) отнюдь не русских денег. Хороший разработчик отличается от плохого тем, что знает, когда нужно писать велосипед, а когда достаточно взять готовый. Плохой, соответственно, либо пихает кругом фреймворки, либо же наоборот везде пишет велосипеды. И виноваты в этом не инструменты разработчика, а он сам.
Все, не буду утомлять своей философией. Под хабракатом можно почитать о том, как можно взаимодействовать с базой данных в .Net без привлечения экскаваторов.

Приблизительно через год нас ждет очередной релиз Microsoft Visual Studio и едва ли не самой вкусной новинкой обещает стать F# — функциональный язык глазами ребят из Кембриджской лаборатории Microsoft Research. Этот язык совсем новый и сейчас находится на стадии вылизывания в лабораториях Microsoft Research. Microsoft позиционирует F# как один из основных языков для .Net наряду с C# и VB.Net что скорее всего значит, что рано или поздно с ним придется столкнутся очень многим програмистам под .Net. Я, как и многие разработчики, никогда не сталкивался с чисто функциональными языками, но принцип «Готовь сани летом» еще не отменяли. Эта статья — мой личный маленький «Привет F#».

Одим хмурым воскресным утром мне было нечего делать и я решил попробовать написать свой вариант велосипеда – облако тэгов на ASP.Net. Результат получился довольно интересным, поэтому решил оформить его в виде статьи и выложить на Хабре.
Сразу оговорюсь – это результат всего-лишь полуторачасового кодинга, соответственно просьба не воспринимать его как полностью готовый контрол, а лишь как концепт, который еще можно развивать и развивать.