Недавно мне захотелось создать личный проект на андроиде, и основной вопрос был такой: как однозначно идентифицировать пользователя заставляя его делать как можно меньше телодвижений? Конечно же это аккаунт Google. Я пытался пробовать множество примеров в сети — однако API несколько раз обновилось за время своего существования, многие методы не работали, мои вопросы в Google+ по этому поводу либо были вообще никак не восприняты окружением, либо были вроде «Никогда такое не делал».
В этой статье я постараюсь как можно более просто для новичков (вроде меня) описать мой метод авторизации в Google на андроид, получения токена и проверке этого самого токена на сервере.

Примечание от переводчика:

Я решил перевести эту статью в основном из-за личности автора. TJ вложил очень много усилий в развитие Node.js и его инфраструктуры, он автор таких проектов как express, jade, mocha, stylus, автор 550 репозиториев на npm. Существуют также теория, что под этим именем скрывается группа людей.

Как бы то ни было, JavaScript и Go сообщества в ближайшие время ожидают изменения.

Покидая страну Node.js

Я сражался с Node.js достаточно долго, что бы перестать получать от этого удовольствие, это мое официальное прощание! И, что еще важнее, я ищу людей, которые смогут поддерживать мои проекты!

Node отлично справляется с некоторыми вещами, но, к сожалению, это не самый подходящий инструмент для того, что мне сейчас интересно. Я все еще планирую использовать его для сайтов, но если вы хотели бы заняться поддержкой одного из моих проектов, дайте мне знать. Просто оставьте комментарий с вашим именем на Github, ссылкой на npm и названием проекта. Как обычно я прошу не делать больших изменений в существующих API: создать новый проект будет проще.

Я также продолжу поддерживать Koa.

Осенью 2014 года в продажу поступит четвертый по счету LifeTrak с индексом R450 (R415). Компания успешно открыла для себя возможности циркуля, и создала первый круглый гаджет в своей продуктовой линейке.

При этом столь радикальный подход к форме сопровождается традиционным бережным подходом к «содержанию». Те, кто помнит, как чутко изменялись устройства LifeTrak, то революции от R450 и не ждут, В новом гаджете количество ключевых особенностей, заявленных разработчиком, повысится всего на единицу, с 12 до 13! В общем, часики не для суеверных.

Нам, как официальному дистрибьютору LifeTrak в РФ, удалось в числе первых получить новинку и ее протестировать. Что нам понравилось, а что нет в новых часах от LifeTrak — читаем под катом.


Осторожно, трафик, много фотографий.

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

Выбор темы

Наверное, самый важный пункт и к тому же, самый сложный. Причин может быть множество — от организационных, таких как смена университета, кафедры, руководителя до вполне обычных — нынешнее направление не интересное, а новое еще не придумали. Но, как правило, проблема одна — какую тему выбрать для кандидатской?

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

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

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

Попытался начертить схему моей комнаты со всеми устройствами объединёнными в сеть, картинка кликабельна:



Вся идея держится на трёх китах:

• Децентрализация — вся система функционирует без какого-либо главного модуля;
• Простота — минимум компонентов и лёгкость подключения;
• Дешевизна — себестоимость устройства легко уложить в 100 рублей.

Тема «Умный дом» уже у всех на слуху. Про неё говорят, в неё вкладывают, её развивают… По этой теме к таким гигантам как Siemens, General Electric и др. присоединились, казалось бы, не совсем профильные компании, такие как Microsoft, Google, Apple.

Единого стандарта по теме нет, равно как нет инструкции, мол, «делай так и вот так», поэтому теоретически построить свой умный дом может каждый и именно так, как ему захочется и потому эту тему я не смог пропустить и активно к ней подключился. Не скажу, что с умными домами я собаку съел… нет, скорее так, понадкусывал, но тем не менее, на основе свое опыта и своих наблюдений попробую выложить развёрнутый… ммм… How-To? Нет, не потянет. Обзор? Тоже не то… Скорее это будет напутствие или некий набор советов.

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

Самое главное — это то, что статья рассчитана на людей, которые толком ещё не поняли, нужен ли им вообще этот самый «Умный дом» и нужно ли влезать в эту тему?

Теперь термин.
Будем честны, «Умный дом» — это не только такая система с искусственным интеллектом, которая разговаривает с Вами по утрам в ванной (пока вы бреетесь) и готовит Вам ужин пока вы едете домой. Не нужно путать систему с женой.

Мы много рассказываем об одном из главных преимуществ YotaPhone, втором дисплее на электронных чернилах. Но мы обычно не вдавались в подробности: почему мы выбрали именно эту технологию, какие проблемы и сложности вставали у нас на пути, каковы преимущества и недостатки у дисплеев на электронных чернилах, особенно применительно к смартфонам, — обо всём этом мы хотим рассказать.

Это вторая часть статьи (первая часть — try-catch-finally), посвященной такому языковому механизму Java как исключения. Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

1. Магия checked/unchecked
2. Пессимистичный механизм
3. throws с непроверяемым (unckecked) исключением
4. Множественные исключения
5. Или catch, или throws
6. Поведение компилятора/JVM
7. Overriding и throws
8. Передача свойства по наследству

1. «Магия» checked/unchecked

Механизм исключительных ситуация в Java связан с двумя элементами «магии», т.е. поведения, которое никак не отражено в исходном коде:
1. «Магию» java.lang.Throwable — в throw, catch и throws могут стоять исключительно Throwable или его наследники (мы уже разбирали в предыдущей лекции). Это «право» находиться в throw, catch и throws никак не отражено в исходном коде.
2. Все исключительные ситуации делятся на «проверяемые» (checked) и «непроверяемые» (unchecked). Это свойство присуще «корневищу» (Throwable, Error, Exception, RuntimeException) и передается по наследству. Никак не видимо в исходном коде класса исключения.

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

Эпиграф от Milfgard



Заключительная часть цикла, посвященная непосредственно оставшимся методам коррекции зрения. В этой части мы рассмотрим ортокератологию, все варианты лазерной коррекции зрения, замену хрусталика и несколько других методов. Если вы не читали цикл с самого начала, я очень рекомендую ознакомиться с частями 2 и 4.1, в которых подробно рассматриваются те проблемы, с которыми сталкивается современный офтальмохирург. В этой статье я постараюсь развеять уже поднадоевший страх, связанный с фильмом «Пункт назначения 4» и сошедшим с ума лазером. Также я постараюсь ответить на заданные вопросы читателей, как и обещал.

Предыдущие части

Часть 1. Unboxing VisuMax — фемто-лазера для коррекции зрения
Часть 2. Сколько мегабит/с можно пропустить через зрительный нерв и какое разрешение у сетчатки? Немного теории
Часть 3. Знакомьтесь — лазер по имени Amaris. Переезды и первое пробуждение VisuMax
Часть 4.1 Возвращаем зрение. От очков до эксимерного лазера

Это первая часть статьи, посвященной такому языковому механизму Java как исключения (вторая (checked/unchecked) вот). Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

1. Ключевые слова: try, catch, finally, throw, throws
2. Почему используем System.err, а не System.out
3. Компилятор требует вернуть результат (или требует молчать)
4. Нелокальная передача управления (nonlocal control transfer)
5. try + catch (catch — полиморфен)
6. try + catch + catch + ...
7. try + finally
8. try + catch + finally
9. Вложенные try + catch + finally

1. Ключевые слова: try, catch, finally, throw, throws

Механизм исключительных ситуаций в Java поддерживается пятью ключевыми словами

• try
• catch
• finally
• throw
• throws

«Магия» (т.е. некоторое поведение никак не отраженное в исходном коде и потому неповторяемое пользователем) исключений #1 заключается в том, что catch, throw, throws можно использовать исключительно с java.lang.Throwable или его потомками.

Этот пост был написан спустя год после запуска Google+, и пролежал в черновиках с тех пор ещё два года. Периодически я вспоминал про него, вздрагивая: а вдруг G+ взлетел и пост будет уже не актуален? Но время шло, Google+ всё никак не взлетал, и три года после запуска его соцсети, жизнь кипит в Фейсбуке, Твиттере и Вконтакте. Жизнь кипит и на Ютубе, где без G+ теперь ни лайк не поставишь, ни коммент не оставишь. И только в самом G+ жизни нет. А выводы поста не просто остаются актуальными, а подтверждены практикой. Поэтому просто выкладываю написанный два года текст как есть.

Конечно, понятие неуспеха относительно. В Google+ есть большое количество пользователей, бренды считают обязательным в свой «соцпакет» к представительствам в Фейсбуке и Вконтакте добавлять и G+. И тем не менее Google+ — это провал.

Некоторое время назад Google заявил, что планирует отменить возможность устанавливать расширения для Chrome, которые не находятся в Web Store.

Конец очередной недели и новая подборка полезной информации из мира мобильной разработки. Компания JetBrains выпустила AppCode 3.0, разработчики рассказали, как НЕ заработать миллион на приложении, Samsung объявил конкурс приложений для своих умных часов с призовым фондом в $1,250,000, Epic Games выпустила клон Flappy Bird на Unreal Engine – всего интересного и не перечесть.

История: Эта статья впервые появилась в журнале Better Software в марте 2006. Она была переведена на несколько языков.

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

Чем больше я пользовался TDD, тем больше я понимал, что не столько оттачиваю своё мастерство, достигая новых его вершин, сколько то, что это было движение в слепую. Я помню, как мне все чаще приходила мысль: «Эх, вот бы мне кто-нибудь сказал это раньше!», чем мысль: «Отлично, дорога ясна». Я решил, что нужно найти способ обучать TDD, показывающий, как верно работать с ним сразу и без ошибок.

И этот способ — это программирование через поведение. Оно выросло из выработанных agile практик и призвано сделать их доступнее и эффективнее для команд, незнакомых с ними. Со временем, BDD стало включать в себя agile анализ и автоматическое приемочное (прим. acceptance) тестирование.

Добрый день, Хабр!

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

Microsoft Research в своем блоге анонсировала запуск браузерной игры-головоломки Code Hunt по обучению программированию на C# и Java.
Игроку даются фрагменты кода с заранее неизвестной функциональностью. Цель игры заключается в том, чтобы на основе входных данных и ожидаемого результата, изменить код метода или функции так, чтобы выходные данные соответствовали этому ожидаемому результату.

В последнее время мои коллеги начинают знакомство с git'ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git'а без понимания может привести к потере истории разработки.

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

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

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

Ошибка #1 — Идея

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

Вывод: в следующий раз сначала очень серьезный анализ рынка, потом поиск людей готовых купить идею, и только потом продукт.

В течение последнего года я мало писал, так как был занят разработкой нового средства для ведения дискуссий. Если вы, вслед за моими инвесторами, хотите знать, почему это заняло целый год, мне стоит объяснить, как именно я делаю программы, или, как минимум, как мы сделали Stack Overflow, Stack Exchange и, теперь, Discourse:

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

2. На основании исследования соберите команду и сделайте минимально жизнеспособный продукт, который будет делать что-то полезное. Если вам нужно начальное финансирование, самое время найти его — надеюсь вы выполнили все указанное в шаге 1 очень хорошо и возможно еще и знамениты, а в идеале еще и успешны, в противном случае вы в заднице.

3. Начните использовать этот продукт вместе со всей командой, каждый день, весь день. Это не просто разработка: это вся ваша жизнь. Если вы не живете разрабатываемой программой каждый день, целый день… проект неизбежно ждет плачевный исход. И, честно говоря, если мне приходится вам это объяснять, то знаете что? Вы в заднице.