-
Website
http://zygote.egg-co.com -
Original page
http://zygote.egg-co.com/10-dirty-little-web-development-tricks/ -
Subscribe
All Comments -
Community
-
Top Commenters
-
marcfalk
6 comments · 1 points
-
mike1630
2 comments · 3 points
-
Levi McCallum
4 comments · 1 points
-
garazy
2 comments · 1 points
-
Gen Kanai
3 comments · 1 points
-
-
Popular Threads
Also, is OSF and yongfook.com so far the only ones you've used Codeigniter to build?
We get the message
The Subversion tip was great, I'd never come across using it for web projects this way. I wonder if I could get our tech department to go for it.
*giggles maniacally till the tears flow like wine*
who are big on industry standards :) It just surprised me how big of
a knowledge gap there was between that kind of entity and individual
web designers / small web shops who had lots of coding / design
experience but not much experience with best practices.
If you ever write something called 'Learn basic Ajax, Javascript and the likes, while you smile...a book for the yet daunted', please drop me an email. I'll buy it and promote it as well.
I write professionally, and am a visual artist. Web design is a language I hear more than I can speak.
Thanks for sharing your skills.
May i ask what sort of editor you use for php / css?
http://www.skti.org/skedit/
The div has a class of "clear" and .clear { clear:both; line-height:1px;height:1px; }
Ea of these have their place. I'm personally against adding an unnecessary div to the html, so that solution is at the bottom of my options, but one of the others (floating and overflow, or clearing using a necessary element (ie not adding a random
or <div> to your code) usually solve this.
Really nice list though - I've found a lot more to try & learn! thanks!
what specific problem do you have?
On Fri, Mar 14, 2008 at 6:41 AM, Disqus
proj/
-- htdocs/
-- htdocs/index.php
-- system/
-- system/file_that_routes_requests.php
You then use an .htaccess with mod_rewrite rules to force all requests to that index.php file. Your PHP scripts can then include files that reside outside the document root. In this example, it might include the "file_that_routes_requests.php" file, and pass the request information to a function contained there, which hands off the execution logic to the appropriate code.
So instead of going to http://example.com/users/show.php, you might go to http://example.com/users/show . The router sees that you're requesting 'users/show', and has the logic to load up the code that handles that. In CI, this would be the users controller's show action.
A lot of PHP frameworks do this footwork for you. Rails and CI are both able to use the http://example.com/contoller/action convention, though you can define custom routes as well. Some frameworks, such as Django, don't have a "base convention", or the notion of "controllers" and "actions" (which in Rails and CI are just instances of objects and their methods). In Django, you tie a particular URL to a function object (functions/methods are first-class objects in Python), which gets run when a matching request comes in.
Saves a lot of time, IMO.
If I could add an 11th trick (even if it's just a broader version of #10), it would be: Build on the shoulders of giants. If a lot of people who are probably smarter than me have already gone through and made refinements based on their own experiences, there's little reason to start from scratch.
Thanks for sharing!
I like seeing lists like this. Sensible, yet not blatantly obvious.
If you want to take your svn deployments to the next level, look into Capistrano. Contrary to popular belief, it's not just for Ruby/Rails projects (a point we're trying to make in our next iteration of the documentation). It becomes especially useful once you're dealing with multiple machines that have multiple roles (multiple app servers behind a balancer, multiple db servers behind a master, etc).
Thanks, Jon!
http://masonbrowne.info/2008/03/27/deploying-co...
In this tutorial, I'm deploying to DreamHost shared hosting... and if I can get it running there, you can get it running anywhere.
The great thing about CI is the extremely well-written and easy to navigate user guide:
http://codeigniter.com/user_guide/
https://addons.mozilla.org/en-US/firefox/addon/60
If your website is at http://example.com, you could decide to have everything at http://example.com/someprefix/[rest of path here] - Everything after "someprefix" can be routed by the CI router, and you get the benefit of having CI for new code while still having the legacy stuff in place. Then you can gradually migrate over.
Additionally, if you're the mood for some footwork, you can still take advantage of most of the libraries that come included with CI. In most cases, they'll depend on CI-defined classes (like CI_Base), so you'll still have to include the base library somewhere.
The "no" is that while you can still _use_ CI with your legacy stuff, it's generally easier to just drop into CI than try to get things like, say, the DB layer, integrated with your MVC structure. But that's not to say it's impossible. Just won't work out of the box.
If possible, I'd say do the gradual switch. Then you can take advantage of some of its niceties, like page caching, without having to do glue work.
So awesome... that solves a lot of VERY annoying problems, thank you!
yea right - asp is for people ( although sometimes I wander ) who are happy to settle for a broken site.
I have come accross more broken asp sites than working ones (including microsoft.com)
Yes!! That's a everyday problem when working all day with css. This is the best solution of the problem so far! thank you!
that was a pain but i don't claim to rock at css and thought i had a good fix. now i am going to redo my html real quick..
thanks - PS: my wife loves opensourcerecipees.com
I'm off to setting up SVN now - no more FTP for my webprojects
I made the switch from export to checkout in days...
My MO, at lease for "serious" work, is this:
I have 3 machines: dev, test and production. SVN can sit wherever.
I commit code from dev, SVN update the test machine, make sure everything is ok, and then run a sync script that syncs test to production. No changes are allowed on test, to avoid SVN collisions.
It takes a bit longer, but it's much safer.
the sync script usually looks something like this:
rsync -avzr --exclude=.svn /var/www/html/* woot@production:/var//www/html/
just add a public key authorization to the production server, and you won't have to type a password as well.
The most effective way of using it in web project management that I've found is using branches and post-commit hooks to automate deployment.
You maintain branches for stable, testing, etc, and trunk (as is the usual practice), and for each branch, you have a public/private key for SSH which is only allowed to update the codebase, nothing else.
The hooks simply check whether or not a specific branch was changed after each commit, and if they are, ssh into the appropriate place, ensuring that all of your servers are always running the correct version of the code.
"There are a lot of solutions to this, such as sticking in an element to clear the floats (bleh)"
div's have no semantic purpose anyway so if you want to keep your code clean you have to draw the line when you start sticking them in to randomly fix display bugs.
if there's a way to do it without markup, that's obviously the better way, and that's what #7 is.
jess
http://www.anonymity.at.tc
Thanks for Sweetcron as well, hoping to use it in an upcoming project very soon.
I'm not sure about tip 9. The popular RESTful style promotes the opposite approach: request handlers are grouped by business logic rather than implementation techniques. I think it makes sense because when working on a feature we usually work on a specific set of objects. Typical RESTful controllers with their 7 CRUD methods (index, show, new, create, edit, update and delete) offer a consistant structure and IMHO make the code so much easier to navigate. This design also allows writing actions that can handle both AJAX and regular request.
#5 could also be an issue depending on how your MVC structure is set up. I personally do $template->render('header'); $template->render($page); $template->render('footer'); , so naming files with underscores would be a bad naming convention for some systems.
Item #1 is fine for a team if they follow this discipline: before deploying to the live site, check everything out to a "staging" site like dev.mysite.com; after testing and fixing the code, check it back in and make a "tag" for that revision in the repository. *Then* you deploy that tag to the production site by using svn switch.
If you want raw assets like FLA and PSD files to be version controlled but not in your web space, you can put them in an "assets" directory that's above the public html directory.
I tried deeming myself a "Web Master" ("oh, so you manage websites?"), "Web Designer" ("Oh, but who does the coding"), and "Web Developer" ("Oh, but who does the designing?")...but none of those fit the bill. "Web Producer" works great! Maybe that will look better on my resume.
www.geek.nexo.com
Nevertheless, it always nice when somebody confirms and shares these tricks
Been tryin to figure that crap out.. its really annoying.
Wow, so true.
Personally I prefer to keep subversion for the development systems, the production system gets it's files by using Unison to update from a testing system.
And I certainly wouldn't recommend leaving off the closing of a PHP file, that's just sloppy.
it's not even needed, dude. and it completely eradicates the risk of
parsing errors.
See Zend's recommendations here:
http://framework.zend.com/manual/en/coding-stan...
B.2.1, first paragraph.
I do agree that leaving of the trailing php tag seems sloppy, any issue with surplus whitespace should show up in testing, and Zend Studio even removes any trailing null content for you just to make life even easier.
But you may consider using Git instead of SVN. It will save you some headaches. You can also get a free (public) repo at GitHub.
I've just started using Bazaar myself, but I'm using it in tandem with SVN (until I get a better solution going with my server). Handy thing with Bazaar is that it doesn't store a hidden folder in every folder. Instead, it just uses one .bzr folder in the root of your checkout/branch. So you can easily upload a bunch of folders without having to have a gazillion extra files/folders included. That said, rsync is probably the safer bet for updating your production server.
Tip 7 is pure genius.
Not sure if I agree with 9. I've tried both methods, and I think I prefer grouping the controllers based on subject rather than context. That way you can write one controller action, eg: updateAddressAction() which will provide a different response based on the type of request. So if you've got js disabled, it will post to the same action but respond appropriately.
Will definitely be trying the 15 minute nap + coffee trick.
I will get started using your tricks today.
thanks from tony
This isn't necessarily true - it really depends on how you serve your repository. For example, if your repository is on a separate server and you're remotely grabbing code using some unencrypted protocol (http, svnserve), then all your code is being transferred in clear text. Better to serve the repo using https or ssh tunneling.
Personally I use a read-only account to checkout from our subversion repo to the live server. Our developers only use capistrano to interact with the live server, so they can't get into any bad habits.
If you're a freelance developer, than you have only yourself to blame for getting into bad habits.
I liked the first idea of SVN. I don't know which planet I'm living in, but I never came across this idea before. Thx!
I found that by using :after pesudo class does the job quite well across all browsers...
this tut explains how you can set up a local repository as well as remotely in answer to my own question ;)
Don't bother with the .htacess change to hide the .svn directories. Use svn export instead. It excludes those directories and will make the checkout a damn site quicker
Have you takne a look at Kohana? Based on CI, but full OO. I'm really liking it. Not got the patience to learn Python, or Ruby at the moment.. and this is cmnig form an ex Java dev!
I agree with most. Using SVN has saved my ass over and over, thanks to my team who introduced it to me years ago.
JQuery is possibly the best thing that ever happened to the JavaScript community.
Not sure if anyone else had problems, but I wasn't able to see the second chunk of code for #8 (the HTML)... either way, good list of dirty lil tricks. :)
Great article!
But you may consider using Git instead of SVN. It will save you some headaches. You can also get a free (public) repo at GitHub.
:)
you "could" use svn as part of deploying your app but it's better if you could have a build script, see phing, for deploying your applications.
Update your copy using svn then run phing for deployment. In this way, you can control which part is included and excluded as well as change some settings (ini, xml, yaml) for production only purposes.
Use Linux with sshfs and share the mounted file system via Samba.
http://www.communitymx.com/content/article.cfm?...
* { .. }
not work in older browser, it is better to make a biger reset.css like YUI
your suggestion is exactly what I said.
http://www.carshowsdate.com
Thank God.
Great post
Thanks for this great post
Your tip about FTP andsvn are noted
I will definitely be implementing a few of these!
Chrisranjana.com
I personally use CakePHP and love it.
Make 3 forks
1) Development
2) Test
3) Production
so you don't get your development locked in by testing neither your testing team crazy about pages changing during tests and most important: Development will hold only what is trully 100% tested.
PS: Add to your list: Get time to create Unit Tests so you gain time in testing and let anything pass on your tests that you didnt rememered cus you'll have it tested on your unit classes.
w00t - rh1n0 9 in the house
p/s: Im a good fan of symfony. Do u have any personal experiance with symfony?? I'm checking out CI (erkk.. I need coffee & nap.. ..;)
cheers.
Btw.: To prevent committing everything directly to your live system: Use branches, merging is really easy nowadays.
Thank you for the great tips!
I think I will give the coffee/nap technique a try.
I'm relatively new to SVN, only been using it for a few months. But after some thought and internal debate (and not having seen this post) I established an SVN commit/update workflow at my new job nearly identical to your #1 suggestion. And after years of "doing it the hard way" I have (ironically?) also adopted many of your suggested tools, tips, 'n' tricks in my daily workflow.
1. Khoi Vinh's "designing with grids" changed the way I design websites.
2. The "CSS reset" concept and grid.css style sheet changed the way I build my front ends.
3. MVC and CodeIgniter changed the way I approach server side programming.
4. And the power nap definitely works.
It's nice to know I'm not crazy, just crazy like "teh fook."
world changed was definitely getting to grips with MVC, thanks to
CodeIgniter's easy-to-get-started MVC implementation (and excellent
documentation).
After that, I wasn't building websites anymore - I was making apps.
Peashoot (current project - www.peashootapp.com) is probably the most
complex app I've built so far.
I love the CSS Reset and I suggest using CSS framwork like (960.gs) to fasten the workflow.
Great List! Thanks.
I will give a try.
Rahul
http://BharatPad.com, http://BharatClick.com, http://Chaurasia.info, http://EstateHour.com, http://BharatPlot.com, http://Join2Green.com, http://PetsMantra.com, http://valdot.net, http://TrueMedicalTourism.com, http://TechZed.com, http://TheMedicalTour.com, http://AstroHour.com, http://IndiHub.com, http://GenxHealthCare.com, http://Valueyoga.com
The proper way to work with svn for production environment:
1. Tag your code in svn eg: release-1.0
2. make a folder to host your production files. EG: /var/www/release-1.0
3. svn export your production files from the tag into the release-1.0 folder.
4. Make a symbolic link to your /var/www/release-1.0. EG: ln -s /var/www/release-1.0 /var/www/mysite
5. Inside the httpd configuration file, make sure that your virtual website points to /var/www/mysite (and not /var/www/release-1.0)
Wants to move to the next version? Easy:
1. Tag your code in svn eg: release-1.1
2. make a folder to host your production files. EG: /var/www/release-1.1
3. svn export your production files from the release-1.1 tag into the release-1.1 folder.
4. Eventually, perform some testing here to make sure everything is in place.
5. When ready, just change the symbolic link from /var/www/release-1.0 to /var/www/release-1.1. EG: unlink /var/www/mysite ; ln -s /var/www/release-1.1 /var/www/mysite
Advantages:
- Downtime = 5 secondes?
- You always know which version you run
- no .svn file in your way
- Something went horribly wrong on your new release? rollback instantly by changing the symbolic link from release-1.1 to release-1.0
- Wants to fix a bug found in release-1.0, checkout the release-1.0 tag and go.
- svn export and changing the symlink are easily scriptable
ssh + svn up is for the lazy among us.
http://ez.no/ezcomponents
I feel like such a n00b, reading your list and not understanding anything yet!