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

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

Такое время

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

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

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

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

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

Все началось с того, что на глаза случайно попался конкурс от NextCastle Party, где предлагалось в строго ограниченные сроки (тема была объявлена за неделю) создать игру.

Условием была обязательная возможность играть с живыми игроками за одним компьютером (не важно, pvp или кооператив, синхрон или асинхрон). А так же были ограничения по платформам — необходимо, чтобы игра шла в браузере.

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

Искал в гугле «солнечная панель 100 Вт» и в первом десятке выдается ссылка на Хабрахабр, статья от 2011 года. В комментариях правильные вещи, но актуальностью на сегодняшний день — бред. Сегодня солнечная панель 100 Вт (на Украине) стоит до 100 долларов, контроллеры, аккумуляторы — все это не очень напряжно. Но самая большая загвоздка зеленого прогресса в том, что люди просто не понимают, что такое солнечная энергия, как правильно и по уму все реализовать, зачем это надо и вообще…

Не в рекламных целях. Я торгую на рынке солнечными панелями и 90 человек из 100 отталкивают это новшество, как отталкивали мобильники 15 лет назад — дорого, не нужно, не выгодно, и так хорошо. Многие хотят набрать панелей по 100 долларов на 10 килоВатт и не платить за электроэнергию. Сами посчитайте — 100 Вт х10 = 1кВт * 10 = 10 кВт = 10 000 долларов. Это только на панели, без аккумуляторов и контроллеров. Аккумуляторов на час работы нагрузки в 10 кВт надо еще 12-13 шт по 100 А/ч (еще по 200 долларов каждый) и т.д. В итоге, смотрят на продавца как на идиота, выбрасывают из головы все, что им рассказываешь и в этой самой голове остается одно: «мне это не интересно». На самом деле все обстоит немного иначе.

Зачем созданы солнечные панели? В чем смысл жизни человека? Почему мы дышим грязным воздухом? Спаси планету, освободите Вилли!

На эти вопросы может быть множество ответов, постараюсь изложить более-менее понятно как это вижу я.

В 1975м году, ПК IBM 5100 выпускалась в вариантах с языками программирования BASIC или APL. Как можно догадаться, что в итоге основной упор был сделан на интерпретатор BASIC'а по причине того, что при принятии решения о том, что покупать, пользователям данного ПК он казался более понятным, а APL требовал какого-то минимального уровня вхождения. Говорят, что что APL потерял популярность из-за не ascii-символов, может это отчасти и так, но произошло это не в 75м.

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

до 5й минуты простая математика.

Инфраструктура .Net содержит встроенные средства генерирования кода (On-the-Fly Code Generation). Это позволяет .Net-программе в момент своего исполнения самостоятельно (без участия программиста) скомпилировать текст, написанный на каком-либо языке программирования и исполнить получившийся код. Логично было бы ожидать, что для осуществления этих действий в стандартной .Net-библиотеке предусмотрен простейший метод соответствующего класса. Но к сожалению это не так. Microsoft, проделав огромный путь по встраиванию в среду .Net средств генерирования кода, не сделала самый последний шаг навстречу простейшим потребностям программистов. Значит, придётся сделать этот шаг самостоятельно.

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

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

А что у нас? Помимо повторяемых из года в год слов о необходимости создания в стране международного финансового центра, казалось бы, особенных телодвижений в этой области не происходит. С одной стороны – это так, с другой же – отечественный фондовый рынок значительно интереснее, чем об этом принято думать. И интересен он, в первую очередь, с технологической точки зрения.

UPD: игра вышла.

Привет!

Тут такая история. Я заметил, что в какой-то момент стал отмечать для себя важные вещи для развития ребёнка. Например, у меня в детстве был сначала модульный конструктор с мотором, колёсами, батарейками и так далее, а потом – модульный же радиоконструктор. Эти два предмета очень сильно повлияли на то, чем я потом интересовался в будущем.

Ещё пример – в детстве надо обязательно сходить в политехнический и археологический музеи Москвы. Или, например, запомнились такие штуки: первая хорошая НФ, подаренная в 8 лет; дед, научивший меня чертёжному почерку за 15 минут; шахматы каждые выходные; огромная коробка Лего и так далее. И таких событий – тысячи.

У меня просьба. Давайте накидаем важные и интересные вещи, которые можно и нужно сделать с ребёнком до примерно 10 лет. Наверняка ведь у вас есть такие «чекпоинты», которые запомнились.

Здравствуйте! Сегодня мы будем писать платформер, используя C++, Box2D и SFML, а также редактор 2D карт для игр Tiled Map Editor.



Вот результат (карта создавалась 5 минут + во время сьемки игра тормозила + экран не так растянут — дефект Bandicam):



Исходники и exe — внизу статьи.

Статья родилась из того, что мне потребовался удобный и простой механизм перехвата для некоторых задач, который легко реализуется техниками АОП. Существует довольно много перехватчиков (Casle.net, Spring.net, LinFu и т.д.), требующих внедрять динамические дочерние классы в IL-код во время исполнения и приводящих практически всегда к одним и тем же ограничениям, накладываемым на перехватываемые классы: не статические, не запечатанные, методы и свойства должны быть виртуальными и т.д…

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

Привет, Хабр!

Мы рады поделиться отличной новостью для разработчиков приложений!

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

НИУ ВШЭ, МФТИ и СПбГУ стали партнерами Coursera, курсы будут запущены на английском и русских языках.

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

Zephir — Ze(nd Engine) Ph(p) I(nt)r(mediate). Зефир — это компилируемый высокоуровневый язык программирования, предназначенный для написания PHP расширений без использования C. Проект от создателей Phalcon (скомпилированный PHP MVC Framework). О Zephir на Sitepoint
   

JSDB.IO — большая и качественная база нужных скриптов/библиотек/фреймворков на JavaScript. Все распределено по категориям: Animation, Application, Audio, Video, Games и др. Дабы собрать все популярные .js воедино добавлю еще три ссылки: Microjs (множество маленьких полезностей до 5кб), а еще jsdelivr и cdnjs, которые позволяют добавлять собственные скрипты.

Snap.svg — продукт от Adobe Webplatform. Недавно я рассказывал про "достойного конкурента Raphaël" и в комментариях оспоривали эту фразу из за отсутствия поддержки такого же множества браузеров. В разработке Snap участвует автор Raphaël — Дмитрий Барановский, а причина создания новой библиотеки для работы с SVG — невозможность поддерживать все возможности SVG в старых браузерах.

At.js — очень юзабельный скрипт для автозаполнения (в демо используется Emojify). А еще есть более функциональная библиотека для автозаполнения — Typehead от Twitter.

$('.atwho-inputor').atwho({
  at: "@", data: ["one", "two", "three"],
});

Так получилось, что у меня в руках оказался мертвый ноутбук HP 625 с матрицей 15.6” и контроллер LCD панели NTA92C VGA/DVI.Тратится на восстановление ноутбука желания не было никакого, так что решено было слепить из вышеуказанных деталей второй монитор, да так, чтобы с креплением к VESA обычного монитора. С минимальными для меня временными и финансовыми затратами в рамках «проекта выходного дня».

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

Hello World,

Helios Kernel — это библиотека для управления зависимостями между javascript-модуями, реализующая «классический» подход, часто встречаемый в других языках и средах — с помощью функции include().

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

Helios Kernel придерживается принципа KISS, поэтому здесь отсутствуют некоторые возможности, которые сегодня принято ожидать от библиотеки по управлению зависимостями. При использовании Helios Kernel не нужно описывать конфиг с правилами поиска путей для разных модулей, или экспортировать библиотечные функци через специальный объект. Но эта библиотека была написана как раз потому, что хотелось просто подключать нужные модули и писать код, не натыкаясь на крутые возможности при указании каждой новой зависимости.

Helios Kernel поддерживает динамическую загрузку (и выгрузку) зависимостей в рантайме, а сама библиотека и формат модулей являются совместимыми между nodejs и броузерной средой — то есть модули можно использовать без изменений или трансляции.

В этой статье классический подход реализованный в Helios Kernel сравнивается с управлением зависимостями с помощью RequireJS и показывается, каким образом подход Helios Kernel позволяет избежать некоторых сложностей.

Доброго времени суток, хабравчане. Хочу поделиться с вами ответом Дэна Сэйфера c Quora на вопрос об основных принципах натурального пользовательского интерфейса и очень полезным сайтом Design Principles FTW.

Основные принципы NUI дизайна

1. Дизайн для пальцев, не для курсора
Сенсорные элементы должны быть больше десктопных: 10-14 мм для пальцев, 8-10 для курсора.

2. Помните о физиологии и кинезиологии
Не заставляйте пользователей масштабировать и совершать повторные действия.

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

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

5. Знайте технологии
Понимание возможностей сенсора или камеры позволяет определить какие жесты вы можете спроектировать.

От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

Всем жителям Хабра — привет!

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

Постановка задачи

Интернет – штука полезная и нужная, с этим, думаю, поспорить сложно. И если проблем в городе с интернетом нет, то в деревне, где мне часто приходиться по семейным обстоятельствам бывать, есть определенные проблемы. Есть частный деревянный дом а-ля «хата» (место действия: РБ), из интернета в моей окрестности доступ предоставляют 3 оператора, но максимум – это лишь технология EDGE. До двух ближайших базовых станций (БС) около 3.5 и 7 км. Между домом и БС лес, но не вплотную. Хватило бы и EDGE, но загрузка этих станций от других соседних деревень, судя по скорости, такая, что можно «прятаться в картошку».
Вариант покупать готовое решение отпал сразу из соображений спортивного интереса.
Вдохновившись на одном из форумов удачным опытом парней, где использовалась спутниковая тарелка (она же «офсетная зеркальная антенна») и сам 3G модем в фокусе, решил что-то подобное смоделировать да скрутить.
Сразу скажу, что антенну с модемом хотелось закинуть на чердак, дабы не портила внешний вид дома (об этом ниже).