Недавно задумался о том, чем отличаются паттерны, позволяющие абстрагироваться от работы с хранилищем данных. Много раз поверхностно читал описания и различные реализации DAO и Repository, даже применял их в своих проектах, видимо, до конца не понимая концептуальных отличий. Решил разобраться, закопался в Google и нашел статью, которая для меня разъяснила все. Подумал, что неплохо было бы перевести ее на русский. Оригинал для англочитающих здесь. Остальным интересующимся добро пожаловать под кат.

Все проблемы в области Computer Science могут быть решены введением дополнительного уровня косвенности. За исключением одной: слишком большого числа уровней косвенности.
All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.

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

Я бы хотел обсудить принцип разделения ответственности (Separation of Concerns, SoC) в контексте ORM, а также посмотреть почему этот принцип так важен. Также мы рассмотрим примеры нарушения границ ответственности между доменной логикой и логикой сохранения данных.

Здравствуйте все!

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

Мы предположили, что и в сфере изучения алгоритмов для распределенных систем краткость — сестра таланта, поэтому проработка книги Уона Фоккинка «Распределенные алгоритмы. Понятный подход» является перспективным и благодарным делом, пусть даже объем книги — всего 248 страниц.



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

Всем привет!

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

От переводчика: Джефф Прешинг (Jeff Preshing) — канадский разработчик программного обеспечения, последние 12 лет работающий в Ubisoft Montreal. Он приложил руку к созданию таких известных франшиз как Rainbow Six, Child of Light и Assassin’s Creed. У себя в блоге он часто пишет об интересных аспектах параллельного программирования, особенно применительно к Game Dev. Сегодня я бы хотел представить на суд общественности перевод одной из статей Джеффа.

Поток должен ждать. Ждать до тех пор, пока не удастся получить эксклюзивный доступ к ресурсу или пока не появятся задачи для исполнения. Один из механизмов ожидания, при котором поток не ставится на исполнение планировщиком ядра ОС, реализуется при помощи семафора.

Раньше я думал, что семафоры давно устарели. В 1960‑х, когда еще мало кто писал многопоточные программы, или любые другие программы, Эдсгер Дейкстра предложил идею нового механизма синхронизации — семафор. Я знал, что при помощи семафоров можно вести учет числа доступных ресурсов или создать неуклюжий аналог мьютекса, но этим, как я считал, область их применения ограничивается.

Лето только начинается, но это не повод прекращать учиться. Предлагаем вам ознакомиться с очередной порцией знаний в рамках проекта «Лекции Техносферы». Цель курса — ознакомить студентов с актуальными методологиями тестирования и обеспечения качества современных веб-приложений. Курс позволит слушателям получить достаточные знания для овладения и применения на практике эффективных приемов построения процесса тестирования и обеспечения качества.

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

В преддверии крупнейшей восточноевропейской конференции по гибким методологиям AgileDays’14, мы решили составить рейтинг лучших книг которые влияют на нашу индустрию.

Методику составления рейтинга мы позаимствовали у Jurgen Appelo. Алгоритм подсчёта базируется на пяти различных критериях: количество отзывов Amazon, число отзывов GoodReads, средняя оценка Amazon, средняя оценка GoodReads, а количество дней, прошедших с первой публикации. Это означает, что этот список показывает вам смесь из самых популярных, лучших по оценкам, и (относительно) новейший книги в этой категории.

Данный список книг мы попросили прокомментировать двух экспертов:

Борис Вольфсон. Технический директор компании HeadHunter.

Андрей Ребров. Agile Engineering Coach компании ScrumTrek.

В ходе подготовки спецкурса «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

Традиционно в последнюю пятницу месяца состоялся Python Meetup. В мартовском митапе с приглашенными спикерами мы разобрались в следующих темах:

• Машинное обучение на Python
• Как устроен Python AST и какие интересные факты есть у диалекта Ну
• Как при помощи Requests, Asyncio и Aiohttp перестать использовать многопоточный код

Видео и ссылки на презентации смотрите под катом. Приятного просмотра!

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

Проблема в картинках

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



В какой-то момент в дочерних классах появляется необходимость в одинаковом функционале. Обычная копипаста будет выглядеть на нашей схеме вот так:



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



А теперь обсудим момент, ради которого написана вся статья — как правильно замешивать наш миксин в классы.

def Миф и язык extends «трёхнаправленное программирование»;

Миф о том, что русские программисты лучшие в мире, запущен вовсе не партийными пропагандистами, он возник на перестроечной волне, вместе с мифами о хозяине-предпринимателе, невидимой руке рынка и ста сортах колбасы. Миф, это то, что человек не читавший взрослых книг называет «мем», а человек вообще не читающий, называет правдой. Передача «Разрушители мифов» берёт поверхностные мифы, которые можно легко опровергнуть, например, бросив бутерброд с маслом на пол тысячу раз. А вот Гордон, в одном из своих первых телепроектов «Собрание заблуждений», брался за раскрытие мифов посложнее, такие мифы нельзя раскрыть затопив машину и проверив, можно ли всё-таки открыть двери до того, как машина полностью наполнится водой, они как плавающий баг у которого нету «steps to reproduce». Вспомните Холмса или Хауса, интеллектуал в первую очередь отличается тем, что видит невидимое — пока паникующие пассажиры всматриваются в туман за бортом, он закрывает глаза и всматривается в свои «чертоги разума», вспоминает карту местности и ТТХ парохода.

«Всё содержится в моих чертогах разума, вы же понимаете о чём я мистер Холмс? Я обладаю знаниями, и поэтому могу щёлкать доктора Ватсона по носу хоть целый день.»

От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

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

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

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

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

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

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

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

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

В последнее время я работаю с клиентами над вопросами настроек JVM. Смахивает ситуация на то, что далеко не все из разработчиков и администраторов знают о том, как работает garbage collection и о том, как JVM использует память. Поэтому я решил дать вводную в эту тему с наглядным примером. Пост не претендует на то, чтобы покрыть весь объем знаний о garbage collection или настройке JVM (он огромен), ну и, в конце концов, об этом много чего хорошего написано уже в Сети.

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

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

В данной статье я бы не хотел заострять внимание на принципе работы сборщика мусора — об этом прекрасно и наглядно описано здесь: habrahabr.ru/post/112676. Хочется больше перейти к практическим основам и количественным характеристикам по настройке Garbage Collection в JVM — и попытаться понять насколько это может быть эффективным.

Количественные характеристики оценки эффективности GC

Рассмотрим следующие показатели:

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

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

Добрый день.
В рамках набора на курс «Multicore programming in Java» я делаю серию переводов классических статей по многопоточности в Java. Всякое изучение многопоточности должно начинаться с введения в модель памяти Java (New JMM), основным источником от авторов модели является «The Java Memory Model» home page, где для старта предлагается ознакомится с JSR 133 (Java Memory Model) FAQ. Вот с перевода этой статьи я и решил начать серию.
Я позволил себе несколько вставок «от себя», которые, по моему мнению, проясняют ситуацию.
Я являюсь специалистом по Java и многопоточности, а не филологом или переводчиком, посему допускаю определенные вольности или переформулировки при переводе. В случае, если Вы предложите лучший вариант — с удовольствием сделаю правку.
Этот статья также подходит в качестве учебного материала к лекции «Лекция #5.2: JMM (volatile, final, synchronized)».

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Ну и да, приходите учиться ко мне!

---

JSR 133 (Java Memory Model) FAQ

Jeremy Manson и Brian Goetz, февраль 2004

Содержание:
Что такое модель памяти, в конце концов?
Другие языки, такие как C++, имеют модель памяти?
Что такое JSR 133?
Что подразумевается под «переупорядочением» (reordering)?
Что было не так со старой моделью памяти?
Что вы подразумеваете под «некорректно синхронизированы»?
Что делает синхронизация?
Как может случиться, что финальная поля меняют значения?
How do final fields work under the new JMM?
Что делает volatile?
Решила ли новая модель памяти «double-checked locking» проблему?
Что если я пишу виртуальную машину?
Почему я должен беспокоиться?

Всем привет.

В прошлую субботу — 19 апреля прошла очередная встреча C++ User Group. На этот раз мы встречались в Нижнем Новгороде.
На встречу пришло 82 человека, причём участники были не только из Нижнего Новгорода: Санкт-Петербург, Москва, Рязань, Саратов, Чебоксары, Екатеринбург, Великий Новгород. Меня немного пугает, что зарегистрировался, но не приехал участник из Иркутска. Надеюсь, с ним всё хорошо.