My Little Corner of the Net

Generate Accessors and Mutators Automatically with PDT

I’ve been using PDT, the PHP Development Tools IDE that’s built on top of Eclipse, for my PHP development for a few years now. I came to appreciate the power and flexibility of Eclipse as a Java IDE, so it only made sense to use PDT for my PHP coding.

One thing that’s always frustrated me about PDT, however, is that there is no way to auto-generate accessors and mutators (also called getters and setters) in classes. I do a lot of Active Record style database interactions, with classes that have lots of properties, and I always find it frustrating to write all of the get*() and set*() functions by hand.

I recently discovered the PHP Source Plugin for PDT, which does exactly what I want. With a simple menu click, I get a dialog box that lists all of my class’ properties. With a couple more clicks, I can specify wich of those properties should have accessors and/or mutators, and then the plugin g creates the code. All I have to do is go in and add validation code and PHPDOC comments, and I can move on to the next class. This is going to be a HUGE time saver.

PHP Source Plugin in published by E-surf. The fastest way to install it is to use their Eclipse update site, which is available at http://pdt.plugins.e-surf.pl/updates.

HTTP Post vs. HTTP Get

I am currently involved, for the second time in the past few months, in interviewing for a new web programmer/analyst to join my team at work. Given that we are a web applications shop, several of our technical questions revolve around web protocols.

I’ve now spoken with, between the two positions, around a dozen applicants. One question that I always ask is “what is the difference between an HTTP Post and an HTTP Get and why would you use one verses the other?”

I’ve spoken with people who have anywhere from a few years experience in web technologies all the way up to senior-level folks who have been doing “web stuff” longer than me. Everyone gets the first part of the question correct, at least to some degree. Everyone knows that parameters are sent to the server in the URL string with “get” and that they aren’t with “post” (some people have described how the values are sent in the body of the request with post and some have used phrases like “some other way” to describe the process). Most people also mention that “gets” are cachable and “posts” are not and a few have commented on the fact that “gets” are length-limited and can only contain character data whereas “posts” can contain other types of data (via MIME-encoding) and do not have size limitations.

Not one applicant, however has answered the second part of the question–the “why.” So, as a public service to anyone who may get asked this question in an interview some day (or anyone who wants to make himself a better web developer in the job he already does) I am providing the answer I am seeking:

Get is used to retrieve information from the server, post is used to modify data on the server.

That’s really all there is to it: if you are adding, deleting, or modifying data, you should be using “post.” If you are retrieving existing data and not doing anything destructive to it, then you should use “get.”

If you really want to impress me, you’ll go a little more in-depth:

  • “Post” should be used for any requests that should only be submitted once. Since the data isn’t cached, the request should, theoretically, never be sent twice. This is important to protect against duplicate submisions and overwritten changes.
  • “Get” should be used on search forms.When searching for something, I want my back button to work so I can return to a previous location easily when my search doesn’t pan out as I’d expect.
  • “Post” should be used on data-entry forms. When I’m entering a new order, student record, or blog post, I want to be sure I don’t accidently submit a duplicate when I hit the back button.

Also, whatever you do, please do not say that “post” is more secure than “get” if you want me to take you serious. Neither method does any sort of encryption or even obfuscation on the data, so neither provides any level of security. If you want to make sure an onlooker can’t access the data as it moves over the wire, use HTTPS. If you want to make sure the user of your site can’t access the data, don’t put it on your site.

University Websites

Situational humor is funny because it is true. While it points out our flaws, the humor comes from the fact that there is often little, if anything we can do to change the situation. All we can do is laugh and move on.

In the IT world, one of the best sources for such humor is the web comic XKCD. It is brutally honest in the flaws of the industry, flaws that can only see change from the hand of slow-moving committees and out-of-touch upper management.

XKCD hit it out of the park again with their recent University Websites comic. Featuring a Venn diagram, the strip compares everything on the typical university homepage with everything that people want to see, with the only overlap being the full name of the university.

XKCD University Websites: Things on the front page of a university website vs. the things people go to the site looking for

As the webmaster of a university, this gave me a good laugh because it is true. Our site features a prominent Flash carousel highlighting news of campus events, alumni stories, and (months after hockey season ended) the fact that we made our debut in both the Division I NCAA tournament and the Frozen Four last season. Yet, if i want to find someone’s phone number I have to go to a URL I always get wrong (though I did add a redirect some time ago) and download a PDF.

The problem with universities, unlike businesses, is the fact that our sites have to serve many demographics. Businesses have a set of products or services they provide and their demographic is the consumers of those services. This is true in higher ed as well: we sell the service of educating people for well-paying jobs and as such it would seem our demographic would be students. But even among students we have very different needs: prospective students want to know about the courses they’ll take and how well the balance of fun versus boring-time-spent-in-class works in their favor, while current students want to know the date they can register for their next quarter classes and the location of a campus store selling ice cream at 11:00 at night.

It doesn’t end their, either. The university homepage needs to appeal to parents (who want to know how big of a second mortgage they’ll need to pay the tuition bills), alumni (who we want to give us money so that we can attract more students by decreasing the size of the aforementioned second mortgage), wealthy benefactors (who give us lots of money to really help decrease the size of the second mortgages in exchange for having their name plastered on the front of a building), and businesses (who will license our research to make exciting products and services that we can then brag about on our homepage, making us look good to those prospective students that are the consumers of our services.

Of course, the other issue is that everyone in the university community also wants their soapbox. Professors want to entice students to take their courses, clubs want students to partake in their activities, and researchers want the world to know how they are about to change everything. All of this does have a place as it all contributes to our mission of educating people to find well-paying jobs. Its just trying to manage it all that’s a problem.

Now if I could just figure out where I can get some ice cream later tonight.

Blogging from my phone

I’m testing out the WordPress app for Android devices, which I just installed on my phone. Maybe this will get me to blog more often…I doubt it…

Goodbye Telephone

I recently gave up my landline phone. Sort of. I wanted to upgrade my cell phone to a smartphone, and in order to offset the extra cost of the data plan, I was looking for other places to cut costs.

Since I’m often on the go, my home phone gets little use. I make most of my calls from my cell and most people who call me these days call my cell. Still, I like being able to give some callers—businesses and the like—a number at which they can’t interrupt me at any hour of the day, and I didn’t want to give that up. Paying Frontier, the local phone company, $40 a month for that privilege seemed a little excessive, however.

I’ve thought about switching to a VoIP, or voice over Internet protocol, phone provider for a while, but most of the VoIP providers I’ve seen sell themselves on the fact that long distance is included in the base price. As such, they claim that they’ll save you money (and for many people, they probably do), but since I rarely use my home phone for long distance calls, these plans would only save me a few dollars a month which, IMHO, wasn’t worth switching.

In my quest to find a truely inexpensive VoIP provider, I asked around. As the result of a post I made to the DSL Reportsforums, I was introduced to VOIPo, a texas-based VoIP provider. VOIPo was able to provide me with all of the features I was receiving from my local phone company, plus free long distance, and even 60 minutes of free international calling to select countries each month (not that I’ll likely use that very often) for just $8.25 on their current special (I signed up for a full year).

Not only is VOIPo inexpensive, their service is excellent. I sent them a couple of emails with questions about some unique service needs that I had, and I got answers within hours. One of the answers even came directly from the CEO. I also scoured the web for comments about VOIPo, good or bad, and I was impressed to see that the CEO personally followed up on all of the negative comments on DSL Reports trying to correct the problem situations.

VOIPo gives me a ton of features that I couldn’t get from the phone company, too: I have access to a log of all of my calls, I can program the caller ID that gets displayed when my phone rings for incoming numbers, and I can even set up multiple incoming numbers with distinctive rings and/or separate voicemail—and I can do it all right over the web. I can also get my voicemails sent to my email and can even run a soft phone on my computer or cell phone, so when I’m traveling I can still get and make calls from my home line.

As I said, I decided to sign up for a full year of VOIPo service from the start. They offer a 30 day money back guarantee, so I figured I’d try the service out with a temporary number and, if I wasn’t happy, I’d ask for a refund. While there is a little more line noise than there was on the old phone, the sound quality was still very good, so I decided to keep the service. VOIPo let me port my phone number away from the local phone company for free, and the whole switching process was pretty painless. I’ve been on VOIPo’s service for a few months now, and I couldn’t be happier.

If you feel like you’re throwing money away with your landline, but you aren’t quite ready to give it up, I encourage you to give VOIPo a try. I think you’ll be happy that you did.

<