The presentation abstract tried to explain this:
A software project that is developed by more than a single person starts requiring more than just the source code. From revision control systems through to continuous integration and issue tracking, all these services need deploying and maintaining.
This presentation takes a look at what a services a project ought to have, what options exist to fulfil those requirements and a practical look at an open source projects actual implementation.I presented on Sunday morning but got a good audience and I am told I was not completely dreadful. The talk was recorded and is publicly available along with all the rest of the conference presentations.
Unfortunately due to other issues in my life right now I did not prepare well enough in advance and my slide deck was only completed on Saturday so I was rather less familiar with the material than I would have preferred.
The rest of the conference was excellent and I managed to see many of the presentations on a good variety of topics without an overwhelming attention to Debian issues. My youngest son brought himself along on both days and "helped" with front desk. He was also the only walk out in my presentation, he insists it was just because he "did not understand a single thing I was saying" but perhaps he just knew who the designated driver was.
I would like thank everyone who organised and sponsored this event for an enjoyable weekend and look forward to the next one.
Whether you’re a startup or an already-established business that wants to start selling online, Drupal has all the tools you need. It provides flexible modules for building e-commerce features and for defining workflows, data structures and lists, and displays. The Drupal Commerce framework provides you with everything required to sell products, services or files online. It integrates very well with Drupal and all its contrib modules, so you almost only need to do configuration – no programming – to build the features you need. In ERPAL Platform, we’ve built a Drupal distribution for the community to use to create flexible business applications. To be as adaptable as possible, it’s based on Drupal Commerce, CRM Core and ERPAL Core. So ERPAL Platform itself actually just supplies an appropriate collection of "best practice" modules from the Drupal community that are already preconfigured and cleverly fitted together to provide features for all kinds of business processes. The sales process is therefore already preconfigured and you can extend it as necessary to integrate seamlessly with project management features, manufacturing features or online shop features.
In the video below, we show you how you can implement ERPAL Platform to use its existing features as the administration backend of your online shop and add a storefront where your customers can buy your products, request quotations and place orders. This enables you to build a complete online business "in one Drupal box" including a backend with a lightweight CRM as well as quotations, orders and invoices to cover the entire sales process for an e-commerce business. In this example your online store will have a completely different theme compared to the administration backend. All you need to do is to download some additional modules and add some specific configurations. It’s that easy: just watch the video!
To see some real use cases about how it works in projects where ERPAL Platform is used to sell products online, you may be interested in the slides of a previous webinar, created in cooperation with the Commerce Guys, the company behind Drupal Commerce.
Motivational slides from a presentation at Drupalcamp Berlin can be found atBuilding an online business "in a Drupal box" from Manuel Pistner
On October 15th a new version of Drupal core was published (see details of this fix), so naturally everyone is wondering: How do I protect my site?How Updates Work in Drupal
Drupal is open source software managed by a community made up of all kinds of experts and hobbyists. Community members who manage security specialize in the processing and verification of all modules hosted on drupal.org and the core of Drupal itself. This super-smart team has a long history in Drupal and a vast understanding of the core code, its history and its planned future.
They are in charge of analyzing the existing application to protect it from malicious threats, regardless of their origins. When an issue is detected, they evaluate its impact and urgency in order to determine an appropriate mode of communication that meets the needs of the community. This usually means that in the event of a risk, an update is issued on one of the pre-planned bi-weekly release dates.
The security team works independently and regularly offers updates to the modules and Drupal core. Below are some ways you can follow these updates to keep your site secure and up to date.The Security Alerts
Most Drupal users have an account on drupal.org. If you don’t have one, you’re missing out and you should get one immediately. From your account, you have access to the "Newsletter" tab. On this page, you are invited to subscribe to the security newsletter and be informed of updates.Twitter
Like any self-respecting tech community, the security team is on Twitter: @drupalsecurity.RSS
Whether you developed your site or worked with an agency, once online it must be maintained. The purpose of this maintenance is not to make your site a Rolls Royce, but rather to protect it against errors, insecurities and to improve it with the new features added to Drupal core and the modules you use. It’s encouraged to update early and often.
You can choose the frequency and process for updates, but the operations to be carried out are always the same: update the core of Drupal, update themes and modules and test the full operation of your application before you push your updated project live. Prior to deployment, ensure you have a full backup of your codebase, your files directories, and your database in case anything goes wrong.How do I update my site?
Several technical means are available to you to get the latest version of core, themes and Drupal modules. Whatever method you choose, you will retrieve new files to install it on your production site. Here is a summary of what to do in general (this protocol is an example for your project, please refer to your usual procedure of deployment).
Starting with a copy of your site on a local environment:
- Get the new version of files or a patch containing updates.
- Review the changelog to see what has been changed that may affect existing functionality on your site, including any new dependencies, minor API changes, or other notes requiring manual intervention in the update process.
- Replace the files or apply the patch. At this point updates are physically available but they are not necessarily applied on your site.
- You may be asked to launch an "update" of the database, for example.
- In this case, start Drush UPDB drush command or run the update.php page on your local copy site. This operation will be applied to your site changes in its database.
- To ensure that the updates have all been taken into account, empty the cache of your site. Please note this may take some time and will affect the navigation on the site for treatment. For production sites, it is recommended to keep your current deployment procedure.
- Once this is done, test your site. Check that everything is working properly.
If you update a Drupal site between two very different versions of the core, it is possible that some functionalities could be affected. However, in an update of one direct release to another, you should not experience major functional changes. When you are confident with this procedure, following your usual process, update your site or sites.How to update Security SA-CORE-2014-005 - Drupal core - SQL injection
If your site has been well-maintained, the security update will be simple and have no effect on the functionality of your project. You can update the core of Drupal as you normally do using this new version: https://www.drupal.org/project/drupal
However, if you have not maintained the core of your application for some time (skipping several versions) and even though we do not recommend it, if you made a manual change in the core of Drupal, we recommend that you apply the patch only containing the security patch itself, here: https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch
In both cases, the changes in the new version of Drupal will have no effect on the functionality of your project, because it only affects one file related to forms.How to ensure security on my eCommerce site?
Security is a key issue for an eCommerce website and it is your duty as a merchant to maintain a safe site for your users. To ensure the security of your site, you must first perform regular Drupal core updates, security or not, or suffer the risky consequences.
Then, regularly update the modules you use. In some cases, this may affect the functionality of your site, and must be treated with kid gloves.
In any case, to make these updates, please refer to the standard procedure for updating your site that you have set up with your agency or web host, or enjoy the new technology implementation of Platform.sh to easily update your site and test with confidence.How Commerce Guys ensures the security of your projects
Subscribers of our Drupal Application Support and Commerce Application Support programs have seen first hand how we can help protect your sites. We patched our customers immediately and 100% were protected whether they hosted with us or not.
Our Platform.sh subscribers benefited from the ability to use a “Drush make” driven workflow to manage the codebase for their sites. This workflow has the advantage of managing the versions of Drupal core and contributed themes and modules on your site through a single configuration file that contains a list of elements that make up your site. Platform.sh uses this file to create and deploy your site by downloading modules and the core of Drupal, making updates fast and easy.
By creating a file Drush Make File, you can ask to recover the latest version of Drupal with the security patch automatically. You gain in maintenance time and reduce your potential for errors.
In addition to ensuring the stability of your hosting, Platform.sh blocked incoming HTTP requests for applications that had not applied the patch. Therefore, only stable sites were available on Platform.sh, and any unprotected sites were immediately aware that action must be taken.
Read more about this protective block here.
If you want to know more about the updates to Drupal, the following links to learn more:
I left Debian. I don't really have a lot to say about why, but I do want to clear one thing up right away. It's not about systemd.
As far as systemd goes, I agree with my friend John Goerzen:
I promise you – 18 years from now, it will not matter what init Debian chose in 2014. It will probably barely matter in 3 years.
And with Jonathan Corbet:
However things turn out, if it becomes clear that there is a better solution than systemd available, we will be able to move to it.
I have no problem with trying out a piece of Free Software, that might have abrasive authors, all kinds of technical warts, a debatable design, scope creep etc. None of that stopped me from giving Linux a try in 1995, and I'm glad I jumped in with both feet.
It's important to be unafraid to make a decision, try it out, and if it doesn't work, be unafraid to iterate, rethink, or throw a bad choice out. That's how progress happens. Free Software empowers us to do this.
Debian used to be a lot better at that than it is now. This seems to have less to do with the size of the project, and more to do with the project having aged, ossified, and become comfortable with increasing layers of complexity around how it makes decisions. To the point that I no longer feel I can understand the decision-making process at all ... or at least, that I'd rather be spending those scarce brain cycles on understanding something equally hard but more useful, like category theory.
It's been a long time since Debian was my main focus; I feel much more useful when I'm working in a small nimble project, making fast and loose decisions and iterating on them. Recent events brought it to a head, but this is not a new feeling. I've been less and less involved in Debian since 2007, when I dropped maintaining any packages I wasn't the upstream author of, and took a year of mostly ignoring the larger project.
Now I've made the shift from being a Debian developer to being an upstream author of stuff in Debian (and other distros). It seems best to make a clean break rather than hang around and risk being sucked back in.
My mailbox has been amazing over the past week by the way. I've heard from so many friends, and it's been very sad but also beautiful.
DebConf15 will take place in Heidelberg, Germany in August 2015. We strive to provide an intense working environment and enable good progress for Debian and for Free Software in general. We extend an invitation to everyone to join us and to support this event. As a volunteer-run non-profit conference, we depend on our sponsors.
Nine companies have already committed to sponsor DebConf15! Let's introduce them:
Google (the search engine and advertising company), Fairsight Security, Inc. (developers of real-time passive DNS solutions), Martin Alfke / Buero 2.0 (Linux & UNIX Consultant and Trainer, LPIC-2/Puppet Certified Professional) and Ubuntu (the OS supported by Canonical) are our three Silver sponsors.
Would you like to become a sponsor? Do you know of or work in a company or organization that may consider sponsorship?
Please have a look at our sponsorship brochure (also available in German), in which we outline all the details and describe the sponsor benefits. For instance, sponsors have the option to reach out to Debian contributors, derivative developers, upstream authors and other community members during a Job Fair and through postings on our job wall, and to show-case their Free Software involvement by staffing a booth on the Open Weekend. In addition, sponsors are able to distribute marketing materials in the attendee bags. And it goes without saying that we honour your sponsorship with visibility of your logo in the conference's videos, on our website, on printed materials, and banners.
The final report of DebConf14 is also available, illustrating the broad spectrum, quality, and enthusiasm of the community at work, and providing detailed information about the different outcomes that last conference brought up (talks, participants, social events, impact in the Debian project and the free software scene, and much more).
Please note that this is not meant to be systemd-bashing, just a criticism base one a counter-example refutation of Josselin's implication that there is no use case better covered by SysV init: this is false, as there is at least one. And yes, there are probably many cases better covered by systemd, I am making no claims about that.A use case better covered by SysV init: encrypted block devices
So, waiting for a use case better covered by SysV init? Rejoice, you will not die waiting, here is one: encrypted block devices. That case works just fine with SysV init, without any specific configuration, whereas systemd just sucks at it. There exist a way to make it work², but:
- if systemd requires specific configuration to handle such a case, whereas SysV init does not, that means this case is better covered by SysV init;
- that work around does not actually work.
If you know any better, I would be glad to try it. Believe me, I like the basic principles of systemd³ and I would be glad to have it working correctly on my system.Notes
- Well, it does accept comments, but marks them as span and does not show them, which is roughly equivalent. ↑
- Installing an additional piece of software, Plymouth, is supposed to make systemd work correctly with encrypted block devices. Yes, this is additional configuration, as that piece of software does not come when you install systemd, and it is not even suggested so a regular user cannot guess it. ↑
- Though I must say I hate the way it is pushed into the GNU/Linux desktop systems. ↑
The Quiz module is a sophisticated and flexible way to create quizzes in Drupal.
To get started with Quiz, you need to install and enable the 2 core Quiz modules from http://drupal.org/project/quiz:
During our weekly developers meeting I spoke about my approach to contributing to Drupal core, sharing some tips and tricks I've learnt along the way
This is a preview of a proposed session for DrupalSouth Melbourne 2015
In support of my mission to make local development easier and faster, I've released boxes for four of the most popular Linux distributions I use and see used for Drupal sites: CentOS 6/7 and Ubuntu 12.04/14.04.
My desk today looks like this:
Yep, that’s a computer. Motherboard to the right, floppy drives and CD drive stacked on top of the power supply, hard drive to the left.
And it’s an OLD computer. (I had forgotten just how loud these old power supplies are; wow.)
The point of this exercise is to read data off the floppies that I have made starting nearly 30 years ago now (wow). Many were made with DOS, some were made on a TRS-80 Color Computer II (aka CoCo 2). There are 5.25″ disks, 3.25″ disks, and all sorts of formats. Most are DOS, but the TRS-80 ones use a different physical format. Some of the data was written by Central Point Backup (from PC Tools), which squeezed more data on the disk by adding an extra sector or something, if my vague memory is working.
Reading these disks requires low-level playing with controller timing, and sometimes the original software to extract the data. It doesn’t necessarily work under Linux, and certainly doesn’t work with USB floppies or under emulation. Hence this system.
It’s a bridge. Old enough to run DOS, new enough to use an IDE drive. I can then hook up the IDE drive to a IDE-to-USB converter and copy the data off it onto my Linux system.
But this was tricky. I started the project a few years ago, but life got in the way. Getting back to it now, with the same motherboard and drive, but I just couldn’t get it to boot. I eventually began to suspect some disk geometry settings, and with some detective work from fdisk in Linux plus some research into old BIOS disk size limitations, discovered the problem was a 2GB limit. Through some educated trial and error, I programmed the BOIS with a number of cylinders that worked, set it to LBA mode, and finally my 3-year-old DOS 6.2 installation booted.
I had also forgotten how finicky things were back then. Pop a floppy from a Debian install set into the drive, type dir b:, and the system hangs. I guess there was a reason the reset button was prominent on the front of the computer back then…
It’s finally become properly autumnal, in the real world and in Debian. One week ago, I announced (on behalf of the whole release team) that Debian 8 “Jessie” had successfully frozen on time.
At 18:00 that evening we had 310 release critical bugs – that is, the number that we must reduce to 0 before the release is ready. How does that number look now?
Well, there are now 315 bugs affecting Jessie, at various stages of progression. That sounds like it’s going in the wrong direction, but considering that over a hundred new bugs were filed just 8 hours after the freeze announcement, things are actually looking pretty good.
Out of those 315 bugs, 91 have been fixed and the packages affected have already been unblocked by the release team. The fixed packages will migrate to Jessie in the next few days, if they continue to be bug-free.
Thirty-four bugs are apparently fixed in unstable but are not cleared for migration yet. That means that the release team has not spotted the fix, or nobody has told us, or the fixed package is unsuitable for some other reason (like unrelated changes in the same upload). You can help by trying to find out which reason applies, and talking to us about it. Most likely nobody has asked us to unblock it yet.
Speaking of unblocks, we currently have twenty-four requests that need to be looked at, and a further 20 which are awaiting more information from the maintainer. We already investigated and resolved 260 requests.
Our response rate is currently pretty good, but it’s unclear whether we can sustain it indefinitely. We all have day jobs, for example. One way you could help is to review the list of unchecked unblocks and gather up missing information, or look at the ones tagged moreinfo and see whether that’s still the case (maybe the maintainer replied, but forgot to remove the tag). If you’re confident, you might even try triaging some of the obvious requests and give some feedback to the maintainer, though the final decision will be made by a release team member.
After all, the quicker this goes the sooner we can release and thaw up unstable again.
Footnote: the method used to determine RC bug counts last week and this week differ, and therefore so could the margin for error. Surprisingly enough, counting bugs is not an exact science. I’m confident these numbers are close enough for broad comparison, even if they’re out by one or two.A chilly week is a post from: jwiltshire.org.uk | Flattr
Free software has been my career for a long time -- nothing else since 1999 -- and it continues to be a happy surprise each time I find a way to continue that streak.
The latest is that I'm being funded for a couple of years to work part-time on git-annex. The funding comes from the DataLad project, which was recently awarded by National Science Foundation. DataLad folks (at Dartmouth College and at Magdeburg University in Germany) are working on providing easy access to scientific data (particularly neuroimaging). So git-annex will actually be used for science!
I'm being funded for around 30 hours of work each month, to do general work on the git-annex core (not on the webapp or assistant). That includes bugfixes and some improvements that are wanted for DataLad, but are all themselves generally useful. (see issue list)
This is enough to get by on, at least in my current living situation. It would be great if I could find some funding for my other work time -- but it's also wonderful to have the flexibility to spend time on whatever other interesting projects I might want to.
After a very successful drush code-sprint at BADCamp 2014, drush make now supports YAML format!
Instead of the old INI formatapi = 2 ; Set contrib directory. defaults[projects][subdir] = "contrib" core = "7.x" projects[drupal][type] = "core" projects[drupal][version] = "7.32" ; Remove scary ajax error when autocomplete terminates: https://www.drupal.org/node/1232416#comment-8748879 projects[drupal][patch] = "https://www.drupal.org/files/issues/D7-fix_autocomplete_terminated_error-1232416-179-do-not-test.patch" ; Ensure plain text fields evaluate line breaks. projects[drupal][patch] = "http://drupal.org/files/text-plain-1152216-24.patch" projects[addressfield][version] = "1.0-beta5" projects[addressfield_tokens][version] = "1.4" projects[admin_views][version] = "1.3" projects[field_collection][version] = "1.0-beta7" ; Field collections are ownerless https://drupal.org/node/1954124 projects[field_collection][patch] = "https://drupal.org/files/issues/field_collection-ownerless_fields-1954124-23.patch" ; Fixes fatal error in migrate code: https://www.drupal.org/node/2315921#comment-9028779 projects[field_collection][patch] = "https://www.drupal.org/files/issues/migrate-fatal-error-2315921-01.patch"
YAML can be used with the latest version of Drush 7:api: 2 # Set contrib directory. defaults: projects: subdir: "contrib" core: "7.x" projects: drupal: type: "core" version: "7.33" patch: # Remove scary ajax error when autocomplete terminates: https://www.drupal.org/node/1232416#comment-8748879 - "https://www.drupal.org/files/issues/D7-fix_autocomplete_terminated_error-1232416-179-do-not-test.patch" # Ensure plain text fields evaluate line breaks. - "http://drupal.org/files/text-plain-1152216-24.patch" addressfield: "1.0-beta5" addressfield_tokens: "1.4" admin_views: "1.3" field_collection: version: "1.0-beta7" patch: # Field collections are ownerless https://drupal.org/node/1954124 - "https://drupal.org/files/issues/field_collection-ownerless_fields-1954124-23.patch" # Fixes fatal error in migrate code: https://www.drupal.org/node/2315921#comment-9028779 - "https://www.drupal.org/files/issues/migrate-fatal-error-2315921-01.patch"
Included .make files whether local, or discovered recursively within downloaded projects, can be in either YAML of INI format.
In order to use the newly-supported YAML format, simply name files with a .yml extension, such as my_project.make.yml.
The best part? This can be used now! Even though YAML files are mostly a new concept for Drupal 8, drush make will parse YAML make files for Drupal 7, and even Drupal 6. Want to learn more about DRUSH make files? Check out Joe Turgeon’s “Getting Started With Grunt Drupal Tasks“
In the spirit of the computer video game Doom and its skill levels, we’ll review a few ways you can improve your Drupal speed performance and optimize for better results and server response time. These tips that we’ll cover may be at times specific to Drupal 6 versions, although you can always learn the best practices from these examples and apply them on your own code base.
Doom skill levels: (easiest first)
1. I’m too young to die
2. Hey, not too rough
3. Hurt me plenty
This post is rated “I’m too young too die” difficulty level.
If you’re using a Drupal distribution which is great for kick-starting a project with many features built-in, you should still review added modules which are managed through the installation profile as they might prove un-necessary for your product as time goes and your product evolves and matures. Remember that even if you’re not using a distribution, you might have added some modules to meet a functionality, which you no longer use and you disabled through CSS, through the menus, through the theme, but you forgot all about removing the actual module. These un-used modules account for memory footprint as they are loaded through PHP and they can also account for Drupal hooks, which is even worse in terms of performance for you.
Remember to review your installed modules base on Drupal and remove any un-used functionality:
One of the best ways to learn useful tricks at the command line is to sit with someone and watch what they do. Due to the distributed nature of the Drupal community, we don't do nearly enough pair programming. Too often we work in isolation and then push our work on others when we finish. In this article I invite you to sit down beside me and watch over my shoulder as I explore Drupal 8 from the command line.Navigating Drupal in the Bash Shell
The instructions in this article will work for OSX, and Linux systems, such as Ubuntu, but not Windows.
When reading command line instructions, there are two important characters we need to know about: $ and #. When applied to the beginning of a line, these refer to the prompt. We don't type these characters when issuing our command. $ signifies the command should be run as a regular user; # signifies the command is run as the administrative user (“root”).
As a themer, the first thing I want to explore is, of course, the themes. Let's begin by navigating to our Drupal folder. I start by opening up a terminal application. At the command line, I type cd, and then, using Finder, locate my Drupal folder. I then drag this folder onto the terminal application. It will automatically paste the path to the Drupal folder into my bash prompt. I press return, and bingo – we have navigated to the Drupal folder!
Let's take a peek inside the core folder of themes: we’ll navigate to the folder core/themes and then list (or ls) all files.$ cd core/themes $ ls
There should be four things listed. See them all?
I've had a couple of questions related to Association finances lately in various communications channels. I know that most of you are not finance professionals for a living, so rather than answering in several different silos, I thought I might write up this post about how the Association financials are structured and how you can read them. You know, for when you need a break from your other Drupal work! So if you're into this sort of thing (and I am not judging here, because I am WAY INTO this sort of thing), read on!What are financial statements?
A financial statement is a formal record of the financial activities of the Drupal Association. The financial statements present information in a structured way that should make it easy to understand what is happening with the organization's finances. In other words, financial statements should tell a story about what is happening with the Association's money. Generally, financial statements include three standard reports:
- Income Statement (or Profit & Loss): This report shows the revenue that is recognized as received and spent during a given period. It is tempting to compare the income statement to your checkbook register, but it's not quite that simple. The catch is that the income statement shows RECOGNIZED income and expense. One of the US accounting rules, for example, is that we can not recognize revenue for a DrupalCon ticket until the month in which the event happens. So, if you buy your DrupalCon Barcelona ticket in June, and the event is in September, your ticket revenue will not show up until our September income statement. Until then, that revenue sits on our Balance Sheet. So, the income statement alone does not give you a full picture of the organiztion's financial position. It simply represents the movement of recognized revenue in a specific time period. The income statement also represents some non-cash changes, such as depreciation.
- Balance Sheet: The balance sheet shows us the assets and liabilities for the organization for that given time period. Reading the balance sheet, you can get a better understanding of how much money is in the bank, and where we owe, or might possibly owe, money. These things are not reflected in the income statement. Going back to our DrupalCon Barcelona example, prior to the Con, any revenue from sponsorship, ticket sales, or training sales would be held on the balance sheet in two ways. First, it will simply be reflected as cash in our bank account. Secondly, it is reflected as a liability, broken out specifically as sponsorship or ticket revenue. It's a liability because if we cancel the Con, we have to give you your money back! When preparing the September financials, we move the ticket revenue from the balance sheet liabilities session to the Income Statement, where it is treated as recognized revenue.
- Cash Summary: The cash summary (or cash flow) is the report that simply shows the movement of money into and out of our accounts. It does not account for depreciation or other non-cash accounting.
Those three reports are the standard set that organizations issue when reporting their financials. The Association, however, issues additional reports to add clarity and transparency around the programs that you care most about.About the Drupal Association Financial Statements
The Drupal Association financials are created on a monthly basis, and then are reviewed by the Finance Comittee of the board. On a quarterly basis, the Finance Committee presents the financials to the Board in executive session, which, if there are no serious questions, approves the financials. At that point, we publish the three months of financials to the community. They are promoted in a blog post about the meeting, and are also always available on the board materials page on the Association site.
As I mentioned above, the Association financial statements go above and beyond the standard reports. In addition to the main three, our monthly financials also include the following:
- "PL All Classes:" This is an income statement report, showing recognized revenue and expenses for the month, but it is broken out by program area. This gives you the opportunity to see, for that month, the recognized revenue and expense for the upcoming Cons, or Drupal.org, or our Drupal Product Marketing efforts, for example. This report is for the month only, so keep that in mind. If you are looking at the May financial statements, the numbers in this report are for May only.
- "Revenue:" This report was designed to show how our various revenue lines are performing. One of our board mandates is to diversify revenue so that DrupalCons are not our primary source of income. Taking this pressure off the Cons to perform financially will allow us to make different kinds of choices for the Cons, and it provides us more stability as an organization. This report helps us monitor progress for those revenue lines.
- "PL DC ConName:" We create one of these report for each of the Cons we are working on. They are income statements for those Cons, year to date (YTD). YTD means that the report reflects all income and expense for that year, not just the current month. In these reports, you can see detailed information about expenses, with revenue generally not recognized on the report until the month of the Con.
And, keep in mind that all Association financial statements are reported in US Dollars.How to Read the Financial Statements
A goal of financial statements is that they are supposed to make financial information easier to understand. However, the truth is that it is difficult for mere mortals to read financial statements. It takes both training and practice. However, let's see if I can walk you through some details. I'll use the March 2014 financial statements in this example.Income Statement
The Income Statement presents the income and expenses for both the month of the report (in this case, March) as well as the year to date, or YTD, amounts (in this case, 1 January through 31 March 2014). So the top of the report looks like this:
Here's what what the columns represent:
- Actual: Amounts for the month the financials report represents. In this case, March 2014.
- Budget: The budgeted amount for the month the financial report represents. In this case, the amount we budgeted for March 2014.
- YTD Actual: Total amount for the year, through the month the financial report represents. In this case, 1 January through 31 March 2014.
- YTD Budget: Total budgeted amount for the year, through the month the financial report represents. In this case, the amount we budgeted for 1 January through 31 March 2014.
- Var %: The percent difference between the YTD Actual and YTD Budget. This gives you a sense of how good a job we did at budgeting. Variance can occur because we receieved or spent money faster than we anticipated, or our models were off entirely. Remember that the Association only began budgeting and reporting in these formats 18 months ago, so we're still learning about what our cycles of revenue and expense are, so we expect the variance to decrease overall throughout the next few years as we get better at this.
The Balance Sheet presents the assets and liabilities as of the month of the report, which is March 2014 in this example. The balance sheet almost always also shows a comparative period - the same period the year prior, which is March 2013 for this example. This gives you the opportunity to see how things have changed in the last year. The report looks like this:Cash Summary
The Cash Summary report shows the flow of money into and out of the organization in the given period. For compartive purposes, it also includes a Year to Date (YTD) column that shows all cash movement for the year, which is 1 January through 31 March in this example. The Cash Summary looks like this:What our Financial Statements do not show
Simply put, our financial statements do not show a lot of information. The point of statements is to take complex and copious amounts of data and distill it into something digestable. We do not, for example, show each of the tickets sold for a DrupalCon and who they were sold to. We don't show each invoice that was received for Association software as a service subscriptions. We have the data, and I'm not oppposed to sharing it (as long as I check that we are not violating any privacy or other laws - you never know). However, it does not make sense for us to publish this level of detail on a monthly basis.
That said, if there is something our financial statements do not show you, you can always ask. If it's not published here, it's not because we don't want to share the information. It's because we want to share information that can be meaningfully understood.Summary
That should help you get through some of our financial statements a little better. I am not an accountant, but I am always happy to field any questions you have about these documents, and our amazing Operation Team of Kris and Leslie love to help. Just drop me a line via email or go ahead and post in a public channel like Twitter or a forum. Give me a heads up and I will get back to you.
Flickr photo: Doug88888
I was recently working on a Drupal project that had some internal DNS managed via hosts file. Tell me about it. Having no publicly accessible DNS or IP creates a challenge when your SaaS based Jenkins runs the tests.
The solution for this is a little custom work in your FeatureContext constructor and a BeforeScenario method.
And a little glue in the behat.yml to pass the custom hostHeader variable to the FeatureContext. Make sure that you're also setting the IP of the server for base_url and you're all set.
You can use this same pattern to pass around other variables from behat.yml to your FeatureContext.Tags: