вторник, 3 февраля 2015 г.

Использование gif вместо статических картинок для примеров кода

Пришла в голову идея использовать гифки для демонстрирования примеров кода в блоге:

Человек лучше воспринимает код пошагово, чем весь кусок кода сразу. Что думаете?

понедельник, 2 февраля 2015 г.

Диаграмма языков

Есть четыре парадигмы языков, которые часто путают и смешивают в кучу:
  • Императивная парадигма
  • Декларативная парадигма
  • Фунциональная парадигма
  • Объектно-ориентированная парадигма

Я решил нарисовать простую диаграмму, которая расставляет всё на свои места. Заранее предупреждаю, что это моё личное субъективное видение, которое не претендует на стопроцентную истину:


Таким образом, есть две прямо противоположные непересекающиеся парадигмы: императивная и декларативная. В императивных языках мы описываем решение задачи через последовательность инструкций, которые указывают машине что делать. Декларативная парадигма же не содержит никаких инструкций, а вместо них даёт некоторое описание, которое машина должна интерпретировать.
Пример чисто императивного языка  C, пример чисто декларативного языка  HTML.
Теперь самое интересное: объектно-ориентированная и функциональная парадигмы. Обе они не являются строгим подмножеством императивной и декларативной парадигм соответственно. Да, есть языки, которые объектно-ориентированны и при этом чисто императивны (Java, C++), и есть языки, которые функциональны и чисто декларативны (Agda).
Но в целом, ничто не запрещает функциональному языку быть императивным (Haskell), а объектно-ориентированному языку  декларативным (C# со своим LINQ).
А есть вообще языки, которые сразу поддерживают и императивную, и декларативную, и объектно-ориентированную, и функциональную парадигмы (Scala, Nemerle, OCaml).

воскресенье, 1 февраля 2015 г.

Простенькая задачка для собеседования на Java-программиста

Я вообще ненавижу concurrency. В Java это ад и боль, усложнение понимания кода программы, дедлоки и деградация производительности. Поэтому всеми способами стараюсь её избегать. И тем не менее, это основы, которые нужно понимать. Поэтому предлагаю простую задачку для собеседования на Java-программиста.

Задача: реализовать класс Ref<A>, который представляет собой изменяемую ссылку. У класса должно быть два метода: set и get. set - устанавливает значение ссылки, get - получает значение ссылки или блокируется до тех пор, пока там не появится ненулевое значение.

Решений можно придумать много. На ум приходят synchronized/notify, AtomicReference, блокирующие очереди, примитивы вроде CountDownLatch и т.д. Приведу решение с synchronized/notify как самое натуральное, по моему мнению:

public class Ref<A> {
    private A a;

    public Ref() {
    }

    public synchronized A get() throws InterruptedException {
        while (a == null) {
            wait();
        }

        return a;
    }

    public synchronized void set(A a) {
        this.a = a;
        if (a != null) {
            notifyAll();
        }
    }

}
Ничего сверхсложного, но есть пара нюансов, которые нужно понимать, в частности:
  • Не забыть делать проверку a == null в цикле (правило).
  • Нужно вызывать notifyAll, а не notify (правило).
Если кандидат успешно решает задачу, то можете быть на 90% уверенным, что программист хорош. Спросите у него ещё пару простых вопросов на алгоритмы и смело нанимайте.