Geração de Valor

Hoje vi esta mensagem no facebook e resolvi disponibilizá-la aqui por ser mais fácil de editar e divulgar. Simplesmente um espetáculo.

Tudo pode ser conferido no seguinte link: http://goo.gl/O4voQ. 

Aqui segue apenas o resumo da conversa.

Henrique Duarte Coelho perguntou:

Flávio, há algum mal ao pensar em dinheiro?

Qual é a sua visão em relação a trabalhar para ganhar dinheiro e usufruir dos benefícios que ele pode proporcionar? 

Lógico, não estou falando na situação extrema de idolatrar o dinheiro, mas de pensar que tê-lo é uma das coisas mais importantes pra ter proporcionar felicidade, não pelo fato de TER, mas por poder de fato usá-lo para viver e proporcionar bons momentos que o dinheiro compra?

Flávio respondeu:

Há uma frase muito conhecida que diz assim: "O amor ao dinheiro é a raiz de todos os males". Eu concordo 100% com ela, já que por dinheiro, as pessoas matam, sequestram, enganam, abandonam famílias, declaram guerras, fazem uma má gestão pública envolvendo-se em corrupção, dentre muitas ocorrências que testemunhamos todos os dias nos noticiários.

O dinheiro, não é de hoje, isso é coisa muito antiga mesmo, quando colocado no lugar errado, tem sido motivo para muitas discórdias e razão para muita infelicidade.

Isso porque o dinheiro desperta um fascínio muito grande no imaginário das pessoas. Elas contumeiramente se iludem que " quando eu comprar uma casa, eu vou ser feliz","quando eu ganhar tal salário, eu vou ser feliz", " quando eu ganhar na loteria, eu serei feliz"... E estudos mostram que não é assim que acontece. Ninguém se tornou feliz porque ganhou dinheiro. 

Esta ilusão faz com que muitos, depois de ganharem dinheiro, comprar a casa, o carro, conquistar o salário desejado, caiam num vazio e depressão. A renda no Brasil sobe a cada ano, mas o uso de antidepressivos também. Os consultórios psicológicos têm uma grande demanda, num contexto de prosperidade e aumento no entretenimento. A cada ano, os filmes são mais fantásticos, os video games são excepcionais e as opções para diversão incontáveis. Mas a população não está mais feliz por isso.

Voltemos a frase que eu digo que concordo 100% com ela: "O amor ao dinheiro é a raiz de todos os males". O problema está no AMOR ao dinheiro. eu costumo dizer: AME pessoas. USE coisas. O amor ao dinheiro representa uma das inversões de valores mais comuns na sociedade, transformando-a na porcaria que conhecemos. O problema não está no capitalismo, está nas pessoas e em seu relacionamento com o dinheiro. Usar pessoas e amar coisas, inclusive o dinheiro é uma aberração.

O dinheiro é um excelente empregado, mas um péssimo patrão.

Desejar ganhar mais dinheiro é legítimo. Ter como meta de vida ganhar mais dinheiro também é legítimo, mesmo sem o dinheiro ser a coisa mais importante em sua vida. Agora, adotar esta meta como o seu principal alvo é pensar muito pequeno. É cair no lugar comum da mediocridade, pois assim pensa a maioria e vc já sabe o que eu penso sobre estar na maioria...

Vou lhe explicar porque penso que este é um objetivo medíocre:

Ter esta meta como principal, não lhe sustentará nos momentos de dificuldades, nos momentos em que suas emoções forem desafiadas. Não lhe dará inspiração na hora da necessidade de uma renovação, na hora que vc encher o saco dos não's. Não lhe dará resistência depois do mileesimo quilômetro da maratona da vida. Ganhar dinheiro é legítimo, mas é uma meta muito pequena para sustentar as adversidades do meio do caminho, sacou?

Eu estou dizendo que a minha estratégia é a melhor, mas vou lhe contar como eu lido com isso e como funcionou, pois presumo que vc saiba que eu ganho muito dinheiro :)

Eu nunca trabalhei pra ganhar dinheiro. Eu sempre trabalhei pra conquistar pessoas, ajudá-las a alcançar os seus objetivos, colaborar com a mudança da vida delas. Eu sempre dei foco aos objetivos de quem me cerca e não nos meus. Mas a consequência matemática disso, foi eu conquistar tudo que eu conquistei.

Eu trabalhei para criar o melhor pacote de valor para quem quer aprender inglês para melhorar o seu salário, criei uma empresa onde as pessoas, através de seu preoprio mérito pudessem crescer e realizarem os seus sonhos, um modelo de franquias que um franqueado pudesse investir e recuperar rapidamente o seu capital. No meio disso tudo, montei uma equipe que eu formei de pessoas para AJUDAREM as pessoas (coaching) a realizarem tudo isso. Muitos fracassam, mas é possível e isso alimenta a vontade das pessoas. 

Eu me realizo com as realizações das pessoas. E todas as vezes que alguém tem sucesso dentro de nosso sistema, eu ganho como consequência.

Henrique, olhe mais para fora do que para dentro. No dia em que vc fizer isso, vc vai ganhar muito dinheiro, mas eu estou falando em MUITO dinheiro, muito mais do que as pessoss comuns desejam ganhar idolatrando ele. Gaste sua energia com motivos mais nobres. Esses motivos são capazes de lhe sustentar na hora da dificuldade.

Espero ter colaborado.

ABÇOS

Alternativa ao Glassfish e ao JBoss

No final do abril, o Apache lançou o TomEE, servidor de aplicação baseado no Tomcat 7 e no OpenEJB. Além de outras tecnologias, o maior destaque vai para o fato de que a Apache agora possui uma ótima alternativa para os pesados servidores de aplicações. Muita água ainda vai rola, mas isto mostra que os desenvolvedores Java começam a ter alternativas viáveis para "quando" a Oracle resolver fechar todas as portas de vez.

Ainda é cedo para dizer, mas ainda aposto no Scala como uma nova linguagem de fato proveitosa que irá substituir o Java (na construação de novas aplicações).

Link para saber mais sobre o TomEE: http://openejb.apache.org/index.html

Aristofânio

Agile na Real!

Com já discutido por Scott Ambler (poderia dizer, previsto por), e até que enfim,  alguém do mundo Agile reconheceu publicamente que existe o "Agile" não é fazer algo sem documentação ou trabalhar em pares... mas sim buscar eficiência dentro da sua realidade. 

O que se pode tirar de positivo disso é a evolução com que as discussões tomaram, passando inclusive pelo mundo acadêmico e até sendo adotado como uma boa solução por grandes empresas, mas com muita ponderação! Daí, logo a realidade veio a tona e consultores "evagelistas" queimaram-se no mercado por não fazer ou não saber fazer as coisas funcionarem corretamente como pregavam, sendo que outros deram passos para trás e procuraram criar meios, técnicas e metodologias diferentes, resultando em ótimos trabalhos.

De negativo, é que o mundo dos desenvolvedores ainda vive em busca de uma solução única para todos os problemas, vivem de ilusão baseadas em conversa de charlatões da "metodologia de desenvolvimento". A imaturidade e falta de consciência crítica de muitos acaba por criar ondas gigantescas para pequenos redemoinhos! Conheci alguns desses charlatões, que hoje mudaram o discurso e agora estão formando novos redemoinhos... vamos ver o que tiramos de proveito positivo e negativo das novas ondas que virão!

Salve Scott Ambler o maior Agile Profissional de verdade!

Link para sua leitura sobre este assunto: http://nobull.energizedwork.com/

Aristofânio

Scala com Spring: a primeira impressão

Spring, como é sabido pelos desenvolvedores Java, é um framework escrito na linguagem Java e muito poderoso, estável e cujas funcionalidades auxiliam os programadores a escrever menos código. 

Assim, como é possível fazer programas desenvolvidos em Scala interoperarem com programas desenvolvidos em Java, então também é possível construir uma aplicação em Scala totalmente integrada com Spring. Para tanto existem algumas observações, que precisam ser consideradas. O objetivo aqui não é discutir se isto é ou não viável, mas sim como fazer isto de forma simples e mantendo a experiência do desenvolvedor.

Para começar vamos considerar uma Entidade chamada de Order que deverá ser mantida em um banco de dados PostgreSQL. Supondo que você tenha um Projeto Scala preparado com todas as bibliotecas e dependências do Spring (cujos JARs estão em lib), o arquivo de configuração terá o seguinte conteúdo:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:tx="http://www.springframework.org/schema/tx"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd

http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.1.xsd">

<!-- DataSource -->

<bean id="datasource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName" value="org.postgresql.Driver" />

<property name="url" value="jdbc:postgresql://localhost:5432/db_scala" />

<property name="username" value="postgres" />

<property name="password" value="123456" />

</bean>

<!-- Hibernate Configuration-->

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">

<property name="dataSource" ref="datasource" />

<property name="hibernateProperties">

<props>

<prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</prop>

<prop key="hibernate.show_sql">true</prop>

<prop key="hibernate.format_sql">true</prop>

<prop key="hibernate.use_sql_comments">false</prop>

</props>

</property>

<property name="annotatedClasses">

<array>

<value>...</value>

</array>

</property>

</bean>

<!-- Transaction management -->

<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager" >

<property name="sessionFactory" ref="sessionFactory" />

</bean>

<!-- Instruct Spring to perform declarative transaction management automatically on annotated classes. -->

<tx:annotation-driven transaction-manager="transactionManager" mode="proxy"  />

</beans>

O objeto que repesentará o pedido "Order" terá uma identidade que em outro momento utilizaremos como EmbededId. Por enquanto basta termos:

/** 

  * Representa a identidade de uma entidade

  */

case class Identity(companyId:String, domObjId: String)

/**

  * Pedido

  */

@Entity

case class Order(identity:Identity){

  @Id

  private var id = identity.domObjId

}

Para realizar as operações de CRUD, construíremos um DAO (Data Access Object pattern), o qual terá o seguinte conteúdo:

class OrderRepositoryImpl(sf:SessionFactory) {

  private val hibernate:HibernateTemplate = new HibernateTemplate(sf)

  

  def save(obj:Order){

    hibernate.saveOrUpdate(obj)

  }

  

  def remove(obj:Order){

    hibernate.execute(new HibernateCallback[Unit](){

      override def doInHibernate(session:Session) = {

        val query = session.createQuery("delete from Order o where o.companyid = :companyid and o.code = :code")

        query.setParameter("companyid", obj.identity.companyId)

        query.setParameter("code", obj.identity.domObjId)

        query.executeUpdate()

      }

    })

  }

  

  def removeAll(){

    hibernate.execute(new HibernateCallback[Unit](){

      override def doInHibernate(session:Session){

        val query = session.createQuery("delete from Order")

        query.executeUpdate()

      }

    })

  }

  def find(id:Identity):Order = {

    hibernate.execute(new HibernateCallback[Order](){

      override def doInHibernate(session:Session):Order = {

        val query = session.createQuery("select o from Order o where o.companyid = :companyid and o.code = :code")

        query.setParameter("companyid", id.companyId)

        query.setParameter("code", id.domObjId)

        query.uniqueResult().asInstanceOf[Order]

      }

    })

  }

 

  def findByCriteria(criteria: Criteria):List[Order] = {

   import scala.collection.JavaConversions._

    hibernate.execute(new HibernateCallback[List[Order]](){

      override def doInHibernate(session:Session):List[Order] = {

        val c = DetachedCriteria

        .forClass(Order.getClass())

        .getExecutableCriteria(session)

        c.list().asInstanceOf[List[Order]]

      }

    })

  } 

  

}

Algumas observações, aqui já para iniciar: 

1) Scala possui Collections próprias, sendo que o Spring trabalho com as Collections do Java. Para compatibilizar é necessário importar a seguinte biblioteca:

import scala.collection.JavaConversions._

2) O session factory será passado pelo construtor no Spring, portanto a :

class OrderRepositoryImpl(sf:SessionFactory) {...

Com estas operações definidas será possível realizar o nosso CRUD sobre Order utilizando OrderRepositoryImpl cujo SessionFactory será injetado pelo Spring. Mas não para por ai. Para realizar os testes será utilizado o ScalaTest Framework. E o conteúdo do caso de teste será:

class OrderTest extends FunSuite {

  

  var i = new Identity("co0001", "or0001")

  var o = new Order(i)

  

  test ("salvar o pedido") {  

    //na pasta src dentro de META-INF, encontra-se o arquivo de configuração do spring

    val context = new ClassPathXmlApplicationContext("META-INF/ag-shoppingmanager-core.xml")

    val bean = context.getBean("orderRepository")

    //verificação antes da remoção

    bean.asInstanceOf[OrderRepositoryImpl].save(o)

    //verificação antes da remoção

    val e = bean.asInstanceOf[OrderRepositoryImpl].find(i)

    //teste

    assert(e != null)

  }

  

...

}

object OrderTestMain {

  def main(args: Array[String]) {

 Runner.main(Array[String]("-p", "scalatest-1.7.2-tests.jar", "-o", "-s",  "br.com.arigarcia.shoppingmanager.core.OrderTest"));

  }

}

Pronto...  realizado o teste você poderá verificar que os testes se sairão perfeitamente. Mas como foi dito no inicio segue algumas observações:

1) A utilização de List (do Scala) poderá criar uma complexidade sem nenhuma vantagem;

2) As anotações de @Id e @Column só podem ser feitas diretamente nos atributos e não em parametros, logo não será possível utilizar um construtor personalizado para a entidade no Scala de uma forma mais elegante, sendo necessário a redundância de dados, ou, se optar por remover o construtor personalizado, construir um "ScalaBean" (similar ao JavaBean, para a linguagem Java).

3) Os atributos que possuem Enumerations devem ser repensados para serem convertidos em String manualmente ou então terá que construir um conversor implicito personalizado para resolver este problema.

Por enquanto é só! Com certeza terá mais problemas... a questão é avaliar qual o benefício de interoperar estas aplicações: 

- O que o Scala faz que Java não faz?

- Em que realmente o Scala é melhor que Java?

- Compensa estudar tanta complexidade para simplesmente utilizar Scala ou é melhor utilizar Java?

Existem outros problemas no que se refere a produtividade, não por causa da linguagem em si, mas por causa da falta de ferramente que auxilie a encontrar problemas mais rapidamente (o eclipse ainda está muito imaturo, mas é o mais maduro dentre os que testes - netbeans, intelij, emacs, e mais outras 2 que não lembro o nome agora).

Até o final desse projeto passarei mais informações sobre desenvolvimento com Scala.

Até lá!

Scala: conversões implicitas

Hoje em discussão com colegas aqui na empresa percebi que existe algo interessante na linguagem Scala que merece ser citado, aproveitando o raciocínio de ontem: a Conversão Implicita.

A melhor forma de apresentar isto é fazendo uma demonstração. Então criamos duas classes que se referem ao tipo geral, automóvel (conceitualmente), porém não correlacionadas diretamente (através herança, por exemplo), logo é de se supor que seja possível criar algo do tipo:

def fiatUnoMy(b:FiatUno){

    ...

    println(b.my())

}

onde, 

class Automovel() {

  val name = "FiatUno"

  def my():String = "Is my FiatUno"

}

class FiatUno(name:String) {

  def getName() = name

}

Bem... então a primeira vista algum pode até imaginar que a linguagem é possui alguma inteligência ou que o método my() é um membro de qualquer classe. Porém, nenhum destes pensamentos é verídico. Esse fato expetacular ocorre porque o FiatUno é convertido implicitamente em um Automóvel. Como? Ai está o legal da história! Utilizando-se do mecanismo de "Implicit Convertion". Explicando em miudos: através deste mecanismo é possivel ter uma classe A (de automóvel) que possui um método x, cuja instrução A.x é possível. Uma outra classe, independente de A, chamada de F (de fiat uno), não poderá, então realizar a operação F.x, dado que x mão é um membro de F. Para isto é necessário transformar A em F, ou seja, tornar A = T(F) . E isto é feito através de uma função chamada implicitamente pelo compilador, levando a situação T(F).x.  Será que este assunto não é familiar para você? (para quem estudou Algebra, com certeza!). Em Scala, esta transformação é feita da seguinte maneira:

  ...

  implicit def convertToAutomovel(f: FiatUno) = new Automovel()

  implicit def convertToFiatUno(a: Automovel) = new FiatUno("New Fiat Uno")  

  ...

Com isto é possível termos:

def fiatUnoMy(b:FiatUno){

    println(b.getName)// print: New Fiat Uno

    println(b.name)//print: Fiat Uno

    println(b.my())//print: Is my FiatUno

}

Isto é show demais!!

Bem, por agora é só! Até a próxima.