It was an exciting and busy year here at Ixis in 2014 as we continued to build our portfolio of Drupal clients.
Highlights have included celebrating our tenth birthday and building on and growing the team’s expertise which has allowed the company to win more clients across a variety of sectors. We also celebrated one of our best financial quarter since Ixis was founded in 2004.
We are delighted to be working with the British Council on a new Drupal hosting and infrastructure support project. The British Council are valued clients, and we have worked with them for more than 6 years managing both the global suite of 150 country sites, and the prestigious suite of Drupal teaching and learning sites.
We will be working to to create four individual platforms for hosting key Drupal websites on, moving away from just one main infrastructure, to improve resilience, efficiency and increase availability to the sites which generate more than 35 million page impressions per month and are used by more than 65 million people each year alone.
I'm Andy, a developer at Ixis and having just settled back in after my first DrupalCon I thought I’d wrap up my thoughts after attending the annual European conference for the first time.
Initially - wow - DrupalCon is big! I’ve only been to some smaller PHP conferences so to see over 2000 people in one place was quite something. What struck me was how well it was organised - everything was on time with very few technical hiccups. I found the number of sessions quite overwhelming - there was so much to choose from, so having the videos of the sessions online with in an hour or so after it finished was really helpful. I’m still ploughing through the ones I’m interested in.
With the 2014 European Drupal conference fast approaching, the Ixis team members attending this year have scoured the schedule for their must see see sessions this year, and why.
For the Developers
Content Staging in Drupal 8 (Wednesday 10:45) - moving content about from dev to production has always been a huge pain in Drupal, so hopefully we'll get a chance to see how this might work in Drupal 8 and finally put an end to the question of when and where the client should start adding their conent during the development phase.
We are 10 today (ok strictly tomorrow but it's the weekend!) We're all off to Centre Parcs over the bank holiday weekend to celebrate, and thought it was good time to reflect on some of the highlights and changes over the previous ten years.
Since we integrated the EdgeCast CDN for one of our clients, and released a related EdgeCast Drupal module we have been encouraging more and more clients to consider a CDN layer to accelerate performance to multiple geographic locations and maintain an excellent uptime even during site maintenance periods.
A recent international client who is running many domains with federated content using the Domain module needed to make use of the content delivery network to improve performance and resiliance for their sites.
What's the point in using an IDE, especially a paid one, for PHP development when there are so many simpler, free tools?
In November 2013 I was lucky enough to be offered the chance to present a session at DrupalCamp NW on why it's time for Drupal developers to be using a proper IDE. The session used JetBrains PhpStorm as an example, but presented the case including other popular IDEs like Eclipse and NetBeans as well.
With some seasoned and new members of the Ixis team attending Drupalcon in Prague this coming September we wanted to share our suggestions on essential sessions to attend from our teams point of view.
Matt P in our support team has been working with Drupal 6 & 7 for the past year and feels brushing up on what's coming in Drupal 8 for a site builder will be helpful as a primer when existing clients are begining to plan their site upgrades.
Shopify open sourced Dashing late last year, their Dashboard software created for displaying dashboards on TVs around their office. We decided to see have a play and see what statistics we could show on our office TVs.
Install is simple via gem, although as a non Ruby person I spent more time than I should have installing Ruby 1.9 (from source in the end). Once up the server runs on a port (3030 as standard) and applications can simply send data to the dashboard in a certain format and it is displayed immediately.
If you're trying to trouble shoot problems on a Drupal site and need to get some information out of Drupal then using the command line can get you answers quick.
Traditionally calling any of the Drupal API functions to diagnose something would require peppering your modules with temporary debug code, or writing a whole new module to call API functions and display results.