tripu

Via Kirai I stumbled on the results of this survey that collects information about erogenous zones. Apparently, thousands of men and women were asked to rank different spots in their bodies and the bodies of a partner — in terms of how much they they like to be touched, and how much they desire to touch the other, respectively.

The study is interesting, but I found it somewhat annoying that it is difficult to draw what seems to me like an important conclusion: a comparison between where we think that the other likes to be touched and where he or she actually likes to be touched the most. The body maps provided show coloured zones, but it is difficult to compare women’s guess to men’s desires, for instance, because the variations in hue are quite subtle. Even if the images are displayed side-by-side, bare-eyed it is hard to notice any change at all in most regions of the body.

I am always up for a bit of a Gimp-challenge. So I decided to try and edit the original images to obtain a better representation. This is my take on the results of the survey:

The hot colours (no pun intended) dye areas where we are not touched as much as we would like, so to speak. That is yellow, orange, pink, violet and red. In less academic terms, you could read cool colours, i.e. all shades of blue, as “will you put your hand off now”. I find it much easier here to identify those areas at a glance.

Now there are some interesting results in here. Boys, did you notice those three orange/red spots in the female body? That’s good news or what. Also, it seems that she doesn’t like to be touched in her head and face that much, except that apparently you are not kissing her enough. Oh, and for some reason her right arm expects more attention than her left arm (?). About men, feet and knees look a bit frustrated, in contrast with the arms, which are asking for some independence and need more space, you know, to live their lives or whatever. Penises demand more attention (yes, even more). But not the scrotum. The scrotum is fine, thank you.

The diagram below summarises the process that I followed using Gimp. The female images are used here, but the same applies to the other case. The single most important step, on the left side of the image, involves inverting the colours of the image that represents where women are touched, and then adding it to the picture that represents where women want to be touched. Effectively, we are substracting one from the other. The branch at the bottom simply emphasizes colours to make them more apparent. The steps on the top-center of the image produce black-on-white edges that are used as a frame so that regions of the body become more recognisable.

http://dtree.tripu.info

The other day I wanted to have an overview of the size of a software project I’m working on. The project is relatively big and involves quite a few languages and technologies spread among different tiers. Because I just joined the team there are tons of lines of code already written that I have not even seen. So I felt the need to have at least a grasp of the size of the codebase for each language and learn how programming languages compare among them within the project.

I came up with this very simple Bash script, getSizeStats.sh. It expects one or more directories as parameters. It finds all regular files contained in the trees that hang from those directories. It then adds up LOC for all files, grouping by the extension of the filenames. The script assumes that the arguments are, or might be, local copies of Subversion repos (that’s why it excludes .svn directories). While running, the output line shows a counter for the number of files as they are processed. Once finished, a list of LOC for each language (i.e. file extension) sorted by LOC is created in /tmp/getSizeStats.sh.out.

#!/bin/sh
 
TMP_DIR=/tmp/`basename $0`
TMP_OUTPUT_FILENAME=/tmp/`basename $0`.tmp
OUTPUT_FILENAME=/tmp/`basename $0`.out
 
if [ -d $TMP_DIR ]; then
    rm $TMP_DIR/* 2> /dev/null
else
    mkdir $TMP_DIR
fi
 
COUNTER=0
 
find "$@" -name "*.*" | grep -v \.svn | while read j; do
 
    if [ -f "$j" ]; then
        cat "$j" >> $TMP_DIR/`echo $j | rev | cut -s -d "." -f 1 | cut -d "/" -f 1 | rev`
        COUNTER=$((COUNTER + 1))
        echo -en "\r$COUNTER files "
    fi
 
done
 
if [ -f $TMP_OUTPUT_FILENAME ]; then
    rm $TMP_OUTPUT_FILENAME
fi
 
for i in `ls $TMP_DIR`; do
    echo -e "`wc -l $TMP_DIR/$i | cut -d " " -f 1` $i\t`wc -l $TMP_DIR/$i | cut -d " " -f 1`" >> $TMP_OUTPUT_FILENAME
done
 
sort -nr $TMP_OUTPUT_FILENAME | cut -d " " -f 2- > $OUTPUT_FILENAME
rm $TMP_OUTPUT_FILENAME
 
echo processed -- see $OUTPUT_FILENAME
 
# EOF

(I think that for some versions of echo you’ll have to remove the option -e or it won’t work properly).

The only serious problem I found were filenames containing blanks and other characters that usually need to be escaped (bad naming, I know — it wasn’t my idea). I played with different types of quoting and tried to find a workaround for that. Real-time help about that from @enlavin and @nauj27 was much appreciated. I tried that find -print0 | xargs -0 … thing but couldn’t make it work as I needed. Eventually the while read j; do … approach worked. (I confess that I still get confused easily by the subtle differences between quoting variants and how variables get expanded in each case. I ought to find some time to learn that well, once and for all).

Now there are so many things to improve here. First of all, the script does not tell binary files from text files, i.e. you will also get counts of “lines of code” for all binary assets within your project, such as object files and images. It should also discard all text files that are not source code, e.g. a CHANGELOG. It should be robust to case variations, i.e. group .java and .JAVA files together. It should rely on something more sophisticated than filename extensions to tell programming languages, because you probably want to count your .cpp and .c++ files as a whole.

I was planning to better it adding those fixes/improvements and others. Then Golan told me of sloccount, a command that does just what I need. But proper.

Here you have an example of how getSizeStats.sh works. After re-inventing the wheel, I couldn’t but run my own script… against the source code of sloccount itself.

$ svn co https://sloccount.svn.sourceforge.net/svnroot/sloccount sloccount-src > /dev/null
$ ./getSizeStats.sh sloccount-src/
38 files processed -- see /tmp/getSizeStats.sh.out
$ cat /tmp/getSizeStats.sh.out 
c       4493
orig    3899
html    3032
1       235
dat     197
l       171
rb      152
lhs     59
spec    56
h       50
CBL     31
php     27
inc     23
pas     21
hs      19
gz      10
f       10
cs      8
f90     7
cbl     4
tar     1

“The fact that all these [programming] languages are Turing-equivalent means that, strictly speaking, you can write any program in any of them. So how would you do it? In the limit case, by writing a Lisp interpreter in the less powerful language.

That sounds like a joke, but it happens so often to varying degrees in large programming projects that there is a name for the phenomenon, Greenspun’s Tenth Rule:

‘Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.’

If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one. […]

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about ‘patterns’. I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough — often that I’m generating by hand the expansions of some macro that I need to write.”

— Paul Graham, “Revenge of the Nerds”.

If you are a software developer, a web designer or some other sort of techie it’s very likely that you have been hearing and/or reading about Adobe Flex lately. Well, if you aren’t using it yourself but feel curious about it, or if you just want to have a notion, this extremely quick introduction is for you. Skimming through this post will not turn you into a Flex developer, but it will allow you to nod confidently and even drop some canny words the next time that Flex pops up in a conversation around the watercooler.

First things first — what Adobe Flex is not:

• It is certainly not a tool for generating lexical analysers ;¬)
• It’s not “the new version of Flash” (FKA “Macromedia Flash”). Development of Flash is on-going and the two products coexist. Flex hasn’t replaced (and won’t replace) Flash anytime soon, the reason for that being that…
• …Flex is not “an alternative to Flash”. Sorry to disappoint you, but Flex is not a way to get rid of the dependence on the Flash Player. Actually Flex is built on top of Flash and needs Flash Player to run.
• It’s not a technology to build large, native apps that need to work close to the underlying platform or which performance needs to be optimised (read below to see why I believe this).

Flex in a nutshell (a rather small nutshell):

Flex is an attempt by Adobe to make Flash attractive to, and suitable for, many software developers who were disregarding Flash as something not serious enough to use for developing “proper software”. Adobe has done a praiseworthy effort in that sense and has brought Flash to the realm of OO programming. Adobe used Eclipse to develop Flex Builder. Flex Builder alone does a lot to make old-skool software developers feel at home — it’s a proper IDE with all the features you would expect, plus the extensibility (and the slowness, I’m afraid) of Eclipse.

Flex developers use the Flex SDK (command line compilers and component class library; free as in “freedom”) and the Flex Builder (the IDE) to build their applications. Flex apps are written mainly in two languages:

• Actionscript, an ECMAScript-based language that exists since the first Flash Player.
• MXML, a loose, proprietary implementation of XML used to define GUI elements.

The output of a Flex project is one or more Flash files (.swf). In terms of the approach to the development process, the single most important change from Flash to Flex is probably removing the “movie” way of thinking. Flash animators are used to the “movie paradigm” in which the time is an essential concept. In their animations they have been working with key concepts like “timeline”, “frame” and “loop”. Flex abandons that approach.

I have found that, in general, software developers without any experience with Flash get used to Flex even faster than Flash designers who don’t know much about programming.

What Flex is good at:

• Rendering cool interfaces. Animations, transitions, effects, gradients, reflections, customised skins, embedded movies, nice charts, changes in opacity, layouts that are resized well when their container is resized, etc. For a demo, check the Flex 2 Component Explorer.
• Working on all major desktops and web browsers and many mobile devices. OS’s: Windows, Mac OS, Linux and Solaris. Browsers: IE, Gecko-based browsers, Safari, Opera. Mobile devices: many, and more to come.
• Keeping the same “look & feel” everywhere. You can see the default Flex 2 “look & feel” in the Flex 2 Style Explorer.
• Integrating and communicating with other Adobe formats. Flash movies, Acrobat documents, ColdFusion, Dreamweaver, etc.

What Flex is not good at:

• Computationally expensive software. As we saw before, Flex stresses GUI aesthetics, intuitive design, portability, compatibility with existing Flash files and other Adobe tools, easy deployment, etc. And it was aimed at the web (in spite of Air). So don’t expect it to be any good at doing system calls, invoking hardware drivers, messing with the network at low-level, fine-tuning loops to save cycles of CPU, dealing with gigabytes of data, delivering real-time, etc. Because Flex apps are deployed as Flash files, every Flex app “lives” inside the Flash security sandbox, which prevents it from accessing many of the resources of the computer. Also, Flash is a proprietary format that doesn’t run natively but is interpreted by the Flash Player. That extra layer of translation decreases the performance.
• Classic Flash stuff. Don’t bother to learn Flex if all you need to do is Flash banners and simple animations. For that you will need a timeline, drawing tools and accuracy at pixel-level. Flex is not designed for that.
• Being extrovert with its neighbours. I hear that even Air makes it quite difficult to launch an external executable from a Flex application.

Now, the “hello world” is mandatory, so here it goes.

This application simply displays a customised greeting (it’s a “hello world” on steroids). We’ll make the GUI inherit from the layer that processes the information, in a “code-behind” manner.

First, the Actionscript class contained in the file info/tripu/blog/flex/SimpleApp.as. This class extends the standard Application class and defines what to do with data:

package info.tripu.blog.flex {
 
    import mx.controls.Alert;
    import mx.core.Application;
 
    public class SimpleApp extends Application {
 
        public function greet (who:String): void {
            Alert.show ('Hello, ' + who + '!');
        }
 
    }
 
}

Second, the MXML application HelloWorld.mxml. It defines the GUI by using an instance of the class SimpleApp and adding a couple of visual controls to it. Notice how the AS class that we created before is now used straight as an XML element:

<?xml version="1.0" encoding="utf-8"?>
 
<tripu:SimpleApp xmlns:tripu="info.tripu.blog.flex.*" xmlns:mx="http://www.adobe.com/2006/mxml">
 
    <mx:TextInput id="user" text="world" />
    <mx:Button label="Greet" click="{greet (user.text)}" />
 
</tripu:SimpleApp>

The result of compiling those two files in a Flex project is this Flash file, HelloWorld.swf (you’ll need Flash Player version 8 or above to see the embedded Flash object):