Tidshorisont för NFC

Jag tror (i Sverige) …
  1. att majoriteten av mobiltelefoner har NFC om 3 år.
  2. att efter ytterligare 2 år kan man avsluta ett köp med NFC i hälften av Nordstans butiker.
  3. att efter ytterligare 4 år är NFC vanligare än korttransaktioner.

Enligt PayPal har jag fel, enligt MasterCard kan jag ha rätt. TechCrunch sammanfattar läget.

Alternate NFC Logotype
Alternativ NFC-logga

(Min senaste fem-årsgissning var vid julbordet 2001 – då gissade jag att Linux som alternativ på skrivbordet skulle vara minst lika lättanvänt, -installerat och -användt som Windows. Julen 2006 fanns Ubuntu 06.10. 2007 tror jag NetworkManager kom in och först då var det väl egentligen i samma liga.)

Att välja rätt List-implementation

Jag har stött på tillfällen då man undrar vilken implementation av en kollektion, t ex java.util.List man bör välja. Ibland behöver man använda så lite minne som möjligt, ibland vara så snabb som möjligt, osv. Jag har oftast löst det med att skriva enhetstest och långkörarjobb som gör något om och om igen, så får det stå över natten och när man kommer tillbaka nästa dag undersöka resultat, loggar och JVM-data.

Skärmbild över statistik från körning med Caliper
Skärmbild över statistik från körning med Caliper

Idag hittade jag Caliper via  Jesse Wilssons bloginlägg om LinkedList vs ArrayList (ur kö-perspektiv). Den korta tråden av kommentarer visar dock på hur irrelevant enhetstestbaserade undersökningar kan vara (även om de kör över tid så att GC får arbeta). På en JVM sitter ofta många system och “delar” GC och minnesrymd.

Helt irrelevant finner jag det absolut inte – även om systemet under test inte beter sig som under skarp last så upplever jag att man kan få ökad förståelse om hur olika implementationer beter sig och ju mer delar man har av ett pussel – ju lättare är det att se hela bilden och dra rätt slutsatser.

Statistik från Bredbandskollen

Bredbandskollen
Bredbandskollen

Bredbandskollen har nu dokumenterat ett API och publicerat det under deras
FAQ, sektion 7, längst ned. Det är dock inte JSON utan (schemalös) XML, men det är iaf komplett och det finns nu uttalat att informationen endast får användas i icke-kommersiellt syfte (såvida man inte tecknar avtal med IIS om annat, kontaktuppgifter finns att hitta i FAQ:n).

Informationen nedan är alltså gammal.

Det finns ett sätt att hämta statistik från bredbandskollen.se. Jag har inte sett att det är ett uttalat API, inga villkor för användning eller dokumentation. Tyvärr – IIS har en särställning och därmed borde vi ställa krav på öppenhet (vilken är väldigt god i allmänhet från .SE).

Disclaimer

Jag blev kontaktad av IIS och ombads uppdatera informationen här, enligt:

Hur som helst så skulle vi uppskatta ifall du uppdaterade ditt blogginlägg med hänvisning till att vi fixar ett API på rätt sätt ifall någon har behov av det. Tills dess är det olämpligt att sprida denna bakdörr eftersom vi inte erbjuder någon garanti att denna information är korrekt.

Normalt förfarande är givetvis att man tar kontakt med den som utger sig som ansvarig utgivare av informationen man vill använda, men på Bredbandskollens FAQ fanns ingen sådan information. Inget i någon sidfot. Inget i HTML.

Bas-URL

http://www.bredbandskollen.se/statistik/

getISPs.php

Returnerar ett objekt med ID (heltal) som nyckel, och ISP:ns namn som värde.

getChartData.php?

chartType=0 – okänt
year=2011 – periodbestämning, 2007-2011 (2007-10 verkar vara startpunkt)
month=8 – periodbestämning, 1-12
isps=6 – ISP-bestämning, kommaseparerade index från getISPs
regions= regionsbestämning, kommaseparerade index från lista kodad i HTML (se nedan)
speeds=  typ av förbindelse, kommaseparerade index från lista kodad i HTML (se nedan)

Regioner

{0:"Alla",
2:"Blekinge Län",
10:"Dalarnas Län",
5:"Gotlands Län",
3:"Gävleborgs Län",
6:"Hallands Län",
7:"Jämtlands Län",
8:"Jönköpings Län",
9:"Kalmar Län",
12:"Kronobergs Län",
14:"Norrbottens Län",
27:"Skåne Län",
26:"Stockholms Län",
18:"Södermanlands Län",
21:"Uppsala Län",
22:"Värmlands Län",
23:"Västerbottens Län",
24:"Västernorrlands Län",
25:"Västmanlands Län",
28:"Västra Götaland",
15:"Örebro Län",
16:"Östergötlands Län"}

Hastigheter

{0:"Alla",
1:"256 Kbit/s adsl",
2:"256 Kbit/s kabeltv",
3:"Upp till 384 Kbit/s 3G",
4:"512 Kbit/s adsl",
5:"1 Mbit/s adsl",
6:"2 Mbit/s adsl",
7:"2 Mbit/s kabeltv",
8:"1,5-2 Mbit/s fiber",
9:"Upp till 3 Mbit/s 3G",
10:"Upp till 6 Mbit/s 3G",
11:"8 Mbit/s adsl",
12:"8 Mbit/s kabeltv",
14:"10 Mbit/s fiber",
16:"24 Mbit/s adsl",
17:"24 Mbit/s kabeltv",
18:"24 Mbit/s fiber",
21:"60-100 Mbit/s fiber",
22:"10 Mbit/s kabeltv",
23:"0,20-0,25 Mbit/s adsl",
24:"1,5-2 Mbit/s adsl",
25:"6-8 Mbit/s adsl",
26:"12-24 Mbit/s adsl",
27:"0,4-0,5 Mbit/s kabeltv",
28:"7-10 Mbit/s kabeltv",
29:"12-24 Mbit/s kabeltv",
30:"25-50 Mbit/s kabeltv",
31:"3-5 Mbit/s kabeltv",
32:"50-100 Mbit/s kabeltv",
33:"20-60 Mbit/s adsl",
34:"Upp till 10 Mbit/s 3G",
35:"10-80 Mbit/s 4G",
36:"500-1000 Mbit/s fiber",
37:"100-200 Mbit/s kabeltv",
38:"Upp till 16 Mbit/s 3G",
39:"Upp till 32 Mbit/s 3G",
40:"10-20 Mbit/s 4G",
41:"5-10 Mbit/s 4G",
42:"12-30 Mbit/s adsl",
43:"30-60 Mbit/s adsl"}

Transparens på nätet

Google, Skype, Open Rights Group, Center for Democracy and Technology, Netzpolitik, OpenNet Initiative och andra bjuder in till ett tvådagars-hackathon (8-9 november), kallat Hack For Transparency (#h4t). Det bjuds på käk, nät och 3000 € i pris till bästa bidraget från respektive spår: Internet Quality och Global Transparency.

The objective is then not necessarily to end-up with fully completed projects, but rather to stimulate the awareness and thinking around these issues, and to discover fresh ideas and innovative angles to tackle them.

Senast 10:e oktober behöver man skicka in sin ansökan om att få delta.

Richard M Stallman till FSCONS

En profil som stenhårt driver linjen att människors rätt till frihet är en mänsklig rättighet – som är fullt förenlig med kommersiella intressen. “GNU-guden” Richard Mathew Stallman (RMS) kommer till http://FSCONS.org i år. En udda snubbe med skägg som tänkt till kring många frihetsfrågor.

Jag har lyssnat till honom vid två tillfällen och det brukar vara lite provocerande när han effektivt, brutalt och hänsynslöst svarar varannan fråga med: “Hur tänkte du nu egentligen? Eller tänkte du alls? Menade du verkligen vad du sa? Har du funderat över vad du implicerar egentligen? Nästa fråga, eller vänta – är det någon som har en intressant fråga så kan vi ta den först?”

Free Software, not Open
Free Software, not Open

Kata: Authentication Filter in Java EE

This is an exercise I’ve used to demonstrate how awkward unit testing can be if you can’t use a mocking framework. It’s an almost real work life situation (disclaimer: you should perhaps use container based authentication and JAAS) where we’re using API:s in a Java EE Server, adding two collaborators and then writing the logic combining it all.

No group has (yet) completed the entire task within 90 minutes – you might want to start/focus on using one collaborator only (I suggest the LDAP collaborator).

Originally posted on codingdojo.org.

When cleaning up a folder at work, I found this old document – it’s some form of a logical flow chart of the filter to write.

Here we go …

Background

In this Kata, your a programmer at ABC Corp and you’re making a new web app from scratch. After the head architect started working on this, it’s now up to you to make sure these tasks are completed:

  • allow authentication using request parameters
  • all authentication/login attempts should be verified agains LDAP
  • successful logins should be recorded in the single sign on registry

However, you’re not the only programmer (team) adressing this web app, so the LDAP is written by another team and what you have right now is this interface:

 public interface LdapAuthenticationGateway {
   boolean credentialsAreValid(String userName, String password);
 }

and the single sign on registry is also written by another team, leaving you with this interface:

 public interface SingleSignOnRegistry {
   boolean tokenIsValid(String token);
   String registerNewSession(String userName);
   void endSession(String token);
 }

Your job basically is to write one or more javax.servlet.Filter that handles incoming requests and act according to whether there’s a cookie with a SSO token, username+password parameters etc.

It’s assumed that there’s some form of DependencyInjection framework in place – to get a handle to the SingleSignOnRegistry or the LdapAuthenticationGateway, you’ll simply have to provide something like:

 public void setSingleSignOnRegistry(SingleSignOnRegistry registry) {
   ...
 }

About this kata

This “real life” scenario has been used to demonstrate how mocking (using Mockito) can be useful. We’ve combined it with BDD and JDojo@Gbg will try to practice TDD using this kata (without mocking) next time around.

(“Real life” is quoted – proper JEE authentication should be tied into the container etc etc … The point with this exercise is that it’s fairly easy to explain how it should work and what needs to be done here with “real” Java EE API:s, and then focus on the “How to develop” aspect (TDD), but also to show/talk about the difference between mocking and stubbing.)