Showing posts with label tech rants. Show all posts
Showing posts with label tech rants. Show all posts

14 November, 2007

All Your Data Are Belong To Us!

I just had a rather interesting article pointed out to me, on Computerworld UK. According to David Litchfield, a UK based security researcher,
"There are approximately 368,000 Microsoft SQl Servers... and about 124,000 Oracle database servers directly accessible on the Internet,"
Given these numbers, I have to wonder what would be found if he were also to look for other widely used databases; MySQL, PostgreSQL, Firebird, etc. It's a bit of a frightening prospect to think that I probably have personal information stored on at least one, if not more, of those exposed servers. Things like this make me wonder how so many IT professionals keep their jobs when they really have no clue as to what is really going on. The most likely scenario is that these people are all book trained, they have their degrees and certificates and all that nonsense... then they get into a real world environment, thrown up against a huge ball of servers, and they have no idea what to do. Hearing about these things makes me very glad for the opportunities and experience that I have had. I learned better, LONG ago, than to make amateurish mistakes like this.

You can view the full text of the article here: http://www.computerworlduk.com/management/security/data-control/news/index.cfm?newsid=6198

17 August, 2007

Management frustration

Okay so it's been a while since I've posted on here. Today, however, I have to rant.

Now it's not that I have anything against Indians (dot, not feather -- thank you Simrin) but I have to say that I absolutely hate hate HATE the offshore IT industry! It all started with tech support. You call up some large computer company, only to find that you are not talking to a native English speaker... you are speaking with somebody who very likely learned English just for this job, and has a vocabulary limited to the subject matter at hand. I'm not saying that I'm some linguistic genius. "I speak two languages: English, and bad English." But when I'm calling an American owned company, as a native English speaking American, I expect to speak to another native English speaking American so that we can both fully understand what the other is saying, without having to slow down our speech, repeat ourselves, and watch carefully not to use any colloquialisms which the other person wouldn't understand simply because of their cultural background.

So we started with the offshore tech support.... but wait, it gets better! Now we've moved to offshore programmers. Don't get me wrong, I'm sure this is an alright idea for some companies. They have no IT staff, they need something done and need it cheap. This solution will accomplish those goals. Now take an instance like the company I work for. We do have an IT staff ... well, if you count myself and a part-time sysadmin. Anyhow, we do have a staff. I do all of the programming, tech support, assist with sysadmin work (our sysadmin is an intern... so I'm tutoring him part of the time) and, well, whatever else needs to be done. However, we also have an offshore programmer working on one of our projects. He appears to be a very competent programmer from what I've seen, don't get me wrong. He's also fairly good with English. I don't believe we have had too much trouble with communication; a few small cases where the English language simply failed to explain itself. There are some major frustrations, however. There are days I really wish I had somebody sitting here in front of me, so that I could directly guide then on this project. I could also beat their head in, if necessary. In fact, I could throttle them, slap them around, throw things at them and tell them "NO NO NO STUPID! THIS is how it needs to be done! L-I-S-T-E-N to me.... do you understand the words that are coming out of my mouth!?" That's the joy of having somebody working directly beside you. Or at least, in the same general area.

See, what got me all riled up this morning is an email I got from this offshore programmer of ours. He's working on a project that's going to involve some audio and video processing. This is obviously not a simple process. In fact, in a previous post, I discussed just how easy this isn't. I also talked about how intensive a process it is on a system. So right now, this offshore developer is actually working on building this part of the system. This is a rather important part of the system... despite the fact that there will not be a heavy load imposed from video and audio processing; i.e., we aren't going to have people uploading constantly like YouTube. There will be at most 50 videos uploaded per day. Still, we have currently 3 web servers, and these servers are not very powerful machines. They deliver web pages; they don't need to be anything special. With this in mind, we definitely don't want to be doing the video processing on these servers. Our encoding time -> video time ratio would be through the roof. If somebody uploaded a 3 minute video, it could take upwards of 5 minutes to encode. This would tie up the web server for 5 minutes, starve it of RAM, kill its swap space, send the server into a processing frenzy. All the while, this server still needs to be able to deliver other web pages. Remember, only 3 web servers... and we're serving thousands upon thousands of web page requests per day... and with this new project, that number will potentially increase exponentially. This is simply NOT an acceptable situation. Keeping this in mind, I sent our developer some specifications saying that video and audio files are to be processed on a separate server. I won't go into exact details here... but I imagine it's actually an extremely scaled down version of how sites like YouTube actually work. Offload the work, keep the web servers freed up, continue serving web pages effortlessly, and get the media processed on a nice beefy server. Sounds great, right? Well apparently our developer and his "technical team" do not agree on this. I got an email this morning which said the following:
50 / day is not a big number to think of a separate server. So we can do this on the Web Server itself, instead of a new one.
Wait wait wait..... what? Did you not listen to what I was saying? (See my previous examples of screaming in this post to see how I would have liked to react to this ridiculous statement.)

Well, needless to say, my Friday morning buzz of happiness is now 6 feet under. In fact, more like 10 feet under. That sent me into a bit of a rage... and I still have to reply to this email.... the worst part is, I have to be polite! This is also taking me COMPLETELY off track from the project I've been working on, which is a very very bad thing.

So not happy right now.

Oh and to those who were wondering, yes I'm still alive. I just keep forgetting to post here. Thanks for the reminder!

09 January, 2007

Strength of Character(s)

When did it come to be that you need a degree in cryptography and computer science in order to build a simple form on a webpage?

I'm running into some issues lately upgrading our web software so that it can be used on international sites, and hence with international languages and character sets. It sounds easy enough, really. Translate the sites and they should be good, right? Well, not quite. As it turns out, there are some major conflicts with the character sets that get thrown around on the web. By default, things use the "latin-1" or "ISO-8859-1" character encoding. It uses one byte per character, giving you a possibility of 256 different characters. This is all well and good, for languages based on latin characters. This isn't so good, however, when you get into other language with special characters... like, say, accented characters.

"But wait!" you might say, "Spanish uses accented characters!" Yes, that is correct. That's actually what got me started on this whole train of research today. A Spanish speaking user input an accented character on a form, which apparently we weren't set up to expect, it got put into an XML document as an "unknown character", the XML ended up failing validation because of this one little accent and things blew up.

So I start reading a bit. I know that there are a number of different character sets that can be used... and I know that "UTF-8" is the one that should be used for things of this nature... it uses multiple bytes per character, allowing for a much wider range of characters to be displayed. Perfect. Surely PHP will support this natively, right? PHP is matured enough that strings should just automagically be UTF-8 and it should just work. Right? Wrong. To quote PHP's strings page:

In PHP, a character is the same as a byte, that is, there are exactly 256 different characters possible. This also implies that PHP has no native support of Unicode. See utf8_encode() and utf8_decode() for some Unicode support.

Lovely. Apparently this isn't so easy. Now I'm stuck reading an entire treatise on character sets in web forms. What the hell? What makes this all so ridiculously difficult? It's obviously something that every web developer is going to have to deal with. My not just make it WORK, out of the box, no effort? What is so bloody difficult about that? Well apparently this document I've found is the one that should help me figure all of it out, from what I've been reading. Then I'll need to read up on the UTF-8 support in PHP, as well as their multibyte string functions... at least I think I'll need those.

This is just stupid.

03 November, 2006

Pure, raw stupidity.

You know how it's called a "flash flood" when there's a sudden downpour and areas become flooded nearly instantly? Well, I've just gotten what I like to call a "flash migraine". Except, these aren't caused by sudden downpours of rain. They're caused by sudden downpours of stupid.

I just ran into one of the most ridiculous bugs I've seen since I started at this job. On the locator website for one of our clients, I could add a space (yes, " ") to the end of a zip code in which I wanted to find a location.... and somehow, this managed to make all locations display as being over 5,000 miles away. Even ones that were.. oh, say, 18 miles away.

How do you not notice things like this in development? How do you not CHECK for things like this in testing? Hell... how do you manage to maintain a job in the IT industry, making totally stupid mistakes like this, on major corporate websites!?

I just don't get it .... but I praise the inventor of Excederin migraine.

12 July, 2006

SSL woes

For those of you non technical types, feel free to tune out now. I won't be offended. Honest. This is going to be quite a rant.

So I've got this job, right. And at this job, we do a lot of website hosting, some of these on "secure" (https) servers. For these servers and their hosted pages to work properly, I need an SSL certificate. Easy enough, right? Haha, I wish.

A couple weeks ago, it comes time that we need to order a new SSL certificate, for a new secure website. We go to Thawte, where we've ordered all of our certificates from before, place an order for a new one, and give them all the information they need. After numerous correspondences and far too much time wasted, it becomes glaringly obvious that we're not going to get a certificate from Thawte anytime soon. Alright, screw them, we'll go with the new trusted name on the internet, GoDaddy. They know what they're doing.

Don't they?

We place the order with GoDaddy and receive our new certificate almost immediately. Wonderful! I'm liking this already. Follow their instructions to install the certificate, all goes smoothly... but just to be safe, before I restart the web server, I run a "configtest", to make sure it likes it.
$ sudo apache-sslctl configtest
Syntax error on line 1213 of /etc/apache-ssl/httpd.conf:
Invalid command 'SSLCertificateChainFile', perhaps mis-spelled or defined by a module not included in the server configuration
Wonderful. Doesn't work. Hmm well, what if I just comment that line out? Can't hurt too much, right? So I comment the line out.... run a configtest... it's okay! Groovy! Restart apache, and we're up and running! So I open up Firefox, go to the website, it's secured... no problems! Oh wait, just to be safe, I better check it in IE also. Open up IE... bring up the site... what? Can't verify the certificate? What the hell is this? Oh crap. That line that didn't work. GoDaddy provides an "intermediate" certificate for ... whatever stupid reason. That's great. Well, we can't have IE users always getting an error. This just will not do.

Time to call up GoDaddy support, see if they can help out. I talk to the general tech support girl .... she has no idea what I'm talking about, says she has to pass me on to SSL support. Alright, cool. They've got good hold music anyways. A whole bunch of swing/ska music.... I could stay on hold here all day! (And I nearly do....) Several songs and a good while later, I'm talking to an SSL support guy. I describe the problem to him... he thinks for a minute... asks a few basic questions.... and then decides that I need to re-generate the key.

Woah. Hold on. What?

I tell him the problem again. Still he insists that I should regenerate the key. Okay, I'll try a different approach. I ask him if GoDaddy can possibly create a key WITHOUT the intermediate key. Apparently this thought is blasphemous in his world, and quite an impossible feat. Lovely. I ask for his recommendation on the stipulation that our web server, for some reason, doesn't support using an intermediate key. "Uh.. well.. you should regenerate .... " oh wow, I can see this is getting nowhere fast. Okay okay, another approach.. quick. I ask him if he thinks I might need to upgrade OpenSSL. We've got a 0.9.7 version... that sounds relatively up to date, but I'm not sure how recent. Maybe this is just something not supported there. At which point he lays this whopper on me: Apparently, the GoDaddy servers, are running OpenSSL 1.3. Ahem. coughcough.
The current version is available from http://www.openssl.org. OpenSSL 0.9.8b was released on May 4th, 2006.
Well hello Mr. Future Man! What's it like to be in the year 2025? I'm done with this fool. GoDaddy's support is USELESS. I guess I'll have to do some more creative Googling. Eventually, I come across this site. Exactly what I've been needing from the beginning. This confirms my suspicions that GoDaddy's documentation and tech support is lacking. We're using another (apparently widely used) ssl package. And what it all comes down to is changing the directive for that line. So instead of having "SSLCertificateChainFile", I use "SSLCACertificateFile" .... and then it works perfectly! Shiny!

*sigh* The trials of working in an undocumented environment.

13 June, 2006

Databases.... grr.

Well, it's been a while since I've posted up another blog here. I've been bad, I know. In my defense, however, I've been very busy. Right now though, I'm sitting .... waiting .... watching my machine grind .... because of a stupid, slow, database.

Now, I can respect the fact that restoring 750mb of data into a database might take a little bit of time. That's a lot of data. What I really don't get is how it would take well over 2 hours. That is so not cool. This is one of the many, many, MANY reasons ... I no longer use MySQL. Granted, this is an ancient version of MySQL. 3.23 has been long since antiquated, deprecated and dropped like the bad habit it is. But at the same time that this was out, PostgreSQL had a far superior product which would have taken nowhere NEAR as long to accomplish this same task. Since then, PostgreSQL too, has come out with newer, better versions. In my opinion, it still stomps the living crap out of MySQL, in any application, in any environment.

Then again, maybe this ridiculous amount of time has to do with the fact that I only have 256mb of RAM allocated to that virtual machine. Hmm. I need to get more memory in this system.

17 May, 2006

Buzzword Bingo

Alright, so yes... I've been in the market for a new job. Looking, searching, hunting. I need a change. I need a challenge. I need .... fair compensation.

But I've come to realize that I really dislike most employers. Maybe it's just their HR departments. Maybe it's the heads of IT who just know "What's Hot" in the industry... who knows. But they all love their buzzwords. Me? I hate 'em. I keep seeing more of them all the time. And, sadly enough, I keep on adding them to my resume.

Some of these buzzwords I see are based around things I've been doing for a long time, just never really bothered naming it. One of the (relatively) new crazes is LAMP and WAMP development. Double eww tee eff is that? Turns out, it's exactly what I've done for ..... uhh... 6 years? Well, sorta. LAMP generally stands for "Linux, Apache, MySQL, PHP".. substitute in Windows and you've got WAMP. Hey, come to think of it, you could also have WIMP (Windows, IIS, MySQL, PHP).. heh, appropriate. Anyhow, back on topic, LAMP is something I'm very familiar with... but it's never been on my resume, and still will never be. That's way too buzzword for me. Anyways, I graduated from MySQL years ago.. been using PostgreSQL for several years. LAPP doesn't have quite the same ring to it though.

So I'm finding all these job postings that require me to know all of these buzzwords... and some of them are just ridiculously stupid. Okay so example, I see a job requiring experience with , XML, and XPath. Okay well I've got XML experience ... great! But hell, I've never used XPath ... have I? So I grab an XML reference from the bookshelf, read for 15 minutes ... okay, I now know XPath! How silly is that? If it's something I can pick up in a matter of 15 minutes, why BOTHER having it on my resume? Because I've seen it on so many different job requirement lists is why. I don't get it. I really don't.

I just wish the era of the buzzword would DIE.

Oh and don't forget "Web 2.0". Grr. Hiss. Spit.