37 posts tagged “computing”
It's always interesting to look at the way in which people overcome the problem of navigating the web. The problem being that nowdays content is full of sidelines and links. As you're reading your favourite blog (mine, surely ;)) they might link to another post, such as this one about The Problem With Tabbed Interfaces. From there you might be intreaged by Cyrus Najmabadi's post. And from there Tabbrowser extension. Before long you've got a long list of things to read. Even before you're finished with Jeff's post there are 10 possible other interesting pages to read, and that's excluding the comments. Reach into each of these and there are hundreds of possible fasinating webpages.
If you're anything like Jeff that means you will have one or two browser windows with hundreds of tabs (despite this coming up a few times in his blog I annoyingly can't find any references to it now). If you're anything like me that means you'll have five or six browser windows with six or seven tabs each as I split things up into logical chunks. Maintaining and navigating this hodgepot of links is a difficult task.
This is because navigation is a tree, but most browsers like to make you think it's a list. A list is easy enough for people to understand. With under 10 items it's easy enough to maintain. The trouble is it just doesn't scale.
Back to Jeff's post - here's what links one may visit organised firstly as a tree in which you can easily understand what links to what, giving you the context of how it relates to other content.
The Problem With Tabbed Interfaces
- iRider
- Make Vista's Alt+Tab Thumbnail Bigger
Obviously once you get to Wikipedia there's no end of interesting things. And from every website on the internet you will almost always get to Wikipedia. And then never leave.
The cosmological argument, via Where's Waldo, is bizaarly removed from the problems with tabbed interfaces. But nether the less, that's inevitably how people navigate the web. So what does this bizaar sequence of interesting reads look like in Firefox as I'm browsing?
The Problem With Tabbed Interfaces I hate tabs in web browsers Tabextension3 Outsider FAQ iRider iRider Download Make Vista's Alt+Tab Thumbnail Bigger Where's Waldo? Where's Waldo (TV Series) HIT Entertainment Thomas and Friends Anthropomorthism Cosmological Argument
Except whilst doing that I was talking to a couple of people on IM, and one of my friends always sends me about 4 links as a replacement for the traditional "Hello, how are you?" so it really looks like this:
The Problem With Tabbed Interfaces I hate tabs in web browsers Openmoko Tabextension3 Outsider FAQ iRider Apple March 6th Event iRider Download Make Vista's Alt+Tab Thumbnail Bigger Audiosurf Where's Waldo? Where's Waldo (TV Series) HIT Entertainment Thomas and Friends Anthropomorthism Cosmological Argument
What links are related to the origional post? Which are the one's my friend sent me? How on earth did I get to Thomas and Friends? Who knows.
Interestingly IE uses a kludged tree. All the links you open from a webpage open in a list of new tabs after the current one. This means that you get a tree, only flattened into a list. It's quite confusing at first, but once you realise what it's doing it's useful at times. But why squash it into a list?
There's probably a plugin to make Firefox use a tree for tabs, but I've yet to find it.
My favourite feature of Visual Studio 2008, I've decided, is automatic properties. I say they're a feature of VS2008 because you can use them in code that targets .NET 2.0 - after all the compiler just expands them out like a code snippet. I've been forced to work with VS2005 recently (for the XNA Studio) and I really miss them, my code is begining to look like a mess with the expanded properties everywhere.
If you've not come across automatic properties before, they take this:
and turn it into:private string name;
/// <summary>
/// The name of the employee.
/// </summary>
public string Name
{
get { return name; }
set { name = value; }
}
A lot cleaner and more readable! The compiler generates the backing variable for you, which is great because most of the time properties are just simple accessors for fields. Of course, if you need to do more exciting stuff like validation you can still use the full property./// <summary>
/// The name of the employee.
/// </summary>
public string Name { get; set; }
Even if you know about automatic properties, you may not have come across this very useful trick:
If you've got an automatic backing variable, there is no way to assign a value to it, so you can't create read-only variables by ommiting the set accessor. The solution to this is to make the set accessor private such that the property can only be set from inside the containing class. What I really like about this is that it means, with a proper naming convention, it's now more obvious when you're modifying a property rather than a field. But then I guess it's not less obvious when you're modifying a read-only property. Swings and roundabouts./// <summary>
/// The amount of stock left.
/// </summary>
public int StockCount { get; private set; }
This is all a very long winded way of saying "I miss you automatic properties, but I'll be home soon, I promise!"
It always annoys me when websites force links to defaulty open in a new window/tab (from now on referred to as window). It strikes me as an arrogant assumption of how you want to browse - you want to keep their websites open when in fact the truth is sometimes - a lot of the time - I don't. It is also a major distraction to browsing continuity as most browsers will defautly focus the newly opened window.
It is trivial to open something in a new window yourself - in most browsers a middle click will do it, and a Ctrl+Click if not (though almost all mice now have middle mouse buttons and touchpads some combination that makes it possible). There are arguments that some find precise click difficult, and so will often accidentally activate the mouse scroll feature instead. In my personal experience I have found people have little problem with this, but I have seen no actual evidence for either. If it does happen to be a problem for a small section of users it can be turned into an accessibility feature.
With this in mind, surely it makes much more sense to give the power over to the user? Let them decide whether they want something to open in a new window or not. This would create a consistency - they know what to expect when they click on a link. Without some visual indication as to whether the link will open in a new window or not it can get confusing, and the visual indications would become a clutter.
It's not just through laziness that web designers don't make offsite links open in a new window, it's arguably a good design practice.
As I move more and more towards a functional style of programming I often find myself using referentially transparent functions in amongst the rest of my C# code. A referentially transparent function is basically one that guarantees that it has no side-effects (modifies anything outside of the function) such that every time you call it with a particular argument it will give you the same result.
In these cases it is trivial to optimise it using momoization - that is caching the results for given inputs. However, it is a lot of redundant code to repeat the same caching mechanism again and again, and actually quite difficult when you start to try and get the correct balance between time and space with sophisticated caching algorithms. The ideal place for this would be in the CLR which has much better knowledge about the current demands on memory (think garbage collection).
To this end, I tentatively propose const methods. These are basically methods that are guaranteed to be referentially transparent by denying access to variables and non-const methods outside of the function (of course reference to constants are allowed). These could then be optimised using several different techniques. A const method is implied to be static (an instance method would allow access to the mutable state of the instance object - this.MutableProperty).
Below is an example syntax:
public const int Factorial(int x)
{
return x*(x+1)/2;
}
The lack of reference to variables outside of the function doesn't restrict the use of variables inside the function:
private const int Factorial(int x)
{
int tally = 0;
for (int i = 1; i <= x; i++)
{
tally += i;
}
return tally;
}
Note that this is slightly different to a const method in C++ which, afaik (though I may be wrong), is an assurance that it won't modify any state, but it can still read from it (which leads to the confusing situation that a const method is not referentially transparent - that is a const method isn't constant for a given input).
A lot of the library functions would have to be modified - though only to add the "const" keyword in most cases (some could be trivially re-written to be const).
Over the past few weeks I've been building a steadily growing collection of helper functions. I've gotten to the stage where I've had to write enough reduce functions, manually fill enough arrays and rewritten enough foreach as for loops to get sick of it and begin writing my own helper library.
Below is what I would say is the most useful to others that I would like to share. The purpose of it is to allow one to utilise a foreach loop over an enumerable collection whilst still being able to get at the index. In the past I have often found myself needing to use a for loop instead of a foreach loop simply because I needed the index of the item in the collection. I didn't need to do anything fancy with it, I didn't need to increment it by more than 1, I just needed to be able to refer to it.
A method is written that extends anything that implements IEnumerable, returning a custom enumerator. All this enumerator does is itself enumerate over the collection, yielding the current item along with it's index. Below is a sample usage.using System;
using System.Collections.Generic;
using System.Collections;namespace ICR
{
public static class Collections
{
public static IEnumerable<IndexValuePair<T>> GetIndexValuePairs<T>(this IEnumerable<T> collection)
{
return new IndexValuePairsCollection<T>(collection);
}public sealed class IndexValuePair<T>
{
public int Index { get; private set; }
public T Value { get; private set; }public IndexValuePair(int index, T value)
{
Index = index;
Value = value;
}
}private class IndexValuePairsCollection<T> : IEnumerable<IndexValuePair<T>>
{
private IEnumerable<T> Collection { get; set; }public IndexValuePairsCollection(IEnumerable<T> collection)
{
Collection = collection;
}public IEnumerator<IndexValuePair<T>> GetEnumerator()
{
int index = 0;
foreach (T item in Collection)
{
yield return new IndexValuePair<T>(index++, item);
}
}IEnumerator IEnumerable.GetEnumerator()
{
return ((IndexValuePairsCollection<T>)this).GetEnumerator();
}
}}
}
Sequence.Range is another helper function I have written that returns an object that enumerates over ints/floats/doubles/characters in a given range.foreach (var character in Sequence.Range('a', 'z').GetIndexValuePairs())
{
Console.WriteLine("{0}: {1}", character.Index, character.Value);
}
This code is concise with a clear intent. Compare with the alternative.
This also highlights another advantage - in the second example the sequence had to be stored in a local variable to allow for the multiple references to it (characters.Count and characters[index]). We did not have to do this in the first, allowing for a tighter and cleaner scope control.List<char> characters = (List<char>)Sequence.Range('a', 'z');
for (int index = 0; index < characters.Count; index++)
{
Console.WriteLine("{0}: {1}", index, characters[index]);
}
Our solution also allows one to get the index of any IEnumerable, something which is even more untidy to do with a for loop. (N.B. This is not always appropriate, but depends on the context of the IEnumerable)
Feel free to use the code yourself if you think it would help. Any suggestions and feedback would be welcome,
Amir regularly makes posts on his blog to show off the wonders of conciseness and clarity in Python. His latest offering is an interesting one. As with many of his examples, it shows off more a certain programming style promoted by Python over language features themselves. You can write the same thing in Java or C# with very little code overhead - just the extra verbosity of the syntax (the benefits and drawbacks of which are debatable). You do, however, have to make use of library functions that do not exist in the core libraries that do in Python.
But what is more interesting is how it compares with Linq in C# 3.0. Here is Amir's code from his post, followed by my own version written using Linq:
Amir's Python code*:
My C# code:for item in items:
child_ids = [int(id) for id in item.children.split(',')]if ids != child_ids:
new_list = filter(lambda x: x not in ids, child_ids)
db().update('items', id=item.id, children=','.join(new_list))
This is my first real delve into a more complex Linq example and I have to say it was very easy. The most complex part was working out how to make the first item the Id and the second a list, but once you realize just how first class a feature Linq is in C# it was very quick to come to the conclusion of a nested query. It's not something that must stand out separated from the rest of the code, you can just throw in a quick query here and there in the midst of other code. The only real wart in the code is the ToArray as the antiquated Join method takes a string array rather than an IList.var updatedItems = from item in items
select new
{
item.Id,
Children = string.Join(",", (from childId in item.Children.Split(',')
where !ids.Contains(int.Parse(childId))
select childId).ToArray())
};foreach (var updatedItem in updatedItems)
{
db().Update("items", updatedItem.Id, updatedItem.Children);
}
Both seem to me to be equally readable and maintainable, though the C# example does have a scary amount of code indentation. Overall though this has got me a little more excited about Linq than I had been.
* I have modified the code according to what I think Amir meant. I may be wrong.
Combining my desire to learn more about parsing and the need for an ability to check various truth tables I have made a program that will take an expression and output a truth table for it.
http://www.atomice.plus.com/TruthTables.zip
It was written in Python, so you'll need to download the runtime. You can either run it from the bat file, which will execute into a read-eval-print loop until you quit, or if you are more comfortable with the command line you can cd into the bin directory and use "python TruthTableConsole.py".
It currently only has a limited set of operators, including and (&), or (|) and not (!). You can combine these with single letter case-insensitive constants (a-z) and parenthesis like so:
E = a|b
a b | {E}
----+----
F F | F
F T | T
T F | T
T T | T
E = a|(c&!(a|b))
a b c | {E}
------+----
F F F | F
F F T | T
F T F | F
F T T | F
T F F | T
T F T | T
T T F | T
T T T | T
It takes precedence into account (similar to in arithmetic where you apply multiplication before addition) in the following order: &, |, !
As a point of extension I may add constants (i.e. the ability to write expressions like a|True), the implies and other operators and the ability to have more than one character in variables.
I've been reading Amir's blog for a while now, and I've noticed he quite often writes posts talking about the benefits of a functional programming style and of iterative development. Today, I am proud to say that I have iteratively developed some functional code.
The code is a simple unit-testing module written in Scheme in anticipation of my first programming assignment at University. The idea is to take a function, a list of arguments that the function could take and, given the function is evaluated with the given arguments, what output is expected. This can then be used on any functions I write to make sure that for a selection of normal and certain edge cases it functions properly.
My first attempt was a wonderfully functional one liner:
(define (test func arguments expected-results)
(map equal? (map func arguments) expected-results)
)
Map is a functional idea that applies the given function to each of the elements in a list and returns a list with the results, so the expression (map odd? '(1 2 3 4 5)) will return (#t #f #t #f #t). If the function takes more than one argument, more than one list can be given and the nth item from each list will be used as the arguments, so (map + '(1 2 3) '(4 5 6)) gives (5 7 9).
My first try first applies the function to each of the arguments in the list, and then goes through each one and checks to see if it matches the expected-result, which is what we want. However, there is a limitation in that the function we are testing can only take one argument. You can get around this by wrapping up the function in a lambda expression, like so:
(test (lambda (arguments) (+ (car arguments) (cadr arguments))) '((1 2) (3 4)) '(4 6))
However, this is unwieldy and complicated for something which is a common need. It basically creates an inline function that extracts the first and second item in a list and adds them. Using a similar technique we can test functions with many parameters. However, we can improve on this.
(define (test func arguments expected-results)
(map equal? (map (lambda (argument)
(apply func argument)
)
arguments
)
expected-results
)
)
Now instead of simply mapping the function to the list of arguments we map an inline function which applies the function to a list of arguments. This allows us to write tests like so:
(test odd? '((1) (2) (3) (4) (5)) '(#t #f #t #f #t))
(test + '((1 2) (3 4)) '(4 6))
Notice we have removed the need to wrap up non-unary functions in lambda expressions, but have added the need to enclose single arguments into their own, one element list. These are the sorts of trade-offs you often find yourself needing to make.
The problem now is that the expected-results are orphaned from the arguments. This means that to check you're tests you must count along to, say, the 3rd argument list, and then again along to the 3rd expected-result to check you've done the test right. Far simpler and less error prone to bind the two more tightly, like so:
(test + '((1 2) 3)
'((3 4) 7)
'((5 6) 11)
)
Here we have a list of tests, the first element of which is a list of the arguments and the second the expected results. To allow for this, our test must be re-written like so:
(define (test func . params)
(map (lambda (param)
(equal? (apply func (car param))
(cadr param)
)
)
params
)
)
We now go through each test, evaluate the function with the argument list, and then check it matches the expected-value. The code is a little longer and ever so slightly harder to follow, but the way in which we use it is arguably more simplistic and less error prone.
There are further improvements that can be made such as improving the output to, for example, display the result if it does not match with what is expected. Maybe I'll post the code if I ever do it.
Update:
I have spent a bit of time reworking the code into something that gives more expressive results whilst not compromising on the flexibility of simply returning a list of what succeeded and failed. What I came up with was to prepend whether the test succeeded to the original test, and append the actual result to the end, allowing a very simple check to see which tests failed and which succeeded (you can see this in the following code where the option is given to only print failed tests using the filter function). I then wrote some functions to print out the results in a more readable manner. I will post the code if only for completeness, but due to the addition of some limited object-orientation I rather feel it would be overkill to explain it blow by blow, especially as the core idea of algorithm remains mostly the same.
(require 'object->string)
(define (create-test func arguments expected-result)
(list func arguments expected-result)
)
(define (create-tests func . argument-result-pairs)
(map (lambda (argument-result-pair)
(create-test func (car argument-result-pair) (cadr argument-result-pair))
)
argument-result-pairs
)
)
(define (test-func test)
(car test)
)
(define (test-arguments test)
(cadr test)
)
(define (test-expected-result test)
(caddr test)
)
(define (create-test-result test)
(let ((result (apply (test-func test)
(test-arguments test)
)
)
)
(list (equal? result
(test-expected-result test)
)
test
result
)
)
)
(define (test-result-succeeded test-result)
(car test-result)
)
(define (test-result-func test-result)
(car (cadr test-result))
)
(define (test-result-arguments test-result)
(cadr (cadr test-result))
)
(define (test-result-expected-result test-result)
(caddr (cadr test-result))
)
(define (test-result-result test-result)
(caddr test-result)
)
(define (print-test-result test-result)
(print (string-append "Test "
(object->string (test-result-func test-result))
(if (test-result-succeeded test-result)
" succeeded"
" failed"
)
" ["
(object->string (test-result-arguments test-result))
" => "
(object->string (test-result-result test-result))
(if (not (test-result-succeeded test-result))
(string-append " (expected "
(object->string (test-result-expected-result test-result))
" )"
)
""
)
"]"
)
)
(test-result-succeeded test-result)
)
(define (print-test-results test-results print-all)
(if print-all
(map print-test-result test-results)
(map print-test-result (filter (lambda (test-result)
(not (test-result-succeeded test-result))
)
test-results
)
)
)
)
(define (test tests)
(map (lambda (test)
(create-test-result test)
)
tests
)
)
One interesting thing to note is that with the addition of the object-orientation it made sense to more tightly bind the function being tested with the arguments and expected outputs. However, in the frequent case of applying more than one test to the same function to avoid having to repeat the function over and over I have written a create-tests function who's syntax more closely mimics my original idea. The code can now be invoked as follows:
(print-test-results (test (create-tests + '((1 2) 3)
'((3 4) 7)
'((5 6) 11)
)
)
#f
)
Not quite as succinct as the original, again displaying the decisions one has to make when programming.
Apparently lots of people get drunk and send emails or texts that they later regret sending. With these technologies it is very difficult (almost impossible) to stop it being received (with "hilarious" stories as to how they prevented the person from checking their inbox) as it is lost in "the system". "The system" is what makes it so rwopobust, but it's also what prevents you from being able to stop emails.
On other sites that provide a PM feature, though, there is no system for it to get lost in. It sits on the server until the person receives it. Still there is no ability to delete the message once you have decided you didn't actually want to send it though.
Apparently lots of people get drunk and send emails or texts that they later regret sending. With these technologies it is very difficult (almost impossible) to stop it being received (with "hilarious" stories as to how they prevented the person from checking their inbox) as it is lost in "the system". "The system" is what makes it so rwopobust, but it's also what prevents you from being able to stop emails.
On other sites that provide a PM feature, though, there is no system for it to get lost in. It sits on the server until the person receives it. Still there is no ability to delete the message once you have decided you didn't actually want to send it though.
