Sunday, December 6, 2015
Problema: cate prajituri sunt in tava?
O tava dreptunghiulara contine prajituri dreptunghiulare. Prajiturile sunt de aceeasi dimensiune si tava este umpluta intr-o forma de matrice cu aceste prajituri.
Cate prajituri sunt in tava daca dupa ce au fost luate prajiturile de pe margine au ramas 6?
Dar pentru orice numar N de prajituri ramase in centru?
Dat fiind un numar N cand avem numarul maxim de prajituri in tava?
Thursday, July 30, 2015
Securitate la cote maxime: ING si parola de 5 cifre
 |
| Sursa: https://commons.wikimedia.org/wiki/File:ING_logo.png |
Mai multe detalii gasim direct pe site-ul ING.
Citez:
"Totul incepe cu alegerea unei parole potrivite. Astfel, ne asiguram mai intai ca iti vei alege o parola greu de "spart" folosind 5 cifre care nu trebuie sa fie identice sau consecutive (ex. "00000","12345","54321")."
Cred ca au gresit putin cu ghilimelele, trebuia "greu de spart", pentru ca cateva combinatii(*) inseamna cu adevarat ceva foarte "greu de spart", mai ales ca:
- De obicei pui primele 5 caractere din CNP (adica gender + part of birthday)
- O bucata din data nasterii 23/05/1989
- Numarul tau de telefon (primele sau ultimele cifre, de obicei primele)
- Probabil vei folosi doar primele 5 cifre (12345 sau 01234) intr-o combinatie in care nu-s consecutive (01243 sau ceva similar, nimic prea inteligent)
Deci aveti 252 de multimi de 5 cifre pe care le puteti aranja cum vreti voi, doar sa nu fie consecutive (Deci eliminam 0-4, 1-5, 2-6, 3-7, 4-8, 5-9, 6-0(sa zicem) si invers). Deci 14 variante eliminate de aici.
Avand 5 numere dintr-o multime de mai sus putem avea permutari de 5 elemente adica 5! (1*2*3*4*5) = 120.
252 * 120 = 30240 de parole posibile! din care scazand 14 vom avea 30226.
Securitatea in banking incepe cu low security!
UPDATE:
Mai adaugam la asta faptul ca multi au bifata by default optiunea "Doriti inregistrarea acestui dispozitiv pentru autentificari ulterioare?" fara sa inteleaga implicatiile si ING nu depune eforturi in a explica acest lucru.
Deci un brute force e binevenit in astfel de cazuri si sansele de reusita sunt destul de mari.
Intrebarea e: altii au optiuni mai bune decat "low security ING"? Daca da, care?
Thursday, July 16, 2015
DNA - un colosseum cat o tara
Google:
DNA site:.ro
Sanse mici sa fie o stire mai veche de 24h si tot sanse mici sa fie o pauza mai mare de 24h intre stirile despre DNA.
Paine si circ!
Sa curga "sange"!
DNA site:.ro
Sanse mici sa fie o stire mai veche de 24h si tot sanse mici sa fie o pauza mai mare de 24h intre stirile despre DNA.
Paine si circ!
Sa curga "sange"!
Friday, June 12, 2015
Don't buy shitty tech books
Don't buy this shitty book even though it's old and has some stars in review (better read reviews with fewer stars). I'm telling you: don't buy "The Pragmatic Programmer: From Journeyman to Master". It has nothing to do with pragmatic. It simply looks like a book written while travelling, in a break, when tired, while taking a dump etc (you get the idea).
This book can only be good for people that want to chat about programming and have only written short "hello world"-like programs while alive.
---
"Use Saboteurs to Test Your Testing
If you are really serious about testing, you might want to appoint a project saboteur. The saboteur's role is to take a separate copy of the source tree, introduce bugs on purpose, and verify that the tests will catch them.
When writing tests, make sure that alarms sound when they should."
---
So this means that we should test our tests? What the hell is that?
Now really, who in the world allocates budget for testing the tests? It is clearly that who wrote this never understood what developing software means. How much time do you think you need to test your tests when most of the projects don't have enough tests?
Simply idiotic!
---
"Testing Thoroughly
Once you are confident that your tests are correct, and are finding bugs you create, how do you know if you have tested the code base thoroughly enough?
The short answer is "you don't," and you never will. But there are products on the market that can help. These coverage analysis tools watch your code during testing and keep track of which lines of code have been executed and which haven't. These tools help give you a general feel for how comprehensive your testing is, but don't expect to see 100% coverage."
---
Again, it is clearly that this guy (the book was written by two guys) wrote some unit tests for getters and setters and then saw that writing complete unit tests for functions with at least a loop and an "if" is difficult.
As I've written unit test for a safety critical project I had to achieve 100% coverage. Coverage that was not possible was detailed in a report.
Example of code that is not normally coverable (we don't discuss stubs):
~~~
....
handle = OpenFile(...);
if (!handle)
return;
size = GetFileSize(handle);
if (size != 100)
return;
if ( !Read(handle, buff, 100) ) // this will most likely succeed
return; // this won't execute - must explain why
....
~~~
So when I see that sentence with "don't expect 100% coverage" I feel like I need to shout to the author and tell him to stop writing books. Do whatever you do, I'm sure you're good at what you do, but STOP WRITING SHITTY ADVICES!
100% is totally achievable for most of the algorithms written. Special cases like the one above should be documented and documenting it means that the code is reviewed and expected to work ok even in weird cases (for example when drive is unmounted/disconnected exactly after the GetFileSize function).
So, stop writing shitty advices in books, 100% coverage can be achieved even if it means documenting what's not covered.
Oh, and when I mean 100% I mean 100% for most types of coverage (dc,path, mcdc usually):
http://www.bullseye.com/coverage.html
The only reason you can't achieve 100% coverage is laziness from my point of view.
---
"Even if you do happen to hit every line of code, that's not the whole picture. What is important is the number of states that your program may have. States are not equivalent to lines of code. For instance, suppose you have a function that takes two integers, each of which can be a number from 0 to 999.
int test(int a, int b) {
return a / (a + b);
}"
---
If you write code like that monkey above you surely treat all cases the same when in fact you should be treating special cases separately. A sane person knowing what the 0,999 interval means would write code like this:
int test (int a, int b)
{
if (a > 999 || b > 999 || a < 0 || b < 0)
return -1; // invalid
if (a == 0)
return 0;
// right now a > 0 so we don’t get division by zero since b >= 0
return a / (a +b);
}
Any programmer knows about division by 0. The code from the book is simply ... not relevant.
---
"In theory, this three-line function has 1,000,000 logical states, 999,999 of which will work correctly and one that will
not (when a + b equals zero)."
---
In theory, code like that should never be found on a decent file system. It should be found on some whiteboard, paper or other non-it related communication method. Simply putting such code on a file system is an insult to the IT industry. (I apologize to the industry for publishing it)
And what does he mean by "states"? Because I'm thinking of a state machine but he clearly means something else which is ... only he may know.
---
"Simply knowing that you executed this line of code doesn't tell you that—you would need to identify all possible states of the program. Unfortunately, in general this is a really hard problem. Hard as in, "The sun will be a cold hard lump before you can solve it."
Tip 65
Test State Coverage, Not Code Coverage"
---
Showing such arguments only goes to say that some people don’t deserve to use a computer keyboard, not to mention coding. If special cases are correctly identified then coverage is most likely enough. Writing code like a unevolved monkey is no excuse to create a new “pseudo-science” where state means ... whatever the hell the author wants.
So my advice to you is not to buy this book. It is a book full of crap and stupid advices.
What this book does is like recommending people to put a mattress on front of the car to avoid injuring pedestrians. Looks like a new idea, but it is not applicable and in the end it only proves stupid.
I also have some insights on how these types of books are written but that may be for later. I offer just a hint: don't expect the authors to always be the ones actually writing books.
This book can only be good for people that want to chat about programming and have only written short "hello world"-like programs while alive.
---
"Use Saboteurs to Test Your Testing
If you are really serious about testing, you might want to appoint a project saboteur. The saboteur's role is to take a separate copy of the source tree, introduce bugs on purpose, and verify that the tests will catch them.
When writing tests, make sure that alarms sound when they should."
---
So this means that we should test our tests? What the hell is that?
Now really, who in the world allocates budget for testing the tests? It is clearly that who wrote this never understood what developing software means. How much time do you think you need to test your tests when most of the projects don't have enough tests?
Simply idiotic!
---
"Testing Thoroughly
Once you are confident that your tests are correct, and are finding bugs you create, how do you know if you have tested the code base thoroughly enough?
The short answer is "you don't," and you never will. But there are products on the market that can help. These coverage analysis tools watch your code during testing and keep track of which lines of code have been executed and which haven't. These tools help give you a general feel for how comprehensive your testing is, but don't expect to see 100% coverage."
---
Again, it is clearly that this guy (the book was written by two guys) wrote some unit tests for getters and setters and then saw that writing complete unit tests for functions with at least a loop and an "if" is difficult.
As I've written unit test for a safety critical project I had to achieve 100% coverage. Coverage that was not possible was detailed in a report.
Example of code that is not normally coverable (we don't discuss stubs):
~~~
....
handle = OpenFile(...);
if (!handle)
return;
size = GetFileSize(handle);
if (size != 100)
return;
if ( !Read(handle, buff, 100) ) // this will most likely succeed
return; // this won't execute - must explain why
....
~~~
So when I see that sentence with "don't expect 100% coverage" I feel like I need to shout to the author and tell him to stop writing books. Do whatever you do, I'm sure you're good at what you do, but STOP WRITING SHITTY ADVICES!
100% is totally achievable for most of the algorithms written. Special cases like the one above should be documented and documenting it means that the code is reviewed and expected to work ok even in weird cases (for example when drive is unmounted/disconnected exactly after the GetFileSize function).
So, stop writing shitty advices in books, 100% coverage can be achieved even if it means documenting what's not covered.
Oh, and when I mean 100% I mean 100% for most types of coverage (dc,path, mcdc usually):
http://www.bullseye.com/coverage.html
The only reason you can't achieve 100% coverage is laziness from my point of view.
---
"Even if you do happen to hit every line of code, that's not the whole picture. What is important is the number of states that your program may have. States are not equivalent to lines of code. For instance, suppose you have a function that takes two integers, each of which can be a number from 0 to 999.
int test(int a, int b) {
return a / (a + b);
}"
---
If you write code like that monkey above you surely treat all cases the same when in fact you should be treating special cases separately. A sane person knowing what the 0,999 interval means would write code like this:
int test (int a, int b)
{
if (a > 999 || b > 999 || a < 0 || b < 0)
return -1; // invalid
if (a == 0)
return 0;
// right now a > 0 so we don’t get division by zero since b >= 0
return a / (a +b);
}
Any programmer knows about division by 0. The code from the book is simply ... not relevant.
---
"In theory, this three-line function has 1,000,000 logical states, 999,999 of which will work correctly and one that will
not (when a + b equals zero)."
---
In theory, code like that should never be found on a decent file system. It should be found on some whiteboard, paper or other non-it related communication method. Simply putting such code on a file system is an insult to the IT industry. (I apologize to the industry for publishing it)
And what does he mean by "states"? Because I'm thinking of a state machine but he clearly means something else which is ... only he may know.
---
"Simply knowing that you executed this line of code doesn't tell you that—you would need to identify all possible states of the program. Unfortunately, in general this is a really hard problem. Hard as in, "The sun will be a cold hard lump before you can solve it."
Tip 65
Test State Coverage, Not Code Coverage"
---
Showing such arguments only goes to say that some people don’t deserve to use a computer keyboard, not to mention coding. If special cases are correctly identified then coverage is most likely enough. Writing code like a unevolved monkey is no excuse to create a new “pseudo-science” where state means ... whatever the hell the author wants.
So my advice to you is not to buy this book. It is a book full of crap and stupid advices.
What this book does is like recommending people to put a mattress on front of the car to avoid injuring pedestrians. Looks like a new idea, but it is not applicable and in the end it only proves stupid.
I also have some insights on how these types of books are written but that may be for later. I offer just a hint: don't expect the authors to always be the ones actually writing books.
Monday, June 8, 2015
Interviuri
EL: Aveam sala la ora 9 ... mai tarziu nu se putea??
---
EU: Dar despre proiectul pentru care am venit la interviu ce imi puteti spune?
EL: Avem destul timp pentru asta
(probabil dupa interviu?!)
---
EL: Serverele noastre servesc peste 10 milioane de reclame pe luna
EU (gandind cu voce joasa): 10 milioane / ~300 zile pe an ; 1 mil / 30 ~ 30000 pe zi / ~30h --> cam 1000 pe ora / 3600 ....
EU (cu voce normala): Pai nu cred ca e mare lucru ca performanta pentru ca serveste mai putin de o reclama pe secunda. Cel putin asa cred...
EL (contrariat): .... mda
---
Eu recomandand un om care stia treaba garantat.
EU (dupa 2 zile): ce a facut X?
EL (responsabil cu angajarile): Nu l-am chemat. Nu se potriveste profilul.
NOTA: CV-ul e comun cu 80% din ce am eu pe CV cand vine vorba de job description
---
EL: Cum faci sa adaugi o functionalitate dar fara sa restartezi aplicatia
EU: O solutie ar fi un plugin
EL: Da, dar cum...
EU: Pai un plugin... ca in browsere
EL: Pai mai clar...
EU: Un shared object/DLL
EL: Da, asta voiam de la tine
EU: Pai asa se fac plugin-urile...
EL: Da... dar voiam mai clar
---
EL: Va anuntam cand sa semnam contractul cat de repede
EU: Va multumesc
EU: Cum a ramas cu semnatul contractului?
EL: Am uitat sa va spun, proiectul nu a mai ajuns la noi. E in Slovacia.
(acolo era de frecat duda daca semnam - angajat si fara proiect)
---
EL: Care este nota pe care ti-ai da-o pentru tehnologia X?
EU: Nu asta e scopul interviului?
EL (ganditor): ... hmmm
---
Telefonic:
EL: Hi, this is X, recruiter for Y. How are you doing?
EU: I'm ok, doing some shopping...
EL: You could be shopping with a lot of money in your pocket if you were to work for ...
---
Telefonic:
EA (remote HR): Salut, te-am contactat pentru o oferta de job la compania X
EU: Pai acolo lucrez...
EA: Ah, da. Acum am vazut. Spor la lucru
---
EU: Dar despre proiectul pentru care am venit la interviu ce imi puteti spune?
EL: Avem destul timp pentru asta
(probabil dupa interviu?!)
---
EL: Serverele noastre servesc peste 10 milioane de reclame pe luna
EU (gandind cu voce joasa): 10 milioane / ~300 zile pe an ; 1 mil / 30 ~ 30000 pe zi / ~30h --> cam 1000 pe ora / 3600 ....
EU (cu voce normala): Pai nu cred ca e mare lucru ca performanta pentru ca serveste mai putin de o reclama pe secunda. Cel putin asa cred...
EL (contrariat): .... mda
---
Eu recomandand un om care stia treaba garantat.
EU (dupa 2 zile): ce a facut X?
EL (responsabil cu angajarile): Nu l-am chemat. Nu se potriveste profilul.
NOTA: CV-ul e comun cu 80% din ce am eu pe CV cand vine vorba de job description
---
EL: Cum faci sa adaugi o functionalitate dar fara sa restartezi aplicatia
EU: O solutie ar fi un plugin
EL: Da, dar cum...
EU: Pai un plugin... ca in browsere
EL: Pai mai clar...
EU: Un shared object/DLL
EL: Da, asta voiam de la tine
EU: Pai asa se fac plugin-urile...
EL: Da... dar voiam mai clar
---
EL: Va anuntam cand sa semnam contractul cat de repede
EU: Va multumesc
EU: Cum a ramas cu semnatul contractului?
EL: Am uitat sa va spun, proiectul nu a mai ajuns la noi. E in Slovacia.
(acolo era de frecat duda daca semnam - angajat si fara proiect)
---
EL: Care este nota pe care ti-ai da-o pentru tehnologia X?
EU: Nu asta e scopul interviului?
EL (ganditor): ... hmmm
---
Telefonic:
EL: Hi, this is X, recruiter for Y. How are you doing?
EU: I'm ok, doing some shopping...
EL: You could be shopping with a lot of money in your pocket if you were to work for ...
---
Telefonic:
EA (remote HR): Salut, te-am contactat pentru o oferta de job la compania X
EU: Pai acolo lucrez...
EA: Ah, da. Acum am vazut. Spor la lucru
A good reason to know your neighbors
Image the Internet connection drops because of a faulty router. But there are other routers available (and working!), you just don't know which of the connected neighbors will get mad if you switch cables.
It might be that one of your neighbors:
- is out of town
- doesn't need Internet that bad
- rarely uses his Internet connection
- may call ISP in 2-3 days to come and figure out the problem (while being calm)
- understands your addiction (and doesn't want to see some weird Internet withdrawal symptoms)
Having such neighbors provides you a way to quickly gain access to the Internet when needed. But for this you need to know them. Failure to do so is risky as you might end up cutting the Internet connection of some psycho whose reaction cannot be predicted.
It might be that one of your neighbors:
- is out of town
- doesn't need Internet that bad
- rarely uses his Internet connection
- may call ISP in 2-3 days to come and figure out the problem (while being calm)
- understands your addiction (and doesn't want to see some weird Internet withdrawal symptoms)
Having such neighbors provides you a way to quickly gain access to the Internet when needed. But for this you need to know them. Failure to do so is risky as you might end up cutting the Internet connection of some psycho whose reaction cannot be predicted.
Subscribe to:
Posts (Atom)