₦airaland Forum

stanliwise: i don't get your complain.
make your point cleae

HTML is NOT a programming language, get your facts right!

stanliwise: SHORT DESCRIPTION OF HTML...

As i was saying HTML is a programming language
that is use to structure a piece of information and been interpreted by a browser to give you what you want... google more

A Browser:This is the main machine in web design that interpret html language and bring it out nice looking.
so to not make it confusing html is like tv antenna having the information while A browser is like television interpreting the information
if you are confuse pls ask questions or do a google research about it.

EPIC FAIL!!

continue

Ayo_hbk: ma people in the house.....av bin tryin to download jdk7u17 on ma system and everytime i download it and try to install it also gives an error ...sayin "jdk7u17 windows-x64 is not a valid windows 32 app"...av tried dis mor than 5 times and it always give d same error....pls wats d soln to dis problem cos its just wasting ma mb.....i also downloaded netbeans 7.3 but it is asking for jdk to be installed on the system to complete d installation......thanks

That means you are not using an x64 version of windows. Download the 32 bit version...

[size=14pt]Change the Code[/size]

Even if you don’t know how to solve the problem changing the code anyway can be an effective technique for problem solving.

26. Write New Unit Tests . Since you have to spend time with this code anyway, write some new unit tests. It’s helpful to get your brain thinking about the code in the same way that the computer is.
27. Refactor it . Problem code is often messy code. Tidy-up the code by applying simple refactorings like renaming variables, or unwrapping nested if/then/else blocks.

28. Find Bugs . Another code tidy-up technique is to look at any “Find Bugs” reports you have for the related code and start working with those first. Get the code into a tidy state first because;
It’s an easy cost-effective way of getting your brain focused on the code The problem may become more apparent

29. Rewrite It . One technique is to dump all of the related code and rewrite it from scratch. A fresh perspective may avoid the problem altogether.
30. Comment out unnecessary code - or at least what you "think" is unnecessary. You may discover that your understanding of the flow through the code isn't quite what you thought it was.
31. Experiment. If you are not sure how the underlying product or library is working thenit can useful to introduce little experiments particularly around boundary conditions.
32. Periodically go back to a clean state . If you have been making lots of different changes either in the code or with configuration settings it’s important to periodically go back to a clean slate. Otherwise side-effects from experiment number “3” might affect the “right” answer and so you never actually discover the right solution.
33. Switch Technologies . If you are having problems with one particular technology it might be worth dumping it and switching to a different technology.

[size=14pt]Isolation[/size]

24. Which line of code . Are you sure you know which line of code is causing the problem. Sometimes it helps to temporarily insert additional print statements between each line of code with nothing more than a “line x” statement. Watch carefully and you might be surprised that sometimes the flow through the code isn’t what you thought it was.

25. Break out into an example program . If you are having problems with a library or product then sometimes it helps to break out the related code into a program separated from the main application. This might take a little time to setup but often dealing with an isolated example program is easier to deal with than your project’s overall build process.Once you’ve got “something” working then itgives you a basis for comparison with the main program.

Nothing beats a Native app, they are alot of things you dont have access to in a semi native app or a mobile web app.

laxx: But frankly the world doesn't care. All the world wants is to open a great app on their device and use it. The language or style by which it was built is immaterial.

Well said...

Zackmr22: i want to learn too someone help me

Help you with what?

[size=14pt]Move Away from the Keyboard[/size]

20. Go for a walk . Taking a break from solving a problem is a good way of generating fresh ideas of things to try. Walking by yourself is a good way to put yourbrain into neutral and let it swirl around the problem.

21. Sleep on it . Likewise sleeping on the problem is also good for letting your brain come to grips with the key aspects of a problem.
22. Reset the Priority . The other good thing about taking break from a problem is that it lets your reevaluate how important a problemis. The issue might be a CSS/Layout issue that just simply isn’t worth spending
16 hours on solving, so be careful that you are spending your time effectively.
23. Ignore the problem . If you ignore the problem what you find happens is that you will be hypersensitive to related keywords forthe next week or so. What will happen is when you are reading something like Stackoverflow all of these keyword related articles will suddenly jump out you and mightcontain useful information.

babihouse: that of 2go is not a direct payment or are u saying mobile operator pay 2go due to the amount of style and go credit been bought?

cant remember the last time i saw that app called 2go, but then they used an sms shorcode system. When you acquire an sms chort code from the service providers they give you a percentage of each message sent to that number, e.g. You short code maybe 35412. Each time a user sends a message to that number, he is charged maybe N100, you have a percentage of this and the service provider has its percentage.....Although, when i last checked this shortcodes are not cheap to acquire and i think greedy MTN makes you pay a monthly fee after the start up charges. I dont know if its still done this way....


Hope this helps

[size=14pt]Support[/size]

16. Read the FAQ. Check the Frequently Asked Questions before submitting your support request if there is one.

17. Submit a support request. If you have support available for a product or library then use it. Often the support desk is in a different timezone so when you get to the end of the day put together a support request and let someone else work on it overnight for you.

18. Before you Click Send. What you will also find is that the act of writing the support request will prompt you to think about the problem again and you often solve the problem or come up with new things to try before you even hit the send button.

19. Support. Breakthrough 1st and 2nd level support and talk to the real developers directly and preferably in real-time, chat/skype/screen sharing.

musKeeto: Didn't receive it..

Check your email, also you can check your Spam folder....

musKeeto: Did u get my pm?

Morning..

Yes and i replied you....

[size=14pt]Writing[/size]

13. Write a problem statement. Write the most accurate and precise problem statement you can. By being precise you are challenging your brain to accurately describe the problem which in turn helps you to think of possible solutions.

14. Write a problem diary. Create a text file with a bunch of notes to yourself about the different things you have tried. Include snippets of code or configuration settings and also any errors produced

15. Keep a record of your problems and solutions. Have you ever had a problem where you know you've solved it once before but you can't remember how? Once you have a problem and then solved the problem, document the solution somewhere that's easy to search (preferably across your team) like a wiki, defect tracker, or just email it to yourself.

musKeeto: hey. javanian.. great thread and great job.. I wan send u mail abeg...

No P.

[size=14pt]Talk to Someone[/size]

9. Ask someone who might know. If the problem is something that you think someone else on the team might know about then ask them. When you join a new project or team there are going to be dozens of things that you just won’t know about and someone else on the team will. Don’t be afraid about looking dumb. It’s far better for the team as a whole to get the work done efficiently and get you up to speed as quickly as possible. The only sin is to keep asking the same question over and over, so when someone tells you the answer that you make a note of it somewhere and don’t ask the same question twice.

10. Ask dumb questions. You might think they’re dumb questions but they probably are not. If you don’t know the answer then it probably isn’t a dumb question.

11. Explain the problem to a teammate. They might know the answer or be able to suggest things that you haven’t thought about.

12. Explain the problem to your dog. It really doesn’t matter who you explain the problem to it’s the act of explaining that gets your brain to analyse the problem from different angles.

^^^^ Thanks Boss...

[size=14pt]The Prime Directive[/size]

1. Don't write defects in the first place. The best defect to fix is the one that you never wrote to start with.

- Nicely unit tested code
- Enforce database constraints
- Use an input validation framework
- Avoid unimplemented "else" conditions
- Understand how to use something in isolation before you use it in the main application
- Pepper your code with exceptions for situations you don't expect to happen

[size=14pt]Logging[/size]

2. Print Statements. The ye-olde print statement is still as useful after thirty years of programming as the first time I used one in high-school. Think carefully about the problem and often one or two lines of extra output will help to isolate the problem.

3. Switch to Fine Logging. Sometimes when an underlying library or product is not telling you why it is failing then increasing the verbosity of the logging can uncover additional clues.

4. Search the Logs. If there’s too much logging to read easily, search through the log files for keywords or error codes.

5. Wrap on, Wrap off. Controlling the logging viewed with word wrap on or off can also be helpful. Sometimes you want it on and sometime you want it off.

6. Search different logs. The main server log might not be the only useful log to search through. Java application servers often produce other log files that might be useful.

7. Windows Event Log. Another source of log files might be from the operating system itself.

8. Craft useful logging. Sometimes if you are not getting any useful logging then you might need to write it yourself. For example if you have a complicated data structure to deal with you might include carefully crafted “dump” statements at strategic points in order to get the visibility you need to solve the problem. This can also be quite handy when dealing with multi-thread problems. Sometimes half the problem is just “seeing” what’s actually happening.

Our lives as programmers are a never ending series of one problem after another.

If we are lucky, our daily slog at the keyboard is occasionally punctuated with brief glorious moments where it all "just works" and we feel like gods.

If we are really, really lucky these serendipitous interludes also happen to coincide with events like "product demos" and "production releases".

In between these glorious moments we toil through the frustration of one problem after another. We are not programmers, we are just hacking out the first solution that works.

This post will describe a bunch of different problem solving strategies. I would update the thread daily. Here are the first 8.

After taking a picture, the overhead involved in displaying it on the screen is very complex and requires a large amount of processing operations. Researchers at the Massachusetts Institute of Technology’s (MIT) Computer Science and Artificial Intelligence Laboratory have constructed a new Programming Language called Halide that stands for two things – first, it simplifies the process of writing Image Processing and Computational Photography Software and second, it’s designed to economize the use of mobile battery and processors while processing Images.
For a digital camera, transforming an Image onto screen to make it appear just like how human eye sees is not an easy task. There are certain processes that have to do a lot with capturing light, reading pixels to deduce the colors, Plus-Constant-Correction process so that the result is as similar to what human eye catches, explains GigaOM . And of course, more megapixel a camera has, more intense processes and more complex and lengthy algorithms are involved.
To rewrite the algorithms in this language, researchers have been able toaccelerate image processing up to threetimes and significantly with smaller code. In one case, Halide algorithm was actually pretty much longer than conventional MATLAB, but the Image Processing was 70x faster :
It is definitely an important step in as the web is becoming more and more visual. Halide is therefore an important programming language designed to make it easier to write short and clear image processing code on modern machines. Halide’s front end is an embedding in C++ and Hardware targets include x86-64/SSE, ARM v7/NEON, and CUDA.

webdezzi: no matter the logic you apply, win32dasm and numerous hex editors exists to bypass the license logic
any solution that does not check a remote server for license can be cracked
the host file.

GBAM!!!

lordZOUGA: That is just a launcher.
.
.
@OP, this thread will be deleted, if you think of creating another thread like this, that thought will also be deleted.
Be Advised: Mention of a "Nairaland app" is considered a blasphemy on Nairaland. Punishable by hiding the post or deleting the thread as the case may be. Nairaland members are expected to wallow in misery of page refreshing and to always be at the mercy of opera, firefox or other of such infernal devices.
such is the will of the Nairaland Dictator: Seun.

LMAO!!!


Thread closed not only because it's a duplicate thread but it will eventually be deleted by our oga @ the top and i wont delete it because i see nothing wrong with it....

Use the JNI,

why are you even trying to this?