Введение

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

• Измерение электроэнергии.
• Качество электроэнергии.
• Устройства измерения параметров электроэнергии.

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

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

Подкатом вы найдете ответы на первые два вопроса данного списка. Я намеренно не затрагиваю вопросы точности измерения показателей и с данной серии лишь радуюсь полученным результатам с точностью плюс-минус лапоть. Этому вопросу я обязательно посвящу отдельную статью в третьей серии.

Эти и другие компании говорят, что эрозия приватности неизбежна — но они сами работают над этим.

В январе исполнительный директор Facebook Марк Цукерберг объявил конец эпохи приватности. Через месяц глава Google Эрик Шмидт выразил похожее мнение. Добавьте сюда комментарии Скотта Макнили и Ларри Эллисона многолетней давности, и вы увидите кучу технических CEO, провозглашающих исчезновение приватности, особенно в отношении молодых людей.

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

Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.

1. Быстрая реакция и ответы

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

К сожалению быстрый саппорт, доступный 24/7, это дорого: нужно больше людей и нужна круглосуточно доступная инфраструктура. Чаще всего это просто невыгодно, особенно если вы не крупная корпорация, а маленький стартапчик.

В этом случае нам поможет одна интересная штука.

По просьбам трудящихся пишу статью про Spring IoC. Я не настолько гуру в этом вопросе, впрочем могу кое-что поведать.

Вступление

Доброго времени суток. Не растягивая вступление, сразу перейду к делу. Итак, Android на Windows Mobile.
Еще в недалеком прошлом факт использования устройства, изначально предназначенного для работы с ОС Windows Mobile, под управлением ОС Android вызывал ассоциации с глючностью, нестабильностью и совершенной невозможностью использовать устройство, кроме как для «посмотреть, а что там есть».
Но время идет, и развитие платформы Android бежит вперед семимильными шагами. Всё больше приверженцев Windows Mobile хотят попробовать и «потрогать» Android на своем устройстве. Радует вдвойне, что среди них находятся те, кто готов взяться за нелегкое дело портирования Android на свои любимые коммуникаторы с WM.
Итак, все кого заинтересовала возможность посмотреть на что способны современные сборки Android на коммуникаторах WM, прошу под кат

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

Все знакомы с css параметром border, но есть ли вещи, которые мы не знаем о нем?

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

Нашел как-то на stack overflow вопрос (link).
Need to create java CLI programm that searchs for specific files matched some pattern. Need to use multi-threading approach without using util.concurrent package and to provide good performance on parallel controllers.
Перевод
Нужно написать консольную программу, которая ищет файлы по какому-то паттерну. Программа должна быть многопоточная, но нельзя использовать пакет util.concurrent. Требуется добиться максимальной производительности.


В общем идея в принципе была не сложная. Т.к. по условию нельзя использовать util.concurrent, то надо реализовать свой пул потоков, плюс написать какие-то таски, которые в этом пуле потоков будут крутиться.
Так же я не был уверен в том, что при многопоточном использовании IO будет увеличение производительности.

Дорогой Хабр!



У нас для тебя небольшой подарок. Мы тут работали-работали и вот чего сделали.
Сняли и опубликовали почти тысячу лекций по IT и математике.

UPD2 Помогите, пожалуйста, оперативно решить вопрос насчёт организации торрентов на php.

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

Прежде всего Hibernate cache — это 3 уровня кеширования:

• Кеш первого уровня (First-level cache);
• Кеш второго уровня (Second-level cache);
• Кеш запросов (Query cache);

Кеш первого уровня

Кеш первого уровня всегда привязан к объекту сессии. Hibernate всегда по умолчанию использует этот кеш и его нельзя отключить. Давайте сразу рассмотрим следующий код:

SharedDoc persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user1.setDoc(persistedDoc);

persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user2.setDoc(persistedDoc);

Возможно, Вы ожидаете, что будет выполнено 2 запроса в БД? Это не так. В этом примере будет выполнен 1 запрос в базу, несмотря на то, что делается 2 вызова load(), так как эти вызовы происходят в контексте одной сессии. Во время второй попытки загрузить план с тем же идентификатором будет использован кеш сессии.
Один важный момент — при использовании метода load() Hibernate не выгружает из БД данные до тех пор пока они не потребуются. Иными словами — в момент, когда осуществляется первый вызов load, мы получаем прокси объект или сами данные в случае, если данные уже были в кеше сессии. Поэтому в коде присутствует getName() чтобы 100% вытянуть данные из БД. Тут также открывается прекрасная возможность для потенциальной оптимизации. В случае прокси объекта мы можем связать два объекта не делая запрос в базу, в отличии от метода get(). При использовании методов save(), update(), saveOrUpdate(), load(), get(), list(), iterate(), scroll() всегда будет задействован кеш первого уровня. Собственно, тут нечего больше добавить.

На Хабрахабре очень мало статей о SWT, поэтому я постараюсь исправить данное маленькое упущение.

Из данной статьи Вы узнаете:

• Какова мотивация использовать SWT в отличии от основного конкурента — Swing
• Основные трудности с которыми я столкнулся при разработке простенького блокнота на связке Java + SWT и Немного кода
• Каким образом упаковать и распространить свое приложение для нескольких платформ

Если Вас заинтересовало — прошу под кат.

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

Вот уже подоспела и вторая часть статьи.


1. Нестатические блоки инициализации.

Всем, я думаю, известно, что в Java существуют статические блоки инициализации (class initializers), код которых выполняется при первой загрузке класса.

class Foo {
	static List<Character> abc;
	static {
		abc = new LinkedList<Character>();
		for (char c = 'A'; c <= 'Z'; ++c) {
			abc.add( c );
		}
	}
}

Но существуют также и нестатические блоки инициализации (instance initializers). Они позволяют проводить инициализацию объектов вне зависимости от того, какой конструктор был вызван или, например, вести журналирование:

class Bar {
	{
		System.out.println("Bar: новый экземпляр");
	}
}

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

Map<String, String> map = new HashMap<String, String>() {{
	put("паук",  "арахнид");
	put("птица", "архозавр");
	put("кит",   "зверь");
}};

Очень даже мощное средство, не находите?

JFrame frame = new JFrame() {{
	add(new JPanel() {{
		add(new JLabel("Хабрахабр?") {{
			setBackground(Color.BLACK);
			setForeground(Color.WHITE);
		}});

		add(new JButton("Торт!") {{
			addActionListener(new ActionListener() {
				public void actionPerformed(ActionEvent event) {
					System.out.println("Хабрахабр - торт!");
				}
			});
		}});
	}});
}};

Остальные четыре пункта под катом.

Данный пост является началом серии статей про оптимизацию и улучшение производительности GWT-приложений. Поскольку материала у меня накопилось достаточно много, решил разбить его на 2-3 части.
Приступим к описанию того, что нас ждёт в первой статье.

Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

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

“C++11 feels like a new language.” – Bjarne Stroustrup

Не так давно Герб Саттер открыл на своём сайте новую страничку — Elements of Modern C++ Style, где он описывает преимущества нового стандарта и то, как они повлияют на код.

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

Уточнение

Так как Sun'a больше нет, то и экзамена SCJP тоже нет. Теперь он значится так:
1Z0-851 Java Standard Edition 6 Programmer Certified Professional Exam.

Тут приспичило мне периодически запускать некоторый код в небольшом проектике написанном на Spring Framework. Я уж было приготовился по старой памяти (еще со спринга 2.x) к долгому прикручиванию quartz-а и написании кучи конфигов на xml, как оказалось все значительно проще

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

Что представляет из себя этот паттерн?

Исходя из названия легко догадаться, что это некая, определенная, фабрика (или завод), который создает объекты. Еще раз выражу слово определенная. Как и в реальной жизни фабрика имеет некую специализацию, создавая товары или устройства какого-либо определенного типа. И фабрика, которая выпускает, например, мебель, не может производить, например, еще и компоненты для смартфонов. По аналогии с программированием фабрика объектов может создавать только объекты определенного типа, которые используют единый интерфейс. Самыми главными преимуществами данного паттерна в С++, является упрощение создания объектов различных классов, использующих единый интерфейс. Зачастую библиотекам, которые разрабатывают программисты нужно не только уметь работать с определенными объектами, но и создавать их. Самый очевидный пример загрузка файлов различных форматов. Мы не знаем, какой файл мы будем загружать заранее, но у нас есть список возможных форматов. Пользователь указывает файл, библиотека пытается определить тип файла и вызвать соответствующий загрузчик для него. В большинстве случаев программисты использует конструкции типа switch или if, чтобы определить экземпляр какого класса им необходимо создать. И чем больше возможных вариантов появляется, тем больше разрастается эта конструкция, в последствии превращающиеся в уродливого монстра.

Что нам может предложить фабрика объектов?
Во-первых, простой метод создания объектов, который сократит switch/if до 1ой строчки.
Во-вторых, удобные методы для работы с объектами фабрики. Мы всегда точно можем узнать, зарегистрирован ли у нее определенный класс, количество зарегистрированных классов, а так же удобные методы для добавления и удаления экземпляров классов в фабрику. С помощью фабрики можно ограничивать набор возможных классов, которая она будет создавать, используя некую конфигурацию.