gsilos

Why?

Since it is not possible to rely on the encryption that is provided for us in our daily applications (email, chat, etc), so, I decide to create this method as an alternative to quickly send sensitive data through current chat applications, email, etc.

How?

Using openssl in both sides (the sender and the receiver) is possible to exchange encrypted messages using our preffered chat application. In this process, I tied receiver's github account with his SSH public key, that way we can believe a little bit more if the receiver is who we think he is.

Before starting

c5e3

#!/bin/bash

modprobe -r ec_sys
modprobe ec_sys write_support=1

on="\x8a"
off="\x0a"

led(){
	echo -n -e $1 | dd of="/sys/kernel/debug/ec/ec0/io" bs=1 seek=12 count=1 conv=notrunc 2> /dev/null

PurpleBooth

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

eliasnogueira

Hoje um colaborador da lista sobre Teste de Software [DFTestes] (http://br.groups.yahoo.com/group/DFTestes/) perguntou em uma thread sobre PhantomJS qual era a difernça entre Smoke Test e Acceptance Test. Ai resolvi responder. Como a lista é somente de acesso aos usuários registrados, estou colocando um resumo, na minha ótica, a diferença entre eles:

Dentro de um contexto ágil nós temos uma separação clara do que é smoke test e o que é teste de aceitação.

• Smoke Test: conjunto de testes (bem menor do que o conjunto de teste de aceitaçaõ, que vai configurar posteriormente em uma regressão) com o intuito de validar se os pontos maisimportantes da aplicação continuam funcionando após as alterações.

• Teste de Aceitação: São os testes funcionais que conhecemos. Em um contexto ágil eles são chamados de aceitação ao invés de funcional, pela ótica que adotamos a estes testes, que vão tanto validar a aplicação funcionalmente como validar também da ótica de um usuário (fazer uma venda completa, por exemplo). Este

unak

* Only the releases of the stable versions are listed in principle.  The releases of the unstable versions especially considered to be important are indicated as "not stable."
* The branches used as the source of each releases are specified, and the branching timing of them are also shown.  BTW, before subversionizing of the repository, the term called "trunk" was not used, but this list uses it in order to avoid confusion.
* In order to show a historical backdrop, big conferences (RubyKaigi, RubyConf and Euruko) are also listed.  About the venues of such conferences, general English notations are adopted, in my hope.
* ruby_1_8_7 branch was recut from v1_8_7 tag after the 1.8.7 release because of an accident.
* 1.2.1 release was canceled once, and the 2nd release called "repack" was performed.  Although there were other examples similar to this, since the re-releases were performed during the same day, it does not write clearly in particular.
* Since 1.0 was released with the date in large quantities, the mi