Posts Tagged 'howto'

How to insert a java applet in a web page

• 
• 

Details

Category: Useful Code

Published on Monday, 08 June 2009 00:00

Written by Administrator

Hits: 12531

 

I did learn a lot today while trying to validating my new sub domain: http://websitesasgraphs.waltercedric.com/ I found a huge number of examples using the tag <applet> which has been deprecated and create errors and warning in W3C validation engine. But no example using the  the new HTML <object> tag.  Hence I decide to publish this small post.

The following page are now XHTM 1.0

• display.php (validation Link) XHTML 1.0 Strict
• menu.html (validation link) XHTML 1.0 Transitional

While this one is

• index.html (validation link) HTML 4.01 Frameset

Here is the code to insert a java applet into an XHTML 1.0 Strict web page

Read more: How to insert a java applet in a web page

How To Ask Questions The Smart Way

• 
• 

Details

Category: Open Source

Published on Saturday, 25 July 2009 00:00

Written by Administrator

Hits: 8734

Went through this interesting article “How To Ask Questions The Smart Way”, while a bit old (2006), it is full of very good advices for asking questions the smart way (and also sometimes finding an answer on your own).

In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer. This guide will teach you how to ask questions in a way more likely to get you a satisfactory answer.
Now that use of open source has become widespread, you can often get as good answers from other, more experienced users as from hackers. This is a Good Thing; users tend to be just a little bit more tolerant of the kind of failures newbie's often have. Still, treating experienced users like hackers in the ways we recommend here will generally be the most effective way to get useful answers out of them, too.
The first thing to understand is that hackers actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise. Among hackers, “Good question!” is a strong and sincere compliment.

Android how to delete system application and remove unwanted MyTaxi on Galaxy S3

• 
• 

Details

Category: Android

Published on Tuesday, 28 August 2012 20:32

Written by Administrator

Hits: 1569

I use the hard way, free but a bit more difficult as it require a rooted device, I personally use “Android Terminal Emulator” with granted root permissions (after typing su a prompt will appear)

Android how to delete system application

su (enter)
mount -o rw,remount /system (enter)
rm -r /system/app/FILE-NAME-HERE.apk (enter)

How to remove this SHIT of myTaxi – Passenger Taxi App on Samsung Galaxy S3

This application got installed without my knowledge by a Samsung update as a System App that CANNOT BE UN INSTALLED!

First before I forgot: Go to hell Samsung and Intelligent Apps GmbH

If either of you continue in that direction, installing software without my prior permission, the next update to my Samsung Galaxy S3 will be CyanogenMod 10

Back to the removal of MyTaxi,  Samsung did hide taxi.android.client_v2.5.1.apk under the name /system/app/samsung_ch.apk

To remove it

su (enter)
mount -o rw,remount /system (enter)
rm -r /system/app/samsung_ch.apk (enter)

90 deg. CCPM

• 
• 

Details

Category: Kyosho Caliber 30 - Rotor Head

Published on Thursday, 26 August 2004 00:00

Written by Administrator

Hits: 7670

90 deg. CCPM by CK_

When in MMS mode, move the link from the blue ball to the red ball. Do this on both side of the swashplate.

All credit to CK_ "As for the 90 deg. CCPM, here's why I did it. I started with the stock 120 deg. CCPM with 3 9202s. If I banged the cyclic around quickly there was a lot of collective interaction. Try it for yourself. Wiggle the cyclic and watch the antirotation pin and jump up and down 1/8". The interaction happens because the servos are slow and the front swash input has to move twice as fast as the two in the rear for a fore/aft cyclic movement because the front ball is twice the distance from the center as the rear balls. If you move the cyclic faster than the servos can move then all three servos will move the same speed (the max speed of the servo) and collective interaction will happen because the front swash input is not moving at twice the speed of the other two. Curtis' 140 deg. or whatever it is on the Vigor CS puts the front ball exactly the same fore/aft distance from the center as the two rear balls. This means that all three servos move the same speed for a fore/aft cyclic input. No interaction. If you use 90 deg. then fore/aft cyclic only moves one servo. There can never be interaction if only one servo is moving. Lateral cyclic will move two servos at equal and opposite speeds. No chance for servos to "run out of speed" like with 120 deg. I still get a little bit of interaction but it's nothing like I had with the stock setup. Like I said before, I still don't know why 120 deg. is pretty much the standard and 90 deg. is rarely used when 120 deg. has much more collective interaction. Anyone got any ideas?"

Great response by Dr.Ben "Your info about the 140 degree CCPM is entirely valid. One drawback of having the single ele input up from is that the swash is less stable. 120/140 d. CCPM surrounds the entire swash with support. There is also a control power component here. One reason the big gun CCPM models such as the Fury and Vigor CS can pull such abrupt maneuvers is the combined input of the servos - two for any roll command, THREE for pitch command, and three for a collective command. 90 degree CCPM takes two servos out of the power equation on the pitch axis. I realize the control power issue is of less consequence in a 30 sized bird, but you asked why manufacturers don't employ 90 CCPM more commonly. Much of the interaction you saw is a direct result of the somewhat slow analog 9202's (still a hell of a good servo) and not the 120 d. CCPM per se. If you go to a upper or lower collective command and input a hard over roll input, you will note a pretty good collective interaction because the servo arm on one of the two roll servos is approaching centerline and thus moving its pushrod further, while the other servo arm is retreating from centerline and moving the pushrod less. This differential phenomena is present in all CCPM models with rotary servos and is somewhat minimized by using servo wheels large enough to avoid movement a large number of degrees off centerline. A linear output servo is the only way to avoid the problem completely; we ain't there, yet <g>. The Caliber 30 system might work a bit better better if the bellcranks were designed to create less swash travel per unit of servo movement (meaning equal ball input points on both arms of the bellcrank), and then larger servo wheels were used to get the collective/cyclic range needed (less differential effect). Ben Minor"

Mounting the gyroscope behind the main mast

• 
• 

Details

Category: Kyosho Caliber 30 - Gyro

Published on Thursday, 26 August 2004 00:00

Written by Administrator

Hits: 4426

How to improve your debugging skills

• 
• 

Details

Category: Debugging

Published on Tuesday, 31 August 2004 00:00

Written by Administrator

Hits: 12418

Introduction

I am presenting here some tips which may help You to correct bugs in programs or applications faster, If you have comments or want to submit new ideas, feel free to do it here
Being good in the process of solving bugs is more or less a habit:

• You must discover the right informations (most if the time coming from logs file),
• Know a little bit the system and how components are interacting each other (software architecture),
• Use some rules and decide what to do (actions).

This document is all about theses points...and is targeted for java web applications.

Process

1. Discovering a bug. Depending on the type of person who report bugs: You, end users, a pool of professional tester, your developer collegues. You will have a different amount of informations and instructions to reproduce it. For a user, assertions like: "The system is not working, the system is slow" is common but it does not contains any real informations, except the fact that something is not working. Most of the time, a persons is responsibble to collect all user's complains, be careful since this person may filter the only useful informations as well. In this phase, you need to collect as many informations as possible.
2. Use a bug tracking tool, to keep a track of the bug, to have the name of persons and a description how to reproduce it (a web frontend tool like Mantis or Bugzilla is a good start). As a rule: Explain a bug, is the first step for avoiding it! Be descriptive when you assign a ticket in a tracking tool. If you still think You do not need such a tool, the quality of your application, cost controlling and distribution of tasks among developers before shipment will be disastrous,.
3. Define priorities based on bug severity and assign to a developer (I will suppose it's You :-)). All bug tracking let You define your own subset of priorities.
4. Define Categories: is it a graphical user interface (GUI), backend, input control problem? All bug tracking let You define your own subset of categories.
   

   Example of Error Severity Definitions taken from Mantis Severity level Definition Description Consequences 1 Critical Error Productive operation is not possible. Example: - Crash, The system cannot be launched. 1 Functional Error Prevents the usage of the system . Examples: - A needed function is interrupted, - Loss of data, corruption of data - Usage of the system is hampered in a way that wrong results are created for critical data. - Performance or acceptance.o users The system cannot be launched. 2 Median Error The productive usage of the system is possible with some interference (a "workaround" can be established) Example: - Deactivate some functions which are not working properly - A Hack in done in code which prevent the bug. A "workaround" will be implemented for a short time until the problem is properly fixed. 3 Minor Error T he system can be used and errors are imperceptible. The bug has to be enter in the bug tracking tool.Priority has to be assigned 4 Change Request Nice to have, improvments Example: - GUI is not perfect, colors has to be changed, font size, layout - Error in Titles, subtitles and blocs of text The bug has to be enter in the bug tracking tool.Priority has to be assigned. Usually these bugs are solved if the efforts is small or if developer has some spare time.

5. Try to reproduce this bug in your development environment, whih is in best case not so much different from production environment. Of course You do not have the same processor or memory or disk but the same software components (database, jvm, classpath, structure of data))
6. Correct the bug by changing code/avoiding exception case, rewriting algorithm, changing architecture, finding a workaround (hack), adapt functionnalities if it is possible.
7. In an ideal world:
   1. Write JUNIT testcase(s) to avoid further existence of the same issue. This will greatly improve quality of code!
   2. Document the bugs, correction, and in worst case: a workaround in a central place: a FAQ (Frequently Asked Questions) for developer

Bug life cycle

from Mantis

 

 

Loging, logs files

• Logs file are the oldest way to degug or monitor an application and it's probably the slowest way to debug or locate bugs. Most of the time, you need to reproduce the error in the system, and that can take a lot of time especially if the application has a very complicated workflow. A workflow: dialog and navigation through the application, ex: select a customer, view all account, do a transfer between 2 account This can be the execution of a use-case or a chain of use-cases.
• It is a common Fact: Without informations, nobody can debug a process and this even with a lot of chance.
• Worst case: developper use System.err and System.out for everything, they write "bullshit" in log output ("This is value of i= 2"). Developer do not use the same convention: "Exception : oups" or "@EXCEPTION: ioexception". You must force them to use a logging framework and teach them what to write and level of severity.
• Best case: Your applications is already using a logging framework like Log4j.
  

  Log4j let You reduce the amount of logs to a special part of your application or keep track of unusual case in a elegant mannner. The amount of logs (Level), The location (file or TCP server, mail or...), The domains in the system (packages, or components, or arbitrary part), The layout is standard because the developer can not influence the apparence, you can add relevant information like thread name, time, date All these things can be changed without restarting your application and are controlled by a configuration file (.xml or .properties)!

• Why logs are sometimes better? because during debugging You may change variables values in realtime to let the bug happen. This is why debugging session are called transient: the know how You bring during these sessions (where you set breakpoints, the iterations You do in code, how you manipulate variables/instances on the fly) is simply lost or not share with your collegue. In this case logging output is better because it may stay even after correcting the bug. This can be useful to avoid further existence of the same bug.
• Some mistakes:
  • Do not log too much mainly because of performance issues or try to use a preprocessor which remove logging statements before deploying to production...
  • Do not write stupid data during logging, e.g. "this is the value of i" or "iteration i", in this case use the debuger. for the same reasons avoid writing a 100Kb XML, it is useless, write the XML in a file...
  • Do not rely on logging to rescue You from bad code: instead of losing correcting a bad code, why not try refactor it!

• Log amount can be enormous, especially when you track a bug at the same time with 4000 users working in production on many server (webserver, application server, servlet runner, database cluster).... this is why You "must":
  • Use Unix or install cygwin (if your running under windows) only for having some command like grep, sed, tail, awk, ssh
  • Learn regular expression, to filter the logs file with command like grep, sed, awk
  • Watch logs files in realtime (when users or you are testing your application). Prefer the unix tail command because it is very efficient. You can even combine the tail with a grep command to filter logs output.tail -f Tomcat.out | grep 'error'
  • If You really can not work with a command line, use Jedit which also support regular expression and will probaly have a tail pulgin.

Silent exceptions

The worst case in production is what I call "silent exception", these affects some users but not all. They are silent because the users can still use the application but can have some really bad effects afterwards. Example: During a save, your program encounter a problem, but do not rollback the transaction (due to a bad design or implementation) and save an imcomplete state on disk or in the database. In fact, You must really not let them occur, do something before users even remark the problem (It took always 2-3 days before a pool of end-users got crazy about a problem in general, this time is comming from communication channel).

How to avoid silent exceptions:

• Define job (can be unix crontab) that parse log files daily or weekly with regular expression, and send a report. With log4j you can for example decide to send an email if a certain error level is thrown (level FATAL fro example)
• Explain to developer (with a training) differences between logging level, what is fatal, error, warning, what meaningful info they must add in their logging statements. Review their code by checking usage of logging levels, or reading logs when Your application is in DEBUG mode.
• If you need more error level (better granularity, most of the times it is not a good idea), You may want to define your own level. (and that's easy with log4j)

Debugger and remote debugging

The Java Virtual Machine has an interface which allow to remotely debug an application

Running your application remotely

The code is running in the developer environment but not in production...one more time there is a difference somewhere, finding it may not be easy...

• If you are running your application on remote server, are You sure that you deploy the latest code version? this is very easy to test:
  • You can for example run a Unix scripts which compare class CRC or
  • Use beyond compare, a graphical tools to compare directories and contents even through FTP.
  • If You know the class name and package where the exception occurred (look at the stacktrace in log files), use a decompiler like JAD to verify if the latest code is there (follow the rule 1 : "never trust anyone" even You sometimes ;-) )
• Suspect the classloader:
  • You may have different version of the same class in the classpath = bad deployment
  • The classloader do not respect the servlet guidelines (the servlet runner Resin has some problems for example)
  • Order of jar in classpath, You can have dfferent parser version in different jar files for example.
    In all cases above try:
    • to start the JVM in verbose mode, to see which classes is load a which moment.
    • Use the utility JWhich, inform You where the class was loaded (jar or directory)

Process throw an Exception of Type X

• If the process throw an exception and You know the exceptions class created. Use your IDE! all of them have the ability to trigger a breakpoint on that type. The debugger will then stop where the exception is thrown.

Mistakes

• Do not made a runtime patch (= identifying condition of exception and testing it through IF statements to avoid it), but instead try to find the real reason (design, init phase...) and operate before it occurs, maybe you will need to change your algorithm.
• Do not correct bug or listen to people which assign too many critical errors, if You can proove that it only affect 0.1% of users in production. Definition of bugs priority is essential as ressources are always limited.

Automate gathering of informations

If the system crash, or run in troubles, try to create a journal written on the disk, it can contains

Advantages:

• You can look periodically to see if some error appear often enough to be corrected
• You have some information on the state of the application, if youre design is good enough You can even imagine using/loading this state to put the application in the same status.

Hotline or developer asking for support

Capitalize problems and resolutions in a central place!

• Use FAQ (Frequently Asked Questions) Maybe the error has been already described and a solution found. You may create a lot of FAQs, for developer, manager, hotline. You can not save informations in 1 FAQs for all audience as you may need to adapt responses to the audience.
• Use the Bugs Tracking tool and search if this bug has exist in the past.
  Example: A new bug has been discover, search in the database, if it has already exist, (bug status closed) then it has to be reopened otherwise you can create a new one.
• Do not listen to a developer on telephone when He ask for support, or need help and never trust totally what he says (depend on the person of course)! Always ask for the logs files, because most of the time, they tell the truth and based on my experience, nobody really read them!

No code is perfect, accept it

• Code is living! and like any living creature it is evolving (both in the good and bad way) Development time will or may improve some parts,
• Never trust a process ! Before judging that is your process who made the fault, please verify the previous process. (It let you think that you are one of the best programmer 3 minutes more ;-) Sometimes it can be a consecutive error, so only look at the first exception on top of the list.
• Bug in Apache frameworks or open source projects, of course their code is perfectible, people from Apache try to deliver highly reusable code, but they can not guaranty you that in some particular case it will always work. Remember that some database, OS are existing since 20 years and are constantly improved. So if you find a bug and find an elegant way to handle it, you can send them the corrected code with a short explanation. Do not forget that they do not have your particular application environment, and that they may need to reproduce all conditions before providing a correction to the community (and that's very time consuming).

Links, references

Log4j

Junit
"Developers write code. Unfortunately, developers also write defects, most of which are injected during the initial coding phase. The cheapest place to fix these defects is, likewise, during the initial phases of development. If you wait until function or system testing to catch and fix defects, your software development costs will be much higher. In this article , authors Scott Will, Ted Rivera, and Adam Tate discuss some basic "defensive" coding and unit testing practices to make it easier for developers to find defects -- and, more importantly, help to prevent them in the first place."
http://www-106.ibm.com/developerworks/java/library/j-arrive/?ca=dgr-jw17j-arrive

Cygwin

404SEF without mod rewrite

• 
• 

Details

Category: Mambo CMS

Published on Friday, 18 February 2005 00:00

Written by Administrator

Hits: 2881

Use 404SEF when you can not activate mod rewrite in apache because Your internet provider do not allow it....

1. Enable SEF in mambo configuration
2. do NOT rename the htaccess.txt
3. open /includes/sef.php and change this line: (~ line 217)
   return $mosConfig_live_site."/".$string;
   to
   return $mosConfig_live_site."/index.php/".$string;
   

Comment installer un tool d'accés à distance sur votre PC...

• 
• 

Details

Category: Tutorials

Published on Friday, 08 April 2005 00:00

Written by Administrator

Hits: 9907

Comment installer un tool d'accés à distance sur votre PC...
Version 1.0, copyright Walter Cedric, Licence FDL (GNU Free Documentation License)

Read more: Comment installer un tool d'accés à distance sur votre PC...

Bluetooth in secure mode vulnerable too

• 
• 

Details

Category: Cryptography

Published on Saturday, 04 June 2005 00:00

Written by Administrator

Hits: 8116

A SECURITY flaw could allow hackers to eavesdrop on cellphone conversations made on Bluetooth-based wireless headsets was revealed in april 2004...But at that time an expensive piece of hardware was needed. Now it is even worse a simple brute force while the device are doing keyring exchange... "Whitehouse showed in 2004 that a hacker could arrive at this link key without knowing the PIN using a piece of equipment called a Bluetooth sniffer. This can record the exchanged messages being used to derive the link key and feed the recordings to software that knows the Bluetooth algorithms and can cycle through all 10,000 possibilities of the PIN. Once a hacker knows the link keys, Whitehouse reasoned they could hijack the device." Now the new attack force the  two bluetooth devices to pair, they can work out the link key in just 0.06 seconds on a Pentium IV-enabled computer, and 0.3 seconds on a Pentium-III

 

Convert Your XBOX to NAS

• 
• 

Details

Category: HowTo

Published on Sunday, 29 January 2006 00:00

Written by Administrator

Hits: 18232

Tomshardware has an interesting articles for all XBOX modder which prefer having an original Network attached Storage instead of a game machine.

With the arrival of the Xbox360, there will soon be a buyer's market for its older sibling. Kevin Herring shows how to give an Xbox a new lease on life as a full-featured NAS.

• Part 1, convert Your XBOX to NAS
• Part 2, convert Your XBOX to NAS
• Part 3, convert Your XBOX to NAS
  

{mosgoogle}