Showing posts with label Windows. Show all posts
How to install google playstore in youwave
Hello guys today i will teach you on how to install playstore in youwave through which you can download apps like whatsapp hike facebook messenger games and other collections of apps in the store.
follow the steps
Hello guys today i will teach you on how to install playstore in youwave through which you can download apps like whatsapp hike facebook messenger games and other collections of apps in the store.
follow the steps
Step 1: Open YouWave Android Player and Click on View->Online Content
Step 2: Double Click on Google Play Store icon
It Will Download Google Play Store in your YouWave Android Player.
Step 3: Download Complete and there will Google Play Store icon in the left panel of your YouWave Android Player. Click on this icon to launch the application.
Step 4: Click on this icon to launch the application.
Step 5 : Click to create or use existing Google Account. I have a Google Account so I clicked Existing account button.
Step 6: Accept the Google Play Store terms and conditions to proceed.
YOUWAVE ANDROID PLAYER LIMITATIONS
- Its not free like BlueStack. You can try YouWave for 10 days as a free trial. Also the free version doesn’t have Android ICS.
- Not all apps are compatible as you can see Instagram is not working in YouWave Android Player.
Hello guys today i will teach you how to install Google Playstore in Nokia X2 using Nokia X Tools
Download here
Supported Devices
- Nokia X
- Nokia XL
- Nokia X2
Step By Step Guide
- Enable USB Debugging Goto Settings> About Phone and tap 5 times on Software Version and you shall see Now You are a Developer. Press back once and Developer Option shall be present. Open it and enable USB Debugging.
- Download Nokia X Tools from the above link and open it on your Windows PC.
- Now type 1 in the command Window and hit Enter to install USB Drivers.
- Connect your phone to your Windows PC using data cable.
- Now type 2 to Install GOOGLE PLAY + Services and a prompt in your phone will come up please enable it to allow computer to access system files on your device. If Play Services are not installed in first attempt kindly reboot device and PC and try once again with step 2.
- After success in the above step your device will reboot and you can see Play Services on your phone. You can install Gmail and other Google Apps on your phone from Play Store easily now.
- If you need to delete Google Play Services anytime you can do so by just typing 3 instead of 2 to Remove-Google Play Services and Store.
So that was easy wasn’t it and do leave us your questions and feedback below in the comments section. If any questions are there in your mind contact via contact us form.
Developing applications can be a very stressful job. Nobody is perfect, and running into buggy code is fairly commonplace in this career. Some programmers get angry, frustrated, upset, discouraged even, while others play it cool. How we handle the process of fixing bugs is worthy of scrutiny.
I want to share a collection of phrases and ideas you’ll hear from programmers struggling when fixing their source code. It is all light-hearted humor, triggered when things become stressful. Generally the application will (eventually) work out and you will move onto the next great task.
I am sure many web developers and software engineers can relate to these programming hardships, while still laughing in hindsight.
1. “I don’t know whether to delete this or rewrite it”
Going back to old source code from your past brings a temptation to rework larger block clusters. Ugly logic statements with verbose syntax is very hard to read! But then again, if it ain’t broke, don’t fix it. This is a struggle I often face and it surely plagues a number of other software developers.
2. “I should check Github for a starting framework”
I think most developers know about Github and the amazing open source projects being published every day. Programmers dabbling in all languages join the network to branch off existing projects, add wiki discussions, or make their own code repo. It is an excellent resource for cool plugins and templates to be used on various projects.
3. “Why does this script need so many libraries?”
Moving particularly into bigger languages such as Java and Objective-C, the amount of libraries can become fierce. It can be very noticeable when building off of a framework which requires a lot of grounding. Even some plugins for JavaScript will need a myriad of additional files. Sometimes the clutter will get annoying – but at least it works!
4. “There must be a solution somewhere on the Internet.”
My first reaction to a difficult problem is to check the Internet. Lots of programmers will post forum threads about their issues, and they will eventually be solved and archived. Google is fantastic at picking up keywords related to your issue and pointing you in the right direction of these helpful discussion threads. Unfortunately, sometimes there just isn’t much information out there on a particular issue.
5. “Is there a plugin for this functionality?”
Why reinvent the wheel? Plugins are a great resource for expanding the user interface of any program or website. Additionally they can offer some customization and unique options for the developers to work with. Plus if there isn’t already a plugin available, why not build one yourself?
6. “The site works, but I’m dreading Internet Explorer.”
I don’t need to mention the trials and tribulations which have come from the history of rendering webpages within Internet Explorer. From version 5.5 up to about IE9-IE10 there has been a constant struggle for greater browser support. Web developers may fear the debugging of a webpage, opening within IE6 to a rendering nightmare. Thankfully those days are slowly becoming a thing of the past.
7. “For a logic statement this doesn’t seem very logical.”
There are logic statements for if/else loops, for loops, while loops, do loops… the list is fairly lengthy. When looking over sample code I have relapses trying to figure out how my logic is supposed to work. The sheer number of NOT operators and comparison signs can have your head spinning. I frequently go back to update my own logic for good practice in the future.
8. “I spent 30 minutes writing a function and 2 hours getting it to work.”
Isn’t this the programming story of the decade? You are humming along just fine building what you know, when all of a sudden the function is outputting a fatal error. So now you have to go back removing blocks of code attempting to pinpoint the faulty line number. It can be exhausting yet a relief when you finally find the culprit and solve the case.
9. “After reading several blog posts, I now realize that I’ve been doing this completely wrong the entire time.”
I often like to dive head-first into topics with my own programming ideologies but this can lead to trouble down the road when things don’t go according to plan. There have been many times where I’ve started a project and ran into trouble, seeking blogs and other articles for support. Then I find out the whole method is practically wrong and it’d be easier to just start over! Doing a bit of research first will definitely save time in the long haul.
10. “The nice people on Stack Overflow can probably help me.”
I couldn’t begin to count the number of times that I have solved a difficult problem through Stack Overflow. The community is full of nice, intelligent people who are willing to help if you take the first step. Out of all the online forums this is definitely the most widely supported network for software programming and frontend/backend web development.
11. “All that trouble for a missing closing parenthesis.”
Debugging is all about the steps you take. Two steps forward, one step back, two more forward and so forth. The feeling of staring at code for hours just looking for some mistake in function names or variable scope, only to find a missing parenthesis, is a weird feeling. All that time lost over a minor syntax error. The feeling of being both a genius and fool at the same time.
12. “Welp, coffee break!”
Sometimes you just need to get up and away from the monitor. After hovering over the keyboard for hours at a time, it definitely helps to break up the routine. Most health guides recommend a break every 30-60 minutes. But it all depends on your needs and if you get annoyed more from stopping for a break in the middle of a program than not.
13. “I should put this project on hold and deal with it later.”
An alternative to work breaks is walking away from the project instead of just your computer. Maybe there is other work that needs to be done, so go on over and check that one out instead. This would be a better allocation of time and resources, compared to fretting away while attempting to solve a problem that you’ve been looking into for 5 hours straight.
14. “I wonder if classical music will stimulate my programming abilities.”
There is an idea that classical music could promote plant growth during the early stages of life. I personally love classical music for the intricate notes and complex musical theory. Jazz, piano, big band, classy music has a place in human culture around the globe. So could listening to smart music while programming actually make you smarter at debugging? Probably not, but hopefully it wouldn’t make you more clumsy either.
15. “Maybe now is a good time for testing the theory of Ballmer’s Peak.”
I think many readers know about Ballmer’s Peak which was coined by a particular xkcd comic. To simplify, the theory states that programmers hit a peak of coding ability after consuming a specific amount of alcohol. It was attributed to Steve Ballmer for his wacky antics which may be construed as the ramblings of a drunkard although it is somewhat ironic, as Ballmer was never truly a programmer at Microsoft. Guess we willl have to wait for somebody else to give this theory a trial run.
16. “Was somebody fiddling with my source code?”
It sounds like delusion and paranoia, but sometimes you just have to wonder who is writing this stuff when you are busy catching up on sleep. Looking over projects from weeks or months in the past can leave you with a sinking feeling. Sometimes you will find stuff that you never remember adding – even from projects you just looked into last week! I write it off as crazy but you never know…
17. “I have no idea what any of this means.”
The worst situation you can have is looking into source code with absolutely no idea what to do. This may arise from your own projects, or somebody else’s project, but it is all the same problem. Now you have to decide whether it is worth spending more time searching for an alternative or dissecting the script to learn how it works.
18. “I’m gonna need to Google that error message.”
After working in PHP for years I have to say that Google is my best friend when debugging problems. This is definitely the same case with Objective-C, C++, Java, Python, and other major languages. Error messages try to help but unless you have memorized what the different codes mean, it reads more like translated computer language. Thankfully there is a lot of support online for determining just exactly what these error messages really mean.
19. “I should stop and call it a day… but I really wanna figure this out!”
We all know that feeling of utter frustration where you want to call it quits, but it just feels like giving up isn’t the right choice. You want to keep pushing forward and try new solutions for debugging. But what if it turns into a waste of another hour? I am no stranger to this circumstance and it can be awfully disheartening.
20. “Oh dear, why didn’t I write any comments?”
When it comes to more basic frontend HTML/CSS/JS there isn’t always a need to leave comments. But more complicated scripts and programs will need some type of organization for when you want to look back in a few months, or even after a couple of years. Sometimes you will forget to comment about functions and their parameters, the output format, and other essential data. This will no doubt lead to confusion down the road when bugs start appearing and you have to debug the entire script for a solution. If only there were some helpful comments.
21. “This was working 20 minutes ago…”
Possibly the most frustrating part of building a program is when it goes from working to not working – without ANY updates to ANY part of the code! I swear it happens. And it doesn’t make any sense – maybe the other program was running a cached version? Then there are times when updating one tiny bit of code will cause the whole program to crash on error and just stop working entirely. Revert back to the most recent working copy and keep moving forward from there.
22. “You forget one lousy semicolon and the whole program comes crashing down.”
Almost every programming language I have used will require a symbol for line termination. Not all of them do, but it is definitely common in the C/C++ family. When you forget to add one terminating semicolon it is an honest mistake! But the parser doesn’t understand this and throws out a fatal error. Now you have to spend another 20 minutes scouring code for a technical fault, when the whole time, it was just missing a semicolon. Ah, the joys of debugging software.
23. “I wonder how much it would cost to pay someone to fix my mistakes?”
The overwhelming thought of hiring another developer is tempting, but obviously nowhere near financially viable. Plus how would you learn from all of these mistakes if you are not getting your hands dirty? It can feel good when you finally understand a programming concept, after failing multiple times. But it doesn’t stop this thought from crossing my mind ever so often.
24. “A quick visit to Hacker News is sure to improve my productivity.”
A lot of programmer’s favorite choice for social news on software & startups is the Hacker News frontpage. It has a lot of great information about freelancing, time management, software development, plus new startup launches and raising capital. Although HN can emulate the feeling of being productive by educating yourself, it can also be a drain on your time. Taking a quick recess to check up on news every few hours couldn’t be all that bad.
25. “How can this API have no documentation?!”
The most frustrating part about using a plugin or framework with bad documentation is that you have to look deep into the source code yourself. I simply adore projects where the developers will take the time to specifically design a usable documentation page. All the parameters and options are explained, possibly even used within some example code snippets. But sadly this is not always the case. It is easiest to stay away from poorly-documented work and save yourself the grief.
26. “I sure hope I’ve saved a backup copy of that database…”
Backups are not always on my mind when writing and debugging code. However, data backups offer a stepping stone to go back in time before certain changes were made. This is especially useful on a live server environment where changes are implemented immediately. Remember to keep local copies of your website files and databases in case of an emergency! It can be an annoying task, but not as annoying as rebuilding a corrupt SQL database.
27. “What is the quickest solution to get this working properly?”
After hours of turmoil looking for a custom solution it becomes very clear that you may need a new approach. Programmers want to get the functionality working first before designing a pretty interface around it. Determine the quickest, most accurate solution and implement this to be working at best 100% of the time. Then it is easier moving on to the pretty aesthetics.
28. “I bet updating my software will fix the issue.”
The teams who manage dependencies and plugins for programming languages do not need to push releases very often. Sometimes updating your PHP/Ruby/Python/SQL version may solve debugging issues when transferring files from your computer onto a live server. Local updates will very rarely help with fixing a bug in your source code, unless your version is hopelessly out of date. Hey it’s worth a shot!
29. “I should be more organized and study Git… But I’ll look into it next week.”
The open source version control package Git is extremely popular among programmers. It offers an easier learning curve than other competitors, and it is used in many online repos such as Github and Bitbucket. Developers will put off the idea because it definitely has a steep entry-level curve for beginners. However once you understand the basic commands then Git is a cakewalk. And it makes the practice of debugging with version control a lot clearer, too.
30. “Scrap this, I’m starting over from scratch.”
Sometimes after trying hours of solutions, you just have to move your working files to an archive directory (or delete them) and start again from scratch. The decision is tough considering how the previous hours have been toiled away for little payoff. But when I am in a rut, getting a fresh start is often just what I need to see a project through to completion.
Workplace environment plays crucial role in the development of an app or project. Employer or client cares only about the outcome of the program. No one is happy about how quickly developers change the world. However there are many barriers at the workplace that can affect your productivity while at work. Today we have listed eight barriers that can highly affect your workability.
1. Meetings
This is the most common complaint amongst developers. Programmers mostly blame the manager ruining meetings. Some bosses keep them in dark and avoid to share all the details of the meeting. Some complaints about the meetings are foolish too. If programmers are told to attend all the client meetings, that can have great impact on actual work. Switching mind from out of the space and then back to coding can be difficult for programmers.
2. Emails
Emails, email conversation threads are worse than the meetings. Developers find it too boring and waste-of-time to reply to all the email communication threads. Reply to dozens of email can take lot of time. And if you stop replying to mails, it becomes hard to quantify your work with your employer or project manager.
3. Measurement of Productivity
A management team is only concerned about progress and final version to the product. They start counting lines of code, code repositories or bug fixes. According to them, counting is measuring and measuring must be good. So, programmers focus on lines of code, bug reports and such minor problems instead of solving a real problem. Measuring the productivity can actually make the code worse.
4. Technical Debt
There is never enough time to build the product in time. It takes days and days to plan the project to build what we need to build. Programmers often cut the corners, patch some code in order to build the product. This approach is known as technical debt. Debt is something that needs to be paid off. Every project has some technical debit, sometimes it can be paid off very quickly while, sometimes it takes more time than the projected time for building the product.
5. Non-Programmer Managers
There are always some people who are major in something other than computer science involved in your programming project. They are there due to somebody’s recommendation or they are there due to coincidence. Most programmers hate these managers. The non-programmer manager does not understand the code or the efforts programmer took while building the product. Programmers want a manager who can give little guidance or somebody who can offer bit of quality testing.
6. Selfish Coder
Everyone has these people in their teams. Selfish or cowboy coders do not intend to share the code or the progress of the program. You might get just a null pointer from his code. You may end up spending lot of time in just catching the error in his code. As a team worker, it is your job to catch errors in his code. Many teams end up finding this too late.
7. Poor Documentation
Writing documentation of your software project takes lot of time. Programmers are often measured by the lines of code that they write. As a programmer, it is your responsibility to write proper documentation for the software that you are coding. Sometimes there is plenty of documentation to write. Programmers are bored to go through the old documentation and fix the errors.
8. Distraction-rich environment
Some clients put too much on programmers. They insist developer to come in their office and use their PC everyday to work on the project. Most start-up offices have too small place of work. Some service companies may not have enough number of clients. While sales and marketing teams can function and even thrive with some background noise. Something as small as ringtone can have significant negative impact on productivity of programmer.
Hie Frnd's
Today We Are Going To Cover 1 Topic For Hacker's :)
That is How To Install Weevely Tool in Windows OS .
Weevely is Tool Which is use to BackConnect The Server And Giving Environment Like Telnet or NetCat .
Weevely is Inbuilt Tool of BackTrack OS , Developed in Python .
So For Installing This We Have to Install 1st PYTHON 2.7 in Our System .
So Downloading it From Following Link :
Python
Official Link : Download
After Downloading , Install it .
After Installation Download Python SetupTool's Which is Necessary For Running The Weevely .
Python SetupTools
Official Link : Download
Python SetupTools is in Compressd Format , So Just Unzip It in on Desktop or Any Where You Want .
Now Start CMD With Admin Privileges And Go To That Directory Where You Unzip The Python SetupTools Using 'CD' Command in CMD
Not Execute Following Command's :
C:\Python27\python.exe setup.py install
cd C:\Python27\Scripts
easy_install.exe pip
pip install pyreadline pyyaml
Note : During All This Step's Make Sure Your Are Connected With INTERNET
Not Just DownLoad The Weevley Script .
Weevley
Official Link : Download
Unzip The Zip File .. And Go To Weevely Dir , And Fire This CMD :
C:\Python27\python.exe weevely.py
