Gson: Deserialization of Generic Types

Let's imagine that we are developing a wrapper library for an API, which returns JSON documents as a response. And there are many endpoints that have similar structures, except some fragment and may have a different structure.

Continue reading...

Folding@home

"Help Stanford University scientists studying Alzheimer's, Huntington's, Parkinson's, and many cancers by simply running a piece of software on your computer.

The problems we are trying to solve require so many calculations, we ask people to donate their unused computer power to crunch some of the numbers."

http://folding.stanford.edu

Аббревиатура на все случаи жизни

В одной из последних лекций на образовательном ресурсе Coursera проф. Тим Рафгарден поведал о любопытном факте. Когда математики и программисты второй половины XX века думали о том, как назвать те задачи, которые мы привыкли именовать NP-полными, среди прочих был предложен следующий вариант - английская аббревиатура PET. Вариант, как видим, не прижился, однако достоин упоминания вследствие лингвистической находчивости авторов.

В чем же эта находчивость проявляется?
Как известно, доказательство неравенства классов P и NP еще не получено, и поэтому нельзя аргументированно заявлять о том, что эти задачи можно решить только экспоненциально. Поэтому PET можно расшифровать как "probably exponential time".

Но прогресс не стоит на месте и когда-нибудь это доказательство может быть получено. Тогда аббревиатура останется прежней, поменяется лишь расшифровка - "provably exponential time". Теперь давайте представим что дед мороз существует и P = NP. И даже в этом случае аббревиатуру не пришлось бы менять - задачи стали бы называть "previously exponential time".

Привычный  нам термин NP-сomplete, впрочем, тоже не является уязвимым к разным разгадкам этой мировой загадки.

Декларативное и императивное программирование

Вступление
Допустим, наше приложение тем или иным образом хранит информацию о странах и городах мира. Предположим, что нам нужно вывести все города, начинающиеся на букву "V", расположенные в странах, которые начинаются на "R". Представим, что программа написана на Java без использования СУБД, и данные хранятся в обыкновенных коллекциях. Тогда код получения требуемых городов может иметь вид:

for(Country country : countryList){
            if(country.getName().startsWith("R"))
                for(City city:country.getCityList())
                    if(city.getName().startsWith("V")){
                        //что-то делаем с городом
                    }
        }

Теперь пусть приложение использует СУБД, к примеру, Oracle. Теперь данные можно извлечь посредством простого запроса:

select ctr.name country_name, c.name city_name, c.city_id
            from countries ctr, cities c
        where 1=1
              and c.country_id = ctr.country_id
              and ctr.name like 'R%'
              and c.name like 'V%'

Чем отличаются эти два способа извлечения данных? Помимо синтаксических отличий есть одно очень важное разграничение. В первом случае мы задаем инструкции, пошаговое выполнение которых приводит к извлечению нужных данных, а во втором - описываем данные, которые хотим получить, предоставляя СУБД возможность решить самостоятельно, каким способом эти данные извлечь. Первый подход называется императивным, а второй - декларативным. Рассмотрим эти понятия более подробно

Немного о временных таблицах

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

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

Привыкнув к такому положению вещей, очень легко упустить одну важную деталь.

Something About CASE, NVL And DECODE

Sometimes the programming language constructions which seem to be well known and usual, can behave in odd way. Here is the PL/SQL function for the simpliest example of the situation:

create or replace function get_number_five
return number
is
begin
  dbms_output.put_line('function get_number_five is invoked');
  return 5;
end;

As we can see, this function just returns the number 5 and outputs some string to standard buffer. So, here is an example of function which not only returns the result, but also performs some action, in other words it has some side effect. We need this quality to trace the function executons.

Let's try to guess the result of the following code:

declare
 x number;
 p number;
begin
  p :=5;
  x := nvl(p,get_number_five);
end;

Немного о case, nvl и decode

Иногда конструкции языка, кажущиеся знакомыми и вполне обычными, могут вести себя несколько неожиданно. Рассмотрим в качестве простейшего примера следующую функцию на PL/SQL:

create or replace function get_number_five
return number
is
begin
  dbms_output.put_line('function get_number_five is invoked');
  return 5;
end;

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

Попытаемся угадать, что произойдет при следующем вызове:

declare
 x number;
 p number;
begin
  p :=5;
  x := nvl(p,get_number_five);
end;