I use one mobile application and I like two more. now I like the other one even better. they updated it to 2.0 and at the same time switched from j2me to s60. it now supports gps but most importantly cell based location stuff, so it works for everyone and all the time. it always says the resolution is 1700 meters, but it seems a lot more accurate in densely celled areas. oh yeah, and the other one I like is jaiku, whiched is also owned by google and also uses cell based location stuff.
if only they added the bird's eye perspective from msn live.
we installed gmm2.0 on a colleague's n70, and it helped me realize why this kind of software wasn't available earlier. apparently the location info was only added in symbian 3rd edition.
Friday, November 30, 2007
Monday, November 26, 2007
forkjoinin'
I added a BlockingQueue to Test Police today. a producer creates a list of mutations to be performed and any number of consumers can be started which run the mutations in separate vm's. currently the atomicity is set at the production class level, so that one task includes all the mutations for a single class. this should be fine-grained enough to compensate for the instability problems experienced during long test police runs, such as analyzing a project's entire codebase. there is currently no failover mechanism if a specific jvm crashes during mutation. i.e. that task is not returned to the queue, and is lost.
jsr166y or "forkjoin" is a proposed java7 extension to the parallelization jsr166. it basically allows a closure to be performed on each item in a collection in parallel. test police would be one application that could benefit from such an api: just put all the mutations in a collection, and bam.
jsr166y or "forkjoin" is a proposed java7 extension to the parallelization jsr166. it basically allows a closure to be performed on each item in a collection in parallel. test police would be one application that could benefit from such an api: just put all the mutations in a collection, and bam.
Tunnisteet:
java7,
mutation testing,
parallelism,
test police
Saturday, November 24, 2007
android
bytecode manipulation is out. scala and dalvik are in.
having worked with j2me previously and dabbled in symbian, they're horror. on the techie side, we're excited about the.. technical side. while others see android as a licensing issue.
one person I talked to, said that open stuff is great, but he wondered whether the operators will accept it, since their most valuable asset is closedness.
furthermore, since phones provide a rubbish user experience, any software running on top of them will be horrible as well.
will android reduce accidental complexity by a significant amount and allow for better software and more enjoyable UX, or will it further fragment the landscape already populated by Brew, Symbian, and the already massively fragmented J2ME.
having worked with j2me previously and dabbled in symbian, they're horror. on the techie side, we're excited about the.. technical side. while others see android as a licensing issue.
one person I talked to, said that open stuff is great, but he wondered whether the operators will accept it, since their most valuable asset is closedness.
furthermore, since phones provide a rubbish user experience, any software running on top of them will be horrible as well.
will android reduce accidental complexity by a significant amount and allow for better software and more enjoyable UX, or will it further fragment the landscape already populated by Brew, Symbian, and the already massively fragmented J2ME.
javac stuff
it was unclear to me what function types are.
the usual type in java is interface types. so if I want a function that maps Fruits to Strings I define it as:
interface LolContainer {
String lol(Fruit input);
}
a function type is just a method that is not attached to any class, such as:
{Fruit => String}
which according to the proposal will be converted by javac into something similar to the first example.
this also means that you can write interfaces that extend upon those implicit interfaces.
interface LolWut extends {Fruit =>String} {
boolean somethingElse(Fruit fruit);
}
this lead me to figure out contravariance, which was explained to me by my most respected fellow programmer as something he uses when nothing else works.
Gilad Bracha sez:
In general, if you have an API that only uses a type parameter T as an argument, its
uses should take advantage of lower bounded wildcards (? super T). Conversely, if
the API only returns T, you’ll give your clients more flexibility by using upper bounded
wildcards (? extends T).
It seems to reduce itself back to using this whenever you have to.
I also enjoyed the extension method stuff. No need to repeat the example here substituting lol and wut for everything.
the usual type in java is interface types. so if I want a function that maps Fruits to Strings I define it as:
interface LolContainer {
String lol(Fruit input);
}
a function type is just a method that is not attached to any class, such as:
{Fruit => String}
which according to the proposal will be converted by javac into something similar to the first example.
this also means that you can write interfaces that extend upon those implicit interfaces.
interface LolWut extends {Fruit =>String} {
boolean somethingElse(Fruit fruit);
}
this lead me to figure out contravariance, which was explained to me by my most respected fellow programmer as something he uses when nothing else works.
Gilad Bracha sez:
In general, if you have an API that only uses a type parameter T as an argument, its
uses should take advantage of lower bounded wildcards (? super T). Conversely, if
the API only returns T, you’ll give your clients more flexibility by using upper bounded
wildcards (? extends T).
It seems to reduce itself back to using this whenever you have to.
I also enjoyed the extension method stuff. No need to repeat the example here substituting lol and wut for everything.
Friday, November 23, 2007
livecd's a success
We had three presentations total. I had one with a colleague, and him and a second colleague hosted another session twice for different audiences.
The first one didn't go very smoothly because half of the 10 burned cd's were broken, but for the other two sessions the livecd part went perfectly smoothly. especially in our 45 minute session, they were especially successful because we were able to assign hands on exercises in such a short time.
We had about 30 people attending, and we had 3 extra laptops for people who didn't bring their own.
The first one didn't go very smoothly because half of the 10 burned cd's were broken, but for the other two sessions the livecd part went perfectly smoothly. especially in our 45 minute session, they were especially successful because we were able to assign hands on exercises in such a short time.
We had about 30 people attending, and we had 3 extra laptops for people who didn't bring their own.
Friday, November 16, 2007
virtualizm
after I was almost done with the customizations, the admins at work suggested I use a virtual machine to boot the knoppix iso. wow. I don't have to reboot, I don't have to burn cd's. oh joy!
Tunnisteet:
knoppix
Wednesday, November 14, 2007
apt-gettery
the other livecd turned out ok aswell. I had some trouble booting from dvd's so I wanted to keep it cd-sized. at one point I deleted all the icons from KDE when I tried get the size down. when I got close to the correct size, there was unfortunately no way to predict how much more could be deleted. When I started the "source" data was about 2,5 gigabytes and went down to 959 megabytes. The final 700 meg iso image had about 1.8 gigabytes of compressed data.
apt-get and rubygems worked fine the chroot environment.
apt-get and rubygems worked fine the chroot environment.
Monday, November 12, 2007
remastering knoppix
I am speaking at xpday next week. We have 45 minutes, and our presentation will focus on practical exercises.
to minimize the time spent on setup, and maximize the time spent on actual programming fun we decided to prepare a live cd that all participants can boot up that will have an eclipse environment with all relevant code and tools in workspace ready to fly.
we ended up going with knoppix.
we wanted:
I also have another challenge left. I'm doing the livecd for my colleagues' code reading workshop and they need a bunch of .debs and other software installed. should be fine with the chroot environment but more about that when it's done!
to minimize the time spent on setup, and maximize the time spent on actual programming fun we decided to prepare a live cd that all participants can boot up that will have an eclipse environment with all relevant code and tools in workspace ready to fly.
we ended up going with knoppix.
we wanted:
- eclipse
- some eclipse plugins
- the code for our exercises
- an eclipse workspace with the code in java projects
- eclipse needs to be on a writeable partition, so I put in under the user's home directory.
- /etc/skel is not used to populate the knoppix user's homedirectory, rather /etc/X11/Xsession.d/45xsession is. so I added a bunch of rsyncs in there.
- I had an rsync /blah/blah/workspace/* in there. that didn't copy the oh-so-important .metadata directory. much better with just /blah/blah/workspace
I also have another challenge left. I'm doing the livecd for my colleagues' code reading workshop and they need a bunch of .debs and other software installed. should be fine with the chroot environment but more about that when it's done!
Subscribe to:
Posts (Atom)