A challenge that many website owners face is how to supply continuously fresh content for new and repeat visitors to peruse.

It can be a very time-consuming task to manually upload regular updates. Fortunately, there is an easy way to showcase free, readily available news content on a wide variety of topics.

We will examine a quick and effective method of incorporating RSS (Really Simple Syndication) coding in order to add news content to any site. First, let’s look at what RSS is, and how it works.

RSS is an online coding solution that delivers automatic updates for Web content. Say, for instance, you add an RSS code for international news to your website from a popular source, such as CNN, Reuters, or the BBC. Visitors would be able to access new content links as often as the source updated their news feed. In other words, you get the benefit of presenting the very latest desired information online, with no effort on your part.

Due perhaps to a misguided perception that it is difficult to add the necessary coding to make RSS work within a website’s framework, it remains an extremely underutilized resource.

A typical RSS newsfeed (this one from the BBC) looks like:

http://feeds.bbci.co.uk/news/world/rss.xml

When the XML document is updated by the BBC, the new information is automatically displayed on any website that has incorporated the above URL to obtain World News.

You can find RSS feeds all over the Web; just look for the small orange icon with a dot and two waves above it. The very latest data is available on diverse subjects ranging from international news, to financial updates, to reports on innovations in the food and drink industry, to the latest updates on plants and gardening.

So, now that we have a better understanding about RSS and what it can do, let’s move on to finding out how to incorporate the correct coding into a website in order to gain the noted benefits.

Google Feed API

Google has developed an exceedingly convenient method to display RSS feed data, via their Feed API feature. Using this technique, you can showcase any newsfeed by incorporating some simple Javascript lines into a web page.

To begin utilizing the Feed API, insert the following script into the Head section of your web page, beneath the meta tag area and just in front of the closing Head tag:

<script type="text/javascript" src="https://www.google.com/jsapi"></script> <script src="http://www.google.com/uds/solutions/dynamicfeed/gfdynamicfeedcontrol.js" type="text/javascript"></script> <style type="text/css"> @import url("http://www.google.com/uds/solutions/dynamicfeed/gfdynamicfeedcontrol.css"); #feedControl { margin-top : 10px; margin-left: auto; margin-right: auto; width : 440px; font-size: 12px; color: #9CADD0; } </style> <script type="text/javascript"> function load() { var feed ="http://feeds.bbci.co.uk/news/world/rss.xml"; new GFdynamicFeedControl(feed, "feedControl"); } google.load("feeds", "1"); google.setOnLoadCallback(load); </script>

Then, insert the following code into the desired area of the web page:

<div id="body"> <div id="feedControl">Loading...</div>...

Coda by Panic bills itself to be “one-window web development.”

I have been a web developer (or at least playing with code) for the past six or seven years, and purchased Coda about a year ago. It took me almost this long to realize the beauty that lies within the code editor when you truly use it as a one-window web development system.

Today, I’m going to walk you through setting up your next WordPress site so you can develop locally, deploy to your live server, and maintain the code base and providing site maintenance. All in Coda. So let’s get started.

Developing a WordPress Website Locally

If you’re new to developing WordPress websites, you’ll definitely want to get up to date on WAMP or MAMP, which stands for Windows/Mac, Apache, MySQL and PHP. Basically, it is everything you need to develop a dynamic website, such as WordPress (or Joomla!, Drupal, etc) on your machine.

The advantages to this are incredible. First off, you’re recreating a server on your machine, which means as long as you’re running MAMP, you don’t need to be connected to the internet. So, if you find yourself 30,000 feet in the air on a Boeing 737-400, you can still work on that WordPress website you promised your client. [Note: if you use CDN content such as jQuery or other JavaScript libraries, those still need an internet connection. I found that out the hard way a few days ago. When developing, always have a copy of the most up-to-date script on your machine.]

To get MAMP or WAMP, visit their respective sites and download the application. Installation is fairly self-explanatory, and there are dozens of tutorials on how to set up local development for WordPress.

Getting Set Up With Coda

The first step to creating a great development process with Coda is to plan it out a little. Think of where your files are going, locally and on your server. A little planning here makes the development process a lot easier when setting up your site on Coda.

Let’s take a visual look at the set up for a sample project.

So, as you can see, you’ll have two sets of code bases, one locally on your computer and one live on your server. Obviously, the local code base can be previewed with the magic of MAMP or WAMP, while the live code base is viewable by your customers or clients.

With the layout of the development and deployment system framed out, let’s jump into Coda.

Setting Up A Coda Site

The first tab you want to utilize in Coda is the ‘Sites’ tab.

Next, you’ll want to look in the bottom corner and click “Add Site”. This will bring up the Site creation menu, where you can set up your local code base, FTP to your server, your local preview site, and your live preview domain.

Starting from the top, the Nickname is obviously the name of the site or project. The Root URL is the domain for the server that this site will live on. As the tool tip suggests, Coda will take a quick screen grab of this domain and use it as the preview in the Site menu.

Moving down the list, the Local URL is the domain that your MAMP or WAMP uses. This enables the “Preview” tab in Coda when using a database driven solution. For my setups, my Local URL is always http://localhost:8888. Check your MAMP or WAMP set up and check what your local server is.

The Remote Root is the location on the server where your files will be placed. This could be the root of the server, or could be a subdirectory. Finally, the last key is the Local Root, to which you can browse, select your local code base, and get to work.

The next major section is your FTP information to connect to your server.

Once you’ve got all that set up, click Save and let’s get to work.

Developing Locally

Once you’ve got your site set up, simply double click on it to open up a code editor with your theme file folder on the left and any open files that you were working on. The beauty of the Site is that you can save all of your work, close Coda, come back hours later, click your Site and everything opens up just where you left off.

If you’ve created a WordPress theme before, you know what you’re doing at this point. The connections we created when we set up the site will now allow you to edit PHP and preview the WordPress website in the “Preview” tab. Be sure that this isn’t your exclusive testing, though, as you should always check your website in every browser that you possibly can.

Publishing to Remote Server

So you’ve been hard at work creating your theme locally and you’re ready to publish to the remote server. All it takes is the click of a button.

Once you hit “Publish All”, every file that you have saved will be pushed via FTP to your web server – all from the same Coda window. Sorry if you were hoping the publishing section of this article was going to be longer… but it’s really quite simple.

Maintaining Your Site, Locally and Remotely

Whether you’re working for a client or a personal project or your brand new portfolio website, you will definitely have to maintain the code, add or delete features, and change up the CSS. With your set up in Coda, you’ll never have to dive into the clunky WordPress editor or deal with downloading and uploading FTP files for hours on end.

Within your site, you can quickly select whether you want to work on the Local code base or Remote code base. My recommendation is to always work on the local code first, then Publish All to the web server. Since you have MAMP or WAMP set up, you can preview exactly what your site will look like on the live server without committing the changes. Once you’re satisfied with the changes, publish all and go to bed happy.

Further Extension

While this article touched on a few of Coda’s positives in the Site, Editor and Preview windows, they also have full Terminal support, a dedicated CSS editor (although I prefer to write the CSS by hand), and a Books section, with several free handbooks and the ability to add more. Those items are outside of the scope of this article, but if you’re looking for more information on them, visit the Coda website to read more.

Conclusion

The set up I’ve described above is my go to set up for web projects at the moment. Do you use Coda (or another one-window editor like Espresso)? How do you develop, publish and maintain your websites? Join in on the discussion in the comments below.

...

With HTML5 and JavaScript, you can implement native drag and drop functions within the Web browser.

This is one of the emerging HTML5 tools that promises to make websites more interactive without relying on additional technologies such as Flash. In this tutorial we will create a simple page with images the user can drag and drop into designated areas.

Create an HTML5 Web Page

Create an HTML file for your drag and drop function. Use the following basic outline, with sections for JavaScript and CSS in the head area:

<!DOCTYPE HTML> <html> <head> <style type="text/css"> /*styling here*/ </style> <script type="text/javascript"> //functions here </script> </head> <body> <!--page elements--> </body> </html>

Add Drag Targets to the Page

Your page will contain elements that can be dragged and elements in which the dragged items can be dropped. Start with the areas your user will be able to drop draggable elements into, adding the following in your page body section:

<div class="pics"> <div id="place1" ondrop="dropIt(event);" ondragover="event.preventDefault();"> </div> <div id="place2" ondrop="dropIt(event);" ondragover="event.preventDefault();"> </div> <div id="place3" ondrop="dropIt(event);" ondragover="event.preventDefault();"> </div> <div id="place4" ondrop="dropIt(event);" ondragover="event.preventDefault();"> </div> <div id="place5" ondrop="dropIt(event);" ondragover="event.preventDefault();">...

Savvy web developers often use vendor prefixes to try out the latest browser styles before the styles have been approved by the W3C and turned into a standard.  By specifying a browser or vendor prefix within your CSS stylesheet or style property within a JavaScript function, you can gain control of how an element will render within a specific browser (Chrome, Firefox, IE, etc.).

This gets you access to these browser’s newest and coolest styles and elements.  This article will illustrate how to use a JavaScript function to identify which vendor prefix is needed for the user’s browser. This technique has been adopted by the Microsoft MSDN team as a best practice for their demos.

Before diving into the tutorial, I want to stress the caveats with using vendor prefixes in both CSS and JavaScript.  While vendor prefixes can open your web pages to all the neat stuff companies have packed into their browsers. They can also render your code worthless if a vendor decides to drop support for the style you are accessing.  This happens when the vendor’s request for a new standard is not adopted by the W3C. The W3C is slow to adopt new standards and sometimes a vendor will withdraw its request in order to pursue other technologies. If you choose to employ vendor prefixes in your pages, you will want to make sure your code or stylesheets will still render beautifully when the vendor prefix is no longer found.

Here is an example of a JavaScript setting the transform style using vendor prefixes. (This could also be done in a CSS stylesheet, but this article is focusing on JavaScript.)

var oElement = document.getElementById("myElement"); oElement.style.msTransform = 'scale(2)'; //IE oElement.style.webkitTransform = 'scale(2)'; //Chrome and Safari oElement.style.MozTransform = 'scale(2)'; //Firefox oElement.style.OTransform = 'scale(2)'; //Opera oElement.style.transform = 'scale(2)'; //Someday this may get adopted and become a standard, so I put it in here.

As you can see, if you plan to use vendor prefixes for several styles in your site, this technique can get clunky and time consuming to code. Instead, a better way to find the supported browser is to loop through each vendor prefix to find the right property or return null if one is not found:

function GetVendorPrefix(arrayOfPrefixes) { var tmp = document.createElement("div"); var result = ""; for (var i = 0; i < arrayOfPrefixes.length; ++i) { if (typeof tmp.style[arrayOfPrefixes[i]] != 'undefined') result = arrayOfPrefixes[i]; } else { result = null; } return result; }

The next step is to initialize a variable for all the properties using vendor prefixes in your page.

var transformPrefix = GetVendorPrefix(["transform", "msTransform", "MozTransform", "WebkitTransform", "OTransform"]); var transitionPrefix...

In last week’s lesson, we looked at the variables and methods we would need to interact with the advertising database tables.

This week, we’ll examine the code for the data object class file and how the other parts of the site will use these methods.

First, we include the database connection string information.  This information includes the database server name, cursor location and other pertinent information. Since this information is used throughout the site, it is usually stored in a separate file. In this instance, we have included it in a “require_once” method.

<?php require_once("dev_drive_dbconn.php"); //database connection string info

Now we will create the ads class and instantiate the variables:

class ads { var $_id; var $_oConn;

Now we will create the ads function. This function calls the $_oConn variable and connects the functions to the database tables.

function ads($id = '') { // implement pear db object $this->_oConn =& DB::connect(DSN); if (DB::isError($this->_oConn) ) { catchExc($this->_oConn->getMessage()); } // set ad id if (is_int($id)) { $this->setId($id); } }

Once we have established the database connection, we can set the value of the $_id variable with the setId($id) function.

function setId($id) { if (is_int($id)) { $this->_id = $id; } }

Next, we will build the getAdsCount function. This function will return the number of ads in the database table.

function getAdsCount() { $sql = "SELECT count(ad_id) AS cnt FROM dev_drive_ads WHERE deleted=0"; if (DB::isError($iCnt = $this->_oConn->getOne($sql))) { catchExc($iCnt->getMessage()); return false; } return $iCnt; }

The getClientsCount function returns the number of clients.

function getClientsCount() { $sql = "SELECT count(ad_client_id) AS cnt FROM devdrive_ads_clients WHERE deleted=0"; if (DB::isError($iCnt = $this->_oConn->getOne($sql)))...

This week we’re going to finish up the portfolio slider on our homepage that we have already started.

At this point, if you view your index.php file and scroll down to the secondary screen it should look something like this.

We’re close, all we have to do now is plug in our jQuery elements and then add some CSS to make our secondary portfolio slider screen responsive.

Go ahead and download the Java files you’ll need from here, keep the js directory in your root folder and check out what out the image below to see what your finished product will look like.

Let’s begin in our index.php file.  The first thing we’re going to do is add some links inside our heading that point to our java scripts. These are the jQuery and JavaScript’s that power our slider. As you can see I sandwiched mine between the link to my style sheet and the closing of the head tag.

<link href="main.css" rel="stylesheet" type="text/css" /> <script src="js/jquery-1.2.1.pack.js" type="text/javascript"></script> <script src="js/jquery-easing.1.2.pack.js" type="text/javascript"></script> <script src="js/jquery-easing-compatibility.1.2.pack.js" type="text/javascript"></script> <script src="js/coda-slider.1.1.1.pack.js" type="text/javascript"></script> <script type="text/javascript"> jQuery(window).bind("load", function() { jQuery("div#slider1").codaSlider() // jQuery("div#slider2").codaSlider() // etc, etc. Beware of cross-linking difficulties if using multiple sliders on one page. }); </script> </head>

At this point you should have a fully functioning slider, but it’s not quite responsive yet.  To make our slider responsive we just have to add a few more things in our media queries and we’ll be done.  First up will be our media query for landscape view tablets with a max width of 1024 px, all we need to do is add our #mainBG2 tag under our #mainBG tag.

#mainBG2 { border-top:10px solid #EDEAE5; background:...

Starting out as a newb in anything is always tough because you never really know what “the right” way to do things are.

If you are anything like me, you can easily hack your way through things and get them to work, but are always afraid that you are missing something.  Well, I’ve come up with my own list of best practices before I deploy a Rails application to the public.

Some of these best practices are, of course, universal to any web application development effort, so I won’t go deep into them – but at least they are here for “the record.”

Do NOT store user passwords as clear text. NEVER allow user submitted information fall directly into database queries. Always backup code, data AND user uploaded data such as images, documents, etc. Validate the content type and extension of user submitted files and make sure the upload directory is secured from running scripts.

Now onto the Rails specific practices.  Some of these may be repeats from other lists that you may have encountered, but becoming a Rails developer I found that they were key to ensuring that my applications stayed secure and performed as designed.

Check your users

What I mean by this is ensure that the logged in user has the ability to perform the requested action.  Sure with the :before_filter on a controller, we’ve all come across the authenticate method.  But also check against what action that user is trying to request for that controller.  You may have roles in your application where admins can delete users but users can’t.  If you are just checking to see if a user is logged in, then you will have your plain ol’ registered logged in users deleting everyone.  That’s no good.

In your :before_filter

create methods such as can_edit?(user)

or can_destroy?(user)

. You could even use a gem like Ryan Bates’ Cancan which is nice and simple to implement.

Cross-Site Request Forgery or better known to most as CSRF

This is one of the nice security features that lured me to Rails.  In PHP and other web languages, this was something you had always take into account and make sure, at the most basic level, that you wrote a method to cleanse and validate the session token with each form submission.

In Rails, make sure you enable protect_from_forgery instance method in your controllers. Also (what I enjoy the most), use form helpers to ensure that your authenticity token is on all form submissions.  The reason I like it so much is in using the form helpers I was just coding the form, but with the magic behind the scenes, it was adding the tags necessary to carry out the security.  To make this magic work, include csrf_meta_tag (or in Rails 3, csrf_meta_tags) in your HTML head tag.

Watch for prying eyes

Make sure you filter out sensitive information from your logs.  I’ve developed many applications with sensitive information being flowed back and forth across the wire, such as online credit card transactions, healthcare patient information, etc.  If, and when, there’s an issue and someone else needs to take a look into the logs to find the error or a trace of what’s happening, make sure that sensitive information, such as credit card information, patient records, passwords, etc are removed from the log files.  9999 out of 10000 times, that information isn’t the cause of the issue and no sense in possibly risking that data getting out.

In your config/environments/production.rb file, you can use config.filter_parameters to set which pieces of information you want to have removed from the logs, just by adding in the symbols separate by commas. i.e. config.filter_parameters = [:ccexpdate, :ccnumber]

Make sure your assignments are covered

Issues can easily arise from overwriting a user’s account id.  Or maybe your application does not allow the user to change their username once it’s set.  Whatever the case may be, you want to make sure that these sort of things don’t happen inside a profile update.

Rails makes it nice and easy with the :attr_accessible method inside your model.  This disables the mass assignment on all attributes of a model to that of the attribute that is listed.  You could also use :attr_readonly as well, which only allows the attribute to be set on the create action.

Finally, clean up after yourself

Everyone, especially sys admins, hate messy people.  Think about the space being taken up by your application.  Then think about how many times you’ve released it.  Uh oh, “can you even see the floor in your room” as my Mom used to say.  Each time you release your application to production (if set up properly), you’ve marked the codebase for release and more than likely moved the symlink of your application’s root directory from one directory to another.  Leaving behind a rollback release in case of some disaster where you code blows up.

Do you need the rollback from 19 releases ago, I’m thinking that you don’t.  Most people don’t even need past 3.  But for my own sanity, I like to keep 5.  I use Capistrano for my deployments and there’s a nice and easy way to keep you and your sys admin going to lunch.   set :keep_releases, 5

in your deployment recipe.  By putting this into your recipe, it stops you from having to go into the filesystem and removing all the directories, 5 back from the current one, manually.  It performs this task once your deployment is completed successfully.

Sure there’s a lot more checks to be had, I know I left a few off this list, but I think that these are the bare minimum to launching your Rails app into a production environment successfully.

...