Exact String Matching in Practice
Initially I was interested in string search from an academic view point - just understand the algorithm and be able to implement it. After this passion culminated in the project (StringSearchAlgorithms), I began to compare it to others …
It became obvious that many algorithms worked in theory, but were slow or even failing in practice. Actually most academic algoirthms on string search are optimized for a certain situation dependent on:
- programming languages and APIs
The following sections describe the challenges string search is confronted to in practice.
Testrecorder – Next Steps
After Presenting at Karlsruher Entwicklertag it is time to write a few words about the future of Testrecorder … Testrecorder is a Java tool vor recording runtime situations. Recording means, that we intercept method invocation and capture the state before and after the invocation. From this captured state we generate JUnit-tests.
Naming of Interfaces and Implementations
Which is your naming convention for implementation classes? Do your prefer
Intrinsically I should be pleased about this question - at least someone seems to care about naming conventions … but sorry, both conventions are little more than crap. Unfortunately these patterns are very popular, so my criticism will have little effect. Here you are:
String Search in Java (using the JDK-API)
String search is a common problem, appearing every time we check that a string is contained in another. The JDK Standard API provides some basic functionality for this, yet there are more efficient algorithms for larger patterns and larger texts.
In this posting I present an overview over the string searching features of the Java API, starting with a short definition of string searching and ending with an overview of libraries that provide more features for string searching (more details will follow in later postings).
Accessing Private Fields and Methods with XRayInterface
This posting is about accessing private fields and methods, by adopting a foreign interface to a given java class (not already implementing the given interface). Why? Yet, in my former posting about Repairing Legacy Code I mentioned the challenge of accessing hidden state (private fields) before and after method invocations.
Repairing Legacy Code - Automatically
Many Projects already use automated regression testing. Unfortunately we cannot rely on this in situations that afford them most, for maintaining foreign (untested) legacy code. Here I do not only wish for automated regression tests, I also wish for automated test generators. Why does such a tool not exist?
Meet me at Entwicklertag 2018. Urs Metz and myself will present an overview of tools for automatic generation of tests.
I offer a Workshop on Testrecorder at XP-Days 2017. Everyone that visits the session, will be presented a refactoring of a selected “Legacy Code”-project following the method:
- Record (Capture some Tests)
- Refactor (Simplify the Code)
- Replay (Execute the Tests)