Licença do ExtJS

{ May 17th, 2012 }


cmilfont

Autor: cmilfont

Há uma grande confusão e má interpretação da licença dual do ExtJS e de todos os produtos Sencha em geral, principalmente por causa da GPL3. Como voces deveriam saber, os produtos da Sencha são Open Source com uma licença comercial caso queira monetizar com as ferramentas.

Já discuti com diversas pessoas afirmando que se voce construir uma aplicação com ExtJS voce tem que distribuir o código fonte de sua aplicação, aí que está o grande engano.

Preciso Distribuir o Código Fonte de Minha Aplicação?

Não

Explique

ok, a licença é conhecida como viral, o que ela toca se torna Open Source e voce precisa deixar acessível.

Basicamente se algo depende de código com GPL3 esse algo se torna GPL3.

Agora uma Webapp com ExtJS não depende do ExtJS, sendo mais preciso o seu server-side  não depende da camada de apresentação se esta for feita toda no client-side como as abordagens Full Ajax utilizam. Por isso eu não uso e nunca utilizei em produção algo com a API de Direct do ExtJS, porque a fronteira dessa definição não é claro sob esse aspecto. O Direct força o seu server-side a se ajustar ao client-side quando deveria ser o contrário.

Até a versão 3 voce precisava renderizar o JSON para uma estrutura definida pelo ExtJS nos forçando a fazer coisas assim [como o Responder abaixo] e deixando a fronteira novamente ambígua.

module Sencha
    class Wrapper
        attr_accessor :data, :total
    end

    class Responder < ActionController::Responder

        attr_reader :controller, :request, :format, :resource, :resources, :options
        def initialize(controller, resources, options={})
            super
            @controller = controller
            @request = @controller.request
            @format = @controller.formats.first
            @resource = resources.last
            @resources = resources
            @options = options

            @only = options.delete(:only)
            @include = options.delete(:include)
@methods = options.delete(:methods)
        end

        def to_format
            to_sencha if @format == 'sencha'
            super
        end

        def to_sencha
            ActiveRecord::Base.include_root_in_json = false
            total = 1
            total = @resource.total_entries if @resource.respond_to?(:total_entries)

            if(@resource.respond_to?(:errors) && @resource.try(:errors).size > 0)

                model = @resource.class.name.camelize(:lower)
                @errors = { :attributes => {}, :base => @resource.try(:errors)[:base]}
                @resource.errors.each do |attr, msg|
                @errors[:attributes]["#{attr}"] ||= []
                    @errors[:attributes]["#{attr}"] << msg
                end
                render :json => {:success => 'false', :message => "", :errors => @errors},
                      :status => :unprocessable_entity
                      #, :location => @resource
            else
                sencha = {
                    :data => @resource, :total => total, :success => true, :message => ""
                }
                @params = { :include => @include, :methods => @methods }
                render :json => sencha.to_json( @params )
            end

        end

    end

end

Hoje na versão 4x o Framework trabalha com JSON padrão e voce não precisa modificar o seu Responder para satisfazer o que seja.

Existem estratégias para voce contornar essa limitação ou comprar a licença comercial caso queira fechar modificações nas ferramentas sob a licença GPL3.

Mas Como a Sencha Ganha Dinheiro Então?

Treinamentos, consultorias e outros serviços já são o nicho de negócio principal, imagino. Mas…

Se voce construir uma customização ou novo componente sob a licença comercial, ninguém pode usar ou distribuir essa sua modificação, é aí que a licença comercial entra e é muito justo.

tl;dr

Resumindo, se voce usa ExtJS sob GPL3 voce tem que deixar todo o código que dependa dele sob a mesma licença, mas somente o código que dependa dele.

Posted in cearajs, Ext, sencha, Software Livre ~ 3 Comments

Pair Programming e o bem estar

{ April 18th, 2012 }


cmilfont

Autor: cmilfont

Depois de um pareamento eu sempre tive o sentimento de esgotamento, verdadeira exaustão, aliado com uma sensação de dever cumprido. Mesmo cansado eu me sentia bem, mas não entendia o porquê.

Tom Rath e Jim Harter, pesquisadores do Gallup, chegaram a uma conclusão depois de tabular pesquisas para o livro “Wellbeing: The Five Essential Elements” ["Bem-estar: os cincos elementos essenciais", numa tradução livre] que em todas as situações pesquisadas as pessoas precisavam de pelo menos 6 horas por dia de socialização para se sentirem realizadas (bem), para cada hora de acréscimo seu humor fica melhor e para cada hora de decréscimo ele piora. A partir de 6 horas já não fazia diferença alguma, além de alguns pontos a mais como: socializar com mais de 3 pessoas diariamente  diminui o índice de bom humor e é o dobro do tempo que os especialistas em comportamento consideravam necessário.

Na nossa área existe uma teoria de que, por sermos Nerds, nós não nos socializamos. Pelo contrário, sessões de RPG por exemplo são mais intensivas do que horas de baladas e curtição na praia, são somente formas diferentes. O livro não indica a forma de socialização, nem se pode ser virtual (via Social Networks) ou face-a-face, apesar de que gerações diferentes tem suas preferências (óbvio).

Pois bem, nossas sessões de Pair Programming são em média por volta de 6h, temos garantido (segundo a psicologia) nosso grau de socialização diária para nos sentirmos bem. Outro benefício do PP que a psicologia agora nos dá uma explicação.

Jesus já recomendava:

E depois disto designou o Senhor ainda outros setenta, e mandou-os adiante da sua face, de dois em dois, a todas as cidades e lugares aonde ele havia de ir. Lucas 10:1

Posted in Melhores práticas, Metodologia, Métodos Ágeis, XP ~ 3 Comments

Workshop Agile

{ April 3rd, 2012 }


cmilfont

Autor: cmilfont

Após o post que escrevi sobre erros comuns ainda hoje de modelagem feitos principalmente na comunidade Java - mas não limitados a essa comunidade,  choveram de dúvidas de clientes e desenvolvedores próximos sobre quais as melhores práticas e como desenvolvemos.

Apesar de um tema com bastante bibliografia, muito material na internet e já uma certa maturidade no mercado nós notamos que ainda há um fosso enorme entre a realidade dos projetos atuais e a aplicação dessa teoria, principalmente um treinamento com um sentido mais prático.

Ainda não há uma base consistente e sólida de treinamentos e materiais sobre experiências reais e projetos que deram ou não certo.

Frente a isso nós formatamos um Workshop para responder todas essas indagações com um treinamento voltado ao “como fazer”, direto ao ponto, demonstrando a teoria “by the book” em um projeto de verdade com todas as situações que nos fazem relegar boas práticas e tornam o desenvolvimento tão caro e muitas vezes ineficaz.

Juntei o material de cursos passados, demos uma repaginada com a experiência dos últimos anos, o que funcionou e principalmente não funcionou para responder a todas as perguntas possíveis em um espaço relativamente curto de tempo, mas precisamente focado.

Se tiver interesse de participar, vá lá e se inscreva, faremos de tudo para deixá-lo apto a entender todo o ciclo de desenvolvimento moderno. Um curso para todos os níveis. Uma imersão no Ágil.

Posted in Behaviour Driven Development, Engenharia de Software, Melhores práticas, Metodologia, Métodos Ágeis, Test Driven, XP, xpce ~ No Comments