Recently in Web Development Category
So I'm spending a little time to learn something new. I've been working on www.todocycle.net for a while now (actual hours spent are still pretty low, but with the little free time I have it's been a long time)... any hoo. I purposely chose to use some technologies with this site that I have never used before but had heard about and wanted to learn.
I started out with a few things that I am very familiar with, so that this project wouldn't take for freaking ever to get off the ground as I learn. I only spend about 3-4 hours a month on it, so my time better be well spent in order to see any visible progress. I started out with Postgres for the database, perl as the coding language, and CGI::Application as the MVC framework. All of which I'm quite comfotable with.
Then I chose a few things to work with to force me to learn. Template Toolkit for templating (I've been using HTML::Template for most other things), DBIx::Class for ORM (I've never really given and ORM a chance), and jQuery for a Javascript toolkit.
So far things have been a mixed bag. Picking up Template Toolkit was no problem at all and I am quite impressed by it. DBIx::Class has been another story. It has been a struggle for me to embrace it, and another one to try to get it to do what I want. I'm not giving up on it yet though. I want to give it a fair shot, but it was not a "learn it in one sitting and go to town" sort of thing like Template Toolkit was.
And then there's jQuery. I actually have been putting that one off becuase I was so focussed on the backend of things until now. I just started reading the docs on jQuery and have to say I am mightily impressed. I used Prototype before and disliked it. At my work, they use Yahoo's YUI toolkit, which seems big and bloated to me. jQuery is tiight, lightweight, and very easy to pick up.
So far:
jQuery A
DBIx::Class B-
Template Toolkit A
I started out with a few things that I am very familiar with, so that this project wouldn't take for freaking ever to get off the ground as I learn. I only spend about 3-4 hours a month on it, so my time better be well spent in order to see any visible progress. I started out with Postgres for the database, perl as the coding language, and CGI::Application as the MVC framework. All of which I'm quite comfotable with.
Then I chose a few things to work with to force me to learn. Template Toolkit for templating (I've been using HTML::Template for most other things), DBIx::Class for ORM (I've never really given and ORM a chance), and jQuery for a Javascript toolkit.
So far things have been a mixed bag. Picking up Template Toolkit was no problem at all and I am quite impressed by it. DBIx::Class has been another story. It has been a struggle for me to embrace it, and another one to try to get it to do what I want. I'm not giving up on it yet though. I want to give it a fair shot, but it was not a "learn it in one sitting and go to town" sort of thing like Template Toolkit was.
And then there's jQuery. I actually have been putting that one off becuase I was so focussed on the backend of things until now. I just started reading the docs on jQuery and have to say I am mightily impressed. I used Prototype before and disliked it. At my work, they use Yahoo's YUI toolkit, which seems big and bloated to me. jQuery is tiight, lightweight, and very easy to pick up.
So far:
jQuery A
DBIx::Class B-
Template Toolkit A
This is an attempt at a how-to for getting a few servers up and running that can talk to each other as well as with your host desktop machine all with vitrtualization. This has been a personal desire for some time and I have read documentation about how to do this and have tried multiple times, and every time it seems that the job is complex and error prone. So this how-to will describe how I finally was able to get it working with almost no effort! Yeah!
First of all, let's set the scene and give ourselves a goal: We want to have a VM web server and a VM database server running on our desktop that runs a simple web application. The two machines need to talk to each other. And we want to be able to open our desktop web browser and access the web application running on these VMs. And do all that without any complex configuration or breaking your desktop's network settings.
The first thing we will use in this setup is VirtualBox (http://www.virtualbox.org/)
First of all, let's set the scene and give ourselves a goal: We want to have a VM web server and a VM database server running on our desktop that runs a simple web application. The two machines need to talk to each other. And we want to be able to open our desktop web browser and access the web application running on these VMs. And do all that without any complex configuration or breaking your desktop's network settings.
The first thing we will use in this setup is VirtualBox (http://www.virtualbox.org/)
Continue reading How to: Set up a few virtual servers on your desktop.
So, it's Thanksgiving weekend and I find myself online reading a few articles and blog posts. One of note that I wanted to comment on and point out:
The benefits of vanilla CGI vs FastCGI for Perl apps
The benefits of vanilla CGI vs FastCGI for Perl apps
Interesting read from Mark Stosberg. I'm quite familiar with Mark from his work with CGI::Application,l as I've been a fan of that perl module for many years now. I think there is a bias here that I need to mention, and that I think Mark and I share.
What people value in a web development process/toolkit is significantly weighted by the process and tools that web developer a) first learned, and b) is most confortable using. Meaning that a developer whose first experience programming web applications was with Catalyst and has since found Mojo more comfortable and uses it regularly, will have a different set of "values" (or criteria by which other things are compared) than a developer who started web development with straight CGI.pm and is now a Jifty user. (this bias should extend itself to any and all programmers, but I find it more appearant in web developers where there is more contention about which toolkit is better than another).
Whew. OK, after all that, I have to say that I agree with Mark and feel that "vanilla CGI" is a great way to get things rolling as a developer without having (usually) to change a thing to a web server. Just write your code and go. I also feel that if people expect things to run slow in CGI and not in mod_perl or FastCGI because that is their biased environment of choice, then they will program accordingly. Meaning that they will write code that is slower, heavier, etc. because "oh, mod_perl will take care of it and it will be fast enough," or something similar.
I've never actualy heard anyone say that, but I hear things close to it from other developers (Java web developers mostly) who feel like everything is perfectly normal when you have to rely on huge complex tools and frameworks and middleware and dedicated containers and separation of tiers and abstracted everything and this and that and the kitchen sink too just to develop web applications. This "normal bloat" I'll call it, is where that bias I mentioned earlier really comes out. If people can't even see that their tools and process is overly complex, burdensome, and has a moderate to high degree of dependencies for normal development and opperation, than how can you persuade them that it is perfectly fine to live without that? How can you make them see that that is not "normal" for many, many other web developers?
Living without FastCGI??? Shudder. You're still using perl for web development?!?!?!? How can you live without Hibernate for data access (or replace with your favorite language specific tool here)?!?! Running perl CGI without mod_perl??? Are you stupid??
Yes, stupid like a fox. Err... I mean, doh.
What people value in a web development process/toolkit is significantly weighted by the process and tools that web developer a) first learned, and b) is most confortable using. Meaning that a developer whose first experience programming web applications was with Catalyst and has since found Mojo more comfortable and uses it regularly, will have a different set of "values" (or criteria by which other things are compared) than a developer who started web development with straight CGI.pm and is now a Jifty user. (this bias should extend itself to any and all programmers, but I find it more appearant in web developers where there is more contention about which toolkit is better than another).
Whew. OK, after all that, I have to say that I agree with Mark and feel that "vanilla CGI" is a great way to get things rolling as a developer without having (usually) to change a thing to a web server. Just write your code and go. I also feel that if people expect things to run slow in CGI and not in mod_perl or FastCGI because that is their biased environment of choice, then they will program accordingly. Meaning that they will write code that is slower, heavier, etc. because "oh, mod_perl will take care of it and it will be fast enough," or something similar.
I've never actualy heard anyone say that, but I hear things close to it from other developers (Java web developers mostly) who feel like everything is perfectly normal when you have to rely on huge complex tools and frameworks and middleware and dedicated containers and separation of tiers and abstracted everything and this and that and the kitchen sink too just to develop web applications. This "normal bloat" I'll call it, is where that bias I mentioned earlier really comes out. If people can't even see that their tools and process is overly complex, burdensome, and has a moderate to high degree of dependencies for normal development and opperation, than how can you persuade them that it is perfectly fine to live without that? How can you make them see that that is not "normal" for many, many other web developers?
Living without FastCGI??? Shudder. You're still using perl for web development?!?!?!? How can you live without Hibernate for data access (or replace with your favorite language specific tool here)?!?! Running perl CGI without mod_perl??? Are you stupid??
Yes, stupid like a fox. Err... I mean, doh.
Continue reading Light reading over the Holidays.
So this will probably be a first in a series of posts related to software design patterns and all my inner strugglings regarding what is hype and what is real. There are probably lot of other people out there that may have similar strugglings, and more than likely there are some out there that are blissfully unaware of the concerns. So what am I talking about? Well let's start where I started a while ago, with ORMs.
ORMs (Object Relational Mappers) are a basically a way to have a OO layer between your application code and your RMDBS. There are some basic "features" of an ORM, but not all ORMs support all of these. In any case here is a list of common features:
ORMs (Object Relational Mappers) are a basically a way to have a OO layer between your application code and your RMDBS. There are some basic "features" of an ORM, but not all ORMs support all of these. In any case here is a list of common features:
- OO interface to tables, rows, functions, etc, in your database. So you can use native application code and OOP to interact with your data.
- A more elegant/simpler API to interact with your database. Many ORMs use some other database API under the hood, but add routines and interfaces (or simplifies calls) that the normal API lacks.
- Object (data object) persistence. So that you can create an instance of some data you are modeling and then be able to store that object and revive it later with state preserved.
- Abstract the interaction between your application code and your database such that in the future if/when you need to move to a different database you application code will require as little change as possible. Ultimately, changing databases should be a matter of configuration files, or perhaps even less work. And your app code wouldn't even know the difference between Postgres, MySQL, SQLite, or something else.
Continue reading Software design patterns and excess.
So, I had an idea and wanted to capture it before I forget. A relatively simple tool to graph a floor plan map of office cubicles with info about each cube- person who sits there, department, extension, and any other info about them. It could be done really easily with the right database structure and using the Javascript graphing library wz_jsgraphics.js (http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm).
That way, all you would need is to maintain the data through an easy management tool, then your map is updated realtime online. And anyone can go to the map in their browser and mouse over a cube and get info, or do a search and get a highlighted cube within the map of what they are looking for.
That way, all you would need is to maintain the data through an easy management tool, then your map is updated realtime online. And anyone can go to the map in their browser and mouse over a cube and get info, or do a search and get a highlighted cube within the map of what they are looking for.
So there is a wide world of tools and methods for "web 2.0", and for developers it is hard to know which one to chose to use and support. I have tinkered with two AJAX toolkits and found things that I liked and disliked with them. But overall I found that they were both too big and too feature rich for simple use.
So it occured to me that for some of my simple projects all I needed was bare-bone functionality, meaning the ability to fetch the contents of a given url. Beyond that I can do what I need in small simple javascript. I didn't need fancy event handling, or animation, or auto-complete drop downs, or such. And if I did, then I could probably do that my self later, as long as I had the ability to easily fetch a URL.
Continue reading Minimal AJAX toolkit.
