-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathnotes.txt
More file actions
54 lines (39 loc) · 3.04 KB
/
Copy pathnotes.txt
File metadata and controls
54 lines (39 loc) · 3.04 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
I was very slow to start, was not sure to understand...
Regarding the three version, initial approach was to write a first workable and 'readable' version,
then to branch from it in github when satisfied for 'speed' and 'extensibility'.
as a first step, I decideD to make it work with one single word and its "subwords".
first version was only displaying the list of subwords. second one was displaying
the concatenated word along its subwords: a hash was introduce at this step to store result.
Then few other tests were added to cover some edge cases and real example
A Set was then introduce to store possible subwords to speed the search.
Along the way, I changed my mind and decided to go for the 'speed' version then to tag and from there move
to readability and after extensibility.
*Speed* (Master Branch)
The 'pre parsing' concept was then introduce to minimize complete words list traversal. Unfortunately,
it did harm readability.
Use of ruby IO was one of the coolest discovery in the exercise. First it did ease testing a lot and second,
it provided the file loading support out of the box. In fact, did not really had to do something for
file support, appart testing the fact that it was already working :-)
Exploring ruby collections was also really interesting. The many ways to iterate and how to use code block
in this context was very refreshing.
After first version I was satisfied of (tag v1.s) I decide to do some exploratory test to visually see the
list of potential words that were rejected by my program. I create a small script on the side (explore.rb) to
compare to make like a "diff" between the two list. Surprise! I was not taking care of Upper/Lower case...
Made another interesting discovery on the language: the capacity to substract two set of values to
identify differences.
*Extensibility*
For the extensibility version I decided to try to implemented something like a "Strategy pattern" using
inheritance. So I created a new branch in git and initially guide myself with this post:
http://www.codercaste.com/2011/09/27/the-strategy-design-pattern-in-ruby/
Although this solution finally work and I was able to re-use part of the code to create
another type of finder (word finder with regex), I realize that hierarchy was not so beneficial
regarding re-use because many element to be re-use were part of methods but not complete
method.
Of course, this version showed a small drop in performance/speed for the "loading phase" because with this
design the dictionary is parse two times. On the other side this does not have a big impact on overall performance
of the program as "search phase" always take way more time. Overall performance decrease was by an average of 25-30%.
*Readability*
In order to improve readability this version do not use 'single pass' dual array loading (word candidate & subwords)
and re-introduce find_all to filter on loading (see earlier versions). Effort was also made in
order to make find_concats more verbose by using start_with? and end_with?. With this version overall
performance decrease was by more than %300.