HowTo:Debugging UBIK - Revision history

NWE: /* Isolation Testing */

2024-02-15T14:08:20Z

‎Isolation Testing

2024-02-15T14:02:50Z

‎Full Test System

2024-02-15T13:55:38Z

2024-02-15T13:52:20Z

2024-02-15T13:46:01Z

2024-02-15T13:28:35Z

2024-02-15T13:27:30Z

‎Debugging {{UBIK}}

2024-02-15T13:26:55Z

2024-02-15T13:24:28Z

2023-07-03T19:58:13Z

‎A general policy for debugging

@@ Line 54: / Line 54: @@
 With Who-Bert code and manually created test data, you can additionally set up a "mock" or "fake" situation, to test the behavior under very specific circumstances.
 The View Test Tool simulates how the web service assembles data for the client, ignoring the ACM meta definitions (context, scopes etc.).
 = Inspection =

@@ Line 36: / Line 36: @@
 ==== Full Test System ====
-To reproduce the problem with {{UBIK}}, you require a test setup. This usually means a local copy of the database the problem occurred with and an installation of the {{UBIK}} products relevant for the problem. It is important to use the same binaries, plugins and versions as in the system where the problem occurred.
+To reproduce the problem with {{UBIK}}, you require a test setup. This usually means creating a local copy of the affected database, and installing the {{UBIK}} products relevant for the problem. It is important to use the same binaries, plugins and versions as in the system where the problem occurred.
 Then, we can try to provoke the reported issue in the test setup. This might require getting more information about the issue.
 ==== Isolation Testing ====

@@ Line 228: / Line 228: @@
 The user has to perform a few additional navigation steps, but on the other hand, they have to make that choice anyway.
 We even help them selecting a pair of shoes by leading them through the right choices.
-As a nice side-effect, the result consists of much fewer shoes so it's computationally cheaper to load all the videos.
+As a nice side-effect, the result consists of much fewer shoes, so it's computationally cheaper to load all the videos.
-Optimally, the parameters for the filtering can be inferred even without the user inputting them explicitely, e.g., by looking at the wheather and the user's calendar (sunny wheather, hiking trip: probably not the rain boots).
+Optimally, the parameters for the filtering can be inferred even without the user inputting them explicitly, e.g., by looking at the weather and the user's calendar (sunny weather, hiking trip: probably not the rain boots).
 Anyway, in some cases the use-case can be rearranged so the amount of data and information presented to the user at one point in time is smaller.

@@ Line 66: / Line 66: @@
 = Hypothesizing =
-In order to narrow down the cause of the problem, we can try to formulate an idea what could have gone wrong. Optimally, we actually go and look for a proof, to see it happen in action, but it's always good to know potential error sources. In general, there are several common types of problems, and from another perspective, a set of common sources for such problems.
+In order to narrow down the cause of the problem, we can try to formulate an idea of what could have gone wrong. Optimally, we actually go and look for a proof, to see it happen in action, but it's always good to know potential error sources. In general, there are several common types of problems, and from another perspective, a set of common sources for such problems.
 === Visualizing the architecture and algorithm ===

@@ Line 189: / Line 189: @@
 === Leverage strengths ===
-Usually, he server is strong and fast, the mobile device not so much, and the network is a performance graveyard.
+Usually, the server is strong and fast, the mobile device not so much, and the network is a performance graveyard.
 If you want to waste as much performance and time as possible, then you try to maximize the amount of network interactions and shift all the workload to the client application.
 Vice-versa, leveraging the strengths in {{UBIK}} means to shift all the calculation and preparation to the server and deliver the results in a most compact way to the client in one request-response cycle.
@@ Line 271: / Line 271: @@
 [[Category:Best Practices (internal)|Debug a Customizing]]
 [[Category:FAQ|Debugging UBIK]]

@@ Line 30: / Line 30: @@
 <!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS -->
-[[Category:Best Practices (internal)|Debug a Customizing]]
-[[Category:Resources (internal)|Debug a Customizing]]
 = Reproduction =
@@ Line 272: / Line 272: @@
 [[Category:Best Practices (internal)|Debug a Customizing]]
 [[Category:Resources (internal)|Debug a Customizing]]

@@ Line 26: / Line 26: @@
 # '''Retest''': Test the fix
-== Debugging {{UBIK}} ==
+== Debugging a {{UBIK}} project ==
 <!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS -->
 = Reproduction =

← Older revision	Revision as of 13:26, 15 February 2024
(No difference)

@@ Line 24: / Line 24: @@
 ## Define the functional design (i.e., a suggestion for the desired behavior) as clearly and simply as possible.
 # Create a technical design for the solution
-## If we now the designated behavior, we can describe how to achieve it technically.
+## If we know the designated behavior, we can describe how to achieve it technically.
 ## That mostly means:
 ### Basic idea