Colm O hEigeartaigh: LDAP support in Apache Camel

Planet Apache - Wed, 2015-01-28 11:29
Apache Camel allows you to add LDAP queries to your Camel routes via the camel-ldap and camel-spring-ldap components. The camel-ldap component allows you to perform an LDAP query using a filter as the message payload. The spring-ldap component is a wrapper for Spring LDAP, and is a bit more advanced than the camel-ldap component, in that it also supports the "bind" and "unbind" operations, in addition to "search".

I've created two test-cases that show how to use each of these components. Both test-cases use the Camel file component to read in files that contain LDAP queries. These queries are then dispatched to an Apache DS server that is configured via annotations in the test code, using an LDIF file containing some test data. The results are then processed and written out in the target directory. The test-cases are available here.
Categories: FLOSS Project Planets

Andre Roberge: Scratching an itch: improving pydoc

Planet Python - Wed, 2015-01-28 11:20
Pydoc is great - no make that fantastic.  However, I was never fond of the look of help pages displayed when pydoc is used in webserver mode.    Pydoc uses hard-coded styling options (including font and colors) based on deprecated html 4 syntax.

I decided to see if I could make it more customizable and, after a half-day coding sprint, I offer you mod_pydoc, which is somewhat more easily customizable using css.  The new version has a simplified styling as default.

mod_pydoc is only available from github (for now); I'm hoping that people with better designing skills will contribute some code to make the output look better than my feeble attempt.  Eventually, my intention would be to file a feature request to python.org and submit it as a possible improvement on the current module.
Categories: FLOSS Project Planets

CivicActions: Dockerizing Drupal for Project Development and Testing

Planet Drupal - Wed, 2015-01-28 11:05

Docker has quickly become the favorite virtualization tool for many people including myself. A few months ago we were discussing various technical goals across our project and things started to come together pointing to a basic docker framework to facilitate our development processes. This basically sums up our wish list:

Our Goals
  • Faster developer sandbox set up to get started on projects sooner.
  • Consistent software stack across developers, testing infrastructure, and production.
  • Ideally, a basic tool set that would work for both our new projects as well as our maintenance sites.
  • Start using the cool new trendy docker.
Container configuration with fig

One challenge is to have portable configuration for the building, starting, and stopping of a project's containers. The fig project provides an elegant solution and the configuration is in YAML files, which we in the Drupal community should be getting used to now with Drupal 8. The fig.yml defines your containers, ports, mount point, and how they link together. Maintaining a fig.yml file in our project repositories allows us to do things like add an Apache Solr container with ease.

I was working on a collection of bash scripts and docker files and a fig.yml for one project and at some point it became stable enough to extract for general use. I brought these files together and made them available on github.

Introducing Bowline

Following the nautical and shipping metaphor, I chose the name bowline because it's a simple and basic knot with multiple uses. The idea is that Bowline ties it all together. Plus it reminds me of my sailing days when I could tie a bowline in less than 3 seconds, which is slightly faster than it takes to start the docker containers.

Code and instructions found at the git repo: https://github.com/davenuman/bowline

I have now had success with Bowline on both new project and on existing Drupal 6 and 7 projects. Just last week I also tried it out with Drupal 8 and I'm happy to report that it works just fine on Bowline as well.

Dockerfile flexibility

Out of the box, Bowline ships with two containers. One for mysql 5.5 which is simply the default image from Docker Hub. The second is the web container providing apache, php 5.4, and related software. The web container is defined within the .docker/web-5.4 directory and the Dockerfile with supporting config files are based on the awesome work of the new Drupal testbot project.

Automation, running tests

Imagine your developers getting their local sandboxes up and running in a matter of minutes. This is now possible, facilitated by a few simple bash scripts. Bowline provides a template document intended for instructing your team on how to get set up: https://github.com/davenuman/bowline/blob/master/sandbox.md

Basically, they run build sync-db to get a copy of the database, build sync-files to get the site's uploaded files, then build import which does all the work of building the docker containers and importing the database. There is also a backup script which will save a snapshot of your database named after your current git branch which is handy for switching to another task while preserving your work. The run command is intended for running your automated tests. It assumes behat but you can modify it to run whatever testing software you use. The nice thing is that our developers are all running local behat tests on the exact same software stack as each other and as the test server. We have a Jenkins server with docker and have jobs configured to execute the build and run commands just like we do on our own machines.

Slaying File Permission Dragons Anyone who has worked with a LAMP stack has bumped into file permission issues with uploaded files. Add a docker container to the mix which is mounting your project files and serving them up as the apache user withing the container and there is lots of ways to mess things up. This dragon gave us some grief early on when starting to use docker in this way. We won the day by setting the apapache user to run with the same uid as the docker host user. This way each developer will have ownership to their own file uploads on their system. Here's the simple bash code that makes it possible: # Set the apache user and group to match the host user. OWNER=$(stat -c '%u' /var/www) GROUP=$(stat -c '%g' /var/www) usermod -o -u $OWNER www-data groupmod -o -g $GROUP www-data (source) Room for improvement

One tricky thing we found using docker containers is using drush in a complete way, particularly using drush site aliases. For now we have "crush" which is a temporary work around but not too bad of a work around actually. Crush is a simple bash function that calls drush as a command on the docker web container. We use crush to clear cache manage features and such, and it is working well. However it's not ideal and I'd like to add ssh server to the stack to allow for proper drush site alias usage.

There's always room for improvement. I'd like to find an elegant way to incorporate more developer tools such as sass, compass and debugging tools. Every project is different but it would be nice for Bowline to have some basic Behat smoke tests build in. These things will hopefully be added to the Bowline project as we use it and add things to our drupal project. And yes, pull requests are welcome.

Categories: FLOSS Project Planets

Amazee Labs: Amazee Labs launches first customer website on Drupal 8

Planet Drupal - Wed, 2015-01-28 10:41
Amazee Labs launches first customer website on Drupal 8

We just completed our third Drupal 8 project: SGG - Schweizer Gemeinnützige Gesellschaft after relaunching our own website, helping out with Drupal.com we are now excited to launch our first client website fully on the upcoming major release of our favorite open source CMS.

Having built the community site Intergeneration and voting platform CHymne using Drupal 7, we now chose Drupal 8 for the relaunch of the presentation website of SGG. The compact feature of the site allowed us to apply today's strenghts Drupal 8 and so we recreated the associations website relying entirely on Drupal 8 core functionality.

Building the SGG relaunch was a team effort, read on to find about the findings of each of us for building the relaunch on the latest beta release of Drupal 8.

Boris was involved with site building, these are his thoughts:

Drupal 8 in terms of sitebuilding is awesome. After a short time you are able to build almost everything out of the box. Sometimes you have to think around the corner to get your result. And sometimes you get stuck because of some nasty bugs.

But with a great Backend-Developer on Hand (Alex) we could also solve some issues during creation of our project.

  • Building content types is much more powerful with Drupal 8 core: you can define view modes, form modes and many field types like e-mail, entity reference etc have been integrated
  • Full translation capabilities: thanks to #d8mi no dozen of i18n modules are required but Drupal 8 core ships with configuration, content & interface translation
  • WYSIWYG editing functionality is part of core and just works
  • Views in Core: we can create dynamic listings  
  • Enhanced block system: we can even reference blocks using entity reference now

Alex did backend development for the SGG relaunch, his feedback on the project:

  1. A lot of things in D8 are plugins and the new plugin system is really cool: to extend a plugin, all you need is to extend its class and place your new class in the proper namespace.
  2. Even if core still uses some PHP magic, everything is documented well with PHPDoc, and the IDEs help a lot to write code.
  3. Tip: while Drupal 8 is in the beta stage, use core dev releases only for core development. I tried dev releases two times, in both cases a lot of functionality was broken. If you need D8 in production: use beta releases, they are much more stable.
  4. Every piece of PHP code is covered with tests. That's super cool: if you want to understand how the thing works or what its purpose: read its tests, you will learn a lot from there.
  5. Sad: there is no core stuff for testing JavaScript code. There are some contrib modules for that, but, anyway, it's not in the core, so JavaScript tests are not mandatory.
  6. Sad: beta-to-beta updates are not ready. That makes core updates really hard. The good thing is that it's the target number one.
  7. The translation system is really good. All translation cases are handled right in the core.

Overall, I have really really good feeling about D8. Previously we said "Drupal way" about many coding stuff. Now it's the "right way"! Drupal core now uses bleeding edge technologies, and that makes work really interesting.

Kathryn did front-end development, this is what she would like to share:

Building a custom theme for Drupal 8 is almost an entirely different process than building one for Drupal 7. I think this is especially true for Amazee Labs since historically, we are "Panels people." Because the Panels module isn’t ready for Drupal 8, we're forced to make heavy use of template files. 

In my experience with Drupal 8 (and on this project in particular), working with Twig templates is much more concise and straightforward to code than a D7 .tpl file. As a developer with only basic PHP skills, the Twig syntax is easier to grasp. 

For the SGG theme, there are over ten custom Twig templates, most of which extend upon another.

Even though the design of the SGG theme appears simple, there were many instances where the content display required use of the Twig {{ dump() }} function to drill into variables. 

One thing I found frustrating during this process was sifting through the output of the dump’s results. Krumo formatting in D7 is so nice and tidy, while the D8 output is a jumbled mess, even after wrapping it in a <pre> tag. 

To work around this, Kint is your new best friend. You’ll need to download the 8.x version of the Devel module, enable it, along with Devel Kint. Include {{ kint() }} in your template file and voilà - nested arrays that won’t make your head spin around. 

I could go on, but the gist of it is: mastering Twig continues to be my number one priority for Drupal 8. The SGG Drupal 8 project was no exception.

And this is the result: http://sgg-ssup.ch

Creating web sites with Drupal 8 is possible today. You certainly have to be aware of constraints regarding not-yet-upgraded modules and account for some core bugs along the way. On the other hand, working with Drupal 8 just feels right: best practices from back-end to front-end development have been incorporated and the site building experience is really solid.

Step by step we will approach bigger client projects with Drupal 8. Interested in a future proof website? - let's start a project together.

Categories: FLOSS Project Planets

Dirk Eddelbuettel: RInside 0.2.12

Planet Debian - Wed, 2015-01-28 09:24

A new release 0.2.12 of RInside is now on CRAN. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by the Rcpp integration package.

This release adds new examples which were contributed by Christian Authmann, plus some updates and fixes including one requested by the CRAN maintainers regarding GNU extensions to Makefile. The NEWS extract below has more details.

Changes in RInside version 0.2.12 (2015-01-27)
  • Several new examples have been added (with most of the work done by Christian Authmann):

    • standard/rinside_sample15.cpp shows how to create a lattice plot (following a StackOverflow question)

    • standard/rinside_sample16.cpp shows object wrapping, and exposing of C++ functions

    • standard/rinside_sample17.cpp does the same via C++11

    • sandboxed_servers/ adds an entire framework of client/server communication outside the main process (but using a subset of supported types)

  • standard/rinside_module_sample9.cpp was repaired following a fix to InternalFunction in Rcpp

  • For the seven example directories which contain a Makefile, the Makefile was renamed GNUmakefile to please R CMD check as well as the CRAN Maintainers.

CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Mike Driscoll: Machine vision with Python Kickstarter

Planet Python - Wed, 2015-01-28 09:05

Yesterday I posted about PyImageSearch Gurus computer vision Kickstarter and then I came across another semi-related Kickstarter. This one is for Machine vision with Python using an OpenMV Cam. It uses MicroPython (Python for microcontrollers) to control a camera on a circuit board. This project can be used with an Arduino, mbed or other microcontroller over I2C, Serial, or SPI protocols. I believe the Raspberry Pi falls into one or more of the latter categories.

They haven’t reached their goal yet, but they have almost a month left to raise the funds. You can check our their project here.

Categories: FLOSS Project Planets

Annertech: Check out my website - it's responsive! Yawn!

Planet Drupal - Wed, 2015-01-28 09:00
Check out my website - it's responsive! Yawn! //--> "OMG! You've got a responsive website!"

Once something to brag about, this is now old news.

Categories: FLOSS Project Planets

Ortwin Glück: [Code] Recent Gentoo is safe from GHOST

Planet Apache - Wed, 2015-01-28 08:09
I ain't afraid of no GHOST.

According to Heise the GHOST vulnerability only affects glibc before 2.18. Uptodate Gentoo installations run 2.19 and are not affected.
# equery l glibc * Searching for glibc ... [IP-] [ ] sys-libs/glibc-2.19-r1:2.2
Categories: FLOSS Project Planets

End Point: Getting realtime output using Python Subprocess

Planet Python - Wed, 2015-01-28 04:38
The Problem When I launch a long running unix process within a python script, it waits until the process is finished, and only then do I get the complete output of my program. This is annoying if I'm running a process that takes a while to finish. And I want to capture the output and display it in the nice manner with clear formatting.
Using the subprocess and shlex library Python has a “batteries included” philosophy. I have used 2 standard libraries to solve this problem.
import subprocess import shlex
  • subprocess - Works with additional processes
  • shelx - Lexical analysis of shell-style syntaxes
subprocess.popen To run a process and read all of its output, set the stdout value to PIPE and call communicate().
import subprocess process = subprocess.Popen(['echo', '"Hello stdout"'], stdout=subprocess.PIPE) stdout = process.communicate()[0] print 'STDOUT:{}'.format(stdout) The above script will wait for the process to complete and then it will display the output. So now we are going to read the stdout line by line and display it in the console untill it completes the process.
output = process.stdout.readline() This will read a line from the stdout.
process.poll() The poll() method will return
  • the exit code if the process is completed.
  • None if the process is still running.
while True: output = process.stdout.readline() if output == '' and process.poll() is not None: break if output: self.logger.info(output.strip()) rc = process.poll() The above will loop and keep on reading the stdout and check for the return code and displays the output in real time.
I had one more problem in parsing the shell commands to pass it to popen when I set the shell=False. Below is an example command:
rsync -avzXH --delete --exclude=*.swp --exclude=**/drivers.ini /media/lgisos/lg.iso root@42-a:/isodevice To split the string using shell-like syntax I have used shlex library's split method.
Here is the final code looks like def run_command(command): process = subprocess.Popen(shlex.split(command), stdout=subprocess.PIPE) while True: output = process.stdout.readline() if output == '' and process.poll() is not None: break if output: self.logger.info(output.strip()) rc = process.poll() return rc
Categories: FLOSS Project Planets

Russell Coker: SE Linux Play Machine Over Tor

Planet Debian - Wed, 2015-01-28 02:44

I work on SE Linux to improve security for all computer users. I think that my work has gone reasonably well in that regard in terms of directly improving security of computers and helping developers find and fix certain types of security flaws in apps. But a large part of the security problems we have at the moment are related to subversion of Internet infrastructure. The Tor project is a significant step towards addressing such problems. So to achieve my goals in improving computer security I have to support the Tor project. So I decided to put my latest SE Linux Play Machine online as a Tor hidden service. There is no real need for it to be hidden (for the record it’s in my bedroom), but it’s a learning experience for me and for everyone who logs in.

A Play Machine is what I call a system with root as the guest account with only SE Linux to restrict access.

Running a Hidden Service

A Hidden Service in TOR is just a cryptographically protected address that forwards to a regular TCP port. It’s not difficult to setup and the Tor project has good documentation [1]. For Debian the file to edit is /etc/tor/torrc.

I added the following 3 lines to my torrc to create a hidden service for SSH. I forwarded port 80 for test purposes because web browsers are easier to configure for SOCKS proxying than ssh.

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 22
HiddenServicePort 80

Generally when setting up a hidden service you want to avoid using an IP address that gives anything away. So it’s a good idea to run a hidden service on a virtual machine that is well isolated from any public network. My Play machine is hidden in that manner not for secrecy but to prevent it being used for attacking other systems.

SSH over Tor

Howtoforge has a good article on setting up SSH with Tor [2]. That has everything you need for setting up Tor for a regular ssh connection, but the tor-resolve program only works for connecting to services on the public Internet. By design the .onion addresses used by Hidden Services have no mapping to anything that reswemble IP addresses and tor-resolve breaks it. I believe that the fact that tor-resolve breaks thins in this situation is a bug, I have filed Debian bug report #776454 requesting that tor-resolve allow such things to just work [3].

Host *.onion
ProxyCommand connect -5 -S localhost:9050 %h %p

I use the above ssh configuration (which can go in ~/.ssh/config or /etc/ssh/ssh_config) to tell the ssh client how to deal with .onion addresses. I also had to install the connect-proxy package which provides the connect program.

ssh root@zp7zwyd5t3aju57m.onion
The authenticity of host ‘zp7zwyd5t3aju57m.onion ()
ECDSA key fingerprint is 3c:17:2f:7b:e2:f6:c0:c2:66:f5:c9:ab:4e:02:45:74.
Are you sure you want to continue connecting (yes/no)?

I now get the above message when I connect, the ssh developers have dealt with connecting via a proxy that doesn’t have an IP address.

Also see the general information page about my Play Machine, that information page has the root password [4].

Related posts:

  1. Trust and My SE Linux Play Machine When discussing the machine there are two common comments I...
  2. New SE Linux Play Machine Online After over a year I have finally got a SE...
  3. Play Machine Online Again I have returned from the US and my SE Linux...
Categories: FLOSS Project Planets

Zato Blog: Zato 2.0 released - ESB, SOA, REST, APIs and Cloud Integrations in Python

Planet Python - Wed, 2015-01-28 00:01

The new version of Zato - the open-source middleware platform and backend application server - has just been released.


Release 2.0 brings dozens of interesting features building on and greatly enriching already existing capabilities.

Major features include:

The changelog lists all the updates that are in addition to what Zato has had since the initial release: clustering, scheduling, hot-deployment, GUI, CLI, statistics, Plain HTTP, SOAP, AMQP, FTP(S), JMS WebSphere MQ, ZeroMQ and more.

Check out the no-nonsense introduction to ESB/SOA for an introduction to the philosophy behind the project and just have a look at the following sample screenshots depicting but a small part of the platform in action:

Categories: FLOSS Project Planets

Doug Hellmann: virtualenvwrapper.django 0.4.1

Planet Python - Wed, 2015-01-28 00:00
virtualenvwrapper.django 0.4.1 What is virtualenvwrapper.django?

virtualenvwrapper.django is a template plugin for virtualenvwrapper to create new Django projects automatically. When used with mkproject, it installs Django into the new virtualenv then runs django-admin.py to create a new project skeleton.

What’s New?

This release replaces the use of distribute with setuptools (contributed by Sascha Peilicke).

Categories: FLOSS Project Planets

Vasudev Ram: HTML text to PDF with Beautiful Soup and xtopdf

Planet Python - Tue, 2015-01-27 22:18
By Vasudev Ram

Recently, I thought of getting the text from HTML documents and putting that text to PDF. So I did it :)

Here's how:
A demo program to show how to convert the text extracted from HTML
content, to PDF. It uses the Beautiful Soup library, v4, to
parse the HTML, and the xtopdf library to generate the PDF output.
Beautiful Soup is at: http://www.crummy.com/software/BeautifulSoup/
xtopdf is at: https://bitbucket.org/vasudevram/xtopdf
Guide to using and installing xtopdf: http://jugad2.blogspot.in/2012/07/guide-to-installing-and-using-xtopdf.html
Author: Vasudev Ram - http://www.dancingbison.com
Copyright 2015 Vasudev Ram

import sys
from bs4 import BeautifulSoup
from PDFWriter import PDFWriter

def usage():
sys.stderr.write("Usage: python " + sys.argv[0] + " html_file pdf_file\n")
sys.stderr.write("which will extract only the text from html_file and\n")
sys.stderr.write("write it to pdf_file\n")

def main():

# Create some HTML for testing conversion of its text to PDF.
html_doc = """
Test file for HTMLTextToPDF
This is text within the body element but outside any paragraph.
This is a paragraph of text. Hey there, how do you do?
The quick red fox jumped over the slow blue cow.
This is another paragraph of text.
Don't mind what it contains.
What is mind? Not matter.
What is matter? Never mind.
This is also text within the body element but not within any paragraph.

pw = PDFWriter("HTMLTextTo.pdf")
pw.setFont("Courier", 10)
pw.setHeader("Conversion of HTML text to PDF")
pw.setFooter("Generated by xtopdf: http://slid.es/vasudevram/xtopdf")

# Use method chaining this time.
for line in BeautifulSoup(html_doc).get_text().split("\n"):

if __name__ == '__main__':

The program uses the Beautiful Soup library for parsing and extracting information from HTML, and xtopdf, my Python library for PDF generation.
Run it with:
python HTMLTextToPDF.py
and the output will be in the file HTMLTextTo.pdf.
Screenshot below:

- Vasudev Ram - Python training and programming - Dancing Bison Enterprises

Read more of my posts about Python or read posts about xtopdf (latter is subset of former)
Signup to hear about my new software products or services.

Contact Page
Share | Vasudev Ram
Categories: FLOSS Project Planets

KDE: SoK Project Final Update

Planet KDE - Tue, 2015-01-27 19:17

KDE Jenkins DSL Job

This will be the last post on this subject with the SoK tag, as the program comes to a close this week. I will however be contining
my efforts past the program dates. With that said..
I have been busy! The last couple weeks I have worked out the job DSL from scratch in Java/Groovy for the job-dsl-plugin.
This of course entailed, dusting off the bits of programming I took in university and learning much more.
My DSL takes a json config file and reads the variables in and proceeds to generate a full fledged job in Jenkins. This
makes job creation much simpler!
Due to the complexity of the task, and the extra effort put in to getting windows and OSX builds to
actually build (beyond the scope of the task) Ben has been nice enough to extend my project beyond the initial sok dates.
I plan on continuing my work with this for as long as necessary, and will maintain it if they allow.
As a student, this opportunity has been invaluable and I encourage anyone in the future that wants that extra experience to
refine your skills to participate in KDE’s Season of KDE! You do not have to be a full time student to apply, I graduated years ago.
My new skillset includes:
Building Qt5 + apps on 3 platforms (Linux, Windows, OSX)
KDE infrastructure

To say the least it has been a wild ride!

Categories: FLOSS Project Planets

ThinkShout: Reimagined Sprints and Introducing RedHen Raiser

Planet Drupal - Tue, 2015-01-27 19:00

We’ve been experimenting with monthly team sprints at ThinkShout over the last year with varied levels of structure and outcomes. This month, we decided to take a step back, reevaluate our goals, and reimagine our sprint process. And, we moved it to a Thursday. A bow-tie Thursday.

Previously, these sprints were loosely structured around a topic or technology, such as Twig in Drupal 8. Suffice it to say, they were a lot of fun and very exploratory, but they weren’t the most engaging for everyone on the team. This time around, we decided to collaborate on a single initiative - in this instance, a product - that would benefit from the skills and perspectives of everyone in the company. Consequently, we decided to rally around RedHen Raiser, our new peer-to-peer fundraising distribution for Drupal.

Introducing RedHen Raiser

RedHen Raiser is designed for building peer-to-peer fundraising websites, like the sites you see for marathons and walks, where a fundraising campaign is made up of myriad individual and team pages, and can be customized by the participants for fundraising amongst their respective communities, while remaining connected to the larger campaign.

As the name suggests, RedHen Raiser is built on top of RedHen CRM, including the RedHen Donation and RedHen Campaign modules, and it’s chock full of awesome:

  • Easy Campaign creation so site visitors can join right away by creating their own Team or Individual fundraisers.

  • A beautiful, consistent fundraising experience that is based on inherited display values from the larger Campaign.

  • Goal progress widgets including thermometers, leaderboards, etc.

  • Mini-blogs for Campaigns and Fundraisers via Update content type.

  • Ability to create and maintain different pages for different fundraisers with a single account.

  • Automated start and end dates.

  • Commerce-readiness - just add your payment method and go!

  • Single-page donation forms via RedHen Donation.

  • Built using established modules with simple UI (Views, RedHen, Context, etc) for easy customization.

It’s ThinkShout’s latest offering in a suite of nonprofit engagement building blocks that we’ve been developing, and was initially developed for the Capital Area Food Bank of Washington, DC. RedHen Raiser competes feature for feature with top software as a service (SaaS) peer-to-peer fundraising platforms, such as TeamRaiser, CauseVox and Razoo.

As a result of our work with this client, we were able to release a very rudimentary version of RedHen Raiser on Drupal.org that would provide a basic starting point to other developers interested in building a peer-to-peer fundraising tool. The product is also a huge win for CAFB of DC, simply because they were able to reap a huge dividend on their initial investment by getting these improvements for free.

Involving the Full Team in One Sprint

As an open source product, RedHen Raiser presented us with some interesting opportunities to engage more than just our engineers in the sprint process, and it certainly needed a lot of love on a lot of fronts. Leveraging the different interests and expertise of our 18-person company, we split into five teams:

  • Dev Ops - this team focused on deployment infrastructure, build processes, and automated testing;

  • Bug Fix & Feature Dev - team members spent the sprint day working on the development backlog;

  • UX - the User Experience team worked ahead of the feature development team to identify and sketch out new features and enhancements;

  • QA - the Quality Assurance team was made up of our project managers acting as "product owners;"

  • Community Engagement - this team, consisting of our sales, marketing, and operations staff, was tasked with documenting the sprint and sharing our contributions with the wider Drupal and nonprofit technology communities.

It’s worth noting that the quality assurance team and the community engagement team came together for the first half of the sprint for an in-depth training on the Drupal contributed modules and components underlying RedHen Raiser. Ironically, we often get so busy building these sorts of tools for our clients that we don’t stop to educate our own "non-developer" team members on how stuff works. By taking this time to dive into the nitty gritty with our project managers, marketing and operations folks, we create better advocates for these solutions and help ensure that everyone in the company feels like contributor to our success.

Planning for the Sprint

As ThinkShout has grown, the need for sprint planning has grown with it. Back when we first started these sprints, we could fit our entire team around a single table (covered in pizza boxes and beer) and call out with development tickets we each needed help with.

Now, with a team of 18 working together from 11am to 5pm, these sprints take a bit more planning - to say nothing of balancing the opportunity cost of investing a collective 108 hours of non-client work into a single week. To keep things running smoothly, we’ve taken a more project-planning-esque approach to our sprint days:

  • Scheduling in advance: The date and time of the sprint is scheduled a month in advance. We used to just stick with the last Friday of the month, but found that this sometimes excluded certain team members on deadlines or vacation. Now, we coordinate a bit more tightly to help ensure participation of as many team members as possible.

  • Laser focus: the focus of the sprint is announced to the team three weeks in advance. This gives the team time to think about stuff they want to work on, and add to the feature backlog in the weeks coming up to the sprint.

  • Pre-sprint planning meetings: The department leads meet a week before the sprint to form teams and structure the sprint agenda, and prioritize the development/feature backlog two days in advance of the sprint.

  • Pre-sprint presentations: The week before the sprint, we do a short, company-wide presentation on the sprint topic at our weekly staff lunch. This helps energize the team and sparks knowledge sharing in the lead up to the sprint day.

  • Formally "opening" and “closing” the sprint day: As our sprint commences, we kick things off with a quick, all-staff scrum. More importantly, we pull the team back together at the end of the day for each sprint team to present (and celebrate!) what they’ve completed.

Outcomes of Our RedHen Raiser Sprint

So what does it all mean? This new approach to our team sprints resulted in just shy of 100 commits on RedHen Raiser and the underlying modules that power the distribution. We published a new release of RedHen Raiser, RedHen Donation and the RedHen Campaign modules - as well as a release of our base RedHen CRM suite.

One of the biggest wins to come out of the sprint are automated tests powered by Behat. Tests are triggered with every commit to GitHub and run on Travis CI. At this point, test coverage is a bit limited, but the foundation has been laid for complete test coverage for RedHen Raiser, a critical factor when organizations are evaluating which software to use.

To top it off, we cleaned up a few RedHen project pages on Drupal.org and began working on a RedHen-specfic QA testing plan. We also reached out to the RedHen open source community to let them know what we were up to and how folks can continue to get involved. Most of all, we are proud to say that this effort is a huge contribution to the nonprofit tech community, in that it provides major improvements to a powerful tool that can be leveraged for free - and has the documentation to support it!

All in all, the ThinkShout team came together in a big way, and accomplished much more than we could have if we had remained siloed in our approach. We had a lot of fun, drank some beer, ate some good food, and got to collaborate as a whole team on something really cool. We’re really looking forward to the next one!

Categories: FLOSS Project Planets

Justin Mason: Links for 2015-01-27

Planet Apache - Tue, 2015-01-27 18:58
Categories: FLOSS Project Planets

Laura Arjona: Upgrading my computers to Debian Jessie: Husband’s laptop (Acer Aspire 5250)

Planet Debian - Tue, 2015-01-27 18:39

This is an old laptop, with AMD E-300 processor, 6 GB RAM, Radeon HD 6310 VGA and Atheros AR9485 wireless network adapter.

It was running Windows 7 (preinstalled). The hard disk failed, and I put the hard disk of another laptop (a broken Acer Aspire One D255) on it. Surprisingly, the Windows 7 on it booted (after some self-configuration that took quite long), but it was a Windows 7 Home 32bits, so it was only recognizing 4 GB RAM. That was the perfect excuse to convince my husband to install Debian in the laptop and begin his transition to a free OS. Yay!

I installed Debian Jessie from scratch last summer. Everything went well (the installer went fine, 8 months before than its RC1 release, congrats Debian-boot team!).

I needed the non-free radeon driver for the graphical display :/

Jessie is running GNOME3 desktop, and I’ve been seeing all these months the transition to 3.14 version, and later, the integration of the “Lines” theme (by Juliette Belin), which I like very much.

I have problems to watch high quality videos, in every player that I tried (VLC, Totem, mplayer) the audio and video are not synced, and video sometimes freezes. I’m almost sure that the problem is what mplayer says: “Your system is too SLOW to play this!”.

I tried to install the ATI non-free driver for better performance, but after successfully install it and reboot, GNOME was not starting (I got a black screen, no gdm greeting me). I could log in tty2, though. I don’t know if I did something wrong, how to solve the problem, and I don’t wanted to waste time, so I uninstalled it and returned to the non-free firmware that goes to the Linux kernel. For now, when I need to watch a video that gives those problems, I upload the file to my GNU MediaGoblin site, or use WinFF to reduce size/quality.

Overall impression

Fine! Both my husband and me are very happy.

The installation went really well.

I’m not a GNOME expert user but I find it easy, intuitive, and he found it easy too.

My husband uses the computer to surf the web, watch some videos and online series (we had to install non-free flash plugin from Adobe #grr), read mail from the browser, write something in LibreOffice and print it (hey! we just plug the printer/scanner and it works, no need to install drivers!), scan some image and send it by email… I set Debian as default in GRUB, and the switch from Windows has been very natural for him (he was already using Firefox and LibreOffice in Windows. He still says “I’m a Windows user” although he is just using Debian for months!).

He bought an IPhone 4S (#grr!) and I tried to connect it as shown in the corresponding Debian wiki page, but it didn’t work (I got “segmentation fault” when connecting the phone). However, it is recognized by Shotwell and we can copy all the photos and videos to the computer, which is what we wanted to do. So no problem on that side, either.

In conclussion, one more computer at home running Debian (“future stable”), and we don’t run Windows at home anymore :)

Filed under: My experiences and opinion Tagged: Debian, English, Moving into free software
Categories: FLOSS Project Planets

François Dion: A new blog on future tech and innovation

Planet Python - Tue, 2015-01-27 17:52
I invite you to visit and bookmark my multilingual future tech / innovation / 3D blog. I just started it, and I think you'll like it:


There might be some cross posts, particularly since Python and the Raspberry Pi are used in so many innovations.
Categories: FLOSS Project Planets

Ian Ozsvald: Annotate.io self-learning text cleaner demo online

Planet Python - Tue, 2015-01-27 17:51

A few weeks I posted some notes on a self-learning text cleaning system, to be used by data scientists who didn’t want to invest time cleaning their data by hand. I have a first demo online over at annotate.io (the demo code is here in github).

The intuition behind this is that we currently divert a lot of mental resource early in a project to cleaning data and a bunch of that can be spent just figuring out which libraries will help with the cleaning. What if we could just let the machine do that for us? We can then focus on digging into new data and figuring out how to solve the bigger problems.

With annotate.io you give it a list of “data you have” and “data you want”, it’ll figuring out how to transform the former into the latter.  With the recipe it generates you then feed in new data and it performs the cleaning for you. You don’t have to install any of the libraries it might use (that’s all server-side).

Using Python 2.7 or 3.4 you can run the demo in github (you need the requests library). You can sign-up to the announce list if you’d like to be kept informed on developments.

Ian applies Data Science as an AI/Data Scientist for companies in ModelInsight, sign-up for Data Science tutorials in London. Historically Ian ran Mor Consulting. He also founded the image and text annotation API Annotate.io, co-authored SocialTies, programs Python, authored The Screencasting Handbook, lives in London and is a consumer of fine coffees.
Categories: FLOSS Project Planets

Laura Arjona: Upgrading my computers to Debian Jessie

Planet Debian - Tue, 2015-01-27 17:40

Until now, I usually run Debian stable at work (in my desktop PC) and stable or testing at home in my laptop. I was upgrading to testing during the freeze, and then, stay in testing (future stable) or stable (when it’s published) until the next freeze.

I have changed this ‘conservative’ pattern. I’ve been running Jessie for many months now, and here I’ll document the different experiences in the computers that I use.

Upgrade or clean install?

I decided to upgrade my computers instead of making a clean install (except in the ones  that were not running Debian).

Although the upgrade process have been fine, I’m still not sure which is the best for my needs. Installing from the beginning forces me to re-read the feature list of the different pieces of software and choose the one that fits best (not the one that I was using some years ago). And maybe I just don’t need that non-free driver anymore because there’s free replacement already, the installer is wise. OTOH, upgrading is easier and quicker, and I got all my software and configurations (and my rubbish) there, nothing is lost.

The computers

Here I will link the blog posts of each computer that I upgrade, when I finish writing the corresponding articles:

  • Husband’s laptop (Acer 5250): Clean install – Done, and OK!
  • My laptop (Compaq Mini 110c): Upgrade – Done and OK!
  • Home server (HP Microserver N54L G7): Upgrade – Done and OK!
  • PC at work (motherboard Asus P5KPL-AM-SE): Upgrade – Done, some issues.
  • Mini-laptop Airis Kira N7000 (ARM board, 128MB RAM) – Clean install – Pending

You can comment in this pump.io thread.

Filed under: My experiences and opinion Tagged: Debian, English, Moving into free software
Categories: FLOSS Project Planets
Syndicate content