Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации потоков (далее поток = thread).

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).



Синхронизаторы – вспомогательные утилиты для синхронизации потоков, которые дают возможность разработчику регулировать и/или ограничивать работу потоков и предоставляют более высокий уровень абстракции, чем основные примитивы языка (мониторы).

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

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

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Я разрабатываю бесплатную библиотеку StreamEx, которая расширяет стандартное Java 8 Stream API, добавляя туда новые операции, коллекторы и источники стримов. Обычно я не добавляю всё подряд, а всесторонне рассматриваю каждую потенциальную фичу. Например, при добавлении новой промежуточной (intermediate) операции встают такие вопросы:

1. Будет ли она действительно промежуточной, то есть не будет трогать источник до выполнения терминальной операции?
2. Будет ли она ленивой и вытаскивать из источника не больше данных, чем требуется?
3. Сработает ли она на бесконечном стриме? Требует ли она ограниченный объём памяти?
4. Будет ли она хорошо параллелиться?

Минусик по любому из этих пунктов заставляет серьёзно задуматься, добавлять ли такую операцию. Минусик по первому — это сразу нет. Например, у конкурентов в jOOλ есть операция shuffle(), которая выглядит как промежуточная, но на самом деле прямо сразу потребляет весь стрим в список, перемешивает его и создаёт новый стрим. Я такое не уважаю.

Минусики по остальными пунктам не означают сразу нет, потому что есть и стандартные операции, которые их нарушают. Второй пункт нарушает flatMap(), третий — sorted(), четвёртый — всякие limit() и takeWhile() (в JDK-9). Но всё-таки я стараюсь этого избегать. Однако на днях я открыл для себя операцию, которая плохо параллелится и в зависимости от использования может не сработать на бесконечном стриме, но всё же слишком хороша. Через неё удаётся буквально в несколько строчек выразить как практически любую существующую промежуточную операцию, так и кучу несуществующих. Я назвал операцию headTail().

Доброго времени суток, уважаемые хабравчане! Обычно мои подборки ориентированы сугубо на веб-разработку, но этот выпуск охватывает все сферы программирования. Но самое главное, что интересность и полезность каждого материала имеет социальное доказательство, благодаря замечательному сервису Slant.co. Это некий аналог Quora, сфокусированный сугубо на разработчиков.

Коллекция из почти 200 ответов в Slant на вопросы «Какие лучшие...»

В ресторане заиграла почти забытая песня. Вы слушали её в далёком прошлом. Сколько трогательных воспоминаний способны вызвать аккорды и слова… Вы отчаянно хотите послушать эту песню снова, но вот её название напрочь вылетело из головы! Как быть? К счастью, в нашем фантастическом высокотехнологичном мире есть ответ на этот вопрос.

У вас в кармане лежит смартфон, на котором установлена программа для распознавания музыкальных произведений. Эта программа – ваш спаситель. Для того чтобы узнать название песни, не придётся ходить из угла в угол в попытках выудить из собственной памяти заветную строчку. И ведь не факт, что это получится. Программа, если дать ей «послушать» музыку, тут же сообщит название композиции. После этого можно будет слушать милые сердцу звуки снова и снова. До тех пор, пока они не станут с вами единым целым, или – до тех пор, пока вам всё это не надоест.

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

Как же всё это работает?

Из опыта code-review и ответов на StackOverflow набралось немало моментов, касающихся Java Collections API, которые мне казались очевидными, но другие разработчики о них почему-то не знали или знали, но не чувствовали уверенности их применять. В этой статье я собираю в общую кучу всё, что накопилось.

Содержание:

1. List.subList
2. PriorityQueue
3. EnumSet и EnumMap
4. Set.add(E) и Set.remove(E) возвращают булево значение
5. Map.put(K, V), Map.remove(K), List.set(idx, E), List.remove(idx) возвращают предыдущий элемент
6. Map.keySet() и Map.values()
7. Arrays.asList может быть ключом
8. Collections.max
9. LinkedList, Stack, Vector, Hashtable

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

Пару месяцев назад я взяла на себя обязательство по самопросвещению. Есть в иных конторах такая тема — сотрудника, раз в полгода ревьюят и говорят «давай к следующему ревью ты изучишь Spring, паттерны (какие?) и функциональное программирование!» Идея была бы неплоха если бы цели не ставили так размыто. Пропустим пока спринг и паттерны — на выходных я бросилась в атаку на ФП.

Общие-туманные сведения о ФП у меня конечно были — анонимные классы в Java я писать умею — с похожими способностями Python и JavaScript знакома.

Начну с простых упражнений на Scala — решила я. Выбрала Scala поскольку основной рабочий инструмент у нас Java — ну были еще варианты Clojure, Groovy и Java8 (что-то еще?) — но с ними авось попробую потом.

Поставила себе цели (а правильно ли я ФП поняла?):

• Решать задачи в функциональном стиле
• Т.е. по возможности не использовать явных циклов и ветвлений
• А также избегать мутабельных коллекций и т.п.

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

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

В процессе изучения языка мы обычно пользуемся ПК для работы с соответствующими приложениями, средами, программами, читаем книги, используем массовые онлайн курсы. Сейчас, когда смартфоны с нами всегда и везде, грех не воспользоваться их возможностями для усвоения знаний по программированию или их усовершенствования.В процессе изучения языка программирования, в частности Python, я считаю, что нужна погружаться в него полностью. Лозунг: «Ни дня без кода!» я дополняю, ну если ни кодить, то хотя бы почитать об этом. Для того чтобы не выходить из ритма в условиях, когда нужно в жизни сделать многое, но некогда, а хотелось бы учить Python, мобильный приложения помогут не тратить зря время в транспорте, во время ожиданий и т.д.Предлагаю список приложений из Google Play для изучения Python на Android-устройствах, которые помогут не только получить знания, но и проверить свой уровень по Python.Три из ниже перечисленных приложений я обязательно советую студентам при изучении Python: Learn Python, Quiz&Learn Python и Python Challenge. Ну теперь подробнее.

Количество и объем материалов по PureData постепенно растет, значит настало время собрать их в одном месте. Это, своего рода, пост-содержание написанных мною статей. Многие описанные в них принципы и идеи подходят не только для PD, но и для любого MAX-подобного языка. Удачи в экспериментах.

Привет хабр!

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

Реактивное программирование — очень модный тренд в мобильной разработке на данный момент. Если говорить про android разработку, то реактивность представлена в основном библиотекой RxJava.
В сети все больше статей, обучающих видео, презентаций, записей с конференций, в которых рассказывается про данную тематику. Но подавляющее большинство представленного материала содержит теоретические аспекты и весьма тривиальные примеры, на которых разработчик не может оценить реальный профит от использования Rx. А ведь так хочется увидеть реальный и сложный пример из жизни, который очень наглядно покажет всю мощь, красоту и простоту реактивного программирования.
Поэтому данная статья будет посвящена подробному разбору реального и довольно таки сложного примера. И я очень надеюсь, что после прочтения, вы по-настоящему откроете для себя мир реактивного программирования.

Здравствуйте, уважаемые читатели.

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

Здравствуйте!
Продолжаю серию публикаций по проекту
Maven/Spring/Security/JPA(Hibernate)/Rest(Jackson)/ Bootstrap(CSS)/ jQuery+plugins
(исходный код на GitHub).

Предыдущие публикации:

• По следам Spring Pet Clinic. Maven/ Spring Context/ Spring Test/ Spring ORM/ Spring Data JPA
• Тестируем Spring Rest контроллеры: проще, короче, надежнее. Spring Security Test + JSON Matcher
• Spring Security 4 + CSRF (добавление в Spring проект защиты от межсайтовой подделки запроса)

Заключительная часть проекта: деплой в облачную PaaS-платформу Heroku

Clojure (произносится как closure) — современный диалект Лиспа, язык программирования общего назначения с динамической типизацией и поощряющий функциональное программирование. Автор языка Рич Хикки впервые представил своё творение в 2007 году, с тех пор язык заматерел и достиг версии 1.7, вышедшей 30 июня 2015 года.

Одна из основных концепций языка — это работа на какой-либо существующей платформе. Рич Хикки решил не писать свою среду выполнения, свой сборщик мусора и т.п. — это потребовало бы больших трудозатрат, проще использовать уже готовые платформы, такие как JVM, .NET, JavaScript. На сегодняшний день два самых активно развиваемых направления: Clojure на JVM (именно он достиг версии 1.7 не так давно) и ClojureSrcipt — подмножество языка, которое компилируется в JavaScript для работы в браузере и на Node.js. Версия для .NET развивается не так активно и отстаёт от JVM имплементации. Я поискал в интернете и нашел ещё несколько мёртвых реализаций Clojure: на Go, на PHP, на Python и на Perl.

В этой статье я хочу рассказать о Clojure, показав примеры в сравнении с PHP, основываясь на серии скринкастов на английском From PHP to Clojure.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Мне нравится, когда клиент может сразу увидеть результаты моих трудов. Я могу корректировать развитие проекта согласно желаниям заказчика, что сильно спасает от недопонимания. Думаю и клиенты не против быть в курсе, куда уходит бюджет и на каком этапе их проект. Добиться этого достаточно просто, благо есть даже целая методология, называемая «Непрерывной интерграцией», позволяющая в кратчайшие сроки деплоить мелкие изменения, но как сделать, чтобы это было достаточно удобно для программиста? Ведь никому не хочется писать код, а после переключаться в контекст системы деплоя или даже использовать ssh соединение чтобы развернуть мелкие изменения на продакшене (или на dev сервере).

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

Опытный программист из Торонто Мэтт Бриггс так любит свою работу, что говорит: «я бы писал код, даже если бы это было нелегальным». А когда он опубликовал в своем блоге пост о джуниорах, мидлах и старших разработчиках, то собрал больше сотни восхищенных комментариев. Мы в Alconost тоже восхитились и перевели эту статью для вас.

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

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

Реальность такова, что под «старшим разработчиком» понимается человек, который ваяет код более 3 лет. Его ставят на руководящую позицию, и обычно все заканчивается ожидаемо плачевно.

На самом деле, попытка оценивать людей временными интервалами – слишком упрощенный способ для таких тонких материй, как знание и профессиональный опыт. Но дела обстоят именно так. И если продолжать классифицировать специалистов подобным образом, то самое время нашей индустрии брать тайм-аут. Есть разница между человеком с 10-летним опытом, и тем, кто за то же время стал опытнее в 10 раз.


Постер из сериалa «Компьютерщики»

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

Как-то раз ко мне в руки попал самый настоящий аналоговый синтезатор Korg monotron. Не смотря на свои игрушечные очертания, устройство содержало на борту весь минимум настроек, позволяющий погрузиться в мир аналогового синтеза. Так вот проводя вечера за вращением ручек и экспериментами с LFO-генератором и cuttoff фильтром, я стал ловить себя на мысли, что чего-то тут явно не хватает. Действительно, выполняющая роль клавиатуры резистивная пленка — весьма оригинальное и компактное решение. Но любые попытки исполнить на инструменте какую-то осмысленную партию обречены на провал. Выходит, и применять такой синт можно только как пищалку. С другой стороны, ситуацию могли бы спасти наличие MIDI порта и подключение внешней клавиатуры, но он, увы, отсутствовал.

Как оказалось, мидировать синтезатор не так уж и сложно.