Archive | Learning RSS feed for this section

My other website behind the curtain

1 Jun

I’ve been editing the W3C website for a few decades now (gasp!) and in leading its redesign from the 2008 design, I am learning an astounding amount of new things about it! Here are some of the things I know about it.

Spotlight on the W3C website

In the 21 years I’ve been with the W3C, I remember only 3 different designs, the current one dates from a decade ago. Redesigning our website is crucial to improve the overall experience of those who depends on our Web standards work.

The website is managed by W3C itself and has been up for three decades. It currently contains over 2 million web pages. They’re static HTML or built in Perl, PHP, come from WordPress or are custom built using Symfony.

Tech stack summary

  • Debian Linux
  • Apache is used for serving the static content
  • MySQL for database storage
  • Varnish HTTP Cache is used for full-page caching
  • HAProxy is used for load balancing
  • There are over 3,700 Apache .htaccess files with different rewrite rules

Hosting & content

In a large-scale hosting setup, there are around 100 servers running Linux Debian on OpenStack, of which 20 to 30 servers are related to the primary website.

Web content is stored mostly in CVS and databases via CMS tools (WordPress, Symfony), and secondarily in GitLab and GitHub.

Most content is managed as static HTML edited locally (e.g. emacs, vi, BlueGriffon) and committed into CVS repositories using CVS clients, the terminal or HTTP PUT or WebDAV. Or, content is generated dynamically using Symfony or statically via makefiles, XML and XSLT.

25 instances of WordPress power the W3C Blog (over 950 posts) and W3C News (over 4,200 items), but also our Talks, working groups blogs, a test site, and W3C Community and Business Groups.

The W3C Homepage

The current homepage of the W3C website is a mix of HTML snippets which usually appears elsewhere on the W3C site, generated via XML, XSLT, PHP and other tools:

  • The News items are read from WordPress
    • The “homepage news” category determines what to show on the W3C homepage; we typically show up to 9 entries
    • The “top story” category determines which news item is expanded on the W3C homepage; we prefer to feature one, but have at times shown two or more
  • The right-hand side shows the last three posts from the W3C Blog
  • W3C Member Testimonials rotate from a database
  • The Events and Talks are shown from a Symfony app and WordPress respectively
  • The search bar links to an external DuckDuckGo search (that we chose for its good reputation for data privacy)
  • The rest is static

Markup errors in any of the source files will likely “break” the homepage. On average, I break the homepage 10% of the time!

Astuce peinture carreaux

22 May

Qui n’a pas pesté en repeignant ses carreaux muraux lorsque la peinture est chassée sur des zones recouvertes de restes de joint en silicone ?

Je ne sais pas vous, mais moi j’ai bien nettoyé ma surface au produit dégraissant, à l’anti-calcaire et à l’alcool, je l’ai grattée à la lame et je l’ai inspectée scrupuleusement. Alors quelles ne furent pas ma surprise et ma frustration de voir ma première couche de peinture blanche laquée chassée par endroits, en forme de points ou de traits, là où j’avais si fastidieusement nettoyé.

J’ai donc réfléchi à un petit hack et pris deux heures de retard planifié pour passer le lendemain des petits coups de stylo correcteur-blanc afin de remplir les zones non peintes, sachant fort bien pour en avoir fait l’expérience : ce qui ne se peint pas en première couche ne se peint pas. Point.

Puis seconde couche de peinture spéciale pour carrelage mural; nickel. On ne voit pas les raccords. Il faudra voir à l’usage comment ça vieillit.

Collage d'imagettes montrant la première couche de peinture chassée par endroits par du silicone, moi appliquant du tipp-ex pour combler, le travail achevé, et finalement, la seconde couche parfaite de peinture

The best work team

15 Oct

Eiko Nagase writesAny recurring meeting becomes stale over time if left unexamined.” I concur. For the meeting I run every week it’s become a drag after a year or so to even think of building the agenda. For some of the weekly meetings I attend, I sometimes don’t bother reading the agenda.

Eiko compiled a selection of tips to make your meetings less painful, such as changing the dynamics (location, space, time, participants, language, sound, tech) and concludes that “Constant iteration ensures that processes stay fresh and that, on the whole, they improve.

I think ‘constant iteration’ is either aspirational or a waste of time, unless you {are | have a member of your staff} dedicated to monitoring processes. Constantly iterating, if unexamined becomes stale as well. However, it’s healthy and useful to come back to processes, reassess them, and benchmark them against objectives.

hand-drawn illustration of a W3C face to face meeting, in a U-shaped room, showing people around the table in front of laptops, one person at the microphone, and slides projected on a screen

Above is my hand-drawn illustration of a W3C face to face meeting, in a U-shaped room, showing people around the table in front of laptops, one person at the microphone, and slides projected on a screen. This is one of the recurring types of meetings I run, but being part of a distributed team, the majority is weekly teleconferences and one face-to-face per year.

Here are elementary principles that work for me:

  1. Appreciate the people at your meeting and the time they give to your meeting. Your team, your people, your assets, your luck.
  2. Establish goals for the meeting. Building an agenda and sharing it ahead of time is useful. You may build it with your team. Remind your team of the agenda at the start of the meeting.
  3. Take notes, or find a scribe who does. Record salient points, questions, answers, actions and resolutions.
  4. Watch the time and keep to the time. Make sure you give appropriate focus to each item in the meeting docket. Don’t move to a new item without a clear path forward or next steps to the item at hand. If the matter can’t be resolved, state it. Options range from breaking out separately to further brainstorm, take the conversation to e-mail, or simply come back to in the future with fresher information.
  5. For face-to-face meetings, allow for mental breaks and bio breaks. When at a all-day meeting, typically I can focus intensely for 45 minutes or so, after which my brain will go on a break and wander freely for a few minutes.
  6. Don’t ramble. Don’t hog the microphone. Hear all the voices. You may need to tune how you seek feedback so that people feel confident to speak up.
  7. Share notes after the meeting. Executive summaries are valuable additions to meeting notes, especially if your thoughts are orderly and are at ease with words. Otherwise, my tip is to favour taking short notes and summaries, over verbatim records.

Eiko Nagase also advises to alternate technologies used as part of the collaborative work. I concur, with a note of caution: your choices have to take into account the ability of your team and the effort on-boarding them to a new technology requires.

In the case of my team, I chose to alternate between usual means of collaboration such as e-mail, IRC, wikis, and trying out a new thing, Asana, in order to keep my team’s wit sharp and have them step outside of their habits to tackle some projects from a new angle. We use Asana only when it makes a difference and rarely enough that it does. Otherwise it becomes a hassle and defeats the purpose. We’re not quite ready yet to move our work to Github ;)

I’d like to end with a few more tips regarding getting the best from the people you work with:

  • Know your people. Again, your team, your assets, your luck. 
  • Find out where their inclinations, talents and interests reside; use those. 
  • Follow their work, guide them, help them. This is the opposite of micro-management. 
  • Praise their achievements, appreciate and promote their work. 
%d bloggers like this: