Почитывая «Банду четырех», всё чаще думаю как хорошо было бы иметь отдельный плакат на стену в офисе, резюмирующий и объясняющий шаблоны проектирования. Как здорово было бы не держать все их в голове, а имея проблему, взглянуть и найти подходящее решение. Но найти подходящий постер оказалось не так то просто, да и тот оказался не идеальным.

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

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

Автор — Sebastien Gabriel.

Я не знаю всего, так что, если по вашему мнению я где то ошибаюсь или вам нужно уточнить что-то, либо у вас есть предложения или вопросы для улучшения данного руководства, отправьте письмо (на англ) на sgabriel.contact@gmail.com. Вы также можете найти на меня Twitter, G+ или Facebook.

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

Помните пост «Что хабровчане носят с собой», где народ хвастался содержимым своего рюкзака? Меня, если честно, больше интересовало не содержимое, а то, в чем народ носит свои вещи. Вот так, к слову, выглядела одна из наиболее интересных вещей — фотосумка Boomburum.



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

Введение

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

Что будет в этой статье:

• Разберем, из чего состоит фреймворк и зачем он нужен;
• разберем вопрос безболезненного развертывания кластера;
• посмотрим на конкретный пример;
• немного коснемся новых фич Hadoop 2 (Namenode Federation, Map/Reduce v2).

Чего не будет в этой статье:

• вообще статья обзорная, поэтому без сложностей;
• не будем лезть в тонкости экосистемы;
• не будем зарываться глубоко в дебри API;
• не будем рассматривать все околоdevops-задачи.

С какой целью это может понадобиться? Например, если хочется использовать "текучий интерфейс". Правда, если часть методов разместить в родительском классе, то для них не получится сделать полноценный «текучий интерфейс» — эти методы требуется приводить (кастовать) к дочернему.

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

Суть проблемы

Бывают ситуации когда документы имеют много различных полей и необходимо иметь эффективные запросы по ним. Например есть документ описывающий человека:

{
    _id: 123,
    firstName: "John",
    lastName: "Smith",
    age: 25,
    height: 6.0,
    dob: Date,
    eyes: "blue",
    sign: "Capricorn",
    ...
}

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

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

Я знал про них давно, но как-то скептически относился к бизнесу на базе Ардуино, когда рядом находится Китай, e-bay, таобао — где можно напрямую и достаточно недорого заказать Ардуино и другие комплектующие.

Но вот к нам в хакспейс попал новый набор «Матрешка Z», и я понял, что Амперка не просто продаёт Ардуино — они делают качественные образовательные наборы по электронике для начинающих.

Что же внутри?

Каждому разработчику в определенной степени следует овладеть навыками работы в терминале. Физически находиться у компьютера не всегда возможно, поэтому приходится подключаться удаленно. И действительно, GUI-программы вполне могут с этим с правиться, но зачастую они работают медленнее, чем получение доступа через тот же терминал (в конце концов, это лишь обмен текстом).

Не секрет, что многие Java-программисты, начиная свой путь в индустрии, уделяют большое внимание «тяжелым» технологиям — OpenJPA, Spring, JAX-RS, EJB, WS-*,… Это дает возможность как скорее влиться в современные корпоративные проекты, так и максимизировать скорость роста зарплаты.

Многие из них в конце концов «спускаются» до технологий лежащих в основе указанных фреймворков — JDBC, Servlet API, NIO/NIO.2. Однако прискорбно, что зачастую не остается время на детальное изучение самого языка и возможностей платформы.

Речь идет не о тонкостях или экзотике, а о том, что составляет существенную часть работы фреймворка: Servlet-контейнер использует множественные ClassLoader-ы, JPA2-провайдер использует манипулирование байткодом, абсолютное большинство библиотек используют Reflection API, всеобщее использование Generics только «усугубилось» с появлением функциональных интерфейсов (java.lang.function.*) и лямбд.

На недопонимание изначальной платформы (ClassLoader, Reflection API) накладываются «новвоведения» Java 5 (Generics), а теперь еще и Java 8 (методы в интерфейсах, ссылки на методы, лямбды, Stream API, JSR 308: Pluggable Type Systems). Надо обратить внимание на то, что Generics + Java 8 — это не просто языковые фичи, это частично переход к функциональному стилю программирования.

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

Я собрал определенное количество полезных (на мой взгляд) ссылок по следующим темам

1. Методы в интерфейсах, ссылки на методы, множественное наследование
2. Лямбды (Project Lambda)
3. Stream API
4. Функциональные алгоритмы
5. Аннотации
6. Генерики
7. Reflection API
8. Загрузка классов

Надеюсь кто-то сочтет их полезными.

Много статей написано о том, как правильно реализовывать на Java шаблон проектирования Singleton.

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

Лично я считаю единственным корректным способом реализации синглтона на Java так называемый Synchronized Accessor:

public class Singleton {
    private static Singleton instance;
    
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

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

Однако, пытаясь освежить в памяти возможности Java concurrency, я почитал старые статьи о вариантах синглтонов и удивился, что не нахожу описания еще одного способа, который я называю Function Pointer.

Господа, рад представить вам свой новый проект — Refactoring.guru.

Сайт представляет собой каталог запахов грязного кода и, собственно, самих приёмов рефакторинга. В двух словах — это как книга Мартина Фаулера, но лучше. А именно:

• Весь контент доступен на русском языке. Я старался делать описания как можно более живыми, чтобы избавиться от чувства унылости и скуки, которое возникает при чтении любой переводной книги о рефакторинге.
• Все примеры подаются на Java и PHP. Другие языки обязательно будут добавляться со временем, но я пока затрудняюсь решить, каким будет следующий, можете предлагать в комментах.
• Всё везде перелинковано. Рефакторинги сгруппированы по предназначениям и связям.

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

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

Буду рад всем отзывам и пожеланиям! (а также лайкам и твитам)

Хорошие лабораторные по многопоточности (простые, понятные, нетривиальные и полезные в народном хозяйстве) — большая редкость. Предлагаю Вам одно условие и четыре лабораторные работы по элементарной многопоточности на Java.

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

Условия

Это реализация однопоточного побайтового копировальщика из InputStream в OutputStream. Копирование происходит в потоке вызвавшем метод copy(...)

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public class CopyUtil {
    public static void copy(InputStream src, OutputStream dst)throws IOException{
        try (InputStream src0 = src; OutputStream dst0 = dst) {
            int b;
            while ((b = src.read()) != -1) {
                dst.write(b);
            }
        }
    }
}

Доброе время суток, хабр. Этот топик — продолжение цикла статей, основанных на материалах онлайн курса M101 от 10gen. Поскольку вторая неделя является одной из самых насыщенных, она будет разбита на две статьи.

Это вторая часть статьи (первая часть — try-catch-finally), посвященной такому языковому механизму Java как исключения. Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

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

1. Магия checked/unchecked
2. Пессимистичный механизм
3. throws с непроверяемым (unckecked) исключением
4. Множественные исключения
5. Или catch, или throws
6. Поведение компилятора/JVM
7. Overriding и throws
8. Передача свойства по наследству

1. «Магия» checked/unchecked

Механизм исключительных ситуация в Java связан с двумя элементами «магии», т.е. поведения, которое никак не отражено в исходном коде:
1. «Магию» java.lang.Throwable — в throw, catch и throws могут стоять исключительно Throwable или его наследники (мы уже разбирали в предыдущей лекции). Это «право» находиться в throw, catch и throws никак не отражено в исходном коде.
2. Все исключительные ситуации делятся на «проверяемые» (checked) и «непроверяемые» (unchecked). Это свойство присуще «корневищу» (Throwable, Error, Exception, RuntimeException) и передается по наследству. Никак не видимо в исходном коде класса исключения.

Это первая часть статьи, посвященной такому языковому механизму Java как исключения (вторая (checked/unchecked) вот). Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

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

1. Ключевые слова: try, catch, finally, throw, throws
2. Почему используем System.err, а не System.out
3. Компилятор требует вернуть результат (или требует молчать)
4. Нелокальная передача управления (nonlocal control transfer)
5. try + catch (catch — полиморфен)
6. try + catch + catch + ...
7. try + finally
8. try + catch + finally
9. Вложенные try + catch + finally

1. Ключевые слова: try, catch, finally, throw, throws

Механизм исключительных ситуаций в Java поддерживается пятью ключевыми словами

• try
• catch
• finally
• throw
• throws

«Магия» (т.е. некоторое поведение никак не отраженное в исходном коде и потому неповторяемое пользователем) исключений #1 заключается в том, что catch, throw, throws можно использовать исключительно с java.lang.Throwable или его потомками.

Сегодня все большую популярность приобретает test-driven development(TDD), техника разработки ПО, при которой сначала пишется тест на определенный функционал, а затем пишется реализация этого функционала. На практике все, конечно же, не настолько идеально, но в результате код не только написан и протестирован, но тесты как бы неявно задают требования к функционалу, а также показывают пример использования этого функционала.

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

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

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

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

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

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

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

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

Добрый день.
15 мая была проведен первый вебинар (из 16) курса «Multicore programming in Java». Тут я бы хотел опубликовать материалы, упоминавшиеся на лекции: ссылки на источники, термины, картинки, задание. Возможно кто-то сочтет их полезными для себя.

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

Введение

• Закон Мура, Moore’s law
• Herb Satter, “The Free Lunch Is Over”
• Закон Амдала, Amdahl’s law

“Железо”

Стоит «посмотреть картинки» в следующих источниках

• «What Every Programmer Should Know About Memory»
• «The Architecture of the Nehalem Processor and Nehalem-EP SMP Platforms»
• «A Primer on Memory Consistency and Cache Coherence»

Добрый день.
В рамках детальной проработки курса удаленного образования «Java Core» я пишу серию публикаций и делаю несколько переводов наиболее популярных статей.

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

Сейчас я предлагаю Вам на рассмотрение мой перевод «Programming With Assertions» с некоторыми комментариями.

Оригинальная публикация не только детально объясняет варианты использования ключевого слова assert в Java и то, как реализована поддержка данного механизма на уровне загрузки классов, но также является достаточно неформальным введением в Разработку-по-Контракту (Design-by-Contract).




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

---

Программирование с утверждениями (oracle.com: Programming With Assertions)

Утверждение (assert) — это оператор (statement) языка программирования Java, который позволяет вам проверить свои предположения о программе. Например, если вы пишете метод, вычисляющий скорость частицы, можно «утверждать», что расчетная скорость меньше скорости света.

Каждое утверждение содержит логическое выражение, которое, по вашему мнению, будет верным в момент выполнения. В противном случае, система выбросит исключение. Проверяя, что логическое выражение на самом деле верно, утверждение (assert) подтверждает ваши предположения (ожидания) о поведении программы, увеличивая уверенность в том, что программа не содержит ошибок.