freistil News

« Older Latest Newer »

For the first time, a DrupalCamp directly addressed both businesses and the developer community in Germany (and its German-speaking neighbours). And it was a great success. Taking place in Heidelberg from April 8 to 10, the Drupal Business and Community Days ran a business-centered track with expert presentations in parallel to a community track in which Drupal developers worked on Drupal code and documentation.

The Business Days […] will be an opportunity for the German-speaking Drupal Business Community to get together, and work on strategies for growing Drupal within Germany, Austria and Switzerland. The Community Days […] will be international, with participants from all over Europe. The Community Days will be English, German, and hopefully a few more languages. The community event will have a focus on core, translation, and D8 User Guide sprints.

Why did the event team around Drupal Company Erdfisch choose this kind of topic split? They wrote about their reasoning on the event website:

In Germany, Drupal has an amazing developer community, but it is not as well known as a business product as it is in other countries. We need to work on that!

They did a great job. And having business relationships around Drupal proved helpful quickly: When the venue’s internet connection didn’t hold up, Erdfisch was able to get the University of Heidelberg to offer space at their data center so the development efforts could continue.

You could tell from the high attendance of the business track that providing products and services around Drupal is an important topic for businesses in D-A-CH. In Germany, all the leading Drupal businesses have realised that the market is big enough and treat each other as colleagues even though there’s competition. This opens up the way to share experience and learn from each other. A rising tide floats all the boats, and as businesses we can only benefit from conferences like this one. That’s why we were happy to support the event both as a sponsor and as active participants.

The freistilbox team had planned to attend in full force but unfortunately, I had to stay at home fighting a nasty virus that afflicted the whole family. In consequence, I wasn’t able to give my talk “How not to be afraid of your own success”. Instead, our friends at the Palasthotel stepped in with a great session about their new Drupal development workflow.

In total, 118 people ranging from “interested in Drupal” to “enthusiastic for Drupal” attended the conference. After it concluded, praise for a great DrupalCamp came not only from German attendees…

…there were also people from Canada (!)…

…from the Netherlands…

…from Belgium…

…and probably a few more countries — it was a great weekend for the international Drupal community.

The freistilbox team had lots of fun meeting old and new friends, and we also learned new stuff. So, thanks a million to Erdfisch for organising a great DrupalCamp! We’re looking forward to the next Drupal Business and Community Days!

geewiz

19 Apr 2016

From April 8 to 10, the beautiful city of Heidelberg will be the location for the first Drupal Business and Community Days in Germany.

With a different format from usual DrupalCamps, this event aims at kick-starting Drupal business in Germany and building on both the German-speaking and international Drupal community, literally at the same time: there will be a business track and a community track running in parallel.

The Business Days part will be an opportunity for Drupal businesses to get together and work on strategies for growing Drupal within the DACH region. While Drupal has an amazing developer community here, it is not as well-known as a viable option for businesses as it is in other countries around the globe. This lack of professional reputation is what this track is going to improve.

Under the track’s motto “From acquisition to maintenance”, Drupal experts will share their experience on business topics such as lead marketing, hosting, infrastructure, quality assurance and support. One of these talks will be “Keine Angst vor dem eigenen Erfolg” (“Don’t be afraid of your own success”) in which our CTO Jochen Lillich will shed some light on how to tackle the daily challenges of running a business-critical Drupal website.

Taking place at the same weekend, the Community Days are going to be quite international with attendees coming from all over Europe. Based on the Sprint format common at DrupalCamps and DrupalCons, the Community Days are going to focus on improving Drupal core, translations and D8 User Guides. For participants who have not yet contributed code or documentation to Drupal or feel just a little bit rusty, there will be mentors to help them get started.

The freistilbox team is going to attend in force; this’ll be one of the rare opportunities to meet Markus, Philipp and Jochen at the same physical location. And since we know what actually drives DevOps practicioners around the world, we’re sponsoring one of the coffee breaks.

If you’re part of a Drupal business in Germany, Austria or Switzerland, you don’t want to miss this event. See you in Heidelberg!

geewiz

22 Mar 2016

We use the following configuration snippet in our Apache VirtualHosts on freistilbox:

# Cache TTL
<IfModule mod_expires.c>
  ExpiresActive On
  ## default: 4h
  ExpiresDefault A14400
  ## text/html: 15min
  ExpiresByType text/html A900
</IfModule>

This snippet takes care of proper HTTP caching headers when the web application doesn’t set caching headers itself. The values used here enable Varnish to cache files for 4 hours, HTML content for 15 minutes.

Today I learned that if you want to override this, it’s not enough to simply set the header Cache-control: max-age=600 to change the caching time to 10 minutes. mod_expires is quite strict in its interpretation of the following lines:

When the Expires header is already part of the response generated by the server, for example when generated by a CGI script or proxied from an origin server, this module does not change or add an Expires or Cache-Control header.

When you only set Cache-Control: max-age=600, the web server adds another Cache-Control: max-age=900 and an Expires header. Confusing, right?

To properly control both headers, you have to set an explicit Expires and everything works as expected.

muhh

16 Mar 2016

Last weekend, I had the pleasure of attending the fourth instalment of DrupalCamp London. It’s grown from humble beginnings in 2013 to one of Europe’s most important Drupal gatherings. This year, more than 500 Drupal fans met at London City University to attend the CxO Day on Friday and/or the community talks on Saturday and Sunday.

The CxO Day was a good opportunity for leaders of Drupal-based businesses to meet and exchange experiences. I especially enjoyed Vesa Palmu’s talk “Growing your agency: Organic, mergers and acquisitions” about the different ways to grow a business; lots of good advice!

Over the weekend, the wider Drupal community came together to listen to talks, work on Drupal 8 and enjoy the “Hallway Track” (consuming more than 100l of coffee and 400 pastries in the process). Clifton Cunningham’s enthusiastic keynote was a great start, although I’m afraid that his insights into building a big web application developed in-house doesn’t 100% apply to Drupal; for example, you can’t just split up Drupal into microservices maintained by separate teams. The following sessions held by community members were much more Drupal-centric, of course, and most of them touched on the upcoming Drupal release 8 in some fashion. Since I’m not a developer, I chose quite often to engage in hallway conversations instead of attending presentations. From the few I did attend, I took away these points:

  • After learning about Bigpipe in “Drupal 8 with Cache and Bigpipe” and about AuthCache in “Don’t Varnish over the cracks”, I just can’t wait to see our customers flip the afterburner switch for their authenticated website visitors!
  • It was interesting to see a more modular approach to what we do with our laptop script in “Provision your Mac with Ansible”.

In parallel to the sessions, some developers (a whopping 70% of which were female) gathered for the “Sprints”, group coding sessions that resulted in 2 solutions to Drupal 8 issues being “Reviewed & Tested by the Community”. Well done!

For me, the highlight of every DrupalCamp is always the people. I met lots of familiar faces and again managed to confuse a few new acquaintances with my peculiar mix of German and Irish accents. I thoroughly enjoyed DrupalCamp London and will make sure to register early as soon as DrupalCamp London 2017 is announced. Thanks and congratulations to the #dclondon team for another great Drupal community event!

geewiz

10 Mar 2016

In December, our team met for the fourth instalment of “freistil Days”, our company retreat. This time, we came together in Dún Laoghaire, one of the lovely seaside parts of Dublin. We’re now pretty much settled on a week-long format, with Monday and Sunday being the travel days, respectively. The purpose is still the same:

  • spend some time living and working together at the same place,
  • see a bit of our host city (previously, we’ve been to Barcelona, Rome and Hamburg),
  • enjoy the experience of intense productivity and cross-pollination of ideas, and most importantly,
  • learn to know each other better.

Working together

This time, the project we had chosen was integrating Consul into our infrastructure. Consul is a distributed key/value store and service discovery tool. Until now, the only central database for our infrastructure has been the one in Chef, our system management tool. While Chef enabled us to improve our servers-per-sysadmin ratio continuously, it has its limits regarding dynamic infrastructure orchestration. Using Consul, our services will be able to register all kinds of events and react immediately, for instance, a new application server being added to a cluster, a domain name of a customer website getting changed, a database cluster node having too much load, just to name a few. We expect Consul to make our infrastructure much more elastic. It will also help us eliminate the annoying 10-minute delay between configuration changes and their execution.

Living together

While working on our laptops on a single table allows for fast project progress, it’s also quite intense! Sharing a place has more profound effects on us than mere efficiency. Most importantly, it exposes personality traits you don’t usually discover during short video calls. One colleague might prove to be an excellent cook; someone else might have awesome drawing skills or be a gifted guitar player. It also sheds more light on our, say… less-developed sides. Suddenly there’s time for a discussion to span more than the usual 30 minutes, and it becomes apparent who struggles to focus and who starts impatiently interrupting others to get their point across. freistil Days are a great place to improve our communication skills and we get to understand each other better all the time. And after a heated debate, going out for a pint in one of Dublin’s amazing pubs was sure to help us cool down again. ;-)

Exploring together

During freistil Days, hump day is always excursion day. Everyone on the freistil team seems to like Whiskey, so we decided to visit Jameson Distillery on Thursday. Before, we had the opportunity to attend a talk by Rowan Manahan, the @presentormentor, about “The art and heart of public speaking”. Rowan apparently struck a nerve with Markus, who immediately started planning a talk for WordCamp Europe!

After we had a yummy breakfast at Brother Hubbard and moved to another coffee shop to check our email, we experienced the downside of being out and about with the whole team: reacting to emergencies gets a bit more complicated. A newly hired web developer of one of our customers called because he needed urgent help getting started with freistilbox with a launch deadline looming. Markus managed to take the pressure off quickly; he set up a Skype call from one of the empty tables outside and proceeded to give a thorough explanation of all the core concepts of our hosting platform.

On our tour at Jameson Distillery, we learned all about the essentials of Whiskey-making — and had a taste of the result, of course. After that, we took a stroll through town and finally headed home very satisfied (and tired enough to call it a day early).

Succeeding together

So what results did we achieve during this week? Apart from making our first steps using Consul in production, we also got the

freistilbox Dashboard ready for launching its public beta phase. Doing a serious software development project is a great learning experience for us as an operations team. The Dashboard will not only give our customers the long-awaited self-service experience but will also improve our internal workflows and tool chains.

This realization led us to choose “team workflows” as another central topic for our retreat. Making our internal processes more efficient has always been the key to how a small team as small as ours can manage a steadily growing hosting infrastructure running many hundred high-profile websites. At freistil Days Dublin, we had intense discussions about how we can adapt concepts like Test-Driven Development and Continuous Deployment for our daily development work, which is building the software code that gets and keeps our servers running.

All in all, we had a great time in Dublin. We added new technology to our arsenal. We had quite a few laughs over quite a few beers. We took a stroll through Europe’s tech capital. We learned new skills and got to know each other better. That’s what our company retreats are all about. And in May, freistil Days V are waiting!

geewiz

03 Feb 2016

It has been a planned feature right from the start. But many months went by and it sort of became the Duke Nukem of the web hosting world. I’m talking about the freistilbox self-service web user interface, of course. Often requested, often promised, never delivered. Now the time has finally come to prove this mythical creature actually exists!

When we started freistilbox as a two-founder team, we didn’t have the capacity to both build an enterprise-class web hosting platform and run a serious software development project at the same time. So we decided to focus on the hosting platform first and do the customer dashboard “a tiny bit later”. Little did we know that our growing number of customers would keep us busy building new platform features and improving the existing ones for quite a while…

At first, we didn’t worry too much because being in close contact with our customers has been and will continue to be a central aspect of our strategy. In fact, each support request asking for a new website instance was an opportunity to learn what our customers were doing and to help them get started quickly. But with every new customer, it became clearer that this approach could never scale. Not having a self-service interface caused confusion and frustration for our customers and an ever increasing amount of support tickets for our tech team. There was no way around it — we had to make a change.

The name of this change is “freistilbox Dashboard” and we’re launching it today! Simply go to dashboard.freistilbox.com and sign up for a user account.

If you’re already using freistilbox, don’t worry about the fact that when you log in for the first time, you won’t see much. That’s because your new account is not yet associated with your freistilbox resources. So, as soon as you’ve signed up, simply use the support chat button in the lower right to let us know, and we’ll connect your account with your existing hosting resources.

By the way: We plan to add this live chat to our official support channels and we’re using the Dashboard beta phase as an opportunity to put it through its paces.

Beta phase? Yes, the freistilbox Dashboard will be a work in progress for some time. It currently offers only a view of your basic hosting details and you can’t make any changes yourself yet. But we’re already testing its self-service features internally and will make them publicly available in January.

We’re very excited to finally be able to provide you with a customer-friendly web interface that spares you the effort of keeping your own list of website details and sending support requests for every little change. We admit that it’s taken us a long time to get this far, and we apologize for all the inconveniences.

We’re determined to keep our current momentum and will continue adding new features on a regular basis. If you’re curious what we’re working on at any given time, simply visit the public freistilbox Dashboard roadmap [Update 2016-02-22] issue queue and development milestones. We’ll happily consider all your feature requests, so please don’t hesitate to give us feedback and let us know what you’d like to see next!

Do you have any thoughts about the launch of the freistilbox Dashboard? Let us know on Twitter!

17 Dec 2015

Dear freistilbox customers, the end is near. The end of the year, to be precise. And just as many of you, the freistilbox team is taking the holidays as an opportunity to wind down, relax and recharge.

From Thursday, 24 December, we’ll be off and our technical support will be limited to real emergencies. So, should incidents occur that impact the operation of your production websites, our 24/7 on-call will get them resolved quickly.

Support requests that aren’t related to such incidents, though, will have to wait until we’re back on Monday, 4 January 2016.

There’s still a week left to get things sorted, so we recommend you get in touch as soon as possible if you need our support for a last-minute project or for work you’re planning for the time between the years.

From the whole freistil IT team, thank you for another awesome year, have a happy Christmas and a great start into 2016!

15 Dec 2015

Doing business without a central office has become more popular over the recent years. These distributed companies vary widely in size, well-known examples being Automattic, GitHub, AgileBits, Canonical, Acceleration Partners, Doist, Lullabot and Trello. Other businesses join in and get rid of their existing office:

The obvious advantages are savings on rent and a far wider reach in recruiting new team members without them having to relocate. But the “remote work” approach also has downsides that make businesses shy away from this approach, most notably Reddit and Yahoo!.

Five years ago, I decided to build a virtual company, and I’ve not regretted it ever since. In this post, I’m going to outline why.

Going remote

After I had left my job as Head of IT Core Services at 1&1 in 2009, I had a few months of garden leave for deciding what to do next. I had started a number of IT businesses before, and the entrepreneurial itch was strong enough that I was going be my own boss once again.

My daughter had been born a year earlier and while sketching out my business (literally, using the Business Model Canvas method), I much enjoyed being at home with my family. When I was in a productive mood, I did some work. When I felt my mental batteries draining, I took a nap. When I wanted to cuddle one of my girls, I shut my laptop and went next door. When I needed a change of scenery, I packed my bag and left for Starbucks or the Botanic Gardens. Not until much later I learned that what I was enjoying was called “work/life blend”.

A few months later, I started an enterprise web hosting business. Right at that time, Jason Fried and David Heinemeier Hansson published their new book. In “REWORK”, they share their view of business, strategy, customers and how to run a successful team, and this view differs a lot from the common corporate approach. Immediately, I fell in love with their philosophy of “keeping it real”. Inspired by statements like “Planning is guessing”, “Mission statement impossible” and “Decisions are temporary”, I named my new company “freistil IT”, German for “Freestyle IT”, and I was determined to do business my way. For example, freistil IT was going to be set up from day one as a virtual business with its employees working remotely. I wanted everyone on my team to enjoy the same level of freedom, flexibility and sense of achievement as I did.

Running a remote team in a sustainable way isn’t trivial. While there are lots of tools that allow a distributed team to collaborate, it is a challenge to foster effective communication and build a coherent company culture. Quoting from REWORK:

“You don’t create a culture. It happens.”

But where does culture happen within a virtual company? When there is no central office, opportunities for a few minutes of chat don’t present themselves randomly. In a distributed team, communication and social interaction need to be much more intentional. Many of the things we had to learn you can now find summarised in the latest book from Fried and Heinemeier Hansson, “REMOTE — Office not required”. In the following section, I’m going to highlight what I found to be the essential aspects of remote work.

You can not overcommunicate

A company lives and dies by communication. And I don’t mean just the intentional transfer of information in one-on-ones and conference calls. That’s what email and a host of video conferencing tools are for. But on top of that, there’s a huge spectrum of information floating around freely within healthy companies. The fact that Sue finished her first marathon last Saturday. The huge enterprise deal Sales managed to win. The reasons why Alan’s putting in a lot of extra effort to make a certain customer happy. In a distributed company, this information doesn’t disseminate as easily as where people are co-located.

Project management platforms such as Teamwork (a great fellow Irish company, BTW) or Asana are important tools to coordinate work with a remote team. But as much as they give structure and focus to project-related communication, they can’t fully prevent frustration and loss of efficiency. “Why did she assign this task to me of all persons? Surely she knows that I’m already booked to my ears this week!” Yes, she does indeed; she just didn’t take the time to add a short comment that this task doesn’t need to be done until the end of next week. Had this happened in a real-world meeting, she would probably have noticed the frown creeping onto her colleague’s face, or the hesitation in their voice, and would have quickly clarified the timeframe. In written communication, though, this immediate feedback just isn’t available. You’ll only find out that your teammate is grumpy later, if at all. I’ve been guilty of the sin of omission so many times that I’ve put a sticky note on my monitor saying “You. Can. Not. Overcommunicate.

That’s why in a remote team, the barrier to getting in touch with a colleague needs to be as low as possible. We’ve decided to use Sqwiggle as our internal video conferencing tool. Sqwiggle displays a photo of every team member, and you simply click one to launch a video call. More remarkable is the fact that these photos are actual snapshots that get updated automatically every minute. It takes a bit of getting used to “Big Brother” but this allows us to see at a glance who’s actually at their computer and available to chat. It’s like peeking into their office – well, it is peeking into their office. But it’s more than just practical: On a subliminal level, simply being able to notice the T-shirt someone’s wearing today or smiling about a funny facial expression in one of the snapshots strengthens the sense of working within a team and not in solitary confinement.

Much more than web chat

A running text chat can be the backbone of a distributed company. We started with using IRC, then switched to Campfire, later to HipChat, and now we’re among the 200,000 users paying for Slack. Within less than two years after it was created by Flickr co-founder Steward Butterfield, Slack has gained 750,000 daily users every day, and a 2.8 billion dollar valuation. There are reasons for this impressive success.

As a first impression, Slack is easy to the eye. Other than a plain IRC client and even other web chats like HipChat, Slack is nicely designed. You can already see how much thought went into this product when you log in for the first time: Instead of presenting you with a plain input form, you’re greeted by “Slackbot” who asks you a few simple questions about your details and sets up your account. Slackbot will also notify you of important events and send you helpful hints.

In Slack, you can create as many chat channels as you like and we’ve set up quite a bunch of them to keep topics separated. Here are a few conversation channels and how we use them:

  • #company — our “virtual water cooler” where we talk about what’s going on. This is also the place to let the team know when we’re leaving our desk for a while: “Got to fetch my daughter from school, BBL!”
  • #ops — discussing IT issues: “db12 seems to have an unusual load. Does anyone know why?”
  • #backoffice — sorting out administrative stuff: “Do you think I should simply call them and ask why they haven’t yet paid their invoice?”
  • #helpcenter — consulting the team on support requests: “Here’s someone having a problem with Memcache. You’re more familiar with it, can I assign this to you?”

We also have quite a few “log channels”. And that’s where Slack’s value for us goes through the roof. What differentiates Slack from other solutions is the huge number of integrations that allow us to connect third-party services to a chat channel. With these integrations, we can make sure we get all the information we need simply by subscribing to the right channels.

For example, we make an effort to respond quickly to support requests. While our ticket system will notify us via email, checking our mailboxes every five minutes would completely destroy our productivity. Instead, everyone doing support joins #helpcenter-log. Whoever is free to take on a new request and sees one scroll by can immediately click its link and send out a first reaction. It’s that easy to impress your customers.

Our on-call engineers subscribe to the #monitoring channel where our monitoring systems post continuous updates on the health of our IT infrastructure. That way, they’re able to spot a negative trend even before an alarm is triggered.

In #sales-log, we can see new followers of our Twitter account and who subscribed to our mailing list. Our CRM system also posts updates there when a deal is created, updated, won or lost.

If an update is important enough, we even let services post directly into conversation channels. A team’s Google Calendar might post a reminder for an upcoming conference call right into the team’s channel 10 minutes in advance. New tasks added to an Asana project trigger an immediate notification in the respective project channel.

Slack enabled us to switch from “information pull” to “information subscribe”. Instead of visiting an endless number of web services to get up-to-date on our work, we simply click through a few chat channels. What information is important always depends on the person, on their current role, even on the time of day. Slack allows every member of our team to curate their individual “river of news” from a vast pool of updates. It’s easy to join a channel, and with a click you can leave it again. If there’s a new project or topic, you simply create another channel and invite others with whom you’d like to collaborate.

It’s even possible to extend Slack to people outside of the company, and we’re experimenting with creating permanent channels for key customers where they can engage with us whenever they need.

Mind you, it doesn’t have to be all about work. Slack also helps us learn more about each other as persons. For that purpose, we have a #random channel where we post things that might not be important but interesting or entertaining. Here we post links to articles we’ve just read in Pocket, location check-ins from Swarm or links to new posts on our personal blogs. It’s another way of adding a human touch to sitting alone in front of a screen all day.

A business is a community

A team is more than the sum of its parts. In particular, a team is more than a few people working on company objectives. To achieve a common goal, we need more than tools to coordinate our work. The team machine needs the grease of social interaction. In distributed organisations, social interaction must be facilitated. I can’t just by chance meet Markus on my way back from the toilet and can ask him a quick question about the new test automation infrastructure. These interactions need to be actively sought by everyone on the team and encouraged by their communication tools. It’s similar to an online community where it’s the community managers’ job to foster lively exchanges. With Slack, we find it very easy to strike up a conversation because the combination of posts by team members and the additional information from external services creates a vast pool of opportunities to get in touch. Reactions can be as small and quick as attaching an emoticon to a colleague’s post, like a “heart” or a “thumbs up”.

Tools increase efficiency. Culture grows effectiveness.

With electronic communication tools, there’s always the danger of them doing more bad than good. Information overload, notification fatigue and constant distraction come to mind quickly for everyone who’s ever used Instant Messaging and Social Networks. That’s why it’s important to create a common understanding of their intended purpose and clear expectations for how to use them early on.

We use Slack as a synchronous, real-time communication channel, just like the phone or video conferencing. The convention is that whoever has the time to respond will join the conversation. The others who miss it (intentionally or not) will be informed of any important results in due course. Especially during “Away From Keyboard” time, this prevents FOMO (“Fear Of Missing Out”). While it’s great to be able to scroll back to see what I’ve missed during lunch, I’m not expected to catch up on everything that went over the wire during my absence. Especially after having a few days off, I can rely on my colleagues to have documented everything important somewhere outside of Slack. I can start off again with “Chat Zero”.

Chat notifications help with getting a quick response – when they’re used sensibly. The latter part is important because constant electronic nagging will quickly erode any willingness to keep the chat client running during work that requires any amount of focus. That’s why we use the “@person” or the even more sweeping “@channel” mentions only in exceptional situations that require immediate feedback from a person or a whole group. Everything else we’ll either ask another time later or move to an asynchronous medium like email altogether.

While our Sqwiggle snapshots show who’s in front of their webcam at the moment, we found this indication not reliable enough to determine who’s available to talk. When I’m in a coffee shop, it may be too loud for productive conversations, or I might not even have the necessary bandwidth for a video connection, so I’ll keep Sqwiggle closed although I’m able to chat. Another time, I may want to be visible to my team in Slack but not be distracted by non-urgent messages. So we’ve agreed to switch our Slack status between “active” and “away” to indicate if we’re okay with having a conversation. That way, we avoid the frustration of asking questions into the void without getting any response.

These are only a few examples of how important it is to create a common ground when you’re using electronic communication tools. Especially for people who are new to an organisation, it helps tremendously to have an understanding not only of the “how” (using them efficiently) but also of the “why” (their purpose and the organisation’s expectations around them). That’s why we’ve written a “company runbook” that explains all the different services we use as well as how and especially why we use them.

In five years of working as a remote team, we found that when we apply powerful tools with a clear intention, they create an ROI by orders of magnitude. Slack is a great example.

geewiz

30 Oct 2015

« Older Latest Newer »