Skip to content →

Category: Internet


February is coming to a close, and it’s time for a monthly round-up.

Even though February is the shortest month of the year I doubt it will be the least eventful. Especially the security scene has been on fire this month, and I doubt we’ve seen the final debris of this.

The month gave us two major security related findings from Google.

First, they announced the first practical way to create SHA-1 hash collisions, putting the final nail in the coffin for SHA-1 usage in any security relations.

Later in the month, Google’s security research team, Project Zero, announced how Cloudflare’s reverse proxies would, in certain cases return private data from memory, a bug which came to be known as Cloudbleed. The Google researchers worked with Cloudfare to stop the leak, but according to Cloudfare’s incident report, the issue had been open for a while.

On a slightly different note. Laravel is popular PHP framework. Articles online about the framework seems to be about equal amounts of hype, and belittlement. Earlier this month a critical analysis of Laravel were going its rounds in the Twittersphere. I believe it provides a nice description of the pros and cons of Laravel, without falling for neither the hype nor the hatred that is often displayed in framework discussions in general, and Laravel discussions in particular.

As a lead developer, I spend a lot of time thinking about and making decisions on software architecture. So it’s always nice with some inspiration and new ideas. Even though it’s a rather old article by now, I believe Uncle Bob has some nice points when discussion Screaming Architecture, when he points out that the architecture of a piece of software should make it obvious what the software does, rather than which framework it’s built upon.

Developers seem to find incredible performance gains when upgrading to PHP 7, all from Tumblr reporting more than 50% performance improvement to Badoo saving one million dollars per year in saved hosting and server costs. For the nerds out there, PHP core contributor Julien Pauli did a deep dive into the technical side of PHP 7’s performance improvement.

On the topic of performance, I found, a collection of open source performance testing/monitoring tools, that I’d like to look more into.

Want to know more about what’s going on in the PHP community? Here is a nice curated list of PHP podcasts.

Leave a Comment

HTTPS and HTTP/2 with letsencrypt on Debian and nginx


Most web servers today run HTTP/1.1, but HTTP2 support is growing. I’ve written more in-depth about the advantages of HTTP/2. Most browsers which support HTTP2 only supports it over encrypted HTTPS connections. In this article, I’ll go through setting up NGINX to serve pages over HTTPS and HTTP/2. I’ll also talk a bit about tightening your HTTPS setup, to prevent common exploits.


HTTPS security utilises public-key cryptography to provide end-to-end encryption and authentication to connections. The certificates are signed by a certificate authority, which can then verify that the certificate holder is who he claims to be.

Letsencrypt is a free and automated certificate authority who provides free certificate signing, which has historically been a costly affair.

Signing and renewing certificates from Letsencrypt is done using their certbot tool, this tool is available in most package managers which mean it’s easy to install. On Debian Jessie, just install the certbot like anything else from apt:

Using certbot you can start generating new signed certificates for the domains of your hosted websites:

For example

Letsencrypt certificates are valid for 90 days, after which they must be renewed by running

To automate this process, you can add this to your crontab, and make it run daily or weekly or whatever you prefer. In my setup it runs twice daily:

Note that Letsencrypt currently doesn’t support wildcard certificates, so if you’re serving your website from both and (you probably shouldn’t), you need to generate a certificate for each.


NGINX is a free open source asynchronous HTTP server and reverse proxy. It’s pretty easy to get up and running with Letsencrypt and HTTP/2, and it will be the focus of this guide.


To have NGINX serve encrypted date using our previously created Letsencrypt certificate we have to ask it to listen for HTTPS connections on port 443, and tell it where to find our certificates.

Open your site config, usually found in /etc/nginx/sites-available/<site>, here you’ll probably see that NGINX is currently listening for HTTP-connections on port 80:

So to start listening on port 443 as well, we just add another line:

The domain at the end would, of course, be the domain that your server is hosting.

Notice that we’ve added the ssl statement in there as well.

Next, we need to tell NGINX where to look for our new certificates, so it knows how to encrypt the data, we do this by adding

With the default Letsencrypt settings this would translate into something like:

And that’s really all there is to it.


Enabling HTTP/2 support in NGINX is even easier, just add an http2 statement to each listen line in your site config. So:

Turns into:

Now test out your new, slightly more secure, setup:

If all tests pass, restart NGINX to publish your changes.

Now your website should also be available using the https:// scheme… unless the port is blocked in your firewall (that could happen to anybody). If your browser supports HTTP2, your website should also be served over this new protocol.

Improving HTTPS security

With the current setup, we’re running over HTTPS, which is a good start, but a lot of exploits have been discovered in various parts of the implementation, so there are a few more things we can do to harden the security. We do this by adding some additional settings to our NGINX site config.

Firstly, old versions of TLS is insecure, so we should force the server to not revert:

If you need to support older browsers like IE10, you need to turn on older versions of TLS;

This in effect only turns off SSL encryption, it’s not optimal, but sometimes you need to strike a balance, and it’s better than the NGINX default settings. You can see which browsers supports which TLS versions on caniuse.

When establishing a connection over HTTPS the server and the client negotiates which encryption cypher to use. This has been exploited in some cases, like in the BEAST exploit. To lessen the risks, we disable certain old insecure ciphers:

Normally HTTPS certificates are verified by the client contacting the certificate authority. We can turn this up a bit by having the server download the authority’s response, and supply it to the client together with the certificate. This saves the client the roundtrip to the certificate authority, speeding up the process. This is called OCSP stapling and is easily enabled in NGINX:

Enabling HTTPS is all well and good, but if a man-in-the-middle (MitM) attack actually occurs, the perpetrator can decrypt the connection from the server, and relay it to the client over an unencrypted connection. This can’t really be prevented, but it is possible to instruct the client that it should only accept encrypted connections from the domain; this will mitigate the problem anytime the clients visits the domain after the first time. This is called Strict Transport Security:

BE CAREFUL! with adding this last setting, since it will prevent clients from connecting to your site for one full year if you decide to turn off HTTPS or have an error in your setup that causes HTTPS to fail.

Again, we test our setup:

If all tests pass, restart NGINX to publish your changes (again, consider if you’re actually ready to enable Strict Transport Security).

Now, to test the setup. First we run an SSL test, to test the security of our protocol and cipher choices, the changes mentioned here improved this domain to an A+ grade.

We can also check our HTTPS header security. Since I still havn’t set up Content Security Policies and HTTP Public Key Pinning I’m sadly stuck down on a B grade, leaving room for improvement.

Further reading

Leave a Comment

HTTP/2 – What and why?

What is HTTP?

HTTP, HyperText Transfer Protocol, is an application layer network protocol for distributing hypermedia data. It is mainly used for serving websites in HTML format for browser consumption.


The newest version of HTTP is HTTP/2. The protocol originated at Google under the name SPDY. The specification work and maintenance has later been moved to the IETF.

The purpose of HTTP/2 was to develop a better performing protocol, while still maintaining high-level backward compatibility with previous versions of the HTTP protocol. This means compliance to the same HTTP methods, status codes, etc.

New in HTTP/2

HTTP/2 maintains backward compatibility in the way that applications served over the protocol does not require any changes to work for the new version. But the the protocol contains a range of new performance enhancing features that applications can implement on a case-by-case basis.

Header compression

HTTP/2 supports most of the headers supported by earlier versions of HTTP. As something new, HTTP/2 also support compressing these headers to minimize the amount of data that has to be transferred.

Request pipelining

In earlier versions of HTTP, one TCP connection equaled one HTTP connection. In HTTP/2 several HTTP requests can be sent over the same TCP connection.

This allows HTTP/2 to bypass some of the issues in previous version of the protocol, like the maximum connection limit. It also means that all of the formalities of TCP, like handshakes and path MTU discovery, only has to be done once.

No HOL blocking

Head of Line block occurs when some incoming data must be handled in a specific order, and the first data takes a long time, forcing all of the following data to wait for the first data to be processed.

In HTTP/1 HOL blocking happens because multiple requests over the same TCP connection has to be handled in the order they were received. So if a client makes 2 requests to the same server, the second request won’t be handled before the first request is been completed. If the first request takes a long time to complete, this can will hold up the second request as well.

HTTP/2 allows pipelining requests over a single TCP connection, allowing the second request to be received at the same time, or even before, the first request. This means the server is able to handle the second request even while it’s still receiving the first request.

Server Push

In earlier versions, a typical web page was rendered by in a sequential manner. First the browser would request the page to be rendered. The server would then respond with the main content of the page, typically in HTML format. The browser would then start rendering the HTML from the top and down. Every time the browser encountered an external ressource, like a css file, an external JavaScript file, or an image, a new request would be made to the server to request the additional resource.

HTTP/2 offers a feature called server push. Server push allows the server to respond to a single request with several different resources. This allows the server to push required external CSS and JavaScript files to the user on a normal page request, thus allowing the client to have the resources at hand during the rendering, preventing the render-blocking additional requests that otherwise had to be done during page rendering.


The HTTP/2 specification, like earlier versions, allows HTTP to function both over a normal unencrypted connection, but also specifies a method for transferring over a TLS-encrypted connection, namely using HTTPS. The major browser vendors, though, have decided to force higher security standards, by only accepting HTTP/2 over encrypted HTTPS connections.

Leave a Comment

Validating email senders

Email is one of the most heavily used platforms for communication online, and has been for a while.

Most people using email expect that they can see the who sent the email by looking at the sender field in their email client, but in reality the Simple Mail Transfer Protocol (SMTP) that defines how emails are exchanged (as specified in rfc 5321) does not provide any mechanism for validating that the sender is actually who he claims to be.

Not being able to validate the origin of an email has proven to be a really big problem, and provides venues for spammers, scammers, phishers and other bad entities, to pretend to be someone that they are not. A couple of mechanisms has later been designed on top of SMTP to try and add this validation layer, and I’ll try to cover some of the more widely used ones here.

Since we’re talking about online technologies, get ready for abbr galore!

Table of contents:

Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is a simple system for allowing mail exchangers to validate that a certain host is authorised to send out emails from a specific host domain. SPF builds on the existing Domain Name System (DNS).

SPF requires the domain owner to add a simply TXT record to the domain’s DNS records, which specifies which hosts and/or IPs are allowed to send out mails on behalf of the domain in question.

An SPF record is a simple line in a TXT record on the form:

For example:

When an email receiver receives email the process is:

  1. Lookup the sending domain’s DNS records
  2. Check for an spf record
  3. Compare the spf record with the actual sender
  4. Accept / reject the email based on the output of step 3

For more details check out the SPF introduction or check your domain’s setup with the SPF checker.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is another mechanism for validating whether the sender of an email is actually allowed to send mails on behalf to the sender. Similarly to SPF, DKIM builds on DNS, but DKIM uses public-key cryptography, similar to TLS and SSL which provides the basis for HTTPS.

In practice DKIM works by having the sender add a header to all emails being send which a hashed and encrypted version of a part of the body, as well as some selected headers. The receiver then reads the header, queries the sending domain’s DNS for the public key to decrypt the header, and checks the validity.

For more details, WikiPedia provides a nice DKIM overview.

Domain Message Authentication Reporting & Conformance (DMARC)

Domain Message Authentication Reporting & Conformance (DMARC) works in collaboration with SPF and DKIM. In it’s simplest form, DMARC provides a rules for how to handle messages that fail their SPF and/or DKIM checks. Like the other two, DMARC is specified using a TXT DNS record, on the form

For instance

This specifies that the record contains DMARC rules (v=DMARC1), that nothing special should be done to emails failing validation (p=none), that any forensic reports should be sent to ( and that any aggregate reports should be sent to (

Putting DMARC in “none”-mode is a way of putting DMARC in investigation mode. In this mode the receiver will not change anything regarding the handling of failing mails, but error reports will be sent to the email adresses specified in the DMARC DNS rules. This allows domain owners to gather data about where emails sent from their domains are coming from, and allows them to make sure all necessary SPF and DKIM settings are aligned properly, before moving DMARC into quarantine mode, where receivers are asked to flag mails failing their checks as spam, or reject mode, where failing emails are rejected straight away.

For a bit more detail, check out the DMARC overview or check the validity of your current setup using the DMARC validator.

Leave a Comment

WordPress-sikkerhed og brute force angreb

Der er i øjeblikket mange der taler om et botnet der på nuværende tidspunkt skulle være i gang med at brute force sig adgang til WordPress sites overalt. Der skulle efter sigende være tale om et angreb fra op til 90.000 forskellige kilder.

Om et sådan angreb er i gang eller ej skal jeg ikke kunne sige, men det har tilsyneladende fået rigtig mange WordPressbrugere til at genoverveje deres nuværende sikkerhedsniveau, så noget positivt er der da kommet ud af det lige meget hvad.

Jeg ser mange der diskuterer problemet og mulige løsninger, hvilket igen er positivt, men der er mange der ikke har helt styr på hvad der er godt og skidt, og evt. hvorfor, så jeg vil her prøve at give mit bud på nogle overvejelser man bør gøre sig inden man hovedløst kaster sig ud i installation af tilfældige sikkerhedsplugins.

En række supportere på det officielle WordPress support forum har sammen lavet en side på WordPress codex med tips og tricks til at sikre sig mod angrebet, så hvis du vil have den korte version på engelsk kan den findes her. Jeg vil gå lidt mere i dybden og forsøge at forklare det hele på dansk.

Hvad sker der egentlig?

For god ordens skyld vil jeg lige starte med at forklare det egentlige problem, så vi allesammen snakker om de samme ting, og for at give en idé om de overvejelser man bør gøre sig.

Botnets? What?

Det omtalte angreb stammer fra et stort botnet. Et botnet er et antal computere der, for det meste uden at ejeren ved det, bliver brugt af tredjepart til andre formål end hvad ejeren af computeren havde til hensigt.

I dette tilfælde handler det efter sigende om at bagmændende bag botnettet prøver at tiltvinge sig kontrol over flere computere, for på den måde at udvide deres botnet. De gør det ved at “brute force” sig administratoradgang til maskiner der kører websites bygget på WordPressplatformen. Hvis det lykkedes dem at få adgang til et WordPress-site gør de så dette site til en del af deres botnet, og på den måde vil angrebet vokse hver gang det lykkedes dem at overtage et WordPress-site.

Hvad så med det “brute forcing”?

Brute forcing handler om at tiltvinge sig adgang ved “brute force”, altså rå magt. Det foregår ved de simpelthen prøver at logge ind som adminbrugeren, ved at prøve mere eller mere tilfældige passwords, i teorien kan man jo gætte alle passwords hvis man har uendelige forsøg og god tålmodighed. Da der er tale om et automatisk angreb er det ikke noget der koster bagmændende noget tid, og de har derfor rigeligt med tålmodighed.

Men hvad kan jeg gøre ved det?

For det første skal du tage dine normale forholdsregler. Sørg ALTID for at holde WordPress fuldt opdateret. Det samme gælder alle installerede plugins og temaer. Dette er ikke specielt for det nuværende angreb, men alt software er usikkert på den ene eller anden måde. Folkene bag WordPress arbejder hårdt for at lukke alle sikkerhedshuller der bliver fundet så hurtigt så muligt, så sørg for altid at være opdateret. Sørg desuden for at slå alle plugins fra du ikke bruger. Som nævnt er intet software 100% sikkert, så en tommelfingerregel er at jo mindre software du har jo bedre.

Mht. det nuværende angreb er der selvfølgelig nogle ekstra ting du kan gøre.

Tag backup af alt!

En backup sikrer dig selvfølgelig ikke imod angreb udefra. Men hvis du skulle være uheldig enten at blive offer for angrebet, eller at få ødelagt dit site i et forsøg på at sikre det er det altså noget rarere at have end up-to-date backup, end at skulle starte helt forfra. Sørg altså for at tage backup af både selvesitet (via. FTP) og databasen (f.eks. via phpmyadmin), gerne lige nu, inden du forsøger at øge din sikkerhed.

Selve backupprocessen er afhængig af hvor du har dit website liggende, så der kan jeg ikke være så behjælpelig, men der findes som sædvanlig en række forslag på WordPress Codex.

Skift navnet på din adminbruger

Det igangværende angreb udnytter tilsyneladende at WordPress i gamle dage automatisk oprettede en administratorbruger med brugernavnet. Fra version 3.0 og frem har det været muligt selv at bestemme dette brugernavn, men det er ikke alle der har ændret det. En ændring af dette brugernavn vil gøre det sværere at brute force sig adgang til dit site, da angriberne så både skal finde brugernavn og password, i stedet for kun password.

Hvis du har en administratorbruger med brugernavnet admin kan det ændres forholdsvist enkelt med et plugin, eller ved et par manuelle skridt:

  1. Login som din administratorbruger
  2. I adminpanelet gå til “Brugere” -> “Tilføj ny”
  3. Opret en ny bruger, sæt brugerens rolle til administrator (med et ordentlig password!)
  4. Log ud.
  5. Log ind med din nyoprettede administratorbruger.
  6. I adminpanelet gå til “Brugere” -> “Alle brugere”.
  7. Hold musen hen over admin-brugeren, og tryk på det “slet”-link der kommer frem.

Hvis du oplever at du ikke kan slette admin-brugeren så dobbeltcheck lige at du har logget ind med din nyoprettede bruger, og ikke stadig er logget ind som adminbrugere (ja, vi kan alle lave trykfejl :-)).

Brug ordentlige passwords

Dette er vel nok det vigtigste punkt på listen, og desværre nok også det mest besværlige at gøre ordentligt. Sørg altid for at bruge ordentlige passwords der ikke er lige til at gætte. Som sagt foregår det nuværende angreb som et brute force angreb, hvor de prøver sig at gætte sig til dit password, dette vil normalt foregå på en af to måder.

Enten kan man prøve fra en ende af, med “a” som password, derefter “b”, når alle muligheder er opbrugt prøver man så med to bogstaver, “aa”. Dette kan selvsagt tage lang tid, men hvis dit password f.eks. er “asdf” tager det altså ikke lang tid.

En anden metode er at tage udgangspunkt i en ordbog. I stedet for at prøve alle kombinationer af tal og bogstaver nøjes man med ord fra en prædefineret liste af ord. Disse liste vil ofte også indeholde ofte brugte afarter af ord, hvor f.eks bogstaver er udskiftet med tal. Dette betyder at hverken “password” eller “p4ssw0rd” er særlig gode passwords.

Der er skrevet rigtig, rigtig, rigtig, meget om hvordan man gør sine passwords sikre. WordPress Codex nævner også nogle gode forholdsregler man kan forholde sig til. Der henvises desuden til nogle services der kan hjælpe med at generere og huske gode passwords. De væsentligste ting må være:

  • Lad være med at bruge personlige oplysninger, såsom dit navn, din fødselsdag eller lignende offentlige oplysninger.
  • Lad være med at bruge ord fra ordbogen.
  • Længere passwords er generelt bedre passwords.
  • Brug en blanding af store og små bogstaver, tal og tegn

Men husk altid på de ovenstående metoder der bruges til at gætte passwords. 5up3rM4nRul3z43v3r (superman rules forever) er altså ikke nødvendigvis et godt password, da det stadig er en sammensætning af ord der garanteret vil stå i enhver password breaking ordbog.
Gode passwords vil oftest (altid?) være svære at huske. En metode til at gøre det lettere er at bruge en passwordmanager, et program eller en service til at huske dine passwords for dig. Jeg bruger selv LastPass som gør at jeg har et meget stærkt password som jeg skal huske. Dette masterpassword giver så adgang til alle mine passwords til diverse websites. Det betyder at jeg kan bruge services til at generere tilfældige passwords (eller, ihvertfald tilfældige nok), uden selv at skulle huske alle disse passwords, eller nedskrive dem på papirer som jeg kan smide væk.

Bloker adgang til din loginside

Da det igangværende angreb forsøger at få adgang administratorinterfacet på WordPress sites via den normale loginmetode, er en mulighed for øget beskyttelse at begrænse adgangen til adminpanelet. De to mest brugte metoder til dette er:

  • Password-beskyt adminpanelet
  • Bloker adgang til filen på IP-niveau

Fælles for de to metoder er at de kan fungere på et af to niveauer. Det kan enten gøres via. WordPress selv, eller det kan gøres direkte på serverniveau. Om man bruger den ene eller anden metode kan umiddelbart virke ligegyldigt, men jeg vil gerne lige understrege hvorfor det gør en forskel.

WordPress er skrevet i PHP, som bl.a. bruges til at skabe dynamiske hjemmesider. Det betyder at hver gang sikkerheden bliver håndteret i WordPress skal serveren have hele WordPress i gang med at arbejde for først at finde ud af om en bruger skal have adgang til en ressource. Samme sikkerhed kan ofte klares på serverniveau, hvilket betyder meget mindre arbejde for serveren, da en evt. angriber vil blive forment adgang allerede inden WordPress bliver sat i gang.

Password-beskyt adminpanelet

Passwordbeskyttelse kan som nævnt foregå både på server- og på WordPressniveau. Passwordbeskyttelse på WordPressniveau foregår via. WordPress eget loginsystem, det er en beskyttelse vi snakkede om tidligere med ændring af adminbrugernavn, og brug af gode passwords.

Passwordbeskyttelsen kan dog også flyttes ned på serverniveau med HTTP authentication. Dette vil resultere i at når du tilgår din WordPress loginside vil du først møde en popup hvor du skal skrive brugernavn og password, og derefter vil du møde den normale WordPress loginside. Dette er selvfølgelig en afvejning af sikkerhed vs. convenience da det kan virke lidt irriterende at skulle logge ind to gange. Hvis du vælger denne metode skal du selvfølgelig huske ikke at bruge samme brugernavn/passwordkombination til begge lag af beskyttelse. WordPress Codex har selvfølgelig også instruktioner til hvordan du opsætter HTTP authentication, både på Apache og Nginx servere.

Bloker adgangen på IP-niveau

En anden metode er at blokere adgangen til WordPress-loginformen ud fra forespørgerens IP-adresse. Hvis du ved at du har en fast IP-adresse og at du vil have den samme adresse lige så længe som du har din WordPressside kan du selvfølgelig lave en opsætning der kun giver den ene IP-adresse adgang til din loginside, men det er de færreste forundt (og nu er ikke tidspunktet til en IPv6-diskussion).

Et alternativ, som vil være mere relevant for de fleste, er kun at tillade en IP-adresse X antal loginforsøg, før denne blokeres. Dette kan gøres på WordPressniveau vha. et plugin som WordFence (tak til Kasper Bergholt for anbefaling af pluginet, der tilsyneladende også kan mange andre lækre ting), men igen har vi problemet med at hele WordPresspakken skal startes op, før der kan tages stilling til om en bruger skal have adgang eller ej. Dette er dog noget mere besværligt, og nok ikke noget alle og enhver bare bør kaste sig ud i, men en guide til opsætning af af rate-limiting på Apache kan findes her. Hvis man vil opsætte rate limiting i .htaccess, kræver det dog at man kører Apache med mod_security 2.7.3 eller senere.

Et problem med denne tilgang til det igangværende angreb er at angrebet som forklaret udføres af et botnet der arbejder fra mere end 90.000 forskellige IP-adresser (med mulighed for udvidelse, hvis de får succes). Det betyder at de potentielt kan fortsætte angrebet fra en ny IP, hvis en af adresserne bliver spærret. Dog må der altid være en form for ressource cost tilknyttet hvis angrebet skal flyttes til en ny afsender, da der skal holdes styr på hvor langt hver angriber er nået i ordbogen. Så jo flere lag af sikkerhed du kan opsætte, jo sværere bliver det for angriberen.


Så for at opsummere hvad jeg mener du bør gøre for at højne din WordPress-sikkerhed generelt, og imod det måske igangværende angreb er:

  1. Hold WordPress opdateret, inkl.
    • WordPress core
    • Alle installerede plugins
    • Alle installerede temaer
  2. Tag backup. Om ikke andet for at gøre det lettere at komme tilbage på benene hvis uheldet skulle være ude.
  3. Lad være med at have en adminbruger med navnet admin.
  4. Brug ordentlige passwords. Brug evt. en passwordmanager.
  5. Passwordbeskyt din loginside.
  6. Bloker adgangen for IP-adresser der prøver at gætte dit password.

Hvis i har andre gode råd til beskyttelse af WordPress hører jeg selvfølgelig også gerne om det i kommentarfeltet nedenfor, så vi kan få spredt ordet om ordentlig sikkerhed (At lade være med at bruge WordPress godtages ikke som et godt råd, så hvis det er din mission, så spar dig selv besværet og lad være med at skrive det her).

Leave a Comment

Speciale aka. næste store projekt

Jeg har i tidens løb nævnt en række projekter af forskellig størrelse, som jeg har arbejdet på. Nu er det tid til endnu et, og det er et større et af slagsen, specialet på mit studie på DTU, og dermed afslutningen på mit studie til civilingeniør.

Jeg skal arbejde med en idé jeg har haft igennem længere tid, men som jeg aldrig er kommet i gang med, men nu skal det være. At jeg kan få lov til at arbejde med et projekt som jeg synes er så interessant er jo kun en bonus.

Den grundlæggende ide

Den grundlæggende idé er rimelig simpel, så simpel at det egentlig undrer mig at jeg ikke kan finde andre der har gjort det endnu, ihvertfald ikke i København.

Der er mange muligheder for at gå ud i København, her tænker jeg på barer, værtshuse, spillesteder osv. Faktisk er der så mange at det kan være svært at vælge hvilket sted man skal vælge på et givent tidspunkt. Samtidig er der tilpas mange til at det er svært at have et overblik over de muligheder man har når man gerne vil ud. Det bliver ikke lettere hvis man på et tidspunkt befinder sig et sted i byen man måske ikke kender så godt, og hvor man måske ikke lige ved hvor man bør gå hen (*host* Amager).

Den grundlæggende idé er så en simpel mulighed for at søge efter steder i nærheden af hvor man befinder sig. De fleste har efterhånden adgang til en smartphone når de går ud. Disse indeholder både adgang til internettet og lokationsmuligheder, så de teknologiske krav er som oftest opfyldt, der mangle bare servicen.

Dette kan man delvist klare allerede med eksisterende services som AOK eller Yelp hvis man kan få filtreret spisesteder og shopping fra. Det nu hedengangne MitKBH kunne indtil for nylig også delvist tilbyde noget lignende, ligesom Carlsberg med deres nye CrowdIt vist nok også prøver.

Hvor er underholdningen?

Nogen gange vil man dog lidt mere end bare at finde det nærmeste sted, da man forskellen mellem en god og en dårlig bar kan være så simpel som en 30m gåtur. Derfor kan det være relevant at kigge på lidt mere end bare afstanden.

Den første udvidelse til den grundlæggende idé var derfor at udvide søgningen til at omfatte flere af barernes tilbud. Det kunne være noget så simpelt som at finde en ryger eller ikke-rygerbar, eller f.eks. det kunne være muligheden for at søge efter barer der tilbyder

  • Poolbord
  • Billard
  • Dart
  • Whiskeykort
  • Specialøl
  • Osv.

Mulighederne er mange da vi hver især har forskellige formål med at tage ud. Teknisk er der dog stadig tale om en rimelig simpel søgefunktion, næppe noget der har specialepotentiale for en IT-studerende. Det skal være vildere!

Det mere avancerede

En lokation er bare en af de mange ting en smartphone kan fortælle om brugeren. En smartphone er på mange måder en bærbar PC i klassisk forstand, altså en Personlig Computer (frit oversat). Den vil derfor ofte have kendskab til mange flere oplysninger der kan gøre et søgeresultat mere interessant for brugeren, og det er her det egentlige specialepotentiale kommer ind i billedet. Med adgang til flere oplysninger om brugeren bliver det muligt at tilbyde en mere personaliseret service, og der er generelt mange data der kan bruges til at forbedre oplevelsen.

Dine vaner kan over tid fortælle noget om hvilke steder, eller hvilken type steder du normalt vil vælge. Dette kan bruges til at anbefale nye steder enten i samme genre, eller steder som andre med vaner i stil med dine anbefaler.

En anden mulighed er at kigge på Facebook. Hvilke steder anbefaler dine venner, disse kunne måske have interesse for dig også, især hvis det er venner du i forvejen er meget sammen med, eller ofte tager i byen med.

Selv noget så simpelt som tidspunktet kan være interessant at kigge på. Der er næppe nogen grund til at anbefale en bar der lukker en halv time senere, hvis det i forvejen tager ti minutter at gå derhen. På den anden side kunne det være interessant hvis dine venner har offentliggjort, f.eks. med et Facebook check-in, at de er et sted i nærheden af dig.

Selve specialet

Jeg har efterhånden diskuteret idéen med en del mennekser (mange tak for inputs, alle sammen!) og det er der kommet rigtig mange spændende idéer ud af, også mange flere end opsummeret ovenfor, så jeg tror på at der er rigeligt med muligheder for at udvide konceptet, og hvilke idéer og tilgangsvinkler jeg ender med at vælge er jeg stadig ikke helt sikker på, men jeg tror der er potentiale.

Leave a Comment

Tillykke med de 100.000, Ubuntudanmark!

Den 31. Oktober 2006 kl 21:06 blev det første indlæg posted på det danske Ubuntu supportforum. Det var den spæde start på et forum der siden har udviklet sig meget.

Forummet har pt. over 5000 brugere, og i dag nåede de endnu en milepæl. Der er dags dato blevet skrevet ikke mindre end 100.000 indlæg! Det må jo betyde at de har gjort et eller andet rigtigt.

Tillykke til de mange aktive brugere, og ikke mindst de dygtige supportere! Godt gået, og held og lykke med de næste 100.000! 🙂

Leave a Comment

WordPress Danmark – Hvad så nu?

WordCamp er som jeg har nævnt før på bloggen, vel overstået. Så nu må det være på tide at komme tilbage i den samme gamle rille, og lade WordPress være WordPress.. eller hvad?

Man kunne også vælge noget andet.
Efter søndagens WordCamp var vi en gruppe mennesker der satte os ned, for at prøve at danne os et overblik over hvor WordPress Danmark står i dag, og hvor vi gerne ser det bevæge sig hen af i fremtiden. Det blev til en række foreløbige mål, de har allesammen hjemmesiden som udgangspunkt, men forhåbentlig kan den øgede aktivitet skabe noget opmærksomhed omkring projektet, der så senere kan brede sig til flere kanaler.

Hovedpunkterne for WordPress DK hjemmesiden var:

  • Siden med bureauer skal erstattes, eller med enkeltpersoner der arbejder professionelt med WordPress, så det bliver lettere at finde folk med de rigtige kompetencer.
  • Gæstebloggere – For at skabe mere liv på hjemmesiden, skal det gøres lettere for folk med noget på hjerte, at få lov til at udgive gæsteblogindlæg på
  • WordPress Planet – Der er mange danskere der allerede blogger på dansk om WordPress på deres egne blogs. De skal have mulighed for at tilmelde deres blogfeed til en feed aggregator, der samle danske blogindlæg om WordPress et fælles sted
  • Danske oversættelser af plugins – Det skal være lettere for folk at finde WordPress plugins der er oversat til dansk, samt at hjælpe med at oversætte plugins.
  • ShowCases – WordPress kan stort set alt hvad du skal bruge, og det kan se godt ud mens det gør det. Der skal samles nogle gode eksempler på hvorfor WordPress ikke længere bare er blogging software.
  • Accessibility var et populært emne under hele WordCamp. Da så mange af deltagerne mente at det var så vigtigt, og at det bestemt er muligt at opnå med WordPress, synes jeg bare det er med at komme i gang og få det bevist. Det er jo ingen skam at fremstå som et godt eksempel 🙂
  • Forummet virker pt. som den mest aktive del af sitet. Det er godt. Men det indeholder pt. et stort arkiv af gammelt materiale, noget nyt, noget outdated, noget glemt noget tabt, og noget der måske aldrig igen skal beskues af menneskeøjne. Vi skal finde ud af hvad vi gør med det forum. Er udviklingen gået så hurtigt at de gamle indlæg er outdated og bare kan smides væk, eller er der værdi i at få det struktureret, samlet og måske opdateret? og hvem skal i så fald gøre det?

Ja, der er nok at tage sig til, og der skulle være arbejde nok til alle, så hvis du har en interesse i et af ovenstående emner, eller har andre forslag til hvordan vi kan udbrede WordPress i Danmark, så hop forbi den nye smarte udviklingsblog, og giv dit input!

Jeg har selv meldt mig som tovholder på oversættelsesholdet, og jeg vil i et senere indlæg komme ind på hvad jeg har af idéer til emnet.

Leave a Comment

WordCamp Danmark 2011 – Dag 2

Som nævnt har jeg brugt denne weekend på årets WordCamp Danmark. Jeg skrev i går om WordCamp Danmark, første dag.

Dette indlæg vil omhandle de fleste af mine oplevelser på andendagen. På anden dagen skete der et par interessante ting ud over foredragene og jeg har derfor valgt at fordele andendagen over flere indlæg, men mere om det senere, dette indlæg handler om foredragene.

Da der var 2 aflyste foredrag, var der nogle ændringer i programmet, så dette er altså ikke retvisende for dagen.

Dagens første foredrag var Thomas Clausen, som på første dagen fortalte om webshops. I dag fortalte han om et emne der kom op flere gange i løbet af førstedagen, nemlig custom post types, og taxonomies.
Foredraget startede med en introduktion til custom post types og taxonomies. Det var en god introduktion, der fik slået nogle definitioner og forskelle ordentligt på plads. Et hovedtema som Thomas kom tilbage til flere gange, var WordPress’ template hierarchy, og hvordan WordPress finder ud af hvilken template der skal bruges, baseret på hvilken post type man arbejder med.
Det var et rigtig godt foredrag, der fik slået en række definitioner på plads som jeg synes har manglet lidt. Desuden førte foredraget til en rigtig god debat, og en række længere diskussioner. Det var godt, og slidesne kan findes på SlideShare.

Andet foredrag var Mark Gazel, hovedmanden bag WordPress Danmark, samt hovedforcen bag årets WordCamp (Mange tak!), der snakkede om WordPress Danmark, før, nu og i fremtiden.
Mark startede med lidt forhistorie om hvordan WordPress Danmark opstod, samt forløbet op til at han pludselig, uventet, havde fået overdraget ansvaret for hele foreningen. Dette endte ud me en kort opsummering af hvad der er sket siden WordPress meetup’et (lækkert ord!) tidligere på året.
Herefter kom han lidt ind på oversættelse af WordPress, og plugins til dansk, hvordan det ofte foregår, samt noget om hvorfor det er vigtigt.
Den sidste del af Mark’s foredrag handlede om hans tanker vedrørende WordPress Danmark hjemmesiden, både hvordan det så ud nu, og hvad han håbede at se fremover. Dette ledte til endnu en rigtig god debat, denne gang om foreningens hjemmeside, og hvad den evt. kunne bruges til. Desuden spawnede foredraget en arbejdsgruppe, der sidst på eftermiddagen satte sig sammen, og snakkede om hvad der skulle ske fremover, samt hvordan vi skulle nå frem til dette. Mere om det i et senere indlæg. Mark’s slides findes som resten online.

Det tredje foredrag blev forestået af Mikkel Breum, der snakkede om WordPress themes, og funktionalitet.
En af Mikkels hovedpointer var at themes var meget mere end et pænt design. Langt de fleste theme indeholder også en del teknisk funktionalitet, både i form af indlejret speciel kode, men også i form af inkluderede plugins og tilgængelige shortcodes og custom post types. Dette kan bl.a. give nogle problemer hvis man skifter theme, da man pludselig kan stå med manglende funktionalitet, eller endda manglende blogindlæg, da man har mistet en post type.
Mikkel argumenterede for hvorfor plugins bør installeres ordentligt, i stedet for at indlejres i et theme, hvilket jeg synes er rigtig fornuftigt. Jeg synes generelt at det er en god idé som udvikler, at benytte et MVC design pattern, eller en afart heraf, når man udvikler. Selv brugte Mikkel et projekt ved navn TGM Plugin Activation, til at lade sine themes installere de plugins han bruger direkte i WordPress intallationen, det er et projekt jeg selv skal have kigget mere på.
Til sidste var han en smule inde på parent og child themes, og opfordrede spirende WordPress designere til at sætte sig ind i WordPress’ Theme Review Guidelines, og evt. give en hånd med på Theme Review holdet.
I løbet af foredraget nævnte Mikkel bl.a. ThemeForest, WpCandy og som gode steder at finde themes.

Det sidste foredrag bestod hovedsageligt af at folk præsenterede forskellige WordPress projekter de havde arbejdet på, og snakkede om hvilke plugins og teknikker de havde fokuseret på i projektforløbet, samt hvad tankerne bag projektet har bestået af. Der var rigtig mange spændende projekter, så mange at jeg mener disse fortjener et indlæg for sig selv.

Alt i alt var det en rigtig god weekend, med masser af inspirerende foredrag, og endnu flere inspirerende mennesker. Mange tak til alle deltagende, og især til Mark, for at få det hele op at stå! I løbet af dagen blev nævnt rigtig mange forskellige ressourcer, og Thomas Gam har samlet en liste med mange af dem.

Var du med? Hvad var dine indtryk af erfaringer af arrangementet, og de forskellige foredrag?

Edit: Jeg har tilføjet de resterende slides.


WordCamp Danmark 2011 – Dag 1

Det var som tidligere nævnt ikke min plan at deltage i dette års WordCamp, men da Lars Bachmann var så rar at trække min kommentar som vinderen af en af hans 2 udloddede billetter, var det jo bare om at komme afsted (alt andet ville da også være uhøfligt).

Det jeg personligt fandt mest interessant på første dag, var de mange rare mennesker, der alle var friske på en god samtale om diverse webprojekter, samt hvordan vi hver især bruger WordPress eller andre platforme. Men der var også et rigtigt spændende WordCamp program, med oplæg jeg gerne vil knytte nogle noter til.

Første oplæg var WebMatrosen (fedt navn, egentlig) Oliver Nielsen, der snakkede om brug af videoer online. I starten var jeg ikke helt imponeret, både fordi jeg ikke er voldsomt interesseret i videoredigering, men også fordi det virkede som om at oplægget ikke ville bestå af andet end fremvisning af diverse billeder og videoer. Det ændrede sig heldigvis hurtigt, og førte til Oliver’s tilgang til brug af video online, samt en introduktion til de virkemidler han fokuserer på når han arbejder med videoproduktion, det kunne opsummeres i forkortelsen SUCCES(S), som står for (frit efter min hukommelse):

  • Simplicity
  • Unexpectedness
  • Concreteness
  • Credibility
  • Emotions
  • Stories

Som man kan lære mere om i bogen Made to Stick. Oliver’s slides findes på SlideShare

Andet oplæg blev forestået af Thomas Clausen fra Designgrotten, som talte om brugen af WordPress som e-commerce platform (hans slides findes på slideshare). Det blev hurtigt til en diskussion om hvilken e-commerce platform der er den bedste, en god debat som jeg tror kunne være interessant at have, men jeg synes det var lidt synd da det ikke var et godt tidspunkt til debatten i mine øjne. Noget jeg fandt rigtigt interessant ved Thomas’ oplæg var hans eksempler på plugins han selv brugte, og nævnte som det vigtigste WooCommerce.
Desuden fortalte Thomas om den He-man model han selv arbejder efter:

  1. Handling
  2. Entusiasme
  3. Mål
  4. Aftaler
  5. Niche

Tredje oplæg var Joen Asmussen, der i dagens anledning havde valgt at tage bukser på, på trods af titlen “Bukser ikke påkrævet”.
Joen arbejder til dagligt hos Automattic, som er firmaet bag WordPress. Han fortalte bl.a. om hvordan det er at arbejde for Automattic, og hvordan de arbejder og får virksomheden til at hænge sammen, på trods af at medarbejderne er spredt ud over hele kloden, og sjældent mødes in person. Endnu et godt oplæg, og slidesne er tilgængelige online.

Dagens sidste oplæg stod Lisa Risager for. Lisa snakkede om at personalisere WordPress. Det handlede om theming, og fordele og ulemper ved at lave sine egne themes vs. at benytte eller tilpasse andres themes. Desuden blev der snakket en del om fordele og ulemper ved brugen af plugins, vs. at definere de funktioner man skal bruge i WordPress’ functions file. Oplægget virkede desværre nogen gange som om det var en genopfriskning fokuseret på folk der allerede havde arbejdet med emnerne, nærmere end en introduktion til folk der gerne ville i gang, men overordnet set synes jeg der var et ok fokus, og det var generelt en fint oplæg, med nogle rigtig gode diskussioner. Lisas slides kan desuden findes på SlideShare.

Alt i alt synes jeg det var en rigtig god første dag, og jeg glæder mig meget til dag 2!

Da der var et oplæg om brug af video, er der selvfølgelig også blevet optaget i løbet af dagen, og så vidt jeg ved er planen at optagelser fra alle oplæg kommer online på et tidspunkt.

Edit: Indlægget er nu opdateret med links til de manglende slides.