 |
| Framework |
 |
| Library |
Foreword. If you don’t know what lockerz is, my rant won’t help you here. go read somewhere else.
So there is this site lockerz, which some people call scam, and I cannot say I disagree. As I see it, their methods for giving away free prizes are completely disrespectful to their users. Partially because in case user wants to take prize for his honestly earned ptz (thru redemption or 24/7), he’s taken into arena to compete with bots.
If they catch bot users post-factum, after the prize has been claimed by the bot, well the question arises where that prize goes. And why they only allow to place bid with just 5ptz increment? Is there any human being out there who enjoys playing according to such ridiculous rules?
Anyway, that’s not my topic. The topic is that after I’ve realized I’m competing against bots in 24/7, being software engineer, I decided to dedicate one day to think of something that could even the chances to compete with bot. That is: create one on my own.
Lockerz uses reCAPCHA capcha service in their 24/7. And so, user has to enter captcha provided by this service to increment bid by this measly amount of 5ptz, and therefore prove that he is no bot. And yet, the fastest one wins, and has his bid placed while the others are left with a message “you’ve been outbid” and their wasted efforts entering captcha.
We assume automatic recaptcha solver is intractable. Whas is left? Human. One may use human workforce, like decaptcher service. Or, can spend little of his effort and enter some captchas by himself. Captchas provided by reCaptcha have expiration time (usually a few minutes), and (of course) lockerz doesn’t track how many captchas to be solved user has requested. So it must be clear now. We can just “presolve” some captchas, say 10, few minutes before auction ends, and that’s it, we’re in a good position to compete against other bots.
Noone, but atleast I no longer feel being treated like a fool. It’s always unpleasant to realize you were not fully aware of game rules. So know the rules, dear reader, before you start playing the game seriously, and evaluate your strengths over your opponents. I was lucky in this regard.
I was developing Silverlight 4 application for drawing floor plan on a plane. One requirement was, there should be a grid mode, and while in this mode, drawing element should snap to the grid. So I need to display this grid on drawing surface. I could think of 2 options how to display a grid:
The problem with creating rectangle for each grid point was that it appeared to be extremely slow, considering the fact that the grid was supposed to be constantly changing. Maybe it had to do something with the implementation, as grid points were stored in ItemsControl, which was databound to constantly changing ItemsSource.
The problem with background brush is that there is no such a thing in silverlight 4 off-the-shelf. There is just extremely limited range of basic brushes (like SolidColorBrush, LinearGradientBrush). Although it is written in MSDN that you can derive from Brush class, I couldn't find example on how to do this. By definition, brush maps from a point coordinate to a color. Apparently, Brush class does much more, and since it doesn’t provide something like
public abstract class Brush
{
public abstract Color Map(Point point);
}
(apparently, for performance considerations), it seemed like too much of a hassle to mess with the internals of Silverlight to implement my custom brush.
So, after some googling, I came up with 3rd option:
The idea of pixel shader effect is that each UIElement can have a pixel shader effect applied to it. Pixel shader is somewhat similar to a brush: it maps a pixel from the input image to a color at a corresponding location in the destination image. So it is like a better brush, as it can obtain color at any coordinates from the source image which regular brush cannot.
Silverlight shader effects are written in High-Level Shader Language(HLSL), a C-like language, originally invented by Microsoft for Direct3D. Ideally, pixel shaders should be executed on GPU, utilizing its high parallel throughput ability (each pixel can be processed independently). However, as of now(Silverlight 4), it only utilizes CPU’s SIMD instructions. In other words, today it tends to be quite costly, but this may improve in the future.
So, my idea was, I can create a shader effect which works just like a plain old brush: mapping from source coordinates to destination color(source color can be totally ignored). Shazzam is a good to help with WPF/Silverlight effects development. Having no experience with HLSL, I wrote the simplest thing I could think of, like this:
sampler2D input : register(s0);
// Grid effect shader
/// <summary>Size of the lattice</summary>
/// <minValue>1/minValue>
/// <maxValue>10000</maxValue>
/// <defaultValue>40</defaultValue>
float LatticeSize : register(C0);
/// <summary>Size X of the texture</summary>
/// <minValue>1/minValue>
/// <maxValue>10000</maxValue>
/// <defaultValue>1024</defaultValue>
float SizeX : register(C1);
/// <summary>Size Y of the texture</summary>
/// <minValue>1/minValue>
/// <maxValue>10000</maxValue>
/// <defaultValue>1024</defaultValue>
float SizeY : register(C2);
/// <summary>point size</summary>
/// <minValue>1/minValue>
/// <maxValue>10000</maxValue>
/// <defaultValue>2</defaultValue>
float PointSize : register(C3);
/// <summary>point color</summary>
/// <defaultValue>#FF707070</defaultValue>
float4 PointColor : register(C4);
float4 main(float2 uv : TEXCOORD) : COLOR
{
float stepX = LatticeSize/SizeX;
float stepY = LatticeSize/SizeY;
float pointSizeX = (1 / SizeX)*PointSize;
float pointSizeY = (1 / SizeY)*PointSize;
float4 Color;
Color= tex2D( input, uv.xy);
float dx = uv.x % (stepX);
float dy = uv.y % (stepY);
if(stepX - dx < dx) dx = stepX - dx;
if(stepY - dy < dy) dy = stepY - dy;
if ((dx < pointSizeX)&&(dy < pointSizeY) )
{
Color = PointColor;
}
return Color;
}
and this kind of worked, but there was a problem of edge smoothing. Instead of smoothing edges of a grid point, my shader would create them of a different size, which looks very unpleasant:
Another issue was, this shader effect was also quite slow, considering the fact that it had to be applied for 10000x10000 canvas. Possibly due to all the if’s in the shader code. It is certainly possible to improve this shader so that it would smooth the point edges, and also optimize it big time.
The final solution came to my mind after I saw it is possible to create striped brush in Silverlight using LinearGradientBrush, like this
<LinearGradientBrush StartPoint="0,0" EndPoint="0.1,0" SpreadMethod="Repeat">
<GradientStop Offset="0" Color="Red"/>
<GradientStop Offset="0.5" Color="Red"/>
<GradientStop Offset="0.5" Color="White"/>
<GradientStop Offset="1" Color="White"/>
</LinearGradientBrush>
and the idea that we can overlay one canvas on top of the another. So the solution looks like this:
<Grid>
<Canvas Width="300" Height="300">
<Canvas.Background>
<LinearGradientBrush StartPoint="0,0" EndPoint="0,0.05" SpreadMethod="Repeat" >
<GradientStop Offset="0" Color="#FF101010"/>
<GradientStop Offset="0.1" Color="#FF101010"/>
<GradientStop Offset="0.1" Color="#FFF0F0F0"/>
<GradientStop Offset="1" Color="#FFF0F0F0"/>
</LinearGradientBrush>
</Canvas.Background>
</Canvas>
<Canvas Width="300" Height="300">
<Canvas.Background>
<LinearGradientBrush StartPoint="0,0" EndPoint="0.05,0" SpreadMethod="Repeat" >
<GradientStop Offset="0" Color="Transparent"/>
<GradientStop Offset="0.1" Color="Transparent"/>
<GradientStop Offset="0.1" Color="#FFF0F0F0"/>
<GradientStop Offset="1" Color="#FFF0F0F0"/>
</LinearGradientBrush>
</Canvas.Background>
</Canvas>
</Grid>
Which produces the output:
It is still not ideal, as the grid points are somewhat blurred which becomes very apparent as point size approaches 1px on the display. This approach, however, has huge advantage over the others: it is lightning-fast! I think that this, combined with “right” resolutions, will be a reasonable solution.
Let’s say we have two types: 
Also, let’s say we have operator +, for which
val a = List(
a.reduceLeft( (
((
a.foldLeft(
(((
Edge cases:
val b = List[
b.reduceLeft(_+_) //throw exception
b.foldLeft(
val c = List[](
c.reduceLeft(_+_) // returns
c.foldLeft(
Notice the difference: when list is empty, reduceLeft throws an exception, while foldLeft returns starting value. This can often help to decide which one to use.
Examples:
val a = List(1, 2, 3, 4)//sum of integers in the listval sum = a.reduceLeft( (u, v) => u+v )//integers in the list separated by comma, using reduceval strRepr1 = a.map( u => u.toString() ).reduceLeft( (u, v) => u+","+v )//sum of squares, we use Long to support larger valuesval sqrSum = a.foldLeft(0L)( (u, v)=> u+v*v )//number if items in the listvar count = a.foldLeft(0) ( (u, v) => u+1 )//integers in the list separated by comma, using foldval strRepr2 = a.tail.foldLeft(a.head.toString())( (u, v) =>u+","+v )
Is Lean better than Agile? Scrum vs XP? Of course it all depends, and all methodologies can only be to some degree beneficial for current situation. And in the future new methodologies will appear, which will better address problems of the day. There can be no single “body of knowledge” which is relevant forever.
“But what about math”, you may ask. It seems to have stable body of knowledge (say, axiomatic set theory). Well yes, but we are solving problems on a different level today, taking as a foundation all that has been proven before. It’s not that the foundation is irrelevant, it’s that our focus is elsewhere, as we believe the foundation is stable :).
Also, there is no “single true” foundation. We may take another set of axioms and start building all over from there. It just depends on a problem at hand which theory is better.
That said, i feel Lean and Agile are both very beneficial methodologies for the environment I’m working in, ant it’s really pity how badly they can be misinterpreted. (“You’re not following the plan! Can’t you be a little more agile?”, “Agile is total and thorough crap. Lean, that’s out thing!”)
Of course this works, and of course the other part (and then cleaning up the mess afterwards) doesn’t. If you have to clean things up afterwards, the only way is to sacrifice your own spare time.
I’ve never been allowed to do “code improvements” after feature perceivably works. “It works, go on with the next task! Can’t you see how far behind schedule are we?”. No one builds the perfect thing first time, and sadly I often find that my newborn code is not of high enough quality to be sufficiently maintainable. This is reality. I can write good code, but only when I spend some iterations improving it. I cannot make it good enough first time. Yes, it may be possible to do this, but only when working on familiar problem nth time. For instance good OO skills may do half the job, but what remains, the problem domain, and I don’t see a way to model it perfectly the first time.
I don’t want to work on the same damn problem for the nth time…
I wish i could write something like this:
void foo(MyEnum e)
{
switch(e) complete
{
case MyOption1:bar(); break;
case MyOption2:
baz(); break;
}
}
and expect compiler error is MyEnum also contains MyOption3. Of course, I can add
default: throw new Exception();
but this is not always appropriate when the code is not covered by automated tests. In my case, that’s how it is exactly. Some code similar to above is executed only on rare occasions, so there is little probability that the problem will be spotted by manual testing. And when it is in production, it would rather fail silently than throw unhandled exception.
Of course is is considered a bad practice to litter code with such switch statements everywhere, and bar() and baz() would better be virtual functions on polymorphic objects.
