by Bogdan Varlamov (a.k.a. Phantom Stranger)
I've often found myself working on a class in some legacy application using objects hidden away in third-party libraries and thinking, "Wow... it would be really great if I could call this current existing method but have it process asynchronously (without blocking) and then notify me when it is complete."
The only way to do this would be to inherit the legacy object and add a new "Async" version of the method, right? And what about those pesky sealed classes? Not to mention the problems with having to refactor your whole application (and perhaps any dependent components used by other applications).
It can be quite a mess! But, luckily there is a simpler way...
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
We've all been there before--trying to track down some insipid bug which is impossible to reproduce on a developer's machine. What is the response? To add more logging of course!
That's all well and good, but eventually your log files are going to start getting huge. Don't get me wrong, I LOVE applications with good logging. (In my opinion it's much better to "overlog" than "underlog" [or not log at all!]). But, sometimes it makes sense to cut back on the amount of logging to save disk space, or to make the log files easier to digest...
How can this be done? Certainly not by removing logging from code!
Would you like to know more?
One of my clients asked me to write a very simple RESTful web service to retrieve user data (name, email, address, etc.) based on login credentials. Having recently finished working on a PHP-driven RESTful interface for another client (based on the Zend Framework), I thought this would be a simple and straightforward task. As comedian Bill Engvall says: "Here's your sign!". I should have known better. Would you like to know more?
The main purpose of RealCodersCoding is to post about problems we, the authors, have overcome in our daily coding adventures. Sometimes, the problems we are faced with are complex and require some interesting coding yoga to to work out. Other times the solutions are drop-dead simple, but we refuse to recognize them. Here's a little post about how I wasted an entire freakin' day to one of the latter.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
One of the great things about .NET 3.5 is that it is fully inter-operable with .NET 2.0. You just have to reference the right assemblies and you can use WPF and Windows Forms from the same application! This is great for slowly migrating a .NET 2.0 application over to .NET 3.5; all you have to do is add the new functionality while keeping your old .NET 2.0 logic. Once you are ready, you can slowly migrate your old code over into .NET 3.5 as needed.
Well...at least it's all that easy in theory; there's just one pesky little hiccup--a System.ExecutionEngineException...
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
I recently ran into an issue with an application that was not detecting a physical network problem and was consequently losing data while attempting to write it to the socket.
I know what you are thinking. Sounds like poor programming; surely the .NET Socket class has a clean and Object Oriented way of handling network failures.
That is what I thought at first. The .NET Framework is filled with tons of goodies--namespaces with classes that make coding life easier. I am usually fairly satisfied with what is available in .NET (especially in .NET 3.5), but when it comes to the System.Net.Sockets namespace, there is just more to be desired.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
I've been doing a lot of work with .NET Sockets lately, and I will be posting more articles discussing what I've been working on in greater detail. In this article, I want to talk about the concept of reading a Socket asynchronously, raising events to notify your application when bytes are received, and minimizing the number of times the callback method is processed.
If you are familiar with .NET Sockets you might already know that there are asynchronous methods to receive bytes from Sockets (Microsoft has an Asynchronous Server Socket Example available if you are interested in seeing code for doing this).
In the above code sample, a StateObject class that contains a byte buffer with a static size is passed around. When the asynchronous socket read happens, incoming bytes are stored into this buffer and then passed back to the receive callback method. This example works fine, but I think there are some optimizations that can be applied.
Would you like to know more?
- Published:October 6th, 2008
- Comments:No Comment
- Category:PHP, XML
-
Share / Bookmark
One of my current clients has an old FoxPro (old as in created in '97 and upgraded in '99) database application that the users can't stand. It frequently crashes and it's all too easy to lose valuable data after a lengthy data entry session (just by clicking the sadly misnamed Save button). We are porting them over to a LAMP-based web application. One of the early tasks in this project is to analyze their existing database structure. This application involves hundreds of FoxPro DBF files which are tables (data and schema) that reside in various child directories.
My initial approach (following the KISS principle) was to inspect some of these files and see what's in 'em and how to get the schema out of 'em. I downloaded a trial version of DBF Viewer 2000 and it's a fine tool. I was able to view the data and the schema and, using SnagIt, I captured the text and pasted the values to an Excel spreadsheet. But purely manual approach would take way too long for me. Time to whip out a quick script. The problem: .NET or PHP or other? I'm a recovering .NET dev working on PHP apps. I surprised myself by deciding to go for the PHP option. And I'm glad I did. Here's how I was able to create an Excel spreadsheet with hundreds of worksheets in PHP.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
Do you have an application that starts misbehaving randomly? You aren't quite sure what is going on, but it seems like for some reason your Timer just stops firing it's event handler--and once it stops it never starts back up.
This drove me nuts! But, it is definitely a problem in the Windows Server 2003 SP1. This bug is particularly devious since even if your application uses extensive logging it maybe be nearly impossible to find proof of a timer not firing in your logs.
Short of implementing a Homer Simpson type of "everything is okay alarm" is there anything you can do to determine whether or not your application might be suffering from dying timers?
Would you like to know more?
I was introduced to the world of agile software methodologies and, in particular, Scrum at my last company. In fact, on my first day new whiteboards were delivered to almost every office and a book called Agile and Iterative Development: A Manager's Guide by Craig Larman was handed out to at least one member of each dev team. We were told to choose an agile approach that works best for our team and go for it. However, I later learned that we were to choose any approach we wanted as long as it was called Scrum. In that effort, I helped to wrangle our usual cat herding approach to software development into something closely resembling Scrum processes. It was fun and challenging and a very eye-opening experience.
Would you like to know more?
