Однажды появилась необходимость собрать все уроки, обучающие материалы (tutorials) с habrahabr и geektimes в одном месте и немного их систематизировать. В этом сборнике обучаек представлены более 100 статей на тему ардуино с пометкой «tutorial», либо содержащие несложные для новичков проекты на ардуино, а также немного видеоуроков по смежным темам. Статьи разделены на 10 тематик по сферам применения собранных устройств. Также хочется напомнить, что весь обучающий материал, опубликованный на habrahabr и geektimes является интерактивным: в любой момент можно задать вопрос автору в комментариях к статье. Как правило авторы на них отвечают. Этот сборник будет дополняться новыми обучайками (tutorials) по мере их публикации.

Всем привет!

Предлагаю гиковский разговор на тему Звездных Войн(ЗВ). Для начала, небольшой q&a, о чем я.

Что это?

Немного фанатских теорий на тему Звездных Войн (кроме очевидного)… Под определённым углом можно избавиться от некоторых сюжетных нестыковок, потерь, при переходе от эпизода к эпизоду, нелепых совпадений и.т.д.

Зачем мне это читать?

Если не любите ЗВ — незачем. В противном случае может быть увидите новые сюжетные линии в знакомой истории. Возможно, вам, как и мне, от этого станет интереснее смотреть фильм, а может вы все это и так заметили, но вам не с кем было об этом поговорить.

Это что фанфик?

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

Спойлеры?

Да, без них — никак, но только из оригинальной и новой трилогии, игры Force Unleashed и немного из мультсериалов «Войны Клонов» и «Повстанцы». Седьмой эпизод, как бы мне этого не хотелось, включать не буду, ещё не все посмотрели.

Расширенная вселенная?

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

Всем привет!

По результатам голосования, будем говорить о Матрице.



Q&A

Что на этот раз?

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

Это про то что Матрица в Матрице?

Не-а. Эта теория мне не нравится, хотя она настолько популярна, что уже на грани канона. Как по мне эта теория ужасна, поскольку с помощью подобного трюка можно объяснить все что угодно(это просто сон). К тому же, не забываем про бритву Оккама, эта теория вводит новые сущности, которые необязательны для объяснения.

Зачем мне это читать

Матрица — это антиутопический киберпанк. Говоря о ней, приходится скатываться во все, что обсуждается на ресурсе: робототехника, ИИ, программирование, энергетика и.т.д.

Спойлеры?

Безусловно, и много. Все относительно трилогии и Аниматрицы. Прочие произведения вроде «Голиаф» или The Matrix Online в данном случае нерелевантны. Первое, поскольку описывает очень странные события(вроде столкновения машин с пришельцами), второе — поскольку является убожеством с точки зрения сюжета, ИМХО. Также есть небольшой спойлер из игры Mass Effect(на самом деле большой).

В первой части статьи мы разработали приложение для работы с github, состоящее из двух экранов, разделенное по слоям с применением паттерна MVP. Мы использовали RxJava для упрощения взаимодействия с сервером и две модели данных для разных слоев. Во второй части мы внедрим Dagger 2, напишем unit тесты, посмотрим на MockWebServer, JaCoCo и Robolectric.

В этой статье мы поговорим о проектировании архитектуры и создании мобильного приложения на основе паттерна MVP с использованием RxJava и Retrofit. Тема получилась довольно большой, поэтому подаваться будет отдельными порциями: в первой мы проектируем и создаем приложение, во второй занимаемся DI с помощью Dagger 2 и пишем тесты unit тесты, в третьей дописываем интеграционные и функциональные тесты, а также размышляем о TDD в реалиях Android разработки.

Добрый день, уважаемые хабраюзеры.

В данной статье я хочу поделиться своим опытом разработки под Android.
Требования к функционалу разрабатываемого продукта породили различные технические задачи, среди которых были как тривиальные, разжеванные во множестве блогов, так и крайне неоднозначные, с неочевидным решением. Я столкнулся с массой вещей, незнакомых мне, как .NET разработчику. Узнал о существовании инструментов, которые значительно упрощают жизнь. Думаю, что каждый начинающий андроидовец проходит похожий путь. Я мог бы сэкономить до трети времени, потраченного на разработку, поиск и эксперименты, имея такую статью.

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

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

Это не правильно!

Сейчас в распоряжении программиста, пишет он на Python, C++, Haskell или Ruby, есть огромное количество различных инструментов, которые он может использовать в повседневной разработке.

Компиляторы, интерпретаторы, отладчики, профилировщики, генераторы документации, системы контроля версий, текстовые редакторы, автоматизаторы сборки, статические анализаторы, эмуляторы и виртуальные машины — все это в нашем распоряжении!

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

Если вам интересно, как улучшить свою продуктивность, начать писать программы лучше, да и просто почитать что-то интересное — добро пожаловать под кат!

Сегодня утро на работе началось с холивара на тему вчерашней статьи: “Вот у iOS уже физический движок есть, а в Android даже камера нормально не работает… Придет заказчик, даст проект портировать с iOS на Android — оценишь его в 120 часов, а заказчик скажет, как так, вот под iOS за 8 часов написали...”. Короче получилось много эмоций на пустом месте.

Поэтому я решил поставить некоторые точки над «и» (такая поговорка в русском языке есть, или только в украинском? :)). Так вот, задача:
— написать прототип Flappy Bird с использованием любого физического движка или фреймворка как можно быстрее.

Хотел сначала по исходникам пройтись, но они получились настолько примитивными, что думаю нету смысла. Для разработки взял фреймворк LibGDX и попытался написать более-менее красивый код (это вечная тема, и каждый ведет идеальный код по своему).

После полутора часов работы и полулитра кефира получился прототип. Эта цифра ничего не говорит, я уверен, что на хабре есть десятки программистов, которые реализуют данную задачу в 2-3 раза быстрее. Так само если iOS-разработчики скажут, что такое могут написать за 20 минут — я поверю.

Доброго времени суток!
Model-View-Presenter — довольно известный шаблон проектирования. С первого взгляда все выглядит просто: есть Модель (Model), которая содержит всю бизнес-логику экрана; Вид/Представление (View), который знает, как отобразить те или иные данные; Представитель (Presenter), который является связующий звеном — реагирует на действия пользователя во View, изменяя Model, и наоборот.
Сложность начинается, когда количество форм в проекте становится более одной.
В данной статье рассматривается:
— немножко теории;
— общие проблемы реализации MVP (а именно Passive View) под Windows Forms;
— особенности реализации переходов между формами и передача параметров, модальные окна;
— использование IoC-контейнера и шаблона Dependency Injection — DI (а именно Сonstructor Injection);
— некоторые особенности тестирования MVP приложения (с использованием NUnit и NSubstitute);
— все это будет происходить на примере мини-проекта и постарается быть наглядным.
В статье затрагивается:
— применение шаблона Адаптер (Adapter);
— простенькая реализация шаблона Контроллер приложения (Application Controller).
Для кого эта статья?
Главным образом для начинающих разработчиков на Windows Forms, которые слышали, но не пробовали, или пробовали, но не получилось. Хотя уверен, что некоторые приемы применимы и для WPF, и даже для веб-разработки.

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

Думаю, практически все представители хабрасообщества понимают, как работает транзистор (да и не только он). Тем не менее, я предлагаю оценить объяснение работы транзистора (а также полупроводников и прочего), представленное пользователем YouTube 1vertiasium. Видео — англоязычное, но объяснение настолько красочное, что и так все понятно.

Мне кажется, если бы такое видео показывали бы в школе, даже самые далекие от учебы, нерадивые ученики, понимали бы что к чему.

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

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