9 October 2014

Understanding Dynamic Webpage Updates

There’s a lot of ways to make your webpage update without requiring the user to refresh the page.  The way Facebook updates your news feed while you’re looking at it.  Or Google+, or Twitter, or whatever.

I’m going to talk about just three ways: Polling (with Ajax), Web Sockets, and Comet (or “long polling”).  There’s a ton of different variations of ways to may pages update dynamically.  I’m not going to talk about Flash, or Java, or other icky things (I’m looking at you, Silverlight).

Polling (via Ajax)

Polling the server, using Ajax, was the first way used to make pages interactive.  Your browser would use Javascript to periodically ask the server if anything has happened.  Maybe once every few minutes, or sometimes up to every second (or as quickly as it could, in some cases).

Ajax is a combination of a few technologies, and can be a bit confusing to talk about… so let’s distill it down.  Basically, your browser asks the server, “hey, did (X) change?” to which the server would mostly respond, “no.”  When there’s a change, some part of the displayed page would get that updated bit of information.  Pretty over-simplified, but that’s the gist of it.

The problem is that the server is getting asked a lot of questions.  It’s like reloading the webpage constantly to see if there’s a change: given enough people, that puts a heavy burden on the server.   To fix this, Comet and Web Sockets were created.

Web Sockets

The concept of web sockets is, in its simplest form, that the server will respond when something has changed.  Instead of asking every second for 30 seconds to get a single response (asking 30 times if something has changed), web sockets kinda says, “hey, just let me know when something changes.”  The server only sends back when something actually has changed: in our scenario, that means we’ve eliminated 29 questions.

Unfortunately, Web Sockets is a feature that isn’t 100% supported. Well, it is mostly supported in the newest browsers, but not necessarily completely.  Not in all of them.  And older browsers?  Yeah, they’re screwed.

Comet

So polling is cool, but it’s fairly taxing on the server.  Web Sockets is a cool idea, but isn’t completely supported.  In comes Comet to create that middle ground.

Essentially, comet is just like polling, but with a twist: instead of returning a response immediately, as with polling via Ajax, the server would hold on to the request, and only respond after a certain amount of time or after something changed.  Basically the same as Web Sockets, except… well, different.

The great thing about comet is that pretty much all modern browsers support it.  In fact, even most of the older browsers support it!

Category: Code, Software Development | Comments Off on Understanding Dynamic Webpage Updates
4 March 2014

Why MS Access Application Developers Should Be Ashamed

If you have written what you consider to be an application in Microsoft Access, you should be ashamed of yourself.  MS Access is not a developer-friendly environment.  Not even a little bit.

You might think, “oh, but I’m just making this simple little application, and it’s not going to be used for very long.”  Wrong.  The company you made it for is going to use it until the amount of money they’re spending on maintenance vastly overshadows the amount it would cost to create a real application to replace it.

“No, that’s silly,” you might think, “I told them this thing won’t scale.”

Well, kudos to you for realizing that MS Access is a pile of crap, and for realizing it doesn’t scale.  But the company isn’t going to do anything about it.  Because if it ain’t broke in a way that costs a lot of money, don’t fix it.

“I told them I’ll rewrite it as soon as I have time.”

You’re never going to have time.  Once this thing gets put to use, you’re going to spend all your time fixing it.

Eventually, you’ll leave the company, probably because the pain of maintaining that application was too stressful.  That’s where I come in.  And I hate you for doing this to me.

That’s right, I’m the guy that gets hired to maintain the pile of shit you left behind.  And guess what?  The company has no money to spend on creating a real application, because they’ve spent all of it maintaining that thing.

Without further ado, here’s a few of the many, many, many reasons why MS Access isn’t developer-friendly:

  1.  Source code can’t be maintained.  Go ahead, tell me there is–and prove to me that you’ve used them successfully.
  2. Debugging is a joke.  If the application gets closed, all those breakpoints are gone, and trying to step through it is like scalping yourself and then replacing your own hair with individual strands of silk from a black widow spider.
  3. Changing the code will RESET THE PROJECT.  So those breakpoints you spent an hour setting are ALL GONE.
  4. Only one developer can work on it at a time (see #1).  If more attempt to, the result will be that somebody’s change will get overwritten.  But neither will know who did it, what’s missing, or why.
  5. The source code is obscure, difficult to access, and can be password-protected.  Because that’s a good idea.
  6. You have to know the application’s “secrets” to develop on it (like holding <shift> while opening the file)
  7. Pretty much any programming language that still uses “GoTo” should not be used anymore.

If you’re thinking about writing an application in MS Access: DON’T.

Category: Code, Rant, Software Development | Comments Off on Why MS Access Application Developers Should Be Ashamed
24 February 2014

Nginx and PHP as Different Users (Pooling)

So, after having installed a few WordPress sites on my server (namely this one), I ran into some permissions errors.  I couldn’t get plugins nor any updates to install.

The problem first appeared simply as a prompt to enter FTP credentials.  That was bizarre, so I hunted to find why that was.  I realized it was a permissions issue by reading this page (among others).

I scoured the Internet for answers (in other words, I tried a lot of different search terms in Google) for a way to make Nginx, the webserver software I used, to run as the proper user.  I’d setup different users for different websites, so just changing the webserver’s default user/group wasn’t the answer.

My first solution, albeit an ugly one, was to give everybody read+write+execute permissions on my WP folders.  That was an ugly kludge, but it worked.  And so it sat for some time.

Then I finally found how.  Through some bit of serendipity, I found an article on Apache and suExec.  I changed the term to Nginx with suExec, and found the answer… sort of.

Nginx, PHP-FPM, and Pooling

So the key was the “pooling” part of PHP-FPM that I’d basically ignored.  I had read the configuration file, but didn’t really understand it.

But after reading this article about pooling with Nginx and PHP-FPM, I found the answer.

So PHP-FPM can be configured to run different pools.  Basically, that means that there are multiple main processes for PHP, and they can run as different users.

Easy.  Added a new pool, changed it’s name and the user, and the new process (well, processes) appeared, with the correct user.  But how could I attach that to my website, so it ran as the correct user (instead of www-data)?

It’s All In The Socket

The bit of magic that makes Nginx hand off the PHP work to the correct pool is the socket.  The new pool needed to have a unique socket, then the affected websites needed to be reconfigured to use the socket corresponding to the appropriate pool.

I went back and changed my new pool to have a unique socket name, then restarted the php5-fpm process.  I then went and changed my website’s configuration file to use the corresponding socket.

Before restarting Nginx, I changed the permissions on my website’s folder to no longer be world readable/writable.  Then I attempted to delete an old plugin: as expected, I got a permissions error.  Restarted Nginx, then tried again, and it worked.   Woot!

Category: Nginx, PHP | Comments Off on Nginx and PHP as Different Users (Pooling)
19 February 2014

Why Coding and Smalltalk Don’t Work

So, when I’m working on code, and somebody starts trying to talk to me, I sometimes get funny looks from them when I can’t respond right away.  Or because they have to wait a significant amount of time before I let them talk.  Or because I get frustrated right away when they just start talking anyway.

I’m not intentionally being an asshole.  But I do get frustrated by it.  Switching to and from programming/coding isn’t like switching to/from a book or an article or whatever.  It’s way way more involved.

There’s a fair amount of time required to get (back to) programming.  Like one of those choose-your-adventure novels, only… more.

If you chose “I’ll go with the stranger” on page 2, but didn’t take the candy in chapter 12, and you’ve got a machete (from pages 12, 13, 405, 7004, or 7005), go to page 803..  If you chose “I’ll go with the stranger” on page 2, didn’t take the candy in chapter 12, and you’ve got a machete from pages Honey? 85, 99, or 9008, go to page 405.  If you chose “I’ll go with the stranger” on so I was at the store today page 2, didn’t take the candy in chapter 12, and you’ve got a machete from a page that is NOT 12, 13, 85, 99, 405, 7004, 7005, nor 9008, go to page 777.  If you chose “I’ll go with and I saw Jerry the stranger” on page 2, didn’t take the candy in chapter 12, and you don’t have a machete at all…

So now the stranger’s name is Jerry.  And I got the machete from a store… wait, there’s no chapter called “store” in here… SHIT.

Category: Code, Rant, Software Development | Comments Off on Why Coding and Smalltalk Don’t Work
17 February 2014

Nerd Rage on MySQL and Postgres

MySQL vexes me SOOOOO MUCH.  Why not just use PostgreSQL?

I know, I know, you’re thinking, “I have no idea what you’re talking about.  I don’t even know how to pronounce those two things.”

So, MySQL can just be pronounced “my squeal,” and PostgreSQL can simply be pronounced “post gres.”  There, one part down.

Choosing a database is a developer thing, I guess.  But… WHY?  Here comes the classic car analogy.

On the left, we’ve got the MySQL coupe.

It’s kinda plain looking.  It has a history of doing unexpected things, like not stopping when you press the brakes, and continuing to accelerate when you release the gas.  It looks like any normal car, but there are some rather devious things under the hood, and is definitely not “standards compliant.”

On the right, we’ve got the PostgreSQL coupe.

It looks sleeker, more like a sports car than a run-of-the-mill coupe.  Even though it costs the same as the MySQL coupe.  It does everything you expect it to.  Everything about it is standards-compliant.

So, why choose MySQL at all?  Doing so has zero benefit.  Choosing PostgreSQL means it’s actually pretty easy to convert to MySQL later (right… “hey, I’m trading in my Lamborghini Diablo for a No-Name Turdmobile).

If you’re a developer, and you’re working with a database, just use PostgreSQL.  It will save you time in the end.  SERIOUSLY.

Category: Rant, Software Development, System Administration | Comments Off on Nerd Rage on MySQL and Postgres