Описание

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

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

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

Описание

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

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

Начнём с видео, которое демонстрирует работу устройства:

Введение

Каких только замков ни придумали! И с хитрым ключом, и на комбинации цифр, и с распознанием частей тела. Однако, мне захотелось сделать замок, который я ещё не встречал. Поскольку я увлекаюсь игрой на пианино, за идеей далеко ходить не пришлось: было решено сделать шкатулку, которая открывается, лишь «услышав» знакомую мелодию.

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

Введение

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

Пост содержит фотографии, видео и схемы.

Введение

Мне очень нравится простота некоторых старинных радио: три-четыре станции. Вот – джаз, вот – новости, вот – классика. Ну, а ещё мне нравится мастерить всякие интересные штуки. Поэтому я решил собрать радио, которое будет проигрывать загруженную мною музыку и скачивать подкасты. Более того, хотелось, чтобы вид устройства был в стиле начала XX-ого века.

В этом посте я расскажу про детали проекта: про устройство на базе Android, про IOIO Board и про вырезание по дереву.

Проблема

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

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

Введение

Последние четыре года я живу и работаю программистом в США, в Кремниевой долине. За это время у меня скопились некоторые наблюдения, которыми я бы хотел поделиться. Я сосредоточусь на вопросах инфраструктуры: как там с транспортом, интернетом, дорогами, преступностью, водой, развлечениями и т. п. Я буду рассказывать лишь о том, с чем встретился сам. Надеюсь, этот пост будет интересен специалистам, думающим о работе в долине.

Введение

Однажды я смотрел какой-то старый фильм. Герой воспользовался телефоном: снял трубку, попросил оператора набрать номер друга и стал беседовать. Мне очень понравилась простота, с которой был сделан звонок, и внешний вид телефона. Я решил собрать такой телефон сам. Поднимаешь трубку, говоришь, кому позвонить, голос распознаётся, имя отыскивается в адресной книжке, и совершается VoIP звонок.

В этом посте я расскажу про детали проекта: про устройство на базе Android, про IOIO Board, про вырезание по дереву и по пластику.

О проекте

Я увлечён фотографией. А ещё мне нравится собирать всякую электронную мелочь. Наверное, из-за этого я чувствовал, что просто обязан попробовать сделать скоростной фотоснимок. Эдвард Мейбридж баловался такой фотографией ещё в позапрошлом веке. В этом посте я расскажу об основах скоростной фотосъёмки и о том, как я собирал свой фото-триггер.

Введение

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

Я хочу рассказать о том, как собрать такую штуку дома.

В дороге

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

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

А почему бы и нет?

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

В этом посте я бы хотел рассказать о том, как я делал автоматическую камеру из Lego, как её программировал и что из этого получилось.

Пару недель назад все начали писать о предстоящей майкрософтовской конференции PDC (Professional Developers Conference). В частности, Дуг Рейли написал пост «Кто управляет вашей карьерой?». Многие прочитали и сослались на пост, а некоторые (например, Сэм Джентайл или Роберт Херлбат) даже развили идею в ответных постах.

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

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

Проблема

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

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

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

Хороший код

К хорошему коду много требований: он должен быть оптимальным, у него должны быть юнит-тесты, его должно быть легко переиспользовать, он должен соответствовать код-стандарту компании и духу языка. А ещё его должно быть приятно читать.
Я бы хотел рассказать о правилах, которые помогают мне делать код читаемым.

Основное правило

Я считаю, что читаемым является код, в который можно не вчитываться.
То есть, пары-тройки строк дожно быть достаточно, чтобы сказать, что делает класс или метод. Ещё пары-тройки — чтобы примерно сказать, как он это делает.

Прочие замечания

Я заметил, что есть ещё несколько довольно общих правил, которые делают код симпатичнее.

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

О, коде

Когда я пишу код, мне нравится отдавать себе отчёт о том, что именно я делаю.

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

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

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

Цель охоты — прочитать e-mail адрес и отправить на него сообщение.

Upd. У нас есть перые победители:Horus20 и sdmn! С этими людьми я бы пошел в разведку!

Upd1. tonyzorin абсолютно понял, что значат свечки, дома и чашки! Кудос!

Upd2. Mr. perl_demon так же крут, как и тов. Кнорозов. Ура!

Проблема

Я — параноик. Кода я пишу код, я скрываю все переменные, методы и классы, которые только могу скрыть. Я стараюсь открыть лишь те методы и классы, которые необходимы.

Довольно часто, особенно при написании подсистем, скрыть те или иные методы и классы довольно непросто. Неприятности начинаются, кода подсистема достаточно большая, и для лучшей организации кода необходимо завести несколько под-пакетов.
Например, если есть класс com.system.InternalProperty, который используется и в com.system.persist.PropertyManager, и в com.system.network.PropertyUpdater, то InternalProperty должен быть объявлен public.

В этом посте я постараюсь рассказать о существующих решениях и предложить новую идею.

Мне очень нравится играть в Lego. Нравится собирать роботов и машинки.
А ещё мне очень нравится програмировать. Нравится писать программы и фреймворки.
А не так давно я нашел способ совместить эти два увлечения. Lego Mindstorms — это набор, включающий в себя несколько моторчиков, сенсоров и программируемый модуль, который может считывать информацию с сенсоров и управлять моторчиками.

В этом посте я расскажу больше о Mindstorms и о способах программирования.

Кто тут начальник, а кто — подчинённый?

Не так давно я наткнулся на интересную заметку на improv wiki. Там рассказывалось, как сценическим актёрам наиболее эффективно сыграть «высокую» и «низкую» социальную роль. Короче, как проще всего дать понять зрителю, кто тут начальник, а кто — подчинённый. Мне понравился этот список рекомендаций, поскольку и в жизни мы часто вынуждены либо играть ту или иную роль, либо раскрывать игру других.

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

Статус собеседников

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

Приёмы игры высокого [низкого] статуса