Month: July 2011

Återaktivera domän hos Loopia

En domän förföll, det diskuterades huruvida tjänsten som hostades där skulle fortsätta eller om kunden ville lägga ner projektet. Efter att den förfallit så beslutade sig kunden för att fortsätta köra.

  1. Jag försöker då köpa domänen på nytt via Loopias vanliga gränssnitt, eftersom domänen försvunnit från listan över “mina domäner”.
    Detta misslyckas pga “tekniskt fel kontakta support”. Detta har jag stött på flera gånger: om någon (inte bara jag)  tidigare köpt en domän och hostat den hos Loopia men inte längre kontrollerar den, då kan ingen registrera om den via Loopia – man måste ringa in till supporten, de gör en abrovinsch i sitt system och sedan är det fritt fram igen.
  2. Jag ringer in till supporten (en lördag kl 11) men får veta att jag behöver få hjälp av registry-/domänavdelningen som är tillbaka först på måndag.
  3. Jag ringer på måndag och får “hjälp” med att få tillbaka domännamnet i listan. Jag behöver nu bara gå in och återaktivera domänen.
  4. Jag går in och försöker hitta en knapp som det står återaktivera på. Efter lite letande finns knappen, men den går inte att trycka på: Jag behöver först fylla upp mitt Loopia PrePaid-konto så att återaktiveringen kan dras därifrån.
  5. Jag tycker på länk för att försöka fylla upp PrePaid-kontot. En faktura skickas via mail.
  6. Jag får ett mail med faktura, ser bra ut, och jag trycker på länken “Betala fakturan med bankkort”
  7. Loopias sida hoppar fram men nu står det att jag försöker betala en annan domän (hackernight.se), en domän som är i drift, betald och fin och inte skall förnyas förrän om 4 månader. (Det står också att jag kommer fylla på PrePaid.)
    Jag kontrollerar fakturanumret och ser att det stämmer, men specen på webben är annorlunda från den i PDF:en.
  8. Jag ringer in till supporten och frågar vad som står på. Jag får information att det inte kommer dras pengar åt något håll automatiskt eftersom jag valt manuell hantering av PrePaid.
    Jag: “Så trots att det står att jag betalar för en viss domän, så kommer jag i själv verket inte göra det?”
    Loopia: “Just det, det kommer inte bli fel utan så som du vill.”
  9. Jag tar en skärmdump och skickar till support@ (enligt uppmaning över telefon) för att kunna lösa buggen.

Det är inte bra när ett fakturanummer kan ge olika fakturaspecifikation eller uppgift om vad fakturan handlar om. Det brukar revisorer ha synpunkter på. Själv blir jag bara villrådig och undrar så klart hur deras system fungerar

Jag gillar skarpt att Loopia har ett enkelt gränssnitt, prisvärd tjänst (i övrigt) men

  1. När det väl är dags att betala går det bara via DIBS vilket betyder att man måste ha med sin bankdosa för att genomföra en registrering. Jag har inte min bankdosa med mig i fickan hela tiden. De flesta domäner jag köpt över åren har helt klart varit en reaktion på en ny idé som någon kläckt helt appropå, påbörjar registrering men måste vänta tills jag kommer hem för att avsluta och genomföra den verkliga registreringen.

Jag har varit en nöjd kund, alltid fått snabb och bra hjälp. Det är bara synd att jag behövt ringa, år efter år med samma ärenden.

Det finns dessutom ett fint API för att kontrollera sina domäner. Betalning  – oavsett om det går in i PrePaid eller betalar en faktura – kräver bankdosa. Mindre bra för integration och automatisering. (Så det argumentet faller lite på målsnöret.)

Uppdatering: fixade länkar och skrev till API-argument (och jag fick bra hjälp via mail och twitter innan jag redogjorde här – supporten är kanon, det är “systemet” det är fel på).

Tecken på agil utveckling

Sitter och rensar ut gammal e-post och hittade följande som skickades till en kund när ett POC-projekt övergick i “vi gör lite mer än POC” (från 2008).

Som förespråkare för agil utveckling vill jag ju poängtera att

  •  agila utvecklare aldrig undviker att “träffa” ett lager utan tvärtom har som mål att i varje utvecklingssteg se till att man tar ett “helt snitt av kakan” – man tar inte bara glasyren som vi gjort nu, utan strävar att alltid jobba sig hela vägen ner till botten (databasen) utan fusk eller genvägar.

Om vi har 30 minuter kan vi diskutera vilka agila principer vi skall hålla högt i detta projekt :)

Det förra projektet hade följande högt:

  • gemensamt kodägande
  • daglig regelbunden standup (med de tre frågorna: vad har jag gjort sedan senast, vad gör jag till nästa gång, har jag några hinder i vägen)
  • standupen får vara högst 15 minuter
  • planering i iterationer med synlig sprint backlog och …
  • … burndown chart
  • utvecklarna estimerar och planerar sprinten ihop med beställaren
  • sprintens backlog respekterades av alla
  • utvecklarna bestämmer egna dagordningen – alla jobbar med allt, inga revir
  • show and tell i slutet av iterationen
  • kontinuerligt bygge & test av koden
  • alltid körbar kod
  • sprintens backlog underhölls av och var till för utvecklarna och gav PM info om progress
  • endast återstående tid rapporteras

och halvhögt hölls

  • one shot build – ett kommmando är allt som behövs för att bygga och testa allt
  • retrospective – utan regelbunden utvärdering utvecklas man inte
  • gemensam arbetsyta (open work-area)
  • velocity – utvecklingstakt beräknades efter varje iteration utan indelning i mötestid, utvecklingstid, reviewtid, …
  • enhetstestning
  • coding standards – code review

och halvlågt hölls tyvärr

  • testdriven utveckling
  • automatiserad acceptanstestning
  • parprogrammering

och obefintligt var:

  • on-site customer
  • continuous deployment
  • relativa estimat i produktbacklogen (estimaten där hade rubriken timmar vilket var missvisande)

Det finns andra “agila tecken”, jag tog bara ett par ur huvudet och från http://jsolutions.se/2009/10/29/undersokning-om-agil-utveckling/

/Fredrik :)

Git vs Mercurial

I’ll post my findings on why I prefer one over the other here.

Pro Git

  • feature branch workflow that doesn’t leave dangling branches all around (hg clone is a workaround imo).

Pro Mercurial

  • hg is one character shorter than git
  • hg st is many characters shorter than “git status” – it’s much more convenient
  • hg can reference commits using a short number and not only hashes
  • hg serve

Cons Git

  • None yet really.

Cons Mercurial

  • It’s Python. Clients use Windows. Too often a non-optimal match.

Other Thoughts

Eclipse is moving to Git.

With just a few branches and simple workflow, MercurialEclipse has served well. EGit just recently became useful enough for day-to-day work.

Gitorious is nice (and free), I’ve not seen a similar tool for Mercurial yet.

Lexmark E120n with cups

After a system reinstall (new system hard drive, this time round with Ubuntu Server 10.10 64-bit), I needed to setup CUPS again with a network connected Lexmark E120n printer, which works quite well. Linuxprinting.org however lists a PPD/driver that doesn’t work well at all – for larger files (PDF with airplane boarding passes) it just spits out one page and then stalls.

Enabling remote configuration of CUPS

All of this needs to be modified/added to /etc/cups/cupsd.conf, and then the host can be accessed using HTTPS and /admin/.

Listen *:631

# Restrict access to the server...
<location />
  Order allow,deny
  Allow all
</location>

# Restrict access to the admin pages...
<location /admin>
  Encryption Required
  Order allow,deny
  Allow all
</location>

# Restrict access to configuration files...
<location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
  Allow all
</location>

And restart cups. This will however complain with “400 Bad Request” and the log says Request from "1.2.3.4" using invalid Host: field "hemma.wendt.se". This is because Debian/Ubuntu default config simply chose this setup. The fix:

ServerAlias *

Setting up the printer

Driver: Lexmark E120n Foomatic/lj4dith (grayscale)
Connection: socket://192.168.1.137:9100
Defaults: job-sheets=none, none media=iso_a4_210x297mm

I’ve put up the PPD file I use should I need it again.

SMS Gateway API from 46elks

I just got an alpha invitation to try out the 46elks SMS API. These are my notes.

My Own Summary of The API

  • Several numbers can be tied to your account
  • RESTful HTTP API (with version in base URL) with JSON responses
  • BASIC HTTP Authentication
  • HTTPS
  • Simple GET web hooks / URL callbacks (per account and per number) for inbound delivery with message payload as URL query parameters

Nice

  • “Splitting and joining multi-part SMS messages are automatically handled by the API.”

Opportunities

Delivery Notifications

I’d like to be able to know if a text (SMS) has been received by the target recipient(s). We used this when we had several people “on standby”, if the first person was not reached withing one minute, we moved on trying to contact the next one.

A callback URL for delivery notifications (tracking) would be perfect.

Error Messages

The API docs doesn’t mention error codes/messages or what types of validations are carried out on the backend.

Non-plain Text Content

VCards is the type I’ve ran across previously.

Other Notes

Character encoding is said to be UTF-8 which is fine. The docs should perhaps be more clear on this since they accept parameters with GETs (and in URLs, there is not standard way of telling what character encoding is used).

I’d prefer if the URL callbacks used POST (and JSON payload). GET URLs are limited and even though not many users tend to send 1024+ long texts, my mother does and that would risk being cut off somewhere down the line (or software stack).

Delivery limits – how long will 46elks hold my messages when my server park is out? How many attempts at delivery will 46elks make?

The documentation should have perhaps used https in the examples.

Timeout limits for replying to a message should perhaps be in there, as well as the option to turn this feature off. If my service somehow is throwing error messages out, I’d prefer them not being sent to my clients.

Bottomline

As an alpha preview – this is great and looks really nice and convenient to use. A complete (send and admin account) interface can be written using HTML+JavaScript only. As expected, there are a couple of things missing from the API, such as cost information/account balance and perhaps type (prepaid, invoice, …).

Update: I put out the quick hack files I used to try the API on GitHub.

Apache2, WordPress 3, OpenId och segfault

Pillade med Squeeds blog igår och det slutade med Segmentation fault. Det visar sig att OpenID-pluginen kikar efter om zend finns installerat och denna kik gör att Apache-processen segfaultar. Mycket intressant eftersom jag kör samma setup på min privata blog med exakt samma programvaror och hos samma hosting partner (GleSYS). Min instans är något större, men det borde inte spela någon roll.

Debugging och core dumps: peta in CoreDumpDirectory /tmp i configen, sedan

aptitude install php5-dbg
ulimit -c unlimited
/etc/init.d/apache2 restart

Och för att kolla på en stacktrace:

gdb /usr/sbin/apache2 -c /tmp/core.pid
set pagination 0
bt
bt full

Lyckades dock sätta upp en ny “ren” instans som fungerar utan problem. Antar att webbnissarna som installerat drupallite olyckligt ändrat något jag inte kan hitta.

Google OpenID

https://www.google.com/accounts/o8/id fungerade bra för registrering av konto. (Man behövde inte krångla med https://www.google.com/accounts/o8/site-xrds?hd=squeed.com som URL.) Efter att XRDS-Simple-pluginnen installerats funkade allt som väntat.