|
Rohan Leuva wrote: When you don't know what you're doing it's best to do it quickly"- SoMad>
Similarly, I think it was the Flying Karamazov Brothers who said, "It doesn't matter how you get there if you don't know where you're going."
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
Ah, that was so much easier than trying to figure out a captcha.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
It's on a website my kid sister probably doesn't frequent.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Was it like this?
Uncheck □ this -> □ if □ you □ are □ not □ a bot □.
|
|
|
|
|
No, just the one checkbox.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Can't find it with Google. Is the most relevant result hidden from me?
|
|
|
|
|
Wow, that's very ... uhm ... secure.
I once came across a site where they showed a series of pictures with checkboxes and you had to check all the vehicles and leave the rest unchecked. Try writing a bot for that.
|
|
|
|
|
Algorithm: Randomly check or uncheck each box. If there's five pictures, then you'll successfully bypass the security 1/32 times.
Bots have infinite patience, and checkbox-based security can usually be brute-forced.
|
|
|
|
|
jesarg wrote: 1/32 times
Are you assuming exactly one vehicle? I assumed that any, all, or none would meet the criteria.
Whoops, no, I see it now, sorry.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
There were about 30 pictures perhaps. If you only allowed a few tries before it locked up, it would be pretty secure, I suppose. (I'm not an expert) But nothing is 100% secure of course.
|
|
|
|
|
I thought this forum consisted of only experts! (then I ask myself why would I be here then!)
|
|
|
|
|
If you display a lot of pictures at once, then the system becomes just as annoying to users as a captcha.
Also, you'd have to maintain a large and constantly-changing database of pictures to keep the bot from memorizing which pictures are the vehicles.
In any case, defeating the bots is a much bigger task than people realize. If bot writers are willing to create advanced algorithms capable of deciphering a captcha, then they are willing to go to great lengths to defeat other security features, too.
|
|
|
|
|
I've seen that with "Kittens" and "Puppies" as well - very damn annoying!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
For something I'm working on, I want to test a given XmlElement with a provided XPath predicate to determine whether or not it's the droid node I'm looking for.
public static bool
IsMatch
(
this System.Xml.XmlElement Element
,
string Predicate
)
{
return ( Element.SelectSingleNode ( "self::node()[" + Predicate + "]" ) != null ) ;
}
I wasted an hour trying to get .[predicate] to work.
System.Xml.XmlDocument doc = new System.Xml.XmlDocument() ;
doc.LoadXml ( "<Foo Bar='Baz' />" ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "." ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::node()[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::*[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( ".[@Bar='Baz']" ).OuterXml ) ;
<Foo Bar="Baz" />
<Foo Bar="Baz" />
<Foo Bar="Baz" />
System.Xml.XPath.XPathException: '.[@Bar='Baz']' has an invalid token.
The book I have says . is equivalent to self::node() , but that's not true,
. returns a node, whereas self::node() returns a node-set, and you can only apply a predicate to a node-set.
Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
How about this?
public static bool IsMatch(this System.Xml.XmlElement element, string predicate)
{
return element.CreateNavigator().Matches("*[" + predicate + "]");
}
If you're going to be re-using the same predicate for a lot of elements, you might want to pre-compile it[^]:
public static bool IsMatch(this System.Xml.XmlElement element, XPathExpression compiledPredicate)
{
return element.CreateNavigator().Matches(compiledPredicate);
}
...
var compiledPredicate = XPathExpression.Compile("*[" + predicate + "]");
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, I'll try that too and maybe do some performance comparisons. Performance really isn't an issue with my current usage -- about forty elements being checked with a predicate provided on the command-line.
Your second implementation might make for the basis of an enumerator.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Found an interesting feature in Microsoft Dynamics Ax 2012 R2:
static void Job40(Args _args)
{
smmBusRelTable bus;
int i;
select count(RecId) from bus where
bus.BusRelAccount == bus.TopLevelAccount
;
info(strFmt("From count: %1", bus.RecId));
i = 0;
while select bus where
bus.BusRelAccount == bus.TopLevelAccount
{
i++;
}
info(strFmt("bus.BusRelAccount == bus.TopLevelAccount: %1", i));
i = 0;
while select bus where
bus.TopLevelAccount == bus.BusRelAccount
{
i++;
}
info(strFmt("bus.TopLevelAccount == bus.BusRelAccount: %1", i));
}
Running the job results in this output:
From count: 31597
bus.BusRelAccount == bus.TopLevelAccount: 1
bus.TopLevelAccount == bus.BusRelAccount: 31597
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
A badly designed operator override? At least fun to see that (bus.BusRelAccount == bus.TopLevelAccount) != (bus.TopLevelAccount == bus.BusRelAccount)
|
|
|
|
|
I wish it was that easy. But X++ does not have overrides, the Dynamics Ax VM creates SQL statements from this code.
By tracing statements in the SQL Server I may be able to see the different statements created, but the bottom line is, that this should be a very very simple comparison, and having a failure here, gives me the creeps.
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Ah, I see. Reminds me of an old "obfuscted" Access database, where
SELECT * FROM A, B where A.ID=B.A_ID
was different from
SELECT * FROM A JOIN B ON A.ID=B.A_ID
The trick was that in one case padding with spaces was relevant, in the other case not.
|
|
|
|
|
Ha!
I found the problem. DAX uses a caching mechanism to avoid too many roundtrips to the SQL Server.
If you're using the primary key in a query, then DAX will search an in-memory cache to retrieve a single record.
Apparently, DAX gets confused when I use the primary key field busRelAccount on the left hand side of the comparison. Using bus.disableCache(true) fixes this problem.
I hope they get rid of this bug soon, I really don't like to think of all the places I could have trusted this to just work.
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Because there is no other way to compare OrderNumber to 0
Private Function IsNew(ByVal OrderNumber As Long) As Boolean
Return IIf(OrderNumber = 0, True, False)
End Function
It's not horrible, but it's pretty representative for the code as a whole.
A lot of redundancy, a lot of global variables, no null values (but still NullReferenceExceptions...), Forms with 1000+ lines of code, etc.
VB is not the problem, it's the programmers that code it.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Where do you see the problem behind that code that justifies it to be posted in the Weird and Wonderful?
Well, that IsNew function should better be a function of the Order class and not need a parameter (because OrderNumber could be expected to be a Property).
But otherwise? Does VB.Net have the ternary operator like C# (return OrderNumber = 0 ? true : false;)? I don't know.
Or did you want to tell us that it's better to do the comparison of OrderNumber to 0 whenever that IsNew function is used? Oh no! That would deserve to be posted here! IsNew clearly tells you the intention of the code, while If(OrderNumber=0) does not.
|
|
|
|