.NET Web Forms vs. MVC: Which is Better?

A lot of fuss is being made lately about whether Microsoft's relatively new Model View Controller (MVC) technology should automatically supplant .NET Web Forms as the superior web application development technology. There is no clear-cut answer, and rightly so; they both provide different means to reach the same end. Even Scott Guthrie of the MVC development team stated that, "Different customers look for different programming approaches, and a lot love Web Forms and think it is great. Others love MVC and think it is great. That is why we are investing in both". Below, I have tried to highlight some positives and negatives of both frameworks. This is not an attempt to sway you one way or the other, but rather to possibly provide a broader understanding of why the two frameworks exist as viable options for your company's development needs.

What Are .NET Web Forms?

The idea of .NET Web Forms was born from an attempt to address the ever looming issue implicit in the development of classic ASP web sites. Classic ASP pages housed both the web code and the accompanying code-behind logic in one location: the ASP page. In that way, pages could very easily become long spaghetti-code filled documents that often would become unreadable and unmaintainable. For example, the code to handle page submissions was contained in the same page that would subsequently either redirect the user or need to remain on the current page, but would simply show a different section of the page. This type of event handling was unwieldy.
To address this concern, Microsoft attempted to bring their successful, more event-driven, "visual" windows-application development methodology to web development. As a result, they created a framework that worked more like the popular Visual Basic or Visual C++ desktop / forms development. Suddenly, developers could decouple view code from logic code by having most of their web controls on one page and then have all of the code-behind, "smarts" of the page, contained in a completely separate page.

Advantages of .NET Web Forms

• RAD – Rapid Application Development

  • The mechanisms behind how controls and pages work within an event-driven structure are abstracted out so that the developer generally does not need to know the inner workings of the process
  • Drag & Drop controls provide most of the functionality right out of the box. 3rd party solutions are readily available, and control like Grids generate the HTML and JavaScript for the developer
  • Applications, complete with validation, can be quickly developed by simply setting properties on controls
  • Easy for newbies to "pick up and run" with web application development

• Cost

  • Being the older, more legacy framework, most .NET web developers have experience with Web Forms, or more specifically the desktop application event driven framework from which it was derived - there is a smaller learning curve implicit in learning the Web Forms framework

• More Mature

  • Like the old joke goes, "no matter how old you are I'll always be younger". Even though MVC is a younger .NET technology (the paradigm methodology, though, has been around for a while), Web Forms was here first and has a larger and more robust legacy implementation

Disadvantages of .NET Web Forms

• Very little control over HTML produced on the page

  • The ability to simply drag & drop controls enables rapid application development (RAD), but the drawback is that the developer has very little control over what HTML is actually produced on the page
  • Initially, a pretty big issue with Web Forms was not being able to control the HTML produced on the page, meaning that control ID generation was sometimes after-the fact guess work
    • ID management becomes compromised and using client side frameworks like jQuery become more difficult in that control ID's, or even control nesting / hierarchies, are not always consistent
    • Even though Microsoft has taken steps to improve this in the latest release of MVC, not enough time has passed to determine if they've truly resolved this issue

• Web Forms Life Cycle

  • How many developers truly know the full extent of the Web Forms lifecycle? A lot of developers must become acquainted with the more esoteric lifecycle events as a result of needing to "hook" into 3rd party controls

What is MVC?

The MVC design pattern was not invented by Microsoft. Rather, it has been around for upwards of 30 years, having been first introduced around 1979. Since then, the methodology has been implemented by such well known platforms as Ruby on Rails, Apple's Cocoa and Apache Struts. Only relatively recently has Microsoft added the MVC design, building atop the .NET framework. As a result, .NET developers have the option to develop applications within the existing .NET world they already know but can eschew the lack of overall control offered by the drag & drop of Web Forms. With MVC they can embrace the same separation of concern (SOC) paradigm that has already proven to be successful in other frameworks. Admittedly, not all MVC implementations are exactly the same, with slight differences existing between the different frameworks. For example, Microsoft's implementation of MVC more closely resembles Rails and Django rather than either Apple's Cocoa or even the original implementation of MVC, Smalltalk-80.

Advantages of MVC

• Multiple Forms

  • Web forms do not allow for multiple forms on a page, whereas MVC allows for any number of forms on the page

• Similar to other established, non-Microsoft Frameworks

  • Developers with backgrounds in PHP, Ruby, or Python, will find architectural and event methodologies similarities to those implemented in MVC

• Adheres to the "stateless" nature of the web

  • One big advantage is that Session[] usage is minimized so that the URL's now become the drivers behind data maintenance. For example, because an MVC application will pass data parameters via the URL or the View binding, the potential "crutch" of using and maintaining Session[] variables is virtually eliminated.

• Test Driven Development (TDD)

  • TDD is facilitated much more easily

• Separation of Concern (SOC)

  • SOC is encouraged and easier to implement

Disadvantages of MVC

• HTML & CSS skills must be resurrected

  • Oddly, one disadvantage is that the developer needs to be fairly competent in HTML and CSS, including dynamically modifying the DOM, styles and client-side events
    • The Views are HTML structures that are written from scratch by the developer
    • Web Forms and their drag & drop controls abstract out this process to the point of automatically creating nearly all the necessary HTML needed to display what is needed, including the accompanying client-side functionality
    • MVC requires the developer to understand how the client-side code and HTML all play together, thereby ensuring consistent, controlled code

• MVC is still "relatively" new

  • There is the potential added cost of either having in-house developers learn the new MVC framework or needing to pay for outside vendors to provide the work

No one solution is an absolute better choice than the other. The application framework should be chosen based upon the needs and resources of the company doing the development. If you have a development cycle that requires faster than expected turnaround, then Web Forms might be the best option for your company. If your development project has the time, money, and energy to develop an application from the ground up then MVC could potentially be the better option. Again, neither framework is the definite best option, but one could potentially be a better for your development team structure and resources. Segue has extensive experience with both frameworks and would be more than happy to help consult on your development decisions.

7 Ways to be a Better Programmer in 2014

Great tips to help you sharpen your skills

Coders make resolutions, no? If your to-do-better list is still empty, consider these ideas from other programmers to put to use in the New Year.

1. Check Your Code First Before Looking to Blame Others
2. Continuous Learning
3. Don’t Be Afraid to Break Things
4. The Professional Programmer
5. Take Advantage of Code Analysis Tools
6. Ubuntu Coding for Your Friends
7. You Gotta Care About the Code

1. Check Your Code First Before Looking to Blame Others

Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them so too might different tools from the same vendor.
When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order.
My personal rule is that if I have a bug I can’t pin down, and I’m starting to think it’s the compiler, then it’s time to look for stack corruption. This is especially true if adding trace code makes the problem move around. Multithreaded problems are another source of bugs that turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multithreaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.
So, before you rush to blame the compiler, remember Sherlock Holmes’s advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,” and opt for it over Dirk Gently’s, “Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth.”
—Allan Kelly

2. Continuous Learning

We live in interesting times. As development gets distributed across the globe, you learn there are lots of people capable of doing your job. You need to keep learning to stay marketable. Otherwise you’ll become a dinosaur, stuck in the same job until, one day, you’ll no longer be needed or your job gets outsourced to some cheaper resource.
So what do you do about it? Some employers are generous enough to provide training to broaden your skill set. Others may not be able to spare the time or money for any training at all. To play it safe, you need to take responsibility for your own education.
Here’s a list of ways to keep you learning. Many of these can be found on the Internet for free:

• Read books, magazines, blogs, Twitter feeds, and websites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup.
• If you really want to get immersed in a technology, get hands on—write some code.
• Always try to work with a mentor, as being the top guy can hinder your education. Although you can learn something from anybody, you can learn a whole lot more from someone smarter or more experienced than you. If you can’t find a mentor, consider moving on.
• Use virtual mentors. Find authors and developers on the Web who you really like and read everything they write. Subscribe to their blogs.
• Get to know the frameworks and libraries you use. Knowing how something works makes you know how to use it better. If they’re open source, you’re really in luck. Use the debugger to step through the code to see what’s going on under the hood. You’ll get to see code written and reviewed by some really smart people.
• Whenever you make a mistake, fix a bug, or run into a problem, try to really understand what happened. It’s likely that someone else ran into the same problem and posted it on the Web. Google is really useful here.
• A good way to learn something is to teach or speak about it. When people are going to listen to you and ask you questions, you’ll be highly motivated to learn. Try a lunch-’n'-learn at work, a user group, or a local conference.
• Join or start a study group (à la patterns community) or a local user group for a language, technology, or discipline you are interested in.
• Go to conferences. And if you can’t go, many conferences put their talks online for free.
• Long commute? Listen to podcasts.
• Ever run a static analysis tool over the codebase or look at the warnings in your IDE? Understand what they’re reporting and why.
• Follow the advice of the Pragmatic Programmers* and learn a new language every year. At least learn a new technology or tool. Branching out gives you new ideas you can use in your current technology stack.
• Not everything you learn has to be about technology. Learn the domain you’re working in so you can better understand the requirements and help solve the business problem. Learning how to be more productive—how to work better—is another good option.
• Go back to school.

It would be nice to have the capability that Neo had in The Matrix, and simply
download the information we need into our brains. But we don’t, so it will take
a time commitment. You don’t have to spend every waking hour learning. A
little time—say, each week—is better than nothing. There is (or should be) a life
outside of work.
Technology changes fast. Don’t get left behind.
—Clint Shank

3. Don’t Be Afraid to Break Things

Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder’s goal is to change as little as possible, and hold his breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster. The reason that making changes is so nerve-racking is because the system is sick. It needs a doctor, otherwise its condition will only worsen. You already know what is wrong with your system, but you are afraid of breaking the eggs to make your omelet. A skilled surgeon knows that cuts have to be made in order to operate, but she also knows that the cuts are temporary and will heal. The end result of the operation is worth the initial pain, and the patient should heal to a better state than he was in before the surgery.
Don’t be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the lifecycle of your project. An added benefit is that your team’s experience dealing with the sick system makes you all experts in knowing how it should work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend his time. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in “one big shebang” will cause enough problems to make you consider abandoning the whole effort midway through.
Be the surgeon who isn’t afraid to cut out the sick parts to make room for healing. The attitude is contagious and will inspire others to start working on those cleanup projects they’ve been putting off. Keep a “hygiene” list of tasks that the team feels are worthwhile for the general good of the project. Convince management that even though these tasks may not produce visible results, they will reduce expenses and expedite future releases. Never stop caring about the general “health” of the code.
—Mike Lewis

4. The Professional Programmer

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.
If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up to date with the industry and the technology. Too many programmers feel that it is their employer’s job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up to date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: your employer promises to pay you, and you promise to do a good job.
Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find nothing because they don’t release their code until they’ve thoroughly tested it. Of course, QA will find some problems, because no one is perfect. But as professionals, our attitude must be that we will leave nothing for QA to find.
Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help one another, teach one another, learn from one another, and even cover for one another when necessary. When one teammate falls down, the others step in, knowing that one day they’ll be the ones to need cover.
Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue-tracking database are tragedies of carelessness. Indeed, in most projects, the very need for an issue-tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them.
Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed-upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say, “I’ll go back and fix this later”? Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism?
Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.
—Robert C. Martin (Uncle Bob)

5. Take Advantage of Code Analysis Tools

The value of testing is something that is drummed into software developers from the early stages of their programming journey. In recent years, the rise of unit testing, test-driven development, and agile methods has attested to a surge of interest in making the most of testing throughout all phases of the development cycle. However, testing is just one of many tools that you can use to improve the quality of code.
Back in the mists of time, when C was still a new phenomenon, CPU time and storage of any kind were at a premium. The first C compilers were mindful of this and so cut down on the number of passes through the code they made by removing some semantic analyses. This meant that the compiler checked for only a small subset of the bugs that could be detected at compile time. To compensate, Stephen Johnson wrote a tool called lint—which removes the fluff from your code—that implemented some of the static analyses that had been removed from its sister C compiler. Static analysis tools, however, gained a reputation for giving large numbers of false-positive warnings and warnings about stylistic conventions that aren’t always necessary to follow.
The current landscape of languages, compilers, and static analysis tools is very different. Memory and CPU time are now relatively cheap, so compilers can afford to check for more errors. Almost every language boasts at least one tool that checks for violations of style guides, common gotchas, and sometimes cunning errors that can be hard to catch, such as potential null pointer dereferences. The more sophisticated tools, such as Splint for C or Pylint for Python, are configurable, meaning that you can choose which errors and warnings the tool emits with a configuration file, via command-line switches, or in your IDE. Splint will even let you annotate your code in comments to give it better hints about how your program works.
If all else fails, and you find yourself looking for simple bugs or standards violations that are not caught by your compiler, IDE, or lint tools, then you can always roll your own static checker. This is not as difficult as it might sound. Most languages, particularly ones branded dynamic, expose their abstract syntax tree and compiler tools as part of their standard library. It is well worth getting to know the dusty corners of standard libraries that are used by the development team of the language you are using, as these often contain hid-den gems that are useful for static analysis and dynamic testing. For example, the Python standard library contains a disassembler which tells you the bytecode used to generate some compiled code or code object. This sounds like an obscure tool for compiler writers on the python-dev team, but it is actually surprisingly useful in everyday situations. One thing this library can disassemble is your last stack trace, giving you feedback on exactly which bytecode instruction threw the last uncaught exception.
So, don’t let testing be the end of your quality assurance—take advantage of analysis tools, and don’t be afraid to roll your own.
—Sarah Mount

6. Ubuntu Coding for Your Friends

So often, we write code in isolation and that code reflects our personal interpretation of a problem, as well as a very personalized solution. We may be part of the team, yet we are isolated, as is the team. We forget all too easily that this code created in isolation will be executed, used, extended, and relied upon by others. It is easy to overlook the social side of software creation. Creating software is a technical exercise mixed into a social exercise. We just need to lift our heads more often to realize that we are not working in isolation, and we have shared responsibility for increasing the probability of success for everyone, not just the development team.
You can write good-quality code in isolation, all the while lost in self. From one perspective, that is an egocentric approach (not ego as in arrogant, but ego as in personal). It is also a Zen view and it is about you, in that moment of creating code. I always try to live in the moment because it helps me get closer to good quality, but then I live in my moment. What about the moment of my team? Is my moment the same as the team’s moment?
In Zulu, the philosophy of Ubuntu is summed up as “Umuntu ngumuntu ngabantu,” which roughly translates to “A person is a person through (other) persons.” I get better because you make me better through your good actions. The flip side is that you get worse at what you do when I am bad at what I do. Among developers, we can narrow it down to “A developer is a developer through (other) developers.” If we take it down to the metal, then “Code is code through (other) code.”
The quality of the code I write affects the quality of the code you write. What if my code is of poor quality? Even if you write very clean code, it is at the points where you use my code that your code quality will degrade to close to the quality of my code. You can apply many patterns and techniques to limit the damage, but the damage has already been done. I have caused you to do more than what you needed to do, simply because I did not think about you when I was living in my moment.
I may consider my code to be clean, but I can still make it better just by Ubuntu coding. What does Ubuntu code look like? It looks just like good, clean code. It is not about the code, the artifact. It is about the act of creating that artifact. Coding for your friends, with Ubuntu, will help your team live your values and reinforce your principles. The next person that touches your code, in whatever way, will be a better person and a better developer.
Zen is about the individual. Ubuntu is about Zen for a group of people. Very, very rarely do we create code for ourselves alone.
—Aslam Khan

7. You Gotta Care About the Code

It doesn’t take Sherlock Holmes to work out that good programmers write good code. Bad programmers…don’t. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer.
Good code doesn’t pop out of thin air. It isn’t something that happens by luck when the planets align. To get good code, you have to work at it. Hard. And you’ll only get good code if you actually care about good code.
Good programming is not born from mere technical competence. I’ve seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It’s painful to read, painful to use, and painful to modify. I’ve seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with.
Based on my years of experience in the software factory, I’ve concluded that the real difference between adequate programmers and great programmers is this: attitude. Good programming lies in taking a professional approach, and wanting to write the best software you can, within the real-world constraints and pressures of the software factory.
The code to hell is paved with good intentions. To be an excellent programmer, you have to rise above good intentions, and actually care about the code—foster positive perspectives and develop healthy attitudes. Great code is carefully crafted by master artisans, not thoughtlessly hacked out by sloppy programmers or erected mysteriously by self-professed coding gurus.
—Pete Goodliffe

Wishing you all the best in 2014.

What is a hacker?

A hacker is someone who likes to tinker with electronics or computer systems. Hackers like to explore and learn how computer systems work, finding ways to make them do what they do better, or do things they weren’t intended to do. There are two types of hackers:

White Hat – These are considered the good guys. White hat hackers don’t use their skills for illegal purposes. They usually become Computer Security experts and help protect people from the Black Hats.

Black Hat – These are considered the bad guys. Black hat hackers usually use their skills maliciously for personal gain. They are the people that hack banks, steal credit cards, and deface websites.
These two terms came from the old western movies where the good guys wore white hats and the bad guys wore black hats.

Now if you’re thinking, “Oh boy! Being a black hat sounds awesome!”, Then I have a question for you. Does it sound cool to live in a cell the size of your bathroom and be someone’s butt buddy for many years? That’s what I thought.


Hacker Hierarchy

Script kiddies – These are the wannabe hackers. They are looked down upon in the hacker community because they are the people that make hackers look bad. Script kiddies usually have no hacking skills and use the tools developed by other hackers without any knowledge of what’s happening behind the scenes.

Intermediate hackers – These people usually know about computers, networks, and have enough programming knowledge to understand relatively what a script might do, but like the script kiddies they use pre-developed well-known exploits (- a piece of code that takes advantage of a bug or vulnerability in a piece of software that allows you to take control of a computer system) to carry out attacks

Elite Hackers – These are the skilled hackers. They are the ones that write the many hacker tools and exploits out there. They can break into systems and hide their tracks or make it look like someone else did it. You should strive to eventually reach this level.

Note:- so which hacker do you like to become pls comment...

How to remove a shortcut virus from a pendrive without Antivirus?

How to remove a shortcut virus from a pendrive without Antivirus?

press window+R ->

In RUN type -> cmd -> ok -> command prompt will open

In command prompt type command are as follow[ type drive letter of pen drive i.e replace h:\ with your pen drive letter]

-> Press Enter
After that You can recover your data.from your pen drive

Is it important to put comments within your code ? Why & How.

The primary goal of including comments in your code is to make the code + comments self-documenting enough that a developer other than the original author can understand what the code does and how it does it.

Guidelines for well commented code include:

• Wherever possible, the code should “self document”:
  • Meaningful names for variables and methods
  • Consistent layout
  • Modularized code — each method performs a single task
  • Minimize nesting, where possible
• Write effective comments:
  • Don’t just repeat what the code does
  • Use a comment to summarize a block of code that follows the comment, providing a high-level description of what the code does
  • Describe what and why, rather than how.  The code describes how and sometimes what.  Comments add to the what and also talk about why.
  • Modify comments when you modify code, if appropriate (i.e. keep the comments current)
  • Don’t comment tricky code–rewrite the code
  • Write for humans

This Video Shows How to Auto Complete a text box field in Asp.net

What is WiMAX ?

WiMAX is one of the hottest broadband wireless technologies around today. WiMAX systems are expected to deliver broadband access services to residential and enterprise customers in an economical way.
Loosely, WiMax is a standardized wireless version of Ethernet intended primarily as an alternative to wire technologies (such as Cable Modems, DSL and T1/E1 links) to provide broadband access to customer premises.
More strictly, WiMAX is an industry trade organization formed by leading communications, component and equipment companies to promote and certify compatibility and interoperability of broadband wireless access equipment that conforms to the IEEE 802.16 and ETSI HIPERMAN standards.
WiMAX would operate similar to WiFi but at higher speeds over greater distances and for a greater number of users. WiMAX has the ability to provide service even in areas that are difficult for wired infrastructure to reach and the ability to overcome the physical limitations of traditional wired infrastructure.
WiMAX was formed in April 2001, in anticipation of the publication of the original 10-66 GHz IEEE 802.16 specifications. WiMAX is to 802.16 as the WiFi Alliance is to 802.11.
WiMAX is:

• Acronym for Worldwide Interoperability for Microwave Access.
  
• Based on Wireless MAN technology.
  
• A wireless technology optimized for the delivery of IP centric services over a wide area.
  
• A scaleable wireless platform for constructing alternative and complementary broadband networks.
  
• A certification that denotes interoperability of equipment built to the IEEE 802.16 or compatible standard. The IEEE 802.16 Working Group develops standards that address two types of usage models:
  
  • A fixed usage model (IEEE 802.16-2004).
  • A portable usage model (IEEE 802.16e).

What is 802.16a ?

WiMAX is such an easy term that people tend to use it for the 802.16 standards and technology themselves, although strictly it applies only to systems that meet specific conformance criteria laid down by the WiMAX Forum.
The 802.16a standard for 2-11 GHz is a wireless metropolitan area network (MAN) technology that will provide broadband wireless connectivity to Fixed, Portable and Nomadic devices.
It can be used to connect 802.11 hot spots to the Internet, provide campus connectivity, and provide a wireless alternative to cable and DSL for last mile broadband access.

WiMax Speed and Range:

WiMAX is expected to offer initially up to about 40 Mbps capacity per wireless channel for both fixed and portable applications, depending on the particular technical configuration chosen, enough to support hundreds of businesses with T-1 speed connectivity and thousands of residences with DSL speed connectivity. WiMAX can support voice and video as well as Internet data.
WiMax will be to provide wireless broadband access to buildings, either in competition to existing wired networks or alone in currently unserved rural or thinly populated areas. It can also be used to connect WLAN hotspots to the Internet. WiMAX is also intended to provide broadband connectivity to mobile devices. It would not be as fast as in these fixed applications, but expectations are for about 15 Mbps capacity in a 3 km cell coverage area.
With WiMAX users could really cut free from today's Internet access arrangements and be able to go online at broadband speeds, almost wherever they like from within a MetroZone.
WiMAX could potentially be deployed in a variety of spectrum bands: 2.3GHz, 2.5GHz, 3.5GHz, and 5.8GHz

Why WiMax ?

• WiMAX can satisfy a variety of access needs. Potential applications include extending broadband capabilities to bring them closer to subscribers, filling gaps in cable, DSL and T1 services, WiFi and cellular backhaul, providing last-100 meter access from fibre to the curb and giving service providers another cost-effective option for supporting broadband services.
  
• WiMAX can support very high bandwidth solutions where large spectrum deployments (i.e. >10 MHz) are desired using existing infrastructure keeping costs down while delivering the bandwidth needed to support a full range of high-value multimedia services.
  
• WiMAX can help service providers meet many of the challenges they face due to increasing customer demands without discarding their existing infrastructure investments because it has the ability to seamlessly interoperate across various network types.
  
• WiMAX can provide wide area coverage and quality of service capabilities for applications ranging from real-time delay-sensitive voice-over-IP (VoIP) to real-time streaming video and non-real-time downloads, ensuring that subscribers obtain the performance they expect for all types of communications.
  
• WiMAX, which is an IP-based wireless broadband technology, can be integrated into both wide-area third-generation (3G) mobile and wireless and wireline networks allowing it to become part of a seamless anytime, anywhere broadband access solution.

Ultimately, WiMAX is intended to serve as the next step in the evolution of 3G mobile phones, via a potential combination of WiMAX and CDMA standards called 4G.

WiMAX Goals:

A standard by itself is not enough to enable mass adoption. WiMAX has stepped forward to help solve barriers to adoption, such as interoperability and cost of deployment. WiMAX will help ignite the wireless MAN industry by defining and conducting interoperability testing and labeling vendor systems with a "WiMAX Certified™" label once testing has been completed successfully.