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

Первые бытовые светодиодные лампы под стандартные цоколи E27 и E14 имели много недостатков: некомфортный цвет освещения, низкий индекс цветопередачи (CRI), приводящий к неправильному восприятию цветов окружающих предметов, пульсация (мерцание) света, невозможность работы с выключателями, имеющими индикатор и регуляторами яркости (диммерами), направленность света (у большинства ламп первого поколения светодиоды располагаются на плоской плате, перед которой размещён плафон, поэтому лампа совсем не светит назад), не очень высокая эффективность (50-70 Лм/Вт).

Чуть больше года назад появились первые лампы нового поколения на светодиодных нитях (filament). Впервые я увидел их в ноябре 2013 года на выставке Interlight. Тогда их показывали лишь неизвестные китайские производители. Сейчас лампы на светодиодных нитях появились в ассортименте больших брендов. Компания Thomson предложила мне протестировать два типа ламп — 4-ваттную «свечку» с цоколем E14 и 6-ваттную лампу с цоколем Е27.



Первая лампочка заменяет обычную 40-ваттную лампу, вторая — 60-ваттную.

Привет! Мы выпустили IDE для работы с базами данных.

Полтора года мы делали 0xDBE по программе раннего доступа (EAP). Пора подвести черту под нашей работой. Мы благодарим всех, кто пробовал 0xDBE на своих проектах и писал нам — вы очень помогли. По этому названию мы тоже будем скучать.

Теперь IDE называется DataGrip.



Поддерживаемые СУБД

DataGrip это универсальная IDE для работы с MySQL, PostgreSQL, Oracle, SQL Server, Sybase, DB2, SQLite, HyperSQL, Apache Derby и H2.

Работа с объектами БД и генерация кода

DataGrip предоставляет инструменты для работы с объектами базы данных. Если вы создаёте или изменяете таблицу, добавляете или изменяете колонку, индекс, ключ в уже существующей, используйте графический интерфейс. Подобные изменения сопровождаются генерацией соответствующего скрипта — вы можете сразу выполнить сделанные изменения в базе или скопировать сгенерированный DDL-запрос в редактор и работать уже непосредственно с кодом.

Под катом хочу рассказать про вывод на печать PDF фалов под .NET. С уклоном на печать из разных лотков принтера. Это бывает полезно, когда нужно распечатать документы, состоящие из разных типов бумаги разложенных по лоткам принтера.

Не встречали еще разработчика, который вместо стандартной в скриптовом языке функции деления строки по регулярке — пишет C-подобный код с конечным автоматом, который вводит неокрепшие умы в трепет?

И так ужасно ли то, что ты не знаешь в тонкостях работу красно-черных деревьев или путаешь линейный дискриминантный анализ с вторым законом Ньютона?

Думаю, многие из вас знают, что сейчас существует обилие различных языков (или инструментов), которые позволяют писать код компилируемый в JavaScript. Это CoffeeScript, Dart, GorillaScript и другие (довольно большой список можно найти здесь). Недавно я решил познакомиться с одним из представителей этого списка — языком программирования под названием TypeScript.

Я расскажу о личном опыте — почему решил попробовать именно его, как начать работать с ним, и какие выводы сделал, поработав с ним несколько дней.

Если вам это интересно — пожалуйста, заходите под кат.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Я часто собеседую разработчиков и часто задаю им простой, как кувалда, вопрос — как внутри работает JOIN в SQL? В ответ я обычно слышу бессвязное мычание про волшебные деревья и индексы, которые быстрее. Когда-то мне казалось, что каждый программист специалист должен знать то, с чем работает. Впоследствии жизнь объяснила мне, что это не так. Но мне все еще не понятно, как можно годами теребить базёнку, даже не догадываясь, а что там у нее «под капотом»?

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

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

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

В статье мы попытаемся проследить, как из-за разницы в одном архитектурном решении логически следует совершенно разная идеология работы в запросами в двух СУБД.

Приведенные примеры (которые выполнялись на версиях Oracle 11.2 XE и PostgreSQL 9.4) содержат время выполнения запросов. Нас интересуют только относительные величины: во сколько раз изменилось время выполнения после внесения в запрос тех или иных изменений. При этом абсолютные цифры могут отличаться на порядки в зависимости от аппаратуры, нагрузки и настроек. Чтобы не давать повод для бессмысленных выводов на их основании, все абсолютные значения в статье отмасштабированы так, чтобы один из запросов составлял в обеих системах 10 секунд.

Описание предметной области (создание ее онтологии) начинается с выделения объектов и их классификации, которая традиционно заключается в составлении дерева классов-подклассов и  приписывании к ним индивидов. При этом термин «класс», по сути, используется в значении «множество»:  отнесение объекта к классу мыслится как включение его в качестве элемента в соответствующее множество. Цель этого текста показать, что такой унифицированный подход к описанию структуры предметной области является сильным упрощением и не позволяет зафиксировать разнообразие семантических отношений объектов.

Неделю назад я рассказал о свтетодиодных лампах из магазина Ашан. Напомню, я купил 48 ламп в Ашане и Леруа, протестировал их и вернул обратно в магазины.

Сегодня расскажу о 26 лампах из Леруа Мерлен.

Прошло уже некоторое время, как я впервые познакомился и подружился с TypeScript. В те времена версия еще не перевалила за единицу. А недавно вышел релиз 1.7. За это время мы привыкли друг к другу и пережили много успехов и разочарований. Мне хочется немного поделиться своими впечатлениями и размышлениями по поводу этого диалекта JavaScript как самостоятельного языка. Идея подобного поста возникла у меня спонтанно при обсуждении очередного холивара с коллегами.

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

В ходе подготовки спецкурса «Scala for Java Developers» под платформу онлайн-обучения UDEMY, я анализирую другие «лекционные» видео. В библиотеке накопилось какое-то количество ссылок на дельных учебные материалы по Scala (видео на английском).

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

• General
• Odersky about Scala
• Play
• Akka
• Spray
• Spark
• Slick (DB)
• SBT
• Scalaz
• Shapeless
• Spire (generic numeric programming)
• Functional/Reactive Programming

«Не звони и не пиши мне больше!!!!» — пришла смс-ка от моей девушки Кати. Через пару часов я осознал, что теперь у меня появилась куча свободного времени и я решил переписать Dcoin на Go.

Хранение документов в Postgres немного проще, теперь у нас есть серьезные процедуры сохранения, возможность запускать полнотекстовый поиск, и некоторые простые процедуры поиска и фильтрации.

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

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

Есть некоторые тонкости в написании такой Scala.js библиотеки, но они покажутся знакомыми для JS разработчиков. В этой статей мы создадим простую Scala.js библиотеку (код) для работы с Github API и сосредоточимся на идиоматичности JS API.

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

Вряд ли у вас получится написать ее с чистого листа с помощью Scala.js, но можно написать библиотеку для взаимодействия между вами и фронтенд разработчиками, которая позволит:

• спрятать сложную или неочевидную клиентсайд логику в ней и предоставить удобное API;
• в библиотеке вы сможете работать с моделями из backend приложения;
• изоморфный код из коробки и можете забыть про проблемы синхронизации протоколов;
• у вас будет публичный API для разработчиков, как у Facebook’s Parse.

Также это отличный выбор для разработки Javascript API SDK, благодаря всем этим преимуществам.

Недавно я столкнулся с тем что у нашего REST JSON API два разных браузерных клиента, поэтому разработка изоморфной библиотеки была хорошим выбором.

Сегодня многие системы и языки программирования позиционируются как «мощные». Нельзя сказать, что это плохо. Почти каждый из нас считает это положительным свойством. Но в этом посте я хочу донести такую точку зрения, что во многих случаях нам нужны менее мощные языки программирования и системы. Но прежде чем продолжить, уточню: здесь будет мало оригинальных, моих собственных размышлений. Я буду излагать ход мыслей, возникший по прочтении книги Дугласа Хофштадтера «Гёдель, Эшер, Бах», которая помогла мне собрать воедино разрозненные идеи и мысли, бродившие в голове. Также большое влияние на нижеизложенный материал оказали пост Филипа Вадлера и видеозапись с конференции Scala. Ключевая мысль такова:

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

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

В этой статье хотелось бы поделиться одним из способов простого и удобного интеграционного тестирования http-сервиса, написанного на Go. Интеграционные тесты бывает непросто создавать так, чтобы обходиться без сложных скриптов, но на помощь нам придет Docker, пакет из стандартной библиотеки httptest и билд-теги. Для примера мы будем использовать MySQL базу данных с миграциями, управляемыми пакетом goose. Финальной целью является получить простое и удобное кроссплатформенное интеграционное тестирование простым запуском команды go test, будь это рабочий ноутбук или Continuous Integration сервер.

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

Кому это будет интересно?

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

Вот и состоялся релиз Java 8. Кто-то по-настоящему ждал её и тестировал предрелизную версию, считая недели до марта, для кого-то смена цифры в версии JDK была лишь поводом пару раз поиграть с обновленным языком в домашней IDE без отрыва от работы (ввод языка в production всегда занимает некоторое время), кто-то просто не нуждается в новых фичах, им и возможностей «семерки» хватает с лихвой. Тем не менее, восьмую Java ждать стоило — и не просто ждать, но и внимательно присмотреться к некоторым ее нововведениям, ведь в этой версии их действительно немало, и если ознакомиться с ними поближе, то не исключено, что хорошо знакомый язык предстанет перед вами в совершенно новом свете, порадовав возможностью писать еще более красивый и лаконичный код. И если уж говорить про новые возможности Java 8, было бы странно не начать с лямбда-выражений.