Thank you 😊
Top sites to follow for techies and web geek.
Here are the list of coolest site that a tech geek should visit.
Interactive mind maps.
List of Died Startup.
You can find email address related domain.
For Latest technology
Collection of tools
For new Startups, WebApp, AI, Bots and gadget related Stuff.
Try it 😉
List of API
Wanna vanish from Internet try it.
About Futuristic Technology.
About technology and computer science.
For learners and Developers
Platform to ask questions and connect to people.
Best place to learn web development.
For Gadget lovers.
Command prompt tricks
Command Prompt is a command line interpreter application available in most Windows operating systems.It is a input field in a text-based user interface screen for an operating system or program.It is also called Windows Command Processor but is also sometimes called the command shell or cmd prompt, or even referred to by its filename cmd.exe.
cmd is easy to use and you can perform many operations in it.Here are top tricks you must know. Before knowing the tricks lets see how to open cmd in windows 10.
1.Go to search the web and windows
2.Enter cmd and select it.
Now lets see some usefull cmd tricks.
1.Change the name of title bar.
You can give any title to cmd just give the command title and with it any title you want to give.
Ex:- >title xyz
2.Copying text in cmd.
You can’t copy paste by right clicking and then selecting copy paste this feature is not present in cmd.
a)First select the text
b)Then use keyboard shortcuts CTRL+C(copy) and CTRL+V(paste).
3.Opening command prompt inside a folder.
Suppose you want to execute a file in a folder what you will do is change the directory from command prompt well there is a trick that you can directly open command prompt inside a folder.
- Go to desired folder.
- Hold shift and right click and you will see an option open command window here click it and your are done.
4.Change the Looks.
Bored with default looks you can customize command prompt.
5.Check ip address.
You can find/check ip address of any website using command prompt just give the command nslookup xyz.com.
6.See PC drivers list.
You can see all the drivers that is installed in your system just give the command driverquery.
7.Scanning System files.
You can scan the system files using command prompt.It will scan and repair the files.Just type sfc/scannow.Scanning speed depends on your system speed.
Turn your browser into Notepad.
Notepad is a simple text editor for Microsoft Windows and a basic text-editing program which enables computer users to create documents.We all need notepad to note down the things which we wanna use later but somethings while surfing net you found something you don’t need to save you just want to note it down . So here is the trick to turn your browser into notepad with simple one line code.
here is the code:-
data:text/html, <html contenteditable>
Just copy the code and paste it in browser’s URL bar and you are done!!!
A mobile phone that performs many of the functions of a computer, typically having a touchscreen interface, Internet access, and an operating system capable of running downloaded apps is known as smartphones. The world is going crazy about smartphones and in present scenario approx. 2.32 billion people use it. There are many such things about smartphones that most population doesn’t have the knowledge. Here you will find such tricks of smartphones that will helpful and will reduce your effort.
1.Extend battery life with low power mode.
If your phone is running on iOS9, go to Settings > Battery > Low Power Mode. By going into Low Power Mode, non-essential tasks are disabled, giving you up to FOUR more hours of battery life.
2.Back-up your data.
Sync and store all your important photos, media, contacts, and even text messages. Even in case you delete a photo or you reset your phone you can still recover all your important data.
3.Aeroplane mode for speed charging.
Everyone wants their phone to charge quickly ,by putting it in aeroplane mode your mobile phone will charge quickly as it will use less battery life.
4.Click pictures with volume button.
You can take photos using the volume buttons whilst in the camera phone.
Sometimes we want to save the screen as it appears taking screen in smartphones is very easy though you can do it using various apps available on playstore but it can be done easily you just need to press two buttons same time i.e. power and volume down .
7.Download web images.
If you’ve seen one of those funny photographs on the internet, long-pressing on it lets you download it to your phone – and it’ll pop up in your Gallery for easy sharing.
8.Multiple Gmail accounts.
Android added support for multiple Gmail accounts. Add a new internet identity to your phone by opening the Gmail app, then pressing Menu > Accounts > Add Accounts.
9.Custom caller tone.
If you like talking to people, the same screen lets you allocate a specific custom ringtone to each caller stored in your Contacts directory.
10.Here are top 10 android codes that you can use.
- To display IMEI Number *#06#
- To display RAM Memory version *#*#3264#*#*
- To display FTA SW version *#*#1111#*#*
- To display FTA HW version *#*#2222#*#*
- To display Touchscreen version *#*#2663#*#*
- To test Bluetooth *#*#232331#*#*
- To test secret GPS *#*#1472365#*#*
- To launch Service Mode *#*#197328640#*#*
- To Restore Factory Settings #*#7780#*#*
- To Format phone *2767*3855#
11.Enable Developer Mode.
Navigate to Settings > About phone and tap on your phone’s build number seven times.A message will pop up saying “Congratulations, you are now a developer”.
You can play games on your mobile by downloading but there is a hidden game that you can enjoy just go Settings > About phone and tap the device’s version number several times.Enjoy the game.
13.Plug mouse and keyboard to your phone.
You can plug mouse and keyboard to your device and use it like PC.
Like Share :))
All Type of Calculators.(online)
Really an amazing site for all who are having problem in any sort of calculation . All you need is
In this site variety of online calculators are available .
Hidden games in Google.
Feeling bored try this games on Google that are hidden .
1. T-Rex Run.
When you see there is no internet connection or unable to connect to the internet you can play this game called T-Rex Run.
The custom Pac-Man game appeared as a Google “doodle” on May 21, 2010. You can play it just Google pac-man
To access this classic, type “Atari Breakout” into Google’s Image Search.
4. Zerg Rush
Search “Zerg Rush” in Google and prepare yourself .
To play, punch in “Google Snake Game,” and click on the top result.
Happy Gaming 🎮
Like Share Subscribe
Avoid these 35 habbits that lead to unmaintainable code.
Bad habits are hard to break and even harder if you don’t realize that what you’re doing is undermining your work. If you know but don’t care—that would be the worst. But you’re here, aren’t you?
As a programmer, I’ve seen a lot of poor practices, not just around code, but also around teamwork skills. I’ve been guilty of practicing many of these bad habits myself. Here are my top 35 bad programming habits, organized into four categories: code organization, teamwork, writing code, and testing and maintenance.
1. Saying “I’ll fix it later”, and never doing it
The habit of postponing code fixes is not merely a problem of priorities. Organizing your issue tracker might generate some progress, but you also need to have a way of tracking smaller issues that come up. Adding “TODO” comments is a quick way of making sure you don’t miss anything.
2. Insisting on a one-liner solution
Being obsessive about writing efficient, elegant pieces of code is a common trait of programmers. It’s like solving a puzzle—you find a combination of functions and regular expressions that turn 20 code lines into 2 or 3. Unfortunately, it doesn’t always result in readable code, and that’s generally the far more important outcome. Make your code accessible first, then clever.
3. Making pointless optimizations
Another place where we often misplace our efforts is optimizations. It sounds great to reduce the size of your website a few bytes, but won’t gzip make up for it anyway? And aren’t requests more important? Address optimizations at the end of a project, because more often than not, requirements will change, and your time will have been wasted.
“Premature optimization is the root of all evil.” —Donald Knuth
4. Convincing yourself that styling issues are not that important
If I’ve learned anything over years of looking at other people’s code, it’s that dealing with coding style issues is the thing that developers are most likely to postpone. Maybe it’s hard for inexperienced coders to see what good will come out of addressing styling issues, but over time it will become evident that once code quality derails, a snowball effect will turn any project into a complete mess. Be strict about best practices even if they seem negligible. Set up code checking and linting tools to give yourself space to worry about the more important things.
5. Sweeping things under the rug
Either by catching and ignoring exceptions, or by using libraries that don’t report errors (such as jQuery), there are many ways to sweep things under the rug. But when one of those errors becomes a priority, the challenge of fixing it will be many times greater, considering that you won’t have a clue where to begin. An easy way to avert this is by logging those ignored errors so you can study them later.
6. Using names that don’t add information
Naming is hard, but there’s an easy way to make sure your variable and function names are at least of decent quality. So long as the names add some kind of information that the rest of the code doesn’t convey, other developers will have an easier time reading your code. The reason that naming is so important is that names can give a general idea of what the code does. It takes more time if you need to dig into the calculations to figure out what piece of code does, but a good name can help you understand what the code does in seconds.
7. Ignoring proven best practices
Code reviews, test-driven development, quality assurance, deployment automation—these practices, and several others, have proved their value in countless projects, which is why developers blog about them constantly. A great reference for these best practices is the book Making Software: What Really Works, and Why We Believe It. Take the time to learn how to do them properly, and your development process will improve in all of your projects in ways that will surprise you.
8. Abandoning plans too early
A sure-fire way for making your system inscrutable is to not commit to a plan. You can always say, whenever your code is criticized, that the plan isn’t complete. However, having half-done modules will lead to tightly coupled code as soon as you try to make those unfinished modules work with each other. This kind of complication also comes up when a project’s leadership roles change and the new leads decide that having it their way is more important than architectural consistency.
9. Insisting on a plan that has little chance of working
Just as abandoning your plans can cause problems, so can sticking to a plan that doesn’t work. That’s why you should share your ideas with your team to get feedback and advice when things get tricky. Sometimes a different perspective can make all the difference.
10. Working on your own all the time
You should strive to share your progress and ideas with the team. Sometimes you think you’re building something the right way, but you’re not, so constant communication is very valuable. It’s also beneficial for other people when you work with them. Their work often improves when you discuss ideas with them and mentor the less experienced members of your team, who are more likely to get stuck.
11. Refusing to write bad code
There comes a time in every developer’s life when deadlines will force you to write terrible code, and that’s okay. You’ve tried warning your client or manager about the consequences, but they insist on sticking to the deadline, so now it’s time to code. Or perhaps there’s an urgent bug that can’t wait for you to come up with a clean solution. That’s why it’s important to be versatile as a programmer and to be able to write poor code very quickly as well as good code. Hopefully, you can revisit the code and pay back the technical debt.
12. Blaming others
It’s no secret that arrogance is an all-too-common trait among developers and other technical professionals. Taking responsibility for your mistakes is a virtue that will make you shine among your peers. Don’t be afraid to admit that you’ve made a mistake. Once you’re okay with that, you will be free to focus on learning why you made that mistake and how to avoid it. If you don’t own up to it, learning becomes impossible.
13. Not sharing with your team what you’ve learned
Your value as a developer is not only placed on the code you write, but also on what you learn when writing it. Share your experiences, write comments about it, let others know why things are the way they are, and help them learn new things about the project and its intricacies.
14. Being too slow on giving feedback to managers/clients
One of the most valuable character traits of any craftsman lies in making sure that everyone is on the same page about the work, as much as possible. The reason for this is not so that your manager call fill spreadsheets. It’s for your own gain as well: You will have fewer insecurities and reduce uncertainty about the lifetime and future of the project.
15. Not using Google enough
The best way of solving a complex problem quickly is not having to solve it at all. When in doubt, Google it. Of course, you can bother the engineer next to you instead, but rarely will he be able to give a response as detailed as Stack Overflow, not to mention that you’ll be interrupting his work as well.
16. Overvaluing your personal style
Always aim to coordinate your working style and environment setup with your team. Ideally, everyone on your team should be working under similar conditions and following the same coding style. Doing things your way can be more fun, but co-workers might not be used to your coding style, and if it’s unusual, it will be harder for the next developer to work on what you’ve built.
17. Having a personal attachment to your code
When someone comments on your code, don’t take it personally. Your code should stand on solid ground; that is, you should be able to explain why you wrote it that way. If it needs improvement, that’s only a reflection of the code’s correctness, not of yourself.
18. Not knowing how to optimize
A good optimization strategy takes some experience to get right. It takes exploration, analysis, and knowing every system involved in a process. Inform yourself about these things. Learn about algorithmic complexity, database query evaluation, protocols, and how to measure performance in general.
19. Using the wrong tool for the job
You can only know so much, but the reason why you have to keep learning is that each new problem brings a different context and requires a different tool—one more applicable to the task at hand. Be open to new libraries and languages. Don’t make decisions based strictly on what you know.
20. Not bothering with mastering your tools and IDE
Each new hotkey, shortcut, or parameter you learn while using the tools you work with every day will have a more positive effect on your coding speed than you realize. It’s not about saving a few seconds by using a hotkey; it’s about reducing the context switching. The more time you spend on each small action, the less time you’ll have available to think about why you’re doing it and about what comes next. Mastering shortcuts will free your mind.
21. Ignoring error messages
Don’t assume that you know what’s wrong with your code without even reading an error message, or that you’ll figure it out quickly enough. Having more information about a problem is always better, and taking the time to gather that information will save more time in the long run.
22. Romanticizing your developer toolkit
Sometimes your preferred editor or command line tool isn’t the the best tool for the job at hand. Visual Studio is great for writing IDEs, Sublime is great for dynamic languages, Eclipse is great for Java, and so on. You might love vim or emacs, but that doesn’t mean that it’s the right tool for every job.
23. Hardcoding values instead of making them configurable
Always be thinking about what changes might come and how to deal with them. Technical debt will grow at a monstrous rate if you don’t separate the moving pieces from the rest of your work. Use constants and configuration files where appropriate.
24. Reinventing the wheel all the time
Don’t write code you don’t need to. Perhaps someone else has spent a good deal of time on your problem already, and he or she might have a well-tested solution that you can reuse. Save yourself some trouble.
25. Blindly copy/pasting code
Understand code before you reuse it. Sometimes you don’t immediately notice everything the code is doing on first glance. You will also learn more about a problem when you take the time to read the code in detail.
26. Not taking the time to learn how things really work
Always take the opportunity to expand your knowledge by thinking about how things work and reading about their underlying issues. You might save time by not bothering right now, but what you learn on a project will be more important in the long term than actually getting it done.
27. Having excessive confidence in your own code
It’s dangerous to assume that just because you wrote something, it must be great. You learn more about programming as you work on new things and gain experience, so take a look at your old code from time to time and reflect on how you’ve progressed.
28. Not thinking about the trade-offs of each design, solution, or library
Every product has its fine points that you’ll only learn about by using and analyzing it. Seeing a few usage examples for a library will not make you a master of it, nor does it mean that it’s the perfect fit for every situation that will come up in your project. Be continually critical of everything you use.
29. Not getting help when you’re stuck
Keeping a short feedback loop will always be less painful for you. Asking for help doesn’t mean that you’re incompetent. The right people will see your effort and admission of ignorance as a drive to learn, and that’s a great virtue to have.
Testing and maintenance
30. Writing tests to pass
Writing tests that you know will pass is necessary. They will make refactoring and reorganizing a project much safer. On the other hand, you also have to write tests that you know won’t pass. They are necessary to move the project forward and keep track of issues.
31. Disregarding performance testing for critical cases
Prepare an automated performance testing setup at about the middle point of a project’s development process so you can make sure you don’t have escalating performance problems.
32. Not checking that your build works
It’s rare when a build passes but doesn’t really work, but it can happen, and it might be troublesome to fix the problem the longer you wait to look into it. Quickly testing every build is an important habit to have.
33. Pushing large changes late, or leaving after making a large push
This is where overconfidence will get you, and it can take getting burned multiple times to learn why you shouldn’t do this, so take my advice now and make sure you are always there when your build eventually breaks.
34. Disowning code you wrote
Be willing to support code you wrote. You are the most suitable person for helping others understand it. You should strive to make your code remain readable to yourself and others many years from now.
35. Ignoring the nonfunctional requirements
When you’re trying to deliver something, it can be easy to forget about some important areas such as performance and security. Keep a checklist for those. You don’t want them ruining your party because you drew up your deadlines without thinking about these nonfunctional concerns.
What are your worst programming habits?
As it’s often said, we are creatures of habit. Improving the way you work through habits is a great way to avoid having to think too much about every single situation. Once you’ve assimilated a good way of doing something, it becomes effortless.
Note: this post was originally featured on TechBeacon.
About Version Control
What is “version control”, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
Local Version Control Systems
Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
One of the more popular VCS tools was a system called RCS, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the
rcs command when you install the Developer Tools. RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
Centralized Version Control Systems
The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.
This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything – the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem – whenever you have the entire history of the project in a single place, you risk losing everything.
Distributed Version Control Systems
This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.
Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
ASCII( American Standard Code for Information Interchange)
ASCII abbreviated from American Standard Code for Information Interchange, is a character encoding standard (the Internet Assigned Numbers Authority (IANA) prefers the name US-ASCII). ASCII codes represent text in computers, telecommunications equipment, and other devices. Most modern character-encoding schemes are based on ASCII, although they support many additional characters.
ASCII was developed from telegraph code. Its first commercial use was as a seven-bit teleprinter code promoted by Bell data services. Work on the ASCII standard began on October 6, 1960, with the first meeting of the American Standards Association’s (ASA) (now the American National Standards Institute or ANSI) X3.2 subcommittee. The first edition of the standard was published in 1963, underwent a major revision during 1967, and experienced its most recent update during 1986. Compared to earlier telegraph codes, the proposed Bell code and ASCII were both ordered for more convenient sorting (i.e., alphabetization) of lists, and added features for devices other than teleprinters.
Originally based on the English alphabet, ASCII encodes 128 specified characters into seven-bit integers as shown by the ASCII chart above. The characters encoded are numbers 0 to 9, lowercase letters a to z, uppercase letters A to Z, basic punctuation symbols, control codes that originated with Teletype machines, and a space. For example, lowercase j would become binary 1101010 and decimal 106. ASCII includes definitions for 128 characters: 33 are non-printing control characters (many now obsolete) that affect how text and space are processed and 95 printable characters, including the space (which is considered an invisible graphic).
A June 1992 RFC and the Internet Assigned Numbers Authority registry of character sets recognize the following case-insensitive aliases for ASCII as suitable for use on the Internet: ANSI_X3.4-1968 (canonical name), iso-ir-6, ANSI_X3.4-1986, ISO_646.irv:1991, ASCII, ISO646-US, US-ASCII (preferred MIME name), us, IBM367, cp367, and csASCII.
Of these, the IANA encourages use of the name “US-ASCII” for Internet uses of ASCII (even if it is a redundant acronym, but the US is needed because of regular confusion of the ASCII term with other 8 bit based character encoding schemes such as Extended ASCII or UTF-8 for example). One often finds this in the optional “charset” parameter in the Content-Type header of some MIME messages, in the equivalent “meta” element of some HTML documents, and in the encoding declaration part of the prologue of some XML documents.