vendredi 9 octobre 2015

Bookmarklet for password


It's friday,


Today we create a stupid bookmarklet for having no more 100 passwords to remind :

javascript:(function () { var ps = document.querySelector("input[type='password']"); var p = ps.value; var h = window.location.hostname.match(/[^.]*\.[^.]*$/)[0]; if (p !== undefined) { var t = ""; for (var i = 0; i < 10; i++) { var e = (p.charCodeAt(i % p.length) ^ h.charCodeAt(i % h.length) ^ i); t += String.fromCharCode(i < 3 ? 97 + e % 26 : i < 5 ? 65 + e % 26 : i < 7 ? 35 + e % 4 : 48 + e % 10); } console.log(t); Array.prototype.forEach.call(document.querySelectorAll("input[type='password']"), function (d) { d.value = t; }); }})();


You type your password on the first password input of a webpage and it generates a hash with the hostname (ex google.com) and the password you initially typed.
The bookmarklet puts the new hashed password on all relevant inputs and on the console if you want to print it on a T-shirt



vendredi 25 septembre 2015

Continuous development

Hello,

Here is a small trick to enable continuous development with your source control tool (GIT, HG, or many others)

The idea is that maybe your build chain take a bit of time and before having completely polish what you have done you want to verify to everything is working well with you build so far.

Unfortunately if you are doing that, say goodbye to your refactoring that you want to do meanwhile, It will break the running build process.

So what about

  1. Do a patch between latest repository version and you current development
  2. Clone you repository in another location
  3. Apply the patch to the new location
  4. Run you build
  5. Depending on the success/failure status send a system notification  

And of course everything is shell scripted... 
That's trivial but some developers don't know how to do shell nowaday

jeudi 6 août 2015

Better test : featured random generator (1/3)

EARLY ACCESS please provide feedbacks
As of 2015/09/20 I'm still working on a library that enable this kind of test. That a bit harder than what I suggested here and I will end up providing more implementation details 

In this series of 3 articles, I will propose you two tools to improve or implement your testing framework (mainly IT tests).
The idea behind that is to make your test suite more modular, easier to maintain, rich (lot of tests), faster to run and parallelizable.

  • In this first article, I will talk about featured random generator
  • In the second article I will talk about forest testing. 
  • And in the third article I will propose some implementation details

As usual, I will not propose you a complete implementation. Indeed, this blog is more and more a way for me to share ideas and upgrade them. On top of that, proposing an implementation will discard all not java developers. Finally, I hope you will do this work for me :P
So let's start with :

Featured random generator 

In my previous article (you say that value is not used prove it) I introduced the concept of Random value generator. The idea was for an object used in a test to populate not relevant fields for this test with automatically generated random values.

I really invite you to read that blog entry in order to understand this article

Here we will extend this concept in order to populate all fields with smartly chosen random values.

The issue

You have to test some behavior of your application, somehow it's means that you have to specify behavior of your object and not its characteristics.

For instance let say you want to test what append if you crash a car in a wall at 20mph.
Maybe you would like a tests suite like :

Given a not safe car And you send it to a wall at 20mph Then the driver goes to hospital 
Given a safe car And you send it to a wall at 20mph Then the driver will walk to reach its destination

and not something like
Given a car with seat belt, airbag, thick bumper, compressible motor, no sharp flying element And ... 
Given a car with seat belt, thick bumper, compressible motor, no sharp flying element And ... 
Given a car with compressible motor, no sharp flying element And ...
......
It is a lot of tests (it can have in this case up to 32), It is hard to maintain and hard to figure out the normal behavior. Does it bring your more confidence ? when you write it maybe but in one year after when you will have to do a small change, will you pay attention to all this tests ? Be honest ! I won't

Featured generated objects

You get it ? not safe and safe are what we miss in most our test's object creation. A way to specify behavior, annotations to help our random value generator to smartly fill our fields.

And this annotations give a contract to the object to be created. 
For instance if a car is safe 
  • it has a seat belt 
  • it should also have either a thick bumper or a compressible motor 
  • maybe if it have an airbag we can accept to have sharp flying element ... (I'm not an expert in car security)
or, in an other form :
safe = seat belt & ( compressible motor | bumper > 2cm ) & (airbag | !sharp flying element) 
not safe = !safe 
It is at least for now up to you the way you implement this contract but it is obviously not obvious. The main idea is that you need to use your random value generator to create a matching set of properties given the contract you have 

Also, you have to consider that sometime we need objects that have many features that interact. (That is not hard to do if you solve previous problem I guess)


That's it for today, it is late in the evening and I start to fell asleep.