martes, 24 de enero de 2012
Virtualbox headless
Virtualbox puede ser usado como plataforma de virtualización servidora.
https://www.virtualbox.org/manual/ch01.html#intro-installing
#VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack
#VBoxManage modifyvm "VM name" --vrde on
#VBoxManage startvm "vm2" --type headless
# rdesktop -a 16 -N z:3389
# VBoxManage controlvm "vm2" poweroff
lunes, 9 de enero de 2012
git over Centos
Hoy toca instalar git sobre Centos y vincularlo a Atlassian FishEye.
http://akcdev.blogspot.com/2011/02/instalando-git-en-centos-5.html
http://akcdev.blogspot.com/2011/02/instalando-git-en-centos-5.html
jueves, 5 de enero de 2012
DSL y test
Además de definir DSL para crear nuestras aplicaciones, debemos crear DSL que permitan testearlas. Sin duda, ambos DSL compartiran conceptos del negocio.
http://www.thoughtworks.com/articles/dsls-functional-testing
“I believe that the hardest part of software projects, the most common source of project
failure, is communication with the customers and users of that software. By providing a clear
yet precise language to deal with domains, a DSL can help improve this communication.” –
Martin Fowler, Domain Specific Languages (working title).
Involving all the stakeholders in the testing process requires that subject matter experts,
customers, testers, and developers communicate consistently and effectively. In the past,
many software project teams relied on extensive requirements documentation to communicate
effectively across these groups. However, requirements in this context require a fair
amount of translation. Subject Matter Experts (SMEs) and analysts must translate customer
desires and needs into requirements. Developers must translate these requirements into code,
and testers must independently translate the same requirements into tests. Finally, each one
of these translations must match the customers’ original expectations, which may change
over time. It’s similar to the telephone game that children play in primary school, only that
the starting phrase is a moving target.
We could effect a substantial improvement to the translation problem if the customers could
express and test their own requirements, or acceptance criteria, themselves. At a minimum,
customers should be able to simply review any translations that occur in the process and
verify that translations match their needs.
One means to ensure that code across a project team is readable by everyone is a DSL.
Domain specific languages are mini-computer languages that are designed around a very
specific purpose or domain. They are not general programming languages like Java, C# or Ruby but are tailored toward a narrow task. Depending on the implementation, they can also closely resemble written human language. Applied to automated functional testing, creating a DSL to express testing intent solves several problems.
A DSL for an SUT allows a team to share a vocabulary that describes their domain. If a standard vocabulary is already in use, then using a DSL to express acceptance criteria minimizes translation errors. Furthermore, DSLs allow non-technical stakeholders to interact with the testing effort on more level terms. A properly designed DSL will at a minimum allow these stakeholders to read tests. Under the right circumstances, and with the appropriate skill level, it’s possible for domain experts and non-technical users to write tests as well."
Twist™ is a next-generation collaborative functional testing platform for software teams.
It provides a rich environment for authoring, executing, and maintaining tests. Twist is designed
to be used by subject matter experts, QA professionals and developers, making everyone on
a team jointly responsible for software quality. It allows you to express acceptance criteria as
executable tests, while using Domain Specific Languages. Twist leverages the testing expertise of ThoughtWorks, the creators of the popular web testing engine, Selenium.
Twist
http://www.thoughtworks-studios.com/agile-test-automation/features-benefits
http://www.thoughtworks.com/articles/dsls-functional-testing
“I believe that the hardest part of software projects, the most common source of project
failure, is communication with the customers and users of that software. By providing a clear
yet precise language to deal with domains, a DSL can help improve this communication.” –
Martin Fowler, Domain Specific Languages (working title).
Involving all the stakeholders in the testing process requires that subject matter experts,
customers, testers, and developers communicate consistently and effectively. In the past,
many software project teams relied on extensive requirements documentation to communicate
effectively across these groups. However, requirements in this context require a fair
amount of translation. Subject Matter Experts (SMEs) and analysts must translate customer
desires and needs into requirements. Developers must translate these requirements into code,
and testers must independently translate the same requirements into tests. Finally, each one
of these translations must match the customers’ original expectations, which may change
over time. It’s similar to the telephone game that children play in primary school, only that
the starting phrase is a moving target.
We could effect a substantial improvement to the translation problem if the customers could
express and test their own requirements, or acceptance criteria, themselves. At a minimum,
customers should be able to simply review any translations that occur in the process and
verify that translations match their needs.
One means to ensure that code across a project team is readable by everyone is a DSL.
Domain specific languages are mini-computer languages that are designed around a very
specific purpose or domain. They are not general programming languages like Java, C# or Ruby but are tailored toward a narrow task. Depending on the implementation, they can also closely resemble written human language. Applied to automated functional testing, creating a DSL to express testing intent solves several problems.
A DSL for an SUT allows a team to share a vocabulary that describes their domain. If a standard vocabulary is already in use, then using a DSL to express acceptance criteria minimizes translation errors. Furthermore, DSLs allow non-technical stakeholders to interact with the testing effort on more level terms. A properly designed DSL will at a minimum allow these stakeholders to read tests. Under the right circumstances, and with the appropriate skill level, it’s possible for domain experts and non-technical users to write tests as well."
Twist™ is a next-generation collaborative functional testing platform for software teams.
It provides a rich environment for authoring, executing, and maintaining tests. Twist is designed
to be used by subject matter experts, QA professionals and developers, making everyone on
a team jointly responsible for software quality. It allows you to express acceptance criteria as
executable tests, while using Domain Specific Languages. Twist leverages the testing expertise of ThoughtWorks, the creators of the popular web testing engine, Selenium.
Twist
http://www.thoughtworks-studios.com/agile-test-automation/features-benefits
martes, 3 de enero de 2012
Pasar una VM en virtualbox a VMWare ESXi
Tan sencillo como:
VBoxManage clonehd Ubuntu10.04.LTS-etsii.powered.vdi exthost.vmdk --format vmdk
VBoxManage clonehd Ubuntu10.04.LTS-etsii.powered.vdi exthost.vmdk --format vmdk
lunes, 2 de enero de 2012
Designing web interfaces
Parece que este libro está muy bien
http://designingwebinterfaces.com/explore
Patrones sencillos para hacer mejores nuestras aplicaciones web.
http://designingwebinterfaces.com/explore
Patrones sencillos para hacer mejores nuestras aplicaciones web.
Suscribirse a:
Entradas (Atom)