Harvesting energy from WiFi and GSM networks?

By Confusion on Sunday 10 January 2010 21:21 - Comments (21)
Categories: Science, Technology, Views: 5.828

Source: Oh Gizmo, Engadget

At CES 2010, a company called RCA has presented a device called 'Airnergy', which is supposedly able to harvest energy from WiFi (and GSM) networks, for instance to charge your cellphone. Now this raises immediate suspicions: if that is possible, why aren't mobile devices powered by these networks in the first place? However, given the feeling that we are surrounded by a vast multitude of such networks, it still sounds remotely plausible. The only way to determine whether this makes sense, is to actually crunch the numbers:

My phone has a 0.9 Ah battery, at 3.7V. This means the battery holds 12kJ. With an uptime of 200 hours, this means a mobile phone consumes 17 mW on average.

A wireless accesspoint emits EM radiation in the order of of 100mW. If a device harvesting this power has an active area of 10x10cm and is, on average, located 1 meter from the accesspoint, it will pick up 0.01/(4*pi) * 100 = 0.08 mW, assuming the radiation is the same in all directions.

If the device in question can harvest 0.08 mW, it takes17/0.08 ~ 209 accesspoints and 200 hours to accumulate 12 kJ. My only conclusion can be that this product is completely bogus. Even at a conference, with perhaps 100 nearby cellphones as additional radiation sources, it wouldn't be useful.

This analysis grossly overestimates the power that could be harvested, as it assumes a 100% conversion of EM radiation into electricity and situates the accesspoints within one meter of the device. Is it a hoax? Is it fraud? Is it idiocy? Or is my calculation wrong?

I just started hating Java

By Confusion on Thursday 07 January 2010 15:42 - Comments (32)
Categories: Java, Python, Software engineering, Views: 6.362

A new year, a new hatred. I've just officially begun hating the language in which I do most of my work: Java. The tiresome verboseness finally got to me. Please compare with me:


Java:
1
2
3
4
5
6
7
8
9
10
11
12
    private static String joinObjectFields(final List<SomeObjectobjects
        final Character seperatorfinal SomeObject exclude) {

        String result = "";
        for (SomeObject objectobjects) {
            if (!object.equals(exclude)) {
                result += object.someField + seperator;
            }
        }
        // Strip last ; (and see edit3)
        return result.substring(0result.length() - 1);
    }



Python:
1
2
3
4
def joinObjectFields(objects, seperator, exclude):

  fields = [object.someField for object in objects if object != exclude]
  return seperator.join(fields)


To prevent "these pieces of code don't do the same thing", an alternate Java implementation, more like the Python one:

Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
    private static String joinObjectFields(final List<SomeObjectobjects
        final Character seperatorfinal SomeObject exclude) {

        final String[] fields = new String[objects.size()];
        for (int i = 0i < fields.lengthi++) {
            if (!object.get(i).equals(exclude)) {
                fields[i] = object.someField;
            }
            else {
                fields[i] = "";
            }
        }
        return StringUtils.join(fields';');
    }

Doesn't get much better, even if you would initialize the array to contain "" in every field using a utility method.

For extra hatred, consider the necessary changes to the code to enable the same method to join the contents of a different object field.

Edit: A colleague noted that cloning the list and removing the 'exclude' would make matters slightly better.

Edit2: And before someone starts calling me a Python fanboy: you can also do this in a much shorter fashion in Scheme, Ruby, Perl, Scala, Lisp/Clojure, etc.

Edit3: And of course I stupidly forgot to check whether result.length() is actually > 0 in the first implementation.

Edit4: As JanDM rightly points out, I shouldn't use curly braces in Python :P.

Edit 5: This version in Java, posted by Markus in the comments, is far superior: I wasn't making any sense here: the code does a different thing.

Debian, aptitude update: segmentation fault.

By Confusion on Wednesday 04 November 2009 11:38 - Comments (16)
Category: -, Views: 6.246

Hmmm, my 'aptitude update' currently ends with

E: Method rred has died unexpectedly!
E: Sub-process rred received a segmentation fault.

I'm not going to investigate the cause, but from http://ja.pastebin.ca/1655916, a workaround is to
Workaround: Until a solution is found, try updating your repositories with this:
apt-get update -o Acquire::PDiffs=false

Or by setting
Acquire::Pdiffs false;
in /etc/apt/apt.conf

Eten laten bezorgen in Amsterdam? Thai Kitchen! nl

Door Confusion op dinsdag 03 november 2009 22:14 - Reacties (17)
Categorie: -, Views: 5.279

Ik ben zeer tevreden over Thai Kitchen, een bezorgtoko in Amsterdam. Amsterdam Zuidoost is nogal een uithoek, maar ze bezorgen er gewoon. Het eten is lekker en de service is goed: ze zijn vriendelijk en als ze iets vergeten zijn, dan komen ze het netjes nabrengen. Het enige minpuntje is de bezorgtijd: hou er rekening mee dat het minstens een uur duurt. Het eten is echter wel altijd warm als het aankomt.

Deze ervaring is gebaseerd op twee keer bestellen met ~7 man.

Avoid storing configuration data in your revision control system

By Confusion on Tuesday 20 October 2009 22:02 - Comments (3)
Categories: Java, Software engineering, XML, Views: 2.937

After a discussion with a colleague this afternoon, I thought I'd share the following: you should avoid storing configuration data in your revision control system. Especially authentication credentials should not be in there. Here's why:
  1. When securing servers and networks, things like the server hosting an RCS don't get the same priority as, say, your web facing production server. Mistakes are easy to make and you can simply use Google to find 'accidentally' web facing RCS's that expose passwords.
  2. There will be plenty of copies 'out there', outside of your control. How many developers have that data stored on their machine? How careful are they with their laptops and your production passwords?
  3. Access to the configuration is limited to those that should be able to change it: no accidental changes by a junior performing a careless check in.
  4. If you can use the exact same build for your development, test/staging and production environment, then you can cleanly separate between code problems and configuration problems. If you need to rebuild a distributable archive to have the build process include environment-specific configuration, there will always be the doubt that some other difference may have sneaked in.
  5. It's much easier to change the configuration if you don't have to make a new build to deploy the change.
Now I specifically say 'avoid' and not 'do not ever', because many frameworks do not make this separation particularly easy. In the Java world, standard frameworks like Maven, Spring and Hibernate all impose obstacles to succeed at keeping sensitive configuration data out of RCS's.

Maven is a build tool that offers all kinds of build-time placeholder substitution capabilities, which is diametrically opposed to this advice. Spring does dependency injection and the configuration to wire your application together strongly attracts other types of configuration data to be included with it. And if you are paranoid enough to give production databases different names, so you can never accidentally run a test against a production database: how do you get that name into your Hibernate OR mappings at startup time?

It takes careful thought and thorough understanding of the build and startup processes, but in my opinion it is well worth it. Every time I deploy a new version of the one application in which configuration and code are completely separated, where I just have to drop a new .jar and restart, I dance with joy.