by PHPACADEMY (YouTube - )
Create a search engine for any purpose. This search engine can be implemented anywhere to search your website content, or to search pages on the web.
Sphere: Related Content
Mostrando entradas con la etiqueta programming. Mostrar todas las entradas
Mostrando entradas con la etiqueta programming. Mostrar todas las entradas
25/2/11
PHP Tutorials: Create a Search Engine
0
comentarios
Etiquetas:
ask,
files,
find,
for,
google,
jeeves,
local,
php,
programming,
search engine,
tutorials,
url,
yahoo
29/11/10
10 mistakes every programmer makes
Admit it, you've made mistakes like these…
By Julian M Bucknall
When you start programming, you get disillusioned quickly. No longer is the computer the allinfallible perfect machine – "do as I mean, not as I say" becomes a frequent cry.
At night, when the blasted hobgoblins finally go to bed, you lie there and ruminate on the errors you made that day, and they're worse than any horror movie. So when the editor of PC Plus asked me to write this article, I reacted with both fear and knowing obedience.
I was confident that I could dash this off in a couple of hours and nip down to the pub without the usual resultant night terrors. The problem with such a request is, well, which language are we talking about?
I can't just trot out the top 10 mistakes you could make in C#, Delphi, JavaScript or whatever – somehow my top ten list has to encompass every language. Suddenly, the task seemed more difficult. The hobgoblins started cackling in my head. Nevertheless, here goes…
1. Writing for the compiler, not for people
When they use a compiler to create their applications, people tend to forget that the verbose grammar and syntax required to make programming easier is tossed aside in the process of converting prose to machine code.
A compiler doesn't care if you use a single-letter identifier or a more human-readable one. The compiler doesn't care if you write optimised expressions or whether you envelop sub-expressions with parentheses. It takes your human-readable code, parses it into abstract syntax trees and converts those trees into machine code, or some kind of intermediate language. Your names are by then history.
So why not use more readable or semantically significant identifiers than just i, j or x? These days, the extra time you would spend waiting for the compiler to complete translating longer identifiers is minuscule. However, the much-reduced time it takes you or another programmer to read your source code when the code is expressly written to be self-explanatory, to be more easily understandable, is quite remarkable.
Another similar point: you may have memorised the operator precedence to such a level that you can omit needless parentheses in your expressions, but consider the next programmer to look at your code. Does he? Will he know the precedence of operators in some other language better than this one and thereby misread your code and make invalid assumptions about how it works?
Personally, I assume that everyone knows that multiplication (or division) is done before addition and subtraction, but that's about it. Anything else in an expression and I throw in parentheses to make sure that I'm writing what I intend to write, and that other people will read what I intended to say.
The compiler just doesn't care. Studies have shown that the proportion of some code's lifecycle spent being maintained is easily five times more than was spent initially writing it. It makes sense to write your code for someone else to read and understand.
2. Writing big routines
Back when I was starting out, there was a rule of thumb where I worked that routines should never be longer than one printed page of fan-fold paper – and that included the comment box at the top that was fashionable back then. Since then, and especially in the past few years, methods tend to be much smaller – merely a few lines of code.
In essence, just enough code that you can grasp its significance and understand it in a short time. Long methods are frowned upon and tend to be broken up.
The reason is extremely simple: long methods are hard to understand and therefore hard to maintain. They're also hard to test properly. If you consider that testing is a function of the number of possible paths through a method, the longer the method, the more tests you'll have to write and the more involved those tests will have to be.
There's actually a pretty good measurement you can make of your code that indicates how complex it is, and therefore how probable it is to have bugs – the cyclomatic complexity.
Developed by Thomas J. McCabe Sr in 1976, cyclomatic complexity has a big equation linked to it if you're going to run through it properly, but there's an easy, basic method you can use on the fly. Just count the number of 'if' statements and loops in your code. Add 1 and this is the CC value of the method.
It's a rough count of the number of execution paths through the code. If your method has a value greater than 10, I'd recommend you rewrite it.
3. Premature optimisation
This one's simple. When we write code, sometimes we have a niggling devil on our shoulder pointing out that this clever code would be a bit faster than the code you just wrote. Ignore the fact that the clever code is harder to read or harder to comprehend; you're shaving off milliseconds from this loop. This is known as premature optimisation.
The famous computer scientist Donald Knuth said, "We should forget about small efficiencies, say about 97 per cent of the time: premature optimisation is the root of all evil."
In other words: write your code clearly and cleanly, then profile to find out where the real bottlenecks are and optimise them. Don't try to guess beforehand.
4. Using global variables
Back when I started, lots of languages had no concept of local variables at all and so I was forced to use global variables. Subroutines were available and encouraged but you couldn't declare a variable just for use within that routine – you had to use one that was visible from all your code. Still, they're so enticing, you almost feel as if you're being green and environmentally conscious by using them. You only declare them once, and use them all over the place, so it seems you're saving all that precious memory.
But it's that "using all over the place" that trips you up. The great thing about global variables is that they're visible everywhere. This is also the worst thing about global variables: you have no way of controlling who changes it or when the variable is accessed. Assume a global has a particular value before a call to a routine and it may be different after you get control back and you don't notice.
Of course, once people had worked out that globals were bad, something came along with a different name that was really a global variable in a different guise. This was the singleton, an object that's supposed to represent something of which there can only be one in a given program.
A classic example, perhaps, is an object that contains information about your program's window, its position on the screen, its size, its caption and the like. The main problem with the singleton object is testability. Because they are global objects, they're created when first used, and destroyed only when the program itself terminates. This persistence makes them extremely difficult to test.
Later tests will be written implicitly assuming that previous tests have been run, which set up the internal state of the singleton. Another problem is that a singleton is a complex global object, a reference to which is passed around your program's code. Your code is now dependent on some other class.
Worse than that, it's coupled to that singleton. In testing, you would have to use that singleton. Your tests would then become dependent on its state, much as the problem you had in testing the singleton in the first place. So, don't use globals and avoid singletons.
5. Not making estimates
You're just about to write an application. You're so excited about it that you just go ahead and start designing and writing it. You release and suddenly you're beset with performance issues, or out-of-memory problems.
Further investigations show that, although your design works well with small number of users, or records, or items, it does not scale – think of the early days of Twitter for a good example. Or it works great on your super-duper developer 3GHz PC with 8GB of RAM and an SSD, but on a run-of-the-mill PC, it's slower than a Greenland glacier in January.
Part of your design process should have been some estimates, some back-back-of- the-envelope calculations. How many simultaneous users are you going to cater for? How many records? What response time are you targeting?
Try to provide estimates to these types of questions and you'll be able to make further decisions about techniques you can build into your application, such as different algorithms or caching. Don't run pell-mell into development – take some time to estimate your goals.
6. Off by one
This mistake is made by everyone, regularly, all the time. It's writing a loop with an index in such a way that the index incremented once too often or once too little. Consequently, the loop is traversed an incorrect number of times.
If the code in the loop is visiting elements of an array one by one, a non-existent element of the array may be accessed – or, worse, written to – or an element may be missed altogether. One reason why you might get an off-by one error is forgetting whether indexes for array elements are zero-based or one-based.
Some languages even have cases where some object is zero-based and others where the assumption is one-based. There are so many variants of this kind of error that modern languages or their runtimes have features such as 'foreach loops' to avoid the need to count through elements of an array or list.
Others use functional programming techniques called map, reduce and filter to avoid the need to iterate over collections. Use modern 'functional' loops rather than iterative loops.
7. Suppressing exceptions
Modern languages use an exception system as an error-reporting technique, rather than the old traditional passing and checking of error numbers. The language incorporates new keywords to dispatch and trap exceptions, using names such as throw, try, finally and catch.
The remarkable thing about exceptions is their ability to unwind the stack, automatically returning from nested routines until the exception is trapped and dealt with. No longer do you have to check for error conditions, making your code into a morass of error tests.
All in all, exceptions make for more robust software, providing that they're used properly. Catch is the interesting one: it allows you to trap an exception that was thrown and perform some kind of action based upon the type of the exception.
The biggest mistakes programmers make with exceptions are twofold. The first is that the programmer is not specific enough in the type of exception they catch. Catching too general an exception type means that they may be inadvertently dealing with particular exceptions that would be best left to other code, higher up the call chain. Those exceptions would, in effect, be suppressed and possibly lost.
The second mistake is more pernicious: the programmer doesn't want any exceptions leaving their code and so catches them all and ignores them. This is known as the empty catch block. They may think, for example, that only certain types of exceptions might be thrown in his code; ones that they could justifiably ignore.
In reality, other deadly runtime exceptions could happen – things such as out-of-memory exceptions, invalid code exceptions and the like, for which the program shouldn't continue running at all. Tune your exception catch blocks to be as specific as possible.
8. Storing secrets in plain text
A long time ago, I worked in a bank. We purchased a new computer system for the back office to manage some kind of workflow dealing with bond settlements. Part of my job was to check this system to see whether it worked as described and whether it was foolproof. After all, it dealt with millions of pounds daily and then, as now, a company is more likely to be defrauded by an employee than an outsider.
After 15 minutes with a rudimentary hex editor, I'd found the administrator's password stored in plain text. Data security is one of those topics that deserves more coverage than I can justifiably provide here, but you should never, ever store passwords in plain text.
The standard for passwords is to store the salted hash of the original password, and then do the same salting and hashing of an entered password to see if they match.
Here's a handy hint: if a website promises to email you your original password should you forget it, walk away from the site. This is a huge security issue. One day that site will be hacked. You'll read about how many logins were compromised, and you'll swallow hard and feel the panic rising. Don't be one of the people whose information has been compromised and, equally, don't store passwords or other 'secrets' in plain text in your apps.
9. Not validating user input
In the good old days, our programs were run by individuals, one at a time. We grew complacent about user input: after all, if the program crashed, only one person would be inconvenienced – the one user of the program at that time. Our input validation was limited to number validation, or date checking, or other kinds of verification of input.
Text input tended not to be validated particularly. Then came the web. Suddenly your program is being used all over the world and you've lost that connection with the user. Malicious users could be entering data into your program with the express intent of trying to take over your application or your servers.
A whole crop of devious new attacks were devised that took advantage of the lack of checking of user input. The most famous one is SQL injection, although unsanitised user input could precipitate an XSS attack (crosssite scripting) through markup injection.
Both types rely on the user providing, as part of normal form input, some text that contains either SQL or HTML fragments. If the application does not validate the user input, it may just use it as is and either cause some hacked SQl to execute, or some hacked HTML/JavaScript to be produced.
This in turn could crash the app or allow it to be taken over by the hacker. So, always assume the user is a hacker trying to crash or take over your application and validate or sanitise user input.
10. Not being up to date
All of the previous mistakes have been covered in depth online and in various books. I haven't discovered anything new – they and others have been known for years. These days you have to work pretty hard to avoid coming into contact with various modern design and programming techniques.
I'd say that not spending enough time becoming knowledgeable about programming – and maintaining that expertise – is in fact the biggest mistake that programmers make. They should be learning about techniques such as TDD or BDD, about what SLAP or SOLID means, about various agile techniques.
These skills are of equal or greater importance than understanding how a loop is written in your language of choice. So don't be like them: read McConnell and Beck and Martin and Jeffries and the Gang of Four and Fowler and Hunt & Thomas and so on. Make sure you stay up to date with the art and practice of programming.
And that concludes my top 10 list of mistakes programmers make, no matter what their language stripe. There are others, to be sure, perhaps more disastrous than mine, but I would say that their degree of dread is proportional to the consequences of making them.
All of the above were pretty dire for me the last time I made them. If you have further suggestions or calamities of your own, don't hesitate to contact me and let me know.
-------------------------------------------------------------------------------------------------------
First published in PC Plus Issue 300 Sphere: Related Content
By Julian M Bucknall
When you start programming, you get disillusioned quickly. No longer is the computer the allinfallible perfect machine – "do as I mean, not as I say" becomes a frequent cry.
At night, when the blasted hobgoblins finally go to bed, you lie there and ruminate on the errors you made that day, and they're worse than any horror movie. So when the editor of PC Plus asked me to write this article, I reacted with both fear and knowing obedience.
I was confident that I could dash this off in a couple of hours and nip down to the pub without the usual resultant night terrors. The problem with such a request is, well, which language are we talking about?
I can't just trot out the top 10 mistakes you could make in C#, Delphi, JavaScript or whatever – somehow my top ten list has to encompass every language. Suddenly, the task seemed more difficult. The hobgoblins started cackling in my head. Nevertheless, here goes…
1. Writing for the compiler, not for people
When they use a compiler to create their applications, people tend to forget that the verbose grammar and syntax required to make programming easier is tossed aside in the process of converting prose to machine code.
A compiler doesn't care if you use a single-letter identifier or a more human-readable one. The compiler doesn't care if you write optimised expressions or whether you envelop sub-expressions with parentheses. It takes your human-readable code, parses it into abstract syntax trees and converts those trees into machine code, or some kind of intermediate language. Your names are by then history.
So why not use more readable or semantically significant identifiers than just i, j or x? These days, the extra time you would spend waiting for the compiler to complete translating longer identifiers is minuscule. However, the much-reduced time it takes you or another programmer to read your source code when the code is expressly written to be self-explanatory, to be more easily understandable, is quite remarkable.
Another similar point: you may have memorised the operator precedence to such a level that you can omit needless parentheses in your expressions, but consider the next programmer to look at your code. Does he? Will he know the precedence of operators in some other language better than this one and thereby misread your code and make invalid assumptions about how it works?
Personally, I assume that everyone knows that multiplication (or division) is done before addition and subtraction, but that's about it. Anything else in an expression and I throw in parentheses to make sure that I'm writing what I intend to write, and that other people will read what I intended to say.
The compiler just doesn't care. Studies have shown that the proportion of some code's lifecycle spent being maintained is easily five times more than was spent initially writing it. It makes sense to write your code for someone else to read and understand.
2. Writing big routines
Back when I was starting out, there was a rule of thumb where I worked that routines should never be longer than one printed page of fan-fold paper – and that included the comment box at the top that was fashionable back then. Since then, and especially in the past few years, methods tend to be much smaller – merely a few lines of code.
In essence, just enough code that you can grasp its significance and understand it in a short time. Long methods are frowned upon and tend to be broken up.
The reason is extremely simple: long methods are hard to understand and therefore hard to maintain. They're also hard to test properly. If you consider that testing is a function of the number of possible paths through a method, the longer the method, the more tests you'll have to write and the more involved those tests will have to be.
There's actually a pretty good measurement you can make of your code that indicates how complex it is, and therefore how probable it is to have bugs – the cyclomatic complexity.
Developed by Thomas J. McCabe Sr in 1976, cyclomatic complexity has a big equation linked to it if you're going to run through it properly, but there's an easy, basic method you can use on the fly. Just count the number of 'if' statements and loops in your code. Add 1 and this is the CC value of the method.
It's a rough count of the number of execution paths through the code. If your method has a value greater than 10, I'd recommend you rewrite it.
3. Premature optimisation
This one's simple. When we write code, sometimes we have a niggling devil on our shoulder pointing out that this clever code would be a bit faster than the code you just wrote. Ignore the fact that the clever code is harder to read or harder to comprehend; you're shaving off milliseconds from this loop. This is known as premature optimisation.
The famous computer scientist Donald Knuth said, "We should forget about small efficiencies, say about 97 per cent of the time: premature optimisation is the root of all evil."
In other words: write your code clearly and cleanly, then profile to find out where the real bottlenecks are and optimise them. Don't try to guess beforehand.
4. Using global variables
Back when I started, lots of languages had no concept of local variables at all and so I was forced to use global variables. Subroutines were available and encouraged but you couldn't declare a variable just for use within that routine – you had to use one that was visible from all your code. Still, they're so enticing, you almost feel as if you're being green and environmentally conscious by using them. You only declare them once, and use them all over the place, so it seems you're saving all that precious memory.
But it's that "using all over the place" that trips you up. The great thing about global variables is that they're visible everywhere. This is also the worst thing about global variables: you have no way of controlling who changes it or when the variable is accessed. Assume a global has a particular value before a call to a routine and it may be different after you get control back and you don't notice.
Of course, once people had worked out that globals were bad, something came along with a different name that was really a global variable in a different guise. This was the singleton, an object that's supposed to represent something of which there can only be one in a given program.
A classic example, perhaps, is an object that contains information about your program's window, its position on the screen, its size, its caption and the like. The main problem with the singleton object is testability. Because they are global objects, they're created when first used, and destroyed only when the program itself terminates. This persistence makes them extremely difficult to test.
Later tests will be written implicitly assuming that previous tests have been run, which set up the internal state of the singleton. Another problem is that a singleton is a complex global object, a reference to which is passed around your program's code. Your code is now dependent on some other class.
Worse than that, it's coupled to that singleton. In testing, you would have to use that singleton. Your tests would then become dependent on its state, much as the problem you had in testing the singleton in the first place. So, don't use globals and avoid singletons.
5. Not making estimates
You're just about to write an application. You're so excited about it that you just go ahead and start designing and writing it. You release and suddenly you're beset with performance issues, or out-of-memory problems.
Further investigations show that, although your design works well with small number of users, or records, or items, it does not scale – think of the early days of Twitter for a good example. Or it works great on your super-duper developer 3GHz PC with 8GB of RAM and an SSD, but on a run-of-the-mill PC, it's slower than a Greenland glacier in January.
Part of your design process should have been some estimates, some back-back-of- the-envelope calculations. How many simultaneous users are you going to cater for? How many records? What response time are you targeting?
Try to provide estimates to these types of questions and you'll be able to make further decisions about techniques you can build into your application, such as different algorithms or caching. Don't run pell-mell into development – take some time to estimate your goals.
6. Off by one
This mistake is made by everyone, regularly, all the time. It's writing a loop with an index in such a way that the index incremented once too often or once too little. Consequently, the loop is traversed an incorrect number of times.
If the code in the loop is visiting elements of an array one by one, a non-existent element of the array may be accessed – or, worse, written to – or an element may be missed altogether. One reason why you might get an off-by one error is forgetting whether indexes for array elements are zero-based or one-based.
Some languages even have cases where some object is zero-based and others where the assumption is one-based. There are so many variants of this kind of error that modern languages or their runtimes have features such as 'foreach loops' to avoid the need to count through elements of an array or list.
Others use functional programming techniques called map, reduce and filter to avoid the need to iterate over collections. Use modern 'functional' loops rather than iterative loops.
7. Suppressing exceptions
Modern languages use an exception system as an error-reporting technique, rather than the old traditional passing and checking of error numbers. The language incorporates new keywords to dispatch and trap exceptions, using names such as throw, try, finally and catch.
The remarkable thing about exceptions is their ability to unwind the stack, automatically returning from nested routines until the exception is trapped and dealt with. No longer do you have to check for error conditions, making your code into a morass of error tests.
All in all, exceptions make for more robust software, providing that they're used properly. Catch is the interesting one: it allows you to trap an exception that was thrown and perform some kind of action based upon the type of the exception.
The biggest mistakes programmers make with exceptions are twofold. The first is that the programmer is not specific enough in the type of exception they catch. Catching too general an exception type means that they may be inadvertently dealing with particular exceptions that would be best left to other code, higher up the call chain. Those exceptions would, in effect, be suppressed and possibly lost.
The second mistake is more pernicious: the programmer doesn't want any exceptions leaving their code and so catches them all and ignores them. This is known as the empty catch block. They may think, for example, that only certain types of exceptions might be thrown in his code; ones that they could justifiably ignore.
In reality, other deadly runtime exceptions could happen – things such as out-of-memory exceptions, invalid code exceptions and the like, for which the program shouldn't continue running at all. Tune your exception catch blocks to be as specific as possible.
8. Storing secrets in plain text
A long time ago, I worked in a bank. We purchased a new computer system for the back office to manage some kind of workflow dealing with bond settlements. Part of my job was to check this system to see whether it worked as described and whether it was foolproof. After all, it dealt with millions of pounds daily and then, as now, a company is more likely to be defrauded by an employee than an outsider.
After 15 minutes with a rudimentary hex editor, I'd found the administrator's password stored in plain text. Data security is one of those topics that deserves more coverage than I can justifiably provide here, but you should never, ever store passwords in plain text.
The standard for passwords is to store the salted hash of the original password, and then do the same salting and hashing of an entered password to see if they match.
Here's a handy hint: if a website promises to email you your original password should you forget it, walk away from the site. This is a huge security issue. One day that site will be hacked. You'll read about how many logins were compromised, and you'll swallow hard and feel the panic rising. Don't be one of the people whose information has been compromised and, equally, don't store passwords or other 'secrets' in plain text in your apps.
9. Not validating user input
In the good old days, our programs were run by individuals, one at a time. We grew complacent about user input: after all, if the program crashed, only one person would be inconvenienced – the one user of the program at that time. Our input validation was limited to number validation, or date checking, or other kinds of verification of input.
Text input tended not to be validated particularly. Then came the web. Suddenly your program is being used all over the world and you've lost that connection with the user. Malicious users could be entering data into your program with the express intent of trying to take over your application or your servers.
A whole crop of devious new attacks were devised that took advantage of the lack of checking of user input. The most famous one is SQL injection, although unsanitised user input could precipitate an XSS attack (crosssite scripting) through markup injection.
Both types rely on the user providing, as part of normal form input, some text that contains either SQL or HTML fragments. If the application does not validate the user input, it may just use it as is and either cause some hacked SQl to execute, or some hacked HTML/JavaScript to be produced.
This in turn could crash the app or allow it to be taken over by the hacker. So, always assume the user is a hacker trying to crash or take over your application and validate or sanitise user input.
10. Not being up to date
All of the previous mistakes have been covered in depth online and in various books. I haven't discovered anything new – they and others have been known for years. These days you have to work pretty hard to avoid coming into contact with various modern design and programming techniques.
I'd say that not spending enough time becoming knowledgeable about programming – and maintaining that expertise – is in fact the biggest mistake that programmers make. They should be learning about techniques such as TDD or BDD, about what SLAP or SOLID means, about various agile techniques.
These skills are of equal or greater importance than understanding how a loop is written in your language of choice. So don't be like them: read McConnell and Beck and Martin and Jeffries and the Gang of Four and Fowler and Hunt & Thomas and so on. Make sure you stay up to date with the art and practice of programming.
And that concludes my top 10 list of mistakes programmers make, no matter what their language stripe. There are others, to be sure, perhaps more disastrous than mine, but I would say that their degree of dread is proportional to the consequences of making them.
All of the above were pretty dire for me the last time I made them. If you have further suggestions or calamities of your own, don't hesitate to contact me and let me know.
-------------------------------------------------------------------------------------------------------
First published in PC Plus Issue 300 Sphere: Related Content
6/6/10
Other Voices: An HTML5 Primer
By Michael Mullany, June 03, 2010
It's easy to get lost in the welter of HTML5-related standards
With Google and Apple strongly supporting HTML5 as the solution for rich applications for the Internet, it's become the buzzword of the month -- particularly after Google I/O. Given its hot currency, though, it's not surprising that the term is starting to become unhinged from reality. Already, we're starting to see job postings requiring "HTML5 experience," and people pointing to everything from simple JavaScript animations to CSS3 effects as examples of HTML5. Just as "AJAX" and "Web 2.0" became handy (and widely misused) shorthand for "next-generation" web development in the mid-2000's, HTML5 is now becoming the next overloaded term. And although there are many excellent resources out there describing details of HTML5, including the core specification itself, they are generally technical and many of them are now out of synch with the current state of the specs. So, I thought a primer on HTML5 might be in order.
HTML5 Core vs. The HTML5 Family
When many folks say "HTML5" (particularly when this is followed with "will replace Flash"), they mean (or at least I think they mean), the broad collection of next-generation technologies that are now being implemented in the Webkit-based browsers (Safari and Chrome), Opera and Firefox. Some of these (like CS S3) were never part of the HTML5 standards process, and some of these (like web workers) were originally part of the spec but were spun out separately. We think the right way to refer to this collection is "the HTML5 Family." The family members of HTML5 (like all families) are in very different stages of maturity and implementation. Some are fully implemented in latest revision browsers, some may never see the light of day, and some will become altered beyond recognition before they show up in the mainstream. As mentioned before, the core W3C HTML5 spec is just one part of the collection of related technologies. I list the following specs as members of the HTML5 Family (more or less):
•The HTML5 spec
•Cascading Style Sheets Version 3 (CSS3)
•Web Workers
•Web Storage
•Web SQL Database
•Web Sockets
•Geolocation
•Microdata
•Device API and File API
The Core HTML5 Spec
The central thrust of the core HTML5 spec is to evolve HTML from the XML-centric approach of the early 2000's that had poor traction among browser makers and developers. HTML5 substantially changes many aspects of the language, although most changes have not resulted in new features visible to most end-users. These "user-invisible" changes include a new content model, accessibility features and browsing contexts. In many cases, HTML5 allows what is currently done with styling, JavaScript or server workarounds to be done in HTML. This results in cleaner, human-readable HTML. Today's blizzard of div tags is replaced with meaningful markup like nav and aside. For example, HTML5 adds semantic tags for common content elements: One specific example is a special form field for email addresses. Another specific example is new markup for menus and navigation sections. For forms, HTML5 adds support for PUT and DELETE form actions, which will simplify server side processing. It also provides native support for adding form elements dynamically, which currently has to be done in JavaScript.
For users, the highest impact change in HTML5 is the addition of audio and video tags and a standard 2D bitmap drawing format (canvas). HTML5 audio and video tags allow playback without the use of plugins, and Canvas allows rich 2D bitmapped graphics.
There are many other features in the HTML5 spec, including a drag-and-drop API, cross-document messaging, persistent content caching directives, and user-editable content. Support for them is still being added to the latest browser revisions. Some parts may still end up being discarded before final implementation.
Finally, HTML5 removes many presentational markup elements that littered earlier HTML specs, like center and font. It also disallows direct table styling, and instead, requires the use of CSS. Frames are also officially eliminated.
CSS3
A lot of what people think is HTML5, is actually CSS3, which is itself a collection of sub-specifications. These are in various states of completion and browser implementation. For example, CSS Animations and CSS Transitions are sub-specs that provide rich dynamic 2D animations and effects for elements. CSS 3D and 2D Transformations provide animations for boxed content. The CSS3 spec family also includes standards for richer layout control, borders and backgrounds (the highly desired "rounded corners" ). It also includes more niche capabilities such as Ruby (not the language, Ruby with a small "r" means visual hints for meaning or pronunciation often used in ideogram based languages), aural style sheets and scrolling marquees.
Web Workers
Web Workers let an application spawn tasks for the browser to work on in the background without freezing the execution of the main application. There are a few types of workers that can be created with slightly different behavior. The intent of web workers is to give application developers the ability to specify what tasks within the application are parallelizeable (in the small), so that the browser can better schedule work for the rapidly increasing core count of today's (and tomorrow's) multi-core processors.
Web Storage and Web SQL
Web Storage is one of the more exciting parts of the HTML5 Family. Web Storage allows a page to store string data in a key-value pair database, specific to that domain. There are two varieties of Web Storage, the first is sessionStorage, that persists data only for a single session (think of it as a more functional cookie storage mechanism). The second is localStorage which allows a domain to store data locally across browser sessions (and system reboots). When you add localStorage to the cache manifest from the main HTML5 spec, you have the ability to run an offline application. The Web Storage spec is itself separate from the Web SQL Database spec which provides for a full SQL-addressable database that is accessible offline. Although varieties of this spec are in implementation by browser makers, the standardization process is blocking on the need for a second interoperable implementation that is not based on SQLite (which all the current versions are.)
Web Sockets
The Web Sockets protocol is in the first stage of the standards process and has also been submitted as an IETF draft because it is a networking protocol. It defines a non-http-based asynchronous client/server protocol that can be used in place of the current AJAX methods for asynchronous server communication. It uses an initial http: request to bootstrap the new protocol.
And all the others…
Geolocation is a simple spec that provides a built-in a geolocation object that scripts can query. It also provides methods for defining location cache freshness requirements. This is fairly non-controversial and already in new browsers. File API allows single and multiple file uploads from the user desktop. It's unclear exactly who will support this, but there doesn't seem to be much confusion about what it's supposed to do. Microdata is a mechanism to allow communities of interest to mark up content with semantic tags (for example, tags that identify an address or a resume.) It doesn't specify what these semantic tags are, just how they should be implemented. Device APIs that allow web browser access to devices such as cameras, BlueTooth etc, are still an early work in progress. These hope to define standardized access to native hardware and sensitive data from web applications. Highest priority are a camera API, and APIs for contact list, SMS history etc. on mobile devices. From Google I/O it appears that Google is going to ship something sooner rather than later that allows camera access from a Chrome web application, but there have been no further details on this.
HTML5 Summed Up
It's easy to get lost in the welter of standards enumerated above. But stepping back you should get the sense that the HTML5 Family authors are on a mission to make web applications as powerful as native applications when it comes to user interface richness, offline capability and hardware access. Since HTML5 family apps will be deployed on the web, they'll have the added benefits that the web has always brought, which are:
• A universal client that works cross platform
• Easy searchability and indexing (including deep linking)
• The ability to trivially include third party services and mashups
• Zero hassle deployment and updating (after all, it's just on the web)
We're excited by our initial HTML5-based development, and we eagerly await these new features as they are implemented and stabilized in the latest browsers.
Recomended links about HTML5 Book: Deploying HTML5 Sphere: Related Content
It's easy to get lost in the welter of HTML5-related standards
With Google and Apple strongly supporting HTML5 as the solution for rich applications for the Internet, it's become the buzzword of the month -- particularly after Google I/O. Given its hot currency, though, it's not surprising that the term is starting to become unhinged from reality. Already, we're starting to see job postings requiring "HTML5 experience," and people pointing to everything from simple JavaScript animations to CSS3 effects as examples of HTML5. Just as "AJAX" and "Web 2.0" became handy (and widely misused) shorthand for "next-generation" web development in the mid-2000's, HTML5 is now becoming the next overloaded term. And although there are many excellent resources out there describing details of HTML5, including the core specification itself, they are generally technical and many of them are now out of synch with the current state of the specs. So, I thought a primer on HTML5 might be in order.
HTML5 Core vs. The HTML5 Family
When many folks say "HTML5" (particularly when this is followed with "will replace Flash"), they mean (or at least I think they mean), the broad collection of next-generation technologies that are now being implemented in the Webkit-based browsers (Safari and Chrome), Opera and Firefox. Some of these (like CS S3) were never part of the HTML5 standards process, and some of these (like web workers) were originally part of the spec but were spun out separately. We think the right way to refer to this collection is "the HTML5 Family." The family members of HTML5 (like all families) are in very different stages of maturity and implementation. Some are fully implemented in latest revision browsers, some may never see the light of day, and some will become altered beyond recognition before they show up in the mainstream. As mentioned before, the core W3C HTML5 spec is just one part of the collection of related technologies. I list the following specs as members of the HTML5 Family (more or less):
•The HTML5 spec
•Cascading Style Sheets Version 3 (CSS3)
•Web Workers
•Web Storage
•Web SQL Database
•Web Sockets
•Geolocation
•Microdata
•Device API and File API
The Core HTML5 Spec
The central thrust of the core HTML5 spec is to evolve HTML from the XML-centric approach of the early 2000's that had poor traction among browser makers and developers. HTML5 substantially changes many aspects of the language, although most changes have not resulted in new features visible to most end-users. These "user-invisible" changes include a new content model, accessibility features and browsing contexts. In many cases, HTML5 allows what is currently done with styling, JavaScript or server workarounds to be done in HTML. This results in cleaner, human-readable HTML. Today's blizzard of div tags is replaced with meaningful markup like nav and aside. For example, HTML5 adds semantic tags for common content elements: One specific example is a special form field for email addresses. Another specific example is new markup for menus and navigation sections. For forms, HTML5 adds support for PUT and DELETE form actions, which will simplify server side processing. It also provides native support for adding form elements dynamically, which currently has to be done in JavaScript.
For users, the highest impact change in HTML5 is the addition of audio and video tags and a standard 2D bitmap drawing format (canvas). HTML5 audio and video tags allow playback without the use of plugins, and Canvas allows rich 2D bitmapped graphics.
There are many other features in the HTML5 spec, including a drag-and-drop API, cross-document messaging, persistent content caching directives, and user-editable content. Support for them is still being added to the latest browser revisions. Some parts may still end up being discarded before final implementation.
Finally, HTML5 removes many presentational markup elements that littered earlier HTML specs, like center and font. It also disallows direct table styling, and instead, requires the use of CSS. Frames are also officially eliminated.
CSS3
A lot of what people think is HTML5, is actually CSS3, which is itself a collection of sub-specifications. These are in various states of completion and browser implementation. For example, CSS Animations and CSS Transitions are sub-specs that provide rich dynamic 2D animations and effects for elements. CSS 3D and 2D Transformations provide animations for boxed content. The CSS3 spec family also includes standards for richer layout control, borders and backgrounds (the highly desired "rounded corners" ). It also includes more niche capabilities such as Ruby (not the language, Ruby with a small "r" means visual hints for meaning or pronunciation often used in ideogram based languages), aural style sheets and scrolling marquees.
Web Workers
Web Workers let an application spawn tasks for the browser to work on in the background without freezing the execution of the main application. There are a few types of workers that can be created with slightly different behavior. The intent of web workers is to give application developers the ability to specify what tasks within the application are parallelizeable (in the small), so that the browser can better schedule work for the rapidly increasing core count of today's (and tomorrow's) multi-core processors.
Web Storage and Web SQL
Web Storage is one of the more exciting parts of the HTML5 Family. Web Storage allows a page to store string data in a key-value pair database, specific to that domain. There are two varieties of Web Storage, the first is sessionStorage, that persists data only for a single session (think of it as a more functional cookie storage mechanism). The second is localStorage which allows a domain to store data locally across browser sessions (and system reboots). When you add localStorage to the cache manifest from the main HTML5 spec, you have the ability to run an offline application. The Web Storage spec is itself separate from the Web SQL Database spec which provides for a full SQL-addressable database that is accessible offline. Although varieties of this spec are in implementation by browser makers, the standardization process is blocking on the need for a second interoperable implementation that is not based on SQLite (which all the current versions are.)
Web Sockets
The Web Sockets protocol is in the first stage of the standards process and has also been submitted as an IETF draft because it is a networking protocol. It defines a non-http-based asynchronous client/server protocol that can be used in place of the current AJAX methods for asynchronous server communication. It uses an initial http: request to bootstrap the new protocol.
And all the others…
Geolocation is a simple spec that provides a built-in a geolocation object that scripts can query. It also provides methods for defining location cache freshness requirements. This is fairly non-controversial and already in new browsers. File API allows single and multiple file uploads from the user desktop. It's unclear exactly who will support this, but there doesn't seem to be much confusion about what it's supposed to do. Microdata is a mechanism to allow communities of interest to mark up content with semantic tags (for example, tags that identify an address or a resume.) It doesn't specify what these semantic tags are, just how they should be implemented. Device APIs that allow web browser access to devices such as cameras, BlueTooth etc, are still an early work in progress. These hope to define standardized access to native hardware and sensitive data from web applications. Highest priority are a camera API, and APIs for contact list, SMS history etc. on mobile devices. From Google I/O it appears that Google is going to ship something sooner rather than later that allows camera access from a Chrome web application, but there have been no further details on this.
HTML5 Summed Up
It's easy to get lost in the welter of standards enumerated above. But stepping back you should get the sense that the HTML5 Family authors are on a mission to make web applications as powerful as native applications when it comes to user interface richness, offline capability and hardware access. Since HTML5 family apps will be deployed on the web, they'll have the added benefits that the web has always brought, which are:
• A universal client that works cross platform
• Easy searchability and indexing (including deep linking)
• The ability to trivially include third party services and mashups
• Zero hassle deployment and updating (after all, it's just on the web)
We're excited by our initial HTML5-based development, and we eagerly await these new features as they are implemented and stabilized in the latest browsers.
Recomended links about HTML5 Book: Deploying HTML5 Sphere: Related Content
22/4/10
10 momentos importantes en la historia de la Informática
Por: Federico Reggiani @ miércoles, 23 de septiembre de 2009
Comentarios:
Esto me recuerda un documental muy bueno que vi, habla de la evolución de INTERNET, de como empezo y el porque. Tiene unas bases muy buenas, muchas de ellas no habia oído hablar, pero despues de buscarlo lo corrobore. A mí me gusto, ¿Y a vosotros?
http://www.youtube.com/watch?v=FGxDIh7OLno Sphere: Related Content
1) 1959 - COBOL
Para muchos COBOL es el lenguaje de programación más importante de la historia. Muchos lenguajes actuales están basados en él (Pascal, BASIC, etc.). La prueba más grande que ha superado es la del tiempo, dado que todavía hoy hay miles de ordenadores corriendo aplicaciones COBOL, 50 años después. No es que COBOL haga cosas que otros OS no pueden hacer, pero es que trabaja lo suficientemente bien como para no tener que actualizarlo.
2)1969 – ARPANET
Arpanet es, nada menos, que la red que está detrás de Internet. Fue concebida con fines científicos y hoy terminó siendo el medio de comunicación más importante. Sin dudas, ARPANET cambió nuestras vidas.
3) 1970 – UNIX
No digo Linux, digo UNIX. Este sistema operativo abrió la puerta a cosas como el uso de ordenadores por varias personas (Multi-user). Esto es algo normal hoy en día, pero no lo era en esos tiempos. Esto no solo se refiere a la clave que pones para que tu familia no vea la clase de “películas” que ves, sino que es la base para los sistemas de seguridad que permiten que usemos email, Facebook, Tuenti, etc.
4) 1976 – Apple I
Apple I fue el primer ordenador que lanzó Apple. Pero fue también el primero de uso personal que se haya fabricado. Con él nacen las “Personal Computers”, antes los ordenadores solo eran para universidades y científicos. Pero Steve Jobs había visto un futuro mucho más prometedor y democrático para los ordenadores.
WordStar
5) 1978 – WordStar
¿Usar un ordenador para tareas hogareñas o de pequeñas oficinas? Wordstar nació para CP/M (el D.O.S. original que Microsoft compró) en 1978. Luego lanzó su versión 3.0 para D.O.S en 1982. WordStar abrió las puertas a una nueva etapa para la informática. ¡Ya no era solo para científicos! Además, ayudó a muchos de nosotros a terminar la escuela gracias a trabajos preciosamente terminados, que luego imprimíamos con nuestra impresora de puntos.
6) 1978 – BBS
Los BBS fueron los primeros sistemas en darnos una actividad social en red. Podíamos enviar emails, ver ficheros que otros dejaban para que veamos, compartir imágenes, software, etc. Fueron el principio de lo que hoy hacemos con Internet, o al menos el principio de las redes sociales actuales.
7) 1983 – Microsoft Mouse
Microsoft no inventó el mouse (o ratón), lo compraron hecho (¿de dónde me suena esto?). Sin embargo, ha sido la culpable de que el uso de este dispositivo sea masivo. Usar un ratón en el año 83 era ciencia ficción. ¿Mover una flecha en la pantalla con la mano? ¡Una locura!
8) 1991 – Linux
Con Linux no solo nace un sistema operativo, nace también una revolución. Así como Apple revolucionó el mundo con el lanzamiento de un producto “científico” para las masas, Linus Torvalds hizo lo suyo al lanzar un producto que antes solo hacían grandes corporaciones. Todos sabemos el provecho que saca Microsoft a Windows, ellos dominaban la informática, decidían quién podía usar un ordenador y quién no. Gracias a Linus ahora todos podemos tener un sistema operativo abierto y gratuito. Con ventajas o no, pero lo que Linux provocó es innegable.
Sir Tim Berners-Lee
9) 1992 – WWW
Tim Berners-Lee inventó la Web. A Tim se le ocurrió nada menos que inventar el Hipertexto, o HTML. Imagina por un momento Internet sin la Web. Es difícil porque la Internet que nos viene a la cabeza SIEMPRE incluye la Web. Claro que el chat y el email también son Internet, pero la Web es determinante en nuestras vidas. Alguna vez Tim dijo que “si hubiese sabido que el HTML se iba a transformar en Amazon, lo hubiera patentado”. Un grande. Robert Cailliau también participó, fue el único que le prestó atención cuando Berners-Lee presentó los primeros bocetos de la Web. Un dato: la WWW se creó en el mismo sitio que el LHC, el CERN de Suiza.
10) 1998 – Google
El dominio fue registrado en 1997, pero Google vio la luz en 1998. No solo veo en Google el buscador, sino también la empresa que está detrás de miles de servicios y productos. Desde Gmail a AdSense. Pasando por un largo etcétera. Sin dudas la creación de Google es muy importante en esta historia. Sobre todo por la especulación de lo que le queda aún por hacer.
Luego hubieron cosas como el P2P, Facebook y cloud computing. Lo que sucede es que todavía no tenemos bien en claro qué es lo que van a ofrecer, que sea realmente determinante en la historia de la informática y que no termine solo en lo comercial.
Quedan muchas cosas fuera. Cosas como: C y los lenguajes modernos, Fortran, Windows 95, Seti@Home y el principio de la nube, Apple Lisa (el primero con Interfaz Gráfica), Apple Newton precursora de las Palm, iPhones y SmartPhones actuales, la primera portátil. Vemos muchas menciones a temas relacionados a Internet, pero es que es el acontecimiento más importante junto con el primer ordenador personal.
También quedo fuera la venta de D.O.S. a IBM, que abrió las puertas a los ordenadores compatibles que permitieron bajadas de precio notables haciendo más popular el uso de PC en nuestros hogares.
¿Te parece que falta algo?
¡Claro! ¡Windows y D.O.S.!
No están en la lista porque a pesar de haber sido enormes éxitos comerciales, y haber realmente cambiado la historia, no fueron los primeros en hacer lo que hacen. Cuando saló Google ya existía Yahoo, vale, pero Google nunca funcionó como Yahoo. Yahoo era actualizado pro personas, y Google fue el primero en hacer un crawler automático.
Los que leen mis escasas notas pueden ver que no soy un Linuxero ni un Apple fanboy (aunque uso Linux y tengo un iPhone).
Pero de verdad me parece que Windows y D.O.S. fueron algo que terminó por suceder por la evolución de otras cosas.
Comentarios:
Esto me recuerda un documental muy bueno que vi, habla de la evolución de INTERNET, de como empezo y el porque. Tiene unas bases muy buenas, muchas de ellas no habia oído hablar, pero despues de buscarlo lo corrobore. A mí me gusto, ¿Y a vosotros?
http://www.youtube.com/watch?v=FGxDIh7OLno Sphere: Related Content
Suscribirse a:
Entradas (Atom)
+18.20.50.png)
Blinklist.com
