Краткая история мюзикла

Краткая история мюзикла, от Древней Греции до наших дней.

Доклад по предмету "История искусств" на тему "Краткая история мюзикла".

Фотографии и видео нагло взяты с YouTube и поиска картинок Google. Текст придумали сами. Озвучили тоже.

Использовалось:
* youtube-dl для скачивания видео
* gimp для редактирования картинок
* synfig для анимации (падучий, большие анимации лучше бить на куски)
* kdenlive для монтирования видео (удивил, насколько хороший продукт)

Сижу с красными глазами после бессонной ночи.

Практика POV-Ray

POV-Ray - графический инструмент построения 3д сцен. Был разработан лет 30 назад, весит 12 мг, но позволяет очень много. Завлекла идея программировать картинки.

Убил 2 часа времени на ЭТО:



Update И еще 30 минут на доделку:

#include "colors.inc"
#include "textures.inc"

camera {
    location  <5, 13, -40>
    look_at   <0, 0, -5>
    angle 48
}

#declare Steel = texture {
    pigment { color rgb < 0.450,  0.450,  0.450> }
    finish {
        ambient   0.20
        diffuse   0.75
        brilliance   1.00
        phong   0.70
        phong_size  10.00
        metallic
    }
}

#declare Fire = texture {
    pigment { color rgb < 0,  0,  1> }
    finish {
        ambient 0.5
        diffuse 0.5
    }
}

#declare Energy = texture {
    pigment { color rgb < 1,  0,  0> }
    finish {
        ambient 0.5
        diffuse 0.5
    }
}


//Halo
cylinder {
    <0, 1, 0>
    <0, 0, 0>
    7 
    texture { Steel }
}

//Body
union {
    cylinder {
        <0, -3, -12>
        <0, -3, -3.5>
        1 
        texture { Steel }
    }

    sphere {
        <0, -3, -3.5>, 1
        texture { Steel }
    }

    sphere {
        <0, -3, -12>, 1
        texture { Steel }
    }
}

//Left gandola
cylinder {
    <-2, -0.5, -13>
    <-2, -0.5, -8> 
    0.5 
    texture { Steel }
}

//Left Fire
cone {
    <-2, -0.5, -25>, 0.1
    <-2, -0.5, -13>, 0.4
    texture { Fire }
}

//Left energy indicator
cone {
    <-2, -0.5, -7>, 0.4
    <-2, -0.5, -8>, 0.5 
    texture { Energy }
}

//Right gandola
cylinder {
    <2, -0.5, -13>
    <2, -0.5, -8> 
    0.5 
    texture { Steel }
}

//Right Fire
cone {
    <2, -0.5, -25>, 0.1
    <2, -0.5, -13>, 0.4 
    texture { Fire }
}

//Right energy indicator
cone {
    <2, -0.5, -7>, 0.4
    <2, -0.5, -8>, 0.5 
    texture { Energy }
}

//Bridge
cone {
    <0, 1, 0>, 2.5
    <0, 1.2, 0>, 2
    texture { Steel }
}

//Halo ferm
mesh {
    triangle {
        <-0.2, -3, -8>, <-0.2, -3, -4>, <-0.2, 0, -2> 
        texture { Steel }
    }
    triangle {
        <0.2, -3, -8>, <0.2, -3, -4>, <0.2, 0, -2> 
        texture { Steel }
    }
    triangle {
        <0.2, -3, -4>, <-0.2, -3, -4>, <-0.2, 0, -2> 
        texture { Steel }
    }
    triangle {
        <-0.2, 0, -2>, <0.2, 0, -2>, <0.2, -3, -4> 
        texture { Steel }
    }

    triangle {
        <-0.2, 0, -2>, <-0.2, 0, -4>, <-0.2, -3, -8> 
        texture { Steel }
    }
    triangle {
        <0.2, 0, -2>, <0.2, 0, -4>, <0.2, -3, -8> 
        texture { Steel }
    }
    triangle {
        <0.2, 0, -4>, <-0.2, 0, -4>, <-0.2, -3, -8> 
        texture { Steel }
    }
    triangle {
        <0.2, -3, -8>, <-0.2, -3, -8>, <0.2, 0, -4>
        texture { Steel }
    }

}

//Left gandola ferm
prism {
    linear_sweep
    linear_spline
    4,4.3,7,
    <0,0>, <3,6>, <0,9>, <-6,9>, <-3, 6>, <-9,0>, <0,0>
    texture { Steel }
    rotate <-45,-90,0>
    scale 0.3
    translate <-1, -4, -9.3>
}

//Right gandola ferm
prism {
    linear_sweep
    linear_spline
    4,4.3,7,
    <0,0>, <3,6>, <0,9>, <-6,9>, <-3, 6>, <-9,0>, <0,0>
    texture { Steel }
    rotate <-135,-90,0>
    scale 0.3
    translate <-1, -2, -9.3>
}


light_source {
    <10, 30, -25>
    color White
}

light_source {
    <10, -30, -5>
    color White
}

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

Применение EJB3

Как можно применить контейнер EJB3?

Технология EJB3 представляет из себя смесь различных технологий:

• JPA, которая чаще всего используется с какой-нибудь ORM вроде Hibernate, TopLink или iBatis


• IoC контейнер, причем не полный


• Вполне приличный AOP


• Автогенерацию веб сервисов

Как правило EJB3 применяют в связке с каким-нибудь MVC фреймворком, вроде JavaFaces. Основным недостатком такой схемы является то, что все эти фреймворки построены на основе Servlet API, что само по себе было бы неплохо, если бы JPA сессия не терялась при выходе из контекста EJB3, что за собой ведет проблемы lazy инициализации объектов бизнес модели.

Долго думаю над тем, как можно применять EJB3, при том, чтобы недостатки технологии не мешали разработке. Я пришел к выводу, что необходимо полностью отказаться от слоев, в которых не действует сессия JPA, т.е. от слоя представления. Слой представления же должен поддерживать связь с EJB контейнером посредством веб сервисов. Преимущества такой схемы:

• Слой представления может быть реализован на любом динамическом языке, вроде Python, Ruby, Perl


• Четкое выделение бизнес логики, позволит быстрее и проще ее тестировать


• Более простое сопряжение с другими системами

Причем последний пункт считаю особо важным. Работая в сфере финансовых операций часто приходится объединять между собой различные системы. Для примера приведу случай из собственного опыта. Наша компания работает в сфере финансовых операций, а именно электронных платежей. Основным нашим продуктом является платежная система на ряд сервисов Кыргызстана. Благодаря тому, что бизнес логика доступна через веб сервисы мы легко можем ее соединить с другими сервисами компании.

Unit тесты в perl

Настоящему программисту должно быть пофиг на чем писать, главное следовать концепциям. Одной из важнейших я считаю TDD. Начав проект на перле, сразу полез искать имплементацию JUnit на перле. Таковым стали модули Test::Unit::TestCase, Test::Unit::TestSuite и Test::Unit::TestRunner

Сначала напишем TestCase

package SipPaymentTest;
use strict;
use base qw(Test::Unit::TestCase);

sub new {
    my $self = shift()->SUPER::new(@_);
    return $self;
}

sub set_up {
    my $self = shift;
}

sub test_some_feature {
    my $self = shift;
    $self->assert(0);
}

Написав несколько случаев тестирования, нужен и инструмент запуска тестов:

%cat run.pl
#!/usr/bin/perl

use Test::Unit::TestRunner;
use Test::Unit::TestSuite;

require "lib/config.pl";
require "lib/aub.pl";
require "aubtest.pl";
require "nopaymenttest.pl";
require "sippaymenttest.pl";
require "sipprotocoltest.pl";

my $test = shift;
my $runner = Test::Unit::TestRunner->new();

my $suite = Test::Unit::TestSuite->empty_new("AUB Payment Terminal Test Suite");

if (!$test || $test eq 'AUB') {
    $suite->add_test(Test::Unit::TestSuite->new('AUBTest'));
}
if (!$test || $test eq 'NoPayment') {
    $suite->add_test(Test::Unit::TestSuite->new('NoPaymentTest'));
}
if (!$test || $test eq 'SipPayment') {
    $suite->add_test(Test::Unit::TestSuite->new('SipPaymentTest'));
}
if (!$test || $test eq 'SipProtocol') {
    $suite->add_test(Test::Unit::TestSuite->new('SipProtocolTest'));
}
my $result;
$runner->do_run($suite, 0);

Такой инструмент можно использовать для запуска как одиночных тестов, так и все сразу

%./run.pl NoPayment
........
Time:  1 wallclock secs ( 0.46 usr +  0.03 sys =  0.49 CPU)

OK (8 tests)
%./run.pl
..............F..........
Time:  6 wallclock secs ( 1.32 usr +  0.12 sys =  1.44 CPU)

!!!FAILURES!!!
Test Results:
Run: 24, Failures: 1, Errors: 0

There was 1 failure:
1) sippaymenttest.pl:50 - test_pay(SipPaymentTest)
'2009-09-03 13:07:16.427436' did not match /(?-xism:2009-11-22)/

Test was not successful.

Bean Validation

JSR303 Кажется весьма интересным стандартом. Система валидации данных наверное один из самых старейших велосипедов известных мне. Защитное программирование требует чтобы проверялись все входные параметры метода, что выливается в блоки проверки правильности данных в каждом методе, что в свою очередь ведет к повторению кода - а это нарушает принцип DRY. Вот наконец-то светлые умы мира JAVA добрались и до этой проблемы. Прежде чем рассказать о стандарте, пример:

package test.validator;

import java.util.Set;

import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;

public class User {

  @NotNull(message="Имя должно быть задано")
  String firstname;

  @NotNull(message="Фамилия должна быть задана")
  @Size(min = 3, message="Длина фамилии должна быть больше трех")
  String lastname;

  @NotNull(message="Имэйл должен быть задан")
  @Pattern(regexp = "^(?:[a-zA-Z0-9_'^&/+-])+(?:\\.(?:[a-zA-Z0-9_'^&/+-])+)" +
      "*@(?:(?:\\[?(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\\.)" +
      "{3}(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\]?)|(?:[a-zA-Z0-9-]+\\.)" +
      "+(?:[a-zA-Z]){2,}\\.?)$",
      message = "заданный имэйл не может существовать")
  String email;

  @Override
  public String toString() {
    return String.format("firstname: [%s], lastname: [%s], email: [%s]",
        firstname, lastname, email);
  }

  public static void validate(Object object, Validator validator) {
    Set<constraintviolation<object>> constraintViolations = validator
        .validate(object);
   
    System.out.println(object);
    System.out.println(String.format("Кол-во ошибок: %d",
        constraintViolations.size()));
   
    for (ConstraintViolation<object>l; cv : constraintViolations)
      System.out.println(String.format(
          "Внимание, ошибка! property: [%s], value: [%s], message: [%s]",
          cv.getPropertyPath(), cv.getInvalidValue(), cv.getMessage()));
  }

  public static void main(String[] args) {
    ValidatorFactory vf = Validation.buildDefaultValidatorFactory();
    Validator validator = vf.getValidator();

    User user = new User();
    validate(user, validator);

    user.firstname = "Вася";
    validate(user, validator);

    user.lastname = "Пу";
    validate(user, validator);
   
    user.lastname = "Пупкин";
    validate(user, validator);
   
    user.email = "вася пупкин@example.com";
    validate(user, validator);

    user.email = "vasya.poupkine@example.com";
    validate(user, validator);

  }
}

Обратите внимание на аннотации:
* Логические: @NotNull, @NotEmpty, @AssertTrue/False
* Бизнес: @Email, @EAN, @CreditCard
* Значение: @Min, @Max, @Digits, @Length, @Size
* Другие: @Valid, @Pattern
* Свои собственные!

Жду имплементации в JPA 2.0

Фактор стабильного сервиса

События последних дней заставили наконец-то задуматься о некоторых факторах стабильного сервиса. От проблем с аппаратной частью не застрахован никто, я бы даже сказал - они неизбежны и не брать во внимание такие важные вещи - верх некомпетентности. Итак, несколько очевидных вещей:
1. Если есть возможность дублировать сервис - обязательно сделать. Если что-то случится с основной машиной, перейти на резервную будет делом техники
2. Иметь возможность заменить машину целиком, а не латать по частям. Практика показала, что это дешевле, чем подмоченная репутация

Сжатый опыт J2ME

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

За новое приложение на платформе J2ME я уже взялся с колокольни своего опыта разработки на Java. Бодро нашлись удобные инструменты, вроде готового окошечного виджетового фреймворка Kuix, IOC контейнера israfil-micro-container и даже ORM фреймворк Floggy. Для связи воспользовался SOAP библиотека kSOAP 2.

Отдельно про плюсы и минусы каждой части приложения:

Kuix - большой виджетовый фреймворк с активным коммунити, которое задает одни и теже вопросы на форуме по 10 раз как минимум. Так что любая проблема встреченная вами при работе с этим фреймворком будет обсосана со всех сторон и часто не решена. Фреймворк преследует цель одинаково работать на максимальном количестве устройств. В нашем же случае можно было ограничиться изделиями фирмы Nokia и не тестировать приложение на зоопарке других девайсов. Больше всего меня впечатлила поддержка css данной библиотекой. Оказалось очень удобно сначала сформировать workflow приложения без оглядки на внешний вид, а потом обработать напильником. Работа с данным фреймворком очень похожа на веб разработку. К минусам можно отнести большой вес и необходимость большой вычислительной мощности. На бюджетных сотках за 1700 сом приложение неумолимо выбрасывает OutOfMemoryException.

Israfil - IOC контейнер. В принципе больше нечего о нем сказать. Рома однажды сказал: "нафиг он тебе нужен". Да Рома, он нафиг не нужен, куда удобней работать с singleton'ом ObjectCreator.

Floggy - ORM. Прикольная штука. Кормишь ей объект, кушает. Просишь обратно, отрыгивает. Работает именно так как должна. Мне понравилось. Тем более у меня был опыт работы с API RMS. Мне оно активно не понравилось ибо приходится много думать и много тестировать. Зачем лишний геморой?

kSOAP 2 - Поддержка данной библиотеки сдохла еще в 2006, но к моему удивлению они смогли написать что-то, что работает. Единственный минус - библиотека не умеет работать с cookie. Пришлось ее научить, это оказалось не сложным, просто переписал пару классов. Но тот факт, что можно работать с RPC SOAP радует. Можно целиком избавиться от слоя сервлетов, которые мне честно говоря уже очень надоели. Я уже нашел библиотеку работы с SOAP на JS. Как показала практика бизнес логику удобно держать в виде web сервисов, тогда можно писать различные интерфейсы: веб, для мобильников, десктопные и с легкостью объединять с другими системами, что в бизнес приложениях не редкость.

Как было уже упомянуто, большая часть наших клиентов ходит с сотками очень бюджетного класса, на которых приложение отказалось работать. Я был огорчен неверным построением требований. Но благо это обернулось малой кровью. Благодаря слоистой структуре изменениям подвергся только слой представления. Всего 2 дня работы и интерфейс был переписан на привычный lcdui. Пришла мысль чего я парился? На lcdui разработка куда легче, работает быстрее и весит меньше... разве что интерфейсы получаются однообразные. Но для бизнес приложения это невеликий недостаток.

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

Пару лет назад я читал статью, где утверждалось, что J2ME умер, так как появились сотки достаточно мощные, чтобы запускать J2SE. Но вот, 2 года прошло, а нам экономически выгодно писать приложения на J2ME. Пользователей и сейчас очень много. Среди кассиров почти не встретишь людей, грузящих еды через iPhone или GAndroid...

PS: Никита привет, ты единственный, кто подписан на RSS моего блога, сделай в google reader общей статьей :)