I try not to get too techy in my blog here most of the time, so I apologize in advance for the density of the material.
I've got a few aging production servers that I'm responsible for (Windows 2008-era). Over the past year and a half, I've been having intermittent connectivity problems. Tons of exceptions are being thrown that indicate the server is just...dropping connections randomly. Dropping connections to the client, the SQL Server, or really anything larger than a tiny networking blip. It's not constant enough to warrant a "drop everything and figure this out" response, so it's just been this constantly irritating background noise to more pressing software development concerns.
To add, the error message read "The client disconnected. Invalid viewstate." We're not even using .Net's viewstate that much, so I was understandably confused. I made a few half-hearted attempts to track down the issue, but kept coming up empty.
After finally getting tired of the error and reading a several articles on the subject (also glossing over quite a bit of poking at the code), there seemed to be an issue with Broadcom gigabit NIC cards utilizing the TCP Offload Engine. This nifty feature is supposed to offload checksum calculation and some other TCP stack heavy lifting to the operating system in order to improve networking performance. The recommendation was to disable it entirely.
All our production servers have Broadcom ethernet cards, so after disabling it on all our production systems, our dropped connection issues stopped completely. Fast-forward to several months later, and I'm debugging a problem wherein an application crashes when trying to download a large block of data from a remote SQL Server system, and getting the error: "A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired." Pretty obscure.
This system in particular is a virtual machine running in a Hyper-V server with a physical Intel card, so I dismissed that possibility and focused on the code. After losing a day running down that rabbit hole, I discovered from the "Troubleshooting Common Hyper-V Errors Part 3" article that you can, indeed, be using a TCP offloading engine without a custom driver.
The article recommends disabling only Large Send Offload, but I'm really sick of this issue. Rather than taking a stepwise approach to solving the problem, I've just gone ahead and disabled offloading for all servers that are pre-2012 since Microsoft disabled the feature in 2008 R2 onward for gigabit adapters (presumably because it's so problematic). If networking speed is compromised as a result, I'll upgrade the hardware in question.
I hope I can save someone else the time figuring this issue out.
I wanted to do something I figured would be relatively simple. After all, we're doing it in .Net with a third-party library: Create a PDF with text from a database with vector graphics incorporated in the page. Turns out, it's pretty easy if you want a paid solution; numerous libraries exist for PHP that are non-free. If you insist on going free-only though, be warned: here be dragons (maybe).
While testing LESS on my local server, I used
less.js to process my
.less stylesheet on the client side. It worked well, and on modern browsers the processing time is minimal, but I decided to look around for LESS compilers anyway. I discovered SimpLESS nearly immediately, and it looked perfect.
.less file is as easy as drag-and-drop, and it monitors the file for changes. When your file is saved, it is nearly immediately compiled into a CSS file. If you've made an error in your file, the file highlights red and specifies the line number at which the problem occurred. Output is pure, minified CSS goodness.
SimpLESS, by default, inserts a comment at the top referring to its website. This can easily be disabled if you like.
When I first started using SimpLESS, I was copying and pasting the output into a WordPress template style.css file, which requires a properly-formatted comment at the top to describe the theme. Since SimpLESS performs minification, comments are stripped out. I thought this was the only way to keep my WordPress theme comment intact while still using the features of LESS. This copy-paste tedium was something I specifically wanted to avoid in the first place.
Note: The remainder of this post was written before SimpLESS users complained enough about this very issue, so theme comment preservation is no longer an issue.
I thought that there must be some way to preserve a comment when compiling. Surely that wasn't an uncommon use case? I checked out the SimpLESS source code to see how it was performing its minification (
master/Resources/js/clean_css.js, line 30 if you're interested), and saw they included a special character to preserve certain comments: the exclamation mark.
style.less file), simply put an exclamation point after the initial comment delimiter, like so:
/*! Theme Name: My Super-Cool Theme Theme URI: http://www.pixelbath.com/ Description: Blah blah blah... [cut for length] */
The exclamation point is ignored by WordPress, and if you have SimpLESS processing your style.less file, you can continue to upload your theme's
style.css file as usual.
I actually wrote this last week for a project I'm working on, so imagine my surprise when I see Grant Skinner's post on 9-slice scaling bitmaps in Flash.
His method uses a JSFL script to pre-slice bitmaps into separate MovieClips, which is great, because it's otherwise a complete pain. Mine works on a different principle, and is for runtime use.
Currently, there is no boundary checking (other than for negative values), so it's up to you to implement this. Alternatively, you could wait until I add more features (which could be anywhere from weeks to months, honestly).
Also, if you're not a hardcore Actionscript guy, Grant's method is quite ideal.
I've been impressed with what the Processing community does with generative art, and Actionscript seems to be at a point where it can be used much like Processing. In that vein, I've been watching Mark Knol's generative art for a while, and while I wanted to do something like it, I've never actually bothered to create sit down and start coding it up.
Today, I tried to recreate his work on the Google logo. While mine doesn't seem to have as much depth or chaos, I think it turned out fairly well. With some tweaking, I could improve it, but for now I just wanted to put something out there.
Hope you like it!
Earlier, we learned how to block ads at the OS level. Blocking ads through the browser is awesome, but advertising these days is all about making inroads to the desktop. Even though Microsoft claims that their business is software, Live Messenger seems to be an ad vehicle. I quickly became tired of video ads constantly showing up in Live Messenger (especially those insipid Tru dating site ads) that would play as soon as the cursor went over them, so I resolved to do something about it. I fired up Fiddler, a proxy that allows you to view HTTP traffic. I saw several random requests for rad.msn.com, and upon further examination saw that it was serving ad content, which depending on the content type, would be handled appropriately by Live Messenger's ad box.
I added rad.msn.com to my hosts file, and the ads were now blocked. Since there was now a blank box, I decided to go a step further and replace the image. I tried this before with a program that patched the ad out of the executable, but this isn't a long-term solution, since any software update will require waiting on a new version of the patcher, and a subsequent re-patching. If I just serve a different image up, it's fairly future-proof because Messenger is one the wiser. No matter what subdirectory or file is being requested by Messenger, this script will always throw back the custom image.
Using the index.php file we ended up with on our last ad-blocking adventure, we will add the following before the html is sent to the browser:
The exit() is added so we can bail out early after serving my custom image, and not serve up the normal adblock page (that I see in my browsers). The image size for the Live Messenger ad is 231x60 pixels.
I opted for an image that would blend in with the skin I use for Live Messenger, but wasn't just a "blank space here" image. The skin shown is Oil Slick for Messenger Plus! Live.