Posts com o tag ‘ferramentas’
9mar2010
No dia-a-dia utilizar recursos das ferramentas certas ajudam a agilizar nosso trabalho, tratando-se de controle de versões o Git tem diversos truques interessantes. Vou resumir de forma rápida alguns comandos que utilizo diariamente, a idéia é concentrar aqui novas dicas que forem aparecendo, então sugestões são bem vindas.
INSTAWEB
Um dos comandos mais úteis e interessantes que tenho utilizado ultimamente para fazer revisão de código ou para ter um histórico do projeto é o “instaweb” que inicia um servidor local onde podemos navegar (http://127.0.0.1:1234/?p=.git;a=shortlog) pelos commits e verificar as diferenças do repositório de uma forma bem simples e clara. É importante lembrar que ao subir o serviço o terminal fica liberado sendo necessário parar o servidor após o uso senão o processo continuará “rodando”.
git instaweb --httpd webrick
git instaweb --httpd webrick --stop
STASH
O comando “stash” é útil quando estamos trabalhando em algum código que ainda não está concluído e precisamos atualizar o projeto com as últmas atualizações, então colocamos nossas alterações em área isolada com git stash, atualizamos o projeto e aplicamos novamente nossas alterações com git stash apply. Exemplo:
git stash
git stash apply
AMEND
O comando “amend” é utilizado para corrirgir ou re-editar a mensagem do último commit desde que ele não tenha sido enviado para o repositório. Exemplo:
git commit -m "Alguma mensagem errada"
git commit --amend -m "Correção da mensagem"
GREP
Com “grep” encontramos palavras dentro dos arquivos do projeto, combinado com -n é possível saber em qual linha a palavra ou o conjunto delas foi encontrado.
git grep -n "palavra ou frase procurada"
RESET
Reset pode ser utilizado basicamente para duas situações, uma delas é desfazer um commit mantendo as alterações realizadas no código com “–soft” e para desfazer um commit completamente incluindo as alterações com “–hard”. Exemplo:
git reset --soft HEAD~1
git reset --hard HEAD~1
LOG
Temos diversas formas para verificar os logs de commits do projeto, abaixo alguns tipos de formatações para exibí-los. O último “shortlog” mostra a quantidade de commits do projeto.
git log --pretty=oneline --graph --all
git log --pretty=oneline --abbrev-commit
git whatchanged -n 1
git shortlog -s -n
Para complementar, uma dica para mostrar o branch atual no terminal. No arquivo ~/.bashrc no Ubuntu ou ~/.bash_profile no MacOS inclua as linhas abaixo, feche o terminal e abra novamente para que as alterações sejam aplicadas.
export PS1="\[33[38m\]\u\[33[32m\] \w \[33[31m\]\`ruby -e
\"print (%x{git branch 2> /dev/null}.grep(/^\*/).first ||
'').gsub(/^\* (.+)$/, '(\1) ')\"\`\[33[37m\]$\[33[00m\] "
O terminal ficará assim:
user ~/projects/blog (master) $
Referências:
http://gitready.com/
http://book.git-scm.com/
http://learn.github.com/p/intro.html
Post original:
http://mauriciodeamorim.com.br/2010/03/08/facilitando-o-trabalho-com-git/
.
Link deste post
Tags: Dicas, ferramentas, GIT
4fev2010
Recentemente precisei fazer uma pesquisa com ex-clientes de um produto da Locaweb, pois gostaríamos de saber por que eles haviam deixado de usá-lo. Eu tinha um problema nas mãos, pois ex-clientes não costumam falar. Eles estão frustrados, furiosos ou simplesmente não lembram mais.
Como eu poderia motivá-los a responder uma pesquisa online?
Decidi abordá-los de forma pessoal e informal. Primeiro, no e-mail que convidava-os a participar do questionário, em momento algum citei o termo “pesquisa”. E mais: apresentei-me, dei meu nome e um e-mail para maiores informações, disse o que fazia na Locaweb e por que estava entrando em contato. Então pedi que eles respondessem às perguntas publicadas em uma página do site. A idéia foi me comunicar com eles como uma pessoa que trabalha na Locaweb e que gostaria realmente de receber ajuda, fazê-los entender que não era um setor de atendimento que faz pesquisas de satisfação.
Dusty Users
Isso coincidiu e fechou com as idéias que li no livro “Designing the moment“ (Robert Hoekman Jr.) sobre “Dusty Users” ( clientes que cadastram-se para usar um serviço, mas não vão adiante). Entre as soluções propostas para resgatar a atenção desses usuários, o autor fala sobre o tom amigável e bem humorado com que se pode abordar esses clientes e obter informações.
“So what do we do about this as designers? If our goal is to keep users interested and engaged what can we do to nudge these sleepers awake and get them moving again? (…) The things that really make us pay attention are personal. (…) they are personal messages focused around our needs that create a genuine connection”
“Most important, the messages we send out should be written using a human voice, not with stiff, corporate marketing fluff filled with buzzwords and catch phrases. These messages should be conversational. They should be focused entirely on the recipient, not on us.”
E, casualmente, logo depois da pesquisa enviada recebi newsletters de dois serviços que havia assinado por curiosidade, e que agora estavam me enquadrando como uma dusty user. Vejam o exemplo do Usabilla.com:
Hello,
Not so long ago you’ve created an account at Usabilla.com.
I’m very curious if you’ve already been able to set up your first test and would love to hear about your experiences.
We’re currently running a large number of very exciting test cases for a variety of clients (see http://usabilla.com/references ). We’ve also been working on different demo cases to give you some ideas on how you could use Usabilla for different types of usability tests. You can find an overview of these cases at our blog: http://blog.usabilla.com/?cat=87 . We recently started a Facebook group, which we would like to use to discuss news, demo cases, and to learn from your stories: http://bit.ly/usabillafb .
Please let me know if you got any questions, tips, ideas, or need help to set up a test.
Kind regards,
Paul Veugen
Usabilla.com
Resultados
Ok, e sobre os resultados? Foram ótimos. A participação na pesquisa correspondeu a 7,8% do total de e-mails enviados com sucesso e a 60% dos cliques únicos no link da pesquisa. Isso ficou acima do que esperávamos em função das características do perfil convocado e também ficou acima da média das nossas outras iniciativas em pesquisa. Vejam o gráfico com o percentual de cliques no link da pesquisa (em relação ao total de visualizações únicas da mensagem):
Não ignore o feedback!
Outro resultado interessante, e que toca num ponto importante sobre esse tipo de abordagem: recebemos mais de 200 e-mails válidos (anti-spam e auto-reply não foram contabilizados) com clientes expondo seus motivos e agradecendo pelo contato. Esse feedback é importante, pois traz dados qualitativos sobre a questão da pesquisa. Porém, uma vez que você se apresenta aos seus clientes de forma tão próxima, você deve comprometer-se a atendê-los se eles solicitam a tréplica do contato.
Pense, primeiramente, se você terá tempo para ler as mensagens enviadas (Dica: programe uma hora do seu dia de trabalho para ler os e-mails e respondê-los). Considere que alguns (ou muitos) clientes verão nesse contato uma possibilidade de suporte do produto. Se pedirem ajuda, encaminhe as mensagens para a equipe responsável pelo suporte e informe a origem do contato. Se possível, envie você mesmo um e-mail respondendo que encaminhou o pedido ao suporte e que assim que possível a pessoa será atendida. Se for algum tipo de ajuda que você mesmo pode prestar, responda e agradeça.
De qualquer maneira, não deixe que os clientes percam a fé no seu contato, não utilize a abordagem pessoal como um método vazio. Faça isso porque você se importa com a opinião dos usuários do seu produto, porque se importa com eles.
Boa sorte nas pequisas!
Link deste post
Tags: AI, arquitetura de informação, ferramentas, formularios, método, pesquisa, Recrutamento, Simplicidade, Testes e Pesquisas
15dez2009
Aqui na Locaweb utilizamos alguns projetos de Software Livre para auxiliar na criação de nossos produtos. Além de utilizarmos esses softwares, tentamos sempre que possível contribuir para a evolução dos projetos.
Pensando nisso, decidimos na última sexta-feira dedicar um dia inteiro de alguns desenvolvedores à contribuição ao Software Livre.
Desta vez, o projeto escolhido foi o Gitorious. O gitorious é um gerenciador de projetos git (uma versão livre do Github). Cerca de 12 desenvolvedores entraram em uma sala de reunião e seguiram uma série de tarefas pré-definidas em um backlog. Estas tarefas foram geradas a partir de problemas reais sentidos por clientes do gitorious (no caso os próprios desenvolvedores), além de sugestões de features que poderiam ser implementadas.
Alguns exemplos de histórias implementadas:
- Apresentar o conteúdo do arquivo README na página incial do projeto.
- Bug-Fix: Authorized_Keys deve ser gerado com permissão certa.
- Refatorações e melhoria na cobertura de testes
A empresa também patrocinou refrigerante e pizza para deixar o clima mais descontraído.
O resultado está publicado no próprio gitorious no branch do Fabio Hisamoto.
Link deste post
Tags: ferramentas, gitorious day, linguagens de programação, Linux, rails, ruby, ruby on rails
16out2009
NAnt (http://nant.sourceforge.net/) é uma ferramenta open source de criação de builds automáticos para .NET, modelado a partir do Ant do Java.
Com o NAnt você consegue compilar o seu projeto .NET, rodar testes unitários, configurar a aplicação de acordo com o ambiente (local, integração contínua, produção, etc), realizar o deploy, entre muitas outras coisas. Porém, para utilizar algumas dessas funcionalidades, é necessário um add-on, chamado NAntContrib (http://nantcontrib.sourceforge.net/), que adiciona várias outras funcionalidades ao NAnt, como por exemplo controle de serviços do Windows, de diretórios virtuais no IIS, utilização do MSBuild, entre outras coisas.
O NAnt funciona através de linha de comando, baseado num XML que você cria para seu build.
Como o foco deste post não é explicar como o NAnt funciona e sim mostrar alguns exemplos de como automatizar seus builds, vamos partir para a codificação.
Criando o primeiro build com o NAnt
Vamos começar com um exemplo simples. Iremos criar um build que apenas compila uma solution, em modo release, que contenha um projeto do tipo Class Library:
- Criar uma nova solution no Visual Studio com um projeto do tipo Class Library
- Criar um arquivo com o nome de “default.build”, no diretório raiz da solution criada (Ex.: C:\NomeDoProjeto\default.build), com o seguinte conteúdo:
<?xml version="1.0"?>
<project name="NAnt Example" default="build">
<property name="nant.contrib.path" value="C:\Program Files (x86)\nant-contrib\bin" />
<target name="build">
<loadtasks assembly="${nant.contrib.path}\NAnt.Contrib.Tasks.dll" />
<msbuild project="NAnt.sln" target="Rebuild">
<arg line="/p:Configuration=Release" />
</msbuild>
</target>
</project>
- Executar, através de linha de comando, dentro do diretório do projeto, o comando “nant” para realizar o build
- Caso tudo dê certo, no final da execução, aparecerá a mensagem “BUILD SUCCEEDED” para confirmar que tudo deu certo
O que fizemos?
- Linha 2 – Criamos uma tag para o projeto (project), onde definimos o nome do projeto (atributo name) e o target padrão para execução (atributo default), para o NAnt. No nosso caso, definimos nosso target padrão como build, assim não há necessidade de executarmos esse projeto utilizando o comando “nant build“.
- Linha 3 – Criamos a tag property para definir um valor para uma propriedade, para utilizarmos em outros pontos do nosso arquivo de build. Neste caso criamos uma propriedade com o nome de “nant.contrib.path” com o valor “C:\Program Files (x86)\nant-contrib\bin” para guardarmos o diretório onde foi instalado o NAnt-contrib (É aconselhável que todos os ambientes que você trabalhe esteja instalado no mesmo diretório).
- Linha 4 – Criamos uma tag para realizar uma tarefa específica, no nosso caso, uma chamada de build (atributo name). Dentro desta tag iremos codificar o que queremos que esta tarefa faça.
- Linha 5 – Dentro da tarefa build, criamos uma tag para carregar as funcionalidades do NAnt-contrib, lembrando que utilizamos a propriedade “nant.config.path“, que definimos na linha 3. Sempre que quisermos utilizar uma propriedade, devemos utilizar a sintaxe ${nomedapropriedade}.
- Linha 6 – Agora, vamos utilizar uma task do NAnt-contrib (msbuild), que utilizará o MSBuild para compilar o projeto. Definimos o nome da solução/projeto a ser compilada (atributo project) e o tipo de compilação (atributo target).
- Linha 7 – Definimos um parâmetro para ser executado no MSBuild (tag arg), no nosso caso, estamos dizendo ao MSBuild que utilize a configuração de Release do projeto (atributo line).
Acabamos de criar nosso primeiro build no NAnt que compila uma solution.
Adicionando execução de testes ao build
Agora, vamos criar um projeto de testes em nossa solution e vamos adicionar uma tarefa ao NAnt para rodar os testes:
- Adicionar um projeto de teste a solution
- Criar apenas um teste unitário em branco
- Modificar o arquivo default.build (Como o arquivo cresceu um pouco, coloquei umas quebras de linhas extras para melhor visualização do código)
<?xml version="1.0"?>
<project name="NAnt Example" default="build">
<property name="program.files.path" value="${environment::get-variable('PROGRAMFILES')}" />
<property name="nant.contrib.path" value="${program.files.path}\nant-contrib\bin" />
<property name="mstest.path" value="${program.files.path}\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" />
<property name="test.container.path" value="Tests\bin\Release\NAnt.Tests.dll" />
<property name="test.results.path" value="TestResults" />
<target name="clean">
<delete dir="${test.results.path}" />
</target>
<target name="build" depends="clean">
<loadtasks assembly="${nant.contrib.path}\NAnt.Contrib.Tasks.dll" />
<msbuild project="NAnt.sln" target="Rebuild">
<arg line="/p:Configuration=Release" />
</msbuild>
<call target="test" />
</target>
<target name="test">
<mkdir dir="${test.results.path}" failonerror="true" />
<exec
program="${mstest.path}"
commandline=" /testcontainer:${test.container.path} /resultsfile:${test.results.path}\TestResults.trx /detail:errormessage" />
</target>
</project>
- Executar novamente o comando “nant” para realizar o build
O que fizemos?
- Linha 4 – Propriedade para pegar o valor da variável de ambiente PROGRAMFILES do Windows
- Linha 5 – Utilizando a propriedade “program.files.path” para o diretório do NAntContrib
- Linha 6 – Propriedade com o caminho físico do MSTest (caso use o NUnit, o NAntContrib tem uma tag específica para ele)
- Linha 7 – Propriedade do caminho físico do arquivo de testes que será executado
- Linha 8 – Propriedade do diretório onde serão salvos os resultados dos testes
- Linha 10 – Tarefa para limpar o ambiente antes de começar o build
- Linha 11 – Apagando o diretório dos resultados dos testes
- Linha 14 – Adicionado a dependência à tarefa “clean” (atributo depends)
- Linha 19 – Tag para chamar a tarefa de testes, após compilar o projeto
- Linha 22 – Tarefa da execução dos testes
- Linha 23 – Criando o diretório para o resultado dos testes. Caso não seja possível criar o diretório, o build para por aqui
- Linha 24 a 26 – Chamando o MSTest para executar os testes e salvar os resultados
Agora nosso build só será compilado quando todos os testes da solution estiverem passando.
Limpando a sujeira
Com o crescimento e refatoração de nossos projetos, normalmente criamos arquivos novos e apagamos arquivos desnecessários, com isso, os diretórios onde são gerados os assemblies dos projetos, vão armazenando arquivos antigos, que provavelmente não serão mais necessários. Então vamos criar um build para apagarmos todos os arquivos das pastas obj e bin que o MSBuild cria ao compilar os projetos:
- Alterar o arquivo default.build
<?xml version="1.0"?>
<project name="NAnt Example" default="build">
<property name="program.files.path" value="${environment::get-variable('PROGRAMFILES')}" />
<property name="nant.contrib.path" value="${program.files.path}\nant-contrib\bin" />
<property name="mstest.path" value="${program.files.path}\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" />
<property name="test.container.path" value="Tests\bin\Release\NAnt.Tests.dll" />
<property name="test.results.path" value="TestResults" />
<target name="clean">
<delete>
<fileset>
<include name="**\bin\**" />
<include name="**\obj\**" />
</fileset>
</delete>
<delete dir="${test.results.path}" />
</target>
<target name="test">
<mkdir dir="${test.results.path}" failonerror="true" />
<exec
program="${mstest.path}"
commandline=" /testcontainer:${test.container.path} /resultsfile:${test.results.path}\TestResults.trx /detail:errormessage" />
</target>
<target name="build" depends="clean">
<loadtasks assembly="${nant.contrib.path}\NAnt.Contrib.Tasks.dll" />
<msbuild project="NAnt.sln" target="Rebuild">
<arg line="/p:Configuration=Release" />
</msbuild>
<call target="test" />
</target>
</project>
- Executar o nant
O que fizemos?
- Linha 11 a 16 – Adicionando a tag delete para apagar todos os arquivos, de todas as pastas bin e obj, existentes na solution
Agora não teremos mais problemas com arquivos antigos do projeto.
Diferentes arquivos de configuração para cada ambiente
Recapitulando, nós já conseguimos compilar um projeto, rodar os testes e limpar os diretórios das compilações, porém, se precisarmos utilizar arquivos de configuração para nossos projetos, com certeza teremos problemas com as diferentes configurações para cada ambiente (desenvolvimento, integração contínua, homologação, produção). Então, vamos ver um exemplo para utilar os arquivos de configurações corretos, de acordo com o ambiente escolhido para o build:
- Alterar o arquivo default.build
<?xml version="1.0"?>
<project name="NAnt Example" default="build">
<property name="environment" value="local" />
<property name="program.files.path" value="${environment::get-variable('PROGRAMFILES')}" />
<property name="nant.contrib.path" value="${program.files.path}\nant-contrib\bin" />
<property name="mstest.path" value="${program.files.path}\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" />
<property name="test.project.path" value="Tests" />
<property name="test.assembly" value="NAnt.Tests.dll" />
<property name="test.container.path" value="${test.project.path}\bin\Release\${test.assembly}" />
<property name="test.results.path" value="TestResults" />
<target description="Configures" name="config">
<property name="build.config.file" value="config.${environment}.xml" dynamic="true" />
<if test="${file::exists(build.config.file)}">
<echo message="Loading ${build.config.file}" />
<include buildfile="${build.config.file}" verbose="true" />
</if>
<if test="${not file::exists(build.config.file) and environment != 'local'}">
<fail message="Configuration file '${build.config.file}' could not be found." />
</if>
</target>
<target name="clean">
<delete>
<fileset>
<include name="**\bin\**" />
<include name="**\obj\**" />
</fileset>
</delete>
<delete dir="${test.results.path}" />
</target>
<target name="test">
<mkdir dir="${test.results.path}" failonerror="true" />
<copy file="${test.project.path}\${test.config.file}" tofile="${test.container.path}.config" failonerror="true" overwrite="true" />
<exec
program="${mstest.path}"
commandline=" /testcontainer:${test.container.path} /resultsfile:${test.results.path}\TestResults.trx /detail:errormessage" />
</target>
<target name="build_ci">
<property name="environment" value="ci" />
<call target="build"/>
</target>
<target name="build" depends="config clean">
<loadtasks assembly="${nant.contrib.path}\NAnt.Contrib.Tasks.dll" />
<msbuild project="NAnt.sln" target="Rebuild">
<arg line="/p:Configuration=Release" />
</msbuild>
<call target="test" />
</target>
</project>
- Criar dois arquivos de configuração para o projeto de teste, um chamado App.config e outro ci.App.Config (local e integração contínua), para simularmos os arquivos dos dois ambientes
- Criar um arquivo chamado config.local.xml no mesmo diretório do arquivo default.build (na raiz da solution)
<project>
<property name="test.config.file" value="ci.App.config" />
</project>
- Criar um arquivo chamado config.ci.xml no mesmo diretório do arquivo default.build (na raiz da solution)
<project>
<property name="test.config.file" value="App.config" />
</project>
- Executar o comando “nant build_ci“
O que fizemos?
- Linha 4 – Propriedade para definir o ambiente
- Linha 8 – Propriedade com o diretório do projeto de testes
- Linha 9 – Propriedade com o nome do arquivo do teste
- Linha 14 a 22 – Tarefa para verificar se existe o arquivo de configuração a ser carregado, baseado na propriedade “environment“
- Linha 36 – Copiando o arquivo de configuração do teste, baseado na propriedade “test.config.file“, que é carregada no arquivo de configuração de cada ambiente (config.local.xml ou config.ci.xml). Caso seja um build local (nant build), irá sobrescrever o arquivo de configuração com o arquivo “App.config“, caso seja um build para integração contínua (nant build_ci), irá sobrescrever o arquivo “ci.App.config“.
- Linha 42 a 45 – Tarefa para realizar o build para o ambiente de integração contínua.
- Linha 47 – Adicionado a dependência da tarefa “config” antes de realizar o build
Agora nosso build pode ter arquivos de configurações diferentes para cada ambiente.
Criando um pacote para deploy
Normalmente, nós desenvolvedores, não temos acesso direto aos servidores de produção para realizar o deploy. Com isso, em alguns casos, temos que criar um pacote dos assemblies de uma aplicação e enviar para a equipe responsável que irá efetuar o deploy. Então, neste exemplo, vamos criar este pacote, com todos os arquivos necessários de configurações, específicos para o ambiente de produção:
- Alterar o arquivo default.build
<?xml version="1.0"?>
<project name="NAnt Example" default="build">
<property name="environment" value="local" />
<property name="program.files.path" value="${environment::get-variable('PROGRAMFILES')}" />
<property name="nant.contrib.path" value="${program.files.path}\nant-contrib\bin" />
<property name="mstest.path" value="${program.files.path}\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" />
<property name="project.path" value="NAnt.Core" />
<property name="project.binary.path" value="${project.path}\bin\Release" />
<property name="project.assembly" value="NAnt.Core.dll" />
<property name="test.project.path" value="Tests" />
<property name="test.assembly" value="NAnt.Tests.dll" />
<property name="test.container.path" value="${test.project.path}\bin\Release\${test.assembly}" />
<property name="test.results.path" value="TestResults" />
<property name="deploy.package.path" value="DeployPackage" />
<property name="temp.path" value="Temp" />
<target description="Configures" name="config">
<property name="build.config.file" value="config.${environment}.xml" dynamic="true" />
<if test="${file::exists(build.config.file)}">
<echo message="Loading ${build.config.file}" />
<include buildfile="${build.config.file}" verbose="true" />
</if>
<if test="${not file::exists(build.config.file) and environment != 'local'}">
<fail message="Configuration file '${build.config.file}' could not be found." />
</if>
</target>
<target name="clean">
<delete>
<fileset>
<include name="**\bin\**" />
<include name="**\obj\**" />
</fileset>
</delete>
<delete dir="${test.results.path}" />
<delete dir="${temp.path}" />
<delete dir="${deploy.package.path}" />
</target>
<target name="test">
<mkdir dir="${test.results.path}" failonerror="true" />
<copy file="${test.project.path}\${test.config.file}" tofile="${test.container.path}.config" failonerror="true" overwrite="true" />
<exec
program="${mstest.path}"
commandline=" /testcontainer:${test.container.path} /resultsfile:${test.results.path}\TestResults.trx /detail:errormessage" />
</target>
<target name="build_ci">
<property name="environment" value="ci" />
<call target="build"/>
</target>
<target name="build_production">
<property name="environment" value="production" />
<call target="package"/>
</target>
<target name="build" depends="config clean">
<loadtasks assembly="${nant.contrib.path}\NAnt.Contrib.Tasks.dll" />
<msbuild project="NAnt.sln" target="Rebuild">
<arg line="/p:Configuration=Release" />
</msbuild>
<call target="test" />
</target>
<target name="package" depends="build">
<mkdir dir="${deploy.package.path}" failonerror="true" />
<mkdir dir="${temp.path}" failonerror="true" />
<copy todir="${temp.path}" overwrite="true" verbose="true">
<fileset basedir="${project.binary.path}">
<include name="*/**" />
<exclude name="*.pdb" />
<exclude name="*.config" />
</fileset>
</copy>
<copy file="${project.path}\${project.config.file}" tofile="${temp.path}\${project.assembly}.config" />
<copy todir="${deploy.package.path}" overwrite="true">
<fileset basedir="${temp.path}">
<include name="*/**" />
</fileset>
</copy>
<delete dir="${temp.path}" />
</target>
</project>
- Criar dois arquivos de configuração para o projeto principal, um chamado App.config e outro production.App.Config (local e produção)
- Criar um arquivo chamado config.production.xml no mesmo diretório do arquivo default.build (na raiz da solution)
<project>
<property name="test.config.file" value="ci.App.config" />
<property name="project.config.file" value="production.App.config" />
</project>
- Executar o comando nant “build_production“
O que fizemos?
- Linha 8 a 10 – Propriedades com os dados do diretório e assembly do projeto principal, que será feito o deploy
- Linha 15 – Propriedade com o diretório que será criado, onde ficará o pacote para deploy
- Linha 16 – Propriedade com o diretório temporário, onde organizaremos os arquivos gerados da compilação, antes de enviar para o diretório do pacote
- Linha 37 e 38 – Apagando os diretórios gerados (deploy e temporário)
- Linha 54 a 57 – Tarefa para gerar o pacote para deploy
- Linha 68 – Criando o diretório do pacote para deploy
- Linha 69 – Criando o diretório temporário
- Linha 71 a 77 – Copiando todos os arquivos do diretório onde foi compilado o projeto, para o diretório temporário, exceto os arquivos com extensão “pdb” e “config“
- Linha 79 – Copiando o arquivo de configuração para o ambiente de produção (carregado da propriedade “project.config.file” do arquivo “config.production.xml“)
- Linha 81 a 88 – Copiando os arquivos do diretório temporário para o diretório onde ficará o pacote para deploy
- Linha 87 – Apagando o diretório temporário
Pronto, agora você terá um diretório chamado “DeployPackage” com seu pacote prontinho para ser enviado para a equipe responsável no deploy da aplicação.
Existem inúmeras outras funcionalidades para automatização de seus builds com o NAnt e o NAntContrib, porém, creio que com esses exemplos, voces consigam ter uma idéia de como criar builds automatizados para seus projetos .NET, mas é claro que, para cada projeto, você vai precisar ajeitar seu build conforme a necessidade.
Referências
Leitura recomendada
Link deste post
Tags: .NET, build automatizado, ferramentas, linguagens de programação, nant
6out2009
Uma das coisas que deixava a desejar no Gedit era a falta de uma busca por textos dentro dos arquivos em todo projeto. Conseguiamos apenas realizar buscas por nome de arquivo através dos plugins Snap Open (padrão do Gedit no Ubuntu 9.04), Gedit Open File e Gedit Go To File sendo os dois últimos inclusos no projeto Gmate, mas vasculhando com um pouco mais de calma encontrei o plugin File Search para resolver esta carência.
A instalação é simples:
- Faça o download do arquivo tar.gz
- Descompacte os arquivos
- Copie os arquivos para ~/.gnome2/gedit/plugins/
- Inicie o Gedit ative o plugin File Search em Editar >Preferências > Plugins
- A tecla de atalho para o File Search é Ctrl + Shift + F
Para instalar e obter mais informações sobre os outros plugins mencionados acima consulte este post.
Lembre-se que se você já instalou outros plugins que não fazem parte deste pacote é recomendado que faça um backup antes. Eu particularmente instalei o File Search após ter os plugins do Gmate já instalados e não tive problemas.
Aproveito este post para deixar mais algumas dicas:
* Caso esteja utilizando o plugin Gemini (Fecha aspas, chaves, parenteses automaticamente) é necessário desabilitar o plugin Bracket Completion que vem por padrão;
* Somente um dos plugins de busca por arquivos (Snap Open, Gedit Open File ou Gedit Go To File) deve estar habilitado;
* Alguns documentos devem ser marcados com caracter de fim de linha, se você estiver utilizando o plugin Save without trailing space ele incluirá uma linha a mais em todo arquivo que for alterado e salvo no Gedit;
* Aqui uma lista de shortcuts para facilitar a vida usando o Gedit.
Se gostou do plugin File Search deixe um comentário para o autor, pois é legal copiar e mais legal ainda é reconhecer os autores.
Referências:
- Gedit File Search
- File Search no Github
- Find and Files plugin
- Gmate
- Gedit Text Editor
Post original:
http://mauriciodeamorim.com.br/2009/10/05/gedit-com-busca-de-texto/
Link deste post
Tags: ferramentas, Gedit, Gmate, Linux, Plugin, ubuntu
5out2009
Jason Zimdars - 37Signals
Jason Zimdars ou apenas JZ trabalha como visual designer e front end developer na 37Signals. (uma empresa americana que desenvolve aplicações web para gerenciamento de projetos. Com aproximadamente 3 milhões de clientes, são os criadores de vários produtos de sucesso tais como: Basecamp, Backpack, Highrise e autores do livro: Getting Real) (clique aqui para ver em português)
1)Hey JZ, first of all, I’d like to thank you for taking the time to give us this interview and would like you to tell us about yourself, your life as a professional designer, and the “paths you’ve traveled down” to get where you are. (We also know that you’ve been a designer since your childhood, doing more artistic design earlier and now more… psychological design, since we’re talking about User Experience 
)
Thanks, it’s good to talk with you. As you mentioned I’ve always been interested in art and design — and technology. I feel like I grew up at a very interesting time. I’m old enough to remember the days before personal computers, but I’m still able to experience the amazing things we can do with technology today and use them in my career. By growing up when I did, I have a very fundamental relationship with technology. I dabbled with art and programming on very basic personal computers. I was able to learn HTML before WYSIWYG editors existed. Having that understanding of how these things work is important to me — I can’t imagine being part of the next generation for whom the computer has always been a part of their lives, but it’s just sort of this magical box. Sure kids in college today have tremendous advantages, but they may never get a chance to look under the hood like I did.
I was an “art kid” growing up and even in college was in a very traditional art program. Drawing, painting, ceramics; even the graphic design classes were largely traditional — we hand-drew letterforms, cut designs from paper and painted swatches. But this was also the time when the internet was blossoming. So, with a self-motivated interest in technology I explored computers and the web. Heck, I even talked a painting professor into letting me paint frames of an animation in class, then sequence them with Flash for a project.
Naturally, when it came to my professional career, I stuck with what I knew and liked best. That has always been human-computer interface. I think you’re going to do the best work when you do what you like and what interests you. I don’t have specific education or training in user experience, but I’m a pretty good user. They say the best training for writing is reading and I believe the best way to learn to make great software is to use it. Not only use software, but pay attention to what works, what doesn’t, what was unexpected, what could be better. Years of experience as a user helps you develop a feel for user experience that I doubt a school or book could teach you anyway.
2)How’s your creative process, from start to finish?
Design always begins on paper for me. My sketchbook is where I work out my ideas. I like that with paper I can quickly try a lot of variations and have a record to return to later. Once I’ve got an idea or two that I think is worth moving forward with, I try to get into some kind of mock-up where I can see it in as real a form as possible. Those mock-ups can be static comps or be right inside the application using mock functionality. But the idea is to go from paper to the browser as soon as you can.
Once in the browser it’s easier to see things you couldn’t work out on paper or in Photoshop. From there it becomes a process of iterating just going over and over it with small improvements until you have something really good.
3)Paper prototypes – do they really work? You recently “fired photoshop” from your life, how does that feel? Don’t you miss it even a little?
Well, I wouldn’t say that I “fired” Photoshop, but I have definitely changed the way I use it. Before joining 37signals, I worked a lot on client-driven websites. In those cases the Photoshop comp was our contract, we never proceeded forward with a website or application until we had approved comps. While this approach certainly ensured that we had a solid direction moving forward, it didn’t allow the design to continue to evolve and grow as we moved into code.
Even before joining 37signals, I had begun exploring the idea of working more directly in code and not in Photoshop. I noticed that whenever I designed for myself, I always started with mark-up and layered CSS and graphics on top of it. Even when you’re working from a comp there are things you can’t see until the design is in the browser. There can be awkward interactions that aren’t visible until you can click them. A static comp is just too illusionary to be the gospel for your design. So working out my ideas in the browser became my preferred way of working.
At 37signals we really believe in the Getting Real methods and part of that is making our work real. Sure, I might jump into Photoshop to quickly try a design idea that might take too much time or require too many code changes to see in code, but for the most part we try to work in the browser, with real code that we can click and resize and truly feel.
Most of the time we communicate ideas with each other with simple sketches and then jump right into the apps to try them out. Photoshop only comes into play when it’s a faster way to see and evaluate an approach.
Do I miss it? Not really. I still use Photoshop plenty, but it’s just another tool. It’s nice to not be making comps just for their own sake. The work that I’m excited about is in the browser so the sooner my process gets me there, the better my work is.
4)What tools do you use to find User Experience issues? Do you do usability testing? When? How often?
There aren’t any specific tools or tests that we use and yet we are constantly evaluating the usability in everything that we do. Its is rare that a day goes by when we aren’t working on something in our apps that could be better, be it copywriting, design, or customer service. Ease of use, clarity, and pure enjoyment are things that we expect of our products and every member of the team is always working to make sure we meet our standards and continue to improve them. This isn’t just the realm of designers, at 37signals everyone is involved in using, supporting, and improving our products. Programing, customer support, designers, right up to the partners that run the company; everyone is always keeping an eye on usability.
5)Working in a company that has customers around the world, do you have UX problems that don’t affect Americans, but affect Brazilians, for example? How do you solve this kind of problem?
Many of the design considerations we make have to do with copywriting and units of measure. There are subtle differences in the way US and other countries expect to see dates and times, in particular. This is an area where we’re still improving. Right now we’re fortunate that our customers are primarily English speaking, but I’m sure that will change as we consider localization and experience growth outside North America and Europe.
6)Where do you find inspiration?
Lots of places, but no place in particular. I don’t really seek inspiration, but I try to pay attention when it finds me. The things that I appreciate in the work of others are sincerity, clarity, beauty — the little things that seem clever, creative and make them enjoyable. You can tell when a product is made by someone who really loves it and truly wants people to love it, too. I look for those little moments in products, movies, music, whatever, where you kind of connect with the object. I try to imagine the thought that went into it and how that touch was created. It is a lifetime of experiencing these little moments that help me make them for others.
7)What are your favorite websites, and why?
I tend to visit sites more for their utility than simply for the sake of their design so I appreciate websites that work well and get me in and out quickly.
I really like CNN.com’s article pages. The tabs for media content are nicely done and the “story highlights” at the top of each article are a tremendous innovation. Many times that’s all I need to get what I need from a story.
I love the design and general spirit of Etsy.com. I have a lot of respect for people who make things with their hands.
I’m not a big fan of design galleries, but siteinspire.net stands out as one that truly has a voice. It is well designed and impeccably curated.
I can’t imagine shopping without Amazon.com. I love some of the stuff the guys are doing at Behance. Very nice, clean design. Threadless is another favorite — great design, amazing community.
Thanks a lot for this interview JZ. The closing comments are up to you… :)
No, thank you! I enjoyed talking with you and I hope some of this is interesting to people out there. If I had to sum it all up, I’d just encourage everyone to keep learning, keep growing and always try to get better. So many things all around us can be better and design has a huge opportunity for impact in places you might never expect.
Link deste post
Tags: 37Signals, ágil, AI, apresentação, arquitetura de informação, boas praticas, Design, design de interação, Entrevistas, ferramentas, Jason Zimdars, método, Simplicidade, Testes e Pesquisas, usabilidade, user experience, UX
6mai2009
Dessa vez a WordPress.org está convocando usuários do sistema e moderadores voluntários de diversos países para testes de usabilidade das funcionalidades da interface do sistema. Conheça os detalhes do projeto no WordPress Blog.
Link deste post
Tags: arquitetura de informação, design de interação, ferramentas, testes de usabilidade, Testes e Pesquisas, UX, WordPress
29abr2009
Publicamos um tópico no Fórum da Locaweb pedindo indicações de painéis de controle que os clientes acham interessantes. Seria muito bacana se os visitantes do UXBlog deixassem suas opiniões por lá.
Link pro tópico: O melhor e o pior em um painel de controle
Link deste post
Tags: clientes, design de interação, ferramentas, forum, fórum Locaweb, opinião, painel de controle, sugestões, Testes e Pesquisas, UX
30mar2009
Há algum tempo falei sobre uma ferramenta para testar a consistência de seu layout, Five-Second-Test.
Esta semana conheci uma nova ferramenta muito legal para facilitar o trabalho dos designers. Trata-se do Redmarkit, ótimo serviço para acompanhar o trabalho junto ao cliente sem precisar encontrá-lo de fato (o ideal realmente é sempre manter um contato com o cliente, desde a reunião de proposta até aprovação/entrega do layout, seja ele implementado ou não).
Mas, existem situações onde o cliente está longe ou sem tempo para marcar uma reunião e, nesses casos, essa é uma ferramenta bem útil para otimizar o tempo e agilizar o processo de aprovação/alteração.
Resumindo em 3 passos.
1.Fazer o upload do layout
Após o cadastro, basta criar um novo projeto, adicionar a imagem e o cliente recebe um e-mail na mesma hora como notificação (o cliente não precisa fazer nenhum cadastro para visualizar e comentar o projeto).
2. Cliente faz os comentários
3. Leia os comentários e se necessário faça as mudanças.
O designer recebe um e-mail informando que o cliente interagiu no projeto, acessa o link, visualiza os comentários e com um “check box”, marca as alterações realizadas.
O serviço ainda está em fase beta e por isso o cadastro não está aberto ao público. Mas ganhamos 50 convites de brinde do pessoal do Redmarkit. Se você se interessou, deixe um comentário (com o endereço de e-mail preenchido) e enviaremos o código para você por e-mail (enquanto ainda houver convites! :) ).
Link deste post
Tags: Design, design de interação, ferramentas
