First of all: this devopsdays conference—once again—inspired me. It refreshed my desire to make the world (or at least a part of it) a better place.
A big change in the format was that each speaker only had a 15 minute time slot. This was done to allow more people to speak. While the organization certainly succeeded in that regard, I felt that most talks were too short, that is: I would have loved them to last longer.
It felt like the conference was less technical. Perhaps this was because of the length of the talks, which meant the speakers could not go as deep into a subject as with a 30-minute talk? Perhaps it was because there were no workshops where I usually get (more than) my dose of technical deep dives? Perhaps it was just me?
Note that this is not a complaint about the speakers. Each and every one of them did a great job and had an inspiring talk. I really appreciate them taking the stage and sharing their knowledge, experience and opinions with us. Thank you all!
I talked to a number of sponsors and would like to do more research on certain products. Examples:
During the ignites on the second day, a few other conferences were mentioned:
One of the open spaces I joined was about home labs. I only have a small setup at home, but I did get a few ideas out of this session that may be worth checking out.
But the most important question, in my opinion, that was asked during this
session: do you have a disaster recovery plan for your home lab?
What if I’m not around and something breaks down, like the WiFi, how does my family get things up and running again? Spoiler: they probably won’t. And this is not their fault. I made things more complex than needed (from their perspective that is) and failed to provide instructions on how to solve issues.
On meetings:
On toil:
Random, unrelated stuff:
Something that was said during an open space about testing infrastructure-as-code:
You deploy infrastructure not to have that infrastructure, but to run an application on top of.
I don’t recall who mentioned it, when and what the context was, but r/devops might be fun to read.
]]>This has been the third time I went to devopsdays Amsterdam. And I love this conference!
Some of the reasons:
I had heard about Go, some of my co-workers have some experience with it, but I never wrote anything in the language. I was curious about it though.
The workshop from Michael Hausenblas was a nice intro. Based on what he told and showed us I cannot say that I expect that Go will replace Bash and Python for me. However, I will make some time to actually write some code myself to get a better feel for it.
We are already using the Elastic Stack in some places at work, but I have not used it for monitoring purposes. (I gravitate towards Prometheus combined with Alertmanager for alerting and Grafana for dashboards with graphs.) However, Philipp Krenn showed us that you can also do very interesting things with Kibana in the monitoring and debugging realm. Especially since you can correlate metrics with logs in the same tool.
I could say that Bridget Kromhout’s Kubernetes workshop was a nice refresher of what I had learned in the Kubernetes workshop last year but, to be honest, that would be a lie. I am glad I took this workshop.
It was a good workshop with lots of hands-on tasks. But it went a bit too fast to make it stick. I would have to spend more time on a Kubernetes cluster to really understand everything and get fluent with it. Luckily there is lots of information on container.training (including the sheets of this workshop) and there are plenty of cloud providers where you can get a Kubernetes cluster without having to create or maintain it yourself.
The talk that resonated most with me this year was the one from Waldo Grunenwald about product teams. Perhaps because (in my opinion) this is something that could be better in my job. Product management, development and operations are three different teams with different managers. Then again, I currently try to be the “ops guy” in our development team so that’s also DevOps, right? :)
The other most memorable talks for me were:
I have been using Emacs for quite a while. I was a Vim user in the past, but switched somewhere between 2007 and 2009. (The first time I wrote about Emacs here was in 2009.)
I have tried PyCharm a couple of times and it is a really nice editor with very useful features. It just never stuck with me and I always went back to Emacs after a while.
During the conference I used Visual Studio Code to write my notes. And I have to say I quite liked it. I intend to also give it a go at work. Who knows, I might even switch…
]]>An approach that is quite popular these days is to create a separate
mobile site. In most cases visitors of the ‘desktop’ site of
example.com
are redirected to the mobile version on m.example.com
as soon as the site detects (or thinks) that the client is a mobile
device.
And there we already see the first problem with this approach. What exactly is a “mobile device”? We can probably agree on a smartphone. But what about tablets? An iPad, for example, has a resolution of 1024 x 768 pixels. Isn’t that the same resolution a lot of designs are made for?
So is an iPad a mobile device? If your answer is no, what about an iPhone 4? With a resolution of 960 x 640 it gets awfully close. So is every smartphone a mobile device? Perhaps we should focus on the size of the screen. But where to draw the line? 10 inch, 7, smaller?
Perhaps the term “mobile” should not be defined just by the specifications of the device, but by how the device is used. For instance, you would probably use your smartphone while waiting in a queue, but not your laptop. However, using that definition will open another can of worms.
The life of a modern web developer is even more complex. We may want to optimize the content of the mobile site or application for low bandwidth conditions of 3G or EDGE networks. But user agent sniffing doesn’t help here. Smartphones can also be on Wi-Fi. And the other way around, laptops can be tethered and thus have to suck your heavy desktop version through a straw.
In other words, the user agent or even the type of device your are working on, has nothing to do with how much bits per second can be consumed. As a result you should probably try to keep the size of your site to a minimum either way.
There are bad implementations of mobile websites out there. A simple example: you see a link to an interesting article on Twitter. You click on the link and you are directed to the homepage of the mobile site. Good luck finding that interesting article on the mobile version…
Or the other way around: you are reading a nice article on your phone and want to send the link to a friend. Now he’s stuck with the mobile version of the article on his 22 inch monitor.
Another complaint I have is that the mobile sites are often dumbed down. For example a restaurant that only shows the menu and contact information on the mobile site. Perhaps I want to get a feel for the place and like to view the photo gallery. But now I have to switch to the full version. If that option is even available!
Instead of having a separate mobile site, you can use responsive web design. With this approach you use css media queries to change the layout of the page, while serving the same HTML and the same content. In other words: you don’t necessarily care about the type of device your visitor is using, you set the rules on how things should be displayed on certain widths and let the browser handle the rest.
With this approach you do not design separate sites for distinct devices, instead you design for a range of resolutions. So if next month a new device comes on the market, your site will probably be ready for it. (The obvious exception is when the new device does not fall in the ranges you had anticipated, e.g. a television with a really high resolution.)
Other people, like Ethan Marcotte in his responsive web design article, describe the concept a lot better. Mikko Ohtamaa also just started a series of blog posts that promises to be very interesting.
Don’t get me wrong, having a (separate) site specifically for mobile devices certainly does have its benefits and can be a good solution. But in my opinion it should not be the first option when building a website or web application that should be “mobile aware”.
Actually, I do not have a conclusion… Although I think responsive web design provides a good solution, it is not the holy grail. As I said at the start of this article, we live in exciting times. There is a lot we still have to discover!
]]>First of all a designer needs to be creative. After all, they are the person that needs to capture the ideas of the client and visualize them. However, it is also very important for the designer to understand the web. Something that works in print, may completely fail in a browser. One of the reasons is that print media is meant to be seen/read, while websites need to be interacted with. Closely related is anticipating user generated content. This means that a design should also look great with less (or more) text than the lorem ipsum in the design.
I think these skills are not disputed. But what about the ability to code? I agree with Lukas Mathis that there are risks when designers are also involved in implementation. In his essay Designers are not Programmers he more or less says that designing and coding are two separate worlds. To be able to be good at designing, you’ll have to ignore everything you know about coding. Otherwise the design is restricted by technical limitations: you know what you can implement and you’ll design within those boundaries. Even worse: by already thinking ahead about the way it’s going to be coded, the focus will be on the code instead of the user experience.
A related discussion is what the deliverable of a design should be. In most of the projects I’m involved in, the design results in a Photoshop file. This file is then cut to extract the needed graphics and the HTML/CSS is coded. I guess you know the drill.
However, quite often the role of designer is combined with the role of front-end developer, especially in smaller shops. In these cases it can be easier to do the design in HTML directly, as described by Meagan Fisher in Make Your Mockup in Markup. (The Django package django.contrib.webdesign even helps by generating sample text.1) One advantage is that some design changes are easier to make in CSS than in Photoshop. Depending on your skills, the whole design process may even be faster. Meagan also demonstrates that CSS3 gives you the ability to create a lot of effects without having to resort to images, which means you’ll have to spend even less time in the graphics editor.
Another advantage of designing in HTML is that the client can see
how the design works in the browser. You have to be careful though:
since it’s only a design, it’s very likely that the code is not cross
browser compatible yet. If the client uses a wrong browser, the design
may not come across as intended. (To prevent this, you could export
the page as an image e.g. by using the Firefox add-on
Screengrab. no longer available)
You’ll also carefully have to manage client expectations. If the design is done in HTML, the client may incorrectly assume the front-end work is done. They may not appreciate the time that is still required to make the site look good in all targeted browsers. Or the time needed to make the static HTML more dynamic by integrating the application or adding AJAX effects.
Perhaps the most important skill of a good designer is being able to communicate. Not just because the design should communicate the right things, but also because communication with the client and development team is, in my opinion, the key to success.
Update (2021-07-16): As of Django 1.8 this functionality is provided via the lorem template tag. ↩︎
The first article I read is called It’s OK Not to Write Unit Tests and is written by Chris “cashto” Ashton). Although Chris isn’t saying that all unit tests are worthless, he attributes less value to them than they deserve, at least in my opinion. For the projects I’ve been working on, unit tests can actually be very useful.
For example, I’ve frequently caught bugs after refactoring because a unit test failed. Does this make me a bad programmer? Unit tests can also be used to define the API of a certain piece of code. By writing unit tests in the form of doctests you are forced to think about the way something should work and at the same time document it.
The other article I’ve read is The Problem with Unit Testing. Although I like test driven development, I wholeheartedly agree to the view that 100% unit test coverage is probably overkill in a project. You’ll constantly have to evaluate whether writing a unit test for a piece of code is worth it. For code that is more or less isolated (only used in a tiny part of the project), very straight forward and easy to debug (worst case scenario), I’m likely to skip writing tests for instance.
Note that I’m only talking about unit tests here. There are many more ways to make sure the quality of your code is what it should be.
]]>The Joel Test was devised to rate the quality of a software team. In contrast to other methods, it is designed to quickly provide some basic insight in how a team is doing. And although Joel used the words “highly irresponsible” and “sloppy” I though it was fun to see how we at Zest rate.
We mainly use agile development to create buildout based Plone applications. In answering the questions, I’ll focus on those type of projects.
(Disclaimer: obviously this represents my own view on the matter and is not necessarily the opinion of Zest or any of my co-workers.)
Yes! I cannot even imagine working without it. We mainly use Subversion but some of us are (or have been) experimenting with other source control software, like Bazaar , Git and Mercurial.
Hmmm… tough one. We don’t really “build” in the traditional way. Since Python is an interpreted language, we don’t need to explicitly compile. For instance: restarting Zope is enough to use the latest code (and with plone.reload restarting isn’t even necessary in many cases).
But okay sometimes you’ll have to rerun the buildout to get/update all the dependencies. Rerunning buildout is a single step so I’ll count this as a yes.
In the way Joel describes this, it basically translates for us to doing a clean checkout, running the buildout and then running the tests. (Assuming the tests include integration tests which need the whole Plone/Zope stack.)
But no, we don’t do this. We did have buildbot running for a couple of projects to run the tests after every commit, but I have to admit we are not doing this often enough.
Yes we do. If we encounter a bug, we store it either in a (user) story or we put it in the issue tracker associated with the project.
This depends on the project. Most of the time we try to estimate the time needed to solve the problem and report back to the customer if we expect that the fix will take a significant amount of time. Since in Agile development the customers set the priorities, they can decide that the bug is less important than getting a new feature in the next release.
For our own projects or community projects we do want to make sure we ship code as bug free as possible and in general we give bugs a high priority.
For each project we maintain a list of features in our project management tool. Each feature (or story in XP terminology) has an estimate of how much time it will take to implement. So we can determine when the project will be done.
However, at each iteration meeting the customer could decide to add new feature, change the priorities, etcetera. So the schedule is in no way set in stone.
Each story in the project represents a single feature. Since the set of features for a project isn’t static (new ones can be added, others can be dropped), we don’t write a lengthy document specifying every detail of a project. We tend to describe the feature in a couple of sentences in the story. By splitting it up in tasks when we start working on it, more details are added.
(By the way, not writing specifications and justifying that by saying “XP doesn’t need specs” is wrong in my opinion. You do need to have other practices in place to compensate the lack of written specs.)
Another characteristic of agile development: we only build what is requested. That is: we don’t try to accommodate for every possible future use case of a feature. We try to find a balance between iterative design and thinking things though enough to limit the refactoring needed when more use cases have to be implemented.
And since we have iteration meetings every (other) week where we demo and discuss the work done in the previous iteration, the customer has the opportunity to refine their ideas.
No we don’t. Which is a good thing when sprinting on a project: by having all developers in the same room it is incredibly easy to exchange knowledge. Pair programming also helps here. In my experience if one of the partners gets distracted by the discussion (e.g. to answer a question) the other half of the pair can quickly get him focussed again.
When we are not sprinting though, it can be a bit hard to focus on your task. Especially if co-workers are discussing a project on which you aren’t working right now, but you are familiar with. (Perhaps I’m overly curious and therefore more easily distracted…) However, at the office we do have a place where you are isolated from the other developers and it is also possible to work from home.
If we need tools and our demands are reasonable, sure. It just happens that many of the tools we think are the best, are open source tools. (Although it also depends on the platform that is being used. I’ve got the feeling that the Mac users at Zest use more proprietary software than the Linux users.)
No we don’t. This doesn’t mean our software is deployed at random though. First of all we try to write automated tests (unit, functional and integration tests), although I do have to admit that this heavily depends on the quality level the customer asks for. But this is a different discussion.
Furthermore: usually the project manager tests the application to see whether it meets the requirements. Then we demo it to the customer. And finally: most of the times we first deploy the code to a preview server where the customer can play around to test it.
No, as far as I know we don’t require candidates to write code. (I certainly didn’t have to do it. :) ) But at the same time we also haven’t yet hired developers that didn’t meet up to our expectations. Perhaps we don’t have as high standards as e.g. Joel does, perhaps it has to do with the fact that we are a small company. I don’t know.
It’s no excuse, but this is hard to do this if you’re in a small company. I think most co-workers are too “technology infected” by now to give a completely objective opinion. If you’ve been working with a system long enough (e.g. Plone) you get used to it’s quirks.
However, we do frequently request co-workers to give a second opinion about the (user) interface. And since we work in short iterations, the end-user also gets to work with the software shortly after writing it. So any strange behaviour should be detected quickly.
Perhaps I’m not being objective, but I think that some of the questions from the Joel Test don’t fit in our development process. I therefore don’t want to calculate a score but let you draw your own conclusions. I certainly found a couple of areas where we can improve…
]]>Yesterday in the early afternoon the travel agency picked us up at our hotel and brought us to Corfu International Airport. And there it all began:
Somewhere in the couple of hours we were at the airport it occurred to me that there may be more reasons for this process than just logistics. By having people stand in lines and waiting for some time, they will become somewhat numb. Which is a good thing if you want to cram as many people as possible in a limited space for a couple of hours…
Perhaps the above is quite obvious for frequent flyers, it was a small revelation to me. Oh well, I’m glad to be home again. :)
PS Our holiday was great actually. That’s not the reason I’m happy to be home.
]]>