Archive

Author Archive

The 10 Most Common Mistakes Web Developers Make: A Tutorial for Developers

January 10th, 2017 No comments

Since the term the World Wide Web was coined back in 1990, web application development has evolved from serving static HTML pages to completely dynamic, complex business applications.

Today we have thousands of digital and printed resources that provide step-by-step instructions about developing all kinds of different web applications. Development environments are “smart” enough to catch and fix many mistakes that early developers battled with regularly. There are even many different development platforms that easily turn simple static HTML pages into highly interactive applications.

All of these development patterns, practices, and platforms share common ground, and they are all prone to similar web development issues caused by the very nature of web applications.

The purpose of these web development tips is to shed light on some of the common mistakes made in different stages of the web development process and to help you become a better developer. I have touched on a few general topics that are common to virtually all web developers such as validation, security, scalability, and SEO. You should of course not be bound by the specific examples I’ve described in this guide, as they are listed only to give you an idea of the potential problems you might encounter.

Common mistake #1: Incomplete input validation

Validating user input on client and server side is simply a must do! We are all aware of the sage advice “do not trust user input” but, nevertheless, mistakes stemming from validation happen all too often.

One of the most common consequences of this mistake is SQL Injection which is in OWASP Top 10 year after year.

Remember that most front-end development frameworks provide out-of-the-box validation rules that are incredibly simple to use. Additionally, most major back-end development platforms use simple annotations to assure that submitted data are adhering to expected rules. Implementing validation might be time consuming, but it should be part of your standard coding practice and never set aside.

Common mistake #2: Authentication without proper Authorization

Before we proceed, let’s make sure we are aligned on these two terms. As stated in the 10 Most Common Web Security Vulnerabilities:

Authentication: Verifying that a person is (or at least appears to be) a specific user, since he/she has correctly provided their security credentials (password, answers to security questions, fingerprint scan, etc.).

Authorization: Confirming that a particular user has access to a specific resource or is granted permission to perform a particular action.

Stated another way, authentication is knowing who an entity is, while authorization is knowing what a given entity can do.

Let me demonstrate this issue with an example:

Consider that your browser holds currently logged user information in an object similar to the following:

{    username:’elvis’,    role:’singer’,    token:’123456789′}

When doing a password change, your application makes the POST:

POST /changepassword/:username/:newpassword

In your /changepassword method, you verify that user is logged and token has not expired. Then you find the user profile based on the :username parameter, and you change your user’s password.

So, you validated that your user is properly logged-in, and then you executed his request thus changing his password. Process seems OK, right? Unfortunately, the answer is NO!

At this point it is important to verify that the user executing the action and the user whose password is changed are the same. Any information stored on the browser can be tampered with, and any advanced user could easily update username:’elvis’ to username:’Administrator’ without using anything else but built-in browser tools.

So in this case, we just took care of Authentication making sure that the user provided security credentials. We can even add validation that /changepassword method can only be executed by Authenticated users. However, this is still not enough to protect your users from malicious attempts.

You need to make sure that you verify actual requestor and content of request within your /changepassword method and implement proper Authorization of the request making sure that user can change only her data.

Authentication and Authorization are two sides of the same coin. Never treat them separately.

Common mistake #3: Not ready to scale

In today’s world of high speed development, startup accelerators, and instant global reach of great ideas, having your MVP (Minimum Viable Product) out in the market as soon as possible is a common goal for many companies.

However, this constant time pressure is causing even good web development teams to often overlook certain issues. Scaling is often one of those things teams take for granted. The MVP concept is great, but push it too far, and you’ll have serious problems. Unfortunately, selecting a scalable database and web server and separating all application layers on independent scalable servers is not enough. There are many details you need to think about if you wish to avoid rewriting significant parts of your application later – which becomes a major web development problem.

For example, say that you choose to store uploaded profile pictures of your users directly on a web server. This is a perfectly valid solution–files are quickly accessible to the application, file handling methods are available in every development platform, and you can even serve these images as static content, which means minimum load on your application.

But what happens when your application grows, and you need to use two or more web servers behind a load balancer? Even though you nicely scaled your database storage, session state servers, and web servers, your application scalability fails because of a simple thing like profile images. Thus, you need to implement some kind of file synchronization service (that will have a delay and will cause temporary 404 errors) or another workaround to assure that files are spread across your web servers.

What you needed to do to avoid the problem in the first place was just use shared file storage location, database, or any other remote storage solution. It would have probably cost few extra hours of work to have it all implemented, but it would have been worth the trouble.

Common mistake #4: Wrong or missing SEO

The root cause of incorrect or missing SEO best practices on web sites is misinformed “SEO specialists”. Many web developers believe that they know enough about SEO and that it is not especially complex, but that’s just not true. SEO mastery requires significant time spent researching best practices and the ever-changing rules about how Google, Bing, and Yahoo index the web. Unless you constantly experiment and have accurate tracking + analysis, you are not a SEO specialist, and you should not claim to be one.

Furthermore, SEO is too often postponed as some activity that is done at the end. This comes at a high price of web development issues. SEO is not just related to setting good content, tags, keywords, meta-data, image alt tags, site map, etc. It also includes eliminating duplicate content, having crawlable site architecture, efficient load times, intelligent back linking, etc.

Like with scalability, you should think about SEO from the moment you start building your web application, or you might find that completing your SEO implementation project means rewriting your whole system.

Common mistake #5: Time or processor consuming actions in request handlers

One of the best examples of this mistake is sending email based on a user action. Too often developers think that making a SMTP call and sending a message directly from user request handler is the solution.

Let’s say you created an online book store, and you expect to start with a few hundred orders daily. As part of your order intake process, you send confirmation emails each time a user posts an order. This will work without problem at first, but what happens when you scale your system, and you suddenly get thousands of requests sending confirmation emails? You either get SMTP connection timeouts, quota exceeded, or your application response time degrades significantly as it is now handling emails instead of users.

Any time or processor consuming action should be handled by an external process while you release your HTTP requests as soon as possible. In this case, you should have an external mailing service that is picking up orders and sending notifications.

Common mistake #6: Not optimizing bandwidth usage

Most development and testing takes place in a local network environment. So when you are downloading 5 background images each being 3MB or more, you might not identify an issue with 1Gbit connection speed in your development environment. But when your users start loading a 15MB home page over 3G connections on their smartphones, you should prepare yourself for a list of complaintsand problems.

Optimizing your bandwidth usage could give you a great performance boost, and to gain this boost you probably only need a couple of tricks. There are few things that many good web deveopers do by default, including:

  1. Minification of all JavaScript
  2. Minification of all CSS
  3. Server side HTTP compression
  4. Optimization of image size and resolution

Common mistake #7: Not developing for different screen sizes

Responsive design has been a big topic in the past few years. Expansion of smartphones with different screen resolutions has brought many new ways of accessing online content, which also comes with a host of web development issues. The number of website visits that come from smartphones and tablets grows every day, and this trend is accelerating.

In order to ensure seamless navigation and access to website content, you must enable users to access it from all types of devices.

There are numerous patterns and practices for building responsive web applications. Each development platform has its own tips and tricks, but there are some frameworks that are platform independent. The most popular is probably Twitter Bootstrap. It is an open-source and free HTML, CSS, and JavaScript framework that has been adopted by every major development platform. Just adhere to Bootstrap patterns and practices when building your application, and you will get responsive web application with no trouble at all.

Common mistake #8: Cross browser incompatibility

The development process is, in most cases, under a heavy time pressure. Every application needs to be released as soon as possible and even good web developers are often focused on delivering functionality over design. Regardless of the fact that most developers have Chrome, Firefox, IE installed, they are using only one of these 90% of the time. It is common practice to use one browser during development and just as the application nears completion will you start testing it in other browsers. This is perfectly reasonable–assuming you have a lot of time to test and fix issues that show up at this stage.

However, there are some web development tips that can save you significant time when your application reaches the cross-browser testing phase:

  1. You don’t need to test in all browsers during development; it is time consuming and ineffective. However, that does not mean that you cannot switch browsers frequently. Use a different browser every couple of days, and you will at least recognize major problems early in development phase.
  2. Be careful of using statistics to justify not supporting a browser. There are many organizations that are slow in adopting new software or upgrading. Thousands of users working there might still need access to your application, and they cannot install the latest free browser due to internal security and business policies.
  3. Avoid browser specific code. In most cases there is an elegant solution that is cross-browser compatible.

Common mistake #9: Not planning for portability

Assumption is the mother of all problems! When it comes to portability, this saying is more true than ever. How many times have you seen issues in web development like hard coded file paths, database connection strings, or assumptions that a certain library will be available on the server? Assuming that the production environment will match your local development computer is simply wrong.

Ideal application setup should be maintenance-free:

  1. Make sure that your application can scale and run on a load-balanced multiple server environment.
  2. Allow simple and clear configuration–possibly in a single configuration file.
  3. Handle exceptions when web server configuration is not as expected.

Common mistake #10: RESTful anti patterns

RESTful API’s have taken their place in web development and are here to stay. Almost every web application has implemented some kind of REST services, whether for internal use or integrating with external system. But we still see broken RESTful patterns and services that do not adhere to expected practices.

Two of the most common mistakes made when writing a RESTful API are:

  1. Using wrong HTTP verbs. For example using GET for writing data. HTTP GET has been designed to be idempotent and safe, meaning that no matter how many times you call GET on the same resource, the response should always be the same and no change in application state should occur.
  2. Not sending correct HTTP status codes. The best example of this mistake is sending error messages with response code 200.

3.   HTTP 200 OK4.   {5.       message:’there was an error’6.   }

You should only send HTTP 200 OK when the request has not generated an error. In the case of an error, you should send 400, 401, 500 or any other status code that is appropriate for the error that has occurred.

A detailed overview of standard HTTP status codes can be found here.

Wrap up

Web development is an extremely broad term that can legitimately encompass development of a website, web service, or complex web application.

The main takeaway of this web development guide is the reminder that you should always be careful about authentication and authorization, plan for scalability, and never hastily assume anything – or be ready to deal with a long list of web development problems!

This article originally appeared on Toptal.

Categories: Uncategorized Tags:

Google’s EMD Update – What It Means & How To Adjust Your Strategy

November 23rd, 2012 No comments

Guest post by Nathalie Sanderson

For the past decade, SEOs and marketers have been using exact match domains (EMDs) to boost search engine rankings for specific keywords. Anyone who was fortunate enough to snag the domain name with the exact keywords they wanted to rank for enjoyed a significant advantage over other websites for that particular keyword.

From the point of view of Google’s algorithm, it’s obvious why this “EMD boost” initially made sense. If your website is TravelToTimbuktu.com, it made sense that your website would be relevant if someone searched for “Travel to Timbuktu”. However, this phenomenon was quickly used by SEOs, web developers, and marketers to gain unnatural advantages in the search engine rankings. Webmasters and marketers would use the EMD boost in order to quickly rank small, low quality spam sites above more high quality, relevant content.

The EMD Update – Sept 28, 2012

On Sept 28, 2012, Google launched an algorithm change – known as the EMD update – which virtually eliminated any rankings boost enjoyed by exact match domains. According to data released by Matt Cutts – the head of Google’s webspam team – the EMD update affected up to 0.6% of English U.S. searches.

While this may not seem like much on a grand scale, 0.6% on a scale of hundreds of millions is significant – especially in the SEO community, where the impact was profound. Sites that had been ranking at the top of the SERPS (search engine result pages) for years dropped off the map. To add to the confusion amongst those trying to decipher the EMD update, Google also launched a significant Panda update – its algorithm filter designed to filter out spam – around the same time as the EMD update. This update affected 2.6% of all English U.S. search queries.

The combination of the EMD update and Panda update caused much confusion, leading many webmasters and SEOs to conflate the EMD update – designed to reduce the SEO benefits of exact match domains – with the new Panda release – designed to filter out low quality content.

What Does The EMD Update Mean To Your Business?

As with everything related to Google’s algorithm, the best we can do is informed speculation; the “black box” nature of Google’s search ranking methods makes it impossible to draw any conclusions with 100% certainty.

What we do know however, is that the EMD update doesn’t appear to penalize EMDs, but rather it appears to devalue them. Certainly, it wouldn’t make sense for Google to penalize anyone using an Exact match domain, as that would penalize millions of perfectly legitimate websites. Looking at the numerous “White-hat” EMDs that dropped slightly in the rankings, it’s clear that they didn’t suffer anything comparable to a penalty.

On the other hand, many lower quality EMDs suffered drastic rankings dropped consistent with a penalty. Many speculated that the EMD update may have included a filter that penalizes over-optimized EMDs, meaning that any exact match domain that also has the search phrase in the title, H1, H2, H3 tags, bolded, in image ALT tags etc., when combined with low trust and authority, likely triggers a penalty. For most webmasters, this isn’t anything to worry about. However, for those who built low quality EMD websites for the sole purpose of collecting Adsense or Affiliate revenue, this aspect of the update would have significantly affected their sites.

While many search engine experts agree that there is likely an over-optimization component in the EMD update, the other possibility is that some of the EMDs that suffered penalties around Sep 28, 2012 were not penalized by the EMD update at all, but rather were affected by the major Panda update that occurred around the same time. It’s certainly possible that the Panda filter was tweaked to further crack down on over-optimized sites. This theory makes sense, since many of the EMDs that suffered penalties were also sites with low quality, spammy content. At the end of the day, with 2 major updates released at the same time, it may be awhile longer before we can accurately sort out the true ramifications of the EMD update.

How To Adjust Your SEO Strategy Going Forward

Although the waters are always a bit murky when it comes to SEO, there are a few lessons we can take going forward. The primary lesson is that having a search phrase in your domain no longer seems to offer a significant rankings boost. That certainly doesn’t mean that EMDs are useless – they still carry significant branding power. After all, if your site is an e-commerce store named bluewidgets.com, anyone searching for blue widgets will be able to easily return to your store.

The second key takeway is that – with all the heavily keyword optimized sites that were penalized (whether by the EMD update or Panda), it seems clear that Google is doing everything in their power to reward sites that gather natural links and authority over those whose rankings are engineered by SEOs. Between Panda, Penguin, and now the EMD update, Google is slowly taking away the SEO techniques that have worked for years. While search engine optimization will continue to exist as long as search engines are still around, any efforts to boost the ranking of your site going forward needs to focus on looking as natural as possible.

What does this mean? This means that whenever you make an effort to optimize your site for the search engines, ask yourself if a site would naturally look this way. Would a site naturally have a targeted search term in its title, url, header tags, image alt tags, in bold font, and appearing frequently in the text? Would a site have 100 different links with a targeted search phrase as the anchor text? If the answer is no, then reconsider what you’re doing.

While you should avoid the more “artificial” SEO techniques, continue to put out quality content with the reader in mind. If you build links, search for links from quality sources that are selective in their linking, and opt for natural looking anchor text. Avoid links from poor quality sources that could get you flagged by Penguin – this means spam links, as well as links from sites that tend to link out to other low quality sites. As long as your link profile and on-site SEO look natural, Google will continue to reward your site.

Nathalie Sanderson is an SEO and blogger. Nat is passionate about search engine marketing and entrepreneurship.

Two Reasons Business Can’t Neglect SMS Marketing

October 30th, 2012 No comments

NOTE: This is a guest post, a first for this blog.  SMS Marketing is an interesting little corner of the world of inbound marketing.

By Jawad Khan

SMS (Short Messaging Service) has proven to be one of the most widely used communication and marketing media for top brands to promote new products or keep in touch with customers. You can even see SMS marketing being used by politicians to mass communicate with voters during elections. Obama used SMS Marketing for the first time in the 2008 election and this trend has gained huge popularity in 2012. Other big events also use SMS coverage, including the Olympics and American Idol. Top banks and B2B companies are using SMS Marketing for communication with customers.

SMS Marketing reaches entirely new prospects and customers with great ease. However, this does not mean that SMS Marketing is an ideal method for every campaign with any demographic in any niche. Before sending bulk SMS messages you need to analyze whether your potential customers really want to receive your message or not, and whether your message is accurate and informative or not.

Two big reasons you can’t neglect SMS Marketing:

 

1. Personal Connection with Receiver:
If you ask a group of people whether they would like to give their mobile number to some marketer most of them would ask why that message cannot be delivered using email. But ask them if they would like to receive messages about their favorite sports news and you will see a significant increase in interest.

SMS Marketing works well when you tell people beforehand that you are going to send messages on a specific topic and then keep your promise. Avoid sending them blatant advertisements. If the user knows that you are going to send marketing messages on a specified topic, and he/she agrees to give you his/her mobile number, he/she will become a loyal customer. You will see a great response rate by having a database of such loyal customers.

2. Quick Movers Advantage:
Experts stated that Obama’s text message campaign in 2008 was the most successful mobile campaign to date, a benchmark for marketers around the globe. If email had been used instead of SMS, there would be much less response. Obama’s VP Pick campaign not only grabbed the attention of the receivers but also created a buzz amongst marketers and media professionals.

Top marketers understand and appreciate the fact that only those SMS messages work that are sent on an urgent basis and require quick response from the subscribers. Campaigns with no urgency receive a mediocre response rate but those that are time sensitive and urgent in nature get a much better and quicker response.

It is correct that not all business requires SMS Marketing to promote their product or services, but all businesses should at least use SMS Marketing to increase engagement with existing customers, to increase customer loyalty and ultimately increase returning sales for your business.

Guest Author:
Jawad Khan is a Marketing Manager for multinational IT Company in Dubai, UAE. He loves to write about SMS Marketing, Web Design, SEO, SEM, Online Business, and Affiliate Marketing.