Geek Life....
photography, programming, site design, networking, computers, linux, windows, mac os x, application reviews...
Nov
19
Quickpost – Easy browser/version/platform specific CSS targeting via jQuery
cross browser, css, css level, css reset, jquery, programming
For the last year or so, I’ve solved browser specific CSS issues using a lightweight jQuery plug-in by Jon Hobbs-Smith named BrowserDetect.js. This solution allows us to target specific browsers, and browser versions via CSS selectors injected into the Body class.
Lately though, I’ve noticed a few bugs creeping into some of my work where a specific browser version gives slightly differing results across the three main platforms, Mac, Win, Linux. So I spent some time both refining browserDetect.js and have added functionality that allows me to target the platform as well.
As it sits right now, you can target a fairly granular range of variables compared to the original:
- a specific browser
- a specific browser version
- a specific browser running on a specific platform
- a specific browser version running on a specific platform
- a specific platform
And here’s what the body tag CSS selectors looks like in Firefox 8 on my Mac:
<body class="Firefox Firefox8 FirefoxMac Firefox8Mac Mac">
Download the code: css-level.js
Apr
04
During two of my recent projects I’ve had to generate on-the-fly PDF’s. In the past I’ve used a few HTML->PDF tools and found that support for modern HTML is rather limited.
This newer tool is Linux based but can be used via the PHP Exec functionality to achieve full integration. The best part of it is that it is WEBKIT based, and almost every page I’ve thrown at it seems to have rendered perfectly in the PDF page :)
wkhtmltopdf.
From the site:
Simple shell utility to convert html to pdf using the webkit rendering engine, and qt.
Apr
04
This saved me hours of re-writing aged code on a few of our sites during the migration :)
PHP4 domxml to PHP5
Quote from the source:
When moving from PHP4 to PHP5, some modifications are required in the scripts.
In PHP4, the experimental domxml extension was used to manage XML, but this has been replaced by the dom extension in PHP5.Migration from PHP4 to PHP5 is easy, but might be long if domxml was broadly used. Moreover, in order to have a smooth transition, it is good for scripts to be compatible with PHP5 as soon as possible, even if the server is still running PHP4. The optimisation for PHP5 can be done later.
Apr
04
I recently just completed the migration of our hosting infrastructure to the cloud. This project was a roller-coaster with typical hurdles as is found in the wild. I decided to write about this project but with only basic details instead of the step-by-step of how and when to do things. I simply don’t have time for such an endeavor.
The original fiber-fed network had four linux based servers. Two dedicated name servers and two web servers. Problems with network design/implementation, and poorly configured servers led to the need to move to the cloud or rebuild everything from scratch. We decided on a VPS hosted at 151Front.
The web servers were VHCS2 based. This is an older web-hosting control panel which, in its day was quite capable. Today though, it is a widely exploitable invitation to lose one’s business. The VHCS project ended ages ago and no security patches have been issued in months. To add to this, the boxes were not hardened in the least, even SSH allowed root to log on remotely!!! (argh!)
My first objective during my first month or two was to stabilize the web servers. Configured logging for apache/mysql/and various services, log rotation, ntpd, set up a proper back up script etc etc. Basically extended the robustness of what we had long enough to make things a little easier till we migrate.
The target VPS is WHM-cPanel based. There are no automated tools for migrating from VHCS, so everything needed to be done by hand. This is where a good solid understanding of Linux and operating systems in general really helped.
My first milestone was an easy but extensive one. I gathered all configuration details such as httpd configs, dns zones, mailboxes, aliases, filters etc, etc. Once collected from the four servers, I was able to correlate data in Excel in order to get the big picture of the hosting environment (and the mess!). This allowed me to gain insight as to just how large this project would end up being. It also allowed me to provide a list to management in order for them to define what hosting was actually still relevant and what had expired long ago… seems that the previous admin never found the Delete key.
Once I had proper documentation of what we have currently, without all of the expired accounts etc, I considered this my second milestone being reached. This allowed me to start setting up the accounts on the new server. Once the accounts were set up, it was time to get really dirty and start writing code to create mailboxes, filters, dns zones etc etc etc. This was a long haul but completed with relative ease. The hardest part was keeping track of everything.
With the VPS now configured to support what we have, it was time to actually move data into place. We chose not to migrate email to the new box, as most users were originally set up with POP3 access and of course, no one ever turned off Outlook’s “leave a copy on the server forever!” checkbox. I still had to pull over all of the web sites, FTP data etc etc. Easy peasy, this milestone was a no-brainer!
Perhaps the hardest part of the migration project was testing. The server was operating properly, and the accounts were perfect. What wasn’t perfect (to say the least) was the web site coding. Many of the sites required fixes to operate under PHP5, this was pretty tough. On a good note though I did get them ALL working after lots of blood and sweat. There were two exceptions to this, it seems the person whom designed the network (and quit after I started asking why things were the way they were) decided that he would remove all newline characters from the two websites that he had built. The files were all tampered with the same day I got the root password to the server… really sank my heart when I found this. I was able to locate parts of the code in which the lack of newline chars and javascript/php comments broke the sites and brought the sites up in a functional but having partially broken layouts. This is the best I can do with these two sites until I get a chance to finish my current development projects and loop around to pick up the pieces.
Fun times. More on this stuff later (if I get a chance.) Sorry I left out the bulk of the details, I intended only to hint at what is all involved and perhaps map it all out in the future.
kc/
Apr
03
My old boss pointed out to me a long time ago, that VI was something I should really get down and dirty with. I was an EMACS user at that time and I really had no interest in learning something new when I had lots of work piling up already.
That being said though, he added a very good point. VI is on all Linux distributions by default and being proficient with it means I can sit at pretty much any terminal and get the job done.
And so I learned VI.
Recently I’ve noticed a new fad evolving around the Interwebs. It would seem that pimping out VIM with plug-ins is the latest trend for aspiring developers whom believe the tools and add-ons they use make them more elite than those whom do not. But while some do argue what editor is best, I’m getting work done in trusty old VI. Could you imagine having to explain to a new boss or client that you can’t do work on their machines until you download and install a hoard of plug-ins? Could you imagine a junior employee fumbling with installing things on to a production machine?
There are many full-fledged IDE packages for your workstation available these days, which allow for live editing of files across ftp, ssh and the likes. This way you can have all of your toys installed there and not have to worry about tainting your clients servers :)
:wq
Dec
19
Just a bit distraught at the lack of talent I’m seeing these days. ‘Programmers’ seem to prefer using plug-ins to do what they need to do. When you recommend a REALLY good one to somebody the last thing you want back is a sarcastic response that highlights their lack of skills. Just because it might not simply plug-in to what you are using doesn’t mean it’s useless, and spending 5 minutes looking for a way to make it work would REALLY pay off for you.
They call us programmers for a reason, now live up to it! Sheesh.
Dec
19
Has your work been affected by the recent Wikileaks fallout?
API, development, paypal, programming, web design, wikileaks
Wikileaks stumbled on to the world stage earlier this year with the release of thousands of internal cables belonging to the US Government. Since then, the story has exploded full force into what could very well be mistaken for a new Tom Clancy novel.
Fallout from Julian Assange’s being taken into custody resulted in the Internet backlash, and highly organized Distributed Denial of Service attacks against corporate entities which chose not to support Wikileaks. As a result, Visa, Mastercard, and Paypal service were all affected.
Has your work been affected by this.
Last week we discovered a recent problem with a site I build by hand. It is a full online catalog with a UPS shipping system and Paypal checkout system. After receiving an email from a purchaser the vendor passed it to the development team to try to discover what happened.
As it turns out, the web server logs show that the two users whom were double billed were:
- on the site during the same day
- both had tried to check out three or four times
Now, being a bit experienced in transaction-based systems, I developed the back end to expire the page immediately and revert to the home page after a successful sale. This page records the successful paypal result, writes the invoice in both HTML and PDF versions, and notifies the client and vendor of the transaction so that goods may be shipped. This page was designed to ensure that it can only ever display once per successful transaction.
So what went wrong?
Well. Turns out that these transactions took place December 5th. On this day, Paypal was under considerable stress from the Wikileaks related DDOS attack and thus the site was painfully slow. There are two steps during the Paypal Express Checkout procedure which requires the user flipping between the vendor site and the Paypal API system. Two points of failure. My code was designed to kill a session should a user try to refresh a page in such a position as to resend the transaction requests. This should have killed any chance that a duplicate should ever take place right?
Wrong. The problem is that once I send confirmation to the PayPal API, they record the transaction on their side and they DO NOT confirm whether or not they were able to send back final confirmation to the vendor site. This means that although the transaction took place, the vendor site sat waiting for a response so it could generate the invoice and finalize the sale, a response that never came in a timely manner thus prompting the users to re-checkout after a few minutes.
Personally, I would have their API kill the transaction if their success code back to the vendor never reaches its destination… but that’s just me. There really is no way to fix this from our side, however I can add some bells that correlate calls to the API with return codes from the API so as to determine if they are ever odd.
Oct
17
Evil Google and Bad Programming.
apache, database, evil, exploit, Google, logs, passwords, PHP, programming, Security, vulnerability, web design
Okay so this post isn’t exactly about Google being Evil as much as it is about bad programming habits. This is about how a programming error led to Google automated systems being a little mischievous.
A couple of weeks ago I was asked to look into a problem where a site’s database would empty every so often. The products and news would have to be re-entered. This problem brought to light several items that I thought were noteworthy for a post.
Aug
08
CAPTCHA – Completely Automated Public Turing test to tell Computers and Humans Apart.
All current CAPTCHA implementations are doomed to fail due to the persistence of developers to place the onus on client side technologies for validation. Whether you show the answer to the challenge (albeit after making recognition difficult), or have users spin a photo until it is upright, you are still giving the end-point everything they need to pass the test.
It’s time to rethink CAPTCHA, and move the means of protection server side where it can not be manipulated.
Jun
13
Browser Compatibility has come a long way in the past couple of years. That being said, still we find web developers hacking site code to produce acceptably similar results across the playing field.
Recently, most browsers are starting to really kick into high gear with the all new HTML5 and CSS3 support. This is a good thing. What isn’t so cool though is that once again, Internet Explorer and Microsoft in general have thrown a monkey wrench into what should have been next years end to cross-browser compatibility woe’s.
