To introduce the notes section on this website I wrote a module for Processwire that prefills the title field of a page with a configurable date string.
I recently implemented a notes section on this website which accompanies the regular articles. There are currently three different types of notes: short text notes, photos and tweets.
All of these notes are either published using the Processwire backend interface or syndicated via micropub endpoint. Each note then becomes a page in Processwire and therefore has it’s own URL.
I wanted to make adding these notes as easy as possible for me. One thing I had to consider was the fact that Processwire won’t let you create pages without a title. The title is also automatically translated into the URL for that page.
I didn’t want to enter a title each time I posted a note. I also wanted to create a consistent URL scheme that represented the date of the note’s creation. So I wrote a module that prefills the title field of a page with a configurable date string when the page is created.
The code is available on Github. It’s currently tailored to my needs, but I think it’s easily adaptable to other scenarios as well.
Beyond Tellerrand 2015
I finally managed to attend the Beyond Tellerrand conference in Düsseldorf this year and I had such a great time.
First of all, it just blows my mind how much attention to detail is spent on every aspect of this event. Everything is taken care of and you feel very welcome and well looked after.
Marc Thiele is organizing the conference on his own, which— after the two days I’ve spent here—seemed to me like a Herculean task. But as he mentioned in his opening statement: he does it just because he loves doing it. And I’m sure everyone who was lucky enough to have been here wouldn’t have the slightest doubt about that. Just amazing.
The selection of the speakers couldn’t have been better. The wide range of topics was just incredible and I enjoyed every single talk.
For me, the most interesting notion of the last two days was to take a step back and look at the basic building blocks the web is made of and—even more important—why that is the case. A notion of quality over quantity – not running after the latest innovation but instead building and caring about something that’s here to stay. In that regard, the talks of Jeremy Keith and Christian Heilmann stood out for me.
I’m leaving Düsseldorf tomorrow morning, fueled with stuff to think about. And I wouldn’t hesitate a second to come and attend Beyond Tellerrand again!
IndieWebCamp in Düsseldorf
To be perfectly honest: I didn’t have any expectations of IndieWebCamp when I arrived here in Düsseldorf last friday. But the whole weekend turned out to be such a great experience.
The last two days have been packed with interesting discussions and ideas on how to own the stuff you put online. But I guess what intrigued me most are the things that can be done by people who really care about something.
I was pretty impressed by how much people got done. At the final demo session, everyone had something he or she had done to update their website – although I’m pretty sure that the end of this event will not be the end of their efforts to try and own their stuff online.
I’m really excited about the opportunities to declare responsive images directly in your markup. To make this a little easier for me I wrote a module for Processwire.
Recently, I’ve been looking for an easy way to use the <picture> element with Processwire. By easy I mean this: the user uploads an image at a reasonable size and Processwire does the rest. (I just noticed you could interchange “easy” with “lazy”)
So I wrote a Textformatter module that allows you to do just that. Via the module configuration page you can specify multiple sizes and media queries which the module will then use as <source> elements when rendering the page. You can also provide a fallback image size for browsers that do not yet understand the <picture> element.
The module uses Processwire’s image sizing capabilities and resizes the original image to the configured sizes, when the page is rendered. It then replaces all the <img> elements with the appropriate <picture> element.
You can get the module from Github. It’s still a bit hacky and I have some more features in mind that I want to add. But it does it’s job quite nicely so far.
Coding conventions for small teams
Among constantly growing development teams, things like version control or issue tracking have become indispensable. Unlike those tools, coding conventions are often overlooked – some notes on my workshop last week.
I’ve been working alongside a client’s web development team for quite some time now, but it hasn’t always been that way. When I first started working with the company, there were just two of us: a PHP developer—mostly doing Magento e-commerce systems— and me, a front end developer/designer making websites.
The team has grown over the past few years. Today it consists of eleven developers working side by side on projects rather than just working on their own like we did when there were only the two of us.
Challenges of growing teams
As the company grew and people joined the team, we adopted tools like git and JIRA to tackle certain issues such as shared source code, version control and issue tracking. But eventually we were facing another problem: there were no coding standards that defined how we should write certain source code files.
At least none that the whole team agreed upon. Sure, everyone knew how to write HTML documents or style sheets but when it came to things like naming classes, indentation, semantics or using SASS, there were a lot of different opinions on what could be considered readable code.
Working without coding conventions can be very time consuming, especially when there are multiple developers involved in a project. Reading and understanding someone else’s code can be a real challenge, especially on large projects.
When developers keep editing the same files without any coding guide lines they often end up with some kind of Frankenstein code that everyone throws their own class names, indentations and document structure at. The result is almost every time very hard to maintain and it takes developers joining the project a very long time to work their way through the potpourri of different coding styles.
How we defined our coding conventions
The first thing we did was to find common ground - rules that we already worked by and that we all silently agreed upon. Then we looked at best practices suggested by w3schools, CSS guidelines and jQuery to develop our own set of rules for writing front end code. These included things like formatting, indentation, using and naming classes, variables and functions and so on.
Last week I ran a workshop on front end coding conventions for that particular development team. I also prepared a cheat sheet for everyone’s desk. You can download it here, perhaps it might be useful to you.
I think coding standards are invaluable in a collaborative environment. They ensure proper document structures, consistency and easier maintenance of legacy code.
A fresh start
I always wanted to write more. Since the content of this website was terribly outdated and the site needed to be relaunched anyway, I thought why not turn it into my personal journal.
Although the relaunch isn’t much of a relaunch. It is more of a fresh start – a new launch. This site used to be my online portfolio and blog where I shared the way I had been working as a photographer.
When I started doing webdesign in 2007, I instantly fell in love with the web. Becoming very passionate about it, I spent a lot of time learning and later setting up my own business in 2009. The frequency of my writing declined until I finally stopped altogether.
Writing has always been a part of my life. I’m also a great believer in sharing – that’s why I started writing in the first place. So I decided to share and write about stuff related to the things I do now. The things that I am passionate about.