Я любитель послушать музыку в дороге и на работе, при этом накопил немалую коллекцию музыки в lossless на домашнем компьютере. Хочется иметь доступ к музыке не только дома но и на смартфоне. Ограниченная память не позволяет уместить всю мою коллекцию, какими бы картами памяти я ее не расширял. Да и не хочется память на это тратить, ведь есть еще множество вещей которые туда хочется записать. Раньше я старался успеть перед выходом на работу собрать все, что хочется сегодня послушать, переконвертировать это в сжатый формат (я считаю lossless на мобильном устройстве это излишки) и записать на мобильное устройство. Но как всегда не успевал, и зачастую приходилось довольствоваться старым заезженным плейлистом. Потом у меня появился безлимитный мобильный интернет и я совсем забросил «перекидывание» музыки, стал слушать интернет радиостанции. Приходилось постоянно прыгать между станциями, и еще эти диджеи постоянно вклиниваются. И тут мне пришла идея сделать свой персональный стрим, с блекджеком и… всеми вытекающими.
Решено было установить на домашнем сервере mpd, на смартфоне приложение для прослушивания интернет радио и клиент mpc, чтобы на лету выбирать музыку. Если интересно как, прошу под кат.

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Посетителям сайта stackoverflow.com был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

Ниже — вольный перевод самых популярных ответов.

Java существует достаточно долго, на ней написано огромное количество софта и она является лидером в своей области. Однако Java не лишена недостатков. При проектировании языка важным критерием была простота и легкость изучения языка, и эта простота заставляет писать огромное количество лишнего кода, что бы компенсировать недостаточную гибкость языка: паттерны проектирования, XML конфиги, AOP, гетеры-сеттеры, try catch finaly синтаксис и т.д. Так же очевидно что не для всех задач чистый ООП подход является оптимальным, некоторые задачи намного эффективнее выполнять в функциональном стиле.

Существует много разных языков — Groovy, Python, Ruby, JRuby и еще много других, которые потенциально могут заменить java. Так почему же именно Scala?

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

В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#.
В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.

«Год или два, с момента начала работы в Bell Labs, я работал в паре с Кеном Томпсоном над интерактивным графическим языком, разработанным Джерардом Хольцманом (Gerard Holzmann). Я печатал быстрее, поэтому я сидел за клавиатурой, а Кен стоял позади меня. Мы работали быстро, и когда компилятор выдавал ошибку, я рефлективно начинал закапываться в проблему, изучая стек вызовов, вывод программы, запускал отладчик и так далее. Но Кен просто стоял рядом и думал, игнорируя меня и код, который мы только что написали. Вскоре я заметил закономерность: Кен зачастую понимал, в чем проблема, раньше меня и произносил: „Я знаю, что не так“. Обычно он был прав. Я понял, что Кен выстраивал ментальную модель кода и, когда что-то ломалось, это была ошибка в модели. И думая о том, как эта проблема могла возникнуть, он выяснял, в каком месте модель была неверна или где наш код мог неправильно эту модель отразить.

Здравствуйте! Прочитав недавно статью про оконные менеджеры в Linux, мне захотелось рассказать всем о менеджере, который был там упомянут — «awesome».
Это тайлинговый windows manager для unix (linux, freebsd, openbsd, netbsd).

В предыдущем посте я описал, что this в javascript не привязывается к объекту, а зависит от контекста вызова. На практике же часто возникает необходимость в том, чтобы this внутри функции всегда ссылался на конкретный объект.
В данной статье мы рассмотрим два подхода для решения данной задачи.
1. jQuery.proxy — подход с использованием популярной библиотеки jQuery
2. Function.prototype.bind — подход, добавленный в JavaScript 1.8.5. Рассмотрим также его применение для карринга (частичного применения функции) и некоторые тонкости работы, о которых знают единицы.

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

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

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

Привет Хабрачеловеки!

После затяжной паузы, я попробую продолжить визуализировать структуры данных в Java. В предыдущих статьях были замечены: ArrayList, LinkedList, HashMap. Сегодня заглянем внутрь к LinkedHashMap.



Из названия можно догадаться что данная структура является симбиозом связанных списков и хэш-мапов. Действительно, LinkedHashMap расширяет класс HashMap и реализует интерфейс Map, но что же в нем такого от связанных списков? Давайте будем разбираться.

Спустя 7 лет разработки увидела свет первая мажорная версия Warsow. Warsow — это атипичный для OpenSource проект с рядом особенностей, и вот почему:

Пять параметров, по которым aptitude превосходит (по четвертому параметру не уступает) apt:

1. Логичность синтаксиса. И единство управления.
2. Гибкость поиска.
3. Проставление меток пакетов.
4. Разрешение зависимостей.
5. Интерфейс.

Как известно, жесткие диски — штука шаткая. Особенно верно это в малом пользовательском классе, в котором и не мечтают о надежности, скажем, серверного оборудования. Однако отказы милых нашему сердцу железок в самый неподходящий для этого момент могут даже домашнему пользователю доставить очень много неприятных минут, часов или даже дней (об одном таком случае я недавно рассказывал, в резюмирующих строках статьи, к сожалении, не выразить, сколько времени было убито на борьбу с неверным оборудованием). Столкнувшись с задачей максимально быстро выяснить, в какой участок едва живого внешнего жесткого диска емкостью 160 Гб. воткнуть раздел размером хотя бы 10 и быть в нем более-менее уверенным, я с удивлением обнаружил, что, по крайней мере оставаясь верным операционным системам семейства Linux, сделать это существующими средствами не получится. Как пришлось выкручиваться — добро пожаловать под кат.

Уже догадались, о чем будет статья?

Третий год занимаюсь разработкой крупной системы на Java с использованием СУБД PostgreSQL. Система десктопная, клиент-серверная. Опытного Senior-Java-Developer-а у нас нет, поэтому приходится думать самим. Думать, строить, ломать, строить заново, опять ломать…
За время работы накопился некоторый опыт как по организации непосредственно работы с БД, так и по взаимоувязыванию этих платформ, о котором и хочу рассказать в этой статье.

Опишу выборочно некоторые вопросы, с которыми мы столкнулись при разработке и которые решили.

Пару месяцев назад я случайно наткнулся на массу положительных отзывов о текстовом редакторе Sublime Text 2. Попробовав его в деле, я не разочаровался. Теперь это мой основной рабочий инструмент.

Sublime Text 2 — это платный текстовый редактор, написанный на C++, который:

• Работает в Linux, OS X и Windows
• Обладает приличной скоростью работы
• Приятным интерфейсом (включая всевозможные анимации)
• Гибко настраиваем (правда, не в GUI, а в json-конфигах)
• Имеет множество плагинов, число которых растёт как на дрожжах
• Поддерживает VIM-режим
• Использует fuzzy-поиск

Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.

Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.

И вот несколько вещей, которые вызывают у меня непонимание.

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

Именованные шаблоны

Многие «проблемы» XSLT связаны с тем, что мы слишком часто пытаемся писать на нём в процедурном стиле. Мы постоянно пытаемся сделать из него Smarty, но упираемся в один простой факт — XSLT является декларативным языком, как бы необычно это для нас не выглядело.
Например, мы пытаемся использовать именованные шаблоны, воспринимая их как процедуры, выводящие данные в определённом формате:

<xsl:template name="CreateItemLink">
    <xsl:param name="item"/>
    <a href="/item/?id={$item/id}">
        <xsl:value-of select="$item/name"/>
    </a><br/>
</xsl:template>

* This source code was highlighted with Source Code Highlighter.

Наверное, многие программисты именно так написали свой первый шаблон. И он неплохо решает свою задачу. Декларативный XSLT предлагает немного другой подход:

<xsl:template match="item">
    <a href="/item/?id={id}">
        <xsl:value-of select="name"/>
    </a><br/>
</xsl:template>

* This source code was highlighted with Source Code Highlighter.

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

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

С некоторых пор мне стали нравиться темные цветовые схемы для текстовых редакторов. Соответственно, мне захотелось окрасить в темные цвета и редактор моего основного рабочего инструмента IDE IntelliJ IDEA. Но после установки темной схемы я увидел, что схема применилась только к редактору, а окраска остальных элементов не изменилась. Например, дерево проекта не перекрасилось.