Thoughts and insights from the front line of development. Focuses on PHP and web development with xHTML, CSS, and Javascript.
jacob | 24 June, 2009 20:14
My Father's been lucky enough to secure some time at a small log cabin in the Adirondacks. If you need me, I'll be on Balfour Lake with most of the family.
Hopefully I'll have pictures when I get back!
jacob | 19 June, 2009 07:47
Looks like the Linux Outlaws have started up their own Planet: OutlawPla.net.
I'm a bit worried that some of my posts on this blog are a little off-topic, even for the Outlaws (folks coming from the Forums will know what I mean). I'll be digging through the LifeType documentation to see if I can filter my RSS feed a bit, to prevent the FragDev-related news from hitting the planet site. If that isn't possible, I'll probably switch to manually updating the news and keep it off the blog. We'll see...
jacob | 30 May, 2009 13:12
The first site hosted on the new server is up: make sure to take a look at Lena's Adult Day Services!
If all goes well, I'm going to start moving the rest of the sites on there one by one. This should drop everyone's hosting costs by about 40% - 50%!
jacob | 30 May, 2009 11:46
The Arduino, as described by the Arduino Homepage, is "an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software." What that means to you may differ with your experience, but to me the Arduino is a little chunk of Italian-made circuit board that can make LEDs blink, can tell how bright the ambient light is, can run motors and mechanisms, and otherwise make electronic components do cool stuff.
There seems to be no limit to what people are capable of doing with one of these, with the addition of the right components. Just search YouTube for Arduino and you'll see what I mean. LED cubes dancing to music, robots that seek out the light – one of the guys from our LUG used his to have his dehumidifier tweet whenever it's full, and again to thank him for emptying it. If you would like to follow his dehumidifier, you can do so: Mark's Dehumidifier.
So, as a step towards building my Linux-powered robot to satisfy a New Years resolution, I picked one up. I also bought a couple wires, LEDs and other random components to test with. It arrived yesterday, and pictures will follow (once I get my camera some batteries).
So far I haven't gotten too much accomplished. I've caused a single LED to blink on a schedule, and to react to the light level of the room using a photoresistor. I've also realized that I don't remember anything from Digital in high school – big suprise. Most of last night was spent looking up resistor color codes and re-learning the basics of electronics.
All things considered, I'm very optimistic about how it's going. I'll keep posting progress here for anyone that's interested!
jacob | 08 May, 2009 11:25
This maddening issue took quite a while to figure out, so I sincerely hope I can save somebody the time by documenting it here.
First of all, here's the environment - at work, we're using the following:
Yes, that's right, I have no control over most of the environment. Whatever. Moving on - we were having a problem with one of our new pages. Specifically, getting the information from the database and displaying it on the page.
Whenever I tried to run the query to get the database results, the script would consume all available memory immediately and halt the page execution. We're not talking the normal 8MB of RAM allocated to each page, either: we have our memory allocation bumped up to 128MB. Somehow this script consumed all 128MB and asked for more with just five result rows, each well under a couple kilobytes.
We were able to (somehow) deduce that the problem was in the table itself: apparently PHP's ODBC driver has a fit if there is a 'text' or 'ntext' field involved. It simply consumed all the memory and then quit.
Not a problem, though - MS recommends you stay away from those fields anyways, and instead use nvarchar(MAX) or varchar(MAX). A quick little switch, and we were on our way...
...to an even worse problem. Now, the same field that we had just modified was displaying - but not the text that field contained. Instead, it almost looked as if PHP was dumping memory into that field instead of the text itself. Inside of all the binary symbol garbage I saw things like function names, string values, and more. Extremely upsetting.
After a day and a half I figured out that the new nvarchar(MAX) data type seemed to be the cause, and switched it to the more bland (and not as scalable) nvarchar(1000). Still, if this had happened to one of our live pages, we could have had a serious security problem.
In conclusion, I will stay away from the following SQL Server data types as a sort of "preventative best practice":
If you have the option, I would recommend staying away from MS SQL Server all together. We have had no limit to the amount of problems this sub-par database has caused. Just use MySQL, PostgreSQL or one of the superior Free alternatives.
jacob | 08 April, 2009 16:55
I recently came upon an extremely quick, simple, and brutal to insert a file into a MS SQL database using only the query editor and a hex editor:
INSERT INTO table (binary_field) VALUES (0x!!!)Now, this is far from recommended practice. In fact, this is a damn ugly way to do things. However, I didn't want to muck around in a scripting language, and the other SQL methods I found had too much SQL to them. SQL is not my strong suit, so voila – there you have it.
jacob | 04 March, 2009 12:32
I ran into a very sticky issue while writing a very complex set of PHP classes: I continually ran into the "Class '[ClassName]' not found" error, even though the classes were clearly defined – sometimes even in the same file. This drove me nuts for hours.
I did some digging into the PHP class documentation, and it turns out that you cannot extend extended classes in PHP, and instead of giving you a helpful error message, it just says that the class cannot be found.
As an example, if you have a BaseClass class, and another class that's defined using NewClass extends BaseClass, you cannot then say ExtendedNewClass extends NewClass: that will throw a "Class 'ExtendedNewClass' not found" error.
I don't think I've found the bottom of this problem, so I'll continue adding any new information that I find.
jacob | 25 January, 2009 09:04
This weekend I've been able to dedicate some time to revamping the Fragmented Development web site – which really needed it. The layout that has been up since 2005 has served me well, but this one will be much easier to manage.
Also, it is less offensively orange.
I've updated the navigation bar to include some of the new pages, one of which is the blog, which has languished in obscurity for far too long!
More to come...
jacob | 09 January, 2009 12:05
This is really just a quick piece of trivia, but can cause tremendous problems if you're not expecting it.
PHP does not, by default, call the parent class' constructor when you create an instance of an extended class.
If you would like to have this happen, you must add a manual call to the parent constructor, like so: parent::__construct();.
This caused some very random issues in some of my layout templates, so hopefully I've saved you the trouble of tracking them down. Enjoy!
jacob | 01 January, 2009 00:50
After recently taking a trip down memory lane with the old DOS-based Id game, Hexen, under Wine. I discovered a very random issue with my installation of Ubuntu 8.10 (Intrepid Ibex): my right alt key didn't really do anything.
I guess I had never used it previously, but in Hexen, alt just happens to be the "strafe" key. This made it extremely difficult to stay alive, which motivated me to find a fix.
It turns out that it's actually a problem with the keyboard layout that was detected automatically. Easily remedied by doing the following:
Pretty obscure, and I'm not sure what other side effects it may have, but it did the trick for my particular keyboard/layout combination; I'm using a Kensington K64362 Standard Keyboard with the USA layout.
Hope this helps somebody out there!
jacob | 29 December, 2008 09:13
Web development is entirely reliant on browsers to display web sites. Without browsers, the large majority of the Internet would cease to be useful – or functional for that matter. So how is it that browsers don't matter?
Each browser has at it's core a layout engine, and this layout engine actually determines what the page displays. While we have dozens of browsers to accommodate, most of them share layout engines. Safari, Konqueror, and Chrome all use Webkit (originally KTHML); Firefox, Camino, and SeaMonkey are all Gecko browsers.
The majority of the layout engines render content according to the W3 standards, and should render your page in a similar fashion. There are very few browser-specific bugs these days, and most of them are pretty obscure.
They have a saying about generalizations, and this one is no exception. Out of all the layout engines, one still remains a thorn in the side of most developers: Trident, the layout engine of Internet Explorer, in use since IE4. I'm not sure if they've actually beaten Trident into shape for IE8 or created a new engine, but it doesn't behave like old Trident. In fact, Trident doesn't always behave like Trident, depending on what version of Internet Explorer you're testing. Each version has their own bugs, some of them show-stoppers, like IE6 's problem with fixed positioning and lack of alpha channel support in PNG images.
Even without IE8, the development landscape is much better than what it was years ago. Instead of checking your page against every major browser available, you can develop a standards-compliant page and make sure it displays correctly in a Webkit-based browser and a Gecko-based browser. Sure, you still have to run it by every version of IE in use, but we're one step closer to forgetting the pain of browser inconsistencies and CSS hacks.
jacob | 16 December, 2008 13:16
GoDaddy doesn't allow sites to write files to the filesystem using the PHP filesystem functions. This may be due to security concerns, but it put a kink in the comic system. Storing strip images could always be done through the database, but that adds a whole extra layer of complexity and performance drain to the application.
To get around these drawbacks, I ended up using the FTP extension to bypass the Filesystem extensions entirely. GoDaddy allows you to upload your files through FTP, so I created a second account for the site itself to use and funneled all of the files through the FTP functions. I abstracted as much of this as possible, so that if we ever regain the use of the filesystem functions I can switch to those without much hassle.
This method worked incredibly well, considering it was originally meant as a workaround. FTP provides almost all of the basic functionality of the filesystem functions, but it does require the extra overhead of managing a connection and requiring a username and password. I would be interested in seeing if there was any performance cost involved with running through the extra layer of abstraction.
One glaring issue came up while using the FTP functions in place of the filesystem functions: temporary files. The FTP functions (at least in PHP 4) did not really provide a mechanism for creating and working with temporary files. Uploading a file through a form worked flawlessly, and I could manage files that already existed in the filesystem, but creating a new file and then saving it somewhere wasn't really possible. This really interfered with some cool CSS tricks I had planned, and I honestly haven't really figured out a workaround for it just yet.
Again, as someone who manages a server, I can very well see this being a security issue. While I empathize, I also wish there was some way to provide this functionality. If PHP 5 was available, I believe I could have gotten by with some of the newer FTP functionality.
Anyways, if I can get it together to gather the FTP workarounds I came up with into a file that can be included, I may post it here later. Maybe it will be useful to someone?
jacob | 01 December, 2008 21:33
I haven't posted in quite a while; I've been working on a side project for a couple friends that will manage their new web comic. Feel free to check out the Val'Cielle web comic for yourself.
As with any project like this, I learned some valuable lessons about PHP and techniques for getting things accomplished. I'll be posting these to try to get back into my regular schedule, and hopefully put out some tricks you can use yourself.
jacob | 10 August, 2008 11:38
One of my neighbors waved hello, and we struck up a conversation. Not an out-of-the-ordinary occurance, but soon the topic swerved to something strange.
"Oh, by the way," she started, "my kids mentioned that they saw a lot of bees around your house when they were getting into their car."
I was rather intrigued - I hadn't seen any bees around, and I tend to notice them pretty quickly. Bees aren't my favorite creature, and I get pretty nervous around them. I asked her if she could point to where they were, and she led me to one of my basement windows. Then she dropped the bomb; "Yeah, they said they've never seen so many bees."
This was not what I wanted to hear, especially not associated with my house. Upon closer investigation, there was a small hole in my foundation, right where the stone met the wood of the house, and every second or so a bee or two would fly in and out. They weren't wasps, and they weren't the angry yellow jackets I'd encountered in the past. They were little brownish bees, that didn't seem to mind that I was standing a couple feet away from them. They looked almost like honey bees... but what did I know?
Not a week later, my apiary ambassador blogged about how she had just gotten a call from someone who had a load of bees in a hollowed-out tree near them. She and a couple others had gone and hauled it off to her house. Since I've heard about how the bee population is on the decline, and gassing the little guys seemed a bit harsh because they had done so little to me, I sent her a message asking if she knew of anyone in my area that did a similar deed.
She responded back with a list of names, and I gave the closest guy - Dan - a call. We discussed the details of what I had, and he concluded that I had a decent-sized hive of honey bees living in my walls. He also let me know that it was important that they pulled out the honeycombs with the hive, because if you killed the bees you'd still have a bunch of dead bees and honey rotting and fermenting in the walls. Not a good idea. He said he'd have to cut open the wall, and that he could be there the next day. He also mentioned that if he said to 'get out' while they were doing their thing, that I shouldn't ask questions. Like he'd have to tell me twice.
That morning, Dan pulled up in a pickup with another beekeeper in the passenger seat. They took a look at the bees coming in and out, and started drilling holes in the siding to see if they could locate the hive. Luckily, the bees had kept pretty close to a single area, so it wasn't too hard. They put on some gear, and started cutting.

Immediately there was a cloud of bees surrounding the guy with the saw, and immediately I was twenty feet away. Like I said, not overly fond of bees, and there were quite a few of them. The picture doesn't really show how many bees were flying around at one time. He started by removing the siding, then a chunk of the exterior wall, and then he started pulling out honeycombs.

Dan brought me over one to show me what they were pulling out. He actually gave me one to keep for myself, so I could get some honey out of this whole operation. This one in particular he rubber-banded into one of his frames for the bees to use. Dan's plan was to set most of the honeycomb into a frame, and let my bees make him some honey over where he lives.

After they pulled out all of the honeycombs, they brought out their - I kid you not - bee vaccum. They sucked up a bunch of them lining the cavity where the hive was, and left it to suck up most of the rest of them while they had a glass of water. Did I mention that this all happened in ninety degree heat?

After they were done vaccuming up most of the bees, they took off the black exterior of their vaccum and revealed a little cage on the inside, filled with bees. "How many do you think are in there?" I asked Dan. "Oh, I dunno, looks to be about ten thousand," he replied cooly.
Holy shiiiit. I had ten thousand honeybees in a two by one foot chunk of my wall, and I didn't notice at all.
With that, they drove off to Sandy's Clam Bar with ten thousand bees in the back of their pickup. I was left with a hole in my wall, and a honeycomb full of honey. Not too bad for a Saturday afternoon.

jacob | 09 August, 2008 13:31
I browse with an Firefox extension called NoScript, because it's one of the only ways to secure yourself against most of the nasty things that lurk on the internet. Right now, it's almost a silver bullet for web security: it is rather hard to automatically compromise someone's PC without javascript. If you're at all concerned about identity theft or keeping your computer clean, then this extension is for you.
Lately, I've seen a rash of pages that react very strangely in my browser, simply because I have Javascript disabled. Half the styles will dissappear or not be applied at all, the layout will be severely altered, links and navigation are completely broken, etc.
Take FedEx.com for example. With Javascript enabled, you get a reasonably standard web site layout. The navigation, which uses simple drop-down menus, is positioned at the top.

However, when you disable javascript, the menus end up reverting to their obvious unordered list heritage, and overlap themselves quite a bit. Still "useable", but it also pushes the rest of the site off of the first page. You have to scroll down before you can see the rest.
If these items required javascript, then that would be one thing. I can quite understand when an application like Google Maps doesn't work without Javascript or Flash. If possible, I think it's reasonable to degrade gracefully, but that's a topic for another time. Simple drop-down menus do not require javascript and shouldn't use them. It complicates the code behind the page, and slows down the functionality for the client - Javascript is several orders of magnitude slower than CSS.
Xanga is also guilty of this abuse of Javascript. The login box on their main page, a simple HTML form, now requires javascript to submit. A simple HTML submit button can serve the same purpose, yet they feel my browser should have to interpret their client-side scripts every time I log in. I cannot express how irritating this is, and it may cause me to stop using their service.
Please, folks, let's code responsibly. Don't require Javascript to use your page unless it's absolutely necessary. Due to it's malicious possibilities, more and more people will be turning it off in the future. Build your sites so that Javascript isn't a required component, and everyone wins.
All content, graphics and, design © 2005 - 2008 Fragmented Development. All rights reserved, may contain peanuts. Powered by LifeType.