OPORTUNIDADE DE ESTÁGIO

A Hive.log S/A, empresa de tecnologia da informação aplicada a logística, está à 
procura de candidatos a estágio na área de DESENVOLVIMENTO DE SISTEMAS.
PRINCIPAIS ATRIBUIÇÕES
 Detalhar a especificação de uma parte da funcionalidade do sistema, descrevendo 
um ou vários casos de uso e outros requisitos de software de apoio
 Desenvolver e testar componentes de acordo com os padrões adotados para o 
projeto
 Conduzir os testes necessários e registrar os resultados desses testes
REQUISITOS ESSENCIAIS
 Estar regularmente matriculado em um curso de nível superior nas áreas de Ciência 
ou Engenharia da Computação
 Bom nível de conhecimento da língua inglesa
 Conhecimento de Java
 Conhecimento de SQL
REQUISITOS DESEJÁVEIS
 Conhecimento de HTML, JavaScript e Ajax
 Conhecimento dos Frameworks GWT, Struts, Spring e Hibernate
 Conhecimento da API JSP/Servlets
 Conhecimento das APIs JAX-WS, SAAJ, JAXP (Web Services)
 Conhecimento da IDE Eclipse
DADOS DO ESTÁGIO
Carga Horária: 25 horas semanais (5 hrs/dia)
Valor da Bolsa: R$ 835,00
Carga Horária: 30 horas semanais (6 hrs/dia)
Valor da Bolsa: R$ 1.000,00
Os interessados devem enviar e-mail para oportunidades@hivelog.com.br, com o 
assunto “SELEÇÃO DESENVOLVIMENTO DE SISTEMAS” até o dia 30/04/2012, com o 
currículo atualizado.

Especificação de requisitos é realmente a parte mais importante de um projeto?

“O levantamento de necessidades e especificação de requisitos pode ser considerada a etapa mais importante do projeto de um sistema de informação”

Que atire o primeiro mouse quem nunca ouviu a frase acima. Mas será mesmo que podemos dizer que ela é verdadeira?

Bom, se me perguntarem, eu diria que “em partes”.

O levantamento de requisitos é uma parte extremamente importante em um projeto, contudo o responsável por essa atividade deve ter conhecimento não somente do negócio, mas da sua equipe, tecnologia a ser empregada e suas limitações. Por melhor que seja a especificação, esta por si só não poderá gerar valor (lucro) para o cliente, já que o produto com que este trabalha diretamente é o software. Fazendo uma analogia com o mercado da construção civil, os engenheiros e arquitetos devem fazer o levantamento das necessidades do cliente, projetando a obra e definindo um escopo. Esse levantamento tem valor para o cliente, o serviço é cobrado e o cliente receberá a documentação. Todavia, somente o projeto não satisfaz as necessidades do contratante. O cliente tem a tendência de ver como produto somente a parte funcional que lhe é entregue, e como é esta que será trabalhada diretamente, sua importância não deve ser considerada inferior ao do levantamento de requisitos.

Tão importante quanto realizar o levantamento das necessidades corretamente, é implementar essas necessidades da maneira ao qual foram especificadas. Para otimizar o processo as equipes de levantamento e implementação devem trabalhar em sintonia, de modo que tudo que seja especificado e documentado seja possível de ser implementado, respeitando-se as limitações da tecnologia, pessoal, entre outros. Algumas pessoas acreditam que de posse do levantamento, qualquer desenvolvedor poderá implementa-lo, mas isso não é exatamente tão simples. Mão de obra qualificada é um problema recorrente nas empresas de TI, além do fato de que certas funcionalidades “prometidas” na especificação podem não ser viáveis ou até mesmo impossíveis de serem realizadas por limitações de tecnologia e/ou verba ou prazo, por exemplo.

Por fim, a importância do levantamento de requisitos e da etapa de implementação não devem ser comparadas em uma escala de importância. Elas se auto complementam e devem caminhar juntas para que o produto final seja entregue com excelência.

E você, o que acha?

Fonte: Profissionais TI

Vaga Programador PHP

Galera,
 
A empresa Playlore desenvolve jogos e precisa de programador PHP.
 
Requisitos essenciais:
- Experiência com PHP (OO)
- Zend Framework
- API do Facebook
- Trabalhar em equipe
- MySQL
 
* Urgência para contratação
 
Quem tiver interessado enviar currículo para
brunodesouzaguiar@gmail.com
 
O salário é a combinar.
 
Abraço

Resolvendo Conflitos - SVN

Resolvendo Conflitos

De vez quando irás obter um conflito quando actualizares/fundires os teus ficheiros a partir do repositório, ou quando trocares a tua cópia de trabalho para um URL diferente. Existem dois tipos de conflitos:

conflitos de ficheiro

Um conflito de ficheiro ocorre quando dois (ou mais) programadores alteraram o mesmo punhado de linhas do ficheiro.

conflitos de árvore

Um conflito de árvore ocorre quando um programador move/renomeia/apaga um ficheiro ou pasta, que outro programador também moveu/renomeou/apagou ou apenas modificou.

Conflitos de Ficheiro

A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. Whenever a conflict is reported, you should open the file in question, and search for lines starting with the string <<<<<<<. The conflicting area is marked like this:

 <<<<<<< filename
  your changes
 =======
  code merged from repository
 >>>>>>> revision
 

Also, for every conflicted file Subversion places three additional files in your directory:

filename.ext.mine

This is the file that was theEste é o teu ficheiro como existia na cópia de trabalho antes de a teres actualizado - Isto é, sem marcadores de conflito. Este ficheiro tem as tuas últimas alterações a mais nada.

filename.ext.rOLDREV

Este é o ficheiro que foi a revisão BASE antes de actualizares a cópia de trabalho. Isto é, é o ficheiro que tu SVN exportaste antes de efectuares as tuas últimas alterações.

filename.ext.rNEWREV

Este é o ficheiro que o teu cliente Subversion acabou de receber do servidor, quando actualizaste a tua cópia de trabalho. Este ficheiro corresponde à revisão HEAD do repositório.

Podes então lançar uma ferramenta externa de fusão/editor de conflitos com TortoiseSVN → Editar Conflitos ou podes usar qualquer outro editor para resolver o conflito manualmente. Deves decidir a aparência do código, efectuar as alterações necessárias e guardar o ficheiro.
Posteriormente executa o comando TortoiseSVN → Resolvido e submete as tuas modificações para o repositório. Toma nota que o comando Resolvido, na realidade, não resolve o conflito. Apenas remove os ficheiros filename.ext.mine and filename.ext.r*, para te permitir submeter as tuas alterações.
Se tens conflitos com os teus ficheiros binários, o Subversion não tenta fundir os ficheiros. O ficheiro local permanece intocável (exactamente como o alteraste) e obtens os ficheiros filename.ext.r*. Se queres descartar as tuas alterações e manter a versão do repositório, usa o comando Reverter. Se queres manter a tua versão e reescrever a versão do repositório, usa o comando Resolvido e submete a tua versão.
Podes usar o comando Resolvido para ficheiros múltiplos, se clicares na pasta pai e seleccionares TortoiseSVN → Resolvido... Isto irá mostrar a caixa de diálogo listando todos os ficheiros em conflito nessa pasta, e podes seleccionar quais é queres marcar como resolvidos.

Conflitos de Árvore

Um conflito de árvore ocorre quando, um programador moveu/renomeou/apagou um ficheiro ou pasta que outro programador também moveu/renomeou/apagou ou apenas modificou. Existem muitas e variadas situações que podem gerar um conflito de árvore, e todas elas requerem diferentes passos para a sua resolução.
Quando no Subversion, um ficheiro é apagado localmente esse ficheiro também é apagado no sistema de ficheiros local e, mesmo que este seja parte de um conflito de árvore não poderá mostrar um ícone de conflito sobreposto, e tu não poderás clicar nele com o botão direito do rato para resolver o conflito. Usa então a caixa de diálogo Verificar alterações para aceder à opção Editar conflito.
O TortoiseSVN pode ajudar a encontrar o sítio correcto para fundir as alterações mas, poderá ser necessário trabalho adicional para resolver os conflitos. Lembra-te que após a actualização a revisão BASE de trabalho irá conter sempre a revisão de cada item como estava no repositório, na altura da actualização. Se reverteres uma alteração após a actualização esta voltará ao estado do repositório e não, à versão que estava quando começaste a efectuar as tuas alterações locais.

Apagar localmente, editar após actualizar

1. O programador A modifica Foo.c e submete-o para o repositório
2. O programador B simultaneamente move na sua cópia de trabalho Foo.c para Bar.c, ou simplesmente apagou Foo.c, ou a sua pasta pai.

Uma actualização na cópia de trabalho do programador B resulta num conflito de árvore:

• Foo.c foi apagado da cópia de trabalho, mas foi marcado como um conflito de árvore.
• Se o conflito resultou de, uma mudança de nome em vez de um apagar então, o Bar.c é marcado como adicionado mas não contém as modificações do programador A.

O programador B tem de escolher se vai manter as alterações do Programador A. No caso de uma mudança no nome do ficheiro, ele pode fundir as alterações com o Foo.c no ficheiro renomeado Bar.c. Para simples apagamentos de ficheiros e pastas, ele pode escolher manter o item com as alterações do Programador A e descartar o item apagado. Ou, ao colocar o conflito como resolvido, sem efectuar mais nenhuma acção, descarta efectivamente as alterações do Programador A.
A caixa de diálogo de edição de conflitos oferece-se para fundir as alterações, se conseguir encontrar o ficheiro original do renomeado Bar.c. Dependendo onde a actualização foi invocada, poderá não ser possível encontrar o ficheiro fonte.

Edição local, apagar após actualizar

1. O Programador A move Foo.c para Bar.c e submete-o para o repositório.
2. O Programador B modifica na sua cópia de trabalho Foo.c.

Ou em caso de mover uma pasta...

1. O Programador A move a pasta pai FooFolder para BarFolder e submete-o para o repositório.
2. O Programador B modifica na sua cópia de trabalho Foo.c.

Uma actualização da cópia de trabalho pelo programador B, resulta num conflito de árvore. Para um conflito de ficheiro simples:

• Bar.c é adicionado à cópia de trabalho como um ficheiro normal.
• Foo.c é marcado como adicionado (com história) e adquire um conflito de árvore.

Para um conflito de pasta:

• BarFolder é adicionado à cópia de trabalho como uma pasta normal.
• FooFolder é marcado como adicionado (com história) e adquire um conflito de árvore.
  Foo.c é marcado como modificado.

O programador B agora tem de decidir se quer manter a reorganização do programador A e fundir as suas alterações no ficheiro correspondente na nova estrutura, ou simplesmente reverter as alterações de A e manter o ficheiro local.
Para fundir as suas alterações locais com a remodelação, o Programador B deve em primeiro lugar descobrir o ficheiro para o qual Foo.c foi renomeado/movido no repositório. Isso pode ser feito usando a caixa de diálogo de registo. As alterações devem então ser fundidas manualmente já que não existe actualmente nenhum método para automatizar ou mesmo simplificar este processo. Uma vez que as alterações tenham sido portadas, o caminho em conflito fica redundante e pode ser apagado. Neste caso usa o botão Remover na caixa de diálogo de edição de conflito para efectuar a limpeza e, marcar o conflito como resolvido.
Se o programador B entende que as alterações de A estão erradas, então deve escolher o botão Manter na caixa de diálogo de conflito. Isso marca o ficheiro/pasta em conflito como resolvido, mas as alterações de A necessitam de ser removidas à mão. Mais uma vez a caixa de diálogo de registo irá ajudar a verificar o que foi movido.

Apagar localmente, apagar após actualizar

1. O Programador A move Foo.c para Bar.c e submete-o para o repositório.
2. O Programador B move Foo.c para Bix.c

Uma actualização na cópia de trabalho do programador B resulta num conflito de árvore:

• Bix.c é marcado como adicionado com história.
• Bar.c é adicionado à cópia de trabalho com o estado 'normal'.
• Foo.c é marcado como apagado e adquire um conflito de árvore.

Para resolver este conflito, o Programador B tem de descobrir para que nome o ficheiro em conflito Foo.c renomeado/movido no repositório. Isso pode ser feito recorrendo à caixa de diálogo de registo.
Então o programador B tem de decidir qual o novo nome de ficheiro do ficheiro Foo.c deve manter - o criado pelo programador A ou o nome criado pelo próprio.
Depois de o programador B ter resolvido o conflito manualmente, o conflito de árvore tem de ser marcado como resolvido, com o botão na caixa de diálogo editor de conflito.

Desaparecido localmente, editar após fusão

1. O Programador A trabalhando no trunk modifica então Foo.c e submete-o para o repositório.
2. O Programador B trabalhando no ramo move Foo.c para Bar.c e submete-o para o repositório.

A fusão das alterações no trunk do programador A para o ramo, da cópia de trabalho, do programador B resulta num conflito de árvore:

• Bar.c já está na cópia de trabalho com o estado 'normal'.
• Foo.c é marcado como desparecido, com um conflito de árvore.

Para resolver este conflito, o Programador B tem de marcar o ficheiro como resolvido na caixa de diálogo do editor de conflito, que irá remove-lo da lista de conflitos. Ele então tem de decidir se copia o ficheiro desaparecido Foo.c do repositório para a cópia de trabalho, se funde as alterações do Programador A no ficheiro Foo.c no renomeado Bar.c ou se ignora as alterações ao marcar o conflito como resolvido e não fazendo mais nada.
Tem em atenção que se copias o ficheiro desaparecido do repositório e depois marcas como resolvido, a tua copia será removida novamente. Tens de resolver primeiro o conflito.

Edição local, apagar após fusão

1. O Programador A trabalhando no trunk move o Foo.c para Bar.c e submete-o para o repositório
2. O Programador B trabalhando no ramo modifica o Foo.c e submete-o para o repositório.

Existe um caso equivalente para o movimento de pastas, mas não é ainda detectado no Subversion 1.6 ...

1. O Programador A trabalhando no trunk move a pasta pai FooFolder para BarFolder e submete-o para o repositório.
2. O Programador B trabalhando num ramo modifica Foo.c na sua cópia de trabalho

A fusão das alterações no trunk do programador A para o ramo, da cópia de trabalho, do programador B resulta num conflito de árvore:

• Bar.c é marcado como adicionado.
• Foo.c é marcado como modificado com um conflito de árvore.

O programador B agora tem de decidir se quer manter a reorganização do programador A e fundir as suas alterações no ficheiro correspondente na nova estrutura, ou simplesmente reverter as alterações de A e manter o ficheiro local.
Para fundir as suas alterações locais com a remodelação, o Programador B deve em primeiro lugar descobrir para que ficheiro o ficheiro em conflitoFoo.c foi renomeado/movido no repositório. Isto pode ser feito usando a caixa de diálogo do registo para a fonte da fusão. O editor de conflito apenas mostra o registo para a cópia de trabalho e não conhece qual o caminho que foi utilizado na fusão, pelo que terás de o descobrir por ti. As alterações têm então ser fundidas à mão, visto não existir nenhuma maneira de automatizar ou mesmo simplificar este processo. Uma vez que as alterações tiverem sido portadas, o caminho em conflito será redundante e pode ser apagado. Neste caso usa o botão Remover na caixa de diálogo editor de conflito, para limpar e marcar o conflito como resolvido.
Se o Programador B decide que as alterações do A estão erradas, deverá então escolher o botão Manter na caixa de diálogo editor de conflito. Isto marca o ficheiro/pasta em conflito como resolvido, mas as alterações do Programador A necessitam de ser removidas à mão. De novo a caixa de diálogo registo, para a fonte da fusão ajuda a encontrar o rasto ao que foi movido.

Apagamento local, apagar após fusão

1. O Programador A trabalhando no trunk move o Foo.c para Bar.c e submete-o para o repositório
2. O Programador B trabalhando num ramo move o Foo.c para Bix.c e submete-o para o repositório

A fusão das alterações no trunk do programador A para o ramo, da cópia de trabalho, do programador B resulta num conflito de árvore:

• Bix.c é marcado com o estado normal (não modificado).
• Bar.c é marcado como adicionado com história.
• Foo.c é marcado como desaparecido e adquire um conflito de árvore.

Para resolver este conflito o Programador B tem de descobrir para que ficheiro o ficheiro em conflito Foo.c foi renomeado/movido no repositório. Isto pode ser feito usando a caixa de diálogo registo na fonte da fusão. O editor de conflito apenas mostra o registo para a cópia de trabalho, e não tem conhecimento qual o caminho que foi usado na fusão, então tens de descobri-lo por ti.
Então o programador B tem de decidir qual o novo nome de ficheiro do ficheiro Foo.c deve manter - o criado pelo programador A ou o nome criado pelo próprio.
Depois de o programador B ter resolvido o conflito manualmente, o conflito de árvore tem de ser marcado como resolvido, com o botão na caixa de diálogo editor de conflito.

Fonte: Tortoise

Vaga Web Designer

Você é web designer? Gosta do espírito startup? Acredita que a Educação pode mudar o mundo?

Que tal estagiar conosco?

O que buscamos:

• Alguém que tenha web design como foco e ame design gráfico;
• Seja criativo, proativo e responsável;
• Saiba trabalhar em grupo e com deadlines;
• Possua conhecimento de briefing, teoria das cores, tipografia e diagramação;
• Graduandos (regime estágio, 25h/semana).

Ganha ponto quem:

• Conhecer HTML e CSS;
• Conhecer ou já ter utilizado Adobe Photoshop e Illustrator;
• Conhecer ou possuir noções de interface do usuário (user interface);
• Conhecer ou possuir noções de arquitetura da informação, usabilidade e interação homem-computador;
• Conhecer ou gostar de motion design;
• Estiver disposto a se engajar em um projeto realmente desafiador.

Benefícios:

• Trabalhar numa equipe divertida, multidisciplinar e excepcional;
• Liberdade criativa e intelectual;
• Horários flexíveis;
• Suprimento infinito de café;
• Bolsa via CNPQ no valor de R$ 800,00/mês.

Envie-nos seu currículo / portfólio / linkedin para jobs@redu.com.br

Adicione no título: [DESIGNER] Nome Sobrenome

Oportunidade TI Analista

A Digital Intelligence Systems Corporation (DISYS) é uma empresa especializada em serviços estratégicos de outsourcing e consultoria em tecnologia da informação (TI) que prima pela qualidade e o mais alto nível de tecnologia, visando servir seus clientes de acordo com as melhores práticas do mercado.
Com matriz em Chantilly, USA, possuí 20 escritórios nos Estados Unidos e quatro filiais internacionais, na América Latina, Europa e Ásia.

A Disys vem se posicionando de forma crescente no mercado de serviços de TI no Brasil, presente em São Paulo, Paraná, Rio Grande do Sul, Rio de Janeiro e Pernambuco.

Desta forma, gostaríamos de convidá-lo a avaliar oportunidade para atuação como Analista de Dados.

Analista de Dados

 

Requisitos Obrigatórios:

· Ampla experiência em análise e desenvolvimento em VBA para banco de dados Access e Microsoft Excel.

· Ampla experiência em linguagem SQL .

· Experiência na geração de relatórios gerenciais.

Requisitos Desejáveis:

· Conhecimento em Microsoft SharePoint 2010.

. Microsoft Power Pivot ou Microsoft Dashboard Designer.

 

Perfil Profissional:

Organizado, Disciplinado, Objetivo, Flexível e facilidade de trabalhar em equipe.

Salário: A combinar

Local: Recife

 

Interessados deverão encaminhar currículo com pretensão salarial paratatiane.costa@disys.com.

Novidades posts sobre Drupal

Amigos, 


começarei em breve uma serie de posts relacionados a Drupal, utilizarei exemplos diários para poder contextualizar os posts isso dará uma boa abrangência para você que assim como eu está nesse novo mundo.


Estou aberto a perguntas e sugestões para os posts caso você tenha alguma ideia.


Compartilhem...