Posts Tagged programming
Local web development vs remote web development
Posted by Adam in For Developers on January 12, 2011
Local Workflow
There are two primary development workflows web developers use. One option is to install all necessary servers, libraries, databases etc on their working machine, do their editing their and then push the changes (hopefully through some sort of code revision system, but often through ftp) to the production server.
Pros
- Ability to work without network connection
Cons
- You must install entire server environment on your personal machine, this may be a bad thing for a laptop with limited resources
- You have to keep your working machine’s environment up to date with the versions the server is using
- You usually won’t want to keep a test dataset in a database on your working machine so you’ll need to make a remote connection to your db server ANYWAY eliminated the ability to work without a network connection
- To show clients the current version you have to push changes to a server.
Remote Workflow
Some developers choose to set up a development server (which can either be a separate machine or simple a separate subdomain on the production server). Their code lives there, when they make changes on their working copy there (again, hopefully using some sort of code revision system like subversion or git). This model allows you to run code in an environment more similar to what it will actually be run on in production. It also allows you to allow collaborators, backers or clients to view the current working copy of the code. You obviously don’t want to be working on the code for a production site (you aren’t that good, you will break things, and for a site with any reasonable amount of users this is unacceptable), but this model works well for working on development code.
Editing code that lives on a remote server. The simplest solution for editing code on a remote server is to ssh in the machine and use a command line editor such as vi, emacs or nano to edit the code. This is somewhat distasteful to some developers especially those who are used to GUI text editors. SSHFS allows a developer to mount a directory on a remote machine as a directory on their local machine in a way that is transparent to the operating system. This is an ideal solution because it allows you to edit code with the tools you’re used to using. We plan on making a blog post about how sshfs and autofs make web development easier, but until then check out google for info about them.
Pros
- Code is run on an environment more like what it will be in production
- Database connections are easier
- It is easy to show clients the code you’re currently working on
- It is often times easier to push changes to the production version of the site
Cons
- Network connection is required to do work
- Requires setup to edit code on your local machine while it is on the remote machine
- This problem is relatively easily solved, we’ll discuss this issue in a later post
Conclusion
Here at Casa Nova Designs we have found the remote workflow meets our needs and allows for more rapid development. This article is the first in a series about what our development environment is like, and how we’ve solved common web design head aches to streamline our workflow. In the next article we’ll show you how to use sshfs and autofs to mount remote file systems.
Regards,
Adam
6 Ways to make your PHP code more maintainable
Most of us have inherited projects from other developers, or have revisited old code that we’ve written months or years beforehand. I’ve personally seen code that looked like it was written by a 3rd grader. Hopefully none of you will have to deal with code written this poorly. Here are a few ways to make your code flexible, and maintainable so that you, or some other developer won’t be cursing you.
I’ll assume that if you’re reading this article that you’ve written PHP code before, and that you’re fairly familiar with the constructs of the language. But, for the sake of being thorough, I’m going to mention a few things.
1. Comment!
Make sure you’re commenting. I recommend a header comment to describe the file: The Author’s name, a description of the script, and a listing of your founding assumptions are all good things to include in the file description. Also if you write some code that is particularly complex or important I recommend commenting it aswell. Some sticklers will even recommend commenting every function (including function parameter descriptions). I don’t feel that this is necessary but if you’re writing a massive application or an application created by multiple developers than this will be very helpful.
2. Use Functional Programming
I can’t believe I have to say this, but, use functions. If you write a string of code more than once it should be turned into a function. But, be careful to avoid writing several functions that do similar things, if two functions could be consolidated into one in an elegant way I would recommend that. remember the less code you have to look at in the future the easier it will be to understand what the application is doing.
3. Split up your files.
If you find that your script is very long try splitting it into multiple parts. Also, if you have certain portions of your code that are used on multiple pages make sure that this part is included in an external file for easy maintenance. If one page has several modular parts make sure that they are all contained in external files.
4. Make sure you’re using directories.
If you’re working on a large project, it’s very important that you organize your files into logical directories. There’s nothing worse than a completely flat file system. I’ve seen projects where there were hundreds of scripts (with nondescript names) in the same directory. Do yourself a favor and organize these files. It’ll make finding things later much easier. I usually find that it’s best to organize my files into Models, Views, and Controllers. Model are scripts that describe data objects (classes). Controllers manage interactions between user actions and models and views give information to the user (pages, ajax responses, RSS feeds, RESTful API responses, SOAP pages etc.).
5.Don’t create variables where you don’t have to.
If a function returns an iterable object and all you need to do is perform an action on that object using a loop, don’t create a dedicated variable for it. For example say that I want to iterate over an array that is returned by a function. Instead of:
$arr = functionReturningArray();
for($arr as $element)
do some action($element);
try:
for(functionReturningArray() as $element)
do some action($element)
this is a much more concise way of performing an action.
6. Object Oriented Programming
If you’re not familiar with it already read up on Object Oriented Programming. OOP allows you to create objects that contain all the data and functions to represent a physical object or idea. This is very helpful for large project where you want to compartmentalized your code into distinct pieces (easier for debugging easier for understanding). This approach almost always yields less code, and if done correctly can yield reusable code for other projects.
7. (Bonus) Don’t Be Lazy
One of the main sources of sloppy code is laziness, remember that just because you know what you’re trying to accomplish with your code doesn’t mean that others will. Take the time to do it right, because sooner or later almost all code needs to be revised, write it correctly the first time and you’ll thank yourself later.
Regards,
Adam Haney
Subscribe To Updates
