8 Proposals To Make HTML6 Better

  The buzzword – 'HTML5', appeared a few years ago, but its standard version wasn't made final until the end of 2014. There have been several changes, HTML5 has been pushed to limits by the early adopters and it has hundreds of limitations which all of us are aware about. For Web development, we are still dependent on the age-old protocols, breaking which can effect the Web and a few websites too. Hence, speculations have begun about the next iteration of HTML, HTML6.

Well, HTML5 is still new and it's slowly making its way into the websites but HTML5 has a large room for tons of improvements. Here are eight proposals for HTML6 which can make Web development process faster, simpler and error-free too.

1. More control over video object: 

More control over how the video frames are painted has to be focused in the next iteration of HTML. In the current version, a rectangle is filled with frames from a video and control is provided over a text track with annotations, subtitles etc. But it would be better to have callback hooks and synchronisation mechanisms in HTML6 and also the capability to mix DOM with video.

2. Browser-sizing of imagery: 

A photo requires different pixels to look good on a mobile, desktop and a laptop screen. Even the resolution is different with the size of the window. If a better HTML protocol is followed, it can suggest a required width or height for the image, and also the server which can deliver the optimal resolution.

3. Pluggable languages: 

Standard HTML knows only JavaScript and nothing else. But in future a more robust and pluggable set of languages will be required which will add more flexibility and design choices for developers. A solid open source implementation can also make it get adopted by all the browsers. JavaScript will continue to reign over the Web but a specialised language for more specialised extensions will also be a healthy option.

4. Pluggable pre-processors: 

HTML6 can also embrace som tools which can convert languages into JavaScript. Pre-processors are already in use to translate languages into JavaScript. Openness has always seen benefits on the Web. Reading a JavaScript code, users can learn as well as debug, if the code is written in human-readable form. The current version of HTML assumes a general version of JavaScript and optimising the code is really tough.

5. Dedicated libraries: 

jQuery has transformed the world of JavaScript and the amount of energy wasted on loading jQuery is pretty huge. Some websites use cacheable versions of JavaScript libraries but the next HTML version can do something better than that. A dedicated approved library should be distributed with the browser and it can also save time which is invested in refreshing the cached version of jQuery.

6. Camera integration: 

Users are always interacting with such a browser which has a camera and a microphone connected, as there are so many Web cameras and cellphone cameras around. HTML6 may add a photo or a video capture feature to forms as this element can access photos which are stored in the device. The device also offers better control of the camera and websites can have better specialised apps too.

7. Better annotation: 

A better HTML structure can allow article annotations through paragraphs, sentences and words too. A sophisticated version can also allow annotations to images and videos.

8. Microformats: 

HTML tags are different in headlines, paragraphs and footers. So it's important to create a certain standard to specify some common details like parts of an address or a phone number. Standard tags can speed up search engines and will benefit all of us. Microformats were supposed to be part of HTML5 too but it didn't happen. Markups can also be used for locations, times, dates, items for sale, bibliographies, and all forms of standard data.

Courtesy: Network World 

7 Excellent Software Programs Written By Solo Programmers!

Writing code for developing a software can be done by a person alone, if pair programming is not being performed. Though most of the developers work together in a team, sometimes programmers work on an application all alone. If the programmer is genius enough then he/she can create such an impressive code which is loved a lot by others too. Here are seven such software programs which are written by one person and are quite impressive too.




1. Fabrice Bellard’s JSLinux: 

If a person gets immense recognition as one of the greatest programmers in the world, then that person usually gets motivated to create something unique, just for fun. That's how QEMU hardware emulator developer Fabrice Bellard wrote JSLinux. It's a 32-bit x86 compatible CPU which runs on Linux and it has 32MB RAM. If a programmer is smart enough like Bellard, an excellent program like JSLinux can be written in 7,000 lines of code.

2. David Horne’s 1K ZX Chess: 

Chess programmer David Horne created a version of chess which fits in the 672 bytes available. Though the programme faced some initial struggles as the screen went blank each time the computer started its next move and the game faced problems. But still, being a solo programming initiative, it was definitely an achievement.

3. Olivier Poudade’s BootChess: 

David Horne’s 1K ZX Chess maintained its position as the smallest chess program for 32 consecutive years. Then the record was broken by French programmer Olivier Poudade when he created BootChess which fits in 487 bytes, instead of Horne's Chess' 672 bytes. Poudade took three months to write the program and created over 200 versions too. Some basic chess moves went missing from this program too. But whenever the world talks about miniature chess programs we mostly remember Poudade's achievement.

4. Daniel J. Bernstein’s qmail: 

qmail was created in 1995 and it was a secure alternative to SMTP mail transfer agent Sendmail. qmail is written in C and it's less complex than Sendmail. Bugs were very rare in qmail and it's still popular on Unix systems. The last major release of code took place in 1998.

5. Chris Sawyer’s RollerCoaster Tycoon: 

Assembly language was used in coding computer games at an earlier stage. Then programmer Chris Sawyer wrote RollerCoaster Tycoon and it changed the face of computer games as assembly language was no longer required.

6. Don Knuth’s TeX: 

The author of The Art of Computer Programming, Don Knuth, was not happy with the proofs of the second edition of the second volume of his book. That's when he decided to take control in his own hands and he designed a new digital typesetting system for technical publications. Knuth wrote the initial version of TeX and he used Stanford Artificial Intelligence Language (SAIL) for the same.

7. Richard Stallman’s GNU Emacs: 

One of the creators of the original EMACS text editor, Richard Stallman, wrote started working on GNU operating system in 1983 and was looking for a version of Emacs for his Unix-like system. He started programming a free version of Emacs for GNU, based on a proprietary version of Emacs for Unix, which was created by James Gosling. The Lisp interpreter was not a part of Gosling's Emacs and that was required by Stallman mostly. Stallman wrote a new version of Emacs using C all alone including a Lisp interpreter. GNU Emacs was first released in 1985 and has been ported to several operating systems.

Courtesy: IT World 

8 White Lies Programmers Keep On Telling Themselves

 All of us keep on lying to ourselves time and again in both personal and professional lives. Some professions require such lies much more than others. Long working hours and strict deadlines are nothing new to software developers and that's why they are bound to take shelter under these white lies. ITWorld reached out to several software developers via social media platforms and also analysed developers' comments on discussion forums. Then they compiled a list of white lies which programmers usually tell themselves. Here are eight out of them:

1. No commenting required for this code: 

Programmers find commenting on a code a dragging task and they keep on finding new excuses to avoid the same. They always try to find out some valid reasons to avoid the commenting task or postpone it for later. Often they think it's impossible that their code will need a commenting and sometimes they think that code documents itself, hence no extra explanation is needed.

2. Lies about time-factor: 

Programmers often suffer from over-confidence in this case. They also delude themselves by thinking that a particular task won't take long. Developers underestimate time for something which is still pending. Basically it happens with fixes to a complicated code, which at the end of the day looks like a bigger project than a new one. These lies usually generate from desperate wish to reach home early.

3. Self-dependence: 

With the growth of open source technologies, code, tools and applications are now available for free to developers. But still they prefer to determine their own role in a particular project. Software engineers, most confidently, should be confident about their own skillset. It leads to them thinking that each code is superior to another one.

4. Future plans: 

Programmers are usually confused about what to focus on the most – to do something fast or do it right, which means whether it's more important to fix a bug efficiently or to meet the deadline. Sometimes compromises are being made to coding to save time as programmers plan to solve the bugs and imperfect code in future and this later time actually never comes. That's why, sometimes they are aware that they are writing a dirty code, still they believe they will correct it by a simple rewrite, which is not simple enough. They also keep on ignoring some bugs to save time in the short run.

5. They believe a code change to be a small one: 

When a change is made to the code to resolve a bug or add some more functionality, the smallest tweak can also become a bigger task, much bigger than expected. That's why coders tend to fool themselves by thinking that every change is small and won't consume much time, though the real picture is not the same.

6. Ignoring a bug: 

Sometimes developers avoid to acknowledge that there is some flaw in their code and it has a bug. After writing code, developers test it and at that time they find it to be perfect. They start thinking that the fault is at the users' end as they might be misunderstanding something how the software is supposed to function.

7. Skipping tests confidently: 

To create a software, testing is must, which is not at all fun. Just like writing comments, programmers tend to find excuses for not performing tests as they believe everything is fine with their code. They believe tests are mere wastage of time.

8. Over-confidence about responsibilities: 

Due to over-confidence, programmers convince themselves that they are well-aware about their duties, which is actually not the case, at least always. From this conviction, programmers become careless about work which leads to further trouble.

Courtesy: IT World 

Set up Java Environment Variables

What are the environment variables?

Environment variables are global system variables accessible by all processes running under the operating system (OS).Environment variables are useful for storing values ​​of the entire system, such as directories to search for executable programs (PATH) and the version of the operating system. Examples of environment variables in the Windows operating system are:

• COMPUTENAME, USERNAME: stores the computer name and current user.
• OS: the operating system.
• SystemRoot: the root directory of the system.
• PATH: stores a list of directories to search for executable programs.

In creating JDK and Java applications, you will find these environment variables: PATH, CLASSPATH, JAVA_HOME and JRE_HOME. In summary:

• PATH:maintains a list of directories. The operating system searches the entries path for executables, such as Java (javac) time compiler and Java (Java)     implementation programs.

• CLASSPATH: maintain a list of directories (which contain many of Java class files) and the JAR file (a single Java class file). The Java compiler and Java Runtime searches the CLASSPATH entries to the Java classes referenced in your program.

• JAVA_HOME and JRE_HOME: keep the location of JDK and JRE installed directory, respectively.

Setting the Path in windows 8

•  Assuming you have installed Java in c:Program Filesjavajdk directory
• Right-click on ‘My Computer’ and select ‘Properties’.
• Click on the ‘Environment variables’ button under the ‘Advanced’ tab.
• Now, alter the ‘Path’ variable so that it also contains the path to the Java executable. Example, if the path is currently set to ‘C:WINDOWSSYSTEM32′, then change your path to read ‘C:WINDOWSSYSTEM32;c:Program Filesjavajdkbin’.

Setting by command prompt

• Open the Command Prompt .
• Type “set Path=C:Program FilesJavajdk1.6.0_21bin” 
• Type ” set HomePath= C:Program FilesJava jdk1.6.0_21 “

How to Stop Annoying Facebook Game Requests From Friends Permanently

You probably have a handful of Facebook friends who play endless games of Mafia Wars or Farmville and consistently send you invitations to join them. Or, you may have a friend who works as an event promoter and sends you invites to events halfway across the country that clearly you won’t be attending.

Removing these invitation alerts from your account can be tedious and annoying, but there is an easy way to selectively block them.
1. Click the “Setting” button. (usually looks like a snowflakes or a gear on the top)
2. In the left side, look for “Blocking” button and click it.
3. It will then show you “Manage Blocking” page that has 5 sections listed below.
(Restricted List, Block users, Block apps invites, Block events invitations, Block apps)
(Focus only with “Block apps invites” and “Block apps”)
4. In the “Block apps invites” section, type the name of your friend who always send you games requests then hit enter and Facebook will prevent that person sending you games request.
(You’re still friends with that person as you only prevent him/her from sending you request)
5. In the “Block apps” section, type the name of the App you want to be blocked so no one could send you a game request for that particular game.

What Is Rooting And How To Do That?

what is rooting??

What’s the difference between rooting, unlocking, and flashing a ROM? Rooting, for those of you that don’t know, means giving yourself root permissions on your phone. It’s similar running programs as administrators in Windows, or running a command with sudo in Linux. With a rooted phone, you can run apps that require access to certain system settings, as well as flash custom ROMs to your phone, which add all sorts of extra features. If you’re on the fence about rooting, check out our top 10 reasons to root your Android phone for some motivation.

This can be confusing, since the three practices are often performed at the same time. We’ve detailed some of this above, but briefly: Unlocking your bootloader is usually the first step in the process and allows you to flash a custom recovery. From there, you can then give yourself root access or flash a ROM. Root access isn’t required to flash a ROM, but almost all custom ROMs will come with root access built-in.

Note that when we say “unlock” in this guide, we mean unlocking your bootloader—not unlocking your phone to use a different carrier, which is a completely different thing and doesn’t always require hacking (since you can often purchase carrier-unlocked phones directly from Google or elsewhere).

Before you root your Android phone or tablet, there are a few things you should be aware of:

Can i root my phone?

Warranty – Some manufacturers assert that rooting voids your device’s warranty. However, rooting will not actually damage your hardware. You can “unroot” your device and manufacturers won’t be able to tell if it’s been rooted.

Security – Google Wallet, in particular, has a vulnerability on rooted devices that could allow other apps to access your PIN and other wallet information. Google Wallet displays a warning message if you run it on a rooted device. If you’re one of the few people using Google Wallet for NFC payments, you may want to reconsider rooting your device.

Bricking – Rooting a device is a very safe process. However, there’s always some danger of “bricking” a device when you go outside the normal parameters and hack around with it — particularly if you’re trying to root a device or operating system version not supported by a tool. “Bricking” refers to breaking the device, making it about as useful as a brick. When you root, jailbreak, or install a custom ROM, or otherwise hack around, you do so at your own risk. It’s a good idea to do a little bit of research first and see if other people report success rooting your device.

https://www.youtube.com/watch?v=LO58RbRPgYQ