Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

quinta-feira, 30 de julho de 2009

Adequar-se ao sono do funcionário pode ser rentável para empresas

Até pouco tempo, as empresas estipulavam a escala de trabalho e o funcionário a cumpria, sem ao menos questionar ou sugerir uma alternativa para adequar suas necessidades físicas e psicológicas às empresariais.

As novas possibilidades que o mercado de trabalho apresenta e a mudança de perfil dos empresários estão mudando esse quadro. Adequar-se às necessidades fisiológicas do funcionário pode ser uma alternativa para as empresas que buscam melhores resultados profissionais.

"É importante que os empresários entendam que há pessoas matutinas, ou seja, que podem entrar mais cedo no trabalho, pois não terão problemas para acordar. No entanto, outra parcela, é vespertina, e terá melhor rendimento a partir do final da manhã para a tarde e a noite.

O que não significa que os vespertinos são preguiçosos ou os matutinos, trabalhadores, é apenas uma questão orgânica", explica o Prof. Dr. Luis Vicente Franco Oliveira, Coordenador do Laboratório do Sono da Universidade Nove de Julho – UNINOVE.

Trabalhar a noite, para uma pessoa que não se adapta ao turno, ou vice-versa, pode ser um grande risco, pois, a sonolência faz com que o profissional tenha uma redução dos reflexos, diminua a capacidade de concentração e criatividade, aumente a fadiga, nível de estresse, e, consequentemente, os riscos de acidentes no ambiente de trabalho e no trânsito são maiores.

Atualmente, algumas empresas já oferecem um espaço e período de descanso para o funcionário. Meia hora pode ser suficiente para a recomposição física e psicológica. Além de ter um ganho no rendimento profissional, a empresa pode deixar de perder monetariamente, afinal, funcionário afastado ou acidentado, gera alto custo.

Por Aline Alves - Casa da Notícia Comunicação

quarta-feira, 29 de julho de 2009

Hibernate e seus ResultTransformers

Esse é um ótimo artigo sobre os ResultTransformers do hibernate escrito por Ricardo Wendell em seu blog, Toca do Calango.

Link do post original em : http://tocadocalango.wordpress.com/2008/05/06/hibernate-e-seus-

resulttransformers/

 

Creio que a maioria dos desenvolvedores Java alguma vez se deparou com o trabalhoso problema de persistir informações em um banco de dados relacional. E muitos deles descobriram no Hibernate uma (relativamente) simples e eficiente solução.

Este framework de mapeamento objeto-relacional tornou-se o padrão de facto para realizar o gerenciamento de entidades persistentes em aplicações Java (depois do fiasco dos Entity Beans), tendo muitas de suas idéias adotadas na especificação da JPA. Além da facilidade de definição dos mapeamentos e de uma completa API para a realização de consultas, um dos seus pontos fortes é a ótima documentação disponível.

Entretanto, existem algumas funcionalidades para as quais esta documentação é quase inexistente. E dentre elas temos os esquecidos, mas bastante úteis, transformadores de resultados.

O problema!

Para entender a utilidade deste recurso, considere a seguinte consulta de alunos utilizando HQL (os detalhes podem ser abstraídos sem maiores problemas):

 

  1. List resultado = session.createQuery("select matricula, nome, curso.nome from Aluno").list(); 
  2. ... 
...
List resultado = session.createQuery("select matricula, nome, curso.nome from Aluno").list();
...


Com esta simples projeção restringimos a busca e aumentamos a performance da consulta de todos os alunos persistidos. Entretanto, teremos como resultado final uma lista de Object[] que precisaria ser manipulada para extrair os diversos campos.



Esta manipulação podería ser um laço para percorrer a lista resultante e, para cada array de objetos, instanciar DTOs ou entidades. Simples, mas nada divertido…



Ou então poderíamos criar um construtor para aluno que aceite os parâmetros da consulta e substituir a query por "select new Aluno(matricula, nome, curso.nome) from Aluno" . Dessa forma teríamos uma lista de alunos pronta, mas que necessitaria de novos construtores a cada novo parâmetro necessário.



Para resolver problemas deste tipo é que vamos em busca dos ResultTransformers.



A interface ResultTransformer



Escondida na API do Hibernate existe uma interface que possibilita transformar o resultado de uma consulta, seja ela com Criteria, HQL ou SQL (o suporte aos dois últimos foi adicionado na versão 3.2) que utilize projeções em uma representação mais prática do que, por exemplo, uma lista de Object[]. Apresento então a pequena ResultTransformer:



 




  1. public interface ResultTransformer extends Serializable { 


  2. public Object transformTuple(Object[] tuple, String[] aliases); 


  3. public List transformList(List collection); 





public interface ResultTransformer extends Serializable {
public Object transformTuple(Object[] tuple, String[] aliases);
public List transformList(List collection);
}


Os dois métodos especificados são aplicados em diferentes momentos para transformar o resultado de uma query: transformTuple é chamado durante o processamento inicial do resultado, com acesso às colunas retornadas pela consulta e aos aliases especificados para cada uma delas (se existirem); no caso de transformList a chamada é imediatamente antes do Hibernate retornar o resultado de uma consulta.



Alguns transformadores prontos para usar



Mas de que adianta uma interface sem implementações, não é? Felizmente o Hibernate disponibiliza algumas classes prontas para serem usadas em seus projetos.



Voltemos ao nosso problema: como não ter trabalho para manipular o resultado de consultas com projeção?



A primeira opção é o AliasToBeanResultTransformer. Este transformador mapeia aliases (se você não sabe que o são alias, aguarde mais um pouco para entender com o exemplo) de colunas em atributos de objetos pertencentes à classe definida em seu construtor, populando-os através de métodos setters (via setter injection). A utilização pode ser vista no exemplo abaixo:



 




  1. ... 


  2. List<AlunoDTO> alunos = session 


  3.     .createQuery( "select matricula as matricula, nome as nomeAluno, curso.nome as nomeCurso from Aluno" ) 


  4.     .setResultTransformer(new AliasToBeanResultTransformer(AlunoDTO.class)) 


  5.     .list(); 


  6. ... 



...
List<AlunoDTO> alunos = session
.createQuery( "select matricula as matricula, nome as nomeAluno, curso.nome as nomeCurso from Aluno" )
.setResultTransformer(new AliasToBeanResultTransformer(AlunoDTO.class))
.list();
...


Comparando com o código original vemos algumas diferenças. A primeira é a utilização da palavra-chave “as”. Esta é a forma de definir aliases (apelidos) para as colunas que serão utilizados para popular instâncias da classe AlunoDTO através de setters no estilo setNomeAluno() ou setNomeCurso().



A segunda diferença é a chamada ao método setResultTransformer() da interface Query. Com ela é possível determinar uma estratégia de transformação de resultados de acordo com a necessidade da consulta. Neste caso, informamos uma instância de AliasToBeanResultTransformer, definido para transformar as colunas em objetos do tipo AlunoDTO.



Como alternativa para a criação de DTOs ou de métodos setters em entidades podemos utilizar o AliasToEntityMapResultTransformer. Com ele a lista de tuplas será transformada em uma lista de mapas, onde cada cada um deles terá um conjunto de entradas alias => valor_da_coluna. Dessa forma temos uma representação mais fácil de ser manipulada do que a original.



Logo abaixo vê-se um exemplo de seu emprego:



 




  1. ... 


  2. List<Map<String,Object>> mapaAlunos= session 


  3.     .createQuery( "select matricula as matricula, nome as nomeAluno, curso.nome as nomeCurso from Aluno" ) 


  4.     .setResultTransformer(new AliasToEntityMapResultTransformer()) 


  5.     .list(); 


  6. ... 



...
List<Map<String,Object>> mapaAlunos= session
.createQuery( "select matricula as matricula, nome as nomeAluno, curso.nome as nomeCurso from Aluno" )
.setResultTransformer(new AliasToEntityMapResultTransformer())
.list();
...


Viram como este recurso pode ser útil? Além destes dois apresentados existem mais transformadores que podem ser utilizados em outros casos, como o DistinctRootEntityResultTransformer, empregado para evitar duplicidade de entidades no resultado. E se ainda não for suficente, sempre é possível criar novas estratégias implementando a interface ResultTransformer.

Trabalhar sob pressão!!!

Sob pressão, as pessoas funcionam melhor ou pior? Veja opinião de especialista!

Por Karin Sato – InfoMoney

"Alguma pressão é necessária, uma vez que o ser humano tem a tendência de se acomodar", diz especialista.

Existem pessoas que trabalham melhor sob pressão. Mas é uma minoria. Quem garante é Flavia Garbo, gerente de Desenvolvimento Organizacional da Luandre - Soluções em Recursos Humanos.

"Acredito que é preciso separar a pressão das ações de incentivo. Por exemplo, ações como a do "funcionário do mês" são motivacionais e em nada se comparam com o terrorismo exercido por alguns gestores, que ficam infernizando a vida do funcionário e cobrando metas inatingíveis", explica.

"Alguma pressão é necessária, uma vez que o ser humano tem a tendência de se acomodar. Existe aí uma zona de conforto, na qual as pessoas acabam se apoiando", acrescenta.

Pressão boa ou ruim?

Segundo a especialista, um dos pontos que determinam o comportamento opressor do líder é a meta. "Para motivar, a meta deve ser atingível e desafiadora. Quando é inatingível, ocorre uma pressão que é desnecessária".
A maneira de se comunicar também indica se o gestor já passou dos limites.
Gritar, ameaçar de demissão e humilhar já indicam assédio moral.

Consequências da pressão

Essa pressão desnecessária, na maioria das pessoas, causa estresse e esgotamento. "O efeito é o oposto do esperado. Se a pressão é por prazo, a empresa perde em qualidade. Se é por qualidade, pode perder em prazo", afirma.

Quando um profissional passa muito tempo sob pressão, sua produtividade cai vertiginosamente, de acordo com Flavia. "Justamente para combater o estresse, muitas empresas contam com programas de qualidade de vida para seus funcionários".

Ela lembra que alguns profissionais estressados chegam a desenvolver problemas de saúde, como gastrite, dor de cabeça e insônia. "Como resultado, o nível de absenteísmo [ausência no trabalho] aumenta".

A gerente de Desenvolvimento Organizacional alerta ainda que o profissional pode vir a sofrer a chamada Síndrome do Burnout, termo que, em inglês, significa "acabar-se em chamas". Trata-se de um desgaste provocado pelo trabalho, que causa profundo sentimento de exaustão, frustração e raiva.

quinta-feira, 16 de julho de 2009

Vagas Java/WEB para Maringá (PR) e Campinas(SP)

A Matera está com 40 vagas abertas para desenvolvedores Java/Web, nos níveis júnior, pleno e sênior para as unidades da empresa nas cidades de Maringá (PR) e Campinas (SP).

Os profissionais selecionados deverão atuar em projetos de desenvolvimento de software de grande porte. Os principais requisitos para preenchimento das vagas são: formação superior completa na área de informática ou correlatas e experiência nas áreas de desenvolvimento Java para Web, JBoss 4.x, EJB3 e JPA e JSF.

Além disso, serão considerados diferenciais os candidatos com experiência em desenvolvimento com frameworks ICEFaces ou RichFaces e JBoss Seam e certificações SCJP, SCWCD e SCBCD serão consideradas um diferencial no processo de seleção.

Mais informações em http://www.matera.com/br/cont-empresa-vagas.html

sábado, 11 de julho de 2009

Dicas e truques para HIBERNATE JPA

Seguinte galera, as dicas retiradas do site http://shrubbery.mynetgear.net a seguir são muito importantes, e pode evitar muita dor de cabeça na hora de usar o hibernate para implementar a especificação jpa em seu projeto.

Fetch strategies and types

In native Hibernate, many-to-one association are lazy by default. This means that selecting a list of objects with an HQL query will not initialize the objects at the other end of the many-to-one association. In JPA the default fetch type is eager (i.e. non-lazy), with separate selects. This means that any JPAQL query for an entity that has many-to-one associations in it will result in an N+1 SELECTS problem even if those associations are not used. To eliminate the unnecessary queries, simply set the fetch type to LAZY using:

@ManyToOne(fetch=FetchType.LAZY)


Then, in any JPA query the association can be eagerly fetched using left join fetch.





Optimistic Locking



When optimistic locking is enabled for the parent and child entities in a typical parent-child relationship the parent will be optimistically locked whenever a child is added or removed from the parent's collection of children. That is, when a child is added the @Version attribute of the parent is incremented. In a highly concurrent system this may lead to some unnecessary contention and therefore lots of optimistic locking exceptions.



To disable the propagation of optimistic locking from child to parent, use:



@OptimisticLock(excluded = true)


Note that this can control the optimistic lock propagation on either association: parent->child or child->parent. When using this annotation it is important to think about what the behavior should be for your application.



Here is an example of disabling optimistic lock propagation in both directions:



public class Parent
{
...
private Set<Child> children = new HashSet<Child>();

@OneToMany(mappedBy = "parent", cascade = {CascadeType.ALL})
@OptimisticLock(excluded = true)
public Set<Child> getChildren()
{
return children;
}
...
}

public class Child
{
...

@ManyToOne
@OptimisticLock(excluded = true)
public Parent getParent()
{
return parent;
}
...
}




Typical Mappings




Basic Entity with a Surrogate Key


Most entities will have a Surrogate Key, and some other attributes. Basic entities have the @Entity and @Table annotations on the class and the @Id, @GeneratedValue, and @Columnannotations on the ID property.



@Entity
@Table(name = "thing")
public class Thing {
private Long id;

@Id
@GeneratedValue
@Column(name = "id")
public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}
}



Collection of Primitives


Hibernate can map collections of primitives (Strings, Dates, even enums) to Java collections directly. This can be very convenient when an entity would be a very 'heavy' solution. This requires:




  1. A table to store the collection elements, with a foriegn key back to the parent.


  2. @JoinTable to map the Java collection to the appropriate rows in the table.


  3. Hibernate's proprietary @CollectionOfElements annotation.



For example, here is a User object with a sorted set of roles (enum):



@Entity
@Table(name = "user")
public class User {
...

private SortedSet<Role> roles = new TreeSet<Role>();

...

/**
* The roles for this user.
*
* @return the roles for the user
*/
@CollectionOfElements(fetch = FetchType.LAZY)
@Enumerated(EnumType.STRING)
@Sort(type = SortType.NATURAL)
@JoinTable(name = "userroles",
joinColumns = {@JoinColumn(name = "userid")})
@Column(name = "role", nullable = false)
public SortedSet<Role> getRoles()
{
return roles;
}

public void setRoles(SortedSet<Role> roles)
{
this.roles = roles;
}

...
}



Parent->child using a Set


To make a bidirectional relationship where the 'many' side is fully dependent on the 'one' side, use:




  • @OneToMany in the parent, with the mappedBy attribute set to the name of the property in the child class that refers back to the parent.


  • Use cascade = {CascadeType.ALL} on the @OneToMany to automatically insert children if they are added to the parent's set of children (no need to call entityManager.persist() on the children).


  • Use @ManyToOne on the child's backpointer.


  • You can name the foriegn key column and the foreign key constraint in the child class using @JoinColumn and @ForeignKey respectively. NOTE: Make sure your foriegn key constraint name is unique in the schema. Most databases won't allow you to have two constraints with the same name (duh).


  • DON'T FORGET! The Child class needs to define hashCode() and equals() in a way that does not use the surrogate key!



public class Parent
{
...
private Set<Child> children = new HashSet<Child>();

@OneToMany(mappedBy = "parent", cascade = {CascadeType.ALL})
public Set<Child> getChildren()
{
return children;
}
...
}

public class Child
{
...

@ManyToOne
public Parent getParent()
{
return parent;
}
...
}



Splitting an Entity using Embedded


When an entity has many properties, Java programmers usually want a fine grained domain model while the DBA may want a more coarse grained database schema. For this situation, the groups of related columns can be bundled using an embedded mapping.



@Entity
@Table(name = "user")
public class User {
private Long id;
private UserSettings settings;
private ContactInfo info;

@Id
@GeneratedValue
@Column(name = "id")
public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}

@Embedded
public UserSettings getSettings()
{
return settings;
}

public void setSettings(UserSettings settings)
{
this.settings = settings;
}

@Embedded
public ContactInfo getContactInfo()
{
return contactInfo;
}

public void setContactInfo(ContactInfo info)
{
this.contactInfo = info;
}
}


The embeddable objects:



@Embeddable
public class UserSettings implements Serializable
{
private boolean hasCheezburger;

@Column(name = "cheezburger", nullable = false)
public boolean isHasCheezburger()
{
return hasCheezburger;
}

public void setHasCheezburger(boolean cheebaga)
{
this.hasCheezburger = cheebaga;
}
}

@Embeddable
public class ContactInfo implements Serializable
{
private String jabberId;

@Column(name = "jabber", nullable = false)
public String getJabberId()
{
return jabberId;
}

public void setJabberId(String jabberId)
{
this.jabberId = jabberId;
}
}


In this case the "user" table has "id", "cheezburger" and "jabber" columns, but the columns are mapped to three different Java objects.





Null values


NOTE: When all of the values in an @Embedded object are null, Hibernate will set the field in the parent object to null. This can lead to NullPointerExceptions if not handled correctly. There are two ways to handle this:




  1. Make sure code that calls the @Embedded getter handles null return values.


  2. Add a non-nullable field to the embedded object, thus avoiding the behavior entirely.




Splitting an Entity using OneToOne


Sometimes a more fine grained model for both the db schema and the Java object model is more appropriate. In this case the two tables have the same primary key.



@Entity
@Table(name = "user")
public class User {
private Long id;
private UserSettings settings;
private ContactInfo info;

@Id
@GeneratedValue
@Column(name = "id")
public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}

@OneToOne(fetch = FetchType.LAZY)
@PrimaryKeyJoinColumn
public UserSettings getSettings()
{
return settings;
}

public void setSettings(UserSettings settings)
{
this.settings = settings;
}

public UserSettings addSettings()
{
UserSettings s = getSettings();
if (s == null)
{
s = new UserSettings();
s.setId(id);
setSettings(s);
}
return s;
}

}


The one-to-one object:



@Entity
@Table("user_settings")
public class UserSettings implements Serializable
{
private Long id;
private boolean hasCheezburger;

@Id
@Column(name = "id")
public Long getId()
{
return id;
}

public void setId(Long id)
{
this.id = id;
}

@Column(name = "cheezburger", nullable = false)
public boolean isHasCheezburger()
{
return hasCheezburger;
}

public void setHasCheezburger(boolean cheebaga)
{
this.hasCheezburger = cheebaga;
}
}



Optimizations




  • Don't optimize simple code that is "good enough".


  • Measure performance before optimizing - Use a profiler. If something doesn't show up in the profiler, leave it alone.




N+1 SELECTs


Usually this happens when the UI displays a table of entities, where the entities have lazy many-to-one associations that are navigated in Java code. By default, there will be one select for the main query, and one select for each entity returned for each many-to-one association. If there are many entities, this will bombard the database with queries.




  1. Use left join fetch - Fetch the entities up front in the main query.


  2. Use batch size - Set an appropriate batch size for collections and entities. When one entity in an association is lazily loaded, Hibernate will pre-fetch other instances of that same entity that have proxies in the Persistence Context (Session).


  3. Use side-effect queries - Execute JPAQL queries to initialize the entities that will be referenced, discarding the results.




Over fetching


In a typical, 'real world' application there will be lots of entities and lots of @ManyToOne associations. By default, JPA interprets @ManyToOne as an eagerly fetched relationship, so when any business logic fetches that entity, all the @ManyToOne entities are fetched as well. This may cause unexpected performance problems when updating entities rapidly or displaying data in a table.



Solutions:




  1. Use lazy loading




Partial updates


In some cases, the business logic needs to update only a few properties of an entity. The usual sequence results is something like this:




  1. Thing x = em.find(Thing.class,id); Find by id. Hibernate issues a SELECT<tt> for the entity (and any non-lazy many-to-one entities), and remembers the original values.


  2. <tt>x.setSomeProperty(value); Set the property.


  3. Transaction commits, triggering em.flush(). Hibernate compares new values to the old values. Issues an UPDATE for all persistent properties of x.



Most of the time the business logic will update lots of properties of many different entities, but when only one property is being updated there is some unnecessary overhead. The overhead can be almost completely eliminated by using batch update statements (even though we aren't updating a batch of entities). The previous example could be re-coded as:



  Query q = em.createQuery("update from Thing t set t.someProperty = :propVal where t.id = :id")
.setProperty("propVal",value)
.setProperty("id",id);
q.executeUpdate();


This has the following advantages:




  • No SELECTs. No memory used to store the original values.


  • The UPDATE is for only one column.


  • No comparison with the original values.



However, it is important to remember the following:




  • If there is other code that works with the entity, even in the same PersistenceContext / Session, it will not see the change.


  • Check the return value of executeUpdate() to make sure the expected number of rows were updated.