2 + 3 = 10
7 + 2 = 63
6 + 5 = 66
8 + 4 = 96

9 + 7 = ?

The answer can be found in the first comment.

Question: For the integers between 0 and 100 (i.e. 1,2,3,4 etc.) – How many have the digit 7 in them?

Can you figure it out?

The answer can be found in the first comment.

More from Geek and Poke

I have had this book laying in my stack of books that I want to read for quite some time, so when I finally got around to reading it, I was really excited.

However, after reading it I felt a little bit disappointed, because I somehow had expected more.

If you wanted to, then you could probably sum up the content of book to a few lines (which some critiques seems to do).

1. Add a test.
2. Run test and see it fail.
3. Make some changes.
4. Run again and see it succeed.
5. Refactor and start over.

The book doesn’t build on real world examples but instead shows how to get your mindset tuned in to start using TDD. It would have been nice with a set of best practices on naming conventions, how to write tests effectively, and where to put your test in your project. Every time I look at a new project, I often see it written in a completely different style than the last one.

If you are looking for a good and simple introduction to test-driven development, then this is the book. If you want something that explores the subject a little bit deeper, then should probably try to find another book.

However, I would recommend every developer to explorer the benefits that come with TDD, like higher quality in your code.

“The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.” – David Hyatt

When I first read this, I got one of those Aha! Moments, because I always thought that CSS selectors was interpreted left to right.

1

#foobar a { color: black; }

If we take our example from above, this would mean that instead of just checking for anchor elements inside foobar, the browser will lookup all anchors in the page. Instead of just checking each anchor’s parent, the browser will crawl the document tree, trying to find an ancestor with the ID foobar and it will continue up the tree of ancestors until it reaches the document root.

These guidelines was put forward by David Hyatt, a Safari and WebKit architect.

Avoid universal rules

It is recommended that you use ID, class and tag selectors.

Don’t qualify ID-categorized rules with tag names or classes

Since there can only be one element in the page with a given ID, there is no need to add extra qualifiers.

1
2

NO – div#foobar
YES  - #foobar

Don’t qualify class –categorized rules with tag names

Instead of qualifying class selectors for specific tags, extend the class name to be specific to the use case.

1
2

NO – div.foobar
YES - .foobar

Try to put rules into the most specific category you can

Don’t be tempted to build long selectors, because it can be the biggest slowdown in the system. It is better to be specific and add a class to the appropriate elements.

1
2

NO – ul li a
YES – .list-anchor

Avoid descendant selectors

Watch out for this one, this is really an expensive operation and should be avoided. This can often be replaced with a child selector.

Avoid tag-child selectors

Don’t use a child selector that is based on a tag, it is better to use a class that is associated with the tag; this can really improve the matching time.

1
2

NO - #foobar > li > a
YES - .foobar-anchor

Question all usages of the child selector

In general you should be careful about the child selector and it would be a good idea to avoid them.

Rely on inheritance

Learn which properties are inherited, and avoid rules that specify these inherited styles.

Should I use them?

Well, the answer is; it depends. First you need to be sure that you are focusing on the right problem. Not all pages will be affected, it basically comes down too how much stuff you put into it. The more complex, the greater the chance is that your page will be slowed down significantly (a couple of seconds).

Second, not all complex selectors affect performance, because it comes down to the key selector, the rightmost argument.

Consider this

1

Div div div a.myclass {…}

This can be ok, because our key selector is a.myclass, which might only match one or few elements.

1

a.myclass * {…}

However, this is really bad because it will check every element to see if it is descendant of an anchor with the given class.

Final Word

You might be thinking what about the CSS quires, which I use with my favourite javascript library. Those libraries read left to right because that is the way the DOM APIs work. So the guidelines mentioned above is only how the browser will render CSS, so when you are working with stylesheets, focus on right to left.

And be sure to focus on the once that are the most expensive once.

Further reading

Faster HTML and CSS: Layout Engine Internals for Web Developers

Simplifying CSS Selectors

Question

How many times will Console.Write() be called ?

1
2
3
4

for (byte i = byte.MinValue; i <= byte.MaxValue; i++)  
{
	Console.Write(i);
}

A little tip
Information about Byte Structure

This is something I have heard a lot in some form of variation. For some reason, it doesn’t seem to happen any other place. Why is that?

But what if it did.

I have made two extension classes; one is called EnumerableExtension and the other ArrayExtension. I have submitted the enum extension to the MvcContrib Project, but for some reason it seems like I have forgotten the array extension, so it might get submitted later on.

The PrototypeJS Api has some great examples on how these methods work, so if you want to learn more about them, then you should check that out.

I hope that you will find them useful.

The Enumerable Extensions

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

public static class EnumerableExtension
{
    /// <summary>
    /// Returns all the elements that match the filter.
    /// </summary>
    /// <typeparam name="TEnumerable"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="filter"></param>
    /// <returns></returns>
    public static IEnumerable<TEnumerable> GRep<TEnumerable>(this IEnumerable<TEnumerable> enumerable, string filter)
    {
        var regex = new Regex(filter);
 
        foreach (TEnumerable item in enumerable)
        {
            if (regex.IsMatch(item.ToString()))
            {
                yield return (item);
            }
        }
    }
 
    /// <summary>
    /// Returns the results of applying the iterator to each element.
    /// </summary>
    /// <typeparam name="TEnumerable"></typeparam>
    /// <typeparam name="T2"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="func"></param>
    /// <returns></returns>
    public static IEnumerable<T2> Map<TEnumerable, T2>(this IEnumerable<TEnumerable> enumerable, Func<TEnumerable, T2> func)
    {
        foreach (TEnumerable item in enumerable)
        {
            yield return func(item);
        }
    }
 
    /// <summary>
    /// Returns all the elements for which the iterator returned false.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="match"></param>
    /// <returns></returns>
    public static IEnumerable<T> Reject<T>(this IEnumerable<T> enumerable, Predicate<T> match)
    {
        foreach (T item in enumerable)
        {
            if (!match(item))
            {
                yield return item;
            }
        }
    }
 
    /// <summary>
    /// Incrementally builds a result value based on the successive results of the iterator. This can be used for array construction, numerical sums/averages, etc.
    /// </summary>
    /// <typeparam name="TEnumerable"></typeparam>
    /// <typeparam name="TMemo"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="accumulator"></param>
    /// <param name="func"></param>
    /// <returns></returns>
    public static TMemo Inject<TEnumerable, TMemo>(this IEnumerable<TEnumerable> enumerable, TMemo accumulator, Func<TMemo, TEnumerable, TMemo> func)
    {
        enumerable.Each(item => accumulator = func(accumulator, item));
 
        return accumulator;
    }
 
    /// <summary>
    /// Incrementally builds a result value based on the successive results of the iterator. This can be used for array construction, numerical sums/averages, etc.
    /// </summary>
    /// <typeparam name="TEnumerable"></typeparam>
    /// <typeparam name="TMemo"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="accumulator"></param>
    /// <param name="func"></param>
    /// <returns></returns>
    public static TMemo Inject<TEnumerable, TMemo>(this IEnumerable<TEnumerable> enumerable, TMemo accumulator, Func<TMemo, TEnumerable, int, TMemo> func)
    {
        enumerable.Each((item, index) => accumulator = func(accumulator, item, index));
 
        return accumulator;
    }
 
    /// <summary>
    /// It lets you iterate over all the elements in a generic fashion, then returns the Enumerable, thereby allowing chain-calling.
    /// </summary>
    /// <typeparam name="TEnumerable"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="iterator"></param>
    public static void Each<TEnumerable>(this IEnumerable<TEnumerable> enumerable, Action<TEnumerable> iterator)
    {
        for(var i = 0; i < enumerable.Count(); i++)
        {
            iterator(enumerable.ToArray()[i]);
        }
    }
 
 
    /// <summary>
    /// It lets you iterate over all the elements in a generic fashion, then returns the Enumerable, thereby allowing chain-calling.
    /// </summary>
    /// <typeparam name="TEnumerable"></typeparam>
    /// <param name="enumerable"></param>
    /// <param name="iterator"></param>
    public static void Each<TEnumerable>(this IEnumerable<TEnumerable> enumerable, Action<TEnumerable, int> iterator)
    {
        for (var index = 0; index < enumerable.Count(); index++)
        {
            iterator(enumerable.ToArray()[index], index);
        }
    }
 
    public static string ToJSON<T>(this IEnumerable<T> enumerable)
    {
        var serializer = new JavaScriptSerializer();
        return serializer.Serialize(enumerable);
    }
}

The Array Extension

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public static class ArrayExtension
{
    /// <summary>
    /// Produces a new version of the array that does not contain any of the specified values.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="array"></param>
    /// <param name="values"></param>
    /// <returns></returns>
    public static T[] Without<T>(this T[] array, params T[] values)
    {
        return array.Reject(t => values.Contains(t)).ToArray();
    }
}

Further Reading

More about the keyword Yield

Extension Methods

The party is in Norway, so it took awhile to get here (I live in Denmark), but it is worth it. We wont compete in any of the demo compos, since we haven’t got anything prepared, but one of our musicians is going to compete in the 16k executable compo.

Here are a few cool 4k intros

Receptor by tbc

Evelated by rgba and tbc

Luminagia by Loonies

It is amazing to see what people can get out of just 4kb