One giant leap
A couple of posts ago, I introduced a programming tool that I'd thought up and started working on. The point of this tool was to help bridge a gap between familiar and the seemingly impossible.
So many times as I'm working on web applications, I end up thinking to myself "there's got to be an easier way". I've only been seriously programming for about 10 years now and my first introduction language to programming was Perl. For those that know and work with Perl, you know that "there's got to be an easier way" is a recurring theme. Perl is a very powerful language that has a lot of flexibility, but for my uses and the types of things I've found myself building, it was almost always too much. I don't need a programming language that can do everything because I don't do everything. One of the common things known about Perl is that there are many different ways to do the same thing, and it's not difficult at all to have 10 different methods for doing something that are completely cryptic to anyone other than the developer that wrote it. This is a great idea. It gives freedom of coding style, freedom of choice and flexibility in how something works. The problem is that for the majority of the time, it's simply too much for me to handle.
For the past couple of years, I've passively watched the growth of PHP as a programming language and would constantly find myself criticizing it for it's lack of flexibility or being "too easy". I've seen demos and examples of platforms like Ruby on Rails where you can create an entire blog in 5 lines of code. I like to maintain a lot of programming control in applications I write, and that's doing way too much for me (something about most of my code being put in place to reverse something that it did automatically for me just doesn't seem right). I knew Perl was making me work harder than I wanted to but I didn't know of a different language that I felt would strike the right balance for me in terms of programming control and ease of use.
About 2-1/2 years ago, I was working on a side project that involved integration with Wordpress (and then later, phpBB) which was sort of forcing me into a position of needing to know a little bit about PHP. The end goal of what I was trying to do involved tracking a user's session (in the case of phpBB, actually using phpBB's session) through a site that included iframes so the system needed to either be able to save the cookie, or, if the browser rights were too strict, at least be able to pass the session ID along with every link so every other page would still have session data. It was when I discovered PHP's use_trans_sid setting that I was hooked. With that feature enabled, PHP would automatically buffer anything I was echoing and would go back in and add the session data to the end of any link I was echoing and it would automatically add a hidden form element containing the session information to any form I was echoing so that forms could also continue the same session. This feature got really close to the "doing too much" line, but it ended up saving me a lot of time and the end result was exactly what I'd hoped for (and it did it automatically!).
There have been countless numbers of examples of the same type of situation over the last 24 months or so. number_format(), trim(), setcookie() and array_unique(), just to name a few.
So, with my new excitement about PHP only a few months old, I was sitting in the lobby of the Embassy Suites in Chicago last year on the final day of the RETS conference killing time before my 6pm train while still digesting everything that'd happened the last few days. I'd seen some demos of some nice applications and other tools, but most of them were for Windows or needed to be run as complete programs rather than smaller tools that a developer could use. I wasn't unfamiliar with working with RETS at that point because I'd written a few different internal clients in Perl, but I still couldn't say that I had a good grasp on the big picture yet. I ended up taking out a pad and pen and made a full page of notes. I was determined to find an easier way that would both make sense to me and make sense to someone else that had very little experience with RETS.
That piece of paper is what eventually became the list of goals and general structure layout of PHRETS, a free, open source PHP library for working with RETS. In working with Perl, I knew that there were a ton of Perl modules that could be used to introduce functionality to a program but I had no idea how to write one. I knew that other functions or classes could be written which would do similar things but I'd never needed to write them so I didn't know how those would be structured or designed. I knew that in order for PHRETS to be easy for someone to use, it needed to be fairly easy for me to make. I knew that if I tried to get too tricky with it, it would be too tricky for someone else to understand. I knew that if average Joe Programmer me could use it, any average Joe Programmer could.
A few weeks, I posted the latest version of PHRETS which included the last major part of RETS I'd originally set out to support (GetObject). Personally, this was a pretty big accomplishment because I finally felt like the code could be used by someone to do something useful. The code works, it manages a session successfully, it retrieves and processes metadata (data formats) correctly, it can do queries and retrieve back any type of record from a RETS 1.x server, and it can query for and retrieve back photos. It assumes as little as possible to remain as flexible as possible.
I think I've created an easier way and I encourage you, if you're even somewhat familiar with PHP, to give it a spin. It'll only take a few minutes to know if it'll be successful or not, and I think you'll find an incredible amount of flexibility using the features it has. For example, for retrieving photos, it assume nothing. You tell it what to get from the server, it gets it and returns the actual image data back to you to do whatever you want with it. If you want to put the image data into a file on your system, go ahead (you're a quick file_put_contents() away) and use whatever filenaming scheme you can dream up. If you want to send the image data to Amazon S3 for storage and serving, you can do that, too.
Development on PHRETS isn't done as things are constantly changing and improving. Additional support for versions other than RETS 1.5 are needed and the first steps towards those has already started. Additional error checking and error reporting is needed so those are being added as well. If there are features or items that you see that you'd like to suggest, please let me know. All of the information about PHRETS as available at the project site, located at http://troda.com/projects/phrets .
Look for some additional PHRETS related posts coming over the next few weeks. I'm scheduled to be part of a presentation during this year's RETS Conference in about a week where tools such as PHRETS will be showcased.
So many times as I'm working on web applications, I end up thinking to myself "there's got to be an easier way". I've only been seriously programming for about 10 years now and my first introduction language to programming was Perl. For those that know and work with Perl, you know that "there's got to be an easier way" is a recurring theme. Perl is a very powerful language that has a lot of flexibility, but for my uses and the types of things I've found myself building, it was almost always too much. I don't need a programming language that can do everything because I don't do everything. One of the common things known about Perl is that there are many different ways to do the same thing, and it's not difficult at all to have 10 different methods for doing something that are completely cryptic to anyone other than the developer that wrote it. This is a great idea. It gives freedom of coding style, freedom of choice and flexibility in how something works. The problem is that for the majority of the time, it's simply too much for me to handle.
For the past couple of years, I've passively watched the growth of PHP as a programming language and would constantly find myself criticizing it for it's lack of flexibility or being "too easy". I've seen demos and examples of platforms like Ruby on Rails where you can create an entire blog in 5 lines of code. I like to maintain a lot of programming control in applications I write, and that's doing way too much for me (something about most of my code being put in place to reverse something that it did automatically for me just doesn't seem right). I knew Perl was making me work harder than I wanted to but I didn't know of a different language that I felt would strike the right balance for me in terms of programming control and ease of use.
About 2-1/2 years ago, I was working on a side project that involved integration with Wordpress (and then later, phpBB) which was sort of forcing me into a position of needing to know a little bit about PHP. The end goal of what I was trying to do involved tracking a user's session (in the case of phpBB, actually using phpBB's session) through a site that included iframes so the system needed to either be able to save the cookie, or, if the browser rights were too strict, at least be able to pass the session ID along with every link so every other page would still have session data. It was when I discovered PHP's use_trans_sid setting that I was hooked. With that feature enabled, PHP would automatically buffer anything I was echoing and would go back in and add the session data to the end of any link I was echoing and it would automatically add a hidden form element containing the session information to any form I was echoing so that forms could also continue the same session. This feature got really close to the "doing too much" line, but it ended up saving me a lot of time and the end result was exactly what I'd hoped for (and it did it automatically!).
There have been countless numbers of examples of the same type of situation over the last 24 months or so. number_format(), trim(), setcookie() and array_unique(), just to name a few.
So, with my new excitement about PHP only a few months old, I was sitting in the lobby of the Embassy Suites in Chicago last year on the final day of the RETS conference killing time before my 6pm train while still digesting everything that'd happened the last few days. I'd seen some demos of some nice applications and other tools, but most of them were for Windows or needed to be run as complete programs rather than smaller tools that a developer could use. I wasn't unfamiliar with working with RETS at that point because I'd written a few different internal clients in Perl, but I still couldn't say that I had a good grasp on the big picture yet. I ended up taking out a pad and pen and made a full page of notes. I was determined to find an easier way that would both make sense to me and make sense to someone else that had very little experience with RETS.
That piece of paper is what eventually became the list of goals and general structure layout of PHRETS, a free, open source PHP library for working with RETS. In working with Perl, I knew that there were a ton of Perl modules that could be used to introduce functionality to a program but I had no idea how to write one. I knew that other functions or classes could be written which would do similar things but I'd never needed to write them so I didn't know how those would be structured or designed. I knew that in order for PHRETS to be easy for someone to use, it needed to be fairly easy for me to make. I knew that if I tried to get too tricky with it, it would be too tricky for someone else to understand. I knew that if average Joe Programmer me could use it, any average Joe Programmer could.
A few weeks, I posted the latest version of PHRETS which included the last major part of RETS I'd originally set out to support (GetObject). Personally, this was a pretty big accomplishment because I finally felt like the code could be used by someone to do something useful. The code works, it manages a session successfully, it retrieves and processes metadata (data formats) correctly, it can do queries and retrieve back any type of record from a RETS 1.x server, and it can query for and retrieve back photos. It assumes as little as possible to remain as flexible as possible.
I think I've created an easier way and I encourage you, if you're even somewhat familiar with PHP, to give it a spin. It'll only take a few minutes to know if it'll be successful or not, and I think you'll find an incredible amount of flexibility using the features it has. For example, for retrieving photos, it assume nothing. You tell it what to get from the server, it gets it and returns the actual image data back to you to do whatever you want with it. If you want to put the image data into a file on your system, go ahead (you're a quick file_put_contents() away) and use whatever filenaming scheme you can dream up. If you want to send the image data to Amazon S3 for storage and serving, you can do that, too.
Development on PHRETS isn't done as things are constantly changing and improving. Additional support for versions other than RETS 1.5 are needed and the first steps towards those has already started. Additional error checking and error reporting is needed so those are being added as well. If there are features or items that you see that you'd like to suggest, please let me know. All of the information about PHRETS as available at the project site, located at http://troda.com/projects/phrets .
Look for some additional PHRETS related posts coming over the next few weeks. I'm scheduled to be part of a presentation during this year's RETS Conference in about a week where tools such as PHRETS will be showcased.
Categories
RETS , programming0 TrackBacks
Listed below are links to blogs that reference this entry: One giant leap.
TrackBack URL for this entry: http://blog.troydavisson.com/mt-tb.cgi/24
Leave a comment