So you want to start developing your very first web application? You want to know how you can start quickly and develop your first web application? Well here is the good news, you are at the right place. With these web app development tutorial series we are here to guide you through the development of your first web application and more. But, there are few points before we start. First, we have to mention that these tutorial series are meant for more technical audience with prior web design and development experience. Second, there are different approaches to even developing a simple application. You can copy and paste some code together and call it a success, or take a stricter engineering approach and build a code base that would have test cases, easily extendable, or even scalable for future versions, should you decide to build more features on your existing architecture. In this tutorial series we are going to develop a very simple web application, and build more and more on the same code. Because in real life that’s how software evolves. We will also cover some methodologies and software engineering concepts such as Rapid Application Development (RAD), and Continuous Integration (CI), and many more techniques and best practices that would help you with developing more complex systems. We tried to keep these methodologies separate from the coding tutorial sections, so people familiar with the methodologies could jump straight to the code.
So let’s get started with the concept first, and what you should know before starting your very first and simple web application.
About web apps (applications)
As we all know it, state of the web is very dynamic, and it has evolved a lot since it’s inception. With advent of new web technologies, and more connected devices with powerful browsers, now more than ever people rely on web based software to stay connected.
Before we even start developing a web application, let’s understand what web apps are?
There might be different definitions of what a web app is, how you differentiate a web service from a web app, or even with all desktop software connected to the internet, do we categorize those as a web app or not? Here is what the general Wikipedia definition of Web Application is:
However, as I mentioned earlier, state of the web is dynamic and changes continuously, and so will definition of these terms. But for sake of simple understanding, we assume that above definition of web apps is what we are trying to develop here.
Also, let’s check the facts and make sure that our decision to develop a web app is the right choice. There are couple of factors that would decide if our decision to develop a web app makes sense or not. For example, if we are gaining any benefits by developing a web app versus it’s alternatives such as desktop apps. Or, if we are developing a mobile web app, the alternative would be a mobile native app. There are manygreatarticles on the web about these topics, mobile web app vs. mobile hybrid app vs. mobile native app, however being familiar with the concept that would guide us towards making the right decision is very important, and we should be familiar with these differences before making our decision to design our system. Bottom line with this, desktop apps and mobile native apps have an advantage in using hardware-accelerometers, graphics processors, cameras, and other hardware level access. Of course there are always exceptions, such as using java applets or flash to tap into camera hardware, using browser hardware acceleration in HTML5, or whatever method that would close the gap for web apps. Generally speaking, it is always better to use the right strategy whenever possible.
One of the reasons that web app development is becoming more and more popular is because of the grate amount of leverage that it provides for application developers. One of the main challenges of software development is piracy. With new model of Software as a Service (SaaS), now it is much easier to stop unauthorized access to the software. Also, instead of providing support for different versions of the software on different operating systems, web app users always use the latest version of the software. However, cross platform issues are now cross browser issues, which is much easier to contain. Comparing Microsoft Office Word (Desktop) to Google Docs or even Microsoft’s own Word Web app is a good example of how regular desktop software is transitioning to web based software. I am not suggesting that one implementation or model is better than the other, all I want to emphasize is that knowing the pros and cons with each approach and their differences helps to make the right choice at early stages of the development. Now that we are clear about what web apps are and if our choice to proceed with a web based application model is the right choice, let’s move on to the prerequisites.
Although these tutorial series will cover a basic application development, the premise of these series is to teach you the important concepts that will help you apply on a broader scale to your applications from just an idea to the final product. Here are some of the concepts that we will discuss in the future topics, and your familiarity with these concepts will help you a lot with your application development.
Whether you are developing an application for yourself or others, if your application is solving a problem, there is a possibility that some other person in the universe might have the same problem and looking for a similar solution, and you have a chance to help that person with your application. You could open source your code or charge some money for it. It is possible to sell a license, or provide a hosted solution (on-demand software) to whoever that needs your application. You will have an opportunity to sell your software at a higher flat licensing fee, or bank on a monthly recurring fee.
Business Analysis and Requirements Documentation
Requirements Engineering (RE) is the bridge that closes the gap between your idea to the system that you are developing. Understanding what features and functionality your project will deliver is very important to its success. Requirements engineering clarifies what a system should deliver. If you are just developing an application for yourself, or you are the only one in your team, your requirements document could be just a list of headlines of the main features of your application or even scattered notes on pieces of papers or organized notes in your favorite note application. However, eliciting requirements from customers that are prepared to pay you for developing their requested systems is a journey to the unknown, and it is very essential to put your business analyst hat on and start crafting that requirements document. According to Steve McConnell, author of Software Project Survival Guide:
The most difficult part of requirements gathering is not documenting what the users ‘want’; it is the effort of helping users figure out what they ‘need’ that can be successfully provided within the cost and schedule parameters available to the development team.
Requirements document helps identify customer needs and uncover the clutter in their head into an understandable piece of document that when presented to any software developer, or your team of other engineers that were not present at your client meeting, they could use this requirements document as a guide to develop the exact system that your customer requested.
You might have the best next social network idea, or the next greatest web app idea that would make the world a better place, but your project management approach will highly influence the success and failure of your system. Thus, it is very important to rapidly test our application and continuously build on previous successful builds. We will discuss more about Continuous Integration (CI) and Rapid Application Development (RAD) later, and imply these and similar approaches as part of these web application tutorial series.
Running an efficient software project is not a new problem, and many of these agile approaches certainly are not a new solution, however familiarity with these approaches and general software development life-cycle (SDLC) will definitely ease your application development process.
Minimum Viable Product (MVP)
This is the where business and software collide. Development of a software products might be very expensive if it is not approached properly. In an interview with Venture Hacks, Eric Ries describes Minimum Viable Product (MVP) as a strategy used for fast market testing of a product or it’s features.
The idea of minimum viable product is useful because you can basically say, look, our vision is to build a product that solves this core problem for customers, these kind of general feature areas, and we think that for the people who are early adopters for that kind of solution, they will be the most forgiving.
And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.
The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on.
Once we have established that there is a market demand for the service or application that we have developed, the second part of the project starts. Creating an awesome product. I suggest reading Rework book if you are interested to learn more about business aspect of software and web application development.
Repository and Version Control
In software engineering we iterate through versions also known as software release life cycle. Most common practice in software engineering includes these versions.
- Pre Alpha
- Requirements document, software design, and activities that happen before a project testing fall under this version.
- Stripped down version of your application, which might be unstable and missing data verifications and error handling, but covers the core application features.
- System might have complete set of features, but there might be some undiscovered bugs in the system. Usually this version is only available to a controlled group of users with early access privilege to the system for the purpose of testing and feedback.
- Release Candidate
- System is very stable at this point and no new features will be added at this stage, and the system is available as an early preview to the users for the purpose of identifying the last set of bugs in the system, or understanding user behavior on a larger scale than Beta user set. If perceived positively by users, this version could be a great publicity tool if used by influencers.
- Release (v1.0, v1.2)
- At this stage system is usually released to the customers. Generally version 1 or 1.0 is the first commercially viable and stable version of the system. However, quoted from Edsger W. Dijkstra, since testing only shows the presence of bugs, and not their absence, any minor changes after the major v1 release come as a minor release such as v1.1 which only includes minor changes. Any major changes or new feature sets added to the software come in later releases with a major release increment like v2.
As of writing of this article, my current Chrome browser version is “22.0.1229.94 m.”
Since our code will constantly change and we expect to have different programmers to work on our base code, we need to have a version control system.
About Version Control Systems
What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Git Documentation and Pro Git Book is the best place to start learning about this awesome repository system.
At Big Employee, we use Git version control system. We highly encourage using a version control and a repository system for your web application development, and the choice of version control and repository system is a personal choice and totally up to you. However we suggest Github, Bitbucket, and Springloops for hosting your code on a cloud based repository.
Software architecture is basically the blueprint and skeleton of your application that shows relations between entities of a system and presented in a highest level of abstraction. Later on we will have an exclusive post where we will dive into software architecture and more specifically architectures of web applications. As you know almost all of web applications use a Client-Server architecture, where client requests for services and server provides the service that could be any resource such as data, file, object, CPU time, etc. The ideal Client-Server software should perform independent of Operating System (OS) platform or hardware. A client may become a server, and a server may become a client. A client-server system can be scaled both horizontally and vertically with only a slight performance impact. Horizontal scaling is when we add/remove client workstations, and vertical scaling is when we migrate to a larger and faster server machines or multiple servers or cloud like solution where we have a server farm. There are also other architectural styles, that we will cover in our later posts. For example a more complex architecture might have a separate database server and a separate file server that talk to the primary server where our application is hosted. Architecture design helps us to structure our application on a right skeleton, and it is very important to have the underlying architecture of the application designed properly because if the foundation of our application is not structured right, we wont be able build or grow our application on top of it.
One of the systematic approaches in web engineering is code reuse, and frameworks provide exactly that. For the most part of our web application tutorial series we will use Zend Framework 2. The framework choice for your application is very important. You might decide to write your own framework for the sake of having a full on custom code or increase your web application performance, or might rather to piggy back your application on a framework that would speed up your code development by providing a set of capabilities such as a Model-View-Controller (MVC) architecture. We already had a talk about some principles that will help you choose the right framework, and for these tutorial series we decided to strictly use Zend Framework 2.
User Interface Design and Interaction
User interface of an application is so important that it is considered as one of the key success factors of an application. Getting the interface right is very important. User friendliness of an application is directly related with the interface of that application. And it is not just the interface alone, the interaction of the interface is as important too. Interaction design describes flow of the application or how each elements of the interface should behave when user interacts with the application. You don’t have to have a graphics or art background, or even be a Human Computer Interaction (HCI) expert, but knowing how to test a user interface for its friendliness is an important factor when designing web applications. At Big Employee, our number one source of inspiration is Dribbble for user interfaces and getting ideas from works of other designers.
Having the right set of tools in your toolbox without a doubt will make your development time more pleasing. Also familiarity with these set of tools will help you to navigate your code with ease. Some of these tools are your code editor, database manager/design tools, FTP or SSH tools, image editors, etc. You might choose Eclipse, or NetBeans as your preferred Integrated Development Environment (IDE) for having a built in Git or FTP client. Selection of these tools are all personal choices, depending on what kind of projects you usually work on, but being familiar with the ins and outs of these tool, such as knowing how to duplicate a line or commenting a line using keyboard shortcuts are examples of skills that you should have in a fast paste coding world. We will review some of the tools that we use at Big Employee for developing web applications in later posts.
This is probably one of the most important topics in web application development and always the most neglected one.Yes, no amount of testing is enough testing, we all agree with that. Fortunately there are tools and methods for testing. There is even an approach to development with testing at its heart called Test-driven Development (TDD). However, for most part of these web app tutorials we will use PHPUnit, but for now a simple knowledge of test cases and unit testing is sufficient for these tutorial series.
Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous. – James Bach
Coding Conventions and Best Practices
As much as reading unfamiliar code is unpleasing, reading a code that does not follow standard coding conventions is 10 times more unpleasing. You might come back and work on your project after a year, and even yourself not know what is going on. However, if your code is styled properly and follows some kind of a standard, you will be able to quickly get back to where you were left off. Using coding conventions is very important for team collaborations. Zend Framework has established a guideline for these coding standards, and we will use these standard protocols in our tutorial series.
As a developer, it is our responsibility to ensure safety of our data and protecting our application from security vulnerabilities. Coding best practices suggest that we should encrypt sensitive information such as credit card or passwords. We hear about hacker attacks and consequences of these security breaches in news every day. Having some knowledge about security concerns and principles would help us to use the best judgment when developing our web application.
Coding conventions and best practices not only yield to higher quality code, they also lead to a maintainable code for years to come.
One of the mistakes of newbie developers is working on a live copy of their project and modifying a code on the server without having it tested in their development environment. The concept is very simple, test your code before pushing it to the live server where your application is hosted and others are using it. You could have different sandboxes and stages as it is necessary for your project, but these three are the most common ones.
- This is our working copy. This version of the code contains the latest version and all the experimental features. Developers directly interact with this copy and continuously change, modify and test the latest integration and features.
- The staging environment contains the next release candidate and is usually one version ahead of the production version. In this version final tests are performed and almost no new features are introduced. If you are working with a team, this environment is where your code and your project team code are combined and validated for production.
- This is the stable released version of the software available to the end-users. This version does not change until the next iteration of the software is proven to be stable in the staging environment and ready to be released. Production environment is the actual environment in which your system will run after deployment.
We will build a sticky note application and continue building this project further more. Let’s start coding, here is your first web application of these tutorial series.