Well, I , for one, amd lazy ... it shows in my work, it shows in my lifestyle, it shows in my weight .. and it shows in the way I write code. I'm the guy that will spend 2 days writing an app (which is available for purchase on the Google App Store) because I'm too lazy to get up and get myself a credit card ... because I'm too lazy to get up and scratch in the drawer for my old credit card so I can purchase stuff from Google Play ...
Before you go ranting that I expend time and effort to write an app which costs $3 ... you must remember that I am a programmer .. code it like water to me - extremely bitter, and mostly salty water, but water nonetheless ...
I eat code, I think code, I dream code and I can churn out code if I want to because it has become second nature to me. So it's simpler for me to just write it myself than it is to actually expend some physical effort to go and find something ... you cannot grep in the real world. You cannot hit [Ctrl][F] after opening your drawer. Frankly, I should patent some kind of "Reality Search" function which would apply itself to real-world objects ... but I'm too lazy to go down to the patent office to get it filed in person... Even if I could file patents online in my country, I would be too lazy to get up off my ass to go and use my new function...
Which brings me to the crux of my post ... why would I use python for such a serious task? What I am trying to do is definitely non-trivial, but surely PYTHON?
Well, the truth is that I am too lazy to go back to coding things in C++, I am not an Environmentalist, nor am I a packer ... I am more of a "mapper" who likes to interpret and adapt information into some kind of "view" which can be applied to knowledge ... and my "view" of the matter is that if I need the blazing speed to shoot myself in the foot a trillion times while simultaneously being bitten into millimeter sized pieces, then C++ is the way to go for every project.
If I were to use C++, then I would have to either write little command-line programs which did something specific with some command line input ... and tie that into my server (I'm using Apache - it's easy to set up, and doesn't require any movement on my part) ... or I could churn out some high-level code using a high-level "interpreted", "dynamically typed" language like Python... which saves on compile time, debug time, the amount of keystrokes I have to bang out ... it saves on heart rate as there is less agitation, and it saves on breathing since there is less cursing...
It's kind of a simple choice, really. For anything web-related, use web technologies ... for industrial "blazing speed", specialized applications, then get closer to the hardware with C or C++ ... For the record, I prefer the straightforward nature of C (I have spent several years coding industrial apps using C - if it's not straightforward, then you misunderstood something) but I love the speed you get when you can bang out a couple of object, an interface between them and then set them loose on the world of C++ ... so it's a trade off really. You just need to know which hammer will beat which nail, then all should be fine.
So back to the app - it's a very simplistic application:
- Set up a "service" running in apache which allows an authenticated user to receive a screenshot containing all visible web cams on the home network.
- Send these screenshots at some interval to the authenticated user.
This is fairly simplistic - since I will not even get into the hair raising mess of authenticating a user...
The simplicity is in how one would collate the images and send them over the network ... it's fairly straightforward to get the images - leave the DVR software running all the time, and periodically take a screenshot using this function:
wDC = win32gui.GetWindowDC(HWND_DESKTOP) #hwnd
_w = win32ui.GetSystemMetrics(SM_CXSCREEN)
_h = win32ui.GetSystemMetrics(SM_CYSCREEN)
dataBitMap = win32ui.CreateBitmap()
dataBitMap.CreateCompatibleBitmap(dcObj, _w, _h)
cDC.BitBlt((0,0),(_w, _h) , dcObj, (0,0), win32con.SRCCOPY)
This would give me some image with a predetermined name which I could look up on the drive when I needed it ... I would probably store the images in a folder which represents the images from a specific cam on a specific day ...
Loading up the image is easy ... displaying it to the user is equally easy ... write a little JS function which requests an updated image via Ajax at some interval... Embed an <Object> into the HTML, tie it to the JS and VIOLA! You have a bandwidth-friendly solution to a home-surveillance problem...
This is obviously a gross oversimplification of the whole app, but it would definitely work along these lines ... I would obviously write some code (using PIX or Pillow) to convert the images to JPEGS on the fly either before saving, or at request time ... but the basis is the same. Obviously I would have to port forward on my router to allow that to happen ... but luckily DynDNS has made that much simpler, and all the grunt work of getting it set up , and obtaining a DOMAIN with a dynamic IP has been taken care of .. I have even assigned a static IP to my "surveillance" box which runs the apache server .. so most of the setup work is done .. all I need to do is to tie in some way of getting screenshots at a specified interval - which is equally easy ... write a "backdoor" into the system whereby I can leave a browser window open on the same machine running some periodic Ajax function which would force the server to respond at some predetermined interval - when I get a specific Ajax request, then do the hard work ... very hacky, but sufficient for my purposes - I could hack this together in a day. Now, imagine doing all of that, AND writing the C/C++ code to back it up? Can you imagine the pain and agony and suffering you would go through simply debugging why X won't initialize before Y?
If I wanted ultra-secure 128bit encryption and blazing fast real-time RTSP streaming web app, then I would be forced to resort to a C/C++ HTTP server which relies on the live555 media streaming library somewhere... and then write a C/C++/wxWidgets-backed client side which decodes and displays using FFMPEG... but, thankfully, I don't need to go that route just yet :-)
Thanks to pyfunc over at StackOverflow for the screenshot function, which I am generally going to plunder from the SO site - as much as I plunder many lines of code from awesome coders who are not as lazy as I am.