web development Archives - Aki Björklund

2009-10-182009-10-18

Best books on web development?

I’m thinking of building a definitive list of books on web development. Software development in general should not be forgotten, but the focus of the list would be in great web software development.

Only the best books would be listed so that the list could serve as an educational tool. This is why I am asking your help.

What are your favorites? Let me know in the comments! Books on specific server-side technologies are fine too, the list will be categorized.

Without too much thought, here is a short list of 20 books to get you started:

The last 10 books suggested by Sami Poimala, thanks! (I now have to actually read all those.)

2009-09-022009-09-02

A website is never done

On a recent post in that I warned against multi-vendor web projects. I ended with a claim:

A website is never done. It should be constantly analyzed and developed further. Perfection is a forever moving target. Don’t try to nail everything at once.

This is a serious issue. Even more serious is that it is generally very hard to find a vendor that can actually deliver something like that.

Why?

Consultancies are organized around delivering projects. They have little or no organization to actually continuously develop websites with high quality. Sure, there is maintenance people, but that is often an afterthought and only activated if the client is asking for changes. When selling more to an existing client, sales people unsurprisingly put their effort into selling big projects, not small incremental upgrades.

Web development must not be done in two to four year cycles when everything gets ripped down periodically. That is just insane use of money and in most cases PageRank.

There should be a symbiosis where technical people feed the client with new ideas concerning content (organization of, new types of, better cross-linking etc.) and techies get challenged daily by the continuously changing environment.

One reason for this kind of behavior is that good developers demand to build cool new things and that is what the company then sells.

Even more alarming is that continuous development is generally considered being something lowly. Sure, many of the tasks are not that challenging or sexy.

But.

I spent years on my previous job practically developing a single site. Not once I felt it was something unworthy of me. Not once I felt bored.

It taught me unbelievable amount things that now make me respected at my current job. Why? I had to solve real-life problems, not just problems that aroused during the requirements or the design phase. To solve those kind of problems cleanly, I really had to know the domain.

Developers should sell small improvements directly

Keeping it small requires that no sales people and preferably no project managers are involved.

Developer makes a well argued proposal with an estimated amount of hours of work and the client accepts or abandons it. Client gets billed on actual hours worked, not by the estimation.

This of course requires a contract of some kind. But after that is done, selling costs are rapidly approaching zero.

This kind of arrangement must be based on a mutual trust or otherwise it will not work. I believe this could work with all but the smallest sites and clients, not just with the biggest.

Clients should reserve a budget beforehand for these kind of small incremental improvements. Maybe build a little less features in the initial phase and add more as there is real-life understanding of how the site is actually used?

Developers will be happier when they have their own child to look after and more influence over their work.

This results into better websites for sure. Maybe it costs a little more, but the site should bring in more money too. If not, you are probably not basing your decision making on measurable metrics.

2009-08-082009-09-10

Web developers’ areas of expertise

What should a web developer know? More about web or plain programming? I believe it is often far more valuable to know the domain really, really well than it is to be highly skilled in programming.

Web developer’s development skills can be divided into three categories:

Open web technologies and practices
Server side web technologies
Generic technologies and development techniques

This is my incomplete list of things that every web developer should know about the web:

HTML: What is the purpose of HTML; What is semantic HTML; All the common elements and their attributes; What is the Doctype and what does it do; HTML vs. XHTML, what are the practical differences; HTML5 philosophy and major new additions
CSS: Selectors and their browser implementation statuses; Basics: margin, padding, border: the box model; Positioning with float, position; Some experience in building a simple layout in pure CSS; The difference between quirksmode and the standards mode; General understanding of CSS levels 1–3 and their implementation status in browsers
JavaScript: Deep understanding of the language; Progressive enhancement; jQuery experience; Ajax and JSON basics; Browser manipulation: URL, cookies, etc.
HTTP: What does a HTTP request consists of; Common response codes and their proper use; How cookies work, what are their limitations?; How to read and debug HTTP traffic; Cache control; Statelessness and how to fake it (and why not to fake it)
URI: What is the difference between URL, URI, and IRI; How is URI structured; How and when to use the query string; How does the hash (fragment) work; Cool URIs don’t change
Browsers: Browsers current market share; Browser differences; Browser quirks (IE); Browsers current and future standards’ implementations and other features
DOM: What is DOM and why does it exits; How to view DOM; Standard API to modify with JavaScript
DNS: How does it work and how browsers use it; How to use the hosts file
Usability: Focus on simplicity; Usable forms; Writing for the web
Accessibility: What is it and why is it important?; Accessible forms; Accessible navigation; WCAG
SEO: Why title is an important element; Link economy; Canonical URLs; Every page is linked to with normal links
Security: XSS; CSRF
Miscellaneous: Web feeds (RSS and Atom); RESTful web development; XML; XSL, XPath; Overview of W3C standards and other web standards

I probably did not think of everything, so feel free to add your suggestions in the comments.

In addition to that list, you should of course know enough about the server side technologies too. Know thoroughly at least the programming language, web framework, your database of choice, SQL as a language, something about scalability and performance, security basics and so on. Learning will not end on this side either.

Useful generic technologies and development techniques include writing readable code, designing highly reusable object-oriented software, agile methodologies… I won’t try to make a comprehensive list here.

Where to focus?

More often than not a programmer focuses on programming only. That often results into unusable or otherwise bad websites. Web is a domain like no other. Of course, developing in any other platform will be much more effective if you know the domain.

Focusing your learning efforts on open web technologies gives you several benefits:

The first benefit of focusing on the open web technologies is your agility to switch platforms. The more you know about the web, the easier and faster it is to start developing in a new web development platform, from switching CMS’s to a massive leap of one technology stack to another. There is also less of a vendor lock-in, which gives more options for your career.

Second, your ability to work efficiently with web designers grows. You are able to deliver solutions that make their work easier.

Third, the complete solution is likely to be much more web oriented and thus a better one.

Fourth, you learn something that tends to be more long-lived knowledge than typical vendor-specific technologies.

It never ends

No wonder most of us feel sometimes a bit anxious about all the things we have to learn. And when we do learn, it is mostly rendered useless after a couple of years.

A developer is never out of school.

2009-07-232009-07-25

The trap of multiple vendors in website design and development

Summary: If you have a big or important website to build, do not – under any circumstances – built it using multiple vendors.

Problem: Your company needs a website of some kind and you have not enough resources or expertise to build it yourself.

So you want to hire a company that does that sort of things. What general options are there and what are their strengths and weaknesses?

The three general types of companies that could help are:

Advertising agency
Web consulting company
General technology consulting company

Here is a little table that tries to capture their pros and cons:

Competence	Advertising agency	Web consultant	Technology consultant
General technology	Low	Medium	High
Web technology	Medium/low	High	Medium/low
Web domain	Medium/low	High	Low
Web strategy	Medium	High	Low
General marketing	High	Medium	Low
Visual design	High	Medium/high	Low

This is of course a very simplistic and subjective table. There are always exceptions and individual differences. Many companies cannot be put into these categories.

The choice is pretty easy if you need a simple website and can make compromises.

It gets harder if you need, say, a visually stunning website with a scalable back-end.

What do companies usually do in these situations (and sadly, often when they do not actually need to)? They buy the specification work from one company, visual design from another, and the actual implementation from a third company. In the specification or the visual design phase there usually is not yet an understanding what the technology platform will be.

This leads to multiple problems:

Communicating design decisions becomes extremely time-consuming and error-prone.
The implementation will cost a lot because the limits of the platform cannot be taken into consideration beforehand.
Developers and designers get unhappy because their chances of making a difference is lower.
The probability of success is lower – the forced waterfall model does not easily allow correction of mistakes made in the beginning of the project.

So basically: you will have a website that has some weaknesses (from a single vendor) – or you will own a generally bad website that cannot be fixed easily (from multiple vendors).

So what do I suggest?

You find a single company that has the best record of delivering great websites in all areas that matter to you. Usually that is a company, that specializes to web development and design. Remember that a lot can be fixed afterward, but it is harder, if the basic design decisions were wrong. Money should be reserved for that too. The more players there were in the development for the website, the more the corrective measures will probably cost.

A website is never done. It should be constantly analyzed and developed further. Perfection is a forever moving target. Don’t try to nail everything at once.

2009-04-262009-09-19

10 nykyaikaisen julkaisujärjestelmän kulmakiveä

Nykyaikainen julkaisujärjestelmä on aika erilainen kuin vielä vaikkapa viisi vuotta sitten osattiin kuvitella. Millainen olisi se “unelmien” järjestelmä, jonka kanssa itse tekisin mieluiten töitä?

(Julkaisujärjestelmä-sana on varsin ylikuormittunut. Puhun tässä julkaisujärjestelmästä, mutta tarkennan tarkoittavani sekä sisällönhallintaa että sellaista sovelluskehystä, jonka päälle on vaivatonta kehittää melkein minkälaisia verkkopalveluita vain.)

1. Sisältökeskeisyys

Kun kerran puhutaan julkaisujärjestelmästä, on tärkeää, että sisältö on järjestelmässä etusijalla. Moni julkaisujärjestelmä unohtaa olevansa sisällönhallintajärjestelmä ja keskittyy sivuhierarkian ja irrallisista komponenteista muodostettujen sivujen sisäisen rakenteen hallintaan.

Sivuston rakenne tai komponentti ei varsinaisesti ole sisältöä, yksittäinen juttu tai vaikka video on. Sisällöntuottajat tuottavat juttuja. Asiantuntijat rakentavat sivustoja ja suunnittelevat informaatioarkkitehtuurin. Tämän jaon ympärille on rakentuu luontevasti niin käyttöliittymäsuunnittelu kuin hakukonenäkyvyyden vastuualueetkin.

Kun kaikki sisältö on jollain tasolla samanarvoista, kaikesta sisällöstä voidaan ilman lisäohjelmointia muodostaa vaikkapa syötteitä tai tarjota yleiskäyttöinen web-API sisällön hallintaan.

2. Sisällön uudelleenkäytettävyys

Järjestelmän avulla tuotettu tai järjestelmään tuotu sisältö on mahdollisimman uudelleenkäytettävää. Tämä tarkoittaa sitä, että sisällöstä on riisuttu kaikki esityksellisyys. Ylläpitotyökalut eivät siis esimerkiksi tarjoa sisällöntuottajille fonttivalikkoa vaan asiantuntijan koostamaa tyylivalikkoa.

Toinen merkittävä uudelleenkäytettävyyteen vaikuttava asia on sisällön tallentaminen tiukan rakenteisena. Useimmiten tämä tarkoittaa tallentamista puhtaassa XML-muodossa. Mitä hallitumpi sisällön rakenne on, sitä varmemmin sisältö saadaan taipumaan myös tulevaisuuden tarpeisiin. Epämääräisen Office-HTML-mössön hallinta ei voi mitenkään olla kustannustehokasta pitkällä aikavälillä.

Miksi tämä on tärkeää?

Sivuston kuin sivuston ulkoasu tuppaa menemään uusiksi noin parin vuoden välein. Sisällön on mukauduttava tähän. Ei ole realistista joutua korjaamaan tai jopa syöttämään sisältöä uusiksi ulkoasun vaihtuessa.

Toinen etu on se, että sisältö on vietävissä helposti muille sivustoille tai kokonaan muihin medioihin. Rupu-“HTML” tuottaa aina ylimääräistä päänvaivaa vastaanottavassa päässä ja tekee hommasta siten tehotonta.

Kehittynyt järjestelmä ei tuota esimerkiksi sisältöä, jossa kappalevaihdot on merkitty pakotetuin rivinvaihdoin, väliotsikot eivät ole lihavoituja kappaleita eikä tekstin loppuun ole lyöty tyhjää, jotta olisi tilaa kirjoittaa. Suorastaan itkettää, kun näen isojen mediatalojenkin tuottavan tällaista sisältöä verkkoon. Mikä se niiden bisnes olikaan?

Uudelleenkäytettävyys tavataan nähdä jo ratkaistuna ongelmana, mutta ei se ihan niin ole. Selainpohjaiset HTML-editorit tuntuvat edelleen tuottavan kuraa.

3. Käyttöönoton helppous

Kun käyttäjä kirjautuu järjestelmään, hän voi välittömästi alkaa tuottaa sisältöä, jopa täysin ilman opastusta. Tämä säästää valtavasti kustannuksissa, kun ei tarvitse kouluttaa ainakaan kaikkein yleisimpiin tehtäviin. Se myös osaltaan vaikuttaa järjestelmällä toteutetun sivuston menestykseen, koska mitä helpompi sisältöä on tuottaa, sen todennäköisemmin sitä myös tuotetaan. Mitä enemmän sisältöä, sen suurempi menestys.

Toinen puoli käyttöönoton helppoutta on tekninen. Mitä nopeammin saadaan projekti ja prototyyppisivusto pystyyn, sitä nopeammin voi web-kehitys olla tuottavaa. Pystytys ei saa vaatia erityistaitoja ja mitä vähemmän vaiheita se vaatii sen parempi.

4. Edistyneet SEO- ja analytiikkaominaisuudet

Nätit, kanoniset URL:t ovat itsestäänselvyys. Edistyneet SEO-ominaisuudet ovat esimerkiksi sellaisia, jotka huolehtivat kerran käytettyjen osoitteiden toimivuudesta viimeiseen asti, vaikka sisältöä siirrettäisiin paikasta toiseen. Linkkien toimivuuden varmistaminen on myös olennaista, hyvä järjestelmä tarkistaa kaikki ulkoisetkin linkit aika-ajoin, korjaa ne, mikäli osaa ja ilmoittaa ylläpitäjälle tarvittaessa.

Integraatio Google Analyticsiin esimerkiksi ulkoisten linkkien mittaamisen osalta on hyödyllistä ja poistaa yhden tyypillisen erillisen työvaiheen. Analyticsin API:n kautta voidaan tuoda sisällöntuottajalle juuri häntä varten räätälöityä tietoa kävijöistä ilman erillisen järjestelmän tuomaa vaivaa. Näin sitoutuminen sisällöntuotantoon kasvaa.

5. Todellinen modulaarisuus

Mihin tahansa järjestelmän osa-alueeseen on päästävä käsiksi plugin-tasolta. Toiminnallisuutta voi näin laajentaa koskematta itse tuotteeseen jolloin päivitettävyys ei kärsi. WordPress on osoittanut, että laajennettavuus yhdessä avoimuuden kanssa mahdollistaa järjestelmän menestyksen.

Rajapintojen on oltava erittäin monipuoliset ja ne on tarkkaan dokumentoitu. Kynnyksen tuottaa moduuleita tai muuta lisätoiminnallisuutta on oltava mahdollisimman alhainen.

6. Päivitettävyys

Ajan tasalla pysymisen on oltava mahdollisimman helppoa. Käsin tehtävä päivitystyö ei ole kenenkään intresseissä, koska se on itseään toistavaa ja virhealtista. Mitä laajemmassa käytössä järjestelmä on, sitä kriittisempää on suojautua tietoturva-aukkojen hyväksikäytöltä nopealla automaatti- tai puoliautomaattipäivityksellä.

Ajan tasalla olevat installaatiot myös vähentävät eri versioista välisten eroavaisuuksien aiheuttamia ongelmia, joita modulaarisessa järjestelmässä saattaa helposti tulla.

7. Skaalautuvuus

Nykyaikainen julkaisujärjestelmä on skaalautuva. Tämä tarkoittaa käytännössä, ettei järjestelmän ydinkään ole monoliittinen. Osaset ovat eroteltavissa toisistaan ja siten jaettavissa toisistaan täysin irrallisiksi kokonaisuuksiksi.

Tiedon tallennus- ja kyselytapa on abstraktoitu, jolloin voidaan ainakin tarvittaessa tallentaa tietoa tyypillistä relaatiotietokantaa skaalautuvammalla tavalla. Abstraktio ei saa merkittävästi hidastaa sovelluskehitystä, varsinkin kun useimmissa tapauksissa se ei ole käytännössä hyödyksi.

8. Avoimuus

Suljettu järjestelmä rajaa itsensä tehokkaasti pääasiassa avoimen webin ulkopuolella. Mitä avoimempi järjestelmä, sen vaivattomammin se on liitettävissä toisiin verkkopalveluihin.

Ideaalit rajapinnat webissä noudattavat REST-ideologiaa. Oleellisia rajapintoja ovat ainakin Atom (Syndication Format ja Publishing Protocol) ja OpenID – ja miksei vaikkapa OAuth.

9. Modernien web-käyttöliittymien monipuolinen tuki

JavaScript ja Ajax ovat oleellisia osia modernia web-kehitystä. Näitä on tuettava voimakkaasti. Tulevaisuudessa ainakin HTML 5 tuo kaikenlaista muuta uutta. Järjestelmä ei saa abstraktoida käyttöliittymätasoa niin, että täysi kontrolli merkkaus- ja HTTP-tasoilla katoaa.

10. Sosiaalisen webin perustoiminnallisuudet

Erittäin monella sivustolla tarvitaan rekisteröitymistä, käyttäjäprofiilia, sisällön kommentointia ja arviointia, vapaata avainsanoitusta, jopa sosiaalisten verkostojen luomista. Järjestelmän ydin on suunniteltava niin, että tällaiset asiat ovat joko kiinteä osa tai ne on helppo toteuttaa laajennuksina.

Julkaisujärjestelmän toivelistalle ei ole vaikea keksiä ominaisuuksia. On vaikeaa jopa rajata niitä lähtökohtia, joiden pohjalta ominaisuuksia aletaan valita. Web kehittyy edelleen niin huimaa vauhtia, että täydellistä alustaa ei mikään yksittäinen toimija voi mitenkään rakentaa. Ympärille tarvitaan vahva yhteisö.

Aikaa mitataan usein tunneissa, kun joku kirjoittaa hyvästä ideastaan webissä ja toiset jo julkaisevat alpha-versioitaan plugineista eri alustoille. Julkaisujärjestelmä ei voi olla menestyvä, jos se ei pärjää tässä todellisuudessa.